Why don't people use LISP

LISP is powerful to use, easy to learn, and fast to run. It is also 100% open source. LISP has been around for ages. It is older than C++. I think all the world needs is C and LISP. All this C++, PHP, PERL, Python, and Ruby soup is just too much.

I have been studying PERL, but the second version of the language is already out but the VM and such are not yet recommened for production. I don't want to finish learning this "dead language" or have to port production code that I produce later into PERL 6. I have just started looking at Ruby and after reading up on this language I realized that it does not have a specification, so right now the specification of the language is the interpreter (as PERL did). That is the same error that PERL 5 made. They just kept adding stuff on instead of making a spec; eventually there was so much cruft that things were hard to change but relatively easy to maintain, therefore they could maintain the illusion that they did not make a critical error. The PERL guys do not want to admit that PERL is has become very "crufty" - even for itself. I like those PERL guys but they have been drinking too much of their own Kool-Aid.

Now, when I look at Ruby. I see them making a similar mistake. There exists a specification (DRAFT) of a spec for Ruby based on Ruby 1.8 that will be the official spec into the foreseeable future for a Ruby spec. I guess the Ruby guys learned from the mistakes of the PERL guys.

My question is, why re-live learning pains and not use LISP when it already has a spec, history, capability, and the expertise as a language to service humanity?
 
Paul Graham says it's because the community doesn't help the language because they put down newbies and don't have one solid specification or dialect to live by. Interfaces to hardware and other languages also seem to be a handicap along with having to create everything from scratch. I've been meaning to learn this for quite a while and just started learning Scheme using the SICP book. I have every intention to create something with it, too, if life will quit getting in the way.
 
Yup it's a time vs money thing. Ruby has lisp constructs in it. lambda closures. I believe so does python and the new c++0x.

There is a renaissance going on currently with many functional languages running on the jvm. Some knowledge of functional programming probably may help a javascript programmer as well.

I may read SICP one day. I've played with scheme. I would do it to gain a better understanding for using closures in ruby. I hear haskell is also a conceptual eye opener. In the end OOPS is where the money is. Then again I'm sure there are many people here who do very well writing classical bourne scripts.
 
I pretty much never go outside of C (gcc and HuC, and PHP if you count it as a C dialect), BASIC (freeBASIC [not yet in Ports, though they're working on a FreeBSD version] and sillybasic [also not yet in Ports, but only because I've not submitted it to Ports yet]), and assembly (nasm and pceas). I've been known to do a bit of classic PASCAL (not Delphi) and I picked up a little Ruby while messing with RMXP. But LISP? No thanks. People can also keep their PERL and their C++/C#/Cwhatever-else.
 
If you look at it from a historical perspective initially the workflow of using the shell and pipe/redirection for high level programming and drop down to C when the tool didn't exist. You can almost follow the lineage from ed -> grep -> sed -> awk. Wherein regular expressions where part of ed and the grep utility was a single utility pulled out from ed. Ultimately perl broke the unix philosophy of "do one thing and do it well".

I have a soft spot for ruby though. It is really fun to work with and it's interpreter begs to be hacked. I never did perl but I believe ruby has usurped perl in the shell scripting language arena. Much of perl is in ruby as well as the much of the classical shell concepts. ruby is very much part of the unix culture.

I'm glad we don't live in a monoculture when it comes to programming languages. There is nothing stopping you from using any tools you want and you will always have the ability to use and combine those with other tools if you want.

I don't have the strongest background with c but have read k&r and a tome on the subject. I can do posix sh scripting well enough to create wrappers and automate systems. As for high level programming Ruby certainly has some appeal that goes beyond just gc and simplicity. There is an eloquence to it's introspection, built in design patterns and syntax that makes it a truly unique language.

@Eponasoft My first programming language was applesoft BASIC. I think it's very cool that you are heavily involved in it. When your sillybasic port becomes available I'd be interested in checking it out.
 
Compilers for lisp tend to produce slower code and the syntax is annoying(braces, braces everywhere). Haskell is an example of a functional language that eliminates braces entirely. Good optimizing compilers for functional languages are difficult.

Compilers for C produce very fast code and only the semicolon is annoying. If you like functional languages and semicolons take a look at ocaml. Compilers for ocaml produce very good code but you must specify the type of everything.
 
I enjoy LISP and use it when I can but I would enjoy using it more. The SICP book is great but another book that I was happy to find is "Land of LISP" by Conrad Barski. That is a great book for learning CLISP.

As for the other languages you mentioned, I agree about both Perl and Ruby and will never touch them but I do really enjoy Python. Google code university has a very nice online class (videos + self-checking exercises [unit tests]) for Python and I highly recommend it if you are new to the language.
 
The problem with Lisp is that it is relatively rarely used, making it hard to find usage examples.

I like Ruby. It's pretty much Perl with the worst visual noise removed and more power added. Somewhere I've seen a quote to the effect of "they reinvented Lisp and called it Ruby". Ruby has modules, but not the breadth of CPAN that makes Perl such a problem-solver. And that goes right back to Lisp: is there a huge library of Lisp routines for common programming needs, or does each programmer have to reinvent them?
 
I am happy for LISP to become *THE* industry standard programming language but until that happens, I will stick to C and C++.

Heck, I would even use Microsoft Visual Basic if everyone else did :)
 
