Fog Creek Software
Discussion Board




API War: Joel goes into the weeds

Joel goes out into the weeds more than a few times in his essay.

"... there's so much more great desktop software available for Windows than Mac that it's very hard to be a Mac user."

I know Joel shut this down already by calling us "Peppers," but he's wrong. It's easier, not harder, to be a Mac user. Most computer users don't choose their computers based on available applications or operating system; if they get to choose at all they base their decision on sales and marketing and what their friend the computer expert says. More people use Windows because more people use Windows -- it's an effect of being the dominant commodity, not a matter of deliberate and informed choice.

"It's why so few applications from the early days of the Macintosh still work."

Not true. Lots of applications that were written for 68K-based Macs still work on G5-based systems. I can run Omnis 3, which dates from 1985, on my G4 iBook, and the only thing it can't do is print, because it wrongly assumes it can just write text to the serial port. And I know Apple told them in 1985 not to do that.

"For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to. Even though somewhere in Inside Macintosh, Apple's official Bible of Macintosh programming, there was a tech note saying "you can't do this," they did it, and it worked, and their programs ran faster... until the next version of the OS came out and they didn't run at all. If the company that made the application went out of business (and most of them did), well, tough luck, bubby."

I know a little bit about that, because I was one of those Apple engineers telling developers what they should not do. Some of them (Microsoft, Adobe, Aldus come to mind) got Apple to patch the OS to prevent important applications from crashing. Other developers weren't so privileged. If you ignore the stop signs eventually you will crash, and Microsoft tells developers the same thing; they may bend over backward to save Sim City -- a major application -- but they won't do it for me, or I suspect for Joel.

In my experience at Apple almost none of the developers who went their own way did it to speed up their code. They did it because they were ignorant or lazy. Their old apps don't run today, and a lot of them didn't run back then. As a Macintosh developer, Microsoft was determined to use their own compatibility layer that would let them move most of their source base between Windows and Mac OS; that layer was broken from the beginning and those apps will not work on modern Macs. I could compile a long list of old Mac applications that still work. And I have plenty of "old" Windows programs dating from Windows 98 that don't work on my XP machine, some of them from developers like Symantec and, yes, Microsoft that should have known better.

I'll also mention that Windows and Windows programs often fail to survive hardware upgrades because Microsoft doesn't control the hardware platform, and companies that made video cards or sound hardware three years ago are gone, or no longer writing drivers for their old stuff. Apple doesn't have that problem. I know my closet has a lot more unusable PC hardware and software than Mac stuff.


"The real significant productivity advance we've had in programming has been from languages which manage memory for you automatically."

If that's the case why did it take so long for us to discover it? We've had memory managing languages for 40 years. Garbage collecting memory managers for C and C++ have been around for a long time but never caught on

I have my own opinion: garbage-collected C/C++ is just as hard to master as C/C++. Lisp is equally hard to master. Java and the .NET languages, and Visual Basic, are attractive to management and project managers because they allow less-skilled programmers to write working code, and bugs in VB or Java programs are much less likely to crash the computer. That's not to imply that VB or Java or .NET programmers are all amateurs, but those languages do have big enough training wheels (or safety nets) to lower the bar. Corporate IT departments can get their projects done with cheaper and less cranky (i.e. younger, hungrier, outsourced) developers. Web development has the same appeal to management, AND it eliminates a lot of costly installation support and user screw-ups that result in phone calls and returns.

"Whenever you hear someone bragging about how productive their language is, they're probably getting most of that productivity from the automated memory management, even if they misattribute it."

They, and you, misattribute the benefits to the language. The most significant improvement in my opinion is not in the languages per se, but the improved quality and scope of the libraries (APIs). When I moved away from C/C++ to Python it wasn't because I couldn't handle C++ memory management, though I won't dismiss it: garbage collection is a big improvement. It was because Python has richer data structures (hash maps/dictionaries and lists, for example), and it has libraries written at a useful level. .NET extends those advantages to all supported languages, with the additional plus of mixing and matching languages, so all of a sudden C# programmers can take advantage of the much larger world of Visual Basic components.

"...my experience has been that Visual Basic is significantly more productive. Often I've written the same code, once in C++ calling the Windows API and once in Visual Basic, and C++ always took three or four times as much work. Why? Memory management. The easiest way to see why is to look at the documentation for any Windows API function that needs to return a string. Look closely at how much discussion there is around the concept of who allocates the memory for the string, and how you negotiate how much memory will be needed. Typically, you have to call the function twice—on the first call, you tell it that you've allocated zero bytes, and it fails with a 'not enough memory allocated' message and conveniently also tells you how much memory you need to allocate."

