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

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.

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.

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.

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.

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.

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.