People may forget what you did, but they'll remember how you made them feel. It's been years since I've used TS, but I remember it failing to solve about half the problems that I had with JS. I think they did the best they could given the constraints though.
This article is a good example. TS can't fix the underlying APIs, standard library etc.
If your entire stack is using optionals then Java can be acceptable. It’s not a terrible language otherwise. Checked exceptions are a failure IMO because they only check for some types of errors.
I love Swift as in the language, the syntax, the theory. I despise just as much its tooling that has led me to infuriating moments such as finding out that ternary operators where the cause for a ballooning compilation time.
Meh, I used to have that feeling, especially when discovering fp-ts and then effect (neither of which I've been paid to write), but after about four years, I'm tired of writing it period. The standard library for node is horrible; the ecosystem is okay but not great. And I don't even care for effect anymore. I also write go in my job and it's just okay, but the standard library is much better.
I've been playing around with rust in my free time and like it. I think it's a good FP middle ground. Gleam also looks interesting. But to your point I imagine there aren't many jobs paying for rust and practically none for Gleam.
I’m personally strongly opposed to using any library that becomes a new primitive of my project. I’m fine with an intrusive framework, but never a fundamental change to how plain-old business logic is written. That means fp-ts is out. However stuff like JS’s Date can be replaced under these rules - these days perhaps with a Temporal polyfill.
I believe Fly.io deploys some Gleam in prod. I tried playing with Gleam for a bit, but I got stuck trying to make the Actor Model make sense. It’s Gleam’s solution to mutable state, inherited from Erlang and the BEAM. It takes so much code just to emulate a simple, mutable Map. I liked Rust’s middle ground with `mut` in function defs.
"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
> "My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake."
> -Anders Hejlsberg
Why can't all-1s be null? E.g. a small int goes from the range 0-255 to the range 0-254, but we get a really useful property with no out-of-band Nullable overhead.
With signed ints it even leads to symmetric ranges in the negative and positive directions.
The FORTH-83 standard changed FIG-FORTH's official value of TRUE from 1 to -1 so all its bits were set. That was a rough transition like Python 2=>3, but worth it. It also defined /MOD integer division to be floored (rounded towards -infinity instead of zero like FIG-FORTH), which was also a tough change but the right one, especially for graphics.
>4. For various reasons the definition of all divide functions general effect is that quotients are floored instead of rounded toward zero. This should cause no problems for most pre-existing application software. The new divide functions are marginally slower than the old (a few machine cycles under most circumstances). The side-effects of the redefinition for floored divide can be counter-intuitive under some circumstances. For example, in FIG-Forth the operation
-40 360 MOD
>would return the obvious answer (-40) on the stack, while 83- Standard Forth will return the answer 320!
>5. The true flag returned by all logical operations has been changed from the value 1 (in FIG-Forth) to the value -1 (in Forth-83, all bits set). If your code used the 0 or 1 returned by a comparison in an arithmetic operation, you will need to interpolate the operator ABS after the logical operator. This is a particularly difficult problem to look for in your source code. However, we feel that this mutation in the 83-Standard was beneficial as it allows the returned true/false value to be used as a mask for AND.
You're kind of missing the point. Turbo Pascal has been dead for a lot longer. Or is it?
The point is that TypeScript and C# are extremely similar for a good reason, not a coincidence, and that Anders Hejlsberg knows what the fuck he's doing and talking about, and has been implementing amazing groundbreaking well designed languages and IDEs for a very long time. Turbo Pascal was so great it flummoxed Bill Gates, so Microsoft sent a limo to recruit and hire Anders Hejlsberg from Borland, then he made Visual J++, Windows Foundation Classes, C#, and TypeScript.
>Scott MacGregor of Microsoft said that Bill Gates "couldn't understand why our stuff was so slow" compared to Turbo Pascal. "He would bring in poor Greg Whitten [programming director of Microsoft languages] and yell at him for half an hour" because their company was unable to defeat Kahn's small startup, MacGregor recalled.
>"According to the suit, Microsoft also offered Mr. Hejlsberg a $1.5 million signing bonus, a base salary of $150,000 to $200,000 and options for 75,000 shares of Microsoft stock. After Borland's counteroffer last October, Microsoft offered another $1.5 million bonus, the complaint says."
C# is nominally typed, which, in practice, leads to safer code and less type gymnastics. Of course you can avoid the type gymnastics with "any", then you you're sacrificing safety.
Agree. While people argue and split hairs over X language is better than Y language (noobs if I’m being honest, even if they have 20 yr experience), one can ship actual products and make money using TS.
It’s a good language that scales quite well to the point where you can then extract specific parts to more performant languages.
99.9% of people won’t have that problem, so I think they should just use TS and solve problems.
Anyone else can be safely ignored and they can complain in the corner.
I'd love to disagree, but every other language's ergonomics just seem so clunky or too magic, whereas with TS and the standard web APIs you have so much room to code how you see fit. Sure, I'd rather a LISP for purity but I'm a realist. If only Brandon Eich had really gotten his way, we'd have Scheme.
Reminding me of the near decade of WAT snark where people thought undefined behaviour was a complete proof of the futility of technology when it was actually just people mistaking what technology is. Like it isn't funny that you can't carry water with a brick but for some reason everyone thought JavaScript should be able to accommodate every possible fuckup with a specific error or just fix it. A nice goal but not something to then feel smug about when it doesn't happen but it seemed to be a viral perspective that persisted for way too long.
People aren't mad that errors aren't fixed automatically, people are mad that the behavior is inconsistent and weird for no fundamental reason other than "that's how the interpreter worked when it all started and it's too late to fix the spec now".
Python is a dynamic language as well and in many ways worse than JS, but
[] + {}
raises a type error.
In JS
[] + {}
is an object and
{} + []
is 0. It's not about being smug, it's that in no way, shape or form that makes any sense.
Second, {} + [] isn't a type conversion issue, it's a parsing issue. That {} isn't an object, it's a code block. Assign {} to a variable to ensure it's an object, then do var + [] and you get the same result as the first one.
When using an actual object in both of these, the type conversion makes sense: "+" acts on primitives like strings and numbers, so it has to convert them first. You're getting obj.toString() + array.toString() in either case.
I'll admit the parsing issue here is odd, but most of the time peoples' complaints about javascript type coercion is that they simply never bothered to learn how it works.
One can know the intricacies of how something works and still possess a valid opinion that it doesn't work all that well or defies common sense and expectations.
For me the difference is that you wouldn't then feel compelled to cynically bemoan it for retweets but this schtick went on for years where people would do something out of spec and then complain it was really bizarre to me! Anyway ... Being discouraged by a bug is fine... Making everyone else laugh at the machine on your behalf seems to against understanding and knowledge even if it is fun and funny haha
I don't have dissonance. The language has the features that were designed or there is a bug in what they intended and I don't know why you think adding two empty objects together should make sense anyway. That it doesn't work resolves the dissonance.
In the context of the time it was created it was fine to mess with and having an enlightened view from the future can't negate that even though I understand the complaint.
8 months ago, Chrome rewrote how URLs work [0]. Which, unsurprisingly, affects the `URL` constructor in JS.
We have had so many APIs vanish from any context to "secure contexts" only. Like AppCache, or workers, or the clipboard.
Entire APIs like XMLHttpRequestProgressEvent have vanished entirely.
In fact, there is a lot of obsolete features. Enough that there's a list. [1] You can't use global or source with a RegExp anymore. You can't use the arity property on a function anymore. `Object.prototype.eval` is dead. `Object.getNotifier` is dead. `Date.prototype.toLocaleFormat()` is dead.
Old websites have been broken. Repeatedly. Or we wouldn't have, say, blogspam on why mixed content suddenly broke some Wordpress systems.
Yes, these are good changes. They're more secure. However, we're willing to break some sites in the name of security, but unwilling to fix ambiguous parsing for the programmer?
> peoples' complaints about javascript type coercion is that they simply never bothered to learn how it works
soo.... if the pesky people keep complaining, maybe it really doesn't make any sense? i for the life of me could never figure out why a bunch of mainstream languages a couple of decades ago decided that typing is no longer necessary and should be abolished. Is there any benefit of removing type checking (and relying on bizarre implicit coercion rules when ambiguity ensues)?
Thanks for posting this. People still don't seem to get that there's no mystery out to make their life difficult and that unfortunately everything can probably ultimately be understood in a deterministic system.
This guy single handedly caused a wave of unproductive cynicism with this stunt. It's like the joke about all the things an everything bagel doesn't have except essentially shitting on the hard work of the entire industry by making up endless nitpicks for laughs.
`Date` is based on the original Java `Date` class and its API was mostly copied verbatim, explaining a lot of the quirks and silliness. While JS can't remove things easily because that would break the web, a lot of work has gone into a set of time primitives that will effectively replace it. `Date`'s parsing logic is so bad even Java has deprecated it.
This is one of those cases where the problem isn't language design but boardroom politics - Sun wanted JS not to compete with Java so they had to try to make JS more like Java to present JS as a kind of "Java for amateurs".
