Slashdot Mirror

I'm actually mostly interested in putting a Qt GUI on a Common Lisp or Chez program.

You're in luck

Lisp has it's points...but it's not that great. And many of the libraries that I want to use are a real pain to use from it. And the only decent development environment I've found is actually for Scheme (Racket), and while it provides, e.g., futures, it doesn't actually execute the code in parallel. (Yes, I know that's not actually a criticism of Common Lisp. For that stick with the libraries and the lack of a development environment.) P.S.: I once, long ago, bought a copy of Franz Lisp (my first common lisp). It was OK, but not great. And updating it would have cost me the other arm and leg. A usabe version isn't cheap. So I formed my opinions recently based on SBCL and CMUCL.

Emacs with SLIME nowadays is pretty nice. I think it's the best language environment I've ever used really, and what keeps me going back to CL despite knowing better (shouldn't have picked up SML...). The debugger is particularly excellent, and the inspector, xref support, etc. aren't too shabby either. As for libraries, there are plenty of excellent libraries for most every problem domain, but finding them over the half-finished ones and then managing your personal library... was unpleasant. Until Quicklisp appeared a couple of years ago. Now finding/installing/loading libraries is downright trivial: (ql:quickload #:SYSTEM) and you're done (Quicklisp will fetch the system and any dependencies if they are not available locally). It makes deploying programs muuuuuuch simpler (how much time I wasted keeping my development and deployment environments in sync, oi!). It also has the equivalent of apt-get upgrade, makes life easy when you're someone working on a system in quicklisp (you can use common-lisp-controller to make all Lisps on the machine prefer your development copy), and even manages your SLIME install (finally making it accessible to newcomers who have no idea what their .emacs is).

CL has two things going for it: the standard provides a very complete language (and there's community consensus on extensions for threading, networking, etc.), and the Common Lisp Object System is the best OO language available. Of course, those functional programming folks say OO is sin...

You say you want to "code for personal reasons", which I take to mean because you find programming enjoyable and want to write programs for fun.

Then I would absolutely recommend Lisp and Smalltalk. For Lisp, you can get started with Lisp In A Box and Peter Siebels' "Practical Common Lisp". For Smalltalk, try Squeak accompanied by Squeak by Example. It's all free.

No, you are probably not going to get a job writing in either of these languages, but learning them may indeed help you get a job, as they are both conceptually deep, and their influences are broader than many realize: JavaScript borrows heavily from Lisp, and Ruby and Objective C from Smalltalk. Even Python and Perl have some Lisp concepts in them. In fact it seems that every new dynamic language to come out in the last twenty years owes something to these two languages. They are like the Greek and Latin of programming languages.

If you like continuations you can certainly have them in an OOP language, or even a hybrid OOP/functional one if that's your thing.

There are a few problems with functional programming languages that have prevented their true adoption anywhere.

1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.

Common Lisp (and Scheme, even more so, although the community is more oriented toward impure functional style) enforces no fixed paradigm. It can be used functionally (conses happen to be a pretty good data structure for functional algorithms), but is more often used in an object-oriented manner. It was even one of the first OO languages, and AFAIK the first to implement multiple dispatch. It even has a powerful imperative operators.

Thanks to macros and the metaobject protocol you can even add new paradigms to the language. Paternalistic, Lisp is not.

3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead. For a consumer application, that overhead usually doesnt impede adoption (its more like the software is poorly written than the applications environment is too inefficient). But when talking about server programming the costs of running something under Ruby vs C are astronomical, and the same problem arises with functional programming. It might not hurt the consumer that the Python implementation of their music player consuming 30% more clock cycles than the exact same program written in C, but it does cause huge scaling issues with popular resources like Twitter.

4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO, but professionals should enter the game knowing how the underlying system runs and that making tradeoffs for readability by someone who doesnt know the language anyway vs performance benefits falls to the wayside. Developer time is important, but when you factor in the massive overhead trying to get 20+ year professional developers in C to try to think functionally you are never justifying the upfront cost of using the languages.

Languages like SML and OCaml are actually more optimizable than C. Thanks to providing more type information &c they can take advantage of fancy whole program optimization and whatnot.

The "way hardware works" is an artifact of C being the dominant language. There's no reason hardware couldn't (and it has before) have GC assistance, type checking, capabilities, etc. It's really not appropriate and scalable to view the computer as something that flips bits around a gigantic linear array... it was reasonable to deal with that when you had 4000 words, but not when you have 400000000 words.

Software is nice because you can abstract! Writing programs to a model of an infinite store that Just Works (tm) is beneficial to everyone -- it frees source code from a particular hardware implementation, is easier to reason with, and separates the concern of hardware resource management.

There are other ways than rewriting the same thing several times. You don't even have to use C or C++. You already need at least different layouts for desktops, tablets (really just desktops without the input devices), and phones (or: tiny screen devices) for an application to be usable. So what is the advantage of using an overgrown design-by-committee hack that has repeatedly rejected all innovation in the name of compatibility? It doesn't help that HTML5 is probably more difficult to implement than the entire rest of an operating system.

Good points, fair criticisms...

However, I do think the situation is improving (a bit too slowly perhaps) and I don't think its importance is now past and nothing's being done about it. It's certainly not popular - never really has been and may never be - but it still is important to some (including in real-world, commercial settings of course) and I think it will continue to be. (At least I hope so).

If you hadn't come across it last time you looked CFFI is the FFI of choice now and I think it does have fairly good documentation (at least it's a lot better than many Lisp libraries ;-)).

It already could, through parenscript.

Not going to be the next firefox in terms of popularity... but lisp in a box is just nice for getting into lisp/emacs on any platform. Used to be a big learning curve how to set slime, etc. up and all that.

http://common-lisp.net/project/lispbox/

Well, someone added a decent text editor a couple of years back...

Hi Try out ELKS http://elks.sourceforge.net/ and Movitz LISP kernel http://common-lisp.net/project/movitz/ on your machine. Both are excellent.

As modern programming languages (Python, Ruby, and Scala) are implementing Common Lisp features (closures, variable capturing) and the online availability of Practical Common Lisp, it seems now is a good time for younger people to learn CL. The icing on the cake here is that there are alternatives for Vim users to develop Lisp without using SLIME.

If you have ever worked with static analysis, my criticism is vacuously true.

Hehe! Indeed I haven't. However, I'm sure the Lisp compiler folk have and though I don't really understand what their compilers are doing even after reading about them (e.g. http://common-lisp.net/project/cmucl/doc/CMUCL-design.pdf (somewhat dated now)), fortunately they do seem to work very well. I see the validity of your criticism now but I don't expect (or find in practice) the modern Lisp compilers to be noticably any less clever than e.g a modern C compiler.

how does it come that Lisp always comes out rather high in those rankings, while newer languages like Ruby and Python and up deep down at the bottom?

Because Lisps have real compilers.

In terms of expressiveness they all are very similar, yet nobody seems to have bothered to write a proper native code compiler for the newer languages, even so the popular interest in them is much larger then that for Lisp. Is there any fundamental reason for this?

No

the same kind of power they get with Lisp and Ruby, combined with a nice, small, regular syntax

In other words, this is just a reinvented Ruby targeted to the JVM. Without macros, what's the point? Why not just stick with Common Lisp and get all the power of Lisp, not just some of it, and still have a "small, regular syntax"? You can even use ABCL if you want to target the JVM.

Lisp is a language that CompScis see for two months at University before leaving it behind. [...]

Not necessarily true. Search /. archives for Paul Graham for a "famous" example of someone successfully using Lisp in a commercial product. Personally, I find the Emacs dialect of Lisp to be unfortunately restrictive, lacking even lexical closures. The Common Lisp emulation package helps out quite a bit but then one is still left without things like loop or CLOS. And the addition of SLIME and things like slime-eval are also, IMO, quite useful. However, I'm keeping an eye on Climacs because I would love to have an Emacs written with/in Common Lisp.

Then may the Forth be with you!

Great! Another Lisper! :-)

Here is a LiveCD for getting things done. Though truth be told, Dylan is a beautiful language; and my heart goes out to the Gwydion hackers, this CMUCL/SBCLers considers them semantic blood relatives ;-)

