Slashdot Log In
Why Develop On Linux?
from the stuff-to-think-about dept.
After spending the last year developing under Windows in my previous job, I can say that I would highly prefer the freedom of developing with Open Source rather than depending on a closed environment. I have had numerous problems with the preponderance of binary files created by Developer's Studio (and ActiveX's dependence on the Registry) and the the behavior of just building my project. I prefer makefiles and source code, where everything is specified in text and there's an open syntax describing all aspects of the build process. Here's question I would like to ask of all the Developer's Studio users...how can you take an existing MFC SDI (single-window) project and convert it to an MDI (multi-window in a single pane) project? If it doesn't involve creating a new project from scratch, I'd be highly surprised.
So what are your thoughts on this subject? Do you prefer the slicker, highly integrated commercial environments, or do you prefer open ones?
Well, it's natural... (Score:5)
Don't use MFC as an example of anything (Score:3)
Ugh, if there's ever been an application "framework" nastier than MFC I've yet to see it. The sheer complexity involved in acheiving some of the simplest tasks is truly amazing - who wants to deal with a huge mess of DDX/DDV commands just to get the value of an edit box into a variable?
Personally I'm using Borland's VCL at the moment, and whilst it, like any other framework, does constrain the things you can do, it certainly feels a hell of a lot more "natural" than MFC ever did - things work the way you expect. As for chaning an SDI app into an MDI app? Well, it'd be some work, but I can see myself doing that without starting over.
No, using MFC as an example of why Windows is a poor environment for coding is wrong. Plain and simple, MFC sucks, and there are a lot better alternatives out there for coding apps in. And since Borland are porting Delphi and C++ Builder to Linux, I'd highly recommend them there as well.
---
Jon E. Erikson
Give MS Visual Studio a Chance! (Score:4)
By far, my favorite feature is the popup Intellisense, when you're working with an object or struct and type "." or "->" you get a window with the details of the object at that level. You will quickly get hooked on this feature.
Plus, you can now edit and recompile c on the fly while debugging. That's a big timesaver for me (for correcting "freshman" mistakes like incorrect loop bounds without having to start all over).
And finally, if it's good enough for John Carmack, it's good enough for me!
Two things for me (Score:5)
- The libraries you use are open. You can read (and marvel at or laugh at) their source code, debug them, fix them, and participate in their development communities.
- The API's you program against were mostly written by creative people with taste and community feedback; not by committees with deadlines, backwards compatibility requirements, an internal review only, and a narrow Microsoft mindset.
Really, development on a free platform is just more fun!System Calls (Score:5)
Finkployd
Re:integrated development (Score:3)
There are code control systems available for Windows as well - PVCS (nasty), SourceSafe (even nastier) and WinCVS, which is just a GUI wrapper around CVS. I wouldn't say that Windows suffers in this department.
---
Jon E. Erikson
Development can occur on any platform (Score:4)
Do what you know. (Score:4)
I'd still recommend checking it out or you'd never be familiar with it. I just don't recommend anyone wiping out their Windows partition, running down to the store and buying Linux and think that they can be a Unix programmer. Learn Unix first and when you know it well enough, you'll WANT to program with it.
kwsNI
Let me count the ways (Score:5)
1) Multi-tasking: Booting into Windows makes me feel claustrophobic now. I can start multiple programs but if one of them hangs (like Exchange) they ALL do. If you are like me you like to be doing several things at once (emacs here, netscape there, news reader the other place, etc). This is harder (or even impossible to the extent I do it) under Windows.
2) Determinacy: It used to be that when a program crashed I'd try running it again. Then I'd reboot and try again. Under Linux if it crashes I KNOW it was the program that did it (or course there may be environmental factors, like config files).
3) Source code: In the course of just 7 months, I've had to inspect the kernel code twice (and change it once).
4) And then there's all the little things: DLLs. Installers. Command line tools. Now that I've learned how to use the "find" command...well, there's no superlative strong enough to get across how much I prefer Linux.
Here's what you do: Go back to your friend and find out what he hates most about developing under Windows. Then show him how that isn't an issue under Linux. "Linux, it has something for everyone."
--
Less money, less admin, less machine--more power
Consistent API. Source Available. (Score:3)
Also, with Linux (any open-source, really), I can find out what the bugs are. I've been programming with imagemagick recently and ran across a situation where the headers didn't match the documentation. I just lookined in the
If he's good at Windows programming, though, good for him. It's not easy to be a *good* Windows programmer. And he probably makes good money at it.
Why develop for Linux? (Score:4)
First, I write programs that fill needs that I see. The last desktop-based application I wrote, IntuDex, was a mailing list manager for the Amiga. It was much simpler to use than the relational database that my user group, Amiga Atlanta [amigaatlanta.org], had been using. Also, I could give it to anybody I wanted, an important fact. As the newsletter editor I depended on the secretary/treasurer for mailing labels. My program facilitated data sharing between us, and I didn't have to buy a $300 program to do it!
Second, I'm a big fan of simplicity. Even as an RF/Microwave engineer I find beauty in reducing complexity (try getting my program to believe that when they see this board I'm working on!). Win32 does not provide a "beautiful" environment, at least from my point of view. For example:
is pretty much all you need to do to open a window under the Amiga's operating system. Isn't it like a page and a half of code under Win32?For me programming should be a joy, not a chore. It's realy as simple as that!
Linux/Unix is for curious perpetual coders. (Score:4)
So, why do it? The reason to do it is that the code you end up with under windows is a big steaming pile of non-portability. In many instances, i.e. if it does anything whizzy, it won't even port to other versions of Windows. And there's tons of totally bogus crap you have to deal with in Windows, interfaces not working the way they are specced, weird... ok, one example: quick, allocate a string, and make it work cross platform. Do you want TCHAR, wstring, or any one of six others. Search MSDN, that will help you decide. ha ha ha.
Unix is for people who like to code everything they do. People who want to write a script to check in and out of source control. This morning, my cable modem was down at home. I whipped up a one line script so it would retry my the net every five minutes so I could make a service call from work and then later today I'll be able to log in from work and get to my home network. (The script: while [ 1 ] ; do /etc/rc.d/init.d/network start ; sleep 10 ; if ping -qc10 207.46.130.45 ; then exit ; else /etc/rc.d/init.d/network stop ; sleep 300 ; fi ; done )
you just can't do things like that under Windows. Oh, I know, there are tools you can find to do each thing, but it's not in Windows' blood. OK, then there's stuff like how regular the APIs are, how simple the inter-process control, and how network capable your apps will be (X Windows was designed for network use. When my home cable modem comes back up, I'll be able to log in from across the internet and use my several machines at home no different than if I were at home.
Finally (yes, there's more to say, but I gotta get to work :) you asked about Linux, and it's unix with all the source available. You can look up how things work, no secrets, no frustration with apps that don't quite do what you want. Apps that don't quite do what you want? That's almost the definition of Windows.
Unix isn't perfect, and Linux isn't perfect Unix, but if you love coding, you'll love coding them.
Re:System Calls (Score:3)
Sure you can find those rare Unix books that surfaced a few years back that really dug into the internals/libraries and posix standards but they're so damn expensive!
I'd say give it another year, and the choise will be a no brainer. You will either have A) Windows B) Linux.
With the likes of kdevelope, and the new Gnome and KDE hitting the streets, any gui developer will feel at home and in control of linux
OTH, i would love to see java take off more. OH well. It would be nice to follow IBM's Goal of Platform independance. Nothing like using an operating system which is designed for a specific task rather then vice versa.
IDE's are bad for code maintainance (Score:5)
to alter a program that was once written using a command line C compiler and make, you can just recompile it using those same tools. If, however
the same program was written using some kind of IDE
with its own kind of project files and stuff you're going to have a hard time finding a copy of the same 15 year old IDE the program was developed with, not to mention a computer that can run the thing!
I think IDE's are only good for write-once programs.
Re:Give MS Visual Studio a Chance! (Score:5)
The Intellisense absolutely rocks. However it is not only IDE what counts. I personally can live with vi, make, ddd etc. But it is plenty of mature tools available for M$ environment that makes a difference. Try to profile your code with gprof and then try to do the same using Rational Quantify. Try to make a coverage analysis without recompiling your code under Linux. Try to catch memory errors with ElectricFence - due to how it works it will eat all your memory in a few seconds in all but trivial programs.
Yes, the tools are expensive, but they save a huge amount of time.
Better UI. (Score:3)
For a software developer, the system environment is the UI.
How handily can you find stuff in your log files?
I use grep and perl for that.
How often do you have to reboot an unstable system?
I don't. (well, except for netscape)
Starting any services required in production in your sandbox without stability or resource exhaustion issues. Oracle, Apache...
Multiple desktops = almost unlimited number of windows, all neatly organized. This is
On the contrary (Score:3)
I agree that it's easy to find references to Windows API calls. But it is easier to find documentation on Unix system calls. Just take a system call and do a search on Google. You'll get back 5 tutorials, 4 online man pages (from 3 different implementations) and several mailing list discussions.
As for expensive books: *shrug* Which would you rather have? One expensive comprehensive book (like Stevens) or 15 "Windows Development Bibles" at $10 each?
--
Less money, less admin, less machine--more power
Everything's a file (Score:5)
Need information from about the system? Just read a few files from
Linux has another advantage in that it ships with vi, emacs, the standard development toolchain, bash, perl, etc., which once you get used to, totally blows Visual C++ out of the water as far as ease of use and customizability goes.
My three answers. (Score:4)
I can only see three answers to this question
a) You program in and for Linux when your customers ask you to do it and pay you for it.
b) You don't need more money and want to do your bit in the fight agains The Evil Empire.
c) You need to run something on hardware that whon't run Windows.
I know that some people dont like reason a) but this is the world that most of us live in.
TC - SFBook.com [sfbook.com]
--
Tip Sheet for those replying (Score:5)
People will post lots of replies saying something like "linux offers lots of languages and open source libraries, and heaps of tools that are cool and don't crash, unlike certain other companies' software". This will be marked "Insightful", and leave the original query unanswered.
1) Try to think of the person in question - someone who programs windows and *already knows* the above arguments about linux, but is not convinced. Try to imagine their mindset. What would your knee-jerk reaction be if someone told you that OS xyz is better than linux for dev?
2) There are already lots of libraries in windows, and lots more tools with lots more features than in linux. The IDE envs, testing suites, database tools and utilities, libraries and packages available for Windows make a formidable lineup. It's not for nothing that Windows has such a strongly hooked developer base (check out your local newsstand for evidence). This is why companies and individuals are impressed by a rich development environment with lots of options. Don't expect people to be convinced by Glade and Gimp and a far smaller lineup of software tools - explain why linux would still be better, or other things that compensate for the weaknesses.
3) Don't use ideology. If people wanted to program in linux because it's open source, they already would be doing so. Use a better approach. Not everyone finds ethics and the principles of open source a convincing reason (otherwise they would already be using linux, so you're preaching to the choir).
4) Compare point by point. If you say something is good about linux, think about whether Windows has an equal or better choice. If so, it's a redundant argument - not likely to convince.
5) Avoid zealotry. It turns off people. Really.
Re:Give MS Visual Studio a Chance! (Score:3)
I think part of the reason that dev studio doesn't crash much is that M$ actually uses it to develop code, so of course it is going to be clean -- they have a lot of beta testers and dev studio fixit people.
Keithel
Develop on what your target customer base is... (Score:5)
I've used nearly every type of tool there is to develop on, so heres my 2 cents:
General: All systems support whatever language you want to code in. C++, Pascal, Basic - these are all available. CVS is available on all systems. What differs is the user interface on the development tools on the systems, and the amount of learning time you have to spend before commencing coding.
Windows: Developing on windows is a good way to get to know the closed source system. Documentation is hard, and is often expensive to come by. Mostly people develop code using Microsoft tools. These tools look pretty and work ok. They allow you to edit, compile and run code. As a development environment is good. Whatever you want it there within easy reach. To start developing seriously for windows you are best off buying the Microsoft developer tools. You need to be prepared to continue to upgrade everytime Microsoft release a new OS. This is very costly, and not something a teenager can easily get into. There are free tools for developing under windows, but the windowing system calls make it a nightmare to be productive. Learning time is almost zero - mostly if you draw up your screen and hit run, it will. This can be a drawback in a large app if you need to maintain it on a daily basis - it can be hard to get to module you want quickly.
VMS: This is not something that is often done in someones bedroom. Alpha machines can be expensive, and follow the Apple style of making sure you use everything that Compaq can produce. The tools are good, and the documentation is excellent. The librarys are well documented, and do exactly what the docs say they will. Only in rare cases will these change radically enough to break your code. Developing under VMS is about the same as linux. You have good tools and good documentation, nothing too flash or pretty, but it's all very functional. Standards are so rigoursly enforced that as long as you obey the rules you'll never have to worry about your code crashing because of a conflict with some other piece of code. The drawback is that VMS developers are rare these days and good help is hard to get. Learning time is short, as the tools are basic enough to do exactly what everybody needs to do.
Linux: Developing under linux is nice. There are a lot of tools and a lot of people available to help when something happens. Newbies are very welcome. The range of linux distros and linux ports make it hard to write code once and forget about it. You need to figure out tools such as autoconfigure if you plan on being multi-vendor/multi-platform. Linux isn't as easy to code for as windows is, but if you are developing under open source you will get excellent peer review if your code is something everyone wants. Many of the tools are similar to other systems, but many have been scaled up to support world-wide development. Learning time can be long if you have to start a project from scratch, but is simple enough if you just want to contribute.
Depends on your project (Score:3)
If cross-platform development is important, use the OS with the best tools available. Personally, I need a shell, a compiler and a good text editor for the stuff I write (not that I'm doing really big projects). They are available for Windows *and* Unix, so I just follow my personal taste and pick the one I like better.
Re:Give Emacs a Chance! (Score:3)
By far, my favorite feature is the popup Intellisense, when you're working with an object or struct and type "." or "->" you get a window with the details of the object at that level. You will quickly get hooked on this feature.
Hmm. If you like that sort of thing, I can see that might be useful. That's a pretty trivial hack to make something like Emacs do that for you if you wanted it. Maybe forty minutes of thinking and coding to add a reasonable working version which scans all the included files to pick up the struct definitions. Better still, if you use Tags support under Emacs, you don't have to go search either - you can just look up the details.
Plus, you can now edit and recompile c on the fly while debugging. That's a big timesaver for me (for correcting "freshman" mistakes like incorrect loop bounds without having to start all over).
Not to decry this feature - it's extremely useful - but I do this all the time. With Emacs. Now why use Emacs? Mainly because once you have got over the initial speedbump of actually learning how to drive Emacs, you realise that anything you ever find repetitive or clumsy can be automated, speeded up or helped along with either a quick reconfigure, a new library, or in the worst case scenario, a few minutes of thinking and a few more of coding a new Emacs function. It's this extensibility that makes me realise that I shall never really pick up another editor for anything complex. For all you VI users who are gnashing (sic!) your teeth over this, I use vi as well, but more often than not for simpler editing tasks.
Cheers,
Toby Haynes
Re:Give MS Visual Studio a Chance! (Score:3)
HOWEVER, I think that parasofts insure product line is sweet as well. If you talk about spending money, this is much better than electricfense or even most of the other windows products. The deal here is that parasoft is cross platform and support linux.
Substandard C++ compiler, libraries, etc... (Score:3)
Also, having the full source for the system libraries and the operating system is important when debugging. I've been able to fix/extend things that I couldn't on Windows.
Thread support in Linux is robust and follows the POSIX standard. If you have to write portable code, this can be important. Also, most textbooks and references on threading address the POSIX standard pthreads library.
A rather big one: sockets and file descriptors are unified under Linux/Unix. This means that the system API's that apply to files also apply to sockets. Because TCP/IP was added to Windows later in the evolution of Windows, the socket descriptors are not interchangeable with other system objects, so WaitForMultipleObjects() in Windows cannot wait for a system object and a socket at the same time. This can complicate socket programming.
Windows takes a huge performance hit because its DLL's are not relocateable code, and the runtime loader in Windows must patch each call and jump instruction in the code when the DLL loads. In addition to taking a huge amount of time when a DLL is loaded, it pollutes the swapfile with multiple copies of the DLL because of the patched instructions. Under Linux, shared libraries are position-independent, so they do not have to be patched at load time and they may be paged directly from the shared object file, thus not polluting the swap file.
That's all I can think of off of the top of my head.
It's all about the tools! (Score:3)
Hey people,
Read the subject. The whole point of using the Win32 platform at this stage in the game is the massive number of developer tools that Microsoft has been building for the last 15 years. Imaging the Microsoft environment as a pyramid: VB, ASP, ADO on top, COM, MTS, active directory, etc in the middle, and the Win32 API at the base. Of course this is grossly simplified but it exemplifies what is unique to the Windows development environment.
Case in Point:
1) The Win32 API is similar to Linux system calls; create files, threads, events, mutexes, etc. While you can argue that there are major architectural differences, they both provide the same level of support to the developer.
2) COM, MTS. Now the differences start to show. Linux does not have a component model that is widely integrated or used across multiple projects. Of course, newer works like GNOME are very component driven and may end up driving the defacto component model for Linux. However, on Win32 almost anything can be done with COM using a bit of VB script (can you say Melissa virus?). MIS people can tie together a bunch of different packages using COM. In Linux you have to resort to a wide array of command line tools that have different syntax, different configuration file formats, etc. MTS provides easy to write transaction support that is almost too easy to use.
3) VB, ASP. For anybody who has used these tools they are probably very familiar with their limitations. Is VB or ASP superior to other high level scripting languages? NO!! However, VB & ASP can access thousands of objects. You can create a fairly sophisticated UI in VB in a couple of hours. If you want a new control for your UI chances are someone has already written it.
The moral of the story: The application developer has a whole suite of tools they can use to rapidly develop high level apps. It may be a stinking pile of crap but for the most part it works
IMO, the java technologies are still the Windows killer for development internet apps. JSP and EJB sounds like it may be much better (and more fun to develop) than using VB and COM.
Bah! I second this! (Score:5)
Many of the points brought up by TummyX are valid ones. Sure,they can be refuted, but he could then counter-refutre them.
The key is its a philosophical difference. Linux lovers might say "Linux's command line is superior!" Superior to what? NT's command line? OK, yeah. You know why? Becuase the NT command line is an unimportant accessory in NT while the GUI tools are central to it. It's a philosophical difference.
Like any philosophical difference, you will hardly be able to convince people to give up their current beliefs, morals and understandings to see your point-of-view. Why try?
Why? (kind of long I guess) (Score:5)
When you want to know what something does on UNIX, the documentation is there. In
Windows
Secondly, the documentation is scattered around. It's a lot harder to grep for things: you have to know exactly the right trigger phrases to get the info out of the help systems. (To be fair, it's hard to grep dead trees, but Inside Mac comes with an index volume bigger than the Bible to help on that front.)
Thirdly, the documentation is often simply out of date. Windows chanegs API at a scary rate and it's hard to be sure what you're reading is applicable or useful.
The fourth problem I found is that the API levels are incomplete. They lack details. Obvious example; loading images in MFC in a format to display them. It's horrible and code that gets repeated over and over. It needs an image class to handle that, and several dozen are available but are 3rd party and hence buggy or licenced or shareware or unfinished or unsupported or...
There's no way to tell what will remain a supported interface: Will this DX5 call still work in DX8? Who knows. Macintosh has promises of support attached to the APIs.
I found projects annoying on VC++ as well as other people here, but I didn't on Codewarrior so that might just be the way they're done. I dislike MFCs dialog accessing stuff: Delphi does it much more elegantly.
On the final front, the whole concept of having stuff like running a window being so complicated that tools are needed to generate the boilerplate code to save people from the tedium, kind of indicates that that code is too complicated. On a personal front, I'd much rather have it take 3 lines of code to drive a window than have a tool to write the 300 lines for me.
Microsoft is running with two huge conflicting goals: the first is to drive stuff forward creating new APIs, but the second is not to outdate anything ever. Coupled with their financial issues ("ship it quickly") means that they layer things but layer them badly - some of the layers have thin bits which expose lower level nastynesses, others parts are too thick to expose useful functionality.
The solution to windows being complicated to develop for is to
MFC uses macros instead of virtual function calls to dispatch window messages. Why? Because using vfunc calls was too slow in early versions, given the volume of window messages generated. So now it has this history of macros and general untidiness dealing with that sort of thing.
UNIX never had the problem in the first place. Why? Because X allows you to choose which messages are ever dispatched in the first place, rather than sending them all and letting the app sort out the wheat from the chaff. Manipulating the macros is complicated and error-prone, so now a wizard does it for you: a patch on the patch on the...
UNIX concentrates on being small, layers appear only slowly and are more complete. And at almost all layers, there are interchangeable options. Different shells, X servers, editors, window managers.
This smallness makes it easier for the layers to be complete, and uniform in shape and well understood.
The downside is that it does take it longer to evolve higher layers - media players and so on.
Re:On the contrary (Slightly OT) (Score:3)
It is comprehensive, detailed and well written with clear examples; quite simply the best computer-related text I've ever read. It is pricey, but well worth the money.
Cheers,
Tim
Re:Let me count the ways (Score:3)
4) And then there's all the little things: DLLs. Installers. Command line tools. Now that I've learned how to use the "find" command...well, there's no superlative strong enough to get across how much I prefer Linux.
Several extra tips on that one. For those times when "find" just isn't quick enough, run "updatedb" as a cron task every night at 4am and use "locate" to near-instantly pull filenames out of the database that updatedb builds. Of course if you are doing things like "find . -cmin -60" then this doesn't help, but then you really do want find.
Of course, you can get fancy after that piping the argument into other commands or into other command arguments (using xargs). But that is the beauty of Unix - everything plugs together!
Cheers,
Toby Haynes
Re:Let me count the ways (Score:3)
I *did* quit after it became clear management wasn't going to let me develop on Linux. I'm much happier and productive now - also better paid
4) And then there's all the little things: DLLs. Installers. Command line tools. Now that I've learned how to use the "find" command...well, there's no superlative strong enough to get across how much I prefer Linux.
Hooboy, you're gonna cream when you discover "locate"!
--
Re:*rolls eyes* (Score:5)
I'll assume that was sarcasm. While I prefer nvi, Emacs is highly extensible, and nedit is about the best combination of standard idiot-proof gui and configurability you can get, in my opinion. They're all "easy to use", once you've surpassed the learning curve that every editor has. I hate Intellisense, by the way - it slows me down and my keys stop working properly. After a year or two of 9-to-5 coding, you start to vaguely remember the odd property or method... Yes, that was sarcasm. If there's something I don't remember, I'll look it up, but I don't want the editor to slap me around like that.
True, the source is useless unless is used for something. I like having the source (if only to compile it) in order to put everything (binaries & configs etc) where I want them. When you install MS-App 98, you get the choice of where to put the base directory and that's it.
I also occasionally have to deal with bugs, and unlike your friends, have a clue about what I'm doing.
This actually made me laugh. In the grand "OO theory of everything", you are correct in that no object should need to know the details of any other - just the interface between them. Well. I've done enough programming under Windows to notice the slight (sarcasm again) disparity between the documented interface and the real one. I've even had Microsoft ship me a new version of an API with older docs than the ones I already had! If Microsoft wrote to their own published interfaces, their apps wouldn't compile let alone run, let alone run crash-free. Not that they've achieved the last, of course...
Re:Well, it's natural... (Score:4)
Learning C++ in Microsoft's Visual Studio environment is, in my opinion, a bad thing. A novice programmer can crank out software (the quality of which is usually poor) using MFC and the IDE's Class Wizard and not actually understand anything about the language. When faced with a task that requires actual understanding of inheritance, polymorphism, overloading, or anything the IDE can't generate a framework for, such a programmer will always get stuck (making more work for me).
It is better to at least learn C++ in an environment that requires one to actually learn how the language works to get anything done. This understanding will be useful even when asked to work with something like Microsoft's Visual Studio.
I once worked on the project were the technical lead required UNIX (or similar OS) C++ experience even though the bulk of the work was on Windows NT. His reasoning was that almost all people claiming C++ experience but only had Windows experience didn't know the language well enough for a complex project.
Re:except (Score:4)
Except that MFC calls are supposed to hide all the complexity of the Windows equivalent of Xlib (and Xaw) calls from the programmer. There are class libraries that are available for X (Qt vs GTK flamewar, anyone?) and they are all better done than MFC. (Well, I hope they are, anyway. While I can imagine someone setting out to make a worse class library than MFC, I'd like to think that nobody would.)
Unfortunately, MFC is the standard for Windows programming. If you're doing Windows programming and you're not using MFC, then the suits complain. If you're strong enough to resist the suits, then you could already be running Linux.
Windows GUI programming is not nearly as nasty without MFC (which I found entirely unpleasant with its arbitrary and arcane rules concerning things like the messages that need be handled) but for most shops Windows programming means MFC programming just like it means using Microsoft C++ or Visual BASIC
As for the IDE's, well, back in the 1970's, an article titled "Real Programmers Don't Use Pascal" said that real programmers are happy with an 027 keypunch, a FORTRAN IV compiler, and a beer. The way I see it, XEmacs blows the heck out of a keypunch, C is at least as good ad FORTRAN IV, and I can afford plenty of beer. At least with makefiles and command-line compilers, I don't have to worry about my project files getting munged because somebody decided to update the IDE.
One opinion, worth what you paid for it.
2 different arguments... (Score:3)
1) Windows itself is a buggy and unstable platform with bad API's.
2) Programming tools on Linux are easy/harder/more productive than under Windows (with tools like Visual Studio)
I agree with #1, however as user of Visual Studio for several years I'd say that Windows wins #2.
I've never used a more helpful and intuitive coding environment. Once you use Intellisense its hard to remember how you worked without it. Just try coding without syntax highlighting and you kind of get the picture. "Edit and Continue" make it an absolute joy to debug.
If you are a little careful it's easy to write portable code under Visual Studio, and Win2k is suprisingly stable.
That said, there's something beautifully pure about using makefiles and debugging with GDB, and its good for your soul to take control on a low level now and then. For me, its kinda like camping in the woods for a few days. Some peope like camping a lot, others don't...
Try both out and see what feels "right".
Cheers,
Justin.