Fog Creek Software
Discussion Board

Eric's article is lacking...


"All those layers of abstraction started contributing to our bug list.  I've been involved in a couple of projects which completely failed because Java was chosen."

As amazing as the .NET platform is, Eric's article doesn't actually explain anything with regards to the quote Joel selected for the front page. The list of abstractions is interesting, but when it comes time to make the leap from "my software is really complex" to "and that's why .NET is better than Java", he doesn't actually explain the "reasons" why this is so.

Coding in .NET is a dream, but to imply that the framework hasn't borrowed a lot of the pattern-based ideas found in the JDK is off-base. Further, if you're going to say something like "the project failed because Java was chosen," you should really try to explain why this is so, rather than just tossing it in at the end. I'm sure if we took a poll we could find some C# projects that failed because ".NET is just impossible to get right" or some other ridiculous sentiment.

I guess what I'm trying to say, Joel, is that I know .NET is really awesome, but let's not just post anything that has pro-.NET sentiment and a JoelOnSoftware twist - substance is good too.

Dan J
Monday, April 28, 2003

"I've been involved in a couple of projects which completely failed because Java was chosen"

How so?

Monday, April 28, 2003

It read like an advertising piece to me, or maybe I'm just too cynical.

"dotnet cured my cancer and saved my marriage"

"java stole my watch and killed my dog"

gimme a break
Monday, April 28, 2003

To be nitpicking, Eric seems not to understand TCP/IP correctly: he states TCP is an abstraction on top of UDP. Which is not true of course, TCP and UDP are both abstractions on top of IP.

Roel Schroeven
Monday, April 28, 2003

>"Eric's article is lacking substance."

Agreed.  His indepth analysis of the layers of abstraction was interesting, but he never does say exactly what it is about Java that caused his projects to fail.  He makes mention of the garbage collector, but he never goes into any detail.

He also implies that every nontrivial project he'd ever worked on in Java failed (though he never explicitly says it) and has come to the conclusion that .NET is always better for all projects though it sounds as if he's only implemented one non-trivial .NET solution.

After such an interesting breakdown of various layers of abstraction, for him to throw out such a whopper with zero explanation was dissappointing.

Monday, April 28, 2003

Actually Eric never says TCP rests on top of UDP, you misread it. Using the same logic you could conclude that he thinks DNS rests on top of SSL or Ethernet on top of Radio. I think he was just stating the various abstractions in Vault. I understand why you did misread it though, I thought the same thing at first given the Control Flow example at the top and how he refers to them as "layers".

As for Java, he is stating his experiences, not scientific evidence of Java's inadequacy. I think you guys might be reading too much into it. If you want him to elaborate on his Java experiences why don't you just email him?

Ian Stallings
Monday, April 28, 2003

I have a better idea, why don't you email him and report back your findings?

Monday, April 28, 2003

My biggest problem with Eric's article is this statement:

> Abstractions reduce performance.

> Writing in Java is faster than writing in C.
> But C code runs much faster than Java code.
> It's a tradeoff that you cannot avoid.
> All you can do is make the right choice.

Makes sense, doesn't it? Only problem is, it isn't true. At least not always. I'm not saying that Java is faster than C (though it might be as I'll explain in a second), but that abstractions can, and often do, improve performance. Simple example: the car abstraction is much faster than the lower-level walking abstraction.

As to programming language abstraction, choosing a higher-level programming language can often improve performance because it allows you to develop more efficient algorithms. Hand-coded assembly is often perceived to produce the best results, but the truth is that with modern CPU architectures, compilers often emit better code than could be done by hand.

Finally using somebody else's code doesn't only save a lot of time, but also buys that person's knowledge. Only a fool would assume that he can write better code than any library provider, even if he doesn't need to be as general.

Dan Shappir
Monday, April 28, 2003

Eric is talking about his pesonal experience, which I think is fair enough.

I can relate to Java's all to abstract nature causing problems in the final stages.  He lists problems with the Garbage Collector explicitly (he refers to it merely as Layer 11). 

I'm sure even the most evangelical of Java brewers would have to agree that Threads are also a source of much grief.  Just look at all the problems with the double checked singleton pattern ( )

I think .Nets advantage come from just one thing: there is only one CLR.  When coding for Java you have to code for the multitude of JVMs.

