For roughly the past seven years that I've been doing NESdev, I have written data conversion and source code preprocessing tools in Python because I can get them working faster than if I had written them in C++. These tools include PNG to CHR, PNG+palette to CHR+NAM, Pently's MML-like language to ca65 assembly, source code shuffling to add buffer overflow canaries and make prototype leaks traceable, and NESASM assembly to ca65 assembly for Action 53. But I try to keep my options open.
I'm curious about the advantages of JavaScript over Python. Pip vs. NPM looks like a wash as far as I can tell, but I have a couple concerns.
One is more practical. I imagine that more people have Python installed than Node, though Windows comes with neither. It does come with Windows Script Host (cscript.exe), which interprets a JavaScript dialect called JScript, but the standard libraries bundled with Node and WSH are incompatible in several ways. For example, reading files in Node looks nothing like reading files in JScript. So any command-line program to be used by a wide audience would have to wrap both Node's I/O and WSH's I/O.
Crockford rant ahead
Another is whether Douglas Crockford, author of the JSON spec and JavaScript: The Good Parts, cautions against using bitwise operations in JavaScript, which if followed would limit its use for data conversion tools. The &, |, <<, and >>> operators are mentioned only in the chapter "The Bad Parts":
JSLint, Mr. Crockford's static analysis tool to enforce some conventions described in The Good Parts, has a "tolerate bitwise operators" checkbox that defaults off. In its manual, he defends this similarly: "The bitwise operators are rarely used in JavaScript programs, so it is usually more likely that & is a mistyping of && than that it indicates a bitwise and."
But then Mr. Crockford is known for being opinionated. JSLint has no options to control indentation style other than "tolerate whitespace mess". In particular, its requirement of 4-space indentation is incompatible with the 2-space indentation to which Firefox Scratchpad defaults. (You can't change the indent level from within Scratchpad; the setting is more hidden. You have to open the developer tools on a web page, click the gear, and scroll down to "Editor Preferences". The page about Scratchpad doesn't even mention it; it mentions only the ability to enable Emacs or Vim key bindings. But perhaps this ire should be on Bugzilla, not here.) It used to have an indent level option, but Mr. Crockford removed it in this change that diff thinks is a complete rewrite, and he closes feature requests to reintroduce it within hours without comment. And he puts a vague and non-free field of use restriction "The Software shall be used for Good, not Evil." in the modified MIT license used for his JSON reference implementation and for JSLint.
Is it wisest A. to ignore some of Mr. Crockford's axes to grind, B. to use a language other than JavaScript for data conversion tools, or C. to exercise a third option that you are about to describe?
In this post, zzo38 wrote:
(I myself prefer JavaScript as scripting language of choice, but that is just my opinion and you can use Python if you prefer to.)
I'm curious about the advantages of JavaScript over Python. Pip vs. NPM looks like a wash as far as I can tell, but I have a couple concerns.
One is more practical. I imagine that more people have Python installed than Node, though Windows comes with neither. It does come with Windows Script Host (cscript.exe), which interprets a JavaScript dialect called JScript, but the standard libraries bundled with Node and WSH are incompatible in several ways. For example, reading files in Node looks nothing like reading files in JScript. So any command-line program to be used by a wide audience would have to wrap both Node's I/O and WSH's I/O.
Crockford rant ahead
Another is whether Douglas Crockford, author of the JSON spec and JavaScript: The Good Parts, cautions against using bitwise operations in JavaScript, which if followed would limit its use for data conversion tools. The &, |, <<, and >>> operators are mentioned only in the chapter "The Bad Parts":
In Java, the bitwise operators work with integers. JavaScript doesn't have integers. It only has double precision floating-point numbers. So, the bitwise operators convert their number operands into integers, do their business, and then convert them back. In most languages, these operators are very close to the hardware and very fast. In JavaScript, they are very far from the hardware and very slow. JavaScript is rarely used for doing bit manipulation.
As a result, in JavaScript programs, it is more likely that & is a mistyped && operator. The presence of the bitwise operators reduces some of the language's redundancy, making it easier for bugs to hide.
JSLint, Mr. Crockford's static analysis tool to enforce some conventions described in The Good Parts, has a "tolerate bitwise operators" checkbox that defaults off. In its manual, he defends this similarly: "The bitwise operators are rarely used in JavaScript programs, so it is usually more likely that & is a mistyping of && than that it indicates a bitwise and."
But then Mr. Crockford is known for being opinionated. JSLint has no options to control indentation style other than "tolerate whitespace mess". In particular, its requirement of 4-space indentation is incompatible with the 2-space indentation to which Firefox Scratchpad defaults. (You can't change the indent level from within Scratchpad; the setting is more hidden. You have to open the developer tools on a web page, click the gear, and scroll down to "Editor Preferences". The page about Scratchpad doesn't even mention it; it mentions only the ability to enable Emacs or Vim key bindings. But perhaps this ire should be on Bugzilla, not here.) It used to have an indent level option, but Mr. Crockford removed it in this change that diff thinks is a complete rewrite, and he closes feature requests to reintroduce it within hours without comment. And he puts a vague and non-free field of use restriction "The Software shall be used for Good, not Evil." in the modified MIT license used for his JSON reference implementation and for JSLint.
Is it wisest A. to ignore some of Mr. Crockford's axes to grind, B. to use a language other than JavaScript for data conversion tools, or C. to exercise a third option that you are about to describe?