Are GUI Dev Tools More Advanced than CLI Counterparts?

JohnG inputs: "I just got into quite a long argument over on the Yahoo! message boards over the power of command line dev tools. Basically the guy told me that it is impossible to create 'state of the art' programs with command-line tools. But when I asked him to give me reasons why he just called me stupid and 'behind the times'. Considering he was an avid supporter of anything Microsoft, I take what he says with a grain of salt. But what I want to know is how many of you developers have switched from command line work to KDevelop or CodeWarrior? And what advantages you think it offers? Certainly there are many 'state of the art' apps created with command line tools, but I'm open to anything that can increase productivity. I've just never seen a compelling reason to make the switch from what I am used to and comfortable with." Personally, I feel the best development environment to work in would be one that ignores neither the GUI, or the command line.

Comments

Neither

[Biff Grande]

I don't think either is really more powerful. It is just a matter of personal preference. A GUI tool might help to visualize your application's structure, but that is about it.

GUI cvs Command

[OmegaDan]

GUI apps are impossible to automate, run from crond, pipe information in and out of ... this is why they will always be needed in unix, this is why they ARE needed in widnows ...

Window's answer to crond is every program that needs to schedule something includes its own task bar scheduler that eats 5 megs of ram. And you'll notice those programs execute command lines as well (ie. nav /scanall), because a command line interface is the *ONLY* conveniant way for one program to manipulate another.

Re:GUI cvs Command

[keesh]

Seen what you get with Delphi (and Kylix for that matter)? There's the nice cute GUI, sure, but you still get commandline compilers, resource builders, linkers and so on as separate apps. You can, of course, pipe and so on...

This gives you the best of both worlds -- use the GUI when you want to design interfaces, ignore the gui and just stick to the commandline tools when you want automation.

Borland's C++Builder also has separate commandline tools (and pretty primitive grep and make...) (which, incidentally, are free for download but not quite Free).

Re:GUI cvs Command

[sahala]

Window's answer to crond is every program that needs to schedule something includes its own task bar scheduler that eats 5 megs of ram.

Maybe this is the case for Windows 95/98/ME, but with NT and 2K you can have services, the at util (cron-wannabe, but not nearly as robust), and the for-dummies Task Scheduler (a pretty interface for AT). You don't need to be throwing things in the task bar.

You're right about the power of automation and scriptability that command line provides -- this is an age-old plus for the *nixs. Personally, I'm all for the software build and testing to be command line driven. It can be automated and the output stuffed wherever the hell you want it. Hell, even have it page you when shit happens.
As for the coding, unit compiling, etc I believe people should be able to use anything they want, whether it be Emacs, VI, Visual Studio, Codewarrior, or whatever, so long as it conforms to the build requirements. I really couldn't give a shit whether a java class was made in J++ or assembler, so long as it compiles and tests under the build system.

The IDE's just wrap command line tools still

[joshtimmons]

If I understand the claim correctly, it's that one needs a GUI development tool to produce a modern application. I've worked for quite a while with various IDEs as well as plain makefiles and have never noticed a productivity difference.

One of the reasons the claim confuses me, though, is that tools like KDevelop and, even MSVC, do still run a command line compiler. All that they do is manage the "makefile" or whatever underlying build engine the IDE is using. So, it follows that anything built on such a system can be built with both command line tools and from the IDE. This is true of all the java, C, and C++ IDE's that I have used.

There are some places where IDE's have enhanced my productivity, but they tend to be editor related and aren't really applicable to the command-line tool vs GUI. They are:

1. Automatic completion of symbol names and displaying parameter lists for functions as I write code to call them.

2. It's been several years since I have hand-coded a static form or dialog box. For this activity, I find a form builder quite handy. (Dynamically built forms are another matter).

But, as I said, these features don't require a GUI development environment. Just because I don't have a C++ editor under unix that does these things doesn't mean that command line tools aren't capable of producing serious apps.

Anyway, I ramble. The bottom line is that the tools you mentioned are all wrappers around those command line tools that supposedly can't do the job. The project management is nice, but a well-designed makefile is just as quick to work with.

Re:The IDE's just wrap command line tools still

[dachshund]

One of the reasons the claim confuses me, though, is that tools like KDevelop and, even MSVC, do still run a command line compiler

