Slashdot Mirror
Culture of UNIX and Windows Programmers
bebonzo writes "Joel Spolsky, 'Joel on Software' has an interesting review of Eric S. Raymond's book about 'The Art of UNIX programming'.
Quote:"What are the cultural differences between Unix and Windows programmers? There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers."
About slashdot: "slashdot-karma-whoring sectarianism..."" He's harsh on some points, but pretty on the money. Except about us. Nobody karma whores. Update Note to self, never post before coffee. Yes, its a dupe. get over it.
Is not about the command line or GUI.
It is that Microsoft's own development teams have always programmed with inside knowledge of the OS, able to bypass the official API whenever necessary.
This was explained to me by the director of a large bank in Brussels that abandoned a huge Windows-based project after finding that COM+ and MSMQ could not talk to each other, and this after spending time with the actual developers at Microsoft to resolve the issues.
Each Microsoft application is written "to the metal", reimplementing huge pieces of code that should be abstracted into layers.
Many of the security issues in Windows software stem from this design model: a typical Linux security issue can be fixed by a single patch in one layer, but typical Windows security issues reappear in application after application.
And this is where the Unix model is strong: it is all about layers, formal documented interfaces, and clean separation. When Microsoft decided to add MSIE to the operating system, they were not just screwing their competitors, they were setting themselves up for a fall.
Good software must be built in layers, with formal and definite separation between layers. Microsoft is learning this now, mainly because it simply cannot make its current designs secure.
Ceci n'est pas une signature
CmdrTaco et al need some sort of CVS on submitted newsposts. Check-out a selected submission, nobody else can touch it. With some work and the tying in of keywords, it could also be a dupe-submission checker of sorts.
Yes. Service Packs rule. They need to be tested first, at least for critical server apps, but overall, the long march of Windows Service Packs has been an improvement. I've worked on quite a few hybrid Linix/Windows apps. Usually client server. Guess which platform the client runs on? Deploying Windows apps with PostgreSQL connectivity via ODBC is a breeze. Much easier than deploying Oracle client apps. There are _many_ ways of doing most things in Windows land. It all depends on the experience level of the programmer and IMAGINATION. I would say imagination is a huge part of coding, one that is often overlooked.
Is this sig nificant?
Right time to burn karma by saying that I primarily program Windows using MSVC (I love the smell of flmaebaiting myself in the afternoon).
There are several other differences that I have come across in IMHO (or more my humble experience) between Win32 and UNIX programming.
The first of the these is Hungrain notation which was dervied from MS coding. For those not in the know this is the naming of attributes and variables such that the name reflects its type. Over the years I've come to see several forms of this but the simplest and most useful is to prefix the name to note where the variable is declared.
i.e. g_X - denotes global
m_X - denotes class attribute
c_X - denotes constant variable
X - local variable.
Thus when reading through code using this notation it is easy to see where variables come from.
I've found the use of this notation common in Win32 programming but not in UNIX programming.
(OK - this is the point where I get crusified by the counter examples and the points that alot of UNIX code is written in C not C++ where this notiation is only applicable)
I definately agree with the article in that a good deal of UNIX work is aimed at CLI interfaces where as the Win32 tools are designed for the end user.
But in talking to other programs for Win32 there is the use of DLL's and COM interfaces. Or in short fixed APIs are used when programmers want to talk to other programs.
From my point of view as Win32 coder a final product is usually being aimed at someone who is not programmer. If the software is not functional and easy to use and intuitive then it really ain't going to cut it. Now if I want to expose my product so it can be expanded upon I will present a programmable, simple and documented API.
Actually, given the size and number of their APIs, I think MS has done a pretty good job of maintaining compatibility -- at least until DOT.NET came along. There is a bit of a leap there ;-) The MS Newsgroups are a huge reservoir for support. The most grief I ever had with Windows was a database app written in the early days of ADO. It was buggy as hell, but there were work-arounds for almost everything. Every subsequent release of the MDAC since 2.1 has provided increased stability, functionality and performance. And my old apps continue to work just fine. Maybe I was just lucky?
Is this sig nificant?