Of course, as the CLR matures, and it too starts to gain a little legacy drag it won't be looking quite so slick.  Sure, having a single producer will mean that it will never be quite as bad as multi-vendor Java, but this benefit is at a cost - total dependance upon Microsoft.

Things are so much easier without Hardware extraction.  Look at how much more juice the programmers of games consoles are able to squeeze out of their machines.  However, developers and customer accepted long ago that Harware independance was a price worth paying.  The cost of computers has dropped so quickly because of it.

Now the OS is the biggest single cost in a new computer, so OS independance starts to look more and more like a price worth paying.

Ged Byrne
Monday, April 28, 2003

How does garbage collection in C#/.NET compare to garbage collection in Java?

Beth Linker
Monday, April 28, 2003

A lot of people blame c++ for project failure when the real problem is their lack of understanding of the language.  Or worse, they just can't design a large project, and they blame the language.

I'd be interested in hearing Eric's side of the story, but not interested enough to email him.

Monday, April 28, 2003

Ged said "I think .Nets advantage come from just one thing: there is only one CLR.  When coding for Java you have to code for the multitude of JVMs."

True, but this is like saying there is only one Model-T so the fact that the engine fits makes it an advantage. 

I am merely pointing out that the proported goal of .net is platform independence, although what that means appears unclear.    (Do you really expect a Linux implementation to run as fast as windows?).  While writing to the specifics of a JVM (save IBM versus SUN), we can expect that we have selected where to gain performance.  Until a similar situation exists with .net, such a comparsion is meaningless.

Bob B.
Monday, April 28, 2003

Dan Sheppir: exactly how is a car an abstraction of walking?

(I know, I know, that wasn't your point, but it's still wrong IMO.)

Monday, April 28, 2003

"I am merely pointing out that the proported goal of .net is platform independence"

I'm not understanding what you mean by "platform" in that sentence.  I was under the impression that the purported goal of .NET is to implement a _new platform_.  Can you please clarify? 


Eric Lippert
Monday, April 28, 2003


What I mean is that you can expect things to work a certain way.

In Java, when dealing with threads all bets are off.  You have to code entirely defensively for them. 

Say somebody writes a complex mutlithreaded application on a JVM under windows.  They release it and then a customer running a JVM under Linux complains:  the app just hangs.  After some investigation it is discovered that the scheduler is running a single thread indefinately, because they are scheduled differenly on that OS.

The programmers look at the issue, and they discover a little note in the API that warns that this will happen.  Stupid damn Java, so difficult.  The developer is held responsible for not taking into consideration all possible platforms.

When the CLR finally arrives on Linux, in the same scenario the Linux CLR is held to blame.  The MS CLR is the one true CLR, and any other implementation would be expected to behave the same way.

Ged Byrne
Monday, April 28, 2003

Dan, an abstraction cannot be faster than the thing it is abstracting from.  Driving is not an abstraction of walking.

Hand coded assembly is often slower than the optimised assembly produced by compilers, but the language the compiler compiles is the abstraction, not the compiler itself.

The compiler converts the abstracted language to the lower level language.  Some languages, like Java are not compiled to native machine code at all, so must inevitably run slower. Java abstracts away the operating system, so optimisations aside, it is simply impossible to make a Java app run faster than a natively compiled app.

Monday, April 28, 2003

Nice to see my article got so many readers.  Thanks for the feedback.  Since my weblog has no discussion forum, I'd like to offer a few responses here if Joel's doesn't mind.

1.  Ask Joel to be sure, but I seriously doubt Joel linked my article because of its pro-.NET sentiment.  It simply appears to me that abstractions are a favorite topic for both of us.

2.  Yes, my atricle lacks "substance" if you were specifically looking for the details of why I was dissatisfied with Java.  I left those stories out intentionally because I wasn't really trying to write a detailed comparison between Java and .NET.  The point was that really tall piles of abstractions are really hard to get right.  In my own experience, Java's implementation didn't quite get the job done.  I'm deeply impressed with .NET so far.

3.  A car is *not* an abstraction built on walking.

4.  Most of the time in computer science an abstraction is slower than the layers on which it is built, but I wasn't trying to claim that this "rule" is without exceptions.

5.  Compilers *never* emit better code than could be done by hand.  Every assembler instruction available to the compiler is also available to the hand-coder.

Eric W. Sink
Monday, April 28, 2003

