I don’t get the hatred for types, they have saved my ass so many times and saved so many headaches exactly like what the article describes. I used to write a lot of ruby and after getting decent at typescript I can’t go back.
It’s not just ceremony, types ensure some level of logical consistency in your app. They reduce how much of the world you need to keep in your head at one time, and they allow you to express your intent far more robustly than comments and naming can. I love rust’s approach of making invalid state not even representable.
Designing custom types are one of my favorite things about programming
Instead of just doing what I want to do, I’m stuck either doing plumbing work to hold my values and pass them around, or I’m casting things back and forth where I know things are correct but the compiler doesn’t.
I hate this attitude.
Instead of doing what you want to do? Dude, unless you’re a hobbyist, you’re being paid to do what your company wants you to do; i.e., it’s not about what you want.
Stuck doing plumbing work? Yeah, nobody likes plumbing, but we all know it’s necessary. When you’ve got your proverbial shit backing up onto your floor because you cheaped out on plumbing, cry to me then.
If you’re casting things back and forth, you’re doing it wrong. Spend a day or two and build yourself a solid, consistent foundation, plan ahead, and you won’t be casting things back and forth.
And no, you obviously don’t know better than your compiler, you arrogant sack of sh…
Anyway, get over yourself already and just do your damn job better.
I mean I agree but you don’t have to be a dick about it
deleted by creator
How many billion dollar companies were built on dynamically typed languages? Do you think that companies/bosses/investors care about the compiler warnings or whether you can deliver/iterate faster than the competition?
nobody likes plumbing, but we all know it’s necessary.
Is it, really? Are we all working on mission critical software? We are living in a world where people are launching usable applications with nothing but the prompt to an LLM, ffs, and you are there trying to convince yourself that pleasing the Hindley-Milner gods is fundamental requirement in order to deliver anything?
Good engineering is about understanding design constraints and knowing where to choose in a myriad of trade-offs. It’s frankly weird to think that such an absolute, reductionist view like yours got so much support here.
I care about types not just because I like having stronger confidence in my own software, but because, as a user, bugs are really annoying, and yes, I’m confident that stronger type systems could have caught bugs I’ve seen in the wild as a user.
I don’t really want to be talking past each other. The point I am refuting is that even if type-safety can help reduce the amount of bugs shipped, this is not the only metric that matters to measure the value of the software being developed.
bugs are really annoying
And being late or never delivering out of fear of shipping buggy code is even worse.
Some years ago, I worked on a crypto project that was financed via an ICO. This meant that whatever money the company was going to get was already in their hands, and their only job was to make sure they could prove they’ve done a best effort to deliver what was promised to investors.
Because of these incentives, the engineers were more concerned about covering their asses regarding bugs than to actually get the software out in the hands of users. The implementation was in python, and to the team it was easier to justify spending time on getting 100% mypy coverage than to get things in hands of users to see the value of what we promised to deliver.
In the end, by the time the team managed to deliver, the code was super well-tested, there were 0 mypy warnings and absolutely zero interest from other people in adopting our tool because other competitors have launched a whole year before them.
I understand what you’re saying, but I want to do whatever I can to promote the shift in attitudes that’s already happening across the industry.
And being late or never delivering out of fear of shipping buggy code is even worse.
From a business perspective, yes, usually true. But shipping buggy software can also harm your company’s reputation. I doubt that this has been researched enough yet to be quantifiable, but it’s easy to think of companies who were well known for shipping bugs (Microsoft, CD Projekt Red) and eventually suffered in one way or another for it. In both of those cases, you’re probably right; Windows was good enough in the 90s to dominate the desktop market, and Cyberpunk 2077 was enough of a technical marvel (for those who had the hardware to experience it) that it probably bolstered the studio’s reputation more than harmed it. But could Microsoft have weathered the transition to mobile OSes better if it hadn’t left so many consumers yearning for more reliable software? And is Microsoft not partly to blame for the general public just expecting computers to be generally flaky and unreliable?
Imagine if OSes in the 90s crashed as rarely as desktop OSes today. Imagine if desktop OSes today crashed as rarely as mobile OSes today. Imagine if mobile OSes crashed rarely enough that the average consumer never experienced it. Wouldn’t that be a better state of things overall?
Imagine if OSes in the 90s crashed as rarely as desktop OSes today. Imagine if desktop OSes today crashed as rarely as mobile OSes today. Imagine if mobile OSes crashed rarely enough that the average consumer never experienced it. Wouldn’t that be a better state of things overall?
Depends. What is the cost to get there? Will that sacrifice openness? Will that sacrifice portability? Will that require ossified structures that will make development of new applications more difficult?
Look, the article is talking from the perspective of someone who is developing web apps in Ruby. Performance is not a huge concern. Processes being crash-proof are not a concern. You know what is the concern? To be able to validate ideas and have something that bring customers willing to pay real money to solve their real problems.
For his scenario, forcing to define everything up front is a hindrance, not a benefit. And having GP screaming at it like this for having this opinion is beyond ridiculous.
Types aren’t unit tests. Unit tests only test a discrete set of inputs and outputs for correctness, and can miss cases that aren’t tested for.
In sound type systems, they are closer to formal verification. The compiler guarantees the properties you expect of the type hold.
As for the rest of the article, do what works best for you in your projects, but if I need to work with you, I’m going to ask for types. I need to know what types the interface expects to receive. Names are not enough. Document them, use type hints, whatever, just put them somewhere because I’m not psychic and I don’t know what you thought about when writing the function.
Seems like a Ruby issue and suggested improvement? Using keyword arguments does feel like introducing a type of typing.
In C# I use records for simple, naturally behaving types, I can define explicit and implicit cast operators, so I have to choice between requiring explicit casts or not (because they make sense to require or are not necessary). I can use
varto define a variable without specifying a type, and it is deducted from what it gets assigned - but is still that specific type and gives me type safety.In Rust, as far as I understand anyway, traits define shared behavior. In Go interface implementations are implicit rather than explicit. With these, there’s even less of a need of elaborate explicit typing like the post argues/gives an example of.
In general, I’ve never had considerable effort or annoyance implementing or using typing. And I know what it’s good for; explicitness, and in consequence, predictability, certainty, increased maintainability, and reduced issues and confusions. If following references or refactoring becomes unpredictable or high effort, it’d be quite annoying.
When I’m coding JavaScript adding JSDoc so the typing information gets passed along is quite cumbersome. Without it, the IDE does not give intellisense/auto-completion or argument type matching. JavaScript is better with it, I consider it worth it with IDE support, but it is quite cumbersome. (I try to evade TypeScript compiler/tooling overhead.)
A programming language can offer extensive auto-deduction while using strong typing. With appropriate conversions in place, it will only report conflicts and where it was intended to.
I’m thinking of where I enjoyed dynamic natures, which I certainly have. But I don’t think that’s a matter of typing. It’s a matter of programming language interfacing to typing. If in PHP or JS I make a change, hit F5, and get an error, that’s not any better than the IDE already showing it beforehand. And for the most part, I can program the same way with or without typing.
Man, this became a long text.
In Rust, as far as I understand anyway, traits define shared behavior.
They’re certainly the concept closest to e.g. C#/Java interfaces. But you can also define shared behaviour with enums, as Rust’s enums are on steroids.
Basically, let’s say you’ve got two existing types
TypeAandTypeBfor which you want to define shared behaviour.Then you can define an enum like so:
enum SharedBehaviour { A(TypeA), B(TypeB), }And then you can define the shared behavior with an
implblock on the enum:impl SharedBehaviour { pub fn greet(&self) { match self { SharedBehaviour::A(type_a) => println!("Hi there, {}!", type_a.name), SharedBehaviour::B(type_b) => println!("Hello, {}!", type_b.metadata.forename), } } }On the flipside, Rust doesn’t have superclasses/inheritance for defining shared behaviour.
If in PHP or JS I make a change, hit F5, and get an error, that’s not any better than the IDE already showing it beforehand.
This is even worse because it can happen in prod without you ever triggering this case. For some projects, it doesn’t matter because the impact of a bug is small. For most, you put a subpar, buggy experience in front of your users, waste more time looking for the cause and debugging later with upset users, and at worst cause actual damages (depending on the project anyway).
This was always the trade-off of dynamic languages. You have to write a lot more unit tests to prove basic correctness, but you can move quickly at first if you’re not bothered about that.
I feel like this has somewhat shifted in recent years. Due to type-aware IDEs/editors being pretty much universal now, having types speeds you up in that initial phase, too. And type inference eliminates much of the inertia, too.