You're describing bad library design, not a memory management problem. Visual Basic is just better than C++ at hiding the problem.

Joel observes:

"No matter how consistent Microsoft is in their marketing message ('just use .NET—trust us!'), most of their customers are still using C, C++, Visual Basic 6.0, and classic ASP..."

And then explains why he isn't using .NET:

"And personally I still haven't had time to learn .NET very deeply, and we haven't ported Fog Creek's two applications from classic ASP and Visual Basic 6.0 to .NET because there's no return on investment for us. None."

Perhaps other developers are in the same boat; I would guess that Fog Creek isn't the only software company looking for the ROI in .NET. The ROI is there mainly for web applications and new development; few developers will rewrite their working apps in .NET (or anything else) until they have to.

"Microsoft would love for me to stop adding new features to our bug tracking software and content management software and instead waste a few months porting it to another programming environment, something which will not benefit a single customer and therefore will not gain us one additional sale, and therefore which is a complete waste of several months, which is great for Microsoft, because they have content management software and bug tracking software, too, so they'd like nothing better than for me to waste time spinning cycles catching up with the flavor du jour, and then waste another year or two doing an Avalon version, too, while they add features to their own competitive software. Riiiight."

Oops, a conspiracy theory creeps in, and Joel imagines Fog Creek to be a bigger blip on Microsoft's radar than it probably is. If you get hit by a train, chances are the train wasn't aiming for you in particular.

"Nobody (by which, again, I mean "fewer than 10,000,000 people") wants to develop for the Windows API any more. Venture Capitalists won't invest in Windows applications because they're so afraid of competition from Microsoft."

Venture capitalists aren't investing in much of anything these days, but I'm pretty sure developers of pure web applications have an even harder time getting investors interested than those developing Windows desktop apps.

"And most users don't seem to care about crappy Web UIs as much as I do."

This is what snotty C/C++ developers -- to say nothing of Mac users -- have said about Windows and Visual Basic for years. Maybe Joel doesn't have his finger on the pulse after all.

Most users care about getting their job done, as Joel pointed out in the beginning of the essay. They adapt to suboptimal UI; Microsoft has conditioned them to do so.

Greg Jorgensen
Wednesday, June 16, 2004

Wah!  Pass the cheese...

Karl E. Peterson
Wednesday, June 16, 2004

Great rebuttal to Joel's article, Greg.  I used to be a Java developer and my company loved the fact that they could deploy the code to the server and allow all 1500 users spread over the country to access it via an Intranet.  The software was previously written in VB and CDs were sent out to each user with each update which the user had to install themselves.  Talk about a major headache!

Of course, if you're Paul Graham you develop the software in LISP on a hacked version of Apache right from the get-go, but my company doesn't want to pay for a Paul Graham.  They want cheap fresh college grads or programmers with a few years of experience that can start writing workable code after reading a book.  That's what Java allowed them to hire.

the real world
Wednesday, June 16, 2004

> On Joel sticking with ASP

How people do productive programming in ASP with VBScript is beyond me.  I did everything to avoid it like the plague before .NET came out.  The problem with VBScript is it doesn't have a consistent theoretical model.  I can't just guess at something because the way to do something is often totally random. 

It seems like for every piece of functionality they went to the first person they found and said:

"Write five lines to read a text file." 

And that's what went into the language. 

My guess is the grammar for the language is complete mess of special cases, and can't be specified in less than 100 lines of BNF, if it can be specified in BNF at all. 

In my opinion the power of languages like C and Python lies in their consistency.   

Ok 'nuff posting for today.

christopher baus (www.baus.net)
Wednesday, June 16, 2004

The irony is that in the real world it would be cheaper to hire a few Paul Graham's than it is to hire a bunch of so-so programmers. The real problems are 1) few companies can identify the Paul Graham's of the world (at least before they are famous), and 2) there aren't enough of them for the bigger companies anyhow.

So they hedge their bets and go with Java -- a low productivity language, but one which is relatively robust, has plentiful libraries, and which "everyone else is using". Most programmers work in corporate IT, and corporate IT is as much about politics and avoiding career-sinking disasters as it is about getting the job done well. (And even so, look at all the EJB train wrecks...)

Java isa big step forward compared to C/C++, but only because their productivity was terrible to begin with.

full-time java guy
Wednesday, June 16, 2004

As I read the original post going on about Microsoft using a broken layer (of cross-platform code) to write Macintosh applications, I had to smile. The comment is no doubt true; but I've been using Microsoft Word 5.1a on my flat panel iMac (running in Classic), and it runs better than it ever did on my old Performa.

