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.
For any kind of programming in the languages I'm familiar with (PHP, PERL, C++), I prefer a good old fashinioned text editor. I do find using tools like dreamweaver and such helpful in HTML, but I would go nuts if I had to rely on them totally. I say if you can't use either GUI or CLI, you've got problems - jst the same as if you can only write one language or for one OS.
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...
It's just a BloJJ
If I understand the claim correctly, it's that one needs a GUI development tool to produce a modern application. I've worked for quite a while with various IDEs as well as plain makefiles and have never noticed a productivity difference.
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.
They didn't get rid of it, not even in XP. You have to look to find it, but it's in there, buried.
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
GUI apps are impossible to automate, run from crond, pipe information in and out of...
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!
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.
OK, now that I got _that_ out of the way, let me explain...
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...
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.
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.
Usability labs have shown that it's faster to access a menu than use a keyboard command. Especially when the menu bar is at the top of the screen (like on a mac) as opposed to on each window (like in Windows), because you can't overshoot the top menu item (exploiting a principle known as Fitt's Law).
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
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.
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.