10 ms·

Static Types Are for Perfectionists

39 points by PaulKeeble 1y ago

PaulKeeble 1y ago
Despite the somewhat clickbait title this is quite interesting on technology preferences and the path to what makes us happy and productive. The idea that our preferences in technology are driven by our path of learning seems relatively self evident, those that started with C/C++ verses Smalltalk verses Java verses Python as their first language likely have a very different perspective on the various trade offs of these languages. Given we don't usually learn every language and certainly not to a deep extent few have deep experiences in all the possibilities to grok the differences in practice on similar projects. "I need the right project and the right team to function well" I really resonate with this, in the right environment I seem vastly more productive. I have a significant preference for low levels of control and oversight and in those environments I can take actions quickly with less discussion and often get to better answers quicker, but I hate not being able to do that and it impacts my performance disproportionately. Its one of those preferences for culture that seems vital to how I want to work and impacts productivity a great deal. Asking permission or high rigour for potentially "extra" work just grinds my gears!
- AnimalMuppet 1y ago
  I don't think it's just "what our path of learning was", though that plays a role. I think that different personalities prefer different styles (functional vs procedural), different languages (static vs dynamic typing), and probably several other axes. This explains, for example, why one person sees functional programming as a massive revelation, where suddenly everything "just fits", and assumes that anyone who doesn't have the same reaction hasn't "gotten it" yet. And others, despite diligent trying, never have that reaction.
parpfish 1y ago
i like static code because a codebase that applies types well gives you the same benefits of writing lots of tests for free.
- cma 1y ago
  Ironically they usually make unit tests and testing by hand in the repl harder
- Spivak 1y ago
  Yep, there is basically nothing else to be said. Using a static type checker isn't some moral imperative or whatever. I simply am able to write better, more correct code faster than without it. And my test suite doesn't have to do things like check the return type of the function because the type checker already knows.
  - igouy 1y ago
    Ummm wouldn't that be check the return value which the type checker doesn't already know?
  - 90s_dev 1y ago
    Type systems make 93% of tests obsolete. The other 7% are implied by developing new features and making sure they work as you expect. If nothing broke, you're good to go. Incidentally, it scales with a team. The more people writing code, the more people who will run into some bugs one of you introduced. In my experience, automated tests (unit or e2e) never reduced that number, but only slowed us down. I wonder if TDD & BDD were just an excuse to bill clients for more time while giving them a false sense of security.
    - theLiminator 1y ago
      Ironically the strongest advocates of dynamic languages tend to be places where a strong type system would solve a huge percentage of their bugs. Web development is mostly the munging of data together and ensuring that you're glueing stuff together correctly. Static type systems, especially ML based ones would ensure that most of this is done correctly.
    - AnimalMuppet 1y ago
      > Type systems make 93% of tests obsolete. I don't suppose I could trouble you for a source for that number?
edg5000 1y ago
I wrote a large enterprise JavaScript application that was behind Apple/Google update approval, was used daily by businesses whose entire operation depended on it. I will never touch loosely typed stuff again. I want every keystroke checked for errors. I want autocomplete to select from possible members/fields/variables/functions/classes rather than doing constant global find/replace operations and having the customer be the beta tester
- emoII 1y ago
  You do write tests, don’t you?
  - fyrn_ 1y ago
    Yeah, that will really help with the auto complete and keystroke by keystroke checking?? What?
  - ninetyninenine 1y ago
    Don't understand why people find tests important but not types. There's two popular ways to verify your programs. Types and tests. Types are EASIER then tests and types COVER more then tests. The ideal thing is to use both, but why spend so much time on unit tests over types is beyond me. Note that integration tests are a different beast. Why? Because you need to test things that aren't covered by either unit tests or types. In unit tests you mock out things that are external like IO, databases, and the like. In integration tests you need to test all of those things. Integration tests are THE most important thing to use to verify your program because it's an actual test to see if your code works. But unit tests vs. types? Types win. When I code. I never write a single unit test. Just types, and integration or end 2 end tests. It doesn't hurt to write a unit test and it's actually better. But the fact that I'm confident my code works without it shows the level of importance.
    - gleenn 1y ago
      If you do it right, your tests cover the thing you care about and are less work usually because you write the test for the part of code that has the interesting part you want to verify works correctly. Types, especially on fully typed languages, make only guarantees about the type of values and they make you do it in places you might not care about. Types also only catch certain classes of errors that I personally find less helpful that tests. So to me, tests are less work, focus on thebimportant parts, and give better error messages. Obviously you can also write bad tests and do things like effectively just check the types in pmaces and you are back to square one. Testing is more of an art but the effort/economics of time are far better to me.
