RE: Industry versus academia

["Anton van Straaten" <address@hidden>]

Eli Collins wrote:
> How important are language/tool issues to businesses?

More important than the businesses themselves realize - which is one of the
underlying themes of this discussion.  John Morrison hit on this when he
mentioned cost-shifting.

What's the cost to businesses of debugging buffer overflows?  Factor in the
overall cost to businesses worldwide of dealing with the major viruses which
have exploited them, and you'll get a pretty big number.

Java is/was a big improvement over C/C++ for certain kinds of applications,
and one reason was that it eliminated buffer overflows, and thus their cost.

But now, what's the cost to businesses of using a language/tool like Java,
which really requires a whole raft of tools using or providing source code
generation, reflection, and wizards to make it viable for development of
"enterprise apps"?  Significant complexity is created, and has to be
mastered, at some cost, simply to deal with the shortcomings of the tools.

Why does Java need all these things?  One big part of the answer is its
typesystem, which has various draconian restrictions that result in the need
for tools that generate boilerplate or do reflection.  Many of these
problems have been solved in academic typesystems.  So there's one area that
academic advances could have a large economic impact on common commercial
systems.

In fact, this is already happening, with changes to Java to support
generics, and with third-party tools - Dan already mentioned AOP as an
example of this.

[Another way to solve problems in this area is the typical
lightweight/scripting language solution, which is to eschew static
typechecking - but this is viewed with some caution in many kinds of
commercial development, and that's a separate discussion...]

> I think there might be bigger issues in software development that trump
> the introduction of academic PL advances.

You're arguing for the status quo, which ignores all those shifted costs -
someone downstream eventually pays them, so you can afford to ignore them
until your competitors start using better tools and out-competing you.  This
has happened before, over and over, going all the way back to when assembler
was still a dominant language.

Some of the "bigger issues" you're thinking of may indeed be bigger, but
more likely, they're simply easier to directly address.  An average business
can address communications issues and methodologies internally.  An average
business can't design a new language incorporating academic advances to help
solve its problems, nor can it wait around for someone else to provide such
a language in a "business-ready" form.

I think when you assert that issues other than tool choice are more
important, it only works because you're comparing tools from roughly the
same generation.  Would you say the same thing if faced with a client
wanting to develop an enterprise resource workflow application in IBM
Assembler?

What we're talking about on this list are things that affect the next
generation of languages - languages which will ultimately take market share
away from languages like Java and C++, not just because of industry fads,
but because of increased productivity, reduced complexity, lower costs.

> JITS and GC don't fix mediocre code, they help it stick around.

Helping mediocre code stick around is one of the goals - there are plenty of
mediocre programmers to go around, and we need ways to use them (apparently!
:)

But another goal is helping code which uses high-level abstractions to
perform well.  It's the high-level abstraction features, and the ability to
use them without paying an unacceptable performance cost, that's the real
point.  This is another area where academic language features can help.  For
example, right now, Java still suffers from performance issues which are a
direct result of its typesystem.

So some of the promises from the academic world include better abstraction
support, more flexible typesystems, and better performance in the presence
of these features.  These will certainly have an important impact on
business, at some point in the future.  But, it's not one that the average
business can plan for or manage, so it's essentially irrelevant to them
until it happens.

Anton