Slashdot Mirror

Joel had an interesting article recently entitled How Microsoft Lost the API War. He is arguing that a lot of Microsoft's past success had to do with there philosophy of never, ever breaking backward compatibility. However, recently they started to break backward compatibility (especially for developers), arguing that the new frameworks would be better, faster, more elegant, etc. Granted, most of the issues mentioned in the article relate to security (yes, I read it), but this may still be indicative for a new direction Microsoft is taking.

Joel had an interesting article recently entitled How Microsoft Lost the API War. He is arguing that a lot of Microsoft's past success had to do with there philosophy of never, ever breaking backward compatibility. However, recently they started to break backward compatibility (especially for developers), arguing that the new frameworks would be better, faster, more elegant, etc. Granted, most of the issues mentioned in the article relate to security (yes, I read it), but this may still be indicative for a new direction Microsoft is taking.

One point to think of, regarding "How many of you Slashdotters have used the backwards compatibility on Playstation 2's" is that, well, actually making use of PS2's backwards compatibility is most likely quite rare, but when it was a *new* console it meant that the console immediately had 100x the games of any competitor.

I've had good experience with a friend who owns only a PS2, and she likes to play a lot of PS1 games as well (namely Final Fantasy series 7, 5 and 1-2-3)

Breaking backwards compatibility seems to be in line with the previous slashdot article on M$ losing the API war

Microsoft grew up during the 1980s and 1990s, when the growth in personal computers was so dramatic that every year there were more new computers sold than the entire installed base. That meant that if you made a product that only worked on new computers, within a year or two it could take over the world even if nobody switched to your product. [...] So in many ways Microsoft never needed to learn how to get an installed base to switch from product N to product N+1.

this Article "How Microsoft Lost the API War" by Joel Spolsky, really goes into detail on how and why this happened. Definitely a MUST READ.

Robert

"It runs on windows" is what has made microsoft. Developer lock in to the win API is needed. So yes, development tools will continue to improve as long as developers may be tempted to move to another OS.

--------------

I completely disagree. Rewriting an application from scratch is the worst thing you could possibly do. This is how Microsoft beat Netscape in the first place, remember? It's a key concept of software design. If you have something that works, build on it. You can argue all you want that IE isn't all that great. And you're right. But, it's still a whole lot better then starting from scratch.

Joel Joel Spolsky (Joel On Software) has an excellent article on this topic that I'd recommend any coder-types reading. It's from way back in 2000 but I find I just keep pointing this gem out over and over.

Here's a link for you. Things You Should Never Do, Part I

You're making Microsoft's argument in this debate of "UI vs. API"; the other side would be exemplified in Joel Spolsky's recent article on Microsoft and .NET; his argument is that it's browser-based apps that are going to predominate, not rich UI applications. With web applications, one doesn't have to install the .NET framework to use a web application; all you have to do is open your browser and enter the URL. The Longhorn UI is going to have to be really compelling to get people to buy into a software "upgrade" (which will probably require a hardware upgrade).

Well, in that case C# comes from VB too.

You wouldn't be the first to suggest that. To wit, see Joel Spolsky's column, as found on Slashdot yesterday:

And along came .NET. This was a grand project, the super-duper unifying project to clean up the whole mess once and for all. It would have memory management, of course. It would still have Visual Basic, but it would gain a new language, one which is in spirit virtually the same as Visual Basic but with the C-like syntax of curly braces and semicolons. And best of all, the new Visual Basic/C hybrid would be called Visual C#, so you would not have to tell anyone you were a "Basic" programmer any more.

The latest joelonsoftware column discusses why it's not in Microsoft's interest to update IE.

Down near the end of this usenet post I wrote last month I talk about how the W3C has been a disappointment lately. Many of the specs I see from them are written for computer parsers, not humans. This is far different from the specs back in the heyday of Web growth. Lately it feels like following the W3C is like following a bureaucracy. It used to feel like I was having a conversation with fellow developers, people who were really into building Web sites and wanted to provide good, standardized ways to do more.

The bottom line is that if this new group can produce more developer-friendly documents that better address real-world problems, then I will support it. If they can get the KHTML team on board, then that's a huge bonus. Trying to do more within the realm of what already exists (rather than scrapping the old and starting again) is the right thing. It's refactoring. It's smart.

I think they eat their own dogfood. That's a pretty good reason for them to upgrade.

