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.
You wouldn't make a complex 3d model of anything programming polygons... you could. Java3D and OpenGL have ways for this. But to get something that LOOKS decent takes a program like 3DS MAX. You can then use THOSE models in your OpenGL app.
In the same vein, making a GUI would be better suited to a GUI programming tool, with the backend being designed with real code.
http://www.mingw.org/
Win32 ported gcc that has all the win32 headers and compiles win32 native binaries that don't require additional DLLs to run anywhere (like Cygwin).
Also makes it easy to compile linux/unix sources on win32 with ususally slight modifications (esp. socket code) but not as easy as Cygwin is for porting.
For most of this year I have been developing command line programs as well as linux kernel device driver code, and I primarily use a graphical development environment. I use an editor/project management program called Visual SlickEdit. Granted, it's not OSS, but it was provided by my employer, so I'm not complaining too much. It has features that simply would not work with a non-graphical editor, such as an easy file management interface, advanced searching mechanisms, and automatic code cross referencing tools. Being able to trace execution flow through the kernel by just clicking on variables and function names can save tons of time.
On the debugging side of things, ddd is a must. This is GNU's graphical front end to gdb, and I honestly believe my testing would be about 10 times harder without it. Being able to graphically display huge chains of data structures (especially in the kernel) is completely invaluable. I can't imagine how much longer it would take me to find all of the subtle bugs that crop up if I was just using gdb on the command line.
On the other hand, though, I still do a lot of my work with command-line scripts that I've written. Stuff like kernel builds and installations on a remote test box, rebuilding and installing my admin tools, setting up test cases, and opening debugging sessions are all done through simple scripts. When I need to run these, I simply tab to an xterm and run them.
So I don't think this situation is completely black and white. I see both methods co-existing quite nicely.
>With MS Visual C++, you are basically stuck with their IDE and you better like it
Huh? Am I the only persson that realizes that MSDev is a GUI interface to the command line tools that it runs? You can still execute cl.exe and link.exe from the command line - after all, thats what MSDev does, and pipes it's output to the Output Window.
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.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
GUI tools are wonderful for tasks like creating user interfaces. Most GUI tools don't scale very well, though. When I build user interfaces in Java I code all of the layout manager stuff by hand rather than using the tool in Symantec's expensive environment -- it isn't good enough. Glade http://glade.gnome.org/ is good enough. It's wonderful. Does anyone write libglade XML by hand?
I also like having an editor that respects my breakpoints and adjusts them when I move code around. I learned how to program in assembly language and it seems natural to me to inspect registers/variables and change code while it is running.
Color syntax highlighting, dialogs to set compiler options, integrated icon editing, these features I don't *need* but I don't mind a pretty environment as long as it is designed as a view into the command line tools rather than a replacement.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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.
I have two different opinions regarding GUI-based dev environments. First of all, when I use Linux / Solaris, I find that KDevleop is pretty nice, but it's just not good enough (to me) to warrant using it over emacs/vi and gcc. I've heard that CodeWarrior is better, but I haven't ever used it much, and when I have seen it I wasn't impressed. On the flipside, when I develop in Windows, I use Visual Studio.NET (I used to work for MS, so I have a copy of the Beta 2). It comes with lots of cmd line tools, but the visual ide is very, very good. I definitely use VS when I'm using windows. However, if you really wanted to, the cmd line tools can accomplish everything that the IDE does in terms of settings, compilation, project management, etc. I'm still a linux fan, but I've got to give proper credit to VS.NET. At any rate, I don't think one or the other determines whether or not you can create "state of the art" software. That has a lot more to do with the skill of the engineer.
You're right, there are easy ways to do that in Visual Studio as you describe. However, the same functionality that you and the original poster described could easily be had by a single key mapping in an non IDE editor worth its salt.
;-) ) by pressing CTRL-].
Example from vim:
nmap <f1> yiw:r!man <c-r>"|grep \#include<cr>
So after sticking in that mapping, hit f1 on a command that's not yours and you'll have the info you were seeking.
Oh, and of course, you could already jump to the definitions of any of your own symbols (in nearly any language, not just the one that your parochial bloated IDE supports
Yes, most good non-IDE editors can easily have more convenience features than an IDE; it simply requieres a little time spent configuring the editor.
Last fall I and 2 other guys participated in an ACM programming competition. The allowed editors were VAJ, VAC, vim, and emacs (oh and notepad if you were horribly sad) (oh and you could use Delphi, too). For the small quick algorithm intense work we were doing, using vim configured to compile and debug java was incredibly quick and was certainly an edge in helping us to win. VAJ/VAC is just too bulky for just trying to whip something out and runs alltogther too slowly on a typically underpowered university lab computer, in my experience.
Caveat: Of course most development doesn't happen under the conditions that I described above.
- It uses obscure, undocumented macros to implement critical functionality. The only way to really use MFC is through the wizards, which take care of the macros for you. The VCL uses no macros, as Delphi doesn't have them. This makes the source code far more readable. Further, it's well commented, clean code, and also documented in the help files for the most part.
- Another reason: the Win32 API and MFC are both far to complex to remember. The VCL uses a consistent and logical approach to objects. For instance, list boxes, combo boxes, and listviews all have an "Items" property which acts consistently, and can all be used as base classes in a fully OO system at many points along the chain. You can program in it without remembering things like, "now, does this function return zero or -1 for failure?" and the like.
- Without MSDev's annoying-as-all-hell code completion, you'd spend even more time reading MSDocs(tm) than already. This is a UI issue, but again I prefer Borland's UIs. The Code completion is actually very intelligent, and you don't have to compile your code first.
Some other reasons why it's better IMHO:- The VCL and CLX uses properties! I know this is a small thing, and not compiler-portable, but code looks so much nicer.
- The CLX library (kindof the successor to the VCL) is cross-platform. It compiles on Linux (x86) as well as Windows.
- MFC doesn't abstract controls away enough compared to the VCL. Most controls have only very basic wrappers around the Win32 API, and using MFC isn't that much better than the API. (I really find it hard to believe that the Dev Studio people couldn't think of many major improvements to the API when they're in a fully OO environment.)
- The VCL/CLX streaming and loading system puts MFC to shame. MFC is still using dialog templates, which were passable for Windows 3.0, but aren't suitable for modern visual programming styles.
- It adds internal messages for component writers that fill out the gaps in the API. For example, there are messages before and after important property changes, so you can veto the change if necessary.
- You can create controls which integrate into the IDE much more cleanly than in Visual Studio, using property editor classes and the like.
- You get waaaayyyy more components in Delphi/Kylix/C++ Builder/JBuilder than in most other similar products. (As in, over 150 components in Delphi 6 Pro that do everything from GUI stuff to your flavour of database API to pre-built base classes for SMTP servers.) You can use visual development when you want it, or program these components like Database objects if you'd prefer.
All in all, I'd suggest that you give these tools a look if you can. I think C++ Builder opens and compiles many Visual C++/MFC projects (but I'm not sure), so you can keep some degree of compatibility if you're tied to Microsoft code.