Earlier quoted context omitted.
RISC is a misleading name, the concepts of its design are not really based around the idea of a "Reduced Instruction Set" as in "small" per se, nor are CISC machines necessarily a large size instruction set. 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 me…
when the concerned ARM instruction is doing something perfectly capable by the software to just score 1-2% performance improvements, it is definitely CISC based on the definitions you listed above.
ARM chips have an instruction with JavaScript in the name
261–270 of 312 posts
Re: ARM chips have an instruction with JavaScript in the name
#262Earlier quoted context omitted.
Personally I think this would be unfortunate as I don't think JavaScript is the path forward, but computers have always existed to run software (d'oh), which mean the natural selection will obviously make this happen if there is a market advantage. However I see all high performance web computing moving to WASM and JavaScipt will exist just as the glue to tie it together. Adding hardware support for this is naive and…
I partially agree. I wish TypeScript compiled directly into a JIT without compiling into JavaScript and I wish TypeScript has a strict mode that always actively requires type definitions.
Re: ARM chips have an instruction with JavaScript in the name
#263Earlier quoted context omitted.
That is simply not true, io language is prototype based yet it is simple to reason about, fix for JavaScript: Object = Object.prototype Function = Function.prototype That's how most dynamic languages work, no need for explanations, obvious assertions: Object.__proto__ === null Function.__proto__ === Object object = new Object.constructor object.__proto__ === Object object.constructor === Object.constructor object.toS…
... what? This comment is incomprehensible. What does it have to do with the parent comment (besides exemplifying the "teenager left at home for the first time" and creating-a-mess stuff)? None of this crazy reflective, meta-level programming belongs in the LOB application logic of any program. Save it for your programmer workspace/REPL environment--which is something that 90+% of JS programmers aren't using anyway.…
I've thought that's caused by prototype inheritance, but no io language [1] prototype based yet easy to understand. The only difference — it does not hide [[Prototype]]. I've redefined Object and Function to show how it works. You would get same result in "dead" files. REPL to make it easy to reproduce.
Imagine it is another language
object.private = function () { return 'hello' }
Object.shared = function () { return 'world' }
Object.constructor.static = function () { return '!' }
vs object.private = function() { return 'hello' }
Object.prototype.shared = function () { return 'world' }
Object.static = function () { return '!' }
Can you see the difference? Or straight from io tutorial Contact = (class {
constructor(name, address, city) {
this.name = name
this.address = address
this.city = city
}
}).prototype
holmes = new Contact.constructor("Holmes", "221B Baker St", "London")
Contact.fullAddress = function() {
return [this.name, this.address, this.city].join('\n')
}
holmes.fullAddress()
No "prototype" (except from class but it can be redefined).> ... and that's not even what instanceof means.
Thank you, it should check [[Prototype]] not constructor
// Object instanceof Object
Object.constructor.__proto__ === Function
// Object instanceof Object
Object.constructor.__proto__.__proto__ === Object
// Function instanceof Function
Function.constructor.__proto__ === Function
// Function instanceof Object
Function.constructor.__proto__.__proto__ === Object
[1] https://iolanguage.org/Re: ARM chips have an instruction with JavaScript in the name
#264Earlier quoted context omitted.
... what? This comment is incomprehensible. What does it have to do with the parent comment (besides exemplifying the "teenager left at home for the first time" and creating-a-mess stuff)? None of this crazy reflective, meta-level programming belongs in the LOB application logic of any program. Save it for your programmer workspace/REPL environment--which is something that 90+% of JS programmers aren't using anyway.…
Do you ever type "prototype"? Do you ever type "prototype" in any language but JavaScript? How it differs from other languages accessing [[Prototype]] / class directly, not through constructor? I've thought that's caused by prototype inheritance, but no io language [1] prototype based yet easy to understand. The only difference — it does not hide [[Prototype]]. I've redefined Object and Function to show how it works.…
> Do you ever type "prototype"?
Not every day or even once in an average week, unless you're doing something wrong.
> You would get same result in "dead" files.
You don't understand. You shouldn't even be futzing with these things in _any_ file in the first place. Keep this sort of thing inside your REPL, and keep it out of anything checked into source control or anything distributed to other other people. 99% of ordinary LOB logic simply does not require (or justify) the use of these kinds of meta-programming facilities. Don't start using clever code reflection tricks unless you're writing a reflection framework.
Dropping this highly relevant link here for the second time:
https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf
> straight from io tutorial `Contact = [...]`
Er... okay. In JS:
class Contact {
constructor(name, address, city) {
this.name = name;
this.address = address;
this.city = city;
}
getFullAddress() {
return this.name + "\n" + this.address + "\n" + this.city;
}
}
let holmes = new Contact("Holmes", "221B Baker St", "London");
console.log(holmes.getFullAddress());
Prints: Holmes
221B Baker St
LondonRe: ARM chips have an instruction with JavaScript in the name
#265Earlier quoted context omitted.
Do you ever type "prototype"? Do you ever type "prototype" in any language but JavaScript? How it differs from other languages accessing [[Prototype]] / class directly, not through constructor? I've thought that's caused by prototype inheritance, but no io language [1] prototype based yet easy to understand. The only difference — it does not hide [[Prototype]]. I've redefined Object and Function to show how it works.…
... what? > Do you ever type "prototype"? Not every day or even once in an average week, unless you're doing something wrong. > You would get same result in "dead" files. You don't understand. You shouldn't even be futzing with these things in _any_ file in the first place . Keep this sort of thing inside your REPL, and keep it out of anything checked into source control or anything distributed to other other people.…
Do you have to understand it or not? There is a ton of information on the web (viewed 191k times) [1], [2], etc. Acting like it is intuitive is disingenuous.
No, that's you who don't understand. I've shown particular code that is error prone in JS but is ok in other languages. That is the issue. It is not solved. Every novice gets it. It is simple to solve. Instead you claim "you should not need this", tell it 191k viewers. Yes, you know what's going on, still you claim "you don't need this".
class Foo
end
foo = Foo.new
foo.class == Foo // metaprogramming! *You shouldn't even be futzing with these things in _any_ file*
Sure I know about method definition in class. Extend it (same class). It is useful technique.And please don't post twice same if you can't read response.
[1] https://stackoverflow.com/questions/9959727/proto-vs-prototy...
Re: ARM chips have an instruction with JavaScript in the name
#266Re: ARM chips have an instruction with JavaScript in the name
#267Earlier quoted context omitted.
"When I use a word, it means just what I choose it to mean —neither more nor less."
It's not often that one comes across a quote from one of the greatest works of art: 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".
Descriptivism refers generally to describing how a community uses language, so the most common usages end up being the primary definitions. Once documented, these tend to become prescriptive.
In that context, a single author who uses a word in an unusual way would likely not have any impact on the descriptive or prescriptive definitions of that word, unless of course their usage becomes common.
Humpty was arguing for the benefits of using words in unusual ways, which potentially violates both prescriptivism and descriptivism.
Impressionistic use of words is one example of this, where the words used might convey a certain feeling, perhaps via their connotations, even though their literal definitions may not be exactly appropriate. This kind of usage is generally found in literature where language is being used as an artistic tool rather than a prosaic tool of communication.
tl;dr: my HN comments is a art
Re: ARM chips have an instruction with JavaScript in the name
#268Earlier quoted context omitted.
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.
Yeah, that's not objective. Sorry.
The comparative approach I mentioned can be used to eliminate personal feelings about such issues - not in all cases (types might be an example), but certainly in some.
Many users of Javascript, including myself, recognize that it has many weaknesses. There's even a book that acknowledges this in its title: "Javascript: The Good Parts."
Denying this seems to be denying objective reality.
You may be confusing "objective" with "universal," thinking that I'm claiming some unsituated universal truth. But that's not the case. Any statement is only ever true within some context - the language that defines it, the semantics of the statement, the premises that it assumes.
In this case, there is a shared context that crosses programming languages, that allows us in at least some cases to draw objective conclusion about programming language features. "The bad parts" implied by Crockford's title includes many such features. We can examine them and conclude that while they might have some historical rationale, that they are not good features for a programming language to have.
In many cases this conclusion is possible because there's simply no good justification - the title of this post is an example. Having all numbers be floating point has many negative consequences and no significant positive ones - the only reason for it is historical. Such features end up having consequences, such as on the design of hardware like ARM chips. That is an objectively terrible outcome.
You can of course quibble with such a statement, based on a rigid application of a simplistic set of definitions. But you'd do better to try to understand the truth conveyed by such a statement.
Re: ARM chips have an instruction with JavaScript in the name
#269Earlier quoted context omitted.
Yeah, that's not objective. Sorry.
What do you think "objective" means? The comparative approach I mentioned can be used to eliminate personal feelings about such issues - not in all cases (types might be an example), but certainly in some. Many users of Javascript, including myself, recognize that it has many weaknesses. There's even a book that acknowledges this in its title: "Javascript: The Good Parts." Denying this seems to be denying objective r…
None of the properties you're talking about are objective. Objective doesn't mean Crockford wrote a book about it or "lots of people agree with me".
Objective means factual. You're putting the word "objective" in front of your own and others opinions to arrogate the credibility of objectivity onto statements that are not based in observation of material reality.
More people holding an opinion doesn't make it a fact. "Terribleness" or "justifiableness" are not matters of fact, they are both matters of opinion.
Do you understand? You keep repeating your opinion and then using the word "objective" to claim that your opinion is fact. You think I am disagreeing with your opinion, rather I am disagreeing with you stating your opinion is a fact. No matter how many people agree with you it will never be a fact, it will always be an opinion because "terribleness" is not a matter of fact! "Terribleness" is the result of a value judgement.
There are no such things as "objective conclusions", objectivity is not a manner of reasoning. You're looking for something more like "observations", "measurements", hard facts.. none of which apply to "terribleness" because it can't be materially observed--only judged.
"Objectively" isn't an intensifier unless used in the form "Objectively [something that isn't objective]." Why would actual facts need to be intensified? What kind of insane argument would anyone have where facts and opinions are compared directly?
I know it sounds stronger to say your opinions are facts but it is okay to have opinions. Just remember that the difference between opinions and facts is a difference of kind rather than a difference of degree. You can argue an opinion, you can attempt to persuade me to your way of thinking if you show your reasoning.
Re: ARM chips have an instruction with JavaScript in the name
#270Earlier quoted context omitted.
... what? > Do you ever type "prototype"? Not every day or even once in an average week, unless you're doing something wrong. > You would get same result in "dead" files. You don't understand. You shouldn't even be futzing with these things in _any_ file in the first place . Keep this sort of thing inside your REPL, and keep it out of anything checked into source control or anything distributed to other other people.…
> Not every day or even once in an average week, unless you're doing something wrong. Do you have to understand it or not? There is a ton of information on the web (viewed 191k times) [1], [2], etc. Acting like it is intuitive is disingenuous. No, that's you who don't understand. I've shown particular code that is error prone in JS but is ok in other languages. That is the issue. It is not solved. Every novice gets i…
Because your comments are incomprehensible.
> I've shown particular code that is error prone in JS but is ok in other languages.
It's not OK in Java. It's not OK in C. It's not OK in C++. Because you can't even do that in any of those languages.
> still you claim "you don't need this"
Look at the languages I listed above. Think about the program you're trying to write. Do you think it's impossible to write the program you want to write in those languages, where you are not even allowed to to do your clever tricks?
Look at the underscores in the name __proto__. That's a huge, massive sign in your face that means, "If you find yourself touching this a lot, it's because you're doing something wrong." How could it be clearer? Imagine it were called __proto$do_not_use$__ instead. But you use it anyway. And then you ask, "why is this so difficult?". Where's the surprise?
Think about this whole thread. You're doing something, experiencing pain, and then complaining about the pain that you feel. Yes, of course you feel the pain. Every time you mention the pain, you are actually giving an argument against yourself: it's not the right thing. So stop doing it. The fact that you got instanceof wrong is further evidence that you're not the best person to tell us which road to take to get to the party--you don't know the city.
(As for the code snippet you wrote in this comment, it's not clear at all what you're even trying to say. Once again: incomprehensible.)