Hacker News new | past | comments | ask | show | jobs | submit login
Why I like Common Lisp (p-cos.blogspot.com)
171 points by lispm on Sept 7, 2014 | hide | past | web | favorite | 178 comments



What I like most about Common Lisp is how it made me a better programmer. The different paradigm of coding trains your brain in different ways which offer perspectives on problem solving that I otherwise wouldn't have considered.

Note that for the above effect, it is irrelevant what Lisp you choose. Yes, it also applies to learning any additional language, but because Lisp is a different breed altogether (as opposed to Fortran-derived languages), more value is to be had from the diversity.

I used to be a huge fan of Common Lisp (even wrote my own series of blogs on why I love it a few years ago) -- still use it in my daily work -- but I came to realize that it's not perfect. There are many things that Clojure has improved upon, e.g. consistent accessor methods, shared immutable data structures vs copying, and probably many more once I dive deeper -- there's a reason why even pg started recommending Clojure over CL or Arc.

I've been coding in Common Lisp for about 3-4 years. Even the algorithm of my startup is written in Common Lisp. There are definitely moments of sheer joy when I switch back and forth between Javascript and Common Lisp. But also moments of annoyance... sometimes certain algorithms are just more naturally imperative, and CL makes it hard not to write recursive.

tl;dr learning a Lisp is highly recommended. It does not matter which flavour. Or just go read SICP.


It's perfectly easy to write imperative code in CL. You have objects, you have vectors, you have every control structure operator ever conceived except CALL/CC, ... what else do you need?

On the other hand, if you want to write more functionally, CL also now has shared immutable data structures. Check out FSet: http://www.ergy.com/FSet.html


> CL makes it hard not to write recursive.

Say what? Are you sure that you don't mean Scheme? CL has LOOP…


> CL has LOOP...

Oh gawd. The biggest wart on the language.

Let's just agree that it's controversial :-)


Blame Interlisp. We got it from there.

Still the point is, that Common Lisp prefers iteration by loop-like constructs (or higher-order mapping) to recursion, due to the lack of TCO in the standard: DOLIST, DOTIMES, DO, DO*, LOOP, MAPCAR, MAP, ... Many people prefer the design of the ITERATE macro, but LOOP is already included.


The lack of TCO in the standard is almost a non-issue considering that most of the implementations support it. Even Allegro has long done TCO on local calls (calls to functions defined with LABELS or FLET, within the scope of that construct).

The only people who need to worry about TCO are those writing portable libraries. Everyone else can assume it, at least for local calls, which represent 98% of the times that it matters anyway.


> almost a non-issue considering

Almost. It's just that that many implementations support it (ABCL not) and that the language does not support it. TCO interacts badly with many Lisp language features: dynamic binding, unwind-protect, ...

> Everyone else can assume it, at least for local calls, which represent 98% of the times that it matters anyway.

If the right optimizations settings are set.


> TCO interacts badly with many Lisp language features: dynamic binding, unwind-protect, ...

I've never understood this claim. I mean, I understand the technical point: that use of dynamic binding or UNWIND-PROTECT creates a barrier in the stack across which TCO cannot be done. But in practice it seems to me a non-issue. I can't recall ever, in 35 years of Lisp hacking, wanting to write a tail-recursive routine that used one of them on each iteration, in such a way as to cause unbounded stack growth. It just doesn't happen, at least not to me.

Maybe that's partly because I try to keep my usage of dynamic binding to a bare minimum. I think some people overuse it.


Ah right, I forgot about ABCL. I haven't used it, though I keep meaning to give it a try. Hmm, it can't do TCO even on local calls? My code may not run in it, then.


Btw., if you haven't seen it, here is an overview:

http://0branch.com/notes/tco-cl.html

Btw., Symbolics Genera also did not support TCO. ;-)


The overview is useful -- thanks. I see Allegro now does full TCO. Either that wasn't true when I was using it (a dozen years ago) or we just didn't have the right optimize switch settings to turn it on. In any case, I thought that the strategy of doing TCO only on local calls was pretty good -- it let me write loops tail-recursively with LABELS, but didn't significantly impact debugging because only local call frames got deleted.

I'm well aware that the LispMs did not do TCO -- I owned several (starting with a CADR) and still have an XL1200 rusting in my closet :-)


Iterate is so much cooler! defmacro-clause has been a godsend for my work.


do you have a link/source for paul graham recommending Clojure?


He's said its probably your best bet:

https://news.ycombinator.com/item?id=4487793


Seconded.


I love Common Lisp; I've been writing Common Lisp at home for something around 7 years. It's fast, flexible, expressive, and deeply programmable.

I won't say it doesn't have its warts: the namespacing and packaging systems are kludgey, and the extensibility of built-in operators is poor. It's a dynamic language to boot, which implies type derivations are often estimates at best (painful sometimes on a poorly tested codebase).

But, Common Lisp, above all that, is an integrated development system which allows live and fluid development. I can't stress enough that it is a deep and joyful technology which lets me achieve more faster in it.

I only wish there were jobs in it. :-/



Not a bad feed, but...

Common Lisp has under 10 employers in the US/CA, as far as I can discern: Clozure Associates, Grammarly, 1? 2? defense contractors in the Seattle region, ITA (now owned by Google), a company in Colorado, D-Wave in Vancouver, BC (Canada), and a handful of very small consulting-type shops. Occasionally there are some university jobs that come up, usually in Boston area.

I've been monitoring things for a while, and the prospects are dim. Suppose I'll just have to run my own business, eh? :)


I have never been more productive than when I'm developing with Common Lisp in Emacs with Slime. It's a really fantastic environment.


Don't forget paredit, ac-slime, and redshank.


What exactly do you develop with Common Lisp?


I develop everything (typesetting software, compilers, web server, email client, a desktop environment just for me, a sound synthesizer, my invoice generator, IRC bots, full blown web apps, a wiki engine and tons of general purpose libraries) using Common Lisp. My love for the language comes especially from the fact that its so limitless by design. I have DISASSEMBLE and I have DEFUN. I have ETYPECASE and I have LOOP. Lacking a language feature? Add it with ease and incredible performance.


Are any of these software tools available as open source so I can see the advantage of using Lisp?


Not the parent, but I recently wanted ssyntax[0] in Common Lisp, so I decided to write an implementation for it[1]. In doing so, I created a DSL for defining ssyntax (made up of defssyntax-test, defssyntax-macro, and defssyntax-sym-mac). Just note that my implementation uses a library of utilities I wrote[2] and is not pure Common Lisp.

[0] http://arclanguage.github.io/ref/evaluation.html

[1] https://github.com/malisper/Clamp/blob/master/experimental/s...

[2] https://github.com/malisper/Clamp



Please tell us about your stack. Which implementation of Common Lisp do you use?


Slackware, Clozure Common Lisp, Emacs, Slime.

Actually its not very fancy. I basically live in a live CL image, have some emacs key bindings which invoke a simple CL job system (EVAL in a thread). I can shift-right-click things to get a menu of actions for that type of file and plain-right-click to run the VIEW action for that type of file (as a job in CL).

http://i.imgur.com/2b47mII.png

I have a QUERY function which is hooked up to Recoll (full text search). I have the HTML ANSI CL draft under /usr/doc/ansi-common-lisp/ and HTML versions of all manpages under /usr/doc/man so finding documentation is quite nice. E.g. I (query "defun") or (query "gethostname") and get a sane list of results.

I have a markdown like language in which I write all my documentation, its media independent and has backends for plaintext, html and LaTeX output. I want to release it soon but well...

There is the SH DSL for executing UNIX commands, the PIPE macro for doing things like (pipe (sh hostname) (read)) (just a silly example).

My web server is open source (telnet to mr.gy on port 80). Its mostly "cute", not something you'd run on a large site.


I'd love a write up of your setup, and I think other people here would as well. Did you build this all from what you thought you'd rather use, or have you tried Lisp machines like Genera?


Never used Genera or the likes (am a youngster). I have seen screencasts though. I have been mostly influenced by Acme of Plan 9 and the Oberon UI (also only through secondary sources). I am also stuck on UNIX so I had to deal with that in some way, also I know my way around UNIX so I felt it was easier to integrate UNIX with CL instead of learning a new OS.

