7 ms·

My theory is that these career evangelists have spent too much of their careers doing just that: evangelizing. They haven't actually been writing code or buildi

My theory is that these career evangelists have spent too much of their careers doing just that: evangelizing. They haven't actually been writing code or building software. They've just been telling everyone how they think they should be building software. I have arrived at the same conclusions as you wrt. static vs dynamic typing. A sufficiently powerful static type system entirely subsumes dynamic typing, and there is quite literally nothing you can accomplish with dynamic typing that you cannot accomplish with such a static type system. After writing software using both dynamically and statically typed languages, this is the conclusion I have arrived at, and it feels like a no-brainer to me. This is so much of a no-brainer to me that I can't help but be biased when someone disagrees. I want to think that I am open to having my mind changed, but I have yet to see any evidence that sways me. I do think perhaps a lack of external demand for code quality and correctness might sometimes be at fault. When all you need to do is write the code for the happy path correctly, maybe you just feel static types get in the way. I've converted several javascript projects to typescript, and in every single one of those projects, the conversion exposed multiple(in the tens or sometimes hundreds) cases of incorrect handling of null/undefined or just type mismatches. I know this has to do with culture and the specific company and engineering discipline, but what I'm trying to get at is that I think a lot of people out there are writing code this way: just hack away until it works, and fix it if it ever crashes. When this is all you want, maybe proving correctness to the compiler is too bothersome. But I don't and won't work this way.

1337shadow 5y ago
> there is quite literally nothing you can accomplish with dynamic typing that you cannot accomplish with such a static type system. Exactly, and all you need is Any > a lot of people out there are writing code this way: just hack away until it works, and fix it if it ever crashes. I'm willing to agree that Non-TDD hackers should go for static typing.
- uDontKnowMe 5y ago
  >Exactly, and all you need is Any If you're using Any, then your program is (at least in part) dynamically typed. I don't think it's fair to say "look! Static typing is better than dynamic typing in any and all situations! (so long as it can use dynamic typing)"
  - 1337shadow 5y ago
    Exactly :)
- marcosdumay 5y ago
  Tests are a very underpowered replacement for types. They require a lot more work to create, much more maintenance, and bring you much less confidence. Unity tests are the worst kind on each of those dimensions. It's really not a good idea to follow TDD instead of using types. You want tests for things that aren't practical to verify, not for replacing static verification.
sgeisenh 5y ago
> just hack away until it works, and fix it if it ever crashes. This also makes collaboration really hard. Types are a form of documentation. But unlike comments, types are enforced by the compiler. Invariably, lots of comments in a codebase are wrong. Many of those probably started out correct but the code changed and the comment didn't.
- DonHopkins 5y ago
  ...to the point where you can improve code quality by deleting comments.
- scns 5y ago
  In Elixir (and Rust too IIRC) example code in comments is checked by the compiler.
DonHopkins 5y ago
https://news.ycombinator.com/item?id=22210073 https://news.ycombinator.com/item?id=22210073 From the HN discussion about the video of "A Conversation with Language Creators: Guido, James, Anders and Larry" https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 https://www.youtube.com/watch?v=csL8DLXGNlU https://www.youtube.com/watch?v=csL8DLXGNlU I posted these Anders Hejlsberg quotes, who co-designed TypeScript, C#, Delphi, Turbo Pascal, etc: https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 >"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg >"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg [...]
- scns 5y ago
  I like what Anders Hejlsberg says here, but still wonder why he is not pushing for F# adoption/funding/tooling etc. I'm in no position to judge such an accomplished language designer in any way, just curious. Is it ego? NIH? Or that other thing (Whose name someone else can surely provide) about not being able to see the solution if your salary depends on the problem.
  - marcosdumay 5y ago
    It's almost unanimous that the general "null" from C is a very bad idea.
    - scns 5y ago
      I know. C.A.R. Hoare who invented null, called it his Billion Dollar Mistake. https://en.wikipedia.org/wiki/Tony_Hoare?wprov=sfla1 https://en.wikipedia.org/wiki/Tony_Hoare?wprov=sfla1
