211–220 of 312 posts
Earlier quoted context omitted.
That’s not what “objective” means.
"When I use a word, it means just what I choose it to mean —neither more nor less."
https://www.goodreads.com/quotes/12608-when-i-use-a-word-hum...
That whole conversation is quite interesting and perhaps this part can also be thought of as alluding to "prescriptivism versus descriptivism".
Earlier quoted context omitted.
Would you say the same if the language was c or c++? Yes this is necessitated by some of JS's big warts, but the sheer amount of javascript in existence weights heavily when considering the trade-offs. You cannot ignore HTML/JS if you're targeting UI applications - it is table stakes.
Yeah, but isn't the whole point of ARM to be a reduced instruction set? How reduced are we, really, if we're dedicating transistors to the quirks of a single language?
It is much more about the design of the instructions, generally RISC instructions take a small, fixed amount of time and conceptually are based on a sort of minimum unit of processing, with a weak to very weak memory model (with delay slots, pipeline data hazards, required alignment of data etc) with the compiler/programmer combining them into usable higher level operations.
CISC designs on the other hand happily encode large, arbitrarily complex operations that take unbounded amounts of time, and have very strong memory models (x86 in particular is infamous here, you can pretty much safely access memory, without any alignment, at any time, even thought often the result will be slow, it wont crash)
As an example, the PDP-8 has fewer than 30 instructions, but is still definitely a CISC architecture, some ARM variants have over 1000 instructions but are still definitely RISC.
RISC is about making building processors simpler, not about making instruction sets and programming with them necessarily simpler.
Earlier quoted context omitted.
Would you say the same if the language was c or c++? Yes this is necessitated by some of JS's big warts, but the sheer amount of javascript in existence weights heavily when considering the trade-offs. You cannot ignore HTML/JS if you're targeting UI applications - it is table stakes.
Yeah, but isn't the whole point of ARM to be a reduced instruction set? How reduced are we, really, if we're dedicating transistors to the quirks of a single language?
Earlier quoted context omitted.
Its not that it isn't capable, its that it has more gocha's than most other languages of it size (and no, just because the gocha is well defined doesn't mean that it doesn't trip programmers up). Its also despite a couple decades of hard work by some very good compiler/JIT engineers at a considerable disadvantage perf wise to a lot of other languages. Third its most common runtime environment, is a poorly thought out…
Many of the gotchas wouldn't ever show up if only people committed to writing JS as sensibly as they write their programs in other languages when they're being forced to do things a certain way. But when it comes to JS and even other dynamic languages, people for some reason absolutely lose their minds, like a teenager whose parents are going out of town and are leaving them home by themselves overnight for the first…
Object = Object.prototype
Function = Function.prototype
Object.__proto__ === null
Function.__proto__ === Object
object = new Object.constructor
object.__proto__ === Object
object.constructor === Object.constructor
object.toString === Object.toString
object.private = function () { return 'hello' }
Object.shared = function () { return 'world' }
Object.constructor.static = function () { return '!' }
// Object instanceof Function
Object.constructor.__proto__.constructor === Function.constructor
// Object instanceof Object
Object.constructor.__proto__.__proto__.constructor === Object.constructor
// Function instanceof Function
Function.constructor.__proto__.constructor === Function.constructor
// Function instanceof Object
Function.constructor.__proto__.__proto__.constructor === Object.constructor
Object.constructor.__proto__ === Function
Object.constructor.__proto__.__proto__ === Object
Function.constructor.__proto__ === Function
Function.constructor.__proto__.__proto__ === Object
Earlier quoted context omitted.
Regarding gotchas, it's bearable. I only have a couple on my short list: == vs === and xs.includes(x) vs x in xs, and only the latter is not reducible to a trivial rule of thumb. TS is helpful in this regard, possibly there are more in plain JS. Regarding performance, modern JS is plenty fast, but it's not in the 'terrible' category. It's memory usage, perhaps ;) https://benchmarksgame-team.pages.debian.net/benchmark…
Why are MFC and QT inferior to the Javascript way? I don’t know much about either.
* Apps eventually degenerate in a mess of interconnected components triggering events on each other. Building UIs felt more like writing Verilog than writing functions. Nothing like chasing event ordering bugs through library components. With React I never saw 'enqueue a new event for component X' anti-pattern. All callbacks flow from children to parents in a fairly regular manner.
* Related, there is no need to manually manage repaint events in React. Visual updates happen automagically. See, for example, https://stackoverflow.com/questions/952906/how-do-i-call-pai... for a hair pulling session related to manual repainting.
* On the ergonomics side, having a markup language allows for terse but readable definitions of component trees. I see 2020 Qt has introduced a markup language, this was not the case circa 2005.
* Hooks give an extra layer of niceness. Declaring a component is as easy as declaring a function. Local state becomes almost as simple as declaring a local variable.
* The inspector capabilities of modern browsers are very handy when debugging layout and styling issues.
Earlier quoted context omitted.
So, there are excuses for Javascript's terribleness, but that doesn't stop it from being objectively terrible.
And that's your opinion. I find javascript quite enjoyable and easy to use, without producing errors. YMMV.
Earlier quoted context omitted.
Sad to see the word "objective" become the next bullshit intensifier because people can't separate their own subjective opinions from the realm of verifiable fact. "Terribleness" isn't an objective property.
You can compare Javascript to other languages and note that many of its notorious problems have no rational justification, and are unnecessary. That's what I call objectively terrible.
Earlier quoted context omitted.
It seems to me people are ignoring that the C stands for Complexity. What's reduced is Complexity of the instruction set, not the size of it (or even the instructions themselves). In the context of the coinage of the term, they almost certainly could have called it "microcode-free ISA", but it wouldn't have sounded as cool.
Is ARM even microcode free these days?
Earlier quoted context omitted.
> Adding hardware support for this is naive and has failed before (ie. Jazelle, picoJava, etc). The hardware support being added here would work just as well for WASM (though it might be less critical).
Pray tell in which way this will help WASM?
Earlier quoted context omitted.
Sad to see the word "objective" become the next bullshit intensifier because people can't separate their own subjective opinions from the realm of verifiable fact. "Terribleness" isn't an objective property.
You can compare Javascript to other languages and note that many of its notorious problems have no rational justification, and are unnecessary. That's what I call objectively terrible.