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).
Thinking about writing a C interpreter for Kernel 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.
- 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)).
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 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.
There is emscripten:
https://github.com/kripken/emscripten/wiki
; and here is asm.js:
http://ejohn.org/blog/asmjs-javascript-compile-target/
https://hacks.mozilla.org/2013/12/gap-b ... mizations/
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).