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

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 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: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.

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: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).

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.

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.