1. 54

  2. 19

    I can’t find the damn source toot, but someone on the fediverse said “you can’t have too many smart programmers, you need some control rod programmers, or otherwise they just end up making a Lisp”

    1. 8

      I saw it here.

      1. 6

        From the link on GOOL:

        “The GOOL compiler is embedded in Allegro Common Lisp (an ANSI Common Lisp from Franz Inc. which I run on an Silicon Graphics workstation running IRIX).”

        Well, that wouldve probably been a dream setup for me at one point. :)

    2. 15

      C++ got its act together. Java and Perl came along (and later, Python). Meanwhile, Lisp hadn’t advanced much in about a decade (since the ANSI spec was finalized). It was still a win, but the competition had narrowed the field. Once upon a time Lisp had a long list of features that no other language had (GC, full numeric tower, CLOS, incremental development, macros) that list kept getting shorter and shorter, and the case for Lisp, which had never been easy even in the best of times, was getting harder and harder to make.

      I think that this is definitely an issue with Lisp. The core is really, really good; it still has plenty of features that common languages don’t have. But even though it’s more advanced than they are, it’s still stuck in 1994. The median language is a lot better in 2018 than it was in 1994: it’s JavaScript, which is a horrible, terrible, no-good language but still orders of magnitude better than C for software development.

      Lisp is still better: it still has things JavaScript, Python, Java, Ruby, Scala, Erlang & Go are all missing. But it’s not as much better as it used to be, because all of those languages are much more capable than C, assembler & Pascal.

      But then a very strange thing happened: I noticed that all around me people were writing code using C++ and Java and Python and even (gasp!) Perl, and they were actually getting it to work without tearing their hair out. In fact, in a number of cases I saw people whip things up in Perl in a couple of hours that would have taken me days or weeks to do in Lisp.

      I think that’s a factor of batteries being included. Once upon a time Common Lisp was derided for including hash tables: nowadays they are table stakes. Once upon a time people laughed at Common Lisp for being a huge standard; now they laugh at it for not including a web server, let alone standardising sockets.

      The good news is that this is fixable (we can always have a new standard, if we want to go to the effort), and in practice it more-or-less is fixed: Quicklisp provides semi-standard libraries for everything. Would it be nice to have a truly-standardised library equivalent to, say, Go’s? Hell yes. Can we get by with what we have now? Sure.

      I do think that the Lisp world needs to consider a compatibility-breaking Common Lisp 2 at some point. The world has changed a lot in 24 years; it’s time Lisp took note.

      1. 9

        What do you think of other newer age Lisps like Clojure?

        1. 8

          You beat me to it. Ill go straight to saying it seems to solve that very problem with proof being its mainstream status having a big community and plenty of job ads for it. Need more LISP initiatives like that.

          1. 8

            Honestly, I don’t like Clojure — it’s not (IMHO) really a Lisp (among other things, it breaks conses). It’s a neat language, but it’s not my cup of tea. I’d like to see a Lisp continued & carried on, not a break with tradition.

            1. 8

              cons, car, cdr is the least that I miss in clojure, I guess they are a bit too low-level for my taste (and kind of complicated for reading code, although I never had a problem writing them out for some reason).

              What I kind of miss is in Clojure is CLOS, i.e. a multiple dispatch object system.

              1. 3

                I am not familiar with CLOS, but Clojure does have this.

                1. 1

                  Yes, and if it hadn’t this, one could probably write a multiple dispatch system with macros. I guess i could build my own island of multi methods. But that is a little different from an ecosystem that invests in them like Dylan or cl.

                  1. 1

                    I’ve been meaning to try Common Lisp. Things like the condition system, image dumping, CLOS, and MOP seem different from what I know and worth learning. I’m going to try out PAIP. Any insight on what the CL ecosystem tends to do with mutli-dispatch?

          2. 8

            I do think that the Lisp world needs to consider a compatibility-breaking Common Lisp 2 at some point.

            i’d love to see that effort put into optimising the racket runtime and adding libraries to it, personally. i think it has real potential to be an “industrial-strength” langage; the design is already excellent.

            1. 6

              i’d love to see that effort put into optimising the racket runtime and adding libraries to it

              Some work is being done right now to integrate the Chez scheme backend with Racket, which would mean some really nice speed improvements for compiled code.

              1. 3

                The problem with Racket is that it’s very much a Scheme rather than Lisp, with all the mistakes that come with being a Scheme: Lisp-1, #f, (car '()) being an error. It’s an incredibly impressive body of work, but I wish that effort had been expended on Common Lisp instead.

                1. 8

                  wait why shouldn’t that be an error though.

                  1. 4

                    wait why shouldn’t that be an error though.

                    Because it makes writing code which walks through lists a bit simpler. It’s useful that (car nil)nil & (cdr nil)nil. This — like having multiple namespaces — is one of the places where Lisp is more pragmatic than Scheme. I find that quality attractive in a programming language meant to be used.

                    I really wish that I could find a good article about this to share with you. I know that I’ve read one in the past, found the arguments convincing and have had the ‘nil should be carable’ bit set in my head since.

                    1. 7

                      It’s useful that (car nil) → nil & (cdr nil) → nil.

                      That sounds horrible, a recipe for “foo is not a property of undefined”-style errors miles away from where the problem actually occurred. Surely your functions should know what kind of data they expect to be operating on, and fail-fast is not.

                      1. 3

                        Yes that is my view too. Though I think for smal projects bargap’s proposal could be good but as the project grows in size the need for errors to happen close to the source of the problem grows.

                        1. 1

                          It actually works out very well with the sort of code which is written in Lisp. Typically, Lisp systems depend on it.

                          1. 1

                            I’ve found it to be the single largest source of errors in the lisp systems I work with.

                            1. 1

                              Are you writing Lisp or Scheme? If you’re finding it to be a huge source of errors in Scheme, then wouldn’t that tend to support the Common Lisp way of doing things?

                              1. 3

                                I mostly write Clojure and Emacs Lisp, (since 2008 and 2004 respectively) which use nil in the same way Common Lisp does. I don’t have these problems when I write Racket.

                                1. 1

                                  I don’t know Clojure, but I’ll agree elisp is a good basis for comparison. All I can say is that my experience with elisp & Common Lisp differs from your own, and that my experience with Scheme has convinced me that I do not want to write a large system in it — nor use a large system written in it.

                        2. 6

                          Leaving nil out of the language is hands-down my favorite thing about Racket. So many of the problems of CL and Clojure just evaporate completely.

                          1. 6

                            Of course Racket has nil. It’s just written '().

                            1. 6

                              When I say nil here I’m referring to a single value which can mean “emptiness”, “false”, or “not found” depending on the context. Racket has three different values for each of those cases instead of lumping them all into a single value, and that is much less error-prone.

                          2. 2

                            Could you write a car that doesn’t error, Call it care

                    2. 3

                      That reference to Quicklisp made me think about slib

                      I like the idea of having a standard library build only on spec scheme and app’s built with the specific particularities of scheme implementations.

                    3. 10

                      The title is a little dramatic.

                      Despite the self-deprecation, it does sound like they were fixated on this one language and refused to consider others seriously. I’m sure the author could have picked up the other languages, and I’m sure they would have found trade-offs and things to like and not like when compared to LISP and been very good at programming in them too. It’s just that they did not want to.

                      It should more accurately be “I refused to re-tool when companies changed their tech stack”.

                      1. 12

                        He was fixated but did relent eventually. In his own words:

                        What’s more, once I got knocked off my high horse (they had to knock me more than once – if anyone from Google is reading this, I’m sorry) and actually bothered to really study some of these other languges I found myself suddenly becoming more productive in other languages than I was in Lisp. For example, my language of choice for doing Web development now is Python

                        1. 9

                          I agree about the title being dramatic, but Kenny Tilton’s proposal makes for a better headline ^_^

                          “How Lisp Made Me Look Good So I Could Get Hired By A Booming Company and Get Rich Off Options”?


                          J/king aside your point makes sense in the abstract, but can you make it more concrete? Like what trade-offs would they have found in the late 90’s?

                          1. 3

                            Hi, i think it’s there in the article. They found that c++ and python had caught up so I assume they took a look but did not commit, being too enamored of one language. I accept that different languages have tradeoffs but to refuse to use a language others are using productively is not a virtue

                            1. 3

                              They found that c++ and python had caught up

                              That is not how I read it, they saw people being productive on them in spite of it (in their impression).

                              Because I don’t have context/information about the state of lisp implementations vs Java or Python back then I can’t really weigh in about the truth of those statements (From what I’ve heard the GC of free implementations was really slow for example). Even today I struggle to see anything that Python, the language, does better than Lisp. There are other factors that may make it a more sensible option for an organization or even a developer’s perspective (Wealth of libraries) but nothing about the language that seems like a trade-off to me. It is less extensible, slower (CPython vs SBCL) and less interactive.

                          2. 3

                            Seems like he tried, but knowing Lisp by heart makes you more aware about all that PLT stuff (I think) and he considered every other language inferior.

                            You clearly don’t want to work with the tools/languages/concepts which seem to be bad for you, even when companies weren’t enlightened by Holy Lisp paradigms and wanted to use Java instead.

                            1. 1

                              This seems like the attitude he had, but it also seems wrong.

                              Practical use has a very different set of goals from exploration & learning, and the two have values that conflict. So, one should go about them in different ways. (Of course, when you’re learning for work, this is difficult. I don’t recommend it, unless you can convince someone to pay you to learn things correctly!)

                              When you’re learning a new technology, you should focus on doing things the hard way – reinventing square wheels, etc. You should burn the bad parts into your memory. (That way, you know how to avoid them, and you know how to make the best of them when you need to.) The easiest way to do this is to specifically seek out the wrong job for the tool.

                              Once you’ve learned the technology, when you’re on the exploit side of the explore/exploit division (i.e., when somebody has given you a task and a budget), you should be using the right tool for the job.

                              General purpose languages are good-enough tools for many jobs, and lisp was clearly a slightly better tool for all the jobs that his peers were doing in other general purpose languages. But, it’s not like lisp doesn’t have areas where it falls down and requires awkward code. He could have honed his skills even in lisp by focusing on those areas (and then he’d have better tolerance for languages like C, where many more things are awkward.)

                              1. 2

                                One shoukd know what to avoid but seeking out bad tools is an unnecessary, extra step for an experienced dev. I dont need to see 50 ways to experience buffer overflows to know checking buffers by default should be in the language.

                                Likewise, I know a few features like easy metaprogramming and incremental compilation that dramatically boost productivity. Using a language without something similar isnt going to teach me anything other than language author didnt add those features. Now, it might be worthwhile to try one that claims similar benefits with different techniques. That’s not what most job languages are offering, though.

                                One still doesnf havd to learn them grudgingly all the way. They will have useful tools and libraries worth adding to better languages. Redoing them with those languages’ benefits can be fun exercise.

                                1. 5

                                  The way I see it, staying on the happy path while learning leaves you blissfully ignorant of unpublicized downsides and awkward corners. (It’s how you get people using hadoop and a large cluster for problems that are 80x faster with a shell one-liner on one core – they don’t really know what their favorite technology is bad at.) The fact that most professional devs don’t know the ugly corners of their preferred technologies makes learning those corners even more valuable: when backed against a wall & locked into a poor-fitting tech, the person who has put in the effort will know how to get the job done in the cleanest & least effortful way, when all possibilities look equally ugly and painful to the casuals.

                                  This doesn’t mean learning these ugly corners has to be grudging. A good programmer is necessarily a masochist – the salary isn’t worth the work, otherwise. Exploring the worst parts of a language while challenging yourself to learn to be clever with them is lots of fun – when you don’t have a deadline!

                                  Facing the worst parts of a technology head-on also encourages you to figure out ways to fix them. That’s nice for the people who might follow you.

                                  I dont need to see 50 ways to experience buffer overflows to know checking buffers by default should be in the language.

                                  I concede this point, but I think it’s irrelevant. I don’t suggest we dive into uninteresting language flaws (or bother diving deep into languages that are shallow re-skins of ones we already know). But, writing a web server or graphics library in Prolog is a real learning experience; writing a befunge interpreter in brainfuck likewise.

                                  1. 5

                                    I like to learn very different languages so I have a new viewpoint. In Haskell space is function application, in Joy it’s “apply this to the stack”. Unification in Prolog was mind expanding, as well as definite clause grammars. When I find something that’s easy and powerful in one language, and not in another, I try to understand what underlying design and implementation decisions were involved. I’m still fighting with APL, but I’m starting to see the good sides.

                                    I enjoy solving programming katas or advent of code problems in these out of the way languages, there’s so much understanding to gain!

                                    1. 5

                                      good programmer is necessarily a masochist – the salary isn’t worth the work, otherwise.

                                      I think there’s a delicate balance to be struck between knowing the crufty bits of your language (like JSON un/marshaling in Haskell) and spending so much time banging your head against these parts that you become a specialist in the language/environment and refuse to leave its confines. While I’ve definitely met professionals who choose their language based on flashy tours that reduce cruft and constantly reach for different languages without learning the details of one, I also think you shouldn’t outright reject new and different paradigms by getting turtled into a single paradigm.

                                      1. 3

                                        Definitely. If your familiarity with a language prevents you from using a better match, you’ve failed. I think it’s important to be deeply familiar with the ugly bits of a wide variety of very different languages.