I think we're ALL looking forward to that shift in the tides. :-)

"It all boils down the the fact that I can't seem to write a decent resume to save my life."

Seriously, check out some resumé services. Short of the "Never Lie" Rule, everything else is just formatting. We devour folks who claim C++ as an area of expertise but who then can't scribble down a simple class on a scrap of paper during the interview.

Here's a useful diatribe on resumés. That Joel guy gets a bit zealous at times, but often has a decent perspective to consider.

Here's another discussion on resumés. Same Joel guy, but it's a forum on his company's site. Just the tip of the proverbial iceberg.

Best of luck!

Actually IMHO java exceptions seem to be the one thing that keeps it from working in large projects. (that and speed, but speed has been mostly dealt with).
The 'Horribly Twisted Hack on C" as you call it seems to be infinitely easier to maintain in large projects. Exception handling works like magic in college level applications but as soon as you get into larger applications it begins to break down maintainability and readability. That is if the programmers have not already decided to catch all and simply ignore them.

Exceptions.
1. Seperates errors from error handling. Great for modular small project. Shit for maintaining a large program with many modules. Impossible to debug without complete knowledge of the code, and perfect error messages. (NOTE: programmers rarely comment or include useful error messages in exceptions.)

2. Slow, hog processor and resources, This makes them basically useless in real code for anything but fatal or near fatal error conditions.

3. Useless Complexity!
Compare the C code
if (NULL) {
printf(GetError());
assert(false);
}

with a standard java exception block. Try it with an exception block which processes 4 different error messages. 20 times the length (I will not post it here, if you have seen one you know.

Now remember that this: It, adds NO end user functionality, takes time to program where end user functionality is not being added, Must be maintained with every library/version change, and may never actually be called or tested.

The C version has none of these problems and solves the problem quite eloquently. That is it returns an error if the function doesn't work as intended. The programmer can then debug it.

4. Want to modify a library and add an exception condition? How do you feel about updateing every class in your entire project which uses that library?

4. Want to include a large 3rd party library? They probably hacked around these problems in their own way. A way which breaks or eats all of your exceptions when in use.

etc. etc.
here are some articles which put it more eloquently

http://www.artima.com/intv/handcuffs.html

http://www.joelonsoftware.com/items/2003/10/13.htm l

This may seem a surprising thing to do, but in fact it makes good sense to commoditize the products that complement your own. For IBM, a hardware vendor, that's the OS. For Microsoft, an OS vendor, that's hardware.

For the last twenty years, Microsoft has been extraordinarily successful in commoditizing PC hardware. This has not been good news for IBM (though most of IBM's problems over that time have more to do with a misperception of where the market was going). Now IBM is turning the tables on Microsoft by commoditizing Linux, which if successful, will drive down the price of Windows and make it more affordable to buy computer hardware.

I don't think most people care about "bloat", or at least they care about it less than software that does what they want. Strategy Letter IV: Bloatware and the 80/20 Myth Joel on Software - Bloatware and the 80/20 Myth

You could have just linked to Joel's rant instead of copying it without attribution.

Anyway, I think that the way to go is to make the standard local-file-access API more powerful. That way, you can still have a unified API. Which is why "FtpOpenFile" isn't the best way to go.

And it doesn't necessarily have to be much harder to access local resources with the more powerful API. The common/simple cases can be streamlined. For example, language features like exceptions can let you ignore errors that you wont encounter when doing local stuff. (No, exception semantics aren't perfect (yet), but they do work well in many situations).

Joel Spolsky, the guy whose opinions every slashbot likes to parrot and pass off as their own, uses Visual Basic. How do the slashbots handle the cognitive dissonance!

1. I don't believe this will ever happen because if you add a million good and elegant things and you take away one trivial foolish thing then after an upgrade that trivial foolish thing is the only thing you will hear about. Valid points like "but now you can do it better this way", "it caused these problems", "it prevented us from doing this wonderful new thing" never make users happy no matter how true they are. It is (very++) true with a small system (tiny compared to the windows OS) with a few tens of thousands of user so I can only assume this is more true in an insanely large system with many hundreds of millions of users.

2. Write truly performance-critical or chip-level stuff and you write in either assembler or the 'Generic Assembler' C. I agree that most programs that aren't performance constrained should be written in almost anything but C/assembler.

I don't think that how the kernel is written is the problem. Buffer overruns etc. can be avoided by careful C/asm programming, even using the same sort of techniques the various interpreters use. Any technique can be implemented at the asm level ,by definition, as all computer programs eventually execute CPU instructions. I can even imagine a useful kernel-level virtual machine for some kernel-specific tasks.

The problem ( and opportunity ) microsoft has is that they want to eliminate other choices by tying their applications (esp. I.E.) to the kernel. This is crazy from a computer science , 'write in layers' point of view but makes perfect sense from the 'beat the antitrust case and tollgate the world' sense. This is the problem: rational computing overridden by business needs.

Rewriting anything in a new language is not likely to be a one fell swoop situation! It is, in my limited experience, very much a 'go to heaven by way of hell' scenario.

3. I believe many ways to do one thing is usually a good idea as long as they are just different ways , perhaps convenient in different contexts, to eventually do one thing. e.g. if you have data structure X and wish to manipulate a variety of its parts for a variety of reasons it is useful to, at the lowest level, force them through a consistent internal API, with one place to do sanity checking. This doesn't mean the external API needs to be or should be this way. If the user ( in this case a programmer at level N + 1 ) can learn some simple task-based APIs and get their work done without ever needing to know the extraneous ( to them ) elements, then this is a good thing. As N + X gets closer to the user, then this becomes more evident. The end user could end up with a variety of 'correct' methods that they could discover. Please don't say 'training' to me -- If I as a user need to be trained before I can do something, instead of being able to discover how to do it, then I will be unhappy with that software. I write 'consulting ware' ,as joel would describe it, and I am sometimes guilty of writing software that requires explicit training. Our software is used to implement a variety of ,mostly linear, business functions but any time I can provide multiple guessable paths that do the same thing, I am pleased.

4. ;) my opinions:

