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.

Re:Neither

[daviddennis]

Nice try. Don't bother clicking on the link, folks; it's goatse.cx time.

D

Re:Neither

[daviddennis]

In this case, he was using an IP address to conceal that it was Goatse. Thus my warning.

D

I believe you're correct.

[W1BMW]

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.

GUI-CLI? Where's Emacs?

[jmerelo]

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

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

Re:GUI cvs Command

[sjames]

Windows' answer to Crond is the Scheduled Tasks folder. It's not Microsoft's fault that nobody uses it.

In order to effectively launch an app from a scheduler, it must have a way to accept options from the scheduler. Thus, it will end up parsing a command line. I suppose an expect like framework for queueing windows events could help there, but I haven't seen such a thing.

Re:GUI cvs Command

[sahala]

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.

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.

Re:GUI cvs Command

[Trepidity]

And what's wrong with a GUI app parsing the command line? That way you get the best of both worlds - GUI when it's more convenient, and CLI when it's more convenient.

I don't see why you'd want to hobble yourself by doing things 100% GUI (Visual Basic) or 100% CLI (gcc and gdb and nothing else).

Re:GUI cvs Command

[be-fan]

OS/2's REXX is also pretty famous. Sorry I forgot to mention those!

hrmph.

[egomaniac]

I keep trying GUI tools every few years and I continually find that they make my life more difficult.

Perhaps I've just been using text editors and command line compilers for too long to successfully make the switch, but I always find that GUI tools are great for simple, brain-dead stuff but the second you want to do anything the least bit interesting the tool fights you every step of the way.

I refuse to stop doing interesting things in my programs, so until these tools stop fighting me I won't use them. I think the Microsoft crowd is (in general) a lot happier to say "Ooh, the tool doesn't want me to do that. Oh well" than I am.

I hold out hope, since the idea of being able to drag-and-drop my way to a user interface is pretty compelling, but I've never found the reality of the situation to be even remotely close.

Re:hrmph.

[sbeitzel]

I guess I'm just confused...what have you wanted to do with, say, MS Dev Studio or KDevelop, that these tools wouldn't let you do? Or maybe I'm missing the point. I like having an IDE manage the makefile. I would much rather not have to edit the damned thing with vi. And really, when it comes to designing a window or a dialog, having a graphical tool to do that layout is really nice. And being able to click a tab in the IDE to switch back to the .cpp file that implements the handlers associated with that window, well I like that, too.

But maybe the question isn't about IDEs, but about purely graphical development environments. If that's so, then the editor's comment is out of line -- because KDevelop and Codewarrior both involve typing; a great deal of typing. The only completely graphical development environment I've seen is a weird language for the Mac, called prograph, and even that is more like flowcharting than drawing.

Re:hrmph.

[tzanger]

but the second you want to do anything the least bit interesting the tool fights you every step of the way.

I refuse to stop doing interesting things in my programs, so until these tools stop fighting me I won't use them.

Can you give some specific examples? I'm no app programmer but last year I was called in to turn around a wholly-mismanaged software project. It's there I learned about Borland C++ Builder.

Now, I generally dislike app programming -- I am an embedded systems designer by trade -- but I can learn very quickly and seem to have a sense of how a user interface should work, hence my involvement in this project.

Anyway, I learned the basics of C++ (I'm a fluent C/asm [many platforms] programmer), DCOM and Borland's VCL in a few weeks and managed to get this project turned around and at least releasing stable, usable releases. But when learning to use C++ Builder I occassionally butted heads with it with respect to form design and so on but it was because of my lack of experience with the software, not the software itself, which was the cause.

Examples: tabbed forms. You actually use the tabs in the form designer to switch to another "pane" and put objects on it. That seemed weird to me -- You literally stacked form elements on top of the correct pane, swapped panes and continued stacking. Neat trick, but in my mind it wasn't "right". Raised panes worked the same way. I would have done it with some kind of selector but the end result is that C++B wasn't restricting what I wanted to do; it just wanted me to do it differently. I could have hit F12 and typed out the information and have it appear that way if I wanted as well.

Generally speaking, if you are trying to do "cool" stuff in your UI or your GUI forms designer is making your life rough, you are probably breaking the UI rules for the platform you're working for. Palm has some very strict rules but after working with it for a while you learn how it should be done to work and play "nice" with the user.

Re:hrmph.

[egomaniac]

Well, it's been six years since I've used a language other than Java, so your comments re. makefiles and specific IDEs don't really apply (or rather it's been so long that I can't remember the specifics).

As far as "cool" things I'm doing, I'm referring to pretty much anything but creating forms. Forms are easy, all the tools are designed to do that. Try doing anything sophisticated like, say, a table which has an embedded tree and expands/contracts rows as the tree elements are expanded/contracted. This is really easy to do with code (at least in Java) but unbelievably nightmarish to do in an IDE.

Any time I end up trying to do stuff like that and have it work right, the IDE ends up putting so many obstacles in my way that I wish I had just coded the thing from scratch. (And it's not just that the IDE makes me hand-code this behavior, it's that hand-coding it is really tough because of the way the IDE expects/wants everything to behave).

It's probably just because my GUIs aren't primarily form-based, but whatever...

The IDE's just wrap command line tools still

[joshtimmons]

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.

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:The IDE's just wrap command line tools still

[MCRocker]

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.

Know any good Win32 CLI C++ compilers?

[Katravax]

I'd love a good one. I can handle makefiles. I tried the borland free compiler, but can't get even a simple app under 100K (thanks to the forced runtime). LCC is great, but I need C++, not just C. I need one with the Win32 include files, and I need to be able to NOT use the runtime. I own a copy of VC++, but I'd prefer a another compiler so I can at least get my dev environment out from under MS. I would be willing to pay for one; has anyone used the Intel compiler? Of course I'd prefer free. Suggestions anyone?

Re:Know any good Win32 CLI C++ compilers?

[Gottjager]

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.

Re:Know any good Win32 CLI C++ compilers?

[BitwizeGHC]

http://www.mingw.org

Re:Know any good Win32 CLI C++ compilers?

[keesh]

Borland's free C++ compiler which is here. All the MS includes, Borland's VCL stuff... Very powerful commandline.

Re:Know any good Win32 CLI C++ compilers?

[Katravax]

Anyway, all these tools are completely functional from the command line, as you'd know if you'd bother to actually read some fucking documentation.

I do use nmake and cl already. I clearly stated I wanted to get away from the MS toolkit. I appreciate that at least you did make a useful comment in addition to the insult. I also explained why I don't like the Borland compiler. I didn't know that the Intel compiler didn't come with headers.

Re:Know any good Win32 CLI C++ compilers?

[Katravax]

Maybe I'm missing something, but what's the beef with a 100K program?

It's bigger than necessary. I detest large distributions. My goal is precise functionality, neatly-done code, tiny executable. For a particular program I've done that I use as a test project (with a basic GUI and performs some network functions), I've got the distributable size down to 18K in x86 ASM, 22K in PB/DLL, 24K with LCC, 28K with VC++, and WHAM! 132K with borland's free C++ compiler (which, as best as I can tell after searching for hours and hours for an explanation, force links the runtime whether or not you explicitely call runtime functions because they embedded the entries in the runtime). It's a personal goal in my software that they never use external files (with very rare exceptions), and use as little disk space and memory as possible. I do balance that with development time, though, and I'm not fast enough working in ASM to do everything that way. Of course, all these beat the hell out of the equivalent VB project at 1.5M.

Re:Know any good Win32 CLI C++ compilers?

[Katravax]

Yeah , you did but without any logical reason. Do you just "hate" MS ?

Well, if I hated MS, I wouldn't be working in Win32 would I? :)

I was trying to keep the original question short, and didn't explain all my reasons. Here are some of them:

• I don't like the direction MS is headed with their development tools. I know that doesn't affect those they've already released, but it is a minor protest on my part.
• The disk space required to install MS' development tools is beyond what I consider acceptable. I know this because no one else's take up that much space (except Borland's, and I don't want or need VCL, either).
• I don't like Dev Studio (I could go on for hours about this one, but it's basically an editor flame). I work from Visual Slickedit, so other than using nmake and cl, I have no reason to bother with their tools any more.
• I'm tired of running into true compiler bugs and errors in their implementation of C++ and the STL. (I know I can use a third-party STL, but if I have to keep using third-party stuff in an environment I don't like, what's the point of using the environment to start with, you know?) If they did actual updates more often, this might not be as big a problem.
• I detest MFC for the same reason I detest VB and other large library-based tools. I'm straight Win32, so there's no need for all the extra stuff that comes with VC++.
• In a nutshell, I want a compact set of tools for which I can build and keep option files and other settings the way I want to work. VC++ is configurable enough, and works from the command line, but since I'm using less, I want less on hand to do it. I'm a minimalist in my coding style, and want a less bulky toolset.

This isn't some anti-MS rant I'm on. I happen to like Windows NT and 2000 as end-user OSes. I just want a compiler and toolset that works how I like to work, and doesn't weigh me down with stuff I don't need or want.

Re:Know any good Win32 CLI C++ compilers?

[Anonymous Brave Guy]

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.

Re:Know any good Win32 CLI C++ compilers?

[Teferi]

nmake isn't an especially good make utility. it lacks a lot of the niceties of GNU or BSD make, and isn't quite as flexible.

Re:Know any good Win32 CLI C++ compilers?

[Katravax]

I agree. I'm not typical. I also figured there may be a couple other die-hards like myself around, and that they may read slashdot. :) I've actually tried all the compilers listed so far (other than Comeau), but I've been very glad that some people have offered suggestions.

Re:Know any good Win32 CLI C++ compilers?

[Katravax]

Oh man, no shit! I am with you, brutha. That screwed-up all-in-one helpfile of theirs is the absolute most difficult-to-use thing they've ever released. I also hate how the WinCE calls all have the same names, and you have to scan to the bottom of a doc to see if you got the CE or the Win32 version of the function when you clicked the item in the list of 15 identically-named items.

Re:Know any good Win32 CLI C++ compilers?

[Katravax]

Please, please, please email me and tell me how you've gotten rid of the runtime! I don't use any runtime functions in my apps, yet still the thing links in the runtime! Can you send me a makefile with the switches you use?

I would actually be quite happy with the Borland compiler if I could figure out the right combination of switches to use to eliminate the runtime.

Re:Know any good Win32 CLI C++ compilers?

[lars]

Err... I certainly hope you are just writing these programs for fun, and that someone is not actually paying you to waste time needlessly minimizing executable size.

Re:Know any good Win32 CLI C++ compilers?

[spongman]

you can install Microsoft's C++ compiler, linker and headers without any of the visual C++ stuff for free as part of the Platform SDK (look for the 'build' environment).

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.

Re:Depends on what you want them for

[Skapare]

Maybe that's why so many web forms (I don't know that you meant web forms ... maybe you meant app forms, but I feel like picking on web forms right now) I see out on the internet suck so much. What happens is that when people use some application that build the site, the page, or the form, for them, they are assuming it will build it correctly and portably. In reality I find that to be far from the case. For example a certain well known web page builder application from a very large and controversial software monop^h^h^h^h^hcompany consistently produces broken HTML. That's probably by design. But the end result is that people think they are saving themselves a lot of time by using ... and trusting ... it, but in reality they often build a lot of resentment, and end up having to do more work just to fix it up. And when these kinds of apps use Javascript to do everything like hyperlinks (instead of using an <a href="whatever"> tag) and forms, it's even worse.

GUI Tools

[EarTrumpet]

My experience with gui tools is having to clean up after one of my programmers writes an application with them. Take a coder that doesn't know a language, add a gui design tool to the mix, and you've got yourself a mess. The latest incident involved some Java IDE...everything looks nice on the developers machine...but when the application was ported to the customer site, it became clear that the IDE used absolute spacing to place all the widgets. The differences in fonts between our development environment and the production environment made the application unusable. Every screen had to be reworked using proper layout managers.

I've banned IDEs for now...perhaps if my developers use a text editor to code they may actually learn something.

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.

Re:The much-maligned command line

[dangermouse]

(DOS sucks,of course, but not because of its command line interface).

IMHO, DOS sucks at least in part because of its horrible command line interface. When I discovered UNIX shells, I was astounded at how much easier it was to Get Things Done on the commandline.

Re:The much-maligned command line

[daviddennis]

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

Re:The much-maligned command line

[scrytch]

"Command line??? How primitive! Look at all the colorful and pretty pictures I have on my desktop, you dirty UNIX user!"

Show me one single usenet or mail list archive post with this sentiment from someone who shouldn't have been canned as a troll anyway. In other words, show me an example of this sentiment used as serious argument. Whereas I see attacks like "point and drool" taken as serious argument every day. As usual, those that can do, do, those that can't argue about it on slashdot (I guess I just indicted myself)

Re:The much-maligned command line

[daviddennis]

Getting rid of the command line isn't evil, it just blocks out a lot of useful stuff. I use a Mac with both 9.x and MacOS X. Curiously, in OS9 I rarely (but sometimes) miss the command line, but in X, I use it for everything. Part of the reason is that the new Finder is still a bit slug-like, but even in Windows I use the command line for most things.

D

Re:The much-maligned command line

[MrBogus]

For MS, removal of DOS was a good thing because it removed the command line

Back in the late 80s and early 90s, there was a huge PC user war between the commandline gurus and their Novell login scripts (FIRE PHASERS) and batch files, and the GUI-friendly userbase that liked the Macintosh and even saw some value in Windows or OS/2. The DOS&Novell guys ruled the roost and routinely berated GUIs as "cartoony" and "toy computers" and did everything in their power to supress Windows 3.

Then businesses realized that GUI environments would save them $Money and the DOS/Novell fanatics were purged in a huge pogrom. They either were reeducated to think "GUI is great! Windows is great! Down with the command line!" or they retreated to using UNIX.

The unspoken legacy of this war is the main reason that CMD.EXE is downplayed in the MS crowd. Microsoft of course is of two minds about the subject - on one hand shipping many advanced admin tools as commandline only, and on the other not shipping what should be standard commandline stuff on the OS media but instead forcing you to install the Resoure Kit.

Re:The much-maligned command line

[Keeper]

You've never spent any real time around people who program Windoze apps have you? I've always got 2 or 3 copyies of cmd open for performing various tasks ...

kill the menu, start the menue, register the typelibs, delete the corrupted obj files, etc... using the GUI to perform those tasks is annoying.

Re:The much-maligned command line

[Admiral Burrito]

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 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:

• Command-line editing sucked. The arrow keys did not work like in a real editor. All you could do was backspace to your typo, fix it, then re-type everything you missed.
  
• Limited command history. Press F3 to bring back the previous line, then use backspace as described above. Alternatively, there is a way to bring back the line one character at a time, then you can type onwards, or press the Insert key exactly the correct number of times to match the number of new characters you want to insert before bringing back the remainder of the line.
  
• Doskey fixed the above two issues, but on most systems it was not loaded (probably due to ignorance). It also came around about the time of Windows 3, by which time hatred of the command line was firmly entrenched and many people were using menu-based shells to escape the torment.
  
• Filename globbing is handled by the command, not the shell. And most commands were not very smart. In unix shells, you can do "cp *.foo *.bar /some/directory" because the cp command just wants a list of files with a destination as the last argument. The DOS copy command, on the other hand, only accepts two arguments. So you have to go "copy *.foo \some\directory" then "copy *.bar \some\directory". The more complex globbing and substitution commands availble in unix shells were totally absent in command.com.
  
• Scripting sucked. All you could really do was concatenate a few static commands into a .bat file. Looping and conditional operations existed, but making them do anything useful required ugly/clever hacks that were beyond the ability of the average user and even most technical users.
  

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 much-maligned command line

[spongman]

yes, CMD.exe is still there, but more important is the presence of the much more powerful, and sadly ovrlooked cscript.exe

Being able to automate COM objects (i.e. most windows functionality is now automatable) from script is huge.

Revision Control

[TornSheetMetal]

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.

Irrelevant.

[rjh]

For one project of mine (a GNOME-based network app), I prototyped in Glade and spent the rest of my time in gIDE tweaking it until it was in a semistable form. It took a helluva lot of time, due to the code's complexity and the tremendously intolerant attitude C takes toward even the slightest failing.

A few weeks later, I decided to learn Python and figured to port this app to Python and PyGNOME as my own sort of final exam; i.e., did I now understand Python well enough to write real apps? Using no tool more sophisticated than xemacs, I had the app running in Python/PyGNOME in under three days.

Part of this is undoubtedly due to the fact that I'd already hammered out the program logic by writing it in C the first time. Part of it is due to the fact Python is a more appropriate tool for GUI construction.

But in the end, a shift in programming language (C to Python) made a tremendous difference in development time and brain-pain. The ``downshift'' from an IDE to a traditional editor made pretty much no difference at all.

The question ``[a]re GUI dev tools more advanced than CLI counterparts?'' is, in some ways, a foolish one. The most advanced tool any hacker has is what's between his ears, and the experience he's accumulated over his years.

Re:Irrelevant.

[PurpleBob]

That is flamebait of the worst sort.

What's wrong with using the programming language which is best for the job, which he seems to have found is Python? Does it threaten your existence as a great l33t C programmer (Look at me, I use -Wall, I'm BETTER THAN ALL OF YOU) that Python might have an advantage over C?

Re:Irrelevant.

[rjh]

This is a good thing, it finds bugs.

Close; it creates bugs. Dynamic memory management is much more reliable when it's left to automated tools; when was the last time you saw LISP or Scheme code dump core on a segmentation fault?

I compile with gcc -Wall. Maybe you should go back to Basic?

Funny. I write code in Ada95, in LISP, in Scheme, in OCaml, in C, in C++, in Python, and in half a dozen other languages too esoteric to mention here.

If you feel that you're a 31337 haX0r because you know C, buddy... think again. There's an entire world of languages out there, and some of them are very, very good.

Free your mind and your code will follow.

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.

Re:GUI's are easy to learn, but never efficient.

[cpt kangarooski]

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.

Re:GUI's are easy to learn, but never efficient.

[Anonymous Brave Guy]

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"

• Right-click and choose "Go To Definition".
• Click on a "load matching .h file" icon on the toolbar, if it's a function in your own class.

Alternatively, for full docs on a library function, how about clicking on the name and hitting F1?

These are all routine things I do several times a day at work in my "inefficient" IDE.

Re:GUI's are easy to learn, but never efficient.

[scrytch]

Here's a nice cryptic example. What's a fast way to find the include file for a function?

Right-clicking on it in turbo-C++.

Or let's get radical, how about an environment that looks for headers in your include path, then puts them in a suggested list you can then edit, so you don't have to bother with finding the damn header in the first place unless it's ambiguous. Could probably program it in vim if you really want to deny that the 'v' (and the 'i') in vi stand for anything but "visual". Unless you're using a keypunch to enter your code, you're using a GUI of some sort.

Re:GUI's are easy to learn, but never efficient.

[ivan256]

I once had a Professor that had a "nifty" little script that included all the .h files in his include path. He never could understand why it took so long to compile simple little programs.

Better to understand how your libraries work. Then you'll already know what to include and you'll write a better program too.

