1. 35
  1.  

  2. 10

    The article matches my experience. Python was my favorite language because [I thought] it had great support for interactive programming, which is the style I’m more comfortable with. After learning CL I know longer think that is true. Python is another batch-oriented ‘dead’ language to me. (And TDD at least allows me to treat it as a zombie ^_^)

    A minor nit about the hype epilogue

    JavaScript was written in CL!

    It is incorrect or at least overselling it. Mozilla had a CL prototype of ES4 iirc, but it was never shipped. Although there is a JavaScript implementation in CL by the author of code mirror: http://marijnhaverbeke.nl/cl-javascript/.

    The C# garbage collector was prototype in CL though!

    About iterators, although as the article mentions there are libraries that implement them, in practice (loop :for ... := ...) does the job.

    1. 1

      Hey, I found the links back: https://jorgetavares.com/2010/05/19/original-implementation-of-javascript-in-cl/

      “js/semantics contains experimental code used to generate LR(1) and LALR(1) grammars for JavaScript as well as compile and check formal semantics for JavaScript. The semantics can be executed directly or printed into either HTML or Microsoft Word RTF formats. This code is written in standard Common Lisp. It’s been used under Macintosh Common Lisp 4.0, and Allegro Common Lisp 5.0.1 for Windows, but should also work under other Common Lisp implementations.”

      We still can see sources: https://dxr.mozilla.org/mozilla/source/js2/semantics/

      (taking notes here: https://github.com/vindarel/list-of-languages-implemented-in-lisp/tree/master#javascript)

    2. 19

      So why is CL not more popular ?

      Because the multiplicity of implementations means that the package you need might not be available for your Lisp and some fundamental feature you need simply doesn’t exist.

      Because the standard library is enormous but misses a lot of what the modern user needs. There’s no standard way to do networking in CL, for example. Sure there are third-party and implementation-specific libraries (and good ones) but they’re not just “there”. This only gets worse as the use-case gets more specific: let’s say I want to talk to an IMAP server, retrieve emails, parse them, and then open up a connection to an SMTP server. Python has literally every step of that in the standard library, and numerous third-party implementations of each that all work on the reference implementation of Python (CPython). CL doesn’t.

      Because of the mixed metaphors. CLOS is there, and fantastic (better than anything that came after), but there’s also non-CLOS parts of the standard…and some libraries are OO and some aren’t and some are halfway and so on.

      If you’re writing a truly unprecedented piece of code, something that no library already exists for, then CL is the better language, but the minute you want to do something with an existing system, you’re suddenly looking at a paucity of support that may or may not even work on your system.

      (Note that the slightly angry tone of this comment is out of a…frustrated love. I wish CL had remained at the top, it is a wonderful language. It just didn’t, and I’m disappointed. Maybe things have improved some in recent years? I hope so.)

      1. 10

        As a big user of Common Lisp, I can tell you that most of those don’t end up being problems in real life.

        One of the ideas behind CL is that the language is extensible and the user community can extend it as they see fit. Going with your example of networking, the standard won’t be updated to include it because it can be added by user library. When a library solves a problem well it’ll become popular, get added to QuickLisp, and then it’s available for everybody - no standard update required.

        As you point out, Python’s huge standard library doesn’t offer much benefit over Common Lisp’s way of doing it. Python will often have a suitable library in the stdlib, but also third party libraries to do the same thing in different or better ways. Realistically people should check Pip for a better library before using the one in the standard library. It’s really no different than checking for a library in Quicklisp.

        And then there’s a maintenance cost for implementations to keep alive obsolete libraries like CGI and optparse in Python.

        As far as implementation specific code goes, it’s usually just not a problem. There are “standard but not officially standard” libraries that hide the implementation details in almost every case. trivial-sockets, for example, is the socket networking library that uses macros and inline functions to call into the implementation specific socket libraries.

        1. 5

          So I used CL a fair bit years ago, and Scheme was my preferred extension language for a long time.

          (Ironically, though, I’ve never liked Emacs…)

          The standard-but-not-standard stuff is, IMHO, a problem for people getting into the language….it may not be a problem for experienced users, but approaching the language from the outside you’re going to say “Common Lisp can’t do networking?!?” and then look at Rust/Python/Go and see that all the stuff they want is already there. They’re not going to know about QuickLisp or whatever.

          (Yes, Python has pypi/pip, I know, but you can do an awful lot of “real world, modern” coding in Python before you have to resort to PyPI. Same with Go, etc.)

          The other problem, and like I said this may have changed, is that not everything works for every implementation. I recall CLISP not supporting some sort of library that seemed fairly important, while SBCL did (or vice-versa). So that adds onto the problem of having to choose an implementation on top of choosing a language.

          (Note that it’s not quite the same as C/C++. With those languages, you’re generally using operating-system-provided facilities so the compiler matters less, and the STL is also reasonably comprehensive on top of that.)

          Again, all this is just IMHO.

          (And I’m old enough to remember when you had to roll most of your own stuff regardless of what you were doing…good times, but I’m too old for that now.)

          1. 6

            By this metric C can’t do networking, yet it’s doing OK.

            1. 1

              C can’t do many things compared to Python, at least not easily or well, but can do others. Let’s try to compare apples to apples.

              1. 4

                The point is not C vs Python, is that the claim that C can’t do networking is patently false. And C doesn’t have networking in their standard. Ergo not having networking as part of your standard is not an impediment to have good networking support.

                1. 2

                  C is however more practically important language, and again doing fine without networking in the spec.

                  We can’t compare CL to Python anyway as Python is not standardised.

              2. 5

                The standard-but-not-standard stuff is, IMHO, a problem for people getting into the language….it may not be a problem for experienced users, but approaching the language from the outside you’re going to say “Common Lisp can’t do networking?!?” and then look at Rust/Python/Go and see that all the stuff they want is already there. They’re not going to know about QuickLisp or whatever.

                I don’t think that’s a realistic situation. If a new user is given documentation about the Rust/Python/Go libraries, they can just as easily be given documentation about Common Lisp’s libraries.

                1. 3

                  The standard-but-not-standard stuff is, IMHO, a problem for people getting into the language….it may not be a problem for experienced users, but approaching the language from the outside you’re going to say “Common Lisp can’t do networking?!?” and then look at Rust/Python/Go

                  I would expect new comers to read their implementation’s documentation not saying CL can’t do networking: http://sbcl.org/manual/#Networking That is what I did with Python and Ruby.

                  1. 1

                    The other problem, and like I said this may have changed, is that not everything works for every implementation. I recall CLISP not supporting some sort of library that seemed fairly important, while SBCL did (or vice-versa). So that adds onto the problem of having to choose an implementation on top of choosing a language.

                    This is not a problem. Every modern resource will say: “just install SBCL now”, and nobody recommends CLISP today (although it’s still developped, that could change). De-facto standard libraries are well referenced.

                    I encountered an actor library made for CCL (open source) and another one for LispWorks. That’s the only moment I saw a difference so far.

                    If newcomers find the Cookbook, they’ll be fine :) https://lispcookbook.github.io/cl-cookbook/getting-started.html

                    1. 2

                      nobody recommends CLISP today

                      That makes me sad. CLISP was where I got started with Lisp…

                      1. 2

                        CLISP was unmaintained for the last decade, although it has seen a resurgence in activity in the last few years. CLISP has a great CLI REPL, which is what newcomers will first try to use.

                        1. 1

                          Almost a thing in common. My experiments went from Lisp-in-a-box -> CLISP IIRC. Long time ago, though.

                        2. 1

                          Hey Vincent, nice post on the post and kudos for evangelizing CL while keeping a positive attitude. You rock!

                          1. 1

                            wooo, thanks :)

                    2. 5

                      I mostly agree with the observations you make about CL but disagree with most of the conclusions. The only observation I disagree with is

                      Because the standard library is enormous but misses a lot of what the modern user needs.

                      CL doesn’t have an enormous standard library, which is why, as you mention the standard doesn’t include a lot of the the modern user needs. But that is the job of implementations. SBCL comes with networking, threads, timers, a test framework, mailboxes, an FFI. Commercial implementations such as LispWorks come with even more libraries.

                      The only thing that I constantly wish CL had as part of the standard is built-in sets.

                      There’s no standard way to do networking in CL, for example. Sure there are third-party and implementation-specific libraries (and good ones) but they’re not just “there”

                      That is a commonly raised objection, but it makes no sense to me. Do people program w/o using GCC built-ins? Why would I not consider the documented libraries of my implementation as being there? Recently I’ve writing a Gopher client, the protocol implementation is ~100 LoC on SBCL w/ no dependencies (using sb-bsd-sockets). I didn’t have to go shopping for libraries. Just download the RFC and start hacking!

                      Because of the mixed metaphors

                      It is true that CL has mixed metaphors, different parts of the language have different objectives. But that is a necessity for a general purpose language, especially in one that wants a uniform view of the work. Lisp is a jealous god after all0. Mixed metaphors are not pretty, but they are a thing that CL gets right.

                      looking at a paucity of support

                      If one wants support, Lispworks and Franz are always there, they provide you with a lot of the standard library you asked for.

                      (Note that the slightly angry tone of this comment is out of a…frustrated love.

                      Your comment doesn’t read as angry to me. And there is a lot to be frustrated wrt Lisp’s history. What frustrates me the most is that due to lack of resources and experience reports ‘we’ (Lispers) haven’t been able to move Lisp past CL. One can read Baker’s critique of the DIN Kernel Defintion to see how much CL could be improved for the application programmer (Spoiler for rust fans, it involves linear types). I wish we would have moved past CL. I wish the MOP would be fleshed out more. But alas, all I can do is wish (and program in Lisp of course, it is still a great language today)

                      Quoting below the Jealous God reference because linking to google groups suck

                      You make a good point about the importance of environments. That’s precisely the advantage of Lisp. You get a uniform picture of the world – everything is Lisp. You don’t have to know anything about machine language, assemblers, linkers, and all plethora of itty bitty ‘tools’ with <3-character names. You have the same language for writing macros, the same language for writing system code, the same language for writing scripts, the same language for writing editor extensions, the same language for interacting with windows, etc.

                      Now some would consider this sameness a negative, and with most languages it would be. But with the power of Lisp as an ubiquitous extension language, I don’t have to memorize all sorts of ‘special-purpose languages’, each with different syntax, different naming conventions, different shadowing semantics, different versions of ifthenelse, dowhile, etc.

                      Lisp is the ultimate ‘fractal’ language, because it is good at all levels, from microcode to shell scripts.

                      1. 1

                        “But alas, all I can do is wish (and program in Lisp of course, it is still a great language today)”

                        Nah, it’s Lisp: you can implement the better features and paradigms as macros in CL. Then, get their benefits even while the purpose-built language is still an academic prototype. ;)

                      2. 5

                        I have used CL only for small personal projects but so far I can only agree with @jlarocco that working with QuickLisp has been a very good experience. Libraries are easy to install (at runtime, no reload!) and typically quite reliable. Not everything is well documented but the nature of CL makes it easy to browse around and dig in.

                        Coming from Smalltalk I really started loving CL for its interactive workflow and expressiveness. And I was more than once surprised by the performance of code generated by SBCLs JIT. With all that I would really love to work on a CL project professionally.

                        That said, I think similar to Smalltalk, the versatility of the language is the main inhibitor of success. http://www.winestockwebdesign.com/Essays/Lisp_Curse.html lays it out nicely - a programming language that is standardized, not too crazy, and easy to onboard people to probably fits the needs of larger and large projects better.

                        1. 2

                          Coming from Smalltalk I really started loving CL for its interactive workflow and expressiveness.

                          I thought Smalltalk was the most interactive platform ever O_o

                          With all that I would really love to work on a CL project professionally.

                          thanks to my blogging and other activities I was contacted this year to work for 2 months on a website :) Now, if all goes well, I’ll have an opportunity for six months… so, do stuff, contribute and show it :)

                      3. 2

                        Why not both? I wrote a Lisp for Python: http://github.com/shawwn/pymen

                        (It’s a fork of Lumen and I never got around to updating the README, which is why it seems like it’s only for Lua and JS. But run bin/pymen and it’ll drop you into a REPL.)

                          1. 1

                            Like with Nim, I think a Python-to-X converter could be a good idea to leverage its massive amount of libraries. CL is another option there.

                        1. 1

                          Soooo, what is the good CL to use under Windows? I’m asking because most stuff I see seems geared towards *nix.

                          1. 3

                            Not a Windows user myself.