21 ms·

The Lisp Curse (2011)

194 points by jlturner 11y ago

lmm 11y ago
Power is a weakness in a programming language, not a strength - some of the most interesting research languages today are not even Turing-complete. It's easy to add expressiveness to a clunky language; it's much harder to add limits to an expressive language that prevent expressing nonsense.
- sklogic 11y ago
  Some really interesting things may happen when you add arbitrarily powerful macros to a bondage and discipline non-Turing-complete language.
  - randcraw 11y ago
    One of them is that, each time you read a new program, you have to learn a new language. Probably no language benefitted / suffered from this more than Lisp.
    - kazinator 11y ago
      Any signficant project in any language has a "dictionary" of custom identifiers, whose vocabulary you have to learn if you want to become a maintainer. The thousand functions in a big C program are just as much a language, as some Lisp macros. The functions all do something. That something isn't "transform the code", but that doesn't matter; if you're looking at the function call and don't know what it does, you're just as lost. Basically, if you're reading Lisp, you go from "outside in" and just assume that everything you see whose definition you are not familiar with is a macro. Well-behaved code follows certain unwritten conventions. For instance, it avoids creating confusion by exhibiting multiple completely independent uses of the same symbols in the same scope. So for instance if we have (frobozz a b) wrapped in a lexical scope where we have (let (a b) ...) in effect, this well-behavedness principle tells us that the a and b symbols in (frobozz a b) refer to these variables. So, we can probably lay aside our suspicion that, for instance, frobozz is redefining some unrelated a in terms of some unrelated b. However, frobozz might be a macro; so we can't cast aside our suspicion that either a or b has its value clobbered. (Same in Pascal or C++, with ordinary functions: frobozz(a, b) could take VAR parameters or references, respectively).
    - eudox 11y ago
      This isn't really the case. Some libraries are all macros, some libraries have no macros, but most have a few macros that quickly fall into general patterns: some macros for setting up and tearing down context safely (with-thing macros), others for iterating some data structure without revealing its internals (do-thing macros), generally simple stuff.
    - sklogic 11y ago
      > One of them is that, each time you read a new program, you have to learn a new language Which is not bad at all. You still have to do it with the programs written in the same language built with different libraries and targeting the different problem domains. In the latter case the language is obscuring the essence of the code. And if you're using a well designed DSL, and you're familiar with the problem domain, it will be readable naturally, just like a pseudocode.
      - lmm 11y ago
        A lot of domain languages need infix operators though. And even if you understand the domain, it's hard to read and refactor code in the presence of unrestricted macros, whereas in a language where such DSLs are implemented via the type system the tooling will understand that.
        Jtsummers 11y ago
        Why do they need infix operators? Most programmers already use prefix notation with function calls. Infix is primarily restricted to mathematical and logical operations, but the prefix (lisp style, taking an arbitrary number of arguments) is pretty clear when written neatly: (and cond1 cond2 cond3) (NB: multiple lines like this would really only be used for a lot of conditions or longer expressions.) We already do something similar with our algol-like languages: if((cond1 || cond2) && (cond3 || cond4) && (cond5 || cond6) && (cond7 || cond8)) In lisp, CL at least, would look like: (if (and (or cond1 cond2) (or cond3 cond4) (or cond5 cond6) (or cond7 cond8))
        lmm 11y ago
        But at that point it's no longer the language of the domain. If you're going to support writing mathematics that looks like the mathematics that mathematicians write then you need infix operators, because mathematics is written with infix operators. Similarly for many other domains.
- kazinator 11y ago
  "Expressive power" and "computational power" aren't the same thing. Turing's original Universal Machine (you know, the moving read/write head over an indefinitely long tape of symbols) is not expressive at all; a simple task like adding two integers on that machine requires a completely arcane, verbose piece of gobbledygook to be prepared on the tape, where you cannot tell at a glance which part of it is the program, and which is the integers to be added. It is less expressive than 4 + 4 in a calculator language that doesn't have loops. Expressive power is, in its barest essence, the freedom to assign an arbitrary meaning, from some domain, to a new combination of symbols, such that every symbol in that combination refers to some entity in that domain only. It behooves us to have a general-purpose language with as much expressive power as we can get our hands on. It is not hard at all to add restrictions in domain languages created inside an expressive language. For instance if you make an x86-64 assembler in Lisp, it will be just as restricted as any other assembler; it will diagnose unrecognized opcodes, bad addressing modes, etc.
  - lmm 11y ago
    > For instance if you make an x86-64 assembler in Lisp, it will be just as restricted as any other assembler; it will diagnose unrecognized opcodes, bad addressing modes, etc. But it won't enforce those things at compilation time in the type system, because it doesn't have one. You might have a macro that checks them, but it would be ad-hoc.
    - kazinator 11y ago
      If I make an assembler in Lisp, compile it and ship it to you so that you can apply it to your assembly language programs, it wouldn't work so well for me to be diagnosing your assembly language problems in my compile time.
      - lmm 11y ago
        I'd prefer a language where I don't have to write a domain language from scratch and write a program that can enforce its rules at runtime. Rather I'd like to be able to express my domain code in the language itself, so that my users don't have to learn (and I don't have to create) a new language. That requires a consistent way of restricting things at compile time, which is very hard to retrofit - if I ever want to be able to enforce that programs don't do certain things, the language needs to not offer unrestricted access to those things.
- davexunit 11y ago
  >Power is a weakness in a programming language, not a strength The truth is that Lisp is not the right language for any particular problem. Rather, Lisp encourages one to attack a new problem by implementing new languages tailored to that problem. Such a language might embody an alternative computational paradigm […] A linguistic approach to design is an essential aspect not only of programming but of engineering design in general. Perhaps that is why Lisp […] still seems new and adaptable, and continues to accommodate current ideas about programming methodology. - Lisp: A language for stratified design http://dspace.mit.edu/bitstream/1721.1/6064/2/AIM-986.pdf http://dspace.mit.edu/bitstream/1721.1/6064/2/AIM-986.pdf
kazinator 11y ago
Replicating "pre-AI-winter" success is like trying to replicate "pre-dot-com" success, et cetera. The past is the past. Such things all depend not on technical reality but on what was the predominant belief among some non-technical decision makers. Old Lisp was funded by institutions. There were so many dialects because multiple institutions were actually developing Lisp using local talent. That required funds, and dispensation of funds requires that someone is rationalizing that dispensation based on some beliefs, and those beliefs are very distant from specific technical ideas like "multiple dispatch is a beneficial in OOP". What remains is that the Lisp design contains numerous elements which are great ideas, which, if they are nicely implemented in their proper form, give you a great programming language. That doesn't translate to being able to return to the time when you're showered with institutional money to just go wild hacking on whatever you like.
nabla9 11y ago
Lisp is programmable programming language, especially Common Lisp. It works as programmer amplifier. Better you are, more you benefit from it. I challenge anyone to watch this lecture from Christian Schafmeister and say they are not impressed: https://www.youtube.com/watch?v=8X69_42Mj-g https://www.youtube.com/watch?v=8X69_42Mj-g and https://www.youtube.com/watch?v=0rSMt1pAlbE https://www.youtube.com/watch?v=0rSMt1pAlbE
- tosseraccount 11y ago
  What popular programs are written in Lisp?
  - eudox 11y ago
    Maxima and pgloader http://maxima.sourceforge.net/ http://maxima.sourceforge.net/ http://pgloader.io/ http://pgloader.io/
    - defgeneric 11y ago
      pgloader (Dimitri Fontaine) is a great piece of software. There's also cl-abnf from the same author and project which is another great example of the expressive power of common lisp. Also, everything Fernando Boretti does is awesome ;) https://github.com/eudoxia0 https://github.com/eudoxia0 http://eudoxia.me/article/common-lisp-sotu-2015/ http://eudoxia.me/article/common-lisp-sotu-2015/ https://github.com/dimitri/cl-abnf https://github.com/dimitri/cl-abnf
  - xrange 11y ago
    A better question: "What impressive programs are written in Lisp?". Or "Why isn't there a Squeak-like Lisp machine environment, where 'compatibility' doesn't have to matter?". If a language is incredibly productive and programmable, why don't we already have a VPRI-like STEPS environment in 20,000 lines? http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf
    - 11y ago
jcfrei 11y ago
previous discussions: https://news.ycombinator.com/item?id=3808194 https://news.ycombinator.com/item?id=3808194 https://news.ycombinator.com/item?id=2450973 https://news.ycombinator.com/item?id=2450973
mbrock 11y ago
I don't think there's much explanatory power here at all, actually. Some of the most popular languages today, from a web development perspective at least, are JavaScript, Ruby, and Clojure. One of them is an actual Lisp with full-blown macros and a lot of Emacs users. The others are also extremely expressive, dynamic, and amenable to metaprogramming. I don't think there's a single, simple, beautiful explanation for why Common Lisp isn't more widely used. Mostly it just has an undeserved bad reputation... partly because articles like this show up all the time, reinforcing the stigma of Lisp as a weird language for bipolar geniuses, or whatever.
- dreish 11y ago
  But one of the most important features of Clojure is that it's hosted on mature, decidedly non-Lisp platforms with plenty of well-maintained libraries, and it has clean, concise interop. If that's what a Lisp needs to become popular, then I'd say that's evidence for this theory, not against it.
- noam87 11y ago
  Agree. I think there is one reason only why lisp/scheme are not mainstream: community. 1. Ruby + Clojurescript have prominent, opinionated community leaders who spend an immense amount of resources on proselytizing and preaching agreed-upon best practices (hell, 90% of Ruby development is done within a framework that all but forces you to write code in a particular, proven way). 2. As for JS: web developers are all forced to use it, which naturally leads to less fragmentation (if Chicken Scheme was the only scripting language available on a UNIX OS, by necessity some libraries would become dominant). Even then, most large enough JS codebases are ghastly. --- Contrast that with Lisp/Scheme. I am now learning scheme, and love the language to point that it's depressing not to get to work in it on a daily basis. That said, the most impenetrable aspect of scheme/lisp is not the language, it's the community: I don't think I'm exaggerating if I say that the entirety of the scheme community (with the exception of racket) is scattered into completely fragmented groups of under 20 individuals, all of whose landing pages look like they were designed in 1993, filled with broken and outdated links; libraries are maintained and abandoned willie-nillie, communication happens mostly in the form of mailing lists... where do I go to watch a talk? where do I read about latest libraries and projects? what are some of the agreed upon best practices? "Read the SRFI" is not documentation (if you can figure out the relevant SRFI in the first place). Example 1: this is the package manager Gambit Scheme recommends http://snow.iro.umontreal.ca/ http://snow.iro.umontreal.ca/ -- a noble attempt at unifying scheme packaging across implementations. DEAD (as far as I can tell). And why? Because each scheme implements its own unique module system, implements its own unique subset of RnRS. Example 2: need an LMDB library? Well, the chicken scheme version is a port of a version that exists only within the LambdaNative framework (which is implemented in a different scheme). Why does it have to be ported? because the two schemes have an incompatible way of handling c-bindings. So one can't just write a library that's R5RS compliant and assume it works across implementations. So we end up with two developers maintaining two versions of the same library, instead of both focusing on the same one. And when one of them decides to start using leveldb on his projects instead? The project is DEAD. (I'm not arguing for a singular implementation of scheme. Part of the beauty of the ecosystem is the variety in implementations suited for different purposes. But so many of the incompatibilities are trivial, and are a community problem, not a technical one. If everyone agreed to implement, say, R7RS-small and better efforts were made to standardise the trivial, like how modules are defined, or how c bindings are to be declared, we could have a central repository of cross-compatible packages.) The problem isn't the language or its power, it's a lack of community building efforts, which makes it extremely frustrating for a newcomer, even one who is absolutely enchanted by the language; and downright prohibitive for a company to bet on scheme. Imagine you are a project manager, would you gamble the success of your company on a language whose libraries, as far as I can tell, almost ALL have a bus factor of 1? tl:dr scheme needs a modern, newcomer-friendly, robust community portal. When there is one link I can give to people where they can find: practical tutorials, lectures, a quick overview of the ecosystem, portable libraries, books and articles full of tips and best practices, charismatic community leaders (who explain things in simple terms that don't scare off the uninitiated, as opposed to trying to convince you how much smarter Lisp programmers are)... then there will be no reason for the language not to be widely used.
kruhft 11y ago
For those that are interested, here's some livecoding streams of me developing and working in a Lisp I'm developing Sigil: https://www.livecoding.tv/burtonsamograd/videos/ https://www.livecoding.tv/burtonsamograd/videos/ See the 'building a language' parts for actual lisp programming, the rest is JS webdev. Sigil is a minimal lisp with only the basic primitives (cons, car, cdr, cond, null, atom, lambda and a few others) and macros. The project is an experiment in building a lisp from the axioms and seeing how far one can go without having to add to the underlying lisp implementation (which is in javascript).
zwieback 11y ago
In 1988 I was an intern at HP Labs and my project was 50% Lisp and 50% C, the latter half dealing with time-critical IO and low-level routines crunching CAD tablet input. At the end of a day working on the Lisp portion, which assembled sketched lines into a CAD model I went home happy and relaxed with a feeling of accomplishment. At the end of the C days I felt tense and slightly worried, thinking about ways of more cleverly detecting what the user was trying to sketch on the tablet. In my 20+ years of programming I never returned to Lisp and I don't quite know why I don't miss it. I have a vague nostalgia for Lisp but I think modern programming languages give us enough tools to get our job done without feeling too much shame about abandoning the purity of Lisp. Also, the proselytizing has not helped. I think the "Blub paradox" article embodies the mindset that was ultimately the nail in Lisp's coffin.
- mwfunk 11y ago
  I had to Google the Blub Paradox (https://en.wikipedia.org/wiki/Paul_Graham_%28computer_programmer%29#The_Blub_paradox https://en.wikipedia.org/wiki/Paul_Graham_%28computer_progra...) but I see what you mean. It's based on the idea that someone who disagrees with you about something can't be acting rationally, rather that they are somehow incapable of perceiving your wisdom. Sometimes that is the case, of course, but I don't think that explains why Lisp isn't the universal language that everyone writes everything in. I have a lot of warm fuzzy feelings about Lisp as well, but a lot of Lisp advocacy has been of the "One True Language" variety as opposed to "right tools for the right job, and here's why Lisp might be the right tool for you". It doesn't affect my perception of Lisp, but it doesn't help market it either.
  - force_reboot 11y ago
    The name doesn't help at all. "Blub" has connotations of bumbling stupidity even without knowing what the "Blub Paradox" is.
draw_down 11y ago
I think this is not properly accounting for the difference between something that's 90% done, and something that is done. (Nothing is ever finished, of course, but you know what I mean.) As we all know, the difference between the two is not simply a gap of 10 percentage points. Far from it. Teams of people were required to write Haskell and Dr Whatshisname tossed off Qi by himself. OK, but people use Haskell, does anyone use Qi? If not, then it's not a problem for Qi to be 90% done. And that's a lot easier to accomplish by oneself.
xrange 11y ago
I wonder why there is all the anguish around why Lisp hasn't flourished, and seemingly less anguish around APL, or even Smalltalk. Is there a reason it engenders so much loyalty? Is it the idea that macros allow you to extend the language, and that seems like the pinnacle of the programming hierarchy? Could there be insight gleaned from looking at programming languages as a fad or style?
- Jtsummers 11y ago
  For me, lisps (CL, scheme, or any other variant) hit a nice sweet spot. You're programming at the AST layer, which makes adding new semantic features (say you wanted erlang style concurrency and message passing) trivial to integrate syntactically (less trivial to implement the underlying feature). Compare this to trying to patch that into C#. Same for any new semantics: logic languages; specific constructs for math, physics, music; OO - see CLOS. APL is less extensible in this regard (to my understanding, someone might prove me wrong). Smalltalk is probably on par, if you can model it with objects and methods/messages cleanly. But in the end, for me, it's the idea of programming the AST directly and being (mostly) freed from arbitrary syntactical constructs.
  - AnimalMuppet 11y ago
    > You're programming at the AST layer, which makes adding new semantic features (say you wanted erlang style concurrency and message passing) trivial to integrate syntactically (less trivial to implement the underlying feature). To me, this hits the nail on the head, for all the wrong reasons. Syntax isn't the problem, implementing the feature is! If I'm writing Lisp code, why do I want it to look like Erlang? What's wrong with it looking like Lisp? ("Erlang style concurrency and message passing" is two things, syntax and functionality. Do you want the functionality? Fine. You want the syntax too? Why?) In fact, this is kind of what the article is about. People want the syntax "their way"; it makes it hard for others to work with their code. The only time you should invent new syntax is when it is impossible (or very hard) to say something in the syntax you've got. "I don't like it" isn't good enough. "It will save me a few keystrokes" isn't good enough.
- 11y ago
jdblair 11y ago
A personal anecdote: I stumbled on LISP and Scheme around the time I graduated from high school in 1991. I became interested in LISP from learning about classic AI research. I found a professor my first year in college who mentored me in an independent study of LISP. I then learned scheme doing a self-study with SICP. Despite all of this, I've never done any paid work in LISP, and I've spent the majority of my career writing C. I can't write a LISP program from scratch from memory any more. However, I've found that the ideas of functional programming and the concept of the read-eval-print loop have colored my understanding of software design in a really positive way. I remember when I learned TCL in the mid 90s it was immediately obvious that TCL is just LISP on strings (read-substitute-print). Lua is also very LISP-like, with tables instead of lists.
arijun 11y ago
Should add a (2011) to the title.
- dang 11y ago
  Added.
cperkins 11y ago
I read the article and thought a lot about it, but I'm not buying it. The acceptance problems for Lisp haven't been because it is "too powerful" or that lone wolf hackers won't work together. The author makes an example of the many Object Oriented (OO) systems, but he performs some bait-and-switch there. Those many OO systems were for _Scheme_, not Common Lisp. And Scheme is intentionally a tiny Lisp. For a long time, Scheme was focused on being the smallest possible Lisp. Common Lisp on the other hand, while it briefly went through an OO experimentation period, really only has one OO system: CLOS. Also, the whole Emacs line is off target too. What has that to do with the expressive power of the language? And why ignore the two extremely powerful commercial Common Lisp IDE's out there? So is the point that Common Lisp isn't successful because there isn't a better free IDE? And the "lone wolf/80%" isn't doing it for me either. The Common Lisp specification was the work of many bright minds and is brilliant. And it stands in complete opposition to the situation the author attempts to describe. I'm not saying that Lisp in general (Scheme, Common Lisp, and Clojure) has been successful, or that Common Lisp in particular has been. If the standard is mindshare and acceptance they have not been successful. There are histories and causes aplenty, but being too powerful is not one of them.
arijun 11y ago
I think that Clojure mitigates these issues quite a bit for a couple reasons: - The core library is has enough built in that many questions are answered using built in solutions (e.g. what is done with objects elsewhere is very frequently done with maps and functions that operate on maps) - The language designer (Rich Hickey) is very opinionated, and the language tends to attract people who agree. There still are multiple choices when it comes to solving some problems (Om vs Reagent vs Rum vs etc.), but is that really that much different than other languages? Javascript has a million choices for the same domain.
jwr 11y ago
I used to read these kinds of articles with interest, back in my Common Lisp programming days. They would worry me. Back in the day, I would even sometimes participate in language advocacy discussions. These days, I don't care at all — I just write great apps that work (fast). Some code runs on the JVM, some code runs in the browser, some runs in both places. I get to use an impressive set of libraries from at least three different ecosystems (Clojure/ClojureScript, Java, Javascript). I get to use fantastic languages with impressive concurrency support. I deliver applications which customers pay money for. For me at least, Clojure made this kind of writing totally obsolete, in the span of several years.
- nickbauman 11y ago
  I've had the same experience but only in isolated places where I could choose the technology. Most of the time, though, I bring up any Lisp and people act like I walked in with dog excrement on my shoes. But these are the same kind of people that are telling me that Golang is going to cure cancer, too so the feeling is mutual.
- jtwebman 11y ago
  I just started learning Clojure and I would agree with you already. It has all the nice parts from other ecosystems and is just fast to do what I need to do.
- raspasov 11y ago
  Can't agree more. I feel like the reason why a lot of Lispers back in the day ended up re-inventing the wheel is not because of Lisp's "dark, seducing power" but simply because the tools and solutions just weren't there yet. For example, if it wasn't for the existing JVM ecosystem of tools and libraries, I would probably end up creating my own undocumented, unportable, bug-ridden implementation of 80% of Netty. Instead, I just use https://github.com/ztellman/aleph https://github.com/ztellman/aleph
  - deleted 11y ago
    [deleted]
- 11y ago
DanielBMarkham 11y ago
I like it. It's a keeper. Also the argument is a bit overstated. "...The moral of this story is that secondary and tertiary effects matter....Employers much prefer that workers be fungible, rather than maximally productive...[in regards to creating a larger framework] The reason why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp hackers would have to cooperate with each other..." So here's what I see. I see a lot of frameworks and libraries composed by folks using other languages. Many of these, yes, are much more complete than one, totally-custom-made solution by some Lisp hacker. And yes, large numbers of people participate in creating and maintaining these larger frameworks and systems. I also see large corporations bleeding cash because they wanted silo'ed, fungible programmers. Got seven architectural tiers, each with its own framework? Hell, you're going to need seven extremely specialized programmers, kid. Time to get on the phone with the recruiter. So they purchase these specialists. All the buzzwords match. The specialists sit down at the magic frameworks, the ones all the cool kids over the last two years have decided to support. Life is good. For about ten minutes. Then something is required that's not in the frameworks. Or the framework is broken under this one particular edge case. Suddenly we need somebody who's general purpose again. Except -- and this is especially nice -- that's not the guy we hired. So seven layers of experts sit struggling with seven oddball issues. Googling Stack Overflow. Hacking the crap out of things. Making a total mess. And at the end of the day, if we're lucky, something ships. Something with little problems here and there that requires seven different areas of expertise to figure out. Plan on maintenance being fun. The next day version 2.0 of the framework on layer 5 ships. Now if you want maintenance programmers, for layer 5 they have to know both version 1.0 and 2.0 More complexity continues. It's fun for everybody. Compare this to the guy who uses a standard language, decades-old libraries, hacks out a partial solution (but good enough to ship) in a few days and then moves on to something else. Now tell me that the framework guys have a better technology development model. I ain't believing it. I'm not saying become a lone wolf and never work with folks. I'm saying that "working with folks" can completely kill any kind of value you're trying to create. Do it wisely.
agumonkey 11y ago
Reading this I wonder if the everybody rewrites everything is that much of an issue. The benefits of it-crowdsourcing capitalized through libraries isn't obvious to me. Some languages make it necessary to distribute the cost of libraries through groups. Maybe Lisp allows to skip that and go straight at the problem. I remember one article about a guy looking at a Graph library for Java. He found two, generic, typed, object and all that; they were more a problem than a solution. He made its own thing in Lisp and called it a day.
Animats 11y ago
This is not the curse of LISP; it's the curse of compile-time macros. Any language extensible at compile time has this problem. C++ has it. (See Boost). Rust seems headed there. You can even do this with C macros. There was, around 1990, a fad for "extensible languages".[1] It died, because the resulting code was so hard to read, with program-specific syntax for each program. Don't go back there. [1] http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf
- sklogic 11y ago
  I really hope that extensible languages are the future. It is unfortunate that a majority of their users had no clue on how to properly extend the languages. It's about a time to fixe it. > resulting code was so hard to read, DSL code is the easiest to read and maintain. No "general purpose" language would ever match this. > with program-specific syntax for each program. As if it's something bad. > Don't go back there. You failed to understand the entire concept.
  - rndmio 11y ago
    > You failed to understand the entire concept. I don't think so. As the article states, this is a social/community issue, if every application has it's own language and syntax that is a huge barrier for others coming to work on it. You might not care about that but most large pieces of software are not written by one person. Beyond that you come to issues of code and skill reuse. A lot of people dislike the expressibility of Go, but it's hard to write code that someone else can't easily come and read and understand.
    - sklogic 11y ago
      > As the article states The article is plain wrong. > if every application has it's own language and syntax that is a huge barrier for others coming to work on it And this is quite obviously not true. A well designed (note the emphasis!) DSL makes any app/problem domain/library/whatever much more accessible than any kind of a "general purpose" language can. Simply because DSL does not obscure the essence of the problem. > Beyond that you come to issues of code Code reuse with DSLs is way beyond anything the inferior languages can achieve. I witnessed cases where 30+ years old DSLs got revived by reimplementing them from scratch, immediately making an entire (huge) code base available on a new platform, with new tools and bells and whistles. > and skill reuse. One should never care about those pitiful "language" skills. They're worthless.
bch 11y ago
"BBM" == Brilliant Bipolar Mind. The acronym is used in "The Lisp Curse" citation of The Bipolar Lisp Programmer, but defined elsewhere in material not cited.
diogofranco 11y ago
There are many good points in this article and even the variety of Common Lisp implementations in existence attest to the author's point. It seems that everyone is rolling out their whole new CL implementation. That said, even if it were true that the power of lisp turned out to be it's curse, one should be careful to generalize this way about lisp hackers, 80% projects and lack of documentation. The language might tempt you to become the hacker portrayed in this article, but it certainly doesn't fight you should you want to follow best practices.
- pareidolia 11y ago
  Having multiple implementations wasn't a problem for Java (Sun JDK, IcedTea, JRockit), noone thinks much of the different compilers available for the C family (GCC, CLANG, Microsoft C compiler, Intel's C compiler), consider Ruby with MRI, JRuby, or Python. I could go on. Members of the Lisp family seem to be judged by a different standard. I don't know why that is. My perspective: the implementations attest to good documentation and collaboration. SBCL by itself is an admirable artifact with extensive documentation that's been maintaned since 1999 (when it forked from CMUCL). So what gives?
chetanahuja 11y ago
"It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere." Oh is it time already for another "C is for idiots" thread from Lisp supremacists again? If Lisp fanboiz were slightly less busy ridiculing the rest of the world over how stupid everyone else is, they might even have had some time to pay attention to silly things like performance and tooling. That might help the adoption a bit more than the supercilious rock throwing that is almost exclusively the tone of every single article/post from Lisp lovers.
- raspasov 11y ago
  C is the king of raw performance, there's no denying that. But for the vast majority of high-level, user-facing applications today it's a bad fit. Clojure is more than fast enough for serious server side programming, often coming close to Java in performance with minimum amount of tuning needed in the average case. When you add multithreading into the mix, it's not even a contest; the amount of time you'll have to spend to make an idiomatic Java or C++ run both correctly and fast is gargantuan compared to a language where concurrency was built-in from the start.
PaulHoule 11y ago
The homoiconic thing is not all it is made up to be. That is, you can take (say) Java and parse it to an abstract syntax tree and the manipulate the tree. Assuming you have a good toolbox of operators, working with that kind of AST is not much harder than working with s expressions. Maybe it is easier if you can build a general notation that can be generalized for multiple languages and also represent more ordinary data such as json formatted, relational, rdf, etc.
- AnimalMuppet 11y ago
  Yes, but parsing Java into an AST is much harder than parsing S-expressions into an AST...
- retrogradeorbit 11y ago
  I couldn't disagree more. Working with that kind of AST is many orders of magnitude harder than Lisp macros. None of it is first class. You brush over it in your comment like writing a Java parser is trivial. My clojure parser returning the AST in its entirety is: (read-string (slurp "my-source.clj")). What does your Java one look like? The proof that it is so much harder is that no one ever does it. Yet people do this all the time in Lisps. If its "not much harder" I'd expect to see more of it, but I don't, because it is just so much work. Aside from parsing, what about templating. Yes, you can manipulate the AST once you have it, but what would templating AST look like? Would it look just like the Java code? With the syntax quote in clojure it looks very much like the output. How would you even begin to template syntax in your hypothetical Java implementation?
  - PaulHoule 11y ago
    1. I am not writing a parser, one already exists and can be brought in about as easy as your code sample. 2. I am translating the AST to rdf which lets me work on the AST with production rules 3. If I wanted templates I would use templates. What I do do is start out with an abstract representation and then apply say 20 simple transformations that step by step fill in the details to get to code. Speed is OK because we have indexes, rete networks and other tricks. 4. People are not doing it yet and this is why people are saying code reuse is hard, etc. 5. The transformations are written in a sparql derived rule format that itself uses the transformation system to add features by composition.
winestock 11y ago
I'm the author of this essay. This must be at least the third time that it has appeared on Hacker News. I'm starting to get sick of it, myself, but I keep it up because so many people like it (at the bottom of the page, you can see the translations; all done gratis by volunteers). I wrote it during a period when I was especially fascinated with Lisp and got caught up in the theorizing to which the Lisp community can be prone. Nowadays, I freelance in front-end web development and doing Lisp hacking is something that I put on the back-burner.
- Scarbutt 11y ago
  so you just use javascript? I'm in that period of fascination, any practical advice? ;)
  - winestock 11y ago
    For now, yes. My life has taken some unexpected detours, these past few years, so I have to focus on work rather than inspiration.
    - pareidolia 11y ago
      Have you ever put (any, as in CL, Scheme etc.) Lisp into practice? I got the impression from the essay that you think that everything in a Lisp consists of macros, which is not the case.
bitwize 11y ago
People who care what other people think about the programming languages they use write essays like this. The rest of us just shut up and hack some Lisp.
justnotforme 11y ago
A lot of thoughts about lisp; are written by zealots; who like to create the impression that they are playing with some kind of dangerous mind amplifying meta language; and if you start using it; you might accidentally unleash creatures from the id. But then you look at it; and find it is simply a programming language.

194 points by jlturner 11y ago

lmm 11y ago

Power is a weakness in a programming language, not a strength - some of the most interesting research languages today are not even Turing-complete. It's easy to add expressiveness to a clunky language; it's much harder to add limits to an expressive language that prevent expressing nonsense.

sklogic 11y ago
Some really interesting things may happen when you add arbitrarily powerful macros to a bondage and discipline non-Turing-complete language.
- randcraw 11y ago
  One of them is that, each time you read a new program, you have to learn a new language. Probably no language benefitted / suffered from this more than Lisp.
  - kazinator 11y ago
    Any signficant project in any language has a "dictionary" of custom identifiers, whose vocabulary you have to learn if you want to become a maintainer. The thousand functions in a big C program are just as much a language, as some Lisp macros. The functions all do something. That something isn't "transform the code", but that doesn't matter; if you're looking at the function call and don't know what it does, you're just as lost. Basically, if you're reading Lisp, you go from "outside in" and just assume that everything you see whose definition you are not familiar with is a macro. Well-behaved code follows certain unwritten conventions. For instance, it avoids creating confusion by exhibiting multiple completely independent uses of the same symbols in the same scope. So for instance if we have (frobozz a b) wrapped in a lexical scope where we have (let (a b) ...) in effect, this well-behavedness principle tells us that the a and b symbols in (frobozz a b) refer to these variables. So, we can probably lay aside our suspicion that, for instance, frobozz is redefining some unrelated a in terms of some unrelated b. However, frobozz might be a macro; so we can't cast aside our suspicion that either a or b has its value clobbered. (Same in Pascal or C++, with ordinary functions: frobozz(a, b) could take VAR parameters or references, respectively).
  - eudox 11y ago
    This isn't really the case. Some libraries are all macros, some libraries have no macros, but most have a few macros that quickly fall into general patterns: some macros for setting up and tearing down context safely (with-thing macros), others for iterating some data structure without revealing its internals (do-thing macros), generally simple stuff.
  - sklogic 11y ago
    > One of them is that, each time you read a new program, you have to learn a new language Which is not bad at all. You still have to do it with the programs written in the same language built with different libraries and targeting the different problem domains. In the latter case the language is obscuring the essence of the code. And if you're using a well designed DSL, and you're familiar with the problem domain, it will be readable naturally, just like a pseudocode.
    - lmm 11y ago
      A lot of domain languages need infix operators though. And even if you understand the domain, it's hard to read and refactor code in the presence of unrestricted macros, whereas in a language where such DSLs are implemented via the type system the tooling will understand that.
      - Jtsummers 11y ago
        Why do they need infix operators? Most programmers already use prefix notation with function calls. Infix is primarily restricted to mathematical and logical operations, but the prefix (lisp style, taking an arbitrary number of arguments) is pretty clear when written neatly: (and cond1 cond2 cond3) (NB: multiple lines like this would really only be used for a lot of conditions or longer expressions.) We already do something similar with our algol-like languages: if((cond1 || cond2) && (cond3 || cond4) && (cond5 || cond6) && (cond7 || cond8)) In lisp, CL at least, would look like: (if (and (or cond1 cond2) (or cond3 cond4) (or cond5 cond6) (or cond7 cond8))
        lmm 11y ago
        But at that point it's no longer the language of the domain. If you're going to support writing mathematics that looks like the mathematics that mathematicians write then you need infix operators, because mathematics is written with infix operators. Similarly for many other domains.
kazinator 11y ago
"Expressive power" and "computational power" aren't the same thing. Turing's original Universal Machine (you know, the moving read/write head over an indefinitely long tape of symbols) is not expressive at all; a simple task like adding two integers on that machine requires a completely arcane, verbose piece of gobbledygook to be prepared on the tape, where you cannot tell at a glance which part of it is the program, and which is the integers to be added. It is less expressive than 4 + 4 in a calculator language that doesn't have loops. Expressive power is, in its barest essence, the freedom to assign an arbitrary meaning, from some domain, to a new combination of symbols, such that every symbol in that combination refers to some entity in that domain only. It behooves us to have a general-purpose language with as much expressive power as we can get our hands on. It is not hard at all to add restrictions in domain languages created inside an expressive language. For instance if you make an x86-64 assembler in Lisp, it will be just as restricted as any other assembler; it will diagnose unrecognized opcodes, bad addressing modes, etc.
- lmm 11y ago
  > For instance if you make an x86-64 assembler in Lisp, it will be just as restricted as any other assembler; it will diagnose unrecognized opcodes, bad addressing modes, etc. But it won't enforce those things at compilation time in the type system, because it doesn't have one. You might have a macro that checks them, but it would be ad-hoc.
  - kazinator 11y ago
    If I make an assembler in Lisp, compile it and ship it to you so that you can apply it to your assembly language programs, it wouldn't work so well for me to be diagnosing your assembly language problems in my compile time.
    - lmm 11y ago
      I'd prefer a language where I don't have to write a domain language from scratch and write a program that can enforce its rules at runtime. Rather I'd like to be able to express my domain code in the language itself, so that my users don't have to learn (and I don't have to create) a new language. That requires a consistent way of restricting things at compile time, which is very hard to retrofit - if I ever want to be able to enforce that programs don't do certain things, the language needs to not offer unrestricted access to those things.
davexunit 11y ago
>Power is a weakness in a programming language, not a strength The truth is that Lisp is not the right language for any particular problem. Rather, Lisp encourages one to attack a new problem by implementing new languages tailored to that problem. Such a language might embody an alternative computational paradigm […] A linguistic approach to design is an essential aspect not only of programming but of engineering design in general. Perhaps that is why Lisp […] still seems new and adaptable, and continues to accommodate current ideas about programming methodology. - Lisp: A language for stratified design http://dspace.mit.edu/bitstream/1721.1/6064/2/AIM-986.pdf http://dspace.mit.edu/bitstream/1721.1/6064/2/AIM-986.pdf

kazinator 11y ago

Replicating "pre-AI-winter" success is like trying to replicate "pre-dot-com" success, et cetera. The past is the past. Such things all depend not on technical reality but on what was the predominant belief among some non-technical decision makers. Old Lisp was funded by institutions. There were so many dialects because multiple institutions were actually developing Lisp using local talent. That required funds, and dispensation of funds requires that someone is rationalizing that dispensation based on some beliefs, and those beliefs are very distant from specific technical ideas like "multiple dispatch is a beneficial in OOP". What remains is that the Lisp design contains numerous elements which are great ideas, which, if they are nicely implemented in their proper form, give you a great programming language. That doesn't translate to being able to return to the time when you're showered with institutional money to just go wild hacking on whatever you like.

nabla9 11y ago

Lisp is programmable programming language, especially Common Lisp. It works as programmer amplifier. Better you are, more you benefit from it. I challenge anyone to watch this lecture from Christian Schafmeister and say they are not impressed: https://www.youtube.com/watch?v=8X69_42Mj-g https://www.youtube.com/watch?v=8X69_42Mj-g and https://www.youtube.com/watch?v=0rSMt1pAlbE https://www.youtube.com/watch?v=0rSMt1pAlbE

tosseraccount 11y ago
What popular programs are written in Lisp?
- eudox 11y ago
  Maxima and pgloader http://maxima.sourceforge.net/ http://maxima.sourceforge.net/ http://pgloader.io/ http://pgloader.io/
  - defgeneric 11y ago
    pgloader (Dimitri Fontaine) is a great piece of software. There's also cl-abnf from the same author and project which is another great example of the expressive power of common lisp. Also, everything Fernando Boretti does is awesome ;) https://github.com/eudoxia0 https://github.com/eudoxia0 http://eudoxia.me/article/common-lisp-sotu-2015/ http://eudoxia.me/article/common-lisp-sotu-2015/ https://github.com/dimitri/cl-abnf https://github.com/dimitri/cl-abnf
- xrange 11y ago
  A better question: "What impressive programs are written in Lisp?". Or "Why isn't there a Squeak-like Lisp machine environment, where 'compatibility' doesn't have to matter?". If a language is incredibly productive and programmable, why don't we already have a VPRI-like STEPS environment in 20,000 lines? http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf
  - 11y ago

jcfrei 11y ago

previous discussions: https://news.ycombinator.com/item?id=3808194 https://news.ycombinator.com/item?id=3808194 https://news.ycombinator.com/item?id=2450973 https://news.ycombinator.com/item?id=2450973

mbrock 11y ago

I don't think there's much explanatory power here at all, actually. Some of the most popular languages today, from a web development perspective at least, are JavaScript, Ruby, and Clojure. One of them is an actual Lisp with full-blown macros and a lot of Emacs users. The others are also extremely expressive, dynamic, and amenable to metaprogramming. I don't think there's a single, simple, beautiful explanation for why Common Lisp isn't more widely used. Mostly it just has an undeserved bad reputation... partly because articles like this show up all the time, reinforcing the stigma of Lisp as a weird language for bipolar geniuses, or whatever.

dreish 11y ago
But one of the most important features of Clojure is that it's hosted on mature, decidedly non-Lisp platforms with plenty of well-maintained libraries, and it has clean, concise interop. If that's what a Lisp needs to become popular, then I'd say that's evidence for this theory, not against it.
noam87 11y ago
Agree. I think there is one reason only why lisp/scheme are not mainstream: community. 1. Ruby + Clojurescript have prominent, opinionated community leaders who spend an immense amount of resources on proselytizing and preaching agreed-upon best practices (hell, 90% of Ruby development is done within a framework that all but forces you to write code in a particular, proven way). 2. As for JS: web developers are all forced to use it, which naturally leads to less fragmentation (if Chicken Scheme was the only scripting language available on a UNIX OS, by necessity some libraries would become dominant). Even then, most large enough JS codebases are ghastly. --- Contrast that with Lisp/Scheme. I am now learning scheme, and love the language to point that it's depressing not to get to work in it on a daily basis. That said, the most impenetrable aspect of scheme/lisp is not the language, it's the community: I don't think I'm exaggerating if I say that the entirety of the scheme community (with the exception of racket) is scattered into completely fragmented groups of under 20 individuals, all of whose landing pages look like they were designed in 1993, filled with broken and outdated links; libraries are maintained and abandoned willie-nillie, communication happens mostly in the form of mailing lists... where do I go to watch a talk? where do I read about latest libraries and projects? what are some of the agreed upon best practices? "Read the SRFI" is not documentation (if you can figure out the relevant SRFI in the first place). Example 1: this is the package manager Gambit Scheme recommends http://snow.iro.umontreal.ca/ http://snow.iro.umontreal.ca/ -- a noble attempt at unifying scheme packaging across implementations. DEAD (as far as I can tell). And why? Because each scheme implements its own unique module system, implements its own unique subset of RnRS. Example 2: need an LMDB library? Well, the chicken scheme version is a port of a version that exists only within the LambdaNative framework (which is implemented in a different scheme). Why does it have to be ported? because the two schemes have an incompatible way of handling c-bindings. So one can't just write a library that's R5RS compliant and assume it works across implementations. So we end up with two developers maintaining two versions of the same library, instead of both focusing on the same one. And when one of them decides to start using leveldb on his projects instead? The project is DEAD. (I'm not arguing for a singular implementation of scheme. Part of the beauty of the ecosystem is the variety in implementations suited for different purposes. But so many of the incompatibilities are trivial, and are a community problem, not a technical one. If everyone agreed to implement, say, R7RS-small and better efforts were made to standardise the trivial, like how modules are defined, or how c bindings are to be declared, we could have a central repository of cross-compatible packages.) The problem isn't the language or its power, it's a lack of community building efforts, which makes it extremely frustrating for a newcomer, even one who is absolutely enchanted by the language; and downright prohibitive for a company to bet on scheme. Imagine you are a project manager, would you gamble the success of your company on a language whose libraries, as far as I can tell, almost ALL have a bus factor of 1? tl:dr scheme needs a modern, newcomer-friendly, robust community portal. When there is one link I can give to people where they can find: practical tutorials, lectures, a quick overview of the ecosystem, portable libraries, books and articles full of tips and best practices, charismatic community leaders (who explain things in simple terms that don't scare off the uninitiated, as opposed to trying to convince you how much smarter Lisp programmers are)... then there will be no reason for the language not to be widely used.

kruhft 11y ago

For those that are interested, here's some livecoding streams of me developing and working in a Lisp I'm developing Sigil: https://www.livecoding.tv/burtonsamograd/videos/ https://www.livecoding.tv/burtonsamograd/videos/ See the 'building a language' parts for actual lisp programming, the rest is JS webdev. Sigil is a minimal lisp with only the basic primitives (cons, car, cdr, cond, null, atom, lambda and a few others) and macros. The project is an experiment in building a lisp from the axioms and seeing how far one can go without having to add to the underlying lisp implementation (which is in javascript).

zwieback 11y ago

In 1988 I was an intern at HP Labs and my project was 50% Lisp and 50% C, the latter half dealing with time-critical IO and low-level routines crunching CAD tablet input. At the end of a day working on the Lisp portion, which assembled sketched lines into a CAD model I went home happy and relaxed with a feeling of accomplishment. At the end of the C days I felt tense and slightly worried, thinking about ways of more cleverly detecting what the user was trying to sketch on the tablet. In my 20+ years of programming I never returned to Lisp and I don't quite know why I don't miss it. I have a vague nostalgia for Lisp but I think modern programming languages give us enough tools to get our job done without feeling too much shame about abandoning the purity of Lisp. Also, the proselytizing has not helped. I think the "Blub paradox" article embodies the mindset that was ultimately the nail in Lisp's coffin.

mwfunk 11y ago
I had to Google the Blub Paradox (https://en.wikipedia.org/wiki/Paul_Graham_%28computer_programmer%29#The_Blub_paradox https://en.wikipedia.org/wiki/Paul_Graham_%28computer_progra...) but I see what you mean. It's based on the idea that someone who disagrees with you about something can't be acting rationally, rather that they are somehow incapable of perceiving your wisdom. Sometimes that is the case, of course, but I don't think that explains why Lisp isn't the universal language that everyone writes everything in. I have a lot of warm fuzzy feelings about Lisp as well, but a lot of Lisp advocacy has been of the "One True Language" variety as opposed to "right tools for the right job, and here's why Lisp might be the right tool for you". It doesn't affect my perception of Lisp, but it doesn't help market it either.
- force_reboot 11y ago
  The name doesn't help at all. "Blub" has connotations of bumbling stupidity even without knowing what the "Blub Paradox" is.

draw_down 11y ago

I think this is not properly accounting for the difference between something that's 90% done, and something that is done. (Nothing is ever finished, of course, but you know what I mean.) As we all know, the difference between the two is not simply a gap of 10 percentage points. Far from it. Teams of people were required to write Haskell and Dr Whatshisname tossed off Qi by himself. OK, but people use Haskell, does anyone use Qi? If not, then it's not a problem for Qi to be 90% done. And that's a lot easier to accomplish by oneself.

xrange 11y ago

I wonder why there is all the anguish around why Lisp hasn't flourished, and seemingly less anguish around APL, or even Smalltalk. Is there a reason it engenders so much loyalty? Is it the idea that macros allow you to extend the language, and that seems like the pinnacle of the programming hierarchy? Could there be insight gleaned from looking at programming languages as a fad or style?

Jtsummers 11y ago
For me, lisps (CL, scheme, or any other variant) hit a nice sweet spot. You're programming at the AST layer, which makes adding new semantic features (say you wanted erlang style concurrency and message passing) trivial to integrate syntactically (less trivial to implement the underlying feature). Compare this to trying to patch that into C#. Same for any new semantics: logic languages; specific constructs for math, physics, music; OO - see CLOS. APL is less extensible in this regard (to my understanding, someone might prove me wrong). Smalltalk is probably on par, if you can model it with objects and methods/messages cleanly. But in the end, for me, it's the idea of programming the AST directly and being (mostly) freed from arbitrary syntactical constructs.
- AnimalMuppet 11y ago
  > You're programming at the AST layer, which makes adding new semantic features (say you wanted erlang style concurrency and message passing) trivial to integrate syntactically (less trivial to implement the underlying feature). To me, this hits the nail on the head, for all the wrong reasons. Syntax isn't the problem, implementing the feature is! If I'm writing Lisp code, why do I want it to look like Erlang? What's wrong with it looking like Lisp? ("Erlang style concurrency and message passing" is two things, syntax and functionality. Do you want the functionality? Fine. You want the syntax too? Why?) In fact, this is kind of what the article is about. People want the syntax "their way"; it makes it hard for others to work with their code. The only time you should invent new syntax is when it is impossible (or very hard) to say something in the syntax you've got. "I don't like it" isn't good enough. "It will save me a few keystrokes" isn't good enough.
11y ago

jdblair 11y ago

A personal anecdote: I stumbled on LISP and Scheme around the time I graduated from high school in 1991. I became interested in LISP from learning about classic AI research. I found a professor my first year in college who mentored me in an independent study of LISP. I then learned scheme doing a self-study with SICP. Despite all of this, I've never done any paid work in LISP, and I've spent the majority of my career writing C. I can't write a LISP program from scratch from memory any more. However, I've found that the ideas of functional programming and the concept of the read-eval-print loop have colored my understanding of software design in a really positive way. I remember when I learned TCL in the mid 90s it was immediately obvious that TCL is just LISP on strings (read-substitute-print). Lua is also very LISP-like, with tables instead of lists.

arijun 11y ago

Should add a (2011) to the title.

dang 11y ago
Added.

cperkins 11y ago

I read the article and thought a lot about it, but I'm not buying it. The acceptance problems for Lisp haven't been because it is "too powerful" or that lone wolf hackers won't work together. The author makes an example of the many Object Oriented (OO) systems, but he performs some bait-and-switch there. Those many OO systems were for _Scheme_, not Common Lisp. And Scheme is intentionally a tiny Lisp. For a long time, Scheme was focused on being the smallest possible Lisp. Common Lisp on the other hand, while it briefly went through an OO experimentation period, really only has one OO system: CLOS. Also, the whole Emacs line is off target too. What has that to do with the expressive power of the language? And why ignore the two extremely powerful commercial Common Lisp IDE's out there? So is the point that Common Lisp isn't successful because there isn't a better free IDE? And the "lone wolf/80%" isn't doing it for me either. The Common Lisp specification was the work of many bright minds and is brilliant. And it stands in complete opposition to the situation the author attempts to describe. I'm not saying that Lisp in general (Scheme, Common Lisp, and Clojure) has been successful, or that Common Lisp in particular has been. If the standard is mindshare and acceptance they have not been successful. There are histories and causes aplenty, but being too powerful is not one of them.

arijun 11y ago

I think that Clojure mitigates these issues quite a bit for a couple reasons: - The core library is has enough built in that many questions are answered using built in solutions (e.g. what is done with objects elsewhere is very frequently done with maps and functions that operate on maps) - The language designer (Rich Hickey) is very opinionated, and the language tends to attract people who agree. There still are multiple choices when it comes to solving some problems (Om vs Reagent vs Rum vs etc.), but is that really that much different than other languages? Javascript has a million choices for the same domain.

jwr 11y ago

I used to read these kinds of articles with interest, back in my Common Lisp programming days. They would worry me. Back in the day, I would even sometimes participate in language advocacy discussions. These days, I don't care at all — I just write great apps that work (fast). Some code runs on the JVM, some code runs in the browser, some runs in both places. I get to use an impressive set of libraries from at least three different ecosystems (Clojure/ClojureScript, Java, Javascript). I get to use fantastic languages with impressive concurrency support. I deliver applications which customers pay money for. For me at least, Clojure made this kind of writing totally obsolete, in the span of several years.

nickbauman 11y ago
I've had the same experience but only in isolated places where I could choose the technology. Most of the time, though, I bring up any Lisp and people act like I walked in with dog excrement on my shoes. But these are the same kind of people that are telling me that Golang is going to cure cancer, too so the feeling is mutual.
jtwebman 11y ago
I just started learning Clojure and I would agree with you already. It has all the nice parts from other ecosystems and is just fast to do what I need to do.
raspasov 11y ago
Can't agree more. I feel like the reason why a lot of Lispers back in the day ended up re-inventing the wheel is not because of Lisp's "dark, seducing power" but simply because the tools and solutions just weren't there yet. For example, if it wasn't for the existing JVM ecosystem of tools and libraries, I would probably end up creating my own undocumented, unportable, bug-ridden implementation of 80% of Netty. Instead, I just use https://github.com/ztellman/aleph https://github.com/ztellman/aleph
- deleted 11y ago
  [deleted]
11y ago

DanielBMarkham 11y ago

I like it. It's a keeper. Also the argument is a bit overstated. "...The moral of this story is that secondary and tertiary effects matter....Employers much prefer that workers be fungible, rather than maximally productive...[in regards to creating a larger framework] The reason why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp hackers would have to cooperate with each other..." So here's what I see. I see a lot of frameworks and libraries composed by folks using other languages. Many of these, yes, are much more complete than one, totally-custom-made solution by some Lisp hacker. And yes, large numbers of people participate in creating and maintaining these larger frameworks and systems. I also see large corporations bleeding cash because they wanted silo'ed, fungible programmers. Got seven architectural tiers, each with its own framework? Hell, you're going to need seven extremely specialized programmers, kid. Time to get on the phone with the recruiter. So they purchase these specialists. All the buzzwords match. The specialists sit down at the magic frameworks, the ones all the cool kids over the last two years have decided to support. Life is good. For about ten minutes. Then something is required that's not in the frameworks. Or the framework is broken under this one particular edge case. Suddenly we need somebody who's general purpose again. Except -- and this is especially nice -- that's not the guy we hired. So seven layers of experts sit struggling with seven oddball issues. Googling Stack Overflow. Hacking the crap out of things. Making a total mess. And at the end of the day, if we're lucky, something ships. Something with little problems here and there that requires seven different areas of expertise to figure out. Plan on maintenance being fun. The next day version 2.0 of the framework on layer 5 ships. Now if you want maintenance programmers, for layer 5 they have to know both version 1.0 and 2.0 More complexity continues. It's fun for everybody. Compare this to the guy who uses a standard language, decades-old libraries, hacks out a partial solution (but good enough to ship) in a few days and then moves on to something else. Now tell me that the framework guys have a better technology development model. I ain't believing it. I'm not saying become a lone wolf and never work with folks. I'm saying that "working with folks" can completely kill any kind of value you're trying to create. Do it wisely.

agumonkey 11y ago

Reading this I wonder if the everybody rewrites everything is that much of an issue. The benefits of it-crowdsourcing capitalized through libraries isn't obvious to me. Some languages make it necessary to distribute the cost of libraries through groups. Maybe Lisp allows to skip that and go straight at the problem. I remember one article about a guy looking at a Graph library for Java. He found two, generic, typed, object and all that; they were more a problem than a solution. He made its own thing in Lisp and called it a day.

Animats 11y ago

This is not the curse of LISP; it's the curse of compile-time macros. Any language extensible at compile time has this problem. C++ has it. (See Boost). Rust seems headed there. You can even do this with C macros. There was, around 1990, a fad for "extensible languages".[1] It died, because the resulting code was so hard to read, with program-specific syntax for each program. Don't go back there. [1] http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf

sklogic 11y ago
I really hope that extensible languages are the future. It is unfortunate that a majority of their users had no clue on how to properly extend the languages. It's about a time to fixe it. > resulting code was so hard to read, DSL code is the easiest to read and maintain. No "general purpose" language would ever match this. > with program-specific syntax for each program. As if it's something bad. > Don't go back there. You failed to understand the entire concept.
- rndmio 11y ago
  > You failed to understand the entire concept. I don't think so. As the article states, this is a social/community issue, if every application has it's own language and syntax that is a huge barrier for others coming to work on it. You might not care about that but most large pieces of software are not written by one person. Beyond that you come to issues of code and skill reuse. A lot of people dislike the expressibility of Go, but it's hard to write code that someone else can't easily come and read and understand.
  - sklogic 11y ago
    > As the article states The article is plain wrong. > if every application has it's own language and syntax that is a huge barrier for others coming to work on it And this is quite obviously not true. A well designed (note the emphasis!) DSL makes any app/problem domain/library/whatever much more accessible than any kind of a "general purpose" language can. Simply because DSL does not obscure the essence of the problem. > Beyond that you come to issues of code Code reuse with DSLs is way beyond anything the inferior languages can achieve. I witnessed cases where 30+ years old DSLs got revived by reimplementing them from scratch, immediately making an entire (huge) code base available on a new platform, with new tools and bells and whistles. > and skill reuse. One should never care about those pitiful "language" skills. They're worthless.

bch 11y ago

"BBM" == Brilliant Bipolar Mind. The acronym is used in "The Lisp Curse" citation of The Bipolar Lisp Programmer, but defined elsewhere in material not cited.

diogofranco 11y ago

There are many good points in this article and even the variety of Common Lisp implementations in existence attest to the author's point. It seems that everyone is rolling out their whole new CL implementation. That said, even if it were true that the power of lisp turned out to be it's curse, one should be careful to generalize this way about lisp hackers, 80% projects and lack of documentation. The language might tempt you to become the hacker portrayed in this article, but it certainly doesn't fight you should you want to follow best practices.

pareidolia 11y ago
Having multiple implementations wasn't a problem for Java (Sun JDK, IcedTea, JRockit), noone thinks much of the different compilers available for the C family (GCC, CLANG, Microsoft C compiler, Intel's C compiler), consider Ruby with MRI, JRuby, or Python. I could go on. Members of the Lisp family seem to be judged by a different standard. I don't know why that is. My perspective: the implementations attest to good documentation and collaboration. SBCL by itself is an admirable artifact with extensive documentation that's been maintaned since 1999 (when it forked from CMUCL). So what gives?

chetanahuja 11y ago

"It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere." Oh is it time already for another "C is for idiots" thread from Lisp supremacists again? If Lisp fanboiz were slightly less busy ridiculing the rest of the world over how stupid everyone else is, they might even have had some time to pay attention to silly things like performance and tooling. That might help the adoption a bit more than the supercilious rock throwing that is almost exclusively the tone of every single article/post from Lisp lovers.

raspasov 11y ago
C is the king of raw performance, there's no denying that. But for the vast majority of high-level, user-facing applications today it's a bad fit. Clojure is more than fast enough for serious server side programming, often coming close to Java in performance with minimum amount of tuning needed in the average case. When you add multithreading into the mix, it's not even a contest; the amount of time you'll have to spend to make an idiomatic Java or C++ run both correctly and fast is gargantuan compared to a language where concurrency was built-in from the start.

PaulHoule 11y ago

The homoiconic thing is not all it is made up to be. That is, you can take (say) Java and parse it to an abstract syntax tree and the manipulate the tree. Assuming you have a good toolbox of operators, working with that kind of AST is not much harder than working with s expressions. Maybe it is easier if you can build a general notation that can be generalized for multiple languages and also represent more ordinary data such as json formatted, relational, rdf, etc.

AnimalMuppet 11y ago
Yes, but parsing Java into an AST is much harder than parsing S-expressions into an AST...
retrogradeorbit 11y ago
I couldn't disagree more. Working with that kind of AST is many orders of magnitude harder than Lisp macros. None of it is first class. You brush over it in your comment like writing a Java parser is trivial. My clojure parser returning the AST in its entirety is: (read-string (slurp "my-source.clj")). What does your Java one look like? The proof that it is so much harder is that no one ever does it. Yet people do this all the time in Lisps. If its "not much harder" I'd expect to see more of it, but I don't, because it is just so much work. Aside from parsing, what about templating. Yes, you can manipulate the AST once you have it, but what would templating AST look like? Would it look just like the Java code? With the syntax quote in clojure it looks very much like the output. How would you even begin to template syntax in your hypothetical Java implementation?
- PaulHoule 11y ago
  1. I am not writing a parser, one already exists and can be brought in about as easy as your code sample. 2. I am translating the AST to rdf which lets me work on the AST with production rules 3. If I wanted templates I would use templates. What I do do is start out with an abstract representation and then apply say 20 simple transformations that step by step fill in the details to get to code. Speed is OK because we have indexes, rete networks and other tricks. 4. People are not doing it yet and this is why people are saying code reuse is hard, etc. 5. The transformations are written in a sparql derived rule format that itself uses the transformation system to add features by composition.

winestock 11y ago

I'm the author of this essay. This must be at least the third time that it has appeared on Hacker News. I'm starting to get sick of it, myself, but I keep it up because so many people like it (at the bottom of the page, you can see the translations; all done gratis by volunteers). I wrote it during a period when I was especially fascinated with Lisp and got caught up in the theorizing to which the Lisp community can be prone. Nowadays, I freelance in front-end web development and doing Lisp hacking is something that I put on the back-burner.

Scarbutt 11y ago
so you just use javascript? I'm in that period of fascination, any practical advice? ;)
- winestock 11y ago
  For now, yes. My life has taken some unexpected detours, these past few years, so I have to focus on work rather than inspiration.
  - pareidolia 11y ago
    Have you ever put (any, as in CL, Scheme etc.) Lisp into practice? I got the impression from the essay that you think that everything in a Lisp consists of macros, which is not the case.

bitwize 11y ago

People who care what other people think about the programming languages they use write essays like this. The rest of us just shut up and hack some Lisp.

justnotforme 11y ago

A lot of thoughts about lisp; are written by zealots; who like to create the impression that they are playing with some kind of dangerous mind amplifying meta language; and if you start using it; you might accidentally unleash creatures from the id. But then you look at it; and find it is simply a programming language.