Re:GUI's are easy to learn, but never efficient.

[scrytch]

I once had a Professor that had a "nifty" little script that included all the .h files in his include path. He never could understand why it took so long to compile simple little programs.

Better to understand how your libraries work. Then you'll already know what to include and you'll write a better program too.

Was it out of some desperate desire to be right and superior and put me in my place that caused you to ignore what the hell I said and post that unrelated anecdote? I'm talking about something that finds declarations, not something that blindly includes every header. Doesn't anyone have reading skills anymore?

Re:GUI's are easy to learn, but never efficient.

[Tachys]

Many GUI's have keybinds for most if not all of the menu commands.

So the menus can act as built in reference cards

Re:GUI's are easy to learn, but never efficient.

[Ronin Developer]

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

Borland Delphi. Click on function. F1. Brings up help which tells you where the function is located and its syntax. Ya, I thought so too. :-)

I'm an advid user and proponent of GUI IDEs and am highly proficient in its use. Like any decent tool, there are short cuts and commands that speed you along the way. But, I don't have to switch tools to compile, run the program in the debugger, and then reload my editor...the tools handle this seemlessly.

In the same vein, I have friend who absolutely can't stand GUI tools. He's extremely proficient using the CLI. I find the CLI tools difficult, but not impossible to master...I just want to get the job done.

Kylix allows me to do this. I code in Delphi 6, copy the code over, and recompile and run under Kylix or vice versa. The IDE command set and operations are the same. This means productivity to me. Others, may care more for the CLI. But, when you go cross platforms and have to deal with library includes and such, often having a tool manage that complexity is a Godsend as it leaves you to concentrate on the task at hand and not symantics.

Cheers, RD

Re:GUI's are easy to learn, but never efficient.

[Error27]

In my experience helping CS 1 students, command line tools are easier to learn.

With a command line tool you simple create a text file and you use gcc to compile it.

With the borland or vc++ you have to go through a long process outlined here. The sad part about it is that people will have problems manipulating the compiler throughout the entire CS 1 course. They'll do something like include header files as source files or they'll try to reopen they're source by clicking on a source file instead of a project file...

Re:GUI's are easy to learn, but never efficient.

[leifw]

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.

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 ;-) ) by pressing CTRL-].

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.

Re:GUI's are easy to learn, but never efficient.

[Anonymous Brave Guy]

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.

But if you start customising your editor to hook in the convenient compiler/help/whatever, then aren't you really just working in your own IDE?

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.

Sorry, I'm not sure I buy that. The editor in Visual Studio is already highly customisable, as are the editors of most other good IDEs I've used. With these things, you can often customise keyboard shortcuts, menus and toolbars to your heart's content. They also tend to provide decent macro facilities these days. In other words, they provide much the same "convenience features" as most editors.

Many also now have full-blown automation interfaces. There is a whole market for Visual Studio add-ins, and we use a couple regularly at work. The only real problem I can see is that it isn't a ten second job to set up this automation -- it's great for significant extensions, but not (yet) the sort of tool you'd use to replace your build scripts.

The Hell, You Say...

[Greyfox]

I've done GUI work with visual design tools and I've done it with EMACS and I find that EMACS tends to be less limiting. It also forces you to understand the underlying model of how your GUI works (Admittedly not something you want to do as a Windows programmer.) Better understanding promotes better programming and better use of the GUI features. While it's true that a beginning GUI programmer can more quickly produce a GUI using a visual design tool, he will take more time to improve as a GUI programmer in the long run.

AND, I've seen stunning complex 3D models of a lot of things that were generated using ray tracing programs in which you describe the scene using the ray tracer's programming language. Many of these ray tracings were done before the advent of 3D accelerated video cards and 3D modelling programs. Some of them were done before the widespread advent of the GUI. While a 3D modelling program might get you most of the way to a good look, I'd be willing to bet that your best 3D people still go in and tweak the generated files by hand to get the final look. Knowing how to do that can be the edge between a good 3D artist and a great one.

GUI is terrible for less skilled programmers

[ColGraff]

I'm coming out of the closet - I am not a good programmer. I can do some basic database apps, basic second-year-programming DOS stuff, but that's about it. I can't write games, I don't know assembly, and I have never written a complex program with a real GUI.

That said, I find that GUI development environments are terrrible for me. To get any work done at all, I need to be staring at the code, and nothing but the code. I don't want to click through little dialog boxes to get to parts of my program, and I don't trust the way VB and Delphi hide my code from me. Without not just the ability, but the neccessity to step through my code line by line the old-fashioned way, I'm just lost.

English to E Translator

[Shoeboy]

My undying passion for the lovely Heidi Wall has made me quite the perl hacker. I've gone so far as to develop a little program I call e2e.pl, the English to English Translator. This nifty app lets me translate what people say into what they mean. Let's apply it to this article:

I just got into quite a long argument over on the Yahoo! message boards over the power of command line dev tools.

Translation: Traffic at the helpdesk was pretty slow, so I was wasting time bragging about my 1337 coding skills and Lunix prowess on Yahoo.

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

Translation: Another helpdesk monkey pretending to be a 1337 programmer started flaming me. I flamed back, but I was outflamed and couldn't match his fluent profanity.

Considering he was an avid supporter of anything Microsoft, I take what he says with a grain of salt.

Translation: I called him an "asslicking Micro$oft whore," made some cracks about VB programmers and impotence and retreated.

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.

Translation: I know that slashdot is packed with gifted flamers and CLI enthusiasts, so I was hoping you could give me some good ammunition before I rejoin the fight.

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.

Translation: But I'm not honest enough to admit that I'm looking for ammo so I'll wind up with some lame ramblings about productivity to make it more palatable to the /. editors.

Well, I think that clears that up.
--Shoeboy

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.

Re:Bigotry makes for sub-optimal programmers

[gowen]

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.

How true. I'd like to add the following though. Many people, often with respect to KDE v. Gnome v. plain-old-window-managers or Windows v. Unix talk about how usability is enhanced by common look and feel. Well, for me, an unashamed luddite, Makefiles provide that look and feel. Yes, they work for code, but a good template Makefile for LaTeX gives handy commands for (say) making and previewing in GV, printing, printing reduced to 4x4, converting to a PDF file or HTML and many other useful things.

The same goes for automating validation of SGML or so on. The only trouble is, if I'm ever caught without my Makefiles, I've found I'm completely useless :(

Re:Bigotry makes for sub-optimal programmers

[mgkimsal2]

But - what defines 'best'? If 'best' is measured in time to complete the project, and someone has only EVER used one type (GUI or CLI) learning the other way will (considerable) time to the project, meaning it takes longer, and is therefore not 'best'. "Best tool for the job" is often misused and staying with one tool only becomes a self-fulfilling prophecy.

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:Different, not more advanced

[NSG]

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

Re:Different, not more advanced

[proxima]

Thanks, I was under a false impression.

I stand corrected.

Re:Different, not more advanced

[Faux_Pseudo]

GNU emacs version 20.x amd under does not support color syntext highlighting on the command line as of yet.
Version 21 will do so. If you have a nntp server with a long post life you can find a copy of gnu emacs 21 that i posted to alt.binaries.test about a week ago.
If I get a few requests by email I will post it again.
Or you can do a search on google.

Re:Different, not more advanced

[Faux_Pseudo]

You must be new to the open source idea. The binarie in question is a tar.gz of the source code.

Re:Different, not more advanced

[Skapare]

I'd rather have boxed code instead of colored code. I find boxes easier to read (with thin lines, of course). I'd want to have the loops boxed. Keywords can be colored, and that helps some, as long as I can control the colors (I have a certain vision problem that requires me to control the colors to be able to see).

Re:Different, not more advanced

[doug363]

I generally don't like MFC, and prefer Borland's VCL (and CLX libraries). It is better thought out and addresses the points you brought up, and many other annoyances:

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

Re:Different, not more advanced

[Dwonis]

Depends of your definition of a "binary". If you equate "binary" with "executable machine-language instructions and data", then you are correct. If you define "binary" as "not ASCII text", then tarballs fall easily into the "binary" category.

Re:Thing is....

[mughi]

You can do anything with command line that you can do with GUI. BUT, with CLI or line by line programming you can't design other GUIs as nicely. You can still do it, piece of cake... but to make a really good GUI with standard programming, takes a LOT of time and a LOT of effort.

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.

With a tool like Visual Basic(ugh! VB sucks!) your GUIs and forms are easy to design and manipulate. You can make the same forms and GUIs with C++ or Java but it will take you longer, it's much harder to do complex things and lots of times your design will LOOK awkward.

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?

You wouldn't make a complex 3d model of anything programming polygons... you could.

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.

It's all the same, really

[trentfoley]

Personally, I write my programs in various flavors of assembly on paper with pencil. I then hand assemble, again on paper, but I use pen instead of pencil. Then, I use a machine-language monitor to directly enter the op-codes to ram, either in hex or octal (binary is just too primitive!). This is the only way I truly know what the processor is doing.

And, if you believe that, I have several priceless family heirlooms to sell you.

I'd say it depends on how people think.

[daviddennis]

I wrote a Visual Basic application some years back, and kept on struggling with getting the user interface right. Even something as simple as getting all the buttons to line up consumed amazing amounts of time.

Now I write C code that spits out HTML tables, and the alignment is perfect every time. If there's a problem, it's usually easy to fix - usually as simple as forgetting "<td valign = top>".

And if I'm asked to, say, change the background colour of the page, or switch a whole bunch of elements from the left side of the screen to the right, I can do it, easily.

The only development tools I need are emacs, gcc, and a dose or two of common sense. Not bad, not bad at all.

