Hacker News Reader

Comment by pluc | Hacker News Reader

Please don't make fun of JavaScript. Last time it happened, it replied with Node and now it's everywhere.

I maintain that TypeScript is probably the best language you’ll be able to get paid to write.

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.

I wouldn’t blame TS for not fixing the JS standard library. It’s just a type system.

Normally, I would agree with you, but if you are going to say it’s the best language, then the criticism is fair.

Best language would be the entire ecosystem, including standard library

Yes, I just think you’ve got the wrong expectations if you say “TS failed to fix half of JS’s” problems.

Kotlin and even modern Java are both preferable for me. There’s no shortage of JVM roles.

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.

As of the last couple years, you're probably not wrong. Basically every open role right now requires TypeScript, Node, Next.JS, etc.

Swift is a bliss to write and easy to get paid to write it.

I feel differently, but I've only tried it briefly. It feels like an abomination that can't decide what it is and has just too much syntactic sugar.

Atrocious tooling.

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.

i was paid to write rust for a couple of years.

was it for blockchain stuff

Actually nope :)

Hence the 'probably'

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.

C# pays fine

If you like one, you’ll prolly like the other

Hell you might even like ActionScript ;P

If you like TypeScript and C#, then you'll probably also like Delphi and Turbo Pascal!

They were all written by the same guy, Anders Hejlsberg:

https://en.wikipedia.org/wiki/Anders_Hejlsberg

https://news.ycombinator.com/item?id=19568681

"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.

https://python-history.blogspot.com/2010/08/why-pythons-inte...

https://forth-standard.org/standard/diff?utm_source=chatgpt....

https://atariwiki.org/wiki/Wiki.jsp?page=Converting+FIG-Fort...

>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.

Hello Don!

I always suspected that FORTH had inconsistencies in division across versions. That's why the lord told us to Go FORTH and Multiply instead.

Delphi has been dead for 10+ years. Nobody uses it except for a few legacy applications and licenses cost $1200+.

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.

https://en.wikipedia.org/wiki/Turbo_Pascal

>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.

https://news.ycombinator.com/item?id=8664370

>"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.

First, [] + {} isn't an object, it's a string.

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

It’s absurd. Comedy is cognitive dissonance manifest. It can’t not be funny.

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.

The complaint is that type coercion exists at all. It solves no problems and creates several out of thin air.

Or are you arguing that ceteris paribus you'd rather not have the language throw an error or just propagate undefined?

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.

JS has had how many breaking changes since then...? They've transitioned to the future.

Why is it still here today?

> JS has had how many breaking changes since then...?

What breaking changes has JS ever had? Its an incredibly stable language.

Ok, lets reword that. JS has breaking changes in browsers or node at least once a year.

If the platform can continuously shift, in an ecosystem that rots faster than my veggie garden, can we not have more sensible systems in place?

You’ve still failed to give any examples of these breaking changes. Old websites still work great.

I’ll try again. What breaking changes does JavaScript make? What are you talking about?

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?

[0] https://news.ycombinator.com/item?id=41912354

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> 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)?

You will never bother me to learn something as convoluted as {} being sometimes parsed as an object and sometimes as a code block.

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.

I've read your comment several times and I still don't get how I'm supposed to be frustrated by this?

> the near decade of WAT snark

For today's lucky 10,000:

https://www.destroyallsoftware.com/talks/wat (2012)

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.

Did you even read TFA? Tell me dates make even the faintest sense.

`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".

Reply on news.ycombinator.com