
Ask HN: Why Shouldn’t I Use Lisp? - nicholas-cc
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&#x2F;higher-level languages with more features?
======
mimixco
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.

~~~
kazinator
> _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".

~~~
SamReidHughes
You could use TypeScript, like VSCode does.

------
fulafel
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

------
auganov
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.

------
karmakaze
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.

~~~
abrax3141
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.

~~~
karmakaze
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.

~~~
kazinator
> _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?

    
    
      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;
      };
    

When and where is this allocated? What does it represent? How do you use it?

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.

~~~
karmakaze
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.

~~~
kazinator
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.

~~~
bordercases
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?

------
CyberFonic
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.

~~~
kazinator
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").

~~~
lispm
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).

~~~
kazinator
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.

------
_bxg1
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](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.

~~~
fulafel
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)

------
sdfjkl
((

------
SamReidHughes
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.

~~~
veddox
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).

~~~
SamReidHughes
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.

~~~
veddox
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?)

~~~
SamReidHughes
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.