If you think text, as I do, you are way better off writing programs that spit out text, instead of programs that manually position every pixel on the screen. In my experience, I'm far more productive and create much more attractive applications by spitting out HTML and letting the web browser worry about the pixel by pixel stuff you do with a GUI.

But if you think visually, as I think most people do, the GUI's probably going to work better. It's certainly mind-numbingly difficult to translate a bunch of numbers into a page prototype in my head. But, perhaps, not yours - and that's why we all need different tools.

D

Re:I'd say it depends on how people think.

[scrytch]

Even something as simple as getting all the buttons to line up consumed amazing amounts of time.

Ever thought of using the "align" tool? Or snap to grid? Or hilighting all the elements you want to hand-align and entering the appropriate value for the x/y/top/etc values in the inspector? In the Borland editors, you could even edit the form language directly. Any tool is a waste of time if you don't bother to learn it.

Somewhere in between.

[cygnus93]

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.

Use the appropriate tool for the job.

[w3woody]

The upside of GUI tools, and why I use the CodeWarrior IDE, is that they streamline a number of tasks, making it fast and easy to create a simple application. They also integrate a number of tools which I find quite useful for building a simple application, such as class browsers. The CodeWarrior IDE is excellent for building an application which may consist of a few hundred C++ files, all compiled and linked to a single executable.

However, sometimes you're not building an application. Sometimes you need the power of a Makefile to do something more complicated than "compile everything, and link everything into a single .exe". And that's where something like the CodeWarrior IDE falls down.

GUI tools work extremely well in the problem space they were designed. The CodeWarrior IDE was designed for building large Macintosh applications, such as a word processor or a drawing program: something which largly consists of a single executable program built from several dozen or several hundred source files. The CodeWarrior IDE contains a number of tools which help manage the complexity of all of those source files: file grouping in the project window, class browsing--all geared towards managing a single executable with a ton of classes and sources.

Building a Macintosh printer driver with the Codewarrior IDE (which consists of a half-dozen separately linked code resources) is a pain in the neck, but doable. The last game I worked on, which consisted of a very simple engine running an ad-hoc compiled scripting language was a royal pain in the ass: first, build the compiler. Then, outside of the compiler environment run the compiler on the half-dozen scripts. Then, in the compiler environment, build the game. With a makefile this would have been reduced to one step. And I could have prevented errors where the compiled scripts were built with the wrong version of the script compiler.

I think the short answer is you use the right tools for the job.

real shells?

[anshil]

A lot of people who grew up and are used to windows prefere the mouse and clicks over keyboard and strokes. They tend to say that with the mouse they can do faster then with their shell.

Sure it's because the command line interface windows ships with is the DOS-Box, actually a very bad and lausy shell. Sure you're faster with explorers cut&paste than typing things into the DOS box.

But most of these people never touched a bash shell. Those who learned to use a 'real' shell (bash) will most likely always prefer to use it against point+click tools, since the shell allows you to write powerfull commands very fast, through technics like tab completion. And for the advandaced user he can even enter commands to be executed in loops.

Try to write apply the program X against all n files ending with .x, In the Dos box? Impossible but entering n times the command, in windows explorer? possible but nasty, since it requires you to select all .x files seperatly, in a bash shell? No problem just write
for i in *.d; X $I; done

finished! It might take once here and there an hour to study the advantaged features a real shell might offer, but for people having to work 8 hours each they with a computer they pay easily of in the long run.

It's like a cashier, in his profession an expert. No cashier wants to use a point&click interface, it would take them indefintly to enter a more compilicated invoice. owever a secreaty having to write just one invoice each day, she will not want to spend a weak to learn the real cashiers interface with all it's short cuts, she will like to click on a menu, look what it offers, drag down to a submenu, look again what it offers, select a item, and fill out a popup box. This takes her say 1 minute. Fine since she has to do it only say once a day. However a cashier working on a line having to enter 1000 entries each day this is unacceptable, however he knows his interface designed for the professional very well, he hits in example CTLR+R, A, 15, Enter and is finished, took him 5 seconds.

Same is it for programmers, shell's. makefiles etc. all take their time to learn, and a hobby programmer will prefer a point&click interface. While one working heavily with these tools day, day out, will prefer a makefile far over the project settings dialog, since it allows him to write more powerful commands in shorter times, but in contrast to the dialog it requires knowledge/training to understand the makefile language.

Re:real shells?

[anshil]

I think you explained in another words what I was trying to say.

The advantage to point-n-click is that the options are most likely laid out for you in the open, thus not requiring the memorization of commands. With a CLI, you have to know exactly what you want do to.

It's exactly that, for doing a task the first time a GUI is definitly faster in hours. For doing a task 8 hours a day, a deticated interface is doing faster. Since the time used to learn it once is compensated in future uses.

Just look at the supermarket, imagine the chasier would have PC keyboard, and even a mourse, I wouldn't want to wait in the queue.

I took the secretary as an example, since normaly secretaries have a huge bantwith of tasks to do, but again normally they learn typing
fast with 10 fingers, a lot of programmers don't work on especially. Okay that's a value dated a little more back into time. Today you value people by their ability to solve tasks themselfs, and having a wide spread spectrum of tasks it is effectivier to have user interface for each one which are more intuativee compared to more effective interface you've to be especially trained.

Again the 'project settings' dialog for MFVC. Somebody looking the very first time at can very quickly understand how to turn on and off diverse compile options, while learing how to use makefiles takes up a weekend.


So please get off your high horse and realize that these are different tools for different purposes.

Didn't I say that? However for people that program day and day out, having to learn an dedicated interface pays off. I agree that implementing GUI software with a GUI possiblity to click components on a form. However in example I disliked in example Kdevelop because last time I looked at it, it didn't allow me to use my makefiles, it inseted to use it's autogenerated ones.

Okay the for loop was a bad one :/ Espeically I must confess, I use them very seldom sensefully directly at command line (shell scripts are something different, but this is not a CLI then per se).

I will try to take another example 'vi'. Imagine you're used to windows only (as I was). During the first time you use a unix system you'll sooner or later dump against the editor vi. Accidently it will pop open, and you think fuck what's that for a stupid, ugly thing. And how the hell to I get it away? Well after reading some minutes a man page you discover that :q will do, and you thank haven that it's gone. However as time passes by, you don't always want to use in example kwrite, because you're currently hacking on your installation and x-windows doesn't yet boot up, so you read and learn how at least to edit, and to save a file, so you use vi as a emergency backup, it will always run, even if everything else fails. One time you'll have some minutes free you decide to look how copy&paste is done, since in some config files you feel stupid repeating every line, character by character. And so you slipped into using it. Once nearly unnoticed you'll start to edit your c source files, and you think, hey that thing has syntax coloring, not bad after all. So you use it here and there. From using it and having free minutes you'll slowely start looking for command after command. And suddendly you think, wow 'vim' is a really cool editor, I allows me to do things fast and efficient, the interface is stale and looks like hell, but it's possiblities seem to be nearly without limimts. I guess today I know 10% of it commands and it's allows me seamless editing. I used all these editors before the DOS-Borland-IDE, MSVC, ED4W, UltraEdit, KWrite, SourceNavigator, all of them were graphically more appealing, easier to learn&understand, but today I personally prefer 'vim' over all of them. Thats how an applcation you hated and wanted to go away slowly turned into one of you're most beloved tools.

However yes, as a programmer I edit plain text files all day long, hour for hour. I agree that somebody having only to edit one config file once in a weak, having to learn vi block command is over kill.

Just like I want a GUI to be able to add some numbers, I don't want to learn the interface a cashier has to use and will prefer. I don't care if it takes me 20 seconds or 3 minutes, I do it only once in a month.

That's my opinion for CLI vs. GUI

-
And please if you don't agree with click reply, don't moderate me 'OffTopic' that's definitly false since this is on the topic the thread was started.

GUI dev tools are necessary

[glassware]

Are you serious? GUI tools are incredible nowadays.

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.

Re:GUI dev tools are necessary

[stripes]

I can run the program and step through the source code in another window.

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)

The editor highlights my code in color, and I can expand or contract each class definition.

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.

In a project window, I can see all the files available and check them in or out of source code control.

I'm unconvinced that that is really better then using ls directly, but whatever floats your boat.

When I move my mouse over a function call, I get a popup with the list of arguments.

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

I can standardize my comments and have the development tool create new classes for me with my comment scheme already in place

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

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

Did something prevent you from opening anew xterm window to search from things in a CLI?

Make scripts are generated for me automatically

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)

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.

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.

Re:GUI dev tools are necessary

[anshil]

Let me guess, you use MSVC, right? :)

However that's all not necessarly GUI releated.

I can run the program and step through the source code in another window.
gdb can do this without graphics, altough I admit for debugging I also prefer a graphic interface like ddd.

The editor highlights my code in color, and I can expand or contract each class definition.
Nearly every editor can today do syntax coloring, that includes emacs and vi, which are non GUI.

In a project window, I can see all the files available and check them in or out of source code control.
> cvs -n upd | grep ?\
will in example do the same, list all files which are not in source control.

When I move my mouse over a function call, I get a popup with the list of arguments.
btw. CTRL+Space will do the same, without having to wait 5 seconds. well vi can also use tags, well yes it doesn't pop, but you can let it open another windows showing the class interface definition.

I can standardize my comments and have the development tool create new classes for me with my comment scheme already in place.
Standarize you comments has nothing to do with GUI, also creation of classes from a temple has also nothing to do with GUIs. You reverted only to list MSVC features :o)

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.
Yes code browsing is a matter of GUI, but having it in the same application is a matter of IDE, if I forgot a constants name but know it's value I type:
> grep -r VALUE

