[dead]
Proposal: JavaScript Structs
61–70 of 371 posts
Re: Proposal: JavaScript Structs
#62Earlier quoted context omitted.
High performance applications are already being written that depend on features like shared memory, but because the language has poor support for them then developers have to use ugly workarounds. This proposal solves that with built-in support. >It should just stay this way Counterpoint: JS has been evolving significantly, look at ES6 and ES8 in particular if you need help finding examples.
Exactly. Without new features and syntaxes people would still be doing MyClass.prototype.method = function () { } like idiots. Such a meaningless argument for preventing progress.
Nobody needs classes nor prototypes in JS. Objects + functions is more than enough. I stopped using these few years ago and miss nothing.
Re: Proposal: JavaScript Structs
#63I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…
I think in this specific case it's JavaScript's requirement for backwards compatibility that bloats it... but there's a lot you can ignore. Like, you can declare a variable with var, let or const but there's absolutely no reason to use var any more. I feel similarly about the proposals to introduce records and tuples: https://github.com/tc39/proposal-record-tuple ... in most scenarios you'll probably be better off us…
> I'm not so sure about that. I think we end up consuming a lot of these features in the TS types that get published alongside libraries. We just don't know it, we just get surprisingly intuitive type interfaces.
Very true. As a downstream consumer, I can do all business logic in ancient, simple languages. But I'm sure these things are extremely nice to have for the more complicated upstream dependencies I rely on.
Re: Proposal: JavaScript Structs
#64I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…
Javascript is not simple AT ALL.
It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects proxies, counter-intuitive array and mapping manipulations, lots of different ways to create said arrays and mappings, very rich destructuring, so many weirdnesses on parameter handling, multiple ways to do imports that don't work in all contexts, exports, string concatenation + string interpolation, no integer (but NaN), a "strict mode", two versions of comparison operators, a dangerous "with" keyword, undefined vs null, generators, sparse arrays, sets...
It also has complex rules for:
- scoping (plus global variables by default and hoisting)
- "this" values (and manual binding)
- type coercion (destroying commutativity!)
- semi-column automatic insertion
- "typeof" resolution
On top of that, you execute it in various different implementations and contexts: several browser engines and nodejs at least, with or without the DOM, in or out web workers, and potentially with WASM.
There are various versions of the ECMA standard that changes the features you have access to, unless you use a transpiler. But we don't even touch the ecosystem since it's about the language. There would be too much to say anyway.
There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough.
Re: Proposal: JavaScript Structs
#65I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…
This is why always say the true beginner programming language is C. Stupid easy to learn, have some loops, have some conditions, make some memory allocations. You will learn about the fundamentals of computing as well, which you might as well ignore (unknowingly) if you start with something like JavaScript (where is this data living in my computer?).
And this is why I always say, we have a world full of computer consumers, not programmers.
C as a first language is only easy, if you happen to bring along a deep technical interest (and pre knowledge) about the "technical fundamentals of computing".
Most people do not have that.
Tell them about heap and memory allocations and you will get a blank stare.
But show them some simple functions, to make some flashing graphics on the sceen - and they will have fun. And can learn the basics of programming at the same time.
And then you can advance more low level, for those who feel the call. But please don't start with it, unless you have some geeky hacker kids in front of you who really want to learn computers. Then C makes sense. For "normal" people not so much.
Re: Proposal: JavaScript Structs
#66Please stop. What a nonsense. JS is a dynamic language where everything is a Hashtable. It will never be really fast as your structs won’t be in single cacheline, you won’t be able to calculate field address during compile time by pointer offsets. There’s no simd, no multithreading, no real arrays. JS is such a simple, dynamic language. It should just stay this way. Please stop bloating it with every feature that’s t…
High performance applications are already being written that depend on features like shared memory, but because the language has poor support for them then developers have to use ugly workarounds. This proposal solves that with built-in support. >It should just stay this way Counterpoint: JS has been evolving significantly, look at ES6 and ES8 in particular if you need help finding examples.
I just mean you won’t write a video codec or a 3d renderer in JS. It will never get there. Just leave these things to WebAssembly where needed and leave JS as a slow, dynamic language we use for web apps.
Re: Proposal: JavaScript Structs
#67I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…
Try Go. Go is really stable as a language and have a very small core feature set.
This is easily the most appealing thing to me about Go. I learned Go through the "Learn Go with Tests" way and I had a ton of fun.
It is hard for me to recommend using Go internally since .NET/Java are just as performant and have such a mature ecosystem, but I crave simplicity in the core libraries.
Here's the link for anyone considering learning Go: https://quii.gitbook.io/learn-go-with-tests
Re: Proposal: JavaScript Structs
#68I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…
> And nobody uses most of it! Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it.
> Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features.
This is very true and my original post was short sighted. You could, of course, make most upstream dependencies without modern language features. However, their complex jobs get much easier with these features.
Downstream, business logic is much easier to implement without these features compared to complex, low level functionality.
Re: Proposal: JavaScript Structs
#69I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…
Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects pro…
This is true, but what's also true is using biome or eslint more than half of your complaints are gone. JS has always had bad parts, but today it's a lot easier to avoid them thanks to linters. And if you do stay in the good parts, it's my favorite language, for many reasons.
That said, I hate the constant stuffing of features (though not this one which is much needed), more stuff around JS like WebComponents, or CSS adding a ton of sugar.
Re: Proposal: JavaScript Structs
#70Earlier quoted context omitted.
High performance applications are already being written that depend on features like shared memory, but because the language has poor support for them then developers have to use ugly workarounds. This proposal solves that with built-in support. >It should just stay this way Counterpoint: JS has been evolving significantly, look at ES6 and ES8 in particular if you need help finding examples.
I just mean you won’t write a video codec or a 3d renderer in JS. It will never get there. Just leave these things to WebAssembly where needed and leave JS as a slow, dynamic language we use for web apps.
It's a false dichotomy. Computers are fast. You should be able to write fast computer programs in any language.
The limiting factor on a program's performance should be the design of algorithms and data structures, not the programmer's choice of language or runtime.