A better idea would be to never turn your back on any class of users -- ignoring their specific requests, perhaps, but always making sure they can solve their problem using their language. Even that strategy doesn't require language support for everything. CPython does just fine with the scientific computing community by punting to C bindings, for example.
The examples Yegge provides don't make any sense to me. The need to port Java code to Clojure is questionable, since Clojure provides good Java bindings. If you want a more Clojure-y version of a Java library, then a straight line-for-line port is not much of an improvement. As for the LOOP macro, you don't have to add everybody's little helper function into the standard library. I'm a big fan of languages adding helper functions to standard libraries if there's one obvious way to write them and the act of adding them will save everyone else from including their own version in all their projects, but a LOOP macro is absolutely NOT that.
(Unless it's just a straight-up reimplementation of Common Lisp's LOOP macro, which would do exactly one job, which is allowing Common Lisp programmers to be more comfortable in Clojure. Hey, guess what -- Common Lisp programmers already have one of the easiest paths to learning Clojure, since they know a Lisp already. Many non-Lisp programmers are tackling the learning curve and embracing Clojure, so CLers can't complain that it's too hard. Plus, many Common Lisp fans regard LOOP as an abomination and never use it anyway. Writing control structures in a complex DSL that few programmers bother to learn completely is not one of Common Lisp's best features. Saying "no" to a Common Lisp-style LOOP macro would be the right thing to do.)
What? Plenty of CL programmers learn LOOP. It's unbelievably convenient; as far as I'm concerned it is a masterpiece of usability. An abomination? Perhaps. Crack is an abomination and it's a masterpiece of usability too. But I don't care. I'm not a purist, and LOOP makes my work easier and more fun.
Complex DSL? Complex to specify, perhaps. Complex to implement? Not that bad. I wrote a pretty big subset of it for Parenscript and it wasn't hard. Complex to use? Not at all.
The reason many Lispers dislike LOOP is that it's un-Lispy. It's a foreign body implanted in the Lisp organism. Interestingly, though, CL's immune system doesn't reject it, meaning that it interoperates fine with everything else. If there were an impedance mismatch, LOOP wouldn't have lasted.
Java had this problem with Generics. A sizeable portion of the Java community had a massive allergy to them because they'd previously been burned by C++ templates. Of course there was the typical language war response "you're just not smart enough", but no matter how many times the people railroading it in protested that Generics weren't templates the facts remained:
They looked like templates
They had lots of funny little side effects and gotchas (just like templates)
Nobody really understood them, and even if they did, nobody could explain them. See also:
Class Enum<E extends Enum<E>>
In other words, it looks like a duck, it quacks like a duck (etc).
It is entirely possible that with different syntax (not the C++ style angle brackets) and different keywords (extends in the above example is clearly different from the normal extends in an object context) there would have been less cognitive dissonance from the C++ refugees and less pushback.
But ultimately what it boiled down to was this: the JCP (java community process) was a massive failure because you couldn't vote against things. You could only vote yes, no was not even an option, and abstentions were ignored (and therefore useless). It is like Communism - they call it democracy, but there's only one party to vote for...
Today it is 100% clear that the naysayers were not only wrong about Java generics. They are wrong about generic programming in general. Unfortunately they managed to cripple Java before this realisation became obvious.
The difficulty with loop is it takes something trivial and makes it more complex than it needs to be. Simple things are not simple. Complex things are rare and loop doesn't simplify them enough.
If you ignore the hyperspec, however, and get a feel for it by looking at examples and writing code using it, it becomes quite simple. It is very useful when you are translating C or Java code.
I find it quite readable in comparison to many of common lisp alternatives for iteration. And I kind of disagree that simple things aren't simple.
(loop for i from 0 below 10 do ...)
Is pretty much the simplest construct that you normally need.
Granted, I would likely just use dotimes in that case... but lets say you are iterating between 5 and 15, dotimes becomes unwieldy, where the for loop is pretty much the same code with the numbers changed.
(loop for i from 5 below 15 do ....)
Now try incrementing by 2
(loop for i from 5 below 15 by 2 do ....)
compare to the similar do* code
(do* ((i 5 (+ i 2)))
((>= i 15))
Not that I don't understand your point... in fact, as little as a year ago, I felt that way too... but I have since changed my mind.
My current preference is to use do* if writing a macro that needs iteration, and to use loop when I am doing something similar to a list comprehension or array traversal.
(common-lisp.net seems to be down)
I sometimes joke my programming language is LOOP instead of CL: http://www.reddit.com/r/science/comments/bc91w/on_the_8th_da...