And if C hasn't been invented alongside Unix, it would never have taken off either. Every popular language has a killer app, no exceptions. Conversely no language ever became popular without a killer app.
That JavaScript would never have become popular without its killer app is merely asserting a tautology.
Oh stop. When you spec out a project, you see where values would never exceed 256, so you use a byte, 16-bits for less than 65536, 32-bits for less than 4 billion, half these for signed values, etc. We all do this every day and twice on Sunday. If this were not the case, *all* numeric values in a system would always be 64-bit.
There are a huge number of cases where 4 billion would be constraining but 2^53 would be more than enough to avoid overflow. YouTube itself only had a 32-bit overflow for popular videos close to a decade after it launched. 2^53 would have covered them for millennia at that rate. Granted it was a database schema limitation in that case, but the point clearly holds.
It takes a while to roll over 9,007,199,254,740,992. If you absolutely need 64-bits (or 128-bits), then that's the spec and you pick the tool for the job. But don't let your blind hatred of JavaScript skip over the reality of our profession: sometimes even 2^8 is enough for some values. 2^53 is more than enough for most apps. Empirical evidence from the last 23 years strongly suggests my assertion to be true, purists such as yourself notwithstanding.
Coulda, shoulda, woulda. Most languages don't start out polished. You either break backward compatibility (and break literally millions of web sites) or you put in something like "use strict".
Languages that break compatibility get used as often as Lua, forever stuck at 5.1 with luajit or slow with 5.3.
Or you run into great gnashing of teeth and fracturing the community like Python's 2.7->3.0 transition.
Can't you just give credit where credit is due that web pages authored in 1995 still work? Phone apps written in 2013 can't even make that boast!
Mantissa doesn't lose information until 2^53, ie., a fairly large number. If you need to do 64-bit bitwise operations, absolutely, JavaScript is not the tool you want to use. Instead use a different language with different trade offs.:-)
It's amazing what you can accomplish when "constrained" to 2^53 (Number.MAX_SAFE_INTEGER). Sometimes a language is "good enough." Can't tell you how often I've wondered if something would work in Node and all I have to do is open of the dev console in Chrome to try it.
And the vast majority of people don't need numbers larger than 2^53. Don't get me wrong, I'm looking forward to using BigInt, but mostly for conversions to/from 64bit numbers. In actual usage, I rarely find 2^53 to be constraining.
I take that back; bitwise operations being limited to 32bits is a legitimate pain. Yet another reason I'm looking forward to working with BigInt.
And since you've invited us to the Slashdot pedant party, Node is written in C and C++. It *executes* JavaScript. Node is not "written" in JavaScript though most of its core modules contain JavaScript. Sockets: C. Process management: C. HTTP: mostly JavaScript, but completely dependent upon Buffer, which is a C interface to memory. Crypto: C.
Careful picking a technical fight about Node with a code contributor to Node.;-)
BigInt is the name of the *spec* that handles large numbers, of which so far V8 has implemented, so therefore available in newer builds of Chrome and Node.
There is no reason to believe Firefox and Edge will not follow suit shortly.
Apples and oranges. Dart was intended to be simply a "cleaner JavaScript" in the same vein as TypeScript. Too little too late though. JavaScript was sufficient. And I say sufficient because it's obviously used extensively. PHP is more extreme example of ugly but obviously usable since empirically it is widely used.
WebAssembly on the other hand is a compilation target, not something you would code yourself by hand. Rust-to-WebAssembly is an impressive combination IMHO that I hope to see a lot more of.
Technically I was just mocking Slashdot's inability to handle standard multibyte character encodings like UTF-8. Typically I would not recommend rewriting a working codebase simply to switch languages.
But since you brought it up, yes, I think in 2018 it would make more sense to write a web site in JavaScript than Perl. Go would be my choice for something where I would be looking at C but want internet-capable services.
Python is a (slightly) more elegant language, but the V8 engine eats the various Python VMs' lunches at this point in all relevant metrics: speed, memory usage, available libraries, and developer pool. (Python handily beats JS for machine learning and finance though due to available libraries.)
For something like Slashdot, I think Java is unnecessary. There isn't a whole lot of business logic needed in the middleware, and this is where Java shines.
Node is more than sufficient to handle the likes of Slashdot, though honestly algorithm trumps language every day of the week and twice on payday.
And yes, I have coded all of them at one time or another in a professional capacity.
But back to my original point: it's 2018 and therefore laughable that any website lacks end-to-end Unicode support.
"Imagine if Google had created node.js first, and all browsers were using some other language like Python."
LOL! That's some interesting time travel you've got there! Chrome forked from WebKit (forked from KHTML) in what? Late 2000s? Google didn't even make Node.js! But let's say they did, for the sake of argument. That still leaves over 10 years of JS in the browser. (Hello, Netscape 2.0 Gold Beta!)
Python would have been a non-starter because Sun wanted Netscape to make a scripting language that superficially looked like Java.
And if it hadn't been JS, it would have been Microsoft's VBScript? You old enough to remember that? That was the other likely option at the time. Believe me when I say JS was the far superior option and no other realistic options were on the table.
That said, ES2017 is quite nice. Quite pythonic actually. Also, unlike Python, JavaScript written in 1995 still works today. Don't get me wrong, I like Python too, but it was never gonna happen. Best to let it go and move on.
is still useful. Covers null, undefined, and empty string. The Google JS programming style guide actually forbids triple equal comparisons with null.
But feel free to continue on your rant, especially since BigInt already landed in V8 and is available in the newest builds of Node. You seem to be on a roll.
Why would you turn strict mode off mid-way through a file or function?
Fun fact: "use strict" was derived from Perl, the language Slashdot is written in.
Fun fact #2: JavaScript is also used on the server side where script tag hacks are unnecessary.
Fun fact #3: The vast majority of folks don't specify version anymore. No point really with current browser usage. Perhaps your knowledge of JavaScript is out of date?
Wow! 2018 and Slashdot still can't handle simple Unicode like ellipses. No combining characters, just a simple two-byte UTF-8 sequence.
Too bad it was written in Perl and not JavaScript.:-D
(Yes, I know Perl supports Unicode now. Yes, I know server-side JavaScript only existed as Netscape's proprietary LiveScript at the time. But it's been 20 years. Talk about living in the past. Can I even do a Euro character? Are they still on ISO-8859-1 or have at least updated to ISO-8859-15?)
I think you mean "strictly," not "strongly."// JavaScript let foo = 'bar';// not strict typeof(foo) === 'string';// strong// C int blah = 5;// strict void *glarb = blah;// not strong
Aside from that, you're still wrong.:-) Languages are for people to understand and write, not computers. People can (and do) write more lines of code with JS and Python nowadays than in C even though fewer lines of code are necessary than the equivalent C. They're getting more done. Harkening back to "good old days" that never existed doesn't help anyone, nor prove you're a better coder.
And I'm old enough to remember people who were still skeptical of C because assembly didn't hide anything from you. Feel free to find your way clear of my grass frontage.
Its market share may be very low now, but isnâ(TM)t it worth it to evaluate a security profile based strongly on privacy? Wouldnâ(TM)t many hacks be mitigated by virtue of the same code that blocks tracking, ads, and fingerprinting?
As opposed to in the past where it exclusively meant giving jobs, housing, and education to unqualified whites at the expense of the qualified non-white.
Perhaps you've seen the news lately where unarmed (and often cooperating) black folks have been killed by police *on video* in a markedly different way than their official report says, and the officers have more often than not been cleared of any criminal prosecution.
Maybe making notable changes to a society that allows that to happen regularly could be a first step toward black folks "getting over it"?
Jewish = religious tradition and linguistic, cultural, and historical heritage Polish = linguistic, cultural, and historical heritage Native American = too vague without tribe
Now let's look at black folks in general in the US. Religion? Tossed aside and forced to convert to Christianity. Some small vestiges eake by in voodoo. Language before slavery? Tossed aside and forcibly forgotten while simultaneously forbidding English education and literacy. Cultural memory before slavery? Eradicated. History before slavery. Erased.
We say "African American" because you have a huge swath of people that have no idea what country their ancestors came from, no idea what tribe, no idea the heritage, no idea the lineage, no idea the cultural connections...
Imagine forcing people to forget their families were Irish or Polish or Russian or French. Imagine no idea they came from Christian or Jewish communities. And all records from the time destroyed so that you have no hope of ever finding out. Ever. Your ancestral history? Gone. Poof.
No tell me again how you don't see any difference.
So you're saying your family, upbringing, and sense of personal and cultural history while in China had absolutely nothing to do with your later success? Good to know.
You refer to "merit" as though it can be objectively measured. If you look closely, you'll find non-trivial biases in that so-called meritocracy. And those biases curiously always seem to favor the ones that are already on top. Funny that.
Slashdot Mirror
And if C hasn't been invented alongside Unix, it would never have taken off either. Every popular language has a killer app, no exceptions. Conversely no language ever became popular without a killer app.
That JavaScript would never have become popular without its killer app is merely asserting a tautology.
Oh stop. When you spec out a project, you see where values would never exceed 256, so you use a byte, 16-bits for less than 65536, 32-bits for less than 4 billion, half these for signed values, etc. We all do this every day and twice on Sunday. If this were not the case, *all* numeric values in a system would always be 64-bit.
There are a huge number of cases where 4 billion would be constraining but 2^53 would be more than enough to avoid overflow. YouTube itself only had a 32-bit overflow for popular videos close to a decade after it launched. 2^53 would have covered them for millennia at that rate. Granted it was a database schema limitation in that case, but the point clearly holds.
It takes a while to roll over 9,007,199,254,740,992. If you absolutely need 64-bits (or 128-bits), then that's the spec and you pick the tool for the job. But don't let your blind hatred of JavaScript skip over the reality of our profession: sometimes even 2^8 is enough for some values. 2^53 is more than enough for most apps. Empirical evidence from the last 23 years strongly suggests my assertion to be true, purists such as yourself notwithstanding.
Coulda, shoulda, woulda. Most languages don't start out polished. You either break backward compatibility (and break literally millions of web sites) or you put in something like "use strict".
Languages that break compatibility get used as often as Lua, forever stuck at 5.1 with luajit or slow with 5.3.
Or you run into great gnashing of teeth and fracturing the community like Python's 2.7->3.0 transition.
Can't you just give credit where credit is due that web pages authored in 1995 still work? Phone apps written in 2013 can't even make that boast!
Mantissa doesn't lose information until 2^53, ie., a fairly large number. If you need to do 64-bit bitwise operations, absolutely, JavaScript is not the tool you want to use. Instead use a different language with different trade offs. :-)
It's amazing what you can accomplish when "constrained" to 2^53 (Number.MAX_SAFE_INTEGER). Sometimes a language is "good enough." Can't tell you how often I've wondered if something would work in Node and all I have to do is open of the dev console in Chrome to try it.
Perfect is the enemy of good.
And the vast majority of people don't need numbers larger than 2^53. Don't get me wrong, I'm looking forward to using BigInt, but mostly for conversions to/from 64bit numbers. In actual usage, I rarely find 2^53 to be constraining.
I take that back; bitwise operations being limited to 32bits is a legitimate pain. Yet another reason I'm looking forward to working with BigInt.
Such as?
It *is* a keyword. They however are calling typeof(...), which by contract *always* returns a string.
And since you've invited us to the Slashdot pedant party, Node is written in C and C++. It *executes* JavaScript. Node is not "written" in JavaScript though most of its core modules contain JavaScript. Sockets: C. Process management: C. HTTP: mostly JavaScript, but completely dependent upon Buffer, which is a C interface to memory. Crypto: C.
Careful picking a technical fight about Node with a code contributor to Node. ;-)
BigInt is the name of the *spec* that handles large numbers, of which so far V8 has implemented, so therefore available in newer builds of Chrome and Node.
There is no reason to believe Firefox and Edge will not follow suit shortly.
Apples and oranges. Dart was intended to be simply a "cleaner JavaScript" in the same vein as TypeScript. Too little too late though. JavaScript was sufficient. And I say sufficient because it's obviously used extensively. PHP is more extreme example of ugly but obviously usable since empirically it is widely used.
WebAssembly on the other hand is a compilation target, not something you would code yourself by hand. Rust-to-WebAssembly is an impressive combination IMHO that I hope to see a lot more of.
Technically I was just mocking Slashdot's inability to handle standard multibyte character encodings like UTF-8. Typically I would not recommend rewriting a working codebase simply to switch languages.
But since you brought it up, yes, I think in 2018 it would make more sense to write a web site in JavaScript than Perl. Go would be my choice for something where I would be looking at C but want internet-capable services.
Python is a (slightly) more elegant language, but the V8 engine eats the various Python VMs' lunches at this point in all relevant metrics: speed, memory usage, available libraries, and developer pool. (Python handily beats JS for machine learning and finance though due to available libraries.)
For something like Slashdot, I think Java is unnecessary. There isn't a whole lot of business logic needed in the middleware, and this is where Java shines.
Node is more than sufficient to handle the likes of Slashdot, though honestly algorithm trumps language every day of the week and twice on payday.
And yes, I have coded all of them at one time or another in a professional capacity.
But back to my original point: it's 2018 and therefore laughable that any website lacks end-to-end Unicode support.
"Imagine if Google had created node.js first, and all browsers were using some other language like Python."
LOL! That's some interesting time travel you've got there! Chrome forked from WebKit (forked from KHTML) in what? Late 2000s? Google didn't even make Node.js! But let's say they did, for the sake of argument. That still leaves over 10 years of JS in the browser. (Hello, Netscape 2.0 Gold Beta!)
Python would have been a non-starter because Sun wanted Netscape to make a scripting language that superficially looked like Java.
And if it hadn't been JS, it would have been Microsoft's VBScript? You old enough to remember that? That was the other likely option at the time. Believe me when I say JS was the far superior option and no other realistic options were on the table.
That said, ES2017 is quite nice. Quite pythonic actually. Also, unlike Python, JavaScript written in 1995 still works today. Don't get me wrong, I like Python too, but it was never gonna happen. Best to let it go and move on.
Fun fact #4:
if (foo == null) // double equals
is still useful. Covers null, undefined, and empty string. The Google JS programming style guide actually forbids triple equal comparisons with null.
But feel free to continue on your rant, especially since BigInt already landed in V8 and is available in the newest builds of Node. You seem to be on a roll.
Why would you turn strict mode off mid-way through a file or function?
Fun fact: "use strict" was derived from Perl, the language Slashdot is written in.
Fun fact #2: JavaScript is also used on the server side where script tag hacks are unnecessary.
Fun fact #3: The vast majority of folks don't specify version anymore. No point really with current browser usage. Perhaps your knowledge of JavaScript is out of date?
Wow! 2018 and Slashdot still can't handle simple Unicode like ellipses. No combining characters, just a simple two-byte UTF-8 sequence.
Too bad it was written in Perl and not JavaScript. :-D
(Yes, I know Perl supports Unicode now. Yes, I know server-side JavaScript only existed as Netscape's proprietary LiveScript at the time. But it's been 20 years. Talk about living in the past. Can I even do a Euro character? Are they still on ISO-8859-1 or have at least updated to ISO-8859-15?)
"â¦still slowâ¦"
[citation needed]
I think you mean "strictly," not "strongly." // JavaScript // not strict // strong // C // strict // not strong
let foo = 'bar';
typeof(foo) === 'string';
int blah = 5;
void *glarb = blah;
Aside from that, you're still wrong. :-) Languages are for people to understand and write, not computers. People can (and do) write more lines of code with JS and Python nowadays than in C even though fewer lines of code are necessary than the equivalent C. They're getting more done. Harkening back to "good old days" that never existed doesn't help anyone, nor prove you're a better coder.
And I'm old enough to remember people who were still skeptical of C because assembly didn't hide anything from you. Feel free to find your way clear of my grass frontage.
Its market share may be very low now, but isnâ(TM)t it worth it to evaluate a security profile based strongly on privacy? Wouldnâ(TM)t many hacks be mitigated by virtue of the same code that blocks tracking, ads, and fingerprinting?
Worth a shot at least.
What do you use for continuous integration? And what language is it written in? And how does that language make it better than Jenkins?
As opposed to in the past where it exclusively meant giving jobs, housing, and education to unqualified whites at the expense of the qualified non-white.
Perhaps you've seen the news lately where unarmed (and often cooperating) black folks have been killed by police *on video* in a markedly different way than their official report says, and the officers have more often than not been cleared of any criminal prosecution.
Maybe making notable changes to a society that allows that to happen regularly could be a first step toward black folks "getting over it"?
Jewish = religious tradition and linguistic, cultural, and historical heritage
Polish = linguistic, cultural, and historical heritage
Native American = too vague without tribe
Now let's look at black folks in general in the US. Religion? Tossed aside and forced to convert to Christianity. Some small vestiges eake by in voodoo. Language before slavery? Tossed aside and forcibly forgotten while simultaneously forbidding English education and literacy. Cultural memory before slavery? Eradicated. History before slavery. Erased.
We say "African American" because you have a huge swath of people that have no idea what country their ancestors came from, no idea what tribe, no idea the heritage, no idea the lineage, no idea the cultural connections...
Imagine forcing people to forget their families were Irish or Polish or Russian or French. Imagine no idea they came from Christian or Jewish communities. And all records from the time destroyed so that you have no hope of ever finding out. Ever. Your ancestral history? Gone. Poof.
No tell me again how you don't see any difference.
So you're saying your family, upbringing, and sense of personal and cultural history while in China had absolutely nothing to do with your later success? Good to know.
You refer to "merit" as though it can be objectively measured. If you look closely, you'll find non-trivial biases in that so-called meritocracy. And those biases curiously always seem to favor the ones that are already on top. Funny that.