c download

[SmokeMonster]

The problem with a text editor and command line is that they lack features that make writing and maintaining larger programs easier. I mean a text editor is probably fine for a first year CS course where you are writing trivial programs but beyond that I can't imagine the headache of dealing with a 1000+ LOC program written in a text editor without an IDE. Basic features like a good debugger are missing, I don't care what anyone says GDB is a horrible horrible debugger, I use Code::Blocks to write my C programs and the same bug that takes 30 seconds to catch in a GUI debugger takes like 5 minutes in GDB it's an absolute abomination of a debugger. The error message are atrocious on commandline gcc, a decent IDE gives you more clues about what's wrong rather than unhelpful "Segmentation Fault" and "Bus Error". There is something to be said about having all the tools you need to write code all together in one convenient place, being able to compile with one keystroke, debug with another instead of having to constantly shift between editor and the terminal. Now someone may argue that you hack around in vim to get any feature you want working, but that just defeats the initial premise of simplicity on text editors.

[DemonWasp]

Point-by-point rebuttal:

• Which IDE do you think Linux, which has several million LOC, is written in? That's right, the command-line.
  
• GDB is pretty well the gold standard for C/C++ debuggers. The error messages may be intimidating to a newcomer, but once you get used to them, supposedly they're pretty good. They certainly seem to work just fine when debugging Linux.
  
• Again, it's a matter of getting used to what gcc/g++ says. Try writing your programs with -Wall -Werror; it'll help you find your bugs early on, rather than later.
  
• The command line of a real operating system counts as "one convenient place". You can compile with a couple of keystrokes in most setups: make. You also get a LOT of control over how compilation works.
  
• Try tabbed terminals, multiple screens, etc. There are a lot of nice things about having as many views into your code, environment, and compilation information as you want, which you can do really easily with terminals, but which is almost impossible with any IDE.
  

Don't get me wrong: I still use Eclipse to write my Java / Jython / Scala / etc. There are simply a lot of ways to get things done more efficiently from the command line.

[mirhagk]

should I do a point by point by point rebuttal. And should I use int array[][][] or int array[,,]. (LOL JOKES!!!!)

anyways let's see

DemonWasp @ Sat Feb 19, 2011 5:07 pm wrote:

Which IDE do you think Linux, which has several million LOC, is written in? That's right, the command-line.

Linux is broken up into 100's of source files. And anyone who works on it only deals with one or two at a time, just too confusing to keep opening up different files, and it's very modulated regardless. In a project environment, you can easily switch to any source file you want, and with a good programmer makes modularization even easier, as you can have each class be it's own file, and not have to worry about switching between different files cuz it only takes a click to switch to another file in the project. And with sub projects in a solution, you can dev for multiple environments, and easily manage and compile for all environments, or specific ones. example, xna in VS2010. If you want to dev for a new environment, like say add an Xbox version halfway through completion of the project, simply do that, it takes care of the specifics, like which libraries can be included, where to run the project, compilation settings etc.

DemonWasp @ Sat Feb 19, 2011 5:07 pm wrote:

GDB is pretty well the gold standard for C/C++ debuggers. The error messages may be intimidating to a newcomer, but once you get used to them, supposedly they're pretty good. They certainly seem to work just fine when debugging Linux.

I can't really argue here, but I know VS2008 onwards lets you do amazing things with debugging, the error message points to the line that had the error, and it lets you go over variables in the project, simply moving your mouse over them tells you their value, it lets you insert instructions to this specific debug section, without a recompile, lets you change values of variables, move variables around etc. Some of these features can be done with 8+ programs and a text editor, but this IDE manages all of it right there for you. (Seeing register values is cool and all, but is really annoying to deal with, and way less useful)

DemonWasp @ Sat Feb 19, 2011 5:07 pm wrote:

Again, it's a matter of getting used to what gcc/g++ says. Try writing your programs with -Wall -Werror; it'll help you find your bugs early on, rather than later.

