The most startling of these is his spelling of "one" – yes, yes that Kelly's eye, that ineffectual multiplier, that name Prince Charles calls himself – which he, Crockford, insists on rendering "wun". Over and over again. With all the adorable variations tossed in for free: somewun, anywun, no wun, I wunce wrote a constructor, wunth and, brace yourself for it, twoth.
This is quite annoying and distracting, but no more so than an economy-class, transatlantic flight in a cramped, middle-aisle seat in front of a poorly disciplined ADD boy-child whose seatback kicks are Poisson-distributed with Lambda around 4.7 per minute.
I am sure I have seen that spelling "wun" before, in the writings of Daisy Ashford, Alan Alexander Milne, or some other whimso children's author. We have waved "buh-bye" to the wild worldwide web. We have touched down in the Wun Hundred Acre Wood.
Bjarne Again: Hallelujah for C++READ MORE
Eeyore's Gloomy Place
A decade on, thanks in large part to Crockford's contributions, the language's importance has increased n-fold. One consequence of this: of recent times, the language has suffered serial tampering, culminating in annual revisions to its standard. Good Parts has fallen obsolete.
- Callbacks, promises and async/await – i.e. all three code-sequencing structures used by Node.js programmers ancient and modern. These Crockford styles as "the three mistakes"
- ES6 generators ("added during the time when the standards process suffered from serious Python envy". Crockford's code snippet demonstrating an alternative looks so much neater and slicker, it should have the standards committee jointly slapping their foreheads and crying "D'oh!")
- Rethrown exceptions ("a terrible practice that C++ made popular")
- The fat arrow
=>("Farts [sic] are an abbreviated way of writing functions". Given reasons for dislike: a problem with ambiguous braces when using a fat arrow to return an object, and the danger of confusing it with
classkeyword ("The coders using
classwill go to their graves never knowing how miserable they were")
There are some newer JS features that receive a warmer welcome: the
Array.reduce method is rated as "kind of brilliant". But such enthusiasm is spent frugally.
Incidentally, the TypeScript language, the current toast of many of those fashionable React kids, Node-inventor Ryan Dahl, and indeed myself, is not mentioned. Given Mr Crockford's stated low opinion of type-safety ("Types can induce us to embrace cryptic, intricate, and dubious coding practices") and his italicised advice "Transpilers should never be used in production", I think we can safely assume that TypeScript is firmly buried in his "crap" pile. Boo hoo.
Tigger bounces in
The book is by no means all gloom and doom; rather it is gloom and remedy.
0.1 + 0.2 === 0.3 // false, obvs
so it is reasonable of Crockford to highlight it. (On the other hand, I suspect his report of this wrinkle
(1 / 0) === (1 / -0) // also false
is there just to amuse readers. Works for me.)
The next bit is smart: disapproving of a standard proposal to supplement
number with a
BigInt, he takes the bottom 24 bits of the ordinary doubles and tortures them into becoming the basis of an arbitrary-precision integer library. Not satisfied with this, he extends his integer library to make a "big floating point" library – cunningly fashioned so that tenths add up properly – and then takes it even further to create a "big rational" library that works with fractions, however vulgar.
It's all very ingenious... but building a model of the SS Titanic out of spent Vestas is ingenious too. And one worries about performance (of the arithmetic, not the matches). There again, my data sources rarely give me as many as 14 bits of precision on a sunny day; I dare say those doing financial calcs will be properly grateful.
This general approach sets the template: identify a problem in the language, then supply a workaround.
...but I'm not convinced the workaround is always needed. "Requestors" are the Crockford alternative to Node.js's callbacks, promises and async/await functions. That the first two are problematic is uncontroversial; but Crockford's objection to async/await, as I understand it, is that it conceals its underlying mechanism from its users, who consequently don't understand its workings.
This sounds to me like the old argument, long ago advanced by the pipe-smoking and leather elbow patch generation, that nobody should be allowed to use C until he or she has mastered Z80 assembly. I am not buying it. Also, miserable conservative that I am, I find myself reluctant to pioneer a fourth callback mechanism when my codebase is already riddled with a confusing mixture of the other three.
A much more promising innovation is JSCheck, a powerful variation on the usual unit testing framework. Instead of obliging the programmer to write tests one tedious
assertEquals() at a time according to the lumpen prescription of the TDD crowd, JSCheck tests are configured using predicate functions that signal true when the results are good. When activated, the target code is bombarded with auto-generated random values. It looks much more like fuzzing than conventional unit tests, and I am looking forward to trying it in anger.
 ==  // false  == ! // true
provide hours of fun for the kids.
Tonstant Weader Doesn't Fwow Up
Crockford has always been cheerfully iconoclastic, and he has always followed the Third Doctor's dictum about being serious of purpose, if not approach.
These are admirable qualities, but the unrelenting jokiness tends to fog the lens. He could do with an editor. My services are available, and are astonishingly good value. If taken up, I'll fix wun problem at wunce. ®
Verity Stob is the pseudonym of a software developer based in London. Since 1988, she has written her "Verity Stob" column for .EXE magazine, Dr. Dobb's Journal and, since 2002, The Register.
Sponsored: Webcast: Simplify data protection on AWS