one is being constanly reminded of the significant advantages which flow from using Lisp (new or otherwise); perhaps someone might care to prescribe newlisp as THE scripting language for Ethereum project?
Thanks for the link. Interesting to see a Forth like language again. Well suited for configurations tasks and built-in scripting. But I wonder if all the size optimizations they want to put in, will take too much speed away. Forth tends to be at least 5 times faster than a "normal" scripting language. Part of the speed comes from the fact that there is almost no function-call overhead, because programs are stitched together by concatenating copies of machine code pieces. I am not familiar with the inner workings of Etherum or Bitcoin crypt-coin software, so perhaps size or some other considerations are more important than speed here.
For Forth enthusiasts see also one of my past projects here:
http://www.newlisp.org/Projects/Gokumanual.html
Goku tried to be suitable for general scripting with the ability to import C libraries and interface to the Windows SDK for graphics (in a different package, than the one linked from the page above).
Jeff Fox has passed away, but his ultratechnology website is still up. Was very sad to hear of his passing, it is a great loss.
http://www.ultratechnology.com/
Are you familiar with it? He documented the direction Chuck Moore took with Forth, sounded really wild. ColorFORTH, blazing fast and implemented in under 4k. Jeff took me to visit Chuck and I saw ColorFORTH in action.
Quote from: "TedWalther"
http://www.ultratechnology.com/forth.htm
Are you familiar with it? He documented the direction Chuck Moore took with Forth, sounded really wild. ColorFORTH, blazing fast and implemented in under 4k. Jeff took me to visit Chuck and I saw ColorFORTH in action.
Useful if the Forth "distractions" were moved and pursued elsewhere? The challenge here is more whether Lisp and in particular newLISP can move quickly enough to claim (some of) the high-ground for development within this very new space (Ethereum)? newLISP might garner a large number of new adopters if it is seen to be robust enough and agile enough in what might be argued is its "natural place" in the application space?
Does one take the silence on Ethereum to mean what? One ... no-one within the newLISP community has an interest in the Ethereum space? or Two ... newLISP is neither robust nor agile enough as a development tool for real work within the Ethereum space? Any newLispers outside of the newLISP environment, interested, then?
Sorry to hear about Jeff Fox. He was part of a computer movement that I found extremely interesting -- Forth. It was so understandable, so logical. It made the world of computer programming accessible to ordinary guys like me.
Great memories! I never understood exactly what happened, but the world went a different direction and left me behind. There will always be a place here on this website to talk about Forth and the culture surrounding it. Probably in the Anything Else forum, but if not there then I'll make a place just for it. Forth was fun, and I miss it.
Etherium appears to be a branch of the most important social, political, and financial phenomenon of the decade -- Bitcoin. The bitchain and distributed database promise an honesty and accountability in transactions that is only beginning to be appreciated. This will be the technology of the next ten years, just watch.
A memory of the past, and a promise for the future.
I was forced to experience Forth in uni by my most excellent computer architecture lecturer, Terry Anstey. I was too young and naive to value the experience at the time, but I have just recently decided to remedy that failing.
newLISP needs a killer-app; I don't know if this can be it or not.
Sadly, I am not agile enough with either lisp or maths to lead the newLISP + Ethereum charge. I will, however, be watching with interest those who do.
Lutz, do you have anything else to offer here? Anyone else with an opinion?
In Forth, it is hard to track the status of the stack when reading code. You need a safe knowledge of the API to mentally track the status of the stack, what's on it and what each Forth word takes off or puts on. This is the reason that Goku had the ! and @ prefixes inserting an extra pop or push of the stack to transfer data between variables and stack. This allowed you to write more readable code, without loosing too much performance.
Today programming is done by many who are not programming professionals. Programming is just one tool among many. That is why today much higher demands are present for the readability of a language.
Quote from: "Lutz"
Lutz just reminded me of this classic piece: http://norvig.com/21-days.html Cheers! :)
Interesting observation, Lutz. That has helped me make a tech decision I've been pondering for a week or so now; thanks! :-)
But I must admit I am still confused about newLISP's possible Ethereum interface. Surely if there was a newLISP interface, it would be... newLISP... right? The causal non-programmer newLISP *users* of the newLISP Ethereum interface would be using newLISP. It's only the newLISP-Ethereum API/library designer who has to know & understand the Ethereum forth api and care about stack stability... no?
Quote from: "bairui"
But I must admit I am still confused about newLISP's possible Ethereum interface. Surely if there was a newLISP interface, it would be... newLISP... right? The causal non-programmer newLISP *users* of the newLISP Ethereum interface would be using newLISP. It's only the newLISP-Ethereum API/library designer who has to know & understand the Ethereum forth api and care about stack stability... no?
If Ethereum wants a virtual machine, why not use newLISP's internal cell-based representation? More flexible than the current stack based one they have now. And newLISP already compiles to it.
@TedWalther: I'm honestly not sure *what* Ethereum _wants_ from newLISP. Perhaps that's something @janeTA can clarify. I had assumed though they they were happy with their VM/API and were looking for others to ratify their party.
If there is $$ on the table, I wouldn't be surprised if they could hire someone to get newLISP to compile for the VM. If Lutz, Kazimir, or one of the other newLISP stalwarts don't want it, I'd step up to the plate. I'm guessing $10,000 to $15,000. Standard consulting deal, 1/3 up front, with milestone reports.
Excellent. That should sort things out, one way or another.
Patricia trees look cool, and are used in big data applications like BGP routing, etc. Very useful for quickly comparing/locating data organized by IP address, etc.
I wonder if Lutz would be open to adding Patricia Trees as a first class data type the way lists, arrays, and red-black trees are?
Patricia is a classic algorithm dating back to 1968.
http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/PATRICIA/
Great comparison of Patricia and Red-Black trees:
http://www.mcdowella.demon.co.uk/Patricia.html
So then updated this:
(new Tree 'blah)
with this:
(new RedBlackTree 'blah)
(new PatriciaTree 'argh)
While still leaving RedBlack as the default, so all old code with Tree still works. The idea kind of excites me.
Quote from: "janeTA"
Jane, what exactly are they looking for? A VM implementation? newLISP is indeed ideal for that. My first estimate stands.
newLISP can easily do the deduplication and the crypto optimizations.
Quote from: "Lutz"
Sorry. I have been reflecting on this.
Quote from: "bairui"
Having browsed Ethereum, the impression I immediately had was newLISP (any Lisp, actually) could be profitably put to work throughout the whole Ethereum space - the whole evolving Ethereum ecosystem if you like - from the foundational level right up through the whole applications space and beyond? Here was (almost) a "tabla rasa" where newLISP could possibly "sing its song" better, faster and smarter than perhaps anything else? Here was what looked to be a vacant "natural" fit for Lisp (AI winters aside)? Far too often Lisp seems to cede such nascent spaces to be filled by other "lesser" technologies? Perhaps this time Lisp could move more swiftly? ...
Quote from: "TedWalther"
Yes, I think I agree? However, I suspect that far "down" the Ethereum foundational chain might already now have been "captured"? Perhaps you might care to elaborate a little for a few of us mere mortals? Perhaps show us some "layers" where you think newLISP (in your example (and (better) more)) could intercede?
Compiling newLISP to run on the etherium VM, I leave that for Lutz to say if it is easy or hard. He just got it compiling into Javascript, so it may not be too hard.
It would be much easier to implement the Etherium VM in newLISP. That would be practical, fun, and easy.
The Etherium developers already have their "pythonesque" language to let people use the etherium. Using newLISP to compile the etherium variant of python to the etherium op-codes, would also be reasonably straight-forward.
Quote from: "bairui"
I'm not sure "Ethereum wants" anything? Perhaps its more what newLISP/ers can bring to the table (or even better, just how fast they can do that)? Three "language" layers look to be immediately in place within Ethereum? Their now ES2, their CLL, and perhaps something (else) for "writing" contracts? One suspects newLISP can be put to work somewhere in/around these (for starters), say? It looks entirely open for newLISP to move into what is the now relatively "vacant" space above that level - "clients" obviously but far far further up than that? The "tree" of possible development spaces looks very open to me? Perhaps someone can visualise and talk to this far better than I ever can?
Quote from: "TedWalther"
Nice opening gambit @TedWalther!
were newLISP a vendor-product one could likely hustle them for support at that $level? (I've tried a few) I'm unclear how large the newLISP communty actually is (clearly there are at least three alpha males within it, capable of handling the proposal) and whether the level of funding cited could be garnered from within it? one suspects perhaps not? one suspects also the "alphas" may also be overloaded with "$career" work?
rather than let this slip, though, perhaps some "local crowd" funding could be organised? could, say, a newLISp bitcoin address be set up against which such $funds could be pooled and work offset? would something like that work? btc could then be traded for ether later once Ethereum's ether hits the exchanges?
so for $15K the newLISP community gets what? like to perhaps map out the milestones/deliverables and ballpark schedule? sounds like it might be just the machine for generating quality Ethereum vmcode which by virtue of being quality gets used often and everywhere within the Ethereum community, which in turn generates ... ether ... for the newLISP pool (down the track)?
Sorry, my posts are becoming increasingly turgid :( I'm not flash with words, preferring visuals. I shall try to do better!
Quote from: "TedWalther"
I wonder if Lutz would be open to adding Patricia Trees as a first class data type the way lists, arrays, and red-black trees are?
While still leaving RedBlack as the default, so all old code with Tree still works. The idea kind of excites me.
Yes! Agree! I would second that. Good thinking!
Pure by theory radix trees seem to be faster but in practice the bit fiddling required is expensive. Looking at the implementation, I see source code about 6 to 7 times bigger than our RB-tree implementation. What exactly would patricia trees add? We have already execellent speed and scaling, better than hashes for big numbers (tens or millions) of keys in newLISP.
In general, I have no objections adopting a new dictionary algorithm. We already switched once from ordinary binary tree algorithm to the current RB-tree algorithm. What other things would Patricia bring to the table, we don't have already?
If anyone wants to implement this in C for testing/benchmarking in newLISP, they should go ahead. I am not convinced enough to try myself.
Ps: this also caught my attention:
"Standard Patricia imposes a restriction on the strings stored in the tree: no string can be a prefix of any other string. One reason for this is that distinguishing between the two strings would then require testing for presence of bits, as well as testing their value. "
Quote from: "Lutz"
Ps: this also caught my attention:
"Standard Patricia imposes a restriction on the strings stored in the tree: no string can be a prefix of any other string. One reason for this is that distinguishing between the two strings would then require testing for presence of bits, as well as testing their value. "
Thank you Lutz, that does look like a show-stopper!
meanwhile ...
Etherium lispy-things are charging onwards & upwards ...
https://github.com/ethereum/cpp-ethereum/wiki/LLL-Tutorial
where LLL = Low-level Lisp-like Language?
What would be useful would be some de-compilers from Ethereum-script (ESn where n = 1 or now 2) to their CLL or better LLL or even better LISP and so on?
What would also be useful would be some ... blockchain exploration tools?
Ethereum Blockchain Explorer in alpha ...
LISP to Ethereuim LLL in alpha ...
LISP to Ethereum CLL in alpha ...
Is there $$ to be made with any of these ideas?
>>Is there $$ to be made ???
indeed we'll all be making dollars.
For people familiar with Bitcoin, but not the thousands of local currencies made in the '30s...
http://www.depressionscrip.com/
Need more specifics please. Feel free to send me a private message if you have an idea of something that can make spendable currency in the near future (like, within a month).
LISP Ethereum client (lite) in alpha ...
What do you mean by "ethereum client". What does an etherium client do.