Dont know much about this.

DemonWasp @ Sat Feb 19, 2011 5:07 pm wrote:

The command line of a real operating system counts as "one convenient place". You can compile with a couple of keystrokes in most setups: make. You also get a LOT of control over how compilation works.

First of all, IDE's don't take that control away, they just hide it away unless you actually want to use it. Good IDE's let you specify a great deal of specifics about the compilation. And instead of saying "real operating system" say linux, we all know what your drooling over. And it's not one convenient place. It's one place, no convenience. That's like saying My Music(using windows) is one convenient place for all your songs. It's one place, but we all know it's better to organize your songs, perhaps using some software to manage them with albums and such, or just placing them in folders by artist or w/e. With an IDE it takes ONE keystroke to compile. takes ONE keystroke to debug, ONE keystroke to step through, over or into. everything is one keystroke, or one click away, instead of remembering and typing commands

DemonWasp @ Sat Feb 19, 2011 5:07 pm wrote:

Try tabbed terminals, multiple screens, etc. There are a lot of nice things about having as many views into your code, environment, and compilation information as you want, which you can do really easily with terminals, but which is almost impossible with any IDE.

Pretty sure tabbed source files, multiple screens work just as well for IDE's. and actually it's pretty easy to view as much information as you want with any good IDE. you can have multiple source files open, you have your debug information, your properties, your solution, your toolbar, and it's all packed together nicely, and divided well, so your not looking around trying to remember which window has your main code, and which window contains debug info.


Point is, IDE's and projects don't remove usefulness, worst comes to worst you can combine them with a terminal. A project is not a really hard concept to understand, and if you ignore most of the buttons until you need them, it literally takes half an hour tops to learn how to use it. For a beginner programmer, which is easier

1. Create a project (what's this, well it's like it sounds, contains all the info for a project, or program)
2. Write your code in the created main function, ignoring everything else for now.
3. Press F5

