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.
Re:Give Emacs a Chance! (Score:3)
There are 2 features (out of the box) of emacs that I just can't live without.
1. Dynamic expansion - start typing a word press alt-/ and if that word exists in any file you have open, it will complete it for you, cycling through the possibilities. Greatly improves my code readability since now I can have informative variable names
2. Coding/indent styles - Once you set up your preferred indenting style, just have to hit tab to put that line in its rightful place. ctl-c ctl-q and the whole damn file is indented the way you want it!
There are a million other reasons emacs is cool and if you don't have one, you can easily make it do what you want. Emacs does take some time to coax it to behave the way you like, but once you are there.......you shall never return to the dark side.
Advantages (Score:3)
Read/Write almost any disk format in existance
Cross-platform testing, using WINE or IBCS, -without- rebooting or switching machines
The Penguin logo is cooler than the flying window
Ability to test out on multiple network configurations
Linux is gaining mindshare & market share in the server arena. Microsoft isn't.
Linux is gaining mindshare & market share in the home network market. Microsoft isn't.
Linux has a guaranteed future. Right now, Microsoft doesn't.
Linux is future-proof, as it can migrate to a pure 64-bit OS. Microsoft 9x is DEAD, in 2032, and companies might not want another Y2K budget fiasco.
CBQ, RED, ECN, RSVP are all supported, making Linux a powerful network machine and DDoS-proof. Windows is not.
Linux supports a wider range of RAID configurations (so long as you don't use 2.3 or 2.4, just yet!)
Linux has better swap-handling, making development quicker. (Faster compile times, less disk thrashing, etc.)
Linux has -real- FS journalling. MS Windows does not.
Re:Why develop for Linux? (Score:3)
How the hell did that get in there?????
The advantage? (Score:3)
The big advantage is that your code will run under Linux (and other Unixish systems if you do your job right). That's a big deal, because you won't get bug reports about other programs crashing yours...and there are way fewer pain in the ass liberery bugs...and when there are it is far easyer to find them with the source to libc (or libcurses, or libfoo) and either fix them, or code around them. Way way way nicer. At least IMHO.
Preach On! (Score:4)
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 :)
MSVC Plugins (Score:3)
Re:except (Score:4)
If you're using "Linux" tools under Windows, the question changes from Why develop on Linux? to Why develop on Windows?
--
General Comments (Score:3)
1) NT == IDE (can use CLI makes on NT)
2) Linux == CLI (can use IDE on Linux/Unix)
Advantages of *any* unix flavor:
1) Client/Server nature of X (can sit at your workstation and work on any other unix box transparently. no need for pcAnywhere)
2) Industrial strength "kill" (i can issue kill -9 [pid] and *know* that the process will die)
3) More sophisticated shells (BASH, C shell, Korn shell, Bourne shell all leave cmd.exe in the dirt). Though one can get these equivalents on Windows, they're there on Unix.
4) lsof (view which processes have files open -- very handy on occasion)
Advantages of NT:
1) Tightly integrated toolset for MS development tools.
Tools/Utilities:
1) The tools/utilities such as vi, emacs, sed, awk, etc. can all be obtained for Windows. However, the Unix versions typically are more full-featured.
2) Editors are definitely a matter of personal preference. Personally, I'm no fan of emacs. There's a nice GUI editor called "CoolEdit" (http://cooledit.sourceforge.net/) [sourceforge.net] that only requires Xlib. See above advantage of the client/server nature of X. Commercial editors like Visual Slickedit (my favorite) is available on Windows, most flavors of Unix, and other platforms (OS/390 even).
3) I've come to the conclusion that it's often better to stick with scripting languages like Perl or Python (my favorite) instead of writing shell scripts or batch files. They're more powerful, usually more readable (at least in the case of Python), and definitely more portable.
4) Using *multiple* compilers on your source is often advantageous since one compiler may catch some things that another will not (as well as giving a check on compiler dependencies).
Re:Give Emacs a Chance! (Score:4)
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)
Well... (Score:4)
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.
Book Recommendation: The Unix Philosophy (Score:3)
Re:except (Score:5)
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.
Re:Give Emacs a Chance! (Score:3)
No you could not add this to emacs as a "trivial hack". No way.
OOOooo! A CHALLENGE! :-)
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.
I disagree, but do continue. I'll explain why later.
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.
Several options here for the budding Emacs hacker to get going on. For Emacs users already using Imenu and Speedbar, much of the functionality to chase those variables is in there. Spawning either inset windows or new frames in Emacs is not a difficult task. Dynamic or stati c abbreviation expansion can be used to fire up lisp functions as well as complete text, so having a hook run at buffer entry to set up the abbreviation tables is trivial.
Now, to do that in Emacs you would have to build code to:
That's why I noted that with TAGS support, most of the work to implement this hack is done. TAGS databases already include a complete list of structs, variables, functions and other such data. Therefore finding out what the definition contains is not difficult and neither is parsing it. Emacs is good with text :-)
Cheers,
Toby Haynes
Re:Why develop for Linux? (Score:3)
Re:Preach On! (Score:3)
Which bring me to my question: Why do people give small schools a bad time? I've been to UT Austin and UT San Antonio and I still prefer my experience at SWT in San Marcos over these two "better" schools.
Re:Preach On! (Score:3)
When I was in college my advanced pascal class (this was 94ish) introduced us to the concepts of pointers, memory allocation, constructors, destructors and object orientation.
I was fscking lost. When did you dereference again? Do I have to allocate memory? Huh?
The semester after I took assembler. Suddenly all these concepts came to life! Wow! I know what a string is now, I know what I'm actually doing when I allocate memory! Wow, suddenly I understand why I need a constructor and destructor! Null terminated string is not just a term but an idea I can visualize in my head!
That's my personal experience with this anyway. YMMV. However, I gotta agree with anyone who says that it is the Right Thing to teach from the ground up. If people had to take an assembler class *before* they got to take their "become a high paid programmer by cranking out crap in VB in 6 weeks" class, I think we'd have better programmers out there.
Now I don't begrudge people needing apps Now(tm). A friend of mine does VB programming and I admit that it has it's place. Being able to produce a program and worry about UI rather than worrying about HOW it's doing it is a good thing. But there *has* to be a nice melding of the two.
Advantages developing on Unix/Linux (Score:4)
- 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 ;-)
Re:Borland's VCL IS the way to go... (Score:4)
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.
Re:Where did this myth come from??? (Score:3)
You are right that the first experimental versions of UNIX predate C, but those versions were not the versions the public saw later when UNIX finally escaped from Bell Labs and saw the light of day. The switch to C happened very early in the development of UNIX, and C was designed explicitly with the needs of the UNIX developers in mind, so it meshed very well.