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

I'm still trying to find a reason why I would use an IDE that has anything more than gVim does

Doesn't that mean that gVim is just a less complex (powerful) IDE?

I mean it's an Environment in which you Develop programs, and unless you're driving it using batch scripts, you are probably using it Interactively.


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^2: Steve Yegge on how to build IDEs and improve speed of dynamic languages

Replies are listed 'Best First'.
Re^3: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by GrandFather (Saint) on May 13, 2008 at 21:41 UTC

    My understanding was that the I was for Integrated because IDEs integrate project management, editing, code browsers, compilation and linking, debugging and various other tools into one GUI environment.


    Perl is environmentally friendly - it saves trees

      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.
        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?