My own experience with JS is that it's not a very well designed language. You only like it because it gives you functionality you want, not because it is inherently a good thing on it's own. If somehow Perl or Brainfuck were the client side language-of-choice, you wouldn't care one whit for JS. It's just that I've already looked ahead that far, and decided that if there's something better (which shouldn't be too hard), I'd dump JS in a New York minute.
-QM
--
Quantum Mechanics: The dreams stuff is made of
| [reply] |
"My own experience with JS is that it's not a very well designed language. You only like it because it gives you functionality you want, not because it is inherently a good thing on it's own. If somehow Perl or Brainfuck were the client side language-of-choice, you wouldn't care one whit for JS."
Yes, that's true.
I would add just one important detail. The precise reason why I love JS is not just because it gives me the functionality but it gives me the functionality ON ALL DEVICES. It's not enough to have another language that is better or gives more functionality than JS.
What makes JavaScript supreme is that it runs on all devices. Pick any device. The oldest smartphone I have from the stone age can run JavaScript. I remember, even Windows 95 had JavaScript running in the web browser. So, that's what makes it stand out. If you know how to program in JavaScript, you can program anything. Even smartwatches run JavaScript. Tesla's model S cars have a big screen with a web browser that runs JavaScript. Some refrigerators now come equipped with a computer screen and web browser which runs JavaScript. That's why why JS rules.
| [reply] |
> you cannot do in JS like accessing the file system,
node.js
> if only it had adopted the vec() function from perl.
Seriously? Please elaborate!
JS has Bitwise Operators.
Hence simulating vec - if not available otherwise - is no problem.
| [reply] |
Yeah, node.js, that's true... But that's when JS is running on the server. Normally, in most cases, JS is running on the client side inside the web browser. And when you're inside the web browser, you cannot access the local file system.
Of course, in Windows, there is a way to read/write files with JavaScript using the FileSystemObject. So, I am well aware that JavaScript can be used to access the file system BUT NOT when you run it within a web browser!
(Pros: If you want to read the directory structure or open files from a NTFS file system, you may notice that JavaScript automatically reads file and folder names in Unicode format, which is neat! In perl, working with special characters in file names in Windows is a pain.
Cons: If you find yourself using JavaScript to work with files, you'll realize that the only way to read a file is to read the ENTIRE file, which is kind of dumb. Sometimes you don't want to read the entire file into memory, but JavaScript gives you no other option.)
The vec() function in perl allows a programmer to modify one character of a giant string by overwriting the string. Example: vec($a, 20000, 8) = 32; In perl, this operation is extremely fast, because all you do is modify one byte in the memory.
But in JavaScript, if you have a very long string and want to replace the 20000th character, you would have to use substring() function to cut the string into two parts and then join the parts together with a space character in the middle.
In other words, in the background, the JavaScript interpreter makes a copy of your entire string. And then from this copy, it creates another copy which contains the new modified character. So, instead of just replacing ONE character in the memory, it ends up copying the entire string twice. From a performance perspective, this is very-very poor design. And it's all because JavaScript does not have a vec() function. For this reason, JavaScript is like a baby toy.
When programmers MUST overwrite a character of a long string quickly, they usually split the string into an array, and that way they can manipulate the individual characters. And when they are done editing, they can join the array into a string. Fortunately, array operations are extremely fast in JavaScript, so this works pretty well. Except, from a resource management perspective, this isn't pretty, because JavaScript uses 22 bytes in the memory to store one element of an array. So, if you have a string that is 100,000 bytes long, and you split it into an array. It will then take up an additional 2 megabytes of memory. So, you wanted to modify one byte, and you ended up writing 2 million bytes to memory. Only because you wanted to change ONE byte in a string.
That's why they say, if JavaScript was a car, it would be a big version of Little Tikes toy car.
| [reply] |
| [reply] |
Point is that strings in JS are immutable.
That's not a poor design decision but helps to better optimize the compiler.
Perl's way to represent large data blobs in strings surprised me when I first saw it. IMHO this has large implications on character representation and the need for utf8 flags.
If JS wanted to support memory manipulation with peek and poke it could just implement a special object.
Anyway using an array of bytes is already fast enough for your needs.
Btw: You didn't say browser before, if Perl was running inside the browser it wouldn't have file access either.
In general you should be careful with bold assumptions written in bold letters.
| [reply] |