constantcrying 1y ago
I think it is important to understand why you are doing what you are doing. Sure, enjoyment and "authenticity" can be part of it, but it clear that e.g. static vs. dynamic typing is an engineering tradeoff. Making a decision in either direction should be based on those tradeoffs. One important consideration is the importance of the project, hobby projects are for enjoyment mostly, so there "authenticity" is really important. At the same time you shouldn't make decisions on how to develop aerospace software based on how "authentic" the development process feels.
- roman-kashitsyn 1y ago
  > you shouldn't make decisions on how to develop aerospace software based on how "authentic" the development process feels. You don’t just land in an aerospace company with an unbiased, rational mind and make an engineering tradeoff. You join it because you find building high-integrity software fulfilling (I am!), and the job enables you to exercise choices that feel right to you. Alternatively, you are so passionate about space that you can endure whatever it takes to get there, including writing Ada/Spark. The best swimmers don’t grow high and develop long limbs and a big chest due to their practice and rational decisions. They become best by already having a matching physique and working hard to capitalize on it. I don’t promote a fixed mindset, saying that you can’t get better if you weren’t born with a natural talent. My point is that some things will resonate more with you and bring you the most satisfaction. You should try different things, listen to your inner response, and not judge others because they made different choices.
gejose 1y ago
Ragebait title
- constantcrying 1y ago
  And a thread where people respond to the title of an article and not the article itself.
  - chrisweekly 1y ago
    It's not a title that suggests much subtlety or wisdom will be found in the article. EDIT: ... which is unfortunate, bc it's actually a decent read w/ interesting points about the relationship between (programming preferences) and (emotions / psychology).
Jtsummers 1y ago
https://news.ycombinator.com/item?id=43966948 https://news.ycombinator.com/item?id=43966948 I'll make the same remark I did last time this was posted here (it's been submitted 3 times in one week): The author starts with this: > I conclude with two implications of this idea: the necessity to accept other people’s preferences without judgment and the importance of finding an environment rewarding your style. And follows it with these two things: > Type theory maximalists should give up their aura of moral and intellectual superiority and accept that they need therapy just as badly as everyone else in the industry (if not more). >> Haskell will still be used in 20 years, because there will always be people looking for a productive way to weaponize their autism. So much for "without judgement".
- 90s_dev 1y ago
  "If I haven't seen it, it's new to me." I'm very happy to see the case being made for static typing. Dynamic types should be niche, and eventually they will be. Rails and Python only made them popular out of a reactionary minimalism thanks to types done wrong in C++ and Java ecosystems. New developers should read articles like this very early on. The more often they're written and posted, the sooner we can all move on from unnecessary type errors.
- sshine 1y ago
  After writing a lot of Nix in the last year, it has opened me to possibly switch to Scheme. I’ve always been a strong static type guy since 1st year of university, and yes, it ties to perfectionism and even a sense of OCD: if I model the world around me, I can relax. But here’s a take that I’ve been trying to articulate about Nix: it’s not about the static types. Nix is loosely typed, and if there is a functional language that doubles as coping strategy for recreating a quasi-perfect model of the world, it’s Nix. So I believe any strong modelling combined with declarative syntax can be argued is a coping strategy for autism. It’s not strictly the types. It also happens that software made this way is more reliable, breaks less. Maybe the opposition to its use in businesses is that business needs often change rapidly, and tying yourself to any correct understanding of the world means you’re late to the party. (I’ll then argue: there are companies that succeed at strong modelling, and companies that succeed at pivoting, and all companies need a bit of both at different times. That’s why huge companies with scaling problems and infinite runway pick Rust, and startups pick JavaScript.)