Amen. Many of the modern development environments are just wrappers. Although there are IDEs out there-- Metrowerks, for instance-- that don't rely on this crutch, even those environments rarely have significant added functionality vs. CLI tools (though the fully integrated tools at least seem more carefully put together than the wrappers like MSVC++). One of the worst things about these wrapper tools is that the GUI generally lacks a complete interface for controlling the really esoteric options; MSVC++ just punts the problem and forces you to enter them into a text box. Big improvement over CLI there.

While it's possible that GUI tools are potentially capable of doing more than CLI tools, none of the tools in common usage today really make this case. I admit that it may be easier to learn to manage a project using a visual tool, but that's not what this debate is about. I'll wager that somebody with good CLI experience can do everything an equally experienced GUI-tool user can do, in the same amount of time. They might even find that they have more flexibility at their fingertips.

Now, when it comes to interface design, GUI tools can be very helpful. But in most "IDE"s, even the UI design features tend to be poorly integrated. Often they're implemented in clumsy, inflexible ways that make them little more useful than their standalone counterparts. And the fact that so many people use the IDE seriously handicaps the development of better tools by third parties.

It Depends on the Team

[quakeaddict]

Lets face it some people like to click buttons that are poorly documented and others like command line switches that are poorly documented. :)

At some point someone is in charge of the builds, and whatever that person likes we all get. If that person does their job right its easy regardless of what your preference is.

One thing is for certain, it doesn't make sense anymore to build GUI's without the help of a drawing tool that automates that tediousness.

Depends on what you want them for

[samael]

For what I do, which is production of front ends onto databases, GUI is invaluable.

Being able to drag and drop items onto a form, set a few properties, add in a few bits and pieces of code for unusual circumstances and validation, and just run it, is great.

For device drivers and command line programs, it may not be nearly as useful.

Of course, I find some facilities (like syntax highlighting, procedure finding, and multiple debugging windows) absolutely essential too, and would probably miss those if I didn't have a decent IDE.

The much-maligned command line

[Xpilot]

I've observed something over the years, and that is the command line is hated beyond measure by mainstream trade press and MS fans. For MS, removal of DOS was a good thing because it removed the command line, which is evil (DOS sucks,of course, but not because of its command line interface).

I've been using a CLI to program and generally do OS stuff for years and years, and I've found some Windows-lovers attitudes more than just a bit annoying.

"Command line??? How primitive! Look at all the colorful and pretty pictures I have on my desktop, you dirty UNIX user!"

I hear comments like that a lot. From CS undergrads too. What brought about this attitude? I put the blame squarely on MS. Even Apple has a decent CLI shell now with OS X. MS is so busy harping its wonderful pointy clicky interface and the clueless world follows suit.

UNIX will always exist, but Windows runs the IT world. At least where I live.

Re:The much-maligned command line

[daviddennis]

They didn't get rid of it, not even in XP. You have to look to find it, but it's in there, buried.

Actually, just check out the properties of a pretty Windows icon, or even an ugly one, and you'll find a command line right there. CMD.EXE isn't going away any time soon.

D

Re:The much-maligned command line

[Admiral Burrito]

I've observed something over the years, and that is the command line is hated beyond measure by mainstream trade press and MS fans. For MS, removal of DOS was a good thing because it removed the command line, which is evil (DOS sucks,of course, but not because of its command line interface).

I disagree here. A significant amount of DOS's suckage comes from its primative command line interface. "Back in the day" most people didn't care about multitasking, but the annoying C:\> prompt was dreaded by most users.

Consider:

• Command-line editing sucked. The arrow keys did not work like in a real editor. All you could do was backspace to your typo, fix it, then re-type everything you missed.
  
• Limited command history. Press F3 to bring back the previous line, then use backspace as described above. Alternatively, there is a way to bring back the line one character at a time, then you can type onwards, or press the Insert key exactly the correct number of times to match the number of new characters you want to insert before bringing back the remainder of the line.
  
• Doskey fixed the above two issues, but on most systems it was not loaded (probably due to ignorance). It also came around about the time of Windows 3, by which time hatred of the command line was firmly entrenched and many people were using menu-based shells to escape the torment.
  
• Filename globbing is handled by the command, not the shell. And most commands were not very smart. In unix shells, you can do "cp *.foo *.bar /some/directory" because the cp command just wants a list of files with a destination as the last argument. The DOS copy command, on the other hand, only accepts two arguments. So you have to go "copy *.foo \some\directory" then "copy *.bar \some\directory". The more complex globbing and substitution commands availble in unix shells were totally absent in command.com.
  
