Live data from Hacker News

ARM chips have an instruction with JavaScript in the name

stackoverflow.com

301–310 of 312 posts

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

#301
post #291

Earlier quoted context omitted.

> Now, attempts to do radically different things (like Itanium) failed for various reasons, in Itanium's case at least partially because it was hard to write compilers good enough to exploit its VLIW design. It's up in the air whether a different high-level language would have made those compilers feasible. My day job involves supporting systems on Itanium: the Intel C compiler on Itanium is actually pretty good... n…

Didn't later Itanium CPU microarchitectures internally shift to a much more classic design so the could work around the compiler issues?

I've never heard of that. If true, that might be a large hole in my theory :)

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

#302
post #295

Earlier quoted context omitted.

I completely agree that separate operators area MUST for dynamic languages. Lua allows operator overloading with metatables as do ruby and Python with classes http://lua-users.org/wiki/MetatableEvents https://docs.python.org/3/reference/datamodel.html#emulating... https://www.ruby-lang.org/en/documentation/faq/7/ > One number type in Lua: Not quite true. Lua had only 64-bit floats like JS until version 5.3 and the bl…

I have no grudge against operator overloading when done consciously — complex numbers, matrix multiplication. I've tried to implement JavaScript arithmetic in Ruby, failed so far. Sorry, I had to be clear, in Lua "one number type" means float, my bad. I meant Lua 5.3 integer still works like JavaScript Number. In the end we have to know about ToInteger, ToInt32, ToUint32, Number.MAX_SAFE_INTEGER [1]. It is not one nu…

> Object.prototype.toString is not as useful as Ruby, Python

I don't know that returning that info would be good or secure in JS

> Oh, DOM UTF-16 string broken by UCS-2 JavaScript function. I understand it is not easy to fix, Ruby fixed in 1.9, Python in 3.0, new languages (Rust, Elixir) come with UTF-8. Microsoft Windows has code pages, UCS-2, UTF-16.

The best and most compatible answer is moving JS to UTF-32. JS engines already save space by encoding strings internally as latin1 instead of UCS when possible (even around 90% of text from Chinese sites is still latin1). IMO they should have made backtick strings UTF-32, but that doesn't exactly transpile well.

> No, every Ruby object contains variables and has a link to a class which defines instance methods, we call it singleton_class

https://mccraigmccraig.files.wordpress.com/2008/10/ruby-eige...

https://i.stack.imgur.com/FPPdI.png

or adding all the things with a few instances, .constructor, etc

https://i.stack.imgur.com/HvzDP.png

I'll let you decide which implementation is easier to work through, but I have a definite opinion that Ruby's system is more complex (and Python layers their OOP on top of what is basically a hidden prototypal system).

> I've red through ES5 to be sure there are no hidden traps left.

You'll love newer ES versions then. The upcoming private fields are an even bigger mess.

JS needs a "use stricter" mode which really slices away the bad parts. Even better, just add a `version="es20xx"` requirement to use newer features and have browsers ignore what they don't know, so you could even compile and link to multiple compilation levels of the same script and have the browser choose.

In truth, JS would be in the best place of any top-20 language if Eich had just been allowed to make a scheme variant as he had planned.

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

#303
post #291

Earlier quoted context omitted.

Didn't later Itanium CPU microarchitectures internally shift to a much more classic design so the could work around the compiler issues?

I've never heard of that. If true, that might be a large hole in my theory :)

To quote David Kanter at Realworldtech

> Poulson is fundamentally different and much more akin to traditional RISC or CISC microprocessors. Instructions, rather than explicitly parallel bundles, are dynamically scheduled and executed. Dependencies are resolved by flushing bad results and replaying instructions; no more global stalls. There is even a minimal degree of out-of-order execution – a profound repudiation of some of the underlying assumptions behind Itanium.

https://www.realworldtech.com/poulson/

Given the large amount of security problems OoO has caused, there is a chance that we may revisit the experiment in the future with a less rigid attitude and greater success.

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

#304
post #289

Earlier quoted context omitted.