My time with UNIX also made me fond of text files so a lot of my "stack" is optimized for plain text interfaces (e.g. the email client started because I didn't like the directory structure of maildir). Also I wanted my mail in a git repository.

> Did you build this all from what you thought you'd rather use

Kind of, its a compromise between what I wanted (a CL OS, optimized for simple text interfaces and CL hacking) and what was in reach. At some point I decided to go the path of least resistance, move my CL stack closer to the UNIX/Slackware stack and reuse and integrate as much open source software as possible.

The result is a very thin layer of CL and Elisp code and some CL apps which combine to a UI I feel comfortable with.


I am an amateurish Linux user and my setup is very similar to you, and I am just starting to lisp (Arch Linux, lots of stuff in Emacs, and SBCL/CCL/ECL; I am trying them all).

It is very encouraging to see you work and I really need to get up to speed on the Lisp.

Also, I am a Recoll fan too. Great stuff!


Cool stuff.

Have you considered inferior shell for unix commands?

Does your markdown resemble scribe from racket? I have been considering doing that.


I find it great for any general purpose coding on the backend. For instance, the algo of Routific is written in Common Lisp.

But once you start building APIs or web apps, it falls extremely short for lack of community and open-source libraries/frameworks.


> it falls extremely short for lack of community and open-source libraries/frameworks.

This is one area I'm hoping to improve. I've already built the ORM, auth system and template engine. Now I'm doing the web framework, pretty soon the admin panel, then a couple of pretty project sites and i'll be on Hacker News.


You might have seen me follow up comments about your work. It is very interesting. I am just starting to get into Lisp and I want to make it the first language I really get it into (in college, as a non-major, I did coursework in C++, Perl, and Python). CL is the language I want to dive deep into and get expert it.

Keep up your stuff. After stumling on your work on that strictly-typed LLVM lisp and your cmacro system, I find your work very inspiring and make me want to focus. You and Fukamachi (did I get his name right? the guy working on cl21 and the Caveman web framework) are doing really cool stuff for the CL FOSS community right now.


Thank you for the encouragement, and best of luck to you :)


Still, I think they fail short from the Common Lisp commercial offerings in terms of the whole package.


True, but for most stuff it is quite good. I use Clozure CL with Emacs/SLIME on ARM/Linux systems and it works great.


It may also depend on people's background and their language mix. I hear good things about the fully integrated Lisp systems, but I'm so used to how I've customized my text editor, and how it's integrated with various other things I also use, that the bar for prying me away from it is fairly high. If I did 100% CL development it might be different.


I just find it utterly fascinating that these discussions on the merits of (Common) Lisp still draw 100 comments within such a short time. This has been going on for decades, in many different venues. This by itself should clue newcomers in to the notion that the language (family) may be worth examining in some detail. :)


Anyone have something better than a wild guess about whether Lisp is getting more or less popular? It was never a very popular language in the first place, having lost out to the spawn of Algol.


At least in terms of the open-source community it feels much more lively now than, say, the early 2000s. There are new books like Practical Common Lisp and Land of Lisp, SBCL has matured into a solid implementation, Clozure CL was open-sourced, and Quicklisp has really improved the convenience of using libraries. I don't know whether that translates to more popularity overall, though.

If you mean the overall Lisp family, I think it's more clearly on an upward swing, especially due to Clojure's popularity (and if you're willing to stretch, Julia smuggles a Lisp-like language under cover of Matlab-like syntax).


Re: open source Lisp, I guess other venues than comp.lang.lisp have taken a lot of the mindshare (the demise of Usenet).

cll was rabidly against OSS, e.g. Pitman's pure hatred for it was practically Gospel there.

A few years ago some younger Lispers emerged, for who OSS was natural, just like with the short Ada renaissance.

At least the "young Lispers" are still there, unlike their Ada counterparts, even if they haven't taken over the world.


+1 for Practical Common Lisp, great book, not as dry and academic as other Lisp books. For comparison, ANSI Common Lisp uses ray tracing as an example, whereas Practical Common Lisp uses an mp3 database.


You can check https://www.openhub.net (ex Ohloh) that tracks open source projects. Go to the tools section and compare languages. Lisp has been in decline for a long time, based on number of contributors and projects updated. Scala is doing exceptionally well

https://www.openhub.net/languages/compare?measure=contributo...


The graph does not look very convincing. It talks about 'the number of developers', while the vertical axis is labelled in %. What is it now numbers or percent. If percent, then of what?


It probably was when computers were less popular :)


Not too long ago I was researching what Lisp to learn. I contemplated Common Lisp, but ultimately chose to learn Clojure. The latter won because the development community seems to have more life to it. Additionally, the fact that one can import existing Java libraries is a huge plus. Very much enjoying everything so far.


I've dabbled in Scheme (SICP), Clojure, Elisp (Emacs) and now Common Lisp. My opinion is that there is value in at least looking at more than one. That way you will see what compromises have been made, and how it affects your program.

While Clojure is definitely more a in-thing right now, it's nice to see "the originals", where it all came from. There are several things Clojure does really well, at the cost of other aspects. It's a very opinionated language, and for some, it may be too opinionated. I find idiomatic Clojure-code to be a bit on the too terse side, affecting the clarity of the code.

Let's also mention the JVM. While this is often used as argument for Clojure, it can also be an argument against it. Now your application needs a JVM to run. That excludes my Raspberry from ever running it, unless you find 30 seconds+ startup time to be acceptable. I don't.

Looking into Scheme, you will definitely appreciate the simplicity of the language. Unlike Clojure, there's no magic behind the curtains. What you see is what you get, and yet it's still so capable. That's quite eye-opening and magic in its own right.

Scheme however isn't a standardized language, like Common Lisp. In that regard you cannot guarantee that what works in one Scheme-implementation works in another. With Common Lisp you can do that. And from that point of view, it makes sense to have a good story on modules/packages. And Common Lisp has that. In plenty.

In Clojure, with Leiningen, you can easily declare what dependencies you have and have those fetched build-time without any extra work what so ever. Sounds good, eh? In Common Lisp you can do that in ordinary code, runtime, even in the REPL. Your code just declares what it needs, and it's there. Just stop a second and think what that does to extensibility, when software written in CL lets you plug your own code in.

All in all, once you know a LISP looking into others is much less work. And as such, you should definitely check out others. Maybe there are other LISPs which suites your needs even better? Unless you look around, you will never know.


> Scheme however isn't a standardized language, like Common Lisp.

Scheme is a standardized language. The first standards defined a relatively small language, also useful for teaching purposes. Then it was tried to define a more modern Scheme with a core language and a library. The R6RS standard was kind of controversial and now there is work for quite some time on R7RS. Additionally the Scheme community has a process to define extensions. Generally the landscape of Scheme is quite a bit more fragmented than the CL landscape. The implementations can differ widely in their implemented language. But if you look at individual systems, Scheme systems have to offer quite a lot. Also, historically there are a several really excellent Scheme books for learning programming and/or computer science.

This site, news.ycombinator.com , actually is written in a Lisp dialect (Arc) running on top of a 'Scheme'.


In practice I tend to think of Scheme as quasi-standardized, in the sense that there is a standard core, but it's difficult to stay within it. Whereas with standards like C99, Fortran 90, or ANSI CL, it's quite common for people to write nontrivial standards-conforming programs that you can expect to run unmodified across implementations. Culturally the Common Lisp community also seems more interested in maintaining portability even when leaving the confines of the official standard, through the heavy use of compatibility layers like Bordeaux-Threads. The Scheme approach seems to be to just target a specific implementation, and share functionality across them on a case-by-case basis by porting libraries (which is sometimes trivial, and sometimes more involved). Hence CL has Quicklisp, while Scheme has a package repository per system.


> Additionally, the fact that one can import existing Java libraries is a huge plus [to Clojure].

Armed Bear Common Lisp http://abcl.org/ is a JVM Common Lisp with this feature.


What are the advantages of Lisp over ML (more specifically, I know Scheme and OCaml). My knowledge of scheme is probably incomplete, but for what I remember, Scheme is OCaml without static typing, sum types, pattern matching, module system. Scheme is more dynamic (dynamic types, code as data, symbols) but i find type safety much more important (and in a language with type inference, it comes with little overhead).

Am I missing something about Common Lisp?


The macros davidxc mentions are a big win. The important point about Lisp macros is that they are not a separate technology you have to learn, as you have with Camlp4. Once you know Lisp, you automatically know macros.

Lisps are also much better at reflection than the MLs. In Common Lisp, you can rebind function symbols from a backtrace, and then carry on as if nothing happened. Changing a class definition updates every instance in the system to conform to that new definition, which makes interactive testing a joy. You can get hold of your namespaces as Lisp objects and interact with them as any other data structure, and see the effects reflected correctly in your runtime. CLOS is the peak of this sort of thing. And most lisps allow you to save a snapshot of the runtime image, which is awesome.

The MLs were originally written in Lisp, and inherit some of these features, but Ocaml, not so much. Still, I love Ocaml.


Common Lisp has macros. Paul Graham's book On Lisp is usually pointed to as the best treatment of macros in Lisp. CL also has many more features than Scheme, as mentioned in the other comments here.


It's probably not exactly true that CL has "more features" than Scheme. That is to say, the Scheme "core" language (well, as of R5RS) describes the essential functionality that qualifies as Scheme, but the major implementations have tons of additional/optional utilities, convenience features and extensions.

The sum total is that the complexity of CL vs. Scheme may not in practice be all that different. Take a look at newer Scheme standards, R6RS, R7RS, the SRFI's, and implementations like CHICKEN to see what I'm referring to.

