Hacker News Reader

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

I didn't say anything about short benchmarks.

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

Exactly. Phones now run with 4GB RAM. A Raspberry now comes with 0.5GB and more.

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

debugger, inspector, compiler, interpreter, command line interface, debug info of those, ...

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

You get rid of any runtime interpretation and compilation. All that remains is a static C program.

> "Compiling to verbose cryptic C"

Then compile to readable C.

>All that remains is a static C program. That what i mean in "verbose cryptic C". Machine-generated C is huge and hard to comprehend in its entirety, with recursion and continuations practically impossible. It is just a step above from dis-assembled programs. C isn't some magic format that prevents bugs or ensures safety(in fact opposite of that, the larger the code the more bugs it will produce).

Which Lisp compiler output to C have you seen?

Many Lisp and Scheme compilers have C output. Embeddable Common Lisp https://common-lisp.net/project/ecl/ GNU Common Lisp http://www.gnu.org/software/gcl/ ManKai Common Lisp https://common-lisp.net/project/mkcl/ Clasp (C++ interop )https://github.com/drmeister/clasp ThinLisp https://sourceforge.net/projects/thinlisp/ https://github.com/aoh/owl-lisp

Bigloo Scheme CHICKEN Scheme Gambit Scheme https://github.com/justinethier/cyclone RScheme SCM Stalin

Whose output have you seen?

An example is GNU common lisp Run the below fizzbuzz with /usr/bin/gcl -batch -c-file -compile $1(below file) (declaim (optimize (safety 3) (debug 0) (speed 3))) (defun is-mult-p (n multiple) (= (rem n multiple) 0))

(defun fizzbuzz (&optional n) (let ((n (or n 1))) (if (> n 100) nil (progn (let ((mult-3 (is-mult-p n 3)) (mult-5 (is-mult-p n 5))) (if mult-3 (princ "Fizz")) (if mult-5 (princ "Buzz")) (if (not (or mult-3 mult-5)) (princ n)) (princ #\linefeed) (fizzbuzz (+ n 1)))))))

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

>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

What do you think of Python, then?

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.

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.

"Informed" about what? I don't blindly follow language evangelism. Its the Lisp advocate job to prove their language is as great as they claim. If for example a site provides an example of 25MB hello world, i can instantly estimate what kind of bloat i deal with and move on. I don't have to (declaim (optimize speed (safety 0))) and use a tree shaker to squeeze the bytes out of final executable just so that i can say SBCL (for example) is not a bloatware generator but these stupid users just forgot to add optimizations and tree-shake everything.

If you recognize Lisp as a family of languages, then there is still newLisp which only adds some 100kb to a executable. And for a lot of stuff it's fast enough.

Oh, I never heard of this one before. Thanks a bunch, it looks quite nice!

...although I code much more in Haskell nowadays, I might get hooked on macros again.

> > written in Macintosh Common Lisp needed 20 MB RAM

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

That's non sequitur. Lets quote the entire context:

> the Dylan IDE written in Macintosh Common Lisp needed 20 MB RAM

How much RAM other IDEs used at the time?

That's less memory than Firefox will leak between the time I end the last word of this sentence and type the punctuating period.

>That's non sequitur. At the time Dylan IDE existed it regularly consumed 3/4 of all RAM. So bragging about it being only 20MB is like bragging your app only consumes 12GB of RAM today.

That's the point. Today the same Lisp IDE would not need 12GB and would nicely run on a Raspberry Pi.

Only If you're fine with using twenty year old software and port it to modern hardware such as raspberry PI.