ECMAScript 4 will be a modern language in all senses of the word. It will support optional type annotations, destructuring assignment, generators, convenient inheritance, and all the other trappings of a modern language.

With ECMAScript 4, the advantages of running anything other than Javascript fade away: you still have all your Ruby/Python/Lisp features, just spelled differently.

And from the browser point of view: would you rather create a generic scripting framework or add one language and be done forever?

Also, instead of trying to compile languages to MSIL, why not just write a source-to-source translator to Javascript? Isn't that what some people do to Java these days?

They're working on it (sort of). These types of concerns are being addressed much more quickly nowadays as interest in Common Lisp increases. CL will be a much nicer Lisp to have underneath Emacs anyway.

Incidentally, most (if not all) CL implementations are compiled nowadays. Even ones that act as an interpreter can compile forms behind the scenes quickly enough that you can't tell the difference.

Learn LISP!

It has a funny name, and carries the mystique and credibility you seek. Nothing says "way old school" and "MIT Wizard" like piles of LISP with your tag on them. Of course, you'll have to leave vim behind - there is only one, true tool for the LISPer, now that dedicated machines like Symbolics are all in the museums.

The opportunities here are boundless - there are whole categories of libraries for HTTP and HTML that simple don't exist yet! If that seems to trivial a challenge, why not look into one of the projects to write and OS in LISP?

