Slashdot Mirror
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.
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.
Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
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.
My Journal
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.
: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.
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
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. =)
Outdoor digital photography, mostly in New Engl
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:
/. editors.
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
Well, I think that clears that up.
--Shoeboy
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.
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.
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
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.
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.