. Compilers *never* emit better code than could be done by hand.
I dont' think that's the point. They emit better code than usually IS (not could) be done by hand.

Monday, April 28, 2003

"I dont' think that's the point. They emit better code than usually IS (not could) be done by hand."

Yes, yes, I understand that.

This is a silly discussion.  My point remains:

Let's divide the world into two groups:

1.  Those who understand compiler output
2.  and those who don't.

If all of us in group 1 get together face to face and decide to stop misunderstanding each other, we will quickly realize that we all agree.

The guys in group 2 will be off in another room making wild guesses about the magic in today's compilers.  Some of them actually believe Java is faster than C because of some really cool aspect of Java's architecture.

Which group will make better technology choices?

Eric W. Sink
Monday, April 28, 2003

"the car abstraction is much faster than the lower-level walking abstraction."

Which is faster scaling a cliff?

Running a decathalon? Can a car fly to the moon? Hangglide? Ski?

Which has greater agility while turning?

Have you ever tried to engineer a bipedal robotic walking mechanism? If so, in your opinion was it easier to get working right than a car? If not, what would that suggest about its relative complexity?

Dennis Atkins
Monday, April 28, 2003

Eric, maybe I'm misunderstanding what you're saying, but you do seem clear in your opinion.

4.  Most of the time in computer science an abstraction is slower than the layers on which it is built, but I wasn't trying to claim that this "rule" is without exceptions.

I would say that it is a rule without exceptions.  It is impossible, _all optimisations being equal_, to make an abstraction faster than what it is abstracted from.

Monday, April 28, 2003

"I would say that it is a rule without exceptions.  It is impossible, _all optimisations being equal_, to make an abstraction faster than what it is abstracted from."

Yep, I would agree with that.  I was just thinking that if I made that claim I would need to define my terms more carefully and think hard about whether any exceptions exist.

But your assertion is intuitive.

Eric W. Sink
Monday, April 28, 2003

this discussion, and the fact that the software in question is yet another revision control system, makes being a programmer seem about as cool as being a tax accountant.

Monday, April 28, 2003

Eric, it's not an intuitive assertion it's simple logic.  I don't need to think hard about exceptions to the rule because none can possibly exist.

Monday, April 28, 2003

Eric, as someone who would like to grow and improve, I am very curious to know what you found lacking in Java.  It sounds like it might be 1) garbage collection in swing apps or 2) something at the language level.

Am I close?

Tuesday, April 29, 2003


I'm surprised this is generating so much friction. Any thing pro-MS, anti-Java is a standard Joel troll (just like anything pro-IDEA, anti-Eclipse/NetBeans/whatever is a standard me troll - by the way did you see Jason Hunter [Mr Servlet; important figure in the Apache Group] is now an IDEA convert :) ).

Joel makes a very strong case for using VB to develop CityDesk and another strong case for not providing a MacOS version, but his anti-Java argument isn't very strong because by his own admission he only tinkered with it in 1997.

The question I have for Eric is this - do you think your .NET project would have been as successful if you had not worked on the three (or however many) Java projects beforehand? In other words, is it not entirely possible that one firm could have three false starts with .NET and go onto develop a successful Java-based product? Experience counts - .NET and Java are built around a number of the same concepts and the lessons learnt in your earlier projects are probably a good example of the principle that you'll always throw "the first one" away.

Walter Rumsby
Tuesday, April 29, 2003

Joel the Troll, who would've thunk?

I remember working in a very resource-poor environment, and learned that getting performance required abstraction-breaking.  I'd have things do doubletime, like having the code that generated the mountain also pretend to be an AI.  (People really thought the AI was learning, which it wasn't.) 

I'd like to think I'm more mature now and think that abstraction is the only way to get reasonable speed improvements.  Abstractions are constraints, and constraints are information, and information is the soul of optimization.

Tuesday, April 29, 2003

"Dan, an abstraction cannot be faster than the thing it is abstracting from."

I don't think that always holds. In "Unauthorised Windows 95", Andrew Schulman talks about the virtual machine performance anomoly, whereby software runs faster under a VM than it does under the native hardware.

John Topley
Tuesday, April 29, 2003

The paradox says that there is an exception to every rule, including this one.

Is this one of those exceptions?

I think the key argument for code at an abstract level having better performance than hand coded assembly is that the abstract code is able to take advantage of future hardware improvements.

