Beginner functional programmers nest their code too deeply, in exactly the same way that beginner C programmers nest their code too deeply. It's not an inherent property of the language.

I have no idea what "hard to fan out results" is supposed to mean, but the conclusion is trivially disproven by the existence of lots of functional programs that do more than compute a single result.

Persistent state works fine, it's just managed more explicitly: you take the "previous" state as input, and you return the "next" state as an output. Practical functional programming languages have a "functional update" syntax for struct/record types that makes it easy to do this sort of thing.

I agree regarding I/O. But OCaml is not a purely functional language, and the I/O implementation uses imperative syntax. It works just like it does in C. (Well, with the notable exception that printf actually type-checks its arguments at compile time.)

The "guards" are a minor detail compared to the use of pattern matching for operating over sum types. It's the presence of a first-class sum type which makes these languages so effective at a wide variety of practical problems, because it gives the programmer a truly effective way to express the invariant that "either the data is of this type, OR the data is of that type, but not both". This is not mathematical bullshit, this is basic business-logic programming that happens all the time. In the mainstream programming languages, you don't have anything better to work with than a tagged union; that's a crappy solution.

The article, of course, elaborates on this. You should consider reading it.

The LOL was aimed at the boldface text. The C++ preprocessor is an underdesigned relic of C which integrates very poorly with the C++ feature set. To describe it as "best" is laughable.

(C++ is also a piece of shit for writing functional-style code, but I'll give that one a pass.)

Objective, generic, functional -- its all there and accompained with the best preprocessor, macros and code generators

LOL

I don't agree that this is a hatchet job. I am concerned by the volume of highly-rated applications on the Android Market which require permissions that should be unnecessary. As you point out, the Android platform enumerates the requested permissions in a very visible way, which is great. The problem is cultural: users do not question these permission requests as much as they should.

I would really like to be able to selectively deny certain permissions to applications.

People who have performance drives *already* use eSATA (seriously, firewire? Is this 2002? Worse, you then go on to talk about CPU usage, where again the answer is "use eSATA")

eSATA is a nice technology in general, and certainly looks like the future of commodity high-speed external storage, but I expect that it will take a couple of years before the OS/driver support matures. As evidence: take a random sampling of eSATA host controllers and you'll find a disturbingly small percentage that provide driver hooks to safely unmount the drive. You'll find an even smaller percentage that does this *reliably*.

1394 drivers are pretty mature these days, so one doesn't tend to run into those sorts of issues. 1394b also gets close to 80MB/s in practice (not just in theory); it takes a pretty fast HDD to saturate that kind of bandwidth. I would argue that 1394 is still a pretty good choice in 2009, although it's clearly on the way out.

Not sure how serious you are, but you've got it backwards. A future FSF could create a GPL with more liberal terms of distribution. Suppose the license permitted binary-only distribution in exchange for a generous donation to the FSF--probably most developers would have a problem with that.

It's difficult to imagine such a scenario today, but I'm sufficiently paranoid to expect that the FSF may not always be trustworthy. All it takes is a gradual shift in the voting membership.

If the FSF continues to release reasonable licenses, a developer can retroactively relicense old software releases under the new versions of the GPL. No risk to the developer, just a little more bookkeeping work.

if GPL then GPL v3 *and higher* (don't forget).

Or not. The "...or higher" language implies a great deal of trust in the FSF. There is risk in making that decision: the FSF could one day release a GPL which offers terms that the developer disagrees with.

It is entirely reasonable for a risk-averse developer to distribute software under a single well-defined license rather than an unlimited number of undefined licenses.

I've helped to guide a bunch of SATA boards from prototype to product. From personal experience, I can tell you that a switch put together "half-decently" is very likely to result in unreliable SATA communication.

Well, if you include a few more pins, then you should be able to merely extend the current design to include the data cables...

Only if you want to deal with a bunch of CRC failures. You can't really expect to be able to mess around with signal lines when you're switching at 1.5 or 3.0 Gbps.