Make scripts are generated for me automatically.
Again what does that have to do with <Gaphic <U>ser <I>nterfaces?
Automake or autoconf also generate very nice scripts automacilly.

Re:GUI dev tools are necessary

[glassware]

I appreciate your thoughtful reply to my post.

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:GUI dev tools are necessary

[stripes]

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.

Other then the dislike of meta-languages, that's all fine. After all none of that will significantly lower your productivity as long as a decent IDE is available.

However meta-languages are extremely useful, if you ever do anything in their problem domain. I first had to use lex and yacc in collage. I never used them before that, I didn't really pay much mind to them. The first time I was forced to use them lex seemed clumsy, and inefficient. Yacc on the other hand, even the first time I used it saved me a ton of effort. Now that I have used lex once or twice it saves me a lot of time as well.

Of corse if your program never turns text into tokens, parses the tokens into something like statements....well then you won't gain anything form lex and yacc. Of corse now that I'm use to them I use them for things like config files where they can do far more then I need, but what little they are called on for they do with far more ease then writing the code myself.

So if you will ever do anything like that more then, say, once, you should go out and try them. Enjoy.

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.

You really remember what all those little icons on the tool bar are? I have to scrub the thing with the mouse to find out. Esp. next vs. step. Of corse I only remember what three grep options are -v (show non-matching lines), -E (regex), -l (show matching files not lines). I hardly use most of those, but I practically never use the others. So I have to skim the man pages once in a while too (more frequently for cvs, for things like making branches, or getting a revision by date).

I have no doubt that if I was required to use CLI tools daily, I would grow to appreciate them as you have

You might, they have a few advantages. But other then meta-programming they are not earth shatteringly large, and GUI IDEs have their own advantages. I just don't think they are worlds apart like many people do.

I may even stumble across and IDE I like as much as the Unix CLI some day. This year I'm giving Apple's a try. IBuilder at least seems worth some time :-)

VISUAL STUDIO SUCKS...

[tjuricek]

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

If you're implementing a lot of GUI...

[osgeek]

Take a look at the development tools for MacOSX (the ones they got from NeXT: Project Builder and Interface Builder). The way that Interface Builder allow you to almost completely separate the GUI of your program from your data modeling code is beyond amazing.

I can't believe that the computer industry has been so slow in copying it.

depends what you are doing

[josepha48]

It really depends on what you are doing. For anything server side, there really are few GUI tools that can optimize the code to make it fast. How many server side GUI tools do you know of that output kernel code? How about clean readable C?

If you are doing GUI develoipment like a user interface, then maybe this is true. If you are using something like PowerBuilder, Symantic Visual Crape oh I mean Cafe, Visual C++ or Visual Basic or something like that. Few GUI tools output optimized readable code. When the GUI screwes up it can be a real pain to debug. Trust me I have been there done that.

CLI can be effective for somethings as well especially in the case where the server is remote and you are using telnet or ssh to get to the server. There are editors that will open telnet/ftp for you and allow you to edit remotely.

Personally I like to use a program that does syntax higlightening with code completion. Outside of that the GUI's are pretty crappy IMHO. This to me gives me a somewhat happy medium. I get readable code with code completion and can limit the bloat. I can use the GUI help (many tools seem to lack that) to tell me the syntax of commands I don't know, which is very useful.

A Case for GUI Interfaces

[Cr3d3nd0]

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.

It all depends...

[HiThere]

If you just want to do what the designer of the IDE (N.B.: GUI or not, unimportant) wanted you to do, then the IDE will be faster and easier.

If you are designing a GUI interface, then a GUI tool will save you untold amounts of grief.

In other cases, it doesn't seem to matter. A well designed IDE will make it easy to get help on various features, and may be language, and even, to and extent, library aware. And certainly syntax highlighting is a real bonus.

On my current project (development on Win95):
Language: SmallEiffel
I am using the tools:
GWD Editor: This is where I do the coding
SEED IDE: This knows about what classes are available, what their features are, etc.
SmallEiffel: This is the compiler
CygWin: This is the execution environment. (Because it allows me to re-direct standard error to a text file, for picking up with GWD Editor)

But I'm not doing GUI design. If I were I'd be using Object-Tools VisualEiffel or ISE Eiffel. ISE would drive the cost up by about $1,000, but would probably be easier to use. Visual Eiffel would entail figuring out how to use their dialog builder. None of these would be portable. Portable would require using Glade on Linux, and figuring out how to make the code work on Windows.

It's often all about code generation

[dmorin]

Think of it this way -- if 90% of my time I generate the same 100 lines of code, and a GUI gives me a button that will generate those lines for me, then it is faster for me to do it that way then to type it into a text editor every time. However, I think that's where the mistake likes -- GUI people tend to think that us CLI people are always typing shit into Emacs. They don't realize that most of your editors can do the same kind of code generation that a GUI can do. I think the only thing the GUIs have ever been better at is situations where you want to visualize what you're building without lots of compiling loops in between - such as screen painting, in the Java world. It's very hard to get a layout manager just right when you have to compile and run every time just to see it.

GUI tools simplify debugging and GUI building

[esnible]

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.

Different strengths

[Anonymous Brave Guy]

This is a very odd discussion. Some people seem to be thinking of their favourite IDE compiler vs. their favourite CLI compiler, for example.

I think the merits of the IDE vs. the command line are actually quite simple. A good IDE will provide useful tools to help find your way around your code. This may not be necessary for a typical /. hacker, but it's essential to working on large-scale projects in a team of more than one. For example, IMHO Microsoft's Visual C++ shines in this area. It provides quick and easy-to-use tools to jump around a long file, or between files in a project; I can find definitions of things, references to things, or a list of base classes or derived classes for the class I'm working on with a couple of mouse clicks. I also find things like syntax highlighting to be useful. I don't much care for the v6.0 compiler itself, but the IDE is undeniably useful in my line of work.

Of course, you could argue that a nice Emacs set-up or some such could also do these things. But the fact is that with a proper IDE, they're already done. By the time you've programmed this all into your favourite highly-customisable editors, aren't you just working in your own IDE anyway?

On the other hand, when we build our MLOC project with VC++, we use our own script files to do it, calling good ol' CL.EXE to do the compilation. Why? Because it gives us the level of control we need, and is easily changed. The project/workspace system used by VC++ isn't up to the complexities of our project when it comes to getting builds done safely and efficiently.

And here we see the key difference. IDEs can be very helpful for reading and writing code: good tools in an IDE can make everyday tasks easier than any CLI toolset I've ever seen could even dream of. But no IDE I've yet seen matches CLI for its scripting abilities and fine control over the build process. Both are important. In today's world, a compiler that provides both an IDE and a CLI is a good solution. In an ideal world, I'd like to see an IDE that allows the build process control of a CLI without the need to drop into independent scripting. Surely such a tool can't be far away.

IBM Visual Age products...

[RGreene]

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.

Re:IBM Visual Age products...

[Salsaman]

Yeah, VAJ is a wonderful IDE. And the beauty of it is, it looks and feels *exactly* the same on Linux and on AIX (probably NT too).

Re:IBM Visual Age products...

[PhiRatE]

I would try it, but the only release for linux appears to be 3.02, and they've released v4.0 now, not to mention the next generation Studio product. Whats with that?

Re:IBM Visual Age products...

[leifw]

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.

Re:IBM Visual Age products...

[Bodrius]

I had the unfortunate experience of depending on IBM Visual Age for Java for a while.

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 .java works fine, but it shouldn't be the way to go).

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.

Re:IBM Visual Age products...

[Skapare]

You'd be surprised. Managers do seem to have the concept of negative numbers when it comes to deciding how long it will take to get a project done. "We promised this to the customer the last thursday before the last monday three weeks ago, so this needs to be delivered on time."

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.

GUI cvs Command. Why not have both?

[robinjo]

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.

Graphical editors

[MikeBabcock]

I use gvim, fwiw, as a GUI development environment. One of the featurs of MS Visual Studio I'd love to have though is pop-up arguments assistance. If you enter, for example:

