If one considers hacking as solely an individual activity, then the limits of expression does have a non-negligible impact on productivity. However, when we involve groups of people, then a language that "supports communities" bests out a "Hacker" language.
Paul Graham has stirred up a hornet's nest when he wrote in his essay "Great Hackers" that:
Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero.
I read through his essay and I agree with many of the observations that he brings forward. The biggest confusion I see though is his definition of the word "Hacker". To better understand what he means, let's look at his other essay "Hackers and Painters", where he writes:
Computer science is a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia. At one end you have people who are really mathematicians, but call what they're doing computer science so they can get DARPA grants. In the middle you have people working on something like the natural history of computers-- studying the behavior of algorithms for routing data through networks, for example. And then at the other extreme you have the hackers, who are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters.
So his definition boils down to people who have the capability of building software of beauty and value. However his reasoning about the limitations of people who write in Java is circumferential at best. His argument about Java is that it's not good enough as a medium of expression. I would agree that there are areas that need enhancement. Java has always been designed for the masses. To reason that it limits expressability therefore no hacker voluntarily uses it, is a bit of a stretch. Just take a sample of this list of "Most Valuable Personalities in Java", most of them in my opinion have achieved some kind of "Hacker status". Also, what about Joshua Bloch or Adam Bosworth, most prominent Java practitioners, aren't they not "hackers"? After all they qualified to get into Google, the place where Graham claims the better hackers go.
The important question though is this "Is Java sufficiently limiting that you can't build software of beauty and value?". To answer that question, we don't really have to look very far, you can find it in his own paper. Paul Graham writes:
Bottom-up programming suggests another way to partition the company: have the smart people work as toolmakers. If your company makes software to do x, have one group that builds tools for writing software of that type, and another that uses these tools to write the applications. This way you might be able to get smart people to write 99% of your code, but still keep them almost as insulated from users as they would be in a traditional research department. The toolmakers would have users, but they'd only be the company's own developers.
There's a not too well known company called Object Technology International (OTI). This company has possibly the most innovative and experience object oriented practitioners in the world. People think that it's IBM that built Eclipse, that's somewhat true, but the more precise truth is that OTI built Eclipse and OTI just happens to be an IBM subsidiary. A subsidiary that is isolated from the larger organization to build innovative products. Nothing has ever been built in Lisp, Python or any other "Hacker" language that comes even close to the innovation in the Eclipse platform. I challenge anyone to point one out.
The point is, "limits of expression" is not all bad. In fact, the main architecture of Java is to support collaboration. That is, it has an "Architecture of Participation". If one considers hacking as solely an individual activity, then the limits of expression does have a non-negligible impact on productivity. However, when we involve groups of people, then a language that supports communities bests out a "Hacker" language.
However, the power of a language doesn't solely rest on its expressibility. Since software development is always practiced best as an iterative activity (as opposed to write-only in Perl), a language that supports this will beat out one that doesn't. That's why, despite the more powerful language constructs in other languages like Ruby or Python, these languages aren't going to win if they aren't going to get the slice and dice capabilities you find in Eclipse. Till then, these languages should be content to confining themselves to small projects.
It'll be interesting to see how bigger projects based on languages like Python will fare. So far, the Chandler project which was announced with a lot of fan fare is not progressing very briskly. May I suggest writing some sophisticated refactoring tools first (albeit in Java).
Finally, let us point out Paul Graham's fatal flaw. Software has a lifecycle, some time in that cycle, it eventually hits maintenance mode. This is the point where no hacker will be caught dead holding the bag. He writes:
It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
The kind of work that you'll find in many projects is that there's some work with some kind of legacy code. Also, today's software will always become someeone else's legacy. That's exaclty what happened to Paul Graham's ViaWeb. It eventually became legacy, and when the hackers refused to maintain it, then they needed to hire non-hackers who re-hacked it in Perl and C++. The lesson here is that, successful projects are ones that can easily be maintained by average programmers. The flaw in Graham's argument is that he's figured out how to win the war but overlooked how to win the peace.
> However, the power of a language doesn't solely rest on > its expressibility. Since software development is always > practiced best as an iterative activity (as opposed to > write-only in Perl), a language that supports this will > beat out one that doesn't. That's why, despite the more > powerful language constructs in other languages like Ruby > or Python, these languages aren't going to win if they > aren't going to get the slice and > dice capabilities you find in Eclipse. Till then, > these languages should be content to confining themselves > to small projects.
I use IDEA rather than Eclipse, but in any case I think you overstate the advantage. Visual Age for Smalltalk was a fantastic development environment compared to the early Java IDEs, but Java won out anyway. There are many developers who prefer PHP (using only a text editor) over Java. Etc.
Moreover, I don't notice the lack of an IDEA nearly as much in Perl as I would in Java. The language just doesn't have as many features that require it (or benefit from it).
I'm not knocking good editors -- things like refactoring support are handy. But they aren't even remotely enough to make me feel "locked in" to Java.
On the contrary, I believe you seriously under estimate the capabilities of IDEs like Eclipse or IDEA.
Your claims are even harder to believe than mine (i.e. "they aren't even remotely enough to make me feel locked in"). Or maybe you just happen to have a photographic memory, so computer assistance is really not necessary for you.
I don't have a photographic memory at all, but 1) in other languages (e.g., Perl), I do not tend to need to reference nearly so many API methods; 2) Even in Java, I very often have Javadoc open if I am using an unfamiliar API -- so auto-completion, while very nice, is not a must-have feature; 3) some other languages also have nice IDEAs (e.g., Smalltalk, or to some extent Lisp); 4) Some of what the IDEs do for Java are either unnecessary or built-in in other languages -- e.g., I can change a function while debugging it in Lisp.
I'm not putting IDEA (or Eclipse) down; I do think they are swell. But I just don't see them as being make-or-break issues.
Java's advantage is the size of its libraries. Everything else I can live without...
1) Regarding 'Nothing has ever been built in Lisp, Python or any other "Hacker" language that comes even close to the innovation in the Eclipse platform.'
I am an avid and experienced Java programmer, so you're preaching to the choir, but when I worked for NASA in the 80s we used Symbolics LISP machines for our development, and they were really something incredible. Imagine an entire OS built in the same language as your editor, file system, mail program, etc. While Eclipse is a nice IDE with lots of people extending it, it's a long ways from something like Genera (check out http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-info/symbolics.html, for example).
2) Regarding the medium limiting expression, this is true in any art form. However, it's both a limitation and an opportunity.
What makes Eclipse powerful is its access to the programming language constructs. Lisp has this by default, providing it with unbelievable flexibility. Smalltalk has access to it to. Python and Ruby have it to an extents (after all they are interpreted) however possibly more at the runtime level and not at the syntax level. The key is introspection, from there you can build powerful language environments.
Admittedly its easier to do in Lisp or Smalltalk than it is in Java. However, in Java and its rendition of Eclipse provides you with a more open environment.
However, I guess I have to qualify my argument, the argument against Lisp can easily put me in hot water, same goes with Smalltalk. However, arguments against Python, Ruby or Perl still hold true.
This of course brings up another question, if Lisp and Smalltalk environments were so good, how come Python and Ruby are more popular now? Answer: Architecture of Participation ;-)
Regarding Javadoc: Yes it does, if you've bothered to configure the environment to find the Javadoc for the jars you've imported. I seldom bother, which in and of itself says something about the perceived value of the feature.
> However, I guess I have to qualify my argument, the > argument against Lisp can easily put me in hot water, same > goes with Smalltalk. However, arguments against Python, > Ruby or Perl still hold true. > > This of course brings up another question, if Lisp and > Smalltalk environments were so good, how come Python and > Ruby are more popular now? Answer: Architecture of > Participation ;-)
Answer 1: Ignorance (as in "Nothing has ever been built...") Answer 2: They are better tools for scripting.
My theory what killed Lisp and Smalltalk, or any other good language for that matter:
1.) Lack of a gratis fully featured cross platform quality version of the language suitable for commercial use. (e.g. gcc, java, perl in contrast to lisp and smalltalk where useful versions where all comercial and expensive)
2.) Lack of good reading books and tutorials (free online and offline) of the learn in 24 hours style (or camel book), and good reference material for more advanced usage for 1.
3.) Lack of extensive standard libraries for 1.
4.) An easy way to share and discuss readable code.
I attribute the resurgence of lisp and smalltalk to good implementations like cmucl and squeak, alas cmucl is not available for windows yet. Additionally there is not much hands on documentation based on those implementations either.
"Nothing has ever been built in Lisp, Python or any other "Hacker" language that comes even close to the innovation in the Eclipse platform. I challenge anyone to point one out."
Hmm. I guess the original poster hasn't heard of Eclipse's predecessor, VisualAge for Java (written in VA Smalltalk). Smalltalk development systems had as much or more functionality as Eclipse 20 years ago - stating that Eclipse is better simply ignores history.
Another point along this continuum - plugins. yes, Eclipse supports them. No, it's not a simple architecture. It's distinctly non-trivial to add a plugin. Contrast that with (an admittedly simpler) application, BottomFeeder (written in VisualWorks). Plugins have a bunch of events they can choose to respond to, and one (1!) method to implement. Simpler, I think.
The original poster should download a Smalltalk system and have a look. His notions of innovation might change.