Re^9: Steve Yegge on how to build IDEs and improve speed of dynamic languages

I don't disagree with you regarding the march of technology. I remember discussing this very idea a couple years back after Paul Graham wrote his Hundred-Year language essay. And, if I've given you the impression that I'm somehow looking to just work with old-style tools because the new-fangled crap is too darn modern, then I've explained myself poorly.

The Perl world is moving toward the use of declarative syntax for Class definition. (P6 Moose et al.) Now what if your DE reminded you when you coded a call to a method that it was still virtual and hadn't been implemented anywhere yet. Or that you just assigned a non-numeric constant value to a variable that later gets passed to a subroutine that will attempt to use it as a number. Sure, you'll find that out later when you compile or run the code, assuming that you exercise that particular path. But wouldn't it be nice to be notified as you did it Friday evening, rather than find out on Tuesday morning after the long weekend, when you try to integrate it with a bunch of other peoples code?

It is exactly this kind of thing that is leading me away from Perl 5 and towards languages like Haskell with their ability to do static analysis. I want this kind of checking. I try to write my code so that it (mostly) self-checks itself. I work as much with intelligent objects as possible so that I don't have to think about this crap.

This is what drew me to Perl in the first place, the fact that whole classes of bugs just cannot happen. Dangling pointer? Nope. SQL injection? Nope. 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.

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. A language that doesn't have the failings I'm running into. In other words, I'm looking for Blub. Perl + IDE != Blub.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^9: Steve Yegge on how to build IDEs and improve speed of dynamic languages

Replies are listed 'Best First'.
Re^10: Steve Yegge on how to build IDEs and improve speed of dynamic languages by Joost (Canon) on May 15, 2008 at 00:02 UTC
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. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^10: Steve Yegge on how to build IDEs and improve speed of dynamic languages by BrowserUk (Patriarch) on May 14, 2008 at 15:11 UTC
It is exactly this kind of thing that is leading me away from Perl 5 and towards languages like Haskell with their ability to do static analysis. Well. Good luck with that, but you're sure gonna miss Diagnostics when you make the move and start encountering stuff like: ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): Malformed predicate [download] 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. Que? If you use a Komodo with perl 5.10, the language hasn't changed one jot. The IDE simply adds a few tools that you don't get with a bare command line. Some of them, maybe all of them, you already get from gVim. Does your use of gVim make Perl a failure? That's like branding the Beetles music crap if someone, somewhere listens to it on a iPod. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]