Fog Creek Software
Discussion Board




Please, hold my hand...

Okay, humor me for a few lines as I lay out the chronology (of which most of you are familiar):

Discreet transistors >> Programmable microprocessors.  The crowd: "what's the point, we can do all this stuff more efficiently in silicon; besides, software people lack the technical skill to really understand what's going on under the hood"

Assembly >> C.  The crowd: "Are you kidding?  Someone is going to accomplish the exact same thing and use way more memory and execute 100% slower?  What a waste.  These people even want to call bloated standard libraries instead of writing their own!"

C >> C++.  The crowd:  "There's nothing you can do in C++ that you can't do in C".

C++ >> Java.  The crowd:  "Java's way too slow and the libraries are awful".  (note, the crowd was on to something here)

C++ >> C#.  The crowd:  "What, I can't even manage my own memory?  Why would anyone want something so slow and bloated.  It doesn't even have obscure feature X."

Java/C# >> XYZ.  Anyone have any idea what XYZ is?

=========

Having seen most of these transistions, I've resigned myself to them.  Progress marches on and each layer, silicon, ASM, C, C++, managed code, still has its place and is still used for the problem domain it's best suited for.

My question is:  Why do people think this is a "bad thing"?  If a technology comes along and offers to hold my team's hand and remove obstacles (memory leaks, consistent library, etc.), why shouldn't we let it?  In the end, most transistions succeed, and I predict "managed code" (C#/Java) will be one of them.  If no one ever held our hand, we would all still be assembly developers.

Bill Carlson
Friday, April 19, 2002

I fear change in any form.

Doug Withau
Friday, April 19, 2002

Surprisingly, I'm going to reach out, pat Doug and the back and let him know that he has the right attitude.

There is a lot of change for change sake in this industry.  If we didn't fear the hype gods, we would be rewriting Photoshop and Quake in XML/DHTML.

So, whether Doug was being sarcastic or not is irrelevent.  Fear is good.  Fear after the writing has been on the wall for 5 years is bad.

Bill Carlson
Friday, April 19, 2002

> Why do people think this is a "bad thing"?

Why assume it is a good thing? We tried and failed a Java project (for a client, that Java might have been good at). Maybe that was a peopleware issue (the kind of person interested in Java is the kind of person who is interested in moving on). Anyway, easy IDEs make it easy to begin a project. Can you maintain it, can you debug it, can you scale it, can you ship it, will the customers accept it... easy to begin a project, not always so easy to end a project. Joel himself made an argument similar to this one, when he defended the "not invented here" syndrome.

Christopher Wells
Friday, April 19, 2002

Christopher makes a good point.  I was using specific languages as examples, but my thinking was directed at the greater extent to which we as developers are isolated from the machine.

The fact that many Java implementations were not usable for large app development does not invalidate the benefits of garbage collection, for instance.

The newer languages and platforms move the developer away from messy internals.  This has drawbacks (performance, impossible to debug framework problems).  But for the most part, I'd say "bring it on".

In 10 years, manually freeing memory will be as arcane as creating your own custom stack frame is today.  This is just the writing on the wall.

The developer that understands the bare, naked internals will always be a better developer, though, even if he/she never has to act on that knowledge.

Bill Carlson
Friday, April 19, 2002

There's one important difference between the Asm->C or C->C++ transitions and the C++->Java transition.

Looking at the compiled program or library, usually you can't tell whether it's written in Asm, C, or C++. The language itself doesn't restrict your development and deployment model much. However, with Java it's different. Moving to Java, you have to change the whole system infrastrusture.

In other words, the C++>Java is a strategical transition, while Asm->C or C->C++ is tactical.
And it's very easy to step back and rewrite a part of the system in assembly language if C is not adequate. With Java, it's usually not and option.

Just my 2 cents.

Igor Krivokon
Friday, April 19, 2002

Igor makes a good point.  The "futurists" would say that everything will be linked by XML web services, but that's a poor subsitute for LINK.EXE.

Fortunately, the mainstream, general purpose languages like C++, Java, C# are powerful enough that a project team can usually keep development homogeneous, provided the team buys into the strategy.

With every "step up" you lose something, sometimes important things.  The question is whether, in 5 years, those things will seem important in retrospect.

Bill Carlson
Friday, April 19, 2002

A few thoughts:

1. All the transitions such as asm to C and so on are part of a migration of capability higher up the application space, which enables more useful applications. Another important enabling factor in this is increasing processor power.

2. Java has reached an evolutionary dead end because it's no good for packaged software. Java is essentially a language for enterprise developers, not ISV's. This is a shame because Java has some lovely ideas. Unfortunately it took the wrong steps into bloatware around 1998 and also away from end-user simpliciity.

3. A worrying feature of .NET is that it subjects all applications to the control of an intervening layer that, in the future, could implement any type of revenue generation scheme, government restrictions or activity reporting. This could also work to the benefit of application developers of course, but it's still an issue that hasn't been discussed much.

Hugh Wells
Friday, April 19, 2002

With every step up you also gain the ability to think at a higher level of abstraction. Well, not with *every* step, but with many of them. Consider the classic Gang of Four SOFTWARE PATTERNS. That had to wait for a high-level language, but it gave us powerful tools for organizing complex solutions. Machine code offers more raw power, but it's at the wrong level to implement the grand pattern schemes.

Mike Gunderloy
Friday, April 19, 2002

"Java has reached an evolutionary dead end because it's no good for packaged software."

What makes you think this heralds the end of Java, and not the end of packaged software?

Paul Brinkley
Monday, April 22, 2002

Interesting point and a different subject. I suppose my answer would be that the market has shown us that packaged software works best; that web services are one of those nice MBA ideas that doesn't work well.

It probably all gets back to speed of response, the ultimately crucial usability factor. That plus reliability.

This situation could be different in seven years time, but not before then. By that time, in my view, .NET will be the platform for web services, and Java will have declined into a niche player.

Hugh Wells
Monday, April 22, 2002

I am generating Flash files that correspond to GUIs.  Actually, I am working on tools that make this reasonably productive.  Though I've just joined this project, I can see firsthand how very responsive the GUI is.

I don't know where the brick wall is yet.  It can be extended with scripting languages; perhaps it works badly in uncommon cases.  Whatever the case is, it is possible to have very responsive web apps; it's just that there is too much dominance over the desktop by Microsoft, that things run in a kludgey web browser and are therefore unreliable.

There are aspects I don't quite understand.  I'm sure there is more to the problem than just Microsoft.  Seven years sounds like a very sensible number, because of all the politics, security and support tools which need to be written.  And there needs to be a killer app.

battle for stalingrad
Tuesday, April 23, 2002

Adapt and overcome...

I believe that's a Navy Seals saying. There will always be a programming language or methodology "du Jour." That's one of the reasons I'm drawn to this business. Don't get me wrong though, I believe that change for the sake of change alone is bad. It's simply our job as engineers and developers to keep abreast of new technologies and techniques and use our best judgement  to winnow the wheat from the chaff and apply the best tools to task(s) at hand.

I also like to remember Bjarne Stroustrup's line about "... once common sense is missing there is no limit to the damage that can unwittingly be done." I remember this as I write code.

Charles J Williams
Wednesday, April 24, 2002

*  Recent Topics

*  Fog Creek Home