in reply to Re^3: 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

A google tie-break has it 1.3M to 33k in favour of your definition. Though at least one online source acknowledges the ambiguity:

Such systems are typically both interactive and integrated, hence the ambiguous acronym. They are interactive in that the developer can view and alter the execution of the program at the level of statements and variables. They are integrated in that, partly to support the above interaction, the source code editor and the execution environment are tightly coupled.

A very quick scan of a book (circa. 1990) that describes the Programmer's WorkBench for MS-DOS and OS/2 systems has a couple of references to interactive, and none that I saw to integrated. So maybe it's a historical thing.

The term "IDE" is generic, and can be as simple as a couple of macros or key definitions in your editor, that save you from having to exit the editor to compile and/or run your program.

Back in the day, running PWB under dos was a mind-blowing revelation. (Single tasking remember.) But the best bits were having the editor jump straight the file and line of compiler errors. Hitting one key to bring up the online help to explain that error. And being able to go straight into a source level debugger. Cool stuff. Sure you could do all of that stuff before, but having the IDE remember break points and watched variables across edits sure sped things up.

Or an IDE can be as complex as the Erlang, Clean or Mozart IDEs. Or probably more so, with things the C#/.NET environment, though I've not yet seen those in action.

The point remains. IDE's are just tools of the trade. You can write good code with them, just as you can write bad code without them. Condemning a whole group of programmers as bad, because they happen find some of the facilities of an IDE useful, is a stupid as condemning gVim programmers as bad because they find syntax highlighting useful.

Hell. I remember bootstrapping a PDP-11 using the front panel switch register, but I wouldn't recommend it for anyone who has a life. It's boring, error-prone and repetitive. That's why we have computers, to do those mundane tasks for us.

It's perhaps the weirdest thing about programmers. They'll spend countless hours persuading their grandmothers to keep their knitting patterns and recipes and photos on a computer. And countless more automating drawing the curtains, making coffee, and anything they can. But when it comes to using computers to assist the the process of programming, it's like you'd asked them to dance naked in a fire-pit.

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."
  • Comment on Re^4: Steve Yegge on how to build IDEs and improve speed of dynamic languages

Replies are listed 'Best First'.
Re^5: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by dragonchild (Archbishop) on May 13, 2008 at 23:43 UTC
    It's perhaps the weirdest thing about programmers. They'll spend countless hours persuading their grandmothers to keep their knitting patterns and recipes and photos on a computer. And countless more automating drawing the curtains, making coffee, and anything they can. But when it comes to using computers to assist the the process of programming, it's like you'd asked them to dance naked in a fire-pit.

    I don't trust most humans to assist the process of programming. The way I see it, a computer is useful at doing repetitive tasks. A good program, following DRY, isn't repetitive. So, where does the computer fit in?

    The reason DRY works is because of modules, such as Moose, Catalyst, and DBIx::Class. I'd prefer to have the computer work through the medium of a module than the medium of an IDE. I don't have to think about the module where I have to think about the IDE.

    And, personally, I enjoy dancing naked around a firepit. In one is a slightly more burning matter. :-)

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

      Computers are good at repetitive, tedious, fiddly and complicated tasks, and they are good at remembering lots of stuff. As BrowserUK implies, a good IDE leverages those characteristics to pick up errors early and to make it much easier and faster to find the information that is required during program development.

      There are a few astounding individuals who seem to be able to hold huge amounts of information about how a piece of code hangs together in their head and access the pertinent information they require with apparent ease. Most of us can't do that. Having a bundle of well coordinated tools that compensate for that lack allows the rest of us to participate in the game and generate quality output where otherwise we would get so bogged down in detail and tedium that we would never produce anything.

      Perl is environmentally friendly - it saves trees
[reply]
      A good program, following DRY, isn't repetitive. So, where does the computer fit in?

      Well, checking that I typed the casing of the module name correctly as I type it could be useful.

      And remind me, is that Text::PDF::Array method name elementsOf or elements_of?

      How about generating those 10 or so almost identical lines that appear in the top of many of the testcase you have to write? 

      ##
# DBM::Deep Test
##
use strict;
use Test::More tests => 128;
use Test::Exception;
use t::common qw( new_fh );

use_ok( 'DBM::Deep' );

      [download]

      Shall I go one looking for the opportunities? :)

      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.
[reply]
[d/l]
[select]
        Catching typos and integrating documentation ... now those are useful things, so long as they are requests and not requirements. I personally despise the hard-integration that some IDEs have that says "I will offer my suggestions NO MATTER WHAT YOU WANT cause I think you're a bloody idiot." At that point, give me Notepad or you'll have a piece of paper that says "I quit!" shoved up your nose.

        Now, Ovid and I have each separately created vim macros for working with test suites and doing syntax checks on a file. Sure, I can see the benefit of those things. I even have skeletons for when I create a new file that generates those lines you're talking about and it's different for a .t vs. a .pm/.pl. Though, frankly, I should be using something like Test::Class or some other xUnit framework so that my setup and teardown can be DRY'ed.

        But, what does it tell you that you need a program to manage your project?

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Perl News