Slashdot Mirror
Are GUI Dev Tools More Advanced than CLI Counterparts?
JohnG inputs: "I just got into quite a long argument over on the Yahoo! message boards over the power of command line dev tools. Basically the guy told me that it is impossible to create 'state of the art' programs with command-line tools. But when I asked him to give me reasons why he just called me stupid and 'behind the times'. Considering he was an avid supporter of anything Microsoft, I take what he says with a grain of salt. But what I want to know is how many of you developers have switched from command line work to KDevelop or CodeWarrior? And what advantages you think it offers? Certainly there are many 'state of the art' apps created with command line tools, but I'm open to anything that can increase productivity. I've just never seen a compelling reason to make the switch from what I am used to and comfortable with." Personally, I feel the best development environment to work in would be one that ignores neither the GUI, or the command line.
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.
It depends on what you're doing. I've found generally that if I'm writing a GUI app, it's nice to have all of the tools that Visual C++ offers, but if I'm writing a quick CL app, I'd prefer to just use a Makefile and be done with it.
Last post!
I get the most out of XEmacs, which is an almot-GUI tool that drives CL utilities. I use it for everything, from C++ to Perl to Javascript to HTML.
Probably the best is to stick to what you know most. DDD is probably much better that gdb embedded in XEmacs, but, well...
It's just a BloJJ
Personnally, I'm not confortable working with a GUI dev tool, I find it complicated, but that's just me.
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.
Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
Visual Studio (6 or .NET) includes CLI tools. You use them when you want to automate builds or not use the IDE just to check on something.
And anyway, it's nice of you to try checking facts before you offer a retort to this guy, but come on, it's just a flame war. Next someone will be asking who writes better software, people who use Emacs or people who use VI? (the answer is neither, it's the people who use Pico, duh)
[o]_O
All that a GUI does for you is 'wrap' the command line so the user doesn't have to be bothered with remembering the 'make' syntax for example. Whether or not a GUI is used to compile the project makes no difference to whether or not the project is good. That depends on the code, and whether you use vi or Microsoft (eeek!) Visual Studio to write your code, it is still the actual code that makes a great program, not the development environment.
Personally I find it easier to create projects with CodeWarrior than to write MakeFiles, but I really like vi and I enjoy the syntax highlighting and other features found in CodeWarrior's Editor. As far as the complexity of the applications you can create with commandline tools such as vi, gcc, and make it matches those of graphical tools such as CodeWarrior, Code Crusader, etc. One thing that I am very fond of are graphical debugers like DDD and CodeMedic. I just think they make life a lot easier.
I'm fine using text editors to write code especially now since it adds color to your code yeee.
If you have something like Star Trek in the future, where you "develop" programs using voice commands, do you consider it more advanced? I don't because Mr. Data still uses CLI!
It's simply a matter of preference. GUI tools are more suitable for developing visual stuff. Usually, they tend to downplay (but not fully) the "batch processing" concept - this will lead to a certain kind of unmanageability and you probably need third-party tools to help. For example, it is hard to use directly a GUI IDE to discern whether two forms are identical or not, but a CLI diff will do the job cleanly.
In any case, the answer is simple: just choose the right tool for the right job. Nothing is 100% better than any other tool!
¦ ©® ±
If you prefer to be a clueful programmer, you do everything from the command line. If you prefer to be a pansy, you use a GUI.
You wouldn't make a complex 3d model of anything programming polygons... you could. Java3D and OpenGL have ways for this. But to get something that LOOKS decent takes a program like 3DS MAX. You can then use THOSE models in your OpenGL app.
In the same vein, making a GUI would be better suited to a GUI programming tool, with the backend being designed with real code.
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.
ZFS: because love is never having to say fsck
-1 Flaimbait, I say.
Why were you arguing on the internet anyway? That's just pretty stupid...
Anyway, personally I prefer a good ol' text editor for most things.
Maybe the only text editor that guy has ever seen was the one that is brought up by the `edit ` command in DOS?
------
Sig
I have found that many people who started programming post DOS, using Win95 seem to be the ones really afraid of the command line. I mean _really_ afraid of it. Many of the people I work with that fit into that category would answer your question just like your collegue did.
These people think they cannot function without visual this and visual that. It really hurts what they can learn because in turn they are afraid of many handy command line tools and programming languages that don't have the visual training wheels they are used to.
I personally have never understood many people's devotion to GUI's in general, whether using them for development or for operating systems or applications. Certainly a GUI can make developing some elements of graphical-based programs easier, i.e. those designed to operate on a visible level, but the majority of most programming is "behind-the-scenes" of the real application. There a GUI can get in the way.
:-)
:-)
I've done quite a bit of Visual Basic, which I loved as a beginner as it was my first "development environment" but now I find, after the initial setting up, most development is done in a maximised code window, no matter what the language.
It can be nice to have debugging options such as real-time variable inspection alongside the application under development, and there a GUI can help, but it's no better than having seperate monochrome STDERR monitors like people used to "in the old days" (and may still use for all I know).
I suppose it all depends on the user. Personally, I'm of the school of belief that if it looks pretty it probably doesn't work as well as something that doesn't. Or maybe I just like to look good as thousands of lines of code zoom past on my screen, in the style of many "hollywood hackers".
I believe it's a similar question to ask if a GUI is better than a simple text menu for many business applications. What's easier to use? A complete Windows / X-Windows environment with all it's bells and whistles or a simple text menu containing just those options necessary for each user? You don't need "training" to press 1,2,3 or 4.
Great. I filter out "Ask Slashdot" so I don't have to put up with deliberate flamebait and lazy students asking for help with their homework, and what do I get? Slashdot starts posting stupid reader-response polls in "Developers". Time to filter that out too.
a poor programmer always blames his tools
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.
The main part of my job is writing device drivers, so I really can't use the IDE to debug with anyway. In this case, it's just a matter of convenience that I use the same environment for all of my development.
Additionally, there are some very good tools for creating GUI apps which are included in CodeWarrior and MSVC. I personally suck at creating GUIs, so I can use all the help that the tools give me.
I love debugging kernel modules as much as the next slashdot reading Linux nut, but seriously, when it comes to debugging applications, a nice GUI-based step/trace utility in the language of my choice is a bloody nice thing to have. Why?
Because it means I can spend less time debugging, and more time actually coding. And this makes me happy.
NO TOUCH MONKEY!
The arguments presented are the same as one might see when comparing GUI to CLI based OS. Obviously the CL has some place in the world, even Apple is bringing it back, but for most typical uses, the GUI is sufficient. In the end, in a new program, a GUI helps you learn how to use it. As you become more sophisticated, the CLI lets you do more.
My other sig is extremely clever...
I run linux full-time, and am facile with gcc and the like. For smallish apps, I stand by my CLIs, and for anything in any language other than C/++, I wouldn't consider anything else. However, when I'm dealing with enormous programs with hundreds of different classes, dependent on large numbers of even larger libraries, all of which I need to compile myself, MS Visual is really far superior to any of the CLIs available to linux users. It's faster, it's much easier to debug (since it effectively interprets the C++, allowing you to do all those cool things like executing code in arbitrary order at debugtime, and even changing code and rerunning the new version, without a recompile), and being able to look through a list of classes and all of their members instantly is invaluable. The last benefit is that if I'm designing a GUI, I'd always rather do it in a GUI. If I know what my program should look like, it's much simpler to say "The big FOO button goes here." Than fiddling with coordinates, or, even worse, packers, for 20 minutes making it look exactly right. Most of these sound like they're things that could actually be done on a command-line program, so maybe the solution isn't to develop GUI IDEs for linux, but to create more robust CLIs. On the other hand, for some things, a GUI will always be better. (Note that I have yet to develop any HTML document in anything other than windows notepad.exe or console emacs, so I still stand by the old ways for some graphical applications.)
This is a self-referential sig
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?
This is probably a major question to get answered first. For example, Emacs with JDE for doing Java work has just about everything VJ++ has (except for a WYSIWYG UI editor that only creates layouts for the proprietary MS Windows only classes). It has menus, integrated debugging, tags support, speedbar...
So, what is this person pushing as a "GUI" tool? One specifically, or many?
Also, given what Emacs does and looks like (except for those pretty buttons on the toolbars), does it count as a CLI tool or as a GUI tool? The line is often blurred, but I know of many people who in discussions vehemently deny that Emacs is an IDE of any form.
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.
I'm still working on a clever footer.
IMHO command line tools are good but only for simple tools. Its not so straight forward to use zillions of command line options. The GUI makes it easier to navigate through the different possible options. :)
A combination of GUI and command lines is the best. For example, tools like imageMagick provide both options of GUI based manipulation and command line options. So, complex command line options doesn't scare away a newbie
I used to use Visual Studio when I programmed in Windows, simply because it had a project window allowing me to easily select between files, had syntax highlighting and an integrated debugger.
When I switched to Linux, I made up the same functionality using Kate and the Kdbg.
So to be honest, for me I don't see any point in extra GUI stuff - when you realise how many command line options for each compiler and linker tool, all a GUI does is change -c to a checkbox with "compile but do not link" next to it. It's nicer to be able to see all the options, but when you know exactly what options you want (i.e. you've learned them), it's easier to type them in on a CLI.
The only exception I can think of is tools which build GUI's which is quite often easier than coding them (but even so, not so powerful - you can code a GUI to do lots more than a GUI designer does, particularly dynamic GUI's).
Use whichever development environment makes you the most productive (which is probably the environment you're most comfortable and familiar with).
I'll qualify myself in saying, I'm not a programmer yet, but, I'm learning Perl. Now, for my humble opinion, probably from indoctorination of a Unix environment; I feel that windows applications are rarely simple. Take a look at defrag in windows, there are two versions, one windows based for 95 - ME. And the old command line version. I prefer the command line version. I'm under the impression that if you build a gui version of a command line tool, it's gets piggish. That feels like a step back. However, software like Word, is neccesarily complex, which is fine. I hope I use good judgement, when writing software in my future, that I can keep simple tools on the command line, and complex tools and apps using a gui. To be honest, I've played with a few gui based dev tools and I think I'll need them to keep track of the structure of my app.
The thing I've noticed about using command-line development tools is that you have to learn more than one tool. Gdb, gcc, lint, xemacs, manpages, and texinfo only begin to have the functionality that is found in Microsoft Visual C++. IDEs, I find, speed up the development and debugging process -- I spend less time reading (and rereading) manpages and more time writing and debugging code. I'm at the "newbie" level for all of the aforementioned tools (gdb, etc.) and am simply unable to do some things that I could do in MSVC++. I predict, however, that I'll be able to more than I could in MSVC++ once I know how to use all of the development tools I have on my *NIX machines.
In short, a variety of programs can do a lot more than the SuperApp of Doom, but the SuperApp of Doom puts it all into one place.
Mike.
http://www.yourmothernaked.com
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.
My Journal
In my experience i have seen that people little understand what they are programming when they write code.
People program by trial and error and copy + paste. They never fully understand the code they are writing until they running it, nor can they understand how it will react to circumstances they did not originally plant. Once it is "working", they never go back to try and fully understand the underlying mechanisms that make it "work".
People are unable to debug code, or locate the area of the problem without actually stepping through the code.
This is why i think programs like visual basic are a bad thing. Without a stiff learning curves it enables anyone to say they know visual basic. This invalidates the skill of anyone with a strong background in it, making it harder for employers to Gage the skillset of the prospective employer.
Proficiency with command line tools generally require a larger amount of experience in the environment being used, therefore to me it demonstrates a strong understanding of the system that is in place.
Everytime my wife cannot get Frontpage to do what she wants it to do I have to come and fix it by editing the code directly.
So as long as Microsoft sticks to producing GUI only tools, CLI competent people will still be able to outperform their GUI counterparts.
CLI people need to understand something, though. If you know NOTHING about either environment, you can find your way around the GUI by clicking various things (what does this do?), whereas with a CLI newbies are stuck, because you can't just type random commands, you'll have to read the docs. Which is one reason why newbies like GUIs and feel frustrated on a command line.
The ideal GUI dev tool gives you all the command-line functionality you could want, while at the same time intelligently automating some of the more mind-numbing activities. If you have ever cut and pasted, then you have already taken your first step down the long, long, road of GUI-dom. And if you haven't, someone is paying you a lot more money than they need to be. Me, I think we should go back to the real command-lines -- typewriters! Finding a complier might be a pain, though.
I've banned IDEs for now...perhaps if my developers use a text editor to code they may actually learn something.
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.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
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.
With a tool like Visual Basic(ugh! VB sucks!) your GUIs and forms are easy to design
I agree, but I don't know if you've noticed but VB programs always tend to look... VBish - they stand out a mile away. I haven't figured out why exactly, it's just that they always look amaturish, no matter who designs using them.
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.
: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.
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. =)
Outdoor digital photography, mostly in New Engl
I don't think it was written with either a GUI or cmd line. I was written by smearing used toilet paper all over a disk drive. "Here ya go! Not to sure what the hell works and what doesn't, but it's shit and it's binary so it oughta do somthin'!"
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
The best interface is a simple one. Sometimes that may be command line, other times GUI.
Anyway, here is the simplest computer around, and the interface is perfect because we are all born with it - the interface is human DRIVE. The computer works like this: I stick my pee sprout in your mom's poop chute for 1, and I stick it in her pee hole for 0.
poop chute = 1
pee hole = 0
Sometimes I stick it in her mouth, but that is for parity.
Sometimes complex operations can take a long time to complete, but that's okay! We're looking for simplicity here, not speed. And waiting for this interface isn't that bad.
This simple computer is very susceptable to visuses. In fact, it comes pre-loaded with several.
For review:
poop chute = 1
pee hole = 0
This computer also fits into Microsoft's
poop chute = 1
pee hole = 0
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.
I'm the stranger...posting to
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:
/. editors.
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
A command-line interface is graphical since you see it on your screen ;) I think what we really need to be discussing is black box development...
Really, though, a graphical interface adds so much to a design environment. So does a command line. What the debate stems from is the tendency to assume that a programming environment must either be a graphical or a cmd line interface, not some sort of hybrid.
It's a stupid carpenter who only uses nails because he thinks screws are for wussies, the converse also being true, blah blah blah.
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.
I use both command line tools and GUI equivalents. I think GUI can help a lot, providing graphical tools for designing (UML modeler, inheritance charts, etc.) and for coding (words completion, syntax highlightning, inline error checking, etc.). However, command line tools are often more flexible. I would say it depends on the target's environment: if you're developping a server for some *n*x platform then command line tools may be more efficient (vim has syntax highlightning, after all :p), but if you're targeting a Win32 platform with hundreds of resources files, etc. Visual Studio stays the best choice.
I've never used KDevelop nor CodeWarrior (except on BeOS, but it was just a poor shitty IDE with not so much features), but I don't see anything valuable currently in unix IDEs that are more source editors than true design platforms.
Julien.
I don't know if its really GUI vs. CLI. It is what do you like for your editor? What do you like in a debugger?
It's all personal style, but I have to say that things like drop down method & property names, and drop down function prototypes can be pretty handy. Tooltip type evaluation of variables in a debugger window is also pretty slick.
On the other hand, if you are used to something that works for you... I don't see how anyone can argue.
The compiler in visual studio can be run from the command line... Infact, you have more control over the compiler that way. I have had to use it on more than one occassion, and found it much easyer to compile code.. than try and find the proper check boxes in the properties.
Well I've developed some pretty powerful apps using vi, cc, dbx, CLI index/search tools and make, on the other hand when doing Java development the IDE I use, Netbeans 3.2, is a big help, partly as jdb is such a lousy debugger, but also as the text editor's integration with the database of classes in the system makes it much easier to look up objects/methods in mid-edit that would be a huge pain to look up using grep/awk, or having to hold several hundred classes in my own memory so this certainly speeds development.
...
This came home when I was doing some work on a C++ system that I was new to, without IDE or class browser support, and I was surprised how much time I spent in another xterm looking up available methods and how to use them.
Of course even Visual C++ eventually just ends up executing cl.exe and link.exe to compile and link the code you've just typed in in the end and also lets you export nmake files so you can build you projects using command line tools too.
If I was developing a GUI based application from scratch I think I'd prefer to do it all in an IDE, then again using Glade to build the GUI and hacking the callback code in using the older steam driven tools, vim/gcc/gdb/gmake, works pretty well too. This was part of a small test program using CORBA with a C++ and a Java GUI based client/server programs. The Java program was done entirely in the IDE, the C++ in a mix of the glade UI builder and the CLI stuff.
Having said that I have met people who have become dependent on flashy GUI tools, and who measure their worth by the sophistication of the tools they use, as opposed to the quality of the code they write. I've even had to cover for people who've refused to fix bugs on certain platforms just because they didn't have access to a GUI based debugger and would be forced to actually read and understand the code, use dbx/xdb/gdb/ladebug/etc or (horrors !) printf()
How did the parent get moderated to 4 insightful? GUI components can be automated in Windows using COM. You can write a program to do anything a user can: create a spread sheet, enter values, change font sizes, and save it. Granted, scriptability for Linux GUI components is rather shoddy, but there's nothing stopping you from automating a GUI component.
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.
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
I have never programmed faster and most of those stupid errors you get when you make typos or simply remember a name or argument order wrong are almost gone.
Add to this the fast debugging where it automatically displays active variables and stuff, and there is no way I'll go back to CLI (the actual compile can still be done by CLI, so we can have our nightly builds).
Currently I am programming Windows only, but will probably end up doing some Linux/Unix code again in the near future - I just hope there will be something similar available at that time, else I'll start calling Linux all the bad words I normally reserve for NT.
Personally, I write my programs in various flavors of assembly on paper with pencil. I then hand assemble, again on paper, but I use pen instead of pencil. Then, I use a machine-language monitor to directly enter the op-codes to ram, either in hex or octal (binary is just too primitive!). This is the only way I truly know what the processor is doing.
And, if you believe that, I have several priceless family heirlooms to sell you.
I think GUI-based development tools are very good for beginners and if the tool is good even for pro's, but commmand line is more flexible. How many of you started with Borland's Turbo * series ? I've used Turbo Basic, Turbo Assembler and Turbo Pascal in my youth (which is not that far away :-), and they were very simple to use which made them so successful. At the same time, they were very powerful, especially because of those great debugger support combined with a good online reference.
;-)
;-)
Now, since I left the Microsoft world three years ago I don't know about todays Borland tools, or Microsoft's Visual tools. But I'd bet these tools are good, because of the programmers use them. Command line tools are found mostly in the UNIX world, maybe because there is no good command shell in Windows
But if you understand more things 'behind the scenes' and start building larger projects with several dozen to hundred files, one sometimes needs more flexibility than a GUI tool can offer. I personally prefer a KDE Konsole with three to five terminals plus Midnight Commander. It makes working very fast, at least for me it's faster than KDevelop or Sniff+ or any other GUI tool that I tried. For me, the main problem with GUI dev tools is simply the lack of good Makefile support. I've found no GUI tools yet, which makes it easy to write a system which uses plug-ins which in turn use 3rd party libraries... plus the necessary directory structure to keep the source maintainable. Maybe there are, but one needs time to learn how to use a specific GUI tool, and I'm too lazy for that
Actually NT has the "at" stuff... equivalent of cron. Oddly enough, my MCSE friend has never heard of it.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
I wrote a Visual Basic application some years back, and kept on struggling with getting the user interface right. Even something as simple as getting all the buttons to line up consumed amazing amounts of time.
Now I write C code that spits out HTML tables, and the alignment is perfect every time. If there's a problem, it's usually easy to fix - usually as simple as forgetting "<td valign = top>".
And if I'm asked to, say, change the background colour of the page, or switch a whole bunch of elements from the left side of the screen to the right, I can do it, easily.
The only development tools I need are emacs, gcc, and a dose or two of common sense. Not bad, not bad at all.
If you think text, as I do, you are way better off writing programs that spit out text, instead of programs that manually position every pixel on the screen. In my experience, I'm far more productive and create much more attractive applications by spitting out HTML and letting the web browser worry about the pixel by pixel stuff you do with a GUI.
But if you think visually, as I think most people do, the GUI's probably going to work better. It's certainly mind-numbingly difficult to translate a bunch of numbers into a page prototype in my head. But, perhaps, not yours - and that's why we all need different tools.
D
Basicly I think the main difference between the two is the level of patiance the user has and how in depth they want to get. I view the difference as a Graph where the Y access is the Time it takes to learn and the X is the Level of complexity you can acheave in the program. On this Chart I see GUI developing tools like a linear curve (A straight line) And non-Gui a Logrithmic Curve. (Well I did have a graph in text that represented it but the Lameness filter didn't like it) Sience most porgrams that are out there are fairly simple so GUI can do the job but when it comes to a point where you need a really complex program command line program can do the work a lot faster and easer because you dont have to fight the GUI and its restriction to get it to work.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
If you're trying to learn an unfamiliar set of libraries (such as the .NET Framework), the Intellisense feature, and also so-called (context sensitive) DynamicHelp are, well, very helpful.
For example, you declare a variable
Type type;
You type
type.
and Intellisense prompts you with a list of methods on a 'Type'. You *pick* (not type) GetCustomAttributes. You see
type.GetCustomAttributes
You type
(
You get a list of the overloaded methods of Type.GetCustomAttributes, each with return types, parameter lists, and summary descriptions of each overloaded method. You pick the first variant, and it prompts you for args as you go.
Very productive -- no hunting about, and you would have to go out of your way to make an error. The same features work for your code as you write it. Declare some methods, write some summary comments, and sure enough you're prompted with these as you write calls on your own methods. (Apparently) no compile required.
(This feature, while very well done, is not new to VisualStudio.NET, of course. For example, Looking Glass Software's Alice Pascal (1985) had the same type, function, and argument prompting, and context sensitive identifier completion, even for user-defined types.)
That said, when I am writing small amounts of quick and dirty C or Python code I invariably bring up a vi or two.
What is a GUI really but a flexible visual analogue of a keyboard and selector system? These days they even have virtual pop-up sticky notes as little non-graphical reminders of what the tiny picture means in case you're not from the U.S. west coast. Many GUI-bound systems don't have a non-graphical representation, though, making the underlying functions impossible to manipulate non-graphically. GUIs are usually oriented towards a particular style of work and a particular set of expectations; they use a language that usually has to obscure the real operation in favour of a metaphor.
We are visual creatures, a computer is quite definitely not. Fundamentally the command line is closer to the Turing Machine nature of what a computer truly is, and with less abstraction comes more sophistication and potential. As a programmer becomes more expert this becomes extremely useful, since the programmer has grown to truly understand the nature of the machine and abstractions get in the way. The programmer masters the machine itself, not an approximation.
For example, in a current project I need Perl, Java, Ada, C/C++ and Python programs written on NT, Unix and VMS to communicate with a system over sockets, ACMS and various species of CORBA. Visual-Foo++ isn't going to handle the single representation of the workflow that I wrote in language X that gets translated and compiled into the interface for the various legacy components. It probably could be forced to, but why when make, lex and yacc can make quick work of the problem? On the other hand, if my application is of the "fill in a form, save, edit, delete data in a database" type then a GUI-based tool is going to be fine for developing it. Some semi-GUI tools like visual debuggers can produce visual representations of data that often help comprehension, but even these often fail when the going gets genuinely tough.
GUI dev env's will be with us for a long time; my favourite ones are those that disappear when it's time to get hard work done...
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.
.exe". And that's where something like the CodeWarrior IDE falls down.
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.
It really depends what your project is, if you are developing a very large GUI Interface then RAD Programs such as Delphi Kylix VB or C++Builder (note 3/4 are from borland and not microsoft =)) (btw Bornald C++Builder has a command line compiler in it's package).
Anyways, i have grown to really like how much less time it takes to create guis with C++Builder.., But after you have created the guis it really doesn't matter, it just makes debugging easier when you have the line of code you are breaking at highlighed and don't have to search for it. So overall i acually prefer the GUI Based compilers but there is still a big need for command line compilers for things like cron compilation.
Anyways, i think i have made my point. OH another point while i am on the subject is if you have to develop for windows use Bornald C++Builder, you will not regret it, i hate the interface of VC, okay i am done now.
Ben
i don't want to disagree with all the "command lines rule" guys here, but if you're doing any kind of UI or OOP work gui tools give you much more info to work with. For straighforward procedural 'C' or system work it may be a wash, but i fail to see the intellectual superiority of setting an object property via text in a file vs entering the same text in an edit box. or selecting a menu item to set it. the intelligence is in knowing what to do, not how you do it.
personally i had nothing BUT command line stuff to work with for oh, about the first 13 years i wrote code and have used both for the last 10 or 11 years. i think it's kinda funny that programmers don't want to make use of the same kind of technology we build for other people.
The revolution will NOT be televised.
You perceived it right: cut and paste is the first step toward an GUI code generation tool. That also explains why GUI tools are probably dangerous.
Why cut and paste? It creates code forks that become a nightmare to support because you need to support every reincarnation of the code, and of course they begin to diverge right away.
Instead of cut and paste, you should be building classes to capture the useful common functionality. The question is, do you build your software top down or bottom up. My brain is trained to function in the latter way, but I have noticed I'm in the minority.
Marko
Personally, I can't imagine any software engineering problem that couldn't be solved with either a CLI-based or a GUI-based tool.
However, _debugging_ code generally seems easier when you have an interactive GUI debugger...compare VC++'s interactive debugger against dbx, for example. Even ddd on top of dbx usually adds a lot compared to just dbx.
So I submit that developing isn't necessarily "better" with a GUI -- some people DO think in code, and the gui doesn't really help unless you're doing GUI layout or the like. But having a GUI front-end to an interactive debugger makes testing and integration a LOT easier, IMHO.
You shouldn't verb words.
I've noticed that part of that look is it's a real bear to get your program to grab the colors the user has chosen and use them for the program..i.e. the VB grey for panels is different than the default windows gray by a small amount. I tried doing this in VC++, and well, no docs told me how. I figured out how to make it work in VC++, though.
Counterparts: Quand le compteur part t'sais pas quand ça s'arrête.
You do realize, that if he is eventually found dead, you will be the prime suspect.
The point is, there are lots of tools out there for development and it's wisest to use those that work best for you/your project.
Maybe you really like CLIs, so you prefer and are more productive with those kinds of tools. On the other hand, you may prefer GUIs and be more productive that way. I (and I think many people) prefer a mix.
I do most of my development (C code) in Visual Studio (even for platforms other than Windows), because I am more productive in that environment than the other things I've tried, like traditional UNIX dev environments.
However, a significant portion of my build process is perl script, because it makes some things easier. I also use command-line CVS for source control because I like it.
Just use what is best for you. Arguments about whether CLIs are better than GUIs and whatnot are juvenile and miss the point.
They can give you hints about the data structure you are using. This is a function of the editor in the Integrated Development Environment(IDE).
To give an example if you have a class foo.
foo bar;
bar.
when you hit the period, a list of the possible things you can do with this class is given. Borland's even go so far as to elimate things that you can't do, so for example an assignement to and integer will only show functions or data that return an integer.
Also for visual applications gui's definititly speed up the process. Pop a few buttons down, and the IDE puts the stubs to handle the code into the class. If it wasn't for Delphi and C builder I'm not sure I could have overcome the learning curve of windows programming. (No I'm not a newbie, I just wouldn't have bothered).
On the other hand I like and appriciate the command line tools, and use both on a regular basis.
I worked on a project with some 12 other developers and I think we all had our own different environments. Some were running Visual SlickEdit, some had Sun's Forte, some Kawa, and I (all by my little self) was running Cygwin, bash, make, ant, and vim (I'm not boasting or anything, just telling it like it was).
On the one hand, I had a lot more programming experience than those people so I could move around my environment faster than they could move in theirs. Including checking out files from Clear Case and running diffs and such. I would say that on average I could find a bug, diagnose the problem, and fix it in a quarter the time that it took most of my co-workers. I can move through a file in vim faster than they can with their GUI editors.
Given that, I would say that GUI tools help you start projects faster because they have templates and wizards and things that give you a decent skeleton. They also have better help systems--so you start typing in a Class name and it pops up a box with members and such.
CLIs are great for folks who know what they're doing because they're more easily customized and can be more efficient. But it does take time to script the infrasctructure.
MS VB and VC++ just call CLI compilers in the background anyway. The only thig that they offer is the ability to (obviously) design the GUI (ie., draw buttons and textboxes etc.).
So, it is all a matter of preference as to whether you want to call them commandline apps yourself or let the MS Visual Studio IDE do it for you.
GUI tools /do/ have a place -- to save me from
/start/
typing prototypes of GUI elements in my apps. Once
this is done, I invariably must make that (static)
prototype an active element. Also, I have _never_
used a GUI tool that would layout GUI elements as
well as I can by hand (remember, that I
with the code from the GUI tool).
b
As a programmer who cut his teeth on Unix, and now manages (sorry) programmers that are only familiar with "visual" environments, I'm amazed by the lack of understanding of the basics of the compilation-link-load-execute model.
Such things as: declaration vs definition, preprocessing, the "#ifndef foo_h #define foo_h #endif" cliche, library search path vs include search path, etc.
It looks like the visual environment hides the details, which is fine when everything compiles, and when you're building a framework along the lines that the tool builders envisioned (simple forms, etc.). But the minute you try to do something different, or if you misunderstand the designer's paradigm - good luck! In these cases, understanding the mechanics of program building helps, while those who don't start hitting the mailing lists...
Ubi dubium ibi libertas: Where there is doubt, there is freedom.
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.
.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
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.
--
Karma 50, and all I got was this lousy T-Shirt.
What is considered a "command line tool?"
$ echo "printf(\"Hello World\\n\")"
Instead of using vi/emacs?
gcc can compile lots of things, but if you're designing a gui I would think using a gui would be something of a prerequisite. If you're not designing a gui then there's no reason to need a gui.
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 know the above was refering to software development, but I think an environment like AutoCAD is extremely cool. It welcomes people who like point and click, and yet a lump sum of the features interact with the user from the command line as well. I wonder if that kind of setup can be applied elsewhere...
By the way, my experience with CLI vs GUI has been... GUI does complex tasks faster than a CLI can, but for the basics, CLI can be used at a blazing speed for fast typists. The point-n-click strategy isn't cool when speed is a priority... But again, a hybrid is truly interesting.
Anything that can be done on the on the command line can be replicated with a GUI. But from the command line, you can't even get close to matching the productivity boost you get with a GUI. Setting breakpoints, opening files, watching certain variables becomes a matter of a half second mouse point and clicks.
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.
Why are you letting these clowns ruin our country?
From the "i-dunno-better-beat-that-horse-til-it's-disassoci ated-atoms" department...
...
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'.
I would simply call you insecure. He finds it impossible to create state of the art tools with CLI, you interpret it as a direct personal attack.
Considering he was an avid supporter of anything Microsoft, I take what he says with a grain of salt.
We all know any argument that comes from a supporter of Microsoft is instantly void of logic or or any merit whatsoever.
[snip]
I am personally writing code for Soar (a symbolic AI language) in xemacs then importing it into a Tcl-based environment where I type things into the console like "print somerule" that dumps out a rule, then right-clicking on operators to generate more print statements, at which time i hilight some of these print statements and copy and paste them into a notepad window. And on windows, so process that, CLI boy.
I've finally had it: until slashdot gets article moderation, I am not coming back.
In the land of macs, where they originally tried to banish all things not GUI driven, even there, in the 80's revolution, the primary development environment was MPW, made by Apple itself, which, of course, was the command line environment for doing Macintosh development; an embarresement to some in the Mac community that felt it inelligent and somehow not fitting of the GUI vision, but it proved essential to get any serious development work done on the platform.
If even there, where in all other things, command line driven interfaces were banished, it proved nessisary, essential even, to do development work, then I say the CLI has a long future ahead...
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.
Only 'flamers' flame!
...therefore I have sworn off all text editors.
That's like most of Windows software companies do: they use GUI tools for developers and CLI for nightly builds. GUI tools are invaluable when you program, just because most of them contain something like IntelliSense, so you have no need to memorize thousands of methods and API calls, you don't need to type them fully, you don't need to memorize the list of arguments. More advanced GUI tools (like Visual Studio.NET IDE) will even highlight some of syntax errors for you AS YOU TYPE. After compilation you have direct access to the places where errors were found from TODO window. I'm not even talking about integrated debugger and MSDN - these two are life-savers. Many people don't know, but in Visual Studio integrated debugger you can change the text of your program as you debug it, and, after performing minimal recompilation, you can CONTINUE debugging it without shutting debugger down and repeating all the steps. I'm not even talking about server browser and integrates SQL utilities. I see clearly, that developer doubles his productivity just by using GUI tools. But when it comes to nightly builds... Man you have to build them on 4-proc server and this is where you need make utility and CLI. Fortunately all GUI tools I'm familiar with offer command line builds. Literally, you get the best of both worlds.
Maybe I'm missing something, but what's the beef with a 100K program?
You can't enter a 100 KB program in a 64 KB demo competition. However, you can enter a well-written 64 KB demo in an 8 MB demo competition.
Will I retire or break 10K?
The fact is that command line programs can't take as much information in in as much time as a GUI interface. Making windows and graphics is notoriously easy compared with trying to type out a GUI like file for the description of that graphic. We need to be able to intuitively communicate a high bandwidth of information to the computer and the command line is archaic in this. I have written an AI program that will track objects. Its very complicated, so the best way to present the interface is thru a GUI. Command line would drive you nuts. The next step in GUI is a virtual 3d GUI where you can turn in 360 degrees and grab your documents with your hands. Point with your hands, etc... This type of interface will present an order of magnitude more information to the user in a smaller time period.
Chalk up one more developer (me) who has gone the other direction--giving up gui devel tools for command line versions.
:)
Bash + vim + make >= GUI+ IDE (IMHO
>>'why the hell would I do it in vi, when I can click on a few menu items and have an editor write all the code for me'
Because you might have enough pride in your work to actually want to write your own code, rather than letting a machine do it for you?
The one exception is this: almost all graphical IDEs come with a kick-arse visual debugger. It is so much easier to track down a bug by stepping through code with a decent variable-watch window and all the other bells and whistles you get that it's not even funny. Unix command-line debuggers are back in the stone ages by comparison. You get forced back into debugging-by-printf/cout hell.
When I'm doing Linux dev work, I use makefiles and a simple text editor, but for debugging I fire up kdbg (used to be DDD), just because it's so hard to go back to command-line debuggers.
Oh, and veering wildly OT: Good lord, are we *ever* going to get precompiled headers for g++? It's pretty much useless for large projects without.
A.
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.
This is not a sig
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
www.HearMySoulSpeak.com
I know a bash shell is orders of magnitude superior to a DOS command prompt. But your example was inappropiate
MOD THE CHILD UP!
I am an IC design engineer and we use all CLI for design and verification. The most GUI we use is for signal waveform veiwing after simulation. There are the occassional gui interfaces for configurations for some tools but for code creation command line interfaces are better for us. Such editors like VI and emacs are still holding strong where I work. No one has even mentioned bringing in a IDE of any sort.
-J
GUI tools are wonderful for tasks like creating user interfaces. Most GUI tools don't scale very well, though. When I build user interfaces in Java I code all of the layout manager stuff by hand rather than using the tool in Symantec's expensive environment -- it isn't good enough. Glade http://glade.gnome.org/ is good enough. It's wonderful. Does anyone write libglade XML by hand?
I also like having an editor that respects my breakpoints and adjusts them when I move code around. I learned how to program in assembly language and it seems natural to me to inspect registers/variables and change code while it is running.
Color syntax highlighting, dialogs to set compiler options, integrated icon editing, these features I don't *need* but I don't mind a pretty environment as long as it is designed as a view into the command line tools rather than a replacement.
oh,i don't know... let's think about this one.
in order to create State of the Art(tm) code, i need State of the Art(tm) tools with fancy buttons and little blinking lights.
but wait...
Uh oh...
where did these State of the Art(tm) development tools come from?
conclusion: State of the Art(tm) programs do not exist, because they require State of the Art(tm) development tools. this is a paradox. please reboot now.
seriously, though, i think the issue comes down to TIME. Fancy development tools are supposed to save TIME. but you know, i use command line development tools, and hitting the (up) arrow takes about as long as it does to click on a button.
you know, forget all that. Fancy development tools suck. Command line Rules. yeah.
/zard
I disagree.
The customers on my last 5 GUI projects, ok all the GUI projects in my professional career, had such demanding GUI requirements that we couldn't build the app with a screen painter anyway. We built some prototypes with RAD tools, but then had to hand code MFC, OWL, AWT or Swing interfaces.
I've used VisualAge, VisualC++, VisualCafe, BorlandC++, Delphi, C++ Builder, and JBuilder and found this to b true in all of them. My most productive tools are API docs, emacs (but any complete editor like jEdit or vi would do), and a comand line compiler (debuggers and profilers are nice, but optional).
Joe
Joe Batt Solid Design
Flexible & distributed in *nix/Win environs. I've payed for many upgrades under both Linux and Windows. Quality tool...
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The problem with these discussions of IDEs vs. CLI tools is that most IDEs contain so many features (most of which no real programmer wants to use) that the tool ends up getting in the way more than it helps.
<shameless plug>
This is the motivation behind the research project I'm a part of, DrJava, to create a simple but powerful Java IDE. (I don't want to hear about Java vs. other languages, we are only targeting Java.) DrJava is targetted most specifically at beginners, but it's pretty useful even for experience developers. It's also in active development and getting new features every day. (See the link for more info, including an academic paper describing DrJava's rationale for teaching students.)
</shameless plug>
We've been using Visual Age for Java (VAJ) at work for nearly two years now -- and it's really awesome. I hate to say it, but I'd prefer to stay within Visual Age instead of the command line. I was/still am a command-line jockey, obviously in Unix, but also in Windows.
From my quick skimming of the responses, people miss an important point: most tools (visual or otherwise) seem to require a compile to identify and fix errors - just general typos. VAJ not only does incremental compile of whatever method you are working on, but it also keeps all classes in synch. Huh? As I code, I'll code a method I know won't be correct. It'll show a funky red 'X' next to the method. As the methods and attributes get finished off, the 'X's go away. Not too much of a big deal, since that is within one .java file. However, that is working across all classes that are loaded in the workspace. Realtime. As you type it. Wanna rename a class? Not a big deal - I save, look at the errors tab, and I can edit right there, change the name. Actually, the tool will do the rename also. But, anytime a class is restructured (renamed, moved, split, combined, removed, etc) you just pop to the errors pane and fix. Not a big deal. You know the impact immediately.
Every piece of code is versioned. Down to the method - really cool if you've messed up a method and need retrieve a prior edition. You can compare different classes, different editions of the same class or method. Locate all references of a method or of a class or all implementations of an interface.
This tool was originally developed for Smalltalk, so it's geared for those of us doing OO. But, it's extremely useful. There are versions for C++, Java, Smalltalk, ... even RPG (ug). Unfortunately, the only trial edition available is for Java -- I use it at home I love the tool so much. It's also available for Linux, but unfortunately, that version is behind the Windows tool. The Entry edition (aka trial edition) is not time-bombed or anything - just limited to 750 classes that you add. That's quite a few, to be honest. And, as projects complete, I think you can just drop them off of the workspace and that resets the 750... although the basic edition costs less than $200.
Oh yeah, I'm not doing GUI development. Web development - a lot of it is framework (persistence, control, etc). Other developers are building messaging components (MQSeries). Just as an FYI that I'm not doing GUI drag and drop development. Not at all!
For those of you doing Java - bounce to IBM's site and try it! Give yourself some time to adjust... the big difference is that all code is housed in the repository. It doesn't sit in the filesystem. This is not a bad thing -- it enables all the cool features that make VAJ unique. You can export or import Java code - JAR or file system - when you need the Java source. You can connect to many types of version control software if you want or need to (I use CS-RCS).
The next version of VAJ will be called WebSphere Studio Application Developer. This will work from the filesystem - this will probably be good for the general acceptance of the tool (IBM kept getting clobbered in reviews because of the repository). However, I have a slight fear that this may end up removing a lot of the features that make Visual Age for Java such a strong development tool.
IIRC, Visual Age for Java won the Jolt award in 2000 and WebSphere Studio won it in 2001.
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 think it depends on the tools a lot and also on what you are doing.. For example, Codewarrior is really good and really fast. It's nice not to have to manually edit dependency lists in makefiles... The windowing debugger is cool -- very fast for debugging simple things, but I miss being able to script breakpoints (i.e., it's not so good at going after the really nasty bugs). For C++, the class browswer is a real time saver.
ProjectBuilder (the OS X GUI development tools) is not quite as good. For starters, it's build on top of CLI stuff. The down side of that is that it's a lot slower and (as others have pointed out) not everything is implemented in the GUI and it has not provisions for getting at the CLI from the GUI. For example, you must stop debugging the program from GUI and run GDB from the command line if you want to use breakpoint scripts (or numerous other things).
There isn't even a clear cut distinction between the two environments. Even CLI people use full screen text editors (which is a GUI of sorts). I don't see anybody using "ed" to edit files these days (I remember using UNIX when that was the ONLY editor..).
An engineer who ran for Congress. http://herbrobinson.us
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++.
- Michael T. Babcock (Yes, I blog)
--
Given enough personal experience, all stereotypes are shallow.
But the real reason that windows programmers swear by MSDev is its wizard system. MFC, the Win32 API wrapper with which most C++ GUI apps are built, requires a great deal of black magic. It uses obscure, undocumented macros to implement critical functionality. The only way to really use MFC is through the wizards, which take care of the macros for you.
:)
I use the VC++ IDE all of the time and none of the applications I've produced for work have been touched by a "wizard." I don't use the MFC (except in a couple of cases when people asked me questions about it -- and then I just consulted their documentation for the macros that were necessary to create a scriptable component.) All of the applications that I write are built on top of my own wrapper of the Win32 programming interface.
I think that if you think that man beats the MSDN Library, you can't possibly be sane.
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
A gui development enviroment is only as helpful as the code is visual. For a RAD enviroment, having a gui is esential, otherwise you miss the point of RAD. RAD lets you speed up by alot your development time by just draging and dropping your parts into place. Much better than spending alot of time developing a gui that really is not the point of your app -- the algorithim really need that time. Keep in mind though that if your compiler does not make good code, all the gui effort is wasted. MS VC++ can be an ok development enviroment, but the compiler in it sucks as its no ANSI complient and probably never will be thanks to MFC. Oracle Jdeveloper on the other hand lets you use and installed JDK on your system to compile the code, so you get the best of both worlds. If it's a command line app you dont really get much out of the gui other than not having to fire up a new shell.
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.
haxor: I don't use a gui for my programming all I use is emacs, a file manager, and a makefile.
.h(pp) and .cpp files. Then theres the tooltips that show me what the return type is and arguments for a function.
emacs = macros + syntax highlighting + editing
file manager = workspace view
makefile = workspace file
IDEs build upon the CLI. Its not correct to compare an IDE to a CLI since they do different things. The IDE takes the place of the above things and ads functionality, so you can't correctly say its more advanced. That said IDEs allow much more productivity and ease of use. If you train yourself to navigate the fileystem quickly by memorizing your source tree, then you can gain some of the usefulness of an IDE, but lets face it. In a project with several thousand source files being modified by a dozen people, this isn't going to cut it. A colleague might have added a new directory structure that you can't effectively navigate.
In addition, IDEs provide language specific advantages. Visual Basic does syntax checking while you're editing. Visual C++ does autocomplete and has an oft overlooked feature called WizardBar. I hit control-n and it adds a new function to my object in both the
No one can argue that ides add significant functionality to the programming environment. The question of CLI vs IDE is moot since they don't provide the same functionality. One compliments the other. A better question would be: editor+CLI+makefile vs IDE. In that case I would say that IDEs will always provide more features with less pain.
Unless you program with edlin or debug or something similar then you're not doing true command line development.
I have worked with two applications both in excess of 600,000 lines of code. One the C++ (GUI developed) front end to the other, a C (CLI developed) transaction engine.
No GUI I have ever seen helps with the development of the transaction engine, however a GUI layer over the top of GDB (al la ddd) makes life much eaiser when debugging.
Make and Makefiles (well gmake at least) are the only way that I have used that comes close to managing projects of that size even remotely effectively. There is some talk of alternative "make" tools that use a different logical basis but whilst interesting I have never used them and so feel unqualified to comment.
I despise the GUI approach to "configuring" ones build environment, dialogs and the like are not the way to accomplish this. But the ability (via keyboard or mouse) to jump around in the codebase is a feature that makes GUIS almost worthwhile
What does this mean. Well I thnk there are several implications. First the GUI approach does not lend itself to the engineering of software. And by this I mean the creation of a resuable infrastructure of software tools that can be used and reused on an ongoing series of large scale projects over the lifetime of a software development organisation. Second, access to an intuitive code navigator is a cricital feature of software analysis and a GUI IDE is a relatively elegant way of achieving this. Finally that major projects will best be built using a non graphical process since the GUI is designed for Us and not for processes. This last point is best illustrated by thinking about how even microsoft builds their nightly versions of Win???, i cannot imagine that they have someone who hits build on a copy of Visual studio before they woalk out the door for the evening. So even in the hallowed halls of redmond does the CLI approach most likely ring loud.
Just a few thoughts :-)
"The first thing to do when you find yourself in a hole is stop digging."
cli apps provide two basic constructs:
the power of cli apps is the fact that both the programatic interface to the component model and the user interface are the same thing! the user interface mecanism provides a 'quasi' natural language interface (which can be quite productive), and the programatic interface provides a convinient way of putting components together for solving problems.
what i don't get is how gui-centric ppl can't see the simple advantage of cli (at least for server/backend components). the same interface gives you a programatic interface (in all languages), and a simple user interface. what a bonus ... you learn the user interface, and you know the programatic interface. few component models are so easy to interact with.
are clis the end-all of user interfaces? of course not ... but they are a useful tool, and a powerful paradigm for componentizing software.
mx
I've tried Cafe, Visual Age, JBuilder, and Forte for Java development, but nothing beats Visual SlickEdit and Ant as my development choice for Java.
I have learned through experience that using a GUI can be VERY helpful when building a GUI. For instance, VisualAge for Java automatically produces GUI code within a fraction of the time that it would have taken me had I wrote it myself. I was sceptical when I first tried it since I don't like having "automated" code in my projects, but most of the time we are all pressured by release dates etc. But for non GUI work, give me any text editor and a big cup of coffee!
SF
As I understand here are that some people advocate a GUI development tool when you're writing GUI apps and a command tool developing something without a visual interface. ???
Nothing is more difficult than writing a good complex GUI app, almost you could call it an art form. And as I never ever seen any good graphical GUI app in Unix/Linux in all my life I think the people in Slashdot are not qualified to have any opinion about this whatsoever.
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.
--Matthew
as far as programming is concerned, the question is a no brainer:
/and/ some information to the right, the left, top and bottom of my editor window?
why should i limit my field of editing to a 80x25 character display when i can have the same functionality
question is if you have the same keyboard comfort in kdevelop as you have in emacs (for instance) - but you can't dispute that all modern IDE's have customizable keyboard shortcuts and even (imperfect most of the time) emulations of other editors...
so what, take a GUI...
regards,
PAT
SEO Test: TIGI und SEBASTIAN - Online Shop - V
...and a good CLI environment will beat bad GUI tools.
;-)
Of course, it depends exactly where you draw the line. Emacs, for instance, is a GUI tool by my definition (e.g. it has menus), but it has been referred to in this thread as a CLI tool. Even vi is somewhere inbetween (surely a CLI purist would use a line editor like ex
I really don't think many people would argue that visual editors and graphical debuggers haven't improved productivity. I've used purify with and without a GUI, and with is better.
For IDE's, I think it is less clear cut. For projects that fall into the shape the IDE designers envisaged they can be quite cool, but command line tools have wider boundaries and are easier to extend (e.g. incorporating your own script based code generation tools into the project build systems.
Finally, tools that offer both options generally allow you to choose the right tool for the job - I still want to be able to type debugging commands in at the command line in my graphical debugger.
There is another class of GUI tools, however, that allow you to incorporate UML diagrams within your design and development process. I guess that the two programs that best represent this class of "modeling tools" are RationalRose and Together.
RationalRose is more popular, since it was out first, and essentially set the standard, but it supports only a one-directional process (unless that has changed recently) -- design your UML diagrams, and generate code from them (some OO people actually see this as an advantage, but that's another discussion).
Together, on the other hand, is bi-directional -- it constantly updates the UML diagrams to keep them in sync with the code you are writing. As a result it has the neat property that you can actually write your code w/o going through the UML modeling/design stage, and yet you get complete UML diagrams of the code when you are done.
Personally, I am ambivalent about the utility of RAD tools for building GUIs -- they can be great for quick prototyping, but on the other hand they tend to produce code that is not very maintainable and thus not too suitable for large commercial application (although a lot of people are so used to them, that it is hard for them to see the alternatives).
On the other hand, UML modeling tools can be tremendously useful, especially in team environments. A picture is worth a thousand words, and that is very true even in programming. Even if you do not use UML for design, Together's ability to generate diagrams representing the code is invaluable when you have to take over or maintain someone else's code. It is much easier to see how classes relate to each other at a first glance, than to try to figure that out by going through the code manually.
There is a glade for python. Many languages with Gnome/Gtk bindings have tie-ins to Glade. Though I'll take perl glade over python glade any day of the week.
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.
I'm a loner Dottie, a Rebel.
How do you think Torvalds created the linux kernel?
What is used/needed to develop on apache?
How did CmdrTaco make Slash?
What development tools do you need for mozilla
Impossible without GUI? Yeah, right. End of discussion.
--- Hindsight is 20/20, but walking backwards is not the answer.
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.
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.
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.
I am a strong Linux advocate but when it comes to programming I much prefer using Microsoft Visual Studio. The point and click compile/debug environment is nice but not really important. What really makes the difference for me is the context-sensitive editor that pops up object methods/members and function/method arguments when I'm typing. There are several Linux-based editors that can do colour coding but few that even attempt to help with name completion. I really hate having to dig through the man pages and books on every other line of my program to get the list of function/method arguments-- with Visual Studio I can write programs faster.
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.
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 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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
They stand out becuase they lack any kind of decent layout managers.
Most VB GUIs can't be re-sized, so they look like crap at resolutions other than what the VB user was using when he created the forms
And many vb programs use the default ugly icons for cancel and ok buttons that came with visual studio.
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.
:wq to save and quit, :e to open a file, and so on - and now I use them instead of the menus.
Simple solution to simple problem. Install gvim (apt-get install vim-gtk for debian users, or vim.org for the rest of ye), and use that. It's pretty, it's fast, it's vim with menus. Nothing stops you from treating it like command-line vim, but if you don't know the standard vi commands, you can use the menus - which, incidentally, have the shortcuts on them. That's how I learned that I can use
I couldn't possibly have learned vi without gvim, since I'd have spent more time in the help than in my files. Now that I've used it though, I can go into most any copy of vi and get around pretty well (except that the original vi sucked pretty bad compared to vim).
Very sweet, very nice.
--Dan
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.
Gilad.
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.
Weapons of Mass Analysis
Linux has "at" also. I believe it's the UNIX predecessor to the cron daemon. At any rate, IIRC it's very insecure, at least on some systems.
As for GUI vs. CLI, I prefer the CLI for 90% of development work. I came to Linux from Windows, where I used Visual C++ for Windows development and RHIDE for DOS development (DJGPP gcc). I have come to love vim, what with all the pretty colors and all (IMO vim has the best syntax highlighting of any editor. kdevelop is pretty good, but I like vim the best). Makefiles are extremely easy to write (all: \n gcc file.c -o file), and autoconf isn't much harder. I especially like the way I can do "cvs -z3 update" to refresh my source tree. Much faster than navigating through a bunch of menus with the mouse. I use CLI for OpenGL, SDL, framebuffer (libfbx), and CLI development. The only thing I use a graphical IDE for is resource editing, i.e. laying out menus and stuff, but I don't do much standard X11/Windows GUI stuff. I mostly work in OpenGL.
In conclusion, I guess what it all comes down to is how fast you can type more than what application style you're developing. If you suck, GUI is better. If you can type fast (I, for example, can type 140 wpm in a burst, avg. 100+ wpm sustained), the command line is better. Vim rules for fast typists, especially because of its moded interface. If you type slower than 60 or 70 WPM, you need to spend more time away from your mouse and get a typing tutor or something, if you want to be a programmer. I'd hate to code at 40 WPM... I can't stand watching my friend code. He uses an IDE because he types at 50 or so WPM. Whoa! I really strayed from my topic!
--
experience euphoria
After 14 years as a developer, my favorite IDE is X11. I can launch as many GVIM sessions as I need to (syntax highlighting etc., fastest editor - period), I can launch debuggers at will (dbx, gdb, ddd if needed) and have a FULL toolbox at my disposal for anything that might need to be done. There is a web browser or xman for on-line help. Proprietary IDEs feel like a straight jacket to me.
KK4SFV
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.
. .. and you never have to wonder whether they will live after cvs is done with them (projectfiles are really allergic for unix-returns)
- 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.
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.
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.
I write java for a large corporation. We're forced to use NT/2K and the only sanctioned editor is Visual SlickEdit. All I ever use to write any code is GVIM or VIM, whether on the NT desktop or the Solaris servers we use. I find the use of GUI tools as more of a hinderance than a benefit, since the learning curve is usually high in order to understand how to take full advantage of the tool. However, I do like the Borland tools for C++ and OO Pascal (Delphi). I don't write any code for MS Windows, though, so I rarely have any reason to use them. What I'd really like to see, no matter how unreallistic it may be, is a GUI like Delphi but using Perl as the language and having the ability to produce compiled binaries that don't embed the entire interpreter. That would be the ideal tool for me.
"A man talking sense to himself is no madder than a man talking nonsense not to himself."
...and that is, the old make things visible rule. Supposedly, if people have to remember a switch, it is less usable than an application that displays the switch.
My Greasemonkey scripts for Digg &
you can use print in gdb, it's not that horrendous. ddd can also show you structs and so on, but I've not used it on really complex objects.
A question about Visual C++ - I've been using it, and the debugger has it's useful features, but two things have been erking me, and I can't honestly believe that they don't exist.
Firstly, how do you view the contents of an array in Visual C++? I can see the top element (this is using things like CArrays and vectors). And secondly, how the hell do I call a function from the debugger? (I know I could theorectically break it, modify the code, rerun it, then remove the code, and recompile it, but this sounds very very fiddly)
I agree with you completely. The X-Y method for laying out forms is an abomination. It breaks down spectacularly when i18n, l10n, and/or UI customization (e.g. font selection) are introduced. In Windows you can eliminate some of these by designing each dialog separately for each locale -- it works, but... yuck!
.Net. It's very strange and rather sad...
Since Java provides a flexible layout manager mechanism, there are some RAD tools in the Java world that provide dynamic layouts -- JBuilder is one, for example. [Nevertheless, I personally find the RAD generated code to be rather unmaintainable, so I prefer not to use it if I can help it. If you have the proper layout tools, doing it by hand is actually faster and cleaner.]
I find it really hard to understand why MS resists the dynamic layouts idea so much. Even when they copied Java, they omitted this feature in
crappy ideosyncratic syntax cobbled together before the industry ever hear of writing specs, QA or who the fuck is actually using the boxes.
It ain't the geeks. It ain't the dweebs and it ain't people with progidious memory capacity.
Its people who are trying to get something done and having to memorise all this crap (what directory did this make file put the modules into, and why is this called that and who are all the users, real or virtual, with accounts on this machine?)
I end up writing code in Squeak! to work on my Linux box (and my Macs,) because I can FIND the damn code, its ORGANIZED, its EVIDENT and I don't get fuckin' tripped up trying to do things only to be stymied by some idiots lousy sense of spelling or lack of QA or their pathetic punsterish humor.
I'm trying to USE the tools not be a toolsmith but man pages are illegible and explain nothing and every fuckin' dialect and distro seems to think its their God given right to fuck with the directory tree.
I just want to get what I need to happen, to happen. Me and the majority of people stuck with Windows.
Got a problem with that?
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Even a RAD/GUI tool like Borland Delphi (and Kylix) come with a CLI compiler. Without a CLI compiler, you cannot script a release process - but the GUI part is also necessary to deliver development performance. Just like using Emacs to edit C++ files instead of vi.
Lars.
That is not true. I spent a semester studying this phenomena, and as a matter-of-fact everything I raid concluded that the keyboard was faster.
This comes back to what application you are talking about. For a paint program where the user's hand is on the mouse, menus are faster. For a data entry program keyboard input is faster.
There are certain things in Windows NT/2000, you cannot do without the command line - like synchronizing the time via NTP...
Lars.
emacs.
I've found that GUI interfaces can be learned very quickly on Mac, Unix, and MS apps. It's easy because most or all of an apps capabilities are exposed to the user with menus, buttons, checkboxes, form etc. Everything is there to see. A very good GUI will even disallow options if they conflict with other options.
The problem is that once a GUI interface is learned, one is locked into that way of working. What if one wants to script actions that are being done all of the time? What if I want something to happen automatically at threee in the morning? It can also be quicker to bang out small command line or script then it is to drill down through several sets of menus. CLIs are excellent for those of us who can do our jobs in our sleep. Like the parent poster said, an expert cashier does not want an obtuse GUI in the way. Punch THIS set of buttons in order (quickly) done...next...done...next..done.
I love bad analogies so here's one: Most GUIs are like a Honda Goldwing with ALL of the options.....and training wheels attached. I'm thinking of the ones that even have air conditioning and six speaker stereos. A good CLI is like a Harley with a couple of saddlebags at most. A Goldwing with training wheels is definitely easy to learn to ride but which one would you want to take on a curvy two-lane mountain road.
I think the best solution is good GUI frontends to command line tools. Everyone can work the way they want to. Good functionality libraries are excellent as well. XMMS and mpg123 use the same code to play MP3s. I love XMMS on my desktop but mpg123 would be better if I'm trying to roll my own MP3 stereo component.
As it's been pointed out, pretty much all base dev tools are CLI. Most IDE's provide an editor (which really *has* to be GUI), a form editor (which is usually faster than designing forms from scratch, but usually gets tweaked afterward), and a debugger (about as GUI as an editor...). The differentiation between MS tools and old UNIX tools isn't so much GUI vs. CLI, but GUI vs. terminal. The GUI is just a prettier terminal, really. When you realize that, you can stop comparing the tools based on whether or not it has some superficial icons and menus, and compare the *individual tools* for their qualities. I certainly think that Emacs in X is very GUI, and a great IDE. I can accomplish things much faster with Emacs than I ever could with MS VC++.
However, if that doesn't satisfy you... If you're really looking for ammo against the GUI users, then here it is: Microsoft uses Perl, a couple of UNIX tools under DOS, and their CLI compiler to build their software. Does that qualify for "state of the art"?
First of all, it's foolish to automatically dismiss someone's opinion because you say they "like all things microsoft". Get over it. To take it even further and dismiss all GUI based interfaces, just because one of them comes from Microsoft, is completely close minded, and that kind of self-defeating attitude only helps Bill Gates take over the world. Microsoft did not get where they did by pooh-poohing good technology because it was written by somebody the choose to demonize. Second of all, GUI based software development tools have been around for a long time, at least since the 70's. Microsoft did not invent them, therefore Linux Political Correctness does not require you to hate them and reject them out of hand. The Lisp Machines from MIT, Symbolics and Xerox, and Smalltalk and Cedar from Xerox all had extremely rich, well developed graphical programming environments, many years ago. Lisp (and Python) are excellent languages for implementing and programming graphical user interfaces, meta-programming tools and integrated development environments. But C++ (and Perl) absolutely unequivocally sucks as a language design, and that's why Visual C++ and all other C++ development environments are so horribly crippled, brittle, inefficient and useless compared to their counterparts designed more than 20 years ago. It's not the GUI that's the problem, it's the language, which does not lend itself to being efficiently understood or debugged by humans or computers. Remember Saber C? Or Lucid's Emacs based C++ Energize development environment? They failed because of the ill-conceived, ambiguous design of C++, which made the problem of tracking and understanding symbolic debugging information so complex that it was too much for workstations at that time. But now that we have 1.5 Gigahertz processors with gigs more of ram and disk, we can finally run "modern" development environments like Visual C++ just about as fast as the venerable Lisp Machine development environment ran 20 years ago, but it still takes a hell of a lot more effort to understand and debug programs using C++ templates instead of Lisp macros, and it always will. The bottleneck is not in the computer, it's in your mind's capacity to take in, understand and manipulate all that information. C++ (and Perl) spend all of their "complexity pollution credits" on the syntax, and there's none left over for the programmer to apply to solving the problem. So of course the development environments have a hard time communicating and allowing you to manipulate all that information. -Don
Take a look and feel free: http://www.PieMenu.com
My opinion of this is, the ultimate perfect set up between the GUI and the CLI, is one in which the fully functional CLI version is made first; where all of its features are DNA encoded into libraries, not executables; and where the GUI takes the libraries, and implements the features with point and click efficiency.
This, to me, is the perfect way to maintain a harmonious balance between the CLI and the GUI - and the people who prefer one over the other.
--- Grow a pair, liberals... stop letting the Republicans bully you!
Of course, I'm not really much of a programmer, and I haven't worked on any large projects, but I honestly can't see why I would want to go back to GUI based IDEs
Under capitalism man exploits man. Under communism it's the other way around.
I do low-level programming - mostly crypto and mathematics - and GUI-based development tools are pretty much useless, as far as I am concerned. They are intrusive big time, and have a way of constraining your margin of manoeuvering. I used GUI-based debuggers at some point, but I dropped them when I noticed I could do things faster using the command line inside EMACS.
I'm sure that GUI-based development tools are very useful for some applicationss but, for what I do, they are just a hindrance.
As a Windows expert/Linux newbie with some Human Computer Interaction study under my belt, I have to say the CLI has the following features/requirements:
* High information load required for operation.
* Medium levels of feedback given.
* High levels of efficiency.
* Low levels of flexibility.
* High levels of consistency.
GUI (Direct Manipulation) has the following features/requirements:
* Low-Medium information load required for operation.
* High levels of feedback given.
* Low levels of efficiency.
* High levels of flexibility.
* Low levels of consistency.
While these are generalisations, I think CLIs are more powerful for the user who is prepared to learn the syntax, whereas GUIs are ideal for the less experienced user and for prolonged use of the interface.
Most GUI designs are shocking, but they are improving slowly. CLI and GUI have different purposes and different requirements, with a small overlap in between.
"Firstly, how do you view the contents of an array in Visual C++?"
:)
Well, you can write in foo[5] in the watch window.
"And secondly, how the hell do I call a function from the debugger?"
Why would you want to do it while running the app?
I guess I am fairly late into the fray, but if I may add my humble opinion, I think it's in the field of debugging that graphical environments make more of a difference.
Most text editors gives you a way to start a shell command, which often is make or similar. It's all about giving you the tools you need, and my personal taste is that I don't want to know everything about the command line options, I want the gui to give me what I need.
This is probably stupid, but try for a second to 'clear' all the GUI from your reality. For example, try telnet to slashdot, port 80 of course, and 'render' the html code in real time, with your imagination. Now you'll see why for *some* tasks, GUIs are way better suited than CLI.
I code almost 100% in Java with a smattering of Delphi. In the case of Delphi, I cannot see using command-line tools. It would be a mess (though possible). Generally, GUI apps require a GUI to design. otherwise you spend a lot of time fiddling with variouos parameters to get the window to look right. (or you end up with interfaces like those nasty Java 1.1 applets... ICK!)
In the case of java, which for me is mostly server apps. A GUI is not as important I used VIM for 4 years to write java. However, I have since changed to Forte and can confirm that my productivity has increased. I find the GUI IDE to be faster to perform tasks across mulitple files, faster to compile and re-run applications and easier to use than text-based editors.
On the other hand, one has to be careful to not rely on and IDE too much. If you become so attached to a particular IDE such that you cannot debug an app or run a program without it, you become less useful as a programmer, esp. in the open source arena where some things you didn't write just won't work under an IDE. I see this a lot with HTML developers, many of them cannot write HTML, they NEED FrontPage or Visual InterDEV just to work. I see this a serious flaw in their experience.
For me, all my HTML is written in TextPad or Forte. I've found by not relying on IDE tools my code comes out cleaner and smaller. and has less problems with the various different browsers.
Si hoc legere scis nimium eruditionis habes
With X, you get multiple source code windows, the ability to recompile / test by hitting up-arrow, Enteri, etc. All navigation is done with the keyboard so no annoying mouse clicks...
IMHO, normal tools like Make, CVS, Vim / Emacs are VERY productive / easy to use if you take the time to learn them.
You won't have good code or be productive with any language / tool if you don't learn them inside and out.
Frankly, the advantage of being able to make wholesale changes in projects (sourcefiles, makefiles, etc.) with the standard tools available in most linux distributions so far outweighs the "any moron can use me" GUI tools favored by MS clones which require 3,561,992 mouse clicks to open a file....
I was the lead on a fairly large dual Sun / Windows application, and the amount of time dealing with the problems caused by "deeply hidden in a forest of menus" options / settings on VC++ casued the windows side to require twice as much time spent with build management than the UNIX side.
The "quality of life / job satisfaction" working on UNIX code is SOO much better than windows dreck (including better pay), that I find no reason to work on that cruft (windows) anymore.
Apple's Dylan IDE was the only IDE that I've ever used that was both quantitatively and qualitatively better than other IDEs or command line tools. Qualitative because of the amazingly unique features and quantitative because of the immense boost to productivity.
Dylan stored all of your source code in a database and had this completely trippy multipane editor to work in. Grab the pane splitter control on any pane and split one pane into 2. Panes could contain views of a number of different types of data in the database - classes, methods, data members, call graphs, etc. etc. (I think there were about 15 or 16 different pane types) - and any pane could be hooked up to another so that one became the input to the next, i.e. hook a class pane up to a method pane, and hook that up to a source code pane and you get the classic SmallTalk browser. Add and delete panes to your hearts desire and the whole thing becomes nearly infinitely customizable.
Debugging was done in the context of the IDE - set a breakpoint in any of the panes and when the program hits a breakpoint you can edit the source code and recompile on the fly - while the program was running. Essentially you could work for hours and only ever launch the program once if you wanted to.
All other developer tools that I've ever used seem like stone age tools compared to what you could do in that thing..
The sad thing is except for the recompile on the fly thing you could do any of the above with C++ or any other language. Yet we're still stuck with source code stored in clumsy files and the tired edit-compile-debug cycle.
That GUIs do not allow the flexibility of using a language that command lines do. The buttons just don't offer that kind of rich control.
The CLI vs. GUI argument is hollow. The real issue of how well a tool meets the needs of the users (in this case, developers). Good GUI tools have been designed, and good CLI tools abound. But just making a CLI tool a GUI tool does not necessarily improve it in any way, and can make it significantly less powerful.
First, I'll cheat, then offer specific examples. 8-) Just how useful would the *nix "cut" utility be in a GUI form? Answer: not at all! cut is essentially a function, designed for the functional programming environment of the Unix command line. The synergy of applications that can use the command line, be scripted in various manners, and communicate with one another is powerful.
One case study/gripe: At work, our C/C++ vendor's toolset uses the CodeWarrior IDE as the front end for build management. I can now categorically state that as a build tool this IDE is MUCH more limited than good old fashioned Makefiles. When I'm PO'ed at the tools, I often say things like: "great IDE for toys!" These limitations are both functional (e.g. the outright ability to accomplish the desired build structure) or simply awful UI design. It almost seems to have been an IDE not designed or written by people who actually develop software!
Another bit of GUI software: Visual SourceSafe (yes, MS's source control software). VSS' source control model basically sucks, which is why we're transitioning to CVS. Nevertheless, the GUI does have a few good ideas in enabling developers to manipulate and visualize the code database. For this very reason, tools like {Win,Lin}CVS are available to provide a convenient visualization front end. Excluding the source control model, which is better VSS or CVS? CVS wins, because it provides scriptable functionality AND the advantages of GUI-based visualization and interaction. The right tool for the right need.
Having a graphical class-browser for C++ work is truly an incredible time saver. The problem is, if you want to use one, it usually means sacrificing truly incredible editors like vim/emacs for GUI editing widgets that are quite featureless and waste your time. I've yet to see a 'best of both worlds' application.
There's a lot of interest in making a KPart for vim though, so maybe soon we'll have a KDevelop that lets us have the best of both worlds.
The same is true for TCL/TK apps as well, IMHO. I can't guess why other than perhaps because you're using higher-level pre-fab "parts" wich you cannot fine-tune (as easily, at least) the way that you can fine tune C/C++ apps.
I might be wrong about the reason for the similarity; but it's still there (compare tkdesk to any other xfilemanager that you like, and you'll see what I mean.)
Oh, by the way; just to live up to being an AC: go here for a screenshot that illustrates my point. ;)
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.
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.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Have you looked at Qt Designer? It does exactly what I think you're talking about.
I do it in a slow-ish heavily GUI 'toy language' with its own memory management and elaborate, pre-made objects, because there's only so much I _can_ do, and I have goals. There are particular things I want the software to do. I choose a weird interface (very text oriented!) for the program, but within that interface if I need to shuffle the positions of the parameters for high frequency sidechain compression, I want to select pictures of the things and drag them to the new places and build the app and have it run, just like that.
If I decide that the delay lines, measured in feet or millisecond of delay, must have the control's background a shade of gray that relates to how 'far' the echo is, for quick visual appraisal of the state of the app, I want to type in a quick me.color = rgb(255-HowFar, 255-HowFar, 255-HowFar). Yes, to some extent this is OOP- but where do I find the place to type that code? In the environment I'm using, I look at the mocked-up app and doubleclick the box and a code browser pops up, open to the _wrong_ event of the _right_ control. It's not perfect, but it gets me there...
GUI isn't about making Super-Genius-Coding-Man more effective. SGCM is already effective, the closer to the raw words and letters and symbols of code the better. It's all in SGCM's head. GUI is about making _me_ effective.
And if you're SGCM, you are perfectly free to feel totally superior to me, but you know what? I can hardly code, but what I'm trying to do is push the boundaries of digital audio mastering and wordlength reduction, and this is very specialized stuff.
If you are SuperGeniusCodingMan, are you programming something original- or are you strutting because you can use raw C and hand-hacked makefiles to produce... an IRC client? >:)
First off, speaking of GUI, I can't imagine anyone coding anything without a GUI today. Even Emacs or vi have all the characteristics of a GUI, having different graphical elements placed on different parts of the screen and being able to switch the code window's representation by issuing "commands".
From a user's standpoint, the difference between a graphical application run in console mode (like vim, pine, Borland Turbo C ...) and a MS Windows / KDE ... application is mainly the enhanced graphics.
If this discussion is about MS Windows /X Windowing like applications, then I have in the last couple of years had very good experience with IBM's
Visual Age for Java IDE. (I might add that this is the only IDE in a "windowing" environment I have really liked).
This tool is simply amazing when you have gotten the hang of it. The threshold for becoming proficient with it is also relatively low. In my last few projects, we have had many new Java programmers on board. These people became proficient with the tool in just a few hours and after a few weeks, they wondered how they had ever managed using vi / ultraedit, jdb or what not.
The strengths of this particular IDE is not it's ability to do frame composition graphically (a feature I have not seen anyone use anyway), but the overview of the project code and development help it gives you. The debugger for example is simply the best I have seen for any language. Having the ability to modify code on the fly (while executing) simply blew me away the first time I saw it. There are too many things about this IDE which have helped save time to list here. The point was to show that there is at least one "GUI" tool which I have found beats the old text editor compiler/linker debugger combination.
For those of you coding java, I recommend taking a look at VAJ. The standard edition is free for evaluation (with a limit of a thousand classes or something). it's available somewhere here, in the download section.
In the end, saving time and effort is what it's all about in a project. If a tool can help you do that, then it's a good tool, no matter what the tool might be (perl,sed,awk,vi...)
In a society that believes in nothing, fear becomes the only agenda ~ Bill Durodié
Yep, auto-coding. where you mix command line with GUI.
but before that there was the first user interface of the Command line,
then there was the second, the GUI. The GUI was easier to use but more
limited than the Command Line interface.
Then there is the Third user interface, the one that completes the primary
triplet of user interfaces. That interface is the side door port to
applications and other functionality of the OS. The port that the user can
use to tie functionality together, to themselves automate.
In this process of automation, auto-coding comes into play.
http://www.mindspring.com/~timrue/KNMVIC.html
There is also a python start of the function set.
The differences between a CLI and GUI IDE is far from just maybe syntax highlighting. Various GUI IDEs provide tools that are just an incredible convenience to the programmer. For example, Visual C++ 6.0 has Intellisense, which will pop up a tooltip window when you type out a function name which will provide you with the parameters available for each overload. It also will provide a list of methods available for a class when you use the dot operator. In Visual Studio .NET, compilation also occurs in the background, so a compilation error is immediately greeted with a Word-style grammer error underline that will provide a tooltip with the description of the error. On top of all of this, for GUI development, you have various form designers, some which provide prototypes for classes that represent the GUI that you can edit, and some which are fully featured that you can edit between both the graphic designer and the code seemlessly.
Okay, I've droned long enough. Are either of these better? Well, arguably, a GUI IDE that provides contextual aid will decrease the learning curve required (make it easier? blasphemous!) But neither method is inherently better, nor does either method produce better applications. Choose the method best suited to the job, and the method that you will be more productive with.
One thing that vastly annoys me about programmers is that they think that there is only one real way to do anything (which is typically the only way that they know.) They don't realize that development tools and languages are just tools on the toolbelt of programming. I can't imagine programmers of this nature being very productive as, say, carpenters, as they attempt to use a hammer to saw a board in half.
Honestly, will you (or anyone else) please provide a link to such a study?
I use both KDevelop and the command-line tools. I recently switched to KDevelop, and while I find it very convenient and easy to use, I still find myself going back to the command line for some things. KDevelop is easier to use than Emacs, but it isn't as powerful for me as the command-line.
I really like the fact that they added a konsole feature in 2.0...I use that a lot now. I just wish I could do file management in KDevelop too.
"I haven't lost my mind -- it's just backed up on tape somewhere."
So, which is more advanced, a philips-head or a flat-head screwdriver?
Now, if what you want to churn out is high-quality, error-free, maintainable programs, then I'd say it's the CLI tools that are indispensible. If you want to get clever, and invent new tricks no one has tried before for, say, having the code write and test itself (using your own special-purpose table-driven code and test case generators and the like), you're going to have an easy time integrating your brand-new tools and automated build procedures into a good, old, utterly general-purpose make-based build procedure, whereas you're likely to have an arbitrarily hard time integrating it into some hyperfancy all-in-one IDE which, like any graphical tool, makes it slick'n'easy to perform those tasks the tool's designer thought of and designed for, but impossible to do anything else.
I could go on, but since I'm in the middle of reading The Pragmatic Programmer (which is not where I got these ideas, but it presents them well), I'll just refer you to it. See especially section 42, "Ubiquitous Automation".
Don't get me wrong, there are some tasks that IDE's (like any graphical tools) are quite good for. But saying "it is impossible to create 'state of the art' programs with command-line tools" (with the implication that IDE's are infinitely superior) is simply infantile; it's as bogus an argument as claiming that vi is infinitely superior to emacs (or ed). As always, use the right tool for the job, and don't try to claim that one tool or set of tools is either perfect or unequivocably superior to its counterpart from the other side of the tracks.
In Apple's Mac OS X, they include a GUI IDE called Project Builder, which is used for most OS X development out there. However, on close examination, one finds that Project Builder is merely an interface stuck on a slightly modified copy of GCC. It creates its own makefiles which include directives to link against the directives to link against the MacOS libraries, and the executes a gnumake command. So Project Builder is really little more than a spiffed-up text editor (it even 'features' being able to use the same keyboard shortcuts as Emacs) with the ability to execute a few commandline statements. But with it one is able to write anything from OpenGL games to SCSI drivers.
...since VC++ 6 SP5 crashes when I try to debug. MSFT's response? "We've fixed it in VC7, you'll have to upgrade." Yeah, like work is going to upgrade all of us so I can debug. WinDbg it is...tmake and emacs is damn tempting.
I think somebody who says it's "impossible" to create complex, modern software is talking out their ass and has never created complex, modern software...especially nothing on the server-side.
Does http://www.asktog.com/TOI/toi06KeyboardVMouse1.htm ldo any good?
;)
I suspect the results would be different with Windows' less efficient menu system. (Yes, I use windows) And personally, it sometimes takes me a minute to *locate* my mouse, let alone move my hand to it
Actually, http://www.asktog.com/TOI/toi22KeyboardVMouse2.htm l is probably better.
Still not really a *study*...
It obviously comes down to what it always has come down to: personal preference. Vi or Emacs?
Ah, another wx fan :).
I'm guessing you're a fairly recent wxPython convert, otherwise you would have already heard of this, but anyway - wxDesigner will almost certainly fit your needs. The author is one of the primary developers of wxWindows and he sells wxDesigner (quite cheaply - student license US$19, single-user license US$89, 10-user license US$299) as a closed-source extra.
It can be used with C++, Python or Perl code.
Pete.
It is called Visual SlickEdit. All of the functionality is available via command shortcuts and you still have a GUI for those who want to use it. Best of both worlds in my mind.
Silly Rabbit...Sig's are for kids.
You gotta do what you gotta do, based on what the environment is.
(Statement - not a disclaimer: I don't program in Microsoft technology, period. Against my religion).
Back when I actively programmed on a daily basis - Pascal, C, a crapload of REXX (mostly on OS/2 - did an entire site with flatfiles), some C++, some Java; none of my interfaces were "platform-oriented"; even the Pascal stuff was ment to be ported to other platforms. Granted, that was back in the days of the BBS, but if you wanted exposure, you appealed to the masses.
Strange, but my last comment sounds eerily familiar... Perhaps I should of registered it as a trademark. But then, somebody(ies) else already did, it would seem.
Bottom line - in todays' world, it's not HOW you are programming, it's WHO you are trying to present your creation TO! Doesn't matter if it's a flat file RPG query, a Java GUI, or a frickin' DOS batch. If it gets the job done, that's fine. My problem is that most of todays' programs try to comb your hair while petting your cat - oh! you wanted me to perform the REAL function, too? Function is creative as long as it's functional.
I feer too many folx/companies/writers have forgotten/forsaken the meaning in my prior sentence.
I am a huge fan of command line development when it comes to getting down and coding, however there is no CLI substitute for UML modeling. A good model and design is essential to success and maintainability on a large scale, distributed project.
Virtually every form, and most pages, I've built are really dynamic. There are lots of static pieces, but overall it's dynamic. I've done this in C and PHP. One example is http://linuxhomepage.com/ done in PHP on the front end and C on the back end. I'm not sure how anyone would build that using all GUI tools. That's not to say that GUI tools couldn't be used for at least some of it. But being more familiar with CLI tools, I found it easier to build that site originally in half a day using CLI tools alone. And I did it in text console mode (not xterm) switching to X, or my Win98 box, to test the rendition via a few different browsers. You can peek at the PHP source here. I'm thinking out the plans for the next version of the site now, and it will be more dynamic than the first, allowing you to choose your own boxes, number of stories in each, where to lay them out, and maybe even a display theme.
now we need to go OSS in diesel cars
There is a gray area where the benefit of one over the other is not as pronounced as what you happen to have more experience with. If you are equally experienced with both, you'd probably see the gray area as extremely thin. If you are more (or exclusively) experienced with one or the other, you'll probably see the gray area as an extreme case.
One factor, but not the only factor (have to weigh these things carefully, but don't dwell away the day worrying about it) in chosing the tools is to choose what you know best, especially if time is a constraint. But do try to find some time to learn something new occaisionally, or else you'll find your world is made of nails just because you're leet with hammers.
now we need to go OSS in diesel cars
I think the whole question sounds a bit silly, because where do you draw the line between commandline tools and GUI tools?
If I use Glade for designing user interfaces and gEdit as my code editor and compile the program by writing "make" in a console. Am I using commandline or GUI development tools?
What if I use a texteditor with some project management abilities (for example listing of files in a leftside pane) and that automatically runs make when I press a certain button combination and pipes the make output into a window. Is that GUI or commandline based development?
What if we agree that the above mentioned example is GUI based and I simply replace the editor with emacs running from a console? Am I then suddenly running a commandline based environment just because I changed the editor?
As allready stated in other comments, most GUI-based development environments are only wrappers for commandline tools. Both MSVC and KDevelop (to an even greater extent) works that way. Personally I think that KDevelop's solution is great. I can write my project in KDevelop and send it off, with project files and everything, to somebody who only uses make and vi from a commandline and he can still edit the code and compile without a problem.
I guess my point is that commandline based and GUI based development isn't so different. When you get into designing and implementing complex systems (either in group or alone) you will have good use of some tools for helping you with project layout and management that for example automatically keeps your makefiles up-to-date when you add or remove includes and a multi-source editor that easily lets you jump between function call, the functions definition and documentation. Nearly all GUI environments have that built in, but you can also achieve it in a commandline based environment through a smorgasbord of small and specialised utilities.
That said, I still think that too many programmers just goes on working in the environment and with the tools they settled on like 5 years ago without taking any look at the new modern (and mostly GUI based) tools and environments that might be very useful and speed up and simplify their work once they have managed the transition. Personally I think that both KDevelop and MSVC are great integrated development environments and they have turned me into a much more efficient programmer.
Will IBM Visual Age work with development of Java code to be compiled with gcj or some other direct (not class file) compiler? Or is it dependent on the JVM and class files? And will the resultant source package compile on most major UNIX platforms (I'm into distributing the source code and getting tight compiles, not messing around with the JVM environment)?
now we need to go OSS in diesel cars
It allows both the creation of command-line tools, as well as full-blown GUI applications. Borland also has a version of Delphi for Linux, called Kylix, and programs written using Delphi should port seamlessly to Kylix.
Gee, and I thought much of the blame was on so many artists coming from the world of print media (e.g. paper brochure layout) to the web (e.g. electronic brochure layout) and not having a clue about basic concepts of adaptable layout (not dynamic, necessarily, just the ability to adapt to different window sizes, different fonts, different widgets, etc). But it has become clear that much of the blame, if not most, is on the part of the programmers (and more likely their managers) for producing crap that doesn't even have the capability to do the right thing.
I've found many a GUI app that had really good graphical layout, sometimes awesomely cool stuff, and did shit when it came to what the coded logic was. But then again, you shouldn't expect protein and vitamins in candy.
Tell me how well linuxhomepage.com does on your web browser in your preferred window size (as long as it's not itsy bitsy) on your desktop with your fonts and widgets.
now we need to go OSS in diesel cars
Not for me anyway... I find that a single common menu bar is the most annoying part of the MacOS interface since with Windows and indeed Unix apps I can click on the menu bar of any application I have open (and pring it to focus at the same time depending on the window manager, on the mac you have to select the correct widow and then move the mouse to the top of the screen....
If you're writing a GUI, IMO you _need_ a graphical dev tool. You can't create graphical art on the command line. It just doesn't work. So, yes, for writing GUIs, GUI dev tools are a hell of a lot more advanced an neccessary.
But for writing back-end code, I don't think is makes a bit of difference. I'm just as productive with a bunch of rxvts running vim and `gdb -nw` as I am with anything like MS Dev Studio or Borland C++ builder, or anything like that.
The fact that command line tools are `small tools that do one thing and do it well' allow you much more control over what you're trying to do that these large behemoths that try and anticipate your needs and do loads of stuff for you that you don't want to get involved with.
Why doesn't the gene pool have a life guard?
It depends heavily upon the type of development you're doing. Quite simply: if you're creating an end-user application such as a word processor or a game, an IDE like KDevelop is definitely the way to go. The app itself is highly visual, so creating it with visual tools makes sense. More importantly, with most apps, there's just a single program that you're writing and debugging, which the IDE can handle quite neatly.
Server tasks, on the other hand, are an entirely different story. Here you have something that is probably not terribly visual; most of the code runs in a place that the user will never see or have access to. You've got many little helper scripts, processes, client/server applications, processes communicating across many different machines, processes running automatically in the middle of the night - managing all of this with an IDE is probably impossible.
I do both types of programming at my place of employment. The core of our business is a payment gateway, which is hugely complex, and involves dozens of servers spread out across the United States communicating with each other, as well as internally, with a hundred and one small programs passing data off to one another. We do all our work on this part of our business with ssh, bash, vi, Perl, SQL, and occasionally some C.
On the other hand, I've worked on a few end-user applications (point of sale apps, install programs, reporting frontends) and KDevelop is great for them. Designing your widget layout in QDesigner is a breeze, and then integrating that back into your C++ code in KDevelop is drop-down simple. The embedded debugger is wonderful, as well.
Moral of the story: Choose the best tool for the job.
To a large extent what GUI tools, visual application builders etc. do is GENERATE code. This means they allow you to generate a lot of working code quickly, but it WILL be of a particular style, and aimed at a certain problem space. I would say they are better for MOST of the problems we solve but not all. I think it's also probable that they encourage us to write a certain type of application, simply by making it easier to write that type of application.
ALWAYS learn to program using CL tools, but don't be scared to use GUI tools, because they can make life so much easier for run-of-the-mill, bread-and-butter programming.
I realise GUI tools do other things as well as generate code, they often incorporate really useful debugging tools etc. But my argument is that a lot of the productivity increase comes from the code generation aspect.
Never trust a man in a blue trench coat, Never drive a car when you're dead
spend some time writing hundreds of lines of code just to be unable to save the class
Are you kidding? You write hundreds of lines of code before you do a save?
The revolution will NOT be televised.
I've been playing with it for a few days and I'm pretty impressed.
The revolution will NOT be televised.
Though most of the guys here stick with emacs or vi, the rest of the world finds such tools uacceptable, the vast majority of people used to e.g. Visual Studio, will never find themselves workin with those unix development tools. And thats to bad , cause developers are much needed....
Wether the standard unix development tools are better or not matters jack if only a small group of developers want to use them.
What you use to get your job done is probably going to be fastest for you. GUI IDEs can quickly take you to a line in your code where the compiler jumped ship. That's about it. Point and drool has always been point and drool. Case in point: MS builds their OS with command line tools, and not GUIs.
But as soon as you leave the command line and the "garden hose" you revert back to the Multics way of thinking, with GUIDs and all that junk, as opposed to the Unix way of thinking with "tools", and look where that has got us - in a mess that's absolutely no fun to romp around in.
GUIs are fun, but they also consume about 60% of the code. And when you need to get the job done, command lines are the way to go.
Rick Downes
radsoft.net
Check out www.eclipse.org. Or for one supported product using the universal tool platform check out WebSphere Studio Workbench. or the source OTI .
[self contents apply: Disclaimers standard] fork.
Emacs can be invoked as both a GUI and CLI[1] tool, and certainly qualifies as an IDE, even if it is not for everyone.
The answer is pretty simple. Emacs in GUI mode can do everything Emacs in CLI mode, and often has several ways to do stuff that are missing in CLI mode. These alternative ways are sometimes useful, and when not, one just use the CLI way that is still available. So a GUI is preferable to a CLI, given the same basic featureset.
It is as simple as that. The reason some people can make an issue of it, is that they are comparing radically different environments, with radically different features. With Emacs, one can isolate the CLI/GUI factor.
BTW: Some people (often people who haven't used a recent or properly configured Emacs) claim Emacs isn't a "real" GUI tool. Objectively, they are wrong, it uses the native window system and has (at least in some versions) all the features traditionally expected from a GUI tool. However, these relatively new GUI features aren't always fully utilized by the various Emacs subsystems. The advantages of GUI Emacs is only going to grow as these subsystems utilize the new fascilities.
[1] Provided we allow full screen tools like vi, and doesn't restrict CLI to pure line oriented tools like ed.
I was working with VAJ for 6 months, and was terribly happy with it (I compared it with other 3 GUIs before deciding). I think you can get results very fast, and found very useful the incremental compilation.
Afterwards I tried Forte for Java CE. It has the same useful things, if you learn to combine it with ant you can work twice as fast, and - the best - you don't have to wait for as much as 10 months to have the next JVM implemented! It's also more flexible in other ways.
Oh, it also have more bugs than VA and is a bit slower, but it's still worth the pain. By far.
ahhh. That makes life a little easier - I was thinking I might have to repeatedly code useless loops forever.
As regards to functions
Sometimes it's handy to have a function to say, write out important parts of a structure, or to obtain a sanitised structure you might have a function call etc.
gdb (much maligned) can do this, it's very very nice in those respects.
The only thing I would love in emacs from Visual C++ is the Visual Basic style hints anyway.. Is anybody working on this?
In Amipro, it is easy to use, and all the supplied tools are there in the menu. I can see what I get, and so forth. But once I exceed its limits, I need to invest heavily in its macro language or other dodgy fixes. I can not add functionality to its menus.
TeX is a markup compiler. I supply it a source file, and it makes up neatly polished pages. I can add all sorts of tools to the front, and add all sorts of tweaks to it. The interface is really not easy to use, but I can replace the editor, the spell checker, &c.
And come to think of it, most of the unix command line filters and tools were designed to handle specific problems with text data: sort, change, do this, do that ...
How many of these would have come had the IDE always been there? Enough said.
OS/2 - because choice is a terrible thing to waste.
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.
If you're doing a device driver or something that interacts with conditions within the machine without a lot of user interaction then a text editor may be all you need because there's an implicit degree of organization within that environment.
It seems to me that where the GUI can come in handy is in dealing with the human interface. This becomes truer and truer as the interaction becomes more and more meta --that is, as you have to account for more potential courses of action based on user input. If you don't have a development GUI here to help you hold all your conceptual place holders, you're fighting against yourself and will probably become frustrated with your work or develop your own GUI to save your project. Gee, maybe that's where these IDEs come from.
So, the question is weak as usual, hardly more than flame bait. Meaningless debates about which is BETTER just get the kids all excited and start a few pissin contests at best. After all, most GUI dev tools have command line interfaces built in, so the distinction only appears clear to those who don't know any better.
Very nice to read the comments!
I think that the best is learning everybody that behind the GUI world there is something else. Here in Europe new developers know a lot about GUIs (generally ONLY one). They can do a lot of amaying things usings tricks with them. Very impressive. The Drawbacks is when the have to use an other GUI, or even have to use a different tool they are not used to (Tuxedo, MSQueries,...) Usually we have to spend a lot of time with them teaching the "real world"!
I think that the best is learning everybody that behind the GUI world there is something else. Here in Europe new developers know a lot about GUIs (generally ONLY one). They can do a lot of amaying things usings tricks with them. Very impressive.
The Drawbacks is when the have to use an other GUI, or even have to use a different tool they are not used to (Tuxedo, MSQueries,...)
Usually we have to spend a lot of time with them teaching the "real world"!
But what is funny is that after some times, we observe GUI gurus begining to use CLI. I think one should know about the both world: know how to use a GUI efficiently (I mean with kb shortcuts), and know how to use the CLI ofr automated tasks and other tricks.
As sayed previously by other:
Try to imagine an automated world only with a GUI...
Try to imagine to pipe commands in a GUI world
Try to imagine to put all the possible commands in the GUI of vi/XEmacs
On the other hand:
Try to imagine teaching the tricks of a grep piped with find to newbies
I feel that GUI are good for intrductions, but evry body should know (learn) about the CLI world.
MS-DOS, for example, has a CLI, but is not an IDE. But while I can't think of any "GUI" that is an IDE, UNIX, which is CLI-based, is indeed an IDE.
Now, I don't think of UNIX (e.g. Linux) as an ideal, out-of-the-box IDE, but it certainly includes the low-level functions necessary to make it into one, as well as some high-level functions.
Certain things that a good IDE would offer programmers happen to map better to the modern ideal of a GUI than to the modern ideal of a CLI.
For example, picking something from a displayed list is, in a typical GUI, a fairly natural thing to do, but not in a CLI.
That is, when you "open" a directory/folder in a GUI, you not only see what is presently there, you can directly select an item for some other action.
Whereas, with CLI's, it's generally assumed that when you enter the "ls" (or "dir") command, what you want is just a scroll-style listing of a snapshot of what is in the directory you've just "opened".
There's no inherent reason a selection couldn't be made directly from that command's output, or that the output itself couldn't be made dynamic (change as the directory contents changes a la MacOS)...
But with the GUI, there's not an obvious way to automate a use of such a viewing, since the rendering is done at such a low level (bitmapped graphics), and since we don't have commonly accepted models, or interactions, for directing such a viewing to be used in some different fashion (e.g. don't display it, pipe it into the GUI equivalent of 'grep' instead), the designers of what could be a conceptually simple function had to make it more complex, by having the display be "live", that is, somewhat real-time and directly manipulatable (is that a word?) by the user.
Whereas, with the CLI, especially a UNIX-like one (which even MS-DOS somewhat copied, unlike some other early DOS-like systems), it's built in that, if a selection is desired, the output of 'ls' can be piped into some selector script; or, if dynamic update is desired, the command can be automatically re-run every few seconds; and so on.
Personally, though "infected" with the delightful experience of having developed a smallish C app using Think C on the Mac around 10-12 years ago, I don't generally look forward to using GUI-based systems to develop code.
Chief among the reasons is the fact that the quality and flexibility of GUI-based apps tends to be noticeably lower than than of CLI-based apps. And I can't have my IDE (however I effectively "define" it via usage) crashing or misbehaving on me while I do my work.
E.g. I'm currently, on this particular notebook, getting "Error saving bookmarks file!" dialogs from Netscape (RH Linux 7.1), though I have no idea why, because there's no error code, no diagnostic message, and endless mucking with bookmark "open", "import", and "save as" menu items doesn't fix anything. (So each time I start up Netscape, I have to manually import my real bookmarks, and must save them manually whenever I add new ones.)
With a CLI, this kind of stupid bug might well be less likely, because instead of mucking about writing code to create a dialog box, a simple "fprintf (stderr, ...);" might do, in which case the programmer might have bothered actually reporting the error code, maybe even the corresponding diagnostic message, file name, etc.
That's just one trivial example of the general impression I have, namely, that GUI-based systems are inherently more complex, larger (in terms of memory usage), monolithic, and persistent (hang around when you don't want them to, e.g. when benchmarking or profiling) than their CLI-based counterparts.
Further, I find GUI-based systems tend to be "behind the curve" with respect to CLI-based ones. Journaling or even periodically saving to a temp file of an edit buffer in case of system/app crash? That's been in various versions of Emacs (admittedly a bit of a cross between a CLI and a GUI, but it isn't mouse-dependent after all) for what seems like decades, but, sheesh, Netscape 4.x still doesn't do that for this "comment" box it lets me type this stuff into! (I've lost a few comments-in-progress that way.)
So, aside from not having some state-of-the-art capabilities CLI's tend to, especially those relating to robustness and recoverability, GUI's tend to be less stable, crash more often, etc. (That is, I've lost more "work" due to Netscape crashes than I've ever had to recover due to Emacs crashes. I've been using Emacs variants for some 20 years now, Netscape for maybe two, and pretty much all I've used Netscape for in this sense is entering /. comments.)
Okay, maybe I shouldn't pick on Netscape, since "everyone knows it's buggy", but isn't it somewhat illustrative that one of the most popular, smash-hit GUI-based apps of the 20th century still, in 2001, can't avoid crashing, won't automatically journal edited text, and so on?
(And, yes, I've used IE, it's more stable, until it crashes, which, though comparatively rare, tends to crash the whole Windows environment...another effect of the tightly-integrated-GUI syndrome, as far as I can tell.)
So GUI-based systems are prettier and let me do some things that are awkward under vanilla CLI's, but, for "real work", they're just too much more complicated, less flexible, less robust, and, by the way, less portable than CLI's, and that looks like it'll be the case for at least another 10 years. So while it's nice, in theory, to use an IDE that already has a button, dialog box, or menu item for every combination of two or three CLI-based commands, that doesn't make up for the losses in other areas. After all, if I really want those buttons, I can "bind" function and other keys to each of those combinations myself, in that CLI. And I can easily write other "special" items (scripts and such) to do things like dynamic display of arbitrary text, offer CLI-based selection of arbitrary items in a displayed list, and so on. These binding and scripts might have bugs, of course, but if they crash, they aren't likely to render inoperable the rest of "my" IDE. And when they're not actually in use, they won't necessarily take up system memory and time the way a typical GUI-based IDE does.
Ideally, both CLI and GUI would be so well-designed that there'd be little difference. (E.g. an "echo $?" might make sense in the context of a CLI-based Netscape-like browser, to at least see the error status of trying to save bookmarks -- maybe that'd be a distinct process running in its own subshell, a sort of mini-daemon.)
So, to me, the ability to use the mouse to point, click, draw, drag, and pop up is wonderful, but, given that I currently can't choose both simultaneously without greatly increasing complexity (what I have to memorize plus the complexity, including crashability and likely bugginess, of the software on which I'm depending), and that the features today's CLI's offer are critical, I'm not likely to commit to learning any GUI-based IDE in the near future.
(Naturally, I've been thinking about how to best design "the ultimate CLI" upon which an IDE might be more ideally built, ditto for "the ultimate GUI", and, naturally, it'd be great if the system could be so well-engineered that most of it didn't care whether the interface being used at a given moment was a CLI, a GUI, or some arbitrary interface, such as one designed for use by the blind. But I've been dreaming about all that for well over 10 years now, and about the CLI part of it, well, ever since first using ITS back in the mid-'70s, so it's unlikely I'll actually design my own IDE to replace Unix, whether CLI- or GUI-based, anytime soon. I've got some pretty cool ideas, though! ;-)
Practice random senselessness and act kind of beautiful.
The other posters have noted scripting languages. You should also look at winbatch, its more a GUI solution to a GUI problem. Basically its like an advanced macro recorder. I think it also has a script language you can use. You can just tell it to record and then do stuff in the GUI and it will capture the events for repeated playback. VC++ also has this type of stuff built in to a certain extent as long as you stay in VC.
Of, course you still have to do real work! lol. I can't really imagine to many project though where a significant part of the GUI couldn't be handed by something like Borland C++ Builder. In the more recent version of BCB they have a Tframe component that removed nearly all my dependence on hand coded GUI components. There are just so many component libraries available that you can buy a component for just about any GUI widget behavior that can be thought of. About the only time I have to hand code a GUI anymore is for complex graphical rendering. Which is the real part of the application anyway. I can believe though with MFC you ended up recoding everything because its a beast and no one I know has ever managed to write much of their application using it. When the GUI's get more complicated than dialog boxes with push buttons MFC blows.
I had a friend though that ended up writing massive amounts of GUI code because he refused to write a table link or ODBC front-end to his proprietary database. In the end he just ended up rewriting nearly all the database management components included with delphi just to save a two or three day leaning curve to learn how to interface his database to the existing components. Some things cannot be forgiven... lol
Everyone seems to be failing to make a distinction between loosely coupled development environments and IDE's vs GUI's and CLI's. Probably because most of the IDE's are GUI.
Frankly the GUI/CLI argument is an old one. I think the answer is more a case of personal preference and what kind of job is being done. Modern GUI's, macro recorders and script languages are as powerful a method of expression as CLI's with their multitude of scripting languages.
IDE's vs Loosely coupled should be a no brainier. Its a lot nicer to be able to use a single environment that is tied together. A lot of people are arguing their emacs->make->gdb configuration is better than the assorted IDE's listed. In truth they are just reinventing the wheel with a group of CLI tools. Instead of accepting a pre packaged IDE sitting on top of command line tools like VC++ they are creating their own IDE using their favorite editor and a bunch of scripts. At that point its pretty much a no brainier that a custom environment designed for their particular project is better. Of course it probably took them three weeks to build a bunch of scripts to tie their resource editor, text editor, code browser, object browser, compiler, debugger, profiler, source control, packaging, etc tools together in a manner that is functional.
So, the real question should have been is it better to use a prebuilt IDE or build your own? The answer to this is probably that it depends on the person. Personally I prefer using VC++ but I also have a large collection of scripts that I load into Xemacs when I'm using a Unix environment that allows me to things like checkout the current module from source control and check everything back in with a keystroke, or build the project and highlight any errors in a widow smart enough to open the offending modules so that I can edit the source line with a keystroke or two. I like to use a nice source browser that allows me to instantly open a new window and go to the module where the function I'm looking at is declared. All of these things require and IDE to be optimal, its just VC++ is preconfigured and I have to remember F12 is 'goto reference' and F7 is build (unless I change the keybindings). While I have about 2k worth of scripts I wrote to do it in emacs.
So what exactly was the point again?
The GUI vs command line argument has raged on all fronts for years. And the gist of those arguments, including personal feelings, are telling. The proper choice depends on the user context.
In essence, I'd say the GUI vs command line debate reduces to an internal evaluation of just how important are the tradeoffs between:
- control
- convenience
where by "control" I'm referring to the command line flexibility that allows you to twiddle a Makefile so that one particular source file gets compiled with a special set of DEFINES and INCLUDE directory path specifications and compiler optimization levels. And that's without having to learn some IDE's Preference sub-sub-sub menu navigation in order to accomplish the task.Convenience is chosen when I'm willing to suffer some loss of control for the sake of rolling faster through a typical development cycle of automatically popping up to the next error, etc. An IDE is great for this kind of work (even IDE's in disguise like emacs with compile, grep and gdb modes.)
Another poster had the right idea suggesting that command line and GUI should be interconvertible. Ideally, the IDEs should be able to let you wander out of the loop as you wish without having to climb and IDE-specific learning curve to do so.
Interconvertability is especially important because software development projects move through different phases, where either approach may be appropriate to the task at hand and the user that is doing the task. (Eg, setting up automated regression tests, etc.)
"Provided by the management for your protection."
However, take Together, from togethersoft.com. Sure, this wraps the java compilers, but its hardly just that. It does what only GUIs can do: talk to my visual brain in things it can understand. Literally, it augments my thinking, by doing what my brain cant: converting textual code into visual representations.
One day, all development tools will be this way.
AutoCAD is a very good example of how to ingegrate both CLI and GUI. You can either type the commands or point and click on them in some toolbar or menu. Usually you learn the CLI variants of the commands after you have used it for a while. It would be nice if more applications worked like this. The problem is to make it logical enough (this maybe would not work that good in a word processor). The GUI versions of Emacs and VI should be good examples too.
A colleague and I had a long debate on this topic. We both used to be Mac users/developers. He now uses Windows and Visual C++. I'm using Linux, vi, g++, etc. more these days.
In the end, we had to agree that both GUI development tools and CLI development tools are about equal when you consider everything. For everything the GUI does well, there's a CLI alternative. For everything the CLI does well, there's a GUI alternative.
He can't type, and even if he ever does Linux development, he's going to need a GUI environment to be productive. I, on the other hand, find myself more productive in a CLI environment.
Were you using the C++ Builder IDE to do this? If so, and if the IDE behaves like Delphi's (which I think it does), then maybe you haven't checked out the "View Project Source" menu option? (Under the 'View' or 'Project' menu; in Delphi, it's been moved around between them.) If you use *that* file, and not the "Main" one, then it'll work, I think.
Hope this helps! If not, mail me -- the address is slightly munged, but I'm sure you can figure it out.
[*]: From a Charlie Calvert book, IIRC; should also be available on his Web site. Basically, it was a straight translation into (Object-, but without using any OO) Pascal syntax of Petzold's / Schildt's C "Hello World" programs, with winMain and message loop and resource file and whatnot. (And you work that way all the time? VOLUNTARILY??? Well, it takes all sorts, I guess...
Christian R. Conrad
mail me at iki.fi ; same user ID as here
Whether global at the top of the screen, or one-per-window, menu bars are a really horrible idea.
They take up screen space all the time, and you have to go away from the place where you are working (the window contents) to go and look for the command you want.
I prefer context menus every time, even (maybe especially) for my root window, rather than a task bar and "start menu" arrangement borrowed from Windows.
The only justification for menu bars is as a reminder for newbies that there are menus. People not used to clicking the right mouse button to get a menu might otherwise assume your application doesn't do much.
-- What do you need?
-- Gnus. Lots of Gnus.