Section :: Rants and Raves

Back To The Command Prompt!

by Huw Collingbourne

Is this really the death of the IDE...?

Monday 12 February 2007.

We don’t want none of those steenken’ IDEs. Such, it would appear, is the confirmed prejudice of many a modern day programmer. This is a prejudice which, I confess, I do not understand. The determination to use the worst tools for the job seems, to me, positively perverse.

However, the anti-IDE sentiment is remarkably prevalent among the ranks of the advocates of ‘scripting languages’ such as PHP, Python and Ruby. Lurking as I frequently do on forums and newsgroups devoted to those languages, I am often made to feel like an old and lumbering mammoth who’s somehow strayed into field full of ‘agile’ gazelles. Then again, I never have seen the light when it comes to agile methodologies or, indeed, to any other –ologies. These agile youngsters would have me believe that IDEs are bad, big and slow you down...

Suffice to say, I beg to differ.

I grew up with IDEs ranging from the simple (but darn’ good for its day) Turbo Pascal to the much more complex (and remarkably good for our day) Visual Studio. En route I’ve dabbled in Delphi, Visual Café, Komodo, Dolphin Smalltalk and a handful of other fairly decent IDEs.

Ah, Smalltalk! That’s the language to blame. In the bad old days when users of other languages were obliged to code in simple editors (or no editor at all) and go through the arcane rituals of compiling and linking before they even knew whether or not their program would run, Smalltalk programmers just pointed, clicked and evaluated. If you aren’t familiar with Smalltalk, I recommend the Dolphin implementation so – give it a go.

Oh, did I mention that Dolphin Smalltalk ‘only’ runs on Windows? That’s another criticism that is often made among the coders of open source languages. Windows is perceived as a niche market. In one memorable phrase, I recall a Ruby programmer expressing bafflement at my decision to develop a Ruby IDE for Visual Studio. In his opinion, Windows was a niche but Visual Studio was just a ‘niche within a niche’.

I must admit that I find it a little depressing that the visionary ideals of Smalltalk, almost three decades ago, have largely defined modern computing and yet are being actively rejected by a large percentage of the new generation of computer programmers.

Add to del.icio.us

Forum

Back To The Command Prompt!
19 February 2007, by Patrick

I too share a cynicism for the pervasive IDE hating meme though I think a partial explanation may lie in a widely held belief that a choice must be made between an (often new found) love of programming in a dynamically typed language and the use of an IDE. In a similar way people also seem to mistakenly believe that a choice has to be made between static typing and a REPL, and between dynamic typing and compilation.

I think all these misconceptions have something to do with people inaccurately defining the space of programming languages as a line with C++/Java at one end and Perl/Python/Ruby at the other. So, if Ruby programmers think IDEs and types are for corporate Java drones they should probably educate themselves and get hip to the wider world of languages and environments including Smalltalk, LISP and the ML family.

Anyway, for the record I use Zend Studio (for PHP), SlickEdit (for many jobs including Python/SQL) and Visual Studio (for C#) almost every day at work and I wouldn’t give up my editor or my IDEs.
- Back To The Command Prompt!
  17 June 2009
  
  There’re several other reasons for it.
  
  1) Machismo. I don’t need no nannying environment. I’ve read the docs.
  
  2) Speed. Notepad, vim or whatever are just there. There’s no loading time.
  
  3) Reliability. Less to go wrong. No editor crashes or hangs to interrupt coding flow.
  
  4) Inevitable incompleteness. IDEs never quite do exactly what you want. It’s frustrating. So why bother?
  
  5) Less fiddling, more coding. Less tempting IDE settings, widgets and extensions to frobnicate and procrastinate with.
Back To The Command Prompt!
15 February 2007, by Johnny P

I think you may be missing the point of people opposed to IDE’s. I know for me having the least bearear to edititing, running, or compiling code is the best thing. That means simply an editor and comand prompt. I am not discounting the benefit that can come from tools built into IDE’s; However, I don’t want to have to have it all installed to make a simple change. I also know those savy at the command prompt can be just as productive, or more than anyone using an IDE.

Remember a fool with a tool(IDE) is still a fool.
- Back To The Command Prompt!
  16 February 2007, by Huw Collingbourne
  
  I know that’s a view that many people share. Nevertheless, I think that the advantages of built in debugging, not to mention error trapping, IntelliSense and so on makes a first rate IDE far more useful than an editor or (shudder!), a command prompt!
  
  Never mind fools and tools. To use a different old saying, don’t you think that a craftsman should use the best tools for the job...?
  - Back To The Command Prompt!
    3 March 2007
    
    > To use a different old saying,
    > don’t you think that a craftsman should use the best tools for the job...?
    
    That is the point. If the job is to kill a fly, the best tool for the job is a good old fashioned fly swatter (shudder all you want), not the most modern cruise missle or smart bomb or tank. They are over kill for the task at hand yet some people insist on using them for every task, perhaps because they are bigger, more powerful or newer, but more likely because they don’t even think about which tool is "best" for the task.
    
    I can swat a fly with a fly swatter before you can even turn on your tank, let alone aim it at the fly. For most tasks, I can be in, out and done with a text editor and command line before the IDE has even finished initializing.
    
    As an aside, debugging only comes into play if you create programs with bugs. It is possible, believe it or not, with thoughtful progrmming to create programs without bugs. I worry about people that rely on a debugger to find the bugs that become evident in "testing". It seems to me that they are going to only find some of the bugs, those that were uncovered during the testing. But if they allow themselves to write bug ridden code, what about the bugs that are not uncovered in testing, they will be released when the product is released. It is much better to develop the programming practices that won’t allow you to write bugs into your code. Zero defects is the standard in many industries (aircraft maintenance for example). It can be in programing as well.