Still CL and Scheme are different languages, each has its fans. It does seem to imply that the stuff it takes to get the job done is more or less independent of language, whether it's included with the base language, or contained in modules or libraries, the features need to be there somewhere in some form.


That's basically true. The more advanced Scheme implementations (and there are several) offer a lot of functionality.

One thing I still find true: Common Lisp has much more useful functionality in the core. Thus the core and the libraries are often actually using them.

Example: by default Scheme has poor argument lists. Thus a lot of code does not use keyword args and the compiler usually does not know about that.

Another example: Common Lisp has a standard object system. All implementations support it and some use it extensively. In most extended Common Lisp much of the libraries is using CLOS: conditions are CLOS classes, I/O is based on CLOS, etc.


Whether functionality should be contained in the "core" or in libraries is often a subject arousing contention, but I think it is, or can be, largely a technical distinction.

Where it matters is how well the functionality is integrated with the core language. The argument goes that in Scheme it is less regularly the case that libraries are complete and consistent vs. CL.

The effort of the R7RS-large work group to create a "standard" library of extended functionality is ongoing, but in a year or two should produce a language standard that could create consistency across Scheme implementations, effectively similar to CL.

Of course, how well that works out depends on the willingness of implementors of Scheme to make it so. Let's hope that they will do that.


Regarding macros there is also the book "Let Over Lambda"


The big difference between Scheme and CL is probably that the former encourages recursion, hygienic macros and is a Lisp-1. Moving from CL to Scheme is very annoying for this very reason. The lack of portability and a SLIME-like IDE doesn't help either.


The defining features of Scheme, differentiating it from predecessors, were probably "proper tail recursion" and "first class continuations". Recursion was not only encouraged but also the principle method of looping.

Although Scheme has a handy "do" procedure for iteration (somewhat like "for" in C), it's quite possible it's not used as much as it could be.

Most Schemes also offer "unhygienic" or low-level macros, though there's a learning curve for it.

I agree Scheme IDE support is marginal, but editor support is fine. Haven't really missed SLIME or other IDE. Compiling Scheme to native code is for me a different workflow anyway.


What's so bad about hygienic macros?


I learned Lisp/Scheme many years ago and am learning OCaml now (and loving it). I guess you could be uncharitable and say that Scheme is OCaml without types, etc. That seems inaccurate though; I will have to think about that :)

But one important thing is that Lisp is its own meta language. With OCaml there are changing and competing meta languages as far as I understand (camlp4, MetaOCaml). The simplicity of the language and meta-language being the same leads to a totally different style of programming.


I'm no expert, but it seems like its easier to get started with Clojure than Common Lisp. There are tons of free Clojure resources and tutorials. There is a great IDE that works quite well (LightTable), and the command line tools with Leinengen are pretty sweet too.

I realize that you can probably optimize your Lisp code a lot more than you can your Clojure code since Clojure is on the JVM, but right out of the box Clojure performs as well as naive Common Lisp, so its probably a more attractive Lisp for most beginners.


Common Lisp has all those tools, what it does lack is a well-designed website that says "Here's how you start".

The closest thing to that is probably the common-lisp.net website, and that's just an unfinished barebones Bootstrap example.

I've been meaning to design a better one, but that's going to take some time.


A website that both provided a starting off point and a unified reference would be a great improvement to the CL community, on the same level as Quicklisp.


I have been coding for fun for 26 years and played around with most popular languages. Common lisp has by far the worst community I have experienced. There is a minority of people that elitist , rude even hostile to anyone that is new to the language. I never gave up a language because of the community but CL community really was very hard to tolerate. Elitism and snobbery is far from uncommon in the coding world unfortunately.

I think as a language it deserve the reasonable praise it gets and certainly a beautifully designed language, powerful and yet flexible. I enjoyed very much coding in it and with the help of lispers I was introduced to a language / environment I fallen in love with Smalltalk , Squeak and now Pharo.


coincidentally I am working through land of lisp, recommend it: http://www.amazon.com/Land-Lisp-Learn-Program-Game/dp/159327... Do I see myself using lisp in production code? Not in the near future. I do think there is value in learning something that exposes you to thinking in different ways, till now what Ive gained is that Python is pretty lispy!


> Python is pretty lispy!

Check this out https://github.com/hylang/hy


thanks!


How long was the learning curve to CL, if you don't mind me asking?

I remember learning Lisp and all that reverse polish notation was very unorthodox to me.


Pedantic comment: it's not reverse, it's just Polish Notation.

http://en.wikipedia.org/wiki/Polish_notation


> I remember learning Lisp and all that reverse polish notation was very unorthodox to me.

I really, really want to answer this, but it's worthy of a chapter in a book. May I summarize instead?

1. Lisp syntax is tree syntax.

An expression such as this:

    (+3 (* 4 5))
Is a tree such as this:

       +
    3     *
        4   5
2. Lisp macros can treat raw Lisp expressions as trees, and transform them into other trees, as well as avoid typical function call evaluation.

3. Lisp has little to effectively no syntax. Since all forms (outside of special reader forms) are in simple lists/trees, you effectively know all there is to know about reading Lisp. (Although, you do need to understand the Triforce of Functions, Macros, and Special Forms, but they're worthy of their own chapters to explain. They're still lists, though.)

4. The nodes[1] of a Lisp tree are also their own data structure, known as Cons Cells[CC]. These allow for easy manipulation and construction of trees, as well as easy recursion by poping off the first part of a cons cell, processing/consuming it, then sending the rest of the list back into the function. Essentially stack-like processing of lists. So while recursive functions can be rather ugly in other languages, they're rather elegant in Lisp, and easy to work with.

Jeeze, I can probably keep going, and adding more and more points and elaborating on their purpose, but it'd be better to just study Lisp on your own instead. I only know cursory Common Lisp, so I can't recommend any books or sources, but I can instead recommend learning Clojure. "Programming Clojure" has been stated to be a good starting book, but I've mostly read "Clojure Programming" from O'Reilly and "The Joy of Clojure". These are also good books, but I'm not sure which is best for beginners.

[1]: Okay, to be more pedantically accurate, Lisp 'trees' are just cons cells linking to more cons cells. It's a bit unweildly to think of all Lisp expressions as cons cells rather than nested function calls or trees. [CC]: http://en.wikipedia.org/wiki/Cons


The fundamental syntax is also the same in Scheme which I've used quite a lot. The stumbling block for beginners is of course the prefix, parenthesized, "everything is a list" notation.

It does take patience to "get used to it". The effort of "getting over the hump" is amply rewarded--one way is the benefit of seeing how marvelously consistent and predictable the notation proves to be. IOW it's a great simplifier, allowing humans to mentally read, parse and understand Lisp code.

To me the great genius of Lisps is shown by the experience of looking at work I'd done months or years ago. Stuff I'd written before in C would often be obscure to me later, especially when I hadn't made enough comments to "explain" what the code was doing.

In contrast, it's much easier to understand my old Scheme programs, often just minutes of review will do it. Sure, I'm talented at making things convoluted, it's just harder for me to do that with Scheme, and no doubt that's true for Lisps in general.

I've looked at Clojure a bit, my impression is it's syntax is more complicated than Scheme. At least there are enough differences that it would take some effortful study to become fluent in Clojure. Not a criticism of the language, but suggests making the transition isn't trivial. Perhaps that applies in both directions.

It's worth adding in the domain of constructing web servers, the list notation of Lisp maps extraordinarily well, and easily, to the hierarchical markup of HTML. It's a feature I've exploited extensively, and I think it could provide better and simpler tools for web programming if employed more widely.


Let me throw this in as an additional reading - http://www.defmacro.org/ramblings/lisp.html - it goes over points 1 - 4 slowly, while building intuition about what's so special about this and code=data equivalence using nonlisper-friendly examples.


I learnt from the Seibel book:

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

You can start writing simple programs in a weekend. The learning curve is quite gentle.


For me it took 2-3 years to feel proficient using CL. I still learn new thing every week (for the last five years or so) and I can safely say that I will be learing for at least five more years. CL is a big language.


Frankly, arithmetic expressions are really the only part that's unusual. There's not much difference between:

    println("some text")
and

    (println "some text")


In Haskell, I have the luxury of infix arithmetic, but I'll still happily write

    sum [a,b,c,d,e]
when I have a lot of summands.

It's just neater, especially when you format as

    sum [summand1
        ,summand2
        ,summand3]
This is more natural in Lisp. Because of this, I always go to Lisp for things like my weekly shopping budget. For bonus points, I can put my cursor at the end of a close bracket and get Emacs to evaluate the enclosed subexpression, which I do lots to figure out the value of individual terms.


We do this in math too: ∑_{i=1,...,n} x_i is a lot more readable than x_1 + x_2 + x_3 + ... + x_n. (Underscore means "subscript" here.)


What was the hard part ? the prefixness ? the parens or the language basic building blocks (cons, map*, lambdas) ?


The prefix-notation is annoying when you're doing anything mathematical. It's sad that CL doesn't come with a infix reader by default, I'm sure there is one on quicklisp.


