Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Are GUI Dev Tools More Advanced than CLI Counterparts?

Cliff posted more than 13 years ago | from the gui-snobbishness-begone dept.

Programming 501

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

Sorry! There are no comments related to the filter you selected.

Neither (3, Insightful)

Biff Grande (267473) | more than 13 years ago | (#2267566)

I don't think either is really more powerful. It is just a matter of personal preference. A GUI tool might help to visualize your application's structure, but that is about it.

Re:Neither (-1, Troll)

Anonymous Coward | more than 13 years ago | (#2267603)

A study amongst psychologists has determined that any given task is far easier and more productive when done with a GUI [] vs it's command line counterpart. The gravitation towards the contemporary GUI isn't an accident. Anyone who tells you otherwise is just an elitist.

Re:Neither (2)

daviddennis (10926) | more than 13 years ago | (#2267742)

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


Re:Neither (-1)

robsmama (416178) | more than 13 years ago | (#2267805)

Thanks for the report. I now have much deeper and broader understanding of the difference between CLI and GUI. I personally think thatm I'll stick with the GUI though, because that can always be scripted with macros. Take outlook for example, it has one of the most powerfull macrolanguage of any application. That think can basically control every aspect of the comp. It's truely a work of art.



Katy! (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2267568)

I want to marry you! We can do calculus together!

23234 (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2267569)


I believe you're correct. (2, Interesting)

W1BMW (462297) | more than 13 years ago | (#2267573)

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.

Square peg in a square hole (0, Troll)

DahGhostfacedFiddlah (470393) | more than 13 years ago | (#2267576)

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.

Stephen King, author, dead at 54 (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2267585)

I just heard some sad news on talk radio - Horror/Sci Fi writer Stephen King was found dead in his Maine home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to popular culture. Truly an American icon.

GUI-CLI? Where's Emacs? (2, Interesting)

jmerelo (216716) | more than 13 years ago | (#2267591)

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

Your choice (1)

WildBeast (189336) | more than 13 years ago | (#2267593)

Personnally, I'm not confortable working with a GUI dev tool, I find it complicated, but that's just me.

GUI cvs Command (5, Insightful)

OmegaDan (101255) | more than 13 years ago | (#2267596)

GUI apps are impossible to automate, run from crond, pipe information in and out of ... this is why they will always be needed in unix, this is why they ARE needed in widnows ...

Window's answer to crond is every program that needs to schedule something includes its own task bar scheduler that eats 5 megs of ram. And you'll notice those programs execute command lines as well (ie. nav /scanall), because a command line interface is the *ONLY* conveniant way for one program to manipulate another.

Re:GUI cvs Command (0)

Anonymous Coward | more than 13 years ago | (#2267639)

Windows' answer to Crond is the Scheduled Tasks folder. It's not Microsoft's fault that nobody uses it. Unix programs could install their own daemons to do scheduling, but they don't because Crond is accepted. Given time, app developers will probably accept Scheduled Tasks.

Re:GUI cvs Command (1)

OmegaDan (101255) | more than 13 years ago | (#2267661)

The reason its not accepted was because it wasn't there in the first version of windows 95 ... so if you want people to be able to use your app on win95 you still have to install your own scheduler ...

Re:GUI cvs Command (2)

sjames (1099) | more than 13 years ago | (#2267749)

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

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

Re:GUI cvs Command where it's AT (1)

simetra (155655) | more than 13 years ago | (#2267791)

Actually NT has the "at" stuff... equivalent of cron. Oddly enough, my MCSE friend has never heard of it.

Re:GUI cvs Command (0)

Anonymous Coward | more than 13 years ago | (#2267702)

GUI apps are impossible to automate

Have you ever heard of COM automation?

Don't get me wrong, the in/out stream metaphor and piping are very useful and all... but there are alternatives.

Re:GUI cvs Command (3, Insightful)

keesh (202812) | more than 13 years ago | (#2267717)

Seen what you get with Delphi (and Kylix for that matter)? There's the nice cute GUI, sure, but you still get commandline compilers, resource builders, linkers and so on as separate apps. You can, of course, pipe and so on...

This gives you the best of both worlds -- use the GUI when you want to design interfaces, ignore the gui and just stick to the commandline tools when you want automation.

Borland's C++Builder also has separate commandline tools (and pretty primitive grep and make...) (which, incidentally, are free for download [] but not quite Free).

GUI is not mutually exclusive to automation! (0)

Anonymous Coward | more than 13 years ago | (#2267770)

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.

Re:GUI is not mutually exclusive to automation! (0)

Anonymous Coward | more than 13 years ago | (#2267803)

I say give me a +4 insightful lip lock on my anal ring and suck hot steaming fecal sludge across your tounge down your throat.

That's what I say.

Re:GUI cvs Command (1, Insightful)

Ummite (195748) | more than 13 years ago | (#2267776)

Automation, DDE, pipe DCOM interface, anything else you want to do?

I'm still using command prompt in windows 2000, and using it since dos 2.0. I don't say it's perfect using automation, dde or any other technology, but DOS is not the perfect way to communicate either. It's ALWAYS a summation of considerations that will tell you wich technology use, not simply "it's the best, let's use it"...

cli (1)

Lord Omlette (124579) | more than 13 years ago | (#2267598)

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)

Can we mod the original post down? (0, Offtopic)

Bistronaut (267467) | more than 13 years ago | (#2267628)

-1 Flaimbait, I say.

Re:Can we mod the original post down? (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2267641)

I say give me a +3 lip lock on my anal ring and suck hot steaming fecal sludge across your tounge down your throat.

That's what I say.

GUI (1, Insightful)

Anonymous Coward | more than 13 years ago | (#2267602)

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.

Does it matter? (0)

Anonymous Coward | more than 13 years ago | (#2267607)

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.

Re:Does it matter? (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2267630)

Personally I find it easier to stick my dick in your mom's ass than her vadge. I enjoy the stimulation and other things she does with her anal muscles. As far as the risk of contracting STDs such as AIDS, herpes, etc, it is worth the risk for such hot action. One thing I am very fond of is giving her a facial cumming and her spreading it all over her DD tits. I just make cumming better.

Text Editors (1)

Captain Pooh (177885) | more than 13 years ago | (#2267608)

I'm fine using text editors to write code especially now since it adds color to your code yeee.

What about a voice-oriented development tool? (1)

frleong (241095) | more than 13 years ago | (#2267616)

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!

Re:What about a voice-oriented development tool? (-1, Flamebait)

Anonymous Coward | more than 13 years ago | (#2267655)

Man, you are a real fucking sad loser.

Re:What about a voice-oriented development tool? (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2267683)

Did you know Captain Kirk was a nigger lover?

Nothing is 100% better than any other tool!

You are wrong because a nigger with a shovel does about 100% less work than a white with a shovel. Or any other tool.

It depends on your preference... (0)

Anonymous Coward | more than 13 years ago | (#2267618)

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.

Re:It depends on your preference... (1)

Quasar1999 (520073) | more than 13 years ago | (#2267710)

What? Good programming is about writing GOOD CODE! Whether or not I choose to remember all the command line switches, or if I entrust a GUI to do it for me, the GUI isn't going to write my code for me... it is simply a tool to help the build process, much like a batch file... do you call people who use a batch file pansy too?

Thing is.... (1, Informative)

MxTxL (307166) | more than 13 years ago | (#2267620)

You can do anything with command line that you can do with GUI. BUT, with CLI or line by line programming you can't design other GUIs as nicely. You can still do it, piece of cake... but to make a really good GUI with standard programming, takes a LOT of time and a LOT of effort. With a tool like Visual Basic(ugh! VB sucks!) your GUIs and forms are easy to design and manipulate. You can make the same forms and GUIs with C++ or Java but it will take you longer, it's much harder to do complex things and lots of times your design will LOOK awkward.

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.

Re:Thing is.... (OT) (1)

uchian (454825) | more than 13 years ago | (#2267712)

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.

Re:Thing is.... (0)

Anonymous Coward | more than 13 years ago | (#2267721)

VB as a language may suck, but don't forget that VBX was the first viable component market, components rock; COM, EJB, CCM etc.

The Hell, You Say... (2)

Greyfox (87712) | more than 13 years ago | (#2267723)

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

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

Re:Thing is.... (2, Insightful)

mughi (32874) | more than 13 years ago | (#2267777)

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

Well, since you use "You", I can answer directly that you are incorrect. I personally can whip out Java GUI apps much more quickly and with much better functionality than with using a GUI tool to do so. For many other people it's the same. Especially with Java and it's layout managers, your GUI is much more that "stick a button this big over here". It's quite easy to program a UI that will scale up to the needed component sizes, even if you change the language on the fly (or just on startup). On the other hand, internationalization is a pain in VB and such.

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

Again, for me I personally can make professionall looking UI's quite quickly in Java with pure code. Plus my code is smaller, faster, and has fewer bugs. And as far as complex, when was the last time you had a UI change from English to French or Japanese with no problems at all?

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

Actually.... I could. Depending on the subject matter, for many 3D models I can get something nicer done more quickly by 'coding' it directly in POV-Ray [] script. This of course depends on the subject matter, but just because one person finds one way faster doesn't mean that another person won't be faster a different way. Just sometimes I'd go with 3DS or Strata, other's I'd just code by hand. And sometimes I'd write a custom C program to make the model. It just all depends.

And just in case it's a factor, I've programmed multimedia products before for many platforms, and have done 3D artist work for Interplay.

hrmph. (2)

egomaniac (105476) | more than 13 years ago | (#2267622)

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

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

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

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

Re:hrmph. (2)

sbeitzel (33479) | more than 13 years ago | (#2267744)

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

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

I'd say it depends on how people think. (2)

daviddennis (10926) | more than 13 years ago | (#2267795)

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.


say no more (-1, Troll)

Anonymous Coward | more than 13 years ago | (#2267633)

> I just got into quite a long argument over on the Yahoo! message boards

Or you could have also said: I am a complete lamer who hangs out on yahoo boards and aol chatrooms instead of coding something worthwhile

Ummm... (1)

Purple_Walrus (457070) | more than 13 years ago | (#2267634)

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?

When They Started (1)

mbrod (19122) | more than 13 years ago | (#2267635)

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.

Interesting Question. (1)

ledow (319597) | more than 13 years ago | (#2267636)

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

Ask Slashdot: Who Cares? (0, Offtopic)

bk1e (176877) | more than 13 years ago | (#2267638)

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.

old addage (1)

arakis (315989) | more than 13 years ago | (#2267640)

a poor programmer always blames his tools

The IDE's just wrap command line tools still (3, Interesting)

joshtimmons (241649) | more than 13 years ago | (#2267643)

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.

GUI tools help debugging (1)

CrimsonHat (245444) | more than 13 years ago | (#2267646)

To a good extent, it probably is a matter of personal preference if you like to do most of your development at the command line or not. However, I love IDEs for their ability to debug in the same environment that I'm writing code in. I also prefer an IDE so I don't have to type so damn much at the command line. As if my coding doesn't kill my hands enough as it is.

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.

Seriously (1)

spankfish (167192) | more than 13 years ago | (#2267647)

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.

Same old stuff (1)

Microsift (223381) | more than 13 years ago | (#2267648)

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.

Depends... (1)

mberman (93546) | more than 13 years ago | (#2267651)

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

Know any good Win32 CLI C++ compilers? (2)

Katravax (21568) | more than 13 years ago | (#2267653)

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

Re:Know any good Win32 CLI C++ compilers? (2, Informative)

Gottjager (17214) | more than 13 years ago | (#2267685)

Win32 ported gcc that has all the win32 headers and compiles win32 native binaries that don't require additional DLLs to run anywhere (like Cygwin).

Also makes it easy to compile linux/unix sources on win32 with ususally slight modifications (esp. socket code) but not as easy as Cygwin is for porting.

Re:Know any good Win32 CLI C++ compilers? (2)

BitwizeGHC (145393) | more than 13 years ago | (#2267727)

Re:Know any good Win32 CLI C++ compilers? (2)

keesh (202812) | more than 13 years ago | (#2267735)

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

Re:Know any good Win32 CLI C++ compilers? (0)

Anonymous Coward | more than 13 years ago | (#2267743)

you will be much happier with cygwin than mingwn...

its basically a bash shell in windows that has almost everything you would want from a linux console(gcc, ld, gdb, and the list continues)....hell you can even run ddd out of it(you have to install the xwindows stuff and recompile it but it DOES work)

Re:Know any good Win32 CLI C++ compilers? (1)

psykocrime (61037) | more than 13 years ago | (#2267748)

You might check the Watcom compiler. I think it can be used from the command line. And, as a bonus, they're in the process of open-sourcing it.

There are some other C++ compilers for Windows as well, or at least there used to be. I'm just having trouble remembering their names. Ummmm. Microsoft, Borland, Watcom, Metaware, Oh, yeah.. Metaware. I think they make a product called High C++ that might be of interest too ya.

And what about good ole GCC? Isn't there a port to Windows that supports the M$ includes and libraries? I thought that I read once that there was.

Re:Know any good Win32 CLI C++ compilers? (0)

Anonymous Coward | more than 13 years ago | (#2267774)

Check out Free C/C++ compiler, based on the venerable Zortech and Symantec systems I think.

Re:Know any good Win32 CLI C++ compilers? (1)

Shoeboy (16224) | more than 13 years ago | (#2267807)

Um, last time I checked, VC++ was a command line utility. It's called cl.exe and works perfectly well from within a console window. The version of make for it is nmake.exe. There are countless examples of how to use MS VC++ from the command line.

Of course, there's always Borland, but you don't seem to like them.

The next option is GCC which you can get as part of cygwin32 and can produce native win32 binaries without linking to the cygwin libraries. The drawback is that you don't have the Win32 headers files as there were licensing issues. The work around was to write their own win32 headers.

Finally, the intel compiler doesn't ship with microsofts headers either. Intel assumes that you already have vc++.

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


What exactly is "CLI" and what is "GUI"? (1)

mughi (32874) | more than 13 years ago | (#2267654)

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.

It Depends on the Team (3, Insightful)

quakeaddict (94195) | more than 13 years ago | (#2267658)

Lets face it some people like to click buttons that are poorly documented and others like command line switches that are poorly documented. :)

At some point someone is in charge of the builds, and whatever that person likes we all get. If that person does their job right its easy regardless of what your preference is.

One thing is for certain, it doesn't make sense anymore to build GUI's without the help of a drawing tool that automates that tediousness.

Command line really becomes complex (1)

kanishka (194086) | more than 13 years ago | (#2267670)

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

GUI's don't do very much (1)

uchian (454825) | more than 13 years ago | (#2267673)

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

Just likes OSes (0)

Anonymous Coward | more than 13 years ago | (#2267675)

Use whichever development environment makes you the most productive (which is probably the environment you're most comfortable and familiar with).

Keeping it simple? (1)

DrkOvrLrd (520071) | more than 13 years ago | (#2267677)

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.

A Variety of Programs vs. the SuperApp of Doom (1)

khog (146409) | more than 13 years ago | (#2267680)

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.


Depends on what you want them for (5, Insightful)

samael (12612) | more than 13 years ago | (#2267681)

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.

Programming Style (0)

Anonymous Coward | more than 13 years ago | (#2267684)

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.

GUI vs. CLI (1)

SirKron (112214) | more than 13 years ago | (#2267689)

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.

Re:GUI vs. CLI (-1, Flamebait)

Anonymous Coward | more than 13 years ago | (#2267789)

Here is what you tell your wife: "Shut up you stupid fucking whore and suck my dick! You fucking ugly bitch! Eat my cum!"

At least that's what I tell her, and it works fine.

Personal preference (1)

jchristopher (198929) | more than 13 years ago | (#2267690)

Whichever development environment you are most comfortable with will be the most efficient for you - regardless of whether it is CLI or GUI.

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.

How much is your time worth? (1)

Henry V .009 (518000) | more than 13 years ago | (#2267695)

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.

GUI Tools (2, Insightful)

EarTrumpet (85772) | more than 13 years ago | (#2267701)

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

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

The much-maligned command line (3, Insightful)

Xpilot (117961) | more than 13 years ago | (#2267706)

I've observed something over the years, and that is the command line is hated beyond measure by mainstream trade press and MS fans. For MS, removal of DOS was a good thing because it removed the command line, which is evil (DOS sucks,of course, but not because of its command line interface).

I've been using a CLI to program and generally do OS stuff for years and years, and I've found some Windows-lovers attitudes more than just a bit annoying.

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

I hear comments like that a lot. From CS undergrads too. What brought about this attitude? I put the blame squarely on MS. Even Apple has a decent CLI shell now with OS X. MS is so busy harping its wonderful pointy clicky interface and the clueless world follows suit.

UNIX will always exist, but Windows runs the IT world. At least where I live.

Revision Control (2, Insightful)

TornSheetMetal (411584) | more than 13 years ago | (#2267708)

Assuming you are doing some form of Revision Control (which you should be ;) ), I find it most important to have the revision control system built into the editor I'm using. I also want a difference engine built into the editor that works with the revision control system. Emacs and Xemacs has these features among other full IDEs. It is useful to look at the differences between your current code and code that has been checked in, in a graphical manner so that the differences are within context. Command line diffs remove the context

It's also nice to have color highlighting of code and smart indention. This can help you know if you spelled things, forgot a ";". A nice feature that some IDE's have which I haven't seen implemented in emacs yet (which I'm sure is possible), is the ability to know the current valid function names and variables and highlight them appropriately.

Irrelevant. (2)

rjh (40933) | more than 13 years ago | (#2267711)

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.

GUI's are easy to learn, but never efficient. (5, Insightful)

MongooseCN (139203) | more than 13 years ago | (#2267713)

GUI's are easier to learn because all the options are laid out in front of you. You can click through menus and scroll bars and see all the options available. This makes it very easy to learn. Eventually though you will know all the capabilities of your editor, but you will still have to click and move through menus and graphics to get to what you want.

CLI tools are the opposite. They are hard to learn, but once you know them, they are fast and efficient. Vim is a perfect example of this. The editor is simply amazing. It has a keyboard interface to do nearly anything you want to do. The only problem is, it's very very difficult to learn. You don't know what all your options are. You have to goto :help and start searching for something simliar to what you want to do. But once you know the basic commands, it becomes easy to find other commands for something you want to do.

Here's a nice cryptic example. What's a fast way to find the include file for a function? Browsing through help files, searching for the command and cutting and pasting the include in? Or this:
:r! man ntohl | grep "\#include"
Ya, I thought so too. =)

What about Slashcode? (0)

Anonymous Coward | more than 13 years ago | (#2267716)

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'!"

The BEST interface (0)

Anonymous Coward | more than 13 years ago | (#2267730)

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 .Net strategy - namely, pay per use. It costs $10 per computation, or 15 minutes, whichever comes first.

poop chute = 1
pee hole = 0

GUI is terrible for less skilled programmers (2)

ColGraff (454761) | more than 13 years ago | (#2267738)

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

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

English to E Translator (5, Funny)

Shoeboy (16224) | more than 13 years ago | (#2267746)

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, the English to English Translator. This nifty app lets me translate what people say into what they mean. Let's apply it to this article:

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

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

Basically the guy told me that it is impossible to create 'state of the art' programs with command-line tools. But when I asked him to give me reasons why he just called me stupid and 'behind the times'.

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

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

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

But what I want to know is how many of you developers have switched from command line work to KDevelop or CodeWarrior? And what advantages you think it offers? Certainly there are many 'state of the art' apps created with command line tools, but I'm open to anything that can increase productivity.

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

I've just never seen a compelling reason to make the switch from what I am used to and comfortable with." Personally, I feel the best development environment to work in would be one that ignores neither the GUI, or the command line.

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

Well, I think that clears that up.

Re:English to E Translator (0)

Anonymous Coward | more than 13 years ago | (#2267812)

Hey! Welcome back... BTW, have you been trolling on in the past few days? Or is there just someone with a similar writing style?

They're the same thing (1)

Farrax (83670) | more than 13 years ago | (#2267750)

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.

Hey Tuna Taco (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2267753)

When you ban an IP, it's because they were modded down 4 times in the past HOUR, not HOURS.

HOUR is singular.
HOURS (note the presence of the "S") is plural.

You dumb fuck. Of course, if this were the most significant thing that was broken in slash 2.2 or whatever the fuck beta this is, I'd advise you to go fix it. But maybe your should go make it WORK first and THEN fix the typos. And then, after you've done all that (through a process called "testing") THEN and only then do you relase it to the public. You're doing it all fucking backwards.

I used commandline tools to do this: (-1, Offtopic)

keesh (202812) | more than 13 years ago | (#2267755)

Slashdot has been Invaded by Martians!
o o
/ \
| |
\ ______/
/ \
| [@][@] | __________________
| ^^ |_/ \
\_______/ \ HONEST... /
* | | \________________/
/ ___/ \____
|| / \
|| | | *** | |
|| | |* *| |
|| | | *** | |
\\ | | | |
\\ | |_____| |
\\ VVV _[_]_ VVV
\\ / \
\\__/| | |
| | |
| | |
| | |
__/ | \__

This Martian is Copyright © 2001 keesh. You may redistribute it under the terms of the GNU General Public License version 2 or later.

Bigotry makes for sub-optimal programmers (5, Insightful)

ben_tarval (512334) | more than 13 years ago | (#2267759)

There are times when CLI tools are superiour And there are times when GUI's
are superiour. If you don't know when each is best used, and how, you are
not up to your full potential as a programmer.

Personally, I believe in keeping an open mind, and using the best tool
for the job. This allows me to do the best job possible.

Now then, ask your bigoted friend if he does anything less. If this doesn't
shut him/her up, then his reply will be most amusing.

GUI helps, but ain't a brain replacement... (0)

DeepMind (444458) | more than 13 years ago | (#2267764)

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.

It's the editor and debugger... (0)

Anonymous Coward | more than 13 years ago | (#2267765)

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.

i guess this guy has never programed before.... (1)

LWolenczak (10527) | more than 13 years ago | (#2267766)

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.

Horses for courses, (1)

RojCowles (30457) | more than 13 years ago | (#2267769)

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

Different, not more advanced (5, Insightful)

proxima (165692) | more than 13 years ago | (#2267775)

The difference between GUI development tools and command line development tools is fairly minor. In many cases, the IDE (Integrated Development Environment) simply brings together a large collection of individual utilities for convenience. This happens in the Windows world with Borland's C++ compiler and their IDE. In the *nix world gcc (and other compilers), as well as debuggers, possibly code-completion (usually only found within the IDE), class browsers, etc, are brought together into one package that allow for faster development of applications.

KDevelop and KDE Studio are two examples of this. The "tools" are really the same - they just offer a GUI interface to several command line utilities. I cannot speak for KDE Studio, but I believe KDevelop is working on good cvs support for a complete approach to shared development. To my knowledge some of these features are already implemented. Also, a GUI based IDE will almost ceretainly have good syntax highlighting.

However, one does not need to use a GUI to get colored code - vim and Emacs/XEmacs offer this from the command line.

In my opinion, development can take place faster and debugging more easily with an integrated environment compared to ed+gcc, but this should be rather obvious. This does not make IDE's (both GUI and terminal based ones - IMO Emacs is an IDE once you configure it properly) more advanced - just more convenient.

The nice part about developing with *nix is that you can use a wide variety of tools, even on the same project. Use what you are comfortable with, and ignore those who say your technique is flawed - everybody has their own way of doing things efficiently. With MS Visual C++, you are basically stuck with their IDE and you better like it.

Choice is good, use what you like.

Re:Different, not more advanced (2, Informative)

NSG (132405) | more than 13 years ago | (#2267816)

>With MS Visual C++, you are basically stuck with their IDE and you better like it

Huh? Am I the only persson that realizes that MSDev is a GUI interface to the command line tools that it runs? You can still execute cl.exe and link.exe from the command line - after all, thats what MSDev does, and pipes it's output to the Output Window.

Have been working with for some time (0)

Anonymous Coward | more than 13 years ago | (#2267780)

And it's pretty neat. I would hate going back to anything with less features!
  • Whenever I type the "." (or "->" depending on the language) it shows the available methods/properties/members.
  • When I select a method, it displays the prototype and a small comment attached to the method (yes, your own methods can have the comments that will be displayed as well).
  • When I'm typing the arguments, it shows which argument I'm in now (kind of helps when a function takes 20 arguments).
  • Many basic mistakes are identified by the background compiler and highlighted directly in the editor (the famous wave line from Word of course) - you see it when you make the mistake, not when you happen to hit the compile button.

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

It's all the same, really (3, Funny)

trentfoley (226635) | more than 13 years ago | (#2267786)

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.

Depends on the needs (1)

DarkDust (239124) | more than 13 years ago | (#2267787)

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

GUI V. Non GUI (1)

jellomizer (103300) | more than 13 years ago | (#2267798)

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.

VisualStudio.NET Intellisense Rocks (1)

Jan (7105) | more than 13 years ago | (#2267800)

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
and Intellisense prompts you with a list of methods on a 'Type'. You *pick* (not type) GetCustomAttributes. You see
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.

Experience and Power are the Key (1)

ssclift (97988) | more than 13 years ago | (#2267814)

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

Somewhere in between. (2, Informative)

cygnus93 (147851) | more than 13 years ago | (#2267815)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?