The "You need a PHD to understand Haskell" slur is so bloody ridiculous. I certainly didn't have a problem with it, and I haven't even finished my degree yet! On a more general note, I find the idea that a programming language can be "too smart" troubling. Is the solution to have dumber programming languages then?
No this is what a GPL developer considers a "loss". Specifically, yet another demonstration of why developing for someone else's walled garden is a bad idea.
I'm not sure that Haskell could, given time, subsume dynamically typed programming. But even if it is possible, why would it be desirable? Most Haskell people don't think very highly of dynamic typing, and the extensions to the language reflect that. They generally add more typing, e.g GADT's, multi-parameter type classes, extensible kinds e.t.c. And dependent typing is certainly not a move towards dynamic typing! Casting it as such shows poor understanding of both concepts.
The confusion about the use case of NoSQL probably stems from the term "NoSQL" being so vaguely defined. All you can say for sure about one is that it's not relational. But other than that there's not much in common between (for example) key-value stores, graph databases and object databases.
Result: The author has to qualify all statements with "only applies to some NoSQL databases".
Remember, you can also use any language that compiles to Java bytecode on a JVM. A short list includes Scala, Clojure, Ruby, Python, Groovy and even Javascript(via Rhino). So the JVM and Java are very much separate things.
There is also the matter that the whole "correctness vs. productivity" debate is a false opposite. There is nothing mutually contradictive with correctness and productivity, so there is no reason why you can't have both.
Of course human error applies here too; But it's much simpler to get one type right than to use the type in the right way everywhere. Per example: The Red-Black-Tree implementation mentioned in the examples. If we define a tree that cannot be unbalanced, we can skip all explicit checks for whether the tree is balanced, thus eliminating a source for errors (forgetting/bungling the balance checks) and also increasing productivity (since we don't need to write the balance checks in the first place).
It's amusing watching the author use purple prose over a single blinking LED. I bet if Steve Jobs gave him a turd he would describe it as "that which makes the flowers grow, with a heady aroma".
Let's assume that the author is right when he says that all companies ignore linux. What would make that such a big disaster? Is there some specific proprietary app that _needs_ to be ported to linux? I myself haven't found a task that lacks a convenient binary, but maybe that's just me?
That, and 'EMACS vs. VIM' is a dead horse. Stop beating it.
I'm not sure i agree with graham on this one. Certainly it's useful and necessary to keep some brevity, however his jab at design patterns is a schoolbook false opposite (if you don't like extreme brevity you must be an enterprise java programmer, seems to be his subtext). That, and some lengh/repetition is useful to the brain's pattern recognition, allowing simpler understanding of code. There is of course also a point where too much repetition leads to a "can't see the code for all the statements" situation.
Where exactly this point is is probably highly personal.
To me the really interesting question is how Microsoft ever got to be a monopoly in the first place, with the kind of products they've been making.
What made windows and office succeed in the first place? Can you really coast that far just on malignant business practices?
I disagree with the main premise: That as long as you provide the "90% functionality" (i.e mail,chat e.t.c), no casual user will miss the last 10%. Sure, most of the time this will work fine, but occasionally people want more. Maybe upload a video to youtube, or chat on that new up-and-coming social networking site? "The user" is not quite so simpleminded as some here seem to think. More importantly, since the web market can change so fast any static set of features could get sidelined by a new application/web page et al, and it's very hard to predict in advance what the user will want. Therefore, one makes devices that can do everything. This is not an anachronism, it's the only logical solution to a market that changes too fast to lock people in to a very small subset of a computer.
1: Critique against mouse and keyboard rings hollow. It's stuck around so far because it "just works" for a large number of apps. Touchscreens not similarly proven.
2: Limitations of the hardware is touted as a "great opportunity". Opportunity how? An opportunity to unleash gosh-darned ugly hacks to get around said limitations?
3: Written by Miguel de Icaza, known troll/closed source afficionado. Notably, nothing is mentioned about how hard it is to develop on an entirely closed platform (see iPhone troubles). Considering who the author is, not surprising in the least. Generally i try to avoid ad hominem but in this case the author's own bias gets ahead of dispassionate analysis.
Especially considering how many (and recent!) examples there are of that kind of thinking leading to disaster in economics. I'd say those that don't learn history are doomed to repeat it, but this barely qualifies as history.
I've seen an interesting way to do method chaining in haskell: The '$' operator: Basically it's a low-priority right-associative binary operator that applies the function to the left to everything to the right.
Using the example from the article, one could do it as: