8 ms·

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely be

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. With that said, it's important to note that type inference is not new. I was doing type inference with Scheme nearly 20 years ago. I believe the reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Types are meant to document code. Without the annotations, you can't look at code and know what is going on. Which, ironically, is the complaint against dynamic typing. In addition to that, you get the pain in the ass of having the compiler always complaining. And because it's inferring types, the error messages are towers of baffling nonsense. It's the worse of both worlds. One thing that never comes up in these discussions is the idea that creating good types is a skill itself. Much like naming variables, if you don't design your types correctly, your entire code base suffers. It's much easier in a dynamically typed code base to "nudge" the data in a certain direction than in a static type system where all types are locked down at initial design time. In addition, certain type systems are much harder to master than others. I've worked with dozens of TypeScript developers and not a single one really knew what they were doing. They were appeasing the compiler and little more than that. There are also plenty of footguns in TypeScript that even TypeScript experts continually forget. I could continue on the weakening of the value of TS (via "any" and "ts-ignore", etc.) and how these completely muddy any sort of metrics one may have on deciding whether types are "worth it" or not (or the fact that such metrics do not, in fact, exist). But that's enough ranting for one day.

billisonline 6y ago
> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime
- mamcx 6y ago
  I think yes. I do F# for a lot of time, and looking at past code I can't just figure some stuff. Not only their type system look alike dynamic, it make you build some stuff that is IMPOSSIBLE to get without a serious look at the types: And the types are invisible and behind abstracts constructs. With python, for example, I can't at first see what a function need but at least see the body give huge clues, because python rely less of abstract type stuff (it have a issue with monkey patching and delayed build of objects BUT, "if look like a duck.." is most of the time enough to get things..
  - gmfawcett 6y ago
    F# lets you specify the types of function arguments and return values. If it will make your code easier to read and reason about, why not just do that? I use Ocaml a lot, which is very similar to F# as you know... and I document the types of all toplevel values in my code. Not because the compiler needs it, but because it helps me navigate the code more easily.
    - mamcx 6y ago
      Yeah, but it is not very idiomatic and if I need to put types everywhere, but is the point of it at the end? Is like people that type python: Is screaming is the wrong tool for the job :)
- watwut 6y ago
  The types make those uis much more powerful.
- ysavir 6y ago
  Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be written independent of the tools used to understand and modify that code. If there's anything about the code that needs to be communicated, it should be communicated via the code itself, whether through naming patterns, comments, types, or any other methodology that can be encapsulated in a text file. Other than letting each developer have their own preferred processes and coding environment, it also makes it easier to SSH into a remote box and know what's going on. A quick google shows that VS Code does allow for SSHing and browsing the remote files via VSCode. That's nice, but I don't know how well it works, and how much I like the idea of allowing another program to run commands on the remote box. I like that I can SSH into a box and use the tools natively available there to read and modify the code, and that the code is prepared in a way that makes it as easy as possible.
creata 6y ago
> Without the annotations, you can't look at code and know what is going on. In Rust, type inference is only inside the function, which I think gets you the best of both worlds. > In addition to that, you get the pain in the ass of having the compiler always complaining. This has stopped so many dumb errors of mine. My types aren't complex enough to guarantee that my program is correct, but they're complex enough to at least know that my program makes sense.
- ben-schaaf 6y ago
  > This has stopped so many dumb errors of mine. I take this one step further: Having a language with rich-ish types and good error messages like rust means I can very often rely on the compiler to tell me how to fix my dumb mistakes. In other words I know where I can be just as if not more sloppy than in an interpreted language and actually get away with it for little effort. I spend a little time getting the parameter and return types as I want them, quickly write an implementation without thinking too much about references and lifetimes then let the compiler work out the details pretty much automatically.
- Gibbon1 6y ago
  My experience learning Perl and Python after C/C++ and C# was okay I really get the obsession with unit tests now. One thing notable in C you usually don't have to type the type name twice. But C++/Java/C# you do. That's when I think about it was a really bad grammar mistake. Java and C# shouldn't have propagated it. Mentioned above I agree with, designing good types is non trivial. I think that's part of the problem that designing good API's is non trivial. I can see programmers getting the hate on when dealing with code bases with crappy types and crappy API's.
