Live data from Hacker News

Should JavaScript be split into two languages?

devclass.com

241–250 of 324 posts

Re: Should JavaScript be split into two languages?

#241

Earlier quoted context omitted.

Well this person is not the only one who thinks js (and web stuff in general) is terrible. I mostly dislike the pace of crapification; I comment almost daily on repositories asking why they made that breaking change with zero benefits for the user. Usually 'we are cleaning up' or so; there are npms that really need never be changed that are changing weekly just because 'keep them fresh'. That kind of misery is just w…

Your first paragraph complains about people, not the tool. It is a side effect of low barrier for entry, not some awfulness of JS. > Neither of these require any bullshit with tooling or anything hard. JS requires any text editor and a browser. TS requires Node and npm i -D typescript. > You can learn enough Go in a few hours to be productive (like C) You want to say that C and Go are easier to learn that JS? JS is l…

> TS requires Node and npm i -D typescript.

So need to install node and npm and then typescript. Go is 1 binary to download and throw in a dir.

I don't find js hard to learn (and I have been programming in it since it came out (I was in the CMS business since the early 90s), I just find it ugly and annoying to work with. But yeah, I guess the ecosystem definitely doesn't help as it's hard to see the proliferation of terrible software/frameworks and habits totally separate from the language; apparently there is something in it that attracts these terrible practices.

Re: Should JavaScript be split into two languages?

#242
post #239

Earlier quoted context omitted.

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

I wonder what the response would've been if I had left the WAT source code out and just claimed, "this WASM binary was built with a compiler", and not specified the language.

Re: Should JavaScript be split into two languages?

#243
If we take this logic, we should get rid of JavaScript support entirely and only support WASM, which would be a direction, but it would ignore how developers are using the platform.

It is now becoming rare when I see any serious project that still uses JavaScript, everyone I know is using TypeScript and I don't recall any job posts not requiring TypeScript. What are the standards bodies doing? They are still implementing hacks upon JavaScript instead of seeing the writing on the wall.

Maintaining JS engines is difficult because of the old stuff that few developers actually use, it would make a lot more sense to start deprecating those features and adding the new ones developers actually want.

I started using alternatives to NodeJS because I don't feel like I should subject myself to a compilation step if I don't have to.

Re: Should JavaScript be split into two languages?

#244

I'd argue that other languages did this (or something similar) to great success, most notably Java. That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes. W…

You are getting your history reversed.

Java is a product of the JVM, which was the innovation, not the reverse. A successful language moving post-success to a new byte code format would be as far as I know unprecedented.

The idea that JavaScript is an interpreted language is also fairly shaky. It’s JIT compiled as soon as it arrives to your browser. Honestly, a modern JS engine is not different from any other VM.

The question as you rightfully pointed really is what do you send to the browser and under it lies the fundamental question of what is a browser actually. Is it a way to browse hypertext content or a standardised execution environment?

Re: Should JavaScript be split into two languages?

#245
post #128

Earlier quoted context omitted.

That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower

Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.

> Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats.

The numeric tower in Scheme describes general number types with above of in the tower graphic (in the Wikipedia article) meaning subtype of. double precision floats and arbitrary precision integers are representations of numbers. Both would also be Real numbers.

Re: Should JavaScript be split into two languages?

#247

One of the examples given makes sense, since Symbol.specie messes with prototypical inheritance and is likely hard to secure as a result because that touches so much of JS as a whole. BigInt failing to materialize I think has more to do with ergonomics around it, they’re a bit unwieldy and there aren’t able to be used with the built in Math object functions. They also have zero JSON support out of the box which is a…

Can't replace Number with BigInt as BigInt is orders of magnitude slower on certain operations. Try to do bitwise operations with BigInt, you'll see what I mean.

bigint cannot be replaced by regular number when working with arbitrarily large whole numbers. With regular numbers you will lose precision out of the range [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER]. If you try to implement such functionality via JS, it would be even much slower than the bigint native implementation. So, it's great to have such thing natively implemented.

Re: Should JavaScript be split into two languages?

#248
post #239

Earlier quoted context omitted.

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

The point is that anyone who's distracted by the arcanity of Web Assembly Text Format obviously doesn't understand the first thing about WASM or its potential use cases. The poster could just have easily have used a regular programming language and compiled that down to a WASM binary. However, for the purposes of a minimal example to be pasted in a text box, this might have led to a much larger Uint8Array.

Re: Should JavaScript be split into two languages?

#249
post #228

Earlier quoted context omitted.

What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?

I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options: A) Get your hands dirty and write what you want. Once. B) Chant along with the mob who doesn't even understand what they're asking for. C) Wait several years for some super complicated solution to be designed by committee. I wouldn't even want direct access to the DOM if we had it today.…

there is also option D.

wait for a framework that implements option A.

if option A works, why aren't there any frameworks yet that implement it?

maybe all the framework devs are waiting for C?

but why?

you could be right about A but at present the majority view seems to be that C is the right option. which is what pushes me into going with B because i have no interest in developing my own framework.

if a framework appears that implements option A i'll gladly consider it. (just as long as it isn't tightly coupled with a backend)

Re: Should JavaScript be split into two languages?

#250

I'm a little annoyed that they said Bigint uses cases never materialized. I've used it several times and it isn't something that's easy to transpile. A bigint class has bad ergonomics and there's no way the perf can be equivalent.

Same toughs. It's irreplaceable when working with arbitrary sized integers. Even if it's used on 1-2% of websites, it's still a significant usage. Surely, it won't be used as commonly a regular floating point number.
Post reply on HN