5 ms·

> they value development speed I never understood that. For anything non-trivial, development speed is increased with types: you get auto-complete, safe refact

> they value development speed I never understood that. For anything non-trivial, development speed is increased with types: you get auto-complete, safe refactorings, code navigation etc.

mro_name 5y ago
maybe you get the sunshine case out of the door quicker. But beware new-year or leap years. Or daylight saving change. Or non-ascii. I mean, who would ever care about fringe cases when you can have continuous delivery instead?
- DeathArrow 5y ago
  Well, if it works when you deploy, maybe you get lucky and the bug will arrive after you've moved to another company. :D
- goto11 5y ago
  I don't see how this is different between type systems. No type system I know of guarantee you handle leap years correctly.
  - mro_name 5y ago
    in real life nobody will guarantee you anything. But treating dates and surnames alike doesn't help robustness either. Or separate types for metric distance and imperial distance might have prevented mars(?) lander losses. Or for sea levels referenced to Rotterdam or Le Havre might have prevented some bridges to have differing levels.
  - mro_name 5y ago
    I apologise for the misleading example "leap year".
    - goto11 5y ago
      I'm a fan of static typing, but if people think it will protest them from logical errors like forgetting about DST, then they are actually worse off.
      - reuben364 5y ago
        I guess; in the sense that it frees cognitive load from reasoning about properties of your program that are easily computed to think about properties that aren't. Even then, maybe thinking about the former primes you to reason about the latter. But even if the compiler tells you what the type of something should be, you ultimately have the synthesize something of that type.
      - mro_name 5y ago
        think of the metric/imperial example above. The distance isn't just a number. Holds for most other things, too. Typed is key. Be it either static or dynamic.
tshaddox 5y ago
I think it’s mostly a historical coincidence that popular languages with conspicuous static type checking have often been slower to develop with than popular languages without conspicuous static type checking.
DeathArrow 5y ago
Some languages even have implicit typing like C# and C++. How hard is to write var v= SomeMethod() or var v = 5?
- eru 5y ago
  In eg Haskell you don't have to stick `var` in front of stuff, either. And it's very much statically typed, but also has type inference. However, you still have to sometimes do some work to make your ideas fit the type system. Number of keystrokes isn't the only thing here.
kajecounterhack 5y ago
Seems to me that there's historically been more cognitive overhead to _learning_ most strongly typed languages, e.g you have to think about pointer vs reference, const, heap or stack allocation, borrowing if it's rust, etc. If you're not already familiar with the concepts, your development velocity is slow. But when you start writing more code, everything you said becomes true: types yield a lot of benefit. People also seem to associate strong typing with compilers that bog down the write->run->debug loop, some of which used to have notoriously bad error messages, and things have changed because of JIT compilation (dart can even be both AOT compiled & JIT compiled), and also because modern compilers are so much better optimized and user friendly compared to just a decade ago (I mean, compare rustc error messages to GCC, lol). Compilers are doing a much better job today of helping decrease total debugging time. FWIW this doesn't mean more advanced programmers necessarily move to strongly typed languages to increase their productivity. Instead, we are moving toward a progressively typed world (e.g typed python, typescript) to bring the benefits to users of dynamic languages as they begin to need them (without forcing them to use anything). And strongly typed languages are doing the opposite, e.g getting lots of dynamically typed features (e.g type inference in C++ with `auto`, initializer list syntax) which again, don't have to be used unless it helps with code readability and/or development velocity.
dan-robertson 5y ago
The way static types can make development speed slower is not by forcing you to write the same code with extra types added in, but by forcing you to write different code. In this sense it isn’t really an argument about static types vs dynamic types (imagine a language with no type checks where programs have undefined behaviour at run time on anything that would have been a static type error) but rather a statically typed language vs a dynamic language. There are patterns or language features in dynamically typed languages which are very hard to translate to static types. I think Peter Norvig has some slides somewhere comparing OOP patterns to lisp, a more dynamic language, and that is the sort of thing I’m thinking of here. For language features, consider implementing an n-ary list map in Haskell vs Common Lisp. Or the typed equivalent of delimited continuations. That said, research on the differences between languages is difficult and inconclusive. I would like to see more of it.
- qsort 5y ago
  > implementing an n-ary list map isn't that just flatMap? > typed equivalent of delimited continuations It's very clunky to do in Haskell, but conceptually they can be built on top of a monadic pipeline. In practice, the only case where statically typed languages force you to write different code is if: (a) the type system is too restrictive and dumb (no generics, awkward function types, etc). (b) you're trying to write a function that effectively returns monster types like Union[None, int, str, List[str]], which is common in dynamic languages but it's something you're not really supposed to do. I agree with your broader point, that static types can in fact slow down development, but I have a different model. Types are kind of two things at the same time: tags to tell the compiler how many bytes need to be allocated, and partial proofs of correctness of the program. The key observation of dynamic languages is that in most cases we can do without the first part: the runtime can handle that in the same way it handles memory management. I believe one of the mistakes of the original wave of dynamic typing proponents is that they kind of threw away the baby with the bathwater: the correctness part is important, and at least a form of optional typing should be provided. The real trouble is that it's not easy to conjure type systems that are both expressive and ergonomic to use for the average developer. Sufficiently advanced type systems are indistinguishable from math riddles, and in a working environment that can be frustrating.
