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?
where I spend my days we mostly program for windows, but we do our programming on a Unix (solaris) platform. Why? The multi user environment provided by Unix make file sharing a breeze. Code control systems (CVS,SCCS,etc) are more widly avliable (and I think more through). My answer, it's easier to share :)
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...
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
Jon Erikson, IT guru
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!
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
- 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 don't know about anyone else, but the programs I develop are intended to run under Linux, so I develope under Linux. If I was intending to develop Windows apps, I'm sure I'd develop them under Windows. Yes, there are cross platform development environments, but to be frank I couldn't care less about Windows (95 has just trashed two motherboards for me so I'm in a very anti-Windows mood atm).
;-)
Anyway, what I'm saying is, if the programs are intended to be run only under Linux, Linux is a good choice for development, is it not?
Now weary traveller, rest your head. For just like me, you're utterly dead.
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 see the difference between Ms-DevStudio and all the Linux tools a bit like the difference between coding in VB and C++. If all you need is a quick way to put up a simple program, it is easier in DevStudio and all its wizards that create stuff for you. But once you need to maintain this code for a while, or wish to do something the wizards did not provide for, you start to run into problems. Under Linux the initial costs of starting up are a bit higher, but once you have a project going, there are (almost) no limits to what you can do, all files are in documented formats and plain ASCII, so you can just go and edit them. Distributed projects are easier to maintain, with a publicly available CVS repository where anyone can get the latest development version, and a standardized way to submit patches etc. And of course the scripting facilites under Unix make it so much easier to make (semi)automatic regression tests and other advanced stuff..
In Murphy We Turst
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 find that Linux is more consistent that Windows. Unix has a philosophy -- everything is a file. It's not followed 100% (as in Plan9), but it's pretty widespread. Windows has no philosophy; it feels like a mash of unrelated ways of doing things.
.c file at the implementation of the function in question, and my questions were answered.
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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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.
We are doing windows coding at work. Before all I ever did was do a little bit of *nix coding at home and school, and the biggest difference is that because Linux/GNU/BSD/etc is an Open platform, the APIs are actually followed. You can use code directly from an MSDN examle in your windows project and it won't work. Also under *nix you get all of the excellent POSIX calls. You can't use POSIX under Windows, it's not there. I had to write a string parser for a project we were working on without the use of POSIX regular expressions, and BOY was that a pain in the ass.
A wealthy eccentric who marches to the beat of a different drum. But you may call me "Noodle Noggin."
Quando Omni Flunkus Moritati
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.
There are a lot of compelling reasons to develop under Linux in my opinion. It's important to note that disclaimer in that sentence however: In my opinion. My first experiences with programming were BASIC on a Commodore Pet. While in university I did a lot of programming under UNIX and became used to the pervasive way in which text and data could be handled and manipulated.
I also realize that if it weren't for this sudden immersion I wouldn't find these reasons all that compelling. I've coded in MetroWerk's IDE under MacOS as well as with the shell-like IDE MPW (Macintosh Programmers Workship). If I had first used an IDE to program I'm not sure I'd ever have really felt as comfortable without one. Most of the reasons that I feel so comfortable programming in a shell environment under UNIX are due to the ability to manipulate data with PERL, sed, awk, sort, cut, paste and so on. I'm not sure that most people get data in alien formats (if you produce the data, you've got some control over the format, if you produce a format that you can't use then you didn't produce a very good format).
I've toyed with IDE's under linux but haven't ever felt the need to change. Under MacOS I prefer an IDE. Under MacOS X I will probably prefer command line utilities.
I think the important thing with anything is to be comfortable with what you are using regardless of whether somebody else feels that there is a better opinion or not.
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
I think, therefore thoughts exist. Ego is just an impression.
"Unix it is simply not documentated as much."
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
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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.
pure and simple.
When you talk about anything, it pretty much comes down to cold hard cash. Everyone wants to know "What's in it for me?" Well, i'll tell ya. Money! If you look at the market share linux has gained in the past few years you see what's going on in the computer world. More and more people are switching to linux. Linux's market share has gone from almost nil, including servers and (especially) home users, to brawling for second with MacOS - that is one hell of an accomplishment. What does it mean. People are going to keep switching to linux and there's a veritable gold mine waiting to be dug in the software market. The same people that are installing default RedHat with GNOME or KDE and trying to figure out why linux is so "cool" are the same people that want Apps for linux.
Well, it's not free....these people are coming from a closed source, pay-to-play environment. You give them good software, open-source or no, and they'll pay for it!! If your friend were to develop an audio app that rivaled something like Rebirth (i swear if someone mentions FreeBirth i'm going to flip my lid)....i would be willing to shell out the cash for that. And so would a LOT of other people that are looking for that type of software.
Why develop on linux? Because there are a lot of gaps out there as far as linux software vs. windows is concerned. And as more and more people switch to linux from windows, the value of closing those gaps is going to increase exponentially. Develop for linux and make a BUNDLE! look at Loki, RedHat, VALinux, and all kinds of others. The way I see it...you either lead, follow, or continue to develop for Windows.
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
Take for example Aegis. Find me a tool like that for Windows which costs less then 1000$ per seat. Or compare the editing power of UNIX editors to the pitiful editor built into most IDEs - not to mention their brain dead build process (BTW, both Emacs and VI can and are commonly used as a UNIX "IDE" to great effect). It goes without saying that you can't replace your IDE's editor or build process, even if you are willing to pay.
Sure, UNIX developement tools are harder to learn (they are not harder to use). But one can hardly claim to be a serious professional and dismiss the UNIX tools as too hard to use. These tools simply assume a power user - one willing to invesrt the extra effort to get the (large) additional benefits. That's what being a professional programmer is all about.
I have seen the future, people, and in it there are a multitude of computing devices, not only PC's the way we see them now, but also PDA's, set tops, even computers in your goddamn fridge!
Sucessful development in the future will be by people who understand standardization, integration and adherence to open protocols. From my linux box I can, using protocols like X, http, nfs and things like CORBA and Java, share data and apps with other linux machines, solaris, BDS, hell even Windoze if I want, and using this stuff is kind of natural when developing on linux as most open source software and libraries out there are based on open standards, making portability and interoperability much easier
Contrast this with our poor friend who is stuck with such hideous and non stardard thinks like MFC (ugh) anc COM (double ugh!)
Now excuse me while I port gcc to the toaster
The advantage of developing on Linux (or just about any Unix) is that it's a consistent, simple, and well-documented environment, with good portability to other platforms. If you develop on Windows as your primary platform, it's easy to get trapped into using hidden and undocumented API's that don't behave consistently from version to version, and it's real easy to wind up with Windows-only code.
Windows-only code isn't automatically a Bad Thing, but it does reduce your options going forward, and it links you inextricably to the Beast. Should there be a strategic need to change platforms a some point, it's going to be a more difficult task to go from Windows to Unix (or whatever) than the other way around.
That said, Visual Studio is a fairly slick IDE, though there are nice IDE's on Linux, as well. If you're developing for Windows, Visual Studio is really nice.
- -Josh Turiel
-- Josh Turiel
"2. Do not eat iPod Shuffle."
If your friend the developer is developing software for Windows, then it surely makes sense for him to develop in Windows. For him, he needs to use the right tool for the job. MS Dev Studio isn't fantastic in all areas, but it's not bad, and most importantly, if he's developing Windows applications, it's probably going to be easier than cross compiling from a Linux platform. Also - Windows has all the other development tools you could want - CVS, RCS etc... and if you need to do lots of scripting stuff for maintainance, there are all the GNU tools - remember, they're avaliable for Windows as well. As Mr. Stallman would say - "It's GNU/Linux"...
A young programmer once asked Stallman: "How can I do Rapid Application Development for Linux?" To which Stallman replied: "If you want to develop applications rapidly, I suggest looking into Scheme."
Of course, what the novice really meant was "how can I cook up pretty-looking programs with the bare minimum of knowledge and effort and call myself a Linux programmer?" In this (poorly paraphrased) story, Stallman illustrates what I consider to be a fundamental difference between the school of thought that says "get it done the quick and easy way" and the school of thought that says "get it right".
Whether this dichotomy is related to the Windows/Linux development dichotomy remains unanswered... just take a look at the source code for a typical "Open Source" Linux project. Ah well.
To the editors: your English is as bad as your Perl. Please go back to grade school.
I use Visual Basic at Work :-( but now I have access to a UNIX account I'm using Perl to autogenerate most of my code (all the fluff thats needed to support the business logic which is what I really ought to be writing).
My questions for Windows programmers: How many times have you been annoyed because VB's compiler gives up on the first thing it finds? Do you just shrug it off when the SourceSafe integration fails to integrate? What when VB saves your work in a completely different place to where the rest of the project is, and hides this detail from you (or have have you learned to work around that one)? "Wot No Layout Managers!?!". Would you like to be able to switch editors at will and still work?
I think the last question is probably the most important. Under Linux I can switch tools as I need. I can use different tools to the rest of my team and we can all get on together. There are development environments for Linux that have things like Intellisense if you want to use them. I use Vim or Emacs depending on the job in hand. Because so much in Linux is text based I have a wealth of really powerfull text manipulation tools to work with. The perl example above shows this.
A lot of work now is web based. If you want "Commerical Environments" then look at things like Enhydra, Java, JBuilder, ... A lot of web work uses the likes of Perl and PHP and Apache as the server. Linux is really strong for those languages. Also the ability to fully remotely administer a Linux (or any UNIX) Apache server really helps. People where I work are fighting NT at this moment because they can't remotely administer the IIS server.
In terms of environment. Linux, in comparison to Windows IMHO is a really well designed logical platform. When you look at how the file structure is organised and why it really seems to make sense. I've explained things like why /bin, /usr/bin and /usr/local/bin to people and though "That is good". Also why PINE has /etc/pine.conf.fixed, /etc/pine/conf and most importantly ~/.pinerc. The UNIX/Linux world has already had to solve the problems of dealing with a multi user environment, problems which the Windows is now starting to see as Microsoft bolt multi user capabilities onto Windows. It seems that system/user preference handling in WinFrame is particulary "interesting"
You can do all of those things under Windows.
Emacs, vim, gcc, python, perl, tcl, sed, awk, grep, tar. All available under windows. So you have all of that PLUS nice GUI IDEs.
I haven't found writing console apps any more difficult under Windows than it is under Linux. Writing GUI apps is as difficult or as easy as the underlying toolkit makes it. You don't have use MFC under windows, anymore than you have to use raw xlib calls under linux.
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.
I think it's rare that you have to do a project that has to work under both Windows and Unix so that you'll have to make a choice on which of both to develop. If it's a pure Windows or Linux app, there's no reason to do it under the other OS. If complex tools are involved that must be used, again the choice has been made for you.
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.
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
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
What exactly is "productive" about rebooting because your beta app crashed the system or you're not sure whether the app might work after a reboot?
(intellisense, integrated debuggers,
emacs, emacs (if you need it), perhaps kdevelop
debugging a web page, its server side scripts, its client side scripts, and binary server side code simultaneously).
On Unix, you can do as many things simultaneously as your mind can handle, and that is the only barrier.
What exactly have badly documented system calls to do with a "component architecture"?
what the Linux developer community doesn't get is that Microsoft goes out of its way to take the chore out of programming and allow you to concentrate on the problem you are trying to solve.
More like "allow you to concentrate on paying their license fees, their support contracts, suffering DLL hell and frequent reboots. In what way does Microsof "go out of their way" to do anything except squeeze more money out of their customers?
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Multi-file editing (and opening each file only once)
Integrated editing/compiling/debugging
Availability on both development and target platform
Shall accept files written with other tools and shall generate files which can be modified with other tools
Useful:
Syntax highlighting
Search by variable/function/classes
Version control
MMI visual editor
Optional:
Graph generation
Project management
Conclusions : I'm quite happy with Emacs, but I might taste somenting different from time to time.
Ciao
----
FB
Nuff said.
Exactly what is intellisense? Personally, I hate
emacs, but love vi. (Which can be run under
windows too. I can't think of any features I'd like that vi doesn't have.
X is not that unstable, bloated, debateable, but still pretty solid, not as solid as the kernel, but solid. At least when X crashes, 97% of the time a reboot is not required. Even if X crashed as much as windows, at least time to recovery is short, as you can immediately restart X without reboot.
As to the blackbox model, that is plain bs. In the OSS world, most things could be treated as a black box, and work fine. You never *have* to look at source if you don't want. You certainly can't argue that it *hurts* you to be able to see how the calls you need are implemented.
And dependence on the registry is NOT akin to depending on the file system. That is the dumbest comparison I have ever heard. The registry is a centralized database of settings used by programs stored in a proprietary format in a singular spot on the disk, where if one thing corrupts it, many applications cease to function, a central spot for malicious programs to look for sensitive information. Sure something can corrupt the superblocks of a unix filesystem, but windows filesystem is also vulnerable, if not more so. The registry adds whole new dimensions of problems in security, reliability, and system administration. I have seen registries get so trashed before, and I have grown to hate having to be the administrator of such crap.
XML is like violence. If it doesn't solve the problem, use more.
The compiler in MSVC++ doesn't support the latest C++ standard, especially in the area of templates. In addition, it doesn't support the Standard C++ Library as described in the latest version of Stroustroup.
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.
I beg to differ.
What about the fact that you have access to a truly complete definition of the API? Does this guy realize that there things that MS does with their code that others can't because the API is less than fully documented in the public arena?
Additionally, if you want to compile on a MS platform you pretty much have to shell out several hundred dollars for your tools. On Linux your tools are included with the distribution that you can acquire completely free from many places.
Let's see here, Linux has:
- Stable systems
- Free OS
- Lots of FREE tools, Woohoo!
- Open API
Whereas, Microsoft has:- Questionable stability
- $200+ for the OS
- Expensive tools
- Only a SEMI-open API
I think Linux wins 4-0!!My office has been taken over by iPod people.
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.
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.
On the subject of Stevens, I have "Advanced Programming in the Unix Environment", and would thoroughly recomend it to anyone wanting to get into "serious" Unix-based programming.
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
It's official. Most of you are morons.
The answer for 3.51 was "buried on some cd somewhere, notincluded with the default NT install". The answer for 4.0 is, I assume, the same. I will challenge you, or any of the other MS apologists, to name one commercial program successfully using NT's POSIX module.
--
-- Slashdot sucks.
3) "But what happens when you want to distribute your code and it relies on the 'fixed' code?"
.m". That's one (fairly simple) command under Linux (using RCS anyway).
Put a workaround in your own code but use a fixed kernel if it exists. Eventually you can remove the workaround. Are you saying it would be better if you COULDN'T fix (or even see) the kernel code?
4) "Hey, some of us prefer a point-click-drag to 47 keystrokes."
Please tell me how to use an IDE to do the following: "Mark all files currently tagged V31-BETA2 with V31, other mark the head of the tree V31, skip files in the ldap directory and anything that ends with
--
Less money, less admin, less machine--more power
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
>> 3) I too have had to fix the source code to Linux once -- for my own use. But what happens when you want to distribute your code and it relies on the 'fixed' code? Do you have to wait for your fix to be integrated into the mainstream? Furthermore, though, why should you even have to look into the source code? Ao good API should leave nothing questionable enough for the source code to be consulted.
And you wish to wait on Microsoft to integrate fixes to the proprietary source? All the open source setups that I have seen have responded much faster verging on infinitely faster than any company on a bug fix. And I say 'inifinitely' because many times they simply never respond at all and never fix the problem. The beuaty of open source is that if you are inclined, you can go fix the bug yourself, send the patch with the fix to the maintainers and that saves them the time of figuring out the bug themselves.
You miss the point of an API. An API is to abstract out everything that a person needs to know about how to use this 'black box'. Regardless of how well they did the abstraction, the black box may simply be functionaly broken. An API has nothing to do with that. Open source allows you to go fix that bug and continue on in your development.
RedShodan --------- Never underestimate the bandwidth of a station wagon full of tapes.
Generally the biggest problem with converting an MFC program from SDI to MDI is that you've made all sorts of assumptions about your document being the only one in the application, and similar assumptions about your view. If you've been true to the Doc/View architecture, and assuming your MFC code is clean it really isn't that hard to change from one to the other. The easist thing to do is create 2 projects from scratch which are identical except one is SDI and one MDI. Do a diff and see which code is different. It's not a lot - mostly the Application initialisation.
As for MSDev vs Emacs: I've seen both in use where I work and that's on Windows. When given the choice, I prefer to write my code using MSDev because I like the IDE. Even when coding for Linux, I prefer the layout and operation of the system. Then you switch windows and make (assuming you have Samba and share code dirs). Others use Emacs on NT for development.
I've never crashed NT with Dev Studio. Developing on 9x is suicide - you learn to regret it really quickly. Personally I don't mind Win32 development. YMMV of course, but Microsoft really does go out of their way to make things easier for developers. With tools like MSDN on DVD (over 6G of indexed help), Linux's man pages really pale in shame. The only redeeming grace is the "ultimate" documentation - the kernel itself.
I will say it again: YMMV.
(Brace for flames - this is Slashdot).
John Wiltshire
Fear: When you see B8 00 4C CD 21 and know what it means
The developer in question should be looking at making his/her code run across Unix, not Linux.
Portable code is the key. If they write PORTABLE code they can run on Solaris, AIX, HP/UX, BSD, Mac OS X, etc.
Now, why develop for OpenSource Unix *FIRST*? As another had said....you have FULL access to the source code. You can trace the flow from your code to theirs. And figure out if the error is in their code, the written docuemntation you used to produce the call, or the error is in your code.
The only thing to watch out for is GPLed code if you don't want your code under the GPL. Odds are your firm makes its profit from intellectual property expressed in the source you compile and sell. *IF* someone makes a charge that you have GPLed code in your product, you will have to defend this charge. Such defense could be as simple as a statement "No we don't" to hiring a lawyer to explain to a judge why the lawsuit over the GPL needs to be decided in your firms favor via the presentation of your source code to a judge, paid experts, etc. How do you avoid the GPL? Just read the licences. Some are as simple as public domain. The licence on PostgreSQL is an example of a simple one that is not PD and specific to one program. Some are more verbose and complicated.
If the code *HAS* to run on Windows, libraries exist for Unix to Windows portability. These cost $, and slow up operation, but somehow money and speed are not an issue with M$ software.
If it was said on slashdot, it MUST be true!
man mount:
hard: The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. This is probably what you want.
soft This option allows the kernel to time out if the nfs server is not responding for some time. The time can be specified with timeo=time. This option might be useful if your nfs server sometimes doesn't respond or will be rebooted while some process tries to get a file from the server. Usually it just causes lots of trouble.
--
Less money, less admin, less machine--more power
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
As a developer of multi-platform applications for almost a decade now, I can say that there aren't any significant advantages in the actual development of apps across different platforms. SOme asre better for some things, and others are better at other things. The one advantage, and the best advantage, is that you can break into different markets and/or make yourself more marketable. Here's what I mean... The chances that Windows will be where it is 10 years from now looks pretty slim. By learning and porting applications to other OSs, you create a user base in a growing market. If Linux takes off and grabs real market share, and/or Apple ports OSX to Intel machines, how pretty will you be sitting when businesses and consumers realize that your apps are available across all three; and can share data transparently? Answer: pretty damn sweet. If you are a developer for a business (not developing "shrink wrapped" apps), it is also a good idea to get your feet wet in developing for other OSs. Again, MS probably won't be the juggernaught it is today; and you will be a lot more marketable if you can develop on other platforms.
I am Slad.
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...
I find that laziness drives me to code on UNIX, because the UNIX little-tools-in-a-pipe philosophy usually means that I only have to write a tiny program to do what I want, and in general it only needs to handle input from STDIN and output from STDOUT, so I don't have to worry about
In a Windows environment, it's likely I'd feel the need to write some sort of GUI. Windows would not provide me with the rich set of CLI tools I'd need to wrap around my quick and easy program to make it fully functional. It's possible I'd have to write that functionality into my own program instead. Sure, you *can* install GNU sort, cut, awk, sed, tr, etc. on Windows, but by the time you've done so you may as well have installed Linux or BSD.
--
Why?
Because since the code is open, as a coder, you are given entirely free reign to do what you want to do, how you want to do it, and are "empowered" to actually discover and remedy bugs.
Because you are not at the mercy of a large, faceless, corporation which dictates the APIs and specifications to you, forces you to use certain tools, locks you in, and makes you pay through the nose.
Because Linux, Unix, and open source *wants* and *needs* you. Microsoft couldn't care less. There are beanie weenies falling all over themselves to become l33t VB c0ders.
Because it is the Right Thing.
It's 10 PM. Do you know if you're un-American?
Nice troll.
I really love it how Unix has 10000 text editors. But I'd prefer one that works
Try Nedit if you want it to make an easy switch from Windows.
And stability isn't an issue for many windows developers who use NT/2000.
That's funny. I developed on NT 4 for a few weeks and I had processes lock up on at least a dozen occasions - other times, I had the system start doing strange things that only a reboot would fix, like displaying the mouse at a displacement from where the hits were actually occuring. ActiveX controls would crash constantly, and couldn't be restarted - also requiring a reboot. On a number of occasions the mouse cursor just froze, for periods up to 30 seconds. Maybe your experience was different, after all, as a Microsoft Troll perhaps you spend most of your time camping on a web browser and not actually developing?
--
Life's a bitch but somebody's gotta do it.
Visual Studio was a lot better than I expected from Microsoft, but it's not that good. It has a damn lot of features, but many of them narrow your thinking so much that you tend to produce the Same Old Windows App every time.
;))
Here are some of the problems I've run into in Visual Studio:
Project management is so complicated and "behind-the-scenese" that projects can easily get corrupted and unbuildable.
BAD support for advanced features of C++, especially exceptions and templates (yes, worse than g++). One time we took a working, warning-free program from g++ to MSVC++ and it crashed the compiler. Another one couldn't compile because VC++ put a 255 character limit on the length of the names of instantiated templates.
AND IT ASKS YOU "Are you sure you want to recompile?" when you PRESS COMPILE!!
And of course, linux features unmached by windows:
Availability of library/kernel source
Awesome emacs features like smart syntax coloring, automatic indenting, regexp search/replace, keyboard macros
Elegant, scriptable project management
Not having to worry quite so much about compiler bugs.
Of course, the forms designer is the best way to make windows in Windows, and some other tools are invaluable. But as much as I'd like to be able to make apps for the OS I use as my desktop, I've just given up on dealing with MSVC. (And I have no patience to learn the twisted API and compile with cygwin or something
I have written programs using these tools under windows. The experience is not the same. Windows just does not work like Linux/Unix does. Unix has been molded to fit the C language. Working with external programs, libraries, everything is a basic function call in C, whereas under windows, this is far from true.
Eh...
There are several libraries that have ports for both environments. I suggest using one of these if you are developing cross platform, less code to modify. The only time that I would suggest not using them is when you need fast, optimized code.
Eh...
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.
"My cat's breath smells like cat food." - The Tao of Ralph Wiggum.
There is easy to use and easy to learn. MSVC++ is easy to learn. Emacs is easy to use. Seriously. There is a bit of a learning curve but once you understand the basics it becomes much more clear.
Another poster in this discussion mentioned that yes, you can get ``intellisense'' in Emacs. Finally, if you are using the menus in Emacs then you clearly havn't tried to use it. IMHO you shouldn't have to use Emacs' menus. (M-x is your friend ;-)
Finally, the best reason to use Emacs (which I use in windows too, btw) is that when coding, hiting tab, instead of inserting the tab character at the cursor, properly indents the current line. It's great
--Ben
Windows gives me much more freedom (speaking as a programmer). I can actually achieve what I want to do quickly, than spending hours wading around in irrelevant details and reading source and trying to figure out if it is even possible to do whatever.
Emacs in nice in some ways, but it's a dated dog in others. IDEs from Microsoft, Borland, and Metrowerks are annoying in different ways, but make so many things *sweet* (the Microsoft's being the worst of the three, because they insist that MDI programs are good). Similarly, Makefiles are nice sometimes, but once you've lived without them then you wonder why you went through all the trouble in the first place. Of course, you can use Makefiles with Windows compilers as well. The three big compiler companies all ship command line tools, so heck, you could even use Emacs under Windows if you want.
There's no clear answer yet.
Emacs is truly awesome.....I can't stand any other editor anymore. :)
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.
"I have been around the world and found that only stupid people are breeding" -- Harvey Danger
I've recently found out about KDevelop and it's pretty much an IDE like MSVC. I'm not quite sure if it has the Intellisense option, can't check that right now. http://www.kdevelop.org
Karel Bemelmans, karel@narfum.org http://melvin.narfum.org
_______
2B1ASK1
True, I've often used it as a paperweight.
...the single, most effective "tool" to debug applications quickly. Combined with RCS, you can fix a once-in-a-lifetime bug by checking a core dump from something that blew on a production version of an app that you built two years ago.
I refuse to develop under a system where I can't examine the core space of a crashed program. It's stupid.
--
Do daemons dream of electric sleep()?
Use emacs to edit and the 'ddd' frontend to gdb to debug.
I spent over a year working on a large commercial product (Lotus Domino) with MSVisual Studio and was almost convinced that Visual Studio was a better place to develop then linux because of the debugger. THen I discovered ddd. First of all, it supports all that "IntelliSence" shit, and it has the <B>Best</B> data display capabilities i've seen anywhere. You have to try it to believe it.
Emacs has more features that are better integrated then the Visual studio editor anyway.I wonder why such excelent solutions aren't more widely used.
I really don't agree with this. I develop on WinNT using Visual C++ for a cross-platform project on Win32, Irix 6.5, SunOS, and Linux. We don't use cross compilers, but the IDE makes it worth it. Code completion and having the MSDN library is _MUCH_ easier than sifting through man pages.
Your preference for MSDN and code completion over referencing the occasional man page aside, you haven't said anything that addresses the original concern of the post you replied to.
Large projects developed using proprietary IDEs will be difficult if not impossible to manage in another 15 or 20 years (and, as Y2K showed us, the code will need to be managed many years hence). Using industry standard, human readable makefiles may not be as snazzy as running the latest glitzy IDE and project manager, but a developer in 2030 will have little trouble rebuilding the project from the source if need be. The same developer, confronted with a large project developed under Microsoft's IDE, for example (Microsoft isn't the only culprit, there are competing IDEs with the same problem), will find it nigh unto impossible to find a copy of a 20 or 30 year old IDE. Recompiling the project will be next to impossible and very expensive, possibly more expensive than the code is worth.
Now, undoubtably someone will argue that this is doing the hypothetical company and developer a favor, that 30 year old code should be disgarded and rewritten anyway. In some cases perhaps, but in some cases perhaps not. "hello world" isn't going to be any better fundamentally if you retype the code 30 years from now or recompile code written today. In any event, the decision whether to discard or reuse code should be based upon the merits of the code, the time/cost required, etc., not upon the unavailability of some ancient, proprietary IDE needed to rebuild the damn thing.
The Future of Human Evolution: Autonomy
Your co-worker is correct -- if you are building Windows apps, most tools are readily available under both systems (albeit much less expensive and more malleable under a free U*ix). I probably would agree that the IDE's available under Windows are somewhat better, particularly for developing Windows apps.
But if we want to compare pound for pound, the bottom line for me is the command line.
The real difference is that you have a serious, real, command line and shell that was made for doing serious, real, complicated things. The Dos-like approximation under Windows is virtually useless in comparison. Windows are simply a nice means to have plural consoles on the screen at the same time.
Its hard to explain why this is so to someone who hasn't done it, really and seriously, both ways. The command line places massive power at your hands -- and the capacity to manipulate text, therefore manipulate programs, appears to have been highly underestimated by your colleague.
Everything else is a wash, or in some cases only slightly favors one system over the other. At the end of the day, its the command line, silly.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Many of these were good tools, some bordered on great tools.
It was while I was deeply involved in Visual Basic (VB) that I began to get an uneasy feeling. As new versions of VB were being designed and released, it seemed that I was spending more time learning the nuances of the tool, and less time honing my skills as a programmer. Even worse, MS would come out with a set of tools, then abandon or alter them a few months later. Gods help the early adopter.
In 1994, I started working in a group that was almost exclusively Linux. The learning curve was somewhat steep, no doubt about it. But the unix toolset was so rich, and the tools built upon themselves in such a manner, that instead of a vicious cycle of adopt/upgrade/abandon/relearn, I found that all my unix learning built on itself.
The unix command line, with its concurrent filters and pipes, makes it very easy to build and reuse tools. gcc and gdb, coupled with emacs, made for a very powerful programming environment.
But the essential difference between programming under Linux and programming under Windows is that in the former you are using tools, and in the latter you are using products . When MS wanted to push the adoption of OLE (Object Linking and Embedding) in their OS, they spent a great amount of time adding OLE features to their languages. At the time, users may have been clamouring for better OOP constructs in VB, what they got was whatever was on the MS agenda.
Who do you want building your tools?
i) so you can annoy users of other Unices when your "portable" code won't build for lack of linux/soundcard.h
ii) so when your application hangs the X server you can shrug and say "well, what do you want for free?"
Rob
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.
I imagine that someone has already made this point, but I'm on the run, so I'll toss in my $0.02. This will probably get lost in all the noise that this story is sure to generate.
I'm a Windows coder. Don't flame me, I've got my reasons, and it's irrelevant to my point. Just get in your head that I'm experienced with the Windows enviroment.
I have written code in Linux. The networking class I took in college made us use Linux. While I'm not experienced in Linux, I know the basics.
The single thing that really attracts me to Linux (*nix in general, really) is the elegance of the APIs. The beginnings of the API set was written with some very careful thought, to make the interaction between the APIs nearly seamless. I'm a big fan of tight, elegant code - and I continually get frustrated in Windows because the APIs almost force you to create bloated code. I recently rewrote a simple port listening project that I had done in that class - the 50 lines of code for Linux became 300 under Win32. Why so much? Multitude of reasons, but the inelegance of the API set is the basis.
If your friend is a good developer, he'll appreciate the beauty and attraction of good, tight code.
J.J.
The fundamental difference between developing under Windows and under UNIX and its derivatives (I use FreeBSD), is that under UNIX everything other than object files, executables, and libraries, is in flat text files. This includes your project files (i.e. makefiles), your version control files, your documentation (man pages, LaTeX, etc). The formats are well documented. Furthermore, you have all the tools you need to do whatever you like to these text files. And the upshot of this is that you can automate almost anything, to the point where typing `make' can check your latest sources out of various repositories around the 'net, compile them, run regression tests on them, and build and cut your release CD, and maybe even send out the mail saying a new release is available and what the changes are.
Under Windows, you have some great tools - but they don't have this underlying simplicity, and that is where *true* power originates.
When I develop under Windows (not very often anymore, I'm glad to say), I still use command line compilers, make, etc, to get as much of this benefit as I can. But it isn't quite the same...
Graham Wheeler Cequrux Technologies Internet Firewalls/VPN Routers/Encryption Software
If Borland's Kylix is anything like Delphi, it will have all the Experts (Wizards to MS fans) and code completion that you speak of.
BTW, Kylix will be Borland's Delphi/C++ Builder environment for Linux (now in beta).
The only drawbacks I can think of going to Kylix are its dependencies on QT. But, supposedly, they will allow those libs to be distributed..and are encouraging inclusion on Linux distributions.
The other drawback is that it is a commercial product. That won't stop me (I'm a corporate (and hobby) Delphi developer), but it may stop some people. Me, I just want my apps to port with the littlest amount of work and then to develop natively with the same interface I've come to enjoy.
RD
I started as an Amiga guy, then switched to Windows, then to Linux. A few years ago, I had to write an app that I had to port to Windows and Mac, so I have programming experience in most "flavors" of the major OSs of today.
... It's even possible to mix-up the APIs, so you can have one app that has both Motif, Gtk and Qt all used together and using the same event handler! UNIX has some really poor GUI-builders (none of the PD ones I'd recommend), but it's not that tough to throw together a GUI using vi and your own 10 digits.
In short, there are pros and cons to programming on any platform.
* Windows has good commercial tools, but MFC, I/O and the memory problems associated with windows are enough to make one look for an alternative. The public domain tools available for Windows are either buggy as hell or don't even begin to understand the meaning of "robust".
* Mac has an interesting (yet similar paradigm to Windows) philosophy when it comes to GUIs or graphical resources. They're still using the old development tools (with the exception of Code Warrior) of yesterday to write apps. In the Mac world, YOU USE CODE WARRIOR - there's just no other way around it, but in a way, this actually a good thing. If you grab some mac code off the web, you're almost guarenteed it'll compile and work! The legacy stuff makes IPC and GUI development very "hacky".
* UNIX (in general) is interesting because you have several choices of APIs to use. Want to write a GUI? You can choose from a number of different GUI APIs! Motif, Tcl/tk, Gtk, Qt, and so on
Some of the previous comments I also agree with, like the ability to treat devices as files under Linux - sound is simple, framebuffers are simple, tcp/ip is simple - it's all very low-level as opposed to the MFC where you have to instantiate a huge object and dig down inside of it to turn on the thing that you want. Unless you've done this for years, the MFC is a real pain in the ass to do anything very productive with.
That's just my $0.02
- Steve
--
Steven Webb
System Administrator II - Juneau and TECOM projects
NCAR - Research Applications Program
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 :)
It is possible to write plugins. Take a look at the Visemacs page: http://www.atnetsend.net/computing/Vis Emacs/. Visemacs integrates Emacs into MSVC (well, as best it can considering the constraints placed on the task by Emacs ;)). I've been using it for several years, and really like it. The source is available, so I'm sure it wouldn't be hard to do a plugin for Vi, Lemmy, etc. Of course, Emacs integration uses the gnuserv package.
Windowing toolkits like GTK+ are portable across most or all unix platforms. It changes nothing. Use autoconf/automake/gcc and you get an even higher compatibility degree (because those tools know about the 'features' of the os's and what to define/include/etc). Writing GUI applications I've had them compile flawlessly on linux, aix, hpux and solaris without even thinking about compatibility. I run into more problems with network code portability than I do with GUI portability.
Really... I did C++ Windows development for many years (most of this last decade). Still do sometimes... there are several issues though:
- Compiler bugs are extremely slow in getting fixed... like years... you will have to work around the problem. Only recently has there been an open source C++ compiler worth a salt (g++ is awesome for ISO compliance these days but it has it's own issues... but they get fixed quickly). And Borland's C++ compliance with 5.5 is finally good... hadn't been able to use their compiler since 5.01a. MS VC++ is a joke and Watcom is good but way behind in C++ feature support.
- Win9x simply isn't a host development platform... I will spend an average of an hour a day rebooting when I try (I tend to do fairly intensive multi-threaded and low-level devlopment so YMMV)
- Win9x and Win NT behave *very* differently in various areas of the API
- OS bugs just don't get fixed (has MS yet fixed the memory leak with in EnhancedMetafiles and Clipping Regions in Win9x... makes them useless even though I've seen MS state them as the recomended way to print)
- Changes to the OS are not documented... I remember one entertaining time when an Outlook service pack had the side effect of initializing serial port DCB's differently.
- The API documentation is highly inaccurate and contradictory/unclear... and it's not like you can just look at the code to see what it really does. I've spent enormous amounts of time playing with API calls just to see how they really behave... and on which fix level or which OS.
I don't jump on the "open source is the answer for everything" bandwagon much. I think it has it's place and I definitely think that the OS and development tools are places for it. As you can see my complaints are centered mostly around lack of access to information on how things really work and the inability to get problems fixed.
Brian Macy
Windows does everything assbackwards. I've developed under both. I prefer Linux development. If you want to develop under windows, by all means do so. I like the programs that I've written under windows, I don't even really mind the windows development model, but it's not the same. The way that most people learned how to program in academia is the Unix way. I prefer that way, and I programmed under windows before I ever touched a line of Unix source. Don't call me biased, I run a dual boot. It's simply more natural to develop under Linux/Unix, and quicker, and a whole heck of a lot easier. These OS's were written with developers in mind. I do not get that warm fuzzy feeling when I am working under windows. It has gotten better, but it's still not there yet for developers. Perhaps when they break up, Microsoft will be forced to open the gates a little.
Eh...
Even if it is not the best tool at all for the job. MSVC gives you all that built right in, no need to "spend time getting over the speed bumps."
I'd compare MSVC against Emacs like a Video Recorder vs a Computer. MSVC gives you a set of predefined tools to allow you to do what MSVC is designed to do. If at some point you need something which MSVC doesn't do, you have to either upgrade or switch platforms. However, because the options you have are limited, the amount of time you need to acquaint yourself with the MSVC environment is also limited.
Emacs is daunting for the new user. Why? Because it is a programmable, flexible editing environment. You have a predefined range of tools (libraries) at the start, plus the underlying configuration variables (via Customize or Options for Emacs or XEmacs) plus the Emacs Lisp programming language for more specific customization. There is very little limit to what you can do with Emacs - but becoming familiar with it requires time and patience spent. This time is not wasted - far from it. Every time you learn a new trick or feature in Emacs, you build your knowledge further and next time you need some function, you have a better idea of how to find it or write it.
People jokingly talk about EmacsOS. But it's not so far away from the truth - I know people who rarely step outside Emacs in their interaction with the system - maybe to adjust a window position or to switch to another desktop window. A system this powerful takes time to learn, but I doubt you regret the time taken to learn C? Or Unix?
At the end of the day, it's all about being able to make the best of the tools available. I actually prefer having many specific tools which can be used together. Emacs would seem to contradict that, but the reality is that Emacs provides a framework which helps glue those small tools together in such a way that the sum of the parts is greater than the whole.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Myths
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/) 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).
C was written as a standard language under the Unix environment, and then Unix was rewritten in C to ease portability. Pretty much by the same people. Most Unix texts make references to the C language, and vice versa.
Eh...
Locate is great for finding files. Problem with it is threefold:
1) Let's say I install something, like LessTif. The LessTif rpm doesn't modify my ld.so.conf so I have to put the path to libXm in there myself. Where did the RPM put it? Can't use locate because I haven't yet run updatedb.
Yes, that's actually a very interesting problem that's worth solving. What is needed is some kind of event supported by VFS; a program like locate can register to receive it; the event says "I just changed such-and-such directory [and optionally] in such-and-such a way". It doesn't really have to be any more than a notification of change - locate could pick these up and automatically do an incremental re-index on your next locate or locate -u cron job.
We're talking about a feature here that touches the system in a few different places and you'd want to be very careful in how you went about it. Right now we really don't have anything that handles system-wide events/messages. The current state of the art is a kind of hierarchy where program results get passed up and down a tree of execute and a pretty unsophisticated and often inconvenient way. We need a system-wise messaging facility that can handle messages that cross between components, asynchronously. Ultimately such a system will exist in Linux - it's a better way of doing things, so it will happen.
2) Not portable. Maybe there is a locate workalike on AIX or Tru64, but I haven't found it.
Ah, seriously, I don't really care about that. It's good, so other platforms will adopt it if they haven't already. Just don't use it in a script that's supposed to be cross-platform.
--
Life's a bitch but somebody's gotta do it.
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 net will not be what we demand, but what we make it. Build it well.
Autocompletion is possible with Cooledit. Doesn't automatically pick up your custom C++ classes, but that's a mixed blessing anyway. I know people that type the full word without the dot, then go back and put the dot in, so that the autocompletion doesn't freeze the machine for a couple of secs.
perl -e 'fork||print for split//,"hahahaha"'
My school is totally unix in the CS department, and sells the Burks CD's every semester. Almost every student, therefore, has a copy of redhat 5.2 laying in their room. Also, a lot of students burn CD's with various linux distros (go Slack) and hand them out in class. Any school that does not teach its freshmen actual coding, is not teaching them computer science, and is not doing them any favors. In 10 years, where will they be, and are they really computer scientists? I know graduate students who fail out because they don't have enough actual computer science background. I am tired of people in this forum who think that pointing and clicking = computer science. Go and get a degree, and then yell at me, ok?
Eh...
You can write a locate 'workalike-good-enough' on any unix in just a few lines :).
/var/spool/filedb
/var/spool/filedb
updatedb:
find / -type f -print >
locate:
grep $1
Oh yeah, the point being, I agree.
Eh...
I agree completely with you thoughts about documentation, however, you no longer have to pay money for the Inside Mac books (unless you have a thing against trees). All of the Inside Mac documentation is free via html or pdf from the Apple developer website. Microsoft's developer docs are nowhere near as complete and easy to use.
You wrongly assume I am a Microsoft Apologist. I am more of an outsider who is amused to see Linux lovers and Microsoft apologists fight the bloody fight to defend their ways.
;-) Don't get me wrong, I respect your enthusiasm, and the enthusiasm of those who enjoy other alternative operating systems (including those which don't interest me personally). None of the alternative OSes is perfect, but all of them have one thing in common: they are better than Windows in nearly every technical respect, and none of them are guilty of having held back progress the computing industry for fifteen years.
:-)
And I, an unashamed Linux, FreeBSD, and BeOS enthusiast, always find Linux, FreeBSD, Amiga, Mac, and BeOS enthusiasts to be quite amusing.
Apologists, astroturfers, and zealots supporting MS Window variants, on the other hand, are promoting a technically inferior platform and a parasitical company which has actively and severely harmed computing for as long as I've been in the field. Worse, they promote a culture which replaces technical diversity, individual knowhow and intellectual endeavor with a technical monoculture ("One World, One Web, One Program"[1]) mentality, canned solutions which barely work and often map poorly to the problems they purport to solve, and corporate marketing hype which is often criminally misrepresentative. I don't even want to begin discussing their criminally negligent attitude toward security; that is a topic for another discussion. Suffice it to say, that for all of this I can have absolutely no respect whatsoever.
To the subject at hand: as another pointed out, POSIX is only available for Windows/NT, not 95 or 98 (which comprise the majority of installed systems), and even there it is hidden away (and not installed by default). Worse, it has more than once caused severe headaches after various service packs were applied, and had to be removed. This hardly qualifies as a function product in my opinion.
Unlike Linux, code generated for one variant of windows will very often not work at all on another variant, whereas for Linux most code will work with a simple recompile, 64 vs. 32 bit architectures not withstanding (We do allot of work on both 32-bit Intel and 64-bit alpha Linux platforms where I work).
Actually, I prefer BeOS as an OS. None of the programs for it crash the OS. 'course, there aren't too many programs either!
I like BeOS, but Adamation Personal Studio crashes all the time when I try to make long video captures (from either analog or firewire sources). On occasion, it does take BeOS out with it, and a hard reboot is required. It is a very cool OS, but no where near perfect just yet.
[1]Microsoft Promotional Ad, bearing a striking resemblence to Hitler's "Ein Volk, ein Reich, ein Fuehrer" political slogan. Both show a completely malignant attitude toward diversity, be it technical, biological, or cultural.
The Future of Human Evolution: Autonomy
Set up an interrupt handler for SIGCHLD that calls wait() or waitpid() to reap the child process.
(and, btw, the SIGIGN thing is not specific to just Linux, it's mentioned in the HP-UX manpages too, and IIRC Solaris as well)
DNA just wants to be free...
...there seems to be only one solution. Whatever platform your are programming on or for, use LOTS of acronyms.
--
+&x
I've programmed on a variety of Unix systems for almost 20 years. I've programmed on Windows (mainly NT, VisualC++) for about 3 years.
The biggest benefit to switching to Linux (or some other Unix system) is that it doesn't crash. We all write bad code when we are developing. You allocate an infinite amount of memory (or leak it), you open an infinite number of windows, you open too many files, you chase wild pointers, you pass bad parameters to system calls, you lock up all your threads, etc. Under unix, you just kill the app (from a window that will not be hung), and start again. You have not corrupted the OS.
Any number of times under Windows, the IDE goes down, or the browser crashes and the OS goes down or locks up. If I have to kill a process, the OS becomes unstable, and after a while I have to reboot.
Yes, I've crashed the X server. But you just rlogin to the box, or switch to another login screen (cntrl-alt-F4 or whatever it is - BTW - God bless whoever built that!). You can kill the server, kill your shells, kill your hung emacs, whatever. Then you just login, and start again. Linux *doesn't* hang!
This results in *way* faster development. In Linux, I don't have to be as careful, and consequently, I can move faster. In Windows, I'm always afraid to run outside the debugger, and even then it will lock up, sometimes.
One thing I do like about Windows development. That is the microsoft knowledge base. Whenever you hit one of those wierdo, impossible errors with the useless unrelated error message, you can look it up, and they record the most likely causes, and patches. It would be nice if the same service were available for linux. Searching dejanews and the HOWTO's is OK, but not as efficient.
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
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Reason 1 for me is portability.
The GNU compiler is more compliant with standards than VC++ (yes it is, yes it is). I don't feel the constant pressure to use ATL, MFC, and a bunch of platform-specific stuff. I can get my Linux-written code to compile on Windows a lot easier than vice-versa.
Yes, if you're doing GUI stuff, you're S.O.L. You're S.O.L. if you're doing GUIs on any platform, though. Abstract it from your logic and processing or you'll regret it later.
Here's a suggestion: Go to Cygwin's site and get their Bash and compiler for Windows. Fire up your favorite text editor and go.
I do this when I have to write code in Windows. When it comes time to pull the whole thing together, I load the code into VC++ and add the Windows-specific stuff. Works like a charm and I know that my core logic will be portable later.
Save the whales. Feed the hungry. Free the mallocs.
I much prefer the highly integrated IDEs for the type of programming that I do. Sure, text mode programming and all that can (at least some people believe that) be more efficiant than an IDE, but it has to be set up right, and switching between programming and debug incurs some overhead. For the graphics stuff (especially with DirectDraw) that I do, I tend to write a small module, then have it crash, fix the bug, recompile, have it crash again, etc. numerous times before it works correctly. For me, it is a tremendous advantage to be able to simply move my mouse to redo the build rather than to switch to a new terminal, hit up bring up the previous command, and then execute my program. Also, VisualStudio offers something that keeps me coming back for more: incremental compiling. If you make a reletivly small change (like one often does in debuging graphics code) it will just change that part and not recompile the whole file, which is much faster. Also, it tends to produce better optimization and support incremental linking (which isn't supported by default in most Linux distro's) which make file size smaller.
A deep unwavering belief is a sure sign you're missing something...
It is possible under Windows, there are toolkits that wrap the interface (You can even make it look like Motif!) Or you can use something like MFC or OWL instead of Win32. However, toolkits are rarely used because it is more convenient for the user to have all apps look the same. I think this is an important philosophy, because in all truth, the user is more important than the programmer. You only program it once, people have to use it everyday.
A deep unwavering belief is a sure sign you're missing something...
There is nothing about Windows that prevents people from sharing code. A Windows developed OSS program is just as free as one developed on Linux. A proprietory Linux program is just as proprietory as one on Windows. However, people who care about Open Source tend to have some religious differences with Bill, or are hard core UNIX nuts. As such, they tend to stay away from Windows.
A deep unwavering belief is a sure sign you're missing something...
You have fun developing database servers? (Just kidding) I do stuff for fun too, and graphics on *nix is no fun. Say what you will, but DirectX rocks hard as hell.
A deep unwavering belief is a sure sign you're missing something...
My personal experience, before having read any of the four hundred or so responses already under this thread...
I learned to program on a Commodore 128, in MSBASIC 7.0, one manifestation of the prototypical policy=implementation environment. It wasn't all that bad (structured programming constructs had been backhacked into the language, but that didn't mean much to a twelve-year-old trying to figure out how to write an operating system in BASIC), but to learn to code on such an environment is very limiting. There is no hand-holding outside the manual, but you can't get lost easily (short of a rogue POKE) so it doesn't matter. It wasn't for a very long time that I understood the benefits of keeping the implementation separate from the environment. This is what has made Unix more successful than many other environments of its generation.
The beauty of Unix is that implementation doesn't matter -- you have your choice of tools, and you're free to use whatever you're comfortable with. You don't have to write every last piece of code in bash or jump through hoops to do otherwise. Linux goes traditional Unix one better by traditionally offering a far richer development environment than any other system on the market. Not only do you have a solid, time-tested C compiler (gcc), you have any number of other languages like Perl (my personal language of choice), Python, Fortran, etc...
Another aspect of GUI systems is the IDE. I used to think IDEs were the greatest idea until I switched my Mac environment from Think to CodeWarrior. Now CodeWarrior is pretty damn good, and AppleScripting gives you every bit as much flexibility as shell scripting and then some, but to me it's not particularly obvious how to construct a tool chain in a project build -- there is a learning curve that simply doesn't exist in a traditional shell environment.
I don't like make(1) very much, I'll admit, but there's a certain simplicity to using componentized tools that just isn't there when you're using modulomonoliths like CodeWarrior or Visual Studio. Fast turnaround tools are much more easily managed under Unix, as well; I don't think I could meet the demands of the constant fine-tuning my current language project requires if I wasn't writing it in Perl (or maybe Python), and as good a tool as MacPerl might be it's still a GUI app.
So what's so great about Linux? The flexibility. Yes, there's a learning curve. But it's worth it just to not have to worry about the complications involved in managing a full-up project file for a simple program.
/Brian
Hmmm. Well, I didn't know about TAGS. It sounds like the hard part (equivalent to the first stage of the compiler) is done by TAGS. So maybe with TAGS it would be easy.
Where can I find out more about TAGS? Does it support Java? (My employer's language of choice)
Do TAGS automatically update whenever you add or modify members or methods in a class?
The other thing that is missing (or, maybe not?) from emacs is the good integrated debugger that DevStudio has. Can you do an edit and continue on a running C++ or Java program from inside emacs?
I hope the answer is yes, but I suspect no. But I was wrong before...
I suppose I will just have to take the plunge, get a good emacs book, and go from being an emacs user to an emacs expert. Then I'll be able to fix the keyboard commands too. (Ctrl-X, Ctrl-C, Ctrl-V should be cut, copy, paste, dammit! And Ctrl-Z for undo!)
Anyway, thanks for the info.
Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
- 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 !
Where can I find out more about TAGS? Does it support Java? (My employer's language of choice).
TAGS is pretty wide ranging in it's abilities and Java support is somewhere. Ah. Here it is. To create tags for Java, and for Java development under Emacs, take a look at JDE. I've not used it, but it looks pretty wide-ranging. It also features automatic completion of class fields and methods :-)
Do TAGS automatically update whenever you add or modify members or methods in a class?
No - they are updated when you run the TAGS utility. If you update the methods/members, it's best to rerun TAGS to tidy up the database. It's often a good idea to run TAGS as part of your makefile so that whatever changes are put into the binary are reflected in the TAGS database.
The other thing that is missing (or, maybe not?) from emacs is the good integrated debugger that DevStudio has. Can you do an edit and continue on a running C++ or Java program from inside emacs?
Yes - with GUD (Grand Unified Debugger) under Emacs, you can interface with whatever debugger you feel like, from gdb, xdb, etc.. You can mark lines in the code as breakpoints, view variables, step, next, and so forth inside Emacs, plus issue compile and connect to process calls. I note that JDE also features automatic jump-to-offending-line with compilation issues too.
After a brief amount of searching, I discovered QuickPeek for Emacs, which works as follows:
QuickPeek
Quick peek is a tool that uses a second frame to display context sensitive information about where the cursor is. It wants to be the superior copy of "Intellisense".
There is a reason that one of the more popular icons for Emacs is a kitchen sink :-)
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Here is a little story that happened to me a few years back which made me rethink my decision to develop for Windows.
I was having trouble developing an MFC application. I forget what the actual issue was, but when I called Microsoft's tech support for assistance, I was asked a number of questions about the configuration of my project. One of the things they wanted to know was what options I had chosen in the AppWizard. I told them I didn't use AppWizard because I preferred to code everything by hand. There was a long silence, then the MS representative said, "You can do that?"
Up until this point I had always believed Microsoft's claims that they put wizards in Developer Studio to remove the tedium of repetitive programming tasks. This incident got me thinking. Why is MS so adamant that people use the wizards that even their tech support doesn't know there's another way?
Wizards are supposed to be helpers. If you don't feel you need the help and would rather do it yourself, why use them? I learned more about MFC's internals while coding by hand than I'm sure these tech support people even knew.
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.
I refer you to an internal Microsoft memo.
For additional information (there is no shortage on-line, and no reason to belabor the obvious any more here) may I suggest numerous introductory Linux websites, some of which you'll find linked to here and here.
The Future of Human Evolution: Autonomy
autoconf automake aclocal gcc beowulf/clustering portable tools (for unix) CORBA - ACE+TAO, ORBit, MICO DB's - PostgreSQL, mySQL, Oracle, ... Apache Modules + LibGimp bash make i could go on.. but its time to go back to work..
There is one thing that all the GUI libraries for UNIX (Gtk, Qt, Xt, Fltk, etc) do better than the windows GUI for the coder - all space allocation for widgets (Sizing and positioning) is done automatically. In windows, you can only place widgets (buttons, text inputs etc) on coordinates. If you want resizable windows, you must code the resizing/moving of the widgets in the window by yourself (At least, so it was in VB. And I can't imagine why they would have it like that in VB if it's not because of the underlaying GUI tookit). This is one reason programming GUI apps under UNIX is much easier, even if you don't use a GUI-drawing tool (Like GLADE).
All together, what makes UNIX more apreciating as a programmer is that a lot of things are abstracted away. You have device files to manipulate devices. Thus, you don't have to learn how each device or device API works. They are all the same.
--The knowledge that you are an idiot, is what distinguishes you from one.
--The knowledge that you are an idiot, is what distinguishes you from one.
TAGS does not take into account local variables and scope. It also does not give help on function definitions and has limited functionality, however search and replace across multiple files is very nice. Also, C mode (I think) uses regular expressions to skip forward and back statements so it makes mistakes and can be annoying. It does block traversing quite well.
I'm working on an extension to C mode to fix this. TAGS is pretty good, but it misses some potentially important things. Of course,it is quite fast, which is advantageous but it is not something that Emacs itself runs. It is a shell command. Anyway, I finished most of the parser this morning, so I'll be testing it later.
However, some of the features you mentioned have the real potential to be intrusive. Popping up new frames can be very distracting. However, the echo area is quite restrictive, so ehn, whaddya gonna do? =)
Woz
I have no doubt that a lot of developers love Linux and for good reason, however the absurd and misdirected claims that I've seen in here, particularly claims of a nature that make it obvious that the person has no professional development knowledge (i.e. probably jump into vi and spit out a hello world app every couple of months and call themselves a programmer), have no purpose in factual discussions. That sort of nonsense serves no one except for their myopic, cultish obsessives who feel that a lie is acceptable if it follows what they consider to be moral.
That should have just been M-/ (C-M-/ is a pain IMHO)
You actually illustrated one of the best points to using linux over windows. Being able to fix stuff.
It was documented, not in plain english, but in actual code. Since we are talking about developers here, there is no better documentation for an API than to see the code itself, and that is where the advantage is. Now, did you submit this patch back to the mantainer so all could benefit?
Finkployd
Try win2000 and have it work right the first time!
Obviously you have never used Windows2000. Fortunatly, my workplace banned it's use over major security flaws we found, but not after some of us played with it and found it to be horrible horrible joke.
Now go trolling back to ZDNet
Finkployd
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.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
There are different tools available for each platform. Many are available for just one but not the other; in most cases I think that the UNIX tools are more powerful and more flexible in the long run, but it takes at least a year or two of using them before that becomes clear. So I won't bother to cover these, because it's not going to convince anyone except those already "in the know".
Instead I'm going to ask what your application is. I have used both Windows and Linux to develop commercial games for many years. In this area, Linux has a clear superiority, largely because games are such unstable beasts. One can develop a 'typical' user app on Windows without needing to reboot but perhaps once or twice a day, which is perfectly workable. Doing games, I have found that up to 50 (yes, really, I have counted) reboots a day are necessary. At one place I worked I had two computers so that I could work while the other one rebooted, just so that I wouldn't loose so much productivity. (A lot of the blame here lies with DirectX - if you are developing OpenGL on NT 3.5 or 4.0 this is much less of an issue. I have heard that Windows 2000 is similarly usable.) FWIW, writing cross-platform game code is quite easy these days. Most of the games I have worked on in the last three years have run, and been developed, on both Windows and Linux, but have a completely different release target (including Dreamcast, PSX2, and an arcade game).
Another application I have tackled professionaly is enterprise-level servers. Here is an area where UNIX development is a clear win; there are thousands of small server-oriented tools at your disposal that cut your workload by an order of magnitude. TCP wrappers are absolutely *wonderful*, for example - I spent over a week writing code for NT that is entirely handled by TCP wrappers on UNIX. Other major headaches on NT, such as the poor multiprocessor support (running lots of threads pegs CPU #1 at 100%, while CPU #2 hovers just below 30%) and the slow filesystem (perhaps it's the SCSI drivers that are slow, I dunno) make it almost unusable not only as a *target* for high-end servers, but also as a development platform.
When it comes to 'typical' end-user apps, like ICQ clients, word processors, or spreadsheets - I think the difference between the two platforms comes down to personal preference. The tools available on both are perfectly sufficient for this kind of development work, although each developer is likely to have their own preferences.
UI stuff is about the same - writing down-to-the-metal WIN32 code is just as horrible as writing down-to-the-metal X (or even Motif) code. All sane developers use encaspulation (either their own company's classes, or a 3rd party library such as Qt) to hide the ugly implemention details anyways. So in this case, any convincing that you do will be purely an "expand your geek power!" type of argument, rather than a practical double-your-productivity kind of argument.
I think too many people are confusing IDEs with code generators. An "Integrated Development Environment" does not necessarily mean visual programming or code generation. Emacs, with proper modes turned on, is an IDE. Used simply for placing editing/compiling/debugging into one frame, IDEs can be wonderful time savers. I loved MSVC++ for this..who can argue with a debugger that visually allows you to step backwards in code!
The BeerBaron
>I want an editor that uses Alt- keys, not "Ctrl-X Ctrl-that Meta-x foo" for everything. Not sure I understand this; how is Alt-f (for example) better than Ctrl-f? Sure emacs has a lot of ctrl key commands, but I don't see any way around this. You can either map all the commands to mouse clicks or keystrokes (or both) ; and since there are only so many keys available, some key sequences tend to get lengthy. Emacs is my favorite editor -- I don't think you can give it a fair evaluation after a single month of use. I have had 30 files open in emacs for monthes at a time before; I can't remember the last time I had emacs crash on me. I used to get multiple Visual Studio crashes PER DAY back when I used it a few years ago. Sucks ass when the program I am debugging crashes the debugger and the whole OS too! BTW Most Windows programs I use require several Alt keystrokes in a row to do menu functions, too.
. Example:- MSVC server cgi dll = 115k (prints hello world) apache server cgi exec. = 5k (prints hello world) Need I say any more...
/ALIGN:16
Try cracking your project file open and taking OUT all the DLLs - like winspool, GDI, etc etc. Only link to msvcrt.dll - and change linker alignment to
You'll find - lo and behold - that all of a sudden, your HELLO WORLD becomes about 2K long (give or take).
Simon
Coming soon - pyrogyra
With app studio you get huge apps that take up lots of resources. Titanic was a huge ship that took a lot of resources. Did you see all the coal in the engine room?
Apps on Windows are not properly protected from each other; any app can crash the whole system. Titanic's bulkheads were too short to keep the ship from sinking when one compartment got flooded.
C programming under windows requires those near, far where are my variables stuff. Titanic... "...near, far, wherever you are...".
More...???
Well, given that apparently the last time you touched Windows you were programming it under Windows 3.1, no thanks.
NEAR/FAR - went with Win3.1 & DOS. GONE. FINITO.
Windows app protection : across the board in 95/98, and NT/2000 unless it crashes the 98/95 kernel or uses 16bit drivers. In NT/2000, all apps are protected from one another.
App studio creates "huge apps with lots of resources". Only if you use the default settings, in which case, it's YOUR fault. Change them. Don't be afraid - it works just like under UNIX.
Switch to a frickin' MAKEFILE if you have to.
Simon
Coming soon - pyrogyra
Functions are functions and you call them directly - after you fill out a few strucs - if you want to do something. MFC seems less a part of the c standard - too many callbacks (yech! c was not meant for this!) and levels of abstraction.
If C wasn't meant for callbacks, why did they bother putting function pointers in the language?
Clue: Sometimes a function pointer can be orders of magnitude more efficient than a switch statement. And when you have to do direct binding, nothing else will do.
Simon
Coming soon - pyrogyra
That's why I said that OSS people tend to stay away from Windows. I don't think that this is completely deserved, however. Yea, it's nice if the underlying OS shares your values, but I doubt it is the closed-ness of Windows that keeps OSS people from developing on it. I think it is a general resentment (okay, deep seated hate) of anything having to do with Bill or Microsoft. As for my preference, I can see why you like doing backend services on UNIX. The coordination it has between different programs, and all the glue tools available are quite impressive. I am writing a package manager for BeOS (which looks pretty UNIXish in the root FS layout, the userspace programs, and the POSIX API), and have barely written any custom code, just written glue code to bind stuff together. However, I tend to like doing front-end stuff a lot more (graphics and sound) and thus far Windows (actually DirectX) is unmatched for that.
A deep unwavering belief is a sure sign you're missing something...
i always felt dirty (and not in a good way!) when i use MS products.
this will be long winded, but here goes. when i was in college, my gf came up to me all tearful, etc. her aunt had passed away, and the family had agreed to meet at the aunt's house, and go through her things, and decide who would get what. they were supposed to meet at something like 8:30am, as i recall.
anyway, her part of the family shows up at like 8:15, and some other family members already had gone in the house and were loading things up in a truck -- get this, they said "you snooze, you lose"!!!
so, she was upset because she wanted a couple pieces of jewelry that she liked, but the relatives took her aunt's whole jewel case.
okay, i was angry and upset too. i was raised that things like that just shouldn't happen, fair is fair, wrong is wrong.
but as i get older, i realize that many people in our society don't feel that way. it really is "you snooze, you lose". whatever they can grab, between birth and death, well -- that's competition -- you lose if you're on the losing end. go cry about it or something.
case in point: whenever developers yap about MS innovation, thay always get on Visual Studio and "Intellisense".
I'm always glad to see it, cuz i know who (by name, anyway) made visual studio -- something like "Anders Helsjborg". he was with borland, made delphi (which was killing vb) and was targeted by bill gates for recruitment. the final offer? something like $6M to leave borland for MS.
that, in itself, was not so bad. certainly not illegal. but what came next was stunning -- MS rented the top floor of a hotel nearby borland, and called borland's top engineers and invited them over for a "technology expo".
when the enginners arrived, it was not a tech expo, but a recruiting center. several of borland's top employees accepted offers and left for redmond. this move, "Brain Draining" a competitor, is illegal in california. a lawsuit ensued, and MS settled out of court late in the trial (as usual -- another MS tactic -- keep the expensive lawsuit going til the end, then settle).
in the meantime, borland struggled to bring the less senior people up to speed, while MS developed visual studio.
bill gates, like the people who took the jewelry case, may honesty believe that what they are doing is somehow "acceptable". a lot of people agree with him -- that, somehow, "morality and fairness is for losers".
myself? i've found that most microsoft people are intolerable little wretches, enjoying life on the winning side, at any cost. harsh, but true. i've only met a couple microsofties that i though were decent folks -- the rest? watch your back.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Sorry, I meant Linux *did* run like a dream on it. And hopefully will again when I get the replacement through.
Now weary traveller, rest your head. For just like me, you're utterly dead.
I love using emacs but there is so much to learn. Does anyone know of a great web site for learning emacs? I think a well built web site that was newbie oriented would do emacs well. I used emacs in school, started working with MS IDE and have forgotten so much of what I knew...
To be honest the best places to pick up hints and tips are the various Emacs newsgroups. There are several experienced Emacs hackers on there who know their stuff and who post lucid and useful answers. Try gnu.emacs.help and comp.emacs for general enquiries, and gnu.emacs.sources is a very useful place to pick up new elisp hot off the press.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Gee, I guess you didn't read my post.
Yes, I have used NT you blithering idiot.
What I say still stands, NT's security model is an abomination. 95 and 98 don't have a security model to speak of. Etc. etc. etc. with references provided.
I am through feeding the trolls, forage elsewhere.
The Future of Human Evolution: Autonomy
Where did you get the april platform sdk from?
What I say still stands, NT's security model is an abomination.
It's actually better than the one used in Linux.
Better control. Finer grained. The only difference is that on most installations, it's turned off by default.
On Windows 2000, however, it's not.
Simon
Coming soon - pyrogyra
Here you go, hello world in less than 5 lines.
//Start helloworld.cpp
#include
int WINAPI WinMain(HINSTANCE h, HINSTANCE t, LPSTR cmds, int nCmds)
{
MessageBox(NULL, "Hello", "World", MB_OK);
return 1;
}
Okay, fine, that was 6 lines. Sure it's one line in Perl, but considering that C has a minimum requirement of 4 lines, this is not that bad. Also, your perl program is a console mode app, while this is a full-fledged windows application. Yes, it takes about 50 lines of code to create a window, but it takes that much in most procedure-based APIs. Programming Win32 is no harder than programming for X for example. It may be even easier, because it is unified, so once you get the mindset, you can use a lot of stuff like networking without having to learn a different API like in Linux. Of course, you can't compare Win32 to GTK+ or Qt, because those are OO APIs and inherently have less setup code. I do agree, though, that MFC is a bitch and only a fool would try to hand code it, but in reality, MFC was designed to be hand coded, it was designed to be computer generated.
A deep unwavering belief is a sure sign you're missing something...