Yeah that's sad. We had to load it since 21 years...

https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/...

What a step back from my Symbolics Lisp Machine, where the infix reader was included...



This same article was published on planet Lisp http://planet.lisp.org/ by Pascal Costanza


Planet Lisp is just a blog aggregator, and his blog is one of the ones it aggregates.


This article illustrates one of the hurdles the Common Lisp community often sets before itself when it produces a piece of marketing. It points to resources that are not immediately obtained or that don't directly touch on the large subjects mentioned.

For example, one of the important capabilities mentioned in the article is getting close to the metal with profilers and hand tuning code and the runtime environment. Yet none of the links discuss this directly or provide tutorials.

The discussion about the wonders of CLOS suggests reading The Art of the Meta-Object Protocol - a $35.00 345 page dead tree tome which Amazon will get to you in about a week if you opt for free shipping. Graham's Ansi Common Lisp is of course even more obscure - it's been out of print for years and from Amazon you're in the realm of individual sellers [my anecdote is that it took about a month to get the copy I ordered - the seller was a nice person but it was a couple of weeks before they read their email from Amazon letting them know someone had purchased their copy].

The author goes on to recommend LispWorks as a platform. It's $1500 for 32 bits in North America and $4500 if you want to use all 64bits that your OS probably runs under. Sure there's a free version, it's 32-bits, not licensed for commercial work, and crippled. Don't get me wrong, the free version is probably fine for playing around with, but this article targets people for whom tuning the heap and GC are appealing, and this tends to be a professional rather than hobbyist market segment.

The "early Web 1.0" vibe is unfortunately common when the Common Lisp community attempts to promote Common Lisp. Let's face it, the linked Lisperati site looks a GeoCities page [a good one]. The LispWorks page requires four clicks to get to the price of non-crippleware. The author's own guide links to academic papers and black and blue on white websites.

The issue is that the Common Lisp Community is not just sending signals that most of the potential market ignores, it's that it is sending signals that turn the potential market off. I will unequivocally say that crippleware is no longer a viable approach to achieving significant developer mindshare. The landscape is open source and $4500 a seat [and calling it Enterprise Edition] is only going to hit some [potentially profitable] edge cases.

Of all the places accessible from the author's post, the only one that looks in touch with the present is the original article on BlogSpot. Everything else screams "This ain't for you" at most people.

It makes Racket look hip. And that's hard to do.


Yes, it is remarkably difficult to get into Common Lisp—or at least, it was until Practical Common Lisp (http://www.gigamonkeys.com/book/) came out, and it still is for topics PCL doesn't cover in-depth (e.g. CLOS).

On Lisp is definitely not a good beginners' resource. It's a great book in many ways, but I would never recommend it over PCL.

Lispers in general tend to have a fairly old-fashioned mentality (due, no doubt, to many of us being older) about many things. I think it's fair to say that there's much less of a sharing mindset, and much more of a closed mindset; the other way of wording that is that lispers are getting things done and making money doing them, not spending time updating community sites and sharing code (although there are some excellent open-source packages out there).

I'd really like to figure out how to build more of a Common Lisp community. The more I use it, the more I realise that it's a solid, professional, well-thought-out language for developing solid, flexible, reliable software. It's not perfect, but much of what looks like warts at first are actually features. Using it is the closest thing to expressing my thoughts as code. It really is a joy.


>I'd really like to figure out how to build more of a Common Lisp community.

I think the low-hanging fruit is web design. Just touching up the CSS of library documentation would be very useful. Presentation is a lot more important than people think.

For example, compare [0] to [1], or Crane's website[2] with, well, the average Common Lisp library.

[0] http://eudoxia0.github.io/screamer/

[1] http://nikodemus.github.io/screamer/

[2] http://eudoxia0.github.io/crane/


I find the screammer websites very nice (even though it wouldn't hurt to split off the manual/api to its own document).

The crane website I find utterly horrible. Reminds me of the typical Node.js or Ruby websites and that makes me shiver. A software library is not a consumer product. Design for a lipstick brand can not be used for an airplane company. Software deserves a professional "no-bullshit" design.

All three have a crucial mistake in common: Lines wider than 40em. A line must have between 8-12 words on avarage. And that is a typographic law, don't question it, we have known that since we wrote bibles.

The thing with "modern" web design is: I rather have no CSS then BAD design. And fact is 99% of all web developers are not worth their salt. They completely ignore the lessons of hundreds of years of typography.

My father is a designer and to my luck he taught me about typography. Everyone who touches a website should have read Jan Tschichold. There is no way around it, you will only repeat past mistakes.


I don't know if you're a Common Lisp guy, but comments like "99% of all web developers are not worth their salt" aren't really going to help your cause. If you personally dislike "the typical Node.js or Ruby" web sites, that's fine, but a lot of people who write software for the web these days clearly do like those sort of web sites and don't like an unformatted wall of text, even if the lines are a readable length.

(I had a quick look at your site and was vastly disappointed to see that the lines were, indeed, 8-12 words on average, thus precluding my saying "Physician, heal thyself".)


I know it sounds harsh but fact is that today's web design ignores past science. Book design is a very well understood design problem which has its roots in ergonomics and not in graphic design. I don't mean to discredit the "99%"s graphic design skills, in fact I find many graphic design works on the web astonishing and have huge respect for graphic designers (because I really suck at it, but love it a lot). Their book design education appears to be underdeveloped though and for websites ergonomics are more important than graphic design. Thats just the way it is.

Book design is an amazing field by the way. For latin characters it was pioneered by hand written bibles in the medival ages. I only know a few things about it, barely enough to see that its a dying art. :(

Edit: Oh and you cannot "personaly dislike" a book design work. Its the only art I know which has definitive right or wrongs, black or whites, yes or nos. There is only one correct way to typeset any given text.


Hmmm… I certainly do have the freedom to personally dislike a book design, whether the authorities say I should or not. And if that makes me typographically illiterate, then so be it ;-)

In fact, I find the line lengths in many properly typeset works too short for me to read comfortably. For me, longer lines make for easier reading!


People don't read websites, they skim them. Web design is much more akin to poster or presentation design than book design.


I am soo glad that viewpoint is on the way out, and we no longer have to live on the web equivalent of a brutalist concrete cube.


Would you mind elaborating more on what you mean by "Everyone who touches a website should have read Jan Tschichold". A quick search showed that Jan Tschichold has written many books (and many books have been written about him), in German, so I was wondering if there was a particular (preferably English) book you were referring to?


I have "Ausgewählte Aufsätze über Fragen der Gestalt des Buches und der Typographie".

Yeah not much of his work was translated, its sad. Maybe you can find similar/related/inspired authors who wrote or write in english. Its important to note that Tschichold made a U-turn at some point, while he was a big proponent of modernism at first, he later dismissed his opinions and became a proponent of classic typography. So I would go for writings from that later era.


That's a bit of an issue I've got with Tschichold. As there's a lot of "taste" involved in this, it's hard to separate rational judgement from just getting old and more conservative.

And one should note that even old Jan was there way before digital typography on the web, heck, even way before DTP.

Don't get me wrong, I really liked his typography for laymen booklet ("Erfreuliche Drucksachen durch gute Typografie", a title that really can't get both more quaint and Germanic). But he's really supremely conservative in there, warning everybody about the dangers of color, sans-serifs and lauding the beauty and composition of medieval woodblocks. So, yeah, cum grano salis as they say…


Check out quickdocs.org

It's the best centralized source of CL docs I've seen and the design is fairly modern.


I find Nikodemus' original document easier to read than what you have done with it.


[2] the boxes cut off the code on the right side...


There are plenty of things I think could be updated about CL, and I wouldn't recommend LispWorks as a first place to start either. But I think you'd have to be part of a really niche area of tech to consider the very concept of reading books to be obsolete. If I want to get into a new language, the first thing I look for is whether there is a good introductory book, vs. just a scattered set of HOWTOs/READMEs/Wikis.

However there are books online as well, nowadays, if you really prefer to read on a screen. Seibel's Practical Common Lisp is a good starting point: http://www.gigamonkeys.com/book/


I don't think the point was "reading books is obsolete" so much as that only having printed books as references presents a hurdle to the would-be Common Lisper. A language that has good free tools and online documentation available is a language that you can start playing with right now, the moment the desire strikes you, which encourages new people to join the community. If you have to wait for a book to arrive or shell out X thousand dollars to get decent tools, some non-trivial percentage of interested people will decide it's not worth doing those things and move on.


The usual reference of Common Lisp is the Common Lisp Hyperspec. Online and for download. http://www.lispworks.com/documentation/HyperSpec/Front/

Several books for learning Common Lisp are online or for download:

* Peter Seibel, Practical Common Lisp, http://www.gigamonkeys.com/book/

* Common Lisp: A Gentle Introduction to Symbolic Computation, http://www.cs.cmu.edu/~dst/LispBook/

* On Lisp http://www.paulgraham.com/onlisp.html

It's just that these books are 'old'. Common Lisp is 30 now. But since the core language does not change much, the old books are still fine. They may smell a bit.


I'm biased toward reading dead tree books - last month I paid 99 cents for The Standard C Libary, so I take that into account.

What I also take into account is StackOverflow. There are a lot of programmers who don't even read a page of google search results.

I will also say that from my time on HN, the number of people who read dead-tree technical books versus the number who read ebook versions of technical books may be less than dead even. They're cheaper [new] and services like Safari provide entire libraries at reasonable prices. [I've commented elsewhere in this thread on how Seibel's book exemplifies the some of the Common Lisp community's tone deafness].


