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.
Neither (Score:3, Insightful)
Re:Neither (Score:2)
D
I believe you're correct. (Score:2, Interesting)
GUI-CLI? Where's Emacs? (Score:2, Interesting)
I get the most out of XEmacs, which is an almot-GUI tool that drives CL utilities. I use it for everything, from C++ to Perl to Javascript to HTML.
Probably the best is to stick to what you know most. DDD is probably much better that gdb embedded in XEmacs, but, well...
GUI cvs Command (Score:5, Insightful)
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)
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)
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.
GUI cvs Command. Why not have both? (Score:3, Informative)
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.
Re:GUI cvs Command (Score:2)
Windows' answer to Crond is the Scheduled Tasks folder. It's not Microsoft's fault that nobody uses it.
In order to effectively launch an app from a scheduler, it must have a way to accept options from the scheduler. Thus, it will end up parsing a command line. I suppose an expect like framework for queueing windows events could help there, but I haven't seen such a thing.
Re:GUI cvs Command (Score:2)
I don't see why you'd want to hobble yourself by doing things 100% GUI (Visual Basic) or 100% CLI (gcc and gdb and nothing else).
Stallman wrote about this. (Score:3, Interesting)
Interesting. Stallman wrote an essay describing the design logic of Emacs. One thing he pointed out is that a scripting language tacked onto the side of an application as a 'feature' will always suck. It won't be a very high priority for the application's creators and maintainers.
The proper approach is to write the upper layers of the application in the scripting language. So Visual C++ should be made with the compiler, linker, metadata-store etc. in C/C++ and the control/GUI in VB. Or something.
The obvious side effect is that Microsoft's programmers would have felt the pain of an inadequate scripting interface/language and enhanced it.
hrmph. (Score:2)
Perhaps I've just been using text editors and command line compilers for too long to successfully make the switch, but I always find that GUI tools are great for simple, brain-dead stuff but the second you want to do anything the least bit interesting the tool fights you every step of the way.
I refuse to stop doing interesting things in my programs, so until these tools stop fighting me I won't use them. I think the Microsoft crowd is (in general) a lot happier to say "Ooh, the tool doesn't want me to do that. Oh well" than I am.
I hold out hope, since the idea of being able to drag-and-drop my way to a user interface is pretty compelling, but I've never found the reality of the situation to be even remotely close.
Re:hrmph. (Score:2)
But maybe the question isn't about IDEs, but about purely graphical development environments. If that's so, then the editor's comment is out of line -- because KDevelop and Codewarrior both involve typing; a great deal of typing. The only completely graphical development environment I've seen is a weird language for the Mac, called prograph, and even that is more like flowcharting than drawing.
Re:hrmph. (Score:2)
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'd say it depends on how people think. (Score:2)
Now I write C code that spits out HTML tables, and the alignment is perfect every time. If there's a problem, it's usually easy to fix - usually as simple as forgetting "<td valign = top>".
And if I'm asked to, say, change the background colour of the page, or switch a whole bunch of elements from the left side of the screen to the right, I can do it, easily.
The only development tools I need are emacs, gcc, and a dose or two of common sense. Not bad, not bad at all.
If you think text, as I do, you are way better off writing programs that spit out text, instead of programs that manually position every pixel on the screen. In my experience, I'm far more productive and create much more attractive applications by spitting out HTML and letting the web browser worry about the pixel by pixel stuff you do with a GUI.
But if you think visually, as I think most people do, the GUI's probably going to work better. It's certainly mind-numbingly difficult to translate a bunch of numbers into a page prototype in my head. But, perhaps, not yours - and that's why we all need different tools.
D
Re:I'd say it depends on how people think. (Score:2)
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.
Re:hrmph. (Score:2)
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.
The IDE's just wrap command line tools still (Score:3, Interesting)
One of the reasons the claim confuses me, though, is that tools like KDevelop and, even MSVC, do still run a command line compiler. All that they do is manage the "makefile" or whatever underlying build engine the IDE is using. So, it follows that anything built on such a system can be built with both command line tools and from the IDE. This is true of all the java, C, and C++ IDE's that I have used.
There are some places where IDE's have enhanced my productivity, but they tend to be editor related and aren't really applicable to the command-line tool vs GUI. They are:
1. Automatic completion of symbol names and displaying parameter lists for functions as I write code to call them.
2. It's been several years since I have hand-coded a static form or dialog box. For this activity, I find a form builder quite handy. (Dynamically built forms are another matter).
But, as I said, these features don't require a GUI development environment. Just because I don't have a C++ editor under unix that does these things doesn't mean that command line tools aren't capable of producing serious apps.
Anyway, I ramble. The bottom line is that the tools you mentioned are all wrappers around those command line tools that supposedly can't do the job. The project management is nice, but a well-designed makefile is just as quick to work with.
Re:The IDE's just wrap command line tools still (Score:5, Insightful)
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.
Know any good Win32 CLI C++ compilers? (Score:2)
Re:Know any good Win32 CLI C++ compilers? (Score:2, Informative)
Win32 ported gcc that has all the win32 headers and compiles win32 native binaries that don't require additional DLLs to run anywhere (like Cygwin).
Also makes it easy to compile linux/unix sources on win32 with ususally slight modifications (esp. socket code) but not as easy as Cygwin is for porting.
Re:Know any good Win32 CLI C++ compilers? (Score:2)
Re:Know any good Win32 CLI C++ compilers? (Score:2)
Re:Know any good Win32 CLI C++ compilers? (Score:3, Informative)
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.
Re:Know any good Win32 CLI C++ compilers? (Score:2)
I do use nmake and cl already. I clearly stated I wanted to get away from the MS toolkit. I appreciate that at least you did make a useful comment in addition to the insult. I also explained why I don't like the Borland compiler. I didn't know that the Intel compiler didn't come with headers.
Re:Know any good Win32 CLI C++ compilers? (Score:2)
Well, if I hated MS, I wouldn't be working in Win32 would I? :)
I was trying to keep the original question short, and didn't explain all my reasons. Here are some of them:
This isn't some anti-MS rant I'm on. I happen to like Windows NT and 2000 as end-user OSes. I just want a compiler and toolset that works how I like to work, and doesn't weigh me down with stuff I don't need or want.
Re:Know any good Win32 CLI C++ compilers? (Score:2)
Re:Know any good Win32 CLI C++ compilers? (Score:2)
It's bigger than necessary. I detest large distributions. My goal is precise functionality, neatly-done code, tiny executable. For a particular program I've done that I use as a test project (with a basic GUI and performs some network functions), I've got the distributable size down to 18K in x86 ASM, 22K in PB/DLL, 24K with LCC, 28K with VC++, and WHAM! 132K with borland's free C++ compiler (which, as best as I can tell after searching for hours and hours for an explanation, force links the runtime whether or not you explicitely call runtime functions because they embedded the entries in the runtime). It's a personal goal in my software that they never use external files (with very rare exceptions), and use as little disk space and memory as possible. I do balance that with development time, though, and I'm not fast enough working in ASM to do everything that way. Of course, all these beat the hell out of the equivalent VB project at 1.5M.
It Depends on the Team (Score:3, Insightful)
At some point someone is in charge of the builds, and whatever that person likes we all get. If that person does their job right its easy regardless of what your preference is.
One thing is for certain, it doesn't make sense anymore to build GUI's without the help of a drawing tool that automates that tediousness.
Depends on what you want them for (Score:5, Insightful)
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.
All that's pretty easily done textually... (Score:2, Insightful)
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)
I've banned IDEs for now...perhaps if my developers use a text editor to code they may actually learn something.
The much-maligned command line (Score:3, Insightful)
I've been using a CLI to program and generally do OS stuff for years and years, and I've found some Windows-lovers attitudes more than just a bit annoying.
"Command line??? How primitive! Look at all the colorful and pretty pictures I have on my desktop, you dirty UNIX user!"
I hear comments like that a lot. From CS undergrads too. What brought about this attitude? I put the blame squarely on MS. Even Apple has a decent CLI shell now with OS X. MS is so busy harping its wonderful pointy clicky interface and the clueless world follows suit.UNIX will always exist, but Windows runs the IT world. At least where I live.
Re:The much-maligned command line (Score:2)
IMHO, DOS sucks at least in part because of its horrible command line interface. When I discovered UNIX shells, I was astounded at how much easier it was to Get Things Done on the commandline.
Re:The much-maligned command line (Score:3, Interesting)
Actually, just check out the properties of a pretty Windows icon, or even an ugly one, and you'll find a command line right there. CMD.EXE isn't going away any time soon.
D
Re:The much-maligned command line (Score:2)
D
Re:The much-maligned command line (Score:2)
Show me one single usenet or mail list archive post with this sentiment from someone who shouldn't have been canned as a troll anyway. In other words, show me an example of this sentiment used as serious argument. Whereas I see attacks like "point and drool" taken as serious argument every day. As usual, those that can do, do, those that can't argue about it on slashdot (I guess I just indicted myself)
Re:The much-maligned command line (Score:2)
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.
Pointy and Clicky is good (Score:2)
Re:The much-maligned command line (Score:3, Interesting)
I disagree here. A significant amount of DOS's suckage comes from its primative command line interface. "Back in the day" most people didn't care about multitasking, but the annoying C:\> prompt was dreaded by most users.
Consider:
Given those issues, and the fact that most PC users at the time were running MS-DOS and forced to endure the torment I have described, is it any wonder that CLIs are considered "primative" by the majority of the population?
Add to this the Mac. Most offices were PC based due to compatability requirements and investments in PC software, but many people could stop by schools or computer shops and have brief experiences with Macintoshes and be wowed by the pretty GUI and how easy it was to use compared to DOS. Those who couldn't, could hear stories from those who could. Is it any wonder the majority of the population considers GUIs to be the best way to interact with a computer?
So it is my theory that the 100% GUI / 0% CLI attitude, rather than a more balanced "right tool for the job" approach, is the consequence of historical Mac envy.
But it's just a theory.
Revision Control (Score:2, Insightful)
Assuming you are doing some form of Revision Control (which you should be ;) ), I find it most important to have the revision control system built into the editor I'm using. I also want a difference engine built into the editor that works with the revision control system. Emacs and Xemacs has these features among other full IDEs. It is useful to look at the differences between your current code and code that has been checked in, in a graphical manner so that the differences are within context. Command line diffs remove the context
It's also nice to have color highlighting of code and smart indention. This can help you know if you spelled things, forgot a ";". A nice feature that some IDE's have which I haven't seen implemented in emacs yet (which I'm sure is possible), is the ability to know the current valid function names and variables and highlight them appropriately.
Irrelevant. (Score:2)
A few weeks later, I decided to learn Python and figured to port this app to Python and PyGNOME as my own sort of final exam; i.e., did I now understand Python well enough to write real apps? Using no tool more sophisticated than xemacs, I had the app running in Python/PyGNOME in under three days.
Part of this is undoubtedly due to the fact that I'd already hammered out the program logic by writing it in C the first time. Part of it is due to the fact Python is a more appropriate tool for GUI construction.
But in the end, a shift in programming language (C to Python) made a tremendous difference in development time and brain-pain. The ``downshift'' from an IDE to a traditional editor made pretty much no difference at all.
The question ``[a]re GUI dev tools more advanced than CLI counterparts?'' is, in some ways, a foolish one. The most advanced tool any hacker has is what's between his ears, and the experience he's accumulated over his years.
Re:Irrelevant. (Score:2)
What's wrong with using the programming language which is best for the job, which he seems to have found is Python? Does it threaten your existence as a great l33t C programmer (Look at me, I use -Wall, I'm BETTER THAN ALL OF YOU) that Python might have an advantage over C?
Re:Irrelevant. (Score:2)
Close; it creates bugs. Dynamic memory management is much more reliable when it's left to automated tools; when was the last time you saw LISP or Scheme code dump core on a segmentation fault?
I compile with gcc -Wall. Maybe you should go back to Basic?
Funny. I write code in Ada95, in LISP, in Scheme, in OCaml, in C, in C++, in Python, and in half a dozen other languages too esoteric to mention here.
If you feel that you're a 31337 haX0r because you know C, buddy... think again. There's an entire world of languages out there, and some of them are very, very good.
Free your mind and your code will follow.
There is a glade for python (Score:2)
GUI's are easy to learn, but never efficient. (Score:5, Insightful)
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
Here's a nice cryptic example. What's a fast way to find the include file for a function? Browsing through help files, searching for the command and cutting and pasting the include in? Or this:
:r! man ntohl | grep "\#include"
Ya, I thought so too. =)
Re:GUI's are easy to learn, but never efficient. (Score:3, Insightful)
Re:GUI's are easy to learn, but never efficient. (Score:3, Informative)
CLI's are quite inefficient when you need to do a lot of typing. E.g. if you were moving files to a path that was very long; where you have to perform operations on files that can't be selected through grep b/c there's no common rules that are applicable.
Besides which, in the real world, the time you waste trying to remember some cryptic argument and how to use it IS a factor to be weighed.
CLI's have their uses, as do GUI's. Far better for them to augment each other (e.g. right-clicking on a CLI command to select from a list of argument options with their full names; selecting files spacially with the mouse and renaming them with wildcards) than to persist in maintaining a wall.
As for the comment below re: keyboard shortcuts, testing reveals that they are for the most part slower than using the mouse. People don't consciously realize it, but unless the command is incredibly common and ingrained as only a few are, they pause and try to remember it. It's objective testing has revealed this - not people's subjective senses of time.
Re:GUI's are easy to learn, but never efficient. (Score:2)
Alternatively, for full docs on a library function, how about clicking on the name and hitting F1?
These are all routine things I do several times a day at work in my "inefficient" IDE.
Re:GUI's are easy to learn, but never efficient. (Score:2)
Right-clicking on it in turbo-C++.
Or let's get radical, how about an environment that looks for headers in your include path, then puts them in a suggested list you can then edit, so you don't have to bother with finding the damn header in the first place unless it's ambiguous. Could probably program it in vim if you really want to deny that the 'v' (and the 'i') in vi stand for anything but "visual". Unless you're using a keypunch to enter your code, you're using a GUI of some sort.
Re:GUI's are easy to learn, but never efficient. (Score:2)
Better to understand how your libraries work. Then you'll already know what to include and you'll write a better program too.
Re:GUI's are easy to learn, but never efficient. (Score:2)
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?
GUI's have been scientically proven to be faster (Score:3, Interesting)
GUI is terrible for less skilled programmers (Score:2)
That said, I find that GUI development environments are terrrible for me. To get any work done at all, I need to be staring at the code, and nothing but the code. I don't want to click through little dialog boxes to get to parts of my program, and I don't trust the way VB and Delphi hide my code from me. Without not just the ability, but the neccessity to step through my code line by line the old-fashioned way, I'm just lost.
English to E Translator (Score:5, Funny)
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
Well, I think that clears that up.
--Shoeboy
Bigotry makes for sub-optimal programmers (Score:5, Insightful)
are superiour. If you don't know when each is best used, and how, you are
not up to your full potential as a programmer.
Personally, I believe in keeping an open mind, and using the best tool
for the job. This allows me to do the best job possible.
Now then, ask your bigoted friend if he does anything less. If this doesn't
shut him/her up, then his reply will be most amusing.
Re:Bigotry makes for sub-optimal programmers (Score:2)
How true. I'd like to add the following though. Many people, often with respect to KDE v. Gnome v. plain-old-window-managers or Windows v. Unix talk about how usability is enhanced by common look and feel. Well, for me, an unashamed luddite, Makefiles provide that look and feel. Yes, they work for code, but a good template Makefile for LaTeX gives handy commands for (say) making and previewing in GV, printing, printing reduced to 4x4, converting to a PDF file or HTML and many other useful things.
The same goes for automating validation of SGML or so on. The only trouble is, if I'm ever caught without my Makefiles, I've found I'm completely useless
Re:Bigotry makes for sub-optimal programmers (Score:2)
Different, not more advanced (Score:5, Insightful)
KDevelop and KDE Studio are two examples of this. The "tools" are really the same - they just offer a GUI interface to several command line utilities. I cannot speak for KDE Studio, but I believe KDevelop is working on good cvs support for a complete approach to shared development. To my knowledge some of these features are already implemented. Also, a GUI based IDE will almost ceretainly have good syntax highlighting.
However, one does not need to use a GUI to get colored code - vim and Emacs/XEmacs offer this from the command line.
In my opinion, development can take place faster and debugging more easily with an integrated environment compared to ed+gcc, but this should be rather obvious. This does not make IDE's (both GUI and terminal based ones - IMO Emacs is an IDE once you configure it properly) more advanced - just more convenient.
The nice part about developing with *nix is that you can use a wide variety of tools, even on the same project. Use what you are comfortable with, and ignore those who say your technique is flawed - everybody has their own way of doing things efficiently. With MS Visual C++, you are basically stuck with their IDE and you better like it.
Choice is good, use what you like.
Re:Different, not more advanced (Score:2, Informative)
Huh? Am I the only persson that realizes that MSDev is a GUI interface to the command line tools that it runs? You can still execute cl.exe and link.exe from the command line - after all, thats what MSDev does, and pipes it's output to the Output Window.
Re:Different, not more advanced (Score:2)
I stand corrected.
It's all the same, really (Score:3, Funny)
And, if you believe that, I have several priceless family heirlooms to sell you.
Somewhere in between. (Score:2, Informative)
On the debugging side of things, ddd is a must. This is GNU's graphical front end to gdb, and I honestly believe my testing would be about 10 times harder without it. Being able to graphically display huge chains of data structures (especially in the kernel) is completely invaluable. I can't imagine how much longer it would take me to find all of the subtle bugs that crop up if I was just using gdb on the command line.
On the other hand, though, I still do a lot of my work with command-line scripts that I've written. Stuff like kernel builds and installations on a remote test box, rebuilding and installing my admin tools, setting up test cases, and opening debugging sessions are all done through simple scripts. When I need to run these, I simply tab to an xterm and run them.
So I don't think this situation is completely black and white. I see both methods co-existing quite nicely.
Use the appropriate tool for the job. (Score:2)
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
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)
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
for i in *.d; X $I; done
finished! It might take once here and there an hour to study the advantaged features a real shell might offer, but for people having to work 8 hours each they with a computer they pay easily of in the long run.
It's like a cashier, in his profession an expert. No cashier wants to use a point&click interface, it would take them indefintly to enter a more compilicated invoice. owever a secreaty having to write just one invoice each day, she will not want to spend a weak to learn the real cashiers interface with all it's short cuts, she will like to click on a menu, look what it offers, drag down to a submenu, look again what it offers, select a item, and fill out a popup box. This takes her say 1 minute. Fine since she has to do it only say once a day. However a cashier working on a line having to enter 1000 entries each day this is unacceptable, however he knows his interface designed for the professional very well, he hits in example CTLR+R, A, 15, Enter and is finished, took him 5 seconds.
Same is it for programmers, shell's. makefiles etc. all take their time to learn, and a hobby programmer will prefer a point&click interface. While one working heavily with these tools day, day out, will prefer a makefile far over the project settings dialog, since it allows him to write more powerful commands in shorter times, but in contrast to the dialog it requires knowledge/training to understand the makefile language.
Re:real shells? (Score:2)
The advantage to point-n-click is that the options are most likely laid out for you in the open, thus not requiring the memorization of commands. With a CLI, you have to know exactly what you want do to.
It's exactly that, for doing a task the first time a GUI is definitly faster in hours. For doing a task 8 hours a day, a deticated interface is doing faster. Since the time used to learn it once is compensated in future uses.
Just look at the supermarket, imagine the chasier would have PC keyboard, and even a mourse, I wouldn't want to wait in the queue.
I took the secretary as an example, since normaly secretaries have a huge bantwith of tasks to do, but again normally they learn typing
fast with 10 fingers, a lot of programmers don't work on especially. Okay that's a value dated a little more back into time. Today you value people by their ability to solve tasks themselfs, and having a wide spread spectrum of tasks it is effectivier to have user interface for each one which are more intuativee compared to more effective interface you've to be especially trained.
Again the 'project settings' dialog for MFVC. Somebody looking the very first time at can very quickly understand how to turn on and off diverse compile options, while learing how to use makefiles takes up a weekend.
So please get off your high horse and realize that these are different tools for different purposes.
Didn't I say that? However for people that program day and day out, having to learn an dedicated interface pays off. I agree that implementing GUI software with a GUI possiblity to click components on a form. However in example I disliked in example Kdevelop because last time I looked at it, it didn't allow me to use my makefiles, it inseted to use it's autogenerated ones.
Okay the for loop was a bad one
I will try to take another example 'vi'. Imagine you're used to windows only (as I was). During the first time you use a unix system you'll sooner or later dump against the editor vi. Accidently it will pop open, and you think fuck what's that for a stupid, ugly thing. And how the hell to I get it away? Well after reading some minutes a man page you discover that
However yes, as a programmer I edit plain text files all day long, hour for hour. I agree that somebody having only to edit one config file once in a weak, having to learn vi block command is over kill.
Just like I want a GUI to be able to add some numbers, I don't want to learn the interface a cashier has to use and will prefer. I don't care if it takes me 20 seconds or 3 minutes, I do it only once in a month.
That's my opinion for CLI vs. GUI
-
And please if you don't agree with click reply, don't moderate me 'OffTopic' that's definitly false since this is on the topic the thread was started.
GUI dev tools are necessary (Score:2, Interesting)
I can run the program and step through the source code in another window.
The editor highlights my code in color, and I can expand or contract each class definition.
In a project window, I can see all the files available and check them in or out of source code control.
When I move my mouse over a function call, I get a popup with the list of arguments.
I can standardize my comments and have the development tool create new classes for me with my comment scheme already in place.
If I forget a constant's name, I can call up a separate window where I can browse or search through constants defined in many modules.
Make scripts are generated for me automatically.
But probably the best part is that I don't have to give up any of my command line tools in order to get these benefits. If I want to run it from the command line, or do a make from a batch script, that option is still there.
I want to stress that not all of these advantages are Visual Studio or Codewarrior related - some of them come from the revered Turbo Pascal. None of these development environments require you to give up the command line.
Re:GUI dev tools are necessary (Score:3, Interesting)
I do that with command line tools all the time. One xterm for vi, and another for gdb. I admit it is nicer to use a GUI tool to set breakpoints by clicking on lines of code, and to have a whole window of variables with current values (which GUI IDEs like Visual Studio do), on the other hand gdb hasn't ever harf'ed on my code and taken out my editor killing some unsaved changes. Visual Studio has, so has Code Warrior, and two different Symentic Java dev tools.
Oh, wait I see what you mean. You can do that as well, with gdb's attach PID. I tend not to bother, except when debugging a daemon. Normally having my debug session in the same output stream doesn't matter. Partly because I'm either debugging a server type process, or a GUI program. If I were debugging a curses type program it would be more of an issue and I would use attach (or a GUI)
EMACS, and some vi clones (vim) can do the color thing (I find it distracting and useless for code, I do use it for HTML editing though). I think EMACS can do the class collapse and expand thing. That would be kinda nice, but not enough to make me leave vi.
I'm unconvinced that that is really better then using ls directly, but whatever floats your boat.
That is useful. I have to use ^] to get vi to search for the tag, or use another xterm to bring up a man page. It would be nice to have them unified. It would also be nice if vi could figure out what class x is so it can go to the right place when I do a tag search from x.foo()...
Is that really simpler then typing :r ~/t/class to read in a class template? You could shorten that to a keystroke if you use :map...
Did something prevent you from opening anew xterm window to search from things in a CLI?
That is nice, unfortunately it is frequently also a curse. I had a yacc-like program for Java that made java source, but the Java IDEs I used had no way for me to ask for it to be run on the .cup files. The vender had no idea why I would want such a thing, and after much tech support time finally bounced me to someone who did, but told me that it wasn't possible. For C++ I have a similar tool I use to generate lex files (it has simpler rules for generating "trivial" tokens)
You do seem to give up the ability to make meta languages and have the make file apply them for you. That is a very powerful programming paradigm to be cut off from. I don't see why the IDEs have to cut you off from it, but the ones I have looked at either do, or have no obvious way to do it. If you know of any that do, please let me know. Or even good work arounds...
You did leave out the GUI bit that I do find very helpful, and have found no CLI equivalent. Layouts of GUI panels and dialogs. It is far easier to do that in a GUI environment then a CLI one. I know, I have done it both ways. The Apple Builder (based off NeXTs) is extremely nice, but even less capable ones like the Symantic Java Studio, or MegaMax's Atari ST GUI are very very helpful. Doing hand layout of widgets sucks. Even if it is a tad bit simpler to make sure resizes don't suck as much, the rest of the ease of using a GUI layout tool far offsets that one bit where GUI tools are a bit weak. GUI layout tools also get harder to use effectively as you get more and more custom widgets (the Java layout tool could let you make live custom widgets, but then bugs in your widget code can bring down the layout tool...and the rest of the IDE! Which sucks, esp. since exception handling should have let them limit that problem...)
Depending on what you are doing GUI dev tools can be more powerful, or less powerful then CLI ones.
Re:GUI dev tools are necessary (Score:2)
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
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.
VISUAL STUDIO SUCKS... (Score:2, Interesting)
First off, there are two things I like about Visual Studio, which tends to typify IDEs, and those are the dialog editor and the debugger. The rest of the bells and whistles really don't give me much. But I see this sentiment echoed earlier - most people like some kind of GUI tool for developing the actual GUI interface, and a debugger with lots of information at once capabilities. These things are not unique to Visual Studio, but here's one thing that is:
Project Files.
I've overheard that internally, the boys at M$ regard Visual Studio as more of a toy. Supposedly, instead they use a modified version of nmake. (Hopefully one that doesn't just inline files... man that's annoying.) I completely agree with this sentiment. While Visual Studio can import nmake files yet, nmake is about the only other option you have. And what's the other option?
Project Files.
If you have to generate any kind of sizable project, the Project File setup is about as irritating as it gets. For large projects, you want to specify 99% of the build rules necessary in one place, then when you want to create a new library, just specify what kind of target it is and let your build system fly. Project Files instead center most of their rules around the leaft projects. This just causes integration headaches like you wouldn't believe unless your developer staff is really disciplined.
Not to mention, you're also choosing a build solution that is 100% not compatable with any other platform solution. NMake even doesn't port very sensibly to a GNUmake setup, mostly because it's really old version of GNUmake.
Now, admittedly, you can reset the custom commands in Visual Studio, but then, it becomes a hassle if you want to provide more than just two targets (typically all, and clean). For instance, we like to remove the MIDL step from the generic sequence, so we now have an includes target on top of all and clean. All of a sudden, the folks at my job who are still using visual studio have to find a new button to map.
On the other hand, most IDEs aren't as relagated like VS to a crappy build environment. Most can be edited, but personally, I'd still like to be able run a command line like XEmacs from the IDE. This is because we tend to create more targets (like test) and add components that aren't necessarily written in a compiled language. Make is just a handy tool for automating pretty much anything. I have yet to have an IDE that was extensible like this, and personally, this saves me way more time than having to use the integrated debugger or dialog editor. (WinDBG, anyone? And it's still fairly easy to whip out a dialog when necessary - and c'mon what percentage of your time is used writing dialogs?)
So, in the end, I think that VS, which I would be willing to bet is the main IDE in use out there, does not save time at all in a large project. I've even heard that projects using VS don't even run baselines (which is probably because they're using VSS which doesn't allow you to retrieve whole projects set to a tag... what was M$ thinking?...) On my personal experience, projects that don't run baselines hit massive integration problems. Thus, I'm at the point of banning VS inside my company.
On the other hand, if the IDE was designed to thinly wrap a make system, essentially being a powerful editor like Emacs with a integrated debugger, command shell, and dialog editor, I'd probably use it. But I have yet to find this tool.
... whew, that was one kind of rant...
If you're implementing a lot of GUI... (Score:2)
I can't believe that the computer industry has been so slow in copying it.
depends what you are doing (Score:2)
If you are doing GUI develoipment like a user interface, then maybe this is true. If you are using something like PowerBuilder, Symantic Visual Crape oh I mean Cafe, Visual C++ or Visual Basic or something like that. Few GUI tools output optimized readable code. When the GUI screwes up it can be a real pain to debug. Trust me I have been there done that.
CLI can be effective for somethings as well especially in the case where the server is remote and you are using telnet or ssh to get to the server. There are editors that will open telnet/ftp for you and allow you to edit remotely.
Personally I like to use a program that does syntax higlightening with code completion. Outside of that the GUI's are pretty crappy IMHO. This to me gives me a somewhat happy medium. I get readable code with code completion and can limit the bloat. I can use the GUI help (many tools seem to lack that) to tell me the syntax of commands I don't know, which is very useful.
A Case for GUI Interfaces (Score:2, Insightful)
It all depends... (Score:2)
If you are designing a GUI interface, then a GUI tool will save you untold amounts of grief.
In other cases, it doesn't seem to matter. A well designed IDE will make it easy to get help on various features, and may be language, and even, to and extent, library aware. And certainly syntax highlighting is a real bonus.
On my current project (development on Win95):
Language: SmallEiffel
I am using the tools:
GWD Editor: This is where I do the coding
SEED IDE: This knows about what classes are available, what their features are, etc.
SmallEiffel: This is the compiler
CygWin: This is the execution environment. (Because it allows me to re-direct standard error to a text file, for picking up with GWD Editor)
But I'm not doing GUI design. If I were I'd be using Object-Tools VisualEiffel or ISE Eiffel. ISE would drive the cost up by about $1,000, but would probably be easier to use. Visual Eiffel would entail figuring out how to use their dialog builder. None of these would be portable. Portable would require using Glade on Linux, and figuring out how to make the code work on Windows.
It's often all about code generation (Score:2)
GUI tools simplify debugging and GUI building (Score:2, Informative)
I also like having an editor that respects my breakpoints and adjusts them when I move code around. I learned how to program in assembly language and it seems natural to me to inspect registers/variables and change code while it is running.
Color syntax highlighting, dialogs to set compiler options, integrated icon editing, these features I don't *need* but I don't mind a pretty environment as long as it is designed as a view into the command line tools rather than a replacement.
Different strengths (Score:2)
This is a very odd discussion. Some people seem to be thinking of their favourite IDE compiler vs. their favourite CLI compiler, for example.
I think the merits of the IDE vs. the command line are actually quite simple. A good IDE will provide useful tools to help find your way around your code. This may not be necessary for a typical /. hacker, but it's essential to working on large-scale projects in a team of more than one. For example, IMHO Microsoft's Visual C++ shines in this area. It provides quick and easy-to-use tools to jump around a long file, or between files in a project; I can find definitions of things, references to things, or a list of base classes or derived classes for the class I'm working on with a couple of mouse clicks. I also find things like syntax highlighting to be useful. I don't much care for the v6.0 compiler itself, but the IDE is undeniably useful in my line of work.
Of course, you could argue that a nice Emacs set-up or some such could also do these things. But the fact is that with a proper IDE, they're already done. By the time you've programmed this all into your favourite highly-customisable editors, aren't you just working in your own IDE anyway?
On the other hand, when we build our MLOC project with VC++, we use our own script files to do it, calling good ol' CL.EXE to do the compilation. Why? Because it gives us the level of control we need, and is easily changed. The project/workspace system used by VC++ isn't up to the complexities of our project when it comes to getting builds done safely and efficiently.
And here we see the key difference. IDEs can be very helpful for reading and writing code: good tools in an IDE can make everyday tasks easier than any CLI toolset I've ever seen could even dream of. But no IDE I've yet seen matches CLI for its scripting abilities and fine control over the build process. Both are important. In today's world, a compiler that provides both an IDE and a CLI is a good solution. In an ideal world, I'd like to see an IDE that allows the build process control of a CLI without the need to drop into independent scripting. Surely such a tool can't be far away.
IBM Visual Age products... (Score:5, Interesting)
We've been using Visual Age for Java (VAJ) at work for nearly two years now -- and it's really awesome. I hate to say it, but I'd prefer to stay within Visual Age instead of the command line. I was/still am a command-line jockey, obviously in Unix, but also in Windows.
From my quick skimming of the responses, people miss an important point: most tools (visual or otherwise) seem to require a compile to identify and fix errors - just general typos. VAJ not only does incremental compile of whatever method you are working on, but it also keeps all classes in synch. Huh? As I code, I'll code a method I know won't be correct. It'll show a funky red 'X' next to the method. As the methods and attributes get finished off, the 'X's go away. Not too much of a big deal, since that is within one .java file. However, that is working across all classes that are loaded in the workspace. Realtime. As you type it. Wanna rename a class? Not a big deal - I save, look at the errors tab, and I can edit right there, change the name. Actually, the tool will do the rename also. But, anytime a class is restructured (renamed, moved, split, combined, removed, etc) you just pop to the errors pane and fix. Not a big deal. You know the impact immediately.
Every piece of code is versioned. Down to the method - really cool if you've messed up a method and need retrieve a prior edition. You can compare different classes, different editions of the same class or method. Locate all references of a method or of a class or all implementations of an interface.
This tool was originally developed for Smalltalk, so it's geared for those of us doing OO. But, it's extremely useful. There are versions for C++, Java, Smalltalk, ... even RPG (ug). Unfortunately, the only trial edition available is for Java -- I use it at home I love the tool so much. It's also available for Linux, but unfortunately, that version is behind the Windows tool. The Entry edition (aka trial edition) is not time-bombed or anything - just limited to 750 classes that you add. That's quite a few, to be honest. And, as projects complete, I think you can just drop them off of the workspace and that resets the 750... although the basic edition costs less than $200.
Oh yeah, I'm not doing GUI development. Web development - a lot of it is framework (persistence, control, etc). Other developers are building messaging components (MQSeries). Just as an FYI that I'm not doing GUI drag and drop development. Not at all!
For those of you doing Java - bounce to IBM's site and try it [ibm.com]! Give yourself some time to adjust... the big difference is that all code is housed in the repository. It doesn't sit in the filesystem. This is not a bad thing -- it enables all the cool features that make VAJ unique. You can export or import Java code - JAR or file system - when you need the Java source. You can connect to many types of version control software if you want or need to (I use CS-RCS).
The next version of VAJ will be called WebSphere Studio Application Developer. This will work from the filesystem - this will probably be good for the general acceptance of the tool (IBM kept getting clobbered in reviews because of the repository). However, I have a slight fear that this may end up removing a lot of the features that make Visual Age for Java such a strong development tool.
IIRC, Visual Age for Java won the Jolt award in 2000 and WebSphere Studio won it in 2001.
Re:IBM Visual Age products... (Score:2)
Graphical editors (Score:2)
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)
Bottom line: The power is in how you use the tools, not the tools themselves. People who argue about which is better have lost sight of the real goal to programming. Productivity.
Use what works.
A few issues (Score:2)
There are quite a few issues bound up in GUI/CLI development wars, and here's my take on a few of them:
My general solution? I use whatever editor is accessible in xterms (or Terminal.app windows) for most of my programming, I use emacs, joe or Project Builder for compiling and debugging, and I use Interface Builder for building the GUI. I can do everything but building the GUI anywhere I find myself, at any computer (and I hop around quite a bit so it's a definite gain over restricting myself to a GUI IDE), and I am able to leverage my knowledge of text editors (held over from writing a lot of non-code documents) in writing code.
What about UML modeling tools? (Score:3, Informative)
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.
I bent my wookie (Score:2)
Let's ask some of the state-of-the-art programmers (Score:2, Insightful)
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? Get real (Score:2)
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.
pointless war (Score:2)
Personally, I code Java with nothing but a couple of command line shells, a bunch of scripts and a good text editor. I write even GUI code much faster that way and I have much more fine grained control over it. I have or less memorized the whole Java core API so I have no problems with doing it all by hand.
Then.. there's C++ and in particular, Windows (Win32 and WinCE/PocketPC) programming with Visual C++ and Embedded Visual C++. Here, I prefer the Visual C++ IDE because of a few things:
- When I write code, the IDE shows me what parameters each method takes. It shows me what methods and properties classes have as I'm writing, etc. When I write foo->, up pops a window where I can select and tab-complete the rest. When you learn to use this, you code MUCH faster. Also, you don't have to memorize the entire API with parameters and all, since the IDE helps you out.
- Debugging. You see the source code right there on the screen. You can step through it line at a time, step into methods that will automatically bring up that file and jump to the correct line.. Put the cursor over a variable and it shows its value. A good stack trace that you can click on to jump to that piece of code.. Drag and drop watches that allow you to write expressions right there in the watch window to figure out fixed point numbers to integers without a separate calculator.. etc. etc. etc.. For serious debugging, you can't beat a GUI imho.
- You still have cl, nmake, cvs etc. in the command line so if you want to work from a shell, just go ahead and continue from the project from there.
One more thing.. A lot of people under estimate the NT command line. I've seen people that are totally surprised that I have grep, tab completion, Perl etc. under NT / Windows 2000.
My advice is to not knock things until you've seriously tried it out and used it enough that you can actually form an objective opinion on it. I bet most people here who think Visual C++ / Visual Studio sucks have never even used it or just used it for something very very simple.
It's not a war. It's not about UNIX vs. Microsoft and all the political bullshit. Just pick the right tool for the right job and use whatever you find yourself most productive with.
Re:pointless war - one more thing (Score:2)
GUI aginst CLI (Score:2, Insightful)
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
Sure, cave drawings are easy to understand, and if Corporate America (think Disney) will have it's way that's what we'd be left with, but I don't know any good poetry written in cave drawing language, verbal language do have a few none the less.
You may think that programming is nothing like potery, but if that's what you think, you've missed some very subtle thing about programming.
RAD tools are okay for mockups, NOT for real apps (Score:4, Insightful)
In the work I do, less than half of the GUI windows I develop are simple fixed input forms where all the elements are known beforehand. A RAD tool is fine if your window is a simple dialog box with nothing but fixed elements, but as soon as you need a dynamically laid out window you're sunk. Even something as simple as an input form with a variable number of rows of data is beyond all the RAD tools I've found (unless you use an ugly-looking table widget which in most cases means that the end product looks amateurish) -- and if you're talking about something like having a database schema driving the layout of your input forms, you can forget about RAD tools completely. As soon as you need this type of dynamic layout, the RAD tools become your enemy rather than your friend -- and the last thing I want to do is fight the development tools I use, or have to add contortions to my source code just so that the RAD tools will accept them.
But the lack of support for dynamic layouts isn't the main reason I avoid RAD tools -- the fact is, almost all RAD tools I've seen rely on absolutely x,y coordinate placement (and sizing) for each widget. This is a terrible way to lay out your windows, because as soon as your program runs on a different platform, or even on a machine with, for example, a different set of installed fonts, or a different video resolution, suddenly all your nice-looking GUIs turns to custard. At best, your GUI windows look cramped or have widgets that don't line up -- at worst, your widgets overlap or are cropped. Talk about amateurish-looking GUIs! And if your GUI looks messy, your users will assume the code lying behind the GUI is a mess as well -- which is why I'm so fanatical about creating professional-looking GUIs.
Anyway, that's why I've abandoned RAD tools, and hand-code everything. Sure, it sometimes takes a little longer to create a simple dialog box, but I more than make up for that by saving time when creating dynamic layouts and not having to redo everything when I want to run my app on a different machine or platform...
Mind you, it has been years since I've looked at RAD tools -- it may be that some of them now do support dynamic layouts better, and maybe even use logical positioning (eg, sizers and other layout tools) rather than rely on absolute positioning and sizing. If there was such a tool (preferably for wxPython, which is what I'm coding in now), I'd love to hear about it!
- Erik.
The Best of Both Worlds.. (Score:2)
When I'm coding for my own personal enjoyment, I do so in Smalltalk, using Squeak. If I had an IDE nearly as powerful as the classic Smalltalk-80 systems, I might actually use them. Some of the features I use heavily is the class browser, which, instead of being just an afterthought and an add on, is tightly integrated into the cycle of development, the object inspector, which provides an excellent way to snoop inside your instances, and even allows you to invoke their methods using a little command window, and, finally, the fact that the every object in the system is categorized in that browser, makes it very easy for me to determine exactly what each method does.
I just wish Smalltalk VMs weren't so focussed on maintaining the entire virtual machine in one monolithic image. While it does have a certain conceptual grace, it makes it a little thorny distributing applications, although Squeak's newer package distribution mechanism is changing that for the better.
Every tool has its ups and downs (Score:2, Insightful)
- 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
{flamebait}
- editors: Once you use Emacs (or Vi, for that matter) for any appreciable amount of time, you feel _really_ handicapped when you have to edit in the Visual editor. Yes, you can plugin an editor of your choice in Visual. But Visual's default is pretty ascetic.
{/flamebait}
- debuggers: when you have to dig into dynamic libraries, Visual really kicks gdb-ass (shutup you ddd wimps!). And gprof doesn't really cut it if you can have Rational Quantify. AFAIK, Purify is slowly being phased out for unices, which is a shame. And edit-and-continue (Visual) is also really nice. The commands-command (gdb) is a life saver!
And so on and so on. If you use both on a regular basis, and use them seriously, you run into the limits of the tools. Not a problem. I find myself switching back and forth, and using the strongpoints of whatever tool is needed at whatever moment. Use the right tool for the right job. Sometimes a gui is better. Sometimes a cli is better.
Comic Books or Reference Manuals (Score:2)
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)
Most of the anti-GUI comments seem shallow (Score:3, Insightful)
I work in the game business, and it is rare to come across a PC game developer that doesn't use a GUI environment like Visual C++. Now we're not talking about slacker wannabe coders here; we're talking about Tim Sweeney and John Carmack and everyone who used to be at Looking Glass. So most people in this thread would write them off because they use an environment designed for infantile programming? These are sharp people; please give them some credit.
Interruptions and distractions slow you down (Score:3)
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:
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.
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.
The Hell, You Say... (Score:2)
AND, I've seen stunning complex 3D models of a lot of things that were generated using ray tracing programs in which you describe the scene using the ray tracer's programming language. Many of these ray tracings were done before the advent of 3D accelerated video cards and 3D modelling programs. Some of them were done before the widespread advent of the GUI. While a 3D modelling program might get you most of the way to a good look, I'd be willing to bet that your best 3D people still go in and tweak the generated files by hand to get the final look. Knowing how to do that can be the edge between a good 3D artist and a great one.
Re:Thing is.... (Score:2, Insightful)
Well, since you use "You", I can answer directly that you are incorrect. I personally can whip out Java GUI apps much more quickly and with much better functionality than with using a GUI tool to do so. For many other people it's the same. Especially with Java and it's layout managers, your GUI is much more that "stick a button this big over here". It's quite easy to program a UI that will scale up to the needed component sizes, even if you change the language on the fly (or just on startup). On the other hand, internationalization is a pain in VB and such.
Again, for me I personally can make professionall looking UI's quite quickly in Java with pure code. Plus my code is smaller, faster, and has fewer bugs. And as far as complex, when was the last time you had a UI change from English to French or Japanese with no problems at all?
Actually.... I could. Depending on the subject matter, for many 3D models I can get something nicer done more quickly by 'coding' it directly in POV-Ray [povray.org] script. This of course depends on the subject matter, but just because one person finds one way faster doesn't mean that another person won't be faster a different way. Just sometimes I'd go with 3DS or Strata, other's I'd just code by hand. And sometimes I'd write a custom C program to make the model. It just all depends.
And just in case it's a factor, I've programmed multimedia products before for many platforms, and have done 3D artist work for Interplay.
Re:Thing is.... (Score:3, Insightful)
My point exactly, some people CAN do it, and prefer to. Some physicists can also do advanced calculus in their heads, some pilots can fly around the country without using any navigational aids. It's easier and more convenient for these people, like you claim. The real point is not whether it can be done or not, but rather WHO can do it. You will find that the vast majority of people prefer to use the tools that are available to solve a problem.
When I mentioned that you would not program a complex model (i'm thinking along the line of the chick from Final Fantasy, or even just the SIGGRAPH teakettle, anything more complex than several boxes and triangles and quads) using code I was bringing up the use of tools. You would not use a sharpened stone to cut something if you had a knife lying around. You would not use a stone to drive a nail when there is a hammer, would you? Of course not.
Actually.... I could. Depending on the subject matter
You could, I could too... if I put the thought into it. There is a right tool for the right job. Any physist is smart enough to do the calculus in his head, but the vast majority of them are also humble enough to know that actually breaking out the old calculator once in a while isn't a sign of weakness.
My main realm of endeavor is web programming, I've done some stuff with some websites that I can't believe I was able to pull off. PHP, PERL, ASP, whatever, I can do it and well. When it comes to the HTML output of my scripts, I can code HTML like it was english. I can make tables, forms, anything. Does that mean that I'm too elite to whip out the trusty old Dreamweaver? No, I'll still break it out for fragments of what I need. Why? I could do it by hand. Probably just as fast, but messing with that crap while making it look right distracts from my real purpose of scripting. I use the tools that are available. Some tools are better suited for certain jobs. Thet people that say I will never use a GUI development tool because I can do it all in Vi are missing the big picture.
Re:GUI (Score:2)
Sometimes, yes. For example, there are tools that provide a GUI frontend to CVS (e.g., tkCVS), or to the MH mail software (e.g., exmh). That's a great approach, because you can still use the underlying CLI programs in scripts, or over a telnet/ssh session, or whatever.
However, the usual GUI way of things is that there is no CLI program under the GUI - the only interface to the software is the GUI. Suck.
I've never been in a shop that used GUI tools for programming; but then, I've been doing lower level stuff like operating systems, firewalls, spacecraft ground systems, and telephony. If I were putting together pretty GUI apps for end users, I might have a use for a GUI GUI-builder tool.
But for what I'm doing now, I want and need nothing but GNU emacs, gdb, and the C++ compliler. (Which is IBM's "Visual Age", though none of us use any of it's "Visual" features!)