UNIXgod said:
I hear haskell is also a conceptual eye opener.
Indeed. It's a very cool language, but a good introduction is highly recommended. Haskell can be very frustrating if you don't properly "get" the idea behind it.

Fonz
 
ocaml looks kind of interesting... but I think I'll stick with C too. :)

@UNIXgod: sillybasic is pretty similar to Applesoft BASIC, so it might bring back some memories. :) I haven't released it yet because there's a few features left that I'd like to add first (it currently lacks INKEY$ and file I/O), plus I'm trying to write decent documentation too. Commodore 64 BASIC V2 was my first programming language way back in 1984...
 
There are a lot of "cool" languages, but their main question is usability. Take C - it's clean, extremely fast, and doesn't hide anything from the programmer. You won't be prevented from doing stupid things, because that would prevent you from doing smart ones, also. Sound familiar? It's historically, philosophically and functionally tied to UNIX.

So I don't see any of those "new" and "cool" languages replacing C or it's object-oriented siblings.

And I don't see them replacing Perl, either. Why? CPAN. If I need to reinvent the wheel then I'm going to do it in C. Not in Haskell, Ruby, Scheme or anything else. Like .NET on Windows - you just have everything served, so why the hell not if you don't care about speed or memory usage.
 
Zare said:
There are a lot of "cool" languages, but their main question is usability. Take C - it's clean, extremely fast, and doesn't hide anything from the programmer. You won't be prevented from doing stupid things, because that would prevent you from doing smart ones, also. Sound familiar? It's historically, philosophically and functionally tied to UNIX.

So I don't see any of those "new" and "cool" languages replacing C or it's object-oriented siblings.

And I don't see them replacing Perl, either. Why? CPAN. If I need to reinvent the wheel then I'm going to do it in C. Not in Haskell, Ruby, Scheme or anything else. Like .NET on Windows - you just have everything served, so why the hell not if you don't care about speed or memory usage.

There is a Linus Torvalds email which explains why they used C instead of C++ for git. You might find it entertaining:

http://lwn.net/Articles/249460/

I don't see Perl as going away but it's usage has slowed down( in the same sense that awk will never really die). Both Python and Ruby have their own CPAN. I figure I don't really care what language one tool or another is in. Everything can live harmoniously inside a shell script. Ultimately it comes down to using the right tool for the job.
 
Zare said:
There are a lot of "cool" languages, but their main question is usability. Take C - it's
[snip]
I think most of us are aware of the benefits of C...

Zare said:
So I don't see any of those "new" and "cool" languages replacing C or it's object-oriented siblings.
Who said anything about replacing? It would be nuts to rewrite the FreeBSD kernel in, oh say, LISP. It's just a matter of using the right tool for the right job. There isn't much that C can't do but there sure are things that are easier done in other languages, more specifically designed for certain kinds of tasks.

And in the case of functional programming, it's also a matter of how warped your mind is :e

Fonz
 
UNIXgod said:
Do you have a recommendation? I have done some of the stuff in http://tryhaskell.org/

Where would I start?
The catch is that with functional languages like Haskell (as well as logical languages like Prolog) the challenge is not so much in the syntax or finding your way around libraries but rather in the way of thinking. Personally I'm inclined to say that this is better learned from an instructor than from a book, but I'll see if I can find some helpful references for you.

To be continued,

Fonz
 
davidgurvich said:
Compilers for lisp tend to produce slower code and the syntax is annoying(braces, braces everywhere). Haskell is an example of a functional language that eliminates braces entirely. Good optimizing compilers for functional languages are difficult.

Stalin!
 
lockfile said:
My question is, why re-live learning pains and not use LISP when it already has a spec, history, capability, and the expertise as a language to service humanity?

Which LISP? Which spec? The state of affairs of LISP isn't much different from any other new language, despite the fact it should have been standardized and cleaned up decades ago. There are numerous dialects of LISP and Scheme and they're mostly incompatible. The fact that nobody knows *exactly* what you are talking about when you say "LISP" that is the source of most of the problems. LISP is just too weird for the sake of weirdness and nobody seems willing to clean it up. No matter how good any single implementation may be, it's going to remain a niche language because the quirks are built-in to every implementation and instead of working to remove them, they seem to enjoy exploiting them.
 
There's definitely a bit of elitism in the LISP community, but they aren't unfriendly. They're just unlikely to answer questions they have heard a dozen times (or maybe one time twenty years ago). On the overall they seem to have shorter fuses for stupidity. They assume, and perhaps rightly, that someone smart enough to learn LISP is also smart enough to use Google. Land of LISP is a good book to work through, although I've since moved on to Haskell.
 
Precisely. Although the ongoing neglect of LISP is an evolving question, which means new insights can be had. Maybe a prophet will emerge. We can keep our fingers crossed...
 
For large systems I really appreciate type safety. Large systems imply new or inexperienced developers working on the system and lack of type safety can be a nightmare for those trying to figure out what is going on. That is on of the reasons, I much prefer Scala to Clojure (which is the closest thing to modern Lisp you ca, for functional JVM work.

I recently had to clear out some of my old O'Reilly books and what amazes me is the size of the guides/cookbooks for modern languages compared to say K&R's 'The C Programming Language'.
 
Back
Top