4 ms·

I don't think anyone is saying that IDEs like Eclipse or Xcode or Visual Studio do not have a place. They absolutely do. HOWEVER: (1) from my experience of wor

I don't think anyone is saying that IDEs like Eclipse or Xcode or Visual Studio do not have a place. They absolutely do. HOWEVER: (1) from my experience of working with people fresh out of school who were exclusively familiar only with the IDE way of building programs and who knew little to nothing about the command line tools -- such people were curiously unaware that many tasks (testing for example) could be automated. People who used command line extensively, on the other hand, would be the first ones to write a simple script that performed testing of their program. Testing is just one example (I'm sure there are many IDE-tailored solutions for it). There are other things that are done repetitively; using an IDE can mold one into thinking that such tasks are impossible to automate and that they can only be performed by clicking buttons. (2) (Again this is about people either in school or fresh out of it -- certainly not about highly professional IDE users). People who were taught IDE first and who are not familiar with the command line will often assume that running command line utilities is an old-fashioned way and that they are more "modern" (therefore somehow "better") programmers just because they are using a GUI. Such people will then go on to write programs that completely ignore the standard way of interacting with the shell, even if their programs do run from the command line. One example: One of the programmers (who used exclusively GUIs for building programs) would write command-line utilities which, when outputting a text file, would place '\n' at the beginning of each line and not at the end, which then resulted in parts of the output being truncated when I ran them through sed/gnuplot/whatever. Firthermore, even though his programs were quite complicated (read: painful to debug), he had no idea what the difference between stderr and stdout was, and would write any errors that would come up to stdout. The same programmer was then curiously defensive when I told him that his way of doing it was wrong (his answer basically was: "I've been programming for a long time, and I've always done it that way, and I don't care that my programs don't play nice with that sed thing with which I'm not familiar with").

roguecoder 14y ago
I have encountered the inverse: 1) People who exclusively use the command line, especially when recently graduated, have extreme difficulty thinking in an OO fashion, because they have not had the tools to support exploring inheritance and call stacks the way someone with a visual OO development environment has (Smalltalk is ideal for this.) 2) People who have used the command line exclusively are content without visualizations, which can be massively more effective at conveying information, especially about performance and architecture. 3) People who have used the command line exclusively are less likely to employ refactoring tools and more likely to tolerate long, poorly factored code because vim/emacs makes it easy to navigate and ignore the ugliness. 4) People who have used the command line exclusively, especially when they are recent graduates, believe that their approach is inherently better and necessary in order to be a good developer. They get curiously defensive if you expect them to be able to instantly jump to the definition of a method in question or actually use the Strategy pattern.
- bluekeybox 14y ago
  1) Don't really have a defense for that. Then again, not everyone who uses an IDE and claims they know OOP had had experience with Smalltalk. 2) I have encountered people who used UML/SQL schema diagrams in a cargo-cultish way to prove to themselves and (especially) others that what they were doing was well thought-out when in fact the opposite was the case. 3) That reads more like an argument in favor of Vim/Emacs as superior editors. Also, it seems silly to blame lack of refactoring on editor when it's more of an issue of whether the programmer has a sense of code elegance and clarity or not. 4) I guess hubris is not exclusive to either side.

roguecoder 14y ago

I have encountered the inverse: 1) People who exclusively use the command line, especially when recently graduated, have extreme difficulty thinking in an OO fashion, because they have not had the tools to support exploring inheritance and call stacks the way someone with a visual OO development environment has (Smalltalk is ideal for this.) 2) People who have used the command line exclusively are content without visualizations, which can be massively more effective at conveying information, especially about performance and architecture. 3) People who have used the command line exclusively are less likely to employ refactoring tools and more likely to tolerate long, poorly factored code because vim/emacs makes it easy to navigate and ignore the ugliness. 4) People who have used the command line exclusively, especially when they are recent graduates, believe that their approach is inherently better and necessary in order to be a good developer. They get curiously defensive if you expect them to be able to instantly jump to the definition of a method in question or actually use the Strategy pattern.

bluekeybox 14y ago
1) Don't really have a defense for that. Then again, not everyone who uses an IDE and claims they know OOP had had experience with Smalltalk. 2) I have encountered people who used UML/SQL schema diagrams in a cargo-cultish way to prove to themselves and (especially) others that what they were doing was well thought-out when in fact the opposite was the case. 3) That reads more like an argument in favor of Vim/Emacs as superior editors. Also, it seems silly to blame lack of refactoring on editor when it's more of an issue of whether the programmer has a sense of code elegance and clarity or not. 4) I guess hubris is not exclusive to either side.