6 ms·

For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears t

by fouric 2y ago

For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears to be that, while both compile down to C/object code, CRUNCH is additionally targeting a statically-typed subset of Scheme. Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference in expressiveness between program semantics and type semantics (and runtime vs tooling) for much of computing. Now that types and tools are advancing, static Lisps are feasible, and I love that.

stefantalpalaru 2y ago
[dead]
diggan 2y ago
> Now that types and tools are advancing, static Lisps are feasible, and I love that. Haven't that been feasible for a pretty long time already? Judging by how well-received (or not) they've been, it seems there isn't much demand for it. Things like clojure.spec and alike (compile-time + run-time typing) seems much more popular, but isn't static.
- nesarkvechnep 2y ago
  There isn’t much demand for Lisps in general.
  - stolen_biscuit 2y ago
    I think given the sheer amount of them that is demonstrably false
    - cjaybo 2y ago
      Many have been created, but how many have significant usage?
    - CyberDildonics 2y ago
      People make a lot as their side projects through the easy parsing, what software is being made with them? (besides the usual hacker news backend response)
    - nesarkvechnep 2y ago
      Have you used one at work? I would surely love to but haven’t had the chance yet.
      - sjamaan 2y ago
        Clojure is fairly popular (I'm using it at work, though I'd prefer Scheme of course)
      - sjamaan 2y ago
        Apropos, this crossed my feedreader today: https://lispjobs.wordpress.com/2024/12/19/mid-senior-clojure-developers-akosweb-latam/ https://lispjobs.wordpress.com/2024/12/19/mid-senior-clojure...
jnxx 2y ago
What are the main differences between OcamML and a statically typed Lisp?
- packetlost 2y ago
  Type inference is probably the biggest thing. You would need explicit "phases" to expand macros, disallow macro expansion at runtime, and implement bi-directional type inference HM-style to get even close to what OCaml has. To be honest, I'd kill for a Lisp that had the same type system as OCaml, but I suspect the closes we'll get is basically Rust (whose macro system is quite good).
  - shawn_w 2y ago
    Racket has Typed Racket, which while not Hindley-Miller can do some type inference. There's also the plait language which says its type system is similar to ML: https://docs.racket-lang.org/plait/index.html https://docs.racket-lang.org/plait/index.html And Hackett, inspired by Haskell: https://lexi-lambda.github.io/hackett/ https://lexi-lambda.github.io/hackett/ And Common Lisp has coalton: https://coalton-lang.github.io/ https://coalton-lang.github.io/
    - packetlost 2y ago
      Most of those aren't really ready for production use except maybe Typed Racket, which I consider to be too "weak" and took a route with annotations that I'm not a fan of. Coalton is very interesting, I've been following it for a bit. Carp [0] is another one that I've been following. [0]: https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp
      - reikonomusha 2y ago
        Coalton is used in production for quantum computing systems and soft real-time control system automation. There are also (a small number of) Coalton jobs.
dokyun 2y ago
I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case of Lisp is a combination of dynamicity and some stronger typing features that can be applied during the optimization stage. The dynamic nature and ease of use of Lisp relative to its performance is one of its greatest assets: it would be nearsighted to try and sacrifice that--a good Lisp programmer can optimize the important parts of his programs such that they're comparable to or even outperform their equivalents in other more ``high-performance'' languages. With that being said, these developments might bring us closer to a ``sufficiently smart compiler'' that could make that latter stage mostly unnecessary.
- nathan_compton 2y ago
  I don't think it makes sense to conflate Lispers to Schemers. I've programmed in both languages but have a stronger affinity for Scheme partially because semantically it is less flexible and more "staticy" than Lisp. Philosophically, the languages tend to attract different personalities (to the extent that the highly fragmentary Scheme world can be characterized).
- kazinator 2y ago
  I want static types in a higher level assembly language for systems programming. That's because I want to work with machine-level representations, in which there are no spare bits for indicating type at run-time (moreover, using such a language, we can design a type system with such bits, in any way we please). I don't want static types in a high level language. It's just counterproductive. We only have to look at numbers to feel how it sucks. If we divide two integers in Common Lisp, if the division is exact, the object that comes out is an integer. Otherwise we get a ratio object. Or if we take a square root of a real, we get a complex number if the input is negative, otherwise real. This cannot be modeled effectively in a static system. You can use a sum type, but that's just a greenspunned ad hoc dynamic type.