nendroid 6y ago
>I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years. Not always. If you examine history not everything is a cycle, depending on what you look at human efficiency improves as well. Society goes through natural selection. The cultures, methods and behaviors that help us survive live on while methodologies that aren't as good tend to get eliminated. The cycles in the process occur in areas not under selection pressure. It's called genetic drift and mutations in this area can occur willy nilly in random steps or even cycles if it doesn't have an effect on survival. The pressure in this case is survival of a business. There's not enough cultural data on dynamics types vs. static types, but I feel in general the dynamic type thing was a mutation. Dynamic types were natures trial at a baby born with one kidney instead of two because one kidney is more energy efficient to maintain. Now it's being naturally selected out. We'll never know for sure unless you live long enough to see what happens to programming in the far future. For something to be truly called cyclical it must be adopted by huge amount of businesses and eliminated and recreated multiple times.
- dragonwriter 6y ago
  Both classic static and dynamic typing are trending over time to being replaced with the option of static typing with gaps; languages with static typing are more frequently implementing dynamic escape hatches and languages with dynamic typing are getting optional static type checking tools, and both static-first languages and optional typecheckers for dynamic-first languages often have fairly robust type inference, so the firm bright lines that used to exist between static and dynamic languages of the experience of using them is quite a bit blurred.
  - nendroid 6y ago
    Yes, but overall static typing is trending again in the sense that more and more static typing is being used... just a little less strict because of the trapdoors as you say.
disown 6y ago
> I believe the reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Are you talking about scheme? It didn't take off for the same reason all other functional languages didn't take off. Why functional languages aren't as popular, who knows. > Types are meant to document code. Not true. Comments/documentation are meant to document code. Types and type systems exist to constrain the program space to produce sound programs. Type systems limit the number of valid programs. Types and type systems do not exist to document code.
jerf 6y ago
I don't think dynamic typing will ever swing back. They came out of an era when types were expensive and had moderate benefit. Now they are cheap (in modern languages) and have significant benefits. There will always be things like shell scripts and stuff, but I don't expect to ever see a big language without a good typing story ever again. The problem to solve now is to lower the costs more and raise the benefits, not to try to eliminate them.
- joelbluminator 6y ago
  > will ever swing back. Does it need to swing back? Python/JS/PHP/Ruby are still plenty popular. And no, JS isn't typescript.
  - MiroF 6y ago
    JS is losing out to TS long term. Python is getting Mypy. PHP (and Ruby) are dying much more rapidly than many of their peers of similar ages.
    - joelbluminator 6y ago
      Php is dying? Didnt know.
      - MiroF 6y ago
        PHP is literally the only language banned in some major tech companies because of how dysfunctional it is.
        joelbluminator 6y ago
        PHP is quite weak in the U.S, I can only assume that's why you got the impression it's dying. In Europe it couldn't be more popular. I'm not here to "defend" PHP, I use Ruby, but living in the Netherlands you'd be amazed how many companies use it. Ruby is a very small niche here in comparison.
mrkeen 6y ago
> Without the annotations, you can't look at code and know what is going on. Which, ironically, is the complaint against dynamic typing. My complaint is the compiler doesn't know what is going on. > In addition to that, you get the pain in the ass of having the compiler always complaining. This cuts down on the time required for the programmer to decide whether to complain or not. > I've worked with dozens of TypeScript developers and not a single one really knew what they were doing. I'd hate for them to start committing code that can't at the least be checked by the compiler.
throwaway894345 6y ago
> I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. It’s because the ergonomics of the previous generation of (mainstream) languages was cumbersome. No sum types, no type inference, nullability all over, terrible error messages, abhorrence of expressions, etc. some of those things are only indirectly related to static typing, but many people mistakenly attribute them to static typing nonetheless. The new crop of mainstream statically typed languages wed these quality of life improvements with the rugged practicality of the previous generation of mainstream languages (none of these features are new, but no serious team is going to switch from C++ to scheme for the type inference alone). > With that said, it's important to note that type inference is not new. I was doing type inference with Scheme nearly 20 years ago. I believe the reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Types are meant to document code. Without the annotations, you can't look at code and know what is going on. Which, ironically, is the complaint against dynamic typing. In addition to that, you get the pain in the ass of having the compiler always complaining. And because it's inferring types, the error messages are towers of baffling nonsense. It's the worse of both worlds. Type inference is very much a “sweet spot” thing. Like many things, Rust nails this: you have to annotate struct fields and function arguments, but within a function body you get inference. Changes outside of the function don’t result in type errors inside of the function. Locality is key. > One thing that never comes up in these discussions is the idea that creating good types is a skill itself. This is an interesting point, and I agree; however, I think the issue is less that it’s hard to do and more that dynamic typists don’t see it as a worthwhile activity at all—“why should I try to create good types? I just need to get this happy path working so I can get on with life!” Of course there are abundant good reasons (we should care about quality and maintainability and not just superficially churning through feature tickets at the expense of all else), but I think this is a sort of fundamental disagreement between dynamic and static typists.
- zabzonk 6y ago
  > no serious team is going to switch from C++ to scheme for the type inference alone and also possibly because C++ has type inference
