5 ms·

>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

>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.esoteriq.org/hellosize.html https://web.archive.org/web/20090324024745/http://mbishop.es... >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 9y ago
> 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 9y ago
  >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
  - ealhad 9y ago
    What do you think of Python, then?
  - armitron 9y ago
    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 9y ago
      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.
    - FrozenVoid 9y ago
      "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.
- someSven 9y ago
  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.
  - ealhad 9y ago
    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.
throwaway1X2 9y ago
> > 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?
- kazinator 9y ago
  That's less memory than Firefox will leak between the time I end the last word of this sentence and type the punctuating period.
- FrozenVoid 9y ago
  >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.
  - lispm 9y ago
    That's the point. Today the same Lisp IDE would not need 12GB and would nicely run on a Raspberry Pi.
    - FrozenVoid 9y ago
      Only If you're fine with using twenty year old software and port it to modern hardware such as raspberry PI.
lispm 9y ago
> 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.
- FrozenVoid 9y ago
  >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).
  - lispm 9y ago
    Which Lisp compiler output to C have you seen?
    - FrozenVoid 9y ago
      Many Lisp and Scheme compilers have C output. Embeddable Common Lisp https://common-lisp.net/project/ecl/ https://common-lisp.net/project/ecl/ GNU Common Lisp http://www.gnu.org/software/gcl/ http://www.gnu.org/software/gcl/ ManKai Common Lisp https://common-lisp.net/project/mkcl/ https://common-lisp.net/project/mkcl/ Clasp (C++ interop )https://github.com/drmeister/clasp https://github.com/drmeister/clasp ThinLisp https://sourceforge.net/projects/thinlisp/ https://sourceforge.net/projects/thinlisp/ https://github.com/aoh/owl-lisp https://github.com/aoh/owl-lisp Bigloo Scheme CHICKEN Scheme Gambit Scheme https://github.com/justinethier/cyclone https://github.com/justinethier/cyclone RScheme SCM Stalin

ealhad 9y ago

> 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 9y ago
>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
- ealhad 9y ago
  What do you think of Python, then?
- armitron 9y ago
  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 9y ago
    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.
  - FrozenVoid 9y ago
    "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.
someSven 9y ago
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.
- ealhad 9y ago
  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.

throwaway1X2 9y ago

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

kazinator 9y ago
That's less memory than Firefox will leak between the time I end the last word of this sentence and type the punctuating period.
FrozenVoid 9y ago
>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.
- lispm 9y ago
  That's the point. Today the same Lisp IDE would not need 12GB and would nicely run on a Raspberry Pi.
  - FrozenVoid 9y ago
    Only If you're fine with using twenty year old software and port it to modern hardware such as raspberry PI.

lispm 9y ago

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

FrozenVoid 9y ago
>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).
- lispm 9y ago
  Which Lisp compiler output to C have you seen?
  - FrozenVoid 9y ago
    Many Lisp and Scheme compilers have C output. Embeddable Common Lisp https://common-lisp.net/project/ecl/ https://common-lisp.net/project/ecl/ GNU Common Lisp http://www.gnu.org/software/gcl/ http://www.gnu.org/software/gcl/ ManKai Common Lisp https://common-lisp.net/project/mkcl/ https://common-lisp.net/project/mkcl/ Clasp (C++ interop )https://github.com/drmeister/clasp https://github.com/drmeister/clasp ThinLisp https://sourceforge.net/projects/thinlisp/ https://sourceforge.net/projects/thinlisp/ https://github.com/aoh/owl-lisp https://github.com/aoh/owl-lisp Bigloo Scheme CHICKEN Scheme Gambit Scheme https://github.com/justinethier/cyclone https://github.com/justinethier/cyclone RScheme SCM Stalin