Cthulhu_ 5y ago
> For anything non-trivial There's the key phrase. There's plenty of people that can whip up a POC or MVP in an afternoon of hacking or a week of fiddling, but going from that to something that can safely handle millions of users and hundreds of developer contributions needs types and other assurances. If it fits in a developer or a team's heads, then it's just fine - that's how I did my first major JS application, just Knowing what fields my objects have and what types they are expected to have. But that doesn't scale, people move on, gaps exist in tests, etc etc etc.
Someone 5y ago
Historically, in many languages, you didn’t get either of these. If you were lucky, you would have ctags (https://en.wikipedia.org/wiki/Ctags https://en.wikipedia.org/wiki/Ctags) for navigation. Also, development speed can go down if you have to show your compiler that data conforms to a given type. Certainly for one-offs where the user writes and maintains their own program, that can sometimes/often get you something doing something useful for the inputs you have _now_ fairly rapidly.
roenxi 5y ago
> ...development speed is increased with types... There might be a hidden assumption of stead-state in there. In the initial ramp-up when people are learning a language, or learning to code to start with, types will slow down development because there is one more system to learn and use correctly. It is notable that if your code is going to be a bug ridden mess regardless of language features, language features that reduce the number of bugs (like type systems) are a hindrance.

> they value development speed I never understood that. For anything non-trivial, development speed is increased with types: you get auto-complete, safe refactorings, code navigation etc.

mro_name 5y ago

maybe you get the sunshine case out of the door quicker. But beware new-year or leap years. Or daylight saving change. Or non-ascii. I mean, who would ever care about fringe cases when you can have continuous delivery instead?

DeathArrow 5y ago
Well, if it works when you deploy, maybe you get lucky and the bug will arrive after you've moved to another company. :D
goto11 5y ago
I don't see how this is different between type systems. No type system I know of guarantee you handle leap years correctly.
- mro_name 5y ago
  in real life nobody will guarantee you anything. But treating dates and surnames alike doesn't help robustness either. Or separate types for metric distance and imperial distance might have prevented mars(?) lander losses. Or for sea levels referenced to Rotterdam or Le Havre might have prevented some bridges to have differing levels.
- mro_name 5y ago
  I apologise for the misleading example "leap year".
  - goto11 5y ago
    I'm a fan of static typing, but if people think it will protest them from logical errors like forgetting about DST, then they are actually worse off.
    - reuben364 5y ago
      I guess; in the sense that it frees cognitive load from reasoning about properties of your program that are easily computed to think about properties that aren't. Even then, maybe thinking about the former primes you to reason about the latter. But even if the compiler tells you what the type of something should be, you ultimately have the synthesize something of that type.
    - mro_name 5y ago
      think of the metric/imperial example above. The distance isn't just a number. Holds for most other things, too. Typed is key. Be it either static or dynamic.

tshaddox 5y ago

I think it’s mostly a historical coincidence that popular languages with conspicuous static type checking have often been slower to develop with than popular languages without conspicuous static type checking.

DeathArrow 5y ago

Some languages even have implicit typing like C# and C++. How hard is to write var v= SomeMethod() or var v = 5?

eru 5y ago
In eg Haskell you don't have to stick `var` in front of stuff, either. And it's very much statically typed, but also has type inference. However, you still have to sometimes do some work to make your ideas fit the type system. Number of keystrokes isn't the only thing here.

kajecounterhack 5y ago

Seems to me that there's historically been more cognitive overhead to _learning_ most strongly typed languages, e.g you have to think about pointer vs reference, const, heap or stack allocation, borrowing if it's rust, etc. If you're not already familiar with the concepts, your development velocity is slow. But when you start writing more code, everything you said becomes true: types yield a lot of benefit. People also seem to associate strong typing with compilers that bog down the write->run->debug loop, some of which used to have notoriously bad error messages, and things have changed because of JIT compilation (dart can even be both AOT compiled & JIT compiled), and also because modern compilers are so much better optimized and user friendly compared to just a decade ago (I mean, compare rustc error messages to GCC, lol). Compilers are doing a much better job today of helping decrease total debugging time. FWIW this doesn't mean more advanced programmers necessarily move to strongly typed languages to increase their productivity. Instead, we are moving toward a progressively typed world (e.g typed python, typescript) to bring the benefits to users of dynamic languages as they begin to need them (without forcing them to use anything). And strongly typed languages are doing the opposite, e.g getting lots of dynamically typed features (e.g type inference in C++ with `auto`, initializer list syntax) which again, don't have to be used unless it helps with code readability and/or development velocity.

dan-robertson 5y ago

The way static types can make development speed slower is not by forcing you to write the same code with extra types added in, but by forcing you to write different code. In this sense it isn’t really an argument about static types vs dynamic types (imagine a language with no type checks where programs have undefined behaviour at run time on anything that would have been a static type error) but rather a statically typed language vs a dynamic language. There are patterns or language features in dynamically typed languages which are very hard to translate to static types. I think Peter Norvig has some slides somewhere comparing OOP patterns to lisp, a more dynamic language, and that is the sort of thing I’m thinking of here. For language features, consider implementing an n-ary list map in Haskell vs Common Lisp. Or the typed equivalent of delimited continuations. That said, research on the differences between languages is difficult and inconclusive. I would like to see more of it.

qsort 5y ago
> implementing an n-ary list map isn't that just flatMap? > typed equivalent of delimited continuations It's very clunky to do in Haskell, but conceptually they can be built on top of a monadic pipeline. In practice, the only case where statically typed languages force you to write different code is if: (a) the type system is too restrictive and dumb (no generics, awkward function types, etc). (b) you're trying to write a function that effectively returns monster types like Union[None, int, str, List[str]], which is common in dynamic languages but it's something you're not really supposed to do. I agree with your broader point, that static types can in fact slow down development, but I have a different model. Types are kind of two things at the same time: tags to tell the compiler how many bytes need to be allocated, and partial proofs of correctness of the program. The key observation of dynamic languages is that in most cases we can do without the first part: the runtime can handle that in the same way it handles memory management. I believe one of the mistakes of the original wave of dynamic typing proponents is that they kind of threw away the baby with the bathwater: the correctness part is important, and at least a form of optional typing should be provided. The real trouble is that it's not easy to conjure type systems that are both expressive and ergonomic to use for the average developer. Sufficiently advanced type systems are indistinguishable from math riddles, and in a working environment that can be frustrating.

Cthulhu_ 5y ago

> For anything non-trivial There's the key phrase. There's plenty of people that can whip up a POC or MVP in an afternoon of hacking or a week of fiddling, but going from that to something that can safely handle millions of users and hundreds of developer contributions needs types and other assurances. If it fits in a developer or a team's heads, then it's just fine - that's how I did my first major JS application, just Knowing what fields my objects have and what types they are expected to have. But that doesn't scale, people move on, gaps exist in tests, etc etc etc.

Someone 5y ago

Historically, in many languages, you didn’t get either of these. If you were lucky, you would have ctags (https://en.wikipedia.org/wiki/Ctags https://en.wikipedia.org/wiki/Ctags) for navigation. Also, development speed can go down if you have to show your compiler that data conforms to a given type. Certainly for one-offs where the user writes and maintains their own program, that can sometimes/often get you something doing something useful for the inputs you have _now_ fairly rapidly.

roenxi 5y ago

> ...development speed is increased with types... There might be a hidden assumption of stead-state in there. In the initial ramp-up when people are learning a language, or learning to code to start with, types will slow down development because there is one more system to learn and use correctly. It is notable that if your code is going to be a bug ridden mess regardless of language features, language features that reduce the number of bugs (like type systems) are a hindrance.