ruricolist

With the obvious proviso that by the time you graduate said career path may no longer exist.

I dispute the basic narrative here. If you have tail calls, you have GOTO. If you have closures, you have pointers. The story (so far) is not one of features disappearing, but of features being subsumed by other more general, abstract features.

Had the author bothered to read Livio's book, he might appreciate that the reason it is so easy to see the golden ratio in designs is not DNA, but math: anytime you divide a measurement into two parts, one larger than the other, the ratio of the larger part to the whole is always closer to the golden ratio than the direct ratio of the smaller part to the larger part.

In some cases, yes.

If you are committed to doing everything in JS, then you have two choices:

1. Deliver a degraded experience to modern browsers and a terrible experience to older browsers.

2. Deliver a good experience to modern browsers and no experience at all to older browsers.

Depending on your business model, #1 may be the best choice. But if you're trying to compete with native apps then #2 is the only thing that makes sense.

Why browser compatibility? Why polyfills?

I don't understand the logic that goes from "Modern browsers with fast JS engines make fancy web apps practical" to "let's make sure our fancy web apps run in old browsers with slow JS engines."

I was just thinking to myself the other day that the danger of actually taking the time to write something thoughtful and cogent the days is that once you have convinced the intelligent, open-minded readers, that leaves everyone else to write comments. Which means when people come to look at the article in the future, and skip to the comments to get a sense of what kind of reaction people had, they get precisely the wrong impression.

This is an interesting article. It's not a "think piece" about writing "these days". It's a serious attempt to understand just what "public intellectuals" were in the first place, what conditions made them possible, and what part of that, if any, can be revived, or is worth reviving.

He might be completely wrong. But he deserves a little better than TL;DR because he dared to write above the eighth grade level.