BobbyJo 5y ago
To tack on to this: Typing is never the limiting factor in my work. Like, if I had to type even double to accomplish the same program, I don't think that would actually slow me down. Given that, the major time difference between using static vs dynamic typing is the investment needed to go from 'throwing things at a wall and seeing what sticks' to understanding what you need to do and doing it.
- woojoo666 5y ago
  I've found that "throwing things at the wall" can be very helpful sometimes. It isn't necessarily a linear path from designing a solution -> implementing it in code. Sometimes writing some preliminary code can help flesh out the design. It's a symbiotic process. I've wasted countless hours before trying to design a solution on paper when writing the code out and iterating on the code proved much faster. And as for how this relates to static v dynamic typing, when I'm roughing out an implementation I much prefer to leave out types.
  - BobbyJo 5y ago
    I find I can hack on things faster with static typing. I'm inevitably picking up new libraries, and using a new library is much easier when it's inputs and outputs are clear. I can see how dynamic would help if you're writing most things yourself, but static definitely has a huge return when interfacing with anything someone else wrote.
    - woojoo666 5y ago
      totally agree. That's why I think libraries and other mature code should use static typing, whereas I like to use dynamic typing for code that I am prototyping. This is why I love Typescript, you can have both :)
- blacktriangle 5y ago
  Anybody who thinks that avoiding extra typing is the point of dynamic langauges, or that working in a dynamic language is simply throwing things at a wall to see what sticks is completely missing the point. The whole point of dynamic languages is that your problem space is in fact dynamic. In many domains your data simply defies any ontology you try and force it into. Static typing systems themselves are somewhat acknowleging this problem internally with the differences between nominal and structural based typing system. Dynamic langauges are about changing your view on data where instead of shoving all your data into and out of boxes that don't fit, you just see entities as arbitrary collections of attributes and thus typing them makes little sense.
slumdev 5y ago
> I have arrived at the same conclusions as you wrt. static vs dynamic typing. A sufficiently powerful static type system entirely subsumes dynamic typing, and there is quite literally nothing you can accomplish with dynamic typing that you cannot accomplish with such a static type system. After writing software using both dynamically and statically typed languages, this is the conclusion I have arrived at, and it feels like a no-brainer to me. I've come to the same conclusion. A dynamic language is a footgun that doesn't buy any additional power or expressiveness over a well-developed typed language. It gets even worse when dynamic language developers start interacting with data. The "just do whatever" mentality that rejects type design also rejects relational design without any consideration of whether it's (almost certainly) a better choice than a document database.
- blacktriangle 5y ago
  I find the comment that dynamic typing rejects relational design funny when dynamic typing is what makes working with relational data relationally tractable. Static typing falls down almost immediately when trying to work with your relational data and ends up requiring reams of glue or mapping frameworks just to make your relational data approachable.
  - slumdev 5y ago
    It's a feature, not a bug, that the code blows up when the database schema doesn't match my models. Just as the necessity of DI frameworks isn't an argument against unit testing or the inversion principle, the necessity of ORM frameworks isn't an argument against static typing or relational databases.
    - blacktriangle 5y ago
      It's not the schema matching your model, it's the result of any query. How many different types do you need to represent the result of all possible projections on a single 10 attribute relation? Now join that to another 10 attribute relation, how many types to represent all possible projections of a single join between two relations? And Maybe is not the answer, Maybe is a lie. The data is either part of the result set or it is not based on the query.
woojoo666 5y ago
I prefer dynamic typing when writing code that I perceive as "volatile". This is especially true when it's a piece of code that's currently only being worked on by me. Static typing adds boilerplate that feels cumbersome, especially when the types of the variables are already made obvious by the variable names. However when a piece of code becomes mature, doesn't change often, and starts to be depended on by other people (eg a core library), then I start adding types for additional safety and documentation. This system of gradually adding types when needed is why Typescript is so great for me.
- aranchelk 5y ago
  > Static typing adds boilerplate That’s not necessarily true anymore. Languages like Haskell have both strong static typing and very good type inference. > However when a piece of code becomes mature, doesn't change often, and starts to be depended on by other people (eg a core library), then I start adding types for additional safety and documentation. That’s a practice in Haskell development as well, but the safety and guarantee of consistency are already present prior to the annotations.
  - woojoo666 5y ago
    type inference is a beautiful thing and I hope Typescript adds it someday
- dllthomas 5y ago
  I can see that, but find myself with different preferences. When I know I'll be making changes, I want to be working in a setting where I can tell some checker what I'm assuming, so that it lets me know when work elsewhere invalidates that assumption. Assumptions that will be mechanically checked are assumptions I can (metaphorically) page out in my head as I focus on other things, to be alerted when they again become relevant. I definitely agree that all of this becomes even more important when those assumptions need to be shared between the heads of different individuals.
