Static Types Are for Perfectionists(mmapped.blog)
mmapped.blog
Static Types Are for Perfectionists
https://mmapped.blog/posts/38-static-types-perfectionism
130 comments
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.)
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.)
"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.
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.
[deleted]
> So much for "without judgement".
Previously author felt enlightened by sneering on stupid normies for not understanding beautiful, clean™, statically typed code.
What’s better way to show how better you’re now, that you’ve reached new nirvana, by sneering on ivory tower wizards with their arcane languages that are obviously a sign of autism (because whoever is different from, and possibly smarter than, you is obviously autistic)?
Previously author felt enlightened by sneering on stupid normies for not understanding beautiful, clean™, statically typed code.
What’s better way to show how better you’re now, that you’ve reached new nirvana, by sneering on ivory tower wizards with their arcane languages that are obviously a sign of autism (because whoever is different from, and possibly smarter than, you is obviously autistic)?
Author here.
> because whoever is different from, and possibly smarter than, you is obviously autistic
I’m not sure how you came to this conclusion from the text I wrote.
Autism has nothing to do with intelligence level.
BTW, I identify as autistic. And I find Haskell very soothing.
> because whoever is different from, and possibly smarter than, you is obviously autistic
I’m not sure how you came to this conclusion from the text I wrote.
Autism has nothing to do with intelligence level.
BTW, I identify as autistic. And I find Haskell very soothing.
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
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
I adopted Python type annotations on a new project I was writing. Requirements shifted a lot as well as the implementation.
It was amazing. I could refactor quickly after changing a dataclass, field name, function arguments, type, etc. I just ran mypy and it immediately told me everywhere I needed to update code to reference the new refactored type or data structure.
Then only after it was mypy clean, I ran the unit tests.
It was amazing. I could refactor quickly after changing a dataclass, field name, function arguments, type, etc. I just ran mypy and it immediately told me everywhere I needed to update code to reference the new refactored type or data structure.
Then only after it was mypy clean, I ran the unit tests.
My style has changed over time and part of it is thanks to static type checking in Python. I rarely use dictionaries anymore when what I actually want is a different type that functions will handle down the line. So to transfer data, I usually make frozen dataclasses where I used to use dictionaries. It's more work when you want to add fields on the fly ofc but it pays dividend anytime the logic becomes more complex.
Agreed -- dataclasses over dicts. And for legacy code I try to move them to typed dictionaries.
Pydantic is also helpful to enforce types on json.
I've also stopped passing around argparse namespaces. I immediately push the argparse namespace into a pydantic class (although a dataclass could also be used.)
Pydantic is also helpful to enforce types on json.
I've also stopped passing around argparse namespaces. I immediately push the argparse namespace into a pydantic class (although a dataclass could also be used.)
Yes, but, the longer I use python (for personal and admin tasks mostly), the more the REPL and pytest let me sneak up on the 80% solution to my task at hand and get on with life.
The scope of possibility does not end with a full-on enterprise application, having all of the Bell() and Whistle() classes.
The scope of possibility does not end with a full-on enterprise application, having all of the Bell() and Whistle() classes.
Even better, run `mypy` as part of your LSP setup and you don't even need to wait to run `mypy` to see type errors! If I make a mistake I want to be notified immediately.
Just use VSCode with Pylance. Much better than Mypy.
You do write tests, don’t you?
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.
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.
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.
> types [...] make only guarantees about the type of values
What do you think "type of values" means and encodes, and why do you think it's different from your handwritten tests?
I assume you do know that type checking is more than simply validating you're passing a string to a function that expects a string argument?
> Types also only catch certain classes of errors
Which classes of errors? Why do you think manually written unit tests are more complete?
What do you think "type of values" means and encodes, and why do you think it's different from your handwritten tests?
I assume you do know that type checking is more than simply validating you're passing a string to a function that expects a string argument?
> Types also only catch certain classes of errors
Which classes of errors? Why do you think manually written unit tests are more complete?
If I have a complicated set of business-logic functions that all return booleans, the type-checker can tell me I got a boolean back but not that in xyz scenario my result should be true and abc scenario it should be false. You must write a test for that, the types are only the most marginal at helping check correctness. There are many more examples like this. If I have to write the tests, why do I want to spend time writing all the types too if my tests cover the things I care about the the types only cover details like "you returned a number from a function marked boolean", that type of error is super easy to catch with a test, so I didn't need the types.
> the types only cover details like "you returned a number from a function marked boolean", that type of error is super easy to catch with a test, so I didn't need the types
Thanks for your reply, this is why I asked: this kind of typechecking you describe only scratches the basics of what a robust type-checking system can do.
In practice, it can cover much more than "you returned a number from a function marked as boolean", and so it saves you from writing lots of unit tests, leaving you free to write only the few tests that make sense for your business logic.
Once you have a proper type system in place, you can do much more than:
> [...] a complicated set of business-logic functions that all return booleans [...]
You can encode more useful things in the type of the functions than just "it returns a boolean". Of course if every function you write only returns a boolean you won't get much from the type system! But that's circular reasoning...
Thanks for your reply, this is why I asked: this kind of typechecking you describe only scratches the basics of what a robust type-checking system can do.
In practice, it can cover much more than "you returned a number from a function marked as boolean", and so it saves you from writing lots of unit tests, leaving you free to write only the few tests that make sense for your business logic.
Once you have a proper type system in place, you can do much more than:
> [...] a complicated set of business-logic functions that all return booleans [...]
You can encode more useful things in the type of the functions than just "it returns a boolean". Of course if every function you write only returns a boolean you won't get much from the type system! But that's circular reasoning...
It's not circular reasoning, I literally have piles of boolean-typed functions in business logic and there is no quantity of type-checking that will validate that (defn should-go [light-is-green? intersection-is-clear?] (and light-is-green? intersection-is-clear?)) is correct. That requires an actual test. Obviously my example is trivial but they quickly become non-trivial and the type-chrcker will never save me if I replace "and" with "or".
> I literally have piles of boolean-typed functions in business logic
Yes, but this is working with legacy code that wasn't written with a mature type-checking system in mind. The boolean type encodes very little meaning with it, and so there's not much you can reason about it, as you've noticed.
If your argument is "a modern type system cannot help me much with legacy code that didn't leverage it to begin with" I can understand you and even agree somewhat. But that's a different argument.
That's what I mean by circular reasoning: if you don't use the types, then yes, a type system won't be of much use. You'll spend time writing unit tests, which for legacy code seems like an adequate approach.
Yes, but this is working with legacy code that wasn't written with a mature type-checking system in mind. The boolean type encodes very little meaning with it, and so there's not much you can reason about it, as you've noticed.
If your argument is "a modern type system cannot help me much with legacy code that didn't leverage it to begin with" I can understand you and even agree somewhat. But that's a different argument.
That's what I mean by circular reasoning: if you don't use the types, then yes, a type system won't be of much use. You'll spend time writing unit tests, which for legacy code seems like an adequate approach.
If your type-checker is “mature" enough to encode the full value level semantics of the code it types (rendering the code itself superfluous, as then you’d just need to compile the type-level code to get your app), you then have the problem of validating the logic of the type-level code, and the natural solution to that problem is, again, testing.
[deleted]
Type checking is modeling + testing.
I neither used the word legacy nor modern. I don't care how fancy your type checker is today or tomorrow, the arbitrarily deeply complicated boolean-typed function I write tomorrow gleans nearly zero value from type validation. It gains actual validation of correctness with real tests.
It's a legacy problem in the sense your system is a badly designed mess of functions that only return boolean. You could encode additional semantics in the types. Of course if you don't, the type system will be unhelpful.
This is a modeling problem at this point. Types can make your model better by encoding more things. It's often not easy or feasible to refactor the mess, so sometimes you're stuck with it.
This is a modeling problem at this point. Types can make your model better by encoding more things. It's often not easy or feasible to refactor the mess, so sometimes you're stuck with it.
Can you explain concretely how adding types would make a bunch of boolean-valued functions and some tests better? What types would you introduce to my example?
Depending on your language, some things may not be easy to encode in types. "Verify that the function handles gracefully the situation where the map it's passed doesn't contain that one magic entry." That won't be easy to encode in a type...
Of course not everything can be encoded in types, and also YMMV regarding the specific language you're using.
But you now why I asked the question: people who make claims like "types make only guarantees about the type of values" usually don't understand what modern type-checking can do or what can be encoded in types. People making these claims often believe type-checking is limited to validating that you only pass strings to a function expecting a string argument, or some minor variation of that.
But you now why I asked the question: people who make claims like "types make only guarantees about the type of values" usually don't understand what modern type-checking can do or what can be encoded in types. People making these claims often believe type-checking is limited to validating that you only pass strings to a function expecting a string argument, or some minor variation of that.
The fact remains that your type system can be turing-complete and still not validate the actual logic that I need checked/tested.
The same can be said of tests.
Types are just tests. By removing all the mindless, repetitive tests you write, typechecking can free you up to write the actual meaningful tests that you truly need to write.
It's not "pick one", it's "use type checking to help you only write the unit tests that matter".
Types are just tests. By removing all the mindless, repetitive tests you write, typechecking can free you up to write the actual meaningful tests that you truly need to write.
It's not "pick one", it's "use type checking to help you only write the unit tests that matter".
> 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.
Imo this might be true if you're writing a lot of glue code. But I think unit tests are extremely valuable for testing pure functions that are pure logic/computation. For glue code/ensuring everything is hooked up correctly, types easily beat tests, but for pure logic tests (ideally property based testing if you can swing it) works great.
Imo this might be true if you're writing a lot of glue code. But I think unit tests are extremely valuable for testing pure functions that are pure logic/computation. For glue code/ensuring everything is hooked up correctly, types easily beat tests, but for pure logic tests (ideally property based testing if you can swing it) works great.
Game developers work with more purity then web devs as web devs always funnel pure computations to external resources (usually the database).
The weird thing is Game developers don't unit test stuff. Why? Because it's mostly not that effective. I know a lot of people say stuff like game devs are cowboys that don't follow best practices but that's not true. A lot of game devs know their shit inside and out.
Here's the reason why Game devs don't unit test. There's no point. They run the program themselves a couple of times on their own computer and their good. The problem with web dev is that all their code is so Tied with IO they can't even run the code on their computer. So in order to test their logic they have to write mocks and then unit test their code with mocks in place. But why even do this when you can cover it all with an integration test?
Hence I don't unit test. My integration tests and type checking covers it all.
The weird thing is Game developers don't unit test stuff. Why? Because it's mostly not that effective. I know a lot of people say stuff like game devs are cowboys that don't follow best practices but that's not true. A lot of game devs know their shit inside and out.
Here's the reason why Game devs don't unit test. There's no point. They run the program themselves a couple of times on their own computer and their good. The problem with web dev is that all their code is so Tied with IO they can't even run the code on their computer. So in order to test their logic they have to write mocks and then unit test their code with mocks in place. But why even do this when you can cover it all with an integration test?
Hence I don't unit test. My integration tests and type checking covers it all.
Like tests, types can be more hassle than theyre worth if you dont use them correctly.
Before mypy came along I was pretty disciplined at A) testing and B) ruthlessly clamping down on primitive obsession.
I use types a lot now but I didnt see enormous quality or productivity gains when I started using them. I suspect people who let compilers catch their bugs were always A) pretty lax testers and B) probably often let primitive obsession get the better of them.
There are only a few types of tests where I think that types actually serve as an appropriate substitute.
Before mypy came along I was pretty disciplined at A) testing and B) ruthlessly clamping down on primitive obsession.
I use types a lot now but I didnt see enormous quality or productivity gains when I started using them. I suspect people who let compilers catch their bugs were always A) pretty lax testers and B) probably often let primitive obsession get the better of them.
There are only a few types of tests where I think that types actually serve as an appropriate substitute.
TDD and BDD are security blankets for enterprises and clients. They add disproportionately little value, and significantly increase the cost of evolving an app in any direction.
TDD/BDD are just tools, in some cases they're useful and some other cases they're not.
If your work is deeply exploratory and you don't even know what the final interface/API will look like, you shouldn't start with TDD. You should probably test as you go though, once you find some behavior you'd like to keep and pin down variations and edge cases you met during dev.
If/Once you know what the expected behavior is, you can encapsulate that knowledge in tests, that's TDD to me. Then, I can write more code that meets the need of the expected API.
If your work is deeply exploratory and you don't even know what the final interface/API will look like, you shouldn't start with TDD. You should probably test as you go though, once you find some behavior you'd like to keep and pin down variations and edge cases you met during dev.
If/Once you know what the expected behavior is, you can encapsulate that knowledge in tests, that's TDD to me. Then, I can write more code that meets the need of the expected API.
TDD and BDD teaching and tutorials are almost universally terrible so people inevitably do them badly and then moan about the results, which can be worse than not using them at all.
Usually the primary mistake is either using cucumber (which is awful) or surrounding the wrong interfaces with tests (usually at too low a level).
Done well they are like a mini superpower.
Usually the primary mistake is either using cucumber (which is awful) or surrounding the wrong interfaces with tests (usually at too low a level).
Done well they are like a mini superpower.
I've learned from the so-called experts for years. I studied directly under them. I spent so many years trying to find the perfect way to do TDD and BDD. I saw their own code and their own solutions up close. They're frauds. It was all a sham.
I'd be shocked if it wasnt because they also led you to make the two primary mistakes i refered to above.
Ah so you're the guru I should have studied under all those years. If only.
Perhaps. More than a famous guru I find most companies badly need a testing framework that can simulate 90% of possible scenarios hermetically and lack somebody who can build that.
Once you have that and somebody has taken you around the block 3 or 4 times pairing with TDD on your app it usually starts to make more sense.
On my team after I inculcated the TDD habit properly, BDD came naturally. I didnt even encourage them to have conversations with the PO while screensharing the tests. They dont even know that's called BDD.
Once you have that and somebody has taken you around the block 3 or 4 times pairing with TDD on your app it usually starts to make more sense.
On my team after I inculcated the TDD habit properly, BDD came naturally. I didnt even encourage them to have conversations with the PO while screensharing the tests. They dont even know that's called BDD.
"unit tests are a poor man's compiler" (NN)
Yeah, that will really help with the auto complete and keystroke by keystroke checking??
What?
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.
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 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.
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.
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.
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.
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
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
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.
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.
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).
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).
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.
I think if we start to lean on types for our all recipes, we may forget how to prepare them without instruction.
In general though, a strong statically typed language will allow the user to locally reason to a much greater extent.
If there’s a lot of variations that’s exactly when you need help from typing to not mess things up.
If the modelling is trivial, the ROI is much lower (although the devx benefits still make it worth it to me)
If the modelling is trivial, the ROI is much lower (although the devx benefits still make it worth it to me)
static types: write types into the code to make the compiler happy, when trying to think about more important stuff
dynamic types: method parameter name gives the type and comment gives the method return type — conventions show what data is supposed to be
static types are disruptive and exhausting :-)
dynamic types: method parameter name gives the type and comment gives the method return type — conventions show what data is supposed to be
static types are disruptive and exhausting :-)
i like static code because a codebase that applies types well gives you the same benefits of writing lots of tests for free.
The benefits are not the same. Code can type check but not be correct.
There's no free lunch. Some languages require explicit type definitions others don't.
There's no free lunch. Some languages require explicit type definitions others don't.
Conversely, code can pass tests and not be correct, including in ways that would have been trivially caught by a type system.
If you care about correctness, use both. Codebases written in static languages still use tests.
If you care about correctness, use both. Codebases written in static languages still use tests.
> Code can type check but not be correct.
Depends on your type system. It can prove the correctness of certain properties depending on your language.
Conversely, unit tests can pass but your code might not be correct.
Depends on your type system. It can prove the correctness of certain properties depending on your language.
Conversely, unit tests can pass but your code might not be correct.
Depends on your type system. Depends on your tests. Depends.
Yet another under-specified commentary ;-)
Yet another under-specified commentary ;-)
Well, yeah. Types don’t remove the need for ALL tests, but it removes the need for the most boring 90% so your test suite can just focus on the most important behaviors
[deleted]
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.
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.
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.
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.
> Type systems make 93% of tests obsolete.
I don't suppose I could trouble you for a source for that number?
I don't suppose I could trouble you for a source for that number?
Ummm wouldn't that be check the return value which the type checker doesn't already know?
Ironically they usually make unit tests and testing by hand in the repl harder
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?
> 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.
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.
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.
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.
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.
> 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.
No, it is correct. The value None is not with the domain of type int, a parameter that can take the value None does not in fact have type int.
> This yields no value because when you say `= None` you are saying that this is an optional argument.
When you provide any default value, you are making the argument optional, but that's an orthogonal concern to the Optional[T] type, which doesn't mean “optional argument", it is simply a more convenient way of expressing Union[T, None], though with the modern type syntax, T | U is generally more convenient than either Union[T, U] or Optional[T] for U=None.
No, it is correct. The value None is not with the domain of type int, a parameter that can take the value None does not in fact have type int.
> This yields no value because when you say `= None` you are saying that this is an optional argument.
When you provide any default value, you are making the argument optional, but that's an orthogonal concern to the Optional[T] type, which doesn't mean “optional argument", it is simply a more convenient way of expressing Union[T, None], though with the modern type syntax, T | U is generally more convenient than either Union[T, U] or Optional[T] for U=None.
No offense, but this sounds like user error. I rarely have irrelevant type warnings. If I do, it suggests something is wrong with my design.
If you declare a function parameter as `foo: int = None`... that is just an incorrect declaration. Of course a variable annotated as `int` can take a `None` value, but that is because any variable can take any type in Python. Within the Python type (annotation) system it is simply the case that an `int` and an `int | None` are two different things, as they are in other languages (eg Rust's `T` vs `Option<T>` types).
Mypy used to support the "implicit optional" feature you describe but now you must make nullable arguments explicitly optional. This is in line with Python's "explicit is better than implicit" design philosophy. In any case, how long does it take you to just type `foo: int | None = None`? Or you could re-enable the old behavior to allow implicit optionals with `--implicit-optional` or the corresponding config file option. It seems like you just need to configure mypy to match your preferences rather than fighting with its defaults.
To return to the broader point, I'm unsure what an "irrelevant type warning" is, but I suspect that has something to do with my lack of appreciation for dynamic typing. Can you give an example that isn't just a complaint about typing an extra 6 characters or about mypy being misconfigured for your preferences?
If you declare a function parameter as `foo: int = None`... that is just an incorrect declaration. Of course a variable annotated as `int` can take a `None` value, but that is because any variable can take any type in Python. Within the Python type (annotation) system it is simply the case that an `int` and an `int | None` are two different things, as they are in other languages (eg Rust's `T` vs `Option<T>` types).
Mypy used to support the "implicit optional" feature you describe but now you must make nullable arguments explicitly optional. This is in line with Python's "explicit is better than implicit" design philosophy. In any case, how long does it take you to just type `foo: int | None = None`? Or you could re-enable the old behavior to allow implicit optionals with `--implicit-optional` or the corresponding config file option. It seems like you just need to configure mypy to match your preferences rather than fighting with its defaults.
To return to the broader point, I'm unsure what an "irrelevant type warning" is, but I suspect that has something to do with my lack of appreciation for dynamic typing. Can you give an example that isn't just a complaint about typing an extra 6 characters or about mypy being misconfigured for your preferences?
No offense taken. I've had a long career with many different phases. I had a phase where I built palaces of types bordering on DSLs. I ended up building myself a straight jacket. I wasn't solving the customer problem, and I was only slowing myself down. Software is an engineering discipline. Every situation needs to be critically evaluated. Building a life-critical single point of failure component is much different than building a road over a culvert. In early languages you needed to specify types so the compiler knew how much space to allocate for storage. In languages like Python, type hints are more like documentation. It helps the reader understand how to use your code. It can be used for correctness. However if correctness is a primary criteria driven by engineering requirements I'd probably consider another language and accept that it is going to cost more and be slower to develop.
>That would seem to be begging the question …
Please excuse my pedantry: That would seem to lead to the question …
Please excuse my pedantry: That would seem to lead to the question …
No, I was correct. Briefly, my question was "why is static typing good?" and the answer given was "static typing is good because it makes development easier." To the extent that "good" here just means "makes development easier" (and I think that is a lot of what "good" means in this context) then the answer I received was question begging to precisely that extent. Which is why I said "... to an extent." The conclusion was not quite assumed but a pretty similar conclusion was.
I can see how it appeared that I was using the phrase in the incorrect way! That usage bothers me too, and I am attentive to it.
I can see how it appeared that I was using the phrase in the incorrect way! That usage bothers me too, and I am attentive to it.
Yes, you were correct. Apologies.
> Why does dynamic typing lead to lower development effort?
Because you can run your program to see what it does without having to appease the type checker first.
There is nothing wrong with presenting type hints or type errors as warnings. The problems arise when the compiler just flat-out refuses to run your code until you have finished handling every possible branch path.
Because you can run your program to see what it does without having to appease the type checker first.
There is nothing wrong with presenting type hints or type errors as warnings. The problems arise when the compiler just flat-out refuses to run your code until you have finished handling every possible branch path.
In Rust, the `todo!()` macro will fill in type holes without needing to be finished.
Surely you can't be against putting a TODO in an unfinished part of the code?
Surely you can't be against putting a TODO in an unfinished part of the code?
I'm against anything that adds cognitive load without a compelling reason, anything makes me do unnecessary work. Typing "todo!()" is not a huge burden, but it's not zero, and if the Rust compiler is smart enough to fill in the hole it should be smart enough to do it without my having to explicitly tell it.
No, because 99.9999% of the time, you explicitly do not want the compiler implicitly filling in a hole like that, and do want the compiler to tell you that you've forgotten an entire branch of control flow. Typing `todo!()` to make your intent explicit is among the least obtrusive things imaginable.
> No, because 99.9999% of the time, you explicitly do not want the compiler implicitly filling in a hole like that
Who are you to tell me what I want? You are making all manner of tacit assumptions about the kind of work I do and what my requirements are. I absolutely do want the compiler filling in every hole it possibly can. For me, that's the whole point of using a high-level language in the first place. For the kind of work I do, what matters most is getting things done as quickly as possible. Correctness and run-time efficiency are secondary considerations.
Who are you to tell me what I want? You are making all manner of tacit assumptions about the kind of work I do and what my requirements are. I absolutely do want the compiler filling in every hole it possibly can. For me, that's the whole point of using a high-level language in the first place. For the kind of work I do, what matters most is getting things done as quickly as possible. Correctness and run-time efficiency are secondary considerations.
If correctness is a secondary consideration, then you'll be happy to learn that LLMs will let you code in plain English, so there's no need to bother with using a programming language at all. The LLM will happily fill in all the holes it encounters, more eagerly than any compiler would ever dream of.
But for people who prioritize precision and correctness, that's what programming languages were invented for.
But for people who prioritize precision and correctness, that's what programming languages were invented for.
There are two problems with using LLMs for writing code. The first is that when the code they produce doesn't work (which is most of the time) I still have to debug it, and now I'm debugging someone else's (or someTHING else's) code rather than my own. The second is that the work I do is very specialized (custom ASIC design) and LLMs are utterly useless.
But yeah, if all you need to do is build a vanilla app then an LLM is probably an effective tool.
But yeah, if all you need to do is build a vanilla app then an LLM is probably an effective tool.
What is an example of a compiler that flat out refuses to run (compile) your code? Obviously Python is not an example. The other language I know best is Rust, where as I understand the compiler doesn't refuse to compile your code, it cannot compile your code. Is there a language where the compiler could compile your code but refuses to do so unless the types are all correct?
Not that you should ever write this in any language, but as an illustration:
fn main() {
let x: i32 = if true {1} else {"3"};
println!("{}", x);
}
x = 1 if True else "3"
print(x)
> the compiler doesn't refuse to compile your code, it cannot compile your code
"Can not" and "will not" are kind of the same thing in this context. It's not like compilers have free will and just decide to give you a hard time. It's the language design that makes it (im)possible to run code that won't type-check.
"Can not" and "will not" are kind of the same thing in this context. It's not like compilers have free will and just decide to give you a hard time. It's the language design that makes it (im)possible to run code that won't type-check.
Thanks for clarifying that compilers don't have free will. I was being facetious, sorry.
Haskell has -fdefer-type-errors, which makes any type error fail at runtime.
This means you can only really rely on the parts of your program which are type correct, so...
This means you can only really rely on the parts of your program which are type correct, so...
1. Dynamic typing says "anything I can do these operations on, I accept as input". This lets you accept input from code that doesn't have something that fits the strict definition of what input you were expecting.
2. Dynamic typing lets you change what shape your data is without having to change type annotations everywhere.
Problem is, I think both of these are deeply flawed:
1. If you're writing something nontrivial, you probably have several layers of nested function calls, some of which may be calls to libraries that are not yours. If you're saying "anything I can do these operations on, I accept", it becomes very difficult to say what the full extent of "these operations" are. Thus it becomes hard to say whether the caller is passing in valid input. You can "just try it", but that becomes hard if you care about it working in all cases.
2. Refactoring IDEs are a thing these days. You want to change the type signature? Press the button. Even better, it will tell you everything you broke by making the change - everywhere where you're doing something that the new type can't do. Without types, sure, you can just change it without pressing the button. Now try to find all the places that you broke.
It may be possible to construct a better steelman than I have done. For myself, even trying to steelman the position, I find it incredibly unconvincing.
2. Dynamic typing lets you change what shape your data is without having to change type annotations everywhere.
Problem is, I think both of these are deeply flawed:
1. If you're writing something nontrivial, you probably have several layers of nested function calls, some of which may be calls to libraries that are not yours. If you're saying "anything I can do these operations on, I accept", it becomes very difficult to say what the full extent of "these operations" are. Thus it becomes hard to say whether the caller is passing in valid input. You can "just try it", but that becomes hard if you care about it working in all cases.
2. Refactoring IDEs are a thing these days. You want to change the type signature? Press the button. Even better, it will tell you everything you broke by making the change - everywhere where you're doing something that the new type can't do. Without types, sure, you can just change it without pressing the button. Now try to find all the places that you broke.
It may be possible to construct a better steelman than I have done. For myself, even trying to steelman the position, I find it incredibly unconvincing.
"Static typing is a powerful tool to help programmers express their assumptions about the problem they are trying to solve and allows them to write more concise and correct code. Dealing with uncertain assumptions, dynamism and (unexpected) change is becoming increasingly important in a loosely couple distributed world. Instead of hammering on the differences between dynamically and statically typed languages, we should instead strive for a peaceful integration of static and dynamic aspect in the same language. Static typing where possible, dynamic typing when needed!"
https://ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04...
https://ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04...
But you can achieve #1 with typing.Protocol in type-annotated Python and traits in Rust. Fitting the "strict definition" sounds like nominal typing but you can opt in to explicit duck typing or structural typing while still being typed. (Someone correct me if I'm using these terms incorrectly.) In short you can still encode a lot of flexibility with types without just abandoning them alltogether.
And with #2, you can get that with static typing too... Let's say a method accepts an instance of an object `Foobar`. I can change the definition of `Foobar` ("change what shape [my] data is") without having to change type annotations everywhere.
I agree with you, I guess, that I find the steel man position unconvincing.
And with #2, you can get that with static typing too... Let's say a method accepts an instance of an object `Foobar`. I can change the definition of `Foobar` ("change what shape [my] data is") without having to change type annotations everywhere.
I agree with you, I guess, that I find the steel man position unconvincing.
Refactoring IDEs were a thing back in the day.
"Less than 35 bugs were found in the 17,100 changes."
https://news.ycombinator.com/item?id=42473314
"Less than 35 bugs were found in the 17,100 changes."
https://news.ycombinator.com/item?id=42473314
> Without types … Now try to find all the places that you broke.
Do failing tests show what we broke?
Do failing tests show what we broke?
Yes, if you have tests that test all aspects of the behavior for all possible inputs.
Oh, you don't have that? Then do not scorn the help you can get from types.
Oh, you don't have that? Then do not scorn the help you can get from types.
"Less than 35 bugs were found in the 17,100 changes."
https://news.ycombinator.com/item?id=42473314
I wonder how many were not found.
https://news.ycombinator.com/item?id=42473314
I wonder how many were not found.
Sometimes, but maybe you haven't written any tests! Type hints and immediate feedback from mypy are a lot easier than writing unit tests.
> haven't written any
Any!
Then maybe the immediate feedback of consistent types conveys a false impression.
Any!
Then maybe the immediate feedback of consistent types conveys a false impression.
Hard to conceive of a case where that would occur. Can you think of one?
The implication of what you're saying seems to be that if you're concerned about some kind of correctness you should be writing unit tests anyway and not being so fussed about type checking in a language like Python. I suppose if you are strictly following TDD that might work, but in all other cases type checks give you feedback much more quickly than unit tests ever can. I guess I don't understand.
The implication of what you're saying seems to be that if you're concerned about some kind of correctness you should be writing unit tests anyway and not being so fussed about type checking in a language like Python. I suppose if you are strictly following TDD that might work, but in all other cases type checks give you feedback much more quickly than unit tests ever can. I guess I don't understand.
Any old math with consistent types and incorrect calculation? (If only we'd diff'd the output with some known result.)
No doubt we're at cross purposes.
I'm a little surprised that you haven't mentioned — "Program testing can be used to show the presence of bugs, but never to show their absence!" (or existential versus universal quantification).
No doubt we're at cross purposes.
I'm a little surprised that you haven't mentioned — "Program testing can be used to show the presence of bugs, but never to show their absence!" (or existential versus universal quantification).
I'm afraid you lost me.
The way I see it:
Your type system is sound or complete (cannot be both, if it's a Turing-complete language). If it's dynamically typed, then it's probably complete but not sound (many, but not all, dynamically typed language implementations have some basic static type checking). If it's statically typed, it can be either sound or complete. The difference between sound and complete is: Sound type systems will reject valid programs that they cannot prove are valid; Complete type systems will reject only those invalid programs they can prove are invalid.
In practice, the choice is more one of default these days:
Do you default to static typing and allow some dynamic (runtime) type checking? C++, C#, Java, etc.
Do you default to dynamic typing and allow some static (compile-ish time) type checking? Python, JS, Common Lisp, etc.
This lets both sides have what they really want. They want to be able to express all valid programs (a complete type system) but they want to reject all invalid programs (a sound type system). They can't have it. So you end up choosing a direction to approach it from. Either start conservatively and relax constraints, or start liberally and add constraints.
If you accept that, then the case for dynamic typing is that it's a choice to move from the too permissive extreme towards a stricter position. For me this works better (in general, though I also happily use statically typed languages like Ada) because I find it easier to add constraints to a relaxed system than to remove constraints from a restrictive system.
Your type system is sound or complete (cannot be both, if it's a Turing-complete language). If it's dynamically typed, then it's probably complete but not sound (many, but not all, dynamically typed language implementations have some basic static type checking). If it's statically typed, it can be either sound or complete. The difference between sound and complete is: Sound type systems will reject valid programs that they cannot prove are valid; Complete type systems will reject only those invalid programs they can prove are invalid.
In practice, the choice is more one of default these days:
Do you default to static typing and allow some dynamic (runtime) type checking? C++, C#, Java, etc.
Do you default to dynamic typing and allow some static (compile-ish time) type checking? Python, JS, Common Lisp, etc.
This lets both sides have what they really want. They want to be able to express all valid programs (a complete type system) but they want to reject all invalid programs (a sound type system). They can't have it. So you end up choosing a direction to approach it from. Either start conservatively and relax constraints, or start liberally and add constraints.
If you accept that, then the case for dynamic typing is that it's a choice to move from the too permissive extreme towards a stricter position. For me this works better (in general, though I also happily use statically typed languages like Ada) because I find it easier to add constraints to a relaxed system than to remove constraints from a restrictive system.
[deleted]
My attempt: "These dynamic languages are so much more pleasant and productive than Java 1.X."
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.
> 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.
Types give you speed, correctness and better tooling. Dynamic typing supposedly gives you "authentic self". I think I'll pick the former.
So many comments about static vs dynamic typing whereas the article barely discusses that. I loved reading this - very well written!
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.
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.
> 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.
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.
Ragebait title
And a thread where people respond to the title of an article and not the article itself.
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).
EDIT: ... which is unfortunate, bc it's actually a decent read w/ interesting points about the relationship between (programming preferences) and (emotions / psychology).
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.
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.
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.
2018 "Scientists determine four personality types based on new data"
https://news.northwestern.edu/stories/2018/september/are-you...
https://news.northwestern.edu/stories/2018/september/are-you...
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.
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.
> choice of programming languages
We can make our own choice of features:
declare variables once
convert truthy / falsy to Boolean
const and final when possible
local type inference when possible
But then someone else must deal with what we've done.
We can make our own choice of features:
declare variables once
convert truthy / falsy to Boolean
const and final when possible
local type inference when possible
But then someone else must deal with what we've done.
Thanks maybe your comment will motivate me to take another look.
640B parameters should be enough to classify everyone's personality.
> 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?
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]
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".