Slashdot Mirror
Culture of UNIX and Windows Programmers
bebonzo writes "Joel Spolsky, 'Joel on Software' has an interesting review of Eric S. Raymond's book about 'The Art of UNIX programming'.
Quote:"What are the cultural differences between Unix and Windows programmers? There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers."
About slashdot: "slashdot-karma-whoring sectarianism..."" He's harsh on some points, but pretty on the money. Except about us. Nobody karma whores. Update Note to self, never post before coffee. Yes, its a dupe. get over it.
but it does mean that Americans getting off the plane for the first time in Tokyo are confronted with an overwhelming feeling that this place isstrange, dammit
:)
It's funny, but coming from Australia you'd think I'd feel right at home in both the UK and US, but there are lots of little things that make me feel slightly out of place in both countries. I think Gibson's "mirror world" term describes it best. And it's much the same with programming, not that I've explicitly programmed for windows, but it's quite a difference writing GUIs in Java or C++ as opposed to command line tools in Perl or C. Each to their own, I guess
"The Windows programmer will tend to start with a GUI, and occasionally, as an afterthought, add a scripting language which can automate the operation of the GUI interface."
1) No, a VB programmer will do this.
2) No, a good windows programmer will create an object (COM/C# Class) and then write a GUI that will call this object.
also interesting:
"They don't like GUIs much, except as lipstick painted cleanly on top of textual programs, and they don't like binary file formats. This is because a textual interface is easier to program against than, say, a GUI interface"
i would say that textual interfaces were more popular before bandwidth started becoming readily available. the rise of bandwidth has seen a rise of GUI applications because it is quite feasible to VNC from home->work and to run GUI. before ADSL it was a pain in the arse and using textual interfaces was fast and convenient.
To wit: why is it so difficult to accomplish this seeming simple task? Why can't straightforward business task x be accomplished with these shiny new computers? What do you mean we need to hire 5 VB programmers for 3 months to move this data from here to there, or cause this function (which should have happened automatically) to occur every night on schedule?
Yet when I drop down to the command line to run an NT Posix utility which replaces those five VB programmers with a simple script, or pull up SQL*Plus to quickly make mass changes to the database, they sneer "why are you still using that archiac technology?".
The problem that Mr. Sposky doesn't address is this: 2/3 of the problems addressed with computers today (even so-called personal computers) are data processing problems, and there is absolutely no evidence that a GUI is an efficient way to handle those problems. Yet rather than use the best currently available tool (the command line and scripts), or devise a better one, Mr. Sposky and the Windows advocates would have us shoehorn every task into a GUI + complex API world. Um, those don't work very well, I am afraid. If you don't like the command line, fine, but could you propose something better? Because all I see right now is frustration.
sPh
Au contraire, Mr. Sposky, most Windows people I deal with are ignorant of anything that doesn't come from Redmond, and not willing to learn. God knows I've meant plenty of UNIX bigots, but at least they know something about Windows - they have to, there's no avoiding it. The same is not true about Windows bigots: they combine their parochialism with a triumphalism that is as infuriating as it is unmerited.
One other aspect of the two cultures that Mr. Sposky doesn't discuss but is worth bringing up: UNIX bigots are not trying to shoulder Windows out of the marketplace - we couldn't, even if we tried. The Windows culture, however - or its corporate sponsor - is in fact trying actively to extinguish all competition. This is open-mindedness? Give me a break.
[this
Nothing like the smell of fresh dupe in the morning :)
Karma Clown
Dupe immediately following the original! ;)
That's gotta be a record
Left hand doesn't know what the right one's doing I guess!
No Comment.
Or is Hemos going to post the same item in an hour?
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
True, in the Unix world, one makes your source code available to give others the chance to further improve and customize the system, but by making it available, it means OTHER PROGRAMMERS WILL SEE HOW GOOD (or bad) YOU ARE. Because of this, most open source developers will want to put in the extra effort to do it right / clean it up / make it elegant/compatible (or at least the best of their ability).
Most open-source developers are happy to learn and grow by reading suggestions and examining patches submitting by their 'users' (obviously, the ones who submit patches are programmers as well).
In the Windows world, source code is a closely guarded secret. No one is going to see THAT source code, so who cares?
My congratulations to anyone able to make their way through this book.
I, it seems, do not have the stamina to make it through ESR's 80:20 ratio of repetitive ESRisms to possibly insightful content. (No promises on the 20%.)
The Unix Philosophy, Gancarz, is far more my thickness, far less diarrhea of the keyboard, and in the noggin after reading.
On second though, my sympathies.
Is not about the command line or GUI.
It is that Microsoft's own development teams have always programmed with inside knowledge of the OS, able to bypass the official API whenever necessary.
This was explained to me by the director of a large bank in Brussels that abandoned a huge Windows-based project after finding that COM+ and MSMQ could not talk to each other, and this after spending time with the actual developers at Microsoft to resolve the issues.
Each Microsoft application is written "to the metal", reimplementing huge pieces of code that should be abstracted into layers.
Many of the security issues in Windows software stem from this design model: a typical Linux security issue can be fixed by a single patch in one layer, but typical Windows security issues reappear in application after application.
And this is where the Unix model is strong: it is all about layers, formal documented interfaces, and clean separation. When Microsoft decided to add MSIE to the operating system, they were not just screwing their competitors, they were setting themselves up for a fall.
Good software must be built in layers, with formal and definite separation between layers. Microsoft is learning this now, mainly because it simply cannot make its current designs secure.
Silence remains golden. That more you say, the less attention what you say receives. Humans have limited bandwidth, and conserve it for interesting things. If you program continually spits out verbage, no one will notice the important line in the middle of the verbage. If you program throws up dialog boxes like there's no tomorrow (Are you certain you want to print this document?), then people will start answering "yes" to all of them without reading them (Are you certain you want to reformat your hard drive?).
In the world of programming pipes, output must be dealt with, making this maxim even more true. If your program outputs "Foo" to standard error, than my program, which is looking at your standard error for items of concern, must know all the noise you output and ignore it properly. The less you make me do this, the better.
Occasionally, the extra output is helpful. This is why the -v option exists (occasionally, annoyingly, -d).
"If you cannot say anything nice, do not say anything at all" is actually totally backwards. "If you cannot say anything bad has happened, do not say anything at all".
The rule of exceptions states "for every rule, there is an exception". This maxim is not an exception to the rule of exceptions. There are cases where you want to output noise. One such example is telnet, where you need to distinguish between "connected" and "trying to connect", and both situations are common.
Hey, no problem. I just won't waste my time by subscribing.
Let me expand on this a little: "Now if I want to expose my product so it can be expanded upon I will present a programmable, simple and documented API."
...) is a matter of the programmer's skill, not their culture.
Windows programs are written to be *used* by one class of people, and *extended* by another. In Windows, the end-user can not use a "simple, and documented API", only a programmer can. In UNIX, or to a lesser extent on the Mac, programs are expected to use a *common* "simple and documented API", so rather than only letting the elite caste of programmers get in on the action these platforms encourage everyone to do it.
So in a way, it's Windows where programs are written for other programmers, but on UNIX they're written for everyone. Whether or not hey have a functional and easy to use interface (and lord knows there are plenty of Windows programs that fail that test. Solomon 4, Lotus Notes, Microsoft Reader,
I'm both a UNIX programmer/user and a Mac user. I have a friend who's the average Mac advocate around...which means NOT a UNIX programmer. Though we both love OS X, we do have conflicting views about UNIX. I see UNIX among all things as an excellent development platform and he sees Darwin as just a secure foundation for Aqua. He also looks at open source from a regular users' point of view...and not as a programmer...which really makes all the difference if you think about it. The open source movement is a pro-programmer movement.
I think Apple has recently been trying to get more developers for OS X (though ProjectBuilder or XCode) because traditionally Macs aren't programmer-friendly. I'm a programmer. I love programming and once in a while I make small applications for UNIX and the Windows prompt (if they're ANSI and easily portable to Dev C++). Sufficive to say (man that sounds too Star Trek), I've only started compiling these small apps to the Mac now that they have Darwin (and GCC!!!).
There are now 2 major cultures using the Mac at the moment. The UNIX people, and the "I'm just better than you are because I use a Mac" people (the classic Mac crowd). When I first got my iBook a few months ago, I registered in a local Mac forum. I eventually stopped posting simply because of cultural differences.
Apple is attempting to bridge these two cultures mentioned below (taken from the article).
How did we get different core values? This is another reason Raymond's book is so good: he goes deeply into the history and evolution of Unix and brings new programmers up to speed with all the accumulated history of the culture back to 1969. When Unix was created and when it formed its cultural values, there were no end users. Computers were expensive, CPU time was expensive, and learning about computers meant learning how to program. It's no wonder that the culture which emerged valued things which are useful to other programmers. By contrast, Windows was created with one goal only: to sell as many copies as conceivable at a profit. Scrillions of copies. "A computer on every desktop and in every home" was the explicit goal of the team which created Windows, set its agenda and determined its core values. Ease of use for non-programmers was the only way to get on every desk and in every home and thus usability uber alles became the cultural norm. Programmers, as an audience, were an extreme afterthought.
I'm sure there is SOME unifying philosophy behind Windows. I have no idea what that might be, nor would I wish to. But I found this book about the philosophy of UNIX very enlightening when I read it back in the day. It was an epiphany for me at the time to realize that there WAS or could be a philosophy behind an operating system. But this was the book that made the concept clear for me.
Quod scripsi, scripsi.
The very fact that the Unix world is so full of self-righteous cultural superiority, "advocacy," and slashdot-karma-whoring sectarianism while the Windows world is more practical ("yeah, whatever, I just need to make a living here")... - Joel Spolsky
I have subscribed to Joel's mailing list for several years, and have programmed on both sides of the fence. Joel paints a black and white picture of the differences between Unix and Windows - which I must say, is not true. I have to disagree with Joel's oversimplification because he has made the same mistake that he accuses ESR of making: namely that his own monoculturalism has clouded his view of Unix programming. Anytime someone makes a statement that starts with 'the very fact', you can be sure there is less fact and more conjecture than the writer is willing to admit.
The key error in his analysis is narrowly defining the Unix program as being a command-line 'mostly' affair that doesn't tell 'Aunt Madge' when it succeeds. This is not exactly true; while it is true of strict command line applicatioins (which Aunt Madge will not use anyway) - the GUI interfaces do not follow that formula - and programmers are free (not constrained as he would suggest) to build interfaces that meet whatever needs an end user may have - whatever their skill level.
Just because 99% of the end users are familiar with and resist change from the Microsoft GUI does not mean that it is the best UI - it just means that people did not have much of a choice from the beginning (there were only one GUI for PCs back in the late 80s - Windows; the other major GUI was tied to the Apple Macintosh). While the Windows GUI stagnated over the 1990s, the Linux world exploded and a plethora of user interface ideas have surfaced that are effecting the new Windows interface. Same story (DOS - a rip of CP/M), different day ("yeah, whatever, I just need to make a living here").
He also touches on, but does not explore with a self critical eye, the limitations imposed by not having source code. The dependence of Windows programmers on Microsoft APIs provides too many limitations, and increases the likelyhood of unforseen interactions that cause bugs. He whitewashes these issues by simply focusing on the size of the Windows desktop deployments vs. *nix.
The reality is a *nix developer has all of the options available to him; he is not constricted by artificial barriers; a Windows programmer is at the mercy of Microsoft - who can change APIs at the drop of a hat.
His quote above really hits the nail on the head: the Microsoft monoculture is about money above and beyond any moral considerations. I would much rather be a "slashdot-karma-whore" than a Microsoft-whore. From his writings over the years it is plain that he absorbed the 'money is good no matter how you get it' mentality during his stint at the company.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Nigger, please. Take a look at this thread, for example. Take a look at the sheer number of idiotic posts that have been modded +3 Insightful. You mother fuckers do nothing BUT karma whore on /.
At other times you need to do the same repetitive task thousands of times, over dozens of machines, every single day. You'd better be able to automate that, so you need a command line option here.
So, here is my rather remarkable suggestion: programs should, as a rule, cater to BOTH. Have both the gui and the commandline option available at all times. When you need it, use whatever is best for you, mixing options any way you like. Because gui and commandline are not at all mutually exclusive, no matter what many uninformed people will tell you.
Note to self, never post before coffee. Yes, its a dupe. get over it.
Ya tell that to the Slashdot Subscribers, they pay for this shit. You want to run a business, do it professionaly.
The Linux user may say, "How could I do this better?" but the Windows user says, "How would Microsoft intend for me to solve this problem?"
/syle
Your friend is right. When you work in a closed source world, your only option is blind obedience to the people who have the source. The alternative is simply blind disobedience, and then you have no recourse when things break. At least when you obey the Priests of the SOurce, you can (eventually) get them to listen when the API is broken. Disobey them and you will be shunned.
"Breaking things" is subjective. Does a beaver who builds a dam break things? Does the farmer who rips out a beaver dam to un-flood his fields break things? If a service pack breaks something, it means you have disobeyed the Priests of the Source. Repent and change your ways.
His way is best if you want to be certain that, when things break, it's Microsoft's fault. Apply the service pack and things break? It's Microsoft's fault for creating a faulty service pack. Don't apply a service pack and things break? Microsoft's fault for writing faulty code in the first place. It's a CYA mentality.
I'm all for keeping software up to date, but if it breaks things?
How do you know if it breaks things if you don't try it?
How do you know it doesn't fix things?
I'm not a huge fan of spending weeks trying to debug and workaround some glitch that could have been fixed by simply updating the core software.
There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers."
Well, I think this is more of a lame attempt to *divide* the programming community rather than an *informative, educated* observation. Especially the *....Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers...* piece. There are obvious differences, differences that are tied to the platform you are programming in, but I strongly disagree with different *cultures*. Programmers care about a lot of things, and code is only one of them. Most programmers I know (including myself) want to write clean, fast code, and we all hate commenting it. In fact styles of code writing are quite fragmented to personal styles. I have often been able to tell that two different people wrote two different simple functions, using the same language for the same program. There is of course a *better* conformity when the projects involve managers, teams etc etc. Ultimately, I think this: As a programmer, there's a personal achievement and satisfaction when I write code and accomplish something with it, or someone else accomplishes something with the code I write. What identifies programmers with one another is not the platform or style or culture of writing code, is the love for what we do
The phaomnneil pweor of the hmuan mnid. Fcuknig amzanig eh!
Every programmer should do a serious stint in both worlds. I think starting from UNIX and then doing Windows is likely the better option, but people owe it to themselves to broaden their knowledge.
This is clearly not the right forum for positing the benefit of the Windows culture, but there are important things to be learned. Market-driven features, profit margins, target audiences, usability, managing customer expectations. . . These quite aside from the actual coding differences (which, as I get older, seem less and less important).
A firm I work with is porting a lot of their servers from Windows to Linux. They aren't, however, doing it because Linux is cool, or better, or any of the reasons people like to play with it. It's because it's cheaper and finally, with 2.6, mature enough to be a serious option. I lobbied for Solaris/Intel, but unfortunately that beast seems destined for failure.
The more developers get a feel for the real market pressures that influence their lives directly and indirectly, the better a position they'll be in to comment intelligently to their superiors and take greater command of their destinies. Coders who plead to use Linux because it's 'cooler' can be smelled a mile away. Rational, business-oriented arguments, however, will not go unheard by forward-looking firms.
-ac
I'll start with the no. No, it's not a CYA mentality. If you're creating an app for your end users, your end users will blame *you*, not MS, if your apps has bugs. You have not C'edYA by installing the service pack. What you've done is you've kept your machine standard, which is very important in the Windows and Mac worlds. Now your machine is more likely to resemble your customers' machines, or a form that you can easily get your customers' machines into (tech support will tell them to install the same service pack). So, if you can make things work on your machine, even if it requires bug workarounds, things should work just the same on your customers' machines.
And now for the yes. "Blind obedience to the people who have the source" is putting a silly spin on it, but the fact is that both MS and Apple have roadmaps for evolving their entire platforms, and following their advice regarding how to do various things is the way to maximize the chances that your app will continue to work correctly as the platform underneath it evolves.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."