fulafel 5y ago
> A sufficiently powerful static type system entirely subsumes dynamic typing, and there is quite literally nothing you can accomplish with dynamic typing that you cannot accomplish with such a static type system. After writing software using both dynamically and statically typed languages, this is the conclusion I have arrived at, and it feels like a no-brainer to me. Do you thing some existing practical, high-usability programming language has a sufficiently powerful type system in the way you describe? For me the big thing is that static type systems tend to be simultaneously too powerless to express what I need, and too laborious in demanding manual specification of things that I don't actually need to specify for the program to work. In a dynamic language with a good schema system like malli or spec in Clojure, I can have easily customizable verification that is opt-in.

1337shadow 5y ago

> there is quite literally nothing you can accomplish with dynamic typing that you cannot accomplish with such a static type system. Exactly, and all you need is Any > a lot of people out there are writing code this way: just hack away until it works, and fix it if it ever crashes. I'm willing to agree that Non-TDD hackers should go for static typing.

uDontKnowMe 5y ago
>Exactly, and all you need is Any If you're using Any, then your program is (at least in part) dynamically typed. I don't think it's fair to say "look! Static typing is better than dynamic typing in any and all situations! (so long as it can use dynamic typing)"
- 1337shadow 5y ago
  Exactly :)
marcosdumay 5y ago
Tests are a very underpowered replacement for types. They require a lot more work to create, much more maintenance, and bring you much less confidence. Unity tests are the worst kind on each of those dimensions. It's really not a good idea to follow TDD instead of using types. You want tests for things that aren't practical to verify, not for replacing static verification.

sgeisenh 5y ago

> just hack away until it works, and fix it if it ever crashes. This also makes collaboration really hard. Types are a form of documentation. But unlike comments, types are enforced by the compiler. Invariably, lots of comments in a codebase are wrong. Many of those probably started out correct but the code changed and the comment didn't.

DonHopkins 5y ago
...to the point where you can improve code quality by deleting comments.
scns 5y ago
In Elixir (and Rust too IIRC) example code in comments is checked by the compiler.

DonHopkins 5y ago

https://news.ycombinator.com/item?id=22210073 https://news.ycombinator.com/item?id=22210073 From the HN discussion about the video of "A Conversation with Language Creators: Guido, James, Anders and Larry" https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 https://www.youtube.com/watch?v=csL8DLXGNlU https://www.youtube.com/watch?v=csL8DLXGNlU I posted these Anders Hejlsberg quotes, who co-designed TypeScript, C#, Delphi, Turbo Pascal, etc: https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 >"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg >"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg [...]

scns 5y ago
I like what Anders Hejlsberg says here, but still wonder why he is not pushing for F# adoption/funding/tooling etc. I'm in no position to judge such an accomplished language designer in any way, just curious. Is it ego? NIH? Or that other thing (Whose name someone else can surely provide) about not being able to see the solution if your salary depends on the problem.
- marcosdumay 5y ago
  It's almost unanimous that the general "null" from C is a very bad idea.
  - scns 5y ago
    I know. C.A.R. Hoare who invented null, called it his Billion Dollar Mistake. https://en.wikipedia.org/wiki/Tony_Hoare?wprov=sfla1 https://en.wikipedia.org/wiki/Tony_Hoare?wprov=sfla1

BobbyJo 5y ago

To tack on to this: Typing is never the limiting factor in my work. Like, if I had to type even double to accomplish the same program, I don't think that would actually slow me down. Given that, the major time difference between using static vs dynamic typing is the investment needed to go from 'throwing things at a wall and seeing what sticks' to understanding what you need to do and doing it.

woojoo666 5y ago
I've found that "throwing things at the wall" can be very helpful sometimes. It isn't necessarily a linear path from designing a solution -> implementing it in code. Sometimes writing some preliminary code can help flesh out the design. It's a symbiotic process. I've wasted countless hours before trying to design a solution on paper when writing the code out and iterating on the code proved much faster. And as for how this relates to static v dynamic typing, when I'm roughing out an implementation I much prefer to leave out types.
- BobbyJo 5y ago
  I find I can hack on things faster with static typing. I'm inevitably picking up new libraries, and using a new library is much easier when it's inputs and outputs are clear. I can see how dynamic would help if you're writing most things yourself, but static definitely has a huge return when interfacing with anything someone else wrote.
  - woojoo666 5y ago
    totally agree. That's why I think libraries and other mature code should use static typing, whereas I like to use dynamic typing for code that I am prototyping. This is why I love Typescript, you can have both :)