90s_dev 1y ago
> Give them time and relevant experience, and they will arrive at the same conclusions: What does this say about DHH then? He's got decades of experience yet ripped TypeScript out of his codebase angrily, preferring the foggy mystery that is dynamic types. Is he a legitimate outlier? If not, then wouldn't you have to conclude he's just a really bad programmer?
- deleted 1y ago
  [deleted]
goda90 1y ago
I work in software where bugs can be very disruptive for the end user's very important job. Typescript was a godsend over JavaScript. I've blamed issues on changes where the developer clearly didn't grok the area they were changing. And I've witnessed dependency hell slowing down the development process. I've come to the conclusions OP did from professional experience that provides negative feedback, not some past psychology from my personal life. There are certainly cases where you wouldn't get that negative feedback for your software, so you would never feel the need for those things. And maybe in that case you can move faster without them, but you should be careful taking those beliefs into other domains.
keithasaurus 1y ago
static types: here's what this piece of data is dynamic types: go look through code, tests, comments and project history to try figure out what this data is supposed to be dynamic types are exhausting
- dleeftink 1y ago
  Exhausting, yes, why would we need to prep our own meal if it can be served to order? Types are needed for sure, but don't make up for the fact we have to prep our own meals from time to time, even the best recipes don't cover all variations.
  - theLiminator 1y ago
    In general though, a strong statically typed language will allow the user to locally reason to a much greater extent.
  - keithasaurus 1y ago
    For me the variation is one of the places where dynamic typing gets really dangerous, because as variations increase, the requirement for code archaeology does as well. At some point there is enough variation that nobody could reasonably be expected to do enough code exploration to understand the full breadth of that variation. With types, the scope of the variation is clearly stated, and if you want to expand the variation, it should be clear how to do so, depending on the flavor (e.g. union types, sum types, generics, sub types).
    - dleeftink 1y ago
      It's definitely easier to extend existing recipes than having to start from none. What I tried to get at, is that even with in-depth recipes, there's a bigger codebase picture behind the type, that GP found exhausting navigating without. I think if we start to lean on types for our all recipes, we may forget how to prepare them without instruction.
  - williamdclt 1y ago
declan_roberts 1y ago
The author is 100% right when he says that personality has a big affect on programming preferences. I see this play out in language preferences every day, INTJ (haskell, rust) and ENTJ (Golang, Java, Python). Giving a list of the "best 3" programming languages can probably map you very accurately to a Meyers-Briggs personality.
- throw4847285 1y ago
  Unfortunately, MBTI is bunk so we'll have to discover a new personality schema that explains people's programming preferences. One may exist, but it won't be a series of binary divisions of normally distributed traits.
  - RetroTechie 1y ago
    640B parameters should be enough to classify everyone's personality.
  - igouy 1y ago
    2018 "Scientists determine four personality types based on new data" https://news.northwestern.edu/stories/2018/september/are-you-average-reserved-self-centered-or-a-role-model/ https://news.northwestern.edu/stories/2018/september/are-you...
    - throw4847285 1y ago
      I love the Big Five. It is a framework with a lot of explanatory power. The Big Five are demonstrably not personality types because each trait is normally distributed. The biggest mistake that the MBTI makes is drawing a line right down the middle of each spectrum and turning it into a binary. So you get absurd scenarios like the 49% introvert and the 51% extrovert having less in common with eachother than with more extreme types. The second biggest mistake is that the Big Five traits are totally independent of each other. Someone can be very open to experience and extremely neurotic which leads to behaviors that do not really make sense in terms of the common sense understanding of personality as a single "type" that is encoded in the MBTI. Relatedly, the third biggest mistake is that there is no dimension for neuroticism in the MBTI. This mistake was so bad that they fixed it by adding a fifth dimension for turbulence. I would be interested in somebody trying to map Big Five onto the choice of programming languages, but then you face the challenge of trying to boil a complex decision down to human temperament. I would bet you $100 that two people with opposite "personalities" can both end up loving Python for very different reasons. Or, what if somebody is average across the board, the most likely scenario. What programming language are they going to gravitate towards? Sorry you just shared a link to an article and I went off, but this is a topic that really gets me fired up.
