5 ms·

OCaml and Haskell seem to strike a pretty good middle ground to me. Powerful, but generally inferred static types. Haskell is a bit more concise, so I think i

OCaml and Haskell seem to strike a pretty good middle ground to me. Powerful, but generally inferred static types. Haskell is a bit more concise, so I think it can be more appealing to the dynamic language crowd. The major objection people to have to HM-style type systems seems to boil down to "the compiler is forcing me to fix my bugs before it will run my code", which seems a bit silly. It seems doubly silly when it comes from people who advocate TDD or other variations on tests-first.

silentbicycle 17y ago
> The major objection people to have to HM-style type systems seems to boil down to "the compiler is forcing me to fix my bugs before it will run my code", which seems a bit silly. I disagree - immediately requiring types to check can add a bit too much friction for exploratory programming, and types aren't a perfect design tool for everything. It isn't "wah, I have to fix bugs before my program works" so much as, "translating my entire design into types upfront is slowing down my brainstorming too much". I'm not convinced waiting ten minutes before the code has to get past HM would cause a big increase in bugs slipping through, but it really does help make the language feel more flexible. I think a better time for such static analysis (not just type-checking) would be when the code becomes a module and the programmer is already thinking about what to export, etc. Requiring a chunk of code in a scratch buffer or REPL to fully type-check is probably a bit too strict, except checking calls to existing libraries. (Optional type-checking is a different matter, of course.)
- kscaldef 17y ago
  Well, this is why I mentioned TDD. People (maybe not you) don't have a problem with their tests failing right away, and having to fix the test to go forward. In fact, they call it a feature! But when the compiler _proves_ you have a bug, somehow that is too odious. The other thing with a type-inferring compiler is that you don't have to figure out all your types upfront. You don't have to declare any types at all (usually). If everything is good, the compiler doesn't complain. As soon as you start to make an error, it tells you. Personally, I use the compiler very much like TDD advocates use tests. Write a function, make sure it compiles, slowly build up the whole program. If I wait until I've written the whole program before I run the type-checker, it's likely to be pretty ugly. Better to catch the errors quickly when it's less work to correct them.
  - silentbicycle 17y ago
    > The other thing with a type-inferring compiler is that you don't have to figure out all your types upfront. I've worked a fair bit with OCaml. You still need to define types for ADTs, and those can change early on. I think the bigger benefit to inferred static typing is during maintenance, ensuring that the design is still internally consistent. I mostly agree with you, and have the same experience about TDD vs. type inference. I'm not dogmatic about TDD either, though - I use a REPL and asserts, and sometimes QuickCheck-ish tools for testing during the initial writing.

silentbicycle 17y ago

> The major objection people to have to HM-style type systems seems to boil down to "the compiler is forcing me to fix my bugs before it will run my code", which seems a bit silly. I disagree - immediately requiring types to check can add a bit too much friction for exploratory programming, and types aren't a perfect design tool for everything. It isn't "wah, I have to fix bugs before my program works" so much as, "translating my entire design into types upfront is slowing down my brainstorming too much". I'm not convinced waiting ten minutes before the code has to get past HM would cause a big increase in bugs slipping through, but it really does help make the language feel more flexible. I think a better time for such static analysis (not just type-checking) would be when the code becomes a module and the programmer is already thinking about what to export, etc. Requiring a chunk of code in a scratch buffer or REPL to fully type-check is probably a bit too strict, except checking calls to existing libraries. (Optional type-checking is a different matter, of course.)

kscaldef 17y ago
Well, this is why I mentioned TDD. People (maybe not you) don't have a problem with their tests failing right away, and having to fix the test to go forward. In fact, they call it a feature! But when the compiler _proves_ you have a bug, somehow that is too odious. The other thing with a type-inferring compiler is that you don't have to figure out all your types upfront. You don't have to declare any types at all (usually). If everything is good, the compiler doesn't complain. As soon as you start to make an error, it tells you. Personally, I use the compiler very much like TDD advocates use tests. Write a function, make sure it compiles, slowly build up the whole program. If I wait until I've written the whole program before I run the type-checker, it's likely to be pretty ugly. Better to catch the errors quickly when it's less work to correct them.
- silentbicycle 17y ago
  > The other thing with a type-inferring compiler is that you don't have to figure out all your types upfront. I've worked a fair bit with OCaml. You still need to define types for ADTs, and those can change early on. I think the bigger benefit to inferred static typing is during maintenance, ensuring that the design is still internally consistent. I mostly agree with you, and have the same experience about TDD vs. type inference. I'm not dogmatic about TDD either, though - I use a REPL and asserts, and sometimes QuickCheck-ish tools for testing during the initial writing.