edem 6y ago
I don't have to look at my static code to know that it is doing the wrong thing. The compiler tells me. This is impossible with dynamic languages. It is obvious that you never used types otherwise you wouldn't have come up with this nonsense.
SebastianKra 6y ago
> reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Types are meant to document code. Without the annotations, you can't look at code and know what is going on. Type annotations aren't for me, they're for the compiler and the IDE. If I wan't to know whats going on inside a variable, I cmd+hover over it.
joelbluminator 6y ago
I actually wish you'd written more about this, this is important and doesn't get a proper discussion. If you could come up with some code examples of the problems you hinted at it would make a beautiful blog post.

billisonline 6y ago

> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime

mamcx 6y ago
I think yes. I do F# for a lot of time, and looking at past code I can't just figure some stuff. Not only their type system look alike dynamic, it make you build some stuff that is IMPOSSIBLE to get without a serious look at the types: And the types are invisible and behind abstracts constructs. With python, for example, I can't at first see what a function need but at least see the body give huge clues, because python rely less of abstract type stuff (it have a issue with monkey patching and delayed build of objects BUT, "if look like a duck.." is most of the time enough to get things..
- gmfawcett 6y ago
  F# lets you specify the types of function arguments and return values. If it will make your code easier to read and reason about, why not just do that? I use Ocaml a lot, which is very similar to F# as you know... and I document the types of all toplevel values in my code. Not because the compiler needs it, but because it helps me navigate the code more easily.
  - mamcx 6y ago
    Yeah, but it is not very idiomatic and if I need to put types everywhere, but is the point of it at the end? Is like people that type python: Is screaming is the wrong tool for the job :)
watwut 6y ago
The types make those uis much more powerful.
ysavir 6y ago
Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be written independent of the tools used to understand and modify that code. If there's anything about the code that needs to be communicated, it should be communicated via the code itself, whether through naming patterns, comments, types, or any other methodology that can be encapsulated in a text file. Other than letting each developer have their own preferred processes and coding environment, it also makes it easier to SSH into a remote box and know what's going on. A quick google shows that VS Code does allow for SSHing and browsing the remote files via VSCode. That's nice, but I don't know how well it works, and how much I like the idea of allowing another program to run commands on the remote box. I like that I can SSH into a box and use the tools natively available there to read and modify the code, and that the code is prepared in a way that makes it as easy as possible.

creata 6y ago

> Without the annotations, you can't look at code and know what is going on. In Rust, type inference is only inside the function, which I think gets you the best of both worlds. > In addition to that, you get the pain in the ass of having the compiler always complaining. This has stopped so many dumb errors of mine. My types aren't complex enough to guarantee that my program is correct, but they're complex enough to at least know that my program makes sense.

ben-schaaf 6y ago
> This has stopped so many dumb errors of mine. I take this one step further: Having a language with rich-ish types and good error messages like rust means I can very often rely on the compiler to tell me how to fix my dumb mistakes. In other words I know where I can be just as if not more sloppy than in an interpreted language and actually get away with it for little effort. I spend a little time getting the parameter and return types as I want them, quickly write an implementation without thinking too much about references and lifetimes then let the compiler work out the details pretty much automatically.
Gibbon1 6y ago
My experience learning Perl and Python after C/C++ and C# was okay I really get the obsession with unit tests now. One thing notable in C you usually don't have to type the type name twice. But C++/Java/C# you do. That's when I think about it was a really bad grammar mistake. Java and C# shouldn't have propagated it. Mentioned above I agree with, designing good types is non trivial. I think that's part of the problem that designing good API's is non trivial. I can see programmers getting the hate on when dealing with code bases with crappy types and crappy API's.

nendroid 6y ago

>I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years. Not always. If you examine history not everything is a cycle, depending on what you look at human efficiency improves as well. Society goes through natural selection. The cultures, methods and behaviors that help us survive live on while methodologies that aren't as good tend to get eliminated. The cycles in the process occur in areas not under selection pressure. It's called genetic drift and mutations in this area can occur willy nilly in random steps or even cycles if it doesn't have an effect on survival. The pressure in this case is survival of a business. There's not enough cultural data on dynamics types vs. static types, but I feel in general the dynamic type thing was a mutation. Dynamic types were natures trial at a baby born with one kidney instead of two because one kidney is more energy efficient to maintain. Now it's being naturally selected out. We'll never know for sure unless you live long enough to see what happens to programming in the far future. For something to be truly called cyclical it must be adopted by huge amount of businesses and eliminated and recreated multiple times.

