Here are some recent interesting videos by "Mentour Pilot" about the DC10 plane accidents caused by a cargo door coming off and depressurising the cargo hold:
What happened, if you don't want to watch all the video, is that the aeroplane actually collapsed internally. In the second case, some of the passengers were sucked out of the plane.
> UTF-8 is just a way to encode, it doesn't decide what goes into Unicode.
If UTF-8 had not had sequences above 3 bytes, you would not have been able to use it to express Unicode characters as high as Emoji which would certainly have hampered their adoption, is what the person you're replying to means.
While your conclusion is largely correct, it doesn't follow from your premises: UTF-16 is just a way to encode, but its brain-damaged surrogate pair mechanism very much did get baked into Unicode (namely, high and low surrogate code points D800-DFFF).
I think the point is that they accept more than the spec dictates - do your JSON parsers accept e.g. the vs code config file (JSON with comments) or JSON with unquoted keys?
The most commonly used parsers only accept valid JSON - including the one included within most JS runtimes (JSON.stringify/parse). VSCode explicitly uses a `jsonc` parser, the only difference being that it strips comments before it parses the JSON. There's also such thing as `json5`, which has a few extra features inspired by ES5. None of them are unquoted strings. I've never come across anything JSON-like with unquoted strings other than YAML, and everything not entirely compliant with the spec has a different name.
GPT-3 was banished for life from Facebook for raping a sweet, 7-year-old girl! Find out how it happened in this outrage-clickbait article to sell you some quack wellness supplements via a chumbox. 35,827 sold so far! Click now because supplies are almost gone!
A program written in C will execute faster if you run it multiple times, and slower if it has not been run recently. Presumably all of the benchmarks consist of many thousands of repetitions of the same process.
> The Go vs JavaScript lineup is quite stunning. Go destroys Node.js in memory usage and performance on every test except regex-redux (edge case?).
Why would it be stunning that a programming language compiled to assembler can beat a broken-by-design interpreted language which doesn't even have integers or arrays? The stunning part is that the people behind node.js have managed to get that much performance.
That's not a very fair or accurate description. JavaScript implementations use a JIT which is different than what people usually mean by interpreted. Types can be inferred without explicit type declarations. JavaScript has Array and integer semantics can also be inferred.
Ummmm, that's a somewhat harsh and arrogant reply. I actually enjoy coding in Node.js myself. I just wasn't aware how much faster go is (according to these benchmarks of course).
The JS language as specified is interpreted and doesn't have ints or first-class arrays; the code run by the VM that runs Node.js code is compiled and runs on smallints and arrays and so on.
(Not sure if you already knew this, but if so, you're not being factual, you're being selectively pedantic to make something sound worse than it is. Lack of ints or arrays isn't a big factor in JS performance for non-pathological cases.)
There's plenty to not like about JS, but being interpreted and not having integers or arrays is not high on its negatives list. The little bit of good far outweighs the whole lot of bad.
If you don't enjoy JS, it's because you haven't taken the time to learn what's great about it and have gotten hung up on the stupid things other people do with it or you're copying their mistakes.
> If you don't enjoy JS, it's because you haven't taken the time to learn what's great about it and have gotten hung up on the stupid things other people do with it or you're copying their mistakes.
oh come on now, it's perfectly ok for people to dislike a language for any number of reasons. I don't hate JS but I don't particularly enjoy it, and that could be said for a number of popular languages. it has nothing to do with "taking the time" to learn anything - some people just don't jive with JS and that's totally cool.
That last paragraph is a logical fallacy, because it posits that one's distaste for JavaScript could only come via ignorance. I will offer my own anecdotal experience to refute that assertion. I've been forced to use JavaScript since the 1990s, and have done significant amounts of work in Node for several companies. I dislike Node and JavaScript because JavaScript has a weak standard library, ugly syntax, is slow, is a pain to scale, and a pain to write complex code with. I will absolutely give credit to the Node community for improving JavaScript, in both speed and syntax, and admit that JavaScript is better now than it ever has been; however, so are most popular languages. Personally, I've removed JavaScript from my resume, and turn down jobs that use it. If I have to use it for some reason, I can, but right now, I typically avoid it altogether by using Elm, and real server-side languages on the backend. I can't speak for anyone else, but I know JavaScript and still don't like it.
I don't know, I rank not having integers pretty high on the list of faults. Wasn't there just a huge debacle with node being unable to represent inodes properly?
The inodes thing was about lack of 64-bit ints specifically. As I understand it, it was a bug where Node converted inode values to floats (instead of using strings or pairs of 32-bit ints or whatever). One could argue that the bug wouldn't have happened if JS had 64-bit ints, but anyway it's not a foundational thing.
The performance implication of JS not having ints is a different matter. In practice, if you write code that treats a variable like an int, modern JS engines will correctly compile that into bytecode where it really is an int, and performance will be as expected.
So the lack of an int type doesn't really hurt performance, though one can argue that it makes it harder to write performant code.
We're discussing programming language benchmarks. If one was forced to write all of a C or C++ or even Go program using only doubles, and not integers, and only hash tables, not arrays, undoubtedly it would become slower. The impressive thing about Node.js is that it is as fast as it is despite JavaScript not having integers or arrays.
No, we're not discussing language benchmarks anymore. The parent I replied to claimed that not having integers is not a big deal -- I disagree. It's a huge deal.
They go on to say:
> If you don't enjoy JS, it's because you haven't taken the time to learn what's great about it and have gotten hung up on the stupid things other people do with it or you're copying their mistakes.
Which is... wrong. Many, many programmers dislike JavaScript and node.js because of its flaws. I don't think Stockholm syndrome is an appropriate prescription.
I think you're in the right here, but that's a little too far. I don't enjoy programming in JS, because I really like strong typing. And that's ok. You seem to be implying that everyone who doesn't like JS is deluded or arrogant, but that's not the case.
> There's plenty to not like about JS, but being interpreted and not having integers or arrays is not high on its negatives list.
We are having a discussion is about programming language benchmarks.
A benchmark in this case is a measure of how fast a computer program can run. A computer program is a series of instructions for a computer. These instructions are written in something called a programming language. A programming language which is interpreted is inherently slower than a programming language which is compiled to assembly language. A programming language which does not have integers but must represent all numbers as floating point numbers is inherently slower than a programming language which has integers. A programming language which does not have arrays, but must represent arrays using hash tables, is inherently slower than a language which does have arrays. Thus, Node.js, which is interpreted and does not have arrays or integers, would be expected to be have much lower benchmarks than Go's, and yet node.js has exceptionally high performance.
I bought this book based on the endless internet recommendations. After reading it, I was mystified, completely mystified, why people recommended it so strongly.
Despite what the article says about Trump supporters being worried about climate change, this was a campaign pledge of Trump. So this, like the wall, is what people who voted for Trump actually voted for. Rather than blaming Trump, perhaps the voters should be blamed.
The whole thing is from the Silicon Valley TV show. I'm fairly sure that the two pillars are Sales and Engineering, but you're making me actually go watch Season Three all over again to find out if Barker referred to Growth and Manufacturing as pillars too. YouTube clips on that particular part of the series are sparse.
Edit: Yep, Barker refers to Engineering and Sales as the two pillars of success in S03E02, and Growth as the "foundation" of the CToS. Compromise is the "shared hypotenuse". Jack was fired before they could discuss Manufacturing.
https://www.youtube.com/watch?v=Gv5EQlzM1B8
https://www.youtube.com/watch?v=_7rF0wCSpE0
What happened, if you don't want to watch all the video, is that the aeroplane actually collapsed internally. In the second case, some of the passengers were sucked out of the plane.