As you say, there are no instructions available to the compiler that are not available to the programmer.  However, there may be instructions in the future that are available that the programmer cannot be aware of.

For example, I could write some highly optimised code for generation 1 processor.  One version is in assembler, the other is in C.  The task involves lots of block copying. 

Generation 2 processor introduces a new block copy instruction that is significantly faster. 

My assembly code will never take advantage of this new instruction without a manual rewrite.

The C code, if recompiled using a compiler optimised for the G2 processor, will take advantage of the new instruction.

Therefore, in the long term, the C code is more efficient than the machine code.

In the short term, I think it really is impossible.

Ged Byrne
Tuesday, April 29, 2003

Well, I read through parts of his blog and it appears that Eric is a successful entrepreneur who has worked on some very cool software projects (i.e. early browser software).

At first, I wondered why this person was using programming languages such as Java and C# instead of C/C++ then I checked out the system requirements for his SourceGear Vault product.

Seems like he going after a very specific type of customer and is betting the farm on the belief that .NET software development will become very popular in the next year or so.

One Programmer's Opinion
Tuesday, April 29, 2003

The various people that stated that car is not an abstraction of walking are, of course, absolutely correct. Although, if your intention is getting from point A to point B, then both are methods of accomplishing this task and a car is both at a higher-level of abstraction and faster.

But getting back to the point I was actually trying to make: if you view a high-level programming language as an abstraction of the assembly language it's compiled to, then yes, using the higher abstraction can result in faster code.

The reason for this is that major performance improvements cannot be achieved through bit twiddling alone. In order to accomplish such improvements you generally need to replace the algorithm. For example, for a large enough sequence of values the finest handcrafted assembly implementation of bubble-sort will be slower than quick-sort done in C#.

While it is theoretically possible to code any algorithm and data-structure in assembly, it is close to impossible in practice. So if you have a company X doing everything in assembly and a company Y using C# with all the abstractions underneath, for a complex enough problem company Y is likely to produce more efficient code.

Another reason is that by using a higher abstraction, company Y will have more time to do profiling and locate the real performance bottlenecks and invest more time in optimizing only those. By coding everything in assembly, company X will have wasted lots of time optimizing sections that don't impact performance at all.

Dan Shappir
Tuesday, April 29, 2003

I would actually take my previous statements a bit farther. Leveraging certain abstractions actually expands your horizons to encompass types of solutions that you would never have conceived of otherwise.

In the context of programming languages, eventually all code is translated to machine instructions, and yet various high-level languages are conceptually different from each other. If everything boils down to machine code, why do we have C++ and Perl and LISP and Prolog and Icon and Smalltalk?

I would argue that the type of solutions that become apparent when programming using LISP, for example, aren't apparent when using C++, certainly when using assembly.

Yes, you could compile the LISP code the assembly and then optimize the resulting code by hand, but then you *are* using the abstraction (and also have unmaintainable code).

Dan Shappir
Tuesday, April 29, 2003

Not a big deal but, Ian Stallings wrote: "Actually Eric never says TCP rests on top of UDP, you misread it".

From the article: "33. UDP.  TCP is built on UDP, which is even lower level network protocol"

I think Eric confused UDP with IP (since IP is left out).

Tuesday, April 29, 2003

Well said choppy, but I would say it's actually a little LESS than being a tax accountant. 

The tax codes contain numerous changes every year, after all.

Tuesday, April 29, 2003

I agree with the principle that well-worked abstractions can never be faster than perfect implementations in native code.
And if we all had five years for every software project that would be a valid point.

However, we find ourselves in a world of 3GHz processors, where the primary demand is GUI applications (where 90% of the time is spent waiting for human input), and software schedules implementing the "time is money" paradigm.

Sure, if I spent another year on that six month C# or Java project I could make it 15% faster. But who cares? In another year processors will be 30% faster anyway...

Bottom line - unless you're coding realtime or device drivers, I think this is a pedantic debate. :)


Tuesday, April 29, 2003

[I have a better idea, why don't you email him and report back your findings? ]

1. Keep quite while grown folks are talking.
2. Don't mistake my kind words for a lack of true grit.

[Not a big deal but, Ian Stallings wrote: "Actually Eric never says TCP rests on top of UDP, you misread it".]

I was wrong.

Ian Stallings
Tuesday, April 29, 2003

I posted a followup on my weblog for those who care.  It is mostly some responses to the Java folks, but I also acknowledged and corrected my UDP vs. IP mistake.  :-)

