4 ms·

Is there a philosophical reason why Lisp is generally dynamically typed, or is it mostly an artifact of history? Would anything of value of Lisp be lost beyond

Is there a philosophical reason why Lisp is generally dynamically typed, or is it mostly an artifact of history? Would anything of value of Lisp be lost beyond the typical trade-offs you see mentioned in every static vs dynamic debate, such as up-front ease of development?

chimeracoder 14y ago
You can test it out yourself: http://docs.racket-lang.org/ts-guide/ http://docs.racket-lang.org/ts-guide/ Typed Racket lets you easily migrate portions (or the entirety) of a dynamically typed codebase into an equivalent statically-typed version. You get the best of both - easy prototyping with dynamic typing, robustness and scalability of static typing, and then the flexibility of applying those choices to parts of your codebase while keeping everything completely interoperable.
- akurilin 14y ago
  Neat, thanks for the link!
rayiner 14y ago
Lisp both predates static type systems, and has a philosophical bent towards "late binding" to the maximum extent possible. In terms of what you'd lose--eval() for one. It's only been relatively recently that decent type inference has been integrated with interactive execution (GHCi), but I think it's possible (though GHCi is still more limited and cumbersome than full batch GHC).
- dons 14y ago
  Eval is well understood in the context of static typing, since the early 90s with Nilsson and Pfenning. So about 20 years now... GHCi is a bytecode interpreter for Haskell, it supports the full Haskell+GHC type system -- and has very little to do with eval() or your comment.
  - dons 14y ago
    Also, hbi, the first bytecode interpreter for full Haskell, is 23 years old now... There's no excuse anymore to be ignorant of "modern" static typing - a quarter of a century is long enough.
    - akkartik 14y ago
      I found both your comments exceptionally useful until the last sentence. There's plenty of excuse since it isn't being taught in undergrad computer science courses, etc. As one sample point, I have a PhD from a top-10 US institution. Partially in compilers. I'm motivated everyday to learn about programming. I hack on interpreters in my spare time. A lot. I am utterly 'ignorant of modern static typing'. Setting aside modesty, I'll submit that it isn't my fault.
      - dons 14y ago
        Yeah, my comment is really more aimed at the schools that are teaching language design as if it was 1971. And you can always get a copy of TAPL, Types and Programming Languages Benjamin C. Pierce February 1, 2002 ISBN-10: 0262162091 --- And there's a typo above, Nilsson should be "Nielson", as in: "Flemming Nielson and Hanne Riis Nielson. Two-Level Functional Languages. Cambridge University Press, 1992. The Pfenning paper I was thinking of was the S4 stuff: A Modal Analysis of Staged Computation Rowan Davies and Frank Pfenning, 1996
    - oddthink 14y ago
      By similar logic, quantum field theory is about 40 years old, so really there's no excuse to be ignorant of it, either. I kid, but only somewhat. Relevancy (even if just perceived) and accessibility matter.
      - dons 14y ago
        If you're a professional in the field of partical physics, there's probably not excuse...
martinced 14y ago
It's just historical. And Lisps being so powerful you can actually use the language itself to add type safety to it and there's no need for a lot of code (typed Clojure --although not perfect yet-- is quite small, for example). The great thing is that you also don't need to do it yourself because there are people working on the issue. With the Lisp "revival" and especially all the coders re-discovering Lisp nowadays I expect to see more and more research in that area and it's pretty exciting. We'll soon get Emacs (or IDEs) warning us in realtime about type errors ; )
emillon 14y ago
Macros are an important part of lisps, and it's hard (as in impossible in the general case) to verify that they are type-preserving.
- samth 14y ago
  Fortunately, you can write a sound type system for a Lisp without needing to verify individual macros. That's what Typed Racket does, described in this paper: http://www.ccs.neu.edu/racket/pubs/pldi11-thacff.pdf http://www.ccs.neu.edu/racket/pubs/pldi11-thacff.pdf The basic idea is to first expand the whole program (really the whole module) and then to type check the fully expanded code, which doesn't have macros.
deleted 14y ago
[deleted]

chimeracoder 14y ago

You can test it out yourself: http://docs.racket-lang.org/ts-guide/ http://docs.racket-lang.org/ts-guide/ Typed Racket lets you easily migrate portions (or the entirety) of a dynamically typed codebase into an equivalent statically-typed version. You get the best of both - easy prototyping with dynamic typing, robustness and scalability of static typing, and then the flexibility of applying those choices to parts of your codebase while keeping everything completely interoperable.

akurilin 14y ago
Neat, thanks for the link!

rayiner 14y ago

Lisp both predates static type systems, and has a philosophical bent towards "late binding" to the maximum extent possible. In terms of what you'd lose--eval() for one. It's only been relatively recently that decent type inference has been integrated with interactive execution (GHCi), but I think it's possible (though GHCi is still more limited and cumbersome than full batch GHC).

dons 14y ago
Eval is well understood in the context of static typing, since the early 90s with Nilsson and Pfenning. So about 20 years now... GHCi is a bytecode interpreter for Haskell, it supports the full Haskell+GHC type system -- and has very little to do with eval() or your comment.
- dons 14y ago
  Also, hbi, the first bytecode interpreter for full Haskell, is 23 years old now... There's no excuse anymore to be ignorant of "modern" static typing - a quarter of a century is long enough.
  - akkartik 14y ago
    I found both your comments exceptionally useful until the last sentence. There's plenty of excuse since it isn't being taught in undergrad computer science courses, etc. As one sample point, I have a PhD from a top-10 US institution. Partially in compilers. I'm motivated everyday to learn about programming. I hack on interpreters in my spare time. A lot. I am utterly 'ignorant of modern static typing'. Setting aside modesty, I'll submit that it isn't my fault.
    - dons 14y ago
      Yeah, my comment is really more aimed at the schools that are teaching language design as if it was 1971. And you can always get a copy of TAPL, Types and Programming Languages Benjamin C. Pierce February 1, 2002 ISBN-10: 0262162091 --- And there's a typo above, Nilsson should be "Nielson", as in: "Flemming Nielson and Hanne Riis Nielson. Two-Level Functional Languages. Cambridge University Press, 1992. The Pfenning paper I was thinking of was the S4 stuff: A Modal Analysis of Staged Computation Rowan Davies and Frank Pfenning, 1996
  - oddthink 14y ago
    By similar logic, quantum field theory is about 40 years old, so really there's no excuse to be ignorant of it, either. I kid, but only somewhat. Relevancy (even if just perceived) and accessibility matter.
    - dons 14y ago
      If you're a professional in the field of partical physics, there's probably not excuse...

martinced 14y ago

It's just historical. And Lisps being so powerful you can actually use the language itself to add type safety to it and there's no need for a lot of code (typed Clojure --although not perfect yet-- is quite small, for example). The great thing is that you also don't need to do it yourself because there are people working on the issue. With the Lisp "revival" and especially all the coders re-discovering Lisp nowadays I expect to see more and more research in that area and it's pretty exciting. We'll soon get Emacs (or IDEs) warning us in realtime about type errors ; )

emillon 14y ago

Macros are an important part of lisps, and it's hard (as in impossible in the general case) to verify that they are type-preserving.

samth 14y ago
Fortunately, you can write a sound type system for a Lisp without needing to verify individual macros. That's what Typed Racket does, described in this paper: http://www.ccs.neu.edu/racket/pubs/pldi11-thacff.pdf http://www.ccs.neu.edu/racket/pubs/pldi11-thacff.pdf The basic idea is to first expand the whole program (really the whole module) and then to type check the fully expanded code, which doesn't have macros.

deleted 14y ago

[deleted]