Live data from Hacker News

ARM chips have an instruction with JavaScript in the name

stackoverflow.com

201–210 of 312 posts

Re: ARM chips have an instruction with JavaScript in the name

#201

Earlier quoted context omitted.

For a long time I thought the JS hate was just a friendly pop jab. From working with backend folks I’ve realized it comes from at least a somewhat patronizing view that JS should feel more like backend languages; except it’s power, and real dev audience, is in browsers, where it was shaped and tortured by the browser wars, not to mention it was created in almost as many days as Genesis says the world was built.

So, there are excuses for Javascript's terribleness, but that doesn't stop it from being objectively terrible.

That’s not what “objective” means.

Re: ARM chips have an instruction with JavaScript in the name

#202

Earlier quoted context omitted.

For a long time I thought the JS hate was just a friendly pop jab. From working with backend folks I’ve realized it comes from at least a somewhat patronizing view that JS should feel more like backend languages; except it’s power, and real dev audience, is in browsers, where it was shaped and tortured by the browser wars, not to mention it was created in almost as many days as Genesis says the world was built.

So, there are excuses for Javascript's terribleness, but that doesn't stop it from being objectively terrible.

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.

Re: ARM chips have an instruction with JavaScript in the name

#203

It strikes me as ironic that an architecture that used to pride itself on being RISC and simple is heading in the same direction as intel-levels of masses of specialist instructions. I don't mean this as a criticism, I just wonder if this is really the optimum direction for a practical ISA

Ironically this instruction only exists because JavaScript accidentally inherited an Intel quirk in it's double-to-int conversion. This instruction should be "Floating Point Intel Convert" not "Floating Point Javascript Convert", but w/e, trademark laws and all that.

In practice the instruction made code a few percent faster, primarily because it allowed dropping a few branches at the end of every JavaScript int conversion on ARM. IMO, ARM has always been at the "edge" of RISC (at least until AArch64 threw out all of it's quirks) and the exception proves the rule here. Instructions like this exist specifically because they accelerate execution time, rather than for assembler programmer convenience. That's the same underlying reason why RISC had such an advantage over CISC before micro-op decoders and register renaming became a thing. It's not so much that "having less instructions is better", but that things like memory operands or repeat prefixes or what have you primarily act as programmer convenience at the expense of code efficiency. Stuff like FJCVTZS is used by compiled code to gain a measurable speed benefit, ergo it stays in.

Re: ARM chips have an instruction with JavaScript in the name

#204

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.

I'd love to have a way to take a `Date` object and set it as the value of a `datetime-local` input. Sure feels like that should be straightforward to do, without requiring any weird conversions like it does.

Re: ARM chips have an instruction with JavaScript in the name

#205

Earlier quoted context omitted.

I would argue a solid 1-2% can get you a promotion in HW companies. You put 5 of this improvements and that’s a generational improvement.

1-2% for a single language at the cost of polluting an entire instruction set.

It's not a random esoteric programming language, it's JavaScript.

Re: ARM chips have an instruction with JavaScript in the name

#206

Earlier quoted context omitted.

So, there are excuses for Javascript's terribleness, but that doesn't stop it from being objectively terrible.

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.

Re: ARM chips have an instruction with JavaScript in the name

#207

Earlier quoted context omitted.

So, there are excuses for Javascript's terribleness, but that doesn't stop it from being objectively terrible.

That’s not what “objective” means.

"When I use a word, it means just what I choose it to mean —neither more nor less."

Re: ARM chips have an instruction with JavaScript in the name

#208

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.

JavaScript has good parts, I write it a lot. But it is ignorant to close eyes on its warts

    1 + '2'
    1 - '2'
    Number.MAX_SAFE_INTEGER + 2
and entire WAT series, stems from "don't raise" ethos. JavaScript exposes constructor instead of prototype that messed up a lot, in Ruby terms

    Object.alias_method :__proto__, :class
    Object = Object.instance_method(:initialize)
    Class = Class.instance_method(:initialize)
    Class.__proto__.alias_method :prototype, :owner
    new = ->(constructor) { constructor.owner.new }
    
    Person = Class.prototype.new do
      def initialize
      end
    end.instance_method(:initialize)
    
    def Person.foo
      'foo'
    end
    puts Person.foo

    john = new.call Person
    
    def john.bar
      'bar'
    end
    puts john.bar
    
    def (Person.prototype).baz
      'baz'
    end
    puts john.__proto__.baz
Does anyone wants to adopt this feature in their language?

Re: ARM chips have an instruction with JavaScript in the name

#209
post #177

Earlier quoted context omitted.

1-2% for a single language at the cost of polluting an entire instruction set.

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?

Re: ARM chips have an instruction with JavaScript in the name

#210

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…

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.
Post reply on HN