I agree with the blog's premise: "extremist" languages are great for language and for research. So this whole rant is not directly related to the post's central thesis. Instead, it's about the assumptions most people have whenever this topic comes up.<p>What I'm a little annoyed with can be summed up with a single banal and overused phrase: "the right tool for the right job".<p>For one, this phrase really doesn't say all that much--it's basically a tautology. Yes, using the right tool would be good, but with programming languages, it's rarely obvious what the right tool <i>is</i>! It's just a specialized version of the advice to "make the right choices", which is not much advice at all.<p>Another problem is that people inevitably ignore how much programming languages overlap. Virtually any languages worth comparing are going to be <i>general-purpose</i> languages. Choosing between a functional language and an OO language is not like choosing between a hammer and a screwdriver to pound in a nail, it's more like choosing between different types of hammer. In a world where hammers can do anything. (I don't know enough about carpentry to extend the analogy properly.) There are very few applications where one language clearly fits and another is clearly unsuited--and if you're in a vertical like that, the question just won't come up in the first place!<p>Another thing that comes up is people assuming that a multi-paradigm language has the benefits of <i>all</i> the paradigms it supports. I've found this is never the case. Even very multi-paradigm languages tend to favor one paradigm or the other more. And even if they didn't, there are benefits to being consistent. You can do much more by being functional <i>everywhere</i> than you can by merely supporting functional programming in some places. Any mix of paradigms is necessarily going to be a compromise, and the advantages of prioritizing one main paradigm can outweigh the flexibility of supporting more than one to any large extent. Doing one thing, and doing it well, is a powerful idea that doesn't stop applying in designing programming languages.<p>Now, I'm not leaning one way or the other here in any comparison of languages (I'm sure my biases are pretty evident and show through, they're just not germane to this comment); I just think that summarily dismissing a language for being too focused or too "extremist" or not multi-paradigm is rather short-sighted. Also, often, unless you've tried doing something in a language yourself, don't assume it's more difficult than what you already know. There is much "common wisdom" about (like "functional programming is bad for GUIs") which is often more "common" than "wisdom".
Another extreme direction to try out is the direction toward the machine. The value of trying out assembler programming may not have similarly direct benefits. But I personally find it a great general advantage to have detailed knowledge of under which practical conditions your program must run. To know that whatever fancy high level constructs you are making use of, you are always building a giant state machine where space is traded for time.
Incidentally, this is a formula for coming up with PhD projects: take a common comp sci primitive and then remove it or shift it to someplace else in the life cycle or stack.<p><a href="http://chester.id.au/2009/10/21/upsetting-the-natural-order/" rel="nofollow">http://chester.id.au/2009/10/21/upsetting-the-natural-order/</a>
This is why I use Clojure. I can do Functional, OOP, logic, or any of the dozens of other programming styles in one language. And since it's a lisp I don't have to worry about having to need extra syntax from the language writers to get what I want.<p>Pragmatic languages FTW!
>what if we made an OS where everything was a file?<p>Shameless Plan 9 plug.<p><a href="http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Design_concepts" rel="nofollow">http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Design_co...</a>
So, could we start a listing of things learned through the application of extremist programming?<p>Or better yet, a listing that shows where a given principle hasn't been extremified, so we can go try it out and see what happens?
Sure, you could try to treat everything like an object and then find out if an integer was an object (the hard way) or you could just RTFM (the easy way).<p>Don't get me wrong, experimentation is a great for learning about limitations and capabilities; but I personally wouldn't use it as my primary means for learning about the design of something (unless it was very poorly documented, in which case I would try to avoid using it at all).
Nice article and interesting viewpoint, taking principles to the extreme for learning purposes seems very useful.<p>The thing that impressed me most isn't the article though, but the amazingly beautiful clean look of that blog. Really a pleasure to look at and read on the iPad :-)
He underrates the power of principle.<p>"Mass is awesome. What if every object in the Universe had mass?"<p>"Liberty is awesome. What if there should be no such thing as slavery and every human being should be free?"<p>If you pick the wrong principle and take it to an extreme, then yes, it'll lead to undesirable results, but that means you should throw bad principles out, not all principles.
That's the right idea for a hobby or research project, but please don't do this in production code. Think about people who have to maintain it after you. I've seen my colleagues wade through a swamp of completely unnecessary C++ metaprogramming madness left by someone who apparently learned about templates yesterday, and it wasn't very nice.