bpshaver 1y ago
I would love to read the steel man case for dynamic typing, but "static typing is for people who need therapy" isn't doing it for me. Anyone have something to recommend so I can understand the intended benefits of dynamic typing?
- bryanlarsen 1y ago
  My attempt: "These dynamic languages are so much more pleasant and productive than Java 1.X."
- lisper 1y ago
  > I would love to read the steel man case for dynamic typing It's very simple: sometimes lower development effort matters more than correctness. Not all software has to run in a hostile production environment to be useful.
  - bpshaver 1y ago
    That would seem to be begging the question to an extent. Why does dynamic typing lead to lower development effort? I mostly write Python and make heavy use of type hints. With LSP set up, mypy informs me immediately of any potential type errors which makes development way easier for me. Just saying "dynamic typing is easier" doesn't do it for me without further qualification since that statement doesn't conform to my own experience.
    - doug_durham 1y ago
      How much is maintaining your type system really helping you out? I find I spend more time tracking down irrelevant type warnings than fixing type issues. For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false. So now I have to update my declaration to be `foo: Optional[int] = None`. This yields no value because when you say `= None` you are saying that this is an optional argument. The more you tighten your type declarations the more you will be chasing non-existent issues.
adamnemecek 1y ago
Types give you speed, correctness and better tooling. Dynamic typing supposedly gives you "authentic self". I think I'll pick the former.
dkarl 1y ago
The author seems obsessed with what their code says about them personally, and only mentions other people to discuss other points of view on this question. At no point do they say anything about how working with other people influenced their thinking about programming or their technical preferences. In fact they only mention peers a single time: > I met many people whose programming approach was my polar opposite.... I don’t have any issues with their way, as long as we don’t work on the same system Being obsessed with what your code says about you is a concern that competes with and inevitably detracts from other desirable outcomes. This is true even when working by yourself, but it is especially true and especially obvious when working with other people.
alabhyajindal 1y ago
So many comments about static vs dynamic typing whereas the article barely discusses that. I loved reading this - very well written!

39 points by PaulKeeble 1y ago

Despite the somewhat clickbait title this is quite interesting on technology preferences and the path to what makes us happy and productive. The idea that our preferences in technology are driven by our path of learning seems relatively self evident, those that started with C/C++ verses Smalltalk verses Java verses Python as their first language likely have a very different perspective on the various trade offs of these languages. Given we don't usually learn every language and certainly not to a deep extent few have deep experiences in all the possibilities to grok the differences in practice on similar projects. "I need the right project and the right team to function well" I really resonate with this, in the right environment I seem vastly more productive. I have a significant preference for low levels of control and oversight and in those environments I can take actions quickly with less discussion and often get to better answers quicker, but I hate not being able to do that and it impacts my performance disproportionately. Its one of those preferences for culture that seems vital to how I want to work and impacts productivity a great deal. Asking permission or high rigour for potentially "extra" work just grinds my gears!

AnimalMuppet 1y ago
I don't think it's just "what our path of learning was", though that plays a role. I think that different personalities prefer different styles (functional vs procedural), different languages (static vs dynamic typing), and probably several other axes. This explains, for example, why one person sees functional programming as a massive revelation, where suddenly everything "just fits", and assumes that anyone who doesn't have the same reaction hasn't "gotten it" yet. And others, despite diligent trying, never have that reaction.

parpfish 1y ago

i like static code because a codebase that applies types well gives you the same benefits of writing lots of tests for free.

cma 1y ago
Ironically they usually make unit tests and testing by hand in the repl harder
Spivak 1y ago
Yep, there is basically nothing else to be said. Using a static type checker isn't some moral imperative or whatever. I simply am able to write better, more correct code faster than without it. And my test suite doesn't have to do things like check the return type of the function because the type checker already knows.
- igouy 1y ago
  Ummm wouldn't that be check the return value which the type checker doesn't already know?
- 90s_dev 1y ago
  Type systems make 93% of tests obsolete. The other 7% are implied by developing new features and making sure they work as you expect. If nothing broke, you're good to go. Incidentally, it scales with a team. The more people writing code, the more people who will run into some bugs one of you introduced. In my experience, automated tests (unit or e2e) never reduced that number, but only slowed us down. I wonder if TDD & BDD were just an excuse to bill clients for more time while giving them a false sense of security.
  - theLiminator 1y ago
    Ironically the strongest advocates of dynamic languages tend to be places where a strong type system would solve a huge percentage of their bugs. Web development is mostly the munging of data together and ensuring that you're glueing stuff together correctly. Static type systems, especially ML based ones would ensure that most of this is done correctly.
  - AnimalMuppet 1y ago
    > Type systems make 93% of tests obsolete. I don't suppose I could trouble you for a source for that number?

edg5000 1y ago

I wrote a large enterprise JavaScript application that was behind Apple/Google update approval, was used daily by businesses whose entire operation depended on it. I will never touch loosely typed stuff again. I want every keystroke checked for errors. I want autocomplete to select from possible members/fields/variables/functions/classes rather than doing constant global find/replace operations and having the customer be the beta tester

emoII 1y ago
You do write tests, don’t you?
- fyrn_ 1y ago
  Yeah, that will really help with the auto complete and keystroke by keystroke checking?? What?
- ninetyninenine 1y ago
  Don't understand why people find tests important but not types. There's two popular ways to verify your programs. Types and tests. Types are EASIER then tests and types COVER more then tests. The ideal thing is to use both, but why spend so much time on unit tests over types is beyond me. Note that integration tests are a different beast. Why? Because you need to test things that aren't covered by either unit tests or types. In unit tests you mock out things that are external like IO, databases, and the like. In integration tests you need to test all of those things. Integration tests are THE most important thing to use to verify your program because it's an actual test to see if your code works. But unit tests vs. types? Types win. When I code. I never write a single unit test. Just types, and integration or end 2 end tests. It doesn't hurt to write a unit test and it's actually better. But the fact that I'm confident my code works without it shows the level of importance.
  - gleenn 1y ago
    If you do it right, your tests cover the thing you care about and are less work usually because you write the test for the part of code that has the interesting part you want to verify works correctly. Types, especially on fully typed languages, make only guarantees about the type of values and they make you do it in places you might not care about. Types also only catch certain classes of errors that I personally find less helpful that tests. So to me, tests are less work, focus on thebimportant parts, and give better error messages. Obviously you can also write bad tests and do things like effectively just check the types in pmaces and you are back to square one. Testing is more of an art but the effort/economics of time are far better to me.

constantcrying 1y ago

I think it is important to understand why you are doing what you are doing. Sure, enjoyment and "authenticity" can be part of it, but it clear that e.g. static vs. dynamic typing is an engineering tradeoff. Making a decision in either direction should be based on those tradeoffs. One important consideration is the importance of the project, hobby projects are for enjoyment mostly, so there "authenticity" is really important. At the same time you shouldn't make decisions on how to develop aerospace software based on how "authentic" the development process feels.

roman-kashitsyn 1y ago
> you shouldn't make decisions on how to develop aerospace software based on how "authentic" the development process feels. You don’t just land in an aerospace company with an unbiased, rational mind and make an engineering tradeoff. You join it because you find building high-integrity software fulfilling (I am!), and the job enables you to exercise choices that feel right to you. Alternatively, you are so passionate about space that you can endure whatever it takes to get there, including writing Ada/Spark. The best swimmers don’t grow high and develop long limbs and a big chest due to their practice and rational decisions. They become best by already having a matching physique and working hard to capitalize on it. I don’t promote a fixed mindset, saying that you can’t get better if you weren’t born with a natural talent. My point is that some things will resonate more with you and bring you the most satisfaction. You should try different things, listen to your inner response, and not judge others because they made different choices.

gejose 1y ago

Ragebait title

constantcrying 1y ago
And a thread where people respond to the title of an article and not the article itself.
- chrisweekly 1y ago
  It's not a title that suggests much subtlety or wisdom will be found in the article. EDIT: ... which is unfortunate, bc it's actually a decent read w/ interesting points about the relationship between (programming preferences) and (emotions / psychology).