I think the best way for microsoft to produce a reliable OS is to have the DOJ split them into separate OS and application companies. It is the compromises required to lock out competition that cause most of our problems with microsoft software. That said, the whole virus/spam/worm/trojan thing is a huge opportunity for microsoft to 'solve' the problem with palladium-style crap that an ignorant public will accept because of, oh the irony! , the problems caused by the weaknesses microsoft deliberately took on to be anti-competitive. More lock-in enabled because of previous customer-damaging lock-in. Oh to be young and have an abusable monopoly.

I believe they are not stupid , they are far more clever

I think that the caring part is changing in the OSS community, and that is good to see. There are still plenty of developers who want to make software with good user interfaces, and mean well but just don't have the skills. Time to get serious, time to Educate thyself. User interface, interaction design or whatever you want to call it isn't "touchy feely", personal preference or "whatever you are used to". There are real design principals and concepts here that are every bit as rational and useful as any in the Software Engineering realm. It is not voodoo. These design principals and concepts can be learnt and successfully applied just like other areas of software development such as network programming, computer security or object oriented programming etc. And just like these areas/fields in software development if want to have a chance of doing them well you will need to do some study, read up on the subject. Hell, you might even find it interesting. :-)

• The best book on the subject IMHO is About Face: The Essentials of Interaction Design. Very practical, insightful while also being quite entertaining to read. This should be the first book that you read.
• The SAP Design Guild website has a lot of good articles that explain usability principals and at the same time are very practical (and no advertising to wade through on the site, yay!)
• The book "User Interface Design For Programmers" by Joel Spolsky can be read online here. It is quite a good starting point and you can start reading it now.

--
Simon

Just for kicks, check out this article:

http://www.joelonsoftware.com/articles/PleaseLinke r.html

Only networking will get you a job.

US Navy experience means nothing when the pile of resumes is so big yours is not even read.

Every employer I have talked to refuses to distinguish between a person with a university CS degree and a person that learnt Java in his garage. They are looking for smart people that get things done, not necessarily someone that has a degree! These employees prefer to ask simple mindbenders to determine smarts. Too bad they don't know about the few Universities who only allow smart people graduate; it could help them sort out the cruft much faster.

Finally, as you have heard already, those certifications mean nothing unless you are in a large corporation and required to participate in a "continual improvement" regime.

If you are a programmer, rate your prospective employer on the Joel test.

You agree or disagree with a lot of things that Joel has to say, but IMHO this test tells you a lot about what your life as a software developer will be like. If there is no spec, no schedule, no bug database, no testers and no source control then do you really want to work there?