• Scripting sucked. All you could really do was concatenate a few static commands into a .bat file. Looping and conditional operations existed, but making them do anything useful required ugly/clever hacks that were beyond the ability of the average user and even most technical users.
  

Given those issues, and the fact that most PC users at the time were running MS-DOS and forced to endure the torment I have described, is it any wonder that CLIs are considered "primative" by the majority of the population?

Add to this the Mac. Most offices were PC based due to compatability requirements and investments in PC software, but many people could stop by schools or computer shops and have brief experiences with Macintoshes and be wowed by the pretty GUI and how easy it was to use compared to DOS. Those who couldn't, could hear stories from those who could. Is it any wonder the majority of the population considers GUIs to be the best way to interact with a computer?

So it is my theory that the 100% GUI / 0% CLI attitude, rather than a more balanced "right tool for the job" approach, is the consequence of historical Mac envy.

But it's just a theory.

GUI's are easy to learn, but never efficient.

[MongooseCN]

GUI's are easier to learn because all the options are laid out in front of you. You can click through menus and scroll bars and see all the options available. This makes it very easy to learn. Eventually though you will know all the capabilities of your editor, but you will still have to click and move through menus and graphics to get to what you want.

CLI tools are the opposite. They are hard to learn, but once you know them, they are fast and efficient. Vim is a perfect example of this. The editor is simply amazing. It has a keyboard interface to do nearly anything you want to do. The only problem is, it's very very difficult to learn. You don't know what all your options are. You have to goto :help and start searching for something simliar to what you want to do. But once you know the basic commands, it becomes easy to find other commands for something you want to do.

Here's a nice cryptic example. What's a fast way to find the include file for a function? Browsing through help files, searching for the command and cutting and pasting the include in? Or this:
:r! man ntohl | grep "\#include"
Ya, I thought so too. =)

Re:GUI's are easy to learn, but never efficient.

[Webz]

I agree with you, but you should revise the title. It isn't a matter of GUIs never being efficient, since it depends more on how familiar an interface is. Keep in mind that keyboard accessible GUIs can operate much faster with a keyboard than with a mouse. Unlike Apple, Microsoft has done a great job making nearly every aspect of the operating system accessible via keyboard. Once you memorize all of the shortcuts and such, its just as good and as cryptic as a CLI, sometimes.

Re:GUI's are easy to learn, but never efficient.

[cpt kangarooski]

Don't make incorrect absolute statements like this; it's annoying.

CLI's are quite inefficient when you need to do a lot of typing. E.g. if you were moving files to a path that was very long; where you have to perform operations on files that can't be selected through grep b/c there's no common rules that are applicable.

Besides which, in the real world, the time you waste trying to remember some cryptic argument and how to use it IS a factor to be weighed.

CLI's have their uses, as do GUI's. Far better for them to augment each other (e.g. right-clicking on a CLI command to select from a list of argument options with their full names; selecting files spacially with the mouse and renaming them with wildcards) than to persist in maintaining a wall.

As for the comment below re: keyboard shortcuts, testing reveals that they are for the most part slower than using the mouse. People don't consciously realize it, but unless the command is incredibly common and ingrained as only a few are, they pause and try to remember it. It's objective testing has revealed this - not people's subjective senses of time.

English to E Translator

[Shoeboy]

My undying passion for the lovely Heidi Wall has made me quite the perl hacker. I've gone so far as to develop a little program I call e2e.pl, the English to English Translator. This nifty app lets me translate what people say into what they mean. Let's apply it to this article:

I just got into quite a long argument over on the Yahoo! message boards over the power of command line dev tools.

Translation: Traffic at the helpdesk was pretty slow, so I was wasting time bragging about my 1337 coding skills and Lunix prowess on Yahoo.

Basically the guy told me that it is impossible to create 'state of the art' programs with command-line tools. But when I asked him to give me reasons why he just called me stupid and 'behind the times'.

Translation: Another helpdesk monkey pretending to be a 1337 programmer started flaming me. I flamed back, but I was outflamed and couldn't match his fluent profanity.

Considering he was an avid supporter of anything Microsoft, I take what he says with a grain of salt.

Translation: I called him an "asslicking Micro$oft whore," made some cracks about VB programmers and impotence and retreated.