The LGPL is in no way "lesser" than its hideously deformed cousin the GPL.

1. If I don't want anyone doing anything with my code and making it non-GPL (eg: for stand-alone apps): GPL
2. If I don't want anyone doing anything with my code and making it non-GPL, but I want them to be able to *use* it as a library and release the product under any license they want (barring changes to my library): GPL with linking exception
3. If I want anyone to do anything they like with it, including possibly making trivial mods and re-releasing it as their own (eg: OS bindings that I don't want to support): Public Domain

It makes execution a lot faster than bytecode interpreting, and it makes development a lot faster than static (c-style) compilation. So yes, having a native compiler as part of the runtime is a very nice feature. In fact, lisp even lets you do things like implement a natively compiled python without having to do any work on code generation.

I'm still convinced that no conversation of python or ruby is complete without mentioning the intriguing Common Lisp. If you want a web framework with it, check out Weblocks

I'm not sure why this was ever supposed to be funny. Emacs has always been unapologetically a meta-editor. It's got lots of great editors. I've found c-mode (more of a supermode, actually) and python-mode (with a couple extensions) to be great. And SLIME is so good it's practically mandatory for anybody writing Common Lisp. I haven't seen anything equal to SLIME, on any platform or for any language. It makes Intellisense look like Notepad -- it's just insanely productive.

Ehm, concerning Emacs, if you care about code completion (especially fuzzy code completion) and all silly kinds of jumps and cross references (which are good to have, no objections here), take a look at Slime. There is also a nice video of Slime available - 150 megs, but definitely worth watching. I would say that it is an etalon of what's possible in Emacs, as far as the potential IDEness is concerned. Note that the video is quite an old one, the development got much further by now. I especially like the connect-to-any-computer-via-network-and-run-remotely part of Slime. :-) The demonstrated not-so-trivial config is something that you usually set up once and then you just use it (and you can always, for example, automate connecting to different machines, if you need it).

Of course, somebody has to write the major mode for your language, and kids these days like Java more, so they do their IDEs in Java and not in Emacs Lisp. But that is more of a social issue than a technical one. Emacs is still very powerful, even though at times I would like something running a more modern language. (Rather Common Lisp, or Scheme (power through simplicity ;-)), preferably - but no Java, for God's (or gods' ;-)) sake. I consider Java to be soo seventies, as I tried Smalltalk-80 once and found it "a bit" more powerful.)

Ehm, concerning Emacs, if you care about code completion (especially fuzzy code completion) and all silly kinds of jumps and cross references (which are good to have, no objections here), take a look at Slime. There is also a nice video of Slime available - 150 megs, but definitely worth watching. I would say that it is an etalon of what's possible in Emacs, as far as the potential IDEness is concerned. Note that the video is quite an old one, the development got much further by now. I especially like the connect-to-any-computer-via-network-and-run-remotely part of Slime. :-) The demonstrated not-so-trivial config is something that you usually set up once and then you just use it (and you can always, for example, automate connecting to different machines, if you need it).

Of course, somebody has to write the major mode for your language, and kids these days like Java more, so they do their IDEs in Java and not in Emacs Lisp. But that is more of a social issue than a technical one. Emacs is still very powerful, even though at times I would like something running a more modern language. (Rather Common Lisp, or Scheme (power through simplicity ;-)), preferably - but no Java, for God's (or gods' ;-)) sake. I consider Java to be soo seventies, as I tried Smalltalk-80 once and found it "a bit" more powerful.)

As a complete programming noob looking to get into web-related design and things of that nature, what languages are good to start with and to branch to other languages? Would that be like C-> PHP -> SQL? What other languages apply and/or in what order are languages needed to learn to start to bring things together for well designed websites?

