5 ms·

I'm old enough to remember sick of static typing, pointless indirection and mixed paradigm code. And thus the centralisation/decentralisation wheel turns again

I'm old enough to remember sick of static typing, pointless indirection and mixed paradigm code. And thus the centralisation/decentralisation wheel turns again because the new generation think they have discovered something new but ignore the lessons learned in the past. If only we could fix that human tendency with a code upgrade.

lmm 9y ago
No, we really have discovered something better. We oscillate but we are converging: these days all serious statically typed languages have some level of type inference, and all serious dynamically typed languages have some level of optional type checking. We end up overcorrecting each time - Ruby was an overly dynamic, unmaintainable response to the strictness of Java, and no doubt some post-Ruby languages go too far in the straitjacket direction - but at the same time languages on both sides are better than they were previously.
- neilwilson 9y ago
  Ruby has optional type checking. What do you think the testing regime is about? It's a compiler that is built for each project with types specific to the domain problem being solved. Language type checking misses the point. The types I want to check, and the extent I want to check them, are in the spec files. Go type inference, for example, is deeply primitive and an awful lot of Go code seems to spend its time implementing duck typing via work arounds. It looks an awful lot like dependency injection for the 2010s.
  - bjz_ 9y ago
    Go is a terrible example of a statically typed language. Now that is an example of a bunch of people not learning from the past - ie. the entire lineage of ML-based languages! A rich type system lets you mold and shape the types to fit nicely over your domain, effectively becoming a machine-verified DSL for your business problem. It will catch flaws in your mental model before you even begin to write tests or an implementation, and is a cheap way of sketching out your ideas and great documentation to have over the lifetime of your project. Of course you can't fit it exactly, so you need a smattering of spec tests, and probably some property-based tests for good measure to fill in the gaps.
    - neilwilson 9y ago
      Go is what people are using. And python for some reason which amuses me greatly given we have Julia.
  - lmm 9y ago
    > Language type checking misses the point. The types I want to check, and the extent I want to check them, are in the spec files. It's worth incorporating a way to express these things directly into the language proper. That way all your tools will understand them (e.g. automated refactoring will already know what needs to be updated) and you can talk about them in the language. > Go type inference, for example, is deeply primitive and an awful lot of Go code seems to spend its time implementing duck typing via work arounds. Yeah, Go is the exception. It's profoundly and proudly ignorant of 65 years of language design progress. If Go were the only language type system I had access to I'd think language type checking was pointless too.
bjz_ 9y ago
The difference is that we know there's something better than Java, C#, or C++ this time around. We have Typescript, Flow, Elm, Purescript, Haskell, Rust, OCaml, Idris, F*, Nim, Crystal, and more. Yes, some lessons have been forgotten that will have to be relearned, but on the whole we are improving. It's like how Andrew Whiles says[0] on how it's important to be forgetful to be a good mathematician: > It goes like this. You try one strategy on a problem. It fails. You retreat, dispirited. Later, having forgotten your bitter defeat, you try the same strategy again. Perhaps the process repeats. But eventually—again, thanks to your forgetfulness—you commit a slight error, a tiny deviation from the path you’ve tried several times. And suddenly, you succeed. I think we're a bit better than that, but it pays to remember it the next time you see the young whippersnappers publishing an NPM package doing the same thing you did years ago and deemed to be a failure. By all means, share the war stories with them - it's important we get better at appreciating history, but do it from a position of encouragement. They may yet succeed where you failed. :) - [0]: https://mathwithbaddrawings.com/2017/09/20/the-state-of-being-stuck/ https://mathwithbaddrawings.com/2017/09/20/the-state-of-bein...

lmm 9y ago

No, we really have discovered something better. We oscillate but we are converging: these days all serious statically typed languages have some level of type inference, and all serious dynamically typed languages have some level of optional type checking. We end up overcorrecting each time - Ruby was an overly dynamic, unmaintainable response to the strictness of Java, and no doubt some post-Ruby languages go too far in the straitjacket direction - but at the same time languages on both sides are better than they were previously.

neilwilson 9y ago
Ruby has optional type checking. What do you think the testing regime is about? It's a compiler that is built for each project with types specific to the domain problem being solved. Language type checking misses the point. The types I want to check, and the extent I want to check them, are in the spec files. Go type inference, for example, is deeply primitive and an awful lot of Go code seems to spend its time implementing duck typing via work arounds. It looks an awful lot like dependency injection for the 2010s.
- bjz_ 9y ago
  Go is a terrible example of a statically typed language. Now that is an example of a bunch of people not learning from the past - ie. the entire lineage of ML-based languages! A rich type system lets you mold and shape the types to fit nicely over your domain, effectively becoming a machine-verified DSL for your business problem. It will catch flaws in your mental model before you even begin to write tests or an implementation, and is a cheap way of sketching out your ideas and great documentation to have over the lifetime of your project. Of course you can't fit it exactly, so you need a smattering of spec tests, and probably some property-based tests for good measure to fill in the gaps.
  - neilwilson 9y ago
    Go is what people are using. And python for some reason which amuses me greatly given we have Julia.
- lmm 9y ago
  > Language type checking misses the point. The types I want to check, and the extent I want to check them, are in the spec files. It's worth incorporating a way to express these things directly into the language proper. That way all your tools will understand them (e.g. automated refactoring will already know what needs to be updated) and you can talk about them in the language. > Go type inference, for example, is deeply primitive and an awful lot of Go code seems to spend its time implementing duck typing via work arounds. Yeah, Go is the exception. It's profoundly and proudly ignorant of 65 years of language design progress. If Go were the only language type system I had access to I'd think language type checking was pointless too.

bjz_ 9y ago

The difference is that we know there's something better than Java, C#, or C++ this time around. We have Typescript, Flow, Elm, Purescript, Haskell, Rust, OCaml, Idris, F*, Nim, Crystal, and more. Yes, some lessons have been forgotten that will have to be relearned, but on the whole we are improving. It's like how Andrew Whiles says[0] on how it's important to be forgetful to be a good mathematician: > It goes like this. You try one strategy on a problem. It fails. You retreat, dispirited. Later, having forgotten your bitter defeat, you try the same strategy again. Perhaps the process repeats. But eventually—again, thanks to your forgetfulness—you commit a slight error, a tiny deviation from the path you’ve tried several times. And suddenly, you succeed. I think we're a bit better than that, but it pays to remember it the next time you see the young whippersnappers publishing an NPM package doing the same thing you did years ago and deemed to be a failure. By all means, share the war stories with them - it's important we get better at appreciating history, but do it from a position of encouragement. They may yet succeed where you failed. :) - [0]: https://mathwithbaddrawings.com/2017/09/20/the-state-of-being-stuck/ https://mathwithbaddrawings.com/2017/09/20/the-state-of-bein...