Programming - Hold Still, This Won't Hurt a Bit

Well, Linux/Unix is not meant for the joe-average desktop user. It was meant to be a hacker's toy, and nothing more, so it must be really awesome as a development environment! Well, it has some issues. Linux development may have improved since the Unix Haters Handbook was published, but it still has a long way to go. In this next user-submitted rant, we will see what the issues are.

I have to say that I love a good IDE (Integrated Development Environment). A good IDE should have a logical, easily-navigated UI to create applications. The UI should allow the enduser to easily enter all of the data needed to compile/link the app, and the IDE _should_ do whatever needs to be done to successfully invoke the compiler/linker to create the app.

An example of a good IDE that does exactly that is Microsoft's Visual Studio. It uses fully complete wizards to guide the process, and its underlying tools are well integrated with the IDE. It doesn't use extremely fragile, intermediary text files full of various macro languages to achieve the creation of a "project". When you finish the wizard, Visual Studio directly creates the needed makefile for you. It's easy and painless to develop Win32 apps using MS tools.

An example of bad IDEs that don't do this very well are Linux IDEs. The IDE "wizard" takes you only half-way gathering all the info it needs, then it runs some very poorly integrated (if one could even describe a unidirectional, textual pipe as "integration") GNU tools which, too independently of the IDE, try to analyze your system and come up with the remaining necessary info to create the makefile.

It's painful and difficult to develop apps with a Linux IDE.

A big part of the problem is that the IDE uses a lot of the GNU tools (autoconf, automake, etc), which strive to create "universal" dev files that take into consideration every possible configuration quirk of the thousands of Linux distributions made by Tom, Dick, Harry, and their dogs Spike, Fido, and Spot. But this is a nightmare for a newbie who wants to just compile, link, and run his C/C++ program on his single installation of Ubuntu. He doesn't need to take into consideration some quirk of "Martian Christian Linux", yet another pointlessly trivial variation of Linux which, for god knows what reason, is supposedly better for Martians who also happen to be christians. The GNU tools spewout a plethora of dev files that are humanly unreadable and uneditable by all but the extraterrestrial beings who devised the incomprehensible, needlessly convoluted alien "language" that these tools use. This is bad news if you need to hand modify one of these files because the IDE didn't quite get something right (and believe me, it's a good bet that IDE's "output window" will demonstrate blissful
ignorance as it chuffs out autoconf error messages telling you to hand edit your configure file to add this or that). The IDE isn't smart enough to parse the error output of the GNU tools and follow the instructions given to you, even though it's supposed to be the job of a good IDE to maintain and "edit" the underlying compiler/linker support files instead of telling you to do so. Otherwise, what's the point of an IDE?

With Visual Studio, I never had to actually hand-edit any makefile, nor create _any_ other convoluted text file containing any kind of "macro/shell language" for the purpose of creating a make file. I never had to, because the IDE was capable of completely managing the makefile via data that I entered exclusively through the UI. I don't need to remember what the "text flags" are to enable various compilation features, because the IDE's UI is actually useful (as opposed to just a thin wrapper over some hideously designed, command line tools that use their own "logic" to determine what "text flags" ultimately get passed to the compiler/linker).

If you go to the GNU website, you'll find tons of "manuals" that explain to you in excruciating detail what each tool is for, and how it works. Here's a URL to get you started on your quest through dozens and dozens of barely comprehensible (and almost pointless) pages of instructions:

http://www.gnu.org/manual/manual.html

Now I suppose someone can write even more detailed tutorials than these pages, and take you along the way at a slower pace (although it would probably take a person a few years of work to come up with such a volume of text), but here's the bottom line:

