Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should JavaScript be split into two languages?

devclass.com

Post reply on HN
Print view View original

231–240 of 324 posts

Re: Should JavaScript be split into two languages?

#231

Post by Dylan16807 »

xscott wrote: post #224
Dylan16807 wrote: post #209

Earlier quoted context omitted.

> This is where you say something about "exact" vs "inexact" as though that will hand wave it away. I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.

It's a rule, and it behaves like people probably expect for small numbers. But following that rule: float(0.5) + bigint(9007199254740993) == float(9007199254740992) I wouldn't parade it around as a triumph over the problem, and it's arguably better to require people to be explicit about whether converting the float to bigint, or the bigint to float, is what you wanted.

That doesn't really strike me as worse than any other use of == on a float. If anything needs to change there, I think it's more rigor in float comparisons.

Basically, ULP-level inaccuracy is a problem inherent to having float at all, even without bignum interactions. They would be a menace even if you had a pure tower from 32 bit int to double to complex to more.

Re: Should JavaScript be split into two languages?

#232

Post by xscott »

Dylan16807 wrote: post #231
xscott wrote: post #224

Earlier quoted context omitted.

It's a rule, and it behaves like people probably expect for small numbers. But following that rule: float(0.5) + bigint(9007199254740993) == float(9007199254740992) I wouldn't parade it around as a triumph over the problem, and it's arguably better to require people to be explicit about whether converting the float to bigint, or the bigint to float, is what you wanted.

That doesn't really strike me as worse than any other use of == on a float. If anything needs to change there, I think it's more rigor in float comparisons. Basically, ULP-level inaccuracy is a problem inherent to having float at all, even without bignum interactions. They would be a menace even if you had a pure tower from 32 bit int to double to complex to more.

I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead of == to indicate "the result of this operation", but that probably would've caused confusion too...

The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion decisions for you. It's just a rule, and it's not an amazing rule.

Re: Should JavaScript be split into two languages?

#233

Post by [deleted] »

Kwpolska wrote: post #52

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

[deleted]

Re: Should JavaScript be split into two languages?

#234

Post by [deleted] »

Kwpolska wrote: post #52

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

[deleted]

Re: Should JavaScript be split into two languages?

#236

Post by a57721 »

wiseowise wrote: post #225
a57721 wrote: post #206

Earlier quoted context omitted.

Kotlin and Rust are modern languages that were designed much later and not so hastily, so they have less warts than JavaScript as a result.

Kotlin is a lipstick on a pig that effectively doesn’t exist outside of IntelliJ, single vendor that is only interested in driving sales to their IDEs and doesn’t work without bringing baroque Gradle. It has amazing coroutines library and it started with a nice set of features but failed to evolve. Sealed types are a joke compared to union types in TS. No inline types so you’re forced to created stupid data classes e…

No, I wasn't suggesting that Rust is better for prototyping, the only thing I said is that Kotlin and Rust (that you mentioned yourself) are better than JavaScript because they were designed much later and more thoroughly. TypeScript is a different thing to me, it makes part of this new generation of languages, its only problem is that it works on top of JavaScript.

Re: Should JavaScript be split into two languages?

#237

Post by Dylan16807 »

xscott wrote: post #232
Dylan16807 wrote: post #231

Earlier quoted context omitted.

That doesn't really strike me as worse than any other use of == on a float. If anything needs to change there, I think it's more rigor in float comparisons. Basically, ULP-level inaccuracy is a problem inherent to having float at all, even without bignum interactions. They would be a menace even if you had a pure tower from 32 bit int to double to complex to more.

I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead of == to indicate "the result of this operation", but that probably would've caused confusion too... The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion decisions for you. It's just a rule, and it's not an amazing rule.

> I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead

Then it's even less of issue. Yes if you convert to a float you get rounding, what did you expect when you introduced a float?

It's somewhat unintuitive but that's the nature of floating point.

> The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion decisions for you. It's just a rule, and it's not an amazing rule.

But again, you can have the same kind of issue without bignums. It's not a tower problem it's a float problem.

Re: Should JavaScript be split into two languages?

#238

Post by xscott »

Dylan16807 wrote: post #237
xscott wrote: post #232

Earlier quoted context omitted.

I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead of == to indicate "the result of this operation", but that probably would've caused confusion too... The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion decisions for you. It's just a rule, and it's not an amazing rule.

> I wasn't trying to draw attention to comparisons for equality. Perhaps I should've used an arrow => instead Then it's even less of issue. Yes if you convert to a float you get rounding, what did you expect when you introduced a float? It's somewhat unintuitive but that's the nature of floating point. > The real point is that you can get some non-intuitive answers from letting that numeric tower make conversion deci…

I think I can summarize your point of view as, "any use of floats should be treated as undefined behavior, so you get what you deserve."

And that says nothing about whether implicit conversions are a good idea or not.

Re: Should JavaScript be split into two languages?

#239

Post by reshlo »

DonHopkins wrote: post #198
xscott wrote: post #195

Earlier quoted context omitted.

> I need to write some arcane function signature language for every DOM manipulating function You really don't know that you can create WebAssembly in other languages?!? I used WAT to keep the example short, but that's clearly lost on you. > I'll give another 4 years and see if they fixed this. In that time, there are lot of things you could be learning. Embracing ignorance and belligerence isn't like to serve you we…

[flagged]

> it’s just a standard s-expression syntax

I.e. they are correct that it is arcane. What percentage of programmers today do you think have ever seen code written in any Lisp dialect, let alone understand it?

Re: Should JavaScript be split into two languages?

#240

Post by javajosh »

petre wrote: post #221
javajosh wrote: post #186

Earlier quoted context omitted.

The problem is within that gray area. For enjoyers of vanilla js, like myself, I'd hate it if "core" js got so small that I now started to require a compiler for my ES6 code. If I was in charge I'd say "fine, but the core must be at least as large as ES6" and I'd reserve the right to tweak browser native modules in minor ways (for example, it would be nice to support a SPA syntax where you could export/import modules…

The vanilla js APIs are so atrocious that we got jquery.

I think you missed a tense. Was atrocious, we got jquery, which got folded back into javascript. If the last time you worked with vanilla js was when jquery was hot, you're views are outdated.
Post reply on HN