Jtsummers 1y ago

https://news.ycombinator.com/item?id=43966948 https://news.ycombinator.com/item?id=43966948 I'll make the same remark I did last time this was posted here (it's been submitted 3 times in one week): The author starts with this: > I conclude with two implications of this idea: the necessity to accept other people’s preferences without judgment and the importance of finding an environment rewarding your style. And follows it with these two things: > Type theory maximalists should give up their aura of moral and intellectual superiority and accept that they need therapy just as badly as everyone else in the industry (if not more). >> Haskell will still be used in 20 years, because there will always be people looking for a productive way to weaponize their autism. So much for "without judgement".

90s_dev 1y ago
"If I haven't seen it, it's new to me." I'm very happy to see the case being made for static typing. Dynamic types should be niche, and eventually they will be. Rails and Python only made them popular out of a reactionary minimalism thanks to types done wrong in C++ and Java ecosystems. New developers should read articles like this very early on. The more often they're written and posted, the sooner we can all move on from unnecessary type errors.
sshine 1y ago
After writing a lot of Nix in the last year, it has opened me to possibly switch to Scheme. I’ve always been a strong static type guy since 1st year of university, and yes, it ties to perfectionism and even a sense of OCD: if I model the world around me, I can relax. But here’s a take that I’ve been trying to articulate about Nix: it’s not about the static types. Nix is loosely typed, and if there is a functional language that doubles as coping strategy for recreating a quasi-perfect model of the world, it’s Nix. So I believe any strong modelling combined with declarative syntax can be argued is a coping strategy for autism. It’s not strictly the types. It also happens that software made this way is more reliable, breaks less. Maybe the opposition to its use in businesses is that business needs often change rapidly, and tying yourself to any correct understanding of the world means you’re late to the party. (I’ll then argue: there are companies that succeed at strong modelling, and companies that succeed at pivoting, and all companies need a bit of both at different times. That’s why huge companies with scaling problems and infinite runway pick Rust, and startups pick JavaScript.)

90s_dev 1y ago

> Give them time and relevant experience, and they will arrive at the same conclusions: What does this say about DHH then? He's got decades of experience yet ripped TypeScript out of his codebase angrily, preferring the foggy mystery that is dynamic types. Is he a legitimate outlier? If not, then wouldn't you have to conclude he's just a really bad programmer?

deleted 1y ago
[deleted]

goda90 1y ago

I work in software where bugs can be very disruptive for the end user's very important job. Typescript was a godsend over JavaScript. I've blamed issues on changes where the developer clearly didn't grok the area they were changing. And I've witnessed dependency hell slowing down the development process. I've come to the conclusions OP did from professional experience that provides negative feedback, not some past psychology from my personal life. There are certainly cases where you wouldn't get that negative feedback for your software, so you would never feel the need for those things. And maybe in that case you can move faster without them, but you should be careful taking those beliefs into other domains.

keithasaurus 1y ago

static types: here's what this piece of data is dynamic types: go look through code, tests, comments and project history to try figure out what this data is supposed to be dynamic types are exhausting

dleeftink 1y ago
Exhausting, yes, why would we need to prep our own meal if it can be served to order? Types are needed for sure, but don't make up for the fact we have to prep our own meals from time to time, even the best recipes don't cover all variations.
- theLiminator 1y ago
  In general though, a strong statically typed language will allow the user to locally reason to a much greater extent.
- keithasaurus 1y ago
  For me the variation is one of the places where dynamic typing gets really dangerous, because as variations increase, the requirement for code archaeology does as well. At some point there is enough variation that nobody could reasonably be expected to do enough code exploration to understand the full breadth of that variation. With types, the scope of the variation is clearly stated, and if you want to expand the variation, it should be clear how to do so, depending on the flavor (e.g. union types, sum types, generics, sub types).
  - dleeftink 1y ago
    It's definitely easier to extend existing recipes than having to start from none. What I tried to get at, is that even with in-depth recipes, there's a bigger codebase picture behind the type, that GP found exhausting navigating without. I think if we start to lean on types for our all recipes, we may forget how to prepare them without instruction.