See The Chess Variants Pages (http://www.chessvariants.org) for other historic chess variants, such as chaturanga (the original), Tamerlane chess (like shatranj with extra pieces and a larger board), and Byzantine chess (played on a cicular board!).

Now I understand why I was never able to find out anything about where my great-grandfather came from -- very likely it was one of those little villages that were simply wiped out.

About wheelbarrows: the Western wheelbarrow isn't unoptimized, it's just optimized for a different purpose: loading instead of moving. Having the wheel at the front allows for a deep body with low sides, which makes it easier to fill (and empty) the wheelbarrow with a shovel.

This recipe, like the original, suffers from a bizarre lack of bacon grease.

There's an excellent paper on how to build list comprehensions (in Common Lisp) on top of simpler iteration constructs:

http://www.ai.sri.com/~latendre/listCompFinal.pdf

I have a (very loose) implementation of this approach at:

https://github.com/TBRSS/cl-lc

Frankly, though, once you've learned the trick, list comprehensions lose a lot of their appeal.

I remember this piece being better. Now it seems rather glib. As someone who programs mostly in Lisp, I think I’ve learned more from studying array languages than from anything else outside of Lisp. Implementing a handful of functions and declaring APL “absorbed” is silly.

This used to be a big problem in astronomy, before the introduction of computers. Astronomers would use a special device, called a "blink comparator", to rapidly switch between two pictures so they could see the changes between them. (This is how Pluto was discovered.)

I haven't found that to be the case. I don't mean that Clozure's performance is bad, but optimizing numeric code is SBCL's reason for being. When I switched from SBCL to Clozure, I had to move things like password hashing out of Lisp, because I couldn't get acceptable performance out of Ironclad.

To be fair, the compiler is more than a bit more primitive. Clozure doesn't come close to SBCL where numeric code is concerned. But the garbage collector really is much better, especially under heavy concurrency.

I imagine people who are interested in this would also be interested in the Silk Road Gourmet: www.silkroadgourmet.com. Everything from Babylonian recipes to reconstructions of Roman fish sauce.

In working on TBRSS, which is intended as a technical solution to the problem of the fast web, I have increasingly come to suspect that it is, in the social sense, much too late. There is an entire generation of people out there to whom twitchy connectivity is simply the norm, to whom the idea of not having a button to hit or a prompt to answer every few minutes is actually frightening.

Is this a satire? I mean this seems like a satire of the fact that the unfortunate framing of functional programming in terms of "purity" and "impurity" clouds a very abstract question with the intense instinctive reactions we have to questions of personal hygiene. Notwithstanding the fact that a programming language is "impure", you cannot catch anything from it. It cannot defile, pollute, or contaminate you. Nor is there any power that will reward you in this world or the next for your supererogatory devotion to "purity" in programming.

For the record, exactly such a library already exists: http://common-lisp.net/~frideau/lil-ilc2012/lil-ilc2012.html

Although the specific problem of state-with-backtracking would be more idiomatically solved with dynamic binding.

One could make the argument (I think so, at least) that if the number of associations you are dealing with is small enough to write out literally, then using a hash table is a mistake. It might be one of Common Lisp's strengths that is has ways to represent small tables efficiently and thus avoids the "hash addiction" that haunts languages where hash tables are used for everything.

But even if a more compact way of constructing hash tables is called for, why a literal syntax instead of a more compact constructor? E.g. you could write

    (dict "name" "andrew" "location" "sf")

with a compiler macro that produces exactly the above code.

The tricky thing with all of these (pjax &c.) is that by loading with JavaScript, you lose progressive rendering, so while reducing latency you may actually lose perceived speed.

There is one very strong practical justification for pseudonyms: some people have very common names. There are thousands of people named Paul Rodriguez, probably hundreds named Paul M. Rodriguez, but there is only one person who goes by "ruricolist". To the extent that I have one, my nickname is my reputation.

Unfortunately this doesn't work for programming, because in programming we never really know in advance how long anything is going to take, not even within an order of magnitude: a five-day problem looks just like a five-minute problem until it's over. It's the worst thing about programming, the lack of granularity, and why we're always staying up much too late.

Any specific complaints?

The boldest of the officers resumed speaking. 'That one ship is ninety million miles long, Your Highness. It shimmers like fire, but moves so fast that we cannot approach it. But it came into the center of our fleet almost touching our ships, stayed there twenty or thirty thousandths of a second. There it was, we thought. We saw the evidence of life on board: light beams waved; they examined us and then, of course, it lapsed back into nonspace. Ninety million miles, Your Highness. Old Earth has some stings yet and we do not know what the ship is doing.'

[...]

The cabin was small, twenty feet by thirty. The control area of the ship measured nothing over a hundred feet. All the rest was a golden bubble of the feinting ship, nothing more than thin and incredibly rigid foam with tiny wires cast across it so as to give the illusion of a hard metal and strong defenses. The ninety million miles of length were right. Nothing else was. The ship was a gigantic dummy, the largest scarecrow ever conceived by the human mind.

(Corwainer Smith, "Golden The Ship Was—Oh! Oh! Oh!")

Interestingly, the Ur-Lisp (Lisp 1.5) actually had both. There were two ways to define a function. There was one form, LABEL (the ancestor of CL's LABELS), which bound a function like a variable, and another form, DEFINE, that put the function on the symbol's property list. APPLY would check the property list first, then look for a variable binding.

From the Lisp 1.5 manual (1962):

"In actual practice, LABEL is seldom used. It is usually more convenient to attach the name to the definition in a uniform manner... The fact that most functions are constants defined by the programmer, and not variables that are modified by the program, is not due to any weakness of the system. On the contrary, it indicates a richness of the system which we do not know how to exploit very well."

Postgres has "unlogged tables" for the not-exactly-persistent use case.

The HTML5 standard prescribes a regex for implementers to validate email addresses on the client side:

  /^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

So if you're going to use <input type=email>, you might as well use the same check on the server side.

I've just learned something about how my own vision works.

Apparently, when I'm reading on screen, somewhere towards the middle of the line, I switch my focus from my left eye to my right. This makes it obvious, because with the color at the end of the line, I switch too soon, and miss the third of the line in the middle.

Possibly this is a consequence of wearing glasses.

Symbol macros.