Ethereum

[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?

[janeTA]

[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">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).

[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/">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.

[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/forth.htm">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.

[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?

[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?

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

[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?

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

[rickyboy]

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">http://norvig.com/21-days.html  Cheers!  :)

[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?

[TedWalther]

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.

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

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