+ By this I mean you can get a lot done, in not very much code, and maintain it afterwards, and read and modify other people's code easily.
+ By this I mean you can get a lot done, in not very much code, and maintain it afterwards, and read and modify other people's code easily.
Even Alan Kay has been complaining about it since 1997 [1]. Looks like even our complaints get recycled.
1. http://video.google.com/videoplay?docid=-2950949730059754521
1. Code is data, data is code
Implications: everything should be a first class citizen of the language, able to be passed by reference, altered by functions elsewhere.
Examples: s-expression in lisp? Subclassing built-in types of oo language (python new style objects)
2. Configs are applied to code, so that the same code can run unchanged on dev beta and live. (this is my favourite reinvented wheel du jour - devops. In fact the whole 12factor app recently on HN is a great example of rediscovered wheels - or perhaps more fairly a great example of doing this guide to future generations too)
3. iPads are no way to type into unresizeable text boxes
... Edits coming when I get a keyboard
I find it fascinating, it's as if kids these days believe that their fathers had all the things they take for granted, like smartphones, tablets, AJAX, whatever, and then, because they were stupid, chose to use green screens and FORTRAN instead.
To pick Lua (my favorite of the technologies you listed), it has the following things that Tcl does not have:
- strict ANSI C implementation
- small implementation (15k sloc vs. 110k-160k for Tcl, depending on how you count)
- a fast implementation, with an even faster JIT
If you follow your argument to its logical conclusion then everything is just a reinvention of Lisp (including Tcl). But we have tools available to us today (like Lua) that are strictly better than Lisp or Tcl for some use cases. - only one dialect (sometimes changes between major versions,
but there aren't multiple dialects evolving in parallel).
- infix notation is preferred by many programmers, and is easier
to use for non-programmers.
- the language is small (more like Scheme than Lisp)
The Lua and LuaJIT implementations have the following advantages over SBCL (you didn't say which Lisp, so I'm just picking what seems to be the most popular one): - extremely portable
- extremely small
- easy to sandbox
- very good integration with existing C and C++While it's good as a standalone language, it's an outstanding extension language. It's small, trivially portable, and has excellent interop with C. It's not competition for Lisp in general so much as Emacs Lisp or vimscript, designed for systems that have a core written in C but need a lot of customization layered on top. Configuration for window managers, scripting enemy behavior for game engines written in brutally optimized C++, that kind of thing. Systems with a "hard and soft layer" architecture (http://c2.com/cgi/wiki?AlternateHardAndSoftLayers). (Incidentally, Tcl was also designed with this use case in mind.)
That said, if you're using Lua as your primary language but are proficient in C, you can add a lot of power to it pretty easily. The emphasis on C interop goes both ways. (Also, the implementation is very intelligently engineered, and is worth study if you're interested in language design or virtual machines.)
Lua is probably going to be faster, but one wouldn't exactly use a scripting language for math heavy stuff etc either.
It's kind of the opposite of Javascript, which went from 0 to release in a few weeks and had a bunch of design errors become permanent as a result. Lua and Javascript have a lot in common, and studying Lua may be a good way to see where Javascript is going in the long term.
Lua is significantly smaller than ECL, and a bit smaller than PicoLisp. According to sloccount, they weigh in at 432,818 (ECL), 15,018 (PicoLisp), and 14,309 (Lua).
This is strictly a limitation of languages like Lua, but in day-to-day use it sometimes becomes an advantage.
He has a point there. Lua is nice enough to write, but it is `func(arg, 'strarg')` where Tcl is appearantly `func $arg arg`. If I have to type that into an interactive prompt 200 times, I'd take the latter. If I want to write some complex program, I'd take the former. In other words, Tcl is optimized for writing, Lua is optimized for reading.
http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-...
Half the libs needed a source code change to the tcl interpreter. There were two main add ons (I want to remember one was called green eggs and ham???) which were incompatible, so if your lib needed A and another bit needed B you were stuck.
One thing it did have was very easy to write C plugins because everything is a string