the java jvm can lock up hard. makes recovery quite interesting.

also java and .net are "successfull" b/c of general investment from big companes. there's lots of marketing dollars selling products and articles about these platforms. the PHB's read the PHB magazines, and those mags have articles re java and .net. Do those mags have articles on D? then it's not a competition.

Java is successfull because:

• it offers a nice abstraction for system specific issues which is only seldomly leaky.
• you can dive into an unknown project, select a random source file and understand it. You may have problems getting the big picture, but the code itself is there - there are no suprises like operator overloading, defines etc. All you need to know about the class is in it (and it's superclass and interfaces)
• its complex enough to do some magic in it, but the idiot next cubicle can't run totally amok and wreck the whole system.

Jef Raskin
Joel Spolsky
Bruce Tognazzini

At least someone else seems to think so too in this rant.

To put things a little more elegantly than the parent post, I might suggestion the grandparent poster read Joel Spolsky's biculturalism article.

We often see in the linux community the false logic of:

OS X is successful with end-users
OS X is a unix
Linux is a unix
Therefore Linux can be successful with end users

The problems that make linux "un-userfriendly" are cultural, not technological. When people keep citing OS X, via its being a unix, as validating the concept of Desktop Linux, what they keep forgetting is that the mac and linux developer cultures are entirely different. The mac developer culture has a proud 20 year tradition of making graphical software for end-users and valuing usability; the linux developers comes from a 30 year tradition of programmers making command-line software for other programmers and not caring about the non-technical user's experience whatsoever.

Such long-held, deeply-ingrained traditions of the different developer communities affect the way their software evolves, even decades after those traditions began. The answer to the question of why can't linux be like OS X is not something that a lot of linux folks like to hear--Linux can be "purdy and usable" like OS X, but the linux community has to stop idolizing their unix cultural forbears and start realizing that it was the cultural practices of those forbears that put them in the miserable situation they're in today.

Desktop Linux isn't a battle of Proprietary vs. Free. It's really a culture war of graphical vs. command-line, end-user vs. geek, macintosh vs. unix. That's where the real conflict is; people just tend to obscure the conflict by focusing on what license something is put under.

...and insecure

But, hey - he's using .NET, 'cause it is a mature, feature-complete language, right?

Two points, catered to delivering Java-powered client applications to John Q. Public effortlessly (let's face it; that's what applets did):

Up until now, you could release a Java 1.1.x compatible *application* (no security sandbox) without worrying about Granny Smith even having been able to spell jre when she was downloading. That's a good thing. 1.1.x is plenty to check and see if there's a Java 2 JRE laying around, and helping Granny get it if you absolutely need it.

Which brings me to point 2... Do you really *need* Java 2, or do you just want it? Admittedly Swing is a little buggy on 1.1.4 [if you include swingall.jar], which is as far as MS's VM got before the mess started, but Oracle still ships a version of 1.1.8 to power its management tools. There's very little you can't do with 1.1.x, especially once you've got the Collections API in the mix.

I've seen emails go across the Apple Java Development mailing list saying things like, "Our boss says we *have* to have generics, so Macs and their 1.4.x JVM are right out for development." Look, these are things you've been happily *not* using for all of Java's existence, that older code still works in 1.5, yet you're moving the whole of your development over b/c you think a new, just out of beta feature is cool? "As if source code rusted."

This settlement is great news for Java on the desktop. The longer you can keep more of your code 1.1 friendly, the longer you can deploy effortlessly on Windows. That window had almost closed, and now it's back, wide open.

And from the press release, though I'm not so optimistic to believe it'll necessarily be the case, there's nothing ruling out MS's installation of a newer version of Sun's jre by default in the future. Heck, it ain't jre's or clr's that boost an OS, it's, "Developers, developers, developers, developers." Maybe MS sees the more the merrier, and would prefer things like Sun's Mad Hatter not gain any special traction. Reminds me a little of AOL dropping Mozilla (which it based the OS X AOL client on as proof of concept in the Great Game of 0110 Chicken 2003) the second after MS relicensed them the IE engine.

Joel has a great thread on this subject.

time tracking, time estimation

The summary (as I read it)? People like choice when it's related to what they want to do. If they're making a greeting card, they want to choose what font it uses and what overused clip-art to use. They don't want to choose its orientation as it comes out of the printer, or whether it's saved in MS Word or PDF or RTF or HTML or BMP.

So when I install a linux distribution, and I want to compose a word processing document? I don't care all that much whether I'm using KOffice or StarOffice or OpenOffice.org or AbiWord or whatever, because the point is not what program I'm using. The point is to write a document, and I shouldn't have to make a needless choice just to get to that point.

That's why modularity (versus "yes" or "no" to compiling it in) in the linux kernel is such a good idea, for example. It allows me to say, "make this choice for me if I need it, and don't hassle me about it."

I remember going through XP programming or Planning XP and finding a beauty... (paraphrased)

• ... if you need some testing infrastructure, database, web interface etc and have trouble justifing it to the client
• just re-word a story so it has to be completed within the current itteration. ...

for this reason developers who strictly adhere to it's rules are forever going to be caught off balance.

My biggest gripe with XP is customers writing stories that define their own problems. It just does not happen with shrink wrap applications. I suspect that this only works with certain types of application development say internal products.

You can learn as much from a data structures class taugh in Java as you can from one taught in $language_of_choice. The idea is to learn how things work fundamentally, and then apply those ideas practically. A linked list in Java works the same as a linked list in C.

The thing is, Java is somewhat high-level. There are things that go on under the hood that you won't learn about, but once in a while pop up anyway. For example, being taught Java, you won't learn about the difference between memory allocated on the heap, and memory allocated on the stack. And yet...

This does not work (it doesn't even compile):

String x = "a";
(new Runnable() { public void run() { x = "b"; } } ).run();
System.out.println(x);

There's nothing wrong with the code; the problem is that Java pretends to support closures but really doesn't. To use x in the anonymous inner class, you need to declare it final. But if you declare it final, you can't do the x = "b" assignment.

I'm familiar with C, so I understand the difference between the heap and the stack. I can infer that x (the reference to the string, not the string itself) is allocated on the stack. It is not uncommon for instances of anonymous inner classes to outlive the stack frame they were created in, so the compiler doesn't know whether or not x (on the stack) will still exist when the object's run() method is called. So it makes a _copy_ of x, but in order to pretend that it is still x, the compiler wants you to declare it final so that the original and the copy can never get out of sync.

Having experience with C, I know the heap is a safe place to put things that may need to outlive the current stack frame:

final String[] x = new String[] { "a" };
(new Runnable() { public void run() { x[0] = "b"; } } ).run();
System.out.println(x[0]);

It's ugly, but it works. The reference called x needs to be declared final (because it's on the stack) but the reference contained in the array does not need to be final (because it's on the heap).

Because of my experience with lower-level stuff, I understand how Java is faking its support for closures, and how to work around the limitations. This is only one example; there are many other times when understanding things from a closer-to-the-metal perspective gives insights that would be lost if things were only understood from a high level. Joel Spolsky summed this up fairly well: Leaky Abstractions

I disagree.

I suppose what makes a superior display is in the eyes (literally) of the beholder.

You should NEVER have visible flicker on a decent CRT (unless you are comparing your new 2003 LCD to your old 14" running @60Hz)

I find anything below 70 Hz completely unusable, and have to get close to 80 before the problem goes away completely. Of course I've always adjusted my own machines accordingly, but I still occasionally encounter machines where the damn monitor looks like a strobelight to me. (Especially under fluorescent lights.)

As for "sharper pixels" you are technically correct - unfortunately sharper rectangular pixels does not a smooth diagonal line make...

Maybe that's the big difference in our perceptions - a little jagginess doesn't bother me at all. In fact blur drives me nuts and I dislike text antialiasing. (I agree with this "Joel on Software" column.) Instead, I pick fonts that look good on a pixelated display.

We start off with a bang:

From a practical perspective, cost is an obvious differentiator, as are access to source and the ability to run outside the Intel processor environment. But it's possible to argue that those differences are neither real nor important. ...
To get beyond superficialities like these...

Oh for heaven's sake. Would nearly so many small to mid-sized companies running "eShops" have considered Linux if it weren't for the phat licensing deal? Ask Grandma Tilly, heck ask 80% of so-called "SQL Server Admins" out there -- Windows is much easier to learn if your skillset == GUI familiarity. Price is HUGE.

Then ask the governments (start with China) how important open source is. Again, cost of ownership is awfully high to move from any OS to any other. There must be something awfully impressive making whole countries' governments swap from one to another, and the security and freedom to explore what you're running is open source's big "in".

Let's follow that up with some anecdotal evidence to prove whatever I'm feeling today...

"like a 1991 copy of Vsifax for SunOS 4.4 -- works perfectly under Solaris 2.9, while Windows 2003/XP server now contains both a Posix-compliant interface set and four generations of the Win32 interface"

Come on. I'm no *NIX expert and usually let Fink do most of my compiling, but I do know that compiling against the wrong version of foolib can fook builds like nobody's business. I also know that...

"On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity."

VB 3 apps still run (heck, until recently the code would compile in VB 6) without much issue, and though I was upset when I tried Mosaic 2.1 on Windows XP recently, this evidence hardly shows that Windows is a kludge and Linux isn't.

I'm not weighing in that he's wrong; I'm saying he hasn't come close to proving his point with his examples. A better way to show the difference would be to, say, throw a highly customized version of Gentoo doing something very specific better than the best you could do along those lines in Windows. But why can we do this in Linux? Because it's *open*, daggummit.

such [major OS] changes[/advancements] historically have been accompanied by the addition of new layers of kludged code intended to maintain some semblance of backward compatibility with previous kludges.

I like where he's trying to take us here -- certainly a hack for SimCity today makes you hack for it again in 98, and then in 2k, etc, and could end up becoming a lot more like the Princess and the Pea than sand in an oyster. And I think a number of Window's security issues come from deadwood left in what's been described as an OS originally designed to provider home users with a workable, but not networkable, computer.

But what he misses is that its the lineage that's causing these issues, not commercialism per se. Linux comes from a server mentality. Security is key. Windows comes from a mentality that perpared itself for Grandma Tilly (and the SQL Server Admins (which I've been doing for 6 years, before you flame)) where user interfaces are nearly king. This is why Windows seems kludged -- because it's trying to be all things to all people. Linux is too, *now*, and you've seen all sorts of, "throw out X11 and use Y" articles around here.

Anyhow, you get the point. The fellow goes so low-level while keeping a very bird's eye view of what's going on that he's basically saying nothing. Hey, it's all 0's and 1's. You can grab any of your favorite anecdotes and point to places where one wins over the other -- it's nearly as bad as the PowerPC vs. x86 MHz wars Mac/Windows trolls fought nearly daily on comp.sys.mac.advocacy for so long. Sure, if you r

Here is why it makes sense. The OS product is only successful if it has user software. Breaking backward compatibility costs serious market share.

Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn't free memory right away. That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

As we know from Kuro5hin's code windows code review:

It's noticeable that a lot of the "hacks" refer to individual applications. In some cases they are non-Microsoft. [...] Microsoft does not steal open-source code. Their older code is flaky, their modern code excellent. Their programmers are skilled and enthusiastic. Problems are generally due to a trade-off of current quality against vast hardware, software and backward compatibility.

To conclude, M$ writes good code but has to use dirty hacks for backward compatibility. It's not their fault, they have customers to care for.

Joel's 'UI Design For Programmers'

Hamster

At least MS has a meeting and decides how to continue ~.

Remember the old help dialog box? When you first fired up help for that app, you'd have to make a choice between "Minimize database size (recommended)," "Maximize search capabilities," or "Customize search capabilities." Those choices were in there, not for any user's benefit (in fact, this caused even more confusion for the vast majority of users), but because the developers couldn't decide which was best and the product manager was too much a spineless jellyfish to make a decision. They ended up punting the decision to the user. WTFIT?!

If you want to learn more, Joel has a great book about this very topic, or you can read the first seven chapters on-line.

You're a asuming that there is a Microsoft way to look at code and that every MS developer is a robot brain washed to think that way. MS hire very capable and brilliant people, you couldn't tell the difference between a bunch of NT kernel hackers and a bunch of Linux kernel hackers, both groups are extremely knowledgeable and manufacture high quallity code.

MS has the biggest industrial infrastructure in the world of quallity assurance. Every developer should go trhough an internship in Redmond to see this.

Large software *is* complex, period. Given a finite amount of talent and time, bugs are depedent of the size of the project, it really don't make a difference whether you're code is open source or not.

How many people do you think actually look at open source code to look for bugs?

Moral: if MS releases buggy, exploitalbe and potentially unsafe code is *not* because they are sloppy or because propietary code is inherently worse than open source, is because large software is complex and takes a lot of time to do it right.

Article on speed-to-market that's necessary in some markets. Gives a different view than amazon=traditional (or at least a different aspect).

Reinout

I think the real point that he's missing is that every project undertaken on Open Source that's a direct response to something that Microsoft is doing is a step in the direction of eliminating barriers to entry. Anything that can be done on an Open Source platform that could previously only have been done in a Closed Source environment is a good thing.

Things You Should Never Do, Part I

http://www.joelonsoftware.com/articles/fog00000000 69.html

Won't this confuse people?

Yes, but if the WWF can pull it off, so can we. Besides, in six months you'll forget there ever was any other name.

So they'll be able to get Spolsky to say something really nice about Firefox like he already did for Firebird? I imagine that if Joel on Software readers forget it was ever called Firebird, it will be because they forgot Joel endorsed it.

I strongly suspect that Firebird usership has creeped past the usual hardcore anti-Microsoft AND looking-for-the-bleeding-edge technologists, out to a larger slice of the general populace that might not be so patient with all these name changes, and who might be more inclined to try something if someone famous says it's good.

Well, I guess since Joel Spolsky invented Visual Basic for Applications, he is Satan. Which of course makes perfect sense because he is a certifiable fa*got.

Last month, Mr. Spolsky noted he had acquired a more nuanced point of view about when to develop in C#. Still, as your link notes, he thought it was the thing to do in April aught-two.

Joel Spolsky published a great article a while back on .Net, his company's strategy for the platform, and why Anders so damn cool. Also, just in case you're curious as to how his last name is pronounced, it's pronounced hells-burg.

And how are you going to choose the right data structure without some understanding of the hardware it will run on?

While a simple, powerful recursive algorithm written in Scheme may seem elegant to a mathemetician it might suck ass on a real processor because building all of those stack frames can be expensive.

CS departments grew out of either EE or mathematics departments and you can see an inherited bias. CS departments that grew out of EE departments focus more on hardware, assembly and architecture while ones that grew out of math departments tend to focus on algorithms.

Mathemeticians tend to want to abstract away the hardware, but ignoring that nasty little reality is costly. It is this tendency that leads the trend to teaching introductory CS in Java and VB.

EEs tend to want to map everything directly to hardware and end up with suboptimal solutions either because they take too long or because they focus on optimizing a handful of instructions instead of realizing that a more powerful algorithm might have bigger gains.

CS is =not= math and it =isn't= engineering. It's a hybrid and it has to be treated as such.

Here is some suggested reading. Maybe it will help explain why it is critical to understand how real machines work.

Textbooks are just far too expensive and most of the time you're not really getting your money's worth out of them, at least that's how I feel. It appears as though my particular University has some deals with some publishers, such as Addison-Wesley, and get all their programming textbooks from them. As a result, Java Software Solutions is the standard book. Personally I found this particular book to be extremely useless... While other books like O'Reilly's Learning Java, and Head First Java books offered much more content, and were both CHEAPER in price. I've since opted to avoid buying the school's textbooks whenever possible.

The money spent on these textbooks could be used for much more worthwhile things.

I actually bought bootlegged photocopied textbooks this semester. Knowing full well that the content of these books (in terms of learning potential) is quite small, but needing to rely on them anyway for the sake of excersizes and problems that need to be done for assignments. Net savings: $165. Where did this money go? I attended an Undergraduate Software Engineering Conference where I learned lots of interesting things from such speakers as Joel Spolsky. The rest of the money when towards paying off my credit card for... you guessed it, more textbooks... and tuition.

smart and get things done

it was frustrating because I clearly knew what I wanted to be doing but it wasn't available to me at the time. It was always: if you want to do computers you need to go to MIT then you go work at a corporation as an engineer and follow "the path." But I dropped out of college, and started my own company. My brother followed a more conventional path. He got a degree and became a stock broker and that's what my mother expected that you're supposed to do. And he's doing OK for himself, but there's nothing like a few Ferarris to rub your parents face in." John Carmack

for those not treading a worn path, what matters (in software anyway) is the quality of the code, delivered on time meeting the design critera. JOS has consistantly made the point (the right one) that he's looking for the top 5%.

but guess what ... this isn't a rant about hiring. This is a gorilla marketing campaign .... We're goin' up to slashdot to put the word to the net .