Profile cover photo
Profile photo
Douglas Crockford
19,746 followers -
_ __ ___ ____ _____ In the Twenty First Century!
_ __ ___ ____ _____ In the Twenty First Century!

19,746 followers
About
Douglas's interests
Douglas's posts

Post has attachment
Consider this fragment of crap code:

if ( ++p == pe )
goto _test_eof;

* ++
* goto
* missing {}
* dangling _
* major security exploit

Quality matters.

Post has shared content
More computing sins are committed in the name
of efficiency (without necessarily achieving it)
than for any other single reason--including blind
stupidity.

William A. Wulf

More computing sins are committed in the name
of efficiency (without necessarily achieving it)
than for any other single reason--including blind
stupidity.

William A. Wulf

Post has attachment
JSLint currently allows two conventions of indentation.

There is the closed form, where you can break a line pretty much anywhere and indent the continuation 8 space.

a = method(b,
c, d);

And there is the open form in which you break after ( { or [, and the closing ) } or ] will be aligned with the beginning of the thing, and the stuff in between is indented 4. It generalizes the K&R block convention to object literals, array literals, and parameter/argument lists.

a = method(
b,
c,
d
);

I have been receiving complaints that JSLint should not like the old closed form. What say you?
42 votes
-
votes visible to Public
36%
Allow both forms
64%
Allow only the open form

Both cannot and can not are acceptable spellings, but the first is much more usual.

But hasnot is not acceptable while has not is. And willnot is not acceptable while will not is.

That is why I can not use cannot.

But if I am in a great hurry, I can still can't.

Post has attachment
The classes as closures pattern that I have been advocating for JavaScript was anticipated in 1982 by Ian Currie in In Praise of Procedures.

Post has attachment
APL and C did not have a boolean type. They used 0 and 1 as false and true. More recent languages provide a boolean type as a preventative for certain classes of errors. JavaScript tries to have it both ways with its falsy values, which adds complexity but with none of the error avoidance.

So imagine a machine which used 0 and 1 to represent false and true. Also, a condition must evaluate to exactly 0 or 1, otherwise an exception is raised. This would permit the APL idioms while also providing some error avoidance.

In designing a programming language specifically for this machine, should a boolean type be provided?
100 votes
-
votes visible to Public
70%
Yes
30%
No

Post has attachment
I will be in Singapore tomorrow.

Post has attachment

Conventional programming languages are growing ever more enormous, but not stronger. Inherent defects at the most basic level cause them to be both fat and weak: their primitive word-at-a-time style of programming inherited from their common ancestor--the von Neumann computer, their close coupling of semantics to state transitions, their division of programming into a world of expressions and a world of statements, their inability to effectively use powerful combining forms for building new programs from existing ones, and their lack of useful mathematical properties for reasoning about programs.

-- John Backus, Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs, 1978.
Wait while more posts are being loaded