Well, I have personally contributed 1000 answers to Lisp questions on Stackoverflow.

http://stackoverflow.com/users/69545/rainer-joswig?tab=answe...


I wasn't suggesting that Lisp programmers tend to page fault into learning. I apologize for not being clear.

What I was getting at is that StackOverflow shows that many programmers in general tend to page fault into learning whatever language they happen to be using. This is a behavior which StackOverflow is explicitly designed to facilitate. It is also designed to facilitate the behavior in ways that are better than traditional Usenet and its web-based descendants in the form of fora.


You might want to check the Stackoverflow FAQ. Stack Overflow is a question and answer site for professional and enthusiast programmers.

It is expected that people learn a programming language and when they have actual programming problems, then they come to Stackoverflow.com.


Recently I've listened to nearly all of the StackExchange and StackOverflow podcasts - as a tangent this includes the one's where they discuss updating the FAQ, the contents of the old FAQ why it was obsolete, what the new FAQ needed to accomplish, and of course the contents of the new FAQ as it evolved.

One of the reasons that I listened to all of those podcasts is that I found Spolsky's and Atwood's ideas [1] about online communities insightful and was able to relate them to my experience in other online communities. I recommend them to anyone who shares my interest.

[1] and those of their guests and other team members.


>The issue is that the Common Lisp Community is not just sending signals that most of the potential market ignores, it's that it is sending signals that turn the potential market off.

Absolutely agree. The Lisp community could attract hundreds of new people overnight simply by learning a little CSS.

The one thing every other "hip and cool" language community has is that it has learnt that presentation matters. The people who use Python, Ruby and Node have all learnt this, but it seems most Common Lispers are perfectly happy with plain-old HTML pages that look like they were made in 1996.


I admit it: I love "HTML pages that look like they were made in 1996."


And I love the CSS thing that mimics the Symbolics interface (Putting a border around links on hover). But people want "CSS they can trust", as I like to put it. Startuppy Silicon Valley CSS. It may be just marketing, but marketing matters!


Yes design matters.

I think that software deserves very minimal, functional and strict design. Accessibility over everything, uniformity over creativity. I "live" these design decisions for my business website and my products and I have attracted exactly the people I wanted to attract.

So I must assume that my 1996 design was the right choice for my customer segment.


May be that's how they get ardent devotees, like the Sufi masters of yore :D


As a long-time Lisper myself, I am a little surprised at the emphasis on LispWorks in this thread. I never used it much myself, and when I did I wasn't that crazy about it, though that was a dozen years ago so who knows. But the point is, Clozure CL and SBCL are just fine for anything I do. I would recommend Clozure CL to newcomers; SBCL is faster (I think), but more complex to use.


Clozure CL and SBCL are great. I use both.

It's just that LispWorks comes with batteries included, has a cross-platform GUI toolkit, has a cross-platform GUI-based IDE, has a great runtime, has more delivery options, makes great use of CLOS, has more tools included, ... There is a noticeable step up in features from the typical open source / free software implementations to something like Allegro CL or LispWorks. Since both a proprietary and relatively expensive, often they are not a choice. But the fact remains, that they offer more and better features. SBCL shines with some features of its compiler. The topic is discussed, because for some people it is difficult to understand why one pays thousands of dollars for development and/or runtime (see for example the Azul JVM which starts at $3500 per machine per year).


It is a sad state of affairs that kids these days expect everything for free on IT, whereas in other professions one needs to pay for its tools.

Maybe it is showing my grey beard age, but I have bought quite a lot of software in my life, books(!) and even pay donations to open source projects.

As someone that lives from software development, I know how much it costs to transform my hours into something I can give in the supermarket and not all types of FOSS can be adapted to consulting.

Every time someone complains to me about software prices, I make them go through how would they manage to get enough money pay their current salaries. Then the prices don't seem that expensive any longer.


People have been complaining about the moral decline of culture as reflected in the behaviors of youth at least since Socrates and 孔子, so perhaps it is the world's oldest rant. And of course Luddism is equally as old:

If men learn this, it will implant forgetfulness in their souls; they will cease to exercise memory because they rely on that which is written, calling things to remembrance no longer from within themselves, but by means of external marks. What you have discovered is a recipe not for memory, but for reminder. And it is no true wisdom that you offer your disciples, but only its semblance, for by telling them of many things without teaching them you will make them seem to know much, while for the most part they know nothing, and as men filled, not with wisdom, but with the conceit of wisdom, they will be a burden to their fellows.

I am not complaining about software prices. Just acknowledging the zeitgeist. My own grey beard is not so long that it covers my eyes - even when standing on my own bald head.


> I will unequivocally say that crippleware is no longer a viable approach to achieving significant developer mindshare. The landscape is open source

$4500 is definitely steep, but I sure hope you're wrong about commercial development tools no longer being viable. Not because I develop such tools myself, but because I want good tools. How will developers be paid to create great development tools, if it doesn't happen to be in the best interest of a company like Google, Apple, Red Hat, or Joyent to fund the work? See also: http://sealedabstract.com/rants/of-wizards-and-magical-machi...

We've become really spoiled. And that applies to me as much as anyone.


On Lisp by pg is available for free online.

http://ep.yimg.com/ty/cdn/paulgraham/onlisp.pdf


> It makes Racket look hip. And that's hard to do.

Hey!


Credit where credit is due. Racket is moving forward, and that has required solving the same issues I mentioned with Common Lisp. And the Racket Community is doing it from the ground up in ways that are likely to scale...e.g. Scribble.

In particular, the new default CSS for Scribble is a vast improvement. But racket-lang.org isn't as sexy as clojure.org, and pending an influx of commercial cash probably won't be.

The Racket community tends to row in the same direction and does so by consensus, and that makes it's social structure potentially as hip as any open source project. If there was a Racket on Treads for building CRUD, who knows how much use it would see inside the local Starbucks.


Is there something in particular you find "unsexy" about racket-lang.org? Personally, I like it a lot more than clojure.org, but that may just be because I wrote it. :) I've always found the official Clojure web presence to be somewhat staid, by comparison to Scala or Python.


> a piece of marketing

There is no need to market CL. If you are a hardcore programmer then chances are you will love CL.

> Yet none of the links discuss this directly or provide tutorials.

I can recommend "Let Over Lambda" by Doug Hoyte.

> The author goes on to recommend LispWorks as a platform.

We have A LOT of extremely high quality free OSS implementations. Pick any.

> The "early Web 1.0" vibe is unfortunately common when the Common Lisp community attempts to promote Common Lisp.

And I think that this whole Web 2.0 thing is a big pile of bullshit that I never wanted in the first place.

> The issue is that the Common Lisp Community is not just sending signals that most of the potential market ignores, it's that it is sending signals that turn the potential market off.

That paragraph doesn't make any sense at all. No comment.

> Everything else screams "This ain't for you" at most people.

Since when are you the authority on what "most people" feel? Most people don't program the way I do.

> It makes Racket look hip. And that's hard to do.

I knew you were a troll. Your strawmen are just too outrageously bad.


I think the hurdles are less than you think, but Common Lisp is probably not for you. But I think that's fine. There is already a lot of stuff for 'most people'. Why does everything need to be built for 'most people'? Why isn't it okay that there are things which are not for most people? Haskell is not for most people, Prolog is not for most people, Coq is not for most people, why does Common Lisp need to be for most people? The article describes why Charlotte Herzeel likes Common Lisp. maybe she is not 'most people'?

* you don't need to read AMOP to use CLOS. It's there if you want to know 'MORE'. Much more. Much more than you ever wanted to know about reflective OOP. Alan Kay of Smalltalk fame recommended the book as the best book on objected-oriented technology in a decade. ordering it over your book store is easy. But I don't recommend it to anyone wanting to learn Lisp. Read it if you want to know how CLOS is implemented or extended. A bonus point: it shows excellent coding style.

* 'Yet none of the links discuss this directly or provide tutorials.' The LispWorks, SBCL, Clozure CL manuals discuss that. Since there is so much stuff to link to, I recommend to go fully old-school and read the fine manual.

* as the starting book most will point you to Practical Common Lisp by Peter Seibel. Free online and available printed. It even explains a lot of CLOS.

* 'The author goes on to recommend LispWorks as a platform.' I do that too. Not the free version. The full commercial version. I even have the full 64bit 'Enterprise' version of LispWorks on my Mac.

