Are GUI Dev Tools More Advanced than CLI Counterparts? 501
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 believe you're correct. (Score:2, Interesting)
GUI-CLI? Where's Emacs? (Score:2, Interesting)
I get the most out of XEmacs, which is an almot-GUI tool that drives CL utilities. I use it for everything, from C++ to Perl to Javascript to HTML.
Probably the best is to stick to what you know most. DDD is probably much better that gdb embedded in XEmacs, but, well...
The IDE's just wrap command line tools still (Score:3, Interesting)
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 (Score:3, Interesting)
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 (Score:1, Interesting)
BeOS had a prebuilt messaging system that allowed to control GUI application from command line. Launched it, messaged it, and here was the ability to script it.
Now, the fact that stdout and stdin doesn't mean anything when it comes to GUI is rather annoying.
Personnaly, my choice will be either to build the GUI application as if it were a cli one (providing command line parameter and std* support), to create a cli application onto which you could stack a control GUI, or in case of complexity a collection of cli tools controlled and sequenced by a well thought GUI.
This way, you keep the power of cli, without sacrifying the so called userfriendliness for end user.
That's my two cents, and their mine!
GUI dev tools are necessary (Score:2, Interesting)
I can run the program and step through the source code in another window.
The editor highlights my code in color, and I can expand or contract each class definition.
In a project window, I can see all the files available and check them in or out of source code control.
When I move my mouse over a function call, I get a popup with the list of arguments.
I can standardize my comments and have the development tool create new classes for me with my comment scheme already in place.
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.
Make scripts are generated for me automatically.
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.
I want to stress that not all of these advantages are Visual Studio or Codewarrior related - some of them come from the revered Turbo Pascal. None of these development environments require you to give up the command line.
VISUAL STUDIO SUCKS... (Score:2, Interesting)
First off, there are two things I like about Visual Studio, which tends to typify IDEs, and those are the dialog editor and the debugger. The rest of the bells and whistles really don't give me much. But I see this sentiment echoed earlier - most people like some kind of GUI tool for developing the actual GUI interface, and a debugger with lots of information at once capabilities. These things are not unique to Visual Studio, but here's one thing that is:
Project Files.
I've overheard that internally, the boys at M$ regard Visual Studio as more of a toy. Supposedly, instead they use a modified version of nmake. (Hopefully one that doesn't just inline files... man that's annoying.) I completely agree with this sentiment. While Visual Studio can import nmake files yet, nmake is about the only other option you have. And what's the other option?
Project Files.
If you have to generate any kind of sizable project, the Project File setup is about as irritating as it gets. For large projects, you want to specify 99% of the build rules necessary in one place, then when you want to create a new library, just specify what kind of target it is and let your build system fly. Project Files instead center most of their rules around the leaft projects. This just causes integration headaches like you wouldn't believe unless your developer staff is really disciplined.
Not to mention, you're also choosing a build solution that is 100% not compatable with any other platform solution. NMake even doesn't port very sensibly to a GNUmake setup, mostly because it's really old version of GNUmake.
Now, admittedly, you can reset the custom commands in Visual Studio, but then, it becomes a hassle if you want to provide more than just two targets (typically all, and clean). For instance, we like to remove the MIDL step from the generic sequence, so we now have an includes target on top of all and clean. All of a sudden, the folks at my job who are still using visual studio have to find a new button to map.
On the other hand, most IDEs aren't as relagated like VS to a crappy build environment. Most can be edited, but personally, I'd still like to be able run a command line like XEmacs from the IDE. This is because we tend to create more targets (like test) and add components that aren't necessarily written in a compiled language. Make is just a handy tool for automating pretty much anything. I have yet to have an IDE that was extensible like this, and personally, this saves me way more time than having to use the integrated debugger or dialog editor. (WinDBG, anyone? And it's still fairly easy to whip out a dialog when necessary - and c'mon what percentage of your time is used writing dialogs?)
So, in the end, I think that VS, which I would be willing to bet is the main IDE in use out there, does not save time at all in a large project. I've even heard that projects using VS don't even run baselines (which is probably because they're using VSS which doesn't allow you to retrieve whole projects set to a tag... what was M$ thinking?...) On my personal experience, projects that don't run baselines hit massive integration problems. Thus, I'm at the point of banning VS inside my company.
On the other hand, if the IDE was designed to thinly wrap a make system, essentially being a powerful editor like Emacs with a integrated debugger, command shell, and dialog editor, I'd probably use it. But I have yet to find this tool.
... whew, that was one kind of rant...
Re:GUI cvs Command (Score:3, Interesting)
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... (Score:5, Interesting)
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 [ibm.com]! 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 (Score:3, Interesting)
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)
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.
I'm unconvinced that that is really better then using ls directly, but whatever floats your boat.
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()...
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...
Did something prevent you from opening anew xterm window to search from things in a CLI?
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)
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 (Score:3, Interesting)
CLI all the way (Score:1, Interesting)
Linux has "at" also. I believe it's the UNIX predecessor to the cron daemon. At any rate, IIRC it's very insecure, at least on some systems.
As for GUI vs. CLI, I prefer the CLI for 90% of development work. I came to Linux from Windows, where I used Visual C++ for Windows development and RHIDE for DOS development (DJGPP gcc). I have come to love vim, what with all the pretty colors and all (IMO vim has the best syntax highlighting of any editor. kdevelop is pretty good, but I like vim the best). Makefiles are extremely easy to write (all: \n gcc file.c -o file), and autoconf isn't much harder. I especially like the way I can do "cvs -z3 update" to refresh my source tree. Much faster than navigating through a bunch of menus with the mouse. I use CLI for OpenGL, SDL, framebuffer (libfbx), and CLI development. The only thing I use a graphical IDE for is resource editing, i.e. laying out menus and stuff, but I don't do much standard X11/Windows GUI stuff. I mostly work in OpenGL.
In conclusion, I guess what it all comes down to is how fast you can type more than what application style you're developing. If you suck, GUI is better. If you can type fast (I, for example, can type 140 wpm in a burst, avg. 100+ wpm sustained), the command line is better. Vim rules for fast typists, especially because of its moded interface. If you type slower than 60 or 70 WPM, you need to spend more time away from your mouse and get a typing tutor or something, if you want to be a programmer. I'd hate to code at 40 WPM... I can't stand watching my friend code. He uses an IDE because he types at 50 or so WPM. Whoa! I really strayed from my topic!
--
experience euphoria [u4xlabs.com]
Re:GUI dev tools are necessary (Score:2, Interesting)
Overall, the items I listed are the distinct benefits that came to mind thinking of the difference between CLI and GUI tools. However, I also concluded that Turbo Pascal was also a GUI tool: my answers compared integrated development environments to CLI tools, not GUI tools vs CLI tools.
Also, I am not a hardcore programmer in the sense that you have described. I don't like editing makefiles. I don't like meta-languages. I don't like switching back and forth between an editor and a set of development tools. My tastes in development are towards the simplest possible solution for the problem at hand; I'm no good when a refined, elegant application is called for.
Perhaps this is also why I've never grown fond of sending man pages through grep filters: developing a comfort level with CLI tools requires effort, but it often pays off if you use the tools frequently. I like the way I can pick up a GUI tool after leaving it alone for six months and still know how to use it. If I left grep alone for six months, I'd forget what all of the command line options were, and then I'd have to read through the man file again.
I have no doubt that if I was required to use CLI tools daily, I would grow to appreciate them as you have.
Re:The much-maligned command line (Score:3, Interesting)
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:
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.
Re:The IDE's just wrap command line tools still (Score:2, Interesting)
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
The RAD tool that my company makes (see bio for a link) adds significant functionality that you can't get with CLI tools. For example you don't need to recompile to see your results! The application runs as you're creating it... that whole edit, compile, test sequence just becomes modify, glance-to-test, modify some more etc...
Also, building the GUI front-end with our tool is dramatically faster than doing it by hand. Since it's functioning as you build it, you get immediate feedback about what works and what doesn't work. Even if you don't want to use the Code Sourcerer(TM) to generate code and all of the other extra features we provide, the ability to create and test a GUI so quickly makes the tool worth while.
On the other hand, I will admit that we still use CLI's to do some of our work. For example, when you finally finish your application and it's time to ship it off to your customer, our tool uses javac to compile it and jar to package it, but this is when you're all done with development. You don't actually need to compile till the very end.
We also improve the way that existing CLI's work. jdb is really unpleasant to use from the command line. Most people don't bother because it's so awkward. This means that most users are doing the old 1960's style debugging via println's and completely miss out on the advantages of more modern debugging techniques (though with the Execution-On-The-Fly(TM) feature mentioned earlier, our users don't have as much need for a debugger). However, by automating the use of jdb and organizing the output in a more useful way, we make it much more compelling to actually use the debugger.
One final point that's worth considering is that the fact that a GUI tool uses CLI is actually an advantage. It means, among other things, that if there are any limiations of your GUI tool, then you still have real source code that you can manipulate with CLI tools that can provide extra flexibilty. It also makes it easier to integrate with third-party tools such as source archive tools.
Re:IBM Visual Age products... (Score:2, Interesting)
While I agree that some of the features you mention were very convenient (the way it synchronizes the classes in the workspace and the export features particularly), very frequently Visual Age was a real nightmare.
The main issue I have with the system is its very vague (if not plain incompetent) "error checking" features when writing code on the class editor.
It's quite annoying to spend some time writing hundreds of lines of code just to be unable to save the class because I missed a semicolon or parenthesis SOMEWHERE, with no clue as to where it could be. "Unable to compile class because end of statement missing" is not a complete description of a problem. Even the CLI compiler gives more information than this.
I also don't understand the lack of syntax completion for the classes. Not that it's vital to write good code, but it could save some of us a lot of typos (length() vs length(), ridiculous but it happens a lot when typing quickly) and time, particularly with Java's verbosity (ArrayOutOfBoundsException anyone?).
Also because there is no reason for it to be missing on a product like Visual Age.
I ended up having two IDEs open: Visual Age for managing the projects and their packages, and JCreator to actually write the code.
BTW, I recommend JCreator to anyone who has to code Java in a Windows workstation.
http://www.jcreator.com
Fighting to import a repository after changing machines was a waste of time (export to/import from
Having your development IDE run with the amazingly hasty speed of StarOffice unless you have a top-of-the-line machine gets irritating as well.
Unless new versions have changed dramatically since I tried that thing, I'd recommend against using it.
Stallman wrote about this. (Score:3, Interesting)
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.