New Year has come: thanks to Lutz

[hartrock]

[Update 2014-01-02] links: emscripten, Resig's blog entry to asm.js.



Beginning of new year and after doing things with newLISP for a while, it is a good time to say thanks to Lutz for:

[*] publishing newLISP under a community oriented open source license;

[*] being open-minded regarding suggestions for improvements (this is not a matter of course after working with a self designed language and developing it further for such a long time);

[*] being communicative with giving comments to many topics: for a better understanding, why some things are as they are (which helps to learn and to avoid unsuited paths).

[/list]
I've seen many programming language following different paradigms so far; amongst them are Pascal, Lisp (a classical variant sitting at terminals at a computer science department), C (near to the metal), C++ (the former + OOP with metal), Smalltalk (a very nice language for doing OOP consequently without thinking about the metal (view of Smalltalk programmers, VM implementors always (there may be rare exceptions) have to deal with the metal)), F-Logic (logical programming paradigm).



Thinking about writing a C interpreter for Kernel http://web.cs.wpi.edu/~jshutt/kernel.html">http://web.cs.wpi.edu/~jshutt/kernel.html, I've started working through a thick book about garbage collection (because such a project would need a garbage collector). Now I've stumbled about a new language just avoiding this big can of worms: it's very interesting to me, what's possible without GC and just ORO rules.



newLISP gives me (the unexpected) motivation to learn a new language. Under the things I like are:

[*] Clearly functional, but without being dogmatically functional (destructive functions where it makes sense).

[*] Very good docs.

[*] Very fast reaction with fixes to bug reports.

[*] Let the OS make for which it is made for: e.g.

 

[*] -> light weight processes instead of light weight threads.

[/list]

[*] The feeling, that there is a good sense for balancing different features to get high expressiveness without feature bloat (which would be difficult to be fully grasped).

[*] The capability of storing the state of a started newLISP system: this reminds me on Smalltalk images; possibly this feature could be used for a similar IDE functionality like in Smalltalk systems.

[*] System composition by starting newLISP and loading modules (libs): this is good for avoiding code bloat (in Smalltalk systems there is often the need to strip a very big development system (which can be hard)).

[/list]

One newLISP thing, I've stumbled over recently.

To me the following makes sense (this said with having some but without having much experience with newLISP):

[*] To prefer expanding of nested lambdas against proliferation of newly generated symbols with lambdas bound to them (closure style, see http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=15&t=4400&hilit=uuid">http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=15&t=4400&hilit=uuid). I think this is in line with the philosophy of the language.

I assume, the latter could lead to symbols bound to lambdas hanging around not being GCed (because there is none). On the other side there is the possibility to automatically generate names for symbols bound to lambdas, if it is really needed (due to the flexibility of the language): but then you should know why you are deviating from the default (philosophy of the language), and do it explicitely.[/list]

At last an interesting thing outside, but related to porting newLISP.

There is emscripten:

  https://github.com/kripken/emscripten/wiki">https://github.com/kripken/emscripten/wiki

; and here is asm.js:

  http://ejohn.org/blog/asmjs-javascript-compile-target/">http://ejohn.org/blog/asmjs-javascript-compile-target/

  https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/">https://hacks.mozilla.org/2013/12/gap-b ... mizations/">https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/

  http://asmjs.org/spec/latest/">http://asmjs.org/spec/latest/

.

This could lead to some newLISP interpreter running inside the browser, without too much porting effort.

Not to ignore the issues: good Javascript and DOM bindings are laborious (these and a newLISP interpreter written directly in Javascript could be an interesting project on its own, too).

[rickyboy]

Beginning of new year and after doing things with newLISP for a while, it is a good time to say thanks to Lutz for:

[*] publishing newLISP under a community oriented open source license;

[*] being open-minded regarding suggestions for improvements (this is not a matter of course after working with a self designed language and developing it further for such a long time);

[*] being communicative with giving comments to many topics: for a better understanding, why some things are as they are (which helps to learn and to avoid unsuited paths).

[/list]

Agreed, hartrock. Thank you, Lutz!!!!

[Lutz]

Thanks for the friendly words from hartrock and rickyboy. A good time for a big Thankyou and Happy New Year wishes do all who have contributed to newLISP in many ways:



http://www.newlisp.org/CREDITS.txt">http://www.newlisp.org/CREDITS.txt



PS: this file can also be found in the source distribution.

[HPW]

Hello,



As every year: Many thanks to Lutz for his ongoing support of his great newLISP.

This could lead to some newLISP interpreter running inside the browser, without too much porting effort.

Not to ignore the issues: good Javascript and DOM bindings are laborious (these and a newLISP interpreter written directly in Javascript could be an interesting project on its own, too).

This would be a fantastic addition, newLISP running everywhere!

I had a look at a few lisp-implementation of lisp's in javascript from this list:



http://ceaude.twoticketsplease.de/js-lisps.html">http://ceaude.twoticketsplease.de/js-lisps.html

You can see things like clojurejs (which are also quite big and  complex) as a proof of conzept.



A newLISP.js would be so great!!



And you could even think of newLISP on node.js!



Regards