But what I want to know is how many of you developers have switched from command line work to KDevelop or CodeWarrior? And what advantages you think it offers? Certainly there are many 'state of the art' apps created with command line tools, but I'm open to anything that can increase productivity.

Translation: I know that slashdot is packed with gifted flamers and CLI enthusiasts, so I was hoping you could give me some good ammunition before I rejoin the fight.

I've just never seen a compelling reason to make the switch from what I am used to and comfortable with." Personally, I feel the best development environment to work in would be one that ignores neither the GUI, or the command line.

Translation: But I'm not honest enough to admit that I'm looking for ammo so I'll wind up with some lame ramblings about productivity to make it more palatable to the /. editors.

Well, I think that clears that up.
--Shoeboy

Bigotry makes for sub-optimal programmers

[ben_tarval]

There are times when CLI tools are superiour And there are times when GUI's
are superiour. If you don't know when each is best used, and how, you are
not up to your full potential as a programmer.

Personally, I believe in keeping an open mind, and using the best tool
for the job. This allows me to do the best job possible.

Now then, ask your bigoted friend if he does anything less. If this doesn't
shut him/her up, then his reply will be most amusing.

Different, not more advanced

[proxima]

The difference between GUI development tools and command line development tools is fairly minor. In many cases, the IDE (Integrated Development Environment) simply brings together a large collection of individual utilities for convenience. This happens in the Windows world with Borland's C++ compiler and their IDE. In the *nix world gcc (and other compilers), as well as debuggers, possibly code-completion (usually only found within the IDE), class browsers, etc, are brought together into one package that allow for faster development of applications.

KDevelop and KDE Studio are two examples of this. The "tools" are really the same - they just offer a GUI interface to several command line utilities. I cannot speak for KDE Studio, but I believe KDevelop is working on good cvs support for a complete approach to shared development. To my knowledge some of these features are already implemented. Also, a GUI based IDE will almost ceretainly have good syntax highlighting.

However, one does not need to use a GUI to get colored code - vim and Emacs/XEmacs offer this from the command line.

In my opinion, development can take place faster and debugging more easily with an integrated environment compared to ed+gcc, but this should be rather obvious. This does not make IDE's (both GUI and terminal based ones - IMO Emacs is an IDE once you configure it properly) more advanced - just more convenient.

The nice part about developing with *nix is that you can use a wide variety of tools, even on the same project. Use what you are comfortable with, and ignore those who say your technique is flawed - everybody has their own way of doing things efficiently. With MS Visual C++, you are basically stuck with their IDE and you better like it.

Choice is good, use what you like.

It's all the same, really

[trentfoley]

Personally, I write my programs in various flavors of assembly on paper with pencil. I then hand assemble, again on paper, but I use pen instead of pencil. Then, I use a machine-language monitor to directly enter the op-codes to ram, either in hex or octal (binary is just too primitive!). This is the only way I truly know what the processor is doing.

And, if you believe that, I have several priceless family heirlooms to sell you.

Re:Know any good Win32 CLI C++ compilers?

[Anonymous Brave Guy]

No-one seems to have mentioned Comeau C++ yet.

Greg Comeau is a regular contributor to C++ newsgroups, and I've had some personal communication with him in the past. He obviously takes some pride in his product. From what I hear, it's justified; the output it produces is good, and its compliance with standard C++ is, and always has been, at the head of the field. For example, it gets a credit in Alexandrescu's "Modern C++ Design" for being sufficiently up to speed that it can use the Loki library's template tricks, and they're predicting the all-important "export" support by the end of this year. Perhaps most important, Greg seems open to comments, and willing to proactively improve the product.

The big problem used to be lack of a standard library implementation, but I believe it now ships with the latest Dinkumware libraries (as used in VC++, but a much more recent version without the irritating flaws). It should also be noted that this is a commercial product, although Comeau Computing provide a free "try it out" facility on their web site.

I have no association with Greg Comeau or Comeau Computing other than having spoken to Greg in the past and found him to be a good guy.

IBM Visual Age products...

[RGreene]

We've been using Visual Age for Java (VAJ) at work for nearly two years now -- and it's really awesome. I hate to say it, but I'd prefer to stay within Visual Age instead of the command line. I was/still am a command-line jockey, obviously in Unix, but also in Windows.

