Ask HN: Why Shouldn’t I Use Lisp?
I’ve been following people like Jonathan Blow, as well as Paul Graham. I’ve learned Lisp and kind of like it, but I’ve heard Jonathan Blow say that A) GC is bad, and B) not to use Lisp and other similar languages. Could you explain these reasons not to use Lisp/higher-level languages with more features? To paraphrase Ansel Adams (who was speaking of cameras), there is no one best language only the best language for the project you're doing. It may very well be that Lisp is the right language for your project. That depends largely on what the project is and what advantage you are seeking from Lisp (or another choice) that helps complete your project and, most importantly, reduces debugging time later since that's where you'll spend 60% of your coding effort. We are building our product with a Lisp back end because it deals with NLP and large bodies of text where Lisp is ideal. The user interface, however, is HTML/JS (Angular) because that language offers much more flexibility for UI design. > because that language offers much more flexibility for UI design Sure, for values of "flexibility" approaching "the only darn way to make UI run in the browser". You could use TypeScript, like VSCode does. Grammarly? Are you asking what the app is? It's called Mimix[0] after Vannevar Bush's proposal in the 40's. The eventual goal is to replace the word processor as we know it. [0] http://mimix.io Jonathan Blow is an opinionated game programmer/language creator who is eg concerned about memory management eating into his 360 Hz display frametime[1]. GC is still used in many games, eg Unity engine, so it's not a universally held view in the field of games. You should probably tell us more about what domain you are working in and/or read his opinions in the contex of his domain. As for your (B), besides the "is it bad" essay question you probably want to look at languages specifically. As you know there are many Lisp style languages and they have big differences. Eg Clojure, Scheme and Common Lisp are all very different and have different kinds of communities. It's a language family of more internal variety than eg modern Algol style imperative managed statically typed languages (Java/C#/Go). [1] A topic of some of his tweets recently Sounds like your question is about high-level GCed languages in general. The person you're referencing appears to be in the gaming industry where GC is especially problematic. If we're talking about Lisp specifically vs similar languages, people probably end up not using it for non-technical reason. Community, hire-ability and so forth. I've read a lot about Lisps with an open mind, worked through SICP in Racket, and worked on some personal projects in Clojure. It was all fine, but at no point did I feel like there wasn't another language that would have done as well, possibly better. The one area where I was never fully comfortable was the lack of static type checking. I've also dabbled with Haskell and though it it is the most clean and consistent language I've used. I never got to the point where I could wield higher kinded types to my advantage, I felt like I was doing extra work to satisfy the language requirements without necessarily getting the benefits back from it. I realize there's benefits of doing so, but it's unclear when/if I'll even break even. Recently I tried F# having seen OCaml in the past but not really using it. F# seems to have progressed quite a bit since it was just OCaml on .NET. I'm able to work rather fluently with it having already been exposed to Java/Kotlin/Scala/Elixir which seemed close to what I want but seeming to fall short in ways I couldn't quite describe. F# came the closest to what I've always hoped to find in a language. It too has its quirks, some within itself and partly from interoperating within .NET Core. I've yet to use it on larger projects and on a team but the static type checking has already helped me save so much time on iterating design that I wont look at any Lisp for generic work. If I had a need for some specific DSL task it may come in handy as I've often baked minimally expressive configuration languages in the past for no good reason. Right. Lisp totally outshines every other language at building DSLs, so if you reconceptualize your project as a bunch of DSLs that utilize one another, you win big with lisp. What I'm finding is that I can effectively do the same with a statically-typed functional language. The worst are DSLs with poor grammar and concept-fit which add-to rather than solve problems. The ways in which Lisp doesn't scale (people-wise) are well known and relate to each application essentially being its own programming language. > The ways in which Lisp doesn't scale (people-wise) are well known Well, memes about Lisp not scaling people-wise are well-known on forums like HN. The actual data on this is lacking, like reports about someone having actually gathered five hundred Lisp developers onto one project and failed. > each application essentially being its own programming language Meme-fueled nonsense, I'm afraid. Every complex application in any language is its own programming language. New types and functions introduce new syntax, just like macros, along with new semantics. So you know C? Okay, what's this, from the Linux kernel? Guess what, this is new syntax. No, wait, what, it's just using the regular C grammar, right? How can it be new syntax? The same way that a Lisp program have new syntax if continues to be made out of parentheses, symbols, strings, numbers that conform to a rigid grammar. The new syntax is in the schemas built with the definition abilities provided in the underlying fixed grammar. [I don't recall reading this C example first time around. Was the comment edited after I replied?] In any case, "When and where is this allocated? What does it represent? How do you use it?" is just C. The computational model hasn't changed. Perhaps less well known are the well-meaning explorations into why isn't Lisp more popular. The absence of a 500 Lisp developers on one project is itself the datapoint being discussed. The absence of that is because it would require a substantial global recruitment and relocation effort to get that many Lispers into one organization. It speaks nothing to their ability or inability to co-operate on a project. The vast majority of all software tech ever invented is unpopular today. If we just pick a tech stack, language, editor, OS or anything from the last 70 years at random, it's almost certainly unpopular. That's our first-order effect that forms the bulk of the rational explanation for why anything is unpopular. By definition, not everything can be popular: popularity is the selection of a very small number of artifacts (almost always chronologically recent) to the exclusion of everything else. The challenge to that prior is that there is substantial overlap in the features and capabilities that were in, say Commmon Lisp a long time ago and yet there was a substantial delay in those features being accumulated in other languages with vastly greater adoption to this point (like Java, although that example might be disingenuous since the releases of Java and CLOS were only a year apart...) Likewise during the last seventy years some languages saw wild uptakes in popularity for some languages much later in their life-cycle. Who would have expected the modern successes of Ruby? Depends on what you are implementing and how. I find Lisp good if you have a rough top-down design and lots of bottom-up implementation details to suss-out. You can test each bit as you build and in passing you might implement a DSL for your domain. There are many compiled Lisps (both CL and Scheme) so performance can be quite good. Generally, it is hard to deploy Lisp on client systems (if that is a requirement) without introducing many dependencies. Loko Scheme being an exception, since it (like Golang) compiles to a single executable with no dependencies. GC and VMs are common in many alternative environments so that's not a point of difference. If you like Lisp and your dev and target environments are suitable and you are a solo developer or have a team of Lispers then why not use it? In most general terms Lisp is no better nor worse than the alternatives. Traditionally Lisp systems are incredibly easy to deploy by saving an image. Images are so different from what is practical in C or Java that I found it hard to wrap my head around. An image is a saved running state. It requires a runtime that allows interacitvity. Smalltalk, Common Lisp, and ML are all examples. Scheme based systems typically don't provide it...but like anything there are exceptions. Some documentation about images in SBCL: http://www.sbcl.org/manual/#Saving-a-Core-Image Loko Scheme is certainly not an exception in producing a single executable with no dependencies. All major Common Lisp implementations do this. I shipped a program for Windows quite easily using Clozure Common Lisp ("CCL"). Generally that's true. Loko Scheme is interesting, though - but probably not widely used. Check the documentation. Probably he meant 'zero' dependencies. Like not depending on C libs. I see that Loko Scheme depends on running on Linux (unclear, which versions) and AMD64 cpu - it seems to be able to run on bare metal, too - but the dependencies on the hardware are unclear. To bootstrap, it might need another Scheme implementation. Many Lisp systems can generate executables, some of which then may depend on some external libraries (maybe in specific versions), specific OS versions or even specific CPU variants (not unknown on ARM hardware which has a lot of CPU variants). A language implementation that depends on no C libraries, on a platform whose documented interfaces are C libraries, still has a platform dependency, and that platform dependency is worse. Clojure does pretty well on clients, ClojureScript for web and single .jar for JVM Clojure. Assuming performance isn't a problem (which it may well not be), this does a good job of laying out all the other arguments against Lisp: http://winestockwebdesign.com/Essays/Lisp_Curse.html Basically: Lisp projects have trouble scaling to larger teams (and communities) because of how fluid it is. That said, for a solo project or a small team, no language has more expressive power. That said, Jonathan Blow has the occasional good opinion and a lot of really bad ones. His anti-abstraction zealotry is the basis of most of the bad ones. As another commenter here said, there are no universal truths when choosing a technology; it's always about using the right tool for the job. But: 99% of software projects are made by solo devs or small teams, and shooting for scalability in its many dimensions from the outset has doomed many a project from making it out of the door. (Or hobbled them enough that the "happy problem" of scaling is never encountered) (( Because static typing is important for working productively with medium-to-large programs, because the Lisps have decrepit ecosystems, and because they aren't even good dynamically typed languages either, with the possible exception of Clojure. There is nothing that Common Lisp has, that other languages don't have, that makes it necessary. That‘s a pretty opinionated statement... Could you elaborate on why you think the Lisps aren‘t „good dynamically typed languages?“ And I don‘t think „necessary“ is a good metric when comparing programming languages; „pleasant to use“ or „efficient to write“ strike me as more pertinent (as well as the obvious runtime efficiency questions). Use of a bad language like C or Java or Emacs Lisp (if that can be called bad) can be necessary -- the best choice. I don't have a novel explanation of what makes Common Lisp and Scheme bad dynamically typed languages, just the ordinary obvious reasons, so there's no point in writing it out. Unfortunately, my CS background isn‘t strong enough to see the „ordinary, obvious reasons“. But I do like Common Lisp, so I am rather interested in discovering what bothers you about it? And as an aside: what makes you call C and Java „bad languages“? (Especially since you are so much in favour of static typing?) The short version is, In C it's easy to make mistakes with gotchas like implicit conversions, and nowadays it's archaic, lacking in basic features it could have, e.g. something akin to D's scope(exit) statements. In Java it's very expensive, in effort and code bloat, to define new types; in general the language actively fights against making well-organized program, or even just moving data around. With Scheme or Common Lisp, you might look at Clojure or Oz for some inspiration (as well as features we take for granted in Perl/Python/Ruby/PHP/JavaScript) in regard to what sort of features might make a dynamically typed language, even a Lisp, "not bad." Part of it is that statement-based function bodies are actually a good thing, and infix syntax is a good thing. Scheme is just lacking in basic stuff you need, and it relies on tail calls without explicit tail call syntax. And it has call/cc. Common Lisp is bad in detail -- it has all sorts of clever little features, like setf, that don't solve real problems, they solve Lisp problems. And they handle defining and using new types badly, even simple ones like plain record types. Back in the day, CL's advantage was that the competition was so weak. If you gave CL the Python or JS ecosystem today, it would be usable, but that's the nicest thing you can say about it. False
True
False
False
When and where is this allocated? What does it represent? How do you use it? struct usb_host_endpoint {
struct usb_endpoint_descriptor desc;
struct usb_ss_ep_comp_descriptor ss_ep_comp;
struct usb_ssp_isoc_ep_comp_descriptor ssp_isoc_ep_comp;
struct list_head urb_list;
void *hcpriv;
struct ep_device *ep_dev;
unsigned char *extra;
int extralen;
int enabled;
int streams;
};