C++ has WAY more spec footguns than JS (and that's without counting all the C undefined behaviors which alone outweight all the warts of JS combined). PHP also beats out JS for warts (and outright bad implementation like left-to-right association of ternaries). Ruby has more than it's fair share of weirdness too (try explaining eigenclass interactions to a new ruby dev). Even python has weirdness like loops having an…

I have not claimed JS is the weirdest. But I have not claimed "Normally C++/PHP/Ruby/Python devs don't really encounter these notorious problems, for many years now" either. Eigenclass (singleton_class) explained in another thread. I have not encountered Pythons for/else [1] yet. Right, typeof null exposed by Microsoft IE 2 (?). Web is many times bigger now yet even such a small mistake is not fixed. I have issue + o…

`__proto__` doesn't necessarily equal `.prototype`.

    var foo = Object.create(null)
    //now foo.prototype and foo.__proto__ are both undefined
    foo.prototype = {abc:123}
    //foo.__proto__ is still undefined. Need to use Object.setPrototypeOf()
In older JS code, I've seen people trying to abuse prototypes. One result in this kind of thing is often retaining references to those hidden `__proto__` leading to memory leaks.

Also, `__proto__` is deprecated. If you're writing JS, you should be using `.getPrototypeOf()` instead.

> Could you please expand this part? "Primitive" has specific meaning in JavaScript.

    var fn = function () {}
    fn.bar = "abc"

    Object.keys(fn) //=> ["bar"]

    //likewise
    (1).__proto__ === Number.prototype //=> true
JS is torn on the idea of whether something is primitive or an object. You see this (for example) in Typescript with the primitive number being different from the Number type which represents a number object. To get at the primitive, you must actually call `.valueOf()` which returns the primitive in question. Meanwhile, you can attach your own properties to the function object -- a fact exploited by many, many libraries including modern ones like React. You can also add your own `.valueOf()` to allow your code to better interact with JS operators, but I believe that to pretty much always be a bad practice.

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

#305
post #302

Earlier quoted context omitted.

I have no grudge against operator overloading when done consciously — complex numbers, matrix multiplication. I've tried to implement JavaScript arithmetic in Ruby, failed so far. Sorry, I had to be clear, in Lua "one number type" means float, my bad. I meant Lua 5.3 integer still works like JavaScript Number. In the end we have to know about ToInteger, ToInt32, ToUint32, Number.MAX_SAFE_INTEGER [1]. It is not one nu…

> Object.prototype.toString is not as useful as Ruby, Python I don't know that returning that info would be good or secure in JS > Oh, DOM UTF-16 string broken by UCS-2 JavaScript function. I understand it is not easy to fix, Ruby fixed in 1.9, Python in 3.0, new languages (Rust, Elixir) come with UTF-8. Microsoft Windows has code pages, UCS-2, UTF-16. The best and most compatible answer is moving JS to UTF-32. JS en…

Yes, template strings was a clean start.

Of course prototype based language is simpler than class based. Ruby system is more complex. It provides more tools — Class, Module, class and instance methods, variables (as depicted on the picture). You've asked eigenclass (singleton_class these days), that's Class:a -> A, very simple concept.

And yet Ruby inheritance is much easier, it is all around and it just works. No one does this in JavaScript, too complex. There were many attempts of building OOP people could understand on top of JavaScript in 200x. No one does this for Ruby.

> https://i.stack.imgur.com/FPPdI.png

With fix above:

http://sergeykish.com/javascript-no-constructor.png

I'll let you decide which implementation is easier to work through, but I have a definite opinion that current JavaScript system is more complex.

> You'll love newer ES versions then. The upcoming private fields are an even bigger mess.

I follow.

Netscape and Mozilla tried version approach. Module is a clean start, 'use strict' by default. It is not Visual Basic, already good.

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

#306
post #304

Earlier quoted context omitted.

I have not claimed JS is the weirdest. But I have not claimed "Normally C++/PHP/Ruby/Python devs don't really encounter these notorious problems, for many years now" either. Eigenclass (singleton_class) explained in another thread. I have not encountered Pythons for/else [1] yet. Right, typeof null exposed by Microsoft IE 2 (?). Web is many times bigger now yet even such a small mistake is not fixed. I have issue + o…

`__proto__` doesn't necessarily equal `.prototype`. var foo = Object.create(null) //now foo.prototype and foo.__proto__ are both undefined foo.prototype = {abc:123} //foo.__proto__ is still undefined. Need to use Object.setPrototypeOf() In older JS code, I've seen people trying to abuse prototypes. One result in this kind of thing is often retaining references to those hidden `__proto__` leading to memory leaks. Also…

Yes, I know about null [[Prototype]] and who is owner of prototype and __proto__. I like how it is not real property

    var foo = {
      __proto__: null
    }
    foo.__proto__
    undefined
As you can see I do not store it and do not modify it, it is assertion, kind of instanceof.

> Also, `__proto__` is deprecated

Object.getPrototypeOf would be too verbose in this example. I could have defined

    Object.defineProperty(Object.prototype, "proto", {
      get() { Object.getPrototypeOf(this) }
    })
but why bother? We both know that I meant [[Prototype]].

> Primitive

> fn.bar = "abc"

is syntactic sugar for

fn["bar"] = "abc"

do not follow.

> (1).__proto__ === Number.prototype

number is primitive

    typeof 1
    "number"
    1 instanceof Number
    false
number is wrapped in Number when we access property

    Number.prototype.foo = function () { return this }
    1..foo()
    //Number {1}
    typeof 1..foo()
    //"object"
    1..foo() instanceof Number 
    //true
Function is not primitive

    typeof Math.max
    "function"
    Math.max instanceof Function
    true
    Math.max instanceof Object 
    true
it is an object, we can attach properties to object.

As I remember valueOf is complicated by hints, exposed in JavaScript [1]. I've played with removal

    delete Array.prototype.toString
    delete Object.prototype.toString
    Uncaught TypeError: Cannot convert object to primitive value
Unfortunately it converts to string and than converts string to number.

    delete Array.prototype.valueOf 
    delete Object.prototype.valueOf 
    +[]
    //0
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#307
post #128

Earlier quoted context omitted.

Strong sequential consistency is a big one. Most architectures that have tried to diverge from this for performance reasons run into trouble with the way people like to write C code (but will not have trouble with languages actually built for concurrency). Arguably the scalar focus of CPUs is also to make them more suited for C-like languages. Now, attempts to do radically different things (like Itanium) failed for v…

> in Itanium's case at least partially because it was hard to write compilers good enough to exploit its VLIW design This is half true. The other half is that OOO execution does all the pipelining a "good enough" compiler would do, except that dynamically at runtime, benefiting from just in time profiling information. Way back in the day OOO was considered too expensive, nowadays everybody uses it.

OOO parallelism runs hard into limits too (see the heroic measures current ones go to to increase IPC a teensy bit). Parallelism friendly languages have the potential to break through this barrier given parallelism friendly processors. (And they do in GPU land...)

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

#308
post #19

It seems like every 2 months I feel the burn of JS not having more standard primitive types and choices for numbers. I get this urge to learn Rust or Swift or Go which lasts about 15 minutes... until I realize how tied up I am with JS. But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development.

Are you saying you'd like to have specific int32, int64, float32, float64 types?

Yes this specifically.

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

#309

Earlier quoted context omitted.

> C was specified by K&R in 1978. No it wasn’t. K&R was far removed from many C implementations of the time, wasn’t ever written as a formal spec, and had gaping holes of undefined behavior. An educational textbook isn’t a formal language specification.

C was the K&R book, PASCAL was the User manual and Report. These were the platonic ideals of the languages. The specification was the language, the fact that there was an implementation was a bonus. I never once in my comments above said "formal" so perhaps we are meaning two very different things by "specification." No version of Cs specification since K&R has done away with undefined, nor implementation defined beh…

> C was the K&R book

How could this be when zero implementations behaved in accordance with K&R?

The authors and fans may have claimed it as a “spec”, but it never was a functional “spec” in the real world.

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

#310
post #303

Earlier quoted context omitted.

I've never heard of that. If true, that might be a large hole in my theory :)

To quote David Kanter at Realworldtech > Poulson is fundamentally different and much more akin to traditional RISC or CISC microprocessors. Instructions, rather than explicitly parallel bundles, are dynamically scheduled and executed. Dependencies are resolved by flushing bad results and replaying instructions; no more global stalls. There is even a minimal degree of out-of-order execution – a profound repudiation of…

Thanks, that’s a really great article. It does change my views significantly.
Post reply on HN