* Web 1.0: Even worse, a comic book about Lisp programming using Common Lisp. http://landoflisp.com

* '$4500 a seat [and calling it Enterprise Edition] is only going to hit some [potentially profitable] edge cases.' - well you may want to compare what a commercial Smalltalk, Ada or Prolog system costs... The market is small and lowering the cost would help letting the company survive. Something must be working for them: LispWorks was first released 25 years ago.

* 'Everything else screams "This ain't for you" at most people.' - well, Common Lisp is not for most people. For most people there are many simpler options. For those wanting to work on fancy Web X.0 stuff in an easy way, there are better options - and that's totally okay.

Common Lisp is not for most people.

For those who want to use Common Lisp as free and no-cost software, the article mentions 'Clozure Common Lisp' and 'SBCL'. I'd say that's excellent choices. I use those, too. Still I prefer the commercial and expensive LispWorks...


I'm a fan of reading the fucking manual and thus you're preaching to the choir on that. But I'm not an evangelical baptist about it. Truth is that most people program by page faulting - writing some code, hitting a bug, and googling for a solution, lather rinse repeat.

Don't get me wrong, 4500 bucks is probably a bargin. But again the landscape is dominated by FOSS. More to my point the points of comparison are pre-www. Ada, Smalltalk, and Prolog as alternatives suggest a time before twenty-something developers' parents were in college. Those languages were hot at the same time as Lisp Machines. Was an opportunity missed to mention Modula-2 and rotary dial telephones?

The Common Lisp community doesn't handle onboarding well. Seibel's Practical Common Lisp is ok, but how long has it been since CD's were an important recorded music medium for people spending their time with computers? Well over a decade since the days of Napster. Coming up on a decade of iTunes. CD's are more old-school than landlines.

This is to take nothing away from Common Lisp as a language. It's not a knock on the individuals who make up the Common Lisp community. It's pointing out the Common Lisp community's blind spot. Mcarthy was brilliant. He also could have been Rich Hickey's grandpa. We don't make phonecalls on party lines anymore.

Figuring out how to reach the next generation of programmers doesn't require compromising on principle. It does require recognizing that what didn't really work in the past [that is the past since the days when Prolog and Ada were hot, e.g. since C++] probably won't work today, either.

I mean, what's the case of Common Lisp over Clojure? And by that I mean:

  + point me to a webpage that sells me on the idea 
  
  + has a clear call to action

  + and looks at least as vibrant as Clojure's homepage


> most people program by page faulting

As I said, Common Lisp is not for most people.

This Web 1.0 page describes the concept: "Teach Yourself Programming in Ten Years" http://norvig.com/21-days.html

> But again the landscape is dominated by FOSS.

Which landscape? There is not one landscape. Is Apple's XCode FOSS? Windows dev tools? Open Source?

If you believe in FOSS, you can use SBCL, CMUCL, CLISP, ECL, MKCL, Clozure CL and several others. I use SBCL and Clozure CL.

> CD's are more old-school than landlines.

Write games with Land of Lisp then. But sorry, the Common Lisp community is not large enough to rewrite books every so often. In the mean time there are classics like Peter Norvig's PAIP, which are even older and even less exciting. Still it is easily one of the best programming books ever written.

> Ada were hot

Ada was never 'hot'. It is a tool used in a lot of mission critical software.

> I mean, what's the case of Common Lisp over Clojure?

I think you have to find that out yourself. Don't be sad if Common Lisp is not for you. Few people drive a Mercedes Unimog, though Arnold Schwarzenegger had one. http://i.dailymail.co.uk/i/pix/2014/09/04/1409847539952_wps_... You might ask what the Unimog does better than some Toyota, why it costs so much and why so few people have one. If you might spend some time, you might find out what the Unimog is, why it exists and who uses them for what...


>> But again the landscape is dominated by FOSS.

> Which landscape? There is not one landscape. Is Apple's XCode FOSS?

Xcode the IDE is not. The Clang/LLVM compiler, LLDB debugger and many of the other tools are open source.

http://llvm.org

http://clang.llvm.org


The whole development process for Apple's OSX or iOS is not 'free'. Many libraries for OSX or iOS are not free and not open source.

Apple's Cocoa is not FOSS, for example.


>I think you have to find that out yourself.

This won't really do anything to bring people closer to Common Lisp.

This is a bad thing btw.


Maybe you want to answer the question, why or when one should choose Common Lisp over Clojure. I have not enough knowledge about Clojure to answer that.

Thanks.


If it means that this brudgers guy stay away thats a really great thing.

Seriously reading this thread makes me so happy that we don't attract these douchebags.

Edit: friendly fire, sorry


I love Common Lisp[0], that's why I'm trying to improve it.

[0] https://github.com/eudoxia0


Yeah, using words like "douchebags" for other people in the thread reflects great on you and your closed club.

Especially since "brudgers" states his case with arguments and politely and has not sweared at anyone.


Please, he opened up a giant can of strawmen and smeared the CL community because he prefers eBooks, different kind of web design and more marketing.

So yes, I consider it douchey to open a completely pointless debate where there could have been a constructive discussion about the strengths of CL.


One man's "strawmen" are another man's real issues. If you disagree with someone on what the problems are, all he says would look like strawmen.

That doesn't warrant a "douchebag" stamp.

Plus I don't think the word "douchebag" or "douchey" os appropriate for a discussion among people that are not 17-year olds, 20-yo tops. There are far better adult swear words available if needs be.


You are right. In retrospect I am a fool.


Well, don't take it hard on yourself. We all are sometimes!


Obviously I would be redundant.


We indeed have our own trolls...


There are different ways in which a programming language isn't right for someone.

For example, it can be like beef liver. It's not that I don't eat it because of a commitment to vegetarianism. I'm not a vegetarian and I'll gladly eat rare cow on a bun. It's not that I don't believe beef liver is nutritious. I just find eating beef liver an inherently unpleasant experience. It's how I feel whenever I try to use Python [even though it is quite likely more popular than beef liver].

There are also languages which aren't right for me because they don't really fit with what I want to do. Swift for example is only available on the OSX platform and I don't own a Mac.

Neither of those apply to Common Lisp. The reason Common Lisp isn't really for me is that there are simply less painful alternatives for the sorts of things I want to do. And one of the ways in which those alternatives are less painful is because of their communities.

It's not that language communities shouldn't be opinionated. I listened to DHH talk about Rails in the early days on an older Hansel Minutes podcast. The object is "person" and the table is "people". If that offends someone, then Rails might not be for that person.

But the Rails community gets to the point quickly. It lays out the facts and moves forward. Within that community it is not considered acceptable to say, "read this book and these five papers and drop a few thousand on commercial software, and then we might consider you worthy."

They tend not to tolerate that. But from the heritage of usenet.comp.lang.lisp that's still considered by some a perfectly entertaining way to treat novice questions in the Common Lisp community. Answering easy questions is dull and being snarky is an outlet for creativity in comparison.

In the end, my hypothesis is that programming languages live and die the same way as natural languages, either the community onboards new speakers and the language lives or it doesn't and the language dies [take this as a Kuhn paradigm if you prefer a reference point in science]. C remains vibrant as the language of Unix and its descendants. JavaScript thrives as the language of the web. Pascal and Algol and Simula are less than vibrant or thriving because few people are learning the language.

By analogy some members of the Common Lisp community often behave as if it's wrong for babies to babble, that toddlers should learn the alphabet by reading Faulkner, and that only then are they qualified as persons.

Norvig's article is about learning programming, not taking ten years to learn a programming language. Contrary to a portion of our dialog, he's a bit language agnostic.


> Within that community it is not considered acceptable to say, "read this book and these five papers and drop a few thousand on commercial software, and then we might consider you worthy.

You totally distort the Common Lisp community and you post FUD. You attack Charlotte's preferences for no reason. She presented HER preferences. Still you attack the Lisp community as if individual opinions are not allowed and as if she speaks for all.

Chearlotte speaks for herself and I think her recommendations are good.

There are a multitude free and open source implementations. Many were developed before stuff like Rails or Java even existed. Free and Open Source software has been written in Common Lisp from day one.

Clozure CL, mentioned by Charlotte. It is published on the LLGPL.

SBCL, mentioned by Charlotte. SBCL's roots go back to the early 80s as Spice Lisp and then CMU Common Lisp. Public Domain since 30+ years.

And many others. Usually people complain the Common Lisp has too many implementations.

Nobody required somebody to invest $4500 into a Lisp system to start.

It's just that some people in the Lisp community use the commercial tools and think they are great. I'm one of those. LispWorks is probably the best implementation of a dynamic language anywhere.

If people have actual problems with coding, they have multiple forums. I have personally answered 1000 Lisp questions on Stackoverflow.

> analogy some members of the Common Lisp community often behave as if it's wrong for babies to babble

