Slashdot Mirror
Why Develop On Linux?
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?
C and Unix as they stand fit hand in hand, they were born together. This makes programming on any unix-like platform MUCH easier. There are a ton of libraries to work with that have code that you can see and hammer bugs out of. There are a TON of languages, and more compilers and interpretters than you will ever find under windows. The command line is easier to understand. There is less garbage to mess around with. Pretty much, coding in Linux is coding just like you learned it in school. Coding in windows is, sort of like writing a biography about a person who won't tell you anything about themselves.
Eh...
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!
- 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!The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
When you make a system call, you know what is going to happen. No hidden APIs, no undocumented 'features' to bite you in the ass, and it follows well documented standards.
Finkployd
Where I work our developers use windows boxes because that interface is simple for them. They write the code under cygwin and compile with GCC. They can take their code wherever they want since they use a standard compiler. It's not about forcing an OS on people, it's getting them to use tools that will port easily. If they used visual studio or some other propriatary tool it would make things a hell of a lot more complex. The software that they write actually runs on Sun boxes with solaris 7. If you want to push Linux, push GCC. Once they can port their code they will be a lot happier to hear about what else they can do in Linux. I have found that they are most interested in A) a good text editor (emacs or vi) B) Good windowing interface C) ability to display video output from their apps (remote X session or local execution) If that all works fairly simply, I don't think they care a whole lot about what they are actually using.
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
I spent several years developing on Windows (3.1 and 95, mostly). The last 7 months have been on Linux (exclusively). Here's my opinion: I will quit my job before I will spend as much as a week coding on Windows again.
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
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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, 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!
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.
I think IDE's are bad for producing maintainable code. When, after 15 years, you find that you need
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.
When I moved from Windows and started coding for Linux (and unix in general), what really impressed me was how easy it was to do I/O. You open a file, read/write, and close it. There's none of that IDirectSound2->QueryDeviceAndPrayToGod() crap. It's SIMPLE.
/proc. You don't have to go find the undocumented hidden Win32 call that only works on Service Pack 3.
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.
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
--
TC - My Photos..
I use linux, and I can see where this is going....
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.
I am a multi-platform developer. I write and maintain code on VMS, Windows, and Linux.
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.
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?
Well, I've done all sorts of stuff, I've done VB development, Access, Paradox and C++ for Windows. I've developed for the Mac, for embedded systems, for tons of flavours of UNIX, and the reason to use UNIX, for me, has to be the documentation. Mac has this advantage as well, with the proviso that you have to buy "Inside Mac". Once you've bought it, you've got a UNIX level of documentation.
/excruciating/ detail it describes the API, and everything it can do and everything that can go wrong.
/has/ the documentation available, but it's somehow much less accessible. Firstly it carries a lot of layers about with it: there are multiple image formats, and multiple string types and layers of API and not all of what you can do in one layer is wrapped in another layer.
/make it simpler/, not to hide that complexity behind wizards. The problem there is that the minute you try and do something the wizard isn't expecting, you're dropped off into this ocean of complexity with little or no support. This leads to a development style where that which is "possible" is effectively determined by that which the wizards support - and that often there is one way of doing things, because any other way, no matter how obvious leads to complexities and incompatibilities and huge amounts of effort. The example given of switching an MDI to an SDI project is a perfect example of this: you aren't supposed to. You're supposed to make that decision on day 1 of the project and stick with it. Access never used to export new toolbars along with the database: toolbars have to be built on each user machine. Corrollary: Access is designed to be used in a fashion where the development machine is also the deployment machine... anything else requires a fight.
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.
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...
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.
Now, for my personal rant - why are we learning this stuff backwards? At school they try to teach pretty interfaces and making your program user friendly... and then a year or so down the road learning assembly. Why don't we learn assembly first, then basic C, etc, and then by the time we're making those oh-so-spiffy interfaces we're turning out real-world aps that are actually useful. I can only code The Library Program so many times, ya know :) Doing The Library Program in first one language, then another, then another doesn't actually further my knowledge of programming. Give me a book of syntax and I can learn languages. I pay these people umpteen bux I don't have every semester to teach me programming, not pretty interfaces. Okay, end of my explosion about the status quo :)
> Emacs, vim, gcc, python, perl, tcl, sed, awk, grep, tar. All available under windows.
If you're using "Linux" tools under Windows, the question changes from Why develop on Linux? to Why develop on Windows?
--
Sheesh, evil *and* a jerk. -- Jade
No you could not add this to emacs as a "trivial hack". No way.
Why? Well, the compiler and the IDE talk to each other in DevStudio. The only way you could really get the same level of functionality in Emacs would be to build the first few stages of the C++ compiler pipeline into it.
If you type:
"pMyDoc->m_pWindo[tab]" it fills in the rest of the member variable. When you get the m_pWindowList you can type "->Head(" and the little tip window pops up and shows you what the arguments are for the Head method of pMyDoc->m_pWindowList.
Now, to do that in Emacs you would have to build code to:
1. Keep track of all temporary variables, their scope, and their type or class
2. Build tables of all classes and their methods and members, with the class or type of each.
The problem is, that's essentially the first stage of a compiler. It is NOT a trivial hack. You can't just do it by piping together a bunch of text parsing functions: you have to keep all this stuff in memory for decent performance - and even DevStudio 6 is pretty slow sometimes for this stuff.
On the other hand, under Windows you have to put up with MFC which has some good stuff but a lot of problems. You have to put up with all the different versions of Windows, which behave in different (undocumented!) ways and have different bugs. There are at least three occasions where I lost a night of sleep trying to fix things that worked perfectly under NT and blew up under Windows 95. (Microsoft fans who doubt me can get all the gory details by asking.) Without the source you often feel like you are working blindfolded.
My background: One month ago I started my cool new job using OpenBSD, Java, PHP, and Apache. I have used Linux at home for years, but haven't done serious development under it until now. I use Emacs because it's better than vi, but I don't think emacs is very good either. I want an editor that uses Alt- keys, not "Ctrl-X Ctrl-that Meta-x foo" for everything.
Simply put: I want Dev Studio 6 capabilities under a free operating system. That would be bliss. And if the IDE and compiler are all free software too.... ooohhh yeah baby.
The problem is, I believe that most free software developers just put in the huge effort to get good at vi or emacs (which are very powerful) but then don't have any incentive to create something better. And it could be better.
Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
2) Development tools: GCC is one of the best implementations of ANSI C++ available. Possibly the best. With exceptions, namespaces, templates and STL, C++ now feels like a mature language. And you can get an assortment of ORBs and other goodies. And if you ever wonder, "How did they do that?" you can look at the source.
3) Intuitive: I've always found the X paradigm of using callback functions to be much more intuitive than the Windows event driven big case statement offering.
4) Stable APIs: OK, Microsoft hasn't really been playing the API of the week club game since they mercilessly slaughtered OS/2, but if the APIs ever do change, you don't have that nagging feeling that the people who made the change did it just to piss you off.
5) Choice: You have your choice of toolkits, and many of those toolkits are portable to other operating systems.
6) Total Cost of Ownership: All the necessary development tools in Linux are free. By the time you finish assembling everything you need on Windows, you could easily have shelled out more than your computer cost you. And you'll have to pay for updates on a regular basis.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
The fact that this question focusses exclusively on the "what to develop in" aspect ignores the fact that computers are just a tool, and you use the right one for solving whatever problem you need fixed.
So the question should really be, "For what kinds of problems is Linux a better solution that Windows?" Answer that, and you have also answered which system to develop under.
Both systems have their strengths and weaknesses for development, and a competent coder can do a good job on either platform.
Adding toolkits to make Linux more gooey or Windows more command-liney doesn't at all help you answer the "which is more appropriate for this task" question.
- huge number of free (open-source) software floating around. You don't even need to borrow any code, you could just see how feature X is implemented (for example I remember looking at some Perl code and implementing smth similar in C)
- open standarts. Practically all kinds of Unix are compatible on source level because of that (POSIX, X libs and everything on top of them, i.e. GTK/QT, etc, is the same on every Unix). You don't have huge number of undocumented (or in most cases in Windows half-documented) APIs
- For scripting languages one big advantage is that kernel automatically runs interpreter specified after magic '#!' . That could be a quite helpful if you have a system with many scripts running each other. For example if 25 programs call script X, and you decided to rewrite it, say, in Phyton istead of Perl, you don't need to modify those 25 programs to run Phyton interpreter - you just modify the script.
/proc filesystem is very useful too - you could extract a lot of information from it.
For C/C++ programmer Unix have even more advantages:Practically all other advantages depends on language you use. Unix have incredibly good set of tools (gcc,make,cvs,gprof,etc). Most of them had been ported to windows as well, I don't have much experience with those ports. However, there are some advantages of Unix system itself:
For most shell scripts stuff like
Also, windows still lacks many shell utils. Last time I checked, pipes support was horriple - maybe it's changed in W2K, thought
Unix memory protection mechanisms - superior to anything I've seen. Most problems I have with C/C++ programs (especially raw C) are memory-related. Unix approach is very flexible: when program tries to access wrong address in memory it receives SIGSEGV or SIGBUS and could either intercept it and handle situation by itself or it could just create core dump (I usually trap SIGSEGV to output values of internal vars at the time of crash). Libraries like Electric Fence take advantage of this mechanism too.
Also, under Unix, application couldn't write in system memory. Under windows it's not supposed to - and as you could easily see none of microsoft's absolutely bug-free applications never ever crash windows, right ?
Support for debugging, like core dumps and ptrace(). Core dump allows you to save program state at any point, so that you could open it in debugger later. ptrace() allows you to trace process execution - in windows there are mechanisms to do this but all the debuggers I've seen (from SoftIce to TD) use their own functions, which means windows' default interface is almost useless. Also, you could attach your debugger to already running process, this is very usefull when debugging something like server process (in my case Squid proxy 2.3DEVEL3)
Much better development tools, like gdb and ddd. gdb, for example, is scriptable, you could easily program it to watch when variable changes to a specific value, when it does set temporary breakpoint in a specific function, trace that function until exit, and then if another variable has specific value set another breakpoint. I don't claim to be VC++ guru, but the only way to do it that I know is to press "next" and "step" buttons around 700 times. I tried. VC++ crashed somewhere at 500th.
DDD (Data Display Debugger) is really just a shell on top of gdb (or dbx or perl debugger). It's tread if you have complex data structures in your program and would like to examine them. DDD allows you to run gdb remotely, for example I ssh'ed to server (SunOS SPARC) from my workstation couple of times to debug a running cache proxy.
Some of these things could be implemented under windows, but things like watchpoints would require debugger to rewrite parts of OS.
Tools like gcc and emacs.
Emacs Is The Olny One True Editor, period !
Seriously, I never seen any other sools able to do everything emacs can, i.e.:
Please note that all the features above are supported at least for C/C++, Perl and Java, function navigation also works with List, etc
I've tried windows version of emacs, but they have very limited number of features compared to Unix versions
As for gcc, it's simply a C/C++/Objective C compiler with support for, if I remember correctly, at least 29 platforms, one of the best optimisers I've ever seen (egcs beats VC++ and Borland on every project I've seen), very powerfull error-detection mechanisms (I always use -Wall -pedantic options, it's way much more picky than either VC++ or Borland CppBuilder, but I never ever seen it bark on something that was not an error)
gcc is ported to windows, slow, but it's working
Last, but certainly not the least, user interfaces are better designed. For example, in Unix once you open socket you could use file IO functions like write() to write into it. When I tried to do it on NT I had 2 different results: General Protection Fault and BSOD. Unix system supports some very advanced functions, like for example, locking only certain parts of file (you could lock bytes 30 to 56 in a file, rest of the file is writable). X has very powerful API. One thing I really like is window being able to swallow (capture) another window. That, for instance, allows you to run any X application inside Netscape, provided you have plugin called xswallow. X does more than just windowing, it allows you to create atoms and properties - basically something like windows registry, only transparent thru network. Unix Netscape uses this mechanism to send "remote" commands to it's instance runnings, even if that instance is running on another machine. Similarly, XEmacs uses this interface to to connect to remote emacs process.
Unix has wide array of GUI toolkits, like Motif/GTK/QT/Tk. Some of them are much easier (for me) to use than MFC. For example GTK's event handling scheme is much better.
GUI development tools that Unix has look much more appealing to me than their windowsa counterparts. For example Glade - tool that creates GUI interfaces visually. There is a library called libglade that allows you to load Glage project on runtime. That way you could have "pluggable" user interfaces. I have yet to see anything like that for windows.
Component architecture upon which GNOME is build (CORBA) also seems to be better for me than COM. I'm not a COM expert, but parts of COM design I'm familiar with (for example the "proxy" components needed to marshall request over network) look like a kludge on top of badly designed protocol for me. CORBA is available for windows, but unlike GNOME, which is all based on CORBA, windows is based on COM, so practically you have CORBA and no components for it
Bottom line: learn every OS you can. Code for Unix - more fun ;-)
Obama 2012: our incompetent asshole is slightly less of an incompetent asshole than the other incompetent asshole !
A few years ago I decided to try C++ as a programming language for Windows. Until that point, I had been using Visual Basic to develop in the windows environment (mostly database stuff). Because certain things in VB can only be done by accessing the WinAPI, I decided to investigate the possibility of using C++. Since VB and Visual C++ came from the same company, I thought, their IDEs were probably similiar. I had learned C++ in some college classes on a Solaris Box, so I wasn't too concerned with being overwhelmed.
Surprise. Surprise. The VC++ IDE was/is NOTHING like VB's. Windows development in VC++ was more primitive. You actually had to define the main window, create it and create the message loop for the program. In all, in order to bring up "Hello World" in a single window you needed several lines of code and about 30 minutes. Over the next few days, I learned a few other things, but was always astonished that it took so much to do so little. Needless to say, I looked to explore other options.
About this time, Borland released the trial version of C++ Builder. They said that it used the Delphi VCL and IDE. Since my current job at the university included a T3 connection to my computer, it took only a few minutes to download and install.>
For those of you who've never used C++ Builder, think Visual Basic IDE with C++ syntax. In was able to make that same "Hello World" app in 5 minutes, including compile time. This, I thought to myself, was what M$ should have done. Since that time, I've used C++ builder as much as I could. It's stable and does NOT MARRY ITSELF TO THE OPERATING SYSTEM like all other MS products. If Borland/Inprise ever developed a BASIC version of VCL, I would push my company to switch in a heartbeat.
Microsoft's products seem to exist to promote themselves, rather than to encourage the programmer. Their documentation in Visual Studio is almost total garbage. I find myself using 3rd party books and tools just so I won't have to deal with it. I've even used the HLP file on Visual Basic version 4 to look up syntax after a similiar MSDN query on Visual Studio kept giving me the wrong answer consistently.
Regarding programming tools and options for Linux, J++ Builder Foundation a very good tool to use to learn JAVA. Borland/Inprise has a very good history of designing IDEs/GUIs and that much is apparent. The only downside is the sheer size of the APP. You'll need 128MB RAM to run the thing without pounding your disk cache constantly. If you want a good, powerful text editor, use EMACS. If you want a good, simple text editor, use Pico. If you are doing web development and need a server side language, there is a Java plug-in for Apache called JServ. PHP is also a good language, I've recently discovered. Also check out shell scripting. Unlike DOS, The command interpreter in Linux is very sophisticated.
As a coding environment, Linux offers the best choices and widest variety. Once you start, the thought of going back to Windows will make you ill.