Page 1 of 2

Ethereum

Posted: Mon Feb 03, 2014 3:46 am
by janeTA
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?

Re: Ethereum

Posted: Tue Feb 04, 2014 5:43 am
by janeTA

Re: Ethereum

Posted: Tue Feb 04, 2014 3:54 pm
by Lutz
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).

Re: Ethereum

Posted: Thu Feb 06, 2014 7:35 am
by TedWalther
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.

Re: Ethereum

Posted: Thu Feb 06, 2014 7:38 am
by TedWalther
TedWalther wrote: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/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.

Re: Ethereum

Posted: Thu Feb 06, 2014 11:12 pm
by janeTA
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?

Ethereum

Posted: Tue Feb 11, 2014 4:01 am
by janeTA
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?

Re: Ethereum

Posted: Tue Feb 11, 2014 5:50 am
by Ryon
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.

Re: Ethereum

Posted: Tue Feb 11, 2014 8:29 am
by bairui
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?

Re: Ethereum

Posted: Wed Feb 12, 2014 1:36 am
by Lutz
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.

Re: Ethereum

Posted: Wed Feb 12, 2014 2:06 am
by rickyboy
Lutz wrote:Today programming is done by many who are not programming professionals.
Lutz just reminded me of this classic piece: http://norvig.com/21-days.html Cheers! :)

Re: Ethereum

Posted: Wed Feb 12, 2014 3:23 am
by bairui
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?

Re: Ethereum

Posted: Wed Feb 12, 2014 6:04 pm
by TedWalther
bairui wrote: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?
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.

Re: Ethereum

Posted: Fri Feb 14, 2014 6:58 am
by bairui
@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.

Re: Ethereum

Posted: Fri Feb 14, 2014 10:54 pm
by TedWalther
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.

Re: Ethereum

Posted: Sat Feb 15, 2014 4:12 am
by bairui
Excellent. That should sort things out, one way or another.

Re: Ethereum

Posted: Sat Feb 15, 2014 9:00 pm
by TedWalther
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/ti ... /PATRICIA/

Great comparison of Patricia and Red-Black trees:

http://www.mcdowella.demon.co.uk/Patricia.html

So then updated this:

Code: Select all

(new Tree 'blah)
with this:

Code: Select all

(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.

Re: Ethereum

Posted: Sat Feb 15, 2014 9:17 pm
by TedWalther
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.

Re: Ethereum

Posted: Mon Feb 17, 2014 8:35 am
by janeTA
Lutz wrote: ... 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.
Sorry. I have been reflecting on this.

Re: Ethereum

Posted: Mon Feb 17, 2014 8:57 am
by janeTA
bairui wrote: 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?
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? ...

Re: Ethereum

Posted: Mon Feb 17, 2014 9:11 am
by janeTA
TedWalther wrote: ... 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.
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?

Re: Ethereum

Posted: Mon Feb 17, 2014 9:17 am
by TedWalther
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.

Re: Ethereum

Posted: Mon Feb 17, 2014 9:31 am
by janeTA
bairui wrote:@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.
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?

Re: Ethereum

Posted: Tue Feb 18, 2014 4:51 am
by janeTA
TedWalther wrote: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.
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)?

Re: Ethereum

Posted: Tue Feb 18, 2014 11:43 pm
by janeTA
Sorry, my posts are becoming increasingly turgid :( I'm not flash with words, preferring visuals. I shall try to do better!