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.
I introduced one of them to Nessus, not because it was a Unix program, but because it is a damn good (the best?) security auditing tool available.
His reaction to a security audit showing our primary app server had multiple potential holes just in the programs that support the app? "Well, we don't use that software much, we only use it to get into the program. All the work is being done using the other programs."
For the record, the system was an HPUX server running an older version of Apache 1.x. The app gateway is through Apache to Weblogic, though the main application program runs on the HP box, not elsewhere.
This is not simply an aversion to Unix or command lines. The lax security extends into all the Windows systems as well. For example; all drives readable/writable on the network by any user.
It's a lack of professionalism, not intellegence -- the guy is plenty smart. Adding a little fear to the mix (we print checks dammit!) doesn't raise his concern too much. I've not raised the possibility that he, personally, might be held to blaim for security issues and I doubt that it would work with him.
My only hope is that slowly, without forcing him, he will see that there is something behind my comments and tips. Maybe a light will go on, and he will decide to take a look.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
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
Of course, if there was a bug in the library itself rather than the application using it, it would be another matter.
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
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.
Ceci n'est pas une signature
If I recall correctly, the "silence is golden" maxim in Unix programming arose as an artifact of Unix's origins. When Dennis Ritchie and the rest of the historic team at Bell Labs began work on the earliest editions of Unix and C, they were operating on teletype terminals that ran at 110 baud (kinda humbling in this day and age, ain't it?). 110 baud translates to roughly 13 characters per second, so a program that was too chatty wasted precious bandwidth. If they had something like the cp(1) command operating the way the MS-DOS COPY command did, displaying messages like "14 file(s) copied.", which is 20 characters (plus the newline), it would take about a couple of seconds to display, while displaying nothing would be 20 times faster. It had nothing to do with making programs work better with each other and everything to do with conserving bandwidth. This is also the reason why ed(1) and vi(1) have such eccentric design, preserving a resource that was scarce in the day they were made.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
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?
he identified one severe problem but put the wrong spin on it!
observing that a program that produces no output because it succeeded cannot be distinguished from a program that produced no output because it failed badly
With Windows programs, you just never know. In general, I pick up a *nix program, test it a few times to verify that it does indeed do what it was supposed to do and then I use it. With Windows programs, I just never feel secure. I find myself saving more often, checking output at myultiple times through the process and wasting sooo much time verifying that everything did what it ought to have done because I am never quite sure.
Now this is a profound cultural difference, but I think it has little to do with writing for Aunt Madge or writing for other programmers. I think it has more to do with the culture of quality and craft (*.nix) or the lack thereof (Windows).
Many Windows programs "babble", not to reassure Aunt Martha, but to reassure Windows users who have grown up in a culture of "slap it together, get it out the door and let the user worry about any problems with the way it works". Without some confirmation the user just never knows whether a given program is actually working or has crashed. Many Windows widgets including moving progress bars, constantly moving icons and spinning logos are there just to reassure the user that something is indeed happening and that Windows has not crashed in the meantime.
Poster 1: "Wow that was a dupe"
Poster 2: "Hey everyone, this is a duplicate"
Poster 3: "Stupid editors don't read before posting"
Poster 4: "Only idiots duplicate the previous post."
etc... ad nauseum...
Pot, Kettle, Black.
Eric Raymond is really good at rephrasing conventional wisdom so tat it sounds new, which is useful, but it's too often confused with real wisdom.
... because it's so HARD to use programs together in Windows... no, better stick to elephantine "suites"...
Joel Spolsky doesn't appreciate the context that UNIX comes from.
When UNIX came out, *it* was the user friendly operating system. The interface was linguistic rather than iconic, but compared to what came before it was a breakthrough... it was the "Macintosh" of the '70s for the academic world.
Before UNIX you had "linguistic" interfaces, but where UNIX is "process this file with this program", these were more like "Whereas the program, 'this program', hereafter known as SYSTEMUTILITY.GIBBERISH, and the input files, 'this file', to be provided later and to be known hereafter as "GO SYSIN DD *", do AGREE to enter into a contract for processing, known hereafter as EXEC, the user humbly requests the opportunity to render this job to the SYSTEM...".
This was a breakthrough. And once you learn the language it is far more "user friendly" than any amount of icons for those tasks it's good at.
The real cultural divide is that UNIX programmers want programs to work well together so they'll be widely used and eventually sell well, and Windows programmers want programs that look easy so they'll sell well or at least be widely used. The aim is the same, the method is different
The solution, UNIX and Windows programmers can meet in Mac OS X and everyone wins. You get Mac programs playing well together in Applescript, UNIX programs in the shell, and "osascript -e" to tie it all together...
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.
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
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.
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