Rant: lisp is not C. Get over it.

Discussion of Common Lisp
JamesF
Posts: 98
Joined: Thu Jul 10, 2008 7:14 pm

Rant: lisp is not C. Get over it.

Post by JamesF » Tue Sep 09, 2008 6:05 pm

I've just read yet another "objective" dissection of lisp's faults. Here are my responses to the non-issues that turn up time and time again:

The syntax/parentheses.
This is lisp's main strength. It's only a problem if you're expecting lisp to be like, well, something that isn't lisp. If you want syntax, pick a language that has it. But if you can cope without the overhead of memorising dozens of arbitrary rules to distract from writing code, and can manage your agoraphobia when confronted with total flexibility, keep learning. You may just figure out why, after almost fifty years, nobody's bothered to make a serious effort to hamstring the language with something it doesn't need. (I know there's at least one package that adds syntax, but how heavily is it actually used?)

Here it is again, in shorter form: with lisp, you're not wasting mental effort jumping through the hoops of something that produces an AST; you're directly manipulating the AST itself. Lisp source code is fundamentally different from C code, because you're working at a different level.

There are too many choices.
Oh, you poor darling! Having to actually evaluate different options, and choose among them! Having the freedom to select the implementation whose tradeoffs suit you best!
Gosh, that'd rule out Java, C and C++ as well, then.

It doesn't cater to beginners.
This one bugs me even more than whimperings about the parentheses. Heavens to Betsy, how could we possibly allow the inequity of a language that doesn't have a short learning curve?! How grossly unfair, how incredibly mean, to revel in a full-strength language that doesn't hobble itself for sake of the inexperienced! Won't somebody think of the children?

Ferpitysake, people, grow up! If you want a language to learn programming with, it's not like yer menu's exactly sparse: python, perl (if you must), ruby, even shell are right there. Lisp is a language for grown-ups. It's like Unix: they both assume that you know what you're doing, that you want the power, and that you can handle it. If you want a language that stunts itself to protect you, Java and VB are right over there. No, it's not as easy to learn lisp as it is to learn, say, Python - but having climbed that hump, I can tell you that I'm very glad it's there. I'm not glad it's there because it keeps people out, but because it keeps the power in.

The standard hasn't changed for ages.
It's not stagnant - it's mature. Just like the bolt-on syntax, nobody's found sufficient motivation to put in the time and effort to produce a new standard. Variants have come and gone (Dylan, Arc and Goo) but the politics-not-art that is Common Lisp is still the main branch because we still like working with it. As Paul Graham asked, what theory fits these data?

<my favourite feature> isn't part of the core language.
Fine. Throw yer tantrum. Now take another look at the language: if you don't actually need network I/O (web libraries, whatever), you don't need to add the overhead to the runtime. But if you've actually bothered to learn the language, you'd have understood that once you've loaded the library, it is part of the language with which you're working. Batteries? We have entire power stations! And the funny thing is that when the need for a new library arises, that new library is often pretty quick in appearing.

The weirdest part about this is that often the same people who complain about library X not being present, also complain that they want a small core to the language. The source-code to the core can be covered by the average hand; is that small enough? All the rest of CL is the included set of batteries!


Now, understand that I'm not claiming the language is faultless. I'm just sick of hearing repeated complaints about things that aren't actually problems, from people who want lisp to be just like their favourite language, so that they don't have to go to all the work of learning something new.

Maybe lisp isn't for mere mortals. I've certainly met plenty of people who just can't handle non-trivial degrees of abstraction, so maybe it's simply that your brain needs to be *this* evolved to get onto the ride. If so, so what? You can pillory me for being arrogant, but I'm blessed with a mind that can handle a full-power language; should I be denied that tool just because some people aren't able to get their heads around it? If that's the case, we'd best close down the F1 Grand Prix, because Joe Sixpack will never be able to drive at Michael Schumacher's level.

Then again, maybe I should start trolling in the F# forums, complain loudly that it isn't lisp, and look surprised when it goes down badly...

TheGZeus
Posts: 79
Joined: Mon Jun 30, 2008 10:46 am

Re: Rant: lisp is not C. Get over it.

Post by TheGZeus » Tue Sep 09, 2008 7:04 pm

Heh.
I can hardly configure StumpWM without help, but i can read the code just fine and I understand it unless there's CLOS involved.
OOP confuses me on multiple levels, but we come to a beautiful part of CL: I don't have to use it in my code if I don't want to.

On the other hand, even a beginner's guide to C programming leaves me going "WHY???"

I started on Logo at age 13, and I still know jack, but I can read lisp(CLOS aside).
I can also read Python, but so can my mom. I actually found the location of a bug in the driver manager for Ubuntu Hardy, having never worked with Python! That said, all the sprinkles(how I refer to things like ;[{\|!@#$%^&*`~ all over) were... uncomfortable on some level.

In any case, I do't get why people think lisp is weird/hard/primitive. It's is what it is and it's whatever you want on top of that.

JamesF
Posts: 98
Joined: Thu Jul 10, 2008 7:14 pm

Re: Rant: lisp is not C. Get over it.

Post by JamesF » Tue Sep 09, 2008 7:21 pm

TheGZeus wrote:In any case, I do't get why people think lisp is weird/hard/primitive. It's is what it is and it's whatever you want on top of that.
I get why they think it's weird: it's different to the Algol family. What bugs me is the consistent whining that it's wrong because it's different to that family.

OOP confused the heck out of me for ages, too. I have my head around it now, but only use it lightly, and only where it makes sense to me. As you say, it's there to use if you want it, but you don't have to.

mhaggag

Re: Rant: lisp is not C. Get over it.

Post by mhaggag » Wed Sep 10, 2008 12:44 am

JamesF wrote: The syntax/parentheses.
This is lisp's main strength. It's only a problem if you're expecting lisp to be like, well, something that isn't lisp. If you want syntax, pick a language that has it. But if you can cope without the overhead of memorising dozens of arbitrary rules to distract from writing code, and can manage your agoraphobia when confronted with total flexibility, keep learning. You may just figure out why, after almost fifty years, nobody's bothered to make a serious effort to hamstring the language with something it doesn't need. (I know there's at least one package that adds syntax, but how heavily is it actually used?)
The first thing to ask people complaining about parentheses should be: "How long have you used lisp?". It won't be much beyond a couple of toy examples. Lisp parentheses are certainly annoying at first for programmers coming from algol-like languages, much like C's braces are annoying for someone coming from a python or Visual Basic background. But it's easy to get over after some use. We don't see much whining about C braces, do we? Because people are used to them.

As you note, lisp's parentheses give rise to much power--since we're writing ASTs, it's pretty easy to write programs that write programs. Saving and reading objects is a breeze due to the uniformity. Customizing readers is possible. Now, what does C's braces buy us again? Not much beyond scoping.
JamesF wrote: There are too many choices.
Oh, you poor darling! Having to actually evaluate different options, and choose among them! Having the freedom to select the implementation whose tradeoffs suit you best!
Gosh, that'd rule out Java, C and C++ as well, then.
I don't think the problem here is the multiplicity of implementations, as much as the apparent incompleteness of them. Lisp, like smalltalk, leans heavily towards the "image" model. This is very different from the current established conventions in our C-based operating systems and applications. It certainly was for me--finding a lisp implementation that produces executables isn't very straightforward to someone exploring the language, and then they find their executable's 20 MBs in size because it's basically a complete lisp image dump. Not good.

I personally think lisp (and smalltalk) implementations need to be more flexible in their support for the traditional application model. Generating reasonably-sized executables should be as simple as possible. Working with native APIs (especially win32, given the prevalence of Windows) should be a breeze. At least until we get a lisp-based OS or a new lisp machine in which the lisp way is the native one :).

When I was looking for a common lisp implementation in which I can develop and distribute reasonably-sized Windows/Linux executables, I took quite some time before discovering ECL. And it's not very straight-forward getting ECL to work in a C++ application either.
JamesF wrote: It doesn't cater to beginners.
This one bugs me even more than whimperings about the parentheses. Heavens to Betsy, how could we possibly allow the inequity of a language that doesn't have a short learning curve?! How grossly unfair, how incredibly mean, to revel in a full-strength language that doesn't hobble itself for sake of the inexperienced! Won't somebody think of the children?

Ferpitysake, people, grow up! If you want a language to learn programming with, it's not like yer menu's exactly sparse: python, perl (if you must), ruby, even shell are right there. Lisp is a language for grown-ups. It's like Unix: they both assume that you know what you're doing, that you want the power, and that you can handle it. If you want a language that stunts itself to protect you, Java and VB are right over there. No, it's not as easy to learn lisp as it is to learn, say, Python - but having climbed that hump, I can tell you that I'm very glad it's there. I'm not glad it's there because it keeps people out, but because it keeps the power in.
I'm actually rather baffled by this--Lisp is by far easier to learn than most other languages. Sure, Common Lisp is huge, but you don't have to learn the whole of Common Lisp to write programs in it. The basic idea of Lisp can be explained to another programmer in 10 or 15 minutes tops. After that he can start playing with the language, and reading a book that explores the mind-blowing abastractions that can be (and have been!) built with this simple model (e.g. "Paradigms of AI programming" or "Practical Common Lisp"). And as far as tools go, SLIME is simply unparalleled in all static languages, and most other dynamic languages I've seen.
JamesF wrote: The standard hasn't changed for ages.
It's not stagnant - it's mature. Just like the bolt-on syntax, nobody's found sufficient motivation to put in the time and effort to produce a new standard. Variants have come and gone (Dylan, Arc and Goo) but the politics-not-art that is Common Lisp is still the main branch because we still like working with it. As Paul Graham asked, what theory fits these data?
Meh, how frequently is the C or C++ standard changed? And how quickly do the compilers actually catch up? And how many compilers actually implement the standard correctly?
JamesF wrote: <my favourite feature> isn't part of the core language.
Fine. Throw yer tantrum. Now take another look at the language: if you don't actually need network I/O (web libraries, whatever), you don't need to add the overhead to the runtime. But if you've actually bothered to learn the language, you'd have understood that once you've loaded the library, it is part of the language with which you're working. Batteries? We have entire power stations! And the funny thing is that when the need for a new library arises, that new library is often pretty quick in appearing.
I think Lisp needs some work in the batteries department. asdf-install is promising, but getting it to work under Windows is a wee bit baffling to the beginner.
JamesF wrote: Then again, maybe I should start trolling in the F# forums, complain loudly that it isn't lisp, and look surprised when it goes down badly...
I'm curious, why did you choose the F# forums as an example? After this rant it seemed more likely you'd be trolling some C, C++ or Java forums, no? :D

JamesF
Posts: 98
Joined: Thu Jul 10, 2008 7:14 pm

Re: Rant: lisp is not C. Get over it.

Post by JamesF » Wed Sep 10, 2008 5:15 pm

mhaggag wrote: I don't think the problem here is the multiplicity of implementations, as much as the apparent incompleteness of them. Lisp, like smalltalk, leans heavily towards the "image" model. This is very different from the current established conventions in our C-based operating systems and applications. It certainly was for me--finding a lisp implementation that produces executables isn't very straightforward to someone exploring the language, and then they find their executable's 20 MBs in size because it's basically a complete lisp image dump. Not good.

I personally think lisp (and smalltalk) implementations need to be more flexible in their support for the traditional application model. Generating reasonably-sized executables should be as simple as possible. Working with native APIs (especially win32, given the prevalence of Windows) should be a breeze. At least until we get a lisp-based OS or a new lisp machine in which the lisp way is the native one :).
Actually, as far as I can tell, lisp and C have the same image model. It's just that all the heavily-used OSes are C-based these days, so the C image is already loaded. Try running a C programme on a Lisp machine, and I'm sure the shoe would be on the other foot.

Of course, explaining this doesn't remove the annoyance. I've gotten the hang of running lisp programmes via trampoline shell scripts, but it's still a pain. I'm sure it should be feasible to get lisp programmes running like C apps, but I know too little about things at that depth to have any useful answer. Then again, Java has the same problem (ever invoked a Java app from the command-line?) but I haven't heard much complaining about that. Maybe we should see how the Java community fends that one off, and embrace and extend the response they use :)

mhaggag wrote: I'm actually rather baffled by this--Lisp is by far easier to learn than most other languages. Sure, Common Lisp is huge, but you don't have to learn the whole of Common Lisp to write programs in it. The basic idea of Lisp can be explained to another programmer in 10 or 15 minutes tops. After that he can start playing with the language, and reading a book that explores the mind-blowing abastractions that can be (and have been!) built with this simple model (e.g. "Paradigms of AI programming" or "Practical Common Lisp"). And as far as tools go, SLIME is simply unparalleled in all static languages, and most other dynamic languages I've seen.
Again, I think the problem is mostly with people coming from other languages. That, and getting used to making abstractions in one direction while extrapolating them in another.

mhaggag wrote: Meh, how frequently is the C or C++ standard changed? And how quickly do the compilers actually catch up? And how many compilers actually implement the standard correctly?
Exactly. Do these people like constantly playing catch-up with ever-changing versions of a language? I suspect they're so used to it that they think in terms of evolving from, instead of evolving to.

mhaggag wrote: I think Lisp needs some work in the batteries department. asdf-install is promising, but getting it to work under Windows is a wee bit baffling to the beginner.
It does need more work, this is true, and I believe there's at least one effort currently underway to replace it with something even better. The one thing that's stopping me from using asdf-install at the moment is the lack of full support for version constraints; I get just as many problems with dependencies that are too new as I do from the ones that are too old.

However, the situation isn't as dire as many people try to make out. The emergence of http://www.cl-user.net / http://www.common-lisp.net has helped this, as a good complement to Cliki.
I do understand the complaint that wheels are constantly being reinvented, but it's actually a consequence of the power of the language itself, which is under-appreciated by the newcomer. I'm as guilty as everybody else of making a trivial effort to look for a library (if I even look at all) before giving up and just writing it myself. So the "problem," in effect, is that the language is too powerful for the good of its community. Or something.

mhaggag wrote:
JamesF wrote: Then again, maybe I should start trolling in the F# forums, complain loudly that it isn't lisp, and look surprised when it goes down badly...
I'm curious, why did you choose the F# forums as an example? After this rant it seemed more likely you'd be trolling some C, C++ or Java forums, no? :D
Because I lurk on comp.lang.lisp, where there's been a significant level of noise produced by an F# troll (Hi, Froggy!), although his activity has mercifully dropped away in recent times. Sorry 'bout the in-joke, but I couldn't help it. Otherwise, yes, you're right: it'd be a C forum :)

Wodin
Posts: 56
Joined: Sun Jun 29, 2008 8:16 am

Re: Rant: lisp is not C. Get over it.

Post by Wodin » Fri Sep 12, 2008 9:08 am

TheGZeus wrote:I actually found the location of a bug in the driver manager for Ubuntu Hardy, having never worked with Python! That said, all the sprinkles(how I refer to things like ;[{\|!@#$%^&*`~ all over) were... uncomfortable on some level.
Are you sure you're not thinking of perl? :)

dlweinreb
Posts: 41
Joined: Tue Jul 01, 2008 5:11 am
Location: Lexington, MA
Contact:

Re: Rant: lisp is not C. Get over it.

Post by dlweinreb » Fri Sep 12, 2008 9:18 pm

The syntax: It's just unfamiliar to people, and they don't already
realize that you're expected to use a text editor that automatically
indents lines. I like mhaggag's point about the C curly braces being
foreign to Python programmers; it's very much the same thing.

Too many choices: You mean, choices of implementations? You can
pick one more easily if you use my survey paper, at http://common-lisp.net/~dlw/LispSurvey.html.

Doesn't cater to beginners: In what way is it harder for beginners
than Python or Ruby? It's easier for beginners than C or Java, in my
opinion, because of its interactive nature: you can just start typing
expressions. And these days there are many good textbooks, such as
"Practical Common Lisp". Common Lisp isn't nearly as hard to learn
as most people think.

The standard hasn't changed for ages: Well, I don't think that having
standards gratuitously change is what anyone wants! For the most
part, Lisp has been able to absorb (and improve on) good programming
language ideas as they arise, from little ones like "case" to big ones
like object-oriented programming. All this can happen without changes
in the standard, since Lisp is so extensible. However, there are
important features that Lisp does need that can't be added that way,
such as thread and Unicode support.

Missing features: You can add features to Lisp that you can't add to,
say, Java, such as new iteration forms. The complaint that you may be
dealing with here is that Lisp libraries, even when they exist (and
quite a lot do), and not as easy to find as they should be, and some
are incomplete and poorly-documented. There is room for improvement
here.

Common Lisp would not look so large if the standard were written in
terms of a core language plus a set of standard libraries. Consider
that even things like "assoc" would be considered a standard library
function! We originally wanted to write the Common Lisp standard this
way, but, in a nutshell, it was more work than we had the capacity to
do at the time.

Yes, generating smaller executables would be a good thing. If you
want that for Windows, plus close support for Windows API's, take a
look at Corman Common Lisp. On Linux systems, the Common Foreign
Function Interface (cffi) has gotten quite good, making it easy to
call out to C/C++ modules (e.g. encryption primitives).

How many compilers actually implement the C++ standard correctly?
When I was at Object Design, we ported ObjectStore (our
object-oriented database system, written in C++) to a very, very wide
range of machines. Every single one, without exception, had bugs in
its C++ compiler. We always had to work with the vendor to get those
bugs fixed. A close friend of mine who is still maintaining
ObjectStore recently told me that as far as he can tell, the last
person at IBM who knows how to write C++ compilers must have quit.

JamesF's point about how we sometimes don't even bother to look for
libraries because it's so easy to just write it yourself is something
I was just discussing with my co-workers not long ago! Especially
since you often don't need all the generality of a comprehensive
library. That's a problem for getting good libraries written, in a
paradoxical sort of way.

findinglisp
Posts: 447
Joined: Sat Jun 28, 2008 7:49 am
Location: Austin, TX
Contact:

Re: Rant: lisp is not C. Get over it.

Post by findinglisp » Sat Sep 13, 2008 9:50 am

dlweinreb wrote:However, there are
important features that Lisp does need that can't be added that way,
such as thread and Unicode support.
Yes. Yes. Yes.

IMO, Common Lisp needs a touch-up. Nothing major, but it does need to be brought forward into the 21st century. Unicode, threads, and sockets should all be part of the "standard" that is implemented across multiple implementations. Yes, each implementation can do it themselves, and many have, but they have all done it differently, leading to a complete mess when trying to write real programs that might work across multiple implementations. We're rapidly heading toward the same problem that Scheme has in spades, where there isn't enough standardized and hence you get balkanization. Anybody writing "real" programs ends up having to commit to a particular implementation to get it done. And then all the work that happens toward libraries ends up getting spread across multiple implementations.

We have seen this happen before in other markets, and it's not good. Unix, and again, Scheme come to mind. We basically need a Common Lisp reformation where we go back and update the spec for modern times and rally around it. The alternative is that one particular implementation (SBCL, perhaps) ends up with dominant "market share" and most everybody ensures that their libraries work for it. This is basically what Linux did to Unix.

The single implementation languages such as Python and Ruby (or at least dominant implementation languages, since even Python and Ruby have Jython and JRuby, for instance), have an advantage with respect to these issues because they have a strong decision maker (Guido or Matz) taking input but then giving strong direction (like it or not, Python 3000 will be what Guido wants it to be, an Ruby 1.9 will be whatever Matz wants it to be). If you want to write a library for either, you write it to the dominant implementation and everybody benefits. On the flip side, if you want a feature that isn't there, you're screwed unless Guido or Matz decides they want to implement it.

To hammer this home, let me give you some insight into a decision that I recently had to make. I really love Lisp. If I didn't, I wouldn't have started this forum. I'm working on a project that is going to be doing a lot of Internet access. I had to pick my choice of programming language. I prototyped some stuff both in Lisp and in Ruby. I'm going to end up doing it in Ruby. With Lisp, I was fighting the libraries and sockets and streams and such. With Ruby, it all just worked pretty seamlessly. Do I like Ruby better than Lisp as a language? No. It's good (far better than Perl, IMO), but it's not Lisp. Could I have solved the Lisp problems? Yea, probably, but Lisp is 50 years old and it still has these basic issues? I don't want to start off every project working around basic infrastructure problems. Yea, Lisp can be great for coding efficiency, but that argument is seriously blunted if every Lisp project starts off re-solving problems that should have been solved 10 years ago. Put another way, I'd like to begin every Lisp project working on the actual problem at hand rather than grumbling about Lisp deficiencies.
Cheers, Dave
Slowly but surely the world is finding Lisp. http://www.findinglisp.com/blog/

death
Posts: 17
Joined: Sat Jun 28, 2008 1:44 am

Re: Rant: lisp is not C. Get over it.

Post by death » Sat Sep 13, 2008 11:36 am

findinglisp wrote:With Lisp, I was fighting the libraries and sockets and streams and such.
Can you be more specific about these problems, and about how standardization might have helped?

findinglisp
Posts: 447
Joined: Sat Jun 28, 2008 7:49 am
Location: Austin, TX
Contact:

Re: Rant: lisp is not C. Get over it.

Post by findinglisp » Sat Sep 13, 2008 2:52 pm

death wrote:
findinglisp wrote:With Lisp, I was fighting the libraries and sockets and streams and such.
Can you be more specific about these problems, and about how standardization might have helped?
Certain libraries, particularly when using networking and threading, but even things like streams in some cases, are written to particular APIs. If you happen to be using a different implementation, then you're stuck working through the code and changing it, switching CL implementations, or rewriting things from scratch. Ideally, you'd just plug stuff together and things would be written to use the common infrastructure. To give you some examples, some network protocols really require you to deal with things like binary data mixed with strings, or with strings in different encodings (UTF-8 and such). There are libraries like Edi's great Flexistreams, which try to provide you a nice flexible stream interface across a range of Lisps. However, other libraries are not necessarily Flexistream-aware and won't necessarily return one when you'd want to have one, forcing you to wrap various other streams in Flexistreams, etc.

Then, try using various libraries in a multi-threaded context. Various Lisps use green threads. Others use native threading (e.g. SBCL). Still others have no threading at all. Are the libraries thread-safe? Without knowing, you really have to start introducing chunky locking. That sort of defeats any threading you might be trying to do.

If you had all this stuff standardized, then people would be working with a common model. There would be an official way to deal with Unicode and binary streams. You would still have issues as to whether a given library was thread-safe or not, but as with Java it would be a common part of the documentation and if things were thread-safe, there would be standard ways to make them so. As with any programming language, there would still be subtle bugs in the threading libraries, because threading is hard to get right, but the "rules" would at least be out on the table and everybody could then abide by them.

As I said, without standardization, all this is still solvable. But why would you want to when you could be working on your application?
Cheers, Dave
Slowly but surely the world is finding Lisp. http://www.findinglisp.com/blog/

Post Reply