if ((buf = malloc(

then all of a sudden, "size_t" will pop up in a smaller font right above your cursor, to tell you malloc expects a size_t argument now. This is just one example of the fast assistance I've enjoyed when using VC++.

GDB-Insight

[PrestoChango]

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.

A few issues

[Matthew Weigel]

There are quite a few issues bound up in GUI/CLI development wars, and here's my take on a few of them:

• IDE, versus separate command line tools: In general, an IDE is essentially an interface designed with the programmer in mind - it accelerates common tasks that a programmer might want to do. In general, the command line is an interface that put some thought into shell programming, but not (e.g.) C programming. Debugging and compiling is nicer in an IDE (and this includes emacs in cc-mode), and a good IDE will handle context-sensitive hypertext in a useful manner (providing the function signature of the function name you're typing in, for example), which will make you more productive in the programming phase. The problem is, a GUI can generally accelerate tasks for which it accounts but can do very little to let you do tasks for which it does not account. So programming with an IDE will probably make you more productive, but the command line can never be too far away. Contrariwise, half a dozen xterms is a very powerful, generic interface that lets you be quite productive in activities surrounding typing in code. Depending upon one's familiarity with the command line, either one is very good.
• Developing a GUI through a RAD tool, versus building it programmatically: quite simply, if you're trying to develop a GUI, then use a GUI. NeXTStep/OS X's Interface Builder is the top of the line for this, but most tools are good enough that you will be far more productive putting the interface together through a RAD tool than you will be trying to describe the interface in code. Here's a simple test: how do you design the GUI? Hopefully, with a pencil and paper - if the GUI accounts for Fitt's Law, information prioritization, etc., it's just a lot easier to figure out how things should look by drawing it. Now, which is easier - dragging interface objects around to create a usable representation of that GUI, or specifying the layout piece-by-piece in your code? There's simply no comparison, a GUI-building application should be considered necessary for building GUIs.

My general solution? I use whatever editor is accessible in xterms (or Terminal.app windows) for most of my programming, I use emacs, joe or Project Builder for compiling and debugging, and I use Interface Builder for building the GUI. I can do everything but building the GUI anywhere I find myself, at any computer (and I hop around quite a bit so it's a definite gain over restricting myself to a GUI IDE), and I am able to leverage my knowledge of text editors (held over from writing a lot of non-code documents) in writing code.

What about UML modeling tools?

[Mindbridge]

Most of the people here seem to equate GUI development environments with RAD tools for fast building of UI forms (dialogs, etc). [I do not mention the "IDE aspect" here, since few would call Emacs a GUI tool, but it can be a full featured IDE nevertheless]

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.

There is a glade for python

[Ukab the Great]

There is a glade for python. Many languages with Gnome/Gtk bindings have tie-ins to Glade. Though I'll take perl glade over python glade any day of the week.

I bent my wookie

[Graymalkin]

One thing I haven't seen mentioned so far is that a good IDE will not only help you navigate your own complex code but it will also help you navigate other people's complex code. I've seen some well documented source before (usually CIS student's work) but for the most part I've found commenting VERY lacking on alot of projects. A good IDE with an object browser is great for browsing functions that aren't very well documented or commented.

Re:I bent my wookie

[Graymalkin]

That's exactly what I said you dumb piece of shit. Your mom must have shit the best part of you out during a contraction. An object browser lets you browse the functions in the code (especially big libraries of source files) very easily so you can quickly accustome yourself to the functions in question. The sort of questions that are important like what sort of value the function returns and what arguments it expects. Far too many times have the bugs I've run into in other people's code are where a second programmer didn't call the first programmer's functions correctly so shit died unexpectedly when some special case came up that some obscure boolean argument would have handled (is device0 active, if none given assume true sort of situations) but was not required by the function. It's anonymous cowards like you that make me dislike anonymous cowards in general.

Let's ask some of the state-of-the-art programmers

[jelle]

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.

GUI? Get real

[NitsujTPU]

GUI environment tools don't offer ANYTHING above what the command line offers. Have you EVER done anything serious in a "visual" language that couldn't be done better in raw code? Higher layers of abstraction don't mean better code. It all gets translated down to machine code in the end anyway, or linked against something else.

However, who gives a shit? It's not the quality of the user interface, it's the quality of the end product. All of this has very little to do with your IDE anyway.

Re:GUI

[Mr. Slippery]

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.

Sometimes, yes. For example, there are tools that provide a GUI frontend to CVS (e.g., tkCVS), or to the MH mail software (e.g., exmh). That's a great approach, because you can still use the underlying CLI programs in scripts, or over a telnet/ssh session, or whatever.

However, the usual GUI way of things is that there is no CLI program under the GUI - the only interface to the software is the GUI. Suck.

I've never been in a shop that used GUI tools for programming; but then, I've been doing lower level stuff like operating systems, firewalls, spacecraft ground systems, and telephony. If I were putting together pretty GUI apps for end users, I might have a use for a GUI GUI-builder tool.

But for what I'm doing now, I want and need nothing but GNU emacs, gdb, and the C++ compliler. (Which is IBM's "Visual Age", though none of us use any of it's "Visual" features!)

Pointy and Clicky is good

[Ukab the Great]

If and only if you know what you're doing and understand essential principles of interface design. Unfortunately, this last sentace really doesn't describe most of the folks at Microsoft, or for that matter most of the people in the windows development community (actually, it doesn't describe most of the *nix community, either). Saying that all GUI's suck and pointing to M$ designs is like with like saying that all tires suck and pointing to Firestone. I love GUI's and pointy-clicky things, and because of this, I have a hatred of the Windows that even the most die-hard linux zealot cannot begin to fathom.

pointless war

[macpeep]

This is a completely pointless war about something that everyone can just decide for themselves. Use whatever works best for you and you find most comfortable. That goes for operating system, development tools and everything else.

Personally, I code Java with nothing but a couple of command line shells, a bunch of scripts and a good text editor. I write even GUI code much faster that way and I have much more fine grained control over it. I have or less memorized the whole Java core API so I have no problems with doing it all by hand.

Then.. there's C++ and in particular, Windows (Win32 and WinCE/PocketPC) programming with Visual C++ and Embedded Visual C++. Here, I prefer the Visual C++ IDE because of a few things:

- When I write code, the IDE shows me what parameters each method takes. It shows me what methods and properties classes have as I'm writing, etc. When I write foo->, up pops a window where I can select and tab-complete the rest. When you learn to use this, you code MUCH faster. Also, you don't have to memorize the entire API with parameters and all, since the IDE helps you out.

- Debugging. You see the source code right there on the screen. You can step through it line at a time, step into methods that will automatically bring up that file and jump to the correct line.. Put the cursor over a variable and it shows its value. A good stack trace that you can click on to jump to that piece of code.. Drag and drop watches that allow you to write expressions right there in the watch window to figure out fixed point numbers to integers without a separate calculator.. etc. etc. etc.. For serious debugging, you can't beat a GUI imho.

- You still have cl, nmake, cvs etc. in the command line so if you want to work from a shell, just go ahead and continue from the project from there.

One more thing.. A lot of people under estimate the NT command line. I've seen people that are totally surprised that I have grep, tab completion, Perl etc. under NT / Windows 2000.

My advice is to not knock things until you've seriously tried it out and used it enough that you can actually form an objective opinion on it. I bet most people here who think Visual C++ / Visual Studio sucks have never even used it or just used it for something very very simple.

It's not a war. It's not about UNIX vs. Microsoft and all the political bullshit. Just pick the right tool for the right job and use whatever you find yourself most productive with.

Re:pointless war - one more thing

[macpeep]

One more thing about debugging in Visual C++.. When you have a complex inheritance chain for some object, you get an expandable tree right there in the watch window, that you can expand to see the values of member variables for each of the inherited object. Absolutely brilliant. It's hard to provide something this visual and intuitive in a command line.

GUI's have been scientically proven to be faster

[Ukab the Great]

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

All that's pretty easily done textually...

[SuperKendall]

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.

GUI aginst CLI

[fidros]

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 ... well, cave drawings.

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.

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.

The Best of Both Worlds..

[swdunlop]

When I'm doing C, or Python, I use KDE's Kate, since it provides me CVS control, and an interactive terminal, all in the same window. It's simple, unobtrusive, and doesn't require a massive investment in time to learn, unlike KDevelop, CodeForge, et al.

When I'm coding for my own personal enjoyment, I do so in Smalltalk, using Squeak. If I had an IDE nearly as powerful as the classic Smalltalk-80 systems, I might actually use them. Some of the features I use heavily is the class browser, which, instead of being just an afterthought and an add on, is tightly integrated into the cycle of development, the object inspector, which provides an excellent way to snoop inside your instances, and even allows you to invoke their methods using a little command window, and, finally, the fact that the every object in the system is categorized in that browser, makes it very easy for me to determine exactly what each method does.

I just wish Smalltalk VMs weren't so focussed on maintaining the entire virtual machine in one monolithic image. While it does have a certain conceptual grace, it makes it a little thorny distributing applications, although Squeak's newer package distribution mechanism is changing that for the better.

Every tool has its ups and downs

[Zzz]

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.

- 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. .. and you never have to wonder whether they will live after cvs is done with them (projectfiles are really allergic for unix-returns)

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

Comic Books or Reference Manuals

[Veteran]

Many more people read comic books than read the Handbook of Physics and Chemistry. That does not make comic books correct while the handbook is wrong. Gui IDE's and CLI tools have about the same relationship.

If you are doing something light with a GUI - which is most programming these days - an IDE is a good way to do it. If you are doing an asteroid orbit research tool - upon which the fate of humanity might depend - a CLI with a Fortran compiler is the correct way to write it.

People who write light weight apps - a database for a secretary to use - need to understand that they are not the best developers in the world, and that perhaps their opinions on how to write code are not exactly profound.

Most developers who use the Microsoft IDE tools believe that Microsoft uses those tools to develop code for Windows itself or to write programs like Word or Excel. They don't; the tools which they do use are not for sale. That is part of the reason that you can't compete with Microsoft; they have a lot better tools than the ones that they will sell to you. The only Microsoft app I know of that was written with one of their IDE tools was Microsoft Money ( written in Visual Basic). The last time that I checked Microsoft Money was not one of their core money makers.

dev guis

[snillocneb]

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.

GUI tools means that I don't to remember all that

[crovira]

crappy ideosyncratic syntax cobbled together before the industry ever hear of writing specs, QA or who the fuck is actually using the boxes.

It ain't the geeks. It ain't the dweebs and it ain't people with progidious memory capacity.

Its people who are trying to get something done and having to memorise all this crap (what directory did this make file put the modules into, and why is this called that and who are all the users, real or virtual, with accounts on this machine?)

I end up writing code in Squeak! to work on my Linux box (and my Macs,) because I can FIND the damn code, its ORGANIZED, its EVIDENT and I don't get fuckin' tripped up trying to do things only to be stymied by some idiots lousy sense of spelling or lack of QA or their pathetic punsterish humor.

I'm trying to USE the tools not be a toolsmith but man pages are illegible and explain nothing and every fuckin' dialect and distro seems to think its their God given right to fuck with the directory tree.

I just want to get what I need to happen, to happen. Me and the majority of people stuck with Windows.

Got a problem with that?

Re:GUI's have been scientically proven to be faste

[MobyDisk]

That is not true. I spent a semester studying this phenomena, and as a matter-of-fact everything I raid concluded that the keyboard was faster.

This comes back to what application you are talking about. For a paint program where the user's hand is on the mouse, menus are faster. For a data entry program keyboard input is faster.

Ask Microsoft...

[MSG]

As it's been pointed out, pretty much all base dev tools are CLI. Most IDE's provide an editor (which really *has* to be GUI), a form editor (which is usually faster than designing forms from scratch, but usually gets tweaked afterward), and a debugger (about as GUI as an editor...). The differentiation between MS tools and old UNIX tools isn't so much GUI vs. CLI, but GUI vs. terminal. The GUI is just a prettier terminal, really. When you realize that, you can stop comparing the tools based on whether or not it has some superficial icons and menus, and compare the *individual tools* for their qualities. I certainly think that Emacs in X is very GUI, and a great IDE. I can accomplish things much faster with Emacs than I ever could with MS VC++.

However, if that doesn't satisfy you... If you're really looking for ammo against the GUI users, then here it is: Microsoft uses Perl, a couple of UNIX tools under DOS, and their CLI compiler to build their software. Does that qualify for "state of the art"?

A shameless attempt to get this article read

[Travoltus]

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.

Re:pointless war - one more thing

[macpeep]

"Firstly, how do you view the contents of an array in Visual C++?"

Well, you can write in foo[5] in the watch window. :)

"And secondly, how the hell do I call a function from the debugger?"

Why would you want to do it while running the app?

Depends on the design of the tool

[John Whitley]

The CLI vs. GUI argument is hollow. The real issue of how well a tool meets the needs of the users (in this case, developers). Good GUI tools have been designed, and good CLI tools abound. But just making a CLI tool a GUI tool does not necessarily improve it in any way, and can make it significantly less powerful.

First, I'll cheat, then offer specific examples. 8-) Just how useful would the *nix "cut" utility be in a GUI form? Answer: not at all! cut is essentially a function, designed for the functional programming environment of the Unix command line. The synergy of applications that can use the command line, be scripted in various manners, and communicate with one another is powerful.

One case study/gripe: At work, our C/C++ vendor's toolset uses the CodeWarrior IDE as the front end for build management. I can now categorically state that as a build tool this IDE is MUCH more limited than good old fashioned Makefiles. When I'm PO'ed at the tools, I often say things like: "great IDE for toys!" These limitations are both functional (e.g. the outright ability to accomplish the desired build structure) or simply awful UI design. It almost seems to have been an IDE not designed or written by people who actually develop software!

Another bit of GUI software: Visual SourceSafe (yes, MS's source control software). VSS' source control model basically sucks, which is why we're transitioning to CVS. Nevertheless, the GUI does have a few good ideas in enabling developers to manipulate and visualize the code database. For this very reason, tools like {Win,Lin}CVS are available to provide a convenient visualization front end. Excluding the source control model, which is better VSS or CVS? CVS wins, because it provides scriptable functionality AND the advantages of GUI-based visualization and interaction. The right tool for the right need.

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.

Interruptions and distractions slow you down

[xant]

Think context switches. The reason why people hate the animated paper clip is not that he's cute, or that he's bloatware. My mom hates the paper clip even though the cuteness appeals to her and she does not know what the word 'bloatware' means. She hates him because he interrupts her when she's working. She learned how to turn him off.

In the same way, GUI tools can interrupt your work process. Going to the mouse to select something from a menu is ok when you have never found the option before. It's unquestionably faster than looking up an option in a man page for many operations that GUI dev tools support. But taking your hands off the keyboard to put them on the mouse is an interruption. If that's the only way you can get to the option (other than switching to your xterm, which entails an even more egregious context switch), or, if that's the only way you've learned how to access the option—which it frequently will be, because that's how the GUI teaches you to do it—you waste cycles. You get distracted. Concentration is broken, and you have to do hand overhead, brain overhead, and searching-for-the-right-spot-to-click overhead.

The keyboard, on the other hand, is under your fingertips. No context switching necessary.

You might think I'm arguing against GUI dev tools. You would be wrong. GUIs are a faster way to learn what tools are available, and even to show you some tools that you might never have found when faced with the black hole of the command line and no prior knowledge. RTFM is fine, but most people read only enough to solve the problem they think they have. A GUI presents lots of options in an easily-digestible and memorizable hierarchical format (if designed with a minimum of care). You'll see a lot more of the tools and options available to you, and that alone can save development time.

This has been said many times before me: context switching slows you down; so does a steep learning curve. One is better for beginners, the other better for experts. But I still believe there is a best-of-both-worlds solution out there. How about these two things:

• Every time you switch to the mouse to do something, you get an entry in a history file for that GUI. For example, I just picked Tasks->Tools->History to get to the history window in Mozilla. How about keeping a record of that action around? How about a small menu history listbox on the right edge of the menu. That list box would now contain "Tasks->Tools->History (Ctrl-H)" and if I picked it from that list box, I would again get the History window. If I then did View->Apply Theme->Modern I would get yet another entry in that listbox. This helps you memorize where the things are that you use. It also helps you pick them faster by flattening the choices available and paring down the options to those most likely to be picked again.
  
  The same principle could be applied to toolbar buttons. The listbox could instead say "Button pressed" and display an image of the button and the keyboard shortcut to get to it.
• Notice that I included the (Ctrl-H). The keyboard shortcut is still the fastest way to get to that menu item: Leave fingers on keyboard, don't use mouse. That keyboard shortcut ought to burn itself into your brain every time you look at it. How? Make it more important. When you stick something into that menu listbox I just talked about, the keyboard shortcut should appear bright, bold, colorful, and then slowly fade to the same emphasis as the text next to it. You will notice it, but it doesn't interrupt you. You will learn it, and you're more likely to try it next time.

Here I used mozilla as my example of a GUI dev tool, which it clearly is not; in a browser your hand is on the mouse most of the time anyway. You can still see how this would be applied to a GUI IDE though.

Re:RAD tools are okay for mockups, NOT for real ap

[update()]

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.

Have you looked at Qt Designer? It does exactly what I think you're talking about.

OK, my take

[Chris Johnson]

I do this: Mastering Tools Pro

I do it in a slow-ish heavily GUI 'toy language' with its own memory management and elaborate, pre-made objects, because there's only so much I _can_ do, and I have goals. There are particular things I want the software to do. I choose a weird interface (very text oriented!) for the program, but within that interface if I need to shuffle the positions of the parameters for high frequency sidechain compression, I want to select pictures of the things and drag them to the new places and build the app and have it run, just like that.

If I decide that the delay lines, measured in feet or millisecond of delay, must have the control's background a shade of gray that relates to how 'far' the echo is, for quick visual appraisal of the state of the app, I want to type in a quick me.color = rgb(255-HowFar, 255-HowFar, 255-HowFar). Yes, to some extent this is OOP- but where do I find the place to type that code? In the environment I'm using, I look at the mocked-up app and doubleclick the box and a code browser pops up, open to the _wrong_ event of the _right_ control. It's not perfect, but it gets me there...

GUI isn't about making Super-Genius-Coding-Man more effective. SGCM is already effective, the closer to the raw words and letters and symbols of code the better. It's all in SGCM's head. GUI is about making _me_ effective.

And if you're SGCM, you are perfectly free to feel totally superior to me, but you know what? I can hardly code, but what I'm trying to do is push the boundaries of digital audio mastering and wordlength reduction, and this is very specialized stuff.

If you are SuperGeniusCodingMan, are you programming something original- or are you strutting because you can use raw C and hand-hacked makefiles to produce... an IRC client? >:)

Re:Programmmers create code, Clickers Push a Mouse

[Billly Gates]

John Carmack, creator of doom, and quake1, 2, 3 and probably one the best programmers in the world prefers ide's over editors like emacs or vi. So I do not think its code creation per say that programmers like but its nice to have class views of your c++ project files as well as msdn which comes with visual studio. This is what alot of programmers like about them. I am sure quake is huge and these ide's are great for organizing lots of different files and viewing multiple classes.

However, I see alot of so called programmers who know dick. They like to edit, cut, and paste code and use tools to create it for them. I agree this is a bad practice that makes poor programmers. If you do not know how to code something you need to learn how to do it yourself. Or if not, take a look at some code and retype it yourself and learn it and not cut and paste it.

When I wanted to learn Java, I tried Sun's Forte. I hated it because it kept generated code to do things. I then switched to VIM and got a few good java books instead and learned how to do them maunually. My ideal gui would be one which had a cli editor in it but was integrated with things like online documentation and class views. Kdevelop is the closest thing to this. I would nix the automantic code generation though. It does not take alot of code to generate some buttons anyway and would increase long term productivity if the programmer had to learn some essential functions himself.

Re:RAD tools are okay for mockups, NOT for real ap

[Pete]

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!

Ah, another wx fan :).

I'm guessing you're a fairly recent wxPython convert, otherwise you would have already heard of this, but anyway - wxDesigner will almost certainly fit your needs. The author is one of the primary developers of wxWindows and he sells wxDesigner (quite cheaply - student license US$19, single-user license US$89, 10-user license US$299) as a closed-source extra.

It can be used with C++, Python or Perl code.

Pete.

Re:GUI is not mutually exclusive to automation!

[Skapare]

Show me what a script that automates a GUI app in Windows using COM looks like. I just want to see if how they do it makes it all a POS (e.g. too complex) or if there's something real that the X Windows world forgot to do. You can put one up on a web page or ftp server and reply with a link, or if no such access, email it to me and I will (you'll have to find a rot13 app to decode my email).

Dynamic forms and HTML

[Skapare]

Virtually every form, and most pages, I've built are really dynamic. There are lots of static pieces, but overall it's dynamic. I've done this in C and PHP. One example is http://linuxhomepage.com/ done in PHP on the front end and C on the back end. I'm not sure how anyone would build that using all GUI tools. That's not to say that GUI tools couldn't be used for at least some of it. But being more familiar with CLI tools, I found it easier to build that site originally in half a day using CLI tools alone. And I did it in text console mode (not xterm) switching to X, or my Win98 box, to test the rendition via a few different browsers. You can peek at the PHP source here. I'm thinking out the plans for the next version of the site now, and it will be more dynamic than the first, allowing you to choose your own boxes, number of stories in each, where to lay them out, and maybe even a display theme.

There is a gray area

[Skapare]

There is a gray area where the benefit of one over the other is not as pronounced as what you happen to have more experience with. If you are equally experienced with both, you'd probably see the gray area as extremely thin. If you are more (or exclusively) experienced with one or the other, you'll probably see the gray area as an extreme case.

One factor, but not the only factor (have to weigh these things carefully, but don't dwell away the day worrying about it) in chosing the tools is to choose what you know best, especially if time is a constraint. But do try to find some time to learn something new occaisionally, or else you'll find your world is made of nails just because you're leet with hammers.

Where do you draw the line?

[Tord]

I think the whole question sounds a bit silly, because where do you draw the line between commandline tools and GUI tools?

If I use Glade for designing user interfaces and gEdit as my code editor and compile the program by writing "make" in a console. Am I using commandline or GUI development tools?

What if I use a texteditor with some project management abilities (for example listing of files in a leftside pane) and that automatically runs make when I press a certain button combination and pipes the make output into a window. Is that GUI or commandline based development?

What if we agree that the above mentioned example is GUI based and I simply replace the editor with emacs running from a console? Am I then suddenly running a commandline based environment just because I changed the editor?

As allready stated in other comments, most GUI-based development environments are only wrappers for commandline tools. Both MSVC and KDevelop (to an even greater extent) works that way. Personally I think that KDevelop's solution is great. I can write my project in KDevelop and send it off, with project files and everything, to somebody who only uses make and vi from a commandline and he can still edit the code and compile without a problem.

I guess my point is that commandline based and GUI based development isn't so different. When you get into designing and implementing complex systems (either in group or alone) you will have good use of some tools for helping you with project layout and management that for example automatically keeps your makefiles up-to-date when you add or remove includes and a multi-source editor that easily lets you jump between function call, the functions definition and documentation. Nearly all GUI environments have that built in, but you can also achieve it in a commandline based environment through a smorgasbord of small and specialised utilities.

That said, I still think that too many programmers just goes on working in the environment and with the tools they settled on like 5 years ago without taking any look at the new modern (and mostly GUI based) tools and environments that might be very useful and speed up and simplify their work once they have managed the transition. Personally I think that both KDevelop and MSVC are great integrated development environments and they have turned me into a much more efficient programmer.

Re:What is a "command line tool?"

[Skapare]

When you find a bug in your program, your best command line tool is the "rm" command. :-)

Will IBM Visual Age work with ... gcj?

[Skapare]

Will IBM Visual Age work with development of Java code to be compiled with gcj or some other direct (not class file) compiler? Or is it dependent on the JVM and class files? And will the resultant source package compile on most major UNIX platforms (I'm into distributing the source code and getting tight compiles, not messing around with the JVM environment)?

No wonder so many web sites suck

[Skapare]

Gee, and I thought much of the blame was on so many artists coming from the world of print media (e.g. paper brochure layout) to the web (e.g. electronic brochure layout) and not having a clue about basic concepts of adaptable layout (not dynamic, necessarily, just the ability to adapt to different window sizes, different fonts, different widgets, etc). But it has become clear that much of the blame, if not most, is on the part of the programmers (and more likely their managers) for producing crap that doesn't even have the capability to do the right thing.

I've found many a GUI app that had really good graphical layout, sometimes awesomely cool stuff, and did shit when it came to what the coded logic was. But then again, you shouldn't expect protein and vitamins in candy.

Tell me how well linuxhomepage.com does on your web browser in your preferred window size (as long as it's not itsy bitsy) on your desktop with your fonts and widgets.

Depends on application...

[Karellen]

If you're writing a GUI, IMO you _need_ a graphical dev tool. You can't create graphical art on the command line. It just doesn't work. So, yes, for writing GUIs, GUI dev tools are a hell of a lot more advanced an neccessary.

But for writing back-end code, I don't think is makes a bit of difference. I'm just as productive with a bunch of rxvts running vim and `gdb -nw` as I am with anything like MS Dev Studio or Borland C++ builder, or anything like that.

The fact that command line tools are `small tools that do one thing and do it well' allow you much more control over what you're trying to do that these large behemoths that try and anticipate your needs and do loads of stuff for you that you don't want to get involved with.

Development type

[Adam Wiggins]

It depends heavily upon the type of development you're doing. Quite simply: if you're creating an end-user application such as a word processor or a game, an IDE like KDevelop is definitely the way to go. The app itself is highly visual, so creating it with visual tools makes sense. More importantly, with most apps, there's just a single program that you're writing and debugging, which the IDE can handle quite neatly.

Server tasks, on the other hand, are an entirely different story. Here you have something that is probably not terribly visual; most of the code runs in a place that the user will never see or have access to. You've got many little helper scripts, processes, client/server applications, processes communicating across many different machines, processes running automatically in the middle of the night - managing all of this with an IDE is probably impossible.

I do both types of programming at my place of employment. The core of our business is a payment gateway, which is hugely complex, and involves dozens of servers spread out across the United States communicating with each other, as well as internally, with a hundred and one small programs passing data off to one another. We do all our work on this part of our business with ssh, bash, vi, Perl, SQL, and occasionally some C.

On the other hand, I've worked on a few end-user applications (point of sale apps, install programs, reporting frontends) and KDevelop is great for them. Designing your widget layout in QDesigner is a breeze, and then integrating that back into your C++ code in KDevelop is drop-down simple. The embedded debugger is wonderful, as well.

Moral of the story: Choose the best tool for the job.

Emacs users know the answer

[Per Abrahamsen]

Emacs can be invoked as both a GUI and CLI[1] tool, and certainly qualifies as an IDE, even if it is not for everyone.

The answer is pretty simple. Emacs in GUI mode can do everything Emacs in CLI mode, and often has several ways to do stuff that are missing in CLI mode. These alternative ways are sometimes useful, and when not, one just use the CLI way that is still available. So a GUI is preferable to a CLI, given the same basic featureset.

It is as simple as that. The reason some people can make an issue of it, is that they are comparing radically different environments, with radically different features. With Emacs, one can isolate the CLI/GUI factor.

BTW: Some people (often people who haven't used a recent or properly configured Emacs) claim Emacs isn't a "real" GUI tool. Objectively, they are wrong, it uses the native window system and has (at least in some versions) all the features traditionally expected from a GUI tool. However, these relatively new GUI features aren't always fully utilized by the various Emacs subsystems. The advantages of GUI Emacs is only going to grow as these subsystems utilize the new fascilities.

[1] Provided we allow full screen tools like vi, and doesn't restrict CLI to pure line oriented tools like ed.

Stallman wrote about this.

[crucini]

I work with Visual C++ 5 days a week, and there are real limitations in its scripting.

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.

Reduction to Equivalent

[4of12]

The GUI vs command line argument has raged on all fronts for years. And the gist of those arguments, including personal feelings, are telling. The proper choice depends on the user context.

In essence, I'd say the GUI vs command line debate reduces to an internal evaluation of just how important are the tradeoffs between:

• control
• convenience

where by "control" I'm referring to the command line flexibility that allows you to twiddle a Makefile so that one particular source file gets compiled with a special set of DEFINES and INCLUDE directory path specifications and compiler optimization levels. And that's without having to learn some IDE's Preference sub-sub-sub menu navigation in order to accomplish the task.

Convenience is chosen when I'm willing to suffer some loss of control for the sake of rolling faster through a typical development cycle of automatically popping up to the next error, etc. An IDE is great for this kind of work (even IDE's in disguise like emacs with compile, grep and gdb modes.)

Another poster had the right idea suggesting that command line and GUI should be interconvertible. Ideally, the IDEs should be able to let you wander out of the loop as you wish without having to climb and IDE-specific learning curve to do so.

Interconvertability is especially important because software development projects move through different phases, where either approach may be appropriate to the task at hand and the user that is doing the task. (Eg, setting up automated regression tests, etc.)

Re:winbatch

[Skapare]

Simply recording what I do in one GUI session won't really describe how I might want those actions to vary on the basis of varying conditions, either inside or outside the application, or even between multiple applications if the script is driving 2 or more (for example to extract data from one and put it into another in some special way that simple cut and paste won't accomplish).

If the COM interface from a script to an application is truly complete and flexible, then it should be possible for the "script" (probably better done in C/C++/Java for this) to run an application on one machine, and present a GUI on another, and "replicate" the application that way, or even make it available to another script there via the same COM interface rules. If COM integrates network access, then it could already do this. Apparently the way Windows makes everything be a DLL has some power (but also security risks) to it.

I have advocated separating user interface presentation from programming logic, as have many others. Unlike COM, my advocacy is to connect the separation via a protocol rather than a mere API (but there should be a standard API, too). Properly done, one program on the client end would be all you'd need for all applications, where the app logic runs on a separate server, in much the same way as one browser is all you need for quite a number of documents (but HTTP and HTML don't really do it well beyond documents).

I'd also like to know how you got your posting to be on Wednesday December 31, @06:00. Maybe a billennium bug at /. ?