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