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.
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.
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!
All that a GUI does for you is 'wrap' the command line so the user doesn't have to be bothered with remembering the 'make' syntax for example. Whether or not a GUI is used to compile the project makes no difference to whether or not the project is good. That depends on the code, and whether you use vi or Microsoft (eeek!) Visual Studio to write your code, it is still the actual code that makes a great program, not the development environment.
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.
I'm still working on a clever footer.
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
I've banned IDEs for now...perhaps if my developers use a text editor to code they may actually learn something.
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.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Assuming you are doing some form of Revision Control (which you should be ;) ), I find it most important to have the revision control system built into the editor I'm using. I also want a difference engine built into the editor that works with the revision control system. Emacs and Xemacs has these features among other full IDEs. It is useful to look at the differences between your current code and code that has been checked in, in a graphical manner so that the differences are within context. Command line diffs remove the context
It's also nice to have color highlighting of code and smart indention. This can help you know if you spelled things, forgot a ";". A nice feature that some IDE's have which I haven't seen implemented in emacs yet (which I'm sure is possible), is the ability to know the current valid function names and variables and highlight them appropriately.
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
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
Well, since you use "You", I can answer directly that you are incorrect. I personally can whip out Java GUI apps much more quickly and with much better functionality than with using a GUI tool to do so. For many other people it's the same. Especially with Java and it's layout managers, your GUI is much more that "stick a button this big over here". It's quite easy to program a UI that will scale up to the needed component sizes, even if you change the language on the fly (or just on startup). On the other hand, internationalization is a pain in VB and such.
Again, for me I personally can make professionall looking UI's quite quickly in Java with pure code. Plus my code is smaller, faster, and has fewer bugs. And as far as complex, when was the last time you had a UI change from English to French or Japanese with no problems at all?
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 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.
And just in case it's a factor, I've programmed multimedia products before for many platforms, and have done 3D artist work for Interplay.
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.
For all our defense of command line interfaces and general disdain of Visual Basic, it must be said that almost always, a GUI interface is easier for a non-geek to use. Something that I feel is often neglected by coders and other techie types is the fact that not everyone can understand the concept of computer use. I spent a the majority of my freshman year in college working as a lab assistant in a community college Open computer lab. Every day I would see people of all ages come in and try to undertstand how to do even the easiest tasks on a computer like typing a paper, sending e-mail and even getting rid of the screen saver. Those of you in the tech support field know what I'm talking about, because when something goes wrong, they react with fear and often anger (How many people have YOU had call up to scream and yell at you, and THEN ask how to fix the problem?) Command line is fine, and for those of us who KNOW how to use a computer without having to think about each step, often better because it offers much more flexability, but often we are not the ones using these programs. Those that do need to have access to all the available features, in plain English, at the push of a button. I now run a little database design company, and yes, I use VB to get the interface to look as much like a Microsoft product as I can, not because think that Microsoft's products are supperior (After all I HAVE used Access *shudder*), but because everyone knows these interfaces. Standards don't develop because they are the best or the most stable, they develop because it's what everyone knows.
This is not a sig
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.
I'm a big fan of commandline tools, but every-so-often a GUI is needed. GDB is a prime example. It's a very powerful debugger, but lacks a few of the features that the Insight GUI gave me. I could look at the flat code (without prompts inbetween statements) and also click through some of the complex datastructures inside my program. This was invaluable. I don't even want to think of how hard it would have been to debug on the commandline.
Bottom line: The power is in how you use the tools, not the tools themselves. People who argue about which is better have lost sight of the real goal to programming. Productivity.
Use what works.
How do you think Torvalds created the linux kernel?
What is used/needed to develop on apache?
How did CmdrTaco make Slash?
What development tools do you need for mozilla
Impossible without GUI? Yeah, right. End of discussion.
--- Hindsight is 20/20, but walking backwards is not the answer.
I do similar things, and really I find a textual iterface into these systems just as easy to use and in some ways more powerful and flexible.
Generally text editors like Emacs and Vim are an order of magnitude more configurable than editors built into most IDE's, thus I find it faster to create helper macros in an Editor like Emacs than use a GUI tool that drags and drops form elements. As an example, it would be pretty easy to whip together a macro to take a set of table columns (drom a "desc table" in SQL), then automatically generate a Bean with getters/setters and also generate form elements elsewhere.
I'll admit that for debugging I think a GUI is generally better, from the sapect of examining multiple threads and keeping track of numerous variables.
I do have a particular beef with GUI editors in terms of resizable applications - how many millions of times do I have a program that even when I expand the window doesn't expand form elements to help me view more, or even worse simply makes some portion of what I want to view totally non-accessible? I blame the supposedly easy to use GUI builders for creating apps where designers never had to think about different resolutions and elements are set to exact pixel locations. That whole situation has definatly gotten better but even now I find way too many examples where people fix an app (or web app) to run in a particular sized screen and don't alow me to make use of what space I have.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
How do you write: "sleep 50 && killall pppd" using a GUI?
This has nothing to do with Dev tools. a CLI presents a verbal language interface, something like English, Hebrew or French, just specilized. A GUI present a visual language interface like
Sure, cave drawings are easy to understand, and if Corporate America (think Disney) will have it's way that's what we'd be left with, but I don't know any good poetry written in cave drawing language, verbal language do have a few none the less.
You may think that programming is nothing like potery, but if that's what you think, you've missed some very subtle thing about programming.
Gilad.
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.
Where I work, we make software that needs to run on both windows and unices. I have a win2k desktop with DevStudio, and a suse with (guess...) gcc. I develop on both, and both configurations sometimes bug me.
. .. and you never have to wonder whether they will live after cvs is done with them (projectfiles are really allergic for unix-returns)
- find in files (visual): of course, you can make a script that greps your source dirs, but having it one click away is really more convenient than having your own custom grep script
- makefiles (nix) vs. projectfiles (visual): whoever designed the gui for the projectfile settings was a complete idiot. Any program of reasonable size uses libraries, or is divided in libraries itself. Why have only a 80(?)-character field in which to specify those libs? There's lots of such stupid things in that single window... Our makefiles handle linux{i386,ppc,alpha},{open,free}bsd,solaris,irix
{flamebait}
- editors: Once you use Emacs (or Vi, for that matter) for any appreciable amount of time, you feel _really_ handicapped when you have to edit in the Visual editor. Yes, you can plugin an editor of your choice in Visual. But Visual's default is pretty ascetic.
{/flamebait}
- debuggers: when you have to dig into dynamic libraries, Visual really kicks gdb-ass (shutup you ddd wimps!). And gprof doesn't really cut it if you can have Rational Quantify. AFAIK, Purify is slowly being phased out for unices, which is a shame. And edit-and-continue (Visual) is also really nice. The commands-command (gdb) is a life saver!
And so on and so on. If you use both on a regular basis, and use them seriously, you run into the limits of the tools. Not a problem. I find myself switching back and forth, and using the strongpoints of whatever tool is needed at whatever moment. Use the right tool for the right job. Sometimes a gui is better. Sometimes a cli is better.
My opinion of this is, the ultimate perfect set up between the GUI and the CLI, is one in which the fully functional CLI version is made first; where all of its features are DNA encoded into libraries, not executables; and where the GUI takes the libraries, and implements the features with point and click efficiency.
This, to me, is the perfect way to maintain a harmonious balance between the CLI and the GUI - and the people who prefer one over the other.
--- Grow a pair, liberals... stop letting the Republicans bully you!
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.