8 ms·

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 prevent

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 9y ago
> 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.htm http://www.lispworks.com/documentation/lw70/DV/html/delivery... > 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 9y ago
  >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?
      - 9y ago
nine_k 9y ago
Have you tried applying the same logic to Ruby, Python, or Javascript? All three are widely used.
- rhaps0dy 9y ago
  These don't use linked lists though, they use array-based resizable lists, which are faster with modern cache architectures. (that's only part of point 2 though.)
wtetzner 9y ago
> 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. Do you have any evidence that this happens? I always see this as an argument against macros, but I don't actually see this problem manifesting in practice. In fact, macros are much less scary than monkey patching like in Ruby or Javascript, because a macro can only affect the code within the particular invocation, and it must be imported to be used. Also, the success of Rails seems to suggest that creating specialized DSLs can be a big benefit.
topkekz 9y ago
There are lisps being worked on to resolve points 1, 2, and 4. https://github.com/tomhrr/dale https://github.com/tomhrr/dale https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp
flavio81 9y ago
1.GC that prevents it from using real-time and performance-oriented code. Lisp is a great language but it can't be the silver bullet for everything. If you need hard real-time programming you need to look elsewhere. The same is true of Ruby, Python, C#, and other popular, well-accepted languages. 2.Pervasive use of inefficient lists and dynamic typing, which puts steep memory requirements on top of performance costs. The same is true of Ruby, Python, C#, and other popular, well-accepted languages. And how can you speak about "inefficient" lists? Lisp uses linked-lists which is an efficient data type in the context of recursive functions, which Lisp coders make extensive use of. 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. The whole point of creating a Domain-Specific-Language and then express the problem using the DSL is to, precisely, go away from unreadable code and spaghetti code. It seems you have not used Lisp enough. 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) Common Lisp is generally faster than most of the scripting languages out there (Ruby, Python, Perl), and in reality approaches C speed... As for "Lisp requires eval() and runtime interpretation", this is not true. You need to read more about the Lisp compilation model. 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). "It even allows the programs to be modified at runtime". You mean allow the program to self-modify, right? How horrible, how sinful!! I guess we should stay with statically linked, statically compiled, statically typed, procedural-only, manually-memory-managed, code. I guess we should all go back to Algol-60 then.

lispm 9y ago

> 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.htm http://www.lispworks.com/documentation/lw70/DV/html/delivery... > 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 9y ago
>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?
    - 9y ago

nine_k 9y ago

Have you tried applying the same logic to Ruby, Python, or Javascript? All three are widely used.

rhaps0dy 9y ago
These don't use linked lists though, they use array-based resizable lists, which are faster with modern cache architectures. (that's only part of point 2 though.)

wtetzner 9y ago

> 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. Do you have any evidence that this happens? I always see this as an argument against macros, but I don't actually see this problem manifesting in practice. In fact, macros are much less scary than monkey patching like in Ruby or Javascript, because a macro can only affect the code within the particular invocation, and it must be imported to be used. Also, the success of Rails seems to suggest that creating specialized DSLs can be a big benefit.

topkekz 9y ago

There are lisps being worked on to resolve points 1, 2, and 4. https://github.com/tomhrr/dale https://github.com/tomhrr/dale https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp

flavio81 9y ago

1.GC that prevents it from using real-time and performance-oriented code. Lisp is a great language but it can't be the silver bullet for everything. If you need hard real-time programming you need to look elsewhere. The same is true of Ruby, Python, C#, and other popular, well-accepted languages. 2.Pervasive use of inefficient lists and dynamic typing, which puts steep memory requirements on top of performance costs. The same is true of Ruby, Python, C#, and other popular, well-accepted languages. And how can you speak about "inefficient" lists? Lisp uses linked-lists which is an efficient data type in the context of recursive functions, which Lisp coders make extensive use of. 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. The whole point of creating a Domain-Specific-Language and then express the problem using the DSL is to, precisely, go away from unreadable code and spaghetti code. It seems you have not used Lisp enough. 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) Common Lisp is generally faster than most of the scripting languages out there (Ruby, Python, Perl), and in reality approaches C speed... As for "Lisp requires eval() and runtime interpretation", this is not true. You need to read more about the Lisp compilation model. 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). "It even allows the programs to be modified at runtime". You mean allow the program to self-modify, right? How horrible, how sinful!! I guess we should stay with statically linked, statically compiled, statically typed, procedural-only, manually-memory-managed, code. I guess we should all go back to Algol-60 then.