
The Lisp Curse (2011) - mpweiher
http://winestockwebdesign.com/Essays/Lisp_Curse.html
======
jstimpfle
I would argue that C has the same problems. It gives you so much power, only
in a different way.

------
gkya
> Programs written by individual hackers tend to follow the scratch-an-itch
> model. These programs will solve the problem that the hacker, himself, is
> having without necessarily handling related parts of the problem which would
> make the program more useful to others. Furthermore, the program is sure to
> work on that lone hacker's own setup, but may not be portable to other
> Scheme implementations or to the same Scheme implementation on other
> platforms. Documentation may be lacking. Being essentially a project done in
> the hacker's copious free time, the program is liable to suffer should real-
> life responsibilities intrude on the hacker. As Olin Shivers noted, this
> means that these one-man-band projects tend to solve eighty-percent of the
> problem.

I guess this is true for all programs in all languages. Distributing anything
needs lots of care to following community practices and to possible edge cases
stemming from incompatibilited in people's setups.

------
pron
This is a great lesson for any language designer. The quality of the language
isn't measured by inherent properties. Like any product, its quality is
measured by how it interacts with the constraints, requirements and dynamics
of the industry it serves.

------
pvg
(2011) and previously:

[https://news.ycombinator.com/item?id=2450973](https://news.ycombinator.com/item?id=2450973)

[https://news.ycombinator.com/item?id=3808194](https://news.ycombinator.com/item?id=3808194)

[https://news.ycombinator.com/item?id=11174946](https://news.ycombinator.com/item?id=11174946)

------
dctoedt
Previous discussion of "The Bipolar Lisp Programmer," cited in this article:
[https://news.ycombinator.com/item?id=20012](https://news.ycombinator.com/item?id=20012)

------
tempodox
The article is from 2011 but little has changed.

> Unless they pay thousands of dollars, Lisp hackers are still stuck with
> Emacs.

Still true today. SBCL + slime (or slimv for vim) make a decent IDE for my
shell terminal, but it's nothing for mouse pushers and a far cry from a LispM.

~~~
flavio81
I've used many IDEs for various languages, and i must say SLIME is pretty
good. I don't feel "stuck with emacs" at all.

------
weberc2
Interestingly, I think this is related to Go's success, much to the chagrin of
its functional-programming detractors. While there might be a dozen or more
ways to write a subroutine in Haskell or Lisp, there is more or less one way
in Go. Further, the route in Go is probably not as elegant (according to
popular opinion, anyway) than in functional languages, so fewer are tempted to
improve upon it. That said, contrary to this article, Go isn't harder to
develop in than Lisp; it's likely easier because there is one way to solve any
given problem, and that way is usually quite straightforward. This isn't meant
as a "Go is better than Lisp" post; I can appreciate each for its strengths.
This is just marveling at the nuances of psychology and it's impact on the
technical domain.

~~~
pmoriarty
Similar things were said in favor of Python over Perl, back in the day. Python
had the _" there's one way to do it"_ motto, directly in opposition to Perl's
_" there's more than one way to do it"_.

In reality, one only need look at the many different package management
attempts to see how Python failed at living up to its own aspirations. If more
evidence is needed, take a look at the packages themselves, and you'll see
lots and lots of duplication of effort and incompatible ways of doing the same
thing.

Perl's CPAN was widely reviled by Python fans for having lots of cruft
collected over the decades, and not knowing if the package one uses is the
"right way to do it", and Python's "one way to do it" approach was supposed to
be a solution to that. Well, it didn't work out that way. There are now tons
of crufty Python packages, with similar quality control issues.

I think this is merely a result of a language becoming popular and having a
robust community of developers. Developers like to re-implement things and
write them from scratch, whether just for their own education or amusement, or
for geek cred, or to look good on a resume, or because they finally want to
write it "the right way" (of which everyone seems to have a different opinion
on). Then they abandon packages when they're no longer interested or when
something else takes priority. Happens all the time.

If Go hasn't had something like this happen to it yet, it could be because of
some visionary design that somehow avoided these issues, or it could be that
it's just not as old and popular yet.

~~~
m3talsmith
Regarding Go and package management, I'd say that Go doesn't have that issue
yet because there really is no package management outside of using mercurial
or got repositories. They are working on vendorizing those in a one way
fashion and expect, as a Go programmer, that there will be am explosion of
drift in due time. As you stated, "I think this is merely a result of a
language becoming popular and having a robust community of developers." I
couldn't have put it more succinctly.

------
ealhad
My thoughts exactly, although expressed in a much more organized way.

I love Lisp. I had a great time learning it, but its lack of momentum is a big
problem.

~~~
lithos
I liked Lisp when I played with it, but realized that when it came to things I
shouldn't* play with I wouldn't be able to use it for any serious project.
Seriously even lacking a socket api is a sad state for a language (if I want
to look at multiple someone else's interesting code that actually does
something how many low level communication frameworks am I going to need to
know).

*as in finical, security, encryption type of problems (that each require a decades worth of training/learning to start to get right) that can ruin life's and companies.

~~~
armitron
Common Lisp has multiple "socket apis", most of them well-documented, widely
used, well-tested and robust.

Your other point about "finical [sic], security, encryption-type problems" I
do not understand at all since you do not go into any details.

I've noticed that a lot of people will claim a lot of things when it comes to
Lisp, but it is extremely rare that these claims have any merit whatsoever.
More than often enough, those making the claims are obviously completely
clueless and have never spent more than a couple of minutes [if that] looking
at Lisp. Yet they feel confident making all sorts of false proclamations and
spreading lies and misinformation.

------
nabla9
>Lisp is so powerful that problems which are technical issues in other
programming languages are social issues in Lisp.

This is so true.

Common Lisp is like post scarcity anarchist society where everyone already has
a replicator. The culture of getting together to solve problems don't exist.
In other language, implementing something is so damned hard that if you have
half-assed implementation, others will take it and improve upon it because it
saves work and it gains momentum. In Lisp world people take a look at it and
say: "This is half-assed implementation I could whip something better together
in a weekend." If takes a village, village will form. If not, everyone goes
their own way and never gets together.

"I am reminded of Gregor Kiczales at ILC 2003 displaying some AspectJ to a
silent crowd, pausing, then plaintively adding, `When I show that to Java
programmers they stand up and cheer.´" \-- Kenny Tilton

Time and time again you see the following pattern:

A: Why Common Lisp has no X?

B: Writing rudimentary X takes 2-3 days. Writing it as solid package takes 2-3
weeks. Why don't you implement it?

What A meant is that it would be a standard that could be used across
different software packages.

~~~
lispm
> Writing rudimentary X takes 2-3 days. Writing it as solid package takes 2-3
> weeks. Why don't you implement it?

The research of Gregor Kiczales and others prior to AspectJ took something
like decades with a lot of researchers working on that stuff.

Basic idea of aspects in Lisp came up in the 60s and 70s in the BBN /
Interlisp community. See:

AITR-221 Author[s]: Warren Teitelman

PILOT: A Step Toward Man-Computer Symbiosis

September 1966

ftp://publications.ai.mit.edu/ai-publications/0-499/AITR-221.ps

ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-221.pdf

From there it went into Interlisp, Loops, Flavors, CLOS, ...

Gregor expanded these ideas and moved it to Java.

The Lisp community worked 30 years stuff like that and it took several years
to standardize the Common Lisp Object System, which incorporates some of the
ideas of Aspect-oriented programming.

> What A meant is that it would be a standard that could be used across
> different software packages.

People do that in Lisp, too.

~~~
coldtea
> _People do that in Lisp, too._

Not as much as they should, which is the whole point of the article, and a
core lesson of history.

~~~
lispm
If you feel the need to contribute code, then there is Quicklisp to distribute
it.

> Not as much as they should, which is the whole point of the article, and a
> core lesson of history.

One of the uses of Lisp is prototyping. The Interface Builder from NeXT/Apple
was originally written in Lisp. The Dylan IDE was a prototype in Lisp. There
is lots of research code, some never meant to made available as a supported
library/application. Maybe somebody writes a theorem prover in Lisp for
his/her PhD. The chance for finding users is slim - there are already a few
others. But if you wanted to share, check out the ACL2 (A Computational Logic
for Applicative Common Lisp), it comes with lots of shared code:

[http://www.cs.utexas.edu/users/moore/acl2/current/combined-m...](http://www.cs.utexas.edu/users/moore/acl2/current/combined-
manual/index.html?topic=ACL2____TOP)

[https://github.com/acl2/acl2/tree/master/books](https://github.com/acl2/acl2/tree/master/books)

ACL2 is shared and maintained. It's extensions are shared with stuff from AMD
and Intel.

Most people don't know that and have never heard of it, because these are
niche applications of Lisp, here using theorem provers to check the design of
processors.

[http://www.cs.utexas.edu/users/moore/publications/acl2-paper...](http://www.cs.utexas.edu/users/moore/publications/acl2-papers.html#Processor-
Models)

users: Freescale, Intel, AMD, Rockwell Collins, Centaur Technology, ...

This is one example, there are a several other areas where people share a lot
of code. The canonical examples are the Common Lisp implementations
themselves. They share(d) code in various ways. The first CLOS implementation
was shared. The pretty printer was shared. The CMUCL compiler was shared from
day zero somewhen in 1981 or two - before Common Lisp even existed. SLIME is
shared.

------
winestock
I am the author of this essay and this is the umpteenth time that it has
appeared in Hacker News. If you look it up using the Hacker News search
function, it even invites readers to beat the dead horse one more time.

I'm surprised that it still gets so much attention. Every few months, someone
volunteers to translate it into another language (see the bottom of the page).

I wrote that essay five years ago. Nowadays, just use Clojure or Racket and
ignore what I've written.

And yes, I know, I really need to update the design of the site. I wrote it
when I was still a rookie web developer. I'm starting a new job so I'll
redesign my site in my copious free time.

~~~
saghm
Since you're here, what's your take on why Clojure has become so popular
lately (compared to the mindshare that Common Lisp or Scheme seem to have
nowadays)? Although I've barely touched Lisp (and never touched Clojure), it
seems weird to me that Clojure is so widely used compared to other Lisps. From
what I can tell, the main differences are that it's on the JVM (obviously) and
that it uses loops rather than recursion, but neither of these really explain
to me why things like ClojureScript exist instead of "SchemeScript" or
something like that. Do you think it's related to the ideas presented in the
blog post, or is there something I'm missing?

~~~
winestock
My take is that Clojure's community is distinct from that of other Lisp
communities.

Old school Lispers are the Jacobites of the Computer Age. Their warnings were
ignored, so their nightmares came true; and the world has changed so much, as
a result, that few can even imagine an alternative. They were right about
nearly everything, and now they are irrelevant.

So pour out a drink for the king over the water and for Genera. Curse this
present dark age of bureaucrats and Posix. And then MOVE ON. The Clojurists
are the first sizable community of Lispers that has done that.

~~~
pmoriarty
That was beautifully worded, and I would so love to read a post where you
expand on what you said.

------
gaius
_On the other hand, adding object orientation to C requires the programming
chops of Bjarne Stroustrup_

I'm not sure this is true. You can get basic OO going on C in an afternoon
with structs and function pointers. That is a very, very common technique in
graphics programming (or was, before C++ optimizers got any good). ObjC is
also a thing. The achievement of Stroustrup - and this is no minor thing, so
don't think that I am discrediting him in any way - was he got everyone else
to buy into his vision for a particular way of doing it.

Incidentally I recently attended a talk given by Stroustrup and he is a super
nice guy and certainly doesn't think of himself as a genius.

~~~
brendonjohn
> ...and certainly doesn't think of himself as a genius

This is intellectual humility. He's obviously a genius in his own right.

~~~
gaius
Yes and no. I would define a genius as someone who makes an intellectual leap
that noone has made before. Stroustrup is a smart guy who just works very,
very hard. As such he is an inspiration because he shows what an ordinary
person is capable of if they work hard enough. Just my opinion of course.

~~~
cercatrova
Geniuses are often people who work at something for a long time until they
slowly accumulate the knowledge and experimental results to make such a leap.
After all, Lazy Geniuses don't achieve much, even if they have the potential
to.

~~~
gaius
Alan Kay is undoubtedly a genius, I believe, because he made the leap to OO in
the first place.

------
roenxi
He writes a seductive argument, but it isn't very satisfying to conclude "this
language is so powerful that it defeats itself". Likely there are other, more
mundane reasons why the theoretical purity of the lisps isn't useful in
practice.

For example, the endless (bracketing). My understanding is that the power of
lisp macros comes from this questionable, but distinctively lispy, syntax. And
I say questionable compared to natural human scripts - none of them work from
inside to out. I've seen left to right (eg, English), right to left and up to
down (eg, Chinese). If there were some better known examples of what lisp
macros were good for then maybe it would get better traction. But lisp macros
don't seem to have an example of why they are worth that trade.

Also, in the early days, C was a pretty close mirror to the underlying code
execution - there was probably less mental overhead to squeezing out better
performance.

~~~
sbmassey
Lisp is no more 'inside to out' than any other programming language, it just
uses the same syntax for each subclause where other languages randomly choose
different syntaxes for different kinds of expressions, so C

    
    
      if (a == 0) { printf("color %s", b[i]); }
    

might be lispified

    
    
      (if (= a 0) (format t "color ~A" (aref b i)))

~~~
FrozenVoid
A better example:

    
    
          #include <stdio.h>
        #include <stdlib.h>
        #define ifl(op,a,b, ctrue,cfalse) if(a op b){ctrue ;}else{cfalse ;}
        #define strtolong(x) strtol(x,NULL,10)
        int main(int argc,char**argv){ 
        if(argc<3){
        puts("2 args req");
        exit(1);}
        ifl(>,strtolong(argv[1]),strtolong(argv[2]),puts("Arg1: > Arg2:"),puts("Arg1: <= Arg2:"));
        ;}

------
jasim
> A random old-time Lisp hacker's collection of macros will add up to an
> undocumented, unportable, bug-ridden implementation of 80% of Haskell
> because Lisp is more powerful than Haskell.

How so? Can we program Haskell's Hindley-Milner based type checking into Lisp
with macros and homoiconicity, and have it run during compile-time?

I've been dabbling in OCaml and ReasonML recently, and am enjoying pure
functional programming a lot. But I never could get into untyped FP like the
very practical Clojure before because they didn't seem to offer me too much
compared to Ruby and Javascript.

Functions in ES6 are more first-class than Ruby's lambdas. The single-line
function definition is very concise and you can also do your programming with
immutable values if you are careful about references and use something like
the immutable-helper. Granted you don't get persistent data structures, but
then you have ImmutableJS now. ES6 implementations also have TCO, so a
recursion-based programming model should be fine as well.

In that context, the differentiating power of Lisp seems to be around macros -
a very powerful way to write programs that write programs. I have done my fair
share of meta-programming with Ruby and I realized I really didn't want the
power to change my program model at runtime. While they made certain things
easier - like Rails's ActiveRecord (which is superb btw) - the
"inception"-like indirection made things very hard to reason about.

For me the secret-weapon language is less about power, and more about
structure. We can build equivalent things with any turing-complete programming
language, but the test is when the system has to grow, and that is precisely
when most codebases fail. So far, statically typed FP with Sum Types and
Pattern Matching and Immutability seems to be the cure, and macros and dynamic
typing its very antithesis.

~~~
Guthur
Your final statement is demonstrably incorrect. The world is full of large
software projects not using statically typed FP and actually surprisingly
little from the likes of haskell beyond self serving academic noodling.

~~~
codygman
> surprisingly little from the likes of haskell beyond self serving academic
> noodling

Your final statement is demonstrably incorrect.

Facebook (haxl), Microsoft (Bond), Google (ganeti), Target for supply chain
automation, Bank of America (Haskell is being used for backend data
transformation and loading), standard chartered, Prezi, Android bump
([http://devblog.bu.mp/post/40786229350/haskell-at-
bump](http://devblog.bu.mp/post/40786229350/haskell-at-bump)), At&t (automate
processing of internet abuse complaints).

~~~
pron
> Your final statement is demonstrably incorrect.

The final statement the parent responded to was, "so far, statically typed FP
with Sum Types and Pattern Matching and Immutability seems to be the cure."
That Haskell can be used to write real software, and that it is, in fact, used
by a few projects in the real world, is no demonstration of it being a cure to
anything any more than Go's use in far more project is a demonstration of it
being an even better cure. That those Haskell projects don't seem to do
significantly better than others, does, however, seem to demonstrate that it
is not a cure.

As I read it, the "self serving academic noodling", while too harsh an
assertion (as some real-world Haskell users do enjoy working with it), does
not refer to Haskell being useless, but to Haskell not seeming to substantiate
the strong claims made by some of its fans; at least not in any striking,
self-evident way. Haskell is a fine programming language, but touting it as
the cure to our problems is a bit premature.

------
d_burfoot
For me the problem with Lisp is that it's just ugly to look at. Compare some
Lisp code to an equivalent in Python, just in terms of the raw visual appeal
of the text. The parentheses and indentations obscure the logical meaning of
the code.

~~~
flavio81
Python and Lisp coder here.

At first look, Lisp is ugly to look at.

However once you start learning Lisp and writing your self programs, it
becomes fairly easy to read not only your code but others' code.

> The parentheses and indentations obscure the logical meaning of the code.

Indentations have no effect in Lisp, they are only there to make code more
readable.

Parentheses are there to clearly tell you which statement is acting over which
other statement, so they are there to give you a clear light about the meaning
of the code.

Visual appeal can be just fine, as long as the indentation is well-applied.
The same is true for widely used languages like Java, C, C++, C#, and
Javascript. Wrongly indented C code can be frustrating to read.

Have this small, silly snippet of Common Lisp code and take a look. You should
understand easily what each statement is doing.

    
    
        (defclass my-stack ()
          ((name
            :initarg :name
            :initform "<Unnamed stack name>"
            )
           (the-stack
            :initform ()
            )))
    

So here we DEFine a class called "my-stack". With two members (or "slots")
called "name" and "the-stack". "Name" will be an initial optional argument,
with default value ("initial form") "<Unnamed stack name>"

    
    
        (defmethod into (item (s my-stack))
          "Push an item into our stack"
          (with-slots (the-stack) s
            (push item the-stack)))
    

Here we DEFine a silly method which pushes an item into an object S of type
"my-stack". The explanation "Push an item into our stack" follows. Later what
we say is, that, using the slot "the-stack", perform the following code: Push
an item into the stack. Those two lines are almost English.

    
    
        (defmethod sum-all ((s my-stack))
          "Return the sum of all items in our stack"
          (with-slots (the-stack) s
            (loop for item in the-stack
               summing item)))
    

Here I show you that code can be really straightforward to read. Here to sum
all the stack i use the following loop instruction:

"loop for item in the-stack summing item"

... and it does exactly what it seems to be doing. It's just as if it was
plain english!

So one can write highly readable Common Lisp code if one wants to.

~~~
kazinator
> _Python and Lisp coder here. At first look, Lisp is ugly to look at._

Maybe for you; Lisp was great for me to look at from the moment I laid eyes on
it.

Beauty is very subjective; but the _technical_ advantages or disadvantages of
a syntax aren't.

Some years prior to becoming a Lisp programmer, I had one tiny interaction
with Lisp that wasn't terribly good. It was this: some CLOS example code in a
book on OOP by Grady Booch. I was trying to follow the syntax and it seemed to
have weird repetition in it. That was arising from the _defclass_ syntax for
declaring accessors and initforms, like this _(foo :initarg :foo)_ and _(bar
:accessor bar)_ type stuff. I was boggled by all the repetitions: why do we
have foo and :foo, and so on. I had no clue about Lisp keyword symbols at that
time.

I didn't _hate_ the syntax, and it seemed less verbose than C++, for sure. The
parentheses in it seemed perfectly fine. It was just boggling a little bit:
more so than something like (let ((x 2) (y 3)) (+ x y)), or (loop for x below
10 summing x).

~~~
flavio81
> I was boggled by all the repetitions: why do we have foo and :foo, and so
> on.

For what it's worth, here is my "defclass-easy" macro which will create a
class with the slots you want, it also has a "required-slots" list as a
parameter. Slots that are in both "slot-list" and "required-slots" will have
an ":initarg" of the same name as the slot, and will raise an error if not
supplied when making an object.

Enjoy!

    
    
        (defmacro defclass-easy (class-name slot-list required-slots)
          ;;required-slots should be a list as well
          `(defclass ,class-name ()
             ,(mapcar (lambda (x)  
                (if (null(member x required-slots))
                     (list x)
                     (list x :initarg 
                       (read-from-string (concatenate 'string ":" (string x))) ;creates :initarg :<slot name>
                       :initform `(error ,(concatenate 'string "initarg required: " (string x)))))) ; (error "initarg required: xxxx") 
                  slot-list)))

~~~
kazinator
It's interesting to note that Lisp has some "def easys", just not for classes.
There is a _defsetf_ for simple situations, so you don't have to use _define-
setf-expander_. _defsetf_ 's simplicity isn't one-size-fits-all either; it has
a short form and a longer form. In the same area of functionality, there is
_define-modify-macro_ which handles simple cases, freeing the user from
calling _get-setf-expansion_ and dealing with its return values.

P.S.

    
    
       (read-from-string (concatenate 'string ":" (string x)))
    
       ==> (intern (string x) 'keyword)
    
    
       `(error ,(concatenate 'string "initarg required: " (string x))
    
       ==>  `(error "initarg required: ~s" ',x)

------
FrozenVoid
All this poetic non-sense about flexibility and writing prototype programs is
irrelevant. Lisp has real technical flaws that prevent its use:

1.GC that prevents it from using real-time and performance-oriented code.

2.Pervasive use of inefficient lists and dynamic typing, which puts steep
memory requirements on top of performance costs.

3\. Arcane write-only syntax which becomes context sensitive with Domain-
Specific Languages which Lisp programs devolve to, creating unreadable and
overly condensed spaghetti code(especially macros), making existing code
inaccessible for developers.

4\. Huge runtime which is embedded in every executable, that makes it less
competitive with scripting languages. Lisp requires eval() and runtime
interpretation which other languages optimize out and replace with fixed code
paths. (some external programs called "tree shakers" remove the lisp's runtime
cruft, but they're exception rather than rule)

5\. Lisp has very loose safety. Any piece of data can be potentially executed
at runtime and lisp programs have to be excluded from WriteXORexecute/NX
protection, since lisp code/data are intermingled. Executable stack and heap
expand areas for exploits and create a general lack of stability - any bug can
corrupt running code, Lisp is so far removed from any concept of safety it
even allows the programs to be modified at runtime(this is a fundamental
feature shared with polymorphic viruses).

~~~
lispm
> 1) performance costs

Keep in mind that a compiler like SBCL will put Lisp performancewise in the
range of other statically compiled language/implementations.

> 2) puts steep memory requirements on top of performance costs

Such that the Dylan IDE (
[https://news.ycombinator.com/item?id=14478942](https://news.ycombinator.com/item?id=14478942)
) written in Macintosh Common Lisp needed 20 MB RAM. Steep memory
requirements! Current Lisp implementations run nicely on a first-gen Raspberry
Pi.

Lisp fought with memory efficiency in the 80s (the Lisp Machine operating
systems ran in 20 MB RAM + 100MB virtual memory -> which were 4 MWords RAM of
40bit memory), but hasn't grown much since then. The jump to 64bit
implementations has brought some size increase. But the size varies widely
between large machine code (say with SBCL), space efficient byte code
implementations (CLISP) and tiny executables created by whole-program
compilers like mocl.

> 4) Huge runtime which is embedded in every executable, that makes it less
> competitive with scripting languages

If you want to compete with 'scripting languages', then just don't include the
runtime. You can use many Lisp implementations just like scripting languages.

> Lisp requires eval() and runtime interpretation which other languages
> optimize out and replace with fixed code paths

If a compiler is used (say: SBCL, ECL, LispWorks, GCL, CCL, Allegro CL, mocl,
...) , then Lisp does not require runtime interpretation.

> some external programs called "tree shakers" remove the lisp's runtime

They don't. Treeshakers remove unused code and data. Parts of the runtime are
still there.

> 5) Any piece of data can be potentially executed at runtime

If you remove the compiler & interpreter from the executable, that can't
happen. See for example the LispWorks documentation on 'Delivery':

[http://www.lispworks.com/documentation/lw70/DV/html/delivery...](http://www.lispworks.com/documentation/lw70/DV/html/delivery.htm)

> since lisp code/data are intermingled.

Not necessarily. Code in compiled Lisp implementations is machine code. If all
fails, you can always compile Common Lisp to C code using GCL, ECL, MKCL,
mocl, CLASP (C++).

> Lisp is so far removed from any concept of safety it even allows the
> programs to be modified at runtime

Only if you include an interpreter.

Actually one of the nice features of many Lisp implementations is that usually
all data is tagged and that Lisp code checks applicability at runtime, incl.
array/string/vector bounds checks...

~~~
FrozenVoid
>Keep in mind that a compiler like SBCL will put Lisp performancewise in the
range

Simple short benchmarks don't show a complete picture of the language, since
they're easy to optimize

>written in Macintosh Common Lisp needed 20 MB RAM

At the time when computers had 32/64 MB of RAM.

>. You can use many Lisp implementations just like scripting languages. >If a
compiler is used (say: SBCL, ECL, LispWorks, GCL, CCL, Allegro CL, mocl, ...)
, then Lisp does not require runtime interpretation. >Only if you include an
interpreter.

So which one is it?

>Treeshakers remove unused code and data. Parts of the runtime are still
there.

Huh, What kind of unused code and data is there in a 25MB hello world?
[https://web.archive.org/web/20090324024745/http://mbishop.es...](https://web.archive.org/web/20090324024745/http://mbishop.esoteriq.org/hellosize.html)

>If all fails, you can always compile Common Lisp to C code

Compiling to C doesn't improve safety of Lisp. As a C programmer, "Compiling
to verbose cryptic C" doesn't sell me as a feature, more like a potential
security threat.

~~~
ealhad
> Huh, What kind of unused code and data is there in a 25MB hello world?

If you want to produce a standalone Lisp executable, you have to embed the
compiler with it, hence the big size.

However, if you just run the programs with your own compiler, you only need
the actual code — that is a 44 bytes "Hello world!", shebang included.

On my machine, the SBCL package is 70 MiB, while for example the Python one is
125 MiB.

~~~
FrozenVoid
>However, if you just run the programs with your own compiler,

By that logic GCC is also an interpreter. [https://github.com/abijith-kp/gcc-
interpreter](https://github.com/abijith-kp/gcc-interpreter)

~~~
armitron
It's embarrassing watching you trying to argue, when it's more than obvious
you haven't got the slightest clue of what you're talking about and probably
never used Common Lisp in your life.

Rather than wasting your time propagating fallacies and outright lies,
wouldn't it be better to get informed?

I won't hold my breath.

~~~
very_mediocre
Please don't be mean.

Also, it can be exciting to find where or why one may be misled about
something, and then to try and explain it well.

