Java was around for almost a decade when Eclipse became really mature... And Java was a language that was designed for GUI development from the very beginning, however, the Eclipse team had to develop their own windowing toolkit from scratch to get something that could swing that load.
The Python community has dreamed of a Python-based IDE for as long as Python has existed, but it faces two roadblocks: (i) there is no 'standard' GUI toolkit for Python and certainly none with the required maturity and (ii) it isn't easy for an IDE to reason about dynamically typed code (also not as necessary... Eclipse substantially lowers the 'verbosity tax' that makes Java programming so wet.)
Part of the problem is that an IDE requires that people who are passionate about programming get together with people who are passionate about designing user interfaces. GUI programming is particularly expensive, especially for open mixed initiative applications such as moderns IDEs. The kind of person who is 'hyperproductive' in LISP (or any other language) tends to avoid the morass of GUI development, where you can spend months and months going back and forth with designers and customers making sure the app correctly supports every interaction that would be intuitive to end user.
Now, LISP does have the advantage of being easy to reason about (since the program is also data) but it's fair to say that a really good IDE costs millions and millions of dollars worth of programmer time to develop. The core of Eclipse/Java was developed by professional programmers working around the clock. The community contributed plugins for Eclipse, such as the PHP and Python modes, are just a joke in comparsion... In some sense they're a step up from vi, but they're an embarassment if you compare them to Eclipse/Java or Visual Studio/C#.
JBuilder predated Eclipse and was a lot more usable (IMHO); it came out 2 years after Java was released. It started out written in Delphi though, and only later transitioned to Swing. I think it's also a push to say Java was designed for GUI; AWT was very much a hack.
> Now, LISP does have the advantage of being easy to reason about (since the program is also data)
Is this true? Could you (or someone else) elaborate? I would assume that an editor trying to reason about Ruby or Python code would parse the source code into an abstract syntax tree, and that would be just as easy (or hard) to reason about as Lisp, since those languages are all dynamically typed.
However, I'm pretty ignorant of how tools like Eclipse reason about Java code, so this is all just guessing.
Well, the advantage of a language like Java or C# is that the IDE knows the types of objects, so, for instance, it can autocomplete method and property names. Because introspection is used rarely in static languages, IDEs can do automated refactoring operations and KNOW that they found all the (non-introspection) references that are affected.
It's certainly possible to parse PHP, Python or Ruby into an abstract syntax tree (OK, Perl is a little harder) but practically very few people do metaprogramming at that level, even when it's officially supported. (C# and VB have had "expression trees" for a few years now and they're barely used.)
Part of the appeal of LISP is that you can pretend Noam Chomsky was never born and never need to learn how to write parsers or deal with the data structures that they spit out.
Any kind of extreme metaprogramming is going to defeat 'reasoning-in-code'. For instance, in LISP I can easily implement a new kind of control structure... Because 'understanding' a program in general (rather than running it) is an undecidable problem, it's clear that an IDE will ultimately get bogged down.
I've written a lot of PHP lately in a metaprogramming-heavy framework that uses magic methods to 'create' new properties and methods. The way this is done is systematic, and an IDE could probably be loaded with rules that would help it 'understand' this usage, but so far as I do this kind of code analysis, it's going to be in command-line tools that are cheap to develop compared to GUI tools.
I guess it's easier to parse, but however NetBeans does it they have pretty decent Ruby support so I don't know if it's really that big of a disadvantage.
Seems like you'd want a handful of really good, comprehensive parsers for any language and people would just use those rather than rolling a new one each time.
Java was around for almost a decade when Eclipse became really mature... And Java was a language that was designed for GUI development from the very beginning, however, the Eclipse team had to develop their own windowing toolkit from scratch to get something that could swing that load.
The Python community has dreamed of a Python-based IDE for as long as Python has existed, but it faces two roadblocks: (i) there is no 'standard' GUI toolkit for Python and certainly none with the required maturity and (ii) it isn't easy for an IDE to reason about dynamically typed code (also not as necessary... Eclipse substantially lowers the 'verbosity tax' that makes Java programming so wet.)
Part of the problem is that an IDE requires that people who are passionate about programming get together with people who are passionate about designing user interfaces. GUI programming is particularly expensive, especially for open mixed initiative applications such as moderns IDEs. The kind of person who is 'hyperproductive' in LISP (or any other language) tends to avoid the morass of GUI development, where you can spend months and months going back and forth with designers and customers making sure the app correctly supports every interaction that would be intuitive to end user.
Now, LISP does have the advantage of being easy to reason about (since the program is also data) but it's fair to say that a really good IDE costs millions and millions of dollars worth of programmer time to develop. The core of Eclipse/Java was developed by professional programmers working around the clock. The community contributed plugins for Eclipse, such as the PHP and Python modes, are just a joke in comparsion... In some sense they're a step up from vi, but they're an embarassment if you compare them to Eclipse/Java or Visual Studio/C#.