Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming IT Technology

Are GUI Dev Tools More Advanced than CLI Counterparts? 501

JohnG inputs: "I just got into quite a long argument over on the Yahoo! message boards over the power of command line dev tools. Basically the guy told me that it is impossible to create 'state of the art' programs with command-line tools. But when I asked him to give me reasons why he just called me stupid and 'behind the times'. Considering he was an avid supporter of anything Microsoft, I take what he says with a grain of salt. But what I want to know is how many of you developers have switched from command line work to KDevelop or CodeWarrior? And what advantages you think it offers? Certainly there are many 'state of the art' apps created with command line tools, but I'm open to anything that can increase productivity. I've just never seen a compelling reason to make the switch from what I am used to and comfortable with." Personally, I feel the best development environment to work in would be one that ignores neither the GUI, or the command line.
This discussion has been archived. No new comments can be posted.

Sophistication and Command Line Devlopment Tools?

Comments Filter:
  • Neither (Score:3, Insightful)

    by Biff Grande ( 267473 ) on Saturday September 08, 2001 @12:13PM (#2267566)
    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.
  • For any kind of programming in the languages I'm familiar with (PHP, PERL, C++), I prefer a good old fashinioned text editor. I do find using tools like dreamweaver and such helpful in HTML, but I would go nuts if I had to rely on them totally. I say if you can't use either GUI or CLI, you've got problems - jst the same as if you can only write one language or for one OS.
  • I get the most out of XEmacs, which is an almot-GUI tool that drives CL utilities. I use it for everything, from C++ to Perl to Javascript to HTML.

    Probably the best is to stick to what you know most. DDD is probably much better that gdb embedded in XEmacs, but, well...

  • GUI cvs Command (Score:5, Insightful)

    by OmegaDan ( 101255 ) on Saturday September 08, 2001 @12:19PM (#2267596) Homepage
    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 (Score:3, Insightful)

      by keesh ( 202812 )
      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 [borland.com] but not quite Free).
    • Re:GUI cvs Command (Score:3, Interesting)

      by sahala ( 105682 )
      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.

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

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

      • 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.
    • 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 [mixdown.org] 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.

  • by joshtimmons ( 241649 ) on Saturday September 08, 2001 @12:26PM (#2267643) Homepage
    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.
    • by dachshund ( 300733 ) on Saturday September 08, 2001 @01:01PM (#2267851)
      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.

  • 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?
    • 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.
    • Borland's free C++ compiler which is here [borland.com]. All the MS includes, Borland's VCL stuff... Very powerful commandline.
    • No-one seems to have mentioned Comeau C++ [comeaucomputing.com] 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.

  • by quakeaddict ( 94195 ) on Saturday September 08, 2001 @12:29PM (#2267658)
    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.

  • by samael ( 12612 ) <Andrew@Ducker.org.uk> on Saturday September 08, 2001 @12:33PM (#2267681) Homepage
    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.
    • 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 Tools (Score:2, Insightful)

    by EarTrumpet ( 85772 )
    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.

  • by Xpilot ( 117961 ) on Saturday September 08, 2001 @12:37PM (#2267706) Homepage
    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.

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

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

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

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


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

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

  • 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.
  • by MongooseCN ( 139203 ) on Saturday September 08, 2001 @12:37PM (#2267713) Homepage
    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. =)
    • 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.
    • 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.
    • 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.

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

  • by Shoeboy ( 16224 ) on Saturday September 08, 2001 @12:42PM (#2267746) Homepage
    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.
  • by ben_tarval ( 512334 ) on Saturday September 08, 2001 @12:44PM (#2267759)
    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.
    • 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 :(

    • 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.
  • by proxima ( 165692 ) on Saturday September 08, 2001 @12:48PM (#2267775)
    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.

    • >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.
  • by trentfoley ( 226635 ) on Saturday September 08, 2001 @12:50PM (#2267786) Homepage Journal
    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.
  • by cygnus93 ( 147851 )
    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.
  • 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? (Score:2, Offtopic)

    by anshil ( 302405 )
    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.

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

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

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

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

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

  • by RGreene ( 12105 ) on Saturday September 08, 2001 @02:46PM (#2268350) Homepage

    We've been using Visual Age for Java (VAJ) at work for nearly two years now -- and it's really awesome. I hate to say it, but I'd prefer to stay within Visual Age instead of the command line. I was/still am a command-line jockey, obviously in Unix, but also in Windows.

    From my quick skimming of the responses, people miss an important point: most tools (visual or otherwise) seem to require a compile to identify and fix errors - just general typos. VAJ not only does incremental compile of whatever method you are working on, but it also keeps all classes in synch. Huh? As I code, I'll code a method I know won't be correct. It'll show a funky red 'X' next to the method. As the methods and attributes get finished off, the 'X's go away. Not too much of a big deal, since that is within one .java file. However, that is working across all classes that are loaded in the workspace. Realtime. As you type it. Wanna rename a class? Not a big deal - I save, look at the errors tab, and I can edit right there, change the name. Actually, the tool will do the rename also. But, anytime a class is restructured (renamed, moved, split, combined, removed, etc) you just pop to the errors pane and fix. Not a big deal. You know the impact immediately.

    Every piece of code is versioned. Down to the method - really cool if you've messed up a method and need retrieve a prior edition. You can compare different classes, different editions of the same class or method. Locate all references of a method or of a class or all implementations of an interface.

    This tool was originally developed for Smalltalk, so it's geared for those of us doing OO. But, it's extremely useful. There are versions for C++, Java, Smalltalk, ... even RPG (ug). Unfortunately, the only trial edition available is for Java -- I use it at home I love the tool so much. It's also available for Linux, but unfortunately, that version is behind the Windows tool. The Entry edition (aka trial edition) is not time-bombed or anything - just limited to 750 classes that you add. That's quite a few, to be honest. And, as projects complete, I think you can just drop them off of the workspace and that resets the 750... although the basic edition costs less than $200.

    Oh yeah, I'm not doing GUI development. Web development - a lot of it is framework (persistence, control, etc). Other developers are building messaging components (MQSeries). Just as an FYI that I'm not doing GUI drag and drop development. Not at all!

    For those of you doing Java - bounce to IBM's site and try it [ibm.com]! Give yourself some time to adjust... the big difference is that all code is housed in the repository. It doesn't sit in the filesystem. This is not a bad thing -- it enables all the cool features that make VAJ unique. You can export or import Java code - JAR or file system - when you need the Java source. You can connect to many types of version control software if you want or need to (I use CS-RCS).

    The next version of VAJ will be called WebSphere Studio Application Developer. This will work from the filesystem - this will probably be good for the general acceptance of the tool (IBM kept getting clobbered in reviews because of the repository). However, I have a slight fear that this may end up removing a lot of the features that make Visual Age for Java such a strong development tool.

    IIRC, Visual Age for Java won the Jolt award in 2000 and WebSphere Studio won it in 2001.

  • 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 (Score:2, Insightful)

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

  • by Mindbridge ( 70295 ) on Saturday September 08, 2001 @04:49PM (#2268748) Homepage
    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 [rational.com] 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 [togethersoft.com], 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 [javaworld.com]).

    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.

  • 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.
  • How do you think Torvalds created the linux kernel [linux.org]?

    What is used/needed to develop on apache [apache.org]?

    How did CmdrTaco make Slash [slashdot.org]?

    What development tools do you need for mozilla [mozilla.org]

    Impossible without GUI? Yeah, right. End of discussion.

  • 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.
  • 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.
    • 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 aginst CLI (Score:2, Insightful)

    by fidros ( 8566 )

    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.
  • by ewestra ( 304643 ) on Saturday September 08, 2001 @05:42PM (#2268922)
    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.

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

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

    - 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.
  • 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 (Score:2, Informative)

    by snillocneb ( 520117 )
    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.
  • by Junks Jerzey ( 54586 ) on Saturday September 08, 2001 @08:49PM (#2269407)
    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.
  • by xant ( 99438 ) on Saturday September 08, 2001 @09:12PM (#2269470) Homepage
    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.

All science is either physics or stamp collecting. -- Ernest Rutherford