ORR
1. Open up a text editor
2. Type out all the libraries and neccassary headers etc. (what are all these, the things you program needs to run)
3. Create the main function (whats argc and argv**, ignore them for now, but type them anyways, you will def need them)
4. Type your code
5. Open a terminal (whats that? like command prompt. What's that? like the way the use to navigate computers)
6. Naviage to your source code (how? with the change directory function, don't you know it, no..... im a n00b rememborz)
7. Call the compiler on your source code (whats a compiler, okay, mini lesson)
8. Call the linker (whats a linker, continue mini lesson)
9. Now run your program by typing it's name

I think the IDE is MUCH less confusing for a n00b.

As a final argument let me ask you something.

Are not the most advanced text editors really trying to make themselves more and more like an IDE??? So when does it stop being a text editor and start being an IDE?

I'm pretty sure this is an IDE
http://jedit.org/index.php?page=screenshot&image=36

[DemonWasp]

Apparently I managed to lose my post somehow. The short story:

My point about Linux is that it's a huge, complex, successful project that doesn't ever use an IDE. Complex, successful projects are entirely possible without any IDEs whatsoever.

Everything you mention VS2008 as letting you do are standard features available in most debuggers, including GDB. If you want really advanced features, find a debugger that lets you go back in time.

Using -Wall -Werror means "emit all warnings; count warnings as errors". It will help you by warning you about anything in your code that is usually a mistake, and by making sure you fix problems before running. You can probably do this in any compiler, but that's the gcc/g++ way.

IDEs generally only expose the more exotic command-line switches through an interface that looks like --config=value anyway. Worse, with those settings buried in a .settings file or similar, you can't easily distribute them to other team members. Command-line utilities are much more portable in that respect. Here's an example of something that is trivial at the command line, but nearly impossible via IDE: set up your computer to automatically build your project, run its automated test suite against it, summarize and e-mail you the results; have it run every day at 4am.

When I say "command line of a real operating system", I mean any OS that has a competent command line. Linux counts, yes, but so do: Solaris, AIX, HP-UX, OS X, BeOS, etc. Windows may eventually count if PowerShell turns out to be useful...but still, it would be more useful if they just ported bash already.

It is possible to organize your workspace however you want using terminals. Only the best GUIs have a level of flexibility even approaching that: Eclipse is close, but not perfect. For example: how many debug sessions can you have side-by-side in your IDE? How many through terminals?

Your step lists are uneven: the second example goes into far greater detail. Consider the difficulty involved in installing an IDE and configuring it to use your compiler-of-choice correctly. Consider that building is either "press that button" or "type make": the two are trivially different, and it's hard to say that one is easier than another.

The most advanced text editors are emacs and vim. Vim is a relatively simple, if powerful, editor. Emacs is closer to an operating system (as I hear it) than an IDE -- name me one IDE that has an embedded email client. Meanwhile, jEdit is a text editor, and not a particularly advanced or powerful one. If you can't write, organize, refactor, compile, run and debug code through it, it's not an IDE.

[mirhagk]

The point is that something like notepad++ lets you link to a compiler, and set everything up so pressing f5 will compile and run your program. Well why not just get an IDE.

And installing an IDE such as Visual studio is as simple as downloading a file, and clicking next a couple times.

And the .settings files is actually usually something like assemblyinfo.cs (for VS2010 c#) that is in the solution explorer, and is easily transfered with the rest of the project. Many of these settings files provide an xml format, for ultra simplicity.

And my point is that you can use both, and someone who is smart will. I use the command line in some scenarios, and an IDE in others. So yes with my way I can just as easily accomplish that as you can.

And my point is that it's not quite as easy as typing make, you first have to set up the make file, you dont have to set up anything with alot of IDE's (they have default settings, which you use for 99% of projects anyways).

Besides I'm surprised with your disgust at the .settings file, it is very much akin to a make file in that they both contain all the info to compile.

[DemonWasp]

A settings file is specific to one IDE. A make file is specific to the make standard, meaning it should work with more or less any implementation of make. In particular, your professor / teacher should be distributing a basic makefile to work with anyway. I'd be less against a .settings file if the standards were entirely open (Eclipse happens to use the XML format too, not that that means anything in particular).

For the first few programs, an IDE is an unnecessary weight, especially a full professional version. Start with something lighter, like JCreator or the equivalents for C/C++ or C#, or something even lighter, like the command line. Besides, no matter what IDEs you learn, you will eventually need to learn to use the command line to some degree, so why not start with that?

[mirhagk]

How does it weigh you down, it makes it easier for a n00b. Yes it's more resources, but that's the only weight, You can ignore most of the functions till you need it. WIth command line you cant ignore things, you have to use them and then later learn them.

[DemonWasp]

Unnecessary weight:
- projects
- separate code files
- debugger
- automatically generated files

Necessary weight:
- code file
- compiler

So yes, you can start with a (particular) IDE. Or, you could start with a command-line. The first way, you may have a slightly easier time of some things. The second way, you pick up a skill you're going to need forever, at negligible cost.

Besides, the weight of an IDE includes install size (gigabytes, as I recall, for some versions of Visual Studio), install time (hours for those same versions of VS), start up time and system resources. The system resources become more important when you are editing code remotely -- try editing your code on your home system from school / work and see how that goes in an IDE.

[btiffin]

mirhagk @ Mon Feb 21, 2011 1:15 pm wrote:

How does it weigh you down, it makes it easier for a n00b. Yes it's more resources, but that's the only weight, You can ignore most of the functions till you need it. WIth command line you cant ignore things, you have to use them and then later learn them.

A little old guy advice mirhagk. Take a look at a 'time-in' bell curve for just about ANY human endeavour. People dislike being unskilled in activities and would rather get over being new and get to being competent. Most people spend far more of their time being competent at things than as a beginner or an expert. Aim for competency and most people will follow. Treat people like they are "perpetually a beginner" to the subject and they will pick a different subject. Yes there is a struggle coming to grips with any subject matter, but don't assume humans like being treated as beginners for long, or for that matter, ever. It's not in our nature.

For computing, many people want to get-in, get-out. Programmers are not most people from that point-of-view. Clicking an email inbox button is not programming. Driving is not automotive repair.

Cheers

[SmokeMonster]

DemonWasp @ Sat Feb 19, 2011 5:07 pm wrote:

Point-by-point rebuttal:

• Which IDE do you think Linux, which has several million LOC, is written in? That's right, the command-line.

Obviously, I never argued that it is impossible to write large software with command line/editor. People who write code for Linux OS are power users. Most linux users have already hacked around VIM to get the functionality that an IDE offers. They are no way comparable to the hypothetical noob user that we are talking about. For a new user what do you think is easier? Having a file navigation pane in the IDE or have to use vim commands or installing plugins like NerdTree to get that same level of functionality,

Quote:

GDB is pretty well the gold standard for C/C++ debuggers. The error messages may be intimidating to a newcomer, but once you get used to them, supposedly they're pretty good. They certainly seem to work just fine when debugging Linux.

Again, it's a matter of getting used to what gcc/g++ says. Try writing your programs with -Wall -Werror; it'll help you find your bugs early on, rather than later.

I always use -Wall while compiling my c programs. My problem is not with GDB error messages it is with GCC error messages. Whenever I compile on the unix systems (which I have to do for my assignments) the error messages that GCC gives are almost always a non descript "Segmentation Fault" (or in some cases "Bus Error"). Everything from trying to play with null pointers to dividing by 0 gives a seg fault. Whereas the IDE gives me more of a clue of what went wrong. GDB gives me more info on what the problem was but that should be the job of the compiler not the debugger. As far as the functionality of the debugger is concerned I guess my problem in general is with command line debugging rather than GDB in specific, there are projects which basically slap a GUI on top of GDB I have not tried them myself and I'm sure they're better than the command line version but the command line GDB is just annoying to user, with the IDE debugger I can with one glance look at the state of my program instead of having to type in command after every stepover. I can look at pointers the memory address they are holding and what inside it, I look at the contents of a chain of pointers with one click. I can look at the call stack, output, all my variables in one glance.

Quote:

The command line of a real operating system counts as "one convenient place". You can compile with a couple of keystrokes in most setups: make. You also get a LOT of control over how compilation works.

Try tabbed terminals, multiple screens, etc. There are a lot of nice things about having as many views into your code, environment, and compilation information as you want, which you can do really easily with terminals, but which is almost impossible with any IDE.

How can you say that writing a make file is easier (esp for a noob) than just letting the IDE handle that stuff? Make files are almost a language in of themselves, they require knowledge of how the C compilation process works. That's too much to expect.

DemonWasp @ Mon Feb 21, 2011 3:24 pm wrote:

Besides, the weight of an IDE includes install size (gigabytes, as I recall, for some versions of Visual Studio), install time (hours for those same versions of VS), start up time and system resources. The system resources become more important when you are editing code remotely -- try editing your code on your home system from school / work and see how that goes in an IDE.

But you are presenting a false dichotomy here. It's not just a binary choice between a command line+texteditor setup or a large bloated software Visual Studio. There is a reasonable middle ground, I can find several full featured IDEs under 25 mb (Code::Blocks and Dev C++ to name two) which is not heavy considering the windows version of gVim is almost a 10mb download.

BTW I'm not saying text editor+command line setup is always bad. When I'm working on my rails projects I follow the commandline + vim setup (with all the nice plugins like taglist and nerdtree installed) since that's how it was in the book from which I learned rails and the rails "IDEs" are harder and more convoluted than the command line tools, it's just that for noobs or working in languages like C where you run into hard to debug problems and where you have better alternatives than command line, why not just use them?