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!
Windows programming is like playing golf, UNIX programming is like pig wrestling, after years of development on both platforms I feel that UNIX programming gives me the satisfaction of sport achievements, the unforgiveness of UNIX makes very thrilled.
Having read the article thoroughly, this startling news shows the flaws in the brewing Open Source Zeitgeist that is gripping the software community. Have you considered that providing software for free to countries such as China is essentially tacit support for oppressive regimes?
Far-fetched? Think about it: With MySQL, the People's Army will now be able to do multiple queries on their tables of democratic activists in Olog(n) time instead of lengthy searches in card catalogs. The bureaucratic overhead previously allowed activists enough time to flee the country. How about building cheap firewalls so the people can't get the unbiased reporting that CNN provides? Or using Apache to publish lists of Falun Gong people to their police forces instantly? I doubt that never crossed your minds when you were coding away in your parents' basements. Consider putting that little thought in your mental resolv.conf file.
If that does not concern you ( which it probably doesn't, since the lashout.org paradigm is publishing articles about how not to pay for things ), consider something else. When China eventually goes to war with Taiwan, we want to be able turn their command and control facilities into the computing equivalent of a train-wreck. One of the advantages of Windows never mentioned in the article is the ability of Microsoft to remotely deactivate Windows XP in the case of a national emergency. Thanks to GNU/Lunix, Taiwan will be on a collision course with the mainland in the near future.
Which throws into question Mr. Stallman's motives. A known proponent of socialism, the Chinese government and RMS are natural allies. Could it be a back door to Stallman's dream of an uber-Socialist United States? We may never know for sure. Next time you consider contributing to an open source project, ask yourself this question: don't you want to make sure your work isn't used for nefarious purposes? Will you risk having blood on your hands?
Joel Sposky writes a review-like article on the last book of Eric S. Raymond
I hadn't heard that he died. My condolences to his friends and family. He will be sorely missed.
Why are you letting these clowns ruin our country?
That, or the fact that all the slashes go the wrong way in DOS/Windows because MS decided to use "/" as a switch rather than a directory separator.
When I am king, you will be first against the wall.
Does the story of how the divide between windows and Unix came about start with fallen angels?
They bridge the divide between Windows and Unix. They provide an easy to use GUI, yet still offer the chance to use the commandline stuff. Try SuSE 9 or Mandrake 9.2, its like how Windows 2000 Should of been like.
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
#
raymond's last book? i didn't know he died;-}
;)
Switching from windows to Unix is like resurrection though, from something worldy to something spiritual
Should of???
Oh, please.
Should have!
Only thing I know about Windows/UNIX cultural divide is that I cant use the computer in the *nix world the way I like.
And yes, that means I prefer GUI over commandline by far and would never touch commandline. To those who think it's a fault: It might be only a personal preference but trying to debate it is like trying to debate whether apples (fruits, not the computers) taste good. In that sense, Windows offers me greater freedom to do with my computer what I want to.
Review of his last book. Didn't realise the chap had died and was now no-longer able to write books. Its a shame to see the demise of such a great OSS proponent pass so un-noticed.
Very sad....
Unless of course the word was meant to be "latest" ?
An Eye for an Eye will make the whole world blind - Gandhi
That Microsoft has up and decided it wants to make a secure OS is of no consequence to me. The different iterations of Windows have moved from insecure and user-centered to insecure and Microsoft-centered. When networks get fast enough, I expect Windows will be loaded over a network only, and you won't be trusted to have an actual copy of the OS you bought.
Unlike many other people, I'm not waiting on Microsoft to release a useable operating system before embracing them. I'm never buying Windows again, ever.
You are incorrect, sir.
It is MacOS that is for fags.
HTH.
ESR: "Whenever possible, prototype in an interpreted language before coding C."
Hello, Mr Raymond, there are actually quite a number of high-level compiled languages, that will give you most of the convenience of an interpreted language with most of the speed of C. Write your prototype - and then deploy it, because it's already fast and robust enough for everyday use.
The whole point of this article is to see how many /. readers actually get to the end of it.
"slashdot-karma-whoring sectarianism" is tucked way down near the end in the last paragraph. Over 40 posts already and nobody else has spotted it yet!
Skiing? Check out The Independant Skiers Portal
" ... before ADSL it was a pain in the arse ..."
Another thing:
Unix guys say "arse".
Windows guys say "ass".
who's the troll? 1.yes linux has vunerabilities, but how many have been exploitable to the extend of the windows holes? ahh silence... 2. which windows emulator costs $300??? 3. i plug in my camera's usb... it works perfectly i didn't touch a thing, well except to browse my photos of course. the windows software that came with my camera is utter crap and doesn't work 1/2 as well. 4. there is plently of professional usage of linux outside of servers, your talking to one right now, and when was the last time you tried linux' printing abilities, they are excellent. 5. yes windows is hard to understand becuase it's closed source and poorly documented. 6. used K3b? it's easily as good as any win based cd recorder. 7. lets have a race, you install, configure and setup a mailserver/dns/fileserver/ftp server on win2003 and i'll do it on mandrake 9.2. i'll beat your ass becuase i have done both and mandrake takes 1/2 the time. 8. terminal services? x11 is built on a client server model from the ground up, unlike "terminal services which is tacked on, and thats not even getting into the horrendous cost of ms.... however some of your other points i agree with.. ( i am ignoring the obvious troll comments )video, games and multimedia are not as mature on linux. but this is hardly the fault of linux distro's as these technologies are held back by patents and copyright holders who don't have a clue. microsoft had better be careful or they will shut themselfs out and end up as the sad and lonely one looking in.
If you mod me down, I will become more powerful than you can imagine....
i wasn't aware cigarettes had an OS preference
bah!*@%!
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") stems from a culture that feels itself under siege, unable to break out of the server closet and hobbyist market and onto the mainstream desktop.
i think the article shows a bit of a polarised image. okay, i see the point of OS advocates being too tech-oriented, but we also have some efforts that really try to aim at end users, more or less succesfull. allright, it's not as easy as using MacOSX, but it's quite close in many aspects. and quite usable for the novice, especially in the distributions that try to make it simple (xandros, lindows, etc)
linux on the desktop? very possible. a lot more likely than the writer of this article would like us to believe IMHO
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
That's an interesting statement. I'd love to hear more details because I'm not sure what that means. Using MSMQ from COM+ is just like using it from anywhere else - the big caveats come when running clusters. Just a guess, but were they clustering MSMQ and also using a COM+ application on the same cluster?
The reason I ask is that when I was employed at MS I used to support MSMQ and write utils for the MSMQ dev team. Part of me is still curious when I hear things like this and I can't help but to look at them.
This space for rent.
And that is why you fail.
A computer isn't a Babage to Ballmer history lesson. It's a tool. A tool for automating mundane tasks. You seem to be confusing this for a tuol that burdens users with more unecessary mundane tasks. You are wrong, practically by definition.
And for the record, providing a password is an arbitrary convention. For a typical user who's not worried or doesn't care about someone getting into their computer localy automatic login is fine (hence provided for in linux distros), and occasionally, the computer may want reassurance that, for certain tasks, the local user is performing them. Typing a password, or dragging a set of keys icon onto a computer icon with a locked emblem and changing it to an unclocked, or superman emblem would both be a perfectly valid way of doing this.
Do you run an encrypted file system? I don't. You have locking hard drives in a locking case? I do, but that's more a quirk of fate, so the keys are ties with fishing line to their locks. And don't pretend that if you don't your system isn't any more secure than the guy who automatically logs in.
Your baseless elitism is a just one symptom of the cancerous idiology that contributes to the User hostility of linux. "It's for geeks, you can't be in our club."
Until that attitude has the dents taken out and a new polish put on it, it's going to be a while before it's the OS mom and pop are looking for.
I could give a rat's ass which platform it is since unfortunately I don't have the luxury to choose.
If you can read this sig - the bitch fell off.
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.
is wooing developers with lots of good tools and documentation.
Best Slashdot Co
some of what i believe is behind this Unix/Windows cultural divide is the elitist attitude. you have to be elite to use unix which just isn't true. as i've seen other people post and i agree with Apple put a pretty picture in front of unix and users aren't complaining why can't other people?
i personnally don't care what OS i'm using. at home i'm using my computer for video games and sound engineering, so i have 1 up2date windows box for games, and a mac for sound engineering. Why'd i get a mac? because while i'm in the middle of recording a band session i can't turn to the band and say "sorry guys computer crashed i lost the last 3 hours of your work" if windows was stable enough i would be using that. At work is another story though. i write stupid docs and java code so they put me in front of a windows machine. i personnally don't care. although i worry less about my mac then my windows machine.
My family recently decided to get DSL first thing i did was lock that computer down. i almost went so far as to remove IE with some ie removal tool (XPlite for example) but then i realize this would cause more calls to me then it would solve.
i also find that people want a brand name. i was asked to "buy" my own machine for work and i went to one of the lesser known computer builders and the price difference was several hundred dollars compared to what they wanted me to buy from Dell. Take a guess what's on my desk.
A lot of windows users don't care. if you gave them a mac as their first computer they wouldn't switch because they wouldn't know. the example i use alot is "how many people continue to buy automatic tranny cars over stick shift?" neither one is better or worse just a different interface but sticks are slowly getting phased out.
a lot of people (myself included) need to stop saying "windows is for morons" or "windows is less secure use unix" and start to change our "marketing focus" to something more like "building a more structured and secure tomorrow" like it or not "Where do you want to go today" sold computers, it sold windows and increased his market share. unix needs a "where do you want to go today" why? because no normal computer gives a crap about where the source came from.
BTW side story i was on a project where the dev team used exclusively solaris boxes. i had to write a code review document. with no MS office on my computer i wrote it in the other thing available StarOffice. i got hounded for several months by a stupid Q&A team because they couldn't find evidence that this "StarOffice Product" even existed. like just goto google and type "Staroffice" in the freaking search box.
Again just to reiterate my point. people don't care about which OS they run. they want their computer to be like their cars. "if i got someplace else and sit in a car i should be able to drive it". We need to change the marketing strategy of UNIX.
mod me whatever you like but some of you will think i'm flaming which i'm not. some of you will agree with me. i've said all i wanted to say. thank you for reading
are the Mac zealots. They make the most rabid Linux zealot look positively mellow. If you say one bad word about the Mac, regardless of how true it is, they mailbomb you. Which is why you don't see much coverage of Mac in the mainstream computer press. It's too much hassle. Not the Mac, the zealots.
Best Slashdot Co
Seems like things heading in the right direction in creating a more secure OS, and making it more business oriented.
Lets hope they actually put there money where there mouth is. And not just say this to get some possitive news coverage
"It is not because no one sees the truth that it becomes a mistake" (Mahatma Gandhi)
Both solutions are still too platform specific for my taste.
I would complete it as an MVC product, hiring:
- a competant DB designer to design a decent database
- contract a DBA in enhance performance of said database
- hire a competant programmer in the art of developing good business, and tast oriented objects.
- a decent web designer/graphic designer to create the front end.
If designed well, you will have a maintainable system, that can be accessed with a web browser, and good potential for easy code maintenance.
Have a nice day!
...most Windows people I deal with are ... not willing to learn. God knows I've meant plenty of UNIX bigots ...
:-)
Looks like a Freudian slip to me
before ADSL it was a pain in the arse and using textual interfaces was fast and convenient.
I still find I can work a lot faster with textual interface than I can with GUI interface, eventhough I have 2Mbit ADSL at home. A GUI still doesn't respond as fast as I'd like it to. It still feels a bit sluggish. Also, via a text interface I can access more programs faster than via a GUI.
However, many people prefer GUI's because they have to think less about what they're doing and the availibity of bandwidth certainly improved things for them.
It's a cultural difference in roughly the same sense that the difference between turning on a CD player and playing a musical instrument is a "cultural difference".
Windows programming is overwhelmingly done by people with little experience and skill for people with little experience and skill. Windows programming environments are the programming equivalent of prerecorded music, painting by numbers, or ready-to-serve meals.
And Windows programmers will never advance beyond that stage if they keep doing just Windows programmings: you no more learn programming by using Visual C++ than you learn to play the piano by playing all of Horowitz's collected works on your CD player over and over again.
UNIX is obscure, unforgiving, and takes a long time to master. Just like a musical instrument. You won't hear musicians complain either that a violin or a piano has a user interface that is "too complex"--compared to what their craft is really about, the initial difficulties of the instrument are minor.
But even the appreciation of art takes experience, so it is perhaps not surprising that Spolsky even fails to understand the difference.
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.
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.
I put it forth that this "review-like article" is competely "domestic bovine excrement"-like.
Here are some of the best/worst bits:
Huh? What exactly is return code 0, then? Or syslog entries? And how do you distinguish between cases where the program output was correct and cases where the output was incorrect but the program was unable to decide this?
By contrast, in the Windows culture, you're programming for Aunt Madge
Funny that. What does Aunt Madge do with all the hundreds of complicated scientific/industrial/financial/simulation software packages that exist for Windows (as well as Unix)?
Here again, we see that the Unix culture values creating code that is useful to other programmers, something which is rarely a goal in Windows programming.
Huh? What does reusability and well-documented interfaces between modules have to do with the platform? Did ESR really write this crap or is the "reviewer" making it up as he goes along?
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.
I wonder which specific Windows programmer this sentence refers to. Hopefully one that's been fired for incompetence by now.
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.
And commercial Unixes are created with what goal again?
Aunt Marge can't really use Unix
Can't even keep the lame metaphors consistent.
That's OK; he's not a Windows programmer; we'll forgive that.
Huh? If somebody writes a book pretending to be an expert on something they're clearly not, I'd call that bornerline fraudulent and at least take any viewpoints offered with a huge mountain of salt.
If the actual book is even half as bad as the review makes it out to be, maybe Eric S. Raymond should go back to writing the Nethack Guidebook. It probably has more insight on Windows software development.
We're in our 14th year of our product. Maintenance and enhancements are the norm. No product is bug-free, but for the complexity of our Windows program, it's relatively easy for one developer to take another developer's code and work with it. We have about 20 developers in our company.
Most of the article is dead-on when it comes to the different cultures of development. However, the following
I've encountered too many Unix programmers who sneer at Windows programming, thinking that Windows is heathen and stupid.
[...]
It's rather rare to find such bigotry among Windows programmers, who are, on the whole, solution-oriented and non-ideological.
does not quite relect my personal experience, and I am mostly working in the Windows world (at the moment). The bigotry can be found everywhere, and I've given up on trying to explain the advantages of one culture to people who are claiming the superiority of the other one.
Let me emphasize what an interesting read the Raymond book is. Very much recommended. Certain issues are too often considered 'common knowledge', although they're not, and the book explains the Unix culture well to those who are interested in technology, regardless of ideology. After all, a lot of things can be used on Windows, too, although they may not be the usual way to do it.
If people want a lowest-common denominator interface, all sorts of appliances are possible that aren't "computers." I built a Linux box for my mom that lets her check her email, surf the web, type stuff up and print it... it auto logs in to a GNOME desktop, pretty much all the apps are GTK2 based, she can even run apt-get to automatically upgrade her apps.
Unix is just more flexible. Better. Smarter. Anybody who wants to do more than the most basic stuff in Windows has to make an effort to learn something. If the Redmond-software-hegemony wern't in place, I don't see the difficulty in learning Unix rather than Windows. The rewards are certainly far greater.
To understand recursion, you must first understand recursion.
For anyone who has ever wondered why more people don't use linux, staroffice, etc, I recommend the classic on technology marketing "Crossing the Chasm" by Geoffrey Moore. It describes the "chasm" which technology companies face in crossing from the early adopter market to the pragmatic, mainstream market.
The consumers on the left side of the chasm - what Moore terms the innovators and early adopters - enjoy using new technology, enjoy putting things together, have the vision to see the potential of new technology, and are willing to put up with inconveniences in the iterim.
The mainstream market is pragmatic. It prefers to bet on clear market leaders (so as to minimise risk and benefit from the supporting ecosystem which inevitably grow around the market leader), is willing to wait and see, and needs complete, fully functional, headache-free solutions for their specific needs. Consumers in the mainstream market rely on references within the mainstream market to drive their buying decisions.
A technology company which wants to transition from the early adopter market to the mainstream market therefore has to bridge this "chasm", and in the process, change the focus of its marketing efforts and adjust its product accordingly. As far as the desktop market is concerned, Unix (with the exception of Mac OS X) is a product which clearly has not bridged the chasm.
Windows has culture? Since when?
The Windows APIs in that area are horrible. There are functions for enumerating installed printers, adding printers, and all the other things you might expect. However, none of the APIs are documented well enough to be usable. I found several instances in which the documentation was actually *wrong*. There were significant differences between the APIs for Win95 and win98 and then ever bigger differences for NT.
All in all it was a nightmare and I would have killed for the source code for the add printer wizard. Even better if we could have just called the add printer wizard with bunch of command line options that answered all the questions that would have otherwise been asked of the user.
MS products and APIs have some of the WORST documentation I have ever seen. They make a point of pointing out the obvious stuff and not even telling you the important stuff. I have been spending time using the MS VSS command lines to write scripts for automation of builds and such. Well the VSS docs are VERY incomplete. They fail to meantion that output may be multi-line for commands that SHOULD come back with a single line. There is also very little information on some of the important behaviours of some of the VSS commands and the errors that come up.
Some of the best docs I have seen are from Open Source projects. Yes sometimes the docs are incomplete, but at least you have the fall back of being able to LOOK AT THE CODE when it's necessary.
Causing Chaos Everywhere,
Nik J.
The strange world of a loner, in a populous city, drowning in society
He's obviously never developed anything under *nix before.
How can you say that UNIX development is like pig wrestling?
What kind of development are you talking about? Kernel hacking? GUI development? Or are you referring to the programming tools?
I hate programming under Windows. It's the worst thing I've ever done, and believe me, I've developed on many platforms, ranging from the Amiga to the Mac, Unix and Windows. The programming laugages (C/C++) are a-ok, but the fact that I have to do almost everything with the mouse drives me mad.
Or, hey, MAYBE it's just a matter of taste? I'm a console-iac, you like GUI's.
Don't say that stuff you dislike suck. Dislike but don't give the wrong impression to newbies. I never say that Windows (or windows programming) sucks, I simply say that I hate it because this and that.
This story will be duped at some distant point in the future.
The latest Slashdot meme.
Gotta agree with you here. We don't need to go to Japan to get culture-shocked.
:)
I was in Wales for 6 months. Loved every minute of it. When it was time to go home, I couldn't wait to set foot on the nice wide straight streets, eat cheap burgers and hot dogs, and talk to people who call soccer soccer.
Um, the beer was always better over there though.
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
It's not flamebait, but I don't think it's that true anymore. Several years ago, I would have agreed, but now all the MSDN pages and search engines seem like such a crappy mess that unless you know exactly the function you want, it's damn hard to find documentation for it. And MS' tendency to re-invent the wheel with every Windows release doesn't help people trying to use the APIs.
There is no sig, there is only Zuul.
I've been swashdotted -- Elmer Fudd
old debate. it really isn't a competition.
;=)
I think Linux needs more standardization of libs; not a rewrite and dozens of libs doing the same.
Starting a new thread: the Unified Driver Interface is an interesting topic
Wasn't that an Open-Source thingy sponsored by SCO??
> 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.
Therein lies a fundamental part of the problem itself -- Microsoft's APIs are so entirely overcomplicated and nonintuitive that you need all kinds of API documentation. When I'm creating a simple Windows GUI application, I don't want to memorize 32 different properties of a WNDCLASS or WNDCLASSEX, and I don't want to pile half of my application's GUI code into an event loop. I think the UNIX "everything is a file" methodology combined with a self-describing signal/slot mechanism in the GUI toolkits means I shouldn't even need an API reference because I can do everything I need to with only a limited subset of standard C/C++ functions. Third-party libraries are, with few exceptions, equally simple. You can figure out how to do things in SDL, for example, by looking at the headers and function prototypes because they're self-explanatory -- no figuring out needless and cryptic DirectX COM calls and the like. If you remember what the function is called then you can easily recall how to use it. I don't get that ease-of-development on Windows systems, for certain, unless I'm using third-party toolkits like wxWindows.
I do agree, however, that documentation is much more important than having full access to the source code for a particular API.
I think you missed Sposky's point completely, but...
I believe we need to have "end-user focused" programmers, and I think there are a few sneaking into our world (H Pennington, Miguel de Mono come to mind). They'd be folks who know the "unix way" but focus on the "final" solution: The end app that will be used without piping off to other apps, without having to support connections to 15 other things, whatever. Just what the user needs right then and there.
There's a dearth of those kinds of apps now, but they seem to be arriving more and more.
You know, I had a similar thought when reading this review. Mr. Spolski brings up many of the compare-and-contrast points of unix vs windows programming, and while (in my unix-centric view) most unix points stand on their own, the windows points are rather fluffed up with artificial and (in my unix-centric view) rather unconvincing hand waving. Most of his points seem to boil down to
In the end, Mr, Spolski's review falls into the same category that he would like to pigeon-hole Mr. Raymond's book -- an attempt to be balanced and fair defeated by the author's self-inflicted blinders.
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
Surely displaying nothing takes no time at all, and is therefore *infinitely* faster.
Hey we finally proved it, Unix is infinitely faster than Windows, yay!
Skiing? Check out The Independant Skiers Portal
Even though Microsoft documentation is excellent, I've find LOTS of situations where the behavior isn't clear, and I have to decompile the .NET libraries (using Reflector) to get it right.
For example: The documentation for CollectionBase.IList.Remove(object) doesn't say what happens if the value isn't in the collection: ignore or throw an exception (it throws an exception; that sucks).
However, there was this one point during this discussing at the dinner before his speech where me and several of the LUG members were talking with him about linux GUI's and the future of the Linux Desktop. Eric Raymond said something about the whole unix system of creating back ends first and then grafting GUI's on to those later.
My response: "But Eric, most usability experts recommend you design the interface first and then write the code".
His response: "then they're wrong."
My response: "But what if there's something that the backend folks didn't think of when they wrote there code that the GUI really needs? 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."
My response: "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?"
His response: "then we've got a problem."
It was at this moment I realized two things:
Ergonomica Auctorita Illico!
The cultural values approach produces some interesting insights.
The obvious stuff:
1) Coding for other programmers promotes code reuse. Code reuse promotes productivity.
2) Security is affected by code reuse. It propagates bugs resident in the reused code but avoids bugs that would be introduced should the user have to recode that functionality. The net gain is that, so long as the reused code is in a common library, fixing it once fixes multiple applications. Available source means that more (and fresh) eyes review the common code, improving the possibility of finding the bugs in the first place.
3) Writing for end users, when done well, produces applications with better usability. Naturally it tends to sell better.
4) Writing only for end users tends to produce inflexible applications. The user must use the program exactly as the author intended and no other way, unless the programmer takes the higher road. In the first-to-market commercial business environment, taking the higher road is as hard as pushing a rope.
5) Literate end users is not only a contradiction in terms, it is an unreasonable expectation. Programmers cannot expect end users to learn more than the minimum needed to operate the computer because (1) they see it as a tool to to accomplish their real goal, and (2) The inner workings of the hardware and software do not interest them. Is it reasonable to expect all drivers to understand the inner workings of an automobile, or kitchen users to understand the inner workings of their dishwashers?
6) If Unix is to succeed on the desktop, it must cater to end users.
My conclusions:
1) If we really want Unix to succeed on the desktop, it seems to me like we need cultural fusion. We must pay more attention to end users but without losing the values in the Unix community that produce modular, reusable, secure, reliable code.
2) This fusion alone is necessary but not sufficient, else Apple would have more market share than it does.
3) The cultural fusion discussed so far is in the technical world. But IT vendors' companies rest on three pillars: the technical pillar, the business pillar, and the merchandising/marketing pillar. Every company that hopes to put Unix on the desktop would be well-advised to rethink their business processes, standard contracts, and advertising so as to cater to home end users and to give business end users more visibility and consideration. First on my list of business processes to review would be the help desk metaphor. What a universally negative experience!
What say you, technical literati?
English -- gotta love it! / The engineers refuse to refuse the rocket until the refuse is removed from the launch pad.
Disclaimer: I am certainly not an ESR fan, but this post is factual, not flamebait. If it was flamebait, I'd mention another TLA person :-)
> ESR, a vocal libertarian
No. He's a "vocal OpenSource advocate".
In his words, talk of freedom is "ideological tub-thumping", and OpenSource is simply a superior method for software development.
(I wish he was a libertarian, but this doesn't make it true.)
Expert in software patents or patent law? Contribute to the ESP wiki!
I am now trying to learn Perl (for work) and most sources, again, teach it bottom-up [This is a $calar. This is an @rray.] I wish they would start with [This is how to get perl use a form to ask for a password, submit the form and check the userid/password in a database, return something, and generate the next page, depending on whatever]. I know I gotta understand the foundation but I also have to generate product. I wish I could find somewhere that the two ways of teaching merge so I can generate good stuff AND, eventually, (gasp! maybe by explaining in short phrases even I can get) understand the underpinnings. It's good to have a goal.
*cragen
Everyone who thinks having a pretty GUI is more important than having your data processed correctly deserves the quality he gets behind those green buttons on blue taskbars.
What if a non-experienced user needs to run your scripts? People are use to GUIs for performing tasks, not the command line.
Sig it.
Excellent article. Now will someone do the sequel, explaining to both sides the much greater rift between the UNIX culture and the (IBM) mainframe culture?
The world will be a better place when the UNIX partisans understand exactly why the "Those who do not understand UNIX are doomed to revinvent it, badly" quote makes IBM mainframe guys go ballistic. Compare mainframe security to UNIX security sometime for just a hint of what I'm going on about.
Actually, it's a hell of a lot easier to program for a library with well written docs than having to delve into the source code.
The combination of both, well-written API documentation and source code, makes your life even easier. Sure it's much more convinient to write the code when you have a nice API reference handy but when you actually have to make it work, up to date source code is a must.
All software has bugs -- and every now and then they bite you. When they do, I prefer to have the source available so I can narrow down the problem, fix it (or work around it), and continue working on what I am actually getting paid for instead of waiting for my support request to go through the vendor's support pipeline.
So, if I have to make a choice between clear API documentation and source code, I always prefer the latter.
And it's easier again if you have both.
Especially when you're chasing an elusive memory leak. No source code = debugging hell.
you're missing the point here i think. the relative complexity of programming on each platform is irrelevant to everyone in the entire world, except programmers. people *want* simplicity, and for good reason - the whole reason why ready-to-serve meals sell well is because of convenience, and that's the same reason windows sells. not because it's better or faster or nicer or whatever, it's simply more convenient, and that's what people want. give the customer what they want - ever heard of that?
and your analogy is misleading: people don't learn to play the violin because playing the violin is complex, they play it because it sounds nice. likewise people use windows not because it's powerful or complex but because it does what they want it to do conveniently. people use *nix because it does what they want it to do, conveniently - even if that is learning about programming or networks or just using the GIMP and OpenOffice.
The culture difference comes from why these products exist. Windows is a commercial product designed to attract paying customers, and is therefore (perceived as) useful to a mass market, and convenient. Unix was designed as a functional tool to get things done, so it appeals to functional types (ie engineers of various descriptions) and excels in getting things done. As long as those two groups of people don't overlap too much - and i can't see it happening anytime soon - these two products will be dissimilar and the subjects of these debates.
I use linux and solaris because it does what i want it to do: i can use it to productively manipulate databases, communicate over networks, learn more about programming etc. i dislike windows' instability, unresponsiveness, lack of security and proprietary nature, but i still use it on occasion when i want to do mass-market things, like play games. and i recognise that for it's market, windows is better than unix is for the same market. yes, better. likewise, unix is better for it's own market.
to use your example, no matter how much you tell me that cooking with fresh ingredients in a good oven will make my meal taste better, if i'm walking past a supermarket and need something i can eat in the next 3 minutes i'm going to buy a sandwich. which one is better depends entirely on the user and their circumstances. and i for one am not sold on bringing linux to the masses as a replacement for windows; if the cooking starts tasting bland and the available ingredients disappear to make it more like a sandwich, and the sandwich suddenly needs cooking in an oven so that you can customise it and make sure it's safe to eat... maybe i'll forget the cooking AND the sandwich and just find an apple tree somewhere. if that pisses off the chefs and the shop-keepers, well tough
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
And what's stopping you doing the same in Windows?
I would submit that this is actually a trust issue - you place higher trust on things you know. Those who spend more time in *nix trust that more; those who spend more time in Windows trust that more. It is human nature to distrust the unknown, and to be comfortable with the familiar. (Or resigned to it in the case of the BSoD.)
In the marketing stakes, Microsoft has won (for the time being), bringing with it familiarity to all the users of Windows. To get people to change requires good enough reasons to overturn the status quo and its inertia. (*nix is more secure? Yes, maybe, but Windows patches itself every month to fix things. Windows is susceptible to more viral agents? Yes, maybe, but my antivirus software updates itself. *nix is cheaper? Yes, maybe, but I already know Windows so don't mind paying a little more to get going faster. The latest game I want is only available for Windows? Yes, probably true.)
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.
And sadly, some of those are just an indication that the widget, bar or icon is moving, without any reference to or knowledge of what state Windows or the application are actually in.
[Note: not trolling - just pointing out some perceptions. Mod at will.]
I can understand that, for me the feeling out of place as a European in the USA was walking out of the airport terminal , taking a taxi donwtown, and seeing a bunch of african americans drive by in a big brightly painted pickup with some of the loudest rap music I ever heard blasting out of a couple of 1.5m high speakers in the back. You can walk out of any airport terminal in Europe but you will never see anything that colorful .... except maybe in the Balkans but they use tanks instead of pickups.
Only to idiots, are orders laws.
-- Henning von Tresckow
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
Don't really know if that was a troll or not, but eh..Why not.
In my past two companies, I have work on several R&D projects that exclusively use Windows. When it comes down to money, speed, and effeciency, we are indifferent to what Microsoft says for us to upgrade etc. We use Windows to get the job done, period. I am actually the only Open Source advocate, but I only advocate when I can prove that an Open Source project is faster/more effecient than our current proprietary one. I have worked with several other teams within other companies that have the same ideology.
Sig it.
It's rather rare to find such bigotry among Windows programmers, who are, on the whole, olution-oriented and non-ideological.
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.
People can be solution-oriented and non-ideological without being willing to learn an entirely new set of platforms and skills. Often being solution oriented implies you will be building off of existing knowledge and not starting from scratch in an entirely alien platform. I believe the difference that Sposky is trying to hit upon is that Windows programmers don't hate or belittle Unix programmers whilst the Unix culture tends to be ripe with bigotry. That said, die emacs die. Vi forever. Ah, screw em both, I want an IDE.
mod parent up. This is the fundamental core of the cultural divide. It is not even necessarily about stdin and stdout (though usually it is) on Unix, but it is definitely about getting data in, doing something interesting/useful with the data, and sending it on, whether that be to a socket, or stdout, or to a file (of course, the "Everything's a file" paradigm makes this easy from a programmer's standpoint, because all of these are essentially the same thing). And you're right, the GUI seems to be something that has been tacked on afterwards, in the *nix world.
Did you mount a military-grade, variable-focus MASER on an unlicensed artificial intelligence?
Bah!
You can do Windows programming using vi or emacs if you want to, and compile at the command line.
If you'd rather do that than use VS then you're insane. Maybe you could wear a hair shirt too, just to enhance the effect.
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?
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") stems from a culture that feels itself under siege, unable to break out of the server closet and hobbyist market and onto the mainstream desktop.
Do Unix/Linux types really feel under siege? Having experienced both "cultures" first hand, I'd say not. I think that most people in the open source community are not so zealous or "sectarian", but are also looking for practical solutions. Myself, I am drawn to open source because it is a better way to better software. The development model is going to prevail over proprietary software, especially for those of us who want to program for the server side. I suppose for those who really are zealots or sectarians, Joel's comment above is bulletin board material, or you are thinking, "I resemble that remark". I don't think the viewpoints of strong open source advocates is something to be dismissed out of hand. I also don't think it's a sin to make a buck or two from one's talents.
Always look on the briight side of life! (whistle, whistle)
that Windows programmers hurt their arms and wrists after clawing their way through one too many pull-down menus while Unix programmers hurt their pinky fingers after a heavy emacs session in the world of Control Meta.
As a result, Windows programmers have spastic arms from all this GUI action, looking like zombies from Night of the Living Dead, while UNIX programmers have hands curled up like Igor from Frankenstein's Lab.
"Provided by the management for your protection."
No, you still have to display the newline. Hope you're not a programmer...
We need to recognise why windows programmers write for end-users and unix programmers write for developers, and it is simple: Only developers are using unix.
Unix people, after 20 years, are still adding utility to their OS. Windows people get a complete system out of the box. Windows people never had to code up their own OS, it was provided by Microsoft. If it wasn't provided by microsoft though, it was provided as an end-product by someone else (Trumpet Winsock). Adding to non-existent OS self-improvement time was the fact that there were only ever 2 windows "systems" for Windows: Program manager and later, Explorer. No one had to reinvent the wheel for KDE, GNOME, and whatever DE the user might be running. Therefore, the windows coding efforts were more focused.
I've said it time and time again - we need to drop GNOME or KDE (preferably keeping KDE, IMHO) and just run with that. 2x the developers can do 4x as much work if they aren't duplicating each others work.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Actually, no. You'd have to wait at least the time to receive *one* character, because that would be the only way to know if you received it or not, so 20 times faster is correct here...
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!
Actually, Microsoft SQL server is ripped off from the same obscure antique database server that a couple of guys in Sweden disliked sufficiently that they felt motivated to rewrite it from scratch; and, just to make sure that the original company would never see a single crown in royalties for such a lousy product, they made it free {because cheap is good when you are buying software} and open-source {because cheap is good when you're employing people to fix bugs for you}. The rest, as they say, is history {and so will Microsoft be by 2020}.
..... nobody's ever gonna notice the difference except the poor sod who has to keep fixing it when it packs up and is now out of a job. The only worry is that your boss might find out that it wasn't Microsoft SQL server at all, and try to sack you. However, if they actually install Microsoft SQL Server, it will crash horribly before you can say "Industrial Tribunal", and you should get your old job back. Though, frankly, I'd rather be on the dole than work for a d.h. like that.
So when your boss tells you to install Microsoft SQL Server, install this instead. It's faster, it's more stable, it supports roughly the same deviations from ANSI
Write a procedure for user, explain that he must do it the the same way every time, and move on to the next significant problem.
I stole this
Accepting (at least for argument sake) that sphealey is dead on, that is NOTNOT the same as saying 2/3rds of users (or "useage") is for dp.
Just a WAG, but doesn't it seem likely - given the widespread availability and use of 'puter's - that 2/3rds of users are writing a memo/report/letter to their bosses or kin, or browsing the web, or trying to balance their checkbook? If so, we may want to give weight to two Sposky observations:- Users do just-in-time manual reading, on a strictly need-to-know basis.
... indeed the hallmark of a good Windows help file is that any single topic can be read by itself by an average reader without assuming knowledge of any other help topic.
Seems to me, those are tantamount to guidelines for converting M$ victims![this sig has been trunca
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.
You really are a Lunix zealot. You didn't format your text one bit. It looks like a man page.
It's like the enter key had been removed from your keyboard and you find it too hard to use CTRL+M to replace it.
When the book cover looks this bad I don't even bother reading the book.
"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"
This is so naive as to be laughable. The thing that soooo many windows programmers do not understand is that the "text" based paradigm of the UNIX world is exactly that a paradigm and the metaphysics of that paradigm are so deeply ingrained in the approach to programming that the real benefits are often underestimated. If I write a command line program, I need only understand 4 interfaces stdin, stdout, stderr and argv and only half of them are readable! Within that, we have lines and whitespace as standard concepts, again trivial to grok.
As a programmer it is up to me to present my output in the format understood by the stdin/argv scanner of the program I want to call and the process by which I can discover that format is of varying difficulty based on the complexity and quality of the program I wish to call, but generally pretty simple process nonetheless.
The next generation of interaction between programs (or lets call them objects) requires a huge leap in complexity. It is this next generation paradigm that many windows programmers would claim to use. But for it to work, the self discovery of those input and output formats and some standard nomenclature to allow them to communicate with each other to make the discovery is required. For example, my spreadsheet program may have many different inputs, a clipboard, a file interface, a dynamic data interface etc etc and its outputs might be equally complex, but the critical thing is that it must be able to tell my data capture program that it is a spreadsheet stlye application and that phrase "spreadsheet" style application must make as much sense as a "stdin/stdout" style application makes today. Whilst I agree with this posters point about creating an object, and then using a GUI to call it, the point is somewhat moot since the discovery process means that in the Object focused world there is no capacity for this communication to take place and so the programmer is left with the task of doing all the mapping between objects since a "data capturey" type object doesn't really grok the metaphysics of how to present to a "spreadsheety" type application. Now, don't misunderstand, I am not suggesting that UNIX can do this any better, but the paradigm under which a unix programmer operates understands something about the metaphysics of how applications talk to each other and so the UNIX programmer will think in a reuse/talking to other programs kinda way to a level, even if it is at, overall, a lower level of functional richness, that a windows programmer cannot really hope to emulate.
$0.02
"The first thing to do when you find yourself in a hole is stop digging."
>No, you still have to display the newline.
Damn, I knew someone would spot that. But do you have to wait for that to be transmitted, or does the Terminal produce that on its own? I suppose either way, you also need to wait for the prompt to return, which *will* be transmitted. Damn damn, well it was funny while it lasted.
>Hope you're not a programmer...
Oh tough break, I am. But guess what, I may not use the same rigour in my slashdot posts as I do when I'm writing code.
Skiing? Check out The Independant Skiers Portal
Read the article (I know, it will be hard to force yourself to do so if you are a slashdot regular
I don't know if Spolsky didn't read this far, or if he's just a weak plagarist, or maybe this is the only part that made a big enough impression on him to merit rephrasing for his own column.
The only difference I see is POV, and substitute "mac" for "windows".
Arguments to the contrary cheerfully accepted.
sPh
Joel almost, but not quite touched on it when he mentioned source code availability as a core Unix value, and that is Peer Review.
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?
Alternatively, use the MSDN CD that comes with Visual Studio. Microsoft also provided the ISOs for the April '03 edition of MSDN for free, although I've since misplaced the link.
MSDN provides excellent documentation. Given that you clearly haven't found it, I would say you're not in a position to comment.
Yesss!!!!
Microsoft documentation is not only bad, it is perversely bad!
You can take any, no matter how conplicated, command line and easily make it into a cute little icon, but it is far harder to take a cute little icon and make it into a command line (at least, with Microsoft documentation!!!). Is Microsoft actually trying to hide "features"?
However, even if the user started typing again straight away, they probably wouldn't beat the prompt coming back if it took less than 0.1 seconds, whereas they would if it took 2 seconds.
Now we have the difference between making the user wait 'some' extra time over and above the natural typing pause time, and making the user wait for 'no' extra time.
So I assert that 'infinitely faster' still holds!
Skiing? Check out The Independant Skiers Portal
Yes, you guessed correctly, it was a clustering environment.
It was a _huge_ project, trying to deliver a web-based front-end to an existing system. The ticket was around 150m Euro.
The architecture basically fell apart about 75% through the project. I guess around the time they stopped making use cases and actually tried to scale the prototypes up to work on their clusters. The support calls to Microsoft went very high and it was an engineer from the bank who finally discovered the real problem, apparently. 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.
The project was cancelled and I believe it was not redesigned - the economic crisis meant that the company had to cut back.
Needless to say this kind of experience made the company somewhat cautious about using MS products for anything serious after that. I don't know whether they tried an alternative, most of the business runs very successfully on the classic mainframe model (COBOL, CICS, MVS, etc.)
Ceci n'est pas une signature
You slipped in the proviso "As far as the desktop market is concerned", but if you forgive me mixing my metaphors the Innovators Dilemma tells us that you can cross the chasm in a series of steps.
Linux has long held the innovators sector, it has just about captured the embedded market, it stands eyeball-to-eyeball with Microsoft in the server space. As it raises its profile on emedded devices home users will become more comfortable with the idea of a Linux desktop. Similarly as corporates become comfortable with Linux in their server racks, more and more of them will consider the possibility of deploying Linux desktops, perhaps starting with places like call-centres where they don't need a fully-fledged Windows rollout.
The desktop will be the very last sector that Linux captures, this is Microsoft's front-lawn, and only Redmond tanks are permitted to park there, for now.
However, Linux will eventually win the desktop not because it is technically superior (the best technology rarely wins the mass market) but because it has economics on its side. Open-source software will eventually become the dominant software development method simply because it is more economically efficient for software companies to maintain the software infrastructure collectively. Those companies that recognise this will squeeze out the less efficient ones that decide to maintain all their secret code themselves.
-- Nick "Hallo this is Beel Gates, und I pronounce weendows as
Most of the time, I think he is full of shit (I don't read him very often, though) but for once I think he is right on.
What Joel miss here here is that Apple did not reject Unix; they BUILT upon it ! OS X is the most glaring example of the success of the "provide machanism, not policy" philosophy. Darwin provide the mechanism, Apple provide the policy, everybody is happy. If Darwin would have enforced policy, Apple may not have been able to rename /bin Application, or /lib "Libraries". Imagine if, somehow, Darwin would have forced the use of X Window and Apple could not have used Quartz ...
You know what ? What he exlained in this paper is exactly the reason why I am a Linux users. I am not Aunt Marge. Unix tools and culture had been built with people like me in mind. I am not your typical 99.999% user; why should I use tools built for the lowest common denominator ? Call me an elitist if you want; that's what I am, and Unix make it good to be one.
:wq
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.
>> 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.
You hit the hammer on the very top of the nail's head. It's more or less like that attitude about American cars. Slowly, Japanese cars started to gain ground based on money the consumer saved by spending less on maintenance. But then, they came up with tax-exempting laws that benefit SUV makers.
Probably they don't believe in harsh punishments. Instead, I'd suggest you create some mechanism to fine people who are unprofessional and channel the funds coming from fines to people that don't get any security problems. If there are any legal problems about dealing with peoples' salaries, you can alternatively impose those fines on their departments, thereby reducing money for investments and/or expenditures.
Windows people like to offer inferior services and boast they're cheaper. Let's see how they fare if they have to pay for the consequences of Windows use. Let's see how they deal with people using other OSes and making money out of their tools' quality.
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
Considering the guy did the original implentation of VBA for Excel, I'd say yes he can code. You're missing his point. He implicitly assumes you'll use a break things up between document/view classes to seperate out functionality.
What he's talking about here is providing an interface for other programmers. While that's a good thing, it's not the first thing that is on a windows programmers mind.
sPh
What Spolsky says about the culture differences is right on the money. First some background.
I spent years as a Unix developer and admin. I've written kernel patches, tinkered in the arcana of NFS, written more Bourne (csh, bash) shell scripts than I care to remember, written a few X apps, learned Perl well enough to write books on it, presented at USENIX, wrote medical and finiancial applications using not much more than libc, programmed Unixes from AT&T SysVR3 to Linux, installed the GNU tools from mag tape in 1988, learned gawk from a wire-bound photocopied manual distributed with that tape, have set up UUCP by hand, and fixed more than my fair share of filesystems with fsdb-like tools. My Unix Wizard hat is dusty, but was honestly earned.
My later career has taken me to Windows shops. I'm currently earning a living writing C and C# for an almost completely DOS and Windows-based company. I've spent a couple of years spelunking MSDN documentation, Google groups, and 3rd party library API's. To that end, I've created a few applications for database interrogation and updating by end-users, web-based applcations, and plenty of GUI-based throwaway applications. My Windows hat is still just a propeller beanie, but I'm working on that.
So having a foot planted firmly in both worlds, I gotta tell ya -- he's right.
When I first approached Windows programming I wrote a lot of things that were used by myself, and that was it. Nobody else wanted to use the software I produced; admins and typical "end-users" alike both ignored them. Honestly, these programs did good things: they were relatively bug free, they scratched an itch that end-users had, sometimes they cured what caused the itch, and were all very Unix-like. Unix like? STDIO based textual interfaces, very easy to plug into other programs, command-line driven, and heavily documented.
The phrase that makes Spolsky so right is the importance of the end users's experience. They're completely different.
With Unix I'm fundamentally thinking of "how am I going to write a program to manipulate data X with data Y?", in Windows I'm thinking of "how would a user expect to cause data X to be manipulated with data Y?". True, in Windows I'm faced with two problems: 1. user interface (to meet their expectations of experience) and 2. actually solving the problem at hand. Over the years though I've found that problem #2 is always easy -- it's just bits, it's problem #1 that makes a successful product or a useful tool.
Once I got used to starting with the user interface (while behind the scenes designing the functionality of the task), my Windows applications really took off. People wanted to play with them, touch them, use them. Sometimes they suffered from the "wrong tool for the job" problem (as many monolithic apps do) but that's okay: they were easy to use, didn't require any explanation, and people just learned to make the tool do what they wanted.
One of the design creeds of Windows seems to be that people are flexible. They don't want to read, learn, or memorize anything but they're willing to take the few tools at hand and bend it every-which-way to get it to do what they want. Unix takes the toolkit approach (design a specific tool for a specific job, with generalized I/O) which makes people read, learn, and memorize, but often provides them with exactly the right tool for the job.
It's not so much the culture of the programmers as it is the culture of the consumers.
Get off my lawn.
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 slashes go "the wrong way" (hmm, any explicit biases there?) because the switch syntax was copied from CPM, the dominant microcomputer OS at the time. CPM in turn copied it from DEC's PDP operating systems (like RSX-11, TSX-11, RT-11, etc. etc. etc - the VAX/VMS system also inherited this syntax, incidentally, along with DCL (Digital Command Language) which is the direct descendant of CCL (Concise Command Language) and RSX Indirect).
A stupider paradigm is Unix's re-use of the directory separator as the name of the root directory; there are some efficiencies of notation and processing that this provides but it's really profoundly counter-intuitive. It's actually worse than the exposed numeric MFD of VMS (which is also stupid, but at least it forces one to understand the mechanics of the filesystem).
Liking to program with Windows is like liking the Yankees, or rooting for the Lakers. People love to jump on the MS bandwagon because they are more prevalent in the media. I teach an IT high school class, and I feel torn because the curriculum says to teach VB and VC++. However, I feel that teaching Python and Java results in a better understanding of how things work. But when I have an advisory committee telling me that everyone uses Windows, and that Windows is the way to go, I get frustrated. I feel that they are just buying into the big market MS hype. Back to the sports analogy, I feel like I'm the manager of a small-market team, full of scrappy, hard working UNIX haxors. But when these students get to the big leagues, I hope they find UNIX jobs, not the MS jobs. Actually, I just hope they find jobs.
The problem with the registry isn't that it is undocumented. The problem is that there is no inline documentation. The /etc directory may seem like a bit of a mess, but it is generally a trivial exercise to find the configuration files for the daemon you want to configure (/etc/[daemon-name] being a good place to start). Once you have found those configuration files chances are also good that there will be enough inline documentation, in the form of comments, that you won't actually need to read the man page. As far as I am concerned that is the biggest advantage of plain text configuration files. I can actually read the darn things.
Spolsky -- In my experience, Spolsky sometimes overvalues his knowledge. He tries to be a leader, rather than writing when he is especially knowledgeable about something.
Mis-management of programmers -- The problem is not with different philosophies of how to do the job. The problem is that Microsoft mis-manages their programmers. Microsoft allows each programmer to do his own thing. That's why some dialog boxes in Windows accept Control-A to Select All, and others don't. That's why some Microsoft programs can be closed by Control-W, and some can't.
Releasing products before they are finished -- Another problem with Microsoft mis-management is assigning programmers to a new task before they have finished the last one. Often Microsoft releases programs that only barely work, and have numerous shortcomings that a programmer would eliminate if given time to finish his work. Anyone remember the first version of Microsoft Access? Remember the 63,000 bugs supposedly in Windows 2000? Did we see those bugs? I count 18 critical updates just in Windows 2000 Service Pack 4, and some of those are actually multiple updates. I don't know if there were 63,000 shortcomings, but I do know that some of those are still in Windows XP. For example, Windows XP often re-organizes the desktop icons without asking. Windows XP changes sometimes changes its settings without asking, for example, when doing updates, or when re-installing the OS.
Insufficient planning, standards, and cooperation. -- At Microsoft, my understanding is that there is little way to assure cooperation between teams. Everything is hurry up and finish, and there is too little planning, or writing of standards. Anyone remember the Windows 3.1 method of accessing a serial port from Windows? It was an interface of amazingly poor quality. There are many examples of sloppy design; that's just one that occurred to me.
Sloppy documentation -- Microsoft's documentation has the same poor quality. Information about a particular version of Windows is often scattered, jumps from article to article, is often in error, incomplete, and often refers to earlier version of Windows, sometimes seemingly in error.
Un-fixable problems? -- Microsoft's sloppy management has, over a period of many years, led to a situation in which, apparently, some problems cannot be fixed. That's apparently why there have been more than 60 serious security vulnerabilities found in Internet Explorer in the last two years, and only one or two in Mozilla. Apparently the IE code is a huge mess. Who was using those security vulnerabilities before they were made public? Who uses those security vulnerabilities after they are made public? There's no way to know, but the subject is extremely serious. Certainly if Microsoft were able to fix the security problems in IE, it would do so; the publicity about Microsoft security vulnerabilities is extremely negative and beginning to be known by the non-technical managers of Microsoft's customers.
What is the fundamental problem? -- Apparently, the fundamental problem is Microsoft's "Money now is everything" culture. Microsoft makes money because they had a monopoly, not because the company is managed well.
Harry Callahan's excellent comment -- This comment, to the duplicate Slashdot story, fits my experience better than Spolsky's analysis. Because the other, duplicate, story may be eliminated, or not read, I asked the writer to post his comment again in this, the original story, but I don't know if he will do so. So here is a link and a copy of the comment: The essential difference... by HarryCallahan
[Beginning of Harry Callahan's comment.]
Is not about th
"The end app that will be used without piping off to other apps, without having to support connections to 15 other things, whatever. Just what the user needs right then and there."
I'm sorry, but this is not a feature, it's a flaw. What user X "needs right then and there" is probably not what user Y "needs right then and there". If you design your API's and software to meet X's needs, and ignore Y's, or more appropriately, force user Y to accept that he should be like user X, how is this "end-user focused" in Y's eyes? It's ok to say for X, here's your app, but to then tell Y to shut-up and take it is unacceptable.
Fundamentally the UNIX models of "layers" and "pipes & filters" are far more powerful. At the end, you can provide a GUI for X, a GUI for Y, you can batch process all of the data, who cares. Fundamentally, your GUI is a thin wrapper of existing, well tested functionality, not a reinvent the wheel, "guess what this does" exercise in futility.
Library source code can be extremely useful for debugging; you can step through the library to see what exactly causes your library calls to fail, to see if your problems are caused by a bug within the library, and to more easily get a feel for how the library works in general.
There are also times when you may want to use the APIs in ways never foreseen by even the best documentation. (For example, ever try writing a Linux emulator for Windows?) Library source code can be helpful here too.
What a load of inflamatory bullshit.
All windows applications are then, by your definition, very easy to write, otherwise all these idiot Windows programmers out there wouldn't be able to create them.
Photoshop would require a genuis to write on *nix but any fool could knock it up on Windows.
You clown!
X is a protocol, you are referring to the programs
written that use X, ie. Gnome/KDE.
try running fluxbox for a window manager and watch
your machine r0x!
I have plenty of common sense, I just choose to ignore it. -- Calvin
You most certainly do not. The shell moves you to the next line at the end of your command, and the prompt can appear there.
That was a very insightful post.
Sorry I don't have any mod points!
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
That's something I realised very recently while I was thinking about how much faster I am using vi than notepad, reason being that the commands are so terse/concise because they were designed in the days of ~2400 baud. While we no longer need to conserve bandwidth, conserving keypresses makes vi faster for me than any other text editor. Adding fancy features (colour highlighting of source code, for example) makes it even better which is where vim wins out.
Yeah. You bring it! Real coders use wizards to generate their buffer overruns!
Just like they should have a password for their car, their boat, their bicycle, their television, their mixer, their can opener, their ...
> No, he's a vocal libertarian
;-p)
oh, ok.
When he referred to freedom fighters as "ideological tub-thump[ers]", I thought he was implying that he wasn't one.
Or maybe people are only tub-thumpers when they are fighting for software freedom, but not when they fighting for free speech or the right to own guns.
(now that's flamebait!
Expert in software patents or patent law? Contribute to the ESP wiki!
The open source community values people with skill and talent at programming. Unfortunately, the best hackers do not necessarily have the best vision or foresight (although they may well do). ESR dismissing useability experts as "being wrong" shows that you need more than gut instinct to be a good leader.
Perhaps the open source movement should take some advice from the commercial sector and hire managers who are good at managing, but not necessarily the best hackers. Planning, foresight and vision are more important qualities than having hacked together popular open source programs.
My theory about this is that 1) many VB programmers don't bother with error handling, 2) those that are required to have error handling just catch all exceptions, peel off the error message, put it into a Message Box, close the application and check off the 'add error handling' task. I don't mean to attack the VB programmers (as I am one one from time to time), but they are usually not given time to do much more than that by clients that don't want to pay for best practices.
Think global, act loco
Ever heard of a little technology called XML? Quite popular on UNIX and Windows apparently.
Hang on a sec. You are making my point for me. I am saying: Now that all the layers, pipes and filters are built, people are building GUI X, and GUI Y.
:)) need people focused on the end-user to create GUI X. GUI X does not ever need to continue the long chain of layers, pipes and filters. It just has to pull all the good shit together, and make it exceedingly easy to use.
We (the unix community, I include myself even though I suck
"Windows programmers", to use Spolsky's term, are generally better at the "end-of-the-line" app. It would seem to me that it'd be smart to get more people trained to take existing unix "bits" and make end-user apps out of them...
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
... which will be finding a new job after you were fired and re-replaced by those 5 VB programmers.
Just kidding. However, I think your response illustrates the Unix's world traditional disdain for end user interfaces. In some cases telling the user to "Just type 'foo'" is OK, but Unix folks have trouble distingishing that from "Just type 'foo -xp15 > find -q -t `exec --nn {}`' RTFM!" or "What's wrong with you? Just learn emacs".
Since everyone who uses a computer does so to control it's behavior (in some fashion) you could make the argument that everyone is a programmer - even Aunt Madge when she's browsing the web. She's instructing the computer to do something specific that she wants. And occasionaly it doesn't do what she expected. She has a bug in her program. The only difference is that here programming is done with a mouse and interpreted by a browser. Where as Linus' programs are done with an editor and interpreted first by a compiler and then by the CPU.
I think that if you consider that everyone who uses a computer is, to some extent, a programmer. The difference between the windows and unix culture isn't that one appeals to programmers and the other to users. It's that unix assumes that if there's a problem the user is going to figure it out and gives him/her tools to figure it out, but doesn't make assumptions about the users intelligence and lets the user figure it out on his/her own. Where as windows has to make the tacit assumption that users can't figure it out on their own and has to hand hold them through every step of the process.
In other words, unix assumes it's users are intelligent, and windows assumes it's users are dumb.
Now don't get me wrong. I'm not saying this is bad. I'm just saying that's the way it is. And if you're intelligent, it's incredibly frustrating to use windows because you don't want a computer operating system that can't think for itself to assume you're dumb. And vice versa, if you're a user who doesn't care that much to learn about how computers work best, you want your hand held.
The problem of course is this: windows servers. A server should not be managed by someone who's dumb or who doesn't care that much about how computers work. A server should be rock solid and should be configured correctly and should work. Server admins should be hired because they know what they're doing, and they should get it to work. Microsoft tries to sell the idea that any monkey can manage their server. And what do they end up with? Monkeys managing servers who don't care about installing patches. Deployed servers with huge numbers of vulnerabilities because the admin didn't patch them.
If the culture of windows is supporrts non-computer saavy users and the culture of unix supports computer saavy users, then lets all agree that windows should NOT be in the data center. If you put windows in the data center, then you're already admitting defeat.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Go to any school of engineering any anounce that you want to design for the client but ignore best practices. The next day, anounce that you have learned from your mistake and that you want to adopt best practices but you don't care if it meets the needs of a paying client. You would quickly learn that you are still mistaken. Engineers must do both. Joel, great software requires that you address users and software engineering practices... these are two sides of a coin, not gulf between communities. Perhaps this is why great software takes ten years ;-)
Think global, act loco
I find myself saving more often
You should find yourself saving often in any interactive program. As far as I know, most interactive applications, even on *n?x, hold the sole copy of the recent changes to your document in volatile memory, and you lose it should the power fail.
Hey Kids! I edited the parent post slightly. I think you'll find the result INTERESTING!!!
Sposky writes, "Raymond all too frequently falls into the trap of disparaging the values of other cultures without considering where they came from. It's rather rare to find such bigotry among White peoples, who are, on the whole, solution-oriented and non-ideological."
Au contraire, Mr. Sposky, most Whites people I deal with are ignorant of anything that doesn't come from European culture, and not willing to learn. God knows I've meant plenty of Black bigots, but at least they know something about White culture - they have to, there's no avoiding it. The same is not true about White 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: Black bigots are not trying to shoulder Whites out of the marketplace - we couldn't, even if we tried. The White culture, however - or its corporate sponsor - is in fact trying actively to extinguish all competition. This is open-mindedness? Give me a break.
Would you mind sending me your IP? I'll send you a check.
And what's stopping you doing the same in Windows?
Experience. The fact that the program did it once is absolutely no guarantee that it will do it every time in Windows. Obviously, the experience in *nix is different. I think that was the point of my original post.
Those who spend more time in *nix trust that more; those who spend more time in Windows trust that more.
Let me rephrase that slightly: Those who spend more time in *nix trust the computer more; those who spend more time in Windows trust the computer not at all.
And sadly, some of those are just an indication that the widget, bar or icon is moving, without any reference to or knowledge of what state Windows or the application are actually in.
Absolutely no argument here! Having trained users to expect some kind of confirmation that shitty software was actually working, software designers then generalized it to mean that users loooove to see some kinda activity on the screen. They never really understood why this occurred in the first place, did they? Not surprisingly, this kind of useless, stupid waste of CPU cycles is why I hate the Windows XP GUI!
Now, I have to say that I didn't just dream this up. After working quite a while in both Windows and Linux, I found that I had the very perceptions that I described in my original post; i.e. I hated Windows software that didn't give me some assurance that it was still working and yet the same software behavior in Linux did not bother me at all. It took me a while to figure out why.
At about the same time I noticed that working in Windows always felt a little more frantic, and it took me a while to figure that one out, too. It was because of the constant saving, checking and just general paranoia that I was gonna lose everything at any minute in Windows. I just didn't feel that it was as necessary in Linux. I didn't consciously adapt these attitudes, they were trained into me by years of experience!
"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.
Hear, hear.
:)
I've been a pretty faithful Windows user for 10 years now, and for the most part, I hate its security, but I love its simplicity. It's still my primary OS today. But I gotta tell you, XP changed all that in one fell swoop. Product activation for the geek consumer (and for anyone, for that matter) is perhaps one of the scariest things ever invented, and I can't believe how the public has just brushed it off.
I'm still running older machines that can't handle 2000. Huh. Guess that means I'm running an OS on them that is no longer supported. Is that reasonable on Microsoft's part? Sure. They can't cater to my every whim forever, and I don't fault them in the slightest for it. Now imagine trying to use XP in 5 years. Scared the hell out of me when I realized it, because I've always ran older systems that need an oldish OS. What happens if I ever need to reinstall? Or change some hardware? Sure, I could run a cracked version. Break the law, and take the risk some punk ass Romanian teenager has trojaned it. Yippee.
I look at my folks, still running 98, and probably still going to be for another few years. I look at statistics showing millions of people still on the (now or soon to be unsupported) 9x series. If things don't radically change, where will all of the XP users be in 5-6 years? Praying to god they never have to reinstall their OS, I imagine. I know we've flogged this dead horse on Slashdot, but I still don't see anyone else picking up on this. I'm still trying to explain this to a few clients that are trying to stay on NT 4 for as long as their apps are supported, and they plan on going XP as their next upgrade. They don't understand that they will be living on borrowed time once Microsoft EOL's XP, no matter how hard I try.
I like Windows. I want to continue using Windows. But it's a real bitch knowing older systems are essentially toast once they EOL their "activated" products. Hard drive failure? Oh, sorry, might as well toss that computer. Is this really where we're going with our software? Anyone know if Microsoft has any sort of information as to what, if anything, they plan to do about XP when its time is up? Because when I extrapolate my use, and the use of a lot of people I know, 10 or 20 years down the road, I see a lot of landfill. Well, or Linux machines
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
thanks for the simultaneous chortle/shudder...Trumpet Winsock...that really says it all about the 'ease of use' that Windoze is known for...thank god i never have to touch that POS again...
i just went and read his personal web site and found two things quite funny
firsly, he's a vegetarian - never trust a vegetarian! secondly was this:
"I'm a liberal, bicycling vegetarian Jewish computer geek. I have a boyfriend, Jared, (yeah, mom, he's Jewish!) who makes me really happy (giant smile)."
now i'm not homophobic or anything - but surely that comment to his mother is just hilarious. surely when you bring home your partner and HES A GUY the fact that he's Jewish isn't exactly what's on your mothers mind!
If that's really true, I have a device driver for you to port from linux to Windows that could make you semi-famous. It should be a snap to port; it makes straightforward calls to the linux joystick interface API.
anyone who reads this and wants to give it a try is welcome to it.
Click this link to learn more about a cool, cheap, multiplayer joystick driver that would be cool to have working under Windows.
I've had at least one guy who's used the Windows API for more than ten years tell me that there is no good documentation for writing device drivers using Microsoft's DirectX, even to something as simple as the joystick port. It would be so cool for you to prove him wrong, and people would adore you from afar. :-)
2. which windows emulator costs $300??
vmware.
i plug in my camera's usb... it works perfectly i didn't touch a thing, well except to browse my photos of course. the windows software that came with my camera is utter crap
On the other hand, SANE doesn't support my Microtek Scanmaker 4850 USB scanner at all.
but this is hardly the fault of linux distro's as these technologies are held back by patents and copyright holders who don't have a clue.
Then why has Microsoft been so much more successful in wooing these patent holders and copyright owners to its platform?
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.
It sounds to me like you are trying to get fired. But, since I am looking for a job at the moment, what company are your working for?
I'm willing to get paid to sit around letting the system fall apart -- then heaping all the blame on the boss. That works for me... it's a built-in promotion.
Once the boss is out of the way, I can fix the stuff... built-in raise + respect from upper management.
Once I have acheived that state, then I can coast to retirement... built-in retirement plan. This part, of course, requires hiring people to do the actual work... and you'll need a job. I could probably talk them into rehiring you.
When will Windows be ready for the desktop?
Yeah, the Windows/Java programmer will happily just use whatever XML libs are available. While the Unix programmer has his own favorite file format and loves writing yet another parser to show off his manly awk skills.
> 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.[my emphasis] 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.
This is such crap. I've seen plenty of service-based apps in Windows that allow exactly the same kind of simultaneous multi-GUI frontends as gpsd, and any competent Windows programmer can write such a service. Geez, you write like services were some great unknown concept in Windowsland.
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,
I used to be a 100% windows user, ntil i put together, with the help of the local linux guru/LAN party hosting guy, a linux based file server, i needed RAID, didnt have a controller card and had no use for a gui on a headless box.
the box was red hat 8.
in the past 9 months i've become much more intimatly familiar with *nix. My router is linux, and i just deployed two new boxes, one of them a dual boot with Win2k (for gaming). Only one of the three nix boxes has a GUI, and that right now is KDE. Granted it's a bit klunky compared to Win2k's, in fact ir reminds me more of Windows 95's desktop. Win2k's file manager/web browser/ftp client combo is nice, just type in a different address, but it has many, many, many bugs and holes.
I toyed with the idea of setting up a nix box for my parents, just mozilla, evo and OO.o. until i found out that they needed Quicken 2003 (Crossover didnt deliver).
In any case, I like nix better for some things, windows for others. Is nix suitable for use by the general population? no. it took me 6 months to shake windows logic, the gneral populus would keel over and die, at the least they'd be screaming mad.
Logistical Chaos Officer http://www.slagg.org - LAN Gaming in Sarasota FL,USA
Yes, we need to stop wasting all that effort duplicating things and instead build the best solution the first time. I propose that we make the LUGs into committees and make a super-committee, the Union of Linux Committees, which will then delegate work. That way our leaders can decide what is most important for the Community, and their wisdom will ensure that we do not stray from the true path. History has shown that letting people influence their own lives only leads to confused running in all directions at once.
Finally! A year of moderation! Ready for 2019?
Yeah, but if it was game of minesweeper that was being programmed. At least three of your hires are going to be sitting around twiddling their thumbs.
I'd just hire a Perl/Tk or Tcl/Tk hacker, and feed him enough coke and pizza to last him the single afternoon that it will take him to finish the task.
You'll be over-budget, and I'll be putting my feet up "testing" the program the next day.
YAW.
Your head of state is a corrupt weasel, I hope you're happy.
I'm convinced one of the root causes of this is that Windows people need something to point to when purchasing their solution. This is because they have the mentality that solutions are best purchased so you have someone to point to when it goes bad.
t
BTW. There are differences in transmissions. Automatics generally use more power to operate. Although in towing situations an automatic will usually do better. Software decides the optimum shift timing based on load, engine speed etc.
Ever heard of a little technology called XML? Quite popular on UNIX and Windows apparently.
Of course. And if you think that it is anything even remotely close to a solution to the issue I discussed then you have completely missed the point. An XSLT is the nearest thing to useful in this space, but the problem remains, your userid field is my useridentifier field and the writing of that translation is exactly the problem. In this context XML solves nothing, just provides a language in which to implement solutions. Whilst this may be an improvement, it is arguable at best.
"The first thing to do when you find yourself in a hole is stop digging."
Amen. However, I'll disagree with you that Unix GUIs are bad. Mainly, they're ugly and non-functional from a UI standard point of view, but I think they're just dandy for what Unix geeks actually use them for. Besides, they're a pain to program.
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."
Hear, hear.
I've only read a few things of his (typically via slashdot stories), but I've been amazed at the number of times he's promoted Microsoft and their way of doing things even if it's patently obvious to the outsider that either their particular methodology was not the source of their success, or that they didn't actually have any success in the direction he claimed. Usually the latter, or the former where the real reasons were monopolistic business practices.
Out of Tog, Sporksky, and ESR, only Tog manages to be detached enough to be believable (or instead of 'detached' should I say he's right often enough with what could be considered universal truths, that aren't just Mac specific). However, all three are over-inflated IMHO.
(Gettys not much better but keeps a lower profile).
Some 'spokespeople' however, I think do represent their cases very well. Stroustrup and Berners-Lee, for example. But these are even lower-profile.
YAW.
Your head of state is a corrupt weasel, I hope you're happy.
I'm sorry, but layers, good documentation - in Unix ???? Windows is scarsely better, but be serious. Unix is a massive indecipherable muddle at heart. It ought to have died long, long ago.
Oh Be why hath you forsaken us.
Not all post here are, strictly speaking, pro Linux. I'll agree that you won't find an OS out there that doesn't have some level of flaws.
/etc/rc#.d directory (at least that's the format in the UNIX flavors I'm most comfortable with) compared to creating a service on a Win32 system. I do however appreciate some of the ease of GUI generation capabilities found with the Visual Studio IDE, but get pretty P-off'd when the IDE crashes (not frequent, but not exactly rare) when testing code.
Now for a couple of questions...
- Why is M$ worried about Linux? Could it be the fear that eventually Linux will mature enough to compete at the desktop level? Linux already competes at the server level, but generally in limited application (server software vendors are developing their applications for Linux platform as well as the various commercial UNIX flavors).
- As for you comments on emulating Win32, any OS that desires to compete will need to offer interoperability to some level. If you take the "office" products as an example, yes, competing applications develop around the MS file formats. Taking that into consideration then, why did MS develop all the tools to read the other "office" developer file formats? They wanted to compete.
- Your comment about the average Joe and Linux is probably correct, but then again, the average Joe doesn't care about what makes their computer work. All they want is to be able to read their email, surf the web, and play a few games. I'd guess (sorry, don't know the statistics here) that if you asked an average computer user about the details of their operating system that they'd give a less than complete answer. They'd probably say MS and if they get the version, they actually paid attention to the boot up. Ask them why they chose that OS, and I'm sure they'd say it came with the PC (and they probably didn't have a choice as the mfg includes it as a bundle).
- As for professional printing capabilities, can't respond to that one in any detail. I've personally only had very minimal exposure to a Linux box. I'd have to guess that Linux, as most UNIX flavors do, supports PostScript formats and the professional printing is limited to the software development side, not the OS.
- You bring up scripting as being masochistic. I'm sort of partial to the simplicity of scripting in the UNIX environment. If I want something to run at system boot time, I find doing so much simpler to add to the
- As for gaming/home entertainment/education, yes, the choices are a bit more limited. This may change over time as the platform becomes more accepted. Applications do exist in most cases, but do not have the publicity afforded to MS or MS platform developers. Most of the Linux developers don't have the cash and must spread via the web.
- Your quick to point out that Linux people have problems w/ point and click. At the developer level, everyone eventually needs to code. An IDE will help generate framework, but the coding must still be done. Any coding for an end user will benefit from point and click and generally is written as such, even in the UNIX realm.
- Your comment about MS Media players support for other platforms shows that MS is only willing to interoperate with the ones they develop for. I haven't seen a Media Player for the other UNIX flavors. I also noticed that the Media Player for Solaris is still at version 6.3 (any ideas why they haven't put out a more recent version?).
Well I don't have time to respond to all of these. Must get back to work, but felt a need to defend a little.
Last note, I work with Win32 (NT, 2000, XP), Solaris, IRIX, and AIX. Only exposure to Linux was an old box I tried to salvage with a Linux install. I regularly work to integrate applications in a heterogeneous environments and find that Win32 based systems are often less willing to accept that other platforms exist. My preference is UNIX (any flavor) over Win32 for many reasons, partic
Grandparent:
...
Write your prototype - and then deploy it, because it's already fast and robust enough for everyday use.
Parent:
And then watch it die
Joke:
You obviously do not work for MS. Proper marketing can sell anything.
Real reply:
If you use a good platform, the prototype develops into the application. Without recreating the prototype. Without leaving excess code behind. Without making the program impossible to maintain.
My primary platform for business applications is great. I can build the interface or the functionality first. I can expand either at any time, rarely worrying about new stuff interfering with the existing stuff. The datastore automatically expands to include any fields need by the UI or the code. The source code is the programming documentation, although comments are welcome. The integrated debugger walks through the code showing the value of all variables, allowing easy debugging, and making it easy to learn what code does, and making it easy to see all the code that runs, so an obscure function is not missed. I can create backups of the entire application or any piece of functionality before making changes. The most recent version includes check-in/check-out of design elements. The client used to be cross-platform, but I can move the interface to use a web browser in minutes.
Where I start building an application depends on what it will do. If the interface is very important, then I start with the interface. Then I can get user input into whether all data is being captured. You can call that a protoype, but it is functional for data input, although most of the specifications have not been implemented at that point.
If how the data is processed is the important function, then I start with the code, then add an interface to allow configuration. Most applications require both, so I build an interface for the data entry, then build code for the functionality, then add to the interface for configuration. Repeat until the application does everything I can imagine (which is usually a superset of everything the users or specifications wanted.) When ready for release (and all fields are specified), redesign the interface for friendliness and productivity (without worrying that something will break because I moved a field.)
---
That is how I work professionally. For fun at home, I use Notepad or vi to write Java. But my home work does not require the easy development/maintenance needed by business applications.
I spend my life entertaining my brain.
One word: toilets. That was the first culture shock for me and my family when we travelled to the US in 1990. I was 12 at the time and my first reaction at seeing the hotel toilet was the bloody toilet's blocked up! And the toilets were different everywhere we went! All different flushing actions, with ducts and such at the bottom of the bowl to get rid of the waste as exepdiently as possible. And Americans seem to be embaressed of the word "toilet" so they camoflage it by using other terms: "washroom", "restroom", "little boy/girls room", etc. Very odd.
I haven't been to the UK, but I have been to Germany a few years ago. The toilets there were much more like our Aussie toilets. For me the things that stuck out in deutschland were the dual-axis swinging windows that seemed to be everywhere (at least around Augsburg), the "schwartz musik" ("black music" i.e rap, hip-hop, soul, etc) section in music stores. And in the underground parking lot of a restaurant we found a special parking spot that seemed to be reserved for women drivers, but that might have simply been due to the limited german-language skills of myself and my company at the time.
I agree with ESR here. In fact, my estimation of him as a programmer has gone up a good deal based on his answer.
If you design the UI before you write the program, chances are you are writing the wrong program. It is not possible (except in trivial circumstances) to find all your requirements up front. Any attempt to do so will result in oddly behaved programs. By thoroughly understanding your problem domain (using less than finished UIs) you have the best chance of eventually creating a decent UI.
If you get the problem domain wrong when you are creating the back end, you have less cultural baggage to contend with when you change it. Changing UI is difficult, because people get used to what they had. Even if it is arguably wrong, chances are people won't want you to change it. They could care less if you change the back end. Therefore, if the back end is broken, fix it. Easy as pie. If the front end is broken, you're in a world of hurt.
Now for the last point, which indicates that ESR really knows what he's talking about. If you've already written so much shit in your back end that no-one wants to look at it, you may as well go shoot yourself. You are well and truely fucked. Because if you can't change your back end, your program is dead. This is true of all programs. If you are afraid to change it, you can no longer work on it. The solution? Create a culture where change is good.
Don't know why I'm writing this. The story's old enough that no-one will probably look at it. Oh well.....
what's up with people who think UUOC?
... can't have two inputs to the second part of the command... fiter1. ok, now lets say I know of this before hand...
... so you do soemthing like:
... lets ... 2>&1 forget it.
...
cat in| filter1 | filter2 > out
is preferable to *me* after 15+ years of using unix and helping users with unix.
why?
filter1 out
very nice... but what if you want to prepend procedding?
dosomething | filter1 out
oops! error. why? oh.. there
many times, in unix, commands are "evolved"
cat file
then you look at the output, ok I need column 5
so you use history (control-p? up arrow?)
cat file | awk '{print $5}'
ah, nice... but now I want that sorted...
cat file | awk '{print %5}' | sort > out
sure, I could have started off with something similar to:
sort +5.0 file > out
and I do admire those who know the output format
before it is generated.
New users in unix always seem to get confused
with the difference between
not even mention > (not even close to
each other in *their* minds)
a (new) user will type
cdrecord > file
(and be hanging? waiting on input?)
they might type ^C to break... read...
later come back -- WHAT!? MY FILE IS GONE.
cat file | cedrecord
now they might get some usage... some errors... but their file isn't gone.
cat file | tr '\015' '\012' | cdrecord
You want a useless use of cat?
cat file | cat | cat | cat | cat
othewise, I think people are just fooling themselves.
next...
and to followup on my own post --
... but that's because the commands have been previously "evolved" and tested, etc. Even when building a command, I will use a redirect in via rather than a cat file.
let me clarify... command line unix usage is
*different* from (shell script) programming.
I do not advocate "useless use of cat" in programming. I do use
On the command line and interactive... 100% different.
Except when the documentation is wrong. If you built the library yourself, or have a reasonable expectation that the source code is the same in at least the function you're trying to debug, then you know the source code is never wrong. Documentation writers aren't perfect, and they can forget/ignore important details that an application programmer might want/need.
Reading too much Gibson?
What a bunch of non-sensical, english-major ramblings.
It seems you have such little to say, wrapping it in faux-tek speak will make it seem appealing.
When it is merely tripe.
Actually, this is more a matter of software not written in a monopoly environment. When you don't have inside access to change things as you please, then you're forced to abstract and layer things. It's like the difference between running into a problem and instantly moving it into the kernel, and coming up with a carefully-designed interface to accomplish the same task from userland. A Microsoft programmer has the first option, but somebody programming for Linux is probably going to have a hard time convincing the kernel maintainers to include their custom hack to enable, say, threads, without a real and pressing justification.
s/UNIX/Europeans/
s/Windows/Americans/
(Ducks!)
You will not drink with us, but you would taste our steel? - Walter Matthau, The Pirates
Try internet explorer's explorer bars section of MSDN, there's about a paragraph of text total. I was programming a remote favourites system in the other day, the only way to get anything is from sample code in the platform sdk. It's hideous. Doing the same thing for mozilla took about 90 minutes, not a full day.
Lot's of frequently used MS stuff is well documented, but anything off the beaten path is generally impossible.
-Adam
#!/bin/csh cat $0
Windows programmers see the actual data processing as a secondary task that the GUI (and only the GUI) makes happen. Unix programmers see the GUI as a seperate app, which monitors and controls the central data processing app.
You're right on the first point, but need to try a little harder on the second one. Even Windows programmers know the difference between single-app (I can't remember the right name, but I don't write those), client/server, 3-tier, and n-tier. Programming. Hell, MS has books that talk about it. Of course, you might argue that VB programmers can't read anyway...
Sure I'm paranoid, but am I paranoid enough?
One of the reasons for the invention of the dialog box is that GUI programmers don't have anywhere convenient to redirect stdin/stdout/etc.
Yes, the code that implements the API is often not very useful. But code that calls the API IS! Usually a huge amount more useful than pages and pages of documentation.
I have certainly looked up reams of Microsoft Developer Studio pages, and they are seriously lacking in real examples of how to actually use a function. In much less time I was able to write an Xlib interface (and Xlib is FAR worse of an API than Win32!) that did identical work because of the ability to cut & paste from actual working non-toy programs. I may also have been helped in that the source code had not been sanitized by marketing deleting all the "this sucks but you have to do it this way" comments.
The documentation on Linux sucks, except for the man pages (and RMS seems intent on killing those and turning them all into "info" thus removing the remaining readable documentation!). Yet the fact that programmers seem to be doing better on Linux despite this fact should say something!
PS: It would help if MSDN had a working "search" function. When I time in a Win32 API call name like PeekMessage I want to see the page that describes how to call that function! Not a hundred pages about Access or VB or developer notes that say "you should use PeekMessage to do this"
The Windows Registry is easy to program. You can easily add information. Removing information is a little more difficult. I have worked with it enough that some of the standard MS stuff actually makes sense, causing me to doubt my sanity. I expect whoever invented CLSIDs will be forced to type them in manually for eternity.
The problem is that if you have a problem with the Registry, your entire computer is useless. This one place (2 files) owns your system, and if anything happens to it, you must reinstall every application that depends on it.
MS does not have the brains and/or empathy to have implemented regular backups. Back it up every successful boot, and keep at least the last 5. If there is a problem, mark the current one as bad and use the next newest.
Applications should not depend on the Registry. Program applications so that if the registry disappeared, the program would still function. Use default settings. Then try to create the registry settings again.
I believe that I should be able to delete any configuration file without causing programs to fail. This should include the registry or any specific setting in it. If the settings is missing, use the default. If the setting is bad, use the default. Easy, and proof against both fools and geniuses.
---
Sorry, currently sensitive on this subject.
Over Thanksgiving I finished configuring my father's computer. Two weeks later the registry failed. It reverted to the only backup, which was from when the OS was installed over 1 year ago, and before any applications were installed. Almost every program is useless, and most must be reinstalled. Yes, bad programming on the application vendor's part (such as the programmers who wrote MSWord), but very bad programming on the OS vendor's part (such as the programmers who wrote MSWindows.) I already have him using OpenOffice and Mozilla, but I cannot switch him to Linux until I find a replacement for Photoshop. So I must reinstall MSWindows and all the applications once again, and I am really busy launching another start-up this month.
Yes, he usually uses OpenOffice because it is easier and less crash-prone, but he said there were a couple of things it does not do yet, so he still needs MSWord. He is willing to give them up, (or maybe OO2 will fix them) but he cannot give up Photoshop without a replacement.
I spend my life entertaining my brain.
Clean separation? No duplication? In UNIX?!? What are you smoking?
GNOME, KDE, fvwm, icewm, *wm, etc. The hundreds of Linux distros. There's a HUGE amount of duplication in UNIX! Every third open-source kid thinks its his right, nay, his imperative to duplicate something out there!
Formal and definite layers? Bwahhahahahhahha! You're lucky if UNIX apps document their command-line arguments.
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.
You can do Windows programming using vi or emacs if you want to, and compile at the command line.
:make in GVIM. I'm sure you can do similar with emacs, jsut don't know emacs. Vi and Emacs are both good text editors. GVIM and Emacs can both be extended and used as the frameworks for IDEs. When I want something quick and dirty on windows I fire up OpenWatcom, with GVIM as the text editor. When a project grows in complexity I start writing the makefile my self.
If you'd rather do that than use VS then you're insane.
Well, what about Using Vim from within Visual Studio and compiling with VS? Or writing the make file yourself and using
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
Let me clarify a little the point I was trying to make. In the windows world, the bits to connect via pipes and filters just don't exist. It's write from whole cloth, or use the subset of functionionality that comes prepackaged with your IDE every time you want to do a task. Sure the GUIs are pretty, but each GUI represents a complete processing chain. (e.g. trying to get a data stream from a tape drive == !fun)
OTOH, in the UNIX world, pipes and filters represents the dominant paradigm. Thus each GUI represents a thin layer on top of existing well interfaced components. Much nicer.
If more GUIs are really what's needed in the UNIX world, then writing them is not a problem. I think as Linux and OSS has become more prevalent, the problem has moved to "which of the 10 or so GUI based things do you want to download from SourceForge that can do your task". Thus the problem is not a lack of GUIs, but a lack of monolithic control of what the GUI will be, and where to get it from.
I think something that you tend to find in the UNIX world as well is that the end user apps exist, but just within a different context than most people think. I do a lot of scientific computing. We have written and used several GUI driven apps to do much of our work, all on some UNIX variant. We're just focused on a different end-user than Spolsky's.
I think it comes down to compensation. I have yet to see a compensation methodology for system administrators that encourages the security and reliability minded attributes you are looking for.
.. if a sys admin is truly mindful of these attributes, they can generally avoid the majority of viruses/worms/exploits/etc. Infact, many of the tools that they use for their job can easiy be scriptable, scheduled, etc to the point where they don't really have to do a whole heck of a lot except for monitoring the system.
... if they are really good at their job, they can usually setup systems, maintain them remotely when necessary and generally not have to worry about them very much. Again, less $$ for them for doing a good job.
..
Lets face it
However, if they do this, generally they are perceived as "not doing anything", get smaller budgets to work with, less staff, etc.
So where is the benefit? If security is laxed and the occasional virus hits the systems or computers are less reliable than they should be, then the sys admin is seen as the "hero" for fixing the problems. No problems = out of sight = out of mind.
The problem is even worse for part-timer/hourly sys admins
As a sys admin I tend to want to setup systems correctly, maintain high security on critical infrastructure aspects and work in such a way that supports the rest of the organization. However, I have yet to determine a way to properly compensate for a job "well done"
Any thoughts?
First, the arrangement you describe still isn't a common one. Second, the ascendancy of the GUI as the average user's way of working with the computer preceded plentiful bandwidth by quite a bit.
You don't need to subscribe to MSDN. http://msdn.microsoft.com/. The ENTIRE thing is there. Or do you just want to pretend it doesn't exist?
Amusingly, I'd reverse that exactly. After all, Unix is rational and works, and therefor American, while Windows is silly, looks sharp and never really accomplishes much--it's gotta be European:-)
"...a good windows programmer will create an object (COM/C# Class) and then write a GUI that will call this object."
Regardless of what you think of Jakob Nielson (http://www.useit.com) and other usability gurus, writing the GUI as an afterthought is not good Windows programming.
Running usability tests (e.g., paper prototypes) early on in your development cycle can give you valuable insight into how your users expect to accomplish their tasks. You owe it to yourself to try it out.
Boy you really don't get it, do you.
I used both Unix and VMS on 9600 baud video terminals (so no wasted paper, and very little wasted time, in fact I think the Unix machine printed slower because it went through a network and a VMS front end which did not like the character-based Unix interface much). I can tell you that the terseness of Unix was an incredible relief compared to VMS. I could see what I did, it was not buried in tons of boilerplate, and I could easily run other commands that would tell me that information (like "how many files") if I wanted to know it. This (and the simplified filenames where '/' and '\0' are the only reserved characters) was so amazingly liberating and stunning that I was sold.
In fact part of the reason there is Unix fanatics is that absolutley amazing relief we had when we first encountered it. Part of the livid hatred of Microsoft is that they did not copy Unix, instead reverting to filenames and a command style and CRLF pairs that we knew were obsoleted in 1970, and then having the unmitigated gall to claim they were "innovative". In fact if Microsoft had just made Windows Unix-compatable (and not even do a good job, Xenix would have been good enough) I really doubt anybody would have heard of Linux, and Microsoft would run every single programmable device in the world.
In fact Microsoft blew it totally, but they refuse to admit this and thus refuse to allow their programmers to do what is necessary (copy as much of Unix as possible, while keeping their own advantages). Instead they keep reinventing things, ignoring standards, and pissing people off endlessly.
Wake up, Microsoft. You could wipe Linux and everybody off the face of the planet in less than a year, if you would just make Windows Unix-compatable. This means put forward slashes in the filenames, get rid of CRLF (only read needs to use the binary flag), make readdir() work to show all the disks, and a few other really trivial things. And provide a modern shell and tools right now (the code is all available for free from GNU). The problem is you have to swallow your enormous ego and admit that there is nothing wrong with being compatable with the good ideas that came out before you.
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.
or better still, have an underlying component object model that exposes the functionality of your system and then have a set of GUI and command-line tools that both use these components. oh, and while you're at it, document and expose these components in such a way as they can easily be used from 3rd-party scripts and programs.
Keeping little stories to ourselves would kind of ruin the whole point of Slashdot, no?
Cold hard facts:
- very large bank spending large amount of money
- web application built on COM+, MSMQ, and MS clustering
- application failed because of incompatibility in MS's own software layers
- assistance from Redmond failed to solve problem
- project eventually deemed unworkable and killed
Now, you may be right that there was, somewhere, a solution to this, perhaps even an obvious one. However it escaped the people at the time, all competent, all professional.
My story may even be false, it's possible. IT is so complex that the real story is often hard to uncover.
But the conclusion that MS products are heavily vertical and often interoperable only within tight margins (specific OS, specific SP) remains, and is well-known to anyone who has developed for Windows.
Attacking my credentials is not a response. Showing me the well-defined Microsoft APIs that have been used by Microsoft's own application development teams without compromise... now that would be a worthy response.
Ceci n'est pas une signature
It's impressive how your rant manages to make absolutely no sense. It must be shameful for your family to have a relative so obviously incapable at something they care enough about to wax idiotic on Slashdot. Seriously, I can instantly determine that you've never written something larger than 10kloc just from your post. Sad.
Its more of the OpenSource "Hacker" vs the Closed source Kiddy.
POSIX
Ceci n'est pas une signature
Thanks. I have been reading Slashdot for years, and should have known to mention the GIMP. I did try it a while back, and decided I did not want to have to support it when my father calls. I plan to install it during this reinstall session (see previous post) but tell him that if he has any problems, switch back to Photoshop because I cannot answer them.
That is how I handled the transition to OpenOffice. He had used MSWord for years. I installed both. He tried it, found it easier, stopped losing work, and stayed with it. Except for a few things that either OO cannot do, or are hidden well enough that he could not figure them out. (He reads Help files, but forgets he can web search for help.)
I am hoping that GIMP2 and OO2 will be ready before I finish reinstalling, but I may do it before EOM/EOY, so I doubt either will.
I spend my life entertaining my brain.
Funny, since CORBA was largely backed by UNIX and both GNOME and KDE are largely built using shared libraries and component architectures. You know, since it follows the Rule of Separation to not couple general code to fixed interfaces.
I prefer documentation over source code. But the microsoft documentation on user/gdi/kernel is incomplete. It covers the trivial cases but leaves out most corner cases. When compared to, say, OS/2 API documentation the microsoft documentation is "thin". IBM knows how to write documentation.
An example: GDI paths. (selectclippath, beginpath, closefigure, etc). The documentation tells you how to make a string into the outline and use that as a path. It even has an example for doing this. good. Guess what happens if the font you are using is a bitmap font? The documentation does not tell you. Not even a hint. (answer: the path functions does not fail, they just simply wont work).
The API could also be a lot better especially when dealing with errors. People who have tried using BitBlt or SetDIBits knows the horrors of error 87. One of my other favorites in the documentation is: "If the function succeeds, the return value is 1. If the function fails, the return value is 1."
Looong ago, I started using computers. Apple II, Mac's, Windows, more windows, and more windows, and UNIX. So here I am, armed with knowledge from reading the complete DOS 5.0 command reference (summary, do everything you can to stay away from a serious DOS script), and I look at UNIX. I spend 10 minutes trying to figure out how to do anything besides log out before I log out. And off to the store I go to buy UNIX for Dummies. Now I'm sitting at a unix workstation with a Dummies book, thereby being called a loser by both the geeks and the non-geeks, and looking at commands that do exactly what happens in a basic DOS session. And here's what I learned about the commands used in bash (the only shell I bothered to learn at the time)*:
Take an action you wish to perform, say, see everything in a directory.
Think of every command you can think of that sounds like it would do this: directory, catalog, list.
Now, discard any command that has been used for that purpose in another OS. That takes care of directory (DOS) and catalog (Apple II), leaving list.
Now, remove all the vowels - they're useless anyway. This leaves us with 'lst'.
Last, use only the first two letters. Ah, there it is: 'ls'. If this conflicts with another possible unix command (or you unwittingly used a command from an interface more obscure than the Apple II command-line), the more common command (surprisingly) gets the abbreviation, and you need to go back to the top with another possible command.
I may have missed a couple rules, and there might be a couple exceptions, but this handy guide will solve half your problems for figuring out unix commands.
*I already said that this was long ago, and when I first learned unix, and that it is a general rule, so don't go talking about things like chmod, etc.
Sure I'm paranoid, but am I paranoid enough?
Window$ Core Operating $ystem Divi$ion (CO$D)
Considering some translations of this acronym?
Micro$oft$ Covert SCO Divi$ion. (please note that there is a slight play on the arrangement of the letters on M$ part.
Or maybe
Cost Oodles of Serious Dollars (for the license)
However this is the most likely ;)
Complete Open Source Domination
I think this type of thinking is outdated. There are programmers like myself who pride themselves in being able to program on both platforms (read: windows and unix like environments). The end user is always the focus of our attention, but that end user might _be_ a developer. We don't care about cultures and alliances. The machine is a tool to be used as such.
Renaming the Shortcut doesn't break the link. Changed "Shortcut to CMD.EXE" to "Command Prompt", and the shortcut still works fine.
This incompatibility you talk about is interesting. All of these products are based on the COM binary format specification. And again, they are designed to work with each other. I don't know how to try and prove this to you - I've been using them for the better part of six years. They have bugs, yes. All software has bugs. But I've never had to cancel a project because I couldn't figure out how to make them work together. Sorry, that's how it is.
- assistance from Redmond failed to solve problem
I've had Microsoft support people come on site, solve a particularly nasty problem and then use their laptop to compile a patch in front of me. I don't know what your problem was (and apparently you don't either) but in general Microsoft can identify issues with their software and then issue a fix. I don't know what your support arrangement was, either. But that's my personal experience.
project eventually deemed unworkable and killed
This happens on the mainframe as well. It's irrelevant insofar as your other points are dubious at best.
My story may even be false, it's possible. IT is so complex that the real story is often hard to uncover.
So... you weren't actually there, right? This is hearsay?
But the conclusion that MS products are heavily vertical and often interoperable only within tight margins (specific OS, specific SP) remains, and is well-known to anyone who has developed for Windows.
Oh, most definitely true. No question about it. If I want to make XP and NT4 talk to each other I normally use the lowest common denominator: TCP/IP. Or a subset of RPC/DCOM. If I want to use the "elegant" vertical tight protocols with lots of flash and bang and transaction support and whatnot, I think it's only fair to assume that my environment should be pretty much homogeneous. Right down to the service pack. But this is true for all platforms that provide anything more advanced than sockets, not just Windows.
Attacking my credentials is not a response.
I wasn't attacking your credentials as much as the validity of your anecdote and your point in posting it to begin with. Like I said, I have no problem with people going off like this, but you should expect someone to call you on it. If you were talking about a botched project involving DirectX you wouldn't have gotten a peep from me, because that's a technology I don't understand or otherwise use. But large distributed systems on Windows using COM+/MSMQ/BizTalk/AC2K/HIS2K/etc... well, that's what I do for a living. And when I say they work it's because they do. Whenever I see someone assert how some company cancelled a project and lost a bazillion dollars because these technologies "don't work" I get a bit worked up.
Actually I've seen projects like these scrapped - but because someone couldn't get some Microsoft technology to work with some Oracle or IBM or PeopleSoft technology. That's where things get dicey, regardless of vendors' claims to the contrary.
Showing me the well-defined Microsoft APIs that have been used by Microsoft's own application development teams without compromise... now that would be a worthy response
I'm not sure what you mean. For example, everything in Windows uses COM. From the shell down to the graphics subsystem. COM+ and MSMQ are perfectly interoperable if you know what you're doing. And so on. Just because Windows has a pretty GUI it doesn't mean you can write complex applications using wizards and widgets. It doesn't work that way.
Also, aren't you forgetting the huge 3rd-party windows control market (VB controls, OLE controls, ActiveX controls, .NET controls)? None of these use stdin/stdout for communication, and many of them don't provide any runtime GUI.
Windows programmers don't read/write to stdin/stdout because they don't have to. They don't have to worry about formatting and parsing messages and sending them across a single, simple channel, they pass data as parameters to method calls on interfaces on objects, the marshaling of data and the message transfer is handled automatically for them by the operating system.
My favorite MS API problem was in porting a config application to work with a linux server on a remote machine. This was just a prototype, proof of concept, but it would be shown to upper management, including some that thought we were wasting our time. (Linux isn't supported... its just a fad... it was 1998)
... I stopped, expecting to hear how much better VAXes were or how time was wasted on the youth... but instead he asked "What are your IE settings?"
My coworker, an old VAX Hacker, made the linux software create a file 'CONFIGURING', the pressence of which let me know that the machine was busy (Took around 5 minutes). I simply had to ftp the file down and when I got nothing, I could say the CONFIG was over. An ERROR file would contain any error.
He had developed a very simple MFC app that made an system exec call to 'ftp.exe' to download the file. I took his code and incorporated it with the more feature rich config app. The problem was that everytime I polled with ftp.exe the Command prompt window would appear and dissapear. Real Ugly, Real Bad. So I decided I'd just use the CInternetConnection classes in MFC to do the polling. My friend said I should write my own, but I repeated off all the traditional MS axioms of "Supported by Microsoft" bla bla bla...
I whipped it up in less then an hour thinking, cool, Microsoft made this really easy. So I started it, it received the file, so I polled again in 30 seconds and incremented the task bar... everything looked beautiful, it kept polling and recieving the file, incrimient the task bar... and it kept doing this for 10 minutes.
I telneted to the machine, the file was gone, but my software still was polling. Weird... but wait! I betcha its caching the file! So I checked Temporary Internet files and there it was, so I deleted it. Then I checked the API docs, there was a direct flag I could add when creating the connection called NO_CACHE! The MSDN documentation even stated this would turn off caching. I felt that incredible high when you find a perfect solution to your problems. I enabled the flag and recompiled, 100% sure it would work.
It still cached!
WTF! I poured over the documentation and deja news (before google)... Nothing. I should be able to set that flag and it should work. I spent 1 1/2 long hour DAYS trying different things, tempted to go in to the Temporary Interenet files and delete it myself. I COULD not stop it from caching the file!
So I sighed, told the guy, I'm goign to have to write my own socket layer for this. Oh well, give me a few more days.
"Wait" he said
"What? How can IE override my direct calls to the API? That makes no sense, if anything it should use IE settings as default, but I should be able to override that, which I am. The docuentation doesn't even mention that you get your settings from IE! Besides which, I've spent too long doing this and my friend already told me I'd have to end up writing my own ftp client."
"Try IT!" he now ordered. "Ok", I turned off IE's caching... and it worked.
I am still disgusted...
And about 200 dB at a foot from said terminal.
To heck with bandwidth! It wasted hearing!
That is all.
in my life God comes first.... but Linux is pretty high after that
Francis Smit
If you are all so smart and think everything and everyone else in the world is stupid and beneath you, why don't you actually innovate something of your own, Oh-So-Wise One.
(Like you've actually ever made something of interest to us.)
in my life God comes first.... but Linux is pretty high after that
Francis Smit
Whenever I see someone assert how some company cancelled a project and lost a bazillion dollars because these technologies "don't work" I get a bit worked up.
This is very true, I have seen numerous large projects fail for many reasons, from unclear business requirements, to sabotage, bad management, over-ambition, stupidity, and so on. But over-complex and untested technical platforms are a recurrent underlying theme. Too often. People take vendors at their word, seek to rely on untested functionality rather than build their own, and it becomes a matter of project faith that such-and-such an architecture can and must work when in fact it's unworkable. I've seen this in perhaps 3/4 of the large failures I've watched happening, over 20 years. It happens shamefully often.
My business is designing software architectures, and frankly I find Microsoft's view of the world, and the view they sell to developers, to be... I'll be polite... inelegant and inefficient. It may be the result of solving problems by brute force and money rather than through good design, but it is also clear that Microsoft started as a company that placed marketing before technical quality, and this mentality has never really been eliminated.
There really appears to be a sad but generally accurate rule in IT. When marketing is more important than design, the result is technically poor but the company prospers. When design is more important than marketing, the result can be technically excellent, but the company will eventually die.
Very, very few businesses get both these right.
Ceci n'est pas une signature
No source code = debugging hell If you say that in C, it's debugging hell allright...
Hmm, well, if you read like you say you read, you would realize that Windows ME (which sucked, all things considered, but please get it right as to WHY it sucked) didn't say you had no access to the command line. It said you couldn't BOOT to the commandline instead of booting straight into Windows ME. Which is true... as it was shipped. And have you LOOKED at MSDN without a subscription? Without giving them ANY money, there is a hell of a lot of information up there freely available. You don't even have to sign up for the free access.
I agree with the cut-paste problem. (It still is).
But a good gui for unix will NOT be written:
a) by cloning windows
b) without changing unix at all
I think his point was that the two cultures started out with two very different goals, and the easiest & most concrete way to sum it up is by describing the expected end-user: programmer vs. unskilled novice.
I did not perceive from his article that he advocated one over the other; rather, I thought he was describing what he considered to be the essential pressure dividing the two cultures. This was a pretty neat point, I thought, and explains some of the frustrations I've experienced working with folks from both cultures.
Of course, I had to actually read the article all the way through to get the point, so that probably just shows how far behind I am in terms of /. indoctrination.
What if a non-experienced user needs to run your scripts?
If there is no GUI you do the test, the test is;
1. Do I trust the GUI user with my wife, my life?
2. If the data gets completely hosed, will I get blamed, have to work over-time to fix or find a new job?
3. Will the GUI-user blab any secrets we show him to his fellow GUI-users?
So if he's a guy that always;
1. backs up the data before doing any dangerous stuff,
2. brings your pistol back both cleaned and unloaded,
3. buys your wife dinner before sex and makes sure she showered before he drops her off at your house afterwards,
4. keeps his mouth shut
then you might consider him for nomination to Command Line Wizard's apprentice entry-class! Otherwise you tell him it can't be done.
Apocalypse Cancelled, Sorry, No Ticket Refunds
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).
The point is that it isn't your story. It's just hearsay.
(and the simplified filenames where '/' and '\0' are the only reserved characters)
That's not entirely true. Yes, from the filesystem perspective there are only 2 reserved characters. But looking at Unix as a whole (especially as it was delivered 20 years ago), you really had to treat other characters as revserved.
Like " ", "*", and especially "-". Many programs and commands that are fine in general will choke up or become randomly destructive when fed names like that. Or at the very least, the user-friendliness of the CLI is destroyed.
In fact if Microsoft had just made Windows Unix-compatable
Legally, it already is Unix-compatible, in that Microsoft(tm) achieved POSIX certification for Windows NT.
duh!
If at first you don't succeed, skydiving is not for you
"...cater to BOTH."
I read that and as thinking:
Bastard Operator ? Hell.
what does the t sand for?
heh.
Thats said, there is no reason why a GUI couldn't be designed to create an automation procedure.
Dropdown for the program, text box fr paramteres, checkbaxes for when it need to run, etc...
Of course, I'm the guy who designed a GUI that the grey hairs use instead of the command line.
The Kruger Dunning explains most post on
that point wasn't distant at all!
The Kruger Dunning explains most post on
You could wipe Linux and everybody off the face of the planet in less than a year, if you would just make Windows Unix-compatable.
Oh, and that's backwards. It's a classic case: reduced barriers to switching benefits holders of minority marketshare more than their larger competitors. (So in the extreme, a monopolist will never want to encourage compatibility)
The incompatibility of Microsoft Windows vs Unix-like OSes is helpful to Microsoft. It prevents people from easily switching away to other providers.
If Microsoft creates effective Unix-like support, then future vendors of Windows applications will use these features. Eventually they might transition to them entirely. (Why would Oracle or Adobe continue to write separate Windows, Mac, and Unix releases of products, when they can just move everything to a Unix-targeted codebase?)
When that happens- when some major Windows applications are using its Unix API, not the Win32 one, then it will be easier for users to switch away from Microsoft's OS, while keeping their applications intact.
So, to protect their shareholders, Microsoft should avoid anything that'll help customers switch.
"I polled with ftp.exe the Command prompt window would appear and dissapear. "
Next time, ask a windows programmer how to execute command lines without showing the command window.
Probably the biggest distinctive is: that M$ uses many really bad coding/design practices and the Windows culture is such that it says: oh M$ does it, it must be good. Whereas if the *nix world where to be confronted with the same thing we'd rightly can the programmers and not use their crappy code.
in my life God comes first.... but Linux is pretty high after that
Francis Smit
Am I the only one who found it amusing that there's an MS ad at the top of this page, advertising "Windows Services for UNIX" - Resources for UNIX professionals who want to use their existing skills to manage the Windows OS and applications?
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.
I had an application that printed a report after every execution. about 1,000 per night. No-one could find the reports and no-one really checked the output. Changed the application to on non-zeo return code and guess what the bug reports started rolling and we started solving the real problems.
Chatty is bad, conversely I would acl my harddisk format to confirm and give me a success message. I don't do this 1,000 times a night I do it maybe 1 time a year.
but it is also clear that Microsoft started as a company that placed marketing before technical quality, and this mentality has never really been eliminated.
Because there is nothing wrong with it. Just because you are a good software designer doesn't mean elegant design is the most important thing in the world.
I'm a good software designer too. I used to work my butt off to produce layered, object-oriented, efficient, easily maintained, bug-free code. But after failure of three companies (big and small) and all those hard work turned into meaningless, worthless code, I realized how right Microsoft's mentality is. Having users complain about your software is the most effective way to find out that your software is actually needed. If a piece of software is truly useful, users will tolerate its bugs and other problems. Here I am talking about the business environment where a company simply dies if it can't make enough money quickly to cover its cost. If you have a more secured position where you can show off your geek talents without worrying about running out of money, then you are just lucky. But consider yourself exception instead of the norm in the real world.
Still... using ftp.exe was a hack. No control over the connection, no errors, the connection and download procedure was hardcoded as Strings. It was ugly... it needed to go.
http://support.microsoft.com/default.aspx?scid=kb; en-us;189105
k b; en-us;314486
http://support.microsoft.com/default.aspx?scid=
No, a BAD VB programmer will do this
GOOD VB programmers start with the objects, OR the database first (hey, sometime the DB counts for more)
GOOD VB programmers were even doing something similar to this back in VB2 and VB3 - yep, pre objects in VB - NO code (or as little as possible) went in the UI - they wrote "BAS" modules, and called the functions there - effectively - using the idea of encapulation way back when
Just because there is a LARGE percentage of VB programmers who DON'T do it right, doesn't mean we don't ALL do it right
Back when we was interviewing folks during the dotcom boom, a group of us had an expression "Shrink Wrap" - aka, the guys who thought they were programmers because the had taken the shrink wrap off the box
I WILL admit that part of this problem has actually been caused by Microsoft - their example code (particularly in the "old days") was the EXACT _WRONG_ way to write good, maintainable code
The problem is, we still have a LOT of VB coders writing "VB3 code" in a "VB6/DotNet" world.
Ask people who were around "Back when" what happened why Foxpro IV came out. Fox IV was Object Oriented, Fox III was NOT - The product died, because most of the programmers could not make the transition . Microsoft learned form that, and allowed the transition from VB3, to VB4,5,6 to be smooth, and to allow you to still code, "The same old way" - the problem is, people got the "same old problems"
Part of the problem a LOT of VB programmers have in moving to dotnet is that they never learned the "right way" - then there are the "Others". We had NO problems transitioning
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
Your right, and that's why I find the BEST windows programmers either started out on DOS and remember their command line, or some OTHER command line OS
Batch files - yep, been there, do that (Notice the tense)
Command line utils - yep, to the point that there is a copy of cygwin on my desk
Background processes? Do that
The thing is, I do 2 kinds of programming - the classic stdin>stdout type stuff (what I'm working on today BTW) and the "rich user interface" - stuff where the company has to be able to put an intern that was hired yesterday to work TODAY
There is a place for both styles, and your best programmers will use whichever style of working to accomplish their goal
I know I'm gonna sound like an "Old fart" - but when you learn to program on punch cards, where you have to batch things. Thing is, sometimes a GUI makes life easy
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
Unix applications don't talk to each other via strange, binary, unreadable protocols such as Corba, COM, DCOM, COM+ or whatever MS is selling these days.
/dev/sda1" command you mentioned will produce simple, readable text for me, eh? I'd paste the results in here, but Slashdot has filters to prevent raw, ugly, incomprehensible binary.
Corba is a Unix protocol. So is rpc/portmap. So are X11 and DCOP and Bonobo... None of them are something I'd care to read.
They talk text. Simple, human readable, text.
Uh huh. So this "cat
The Unix idea of a standard input and output stream for each program was a good idea, but not followed through enough. In particular, from a programming language standpoint, there's something very important missing: type safety. Or even types at all.
It's ironic that Unix was supposedly tightly related to the C language, and yet C's weak typesystem is stronger than whatever Unix provides. Is the failure of Unix to provide transmission of datatypes more well-defined than an anonymous bytestream that created an opening for a proliferation of overcomplex IPC protocols.
What world are you from? I'm an American, BTW.
Does the American educational system work? By most accounts, it's one of the worst in the world.
Does the American healthcare system work? Millions of people would say no.
Does the American legal system work? For lawyers, yes. For everyone else who isn't rich, no.
America is a good place to live if you're extremely rich, and can afford to pay for your own healthcare, your own lawyer, and your kids' private schooling. For everyone else, it sucks (compared to other first-world countries of course).
I'll grant you that a lot of European cars look rather silly (mostly the really small ones), but most American cars are pretty ugly too (just not in a silly way; more of a bloated way). And Europe has way more nice cars (Porsche, Ferrari, etc.) than America (Corvette, umm... Corvette).
And of course, there's the American fixation on the Imperial system of measurements...
"geek talents"?
"geek talents"??
It is the sign of an amateur to accept to produce second-rate work just to pay the bills.
The norm is that most of what makes the world tick is the 10% of quality that has survived the brutalities of the "real world", and this slice of quality sustains the remaining 90% of junk.
It's true in every domain of human activity. We all know that it takes more effort and skill to write a really good song, or cook a really good meal, or design a really good program. But please don't reduce this to: "build junk, let your customers suffer, and pay the bills". That is just sad.
BTW, I'm not a "good software designer", I'm one of the best programmers ever born (and forgive my immodesty but I've had a long time to come to this conclusion), and part of what makes me so good is that I simply do not comprimise on the quality of the design. If it's not perfect, I stop, start again, and make it so. My products rarely fail, my businesses do not go bankrupt, and we still use and maintain code that we (my team and I) wrote as far back as 15 years ago.
This is incidental.
You can comprimise on quality when you're making an accounting system for the corner grocer. You cannot when you are making software that entire industries will rely on.
This is the basic difference between Unix and Windows. Unix strives to find and select the very best possible solution to every problem faced. Windows strives to provide the maximum functionality without regard for quality or sustainability. No surprise that most Windows developers throw away their work every 2-4 years, while most Unix applications are built on old, reliable, cheap code that is as tough as nails and as solid as hard concrete.
Ceci n'est pas une signature
Organization and manipulation of data is a specific problem requiring specific skills. Ideally one will find the optimal process to handle the data quickly and effeciently.
UI is another issue. It requires a certain skill and tools. The user thinks of data in a certain way, and it may not the best way to work with the data in the computer.
The problem with Windows programming is that want to combine these two processes into a monolithic program. People raised on visual studio want to hook widgets to databases and call it programming. At no time do they ask if the the solution makes sense.
The upshot is is the GUI presents a data structure, not a interface. The database is driven by the need to make it understandable to users, not effeciency. Both sides lose in this model.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
What the heck are you talking about? Manual transmissions are almost always superior for towing. That's why tractor-trailers only come with them.
Automatics require extra cooling for towing because the extra load causes the hydraulic fluid to heat up a lot.
Manuals have simpler designs with less parts, and are easy to scale up in size to meet the requirements for towing 100,000 lbs.
Windows is for pussies, but "UNIX" is for men who don't have dicks.
No end users for Unix based systems? What an idiot.
First off I have programmed on systems ranging from IBM mainframes through the minis and into the PC"s and unix workstations. Every unix workstation I've seen since about 1985 or so has had end users. Who does Joel think is sitting between the chair and the keyboard anyways.
Most IBM mainframes have end users - at least the tellers in the bank do look like end users to me. All the mini's I ever saw had end users too. So what is this guy flapping his lips about.
As for error messages? M$ stripped the error codes out of the stacks in NT4.0. I saw exactly the same text comming out of OS/2 and on many occations and had to go to my OS/2 machine and call up the error in order to find out what was wrong. NT4.0 was zero help. This is one reason I've abandonded NT.
Not only this - I've found that I could not copy files over the net with NT networked into OS/2. The files failed to arrive 100% of the time with a network copy. FTP did work. NT never provided a single error message. So this fact alone provides proof that Joel does not know what he is talking about.
A test many can try is this. Take a windows 95 machine and an external SCSI hard drive. Do say a dir/s so it will search the disk. While it is doing this, turn off the drive.
You'll find that winders does not provide any message at all that the operation failed. It is very clear that M$ is quite content to put bad data into the end users files or to throw away the data completely rather than deal intelligently with a problem. This is NOT the case with UNIX.
So IMHO Joel has no credibility at all. I think if one checks back to what he did while at microsoft we'll find that integrating the Visual Basic scripting languge into word is one of his accomplishments.
To do something like this is STOOPID from a security standpoint. There is far too much power in the BV system. A word document from a black hat source can ruin your system. Did anyone ask the question why a word processor should be able to run any old code from any old source?
tar -jxvf dir/
you see the file.tar.bz2 done, not a "hey, here I am!" message.
Actually, what you'll see is an error message, since x means you are extracting from a tarball, not creating one, and you specified a directory rather than a tarball as the target. Plus - since you added the v, you'll get extra verbosity. ;-)
Arrr!
What I see is that Windows APIs etc are done through sheer brute force. There are so damn many of them, and they don't particularly make much sense as a whole, but given enough programmers you can implement and use them. Due to the way they are done, usually other components then have to reimplement them in yet another different way to get slightly different behaviour.
The UNIX world tends to place far more emphasis on elegance and simplicity.
UNIX was written by two people. Windows was written by hundreds (later becoming thousands). The UNIX windowing system was 4 people, Windows was thousands. Look at how many Windows APIs have to take cbSize parameters, and have Ex versions.
Unix's fork() and exec() take only the parameters to specify the program. The equivalent Windows API takes 14 parameters.
Both will do the job, and as an end user I don't care how hard it was for the programmer. But as a programmer I follow the examples around me, and UNIX is full of good ones.
I do the same when working in unix and am typically fairly unworried while working in windows. I think this has to do with familiarity more than anything.
You can comprimise on quality when you're making an accounting system for the corner grocer. You cannot when you are making software that entire industries will rely on.
Are you sure your software is so important when it is used by a big corporation or government? How about those CEO's and board of directors who ran companies into ground? Aren't they more important than your software? Can you tell how many crooked decision makers are out there running the business world and the government? If you can live with them, then don't be so harsh on a few bugs left by your fellow software engineers. Unless you subconciously feel threatened by those software developers who don't do things your way.
Actually, this is more of a "management" issue than a Windows or Unix issue.
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.
In many cases the GUI can be a clumsy way of either doing something or telling the computer what to do. e.g. printing several files under Windows especially if you have to send them to a printer which is not normally the default printer.
Because when you write a GUI which must be easy to use, you have to trade off flexibility for useability. The GUI is designed so that the average user finds it easy to use. The problem is a lot of people aren't the average user, so you find that in order to carry out the task you have to navigate through a plethora of menu options, or worse, do something which should be automated manually over and over again. IMHO, this is something fundamentally broken in the whole ease-of-use idea - it's only easy to use if you're doing exactly what the designers want you to do.
If I seem short sighted, it is because I stand on the shoulders of midgets
But I am European (and it looks like you are American), so maybe it should read:
s/UNIX/Us/
s/Windows/Them/
to be more universal!
You will not drink with us, but you would taste our steel? - Walter Matthau, The Pirates
I'm sorry to pick on you, but your post typifies the bullshit that undelies this entire thread. Hello, everyone! Windows does not have a monopoly on GUIs. UNIX and every other operating system out there uses GUIs. And the GUI programmers, for whatever operating system, care as much about the user experience as do Windows programmers.
UNIX is not limited by stdin, stdout, and stderr, after all.
Think of UNIX as an onion. The kernel is in the center. Then there're all sorts of other operating system layers up to the shell and user applications. And the GUI is the outermost skin of the onion. To say that UNIX programmers only care about "data processing" or what comes in stdin and goes out stdout is to ignore a good part of the whole system.
Also, not all Windows programmers are GUI programmers or even care about the user's. So it's not fair for them either.
But, this post does not further the flamewar and comes from an "Anonymous Coward", so I doubt it will be modded up.
... if you can't see Linux making it big on the desktop. I can see it just fine. what you run on your desktop does not bother me.
There are also other people who, while scoring low on logical intelligence, score extremely high on social intelligence, kinetic intelligence, musical intelligence, etc. These people are just as talented as any UNIX programmer, only in another domain.
Are all these people, regardless of their intelligence in whatever domain, unworthy of being offered a computer experience that is straightforward and consistent? Must the whole world become programmers at a professional level? Because that's the underlying message of a lot of the RTFM crowd.
There's a reason so many creative people gravitate toward the Macintosh, with its (theoretically, at least) "every program works like every other program" paradigm. They simply have other things to do with their lives than read "man" pages on building drivers, thousand-page tomes on UNIX programming, and memorizing 15 different and sometime contradictory GUIs and keyboard command sets.
The next time you are being given an injection by a nurse, enjoying a dance performance, or benefiting from the skills of an office peacemaker, remember that they are also computer users. If that nurse spent all of her time programming the myriad instruments she uses to monitor your health, she probably wouldn't have time to actually ... well, monitor your health -- probably wouldn't even pay attention to all the nonverbal (and non-instrument) cues that tell her how you are doing.
It takes all kinds of people to make a world. We all need each other. Non-programmers need programmers to give us these potentially marvelous tools. Programmers need other programmers to create tools that are useful for programmers. And someone must intervene between the programmer and the "end user" to ensure that these tools are actually useful to a general population. (Hence the Macintosh, as Joel pointed out.) And you, Mr. Programmer Guru, need nurses and dancers and musicians and cooks and, well, friends and family who's skills are in being your friend and your family. It's not a question of which culture is superior. It's more: how can the best of all cultures mesh?
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.
IMHO what I suspect is going on is that you can go a fair way with Windows without actually understanding what is actually going on. A learning curve akin to y=x^n. Whereas with other operating you tend to get nowhere unless you know what is going on. A learning curve akin to y=x^(1/n).
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).
My experience is also that people "brought up" with Windows tend only to understand Windows. Whereas those "brought up" with Multics, Unix, VMS, TOPS, etc appear to have more easily transferable skills. Usually the difficulty the latter have with Windows is understanding Microsoft Jargon...
Amen to that...
I have a VAX at work which churns out about 10 pages of junk when rebooting. Occassionally some background process doesn't startup correctly. I never realize this, becuase the error message is burried in 2000 lines of "this volume mounted successfully" and "that volume mounted successfully".
Those kinds of messages are great for debugging, but when the system is in production it should only call for help when it is needed!
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.
I think that 2/3rds data processing figure is wildly inaccurate. On personal computers, what people do is they do their email with an email client, they browse the Web with a Web browsers, they write documents with Word, use Excel for some simple "data processing", prepare presentations with PowerPoint, listen to music with their music player app, and maybe use one or two specialty apps for their field.
That's about it for 99% of computer users.
As a programmer with tools like Perl and the Unix command line utilities available to me on all of my platforms (Linux, Mac, Win w/Cygwin), I find myself doing "data processing" tasks all the time. You may be like me, but that doesn't represent the ordinary computer user. The ordinary computer user does the same tasks over and over again using GUI tools that are optimized for those tasks, while you and I get extra value from out machines by going beyond the prepackaged functionality and doing custom "data processing" that isn't easily done with the standard MS Office-type apps.
Thank goodness their are tools like Linux, Perl, Python, grep, cron, etc., for us, but the Windows/Mac GUI way is a better way for most people.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Sometimes you need to do something once every three months. Clicking in a gui would get the job done in maybe half a minute, while reading up on the required command line actions would take half an hour. So in this case you need a gui.
Actually the time interval dosn't really matter. Repetative tasks are better done by machines than humans.
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.
A just as likely senario is that the same task needs to be done once every few months on several machines all within a certain time period. e.g between 2 and 3 am (either local time or GMT) on the first of every month.
what's that?
In British English, "toilet" often refers to the whole room, and the whole, uhhhm - experience - of taking care of sanitary needs, including not only getting rid of waste, but also the washing up afterward, the sink, the soap, and so on. (So it's closer to the orginal French 'toilet'.) In American English, "toilet" refers to JUST the physical chair-like thing that flushes. It never refers to the room as a whole. Therefore putting the word "toilet" on the door *does not* mean the same thing as "washroom" or "restroom". It's not just a euphamism thing. In American English, putting the word "toilet" on the door is like labelling it, "crapping chair", and has that level of connotation.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
or better still, have an underlying component object model that exposes the functionality of your system and then have a set of GUI and command-line tools that both use these components. oh, and while you're at it, document and expose these components in such a way as they can easily be used from 3rd-party scripts and programs.
This has the side effect of making any component easily replacable. Since all that matters are the (well documented) interface specifications.
With OSS this is at worst neutral, potentially a huge positive. To a proprietary software company like Microsoft it's a huge negative.
So you have to use a different keypress to cut and paste sometimes. BFD. That happens in Windows too. (It's not ALWAYS CTRL-X,C,V, at about the same rate of occurrance as 'middle button' fails to be the right way to paste in a Unix X app.)
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Thanks. That laugh brightened my day.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Any thoughts?
Simple, take your sweet fucking time.
If anybody asks why you're such a slowpoke, just say you're making extra careful that everything is perfect, so there aren't any problems.
And when you DO know the exact name for it, you'll likely get this result: "Sorry, no results were found."
You have to know the exact MSDN, TechNet, Knowledge base name for what you want, which usually bears little to no resemblance to the designations in the docs, helpfiles, Event Logs or actual filenames. Of course, sometimes if you search on the same thing several times you'll get a result, but don't rerun a successful search! It gets tired and may come back with no results.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
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.
Best described as "crying wolf"...
Sorry, but I think it's you who is missing the point, entirely.
XML and it's derivatives (XML Schema etc.) will offer all those interface 'discovery' features you talk about.
Of course he plugs his company. That is the whole point of the site, to draw people in and get them to notice his wares. Nothing wrong with that.
People may or may not agree with his commentary, but Joel doesn't claim to be something he's not. I didn't find the article to be very anti-unix either. Really, I enjoy reading his articles, not because I agree with everything he says, but because he is a good writer.
He is just a geek like the rest of us with all the limits that go with it.
#6495ED - cornflower blue
It's not a broken anything, except that more and more applications must support "it" (the commonly accepted cut/paste method). It's on the application level, really. If you have KDE apps, and Gnome apps, the vast majority of them support and use Ctrl-X/V/C (as if that's somehow intuitive... it's just the commonly accepted use. I, for one, hate that Cut is one key over from Copy. Too easy to miss).
Right now I copy/paste from Kmail into Gedit all day, every day. Even paste into Jedit quite often from KDE and Gnome apps.
Where's the issue? Modern apps are already playing nice together, at least from a Windows-style Ctrl-X/C/V perspective.
Isn't running a seperate executable and parsing the output the Unix Way??
I'm a windows programmer, but a while back I started using seperate processes more and threads less. Joel (citing RMS) made the same suggestion a few weeks ago on his blog.
The idea is that this will make it easier to port programs *to* Microsoft's system. If the program is then modified to use some Microsoft-thing then you have managed to lock them into your platform.
Yes it's true that non-gui applications will probably be able to be ported back and forth more easily. In my opinion this will *help* Microsoft, as it will remove one of the objections to using their systems in server applications. I do not expect them to copy X11 so there is no problem with all the GUI applications.
More importantly, Microsoft has to do something to defuse the virilant hatred of them that is caused by their gratuitous ignorance and breaking of long-established standards. This is fueling the success of Linux far more than any technical or "freedom" benifits.
You are wrong. In original Unix almost all programs passed the filenames given to them in argv literally to the system. It was up to the shell to "quote" characters. If you said 'cat "foo bar"' it really sent the 7-letter string "foo bar" to the program and it was easier to send this literally than to actually look at it, so almost all programs did the "right" thing. Also if you typed "\*" it sent "*" to the program so it had no trouble with names like this. This scheme actually works quite well, the main problem is that there is no way around it, so a DOS-like "rename *.a *.b" cannot be implemented.
You are correct that "-" was a problem. However all programs that choked on that did work if you used "./-". Again simplicity saved the day, they were just checking argv[i][0]=='-' and thus the easier-to-write program also was easy to get to do the right thing.
Modern programs do choke on unexpected filenames, unfortunately. This is because they accept input and use their own parsers.
Microsoft's POSIX is absolutely useless, because it cannot open all the files on the system, and non-Posix programs cannot open all the files created by the Posix system.
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.
I'm surprised Joel didn't take on some other major differences:
- Monolithic versus small parts
- Just works versus elegant (but might not work)
- GUI-oriented versus service-oriented
- et cetera
Joel is right on the money here, though: there is a major "cultural" difference between Windows and Unix programmers -- my workplace hires both types and they're quite a different group of folks.I'd like to lock the Joel and Eric in a room and see what becomes of it...
I am the Lorvax, I speak for the machines.
You are operating under the assumption that the prompt printing wasn't included in the characters he was talking about. If the discussion is about unix philosophy in general, then the terseness or verbosity of the shell is still part of the same issue even though it's a seperate program. To tell you the program is done at least SOME character has to be sent to the terminal. The fact that it might be the shell that's actually doing it doesn't change that statement.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
It's common in Germany to have "Frauenparkplaetze" (parking lots unter video surveillance reserved for women drivers) to prevent women from being robbed or raped in a parking garage at night.
I never understood why Americans are satisfied with opening only *half* of the window.
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
Yeah thats a good point. There's no room to add comments to the registry even if the programmer wanted to. I have never really needed a man file to read/edit any /etc/*.conf file as it's documentation is right there. Come to think of it, AIX's ODM also hase that issue, but the layout of the ODM is easy enough to understand once you learn the acronyms. I guess the same can be said about the registry except soem programs can put some pretty wacky stuff in their entry.
Gorkman
vmware isn't an emulator, it's a virtual machine, you could run anything under your vmware not just windows. and microsoft uses closed source, which patent holders use to protect their oh so orginal ideas. the problem is that the patent system is abused in this way to stifle competetion, and even you must admit that some of the software patents being granted are idiotic. i have no problem with a company patenting some new idea they have spent millions developing, but it must be just that, a new idea/method and it MUST be very specific and must not hamper other companies already working in the same field. one company closing down 5 others is NOT good for anyone.
If you mod me down, I will become more powerful than you can imagine....
Wrong, in this case you need a script.
things done by you or on your behalf may not be as you expected, or intended.
Unix's fork() and exec() take only the parameters to specify the program. The equivalent Windows API takes 14 parameters ... and most of those have suitable defaults, if you zero out the structure.
// name of executable module // command line string // SD // SD // handle inheritance option // creation flags // new environment block // current directory name // startup information // process information
..., const char *argn,
..., const char *argn,
..., const char *argn,
So let's see what CreateProcess lets you do:
BOOL CreateProcess(
LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation
);
Hmmm... it appears to let you specify the parameters to run the app. In detail. If you leave some out (eg. lpCurrentDirectory), you get a useful default value.
Now, fork() lets you spawn a duplicate. Great! But it doesn't let you specify anything to do with that duplicate - it just spawns, and you have to take the return code from fork and use that to set up your new processes' parameters.
How about exec()?
Welll.... it appears to certainly have plenty of parameters:
exec man page
int execl (const char *path, const char *arg0,
(char *)0);
int execv (const char *path, char *const *argv);
int execle (const char *path, const char *arg0,
(char *)0, const char *envp[]);
int execve (const char *path, char *const *argv, char *const *envp);
int execlp (const char *file, const char *arg0,
(char *)0);
int execvp (const char *file, char *const *argv);
but wait... what's this?
exec, execl, execv, execle, execve, execlp, execvp
Wow! Look at all of these different exec-style() calls!
Not so simple now, is it?
Bitching about CreateProcess being too complicated would appear to mean that you've never had to start up an application in a suspended state so that you can specify the priority it runs at before it starts going. Or you've never had to monitor the processes' completion state by checking its handles. Or you've never wanted it to run with its support libraries and data files in one folder, while using another as its default folder.
In other words, exec() is great for writing CLI apps that don't do much, and are self-contained. But for anything more complicated, you really have to write a hell of a lot more code.
Coming soon - pyrogyra
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.
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.
Take it from a guy who has been where you are before... when you are brought before the grand jury, you will thank your lucky stars you kept a diary. If you're not keeping a diary now, then start one. Learn by watching other people make mistakes.
--
jhw
Just point your browser at Snopes , Urban legends or Wikipedia or just about anywhere on the web to find out what utter bullshit this is.
God, I hate these smug, tedious, sub-"Reader's Digest: It's a funny world", lying little fairy stories.
T&K.
Political language
a good VB programmer won't do that either.. Windows based on COM and COM allows easy component based applicatoin development ie. data access/business logic/GUI layers etc.. as opposed to monolitic systems. a good programmer always will stick to this style. btw, if you take Mozilla development, it is based on XPCOM, which basically adoptation of Win COM on application level. i think there is no strong separation Unix/Win programmers but Good/Bad programmers. I've seen plenty of bad code for win and for unix/linux...
"Windows programmers see the actual data processing as a secondary task that the GUI (and only the GUI) makes happen. Unix programmers see the GUI as a seperate app, which monitors and controls the central data processing app." hm, have you ever programmed for Win? or for Unix?:))
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 :-)
Sounds like the difference between using CreateProcess and using the runtime library exec() functions to me.
You do know that you can use exec functions under windows, don't you?
Coming soon - pyrogyra
Clearing up some biased points.
> 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.
MSDN is free to read online.
If you want the entire MSDN help files on the user's computer pre-installed, they'd need to take up about 2GB+ additional space.
Or if you want to save your bandwidth, you can order a DVD pretty cheap.
> UNIX programmers say: Nonsense! You are a programmer right? Then write a program or API that does what you want.
You need to consider:
1. How much is this going to cost.
2. How much do we really need this.
If it can't be easily done, and it's going to cost quite a bit, or if we can work around it, is rewriting our own drivers the right thing to do?
What if management changed their mind tomorrow and decides we don't really need this piece of code anyway.
Personally, I hardly say something can't be done. But usually something SHOULDN'T be done.
jliu
Apparently Mr. Spolsky does not understand one of the principles of Unix programming: The Rule of Repair. "When you must fail, fail noisily and as soon as possible." When an Unix program can not do its job, it lets you know.
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.
Irritating, isn't it? Sometimes I see a zero activity on the network connection, yet the browser progress bar keeps crawling! "The download continues, don't worry". It insults my intelligence. And sometimes the machine freezes WITH the blinking and moving gadgets, too...
Oh yeah, I'm not just keeping notes I'm sending emails.
CYA can be subtile (that's the mode I'm in now) though I'm willing to crank it up a bit if the point isn't memorable enough.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
on the intuitiveness of Ctrl-X/V/C: X looks like scissors V looks like the nipple at the end of a glue bottle C stands for copy I have no idea whether this is coincidence or not, but I found it interesting when I noticed it.
damn you, html formatting and the lack of an edit option!
The UNIX ones are the runtime library. The only system call is exec. There is a greater distinction between library vs kernel in UNIX. Windows is a different area completely due to things sort of being kernel and library (eg the GUI) as well as the different subsystems, and the not truly documented actual kernel interface.
Other areas are also noteworthy. Providing you pick the right function, automatically launching a document works nicely. You can't actually do that in UNIX. There are a smattering of mime type files and random APIs in each windowing environment (KDE & Gnome), mail readers, news readers etc. IMHO there is no excuse for that!
OTOH things are again inconsistent on Windows. For example I use a help authoring tool. I can invoke it from the command line and ask it to do a complete build and then exit. Amongst other things it invokes the Microsoft Help Compiler. However the help authoring tool then exits. There is no way from the start command to wait on a process and all of its children.
On UNIX, the default would be to wait for the process and all its children. However child processes could detach themselves, and they would have the best knowledge if that is applicable.
Noone stops you creating a "comment" string in the registry that you could read. You can put whatever you like in there.
Well dang, that's about the most useful way I've seen to think about it. :-P
You didn't mention the easy availability of guns, and the murder rate that goes with that, or the war on drugs. (although i guess both could be subsumed into the legal area)
Some days I ride in the font of the commuter train.
Strangely enough, this just gave me an idea -- I'll cross a font design program and a rollercoaster simulator and become rich!
I'm one of the best programmers ever born
Cool. If you don't think it's beneath you, visit the TopCoder Arena sometime, would you?
exactly, so isn't it kinda ironic that most of windows administration (since win2k) is implemented in just this way?
> Windows programmers don't read/write to stdin/stdout because they don't have to.
Actually, if you actually try using stdout on Windows for any significant amount of data, you will find that it is very slow. That's a pretty big discouragement.
"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"
/using/ the computer.
We call this
"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.""
Possibly. However I would guess that most people using their Windows machines to do productive work on don't actually have any opinion about users of *nix. If you forced them to pay attention to a *nix user they'd just think "Gosh, what an odd way to spend time. Now I'd better get on with doing some productive work"
You think "power user" is a compliment. They don't even think of it as a meaningful term. Hence your fury with them.
No, but I have to disagree about the availability of guns causing a high murder rate. Michael Moore looked at this in his film "Bowling for Columbine" and found there are other countries with easy access to guns but no correspondingly high murder rate (Canada in the main example here). Personally I think people (at least adults without a criminal record) should have fairly easy access to guns, and as seen with Canada, this isn't an American-only viewpoint.
However, the high murder rate and the "war on drugs" are definitely good things to criticize America about. But I wouldn't categorize the drug war as being part of the bad legal system which enriches lawyers. Drug offenders usually don't get good lawyers, so I don't see lawyers getting rich off of that. If anything, the "war" helps the growing private prison companies, and it helps the government grow larger and take more tax money while not providing any services in return (except for high crime).
Control X/C/V were choosen because it was decided that it would be extreemly common to need them, so people would learn whatever was choosen, and on a standard keyboard (which back then did not have 101 keys and two control buttons - IIRC it was a mac with one command button) was near the control key. The idea was to make it faster. Those who rarely cut and past will just use the edit menu, those who do it all the time are going for speed so speed should be given at all costs.
Must be pretty lame VB Programmers or you're not telling the whole story. In the windows world you would use a DTS Package to do data transferral which at most will contain a little bit of VBScript.
But for scheduled tasks that need to be done in a gui and command line and DTS cant cut it most VB developers I know would do something like this.
Public Class MyDataProcessor
Public Sub ProcessData()
' do data processing
End Sub
End Class
Public Class frmMain
Inherits System.Windows.Form
Private Sub btnDoProcess_OnClick(Object sender, e as EventArgs) Handles btnDoProcess.OnClick
ProcessData()
End Sub
Public Sub ProcessData()
dim dataProcessor as new MyDataProcessor
dataProcessor.ProcessData()
End Sub
End Class
Public Module Main
Sub Main(args as String())
If args.Length<1 then
dim frm as new frmMain
frm.Show()
Else
'-- Its a command line app launched from NT Task Scheduler frm.ProcessData()
End If
End sub
End Module
Give me a GUI and i'll open an eterm :)
Rohan
Sure, now care to find me ANYWHERE where I can find well written docs? I've worked with a lot of them lately, and not one set, or even all combined explain the important details I need to do. You see I need to know more than how to call foo() correctly, I also need to know when to call foo(), what to call first, and that foo exists so I don't waste my time re-inventing the wheel. (this last is hard because so much already exists that no person can keep track of it all)
I think you just proved the point without meaning to. Everything is layered. I've used most of the above, with just about every combonation of other layers. xemacs works the same no matter if you are running Alpha/FreeBSD/Xfree86/KDE, PPC/Linux/Xfree86/TWM or Sparc/Solaris/XSUN/OLVWM. IT looks very different, but it still works, and if you find a bug in any layer you can switch it out for a different one.
OTOH things are again inconsistent on Windows. For example I use a help authoring tool. I can invoke it from the command line and ask it to do a complete build and then exit. Amongst other things it invokes the Microsoft Help Compiler. However the help authoring tool then exits. There is no way from the start command to wait on a process and all of its children.
It could certainly very easily wait for its children to finish if it was designed to do that.
It wasn't. That's bad design on the application programmer's part.
Coming soon - pyrogyra
Didn't I expressly say that I was not insulting them? I have no fury. They are using the computer to do what they like. Perfectly respectable. No issue whatsoever. My clients are people like that, every day, using their computer as a tool to do their job. I'm quite comfortable with them.
I was referring to those who use Windows and do consider themselves power users, who do consider themselves to be extremely proficient, who are then confronted with another environment in which their seeming expertise and proficiency is utterly useless. Some would see that situation as an opportunity to learn some more and expand their skills. Others, of course, just keep walking and pay no mind. Some, though, have a personality such that they see it as a threat to their concept of themself as a "expert" and then seek to belittle the other.
There are profound differences between the world of *nix and the world of Windows. I'll use myself as an example. I learned computers back in the 80s. A soldering iron was something you used sometimes. I learned to program 8-bit machines with 4k of RAM. I went to college, and graduated in computer science (at a school where it was still a science). I have written operating systems, compilers, programming languages, database systems, so on. For me, the *nix world is like water is to a fish. The *nix world still revolves around people like me. Specifically, people interested in the science of computing, and who see the computer and the operating system as a tool to learn about that science and expand their skills.
The Windows world, however, revolves around customers in a consumer model, using products to solve problems, such as writing a letter or whatever else. A Windows user can become an "expert" in their own mind quite easily, without any truly technical understanding of the operating system, how it works, and other fundamentals. They merely install some products, learn how to tweak some of them in the ways permitted by the vendor, perhaps troubleshoot and solve some issues which your average Windows user could never do. That is a rather low bar technically, but as a Windows user is truly a *user,* it is the bar.
That is not traditionally true in the *nix world. In the *nix world, to be considered an expert by your peers requires a great deal more understanding of fundamentals, more ability to troubleshoot and solve issues than available to the Windows user, some programming skills (whether scripted or compiled), and so on.
The hobbyist Windows expert confronting the Linux expert is generally a very lopsided match. And as I stated before, some personalities see that as a threat and react as such.
I have no intent whatsoever to denigrate the users of Windows. Each to their own. Whatever floats your boat. Now, on the other hand, I do find Windows to be wanting in many ways. But if a Windows user finds thoughtful criticism of their OS to be a personal insult, then they have issues. Ditto for Linux users in the same situation.
Larry
Sounds more than a little like KDE/dcop ... check out this recent article.
They're still popular. I took my Mom to the doctor today. The receptionist had a PC running Windows, with some kind of text-mode app (probably a database) maximized. The cash registers at the grocery store also have a text UI. Footage of an office on the TV news shows cubicles and PCs running text-mode apps. The local library replaced their dumb terminals with PCs running Win95, and the only app running on these PCs is a text-mode terminal program to access the card catalog. The last time I visited my insurance agent, it was the same thing: PC running Windows running nothing more than a terminal emulator.
What a f*cking waste. $1250 PC, 16 or more meg of RAM, fast CPU, money for a Windows seat. All this just to run a text-mode program.
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.
Not for me. I live in the country. No cable, no DSL, and dial-up never goes faster than 26,400 baud. I like text. I think others should too, but they're not given the option.
And no, a program doesn't have to be graphical to be user-friendly. Look up the D-Flat or Turbo Vision text-mode UI libraries.
Imagine: a bunch of OSS developpers hiring a manager to improve their mail client. After a few weeks and a few thousands of $$$, the manager advises them to find a way to execute scripts upon reception on their mail client!
Heh! This would make a lot of sense from a manager's point of view, of course, but 99% of the slashdotters know it's a bad idea. Linux developers have better uses for their meagher resources.
What we need is a standard for things like cut-and-paste, configuration, etc. We can have 100 distributions, 10 toolkits, 5 packagings but we need one kernel to rule them all...
Well 'rule' may not be a happy choice of word for people attached to freedom and progress, but I'm convinced that improving coordination can help a lot.
"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."
This is why I've always hated text-based interfaces - since the first time I had to write a shell based program to do SQL queries on IBM DB2 for my university assignment. The glue between the caller and the program is loosely coupled and not tightly integrated. The input/output is not specific and the front-ends aren't tested to work with all comibinations of stdout output.
Sure, a text-based interface can have a well-defined interfaced using keyvals for in/out, but most CLI writers don't keep strict output formats. These interfaces are flexible and desirable because it allows them to be used in any program(C,C++, Java, Perl, Python, etc) without special bindings.
This is why I like C/C++ APIs - they export a well-defined interface. Only if Perl and Python can call C/C++ APIs without writing Perl XS Modules, Python C API modules, or swig glue, it would be perfect. CORBA solves some of these problems but its too complex. Anyone know of a common-interchangeable communication format? (Don't say XML or I'll shoot you).
Kashif
Swallowed a little too much hype, have we?
XML can't do anything automatically, it has to be told how to permute everything.
If I create an object that pulls data from a database, how do you use XML to tell a spreadsheet that it can get that data from my object? What if I update my object so that it returns new types of data? The only way XML is useful in situations like that is to try and describe a translation from my object's format to EVERY OTHER kind of format that exists. And we all know how well that works.
XML is as much a silver bullet as my ass cheeks.
For serial devices? For GPS devices???? Didn't think so.
What are you trying to cut and paste? I can't paste anything usefull underwindows, except images and some other content that will get embedded into another app (which is not even usefull).
I mean, the power of Cut & Paste is highly overestimated. Linking in PowerPoint or Word from Excel is nice, but how much Cut & Paste does make sense?
Advanced Cut & Paste under Linux is piping streams. Yes, a nice Cut & Paste could be usefull, and is trivial to implement, but nobody did it. It could be as easy as telling a mime type, kind of a n HTTP header, for data. But if nobody does it, it may be well because it's not so needed.
In fact, I'm I tended to hate X style coping, but now, having gone BACK to Windows (work mandated, an Windows is quite usefull for many office tasks) I tend to miss simplicity in Cut & Paste. It's not really only CP, but everything. In general, the notion that under Windows, in not on charge. For example, I am using PivotTable reports. And I know SQL and how to tabulate myself, but the pivottable insists on limiting me to the GUI. I can't see the SQL query no matter what. And because of having used the rel thing (SQL), I can know I am not able to perform many needed and simple things. I wouldn't know them otherwise. Not only that, but the tools I have to use are now based on non normaliced tables, because crosstabbing is so easy , and the windows DB guys here don't even notice how ugly and future-limiting everything is.
Windows forces you unnoticeably into doing things the worng way, and you start to think many things cannot be accomplished...there's no "application for that". But you will never know how most things are if you've never gotten away from theGUI centric view. Playing with Linux for a year can make you view things differently. You will never know what you are missing otherwise.
unfinished: (adj.)
Not quite. You don't get the stability and security, or even the scalability of Unix/Linux. Nor do you get the scriptability.
Kinda like putting a Corvette steering wheel, along with the emblems and shifter onto a Ford Escort. It's still a Ford Escort.
Or like putting a giant wing, a fart can, and a bunch of stickers on your little old Civic. it still isn't a sports car.
My Suburban burns less gasoline than your Prius.
but the one thing the parent poster would settle for would be easy to set themes. If a uses wants, then he/her should easily be able to make the programs follow one them based on skins. these can be made by the user so it would be the best.
Open Source Sushi
I don't think it's being fair to Unix-based operating systems to imply that they're playing catch-up on the desktop. (I know you haven't said it, but that's how your comment reads to me.) To a certain extent KDE and Gnome are, but they don't cover everything.
One of the main reasons that I run Linux on my desktop PC is that I don't really like Windows on the desktop. You're effectively locked into Microsoft's idea of a good UI, which for a variety of reasons I don't like. (Both their UI design and their lock-in.)
By running Linux, I get to choose from a much wider variety of UI's. Personally, I choose WindowMaker.
From a UI perspective, I tend to think that allowing for too much choice and configuration about how things work is a bad thing. But on the other hand, I'd rather be able to choose than be forced to use somebody else's bad design.
X11 is a specific application protocol. For that particular application, a binary protocol make sense. It doesn't belong in this discussion.rpc/portmap has little actual use outside of NFS. I place it into the category of application-specific protocols.
DCOP and Bonobo (which is just Corba, you know) are current desktop environments' attempts at copying the Microsoft/Apple architectures. They are not proven, and I doubt they get the same kind of interoperability plain text interfaces do.
Plain text interfaces are at the core of most of the +2000 binaries I have sitting in /usr/bin. The fact of the matter is that all of these are self-documented, and all of these are pieces for me to use as a developer -- even when developing small, one shot, shell commands. This kind of power was never available to Microsoft OS users, and will probably never be.
PS: And, naturally 'cat /dev/sda1' does not produce text. It could never produce text. When people run out of arguments, they start nitpicking on details...
If at first you don't succeed, skydiving is not for you
Logistics, man. If it can be physically completed by one man in two weeks, it is a small project. No two ways about it. You are doing trivial work, and you've planned your career to do trivial work.
Does my bum look big in this?
In short, GUIs are great browsing, when you don't know exactly where you are/want to go, the commandline is better when you know what you want to do.
Ah thankyou for explaining that. Here in Australia we tend to use a mixture of the "proper" British english for mostly historical reasons, plus the perverted US english propogated by their gargantuan media machine. It can be terribly confusing sometimes when dealing with brits or yanks since we're somewhere in the middle.
For example, in school we used the terms "eraser" and "rubber" almost interchangeably. Only later did we learn the slang meaning of "rubber" to also refer to condoms. And only recently I saw a US stand-up comedian on TV talking about a trip to the UK and what these two words mean in each country. It turns out that "eraser" is the US term, while "rubber" means condom in the US but means eraser in the UK. Ah, you learn something new each day!
Since DOS already had used slashes for switches, and the command parse routine was not based on space characters like unix shells are (for example, in DOS you can do cd\ or cd.. which does not work in bash) they had to use a different slash when they implemented hierarchical file storage (aka directory structure). Kapiche?
As an old DEC hand you'll remember that VAX and PDP commands all used the tparse routine (which was available to user programs too) to parse command lines, and tparse allowed abbreviation and switch position independence while avoiding the more undesireable effects of shell pre-processing.
But the real advantage of the DEC systems was version numbering. Anyone who ever programmed for any length of time on a VMS system understands how inexpressibly primitive and lame filesystems without version numbers are.
Yup, I believe that claim is correct. People forget that VMS was much more advanced than unix (though linux is going to surpass it pretty soon) for native english speakers. Linus Torvalds hated it, and I suspect this is because at the time his english really sucked (no longer true).
I've just made something you might find interesting in the men's room, and I left the toilet unflushed for your dining pleasure.
I have a vax in my basement, but I haven't turned it on recently. It's a salvaged Alpha that I converted from Saint/OSF-1 to VMS (hobbyist edition, which is free for home use). But my VMS skillz are pretty rusty I think, I can't remember all the QIO parms anymore.
The last time I used a VMS system professionally was in the 90s (unless you count systems that I don't personally admin, in which case it was a week or so ago.)
I see your point, but I'd argue that a well constructed program can be trivially reconfigured to be in a new location.
For example, I built Infozip's unzip facilities for unix on an HP-UX box yesterday, and I had to change one line in one file (the prefix setting in the makefile) to put it exactly where I wanted it. Took less than five minutes all told (with no prior knowledge of the software) so recompiling it for a new location would be extremely trivial.
I'm not saying that your statement Fundamentally programs should not care where their physical storage is, only where it is in the namespace. is incorrect, but I think it's more a matter of preference related to the type of programs you write. For a word processor, OK, I see you'd want hardware abstraction. For a program that exercises the hardware to the extremes of its physical limitations (for example, a program to test solid fuel rocket motors) you can't afford the overhead, it's too inefficient to have opaque software layers between you and the circuitry.
I'd like to be able to write any sort of program, so I prefer exposed structures and I'm willing to do the extra work if I'm going to write an end-user app. Which I almost never do, incidentally, I'm usually a plumber not a painter.
You ARE a PM! Or do you prefer PHB?
I make businesses better. I do process reengineering and technology implementation. My work has saved companies millions of dollars per month. My work has people finishing their main task in 2 hours instead of 12 hours, so they can be more productive and pick up their children from school rather than just watch them sleep. I have had a positive effect on people and companies, and I plan to continue.
If you call all that "trivial", I cannot imagine what you consider important.
---
[WARNING: Bragging follows.]
Now about man-months:
1 great programmer = 20 good programmers
1 good programmer = 10 average programmers
Time required for a project = (Time for one programmer to complete it) ^ (number of programmers assigned)
- One programmer is more efficient than 2 programmers. With 3 programmers, projects take so long that they may fail. 4 or more almost guarantees failure.
If a project cannot be completed by one good programmer in 6 months, it is designed wrong.
I design applications in my head before the business people have decided what they think they want. I write code 3 to 10 times faster than anybody my colleagues know. My code is more efficient (less LOC) so it is easier to test. I unit-test as I go, and reuse proven code, so beta testing is almost a formality. (I do get upset when clients say, "The last 5 applications worked perfectly, so why do we need to test this one?") I work on the best RAD platform ever created for business applications, and I know more about the platform than the people who write it (by their own admisssion.)
Your typical project:
2 months specification gathering and approval
1 week designing major functionality and assigning responsibility
2 months initial programming
1 month integration of each person's work
Oops! Specifications changed | design was bad/unscalable/does not fulfill needs | someone did not write the same API that someone else planned to use | Integration with backends needs rewrite.
Repeat "design - code - integrate" until project seems to work or the money is gone.
My typical project:
"Show me what you do now."
"Thanks. I'll have something for you to try next week."
[Then a miracle occurs]
"So... Can you talk with that smile or is it stuck?"
(If you want to use the word "trivial", what do you call the corporate application development department that can be replaced by having me work part-time?)
I spend my life entertaining my brain.
From the Slashdot grammar police: credit where it's due. Your well crafted, balanced and insightful sentence was much appreciated.
Now, back to work educating posters about "it's" and "it was done wrongly" etc.
Aegilops
You are just proving my point. God, I hate this attitude so much.
USER: "I need to cut and paste."
SLASHDOT POSTER: "Why do you need to cut and paste? You shouldn't cut and paste. Write a script and pipe your output to stdout."
USER: "I'm sorry, but I'm going to have to shoot you now." [shoots slashdot poster]
If you want people to use programs you develop, one of the most important steps is the part where you shut the hell up and actually LISTEN to what people want.
It's not a part of any reasonable development process to tell the user that they should find a stupider, more complicated way of doing what they want. That, fferreres, is what you are doing.
I really loved your comment. It made me laugh, I've never seen anyone be so blase.
So you're a consultant. Everything you do is perfect. You never get ill. Your family never gets ill. You're [whoever your next prospective customer is]'s personal saviour. You save billions of dollar every day. You leap tall buildings in a single bound. You promise the world, and always deliver! You're worth every penny you charge. You've never been on a project for more than a couple of weeks. You've never had to integrate it to more than one or two things. You've never had to renovate it because the thing you integrated against changed and broke your app. You can ditch anything you don't like, because it's your way or the highway. Those pesky customers only think they know what they want, but you know best! You've never heard of maintenance. You use a Rapid Application dev tool to crank out Rapid Applications. This tool only does what it was explicitly designed to do for you, other people just couldn't get the tool to do exactly what it was designed for. You know this tool better than the people who wrote it, like a secretary knows MS Word better than Microsoft!
You've also skim-read The Mythical Man-Month.
Lotus Notes didn't become what it is today by telling consultants and RAD monkeys how to do their jobs, then giving them whatever one coder could crank out in one week to do it with. The Lotus programmers didn't have an RRD (Rapid RAD Development) toolkit to write 99.999% of Lotus Notes for them. It took them more than 6 months, and it would have taken any team, even a team of great coders or even a single great coder, more than 6 months to write.
Because you only write trivial apps, you assume that every possible programming task must have a 4th Generation Language to really ramp down the complexity of software. But there isn't. Some things are trivial, some trivial things can be made to seem complex, some things really are complex, and to pretend that they aren't leads only to failure.
Once you stop writing web/UI frontends to databases and start writing complex software, you realise just how alone you are -- there are very few tools to help you write things. You cling to everything you can get -- libraries, editors, parser-generators, refactoring tools, etc., but there comes a point where what is needed hasn't been written by anyone, ever. You have to write it, and you haven't written anything like it before. You don't have a single line of well-written, well-tested stock of library code to help you.
If a project cannot be completed by one good programmer in 6 months, it is designed wrong.
This one I'll have to quote around the office. It's the height of naivety. When you start writing full featured 50Kb implementations of Brazillian ISUP that can handle 40 calls/s volume on a 150MHz 604e, I'll be impressed. I'll be even more impressed when, 6 months after release, you work out that "foo = bar" should have been "foo = baz", when some other vendor's equipment uses different values for bar and baz in their packets, which your own equipment doesn't, then you write a 20 byte binary patch (in machine code) rather than use the patching tool which makes a patch that has to replace the entire 2Kb function.
Oh, and yes, Brazillian ISUP can easily be done in 6 months. As can any ISUP. But not ALL of them by the SAME people. And that's the point. To write 20 ISUPs from scratch and integrate them all into the same 6 month release, and test them all, that takes an incredible effort. You can't even think bigger than a single sub-component written by a single person in a tool designed to make it easy. That's what I call trivial.
Does my bum look big in this?
If you rephrased your post to use "consultants" rather than "you", you would have been more accurate. I have seen examples of what you describe. I do not believe that I fit that mold, but I could not live with myself if I believed I was.
I do try to be humorous. I am glad I was able to make you laugh. PMs often have that attitude. Then they try to hire me full-time so they can continue to receive the benefits of my presence.
- I promise the world, and always deliver!
- I'm worth at least three times what is charged for my time.
- I've been on projects for 4 years. 6 years ago, I did maintenance on a project I had written 7 years earlier.
- I had to integrate DB2 and SAP and a PBX into one system. I've had to integrate the entire internet into another system.
- I maintain many of my apps. You can blame the limited time required for this on skill or luck. I tend to make everything configurable.
- I am forced to work with tons of systems that I do not like, because I am only a consultant and cannot touch anything that was not placed under my responsibility.
- People rarely know what they want. I deliver apps that solve their issues. Sometimes they require that I stick to specifications, that rarely lasts through the project because either my ideas are really good, or I have mind control abilities and force them to my will. (You pick.)
- Maintenance is when you get repeat business on the same application. It means that I have failed to anticipate something, usually because to do so would have greatly increased the cost for little benefit during the original development. (Can I charge just in case they change from MSSQL to DB2, and from terminals to a web UI?)
- I use Lotus Notes to rapidly build business applications. I regularly make it do things that Lotus continues to define as impossible. I do not know if there are any real programmers working in this domain; you can read my rants about how Notes Developers are the most untrained group in the computer world. Lotus tried to hire me because "I know more about every area of the product than anybody except the person who wrote that specific code." IBM has said that my "Notes expertise exceeds ours."
- I read The Mythical Man-Month, but it was a decade ago. I remember it being very humorous, but it did describe how many PMs think (which I also find humorous.)
Lotus Notes is a platform. Platforms are not applications. Platforms are very generic to allow applications to be built on top of them. Platforms require planned architecture and tons of integration to be useful. Platforms do not know what data will be stored, so must have a flexible structure. A platform will always take many times the effort as a single application. In easy terms, adding two numbers together takes a moment. Building a calculator that handles input of two numbers and adds them together takes much longer.
Applications are very specific. I know what back-ends to integrate. I know what data is to be stored. I know what UIs are needed. An application has very limited scope, which makes them much easier to write and test.
Lotus Notes has become a great platform because they listened when consultants and RAD monkeys told Lotus what they needed to do their job. I believe the initial work was done by a very small team over 2 years.
I am building a new platform. I have easily put a year's worth of time into it. It stalled because I based it on Lotus Notes, and Lotus Notes has a few major flaws that keep my platform from being production-worthy. Their stated work-arounds will not work for a new platform, although they might work for applications. I will be writing a replacement for the Notes portion next year. I expect it to take me 1 year to be usable, and then I will hire others for expertise in performance-tuning an SQL engine and a few other things.
Pick your example better. Maybe use a statement like "Word Processors cannot be written by one person working for 6 months," except I
I spend my life entertaining my brain.
DEVELOPER: "Here's our GUI! Enjoy!" USER: "Wow, thanks! This sure is pretty. So, how do I cut and paste?" DEVELOPER: "Select to copy, middle-click to paste" USER: "Oh, that works 99% of the time. Why are there exceptions?" DEVELOPER: "We were trying to make it more like Windows" USER: "Fair enough"
cat /dev/sda1 | cdrecord
/dev/sda1 | cdrecord
You think so, huh?
% cdrecord -version
Cdrecord 1.10 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jorg Schilling
% cat
cdrecord: No tracks specified. Need at least one.
cdrecord: Usage: cdrecord [options] track1...trackn
Corba isn't an Unix protocol.
/usr/bin.
/usr/bin contradicts that viewpoint. But let's assume it's true for your personal computer.
/usr/bin much like your own.
So 20 years ago, back when Sun was inventing Corba, they weren't a Unix company?
Your belief is just evidence that Windows developers tend to be Microsoft blinded and impervious to technologies from places other than Redmond.
Your belief is just evidence that Windows haters tend to be Microsoft blinded and assume every technology they don't approve of came from Redmond.
And, no belief I might hold could supply you any data about Windows developers.
X11 is a specific application protocol.
How can a "specific application protocol" be used by 8,000,000 different applications so far (and rising)?
For that particular application, a binary protocol make sense. It doesn't belong in this discussion.
If this was a discussion, it would absolutely belong. You have claimed that text-based interfaces are best for applications. Counter examples are entirely appropriate. (But unnecessary, since the own programs you demonstrated are already counterexamples)
even when developing small, one shot, shell commands.
s/even/only
Plain text interfaces are at the core of most of the +2000 binaries I have sitting in
I doubt that's true. A view of the 3151 files in my own
Which Unix applications get the most use?
Maybe apache, mozilla (or anything using X11), gcc (or any compiler), emacs (or anything using curses), oracle (or anything based on SQL), sshd (or any daemon).
None of those have "self documenting plain text interfaces" at their core. (Well, emacs does, but not via stdin/stdout)
This kind of power was never available to Microsoft OS users, and will probably never be.
Past: Microsoft sold the Xenix OS, which contained a
Present: Microsoft users can download cygwin if they want to. They rarely want to.
Future: WSH, etc.
When people run out of arguments, they start nitpicking on details...
I didn't even bother to argue, since you'd already been contradicting yourself.
Sorry for the typo.
If at first you don't succeed, skydiving is not for you
I restate that Windows developers tend to blindly follow whatever is dictated by Microsoft and be impervious to other technologies. People working on more mixed environments tend to search and evaluate the best solution for any given job. This dictatorship goes well against my gut feelings (i.e. it smells).
I also restate that X11 is a specific application protocol. Not in the sense of a final user application, but in the sense of being applied to a single problem -- remotely displaying computer interfaces. It's not a generic glue protocol, like Corba, (D)COM(+) or piped plain text. It does not belong in this discussion.
I'd wager it's the likes of ls, grep, sort, sed, awk, tar or uniq, not Apache, mozilla or any other big application. I don't have any numbers, however.And just a note: Some of the apps you mentioned do very usefull work if stuffed in a pipeline via stdin/stdout, namely gcc or emacs (although for this purpose, sed or awk are easier to use), and I very regularly use ssh in a pipeline to do simple backups (e.g. ssh somehost "tar czvf - importantdir" > backup.`date --iso-8601`.tgz ). Your lack of knowledge is probably the reason for the poor evaluation of the importance of common, simple, well documented interfaces on every application. Do yourself a favor. Go and read the book mentioned in the article.
If at first you don't succeed, skydiving is not for you
I'd wager it's the likes of ls, grep, sort, sed, awk, tar or uniq, not Apache, mozilla or any other big application. I don't have any numbers, however.
You're wagering wrong. Whether counted in total CPU cycles, time the user spends with it, or just overall importance, big apps win big. The only way small commands could win is if you count the number of times they're invoked, which means nothing (indeed, it inverts the refrain that "uptime is good"). The whole reason that Unix has survived for decades is the power of the server daemons it can run. Small commands that pipe together is a convenience for the power user and the script author, but is not what allowed that OS-family to survive.
How did the fact of being invented by a Unix company brand Corba as a Unix protocol?
If you can't even figure that out, I'm afraid I can't help you. (Hint: why do you call stdin/stdout/stderr a Unix protocol, when other environments implement it too?)
I restate that Windows developers tend to blindly follow whatever is dictated by Microsoft and be impervious to other technologies.
There you go, bringing up Windows(r) developers again. When did Windows have anything to do with it? You seem to be impervious to the idea of IPC mechanisms beyond anonymous pipes (and think only a Microsoftie could want such a thing).
Your lack of knowledge is probably the reason for the poor evaluation of the importance of common, simple, well documented interfaces on every application.
This is hilarious. You've somehow decided that I lack knowledge, when I repeatedly point out syntax errors in your own commands. (For example, you forgot not only that cdrecord needs "-" as a filename before it listens to stdin, but also that the dev and speed commandline options are mandatory)
You're typing at someone who's been a C programmer for 15 years, who hasn't ran a Microsoft OS since 1998, and who runs Linux both at home and work. I would seriously have no idea how to create a CD with xcdroast or WindowsXP explorer, but punch in mkisofs -rJ dir|cdrecord dev=1,0,0 speed=4 - whenever the need arises. I also ran ssh -lmyname host cat files.tar.bz2|tar jxv just the other day.
I am violently anti-Microsoft and pro-Linux. But far above that, I value the truth.
Bold pronouncements that are flatly wrong just make you look simpleminded (or closeminded, depending). Mischaracterization of text-based interfaces (both exaggerating it's benefits, and slandering the alternatives) does nothing to promote better software in the future.
Childs need parent guidance. When you get to grow alder, you can do whatever you want of course. Now, I am not saying I am anyone's parent. But the reality s I have tryed cut & paste under Windows, and then undex X, and found X not to be good. But then, I learned to CONNECT stuff in interested ways that can be automated easily, and everything makes sense. Now I know cut & paste most important feature is good to avoid typing resources, text and images.
And while I enjoy C&P under Windows, I am unable to do most of the important stuff. I can get something easy done really easy, but something a bit more complex is imposible, or just takes a LOT of C7P that should be automated.
Now, I don't know, I think you reason differently when you get used to unix likes, and you get to appreaciate C&P is nice but limited and teaches how to do many things the worng way.
Anyway, keep your ideas and discard other people ones. You'll progress like hell for sure.
unfinished: (adj.)
Thanks for your reply. My view is that, as organisations commit increasing amounts of their business logic to silicon, a kind of Darwin principle kicks in. Those who adapt slowly, badly or expensively to IT issues will not prosper. Windows culture programmers allow a firm to adapt quickly but badly. UNIX culture programmers allow a firm to adapt slowly but well. So it's a trade-off between quality (UNIX) and speed (Windows). If they are weighted equally, there will be a running battle about which is best, and the decision boils down to who is the cheapest. That's the debate - you can do it in Windows or UNIX, so what costs the least? I think that depends on the application somewhat. Where the application is a business system, the cost of failure might mean anything from losing a bag of nails to loosing sales. VB programmers might get this job. Where the application is a air traffic or spacecraft control system, the cost of failure might mean hundreds of lives or billions of dollars. In this case, system quality is the main driver, and VB programmers are not really in the running on these jobs, at least for some of the application space.
I stole this
If your choice of a highly customizable UI only affects you, then feel free. But for most of us, user interfaces are not a private thing. We create, test, document, and provide training for software that people use. All of which becomes much more difficult and expensive if we have no UI standards.
Everybody has to make compromises. I certainly would never use Windows at all if I had an absolutely free choice. But as it is, I use it between 60% and 95% of the time. The desktop I admire the most is Englightenment -- but I never use it, because it simply isn't practical me to make the necessary mental retooling. I could go on, but you get the idea.
It's a pity you can't always do things precisely the way you want. But none of us can, and it's childish to whine about every compromise you have to make.
and since your'e AC, mom, go and re-read "A Guide to Usability" by Jenny Preece. the paperback isn't even 150 pages, and it has funny cartoons. </snarky>
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
What does a "software engineer" do?
What do you need to learn to become a "software architect"?
I have been called many names. The technology-related ones include application design and programming titles such as "business analyst", "visionary", "application designer", "developer", "programmer", "senior programmer", "team leader", and "project manager". I also work on the administration side: originally as "support", then "administrator", now as "architect" of global networks. I prefer titles that suggest technical abilities rather than the ones that suggest managerial abilities, especially since about half the "project managers" I have met have little talent for managing people. Today I just use "technology consultant".
I loved C, but wished it had a few more capabilities that seemed obvious to me. Then C++ became available and fulfilled my dreams. Then MSWindows3.0 became the platform of choice for clients; I read the awful API specifications and fled the industry. The disadvantage with C and C++ is that the common functions are made to allow damage, so if I do not keep the knowledge current, I will write really bad code. I had the experience; I knew most of the pitfalls; I know they are dangerous, and I do not want to take the time to relearn them. So now I write Java, which does not require worrying about memory leaks in every line of code.
You already have Lotus Notes, the database and the GUI (i.e. Windows) written for you. You buy in graphics rather than draw them yourself. You don't need to write 99.9% of what you actually deliver.
That is the good thing! I focus on delivering applications that solve business requirements using interfaces that shift the entire paradigm of the worker and result in magnitudes of productivity improvement. And my apps cost less too!
Why would any engineer not use all available tools?
When designing a bridge, do you reinvent geometry and algebra? Or just define what is necessary to efficiently build a structure to handle the volume of traffic that will cross this chasm? Do you expect your builders to build a forge and mine the ore, or do you order steel beams from a company that specializes in making steel beams? Most of the computer platforms are still building with wood, and the programmers are doing a great job with hammers. Meanwhile I am using powertools...
- And paying a contractor to paint the structure. I do build my own graphics for prototypes. But I know a few incredible graphic artists. They can do in hours what would take me a week, and the result is more professional/impressive. And they charge less than 1/5th my rate. So I pay them to add the professional appearance. Tell me how this is bad business.
That's fine by me, but don't scoff at people who absolutely have to write 50% or even more of what they deliver. And don't scoff at them because they don't cut corners to make themselves look good.
I do not mock the programmers who have to rebuild that 99.9% of what is required every time, although I wonder about calling them programmers. Programmers should have the engineering mind and do have the perfect domain for using it. "Build it once and reuse it."
I do laugh at the business people who are paying those programmers to work on inefficient platforms. They are the ones wasting money when it is their job to protect that money.
I do not cut corners. I make everything fantastic, and am anal about making code perfect. My applications always have features that were not in the specs. Every one of my applications has some feature where the customer goes "That is great. It seems obvious. Why doesn't everyone do it that way?"
A PM told me I was stealing, because either the customer paid for more or less than was delivered, and the consulting house was losing business for expanding the application. I prefer "customer loyalty through great products" over "repeat business due to poor design", and none of my projects ever went ove
I spend my life entertaining my brain.