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.
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.
Of course, if there was a bug in the library itself rather than the application using it, it would be another matter.
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.
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.
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
I have a friend who's a Windows programmer.
I, on the other side, am a Linux programmer. We've worked together on a few projects, and there were differences in the way we looked at solving problems that were sometimes almost insurmountable.
The biggest difference between the two of us is that he has an almost religious believe that, if Microsoft says you are to do things a specific way, you have to do it that and no other way. I, on the other side, try to do things the way I think they work best.
One example is his belief that, if there is a service pack, you need to use it, even if it breaks things (as some visual studio SPs do in some cases). He gets really upset if you don't apply them. I'm all for keeping software up to date, but if it breaks things?
I have to say that his co-workers and fellow Windows programmers don't all agree with that philosophy though...
If a train station is a place where a train stops, what's a workstation?
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...
*cragen
Most UNIX applications are aimed at end-users, not programmers. Most UNIX users never need to see the command line. The main architectural difference between UNIX and Windows is that in Windows the components that communicate with each other behind the GUI are called "DLLs" or "COM interfaces" or customized plug-in APIs, which are complex and fragile and so MUST be kept far away from the user. In UNIX they're called "programs" and "scripts" and "pipelines", and they are simple and reliable and so don't need to be so deeply hidden.
Having simple and reliable interfaces that users occasionally deal with is not a horrible thing. Consider the third common platform, where the components are called "DAs" and "Extensions" and "Programs" and use a relatively simple and reliable interface called "Applescript" to communicate with each other...
To tell you the truth, I do still mark global and static variables with a g and s respectively and put m_ in front of my class members. But I picked up that habit in the embedded world, as far from MS as you can get. I've used it in the MS world before too, but I don't think it did much for most people and its a bitch when you need to change variable types.
However I will have to say that type awareness is MUCH better taken care of using things such as std::string (as opposed to TCHAR, char*, char buffer[3234] so on and so forth), and also putting on all the compiler warnings and using lint as a normal compilation step. You'll catch a LOT more bugs than using hungarian. Splint and PClint(unix varient by same company called somethig else) are two up to date lints. At first its just painful to do so, but after you turn off a couple warnings and get the codebase into compliance initially, all the programmers start writing lint-passing code by default (just like they ususally write code that compiles). This has the added benefit of those habits continuting on to other pojects as well.
Another reason UNIX gets away with no hungarian, is that windows has HUGE functions much of the time. This is because many of the calls take bizzare structures or 5 calls to setup. Try to get the text back from a common dialog that you have starting in a certain initial directory. You'll see what I mean about requiring several lines of code to get things done.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
Sheldon, old bean, I've been doing Windows support and development for about ten years now, and I was the guy responsible for bringing NT into the division I was working at in the first place.
Windows programmers may want programs that work well together, but they don't seem to know or care what "working well together" can mean. To the user, there's a very small set of operations they can perform on most programs, and a slightly larger set they can perform on a small set of programs, but there's no general user-visible glue that will let them do things like ``tell application "iTunes"; play "track 01" from "Goldberg variations"; end tell'' or ``sort +1 addresses.txt | grep "gullible" | mailmerge letter.txt''.
And, unfortunately, what I say "they" I mean "we".
"Hi! My name is Peter da Silva, and I'm a Windows user."
(chorus) "Hi Peter!"
"unix isn't intuitive and it is hard to learn"
Compared to what else was available when it came out? Have you used Exec/1100? OS/360? RSX-11? Not if you're just graduating, you have no idea what the "languages" I'm comparing it to were like, what we had to put up with before UNIX.
And what are you referring to as UNIX? Gnome? KDE? CDE? Motif? X-Windows? None of that is UNIX. X is a platform-independent window system, the first X workstations I used weren't even running UNIX, they ran VMS! The first UNIX "desktop" environments were built on Motif, which was based on the OS/2 window model!
You can learn *unix*. Your aunt madge can learn *unix*. The piles of Windows-style GUI stuff layered on top of it? Get a Mac and you'll get an API and GUI designed for Unix back when Steve Jobs was at NeXT. But the shell? Sheesh, if our middle-aged secretaries can handle it, you can.
Here's a quick rundown: the UNIX shell is basically a simplified and regularized English. Programs are verbs. Nouns are files. flags are adverbs and adjectives. There's basically three conjunctions you need to know: the semicolon which serves the role of "then", the pipe which serves the role of "and", and the ampersand which you can think of as "meanwhile"... it lets you do flashbacks in your story.
That's pretty much it. There's a lot of flowery stuff around it but you don't have to deal with it at the command line unless you really want to.
So, here's a command:
sort addresses.txt | grep gullible | mailmerge spam.txt
What's that do?
"sort addresses.txt, and find the gullible addresses, and send them the spam in spam.txt".
As you learn more words, you'll be able to do more things, but that's true of every language. I've been speaking English for fortysomething years, I've been a nasty scrabble player for almost thirty, and I'm still learning new words and new ways of expressing myself. That's not a problem, that's an advantage.