Slashdot Mirror

Not the most widely used software maybe, but SBCL is taking its time porting to ARM, Clozure CL doesn't have a port I'm aware of, nor does CLISP. The only Common Lisp implemantation I know of that works on ARM is ECL.

CMU CLis a Common Lisp compiler/interpreter (written in cl). Its code is just beautiful - after about 1-2 months since my first contact with lisp I understand nearly everything at first glance. (SBCL also have very nice code). OpenBSD's code (written in C) is also very clear and pretty.

There are alternatives.

I'm starting a project adapting the strongtalk vm to Ruby.

The strongtalk vm is based a very sophisticated new technique called type-feedback, where statistics are taken on the program while it runs, and inlining, specialization and other optimization take placed based on what types are seen to be the common cases in running code.

Probably the most exotic thing the VM does deoptimize running code (for debugging and when the definitions of classes change in a way that invalidates the optimizations), because it actually transforms the activation records on the stack (rewrites the stack!) in order to match the transformation of the object code.

Currently Strongtalk only runs on Windows, and it's not entirely debugged, but it is working and fast. It would need some extensions for Ruby, but even YARV lacks support for continuations...

Another much-better-than-most compiler that I may adapt to Ruby is Steel Bank Common Lisp. It runs on all Unix platforms and is the fastest lisp. It's a more conventional compiler than the Strongtalk VM. I think it's optimizations are all static, and so it can't do much with optimizing polymorphic calls, unlike strongtalk, but it's static optimizations are very good.

I've used to have rather profound C++ experience (about ten years now). I've wrote a Race-Track Microtron control system in it and some other stuff like that, really :-) But I still fail see in which way it's better than Lisp, besides some (but not 10x-20x as when compared to languages like Python in Perl) performance gain, which is not always critical. It's possible to write applications, device drivers and operating systems in it, as well as databases, compilers, GUIs, web applications and lots of other stuff in it. I have some doubts concerning hard real time, but given the fact that GC can be locally avoided/inhibited using rather simple techniques, I think there should be no much problems there. C++ experience is useful thing, but I think that Lisp is in no way less important.

It is perhaps ironic that the Dylan Language Wiki is written in PHP, but that is being rectified.

PHP isn't obsolete because a lot of people want cheap web hosting, and PHP is what's easily around.

I personally wish it would be dead in favor of Mason and Rails, but right now PHP is like a swarm of super-powered cockroaches - every damn web host in the planet supports it, and it isn't going away because every damn web host in the planet supports it! PHP is great because of its availability and its simple and powerful syntax, but there's little else to keep its head above the water. And with things like Smarty, it isn't *that* awful to work with.

Well, my cheap web host gives me SSH account and I could install SBCL. Maybe one day I'll install Rails there too, I've used it on a project and I've liked it a lot.

Your point is well taken, but note that your problem is basically a combination of lacking documentation and you still learning the language. The first is the fault of the language (well, the implementation, but still), while the latter is nobody's fault, because it's an inevitable situation. I would assume that if you were on the clock, you would already know the language you were working in. Ie. if the project were in C++, you'd already know C++, or else you wouldn't have gotten hired to work on it.

What implementation are you on, anyway? Depending on what kind of networking you need, the trivial-sockets library could be up your ally. Very simple way to connect Lisp to a network. If you're on SBCL, there is SB-BSD-SOCKETS, which exports an API pretty similar to standard UNIX sockets. Of course, for the best in documentation quality, springing for a copy of Allegro CL will get you the ACL socket API. Since you're a student, you can get a copy for a mere $99, or about what you'd pay for an academic version of any other commercial software.

Paul Graham's book, On Lisp, is the single best book on programming I have ever read. You can get it as a PDF from his website, for free.

You will also want to read his essay, Revenge of the Nerds, for some serious insight into why Lisp is just so darn good.

If you're just starting on Lisp, the best place to start is with GNU CLISP, although you will find yourself wanting to use Emacs with SLIME to interact with your Common Lisp environment. I use SBCL, but CMUCL and CLISP are also acceptable. On my Powerbook, I use SLIME with OpenMCL.

As it happens, there already exists a class of languages that are strong at manipulating syntax trees, and at writing parsers. Several of them also support dynamic compilation, meaning that your language implementation can choose when to stop dicking with the syntax tree and instead compile it to native code.

One such language is Steel Bank Common Lisp. SBCL runs on a number of platforms, chiefly Linux. It is a native-code compiler -- contrary to the usual myth about Lisps, SBCL doesn't even contain a Lisp interpreter; it compiles all expressions to native machine code. If that doesn't suit, consider CMUCL, from which SBCL is derived; it includes both an interpreter and compiler.

Common Lisp is designed to be extended. You can customize the compiler by writing compiler-macros, which specify optimizations or special cases for compiled code. You can write your own parser, or extend the built-in syntax with read-macros -- so you can use a mix of built-in syntax and your own, or gradually move from the former to the latter while having a working code base at every step.

I don't know if any Common Lisp implementation wants to be the de-facto open source lisp, but SBCL is very popular in the News, Web, and IRC. Throw Emacs and SLIME into the mix and you get a really nice system.

Complains about APIs in Lisp were true some years ago, but not today - you can find libraries for LISP for any area, including opengl, gtk and databases.

I disagree to call Java's pakage structure as "sane". IMHO it's "insane" - it disturbs more than it helps. It proves that the knowledge become a primitive data when it fails to a tree-like structure, instead it must be described based on more general rules.

Apart of Lisp, many other FP languages have excelent support for concurrent programming, either emebedded to the language (Erlang, Mozart, Mercury) or as an extensions (Haskell, ML). For example, after doing concurrent programming in Erlang you would certainly complain of being forced to go back to Java.