From my quick skimming of the responses, people miss an important point: most tools (visual or otherwise) seem to require a compile to identify and fix errors - just general typos. VAJ not only does incremental compile of whatever method you are working on, but it also keeps all classes in synch. Huh? As I code, I'll code a method I know won't be correct. It'll show a funky red 'X' next to the method. As the methods and attributes get finished off, the 'X's go away. Not too much of a big deal, since that is within one .java file. However, that is working across all classes that are loaded in the workspace. Realtime. As you type it. Wanna rename a class? Not a big deal - I save, look at the errors tab, and I can edit right there, change the name. Actually, the tool will do the rename also. But, anytime a class is restructured (renamed, moved, split, combined, removed, etc) you just pop to the errors pane and fix. Not a big deal. You know the impact immediately.

Every piece of code is versioned. Down to the method - really cool if you've messed up a method and need retrieve a prior edition. You can compare different classes, different editions of the same class or method. Locate all references of a method or of a class or all implementations of an interface.

This tool was originally developed for Smalltalk, so it's geared for those of us doing OO. But, it's extremely useful. There are versions for C++, Java, Smalltalk, ... even RPG (ug). Unfortunately, the only trial edition available is for Java -- I use it at home I love the tool so much. It's also available for Linux, but unfortunately, that version is behind the Windows tool. The Entry edition (aka trial edition) is not time-bombed or anything - just limited to 750 classes that you add. That's quite a few, to be honest. And, as projects complete, I think you can just drop them off of the workspace and that resets the 750... although the basic edition costs less than $200.

Oh yeah, I'm not doing GUI development. Web development - a lot of it is framework (persistence, control, etc). Other developers are building messaging components (MQSeries). Just as an FYI that I'm not doing GUI drag and drop development. Not at all!

For those of you doing Java - bounce to IBM's site and try it! Give yourself some time to adjust... the big difference is that all code is housed in the repository. It doesn't sit in the filesystem. This is not a bad thing -- it enables all the cool features that make VAJ unique. You can export or import Java code - JAR or file system - when you need the Java source. You can connect to many types of version control software if you want or need to (I use CS-RCS).

The next version of VAJ will be called WebSphere Studio Application Developer. This will work from the filesystem - this will probably be good for the general acceptance of the tool (IBM kept getting clobbered in reviews because of the repository). However, I have a slight fear that this may end up removing a lot of the features that make Visual Age for Java such a strong development tool.

IIRC, Visual Age for Java won the Jolt award in 2000 and WebSphere Studio won it in 2001.

Re:Thing is....

[MxTxL]

Actually.... I could. Depending on the subject matter, for many 3D models I can get something nicer done more quickly by 'coding' it directly in POV-Ray [povray.org] script. This of course depends on the subject matter, but just because one person finds one way faster doesn't mean that another person won't be faster a different way. Just sometimes I'd go with 3DS or Strata, other's I'd just code by hand. And sometimes I'd write a custom C program to make the model. It just all depends.

My point exactly, some people CAN do it, and prefer to. Some physicists can also do advanced calculus in their heads, some pilots can fly around the country without using any navigational aids. It's easier and more convenient for these people, like you claim. The real point is not whether it can be done or not, but rather WHO can do it. You will find that the vast majority of people prefer to use the tools that are available to solve a problem.

