in reply to Features missing in perl IDEs?

(I'm going to go off on a rant here, about IDEs. Those on the ExtremePerl mailing list will probably recognize it. I've x-posted it in its entirety, originally sent on June 6, 2005.)

I'm still trying to figure out where my projects are going to get complex enough that I need my EDITOR to figure it out for me. To me, that's a CodeSmell and my design needs to be rethought.

I have always looked at IDEs as a bandaid. To me, they are the good programmer's solution to a bad infrastructure foisted upon them by mediocre architects. The Java libraries (and the C++ STL crap) are, frankly, overly complicated. Smalltalk is also rife with this - Bag and Collection and SortedUniqueCollectionThatOnlyWorksOnTuesdaysInMarch ... whatever!

Why should I ever need CodeAssist? Code Complete says that I shouldn't be dealing with more variables in a scope than will exist in 50 lines of code. Ideally, I should be able to see on one sheet of paper everything that I can affect. When I write, I have to justify to myself when the scope goes beyond the size of my window (52 lines).

The methodname completion thing sounds like a good idea. Except, you still need to have documented what those methods do. So, you still need to write the docco. Me - if I had to write the docco for 3245987305734 different methods whose names are 44 characters long and which differ after 12(!) CamelCased characters ... that's an OrganizationSmell to me. That's an organization that -wants- to be obsoleted, and soon.

I just left a contract with a company that, after giving 50% of their profit to the parent, makes over M$150/year. They have locked huge universities and several national patent offices to their products for several _decades_ - and they'll see their profits drop in 5 years.

Why? They rewrote their flagship product in Java. Now, I have nothing against Java per se ... any project that takes 100 developers/designers/testers/architects/etc over 5 years to get to the first beta is going to doom the company.

Now, everyone knows a story like that. Except, I've never heard of a story like that in Perl or Lisp or Haskell. I'll be glad to be corrected, but I only hear stories like that in Java, C++, and .NET ... and I don't think it's a coincedence. The languages that make an IDE go nuts are the very languages that are the most productive to work in.

If I told you I had whipped a project out in a week by myself and changes take 20 minutes, then it was rewritten in the corporate language and it took 4 people 3 months and it still doesn't work right and changes take a week ... could you guess the languages? I'd be interested in seeing a Java -> Perl conversion that meets those criteria.

Basically, there is no IDE for Perl or Lisp or Haskell, and there can never be one. AND THAT'S A GOOD THING. That's a sign that the language is on the right track. If you need an IDE, then that's a sign you will spend way too much time fighting the language (or library) and not enough time making your company money.

  • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
  • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

Replies are listed 'Best First'.
Re^2: Features missing in perl IDEs?
by hding (Chaplain) on Jun 16, 2005 at 14:22 UTC
    There are some pretty nice Lisp IDEs out there. All other things being equal (although rarely are they, of course) I'd probably rather work in Lispworks than, say, Emacs+SLIME+CMUCL for example. A lot of people like the Allegro CL IDE as well. While certainly not necessary, there's still a lot to be said for having well integrated inspectors, browsers, debuggers, and so forth, even for Lisp. And I'd think it'd actually be easier (quite a bit easier, actually) to make a decent Lisp IDE than one for something like C++.
[reply]
      The Lisp machine was mentioned as an IDE on the list by perrin. My response to that was the programmer is redefining the Lisp machine, which means you're developing your perfect language and the perfect editor to go with it. Now, if you could do something like that with Perl, I'd be all ears.
      • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
      • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
[reply]
        That actually wasn't me. I wish I could say I know Lisp, but I don't.
[reply]
Re^2: Features missing in perl IDEs?
by bofh_of_oz (Hermit) on Jun 17, 2005 at 13:23 UTC
    I tend to agree with that. Maybe my opinion is somewhat biased, but I see IDEs as a wheelchair for a programmer - it adds no real benefit over, say, a good editor with syntax highlighting. After all, you're supposed to understand the logic of your program before you sit down to type the code in, right? So all you need from the coding environment is to help you not to make typos.

    That being said, a built-in debugger may be a good idea for many programmers, but that's the only thing I can see as useful...

    --------------------------------
    An idea is not responsible for the people who believe in it...

[reply]

      With all due respect, IDEs are not wheelchairs that figure out the complexity of your program. They are tools that remove the menial, tedious, unproductive, uncreative tasks involved with programming on the CLI. In addition, a good IDE provides a level of support that empowers, not satiates, the developer.

      The most compelling example of this, for me, is the ability to aggressively refactor projects and have the editor monitor broken variable references and method invokations across the whole project. Such radical changes on the CLI are big, risky commitments - generally avoided in favour of hacks.

      As a human (as well as a programmer) IDEs are a huge step forward in terms of HCI. This may be a bitter pill if you have invested significant time and effort in becoming a vim-meister, but that old crufty UNIX engineer stuff is so passe.

      Granted, a lot of IDE benefits are geared towards compiled, strongly typed, Object-Oriented languages. If you dont need that functionality, fine, but to suggest that those that do are in some way disabled is pretty ignorant.




      time was, I could move my arms like a bird and...
[reply]

In Section Meditations