Someone commented on how poor Linux-based systems must be as development environments compared with MS Windows, after (s)he gained the authoritative experience of spending probably three hours playing around with Ubuntu or some such nonsense.
Someone else commented as follows (and this is where the above link actually leads):
In general the text editor and GCC or interpreter is all that is needed for any language. I’ve not met many windows programmers that have the old-school skills to pop open Dos Edit write code without the Studio crutch. (I’m learning to do that myself though with simply .vba coding where applicable.)
Here’s what I started typing as a response, and eventually realized was long enough that I should just post it as a stand-alone, um, thingie:
Making good use of an IDE is an acquired skill set. It is not, as people who’ve done no programming without one seem to think, just a bunch of automatic “programming is easier now” features. There’s an approach to programming that relies on using an IDE, and an IDE being useful depends on that approach to programming.
Also notable in evaluating the use of an IDE is the fact that IDEs are specifically designed to make certain programming activities easier that are particular to certain types of languages. Java, VB, C++, and C# are all languages that not only benefit a hell of a lot from a well-designed IDE, but effectively require a well-designed IDE to achieve an acceptable level of productivity (though C++, being notably closer to C than the others I listed, is less tied to IDEs in that respect). Part of the reason people often consider IDEs indispensable to development is the fact that they do all their programming in verbose object oriented languages like Java and C#, where great quantities of boilerplate class hierarchy code must be written on a regular basis, to say nothing of needing to alter those class hierarchies as one goes. Without an IDE to ease the process of generating and maintaining those class hierarchies, the volume and complexity of the code involved would quickly overwhelm otherwise productive coders on large-scale projects.
Meanwhile, on Unix-like systems, most of the programming is done in languages such as C, Perl, Lisp, and Ruby, as well as various shell languages (bash, tcsh, et cetera). These are languages that don’t benefit as much from a “traditional” IDE. The lack of benefit, however, is not a result of some failure of the language — it’s a result of the fact that IDEs were essentially invented and developed for the purpose of making it easier to work with the challenges particular to verbose object oriented languages like Java and C#.
Technically, I think it was a flavor of BASIC that had the first IDE, though the “IDE” developed for it wasn’t something that would be recognized as an IDE by today’s standards. That IDE was basically just a single interface for a set of basic tools (filesystem browser, editor, debugger, and something vaguely like a code execution shell). A transitional version of an IDE, halfway between that IDE for BASIC and something that would be recognized as an IDE today, was actually a (language agnostic) CASE tool called Softbench, which ran on UNIX and employed a plug-in architecture for extensibility. As such, if anyone tells you that you can’t get good IDEs on Unix-like systems, you might want to point out that the father of the modern IDE was invented for commerical UNIX (circa 1990).
These days, the most highly regarded IDEs appear to be Eclipse and Visual Studio. Eclipse runs on pretty much any OS, including Unix and Linux-based systems.
. . . but there’s the matter of these languages that don’t really need an IDE. Many of them are actually supported by high-quality IDEs. For instance, Eclipse offers support for Groovy, Perl, PHP, Python, and Ruby — and even typesetting languages like LaTeX. This, despite the fact that people who have primarily worked with such languages for a long time (as opposed to working mostly with something like Java, and occasionally needing to do a little tinkering in something like Perl) actually find IDEs too cumbersome and limiting.
That’s really the problem: people who have done all of their development on MS Windows using various incarnations of Visual Studio, with languages like C#, cannot imagine doing any “serious” development without an IDE because all the develoment they’ve done involved working with Microsoft libraries (MFC or .NET, generally) and Microsoft GUI development, and using languages like C# and Visual Basic (or Visual C++, for the “old timers”). Under such circumstances, you really do need an IDE, and because of the fundamental necessity of what an IDE provides, they never realize that there’s not only a helpful aspect to such IDEs, but a limiting aspect as well.
That limiting aspect becomes incredibly obvious if you haven’t really used IDEs much and have worked with languages that don’t impose the challenges upon the developer that make an IDE necessary. If you started out your development with shell and Perl, eventually learned to do system development in C and assembly language, and for scripting and high-level development eventually moved on to Python and Ruby, never having had any use for an IDE, using one would initially feel like being forced into a
straight straitjacket. More to the point, such experience with development might lead you to regard the code generated through the use of a modern IDE to be really atrociously written code. It would probably take a while to realize the importance of an IDE for working on large-scale projects in languages like Java, since you’d be used to being at least as productive without an IDE working on large-scale projects in languages like Ruby.
. . . but wait, there’s more! There’s this so-called “text editor” called Emacs which provides much of the same capabilities as an IDE, but with a very different approach to how tools are integrated. Furthermore, Emacs is particularly good for Lisp development, as it has been adopted as essentially the unofficial official IDE for Common Lisp, and has thus received a lot of loving attention from Lisp developers who have extended and improved Emacs’ Lisp-oriented development support features. GNU Emacs is even written in Lisp, and extended with Lisp.
Emacs certainly isn’t necessary for Lisp, or any other language, though. One of the most famous Lisp hackers in the world — Paul Graham — is a devoted vi user.
Vi was the editor created by Bill Joy when he assembled the original Berkeley Software Distribution of Unix, because he decided it needed a good editor. In a manner somewhat similar to the way Emacs (then EMACS) was originally created as extended functionality for TECO, so was vi originally created as extended functionality for ex, and the two came out at about the same time. Their respective user communities have basically been engaged in an ongoing religious crusade against each other ever since (though a mostly friendly one, believe it or not). The vi editor has since been forked and extended in many different ways, but the most widely used variant today is almost certainly Vim — which is my favorite editor. In fact, I’m typing these words into an instance of Vim right now.
Vim is more like an actual text editor than an IDE. In fact, calling Vim an IDE would be a disservice to Vim, in many respects. While Vim is probably not an adequate replacement for Visual Studio by any stretch of the imagination, when writing code in C#, Visual Studio is not by any stretch of the imagination an adequate replacement for Vim when writing code in Perl. Vim doesn’t come with class hierarchy boilerplate code management features the way VS does, but by the same token VS doesn’t provide the incredible productivity enhancing editor interface you get with Vim. Once one has become sufficiently familiar with the way Vim works, in my experience at least, productivity when writing code in a high level language such as Ruby or Perl, as well as when writing essays and articles in English, increases by between 50% and 300% — and the productivity enhancement increases with the complexity of the project, so that it probably gets even more impressive working on projects of a scale greater than my usual range, as long as you’re using a language better suited to Vim than to VS or Eclipse.
straight straitjacket in Vim, but there’s no comprehensive class hierarchy management either. I do essentially work in an IDE-like environment when developing on my BSD Unix laptop, but it’s not really an IDE as you’d probably recognize it: Unix is my IDE, as I run a group of basic tools all in the same workspace, each in its own terminal emulator window.
Before anyone points it out, as though it disproves something I said, I know you can get a Vim knock-off installed as your default editor for Visual Studio. It’s not quite the same, though — just as using gVim on MS Windows isn’t quite the same as using console-based Vim in a terminal emulator on FreeBSD or Debian GNU/Linux. It really is a poorer experience, to some degree, and that relative paucity of productivity enhancement is magnified when a vi variant is shoehorned into a
straight straitjacket IDE like Visual Studio. I’m sure it improves development productivity for many C# developers, but moving from pure Vim to VS with a vi-like editor plug-in would be a definite step down in productivity for a serious Ruby developer.
So . . . if you think MS Windows is a better development environment than something like FreeBSD or Debian, just because it has Visual Studio and Unix-like systems don’t have it, that must be because you think all development must be like C# and VB development. In fact, it’s probably true that most development isn’t like C# and VB development that way.
Expand your horizons a little. Learn to use Vim or Emacs, then spend a year doing serious development in something like Ruby instead of C# or Java, and do it in a Unix-like user environment. When you’re done, compare that experience with the idea of doing Ruby development in Visual Studio on MS Windows (or, worse yet, in Notepad), and you may find yourself shuddering in disgust at the thought. You may even not want to go back to C#.
In any case, judging the development environment of Unix-like systems by giving a Unix-like system a cursory glance and thinking about how (un)fun it would be to develop C# in a text editor like Kate is not going to give you anything like an accurate view of the actual Unix development experience.