When I mentioned that you would not program a complex model (i'm thinking along the line of the chick from Final Fantasy, or even just the SIGGRAPH teakettle, anything more complex than several boxes and triangles and quads) using code I was bringing up the use of tools. You would not use a sharpened stone to cut something if you had a knife lying around. You would not use a stone to drive a nail when there is a hammer, would you? Of course not.

Actually.... I could. Depending on the subject matter

You could, I could too... if I put the thought into it. There is a right tool for the right job. Any physist is smart enough to do the calculus in his head, but the vast majority of them are also humble enough to know that actually breaking out the old calculator once in a while isn't a sign of weakness.

My main realm of endeavor is web programming, I've done some stuff with some websites that I can't believe I was able to pull off. PHP, PERL, ASP, whatever, I can do it and well. When it comes to the HTML output of my scripts, I can code HTML like it was english. I can make tables, forms, anything. Does that mean that I'm too elite to whip out the trusty old Dreamweaver? No, I'll still break it out for fragments of what I need. Why? I could do it by hand. Probably just as fast, but messing with that crap while making it look right distracts from my real purpose of scripting. I use the tools that are available. Some tools are better suited for certain jobs. Thet people that say I will never use a GUI development tool because I can do it all in Vi are missing the big picture.

GUI cvs Command. Why not have both?

[robinjo]

I've spent a fair share of time programming with CLI tools. One time I even wrote PC software remotely on Amiga complete with handcoding all the graphics. While you can automate a lot the question still is, why bother?

As someone already pointed out in this thread, Delphi gives you both GUI and CLI tools. The GUI is just great when you're developing. Draw your graphics, set properties and doubleclick controls to write code. Especially debugging is fast as you are automatically sent to the error place. I just can't see why this would be a bad idea?

The GUI sucks when you have to automate something, though. Like compiling customized executables from a set of patches. Visual Basic sucks especially bad here but Delphi shines again as it's command line compiler is excellent.

So don't argue which one is better. Have both and use the right tool for the right job.

What about UML modeling tools?

[Mindbridge]

Most of the people here seem to equate GUI development environments with RAD tools for fast building of UI forms (dialogs, etc). [I do not mention the "IDE aspect" here, since few would call Emacs a GUI tool, but it can be a full featured IDE nevertheless]

There is another class of GUI tools, however, that allow you to incorporate UML diagrams within your design and development process. I guess that the two programs that best represent this class of "modeling tools" are RationalRose and Together.

RationalRose is more popular, since it was out first, and essentially set the standard, but it supports only a one-directional process (unless that has changed recently) -- design your UML diagrams, and generate code from them (some OO people actually see this as an advantage, but that's another discussion).

Together, on the other hand, is bi-directional -- it constantly updates the UML diagrams to keep them in sync with the code you are writing. As a result it has the neat property that you can actually write your code w/o going through the UML modeling/design stage, and yet you get complete UML diagrams of the code when you are done.

Personally, I am ambivalent about the utility of RAD tools for building GUIs -- they can be great for quick prototyping, but on the other hand they tend to produce code that is not very maintainable and thus not too suitable for large commercial application (although a lot of people are so used to them, that it is hard for them to see the alternatives).

On the other hand, UML modeling tools can be tremendously useful, especially in team environments. A picture is worth a thousand words, and that is very true even in programming. Even if you do not use UML for design, Together's ability to generate diagrams representing the code is invaluable when you have to take over or maintain someone else's code. It is much easier to see how classes relate to each other at a first glance, than to try to figure that out by going through the code manually.

Re:GUI dev tools are necessary

[stripes]

I can run the program and step through the source code in another window.

I do that with command line tools all the time. One xterm for vi, and another for gdb. I admit it is nicer to use a GUI tool to set breakpoints by clicking on lines of code, and to have a whole window of variables with current values (which GUI IDEs like Visual Studio do), on the other hand gdb hasn't ever harf'ed on my code and taken out my editor killing some unsaved changes. Visual Studio has, so has Code Warrior, and two different Symentic Java dev tools.

Oh, wait I see what you mean. You can do that as well, with gdb's attach PID. I tend not to bother, except when debugging a daemon. Normally having my debug session in the same output stream doesn't matter. Partly because I'm either debugging a server type process, or a GUI program. If I were debugging a curses type program it would be more of an issue and I would use attach (or a GUI)

The editor highlights my code in color, and I can expand or contract each class definition.

EMACS, and some vi clones (vim) can do the color thing (I find it distracting and useless for code, I do use it for HTML editing though). I think EMACS can do the class collapse and expand thing. That would be kinda nice, but not enough to make me leave vi.

In a project window, I can see all the files available and check them in or out of source code control.

I'm unconvinced that that is really better then using ls directly, but whatever floats your boat.

When I move my mouse over a function call, I get a popup with the list of arguments.

That is useful. I have to use ^] to get vi to search for the tag, or use another xterm to bring up a man page. It would be nice to have them unified. It would also be nice if vi could figure out what class x is so it can go to the right place when I do a tag search from x.foo()...

I can standardize my comments and have the development tool create new classes for me with my comment scheme already in place

Is that really simpler then typing :r ~/t/class to read in a class template? You could shorten that to a keystroke if you use :map...

If I forget a constant's name, I can call up a separate window where I can browse or search through constants defined in many modules

Did something prevent you from opening anew xterm window to search from things in a CLI?

Make scripts are generated for me automatically

That is nice, unfortunately it is frequently also a curse. I had a yacc-like program for Java that made java source, but the Java IDEs I used had no way for me to ask for it to be run on the .cup files. The vender had no idea why I would want such a thing, and after much tech support time finally bounced me to someone who did, but told me that it wasn't possible. For C++ I have a similar tool I use to generate lex files (it has simpler rules for generating "trivial" tokens)

But probably the best part is that I don't have to give up any of my command line tools in order to get these benefits. If I want to run it from the command line, or do a make from a batch script, that option is still there.

You do seem to give up the ability to make meta languages and have the make file apply them for you. That is a very powerful programming paradigm to be cut off from. I don't see why the IDEs have to cut you off from it, but the ones I have looked at either do, or have no obvious way to do it. If you know of any that do, please let me know. Or even good work arounds...

You did leave out the GUI bit that I do find very helpful, and have found no CLI equivalent. Layouts of GUI panels and dialogs. It is far easier to do that in a GUI environment then a CLI one. I know, I have done it both ways. The Apple Builder (based off NeXTs) is extremely nice, but even less capable ones like the Symantic Java Studio, or MegaMax's Atari ST GUI are very very helpful. Doing hand layout of widgets sucks. Even if it is a tad bit simpler to make sure resizes don't suck as much, the rest of the ease of using a GUI layout tool far offsets that one bit where GUI tools are a bit weak. GUI layout tools also get harder to use effectively as you get more and more custom widgets (the Java layout tool could let you make live custom widgets, but then bugs in your widget code can bring down the layout tool...and the rest of the IDE! Which sucks, esp. since exception handling should have let them limit that problem...)

Depending on what you are doing GUI dev tools can be more powerful, or less powerful then CLI ones.

GUI's have been scientically proven to be faster

[Ukab the Great]

Usability labs have shown that it's faster to access a menu than use a keyboard command. Especially when the menu bar is at the top of the screen (like on a mac) as opposed to on each window (like in Windows), because you can't overshoot the top menu item (exploiting a principle known as Fitt's Law).

RAD tools are okay for mockups, NOT for real apps

[ewestra]

I've been an application developer for over ten years, writing some very GUI-intensive apps, and I've yet to find a single RAD tool (which is really what this topic is about, not things like syntax highlighting, automatic project management, etc) which can do the job properly. The problem is that they all seem to (a) make it very hard, if not downright impossible, to include dynamic layouts, and (b) rely on hardwired pixel positions to lay out widgets.

In the work I do, less than half of the GUI windows I develop are simple fixed input forms where all the elements are known beforehand. A RAD tool is fine if your window is a simple dialog box with nothing but fixed elements, but as soon as you need a dynamically laid out window you're sunk. Even something as simple as an input form with a variable number of rows of data is beyond all the RAD tools I've found (unless you use an ugly-looking table widget which in most cases means that the end product looks amateurish) -- and if you're talking about something like having a database schema driving the layout of your input forms, you can forget about RAD tools completely. As soon as you need this type of dynamic layout, the RAD tools become your enemy rather than your friend -- and the last thing I want to do is fight the development tools I use, or have to add contortions to my source code just so that the RAD tools will accept them.

But the lack of support for dynamic layouts isn't the main reason I avoid RAD tools -- the fact is, almost all RAD tools I've seen rely on absolutely x,y coordinate placement (and sizing) for each widget. This is a terrible way to lay out your windows, because as soon as your program runs on a different platform, or even on a machine with, for example, a different set of installed fonts, or a different video resolution, suddenly all your nice-looking GUIs turns to custard. At best, your GUI windows look cramped or have widgets that don't line up -- at worst, your widgets overlap or are cropped. Talk about amateurish-looking GUIs! And if your GUI looks messy, your users will assume the code lying behind the GUI is a mess as well -- which is why I'm so fanatical about creating professional-looking GUIs.

Anyway, that's why I've abandoned RAD tools, and hand-code everything. Sure, it sometimes takes a little longer to create a simple dialog box, but I more than make up for that by saving time when creating dynamic layouts and not having to redo everything when I want to run my app on a different machine or platform...

Mind you, it has been years since I've looked at RAD tools -- it may be that some of them now do support dynamic layouts better, and maybe even use logical positioning (eg, sizers and other layout tools) rather than rely on absolute positioning and sizing. If there was such a tool (preferably for wxPython, which is what I'm coding in now), I'd love to hear about it!

- Erik.

Most of the anti-GUI comments seem shallow

[Junks Jerzey]

Is it just me or do most of the anti-GUI comments sound like they're coming from people who have a general dislike for Windows and Microsoft, and therefore don't want Linux clogged up with "none of that sissy crap"? Think about things for a second. A GUI development environment doesn't automatically make you a bad coder. We're still talking about languages like C++ and Java here. If you're not sharp enough to be working in C++, then some magic environment with windows and dialog boxes is not going to suddenly make you capable. Someone who chooses such an environment does so because he or she finds some other benefit to it.

I work in the game business, and it is rare to come across a PC game developer that doesn't use a GUI environment like Visual C++. Now we're not talking about slacker wannabe coders here; we're talking about Tim Sweeney and John Carmack and everyone who used to be at Looking Glass. So most people in this thread would write them off because they use an environment designed for infantile programming? These are sharp people; please give them some credit.

Interruptions and distractions slow you down

[xant]

Think context switches. The reason why people hate the animated paper clip is not that he's cute, or that he's bloatware. My mom hates the paper clip even though the cuteness appeals to her and she does not know what the word 'bloatware' means. She hates him because he interrupts her when she's working. She learned how to turn him off.

In the same way, GUI tools can interrupt your work process. Going to the mouse to select something from a menu is ok when you have never found the option before. It's unquestionably faster than looking up an option in a man page for many operations that GUI dev tools support. But taking your hands off the keyboard to put them on the mouse is an interruption. If that's the only way you can get to the option (other than switching to your xterm, which entails an even more egregious context switch), or, if that's the only way you've learned how to access the option—which it frequently will be, because that's how the GUI teaches you to do it—you waste cycles. You get distracted. Concentration is broken, and you have to do hand overhead, brain overhead, and searching-for-the-right-spot-to-click overhead.

The keyboard, on the other hand, is under your fingertips. No context switching necessary.

You might think I'm arguing against GUI dev tools. You would be wrong. GUIs are a faster way to learn what tools are available, and even to show you some tools that you might never have found when faced with the black hole of the command line and no prior knowledge. RTFM is fine, but most people read only enough to solve the problem they think they have. A GUI presents lots of options in an easily-digestible and memorizable hierarchical format (if designed with a minimum of care). You'll see a lot more of the tools and options available to you, and that alone can save development time.

This has been said many times before me: context switching slows you down; so does a steep learning curve. One is better for beginners, the other better for experts. But I still believe there is a best-of-both-worlds solution out there. How about these two things:

• Every time you switch to the mouse to do something, you get an entry in a history file for that GUI. For example, I just picked Tasks->Tools->History to get to the history window in Mozilla. How about keeping a record of that action around? How about a small menu history listbox on the right edge of the menu. That list box would now contain "Tasks->Tools->History (Ctrl-H)" and if I picked it from that list box, I would again get the History window. If I then did View->Apply Theme->Modern I would get yet another entry in that listbox. This helps you memorize where the things are that you use. It also helps you pick them faster by flattening the choices available and paring down the options to those most likely to be picked again.
  
  The same principle could be applied to toolbar buttons. The listbox could instead say "Button pressed" and display an image of the button and the keyboard shortcut to get to it.
• Notice that I included the (Ctrl-H). The keyboard shortcut is still the fastest way to get to that menu item: Leave fingers on keyboard, don't use mouse. That keyboard shortcut ought to burn itself into your brain every time you look at it. How? Make it more important. When you stick something into that menu listbox I just talked about, the keyboard shortcut should appear bright, bold, colorful, and then slowly fade to the same emphasis as the text next to it. You will notice it, but it doesn't interrupt you. You will learn it, and you're more likely to try it next time.

Here I used mozilla as my example of a GUI dev tool, which it clearly is not; in a browser your hand is on the mouse most of the time anyway. You can still see how this would be applied to a GUI IDE though.

Stallman wrote about this.

[crucini]

I work with Visual C++ 5 days a week, and there are real limitations in its scripting.

Interesting. Stallman wrote an essay describing the design logic of Emacs. One thing he pointed out is that a scripting language tacked onto the side of an application as a 'feature' will always suck. It won't be a very high priority for the application's creators and maintainers.

The proper approach is to write the upper layers of the application in the scripting language. So Visual C++ should be made with the compiler, linker, metadata-store etc. in C/C++ and the control/GUI in VB. Or something.

The obvious side effect is that Microsoft's programmers would have felt the pain of an inadequate scripting interface/language and enhanced it.