I think the best take on this is from Rich Harris at Svelte. They are dropping it for internal Dev because they get the same feature set from JSDoc and have no build step, but they keep it for Svelte users who want TS.
Static typing is objectively better for any non-trivial project / script. I don’t have any idea why anyone who has any degree of experience with this doesn’t understand it.
TypeScript does suck, and I almost understand moving away to JS. JS is like a friend with benefits; it makes no promises, and there are no false hopes between you. Well designed statically types languages like Rust are like marriage; you trust it, and respect it a lot for that. It’s more complex but in a way that gives you confidence. TypeScript, on the other hand, makes promises but lies to you. It also makes you do shitty things to uphold those promises. In a way, that’s worse than making none at all.
I appreciate the imagery you bring here, but I'm quite interested in concrete examples of how TS "makes promises but lies". Don't shoot me (just yet), I'm not a TS developer, just a curious person wanting to become wiser.
Not OP, but my experience with TS is that the promises of type safety only works if all you’re doing is to interact with other TS code. As soon you need to interact with vanilla JS, which is often, all the type safety guarantees you were promised goes through the window.
So it’s some kind of weird hybrid. I prefer statically typed languages myself, but TS is not really it. It’s nice when it works though.
IMO one of the most fundamental, important aspects of type systems is the invariants defined in your model; if I say a field is an array, that needs to be the source of truth and enforced throughout the program. That’s the whole point. Same with if something is immutable or other aspects of the type.
There’s likely a lot of reasons one wouldn’t want to work with DHH. It’s unfortunate because he is clearly really brilliant but seemingly fails to realize that a huge amount of software engineering involves working together with other people, many of whom aren’t that brilliant.
I used to get excited about these promotions, until I realized they are all only for NEW customers.
If you ever gave Jetbrains money, they don't care about you anymore.
Do people still use this for functions? I’ve been in typescript for years, its all arrow functions and very few classes in our codebase. There are almost no this at all. Is it still comnon in js?
this is very handy when you want to carry over some shared context. Justin Fagnani described this as an implicit first argument, which is a model that helped me understand how to use it better.
Going by the screenshots in Github, this is another case of molesting the high-level Python interpreter with low level code riddles. Look at this, are you fucking kidding me?
Importing numpy and then this fucking list comprehension? You need AI telling you that this code is absolute garbage? Well, you’re an imbecile then.
And even having the audacity to fuel the Python-is-slow theme with claims like “its 60000 times slower than other languages”. You’re writing just incredibly stupid code, asshat
Hooo boy... I work in embedded and modern MCUs and modern compilers allow for well abstracted, readable code and small memory footprint. I currently work on 256k of RAM and 1M of Flash, which is plenty, but have previously worked on systems with a fraction of that and still it's possible to write readable code on these.
What a dumb article. Sounds like an old C graybeard who's never understood the point of proper type safety or readable code. None of the performance gains the author talks about actually matter, whereas the entire point of clean code is to make it easier to read and maintain by other programmers. Let's also not forget this important quote from Donald Knuth: "premature optimization is the root of all evil".
Simply put, unless you're working in extremely resource-constrained systems, or have some code snippet being run an incredibly large number of times over a humongous amount of data, these kinds of performance optimizations simply don't matter and you get more benefit from writing the code in a way that reduces bugs and is easier to read. Heck, most of the time compiler optimizations make this entire argument moot anyway.
I thought the point of "clean code" was to make a software source code base comprehensible and maintainable by the people who are in charge of working with and deploying the code. When you optimize for people reading the code rather than some kind of performance metrics, I would expect performance improvements when you switch to performance optimization. The trade-off here is now code that's more performant, but that's more difficult to read, with interdependence and convolution between use cases. It's harder to update, which means it's slower and more costly (in engineering resources) to upgrade.
In a lot of modern software, you don't need extreme performance. In the fields that do, you'll find guidelines and other resources that explain what paradigms to avoid and what are outright forbidden. For example, I have heard of C++ exceptions and object-oriented features being forbidden in aircraft control software, for many of the reasons outlined in this article. But not everyone writes aircraft control code, so rather than saying clean code is "good" or clean code is "bad," like a lot of things this should be "it depends on your needs."
I think you are right that optimising engineering cost is the goal of these practices, but I believe it is a bad thing.
Nowadays we have the most powerful hardware we ever had, yet everything is slow. Sure we reduce dev cost, but the end user is paying the price difference with its time in my opinion.
In the end the only people that benefit from this are the owners of the product, making more money selling unoptimised software, devs maybe get a bit more money, but probably not that much.
I think you are right that optimising engineering cost is the goal of these practices, but I believe it is a bad thing.
In the end the only people that benefit from this are the owners of the product [...]
Yes, that's exactly how the for-profit software industry (and really any for-profit industry) is run. The owners maximize their benefit. If you want to change that, that's a much different problem on a much larger scale, but you will not see a for-profit company do anything but that.
Programming
Hot