But I don't think I agree with the authors conclusions that there's less interest in type safety or strict type checking. I suspect the author finds Typescript too leanient (there's plenty of ways to trigger Typescript's unsoundness) for their liking, but I do think there is an overall trend to use Typescript to design and build more reliable software.
Do not forget you learned a lot along the path. That's something no one can take away from you.
> unfortunately, I see that nowadays, TypeScript won. The idea of strict type-checking for JavaScript is less popular than in 2019.
> [Typescript's types] give people a fantastic tool to cover existed code with types but doesn’t force to re-design it to make it safer.
Many other languages haven't passed the PoC stage. Several are ready, and doable (C#, Go?) but hardly as easy and common as with rust.
At least that was the state when I looked six months ago. It's a fast moving area.
So, yes, that time is now. But the only practical option is rust. Which may be enough, idk.
My only reference is a memory of this talk by Richard Feldman but I might be wrong or misremembering. https://www.youtube.com/watch?v=Tml94je2edk
I’d be shocked to find this to be true. Back then I’d always wonder, “are there typings for this library?” Now I don’t have to.
I'm unconvinced this would be a good thing.
I was also happy to see the shout-out to Ben's Ezno. I'd recommend people start sponsoring that kind of work, it has the potential to make our JS life much saner.
I honestly don’t get the problem TypeScript is trying to solve. JavaScript has lots of wacky problems but its main advantage to me was the loosy goosy approach to types. I was a smalltalk programmer back in the 1990s and it felt pretty comfortable if very primitive in the way of tools.
Typescript just seems unnecessary. Not sure why nobody built something like reentrent exceptions or cool stuff like that, instead they built a stupid jail that down compiles to unreadable sludge.
Now I find out there were competing jails. What a strange ecosystem.
There is a lot of text written and voice recorded over what type safety is good for. It's reasonable to disagree, but to "honestly don't get" what the point of it is seems kinda strange. Like you haven't really looked into it.
It's quite annoying IMO. Some of the things it can be infer are reasonably impressive but then that gets balanced out with having to write out a lot of crap that something a bit more HM-like would be able to nail immediately (rather than just "Any!? Fuck you").
That and the refusal to add other value-adds (despite being a compiler in all but name) hobbles the union types and so on.
Smalltalk is type safe & not statically checked.
page 263 "Programming Languages: Application and Interpretation"
[pdf] https://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-0...
It's generally better to do proper micro-services.
Type safety is the inferior way of doing it where you get hit with a double whammy of long compile times and extreme code verbosity.
> instead they built a stupid jail that down compiles to unreadable sludge
Does it? The Typescript compiler mostly just erases types, leaving the code otherwise the same. Here's a non-trival example https://tsplay.dev/mA078N, where the output is basically the same as the input, just with type syntax erased.
IIRC the only 'language feature' that Typescript actually compiles is enums, which is a bit of a big blob. There's compiler flags to 'fix' that, or you can just not use enums.
Smalltalk (and languages in the same academic orbit, like LISP derivatives) seems to be a tool that fits a few people's hands very well, but there are no large smalltalk projects for two reasons:
- that doesn't actually suit most people, so it's harder to find developers
- the language maps well to one (1) human brain that keeps a model of what's happening, but that breaks down when larger teams of developers are involved.
I guess that keeps the "small" in smalltalk.
Seems like we need do no more than assert: Yes there are!
~
But it's more interesting to look at how a real Smalltalk project worked:
"A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.
Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.
A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.
A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.
Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.
If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.
The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36."
from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002
But mostly because it was expensive. Objective-C and Ruby got you halfway there for free, and there is nothing developers love more than something that is free.
Someone properly trained with something like Smalltalk will on average output 3x the amount of software as someone trained on something like Java.
There are big advantages to doing it.
I've worked with both Javascript and Typescript and the ease of patching up Typescript projects you're not familiar with is unmatched compared to Javascript. At least when my code compiles, I'm sure the plumbing is correct
It runs in the browser. That’s always been its only advantage. Even now that it’s much better than it used to be: still true.
> Not sure why nobody built something like reentrent exceptions or cool stuff like that, instead they built a stupid jail that down compiles to unreadable sludge.
TIL machine-readable and -verifiable versions of the documentation you should be writing anyway (but probably aren’t) is a jail.
Also one of the reasons I didn’t worry about it going the way of other compile-to-JS languages is that it’s output is nearly identical to what I would have written anyway, so it’s got a clean and easy “escape hatch”. But maybe I write unreadable sludge.
(_c = this.log) === null || _c === void 0 ? void 0 : _c.withIndent(' ', () => {
var _a;
// (pointless ?. silence eslint)
(_a = this.log) === null || _a === void 0 ? void 0 : _a.pn(`Buffer address: 0x${utils.hex8(bufferAddress)} `);
});
this.log?.withIndent(' ', () => {
// (pointless ?. silence eslint)
this.log?.pn(`Buffer address: 0x${utils.hex8(bufferAddress)} `);
});
At my workplace a team of test engineers wrote an entire little test framework around our application. It‘s using webdriver.io under the hood but defines all test classes in type script. Everytime I need to inspect a failing test I open it up in my Emacs and jump around the test method definitions quickly and easily and enjoy inline doc strings popping up wherever I set my cursor on. So the task of fixing a test becomes quite easy despite not having written the framework. Back when we used JS or Perl this task used to be quite obscure.
On the other hand when I see react applications written in typescript I become quite skeptical of the supposed architectural benefits of static typing in front end logic. While React applications were already difficult to grasp, static typing constraint make refactorings even more headachy and I receive Java‘s spring framework vibes constantly.
+1: I'm much slower working in environments where I have to do this manually. This is why I've been infiltrating Python type annotations in our codebase.
If you've only done small projects or projects where you are the primary author then you may not run into the issues. You essentially end up doing what Typescript does but in your head without writing anything down.
The problems it solves are:
* Bugs! It catches lots of bugs.
* Navigating code efficiently. You can just click stuff to go to its definition or uses.
* Refactoring code reliably. You can now rename variables without making mistakes.
* Reading code. It can be extremely difficult to understand code without static types because you don't know what anything is or where anything goes unless you run it (which can be very difficult).
Not Typescript, but as an example I was trying to understand some code in Gitlab like `auto_cancel_from_rules.merge(auto_cancel_from_config)`. "what does `merge` do?" I wondered.
Literally could not find it. You can't search for `merge`, way too many results. I don't know what the types of the variables are so I can't look it up. I spent about 15 minutes looking around and eventually gave up.
With static types you can literally just click it and it will take you to the definition.
Dynamic typing doesn't have to get that messy, but it takes discipline that is very hard to enforce at scale. Static typing can sort of approximate that level of mess but it takes a lot more work, and perhaps even more importantly, it's a lot safer to fix. But every significantly-sized dynamic scripting code base I've encountered has certainly had at least one of those two issues deeply, deeply ground into it.
Unlikely. Maybe if you are using a language with a complete type system (let's face it, you are not), but otherwise you are necessarily going to have to encode all the type information into your tests anyway, so you haven't gained anything on this front. A partial type system cannot replace these tests.
Your other points are the real wins, though.
To me it's one of the top requirements for a modern language.
Edit: Also you can follow typedefs of a library and make sense of it without relying on its documentation quality or deciphering the code.
If you're building something simple, and the type/shape of function parameters is either very obvious or very well-guarded, TypeScript's returns diminish.
However:
As a reviewer of complex code, I want to see annotations so that I can better understand what I'm reviewing.
As an author of complex code, I want to clearly communicate the intent of functions I write, so that they are not misused by other developers.
As someone who supports the use of my software, I want to reduce errors by guaranteeing the correct types/shapes of function arguments.
...and I'm just getting started. These are all very compelling needs in my experience.
I think there might be a couple of other tools around in your setup (that might influence your feelings). TypeScript mostly just strips out type annotations, so the output looks pretty close to your input.