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] |
