3 ms·

While I disagree (static typing is much more than catching type conversion errors), my point was that it makes experimentation and design exploration much easie

by pka 10y ago

While I disagree (static typing is much more than catching type conversion errors), my point was that it makes experimentation and design exploration much easier and faster. Without types, you'd need mock data for even the simplest of programs, and changing mock data structure is much more painful than changing a type somewhere and getting the places (all the places) where your program turns then out to be incoherent. Not to mention that types are much more than Persons or Gorillas, they can be higher order functions too (Person -> Gorilla) that are passed around.

nickbauman 10y ago
Sure. But does your static typing system allow you to skip writing automated tests? Pretty sure everyone writes tests these days unless they're spiking something. If you're writing tests, you will have to come up with the mock data anyway. And the kind of exploration you're doing I tend to do from a test regardless. Once my exploration is done I also have a test that captures my work. You still have to write one. The question of whether to static or dynamic is moot in this case. It no longer matters much. Maybe I need to spend some time in Haskell and come over to your way of seeing it. But the studies show that constructing the type system for your problem is very difficult and remains error prone. People routinely make mistakes with types systems of all kinds. I've found I spend more time making the compiler happy that it does making me happy.
- dllthomas 10y ago
  > If you're writing tests, you will have to come up with the mock data anyway. With property based testing, your system will come up with mock data for you.
- pka 10y ago
  The sibling comment points out property based testing (see QuickCheck), which is a good idea in any language. And yes - you don't need to write that many unit tests (but still some) when using a type system, because you can encode a lot of invariants in the types. But still, my point stands - writing tests during early experimentation is a lot harder than just altering some type and letting the compiler infere what needs to be done or what you broke. I've spent some time writing Clojure and still use dynamic languages a lot for smaller tasks, so I know both sides. This doesn't mean much, but I'd really encourage you to try some ML language and spend some time with a nice type system. Haskell is probably too big a time investment, so maybe try Elm [0] - it's very beginner friendly and a lot of the people using it come from JavaScript. [0] http://elm-lang.org http://elm-lang.org

by pka 10y ago

nickbauman 10y ago

Sure. But does your static typing system allow you to skip writing automated tests? Pretty sure everyone writes tests these days unless they're spiking something. If you're writing tests, you will have to come up with the mock data anyway. And the kind of exploration you're doing I tend to do from a test regardless. Once my exploration is done I also have a test that captures my work. You still have to write one. The question of whether to static or dynamic is moot in this case. It no longer matters much. Maybe I need to spend some time in Haskell and come over to your way of seeing it. But the studies show that constructing the type system for your problem is very difficult and remains error prone. People routinely make mistakes with types systems of all kinds. I've found I spend more time making the compiler happy that it does making me happy.

dllthomas 10y ago
> If you're writing tests, you will have to come up with the mock data anyway. With property based testing, your system will come up with mock data for you.
pka 10y ago
The sibling comment points out property based testing (see QuickCheck), which is a good idea in any language. And yes - you don't need to write that many unit tests (but still some) when using a type system, because you can encode a lot of invariants in the types. But still, my point stands - writing tests during early experimentation is a lot harder than just altering some type and letting the compiler infere what needs to be done or what you broke. I've spent some time writing Clojure and still use dynamic languages a lot for smaller tasks, so I know both sides. This doesn't mean much, but I'd really encourage you to try some ML language and spend some time with a nice type system. Haskell is probably too big a time investment, so maybe try Elm [0] - it's very beginner friendly and a lot of the people using it come from JavaScript. [0] http://elm-lang.org http://elm-lang.org