Some non-members of the Common Lisp community seem to whine a bit too much for my taste. What the Common Lisp community (if there is one) does not really like is whiners who fail to contribute.


I'm not attacking the Common Lisp community. If I were, I certainly would not have opened my comments with the idea that the community places a hurdle before itself when marketing the language it loves. And one of the things I love about Lisp is the way in which I share a love for the language with the larger community.[1]

I have nothing against commercial tools. I've spent many thousands of my own dollars on shrinkwrapped bits over the years. That doesn't change the fact that shrinkwrapped bits are continuing to diminish in popularity due to thirty years of Stallmanism running in parallel with nearly thirty years of "greed is good" and even more years of a hacker ethos where spending 80 hours to pirate fifty dollars worth of software is a hobby.

Why care if the Common Lisp community likes me? It don't like most people. It would be foolish to its dislike personally. In fact, why blame them when Hell is other people?

The upshot is that I care enough to say something constructive. I don't wish the Common Lisp community anything but success. I'm not a jaded ex-lover. I hope it meets someone new and that someone turns out to be its soul mate.

[1] Going so far as to coin the term "love song to Lisp": https://hn.algolia.com/?q=love+songs+to+lisp#!/comment/forev...


"[even though it is quite likely more popular than beef liver]."

It's a total digression, but if you don't restrict your population under consideration beyond "all humans", I would guess that's not the case.

Quite a few more people eat cow than program, so even if Python is significantly better liked amongst programmers than liver is amongst cow eaters, there's plenty of room for liver to be "more popular".


>Which landscape? There is not one landscape. Is Apple's XCode FOSS? Windows dev tools? Open Source?

A lot of it is. XCode's compiler, LLVM is FOSS. Microsoft just open sourced large parts of .NET libs and compiler. And there's also Mono, a FOSS implementation of .NET.

Plus, even the closed parts, like XCode and Visual Studio, are either free, have totally functional "community editions", or at worse are dirt cheap -- not $4500 to get to professional development.

>As I said, Common Lisp is not for most people.

You say that as if it's good.

It might be a fact, but it sure ain't good.

Is there a single good thing that can be argued to come from a language not being popular?

I meanbeside BS like "keeps the amateurs away?", which judging by the abundance of amateur Lisp code one sees, is not an actual advantage of Lisp...


Richard Stallman is not happy at all about the LLVM FOSS situation:

http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

> You say that as if it's good.

> It might be a fact, but it sure ain't good.

Is it bad that not everyone understands Hegel or Heidegger? Does that make their writings less useful?

> Is there a single good thing that can be argued to come from a language not being popular?

It's not a question of good or bad. It's a fact of life that some things are less popular than others, which says nothing about the usefulness of the tool.

> I meanbeside BS like "keeps the amateurs away?", which judging by the abundance of amateur Lisp code one sees, is not an actual advantage of Lisp...

It's just that not every programmer has the intellectual capability to understand, master and use Lisp. That's a fact. I've seen that myself countless times at university in beginner's courses. Also many programmers don't need the features Lisp offers and are happy with other approaches. For them Lisp is too complex, too flexible, etc.

Lots of people can learn some basic Lisp or simple Lisp dialects. But once they use actual features of Lisp, which allows every user to radically change the language, the things get tough... in the industry stuff like that is not liked. They want tools and developers which are more predictable.

I think you should get over this 'popularity' BS.


> Lots of people can learn some basic Lisp or simple Lisp dialects. But once they use actual features of Lisp, which allows every user to radically change the language, the things get tough... in the industry stuff like that is not liked. They want tools and developers which are more predictable.

This is such a silly and elitist argument that I've always wanted to dismiss it outright on those principles, but I think it can finally be dismissed on factual grounds now that Clojure is a thing and is actually popular in the industry. The argument that people just can't get Lisp was always an embarrassing position to stake out, but now it no longer holds any water too.

Everyone has their own opinion as to why Common Lisp is having popularity trouble. Mine is that the spec is twenty years old and has no reasonable process for moving forward. I think a number of people are of the opinion that the spec represents stone tablets handed down by God and is completely perfect, but I on the other hand find a number of useful elements missing that are difficult or impossible to implement universally with macros. IMO, Common Lisp's popularity problem flows from its lack of evolution.


> This is such a silly and elitist argument that I've always wanted to dismiss it outright on those principles,

Calling an argument silly and elitist does not help your case much.

> Clojure is a thing and is actually popular in the industry.

The number of Clojure developers and its percentage is tiny. Far from 'popular'. It's also in a different stage of the hype cycle.

> The argument that people just can't get Lisp was always an embarrassing position to stake out, but now it no longer holds any water too.

You need to actually read what I said. Basics of simple Lisps are relatively easy to learn, still many people fail at it. I've seen it in computer science University courses where only like 10% were able to write anything useful in Lisp, struggling with recursion, graphs, dynamic typing, ... Few ever got so far that I would let them program macros.


>Few ever got so far that I would let them program macros

If you start with the assumption that it's for "few people", and teach it like that, then few of your students will get it.

Yet, people have used Scheme and CL as a first language, and even Haskell, and students were able to pick them just fine.


>It's just that not every programmer has the intellectual capability to understand, master and use Lisp. That's a fact. I've seen that myself countless times at university in beginner's courses. Also many programmers don't need the features Lisp offers and are happy with other approaches. For them Lisp is too complex, too flexible, etc.