by fouric 2y ago

stefantalpalaru 2y ago

[dead]

diggan 2y ago

> Now that types and tools are advancing, static Lisps are feasible, and I love that. Haven't that been feasible for a pretty long time already? Judging by how well-received (or not) they've been, it seems there isn't much demand for it. Things like clojure.spec and alike (compile-time + run-time typing) seems much more popular, but isn't static.

nesarkvechnep 2y ago
There isn’t much demand for Lisps in general.
- stolen_biscuit 2y ago
  I think given the sheer amount of them that is demonstrably false
  - cjaybo 2y ago
    Many have been created, but how many have significant usage?
  - CyberDildonics 2y ago
    People make a lot as their side projects through the easy parsing, what software is being made with them? (besides the usual hacker news backend response)
  - nesarkvechnep 2y ago
    Have you used one at work? I would surely love to but haven’t had the chance yet.
    - sjamaan 2y ago
      Clojure is fairly popular (I'm using it at work, though I'd prefer Scheme of course)
    - sjamaan 2y ago
      Apropos, this crossed my feedreader today: https://lispjobs.wordpress.com/2024/12/19/mid-senior-clojure-developers-akosweb-latam/ https://lispjobs.wordpress.com/2024/12/19/mid-senior-clojure...

jnxx 2y ago

What are the main differences between OcamML and a statically typed Lisp?

packetlost 2y ago
Type inference is probably the biggest thing. You would need explicit "phases" to expand macros, disallow macro expansion at runtime, and implement bi-directional type inference HM-style to get even close to what OCaml has. To be honest, I'd kill for a Lisp that had the same type system as OCaml, but I suspect the closes we'll get is basically Rust (whose macro system is quite good).
- shawn_w 2y ago
  Racket has Typed Racket, which while not Hindley-Miller can do some type inference. There's also the plait language which says its type system is similar to ML: https://docs.racket-lang.org/plait/index.html https://docs.racket-lang.org/plait/index.html And Hackett, inspired by Haskell: https://lexi-lambda.github.io/hackett/ https://lexi-lambda.github.io/hackett/ And Common Lisp has coalton: https://coalton-lang.github.io/ https://coalton-lang.github.io/
  - packetlost 2y ago
    Most of those aren't really ready for production use except maybe Typed Racket, which I consider to be too "weak" and took a route with annotations that I'm not a fan of. Coalton is very interesting, I've been following it for a bit. Carp [0] is another one that I've been following. [0]: https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp
    - reikonomusha 2y ago
      Coalton is used in production for quantum computing systems and soft real-time control system automation. There are also (a small number of) Coalton jobs.

dokyun 2y ago

I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case of Lisp is a combination of dynamicity and some stronger typing features that can be applied during the optimization stage. The dynamic nature and ease of use of Lisp relative to its performance is one of its greatest assets: it would be nearsighted to try and sacrifice that--a good Lisp programmer can optimize the important parts of his programs such that they're comparable to or even outperform their equivalents in other more ``high-performance'' languages. With that being said, these developments might bring us closer to a ``sufficiently smart compiler'' that could make that latter stage mostly unnecessary.

nathan_compton 2y ago
I don't think it makes sense to conflate Lispers to Schemers. I've programmed in both languages but have a stronger affinity for Scheme partially because semantically it is less flexible and more "staticy" than Lisp. Philosophically, the languages tend to attract different personalities (to the extent that the highly fragmentary Scheme world can be characterized).
kazinator 2y ago
I want static types in a higher level assembly language for systems programming. That's because I want to work with machine-level representations, in which there are no spare bits for indicating type at run-time (moreover, using such a language, we can design a type system with such bits, in any way we please). I don't want static types in a high level language. It's just counterproductive. We only have to look at numbers to feel how it sucks. If we divide two integers in Common Lisp, if the division is exact, the object that comes out is an integer. Otherwise we get a ratio object. Or if we take a square root of a real, we get a complex number if the input is negative, otherwise real. This cannot be modeled effectively in a static system. You can use a sum type, but that's just a greenspunned ad hoc dynamic type.