dragonwriter 6y ago
Both classic static and dynamic typing are trending over time to being replaced with the option of static typing with gaps; languages with static typing are more frequently implementing dynamic escape hatches and languages with dynamic typing are getting optional static type checking tools, and both static-first languages and optional typecheckers for dynamic-first languages often have fairly robust type inference, so the firm bright lines that used to exist between static and dynamic languages of the experience of using them is quite a bit blurred.
- nendroid 6y ago
  Yes, but overall static typing is trending again in the sense that more and more static typing is being used... just a little less strict because of the trapdoors as you say.

disown 6y ago

> I believe the reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Are you talking about scheme? It didn't take off for the same reason all other functional languages didn't take off. Why functional languages aren't as popular, who knows. > Types are meant to document code. Not true. Comments/documentation are meant to document code. Types and type systems exist to constrain the program space to produce sound programs. Type systems limit the number of valid programs. Types and type systems do not exist to document code.

jerf 6y ago

I don't think dynamic typing will ever swing back. They came out of an era when types were expensive and had moderate benefit. Now they are cheap (in modern languages) and have significant benefits. There will always be things like shell scripts and stuff, but I don't expect to ever see a big language without a good typing story ever again. The problem to solve now is to lower the costs more and raise the benefits, not to try to eliminate them.

joelbluminator 6y ago
> will ever swing back. Does it need to swing back? Python/JS/PHP/Ruby are still plenty popular. And no, JS isn't typescript.
- MiroF 6y ago
  JS is losing out to TS long term. Python is getting Mypy. PHP (and Ruby) are dying much more rapidly than many of their peers of similar ages.
  - joelbluminator 6y ago
    Php is dying? Didnt know.
    - MiroF 6y ago
      PHP is literally the only language banned in some major tech companies because of how dysfunctional it is.
      - joelbluminator 6y ago
        PHP is quite weak in the U.S, I can only assume that's why you got the impression it's dying. In Europe it couldn't be more popular. I'm not here to "defend" PHP, I use Ruby, but living in the Netherlands you'd be amazed how many companies use it. Ruby is a very small niche here in comparison.

mrkeen 6y ago

> Without the annotations, you can't look at code and know what is going on. Which, ironically, is the complaint against dynamic typing. My complaint is the compiler doesn't know what is going on. > In addition to that, you get the pain in the ass of having the compiler always complaining. This cuts down on the time required for the programmer to decide whether to complain or not. > I've worked with dozens of TypeScript developers and not a single one really knew what they were doing. I'd hate for them to start committing code that can't at the least be checked by the compiler.

throwaway894345 6y ago

> I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. It’s because the ergonomics of the previous generation of (mainstream) languages was cumbersome. No sum types, no type inference, nullability all over, terrible error messages, abhorrence of expressions, etc. some of those things are only indirectly related to static typing, but many people mistakenly attribute them to static typing nonetheless. The new crop of mainstream statically typed languages wed these quality of life improvements with the rugged practicality of the previous generation of mainstream languages (none of these features are new, but no serious team is going to switch from C++ to scheme for the type inference alone). > With that said, it's important to note that type inference is not new. I was doing type inference with Scheme nearly 20 years ago. I believe the reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Types are meant to document code. Without the annotations, you can't look at code and know what is going on. Which, ironically, is the complaint against dynamic typing. In addition to that, you get the pain in the ass of having the compiler always complaining. And because it's inferring types, the error messages are towers of baffling nonsense. It's the worse of both worlds. Type inference is very much a “sweet spot” thing. Like many things, Rust nails this: you have to annotate struct fields and function arguments, but within a function body you get inference. Changes outside of the function don’t result in type errors inside of the function. Locality is key. > One thing that never comes up in these discussions is the idea that creating good types is a skill itself. This is an interesting point, and I agree; however, I think the issue is less that it’s hard to do and more that dynamic typists don’t see it as a worthwhile activity at all—“why should I try to create good types? I just need to get this happy path working so I can get on with life!” Of course there are abundant good reasons (we should care about quality and maintainability and not just superficially churning through feature tickets at the expense of all else), but I think this is a sort of fundamental disagreement between dynamic and static typists.

zabzonk 6y ago
> no serious team is going to switch from C++ to scheme for the type inference alone and also possibly because C++ has type inference

edem 6y ago

I don't have to look at my static code to know that it is doing the wrong thing. The compiler tells me. This is impossible with dynamic languages. It is obvious that you never used types otherwise you wouldn't have come up with this nonsense.

SebastianKra 6y ago

> reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Types are meant to document code. Without the annotations, you can't look at code and know what is going on. Type annotations aren't for me, they're for the compiler and the IDE. If I wan't to know whats going on inside a variable, I cmd+hover over it.

joelbluminator 6y ago

I actually wish you'd written more about this, this is important and doesn't get a proper discussion. If you could come up with some code examples of the problems you hinted at it would make a beautiful blog post.