For what it's worth, I still think that particular version of Word represents the best word processor program ever. It's fast, full of useful features (with no clutter), and uses only a tiny bit of memory.

Here's to writing applications with legs!

Mario Diana
Thursday, June 17, 2004

Right on Greg.

Joel is pretty much off track with this article. More and more I get the impression that he's a rather average engineer - with a big mouth.

His preferences, his style, etc. I'll never forget the "exceptions are bad" article...

Nicky
Thursday, June 17, 2004

Joel is a very smart guy; it takes a small person to outright insult him.  But I'll admit that he has been coming across more and more as an "old man."  The kind of person who has has enough of change and wishes things were more like they used to be.  For example, he wrote an installer using raw Win32 calls, he doesn't like exceptions, he generally puts down .net.  Okay, but at the same time he also is fully behind automatic memory management, so I can't pigeonhole him perfectly :)

Junkster
Thursday, June 17, 2004

It was not my intention to insult Joel. I don't know him, but from reading his essays and his book on interface design I've concluded that he is a smart and experienced programmer with some strong opinions. And he can write a good essay. That's why I visit this site.

Joel has his opinions and prejudices, and so do I. Reasonable people can disagree.

Greg Jorgensen
Thursday, June 17, 2004

Mario Diana wrote:

"As I read the original post going on about Microsoft using a broken layer (of cross-platform code) to write Macintosh applications, I had to smile. The comment is no doubt true; but I've been using Microsoft Word 5.1a on my flat panel iMac (running in Classic), and it runs better than it ever did on my old Performa."

I'm not positive but I believe that version of Word was written native for Mac OS, not ported from Windows. Or perhaps the Microsoft Word-specific patches Apple put into the Mac OS survive in Classic. In any case you prove the point I was making: plenty of older Macintosh apps still work, including important programs like Word.

Microsoft employs more Macintosh developers than any other company except Apple. MS has produced some of the best quality Mac software, with a few clunkers here and there.

Greg Jorgensen
Thursday, June 17, 2004

Word 5.1a was great running on my MacIIcx with an Apple Portrait display. Even back then, some Mac folk where complaining Word 5 had become too bloated (If I remember correctly Word 4 fitted onto a 1.44Mb floppy disk). I believe Word 6 was the one where they tried to unify the codebases more. It ran slow as molasses. Actually, this was more appearance than reality in a way. Especially the boot time of the program was excessively long. What didn't help was that this was the time the Mac was transitioning from the M68K to the PowerPC. Those first generation PowerPC's were dead slow, slower in fact than the previous generation 68K Mac's. Apple just didn't finish enough of the OS transition in time, and had to emulate too much. It was around this time I started to get real doubts about the platform, while on the other side of the street, the Windows platform was coming along nicely. It would take many, many years before Apple was successfull in bringing out a decent OS again. OS X looks like a contender again, but so far I'm happy to stay in post 2K Windows land.

Just me (Sir to you)
Thursday, June 17, 2004

> My guess is the grammar for the language is complete mess of special cases, and can't be specified in less than 100 lines of BNF, if it can be specified in BNF at all. 

It's unclear to me why the number of lines it takes to specify a BNF of the language is relevant to anything, but I suspect that it would be a pretty small BNF.  (We've never actually written a BNF for VBScript -- never needed to.)

I don't know what exactly you mean by "special cases" -- if I recall correctly, there are no lookahead weirdnesses in VBScript like there are in JScript. There are a few "special cases" due to old bugs that couldn't be fixed for backwards-compatibility reasons -- like, bizarrely enough, it is legal to put a function declaration inside a conditional statement.

I have in front of me right now a 100% correct hand-built C# implementation of a recursive descent VBScript parser -- draw whatever conclusions you like from these statistics:

* the scanner recognizes 182 distinct tokens, many of which are illegal in VBScript but reserved for compatibility with VB -- see my recent blog entry on the subject for details.

* there are 27 distinct operators and 13 precedence levels

* there are 24 different kinds of statements in VBScript

* the scanner is 927 lines of C#, not counting the token declarations but counting the legal character tables, which are lengthy.

* the parser is 1627 lines of C# -- note that the parser does lots of analysis which could in theory be deferred to a later step, such as ensuring uniqueness of function names, checking property get/let/set methods to ensure consistent argument counts, etc.  That complicated the parser somewhat.

I don't think any of those are out of line for a small, simple language with a straightforward syntax, like VBScript. 

I am considering putting my C# implementation of the VBScript parser up on the internet, in the same spirit that Paul Vick is doing so with his VB.NET parser.  I'll probably do that after I come back from my summer vacation in July.  Watch my blog for details.

Eric Lippert
Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home