Slashdot Mirror
Explaining The Windows/UNIX Cultural Divide
giampy writes "Joel Spolsky writes a review-like article on the last book of Eric S. Raymond (The Art of Unix Programming). His views on the cultural differences among Windows and Unix programmers are well explained. Overall, an interesting read." Also on the topic of Windows, badriram writes "Microsoft is reorganizing the windows team, it seems the are separating the
OS core development. Seems like things heading in the right direction in creating a more secure OS, and making it more business oriented. Read the
article here."
I reckon there might be a gunshot wedding again (with Billy G wielding the gun) if the separation of the parties results in longer delivery times, harder work for "interoperation" etc...
Simon.
Physicists get Hadrons!
forget the programmers, until general knowledge of computers improve and stuborn idoits don't need to have things like " why do i need a password to run a program on MY OWN computer" explained the state of computer security will not improve.
If you mod me down, I will become more powerful than you can imagine....
Eric S. Raymond has just written a long book about Unix programming called The Art of UNIX Programming
oh, he has just written it? How could it be that I was reading this book for over a year now?
#
#\ @ ? Colonize Mars
#
Should of???
Oh, please.
Should have!
The fact that you can't use a *nix machine the way you want isn't a reflection of the Windows/Unix divide - it's a reflection of your personal preferences, experience and background. It's not remotely cultural.
I can't make my Windows machines work in the way I like to (mix of command line and GUI), whereas I can make my iBook and my G4 work wonders because I know OS X / Unix well. That's not cultural either - it's a reflection of the fact that my computing experience has always been some distance from the Windows world.
Just because you don't like something or don't feel comfortable with it doesn't necessarily mean it's a fault with the system as a whole. It can equally easily be a "fault" with your own experience.
"This is why men never share their feelings; because women always remember." -Just Shoot Me.
If you read the article, you would notice that the ENTIRE POINT was that there isn't one true way of doing things. The secondary point is that some *nix people are pulled into some sort superiority complex.
Great, but this article is about ESR, a vocal libertarian.
LordBodak's journal.
Although I understand and agree with your basic point, I would ask that you consider the "product" of a computer and how that relates to average "consumers" need for a tool to make their lives easier/more entertained (because that is, after all, the basic reason why average consumers purchase computers).
Consumers want a tool to use, whether it be for games, email, finances, or just internet surfing. Quite frankly they don't want to spend a ton of time learning about how to use it, and many don't care how or why it works just as long as it does work.
The tug-of-war that exists is that computers by their nature are complex and flexible. Consumers by their nature are very insistant on their desires which in include simplicity, flexability, safety, cost, and utility.
Calling them "stubborn idiots" only highlights the divide of understanding between the computer literate that understand and desire ultimate flexibility, and the average consumer that just wants to use their computer, like a toaster or a vcr or a Sony playstation, without a lot of hastle.
Somehow the creators (programmers and hardware vendors) need to accomodate for that, because I assure you that the average consumer won't change.
Although I despise Microsoft's business ethics, I appreciate their dedication to the principle that I mentioned above.
Linux is in a very good position to make headways in this regard as well, but it will take a fundamental understanding by the programmers and harware teams of said principle to make real headways in the desktop market.
Anything less will ultimately limit the adoption of Linux to, for example, server, web, and corporate applications.
"The masses" are what they are, and deriding them for it won't influence them to change, however it will influence them to avoid the product.
Lets find a way to meet them where they are while preserving the fundamentals.
Is the juice worth the sqeeze?
I am not sure why people bother reading Joel Sporsky's weblog -- half of what he writes is tripe, and half is heavily biased by his ego. Someone else quoted Joel's jab at how "the Unix world is so full of self-righteous cultural superiority;" apparently he does not realize that he is an exemplar of the Windows version of the same.
If I wanted to follow his lead and oversimplify the differences between Windows and Unix programmers, I would say that Unix programmers care about code (period) and Windows programmers care about the quick buck. Mr. Sporsky's crass and half-informed self-promotion is an excellent example. (Ever notice how often he plugs his company and software while griping about software development practices?) I have seen the insides and outsides of commercial applications for both Windows and Unix, and the quality under Unix is generally higher than under Windows.
What is it that microsoft gives you the "freedom" to do that you can't under unix? Besides running 95% of commercially available software. It's ok that you like GUI apps, I use mozilla, gaim, and xchat frequently myself. But linux has a GUI too, and for my purposes at least it's better than windows. Why? Network transparancey.
But I don't mean to get into a bunch of feature comparison here. We're talking about cultural differences. So here's an example. When I don't know how something works in linux, I can run the program with the -h flag, use 'man' or grep through the config files and figure things out pretty easily. If I can't figure out how something works in windows, I'm presented with a control panel full of dialogs with subdialogs and submenus under that. How do you ever find anything?
So really, I don't understand why people consider windows so easy to use. But there are two parts to the mantra "simple things should be easy, complex things should be possible" Windows fails on this part too, but mainly because it shuns the command line. Suppose I want a program that will take all the files on a cd, check them against an md5sum file or create one if there isn't one, and burn them all to a new cd. That's just a few lines of bash, but with a gui app you're stuck doing all that manually.
Is that really the way you want to use your computer?
Give me Classic Slashdot or give me death!
This story will be duped at some distant point in the future.
The latest Slashdot meme.
A point I noticed is when Spolsky talks about the Silence is golden rule and gets it all wrong. The rule is complemented by "If a program fails, it should do so in the quickest and noisiest way possible". This rule is also complemented by the possibility of someone else to write a GUI or a text interfase specifically for showing the results of a command.
This goes without saying that the rule actually means "When a program finishes successfully it should'nt output anything but its normal output. If you say
you see all that output, but not a "command finished successfully" afterwards. If you say you see the file.tar.bz2 done, not a "hey, here I am!" message. This is well, and does not mean "The program doesn't say anything. And it is possible to add a "clarifying" interfase on top of it."I think it would be a good idea!"
Gandhi, about Internet Security
> 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.
no, the REAL difference between these cultures is that Windows programmers feel that Notepad (even with syntax highlighting) is a perfectly good text editor for source code.
No, what makes it wrong is the fact that directory separators are used more frequently than switches, and the positioning of "/" on keyboards is way more consistent than the positioning of "\"
To understand recursion, you must first understand recursion.
Good. Great. Bully for you.
I'll give you the benefit of the doubt that you truely limit your comments to your wants and needs. The problem is that the standardization naz^Wadvocates (oops, almost invoked Godwin's Law, sorry about that) always extend their needs as trumping everyone else's needs. This is just as much a crime when it comes from those whining that Linux needs a standard GUI (or whatever) because the unstated subtext is always "the one I am using".
My needs are different from yours -- I find that I cannot use a Windows system the way I want to, and am much more at home on a unix system. I find I cannot use a KDE inteface the way I can use a olvwm interface. With a modular system like unix, I can use the interface I want, even as other users on the same system use a completely different one, and all without causing undue problems between them.
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
> Have you considered that providing software for free to
> countries such as China is essentially tacit support for
> oppressive regimes?
Have you considered that selling software to countries such as China is essentially explicit support for oppressive regimes?
http://www.microsoft.com/china/
Oh wait, this post makes no sense either.
I just had a Windows programmer/sysadmin type tell me that all he does is play with the program in question until he figures out how it works. He told me that help files are useless. I on the other hand live by the documentation and everything better damn well be documented or I ain't trying it.....not on my production system. I don't mean the easy stuff either. the more touchy something is, the more I want to read befor I attempt it. Man pages can and do suck, but everyone I have come across pointed me in the right direction. Windows likes to hide things even from the programmer. I don't think thats a correct way even if your writing a program focusing on the end user. If something goes wrong, how do you track it down?
The registry would not be as bad as it is if it was better documented. I know I know....if you subscribe to MSDN or some other microsoft money scheme, you can read the documentation. Well, users should have access to that if they so want.
Things like this is why OS/X does well on both fronts. You don't HAVE to look at the commandline ever if your just using it. If you want to write a little script or automate something, the command line is there if you need it. Microsoft on the other hand went so far as to say that Windows ME had no access to the DOS prompt, yet with in a minute of installing it, I had a DOS prompt.
I happen also to disagree with this guy that UNIX programmers typically write a command line program first. Some do, but I have seen others which are useless without a GUI program.
Commandline is valued because you can take different command line programs and pipe it here, append to a file there and have a script or program that does what the original writers of each module never dreamed. There's something to be said for that!
Just one tiny example where the UNIX way ends up being better for users:
The gpsd project is a project that takes the gps data collected by a serial port and makes it availble not just to apps running on the local machine, but also across a network. The advantage is that if you have programs wrote to work with gpsd, you can use MULTIPLE map programs at the same time each showing your current position. You don't have to juggle the serial port between 2-3 programs if you use one map program because of one reason and another map program for another reason. This has not even been dreamt of yet on Windows and the only way to accomplish it on Windows is using 2 GPS's each on their own serial port. To make the data available to any application that want/needs it, you just configure the daemon to look at the serial port your GPS is connected to and then other programs can get the data from the daemon instead of the serial port.
UNIX programmers program to work around limitations in the platform and are able to make the platform do what they want to do. Windows programmers will just say that it's not possible or Microsoft does not support it. UNIX programmers say: Nonsense! You are a programmer right? Then write a program or API that does what you want. Some say that this is a weakness, but I say it's a strength that makes UNIX a tool that actually makes it easy to make it do what you want. Some users don't want or need this kind of power, so they are happy with Windows. The ones that need it turn to Linux or UNIX.
Gorkman
Is this bad enough news? No.
Furthermore, until the same "benevolent dictator" FORCES ALL *nix to employ the use of focus groups, user feedback, and other methods of optimising the UI to suit the needs and wants of the AVERAGE JOE, ALL *nix will continue to suffer a host of maladies from merely looking clunky up to and including full incomprehensibility to the guy we're trying to promote this stuff to.
Apple came a gnat's whisker from pulling this double burden off, but because they run a MORE EXPENSIVE machine that is NOT COMPATABLE with the Great Shoal of Computers, they failed.
Proceed with the downmodding children, I can take the hit.
Is it fascism yet?
No, you still have to display the newline. Hope you're not a programmer...
Three years ago I had to do something very simple with Microsoft's Crypto API. It has two layers: high and low. The high level functions did some common tasks, though totally non-customizable. So I had to use the low level ones. The documentation was vague. Only if they have published the high level functions source, me and the company I worked for would have saved a month. Or maybe I'm mentally retarded. So here is another example: IFS kit. It costs $1000, and it comes with 0/zero/none/not a single line of documentation about writing network file system drivers! Don't get me wrong - I don't like reading Microsoft code (the MSDN "examples" are just enough!) but if I had the source code of the relevant parts of the IFS kit, I would have finished that stupid task a month ago. Now, we're waiting for some preliminary documentation which is to come after 2 months. And 6 years after the first version of the kit... So, poorly documented open-source libraries may suck, but poorly-or-not-documented-at-all Microsoft libraries sick a lot more!
I agree.
That is not to say however that my home machine doesn't need security, especially as the world becomes more networked.
Password based security is the most nightmarish of security scenarios: a partial success. Successful enough for people to rely upon, successful enough to impede the adoption of better approaches, but not successful enough to provide the security and convenience people need. Some people do OK with them but they're a tiny minoritt. Upgrading humanity is not an option. Indeed I suspect that the majority of computer "experts" would fail if audited according to strict password management standards.
The problem is that passwords are an ugly hack that were adopted when the problem was less severe and the stakes were lower. They're a huge Achilles' heel.
Personally, I think a key like device like an iButton would be much better. It's intrinsically more cryptographically secure than a memorizable password, as well as practically more convenient to manage in a secure manner. In high security apps the key device could be enhanced with biometrics or even password protection, approaches that are insufficient on their own but could thwart casual, opportunistic reuse and buy time for privilege revokation if the hardware key is stolen. The very fact the hardware key must be physically taken away from its users is a huge advantage. Passwords can be "stolen" without their owners knowing.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
There are two ways to solve this - bring the functionality into the same address space as the GUI (so if it hangs, force quitting won't leave the confused backend around), or use a network-style protocol with a defined ping/pong approach, and when the backend fails to ping, kill it.
But text-based interfaces are always fragile. Just look at any of the millions of cdrecord frontends out there. They never quite work properly, because cdrecord-of-the-week always has some new diagnostic message, or error, and the program gets confused.
However, as the snippet from the original article above shows, I don't think my interpretation is entirely (if at all) incorrect. Mr. Sposky seems to me to be saying that the Unix metaphor is "less usable" to "Aunt Minnie" (pretty insulting, BTW: my Aunt Minnie was programming calcuating machines before Mr. Sposky was born, but that's another topic) due to its inherent nature.
I am observing that the Windows metaphor works great for the first 2-3 years, but then the end user runs into a brick wall where he can't do what he wants, doesn't know why, and has no tools or path at his disposal to move forward. I have seldom seen a person who grew up in the Unix (or VMS, or TOPS-20) metaphor hit that same wall and not be able to figure out a way around it. It was primarly my Unix and VMS background that allowed me to figure out how to make Microsoft LAN Manager 1.1 actually work, for example, when the Microsoft technicians were clueless (another long story).
sPh
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 don't believe the grandparent post referred to their computer as being attached to a network. It has become a pernicious assumption that all computers are networked these days. I have a non-networked computer, and although it is behind locked doors, I use a password on it just for peace of mind. However, I find the recently common assumption that all computers are networked to be a real pain. Ever tried working on a program where all the documentation is html links? Not easy when you are on an isolated computer. It has become so bad that software boxes have as the computer requirements something like: Pentium 200 Mhz or better, 128MB RAM, at least 1 GB Hard Drive space, etc. but neglect to mention that Internet connectivity is required for use. Not everybody uses their computer as a websurfing device. It is still true that the most secure computer is one which is not attached to a network. You can try to tunnel into the computer I am typing this from, but I dare you to get the data on my other one!
Take cdrecord. cdrecord does the same stuff that the windows cd-rom recording libraries do: write a cd-rom. How do you feed the windows libraries data to write? I don't know. Are they self-documented? Nope. How do you feed cd-record? The most obvious way: give it an image to write via stdin:
cat image.iso | cdrecord
If I didn't know this, cdrecord --help tells me what to do. man cdrecord has a longer explanation with examples. I can get the application, usable by end users, and place it inside my backup scripts. Do this with the windows libraries or Nero or some other burning application. Tell me how long do you have to sift through documentation to do this: Find a way to backup a disk partition to a cdrom using the windows libraries. In any unix, this is something like:
cat /dev/sda1 | cdrecord
Will a end-user have trouble using command line cdrecord? Naturally. But cdrecord is a core application, which shouldn't be used by end users. That's what the Rule of Separation is about. Grab krecord or something like that, and use it.
If at first you don't succeed, skydiving is not for you
Or could you maybe give an example what that should be:
"But what if so much code has already been written that no programmer wants to go back and make all the changes necessary to make it really work?"
I can give you one. The APT library (the backend to Debian's apt tools) uses a built-in download manager to fetch packages and other files. So far so good.
Now, say I'm in the middle of a long download, and I decide I changed my mind about some packages. For instance, I want to install some packages I hadn't thought of or cancel some downloads. There is no way to do this in any interface without cancelling the whole download and setting it up again, and that's because the backend library does not support this functionality. You can access the list of individual download jobs, but there's no way to cross-reference between jobs and the packages to which they refer (aside from decoding URIs to guess what the package is).
I asked the authors about this, and they said (essentially) that they didn't want to go back and make all the changes. This is probably reasonable -- it's a fairly esoteric feature and could be a pain to get working perfectly -- but it is one example of a place where the backend can limit the frontend.
I do find it amusing, though, that the author of the article just implicitly assumes that the reverse is not true: ie, that designing the frontend first will never result in arbitrary limitations for the backend.
Daniel
Hurry up and jump on the individualist bandwagon!
"Or what if there's something in the back-end that just doesn't work once you add a GUI?"
His response: "then it needs to be fixed."
I think the point of his response here is that it can be fixed by refactoring the back end and that he finds the effort to refactor the back end not nearly as great as you imagine.
Give wodehouse some credit, he's been sneaky in his phrasing. MS Developer documents are indeed well written. They also happen to be wrong. My experience matches yours: MS documentation gives you the feeling that it must be your fault that things aren't working, because it's all written down right there! The fact that critical elements are both implicit and left out (typically other functions you must call first), is what makes it so devilish.
No, seriously? Windows GUIs suck... compared to what?
Compared to X? The same X where every single programmer just _has_ to use a different layout, different shortcuts, different menu structure, and for bonus points his own widgets? And where 90% of the GUIs were never even tested in any other resolution or font size than what the developper had? (Here's a hint: 100 DPI fonts are an X standard for a long time now.) And where every app is configured in a different way? And in some cases (e.g., IceWM), contrary to common sense, the changes you do through the menus aren't even saved, and you have to launch a different application to configure your start menu?
Sorry, from the end user point of view, it's the Unix GUIs that suck big time. They suck like an industrial vacuum cleaner. They suck like an expensive hooker.
They're made by geeks, for geeks. And religiously defended by hordes of flaming trolls, ready to insult everyone who dares doubt their idol's wisdom.
What a non-geek user expects is to learn some skills once, and apply those skills again and again. It doesn't matter if you have some cute unique idea. He just doesn't want to have to learn a whole new set of skills for every single program.
He wants that if in Word CTRL+X is "cut", then in every single program it's still "cut". He wants that if F1 is "Help", then by God, it better be "Help" in all programs. And if one program's scrollbars behave in one particular way, then it better be the same way in all programs.
For you discovering how yet another widget set works might count as fun. For Joe Average, it counts as a waste of his time. He'd rather do something else in that time. Like be done sending that e-mail, grab a beer and watch TV, instead of still being at discovering how it works.
And yes, the Windows developpers know that it pays to care about the paying customer. That means, yes, caring about Joe Average who's using those programs. Thinking how you can help Joe Average do what _he_ wants, instead of making it all an exercise in programming for your own ego.
And until more of the Linux crowd discovers the same thing, I just can't see Linux making it big on the desktop. Sorry.
A polar bear is a cartesian bear after a coordinate transform.
cat /dev/sda1 | cdrecord
UUOC. Instead,
This comment is just silly... point #2 is totaly unrelated to his prior comments as many open source projects are *not* command line oriented. If you think FOSS somehow equals command line, you have not explored very far.
Point #1 may be valid for your speaker, but most of the open source tools I work with are web based PHP projects. Surely you are not claiming that Open Office is "desktopically (making up words is fun!) bankrupt", and the result of "BOFH" mindsets. Or Gnome and KDE exist because all FOSS creaters hate GUIs.
If you are going to troll by creating a straw man argument, at least attack one that is credible.
Sig under construction since 1998.
I have extensive experience "programming Windows" and programming "UNIX" [ I live and work "without prejudice"], so I've moved between and am comfortable in both "cultures". Interestingly enough, I find that the cultural divide is much more pronounced now than 20 years ago (20 years ago, did anyone program exclusively for Windows? -- the platform was a joke...). I think that because the Windows SDK is controlled by Microsoft, it's more difficult to do really insightful programming for that platform. So much Unix and Linux stuff is "open", that programmers involved in that culture are exposed to more "inner workings", etc... Where programmers have ONLY used Microsoft's Visual Studio and have ONLY produced end-user, non-programmer apps, their skills I feel are limited. UNIX programmers can certainly produce apps for non-programmers (Open Office, Gimp, KDE etc...), but I think that "Windows Cultured" programmers cannot as easily develop "programmer's tools". I don't think it has as much to do with "culture" as much as "depth and varity of knowledge."
I was hoping maybe he was going to stop writing. That way we wouldn't get any more wingnut rants about how the way to achieve safety on planes is to give guns to all the passengers.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Translation: We didn't know what we were doing, so we fucked it up. And now when I remember, I blame it on the vendor. It's so much better that way.
I guess around the time they stopped making use cases and actually tried to scale the prototypes up to work on their clusters.
See above. Because I surmise you're concluding that the same group of people with the same design using some CORBA implementation and MQSeries or some other IBM software would have actually managed to finish the project.
[...] it was an engineer from the bank who finally discovered the real problem, apparently.[...]
Do you or do you not know what actually happened? "Apparently"? I thought you were talking as a sort of authority on why COM+ and MSMQ couldn't talk to each other.
The COM+ developers and the MSMQ developers knew their own products very well but were unable to figure out what was happening between the two.
Statistics are a bitch. Especially when they come in a single data point. You know, because I've successfully designed and implemented extremely complex systems using these two technologies. Yes, using clusters (AC2K) actually. In fact you could say they're my bread and butter. I think you're just like everyone else who has a chip on their shoulder and a dubious anecdote to tell to anyone who will listen. After all, you don't get the code and Microsoft is evil, so ergo whatever technology they produce can be reasonably expected to suck. There's always the very valuable "well I can't see their code so I can't fix mine" argument. Oh and, of course the whole debacle made the company cautious about using any other Microsoft technologies. Classic.
So I'd suggest that in the future, unless you have some technical backing and cold hard facts to go with it, to just keep this little story to yourself. Not because I fear FUD, but because it simply proves that, if you're an idiot, you won't be able to design decent systems or write good code, no matter what the platform or middleware technologies happen to be. Seems to me that this is quite evident from your case study.
Spolsky: "Aunt Madge might be justified in 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 or a program that produced no output because it misinterpreted your request."
Except on UNIX, even Aunt Madge will rapidly learn that programs just don't silently fail. If you can trust program failures to produce diagnostics, then you don't need diagnostics for program success.
IMHO, the biggest divide between the two camps is this: In UNIX, I am surprised when something is broken. In Windows, I am surprised when something works.
Funny... it's the opposite for me in my experience. Usually, using 'man' doesn't help at all. Sure, it gives basically what you'd find in a header file function declaration but not anything more than that... like... where does that parameter called 'file_des' come from and how do I get one (just pulling something out of the air) to use. Many times, a simple 5 line snippet of code at the bottom of the man page (something that used to be in many man pages) would explain it all. This is a place where hyperlinks are nice. I usually end up looking in Google Groups and get better help from folks who are struggling like I am who get help from someone who knows. Word of mouth isn't effective documentation.
Y'know, people keep saying that this is such a trivial little matter of implementation, but I can't help but observe that 20 years after the Macintosh came out, cut and paste in X windows is still completely fucking broken.
At some point, you have to abandon the excuses and admit that it's not just an implementation problem, it's a broken paradigm.
DEVELOPER: "Here's our GUI! Enjoy!"
USER: "Wow, thanks! This sure is pretty. So, how do I cut and paste?"
DEVELOPER: "Well, that depends on which toolkit the app you're running uses."
USER: "Uh, OK. Thanks." [user turns off computer, goes back to his Windows or OS X machine.]
In the above scenario, the user is right, and the developer is wrong, wrong, wrong, wrong, wrong.
But I haven't seen a lot of people pointing out that esr is also taking it too easy on the Unix culture.
I started reading the draft of esr's "Art" a while back, and was immediately struck that he was repeating the "do one thing and do it well" slogan as if anyone ever really worked that way. Has he ever seen the man page for "tar"? How about "find"? The Unix Way is more like "do one thing sort-of-okay, and then trick it out with options and modifiers and run command files and embedded scripting languages until you can't tell when it's going to fry eggs or flush the toliet."
You might want to balance out esr's idealized view with the half-serious ranting of The Unix-Hater's Handbook (pdf).
I think the chapter on X is one of the better X-windows tutorials around (though unreasonable people may disagree).
It doesn't matter what OS I'm using, if I'm word processing I save at every paragraph. If I'm developing, I save before executing. I trust no machine, no OS. They will all let you down some time, for some reason.
I develop for a living -- yes on and for Windows. I create a variety of applications: Web, desktop GUI, and command-line. It all depends on the audience. End users don't want to remember what list of switches and piping which into what will create the output they need. That's stuff's for techies and background processes. Users need a clean GUI that gives useful feedback.
Some days I ride in the font of the commuter train. From there, you can watch the engineer and take in the opperation of his interface. It makes all kinds of noises. This is called feedback, and is essential to good user design.
Sure, you can write a UI that merely displays a wait icon while the application performs the requested action, but that doesn't tell anyone whether anything is really happening. On the other hand, most users don't want to be bombarded with minutia about what the program is doing.
I think this whole discussion about programming culture is a load of bollocks. If you'd like Joe Blow to use your program, you're going to have to break-down and develop a GUI. This just isn't the day and age of the computer hobbiest anymore.
When developing a GUI app, you have to take the GUI into consideration, just as much as what the applicaiton's supposed to be doing. If your back end can't support your front end, then you've wasted your time, and your employer's money.
The slashes go "the wrong way" (hmm, any explicit biases there?)
/
In how many programming languages is \ not a special character in strings? MS uses C++ quite a bit, where you can't type stuff like ``/usr/local/etc'' in your apps.
URLs use
/ is generally found in the same place and is otherwise typed less frequently.
Hell, slash is easier to say than backslash.
Combine those, and you get the confusion I've seen many times of people typing ``http:\\blah'' or trying to read out some large path on a Windows system, usually starting with \\ to access a remote share and having to say ``backslash backslash data backslash stuff'' vs. ``slash slash data slash stuff.''
That it's even called ``backslash'' should be an indicator. When was the last time you saw a document use backslash as a separator for anything?
-- The world is watching America, and America is watching TV.
In fact, the real evidence supports a totally different conclusion. Consider that all k3w311 web pages have to mangle your precious scroll bars, either eliminate them or at least change the color. If there were comands to make them flip orientation, you could bet that everybody would be using them. Then consider something like winamp. Oooooh, skinable... translate, devoid of all OS supplied consistency. But that isn't a productivity tool, like say, Nero. That one just tries to make the application act like a high-school student's javascript-of-the-week-club web page with pretty clicky buttons instead of using the OS native menus and interface controls.
'Joe Average' learns to repeat single tasks. That's why he doesn't blink when you tell him to click on "start" to "shutdown" or show him a deeply buried directory at the top of his world and call it his desktop. He will click past the "critical update available" message as routinely as he will click on a virus laden nude celebrity attachment. Sure there are exceptions, but if you want to go for average, that is it. Is Microsoft better that Linux for the average? No, it is simply there.
Where I once worked, all the developers worked in UNIX. HP-UX to be exact. All had either X-terminals to a server, or preferably Linux boxes on their desks. We all also had Windows boxes, because the business used Exchange/Outlook for email. Many of the developers NEVER used the Windows PC for anything other than email. We therefore decided to see about handling our email under Linux or HP-UX, and getting rid of the useless, space-wasting, heat-generating other computer and monitor.
We could receive the email, no problem. Exchange did IMAP (sort of). But we had issues sending email, as we needed to do SMTP. We spoke with our email system admin, Dan. His official title was something along those lines. Dan knew nothing whatsoever about SMTP. Basically didn't know what it was. He was a Windows person, 100%. So we attempted to educate him a bit. That was a mistake. See, Dan was like a lot of Windows people. Windows and Microsoft enabled him to do his job, without having to know a lot technically. He was, to management, the email expert. We learned that by showing that he is not the expert (only to him and us even, initially), we endangered his view of himself as the email expert, and his role in the organization I suppose. We then became the enemies, because we presented him with something we needed, which he should have been able to provide, but was unable to due to his ignorance.
Windows has done this for a lot of people, such as the parent's author. It has enabled them. They are able to buy a PC, install software, learn how to click here and there, play games, do all the other cool stuff that comes pre-packaged for them. But when they are confronted by other users, ostensibly the same as them, who are able and willing to use a technically more challenging system such as Linux or other *nix systems, they see that as a challenge to their own view of themselves as a knowledgeable "power user." When the other users then heap scorn on the tool which has empowered them to use a modern computer, they see that in a less than rational way. They see it as a threat. And they respond as the author did. Or as Dan did. Or as countless other users of technology who don't really understand that technology, yet believe they do.
Sure, there are tons of Linux users who bait the Windows users and make stupid inflamatory comments. And sure, there lots of Windows users who do really understand Windows and computers deeply. But in general, a Linux user is a far more technically proficient person than a Windows user, by necessity, and that is a threat to the Windows "power user" who sees himself as a technically elite person, when he really isn't. And if you are going to bring up exceptions, remember: the exception proves the rule.
Larry
The Windows API designed decided to do EVERYTHING in one call. If they add new features in the future, then there will need to be yet another variant of the call. (As someone who has lived through Win286 to XP, this has been both predictable and the API design inflexible).
:-)
The UNIX approach was to make simple calls, and yes, it does amount to the same thing. You can make up 14 system calls (to set up "security", current directories, handle inheritance etc), and if you leave any out, you get sensible defaults.
The difference is the UNIX api designers went for simplicity and elegance. The Windows API designer went for a one shot function does all, and if new features appear in the future, you have to make a new API call. The UNIX api for making a new process has not changing since 1970 because it was simple and elegant. The Windows ones constantly change with new Windows features.
I will certainly grant you that exec* look like a mess, but in reality it is actually all one function with different calling conventions. There is actually only one system call. We certainly won't start on calling conventions
This doesn't mean that you can't have bad design, good design, simplicity, elegance etc on any platform. My general point was just that Microsoft tends to overcome stuff by brute force. Make more APIs, make more versions of them. The UNIX tendency has been for elegance and simplicity. Neither is perfect.