The #1 thing I hate about IDEs is that they make things that aren't code matter.
One time in Visual Studio I accidentally started a Windows project instead of a command line project. I wrote a completely valid and basic hello world. It did not run when I pressed play. Perfect code does not run because some checkbox somewhere in a GUI is wrong. Fuck that noise.
Ahhh I fucking hate vi(m)/emacs. I try and avoid them as much as I can. I understand that there are people who live by them but most of those people that I've met do it purely because they think it makes them elitist.
The #1 thing I hate about IDEs is that they make things that aren't code matter.
One time in Visual Studio I accidentally started a Windows project instead of a command line project. I wrote a completely valid and basic hello world. It did not run when I pressed play. Perfect code does not run because some checkbox somewhere in a GUI is wrong. Fuck that noise.
That is true, nothing is easier than just using gnu compiler. When you have crazy dependencies they can make your life easier, but that can turn around pretty quickly.
The same issue could come up if you specified the wrong compiler command/options either on the command line or in your build script/Makefile. In this case, perfect code does not run because some command/option somewhere on a command line is wrong. Granted, if it's a trivial hello world program, it's easy to figure out where you screwed up on the compiler command line, but imagine going through build system consisting of multiple Makefiles each hundreds of lines long with build variables scattered all over the place (although this can be mitigated by putting common build variables in a common included Makefile). In this case, both the GUI and the CLI are just as "broken," given your point of view.
One could argue that your issue isn't with IDEs at all, but with compiled languages where arguments passed to the compiler matter. Then again, I'm sure that if you pass the wrong arguments to, say, the Python interpreter or run the wrong version of Python on a system with multiple versions installed, you'd also get an issue where "things that aren't code matter."
Nano ain't bad for quick and dirty CLI stuff. Just remember it's not "standard" (there is a difference between commonly installed and "standard"). Vi is the only "standard" editor that's guaranteed to be available on all Unix derivatives. Well, there's also ed, but no one actually uses that unless their system is utterly, horribly, broken so bad that full screen terminals don't work right.
Read the POSIX standard, which defines what is actually standard Unix. Neither nano nor pico are part of the standard. Just because they are common enough to be a de facto standard on Linux (and only Linux) doesn't mean they are a true standard.
Lemme guess, you've never used anything other than Linux, right? The vast majority of non-Linux Unixes only ship with bare-bones vi as their editor -- everything else has to be specifically installed by the sysadmin, and many don't even bother installing them.
No biggie... and yeah... Emacs, nano, pico, etc., can't be relied on. Only what's in POSIX can be relied on. Fortunately, they are common enough that you can usually use them, but then again, absolute basic vi usage isn't that hard to learn for quick and dirty changes on a system with nothing else available.
Meh, I don't see what the big advantage is of modal editing, and I'm a long time vi[m] user (among other editors. I really don't have any significant editor loyalty). It's just another style of UI that has advantages and disadvantages. I'll say this though -- I love vi's modal editing when I need to do large amounts of search/replace with regexes in a single file. I love it enough that I jokingly refer to it as "interactive sed."
Nano/pico are actually not installed on most production systems out there. vim is expected and used by pretty-much everyone in a production/support role.
X is also usually not installed in these systems. 90% of one's work involves:
Comments
Edit; I had imaged that you guys worked alla Hurt locker in the labs. Would certainly make the job more interesting.
One time in Visual Studio I accidentally started a Windows project instead of a command line project. I wrote a completely valid and basic hello world. It did not run when I pressed play. Perfect code does not run because some checkbox somewhere in a GUI is wrong. Fuck that noise.
One could argue that your issue isn't with IDEs at all, but with compiled languages where arguments passed to the compiler matter. Then again, I'm sure that if you pass the wrong arguments to, say, the Python interpreter or run the wrong version of Python on a system with multiple versions installed, you'd also get an issue where "things that aren't code matter."
I've hardly used an IDE in 14 years and I try to avoid it.
Lemme guess, you've never used anything other than Linux, right? The vast majority of non-Linux Unixes only ship with bare-bones vi as their editor -- everything else has to be specifically installed by the sysadmin, and many don't even bother installing them.
I just said they're not standard. Did you take that for an argument..?
Also my lab uses C++ with Eclipse, so yeah...
C++ with Eclipse? Kill it. Kill it with fire.
X is also usually not installed in these systems. 90% of one's work involves:
1. tail
2. grep
3. vim
4. sed
5. find