Eric W. Sink
Tuesday, April 29, 2003

It's funny everyone chooses java's threading to pick on... it's actually one of the most well-thought out threading abstraction models out there.  The bulk of cross-platform threading issues boil down to 2 points: understand how to properly synchronize access to objects and methods across threads, and don't rely on the OS to preemptively schedule threads.

Tuesday, April 29, 2003


When you are developing mobile apps (and they are HOT nowadays) the abstraction vs. performance debate is far from pedantic. On the other hand, people do get too worked up when we start comparing .NET and Java.

Marcos Rubinelli
Tuesday, April 29, 2003

Marcos - understood, but aren't all the top development platforms 4G languages? I mean, back to a small, tight application environment but you're still not working in assembler or pascal, right? ;-)


Tuesday, April 29, 2003

Someone above said it's simply impossible for a virtual machine application to run faster than a native application.

I'm not an expert, but a virtual machine could do optimizations that would be impossible for a piece of hardware to do because the hardware can't change itself.

A while back I read about some CPU, from HP I think, that they were able to run faster by having the CPU emulate itself and do some optimizations that the chip itself could not do.

Of course, I can't find the article now, but it was pretty interesting.

Tuesday, April 29, 2003

And you should not mistake my sarcasm for a lack of true sincerity.

Tuesday, April 29, 2003

Thanks for the update Eric,

now if only you would do full content in your RSS feed, we might all stay subscribed ;-)

Just me (Sir to you)
Tuesday, April 29, 2003


"Sure, if I spent another year on that six month C# or Java project I could make it 15% faster. But who cares? In another year processors will be 30% faster anyway..."

People often make claims like this, however in practice it doesn't bear out: People will often shun a product if it is perceptibly slower than a competitor. Case in point is the dearth of Java applications on the desktop: Even on the fastest of today's processors Java applications still feel sloggy and non-responsive, which is why most large Java applications were a non-starter. Indeed there really hasn't been any large scale .NET Windows Forms applications rolled out, so who can really say how a user will feel when they can choose between a potentially faster binary application and a IL .NET application? (I make no statement here about the speed of .NET, though it does seem to be dramatically faster than Java in the UI).

Another example: I installed and use for development Mozilla, however I don't use it for day to day browsing as it just "feels" sloggy- a barely perceptible lagginess that makes me much more inclined to use Opera [though 7 seems a little laggier than 6] or Internet Explorer.

Dennis Forbes
Tuesday, April 29, 2003

"Sure, if I spent another year on that six month C# or Java project I could make it 15% faster. But who cares? In another year processors will be 30% faster anyway..."

Well, the real argument is not that processors will be 30% faster, but that in another year you will not even be working on the same project, so who cares?

Tuesday, April 29, 2003

Just a note on the "running faster in the VM than on the native hardware" comments. There used to be a book out there about high-performance coding in C++, the title of which escapes me at the moment. In that book, the author developed a small interpreter for a bytecode language to implement a spreadsheet language. He then did benchmarks between the interpreter and hand coded C that implemented the operations.

The interpreter won the timing tests handily.

The secret had nothing to do with optimizations, special instructions, or anything of the sort. The secret was simply this: the intepreter + the bytecode program could fit completely within the processor cache, avoiding TONS of memory access delays. The C program was bigger, and didn't fit in the cache, so it paid the price of those cache misses.

So it's kind of funny. Using one layer of abstration (the intepreter) to get around another layer (the processor cache).

Chris Tavares
Tuesday, April 29, 2003

I apologize in advance for the following digression, but I can't help myself.

Ged wrote: "The paradox says that there is an exception to every rule, including this one. "

This is not, however, a paradox. Consider a universe of "rules", which contains:

Rule Omega: There is an exception to every rule.

Can rule Omega be true?

1. For a rule to be "true", it must apply to all of its cases equally (for omega, a "case" is a rule).
2. For rule Omega to be true, there must be a rule Alpha to which it does not apply.

This is what appears to be a paradox -- a rule must apply equally to everything it covers, but omega must NOT apply to Alpha, one of the things it covers.

However, by a bit of self reference we can solve the problem:

