4 ms·

I've worked on multiple large Java codebases, and on semi-large Clojure code bases. The Java ones compiled great but were full of bugs obscured by 100s of usele

I've worked on multiple large Java codebases, and on semi-large Clojure code bases. The Java ones compiled great but were full of bugs obscured by 100s of useless classes with bespoke interfaces. I found the Clojure code bases to be far more tractable because the language leads to better opportunities for abstraction and more concise code with way less incidental complexity. I think spec can add another layer of description where it's useful (and is not required where it's not).

hota_mazi 8y ago
That's anecdotal, and probably more a consequence of the seniority of the engineers who wrote these two code bases than the nature of the type systems. My point about static type systems is broader and actually backed by science and mathematics. And also, just observing the trend and seeing where the wind blows.
- puredanger 8y ago
  Oh, do tell? Please point me at the scientific and mathematical evidence. I would be interested to see it.
  - Roboprog 8y ago
    Indeed. I’ve googled for this research, and there isn’t much of it - just something that “everybody knows”. The best, recent thing I found was a study done about 5 years ago or so (I think) by a fellow at UC Davis, and the data were pretty weak. Functional programming, and the requisite memory management, had at least as big an effect as static typing. At this point some Haskell snob steps in and say “sound typing”... :-) http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
  - jakebasile 8y ago
    You'll never get it because there isn't any. Static vs dynamic typing is largely a matter of preference despite all the hooting from the recent static typing fad. I truly wish this "apparent truism" would go away, since it commonly turns to people flaming dynamic languages as somehow inherently lesser than those with big fancy type checkers.
  - hota_mazi 8y ago
    Google the Curry Howard isomorphism. In a nutshell, you can mathematically prove a certain degree of soundness of your code when you have type annotations. There is no such thing in dynamically typed languages.
    - puredanger 8y ago
      I guess that's why all those statically typed programs don't have any bugs and don't need any tests. Being "sound" just means you can prove things are consistent with the assumptions you can encode in it. If there are things you can't encode in the types, or if your assumptions are wrong (misapprehension being one of the main problems in software), or if your requirements change, soundness is not going to save you. Static types and proofs are valuable. Programs like compilers have fixed inputs and outputs and are excellent places to lean on things you can prove. But most of the programs I've worked on are not like compilers. They run for years, the requirements change, they have to deal with dirty data, talk to other messy systems, etc. And I'm not saying that dynamic types are perfect either. My point is simply that static types are not a magical end goal of programming. They are a tool with tradeoffs.
      - hota_mazi 8y ago
        > I guess that's why all those statically typed programs don't have any bugs and don't need any tests. This is both a straw man and a fallacy. Nicely done. Also something I never claimed. You are basically saying that since you can't prove a program can be 100% demonstrated to be correct, there's no point in trying to approach this goal, therefore dynamically typed languages are good enough. With your reasoning, we wouldn't be using safety belts because they can't guarantee you'll survive a car crash 100%. Sure, static types have trade offs, but they are a clear improvement on all dimensions over dynamic types, which is why we see dynamic languages converging toward static typing and never the other way around. In ten years from now, we'll look at dynamically typed languages as "It looked cool at the time, but we know better now". A bit like we look at FORTRAN and COBOL today.
        puredanger 8y ago

hota_mazi 8y ago

That's anecdotal, and probably more a consequence of the seniority of the engineers who wrote these two code bases than the nature of the type systems. My point about static type systems is broader and actually backed by science and mathematics. And also, just observing the trend and seeing where the wind blows.

puredanger 8y ago
Oh, do tell? Please point me at the scientific and mathematical evidence. I would be interested to see it.
- Roboprog 8y ago
  Indeed. I’ve googled for this research, and there isn’t much of it - just something that “everybody knows”. The best, recent thing I found was a study done about 5 years ago or so (I think) by a fellow at UC Davis, and the data were pretty weak. Functional programming, and the requisite memory management, had at least as big an effect as static typing. At this point some Haskell snob steps in and say “sound typing”... :-) http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
- jakebasile 8y ago
  You'll never get it because there isn't any. Static vs dynamic typing is largely a matter of preference despite all the hooting from the recent static typing fad. I truly wish this "apparent truism" would go away, since it commonly turns to people flaming dynamic languages as somehow inherently lesser than those with big fancy type checkers.
- hota_mazi 8y ago
  Google the Curry Howard isomorphism. In a nutshell, you can mathematically prove a certain degree of soundness of your code when you have type annotations. There is no such thing in dynamically typed languages.
  - puredanger 8y ago
    I guess that's why all those statically typed programs don't have any bugs and don't need any tests. Being "sound" just means you can prove things are consistent with the assumptions you can encode in it. If there are things you can't encode in the types, or if your assumptions are wrong (misapprehension being one of the main problems in software), or if your requirements change, soundness is not going to save you. Static types and proofs are valuable. Programs like compilers have fixed inputs and outputs and are excellent places to lean on things you can prove. But most of the programs I've worked on are not like compilers. They run for years, the requirements change, they have to deal with dirty data, talk to other messy systems, etc. And I'm not saying that dynamic types are perfect either. My point is simply that static types are not a magical end goal of programming. They are a tool with tradeoffs.
    - hota_mazi 8y ago
      > I guess that's why all those statically typed programs don't have any bugs and don't need any tests. This is both a straw man and a fallacy. Nicely done. Also something I never claimed. You are basically saying that since you can't prove a program can be 100% demonstrated to be correct, there's no point in trying to approach this goal, therefore dynamically typed languages are good enough. With your reasoning, we wouldn't be using safety belts because they can't guarantee you'll survive a car crash 100%. Sure, static types have trade offs, but they are a clear improvement on all dimensions over dynamic types, which is why we see dynamic languages converging toward static typing and never the other way around. In ten years from now, we'll look at dynamically typed languages as "It looked cool at the time, but we know better now". A bit like we look at FORTRAN and COBOL today.
      - puredanger 8y ago