5 ms·

There have been some advances in language theory since Lisp, though. In particular, modern type inference allows you to practically eliminate type declarations

There have been some advances in language theory since Lisp, though. In particular, modern type inference allows you to practically eliminate type declarations and approximate the terseness and expressiveness of dynamic languages. Recent languages such as Crystal and Nim have demonstrated that this is entirely feasible. (I mentioned Go earlier, but Go is, if anything, regressive when it comes to language theory, and not a good example of how to do things right.) The Lisp example is only convincing if you've not seen what a really impressive type system can do; Haskell and the ML family come to mind, and Rust and Swift both seem promising in that regard, as does Crystal. "Less code means less bugs" is a powerful meme, but it's a misleading metric in the context of type systems. Dynamic languages necessarily require less code since they eliminate information that otherwise allows you to fully reason at compile time about the program's future execution, thereby eliminating the ability to guarantee its safety; and the opposite is also true: "less information means more bugs". Ultimately, it's less logic we want — less decisions that can go wrong. In Lisp, or any other dynamically typed language, you can pass a variable of the wrong type to a function and won't know it's wrong until you run the program — how did fewer lines of code help you? The equivalent program in a statically typed language might be slightly longer (though it could also be the same size), but the additional type declarations have made your program less buggy, not more.

braveo 10y ago
"less information means less bugs" is not the same thing as "less code means less bugs". Your entire argument there is a non-sequitur, no one who says "less code means less bugs" is talking about the mechanical aspect of typing out code. They're talking about a combination of using battle tested code and writing at a higher level of abstraction.
- lobster_johnson 10y ago
  I wasn't talking about "the mechanical aspect". And I did not claim anything like what your first sentence implies.
  - braveo 10y ago
    you treated the phrase literally.
kazinator 10y ago
> won't know it's wrong until you run the program That's a big problem, indeed, if your goal is to ship code that was never executed.
- lobster_johnson 10y ago
  But the whole point of type systems is that you can theoretically verify your code at a high level (though very few computer languages are able to approximate anything like a mathematical proof). I wrote about this in another comment, in the context of writing tests.
  - kazinator 10y ago
    In theory, practice is the same as theory. In practice, it isn't. I've seen only toy examples of some non-trivial program properties being encoded in type systems. It nowhere constituted proof of an entire program. Nobody actually does that. A lot can remain wrong in code which passes type checks. There is no "if it compiles, ship it". Not to mention that compilers can have bugs, and that hidden performance and resource problems can lie latent in high level languages.
    - njs12345 10y ago
      How about the property 'this variable is never null'? You might call this trivial but it seems to be useful given that real-world programmers get it wrong frequently: http://stackoverflow.com/search?tab=newest&q=NullPointerException http://stackoverflow.com/search?tab=newest&q=NullPointerExce... Or the property 'this variable is never used after a free' in a language with manual memory management (Rust encodes this) or 'this program is free from data races' (also Rust)? No one is arguing that strong static type systems make it impossible to write programs with bugs, but eliminating whole classes of bugs at compile time certainly makes it easier.