http://common-lisp.net/project/cells/

http://common-lisp.net/project/cells/ is a dataflow extension that provides Common Lisp with classes where instances of the class have properties (slots in lisp parlance) that can be calculated like spreadsheet values.

This isn't strictly true, at least not on the Apple JVM,...

Based on this non marketroid page, it seems that apple's jvm compiles the java standard library at install time. Then it can just mmap the library at execution. It also seems to mark all memory in this file as uncollectable. It would be nice to do this for other java libraries as well, but then you may start to wonder why, exactly, you were using JIT in the first place.

Apple developed an innovative new technology that allows Java code to be shared across multiple applications.

New and innovative? Hardly. Shared libraries were implemented by Multics in the 1960's. Apple's just doing what everybody else (except, I guess, some folks at Sun) realized was a good idea years ago. As for making some objects uncollectable, Lisp was doing that and many other very cool things, long before java.

I use Vim with the Steel-Bank Common Lisp compiler.

If you don't use SLIME, then you're really missing out. I switched from vim to emacs a year or two ago for this reason. Using viper-mode in emacs gives you VI keybindings, so you still have a real editor.

There is a project to create a LISP OS for x86 architectures -- it's called Movitz. It's progressing a bit slow, though, because of a shortage of devs able to do the low-level work necessary. That's improving, and it now has VGA capabilities and such, but it's a long way yet from being complete.
Still, you can already run it on an emu like BOCHS, and I think Qemu can handle it in virtualization now.

http://common-lisp.net/project/movitz/

Pity that you need another OS to run emacs

Lisp, J, O'caml, Erlang, Smalltalk all look like safe languages to write in. And yes, they have operating systems in Lisp.

I'm very picky (i.e. a perfectionist), and I've found something wrong with every language I've tried. That's why I'm working on a language of my own (Mana), but progress is slow, as I'd rather take a few extra years and have a better result than rush things out the door.

I get a lot of pleasure out of programming in Ruby. It has a few quirks, but the big problem is that implementations are so slow. Maybe with Ruby 2.0 this will all be better. At any rate, a lot of the software I use on an everyday basis (especially for email) is written in Ruby (by me).

OCaml is a language I could actually write an operating system in. It's closest to ideal of all languages I've found. A friend of mine was actually writing some code to allow drivers for Minix 3 to be written in OCaml. I would have gladly written some drivers afterwards; unfortunately, he abandoned the project.

I'm also a big fan of Common Lisp. People complain about its parentheses, but once you get over that, it's a very powerful language, and, better yet, you can easily extend and adapt it. There actually is an OS being written in Common Lisp: Movitz.

Why not do a UI in Lisp?

``Have you used wxCL?''

No. I write GUIs very rarely, and I don't program in Common Lisp a lot, either.

``And about ECL then I had to add "or you don't mind your application being infected by GPL".''

How does ECL impose the GPL on your application? Looking at the latest Copyright file, it says ECL is under the LGPL. This means (1) no GPL and (2) no restrictions on what applications can link against ECL.

A know the answers for some of your questions:

1. What is Lisp, and where to find the community web sites

Cliki is a good start:

http://www.cliki.net/index

2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows

On Debian: apt-get install sbcl

For windows try Lispbox:

http://www.gigamonkeys.com/lispbox/

3. Basic language grammar, including CLOS

The best text is "Practical Common Lisp":

http://www.gigamonkeys.com/book/

4. How to use ASDF (including complex examples)
5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more
6. How to package a standalone Lisp application to deliver to customers
7. How to use UFFI

CFFI seens to be a better option:

http://common-lisp.net/project/cffi/

With a good manual:

http://common-lisp.net/project/cffi/manual/index.h tml

8. How to set up a Lisp web application server (modlisp or Araneida or ...)
9. How to use the most common libraries: CLSQL, OpenGL, SDL

Common lisp community is growing, and the OS integration, libraries and documention is improving.

A know the answers for some of your questions:

1. What is Lisp, and where to find the community web sites

Cliki is a good start:

http://www.cliki.net/index

2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows

On Debian: apt-get install sbcl

For windows try Lispbox:

http://www.gigamonkeys.com/lispbox/

3. Basic language grammar, including CLOS

The best text is "Practical Common Lisp":

http://www.gigamonkeys.com/book/

4. How to use ASDF (including complex examples)
5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more
6. How to package a standalone Lisp application to deliver to customers
7. How to use UFFI

