Slashdot Log In
Joel On Microsoft's API Mistakes
Posted by
timothy
on Wed Jun 16, 2004 05:31 PM
from the microsoft-is-a-big-software-company dept.
from the microsoft-is-a-big-software-company dept.
AceMarkE writes "Joel Spolsky of Joel on Software has posted an article entitled "How Microsoft Lost the API War". He covers why the Win32 API is important to Microsoft, what they've done to keep it working, why Microsoft's switch to the .Net platform is both a good and bad idea, and why he feels the browser will be the real future of application development. Definitely worth a read no matter what your opinion of Microsoft is."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Repeating my comment on OSNews... (Score:5, Insightful)
1. Web clients vs. rich user interfaces
I have long wondered why web interfaces aren't much good. The technologies are there; Java applets, Flash, Python could do it, JavaScript could with a few extensions, XUL, heck, even C, compiled on the fly. All these stop just short of integrating well with the web and the client platform. Why? Why has nobody managed (or tried) to take the last step? Even
2. API changes
Contrary to Microsoft's, UNIX and POSIX APIs have been very stable. There have been extensions, but the bulk of what used to work still works. This makes the case for switching over to standard technologies, now that Microsoft is pushing you to switch anyway.
Re:Repeating my comment on OSNews... (Score:5, Insightful)
Because HTTP stands for Hyper Text Transfer Protocol, and HTML stands for Hyper Text Markup Language. The web does a magnificent work in what it was intended to do. The web sucks at extensions. Some reasons:
1) No sessions. No good way to store state. Cookies, etc are ugly kludges.
2) Designed for unidirectional, or, at best, asymmetric data transfers. There isn't a really good way to upload data.
3) Privacy and encryption are an add-on, not built in.
4) No widgets other than those in the browser.
The solution for all these problems have been to create plug-ins, applets, javascript, flash, etc. Since these aren't part of the standard, they are all different and incompatible among them. There isn't any standard beyond http and html. Or, rather, there are too many standards, one for each vendor...
Parent
Re:Repeating my comment on OSNews... (Score:5, Interesting)
Yes, obviously, but then, _how come_ there are no standard protocols that fix this? Many people perceive the need. Users feel the difference between web apps and native apps (Joel is right, for existing apps, users don't care. Now try writing a usable word processor using HTTP and HTML...).
I once posted a message to some mailing list requesting support for sockets in JavaScript. With that, you could interact with the server _without_ reloading the page, have the server push events to you, rather than periodically poll for them, speak any protocol from a web app, etc. The reply I got was that it wasn't going to happen, citing security issues and bloat. Yeah, that's why Java applets do have socket support, and Java is of course a prime example of elegant, light-weight software. *cough* *cough*
As for lack of standardization; we have CORBA which is very standardized and very universal. If you want something lighter, there is RPC. ZeroInstall provides a nice way to "run" native software off the web. Java has gotten pretty usable. WHERE ARE THE GOOD WEB HOSTED APPS?!?
Parent
Re:Repeating my comment on OSNews... (Score:5, Interesting)
Security settings should force you to communicate only with your originating server and port. Hence a Socket is way "too free" for that.
And if the user is using a proxy, then what? How can you access your original server? You have to go through the Proxy.
No, a real way would be to have access to an object a bit like java.net.HttpURLConnection. Such an object would be trivial to write, with two features in mind:
1. It should use the browser's connections settings (proxies, etc...) and caching capabilities.
2. It should enforce that the URLs accessed are issued from the same server/port as the script requesting it.
Socket is way too low level.
Parent
Re:Repeating my comment on OSNews... (Score:5, Informative)
It's not exactly sockets, but you can do an awful lot with the XmlHttpRequest object. Microsoft did it first, I think, and Mozilla has a complete clone. Check out the XulPlanet documentation [xulplanet.com], the Mozilla documentation [elemental.com], the Microsoft documentation [microsoft.com] or this tutorial called Using the XML HTTP Request Object [jibbering.com]
The XmlHttpRequest object is poorly named. Really you're just making an HTTP request, and if the response happens to be XML, there are convenience functions for getting a fully-parsed DOM view of the document. If the response is anything else (plain text, JavaScript, Perl, HTML, etc.) you can do what you want with it, including calling eval() on it from a JavaScript script. You can do synchronous (blocking) or asynchronous (non-blocking) calls to your web server, and either be notified of completion by a callback for non-blocking calls, or just treat it like a function call for blocking calls. It's quite handy, and we have a project at work that makes extensive use of this technique. We have a "thick" or "rich" client application that runs in the web browser. Our client looks like a native application--it has table widgets, with clickable headers that resort the columns, it has a tree widget that looks like the tree in Windows Explorer, it supports drag-and-drop and custom context-menus, and if you open our application in a chrome-free browser window, it's almost possible to forget it's not native (the speed is usually what gives it away, the GUI is a little sluggish...). It works equally well in Mozilla, Firefox, IE 5.5+, and Netscape 7.1+ on Windows 9x, 2000, XP, and many flavours of GNU/Linux (tested on Gentoo and Redhat 7.3, and 8.0 using GNOME, KDE, and some kind of *Box wm). Well, "equally well" is a bit of a stretch. IE's implementation of the DOM is dog slow, so some things run a bit faster in the Gecko-based browsers, but all functionality is equally available in all the configurations listed above. We've managed to stay standards-compliant for the most part, and have abstracted away the quirks in IE, so as soon as Konqueror, Opera and $YOUR_FAVOURITE_BROWSER fully support JavaScript 1.5, DOM 2.0, and CSS 2.0, our app will work in your browser, too. (I don't know which parts these browsers are missing, so maybe our app already works there.)
The only remaining hurdle is to convince management that it should be open-sourced so that other people can use it, too. If you can't wait, you might want to check out SourceForge. There are some other widget kits available for building browser-based apps. We chose not to go with them because, at the time, they were too Alpha-ish, and we disagreed with some design decisions. Our decision not to use those projects has not been revisited for a while though, now that we are rather comitted to our in-house implementation, so things may have improved significantly since the last time I had a look.
Also, if you're going to actually build any significant JavaScript apps (we have more than 40k loc that turns out to be more than 1 meg of JavaScript to download), I highly recommend JSDoc [sourceforge.net]. The main developer, Gabriel, has been very responsive and helpful, and the documentation that his scripts produce is excellent. Especially considering he builds JSDoc in his spare time, I can't compliment his work enough. Now that our codebase is too large for me to keep it all in my head, the API has saved a lot of my time.
Ian
Parent
Re:Repeating my comment on OSNews... (Score:5, Insightful)
Joel has explained the reason Internet Explorer's development hit a wall a year or two ago. All you people asking why Internet Explorer's standards compliance hasn't gotten any better, why it hasn't gotten tabbed browsing, etc, now you have your answer. It's a very good reason (for Microsoft), and it's obvious in retrospect, but I sure didn't think of it until I read these few sentences:
Promising new technologies like HTAs and DHTML were stopped in their tracks. The Internet Explorer team seems to have disappeared; they have been completely missing in action for several years. There's no way Microsoft is going to allow DHTML to get any better than it already is: it's just too dangerous to their core business, the rich client.
Microsoft can't afford to make IE any better, because if was improved one or two generations more, the kinds of web applications that would become possible would make Windows irrelevant as a platform. Everyone would be developing for the web instead of Win32 or .NET or Avalon or whatever. Internet Explorer development has come to a screeching halt except for things which are absolutely necessary to avoid losing its #1 browser position (because for Microsoft the only thing worse than an improved IE is an improved Mozilla!). This is the reason why.
Parent
Hard to be a Mac user? (Score:5, Insightful)
No it isn't, it's easy to be a Mac (OS X) user. No Viruses, No Trojans, a sytem that stays up pretty much indefinitely, and great, great applications that do everythinbg I need and much more besides that I probably don't really need, if I'm honest. This old argument about Mac having no apps is very old, very tired, and very tiresome. Please stop.
Re:Hard to be a Mac user? (Score:5, Interesting)
It seems [apple.com] there may be a few [apple.com] applications [apple.com] for Mac OS X as well. More importantly, Objective-C and Cocoa are easy enough that more OS X programs are being made every day. Developers indeed. If the Linux community could get some standardizationg together and throw some effort behind GNUStep... sigh... that would be nice, too, but Apple's more likely to release OS X for Intel ( i.e. don't hold your breath ). GNUStep is getting closer, though...
If it weren't for guys like Joel with their "if it's not Microsoft it's just weird" attitude and willingness to spread MS FUD, users would have a lot more options, and more developers would be able to make a better living slinging more code for more platforms, rather than being forced to eat Microsoft's swill.
Parent
Re:Hard to be a Mac user? (Score:5, Insightful)
Like he said, *you* have everything *you* need, but the plethora of quite diverse and intensive applications that everyone *else* needs isn't there. Sorry, he's still right.
1. People seem to mix up the fact that just because a particular Windows application isn't available on Mac, that Mac users do without. As a rule, it's not the case.
2. What applications do the vast majority of Windows users use? Office, IE, and Outlook. Right? They are all available on Mac though there's little reason to use IE and Outlook. The one exception is Access. Is this a show stopper in the corporate and business world? Sometimes. In the home market? Rarely.
3. To the typical user -- geeks included -- the availability of more software on Windows just means there's more software they could use but don't. This is not a minor point; there's only so much software that any one person will want to use. I'd be curious to see if Windows users use more, less, or the same amount of software as Mac users.
4. While quality is often in the eye of the beholder, I for one still think that Windows software tends to be crappier than Mac software. Unfortunately, that crappiness seems to be spreading. Suffice it to say there are more ways to produce crappy software than good software and since Windows has so much more software available for it ...
It's not hard being a Mac user, certainly no harder than being a Windows users since the vast majority of users have a hard time using computers at all.
Try this perspective: as a longtime Mac user, I have a hard time using Windows because I can't find much high quality software that runs on Windows --even after several years. Stands to reason, doesn't it? Considering that all the major apps -- Word, Excel, Photoshop, Illustrator, etc. -- were born on the Mac platform, you'd think developers would look to the Mac sometimes for how to do things right.
Parent
Good idea (Score:5, Insightful)
Honestly, I think breaking API compatibility is the only way for MS to actually fix the problems with Windows. A lot of the problem seems to be the large amount of old code and cruft that has been left in the name of backwards compatibility.
It's certainly a big risk to the Microsoft monopoly, but it's a necessary step for them. Now would be a good time for Linux to make a big move for the desktop.
Re:Good idea (Score:5, Informative)
Apple, on the other hand, only broke the API once, with the transition from Classic to Cocoa (the MacOSX API), and even then, they did their best to maintain compatibility, with Carbon.
Parent
Re:Good idea (Score:5, Interesting)
Wait; this is completely contrary to my experience. I worked on Lotus 1-2-3 for Mac, which was targeted at Mac OS 6 & 7 (7 was new when we shipped 1-2-3). 1-2-3 was written in C (actually Symantec's C++ subset) with some inline 68K assembly, and did some grotesque trap patching.
That 1-2-3 68K code runs under OS X on a PowerPC G5. Reliably. I still maintain spreadsheets that I update weekly.
As Joel's article pointed out, Microsoft has engaged in some amazing bend-over-backwards hackery to maintain backward compatibility. This echoes a Wall Street Journal article written about Windows NT development where Dave Cutler bragged about the number of programmers tasked with adding code to make certain "high profile" Windows 3.x apps run under NT.
By contrast, Apple, in the early releases of Mac OS, showed enough foresight to tell developers how to keep their code future-proof, and developers who adhered to those protocols (which were not all that restrictive) wrote apps that still run today, under an entirely new OS on an entirely different CPU.
Parent
Re:Good idea (Score:5, Insightful)
The fact that Microsoft is breaking backwards compatibility is the exact reason that Joel says they lost the API war.
Developers, more than anything else want a stable platform to develop for. Microsoft's top priority in the past was to provide a stable platform (stable in the sense that all old-code worked on the new platform). Developers are users too. I would be really pissed off if I upgraded some app and it wasn't able to work with my old data. Why is there a different expectation when I code for an API? Why should I have to rewrite my code because the vendor discovered some better way of doing it? I probably went to a lot of trouble to get that code working in the first place. Make sure it performs well, possibly works around a couple bugs that took me hours or days to figure out, and now the vendor comes along and breaks it and I have to learn some new way of doing it and deal with new, yet undiscovered bugs. fsck that. If it was an app, I would ditch it. If it was a platform and had a choice, I'd ditch that too.
What platform are people turning to? Joel's answer is the web because HTML/browser represents a very stable platform. I won't reiterate his arguments here. But, I do feel that he has a point. He is a smart guy, and I could see it come to pass. That doesn't necessarily mean it will. Smart people have been wrong before :)
With Joel's world view, how Linux will make inroads on the corporate desktop is simply by having a good web-browser and being free. Features on the client will become irrelevant.
All I can say is prediction is hard, especially when you are trying to predict the future.
Parent
Re:Good idea (Score:5, Insightful)
I agree with this, and I agree with Joel as well.
Maintaining reverse compatibility is the right thing to do today. It's the right thing to do tommorow. It's the right thing to do next week.
But it is not free, and the costs grow exponentially with each iteration. Eventually, "exponentially" will beat anyone... even Microsoft.
They've actually trapped themselves extra badly because each successful iteration ingrained the expectation from their customers that much more that the next iteration too would be backwards compatible. The hole just gets deeper every time.
I've had this discussion with other developers before, who insisted the users need backwards compatibility. My counterargument was just this, a day will come, sooner than you think, where you won't be able to provide it. Personally, I think we need to level with the users sooner, rather then later: We can't provide it indefinately, so let's at least hold the option open of breaking compatibility. (I'm not saying to break it for no reason, just that you will have to, the logic of modern programming demands it, so be ready.)
As usual, if you sensibly prepare for it in advance it's easier than if you are suddenly shocked by it.
Parent
This was not an unusual case (Score:5, Interesting)
Re:This was not an unusual case (Score:5, Funny)
Parent
Security implications of kludged patches? (Score:5, Interesting)
That bit of the article really got me. How many memory allocators do they need to debug or secure? How many exploits might be found by pretending to be SimCity or other applications and getting branched off to languid backwaters of code that don't get much ttention anymore?
Xix.
Parent
I don't agree (Score:5, Interesting)
Yes, there isn't such a big incentive *right now* to write code for Avalon / XAML.
Yes, MSDN Magazine has the *wrong* attidue (notice the ratio of artciles about yet-unavailable technologies to availiable technologies in it recently?)
As a matter of fact, personally, I didn't bother with them because I've more pressing concerns at the moments.
But, the thing is:
By all accounts - Longhorn *will* keep the reknown MS' backward compatability.
A> There hbeen nothing on the contrary.
B> MS has a *really* good track record.
The so-called breaking changes (he mentions
The change in VB.NET is indeed a breaking change.
But, it's not the first time that VB update break existing code (as a matter of fact, I think that is normal for VB, although the changes are usually minimal)
VB.Net is a new language, VB6 has reached its end, you might want to compare it to the transition from C to C++, you've to break compatability (for the furious: byte *buffer = malloc(1024); isn't legal c++)
And if you're going to break compatability, why not do it in a way that is still largely the same, but gives you *so much more* freedom & flexibility.
The other choice would've been to exclude VB from
So, in short, Joel is talking about moving away from old technology (Win32) that he descibe as hard to use and error-prone to a better, OO, managed way of doing things.
While at the same time *retaining* backward compatability.
I don't get it.
Sure, a lot fo code is now not the newest & brightest, but you can say the same about COBOL.
About MS losing the desktop to Web app, that is bull.
Personally, I can't *stand* using webmail, the latency there is killing me.
Any sort of web app is usually a mess to write & maintain correctly - especially cross-platform(for example, Firefox 0.9 can't show *Slashdot* properly - I get all sorts of hovering errors when tables over-write one another. Strangely, IE show it perfectly well. And I usually use Firefox, for the reasons Joel mentioned).
Yes, MS made a big mistake with not updating IE, but I can see their point.
If they are going to sell Longhorn, it needs to be more than snappy UI & pretty pictures (especially for the business client).
It has to have *killer app* - IE 7 & WMP 10 are probably on top of the list at MS.
I'm certain that we will so much improved applications that require Longhorn (DirectX for Longhorn isn't that much of a long call - by the time that it would be out, 2000 would be an old system, and MS can justify not supporting it on Win2K. Games are the #1 killer app, after all.)
Re:I do agree, and not with you. (Score:5, Insightful)
Sure, backwards compatibility with Win32. But not full backwards compatibility, it's more like a subsystem.
The point is, why re-code all your applications for the new longhorn stuff, why re-code all your applications for all the
It's an interesting time, and I won't bet on either side of the coin. We'll just have to wait and see what happens.
ps. Mozilla and Firefox run Slashdot and 99.8% of web sites out there perfectly for me.
Parent
Visual C++ now free (Score:5, Informative)
As a (former) die hard web developer (Score:5, Insightful)
I can see technologies like SOAP enabling rich clients to interop across platforms (ok MS haters, SOAP is a mult-vendor thing so don't reply telling me some tinfoil hat story on how MS will patent SOAP and sue anyone who uses it without license). I am willing to bet some other protocols similar to SOAP, or perhaps riding on top of SOAP, will come along to allow richer communication across networks. HTML just isn't going to do it.
While I totally agree that open standards and open source make the best APIs, MS failed way before even that line. Take SMB for example. Their systems, by design or mistake, don't even follow their own standard! I am betting it is a little of both. Their APIs are this way as well. What is really hurts MS in this particular area is poor documentation and poor implimentation of their own APIs. Having worked with
Re:As a (former) die hard web developer (Score:5, Interesting)
On the spot, AC.
What I wished was that we went back to POSIX -- well, not quite, actually some garbage-collected functional stuff running on POSIX -- and the X Window System.
And I think that could come to pass. With GNU/Linux spreading, Mac OS X holding its share and getting X servers (both Apple's gratis and Fink's free ones), and Cygwin/X getting easier and easier to install, we could soon have X servers everywhere, so that we could run applications from POSIX servers whenever HTTP didn't suffice.
A trend may be starting with public Telecenters [sp.gov.br] and other LTSP or otherwise host-and-terminals GNU/Linux implementations.
Then we could go back to improving the host (GNU Hurd, functional programming, relational databases) and the terminals (Cairo, I/O) and stop worrying about the API du jour.
Parent
And people say.... (Score:5, Funny)
And people say the evil giant doesn't try to fix it's software. They fixed SimCity DAMN IT!
Win32 API will live forever (Score:5, Insightful)
Eventually the WINE development team will crack most of the undocumented Win32 API calls and make WINE better with each release. When that happens, Microsoft will have abandoned the Windows 32 bit platform for Longhorn. Then Linux + WINE will be very valuable for people with new machines who can only run Longhorn or Linux.
My only request is that WINE and other programs than run softare using the Win32 APIs, create a sandbox to prevent viruses and worms from spreading.
The bets are on as to how soon those Longhorn viruses and worms come out after Longhorn is released.
Key quotation regarding IE... (Score:5, Insightful)
Which means, suddenly, Microsoft's API doesn't matter so much. Web applications don't require Windows.
It's not that Microsoft didn't notice this was happening. Of course they did, and when the implications became clear, they slammed on the brakes. Promising new technologies like HTAs and DHTML were stopped in their tracks. The Internet Explorer team seems to have disappeared; they have been completely missing in action for several years. There's no way Microsoft is going to allow DHTML to get any better than it already is: it's just too dangerous to their core business, the rich client. The big meme at Microsoft these days is: "Microsoft is betting the company on the rich client." You'll see that somewhere in every slide presentation about Longhorn. Joe Beda, from the Avalon team, says that "Avalon, and Longhorn in general, is Microsoft's stake in the ground, saying that we believe power on your desktop, locally sitting there doing cool stuff, is here to stay. We're investing on the desktop, we think it's a good place to be, and we hope we're going to start a wave of excitement..."
The trouble is: it's too late.
So, when Slashdot goes on and on about how great Mozilla is (and it is good, I'm not saying it isn't - I really like FireFox 0.9) and laments how Microsoft hasn't done a damn thing with IE since 2001, and how you need the Google toolbar and this and that - remember that quote.
Microsoft wants to slow DOWN the rate of advancement in the browser. If you buy that, and buy Joel's premise on that, you now should conclude something VERY VERY IMPORTANT.
Mozilla for Windows may be the SINGLE MOST IMPORTANT OSS project there is. In many ways, it is just as important as developments in Gnome and the linux kernel, disk systems, network protocols, what have you. It's advancements in being able to push rich applications is vital. It's replacement for Active Scripting needs to be secure. Every step it makes pushes another developer that may have gone to use the Windows API or
Garbage Collection (Score:5, Informative)
The main productivity boost in Python, for example, is its dynamic typing. Its simplicity second, and automatic memory management as a third, perhaps.
Also, his claim that you don't have to debug memory leaks with Garbage Collection is a common fallacy. Garbage Collection makes it very possible to leak memory, often in more difficult ways to debug, since the developer is typically unaware of what memory is behind held by which objects as usually there is no need to put much thought into the issue.
Why the browser will NOT be the future of app dev (Score:5, Interesting)
Just my 2c, but I am sick and tired of hearing "The app is broken" and telling them to run ad-aware and hearing "Ok, it's fixed now. Try not to let it happen again." argh!
I respect Joel, but.. (Score:5, Insightful)
1) It's not ANSI VB or ANSI Win32. If you settle on a programming environment controlled by one vendor, then they can change the language specifications at will. I wrote my System/UI specific wrapper functions over a decade ago. Why didn't Joel?
2) Joel compares C/C++ memory management to automatic vs manual transmissions. I would associate memory management in C/C++ to doctors who know once they make an incision, they have to close it back up when done. Either you know the procedure (or launguage) or you don't. The article seems to want to apologize for all the Comp Sci grads who don't have a clue when it concerns system level programming (I found one in my office this week).
3) VB is a layer on top of Win32. So is MFC. From the object dumps I've run on MSIL applications, so is
4) The Win32 API is feature rich. Give credit where it is due. The Win32 API evolved from the OS/2 API developed in the late 80's in conjuction with IBM.
5) The reason Raymond Chen had to make the effort to be backwards compatible was that some published API calls were always different than the implementation (say API bug). Remember the DOS bug/feature that allowed TSR's? Remember when DDE turned into netDDE which turned into COM? This brain-dead logic has carried MS through until modern day XP. As an API/Library developer for my companies products, I've had to tell third parties I made a bad design decision (2) and you need to re-compile with the new library/API header. All of them appreciate and understand my mistake. Why can't Microsoft do this?
Great article, just some food for thought from a old time beer drinking hippie programmer. Gotta go, playing network freecraft with my ten year old.
Enjoy,
hoist by their own petard (Score:5, Insightful)
So if I'm interpreting accurately, Microsoft just pulled off a successful vaporware strike
The rest of Joel's rant is just way off track. Microsoft has ALWAYS pushed a new incompatible tech, while keeping old ones around. I mean hey even after I got COM, OLE2, COM+,
People predicted MS was going to put itself out of business when it came out with NT, because well hey while you're learning a new API, you might just switch to Solaris (now on x86!) or that exciting OS/2 thing... Microsoft succeeded for two reasons: it kept trying ("third time is the charm" really applies to MS) and its competitors kept screwing up. I don't actually see that changing significantly.
MS is hardly doomed
It was going just fine until...; (Score:5, Interesting)
Bullcrap! I bought heavily into MS's bull about being able to develop with Word and Excel macros in the Visual Basic scripting language. I wrote several applications for customers that had lotsa finely crafted Word and Excel macros. I bought the first round of Microsoft documents that told me how to do these things. I never bought the second round.
You know why? Because they changed everything in the shift from Office 6.0 to Office 97! All of a sudden, every API in the Visual Basic scripting language that underlaid Office changed; not just a little, but enough that a whole new shelf of documentation was needed. When I presented my clients with estimates of what was needed to rewrite the macros to make them work under the new Office they quietly asked that I restore Office to the old version. No can do! Microsoft had made that impossible!
Failing that, my clients insisted that it was my duty to make the macros work with the new version of Office no charge. This would have required rewriting them. Riiiiight! I was gonna do that! In the end, they went back to doing it by hand and I never got another job from them!
Developers! Developers! Developers! indeed! How many more times do you think I did anything with Microsoft tools?
Let me get this straight... (Score:5, Funny)
Technical community and pundits: OMIGOD the windows API is so crappy and kludgy and windows crashes a bazillon times a day and you shot my dog
Microsoft: no, it's actually YOUR badly written applications
TCP: OMIGOD it's still your fault
MS: That's ok we fixed it for you anwyay.
TCP: OMIGOD why did you waste all that energy on such and old and rotten API! You suck! HUZZAH! I'm throwing salt in your eyes
MS: Yeah, I know, we finally decided it was time to part with all that baggage and hired smart guys that you seemed to like and invented
TCP: OMIGOD why did you do this to me!? I thought you loved me!? I'm going to run off with my new lover "teh intarweb" where we will make complicated scientific visualization applications out of javascript and feed starving mouths with semantic web markup alone, and live in a utopian libertarian dream!
I don't buy it. I think Joel has entered the crank-o-sphere. While XUL shows some tentative promise as an application development platform, current web standards are pretty damn CRAPPY at creating rich interactive GUIs or applications of any complexity. That is why we see so much Flash cropping up.
I for one think
Re:Why it has to die (Score:5, Informative)
Say what you like about MS's evil ethics but *do not* mock their API docs [microsoft.com]. They're very good.
Parent
Re:Why it has to die (Score:5, Insightful)
Parent
Bizzare, yes. Undocumented, no. (Score:5, Interesting)
but I've always been able to find documentation on every part of it. Microsoft documentation is very good, and has always been.
I'm sure there are a lot of bizzare hacks and special modes that are not documented, but if you base your code off the documented APIs, you'll be fine.
Parent
Re:Why it has to die (Score:5, Insightful)
You're claiming that MSDN is impossible to read? I've been a programmer working in Windows development for years, using Win32 APIs, MFC, and various other bits and pieces. Say what you like about the interfaces themselves, Microsoft's documentation is, and always has been, comprehensive and remarkably well organised for something on that scale. Compared to typical *nix man pages or trying to sort out perldoc, it's paradise, and why the top-level poster thought giving the source code was at all equivalent to giving good documentation I have no idea.
Parent
Re:Why it has to die (Score:5, Insightful)
doesn't compare to much to "We'll give you the source code"
Microsoft Developer Network [microsoft.com] has comprehensive documentation about the Microsoft APIs. When I was developing for Windows platform, I never needed any documentation other than MSDN. And if you want source code, you can download the SDKs for free. Though it contains only sample codes, I wonder how many Linux developers looked at the sources of the APIs they use. I have never did such a thing.
Parent
Re:Why it has to die (Score:5, Insightful)
Comprehensive up to a point. In fact, not comprehensive at all. People have sold books [amazon.com], profitting from Microsoft's incomplete documentation. I think the grandparent post is somewhat exagerated in saying that it was Linux that made Microsoft put aside the API. However, in my particular case, it was the incomplete API documentation that made me stop using NT and start programming in Qt in Linux. I tried and tried, and there was no way I could make a data acquisition program I was writing to work well under NT 4. I did exactly what the MSDN documentation said. Then, in desperation, I tried to learn Qt. 20 minutes after starting to read the Qt documentation I had my first non-trivial working Qt program. That was in 1998, and I never wrote a MS-Windows program ever since. I have migrated with little effort my MFC programs to Qt/KDE. I only need three sources of documentation: qt3-assistant, Johnson & Troan's "Linux Application Development", and Rubini's "Linux Device Drivers". Plus the thousands of sites in the web where I can find source code for Linux, of course. A complete documentation is good, but nothing can replace a good set of examples.
Parent
Re:Why it has to die (Score:5, Funny)
Parent
Re:Why it has to die (Score:5, Funny)
*wipes away a tear*
Thanks... I needed that. If I had modpoints, you'd have +1 Funny right now.
Parent
Re:Why it has to die (Score:5, Informative)
I don't think he was saying you want to debug other people's stuff. If you have a full debugging version of all the libraries (your and other peoples) it is *much much* easier to debug problems.
And even though I may not want to debug other people's libraries and such, I have had to. This is how I have found bugs in things like PHP, mod_python and such. They were corner cases to those developers, but they weren't for my applications. I'm thankful I could track those problems down, because my application got back up and running again. Not usually the case when I have proprietary closed libraries.
Ciao!
Parent
Re:Why it has to die (Score:5, Insightful)
Parent
Re:Why it has to die (Score:5, Interesting)
Parent
Re:Why it has to die (Score:5, Interesting)
Most of my work these days is under Windows, and I will freely admit that on occasion I have used the source that Microsoft provides. That's right, I have the source to MFC, C library, ATL, WTL, etc. It's not due to lack of documentation though. I often debug in to assembly code, but it's normally to get to somewhere else (e.g. step in to the COM libraries to reach my COM code) and the debug symbols that are freely available normally suffice to give me enough context
Parent
Rose Glasses (Score:5, Interesting)
This is an Open Source fantasy. It simply isn't true no matter how much you love Linux (and I love Linux a lot). The API is not dead, it only seems that way to the Slashdot crowd who see thing through glasses with a unique prescription. Believe it or not, as of yet, Linux is not sweeping the world like a storm...
"It's open and documented such that developers feel comfortable using it and feel like they're getting a powerful suite."
This is only true for Open Source masochists. Building software that does not require the user to have intimate relationships with the OS to install, this is still a large issue that is more or less ignored by all the elitist "gurus" out there.
"One thing that Microsoft hope doesn't happen is Mono becoming the defacto standard and not the MS framework."
Honestly. This is not a troll. Is *anyone* actually taking this seriously? Mono is more or less a "If Microsoft can do it, OSS can do it better" type of deal. Mono is a tool in search of a problem. Write once, run anywhere is a fantasy that just does not provide any real world solutions to real world problems. The only reason so many people are using .NET is because Microsoft has made it the default environment, not because they have problems that only .NET can solve.
Parent
Re:Why it has to die (Score:5, Insightful)
OK, no offence but it's pretty clear that you've not done a huge amount of programming, at least, not with APIs of any size.
No API of any complexity at all is a "black box" - they are often backed by millions of lines of code, and that code, just like application code, will contain bugs and odd behaviours. The documentation will be incomplete - very few people can spec out a complex API to the degree needed to truly understand it, even when you have documentation coming out of your ears like with MSDN.
Even assuming the API is perfection itself, it'll always be lacking SOME feature you want. Openness of an API is a very important thing indeed.
Parent
GNU\Linux (Score:5, Funny)
What's with the backslash in GNU\Linux? You look suspicious to me, Microsoft boy.
Parent
Re:SourceCode != QualityDocumentation (Score:5, Informative)
KDE's are at http://developer.kde.org/documentation/library/cv
Thats every function call to program in KDE and Qt all completeley cross-refrenced, with examples.
Parent
Re:Prophecy (Score:5, Insightful)
If you were using something other than HTML and HTTP, you wouldn't be doing Web development; you'd be doing some other kind of development.
Macromedia Flash applications backed by SOAP look very interesting for apps requiring more GUI-like, real-time interaction. This is basically what Java applets were intended for.
Parent
Re:.NET & C# (Score:5, Interesting)
I program in Objective-C, using Cocoa libs under Mac OS X. ;-)
What's amazing is that Java combined with the hack-y nature of the Win32 APIs finally forced Microsoft to create something that's still not as good as NeXTStep was 15 years ago, and probably isn't ( yet ) as good as Java ( it's just optimized for it's single target platform ).
I'll leave for those who care to debate Java vs .NET. For me, that's a debate that is pointless unless .NET somehow becomes cross-platform, at which point I expect Bill Gates to burst into flames.
Parent
Re:Increased Irrelevancy, however. (Score:5, Informative)
Have a chat with Sun, BEA, HP, SCO, Oracle, Linus, or any bank about how "irrelevant" IBM is. I think you're in for an eye-opener.
Parent