blacktriangle 5y ago
Anybody who thinks that avoiding extra typing is the point of dynamic langauges, or that working in a dynamic language is simply throwing things at a wall to see what sticks is completely missing the point. The whole point of dynamic languages is that your problem space is in fact dynamic. In many domains your data simply defies any ontology you try and force it into. Static typing systems themselves are somewhat acknowleging this problem internally with the differences between nominal and structural based typing system. Dynamic langauges are about changing your view on data where instead of shoving all your data into and out of boxes that don't fit, you just see entities as arbitrary collections of attributes and thus typing them makes little sense.

slumdev 5y ago

> I have arrived at the same conclusions as you wrt. static vs dynamic typing. A sufficiently powerful static type system entirely subsumes dynamic typing, and there is quite literally nothing you can accomplish with dynamic typing that you cannot accomplish with such a static type system. After writing software using both dynamically and statically typed languages, this is the conclusion I have arrived at, and it feels like a no-brainer to me. I've come to the same conclusion. A dynamic language is a footgun that doesn't buy any additional power or expressiveness over a well-developed typed language. It gets even worse when dynamic language developers start interacting with data. The "just do whatever" mentality that rejects type design also rejects relational design without any consideration of whether it's (almost certainly) a better choice than a document database.

blacktriangle 5y ago
I find the comment that dynamic typing rejects relational design funny when dynamic typing is what makes working with relational data relationally tractable. Static typing falls down almost immediately when trying to work with your relational data and ends up requiring reams of glue or mapping frameworks just to make your relational data approachable.
- slumdev 5y ago
  It's a feature, not a bug, that the code blows up when the database schema doesn't match my models. Just as the necessity of DI frameworks isn't an argument against unit testing or the inversion principle, the necessity of ORM frameworks isn't an argument against static typing or relational databases.
  - blacktriangle 5y ago
    It's not the schema matching your model, it's the result of any query. How many different types do you need to represent the result of all possible projections on a single 10 attribute relation? Now join that to another 10 attribute relation, how many types to represent all possible projections of a single join between two relations? And Maybe is not the answer, Maybe is a lie. The data is either part of the result set or it is not based on the query.

woojoo666 5y ago

I prefer dynamic typing when writing code that I perceive as "volatile". This is especially true when it's a piece of code that's currently only being worked on by me. Static typing adds boilerplate that feels cumbersome, especially when the types of the variables are already made obvious by the variable names. However when a piece of code becomes mature, doesn't change often, and starts to be depended on by other people (eg a core library), then I start adding types for additional safety and documentation. This system of gradually adding types when needed is why Typescript is so great for me.

aranchelk 5y ago
> Static typing adds boilerplate That’s not necessarily true anymore. Languages like Haskell have both strong static typing and very good type inference. > However when a piece of code becomes mature, doesn't change often, and starts to be depended on by other people (eg a core library), then I start adding types for additional safety and documentation. That’s a practice in Haskell development as well, but the safety and guarantee of consistency are already present prior to the annotations.
- woojoo666 5y ago
  type inference is a beautiful thing and I hope Typescript adds it someday
dllthomas 5y ago
I can see that, but find myself with different preferences. When I know I'll be making changes, I want to be working in a setting where I can tell some checker what I'm assuming, so that it lets me know when work elsewhere invalidates that assumption. Assumptions that will be mechanically checked are assumptions I can (metaphorically) page out in my head as I focus on other things, to be alerted when they again become relevant. I definitely agree that all of this becomes even more important when those assumptions need to be shared between the heads of different individuals.

fulafel 5y ago

> A sufficiently powerful static type system entirely subsumes dynamic typing, and there is quite literally nothing you can accomplish with dynamic typing that you cannot accomplish with such a static type system. After writing software using both dynamically and statically typed languages, this is the conclusion I have arrived at, and it feels like a no-brainer to me. Do you thing some existing practical, high-usability programming language has a sufficiently powerful type system in the way you describe? For me the big thing is that static type systems tend to be simultaneously too powerless to express what I need, and too laborious in demanding manual specification of things that I don't actually need to specify for the program to work. In a dynamic language with a good schema system like malli or spec in Clojure, I can have easily customizable verification that is opt-in.