CFFI seens to be a better option:

http://common-lisp.net/project/cffi/

With a good manual:

http://common-lisp.net/project/cffi/manual/index.h tml

8. How to set up a Lisp web application server (modlisp or Araneida or ...)
9. How to use the most common libraries: CLSQL, OpenGL, SDL

Common lisp community is growing, and the OS integration, libraries and documention is improving.

Apart from the now old-school Lisp OS:
  http://common-lisp.net/project/movitz/
  there is someone who's working on booting SBCL cores directly with the bootloader in Forth) [it boots, but the cross-compiler has some issues]
  there's a version of smalltalk (of squeak?) that runs without any underlying OS.
  There were several lisp or scheme *chips* in the 70s and 80s.

Also, what exactly do you see in common between Java and Haskell?

Finally, how in the world is that comment even slightly interesting?

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

It's 2006 --- no programmer of desktop/workstation/server programs is going to spend time optimizing their code [...]

1) Programs are becoming platform-agnostic. [...]

2) The world is moving towards higher-level languages and higher-level programming constructs. [...]

You may be interested in the Movitz project. Step 1: get Common Lisp running on the metal, bare x86 hardware (they're doing reasonably well here) Step 2: ? Step 3: profit

Let me know when the world comes to their senses and starts using Scheme instead, or some future or past dialect that has not a thousand page standard and a marginal packaging system.

Well, thousand page standard may not be always a good thing, but IMO it's better than having to rewrite your program from scratch every time you switch implementations. Different Schemes have different OO/package/whatever system, so porting between them is, well, something quite like complete rewrite. Concerning marginal packaging system -- would you please be more specific?

Plus call/cc is cool.

Agreed, but life is hard without unwind-protect (aka try ... finally). And it's possible to have continuations in CL when they are really necessary.

The examples in your first link requires a special Lisp machine to run on. I'm sure you could write Tcl drivers for a Tcl machine as well.

CPUs of "Lisp machines" were not Lisp interpretes. Their instruction set resembled something like Java or .NET bytecode actually AFAIK. Later Open Genera was released that allows one to run the Lisp OS on Alphas. Using high-level opcodes is not critical for Lisp (most modern CL compilers save CLisp produce native machine instructions for their target architectures).

Try writing a driver for the Linux kernel in Lisp. Heck, try writing a userland driver for X.org!

Yes, it's rather hard to do so, just because Linux kernel and X.org are written in C. If they were written in Lisp, it would be hard to write drivers in C unless authors cared to provide proper FFI-based "foreign" driver loading mechanism. There's nothing wrong with Lisp itself concerning low level stuff. For example, take a look at this beast (Lisp on bare metal).

As a matter of fact, I agree that C/C++ is safer bet in our world, but not because C and C++ are more general languages than Lisp is. It's just because most of stuff in use is written in these languages. Lisp machines failed (mostly due to management & political reasons), Lisp itself became the scapegoat for failed AI promises, so now curly braces are almost inevitable for serious programmers.

But nevertheless Lisp is worth learning as it can be the best tool for complex problems in many cases, and also due to the fact that it makes programmers more broad-minded. It's actually much more general than C++ in the sense that it easily supports almost any paradigm one can imagine. For instance, it's possible to seamlessly embed SQL, Prolog, HTML, etc. rewritten using S-expressions in Lisp programs.

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.

The solution to that problem is simply more introspection. See http://common-lisp.net/project/slime/ for an example.

I don't see how... Basically autocomplete isn't going to work when the program logic can be changed at runtime.

def missing_method(name, *args)
    if (random_boolean())
        do_a(args[0], args[1]);
    else
        do_b();
    end
end

Now when I call "string".foo(), it will eiteh rhave just enough parameters, or not enough, depending on, at runtime, if random_boolean returns true or false;

The solution to that problem is simply more introspection. See http://common-lisp.net/project/slime/ for an example.

BTW, emacs all the way ;)

Yes, some Lisp users give Lisp a bad name, and Lisp in general has been far less welcoming to new users than newer languages. Python, for example, is very welcoming and friendly to newbies. That's unfortunate, but it's far from universal, and there are indications that things are changing in the Lisp world, with the release of a new book last year (Practical Common Lisp, available free online as well as in dead tree format), and the Lisp in a Box project (download, install, and have a great (Free as in beer and freedom) Lisp environment set up in minutes).