- lomnakkus 10y ago
  > if your goal is to ship code that was never executed. That's cute, but no. There's a lot of code that only gets executed once in a blue moon and if my experience[1] is anything to go by, this is where types really shine. (Before you say "tests": The amount of code bases I've experienced in dynamically checked languages with no meaningful test coverage is shocking. That, and tests can only show the presence of bugs.) Types are also hugely valuable as compiler-checked API documentation, especially if side effects can be document as in e.g. Haskell or Idris. (I'm obviously assuming non-trivial type inference as in e.g. Haskell or O'Caml. If we're talking anemic type systems like Java or C#, then the trade-off becomes a lot harder to justify, at least for me. In these cases you can indeed remove a non-trivial amount of "ceremonial" code and the type systems indeed have very few useful guarantees like non-nullness and such.) [1] We're all trading anecdotes here, let's be honest about that.
lispm 10y ago
> dynamic languages Dynamically typed languages. > In particular, modern type inference allows you to practically eliminate type declarations and approximate the terseness and expressiveness of dynamic languages. Not of dynamic languages. > require less code since they eliminate information that otherwise allows you to fully reason The idea of Lisp is to have a lot of information at runtime/development time. One develops running software, not a program as text. The running software gives the feedback. These discussions are thirty years old now. Since then everyone saw the type systems of the day as advanced and modern. Haskell is actually also quite old now... Lisp and Haskell are simply used in completely different ways to develop software. I would also bet that there are much larger Lisp programs than Haskell programs in use. A large Lisp program can be several million lines of code, like some Lisp-based CAD applications.

braveo 10y ago

"less information means less bugs" is not the same thing as "less code means less bugs". Your entire argument there is a non-sequitur, no one who says "less code means less bugs" is talking about the mechanical aspect of typing out code. They're talking about a combination of using battle tested code and writing at a higher level of abstraction.

lobster_johnson 10y ago
I wasn't talking about "the mechanical aspect". And I did not claim anything like what your first sentence implies.
- braveo 10y ago
  you treated the phrase literally.

kazinator 10y ago

> won't know it's wrong until you run the program That's a big problem, indeed, if your goal is to ship code that was never executed.

lobster_johnson 10y ago
But the whole point of type systems is that you can theoretically verify your code at a high level (though very few computer languages are able to approximate anything like a mathematical proof). I wrote about this in another comment, in the context of writing tests.
- kazinator 10y ago
  In theory, practice is the same as theory. In practice, it isn't. I've seen only toy examples of some non-trivial program properties being encoded in type systems. It nowhere constituted proof of an entire program. Nobody actually does that. A lot can remain wrong in code which passes type checks. There is no "if it compiles, ship it". Not to mention that compilers can have bugs, and that hidden performance and resource problems can lie latent in high level languages.
  - njs12345 10y ago
    How about the property 'this variable is never null'? You might call this trivial but it seems to be useful given that real-world programmers get it wrong frequently: http://stackoverflow.com/search?tab=newest&q=NullPointerException http://stackoverflow.com/search?tab=newest&q=NullPointerExce... Or the property 'this variable is never used after a free' in a language with manual memory management (Rust encodes this) or 'this program is free from data races' (also Rust)? No one is arguing that strong static type systems make it impossible to write programs with bugs, but eliminating whole classes of bugs at compile time certainly makes it easier.
lomnakkus 10y ago
> if your goal is to ship code that was never executed. That's cute, but no. There's a lot of code that only gets executed once in a blue moon and if my experience[1] is anything to go by, this is where types really shine. (Before you say "tests": The amount of code bases I've experienced in dynamically checked languages with no meaningful test coverage is shocking. That, and tests can only show the presence of bugs.) Types are also hugely valuable as compiler-checked API documentation, especially if side effects can be document as in e.g. Haskell or Idris. (I'm obviously assuming non-trivial type inference as in e.g. Haskell or O'Caml. If we're talking anemic type systems like Java or C#, then the trade-off becomes a lot harder to justify, at least for me. In these cases you can indeed remove a non-trivial amount of "ceremonial" code and the type systems indeed have very few useful guarantees like non-nullness and such.) [1] We're all trading anecdotes here, let's be honest about that.

lispm 10y ago

> dynamic languages Dynamically typed languages. > In particular, modern type inference allows you to practically eliminate type declarations and approximate the terseness and expressiveness of dynamic languages. Not of dynamic languages. > require less code since they eliminate information that otherwise allows you to fully reason The idea of Lisp is to have a lot of information at runtime/development time. One develops running software, not a program as text. The running software gives the feedback. These discussions are thirty years old now. Since then everyone saw the type systems of the day as advanced and modern. Haskell is actually also quite old now... Lisp and Haskell are simply used in completely different ways to develop software. I would also bet that there are much larger Lisp programs than Haskell programs in use. A large Lisp program can be several million lines of code, like some Lisp-based CAD applications.