These are very complicated, convoluted, and frankly, unintuitive tools to use. You can read all these manuals until your eyes fall out, and your brain can maybe retain enough of the voluminous details of each tool such that you'll actually be able to do something useful with them, maybe even on a daily basis (but with a stiff penalty against productivity as you spend too much time plowing through the voluminous GNU docs just to figure out how to enable/disable even one compilation feature). But they will never be easy to use. They will never be as easy as .NET. Never. They will never be half as easy as .NET. They will never be a quarter as easy as .NET. These tools are designed to take into account so many variables/installations/quirks in the entire Linux universe, that they can never be anything but tremendously complicated and convoluted and unintuitive. Think about it. Someone somewhere at this very moment is taking a Linux distribution, and for god knows what reason, changing one damned thing about it supposedly to make it better, and releasing yet another distribution. And now the GNU toolshave yet one more quirk to take into consideration. Let's see, shall we accomodate it by making yet another "implicit rule", or maybe a "macro", or how about an "environment variable"? How about all 3 of them? Hey, it's free software so it's not like you have to pay 3x as much for 3 different ways of doing the exact same thing, plus a doc file that grows 3x as big in order to explain the 3 different ways to do the exact same thing. And wait, this is getting really hard to use what with all this stuff heaped on top of it. So let's make another utility that spits out a bash script that makes the data file needed by the first utility. And of course, let's not make this second utility UI based, with
graphical controls the programmer can click on to select his features, and enter filenames, and such. No, let's make this second utility text-based just like the first one, so that you need to learn yet another "macro/shell/syntax language" and have even more data files to keep track of. And of course, as more and more deviations happen in the Linux world, we'll add stuff to this second utility too.

Finally, someone gets the idea to make things "easier" than those tools. What does he do? He makes another text-based utility of course, with yet another macro/shell/syntax language that tries to cover the exact same ground as the first set of tools. Yep, this one is going to be all things to all people too, but somehow it's going to be better. Now we have two tool sets that essentially do the same thing, and even in essentially the same way, but they're different for the sake of being different. But wait. Now we need to transfer data between the two of them, so we need to make a utility to do that. And no, let's not make just one such utility. Let's divide our resources making dozens of them,of course all of them command line tools (do Linux compiler writers even know what a GUI is, and how event-driven programming works?) each one doing essentially the same job, but in an arbitrarily different way that will somehow mean that support personnel will have to deal with yet more quirks/inconsistencies/variations on the exact same theme.

Madness. Sheer madness.

You've got autoscan, which generates a text-based configure.scan file. Then, you've got automake, which takes a text-based makefile.am file and generates one or more text-based makefile.in files. Then, you've got autoconf, which takes a text-based makefile.in, and text-basedconfigure.am file, and generates a very convoluted, text-based configure file. Then, the configure file generates a whole boatload of other text-based files. And each text file is filled with lines written in its very own, exclusive Martian dialect, with no set order in which information appears.

You're an intelligent being capable of easily reading text and applying deductive reasoning to it. A computer can crunch numbers fast, but it's not so good at deductive reasoning and making complex choices by analyzing freeform text. If you can barely make sense of the above tools and their output, what luck does an IDE have?

The problem isn't necessarily that an IDE is riding atop of text-based tools. Microsoft's Visual Studio does that too. The problem is that an IDE is riding atop of a whole mess of text-based tools that churn out way too much information, in a format that is way too free-flowing, poorly structured, and involves way too many "script/macro languages" that are totally unrelated to the language your app is developed in, all for the sake of trying to be all things to all people from the ancient past (in computer terms), to now, to the day that the last Linux guy ever forks another package and therefore causes another inconsistency to accomodate.

These dev tools are so complicated that even the IDE that tries to make them easier, is itself convoluted, complex, unpredictable, unstable, and ultimately unintuitive.

For god's sake, will some competent programmer please fork gcc, and fix this thing so that it actually is capable of _integrating_ with an IDE? Fix it so that it doesn't require the IDE to use "auto tools" that spew heaps of incomprehensive script files written in a variety of Martian and Venusian languages. Fix it so that when the IDE and these auto tools invariably "break" your project, you don't have to waste hours trying to hand-edit all those Martian-language data files, to get them to work again, until you finally throw up your hands in frustration and nuke the entire directory of unusable poot and restart from scratch (with Visual Studio and Microsoft's compiler instead).