Besides elitist (which I wouldn't mind, if it was also true), this is quite false.

In fact I've seen more bragging and preaching than real world output that people care for from most Lisp advocates.

And even most of the things they are so proud of for building (with the exception of Emacs, which is also based on C), people have built in other languages and with more popular and full featured results.

>Lots of people can learn some basic Lisp or simple Lisp dialects. But once they use actual features of Lisp, which allows every user to radically change the language, the things get tough... in the industry stuff like that is not liked. They want tools and developers which are more predictable.

That's cowboy coder mentality stuff.

And in 2014, the ability to "radically change the language" is not that impressive. It merely boils down to: "Hey, my additions have the same syntax as native stuff and I can do meta-programming too". Sure, but first you have constrained yourself to a very specific syntax, so it's all a wash.


"Is it bad that not everyone understands Hegel or Heidegger? Does that make their writings less useful?"

Yes, actually. If they wrote clearly enough so more people could understand their point, their writings would be more useful. The point of writing something is generally to communicate with others, unless it's a personal journal or diary, meant to be kept private.

"It's just that not every programmer has the intellectual capability to understand, master and use Lisp. That's a fact. I've seen that myself countless times at university in beginner's courses."

Isn't it much more likely that the difficulties are more due to the fact they are beginners, than due to the language used in the course? Did you teach identical material using other languages, and found the students understood the material better? (Honestly curious.)

"But once they use actual features of Lisp, which allows every user to radically change the language, the things get tough... in the industry stuff like that is not liked."

Meta-programming in Ruby has the same challenges, but there is definitely a strong segment of commercial developers who whole-heartedly embrace those techniques. They didn't just give up and say "Oh well, guess we have to give up and go back to using Java", or adopt some complex about their language being too brilliant for other programmers to ever use. Instead, they put effort into persuading others the expressive power of Ruby is worth the tradeoff with predictability. They don't convince everyone, but they certainly managed to get a lot of developers on their side.

I think the Common Lisp community certainly could have accomplished the same thing. There's nothing about the language itself hindering broader adoption, or limiting it's use to academics or elite programmers. It's just the community that seems to want to keep it that way.


> Yes, actually. If they wrote clearly enough so more people could understand their point, their writings would be more useful. The point of writing something is generally to communicate with others, unless it's a personal journal or diary, meant to be kept private.

That's what Hegel and Heidegger did. They communicated with others. It's just that their thoughts are more complicated.

> Isn't it much more likely that the difficulties are more due to the fact they are beginners, than due to the language used in the course? Did you teach identical material using other languages, and found the students understood the material better? (Honestly curious.)

The experience is that 10% of a course were able to write some Lisp. 40% struggled with the tasks, but made it somehow. The rest more or less did not get more than the basics and were confused by things like 'code is data', recursion for iteration, ...

> Meta-programming in Ruby has the same challenges

Meta-programming in Ruby is very limited to what Lisp does enable. Matz designed Ruby for 'ordinary programmers' (his words). Ruby lacks the whole Code-is-Data idea and on the OOP side, it lacks many of the features of a MOP, ... But it was designed that way.

http://www.matthewdavidwilliams.com/2008/11/06/rubyconf-2008...

Matz thinks that there is a cliff and Lisp is beyond that cliff for 'ordinary' programmers. 'Smart people just underestimate ordinarily of ordinary people'.

http://rubyconf2008.confreaks.com/matzs-keynote.html

> Instead, they put effort into persuading others the expressive power of Ruby is worth the tradeoff with predictability

What Matz actually did, was scaling down the language to dynamic OOP + some functional elements.

> I think the Common Lisp community certainly could have accomplished the same thing.

The Lisp community could have scaled down the language. People have done it: Standard Lisp, Logo, Dylan, Eulisp, ISLisp, Scheme, Clojure, ... Some were more scaled down that others.

Common Lisp stayed like it ever was: a language with lots of flexibility and extensibility.

> There's nothing about the language itself hindering broader adoption, or limiting it's use to academics or elite programmers

I've seen research programmers struggling debugging macros which were writing macros. There are code bases where I myself struggle debugging stuff... Common Lisp is great, but it offers so many ways to shoot yourself into the foot....


>That's what Hegel and Heidegger did. They communicated with others. It's just that their thoughts are more complicated.

Well, here's a Hegelian thought for you: the demise of Lisp in the AI circles, and then in the industry means that wasn't not "real" enough (in the Hegelian sense), it was just a temporary transition phase till newer languages got GC, reflexion, macros, metaprogramming, etc.

Die Weltgeschichte ist das Weltgericht, as they say...


> It's just the community that seems to want to keep it that way.

To be fair, it's just that no one cares to proselytize.


Strange, because 90% of what comes out of LISPers is proselytizing (or touting their own horns, which serves the same purpose).


That's mostly because we get annoyed when we see old things being marketed as "new" and "hip" :) That's not proselytizing, that's snobbery.


Well, macros, closures and GC haven't been "new" or "limited to LISP" for like 40 years.

So, if LISP had them since 60 years and others got it 20+ years later than that, hardly matters by now.


It does matter when Lisp is not given due credit.


>Is it bad that not everyone understands Hegel or Heidegger? Does that make their writings less useful?

No, but programming languages are not like Hegel or Heidegger. They have network effects, and they need a good ecosystem.

It's more like a political/state philosopher (like Plato, Marx etc) or a reform theorist. If he could not get people on his platform he wouldn't have the influence he needed to influence policy, which would be bad for him.



That's an old article that only discusses intrinsic language features, and doesn't even try to sell people on Common Lisp's ecosystem. I imagine most people who explicitly choose Clojure over Common Lisp do so because of concerns over CL's ecosystem.


At the bottom it says that SBCL 1.0.18 was used. That version came out in mid 2008[0]. Therefore the article is at most six years old.

As for concerns about the ecosystem, you are going to have to elaborate.

[0] http://t20846.lisp-steel-bank-development.lisptalk.info/1-0-...


A brutal truth of programming today is that serious tools for educated & dedicated people don't have large communities. Of course, this is predictable with the law of large numbers[1], which implies that as size grows, the system shifts towards mediocrity.

But since Haskell, Prolog, Common Lisp, etc, are designed for people who take their tools seriously and perform serious inquiries, they are generally incapable of casual pickup and use by the novice.

I've spent years in Common Lisp and can't recommend it enough for someone interested in a designed dynamic language (as opposed to Perl or Python). I imagine modern Smalltalk might have the same feel.

[1] http://mathworld.wolfram.com/WeakLawofLargeNumbers.html


> Haskell is not for most people, Prolog is not for most people, Coq is not for most people, why does Common Lisp need to be for most people?

Prolog and Coq don't really feel like general purpose languages, they have very specific uses. Haskell and Common Lisp are general purpose languages, they are not meant to be used just for one domain.

What do general purpose languages such as Haskell and Common Lisp gain by remaining niche languages?

I'm genuinely curious. Sure - the community might be a bit more tight knit and the overall signal-to-noise ratio is a bit higher, but the overall output of a community 100x larger will always drown out the smaller one. And among the hundreds of projects out there at least some will certainly outshine the "polished to perfection" projects made by the smaller community. At a certain point the larger community will just have more quality projects than the smaller one.

So what does Common Lisp gain by purposely avoiding contributions? I'm genuinely curious.


> So what does Common Lisp gain by purposely avoiding contributions?

Does it do that?

Contributions are welcome. It's just that it is not easy for most people to contribute to something like Haskell or Common Lisp. Many people just don't have the time or capacity to learn in. There are some people who learn Common Lisp because of specialized tasks (like composing music), but they have a motivation to learn a special tool.


Many people don't have the time or the capacity to contribute to Python or C++ or PHP, either. Yet I rarely see comments as dismissive of the general programming population such as yours, coming from Python/C++/PHP users.


Common Lisp, the standard does not change, but each programmer can radically change the language in a day. This power is simply not for everyone and not everyone needs it.

There is nothing dismissive about it. It's not that many people need a language, where working on one of several meta-levels is the norm and not the exception.


Yeah, there's a lot dismissive about it.

Or, put more bluntly: stop being an asshole. It demeans you and what you're trying to champion.


> Yeah, there's a lot dismissive about it.

It's not. Different people have different intellectual capabilities. Some can read Hegel, most don't. Some understand Monads, most don't. That's how it is. Some can debug compile-time macros, others can't.

> Or, put more bluntly: stop being an asshole. It demeans you and what you're trying to champion

A personal attack. Great style!


Dude, I'm not even disagreeing with what you're saying. I'm saying you're being an asshole all over this thread.

Chill.


I'm neither your dude nor your asshole.

Get some manners.


Well, he is right that you're definitely not polite.


Because I told you guys that not everyone is intelligent enough to be able to program Lisp on a competent level? Is that a surprise for you?

See the 2008 Ruby conference keynote from Yukihiro 'Matz' Matsumoto. He explains it in detail. Start at 8:40.

https://www.youtube.com/watch?v=vDnOBXD167k

I have interviewed many Java programmers in the past five years. I never found one who could explain how GC works, what lambda in Java 8 does, etc. There are a lot of ordinary programmers out there, even some of them with ten years work experience were surprisingly bad at actual programming. I hired some good ones, but generally the number of not so good programmers is high. Giving them a language where code is data, is a recipe for failure...


There are tons of mediocre or even bad programmers out there, in any language. Many of them don't really understand the language they're supposed to master. Heck, there are a trillion C++ programmers out there and giving sub-par programmers access to C++ is also a recipe for failure. Did that ever stop any non-elitist language community?

The reason they're "accepted" is that ultimately they make an ecosystem bigger. They want IDEs, linters, debuggers & other tools, books & presentations & trainings, libraries, services, etc - most of which are paid and which allowed better programmers to earn a living. Some of them - a minority - actually move beyond this newbie phase and contribute something useful. They make crappy and less crappy libraries, some of which might be used by "code wizards" when they need to do something (after all, does anyone except for the military, maybe, 100% audit the code dependencies they have?).

Let them come, be nice, and they will filter themselves out.

I have an additional question for this debate: think about a problem you'd like to solve while developing an application as a start up. What's the likelihood that your problem is solved by several robust libraries in Java and in Lisp? I'd bet that Java probably has several, not just one, high quality open source implementations of the thing I'm looking for - despite the crappy programmers you mention. By high quality I mean - at least decent code quality, good documentation, a lot of examples, discussions about it on public forums, maybe even commercial support, etc.


Personally I would not want to work in a startup problem where I need Java.


* you don't need to read AMOP to use CLOS. It's there if you want to know 'MORE'. Much more. Much more than you ever wanted to know about reflective OOP. Alan Kay of Smalltalk fame recommended the book as the best book on objected-oriented technology in a decade. ordering it over your book store is easy. But I don't recommend it to anyone wanting to learn Lisp.

Certainly not. The AMOP teaches you CLOS assuming you already know CLOS. In the words of Edmund Blackadder describing Johnson's dictionary, it is the most pointless book since "How to learn French" was translated into Fresh. And therein lies its brilliance.


>I think the hurdles are less than you think, but Common Lisp is probably not for you. But I think that's fine. There is already a lot of stuff for 'most people'. Why does everything need to be built for 'most people'? Why isn't it okay that there are things which are not for most people?

Because unless you are a hobbyist or a devil-may-care like professional, you want a big community, lots of resources, great libraries and tooling.

You might not need "most of the people" (majority or plurality) for that, but you sure need "lots of people".

A big community is an essential for basing whole businesses on a language and having access to everything you need in abundance (instead of several projects in various states of source rot, as happens for most unpopular languages) -- and it also doesn't hurt, infact helps very much, for the language lover that would stick to it even if he was the sole user of the language.


> Because unless you are a hobbyist or a devil-may-care like professional, you want a big community, lots of resources, great libraries and tooling.

Then use a language which has that. There are a lot of big community languages with great resources. There is nothing bad about using those.

Lisp has several features which makes it slightly unpopular, but at the same time it is different enough, so that it survives and helps some people to express their ideas.


Learning CLOS from "The Art of MOP" is a stupid idea. Sonya Keene's book is far more suitable, and also rather unnecessary.

Onlisp is a useful resource: http://www.paulgraham.com/onlisp.html. ANSI CL is nice too. For something simpler checkout David Touretsky's book, or Stuart Shapiro's book. PCL is awesome too. The latter is far more in touch with current CL "style". PAIP is also very cool.

No one is asking you to use Lispworks! If you can't afford to pay for it, use SBCL or CCL with Emacs/SLIME.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: