7 ms·

So what does Lisp make harder to implement than today's programming languages? It seems like large-scale composition relies on a well-structured way to define

by trevyn 6y ago

So what does Lisp make harder to implement than today's programming languages? It seems like large-scale composition relies on a well-structured way to define and enforce APIs, and oh wow, typing facilities. Performance has historically been an issue for Lisp because its model is tightly tied to interpretation, but perhaps modern JIT-style compilation can address this. Others? What type of issues do large Lisp projects typically run into?

Jtsummers 6y ago
Common Lisp has long been a compiled language. Its performance is quite competitive when set against Fortran and C. The idea that it's interpreted (and consequently slow) is a very old myth. Of course, it helps to use the right data structures if you want fast Lisp code (using lists for everything is not the right choice).
- username90 6y ago
  > Its performance is quite competitive when set against Fortran and C. No, not at all. It is the same level as Java, a bit slower but I guess that is because there is more work done on Java. Just because you compile a language doesn't mean it is as fast as other compiled languages. You can compile python down to a binary but it will still be super slow.
  - minerjoe 6y ago
    Where do you get your information? SBCL has been shown to be, when optimized, within the same order of magnitude as C. https://news.ycombinator.com/item?id=2192629 https://news.ycombinator.com/item?id=2192629
    - TheRealKing 6y ago
      If you read the discussions to end, you will notice many objections to the benchmark that you have posted here. Even I have objections. -O3 is not the end of all possible optimizations in C and Fortran.
      - minerjoe 6y ago
        I hear you, but I was lazy and only gave one reference. There have been, over the years, many demostrations of optimized SBCL being on the same order as C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/sbcl-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://drmeister.wordpress.com/2015/07/30/timing-data-comparing-cclasp-to-c-sbcl-and-python/ https://drmeister.wordpress.com/2015/07/30/timing-data-compa... https://groups.google.com/forum/?_escaped_fragment_=topic/comp.lang.lisp/JfsiCh2pdfs https://groups.google.com/forum/?_escaped_fragment_=topic/co...
    - igouy 6y ago
      > within the same order of magnitude That could mean 9x slower? 990 seconds instead of 110 seconds.
donio 6y ago
> Performance has historically been an issue for Lisp because its model is tightly tied to interpretation That hasn't been true since 1962.
Reelin 6y ago
> a well-structured way to define and enforce APIs I don't see the issue here? What do you think is stopping you from doing this in, for example, Common Lisp? > and oh wow, typing facilities Common Lisp isn't typed, but there's no reason a Lisp dialect can't be. In fact, Typed Racket is just such a language.
- ywei3410 6y ago
  Hell, to go even further you can implement your own type system on top of Racket's macro system; or better yet, use a macro DSL specifically created for type systems to implement your type system. [1] [1] https://docs.racket-lang.org/turnstile/ https://docs.racket-lang.org/turnstile/
- Jtsummers 6y ago
  Common Lisp is typed. It is not (consistently, see SBCL for a counterexample) statically typed. If you try to do: (+ "hello" 3) You will get an error in CL, and with SBCL an expression like that wouldn't even compile.
  - Reelin 6y ago
    Yes, I'm aware (see my nearby comment for more detail). I very much enjoy writing Common Lisp, but use SBCL almost exclusively specifically because of the amount of (static) type checking it does. Even then, there are significant limitations that often leave me frustrated in comparison.
- flavio81 6y ago
  >Common Lisp isn't typed It is heavily typed. Very strongly typed for the most part (except numbers). So typed that it won't accept a "character vector" in the place of a string. But type checking is mostly at runtime, not at compile-time. The good part is that you can edit your program at runtime and restart it at the exact point the error happened, very easily.
  - Reelin 6y ago
    In context, particularly given the reference I made to Typed Racket, it should be abundantly clear that I'm referring to the lack of static typing there. That being said, I think you'll find truly untyped languages hard to come by. Other than assembly, Forth (similar to assembly in many ways), and esolangs such as Befunge (also quite similar to assembly), languages that see widespread use always check types eventually. Checking types eventually is table stakes. Checking types at compile time, before what you wrote has a chance to explode on you in an unpredictable manner when that one branch for an edge case finally gets taken after a few days of uptime, that's the truly desirable feature that not all languages manage to provide.

by trevyn 6y ago

Jtsummers 6y ago

Common Lisp has long been a compiled language. Its performance is quite competitive when set against Fortran and C. The idea that it's interpreted (and consequently slow) is a very old myth. Of course, it helps to use the right data structures if you want fast Lisp code (using lists for everything is not the right choice).

username90 6y ago
> Its performance is quite competitive when set against Fortran and C. No, not at all. It is the same level as Java, a bit slower but I guess that is because there is more work done on Java. Just because you compile a language doesn't mean it is as fast as other compiled languages. You can compile python down to a binary but it will still be super slow.
- minerjoe 6y ago
  Where do you get your information? SBCL has been shown to be, when optimized, within the same order of magnitude as C. https://news.ycombinator.com/item?id=2192629 https://news.ycombinator.com/item?id=2192629
  - TheRealKing 6y ago
    If you read the discussions to end, you will notice many objections to the benchmark that you have posted here. Even I have objections. -O3 is not the end of all possible optimizations in C and Fortran.
    - minerjoe 6y ago
      I hear you, but I was lazy and only gave one reference. There have been, over the years, many demostrations of optimized SBCL being on the same order as C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/sbcl-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://drmeister.wordpress.com/2015/07/30/timing-data-comparing-cclasp-to-c-sbcl-and-python/ https://drmeister.wordpress.com/2015/07/30/timing-data-compa... https://groups.google.com/forum/?_escaped_fragment_=topic/comp.lang.lisp/JfsiCh2pdfs https://groups.google.com/forum/?_escaped_fragment_=topic/co...
  - igouy 6y ago
    > within the same order of magnitude That could mean 9x slower? 990 seconds instead of 110 seconds.

donio 6y ago

> Performance has historically been an issue for Lisp because its model is tightly tied to interpretation That hasn't been true since 1962.

Reelin 6y ago

> a well-structured way to define and enforce APIs I don't see the issue here? What do you think is stopping you from doing this in, for example, Common Lisp? > and oh wow, typing facilities Common Lisp isn't typed, but there's no reason a Lisp dialect can't be. In fact, Typed Racket is just such a language.

ywei3410 6y ago
Hell, to go even further you can implement your own type system on top of Racket's macro system; or better yet, use a macro DSL specifically created for type systems to implement your type system. [1] [1] https://docs.racket-lang.org/turnstile/ https://docs.racket-lang.org/turnstile/
Jtsummers 6y ago
Common Lisp is typed. It is not (consistently, see SBCL for a counterexample) statically typed. If you try to do: (+ "hello" 3) You will get an error in CL, and with SBCL an expression like that wouldn't even compile.
- Reelin 6y ago
  Yes, I'm aware (see my nearby comment for more detail). I very much enjoy writing Common Lisp, but use SBCL almost exclusively specifically because of the amount of (static) type checking it does. Even then, there are significant limitations that often leave me frustrated in comparison.
flavio81 6y ago
>Common Lisp isn't typed It is heavily typed. Very strongly typed for the most part (except numbers). So typed that it won't accept a "character vector" in the place of a string. But type checking is mostly at runtime, not at compile-time. The good part is that you can edit your program at runtime and restart it at the exact point the error happened, very easily.
- Reelin 6y ago
  In context, particularly given the reference I made to Typed Racket, it should be abundantly clear that I'm referring to the lack of static typing there. That being said, I think you'll find truly untyped languages hard to come by. Other than assembly, Forth (similar to assembly in many ways), and esolangs such as Befunge (also quite similar to assembly), languages that see widespread use always check types eventually. Checking types eventually is table stakes. Checking types at compile time, before what you wrote has a chance to explode on you in an unpredictable manner when that one branch for an edge case finally gets taken after a few days of uptime, that's the truly desirable feature that not all languages manage to provide.