First note that Omega is really the set of Omega-1 (For every rule, Omega-2 applies) and Omega-2 (There is an exception to this rule).

Let Alpha be Omega; then:

1. Omega applies to all rules (every rule has an exception, including itself)
2. There is a rule, Alpha, to which Omega-2 does not apply (there is no exception to Omega).

Anyway, you can really argue this many ways, but in my opinion that's the escape hatch from the paradox.

I now return you to your regularly scheduled language debate. Sorry for the inconvience!

Steven C.
Tuesday, April 29, 2003

From the article:  "But layer 11 [GC] was problem-free, quite unlike its Java counterpart."

Is Eric blaming the GC for "a couple of projects which completely failed because Java was chosen"?  I've only run into a GC-related bug in a Java project once, and I consider it a special case and my fault*.  And I agree with the poster who favors the Java threading model.  The primitives (synchronize, wait, notify) are simple and powerful, and easier to use than WaitForSingleObject, CreateMutex, CriticalSections, Events, etc.

* It had to do with JNI code that associated resources (e.g. a thread) to a Java Object.  Since the Java object was so lightweight, it didn't exert pressure on the GC commensurate with its overall resource "weight" [to mix metaphors].  But I don't blame the GC for this.

Tuesday, April 29, 2003

[And you should not mistake my sarcasm for a lack of true sincerity]

I wont, I'll simply mistake your anonymity for cowardice.

Ian Stallings
Tuesday, April 29, 2003

Well, I bet I know one of Eric's "failed Java projects." SourceOffSite. This is a package you can add on top of sourcesafe, and puts a real client-server model in place. In theory this lets you work much faster from remote locations than using normal sourcesafe.

The problem was that the server was written in Java. Using the MS JVM, specifically, since it had to talk to the SS COM interfaces. The version we were originally using leaked memory like a sieve, and instead of running the GC would just crash every couple of days.

If that's not a problem caused by the GC, what is?

Chris Tavares
Tuesday, April 29, 2003

`Oh dear,' says Ged, `I hadn't thought of  that,'  and  promptly vanished in a puff of logic.

Ged 'Douglas Adams' Byrne
Tuesday, April 29, 2003

Now I am anonymous no more, just like you!  Dare you challenge me to a bout of fisticuffs?

Jim Nastic
Tuesday, April 29, 2003


Eric lists SourceOffSite as a success in his follow up post.

Ged Byrne
Tuesday, April 29, 2003

<troll>Chris claims that the Microsoft JVM leaved memory like a sieve and therefore Eric's project failed, while Microsoft's implementation of the C Sharp CLR seems to work properly.

Wow. Microsoft implementation of a competitive technology is buggy. I'd never have guessed.</troll>

Eric mentioned various Swing horrors, including a printing crash, and this jibes with my experience.

I was the technical lead on JProbe Threadalyzer and the Development Manager for the entire JProbe suite, including a most excellent Memory Debugger. Our managers insisted we write the UI in Swing, and for better or for worse we had plenty of chances to "eat our own dogfood":

One of the reasons JProbe does a decent job of analyzing Swing applications is that we needed our own tools :-)

Reginald Braithwaite-Lee
Tuesday, April 29, 2003

[Now I am anonymous no more, just like you!  Dare you challenge me to a bout of fisticuffs]

Pistols at dawn good sir.

Ian Stallings
Tuesday, April 29, 2003

Well, I guess the definition of "success" differs greatly from a vendor to a customer.

We used SourceOffSite because it was the only product that did what we needed, but we pretty much hated it. We went so far as to write a program to bounce the SOS service once a day just to get around the crashes.

Chris Tavares
Tuesday, April 29, 2003

I suppose Chris is right.  Success and failure can depend a lot on perspective.

We've sold SOS to many, many users, and almost all of them really like it.

But that doesn't change the perspective of those few customers who have had a bad experience.

On behalf of SourceGear, my apologies to Chris for the trouble you had.  If it's not too late to resolve the problem, let us know and we'll try.

Eric W. Sink
Tuesday, April 29, 2003

Well, you did eventually resolve the problem - at least the crashing went away as far as I can tell.

And the company I was working for is gone now, so there's not much else to be done, unfortunately. But it's nice to offer.

Chris Tavares
Tuesday, April 29, 2003

