in reply to Re^9: Steve Yegge on how to build IDEs and improve speed of dynamic languages
in thread Steve Yegge on how to build IDEs and improve speed of dynamic languages
Now, I'm looking for a tool that will eliminate even more classes of bugs, particularly bugs that don't fail quickly. Dangling pointers fail quickly - the whole thing dies. Type mismatch errors fail slowly. Things that fail slowly suck.Type mismatch errors happen, but they don't happen all that much. Personally I think the way Java/C/C++ etc try to catch those errors isn't worth the even 10% of the effort. I've heard good things about ML, but I haven't tried it, mostly because, as I said, type errors are really not that common (in my code at least). Especially not in perl, with its "hard" coercion mechanisms (and SBCL is also pretty good at catching this kind of thing at compile time)
I guess what I'm saying is that I consider an IDE to be an indication of a language failing. If I need an IDE, that's because there's something screwy about the language I'm using and the way I'm using it. Given the plethora of languages out there, I should probably find a better language for what I'm doing.
The "big problem" nowadays seems to me that everybody equates IDEs == static analysis == C/C++/java-style rigid type/class systems.
That's just not true (and the OP's link explicitly agrees with me). It's quite possible to have a development environment for dynamic languages that's as least as good as, say Eclipse, but it requires runtime inspection. And that is *not* a drawback in general - though to make the best use of it, you have to structure your programs accordingly, runtime inspection gives you tons of interactivity that static analysis just can't do (example: break on an exception, inspect the state, recompile a function from your editor into the running program and restart from the exception point - how cool is that? And all that's been common in serious Lisp development tools for decades). For a fairly good example, see SLIME - that really opened my eyes to what's possible (even though it's far from perfect/complete).
update: here's an interesting video on SLIME. you may want to start at about 8 minutes in if you don't care about how to set it up over over multiple machines.
|
|---|