- williamdclt 1y ago

declan_roberts 1y ago

The author is 100% right when he says that personality has a big affect on programming preferences. I see this play out in language preferences every day, INTJ (haskell, rust) and ENTJ (Golang, Java, Python). Giving a list of the "best 3" programming languages can probably map you very accurately to a Meyers-Briggs personality.

throw4847285 1y ago
Unfortunately, MBTI is bunk so we'll have to discover a new personality schema that explains people's programming preferences. One may exist, but it won't be a series of binary divisions of normally distributed traits.
- RetroTechie 1y ago
  640B parameters should be enough to classify everyone's personality.
- igouy 1y ago
  2018 "Scientists determine four personality types based on new data" https://news.northwestern.edu/stories/2018/september/are-you-average-reserved-self-centered-or-a-role-model/ https://news.northwestern.edu/stories/2018/september/are-you...
  - throw4847285 1y ago
    I love the Big Five. It is a framework with a lot of explanatory power. The Big Five are demonstrably not personality types because each trait is normally distributed. The biggest mistake that the MBTI makes is drawing a line right down the middle of each spectrum and turning it into a binary. So you get absurd scenarios like the 49% introvert and the 51% extrovert having less in common with eachother than with more extreme types. The second biggest mistake is that the Big Five traits are totally independent of each other. Someone can be very open to experience and extremely neurotic which leads to behaviors that do not really make sense in terms of the common sense understanding of personality as a single "type" that is encoded in the MBTI. Relatedly, the third biggest mistake is that there is no dimension for neuroticism in the MBTI. This mistake was so bad that they fixed it by adding a fifth dimension for turbulence. I would be interested in somebody trying to map Big Five onto the choice of programming languages, but then you face the challenge of trying to boil a complex decision down to human temperament. I would bet you $100 that two people with opposite "personalities" can both end up loving Python for very different reasons. Or, what if somebody is average across the board, the most likely scenario. What programming language are they going to gravitate towards? Sorry you just shared a link to an article and I went off, but this is a topic that really gets me fired up.

bpshaver 1y ago

I would love to read the steel man case for dynamic typing, but "static typing is for people who need therapy" isn't doing it for me. Anyone have something to recommend so I can understand the intended benefits of dynamic typing?

bryanlarsen 1y ago
My attempt: "These dynamic languages are so much more pleasant and productive than Java 1.X."
lisper 1y ago
> I would love to read the steel man case for dynamic typing It's very simple: sometimes lower development effort matters more than correctness. Not all software has to run in a hostile production environment to be useful.
- bpshaver 1y ago
  That would seem to be begging the question to an extent. Why does dynamic typing lead to lower development effort? I mostly write Python and make heavy use of type hints. With LSP set up, mypy informs me immediately of any potential type errors which makes development way easier for me. Just saying "dynamic typing is easier" doesn't do it for me without further qualification since that statement doesn't conform to my own experience.
  - doug_durham 1y ago
    How much is maintaining your type system really helping you out? I find I spend more time tracking down irrelevant type warnings than fixing type issues. For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false. So now I have to update my declaration to be `foo: Optional[int] = None`. This yields no value because when you say `= None` you are saying that this is an optional argument. The more you tighten your type declarations the more you will be chasing non-existent issues.

adamnemecek 1y ago

Types give you speed, correctness and better tooling. Dynamic typing supposedly gives you "authentic self". I think I'll pick the former.

dkarl 1y ago

The author seems obsessed with what their code says about them personally, and only mentions other people to discuss other points of view on this question. At no point do they say anything about how working with other people influenced their thinking about programming or their technical preferences. In fact they only mention peers a single time: > I met many people whose programming approach was my polar opposite.... I don’t have any issues with their way, as long as we don’t work on the same system Being obsessed with what your code says about you is a concern that competes with and inevitably detracts from other desirable outcomes. This is true even when working by yourself, but it is especially true and especially obvious when working with other people.

alabhyajindal 1y ago

So many comments about static vs dynamic typing whereas the article barely discusses that. I loved reading this - very well written!