Chris, re the VM vs Native example.  That is merely another form of optimisation.

I wrote in an earlier post "all optimisations being equal", an abstraction cannot be faster than what it is abstracting.  If you understand what an abstraction is, it is not difficult at all to see why it is impossible for an abstraction be faster.

The people that visit this board are an abstraction of software professionals from the general population.  Are we suddenly not people because we have become an abstraction?  Do we walk or talk faster?  Of course not, because underlying that abstraction is the real original object presented in a particular way.  When I invoke the Programmer.TalkBullshit() method on myself as an abstraction, I am calling the underlying Person.TalkBullshit() method.  Clearly it is impossible for the abstraction to behave any differently (or faster) than the object it is abstracting from.

You might optimise your abstraction.  For example, imagine a Driver as an abstraction of a role a Person might perform.  We might have a FindKeys(Car) method on our Person and a GetCarKeysFromPocket() method on our abstraction, the abstraction will be quicker because it has cached the Keys in the Pocket, but this is not what you might expect.  The extra function GetCarKeysFromPocket() is *not* an abstraction,  it is a new 'thing' altogether. 

The way it is presented is a convenient abstraction of a function a person might perform. But this is an abstraction of the concept of a person, not an abstraction of our Person object.  Last time I checked, one concept doesn't run faster than another.

Tuesday, April 29, 2003

The example you provide of an abstraction being faster than its basis is actually an example of something else - perceived speed.

We can make abstractions seem to be faster, especially for UI purposes, by pre-loading and so on. This is vital for Java applications.

However it doesn't prove the point you were trying to make. If abstractions can be pre-loaded, so too can native implementations.

Tuesday, April 29, 2003

There's this argument floating around about assembly programs always being faster than their more abstract counterparts in the trivial case.  I'm willing to demonstrate that false.

We assume that a property of a program is its specification.  (That's a reasonable assumption, because that's always part of correctness proofs and a programmer's job.)  That specification may include the statement that a certain percentage of programmers in the world must be able to modify the program in specified ways, within a given time period.  All I need to demonstrate is there are specs where the least abstract program must lose performance in order to meet the specifications, enough to be slower than a more abstract one.

Sorry, this is what I do when I have some minutes on my hands...

Tuesday, April 29, 2003

Am i the only person that actually READS the postings? 

It's obvious that many contributors to this thread have only skimmed others posts and applied their own facile interpretations without even attempting to understand what was written.

Oh well, par for the course on the Internet.

<facile interpretation/>

Wednesday, April 30, 2003

<retort type="witty"/>


Brad Wilson (
Wednesday, April 30, 2003

It might be possible for an abstraction to be faster than the layer beneath it, but it requires that the abstraction be able to operate at a level that would be otherwise inaccessable.

2 examples:

If a processor didn't have the machine language abstraction, you would have to send a lot more data to it to set all of the important switches to move those bits around.

If in a network, you didn't have certain abstractions, you might have to send a program along with your data to some remote switch, rather than it already knowing what to do with the data you send it because of some known protocol.

In other words, if you have layers that operate at different speeds, then pushing a layer of abstraction down to the faster layer can majorly save time.

In practice, an abstraction may be able to improve performance by being able to imply certain facts and create tighter code than "typical" coding at the lower level.  However, some guru probably has the power to imply even more facts.

Keith Wright
Wednesday, April 30, 2003

> However, some guru probably has the power
> to imply even more facts

The implicit statement here, if I understand it correctly, is that given enough time a programming guru could write the assembly language equivalent of any high-level programming language code. It is my contention, as I have expressed it above, that this is simply not true. This is because:

1. Working at a higher level allows the developer to envision and express idioms that would be beyond her grasp had she been forced to work at the assembly level.

2. Working at a higher level allows the developer to leverage library code created by people smarter than she is, or having knowledge that she lacks.

3. Working at a higher level would allow the developer to create such a volume of code that would have taken her more than one lifetime to create in assembly language.

4. Working at the lower level would have caused the introduction of so many bugs that the software would never work anyway.

It is my contention, therefore, that for large enough and complex enough applications working at a higher-level of abstraction always results in better, and thus usually more efficient, code. If this isn't true it just means you've climbed up the wrong branch in the abstraction tree.

Dan Shappir
Thursday, May 1, 2003

*  Recent Topics

*  Fog Creek Home