RE: Industry versus academia

[Eli Collins <address@hidden>]

On Mon, 24 Feb 2003, Anton van Straaten wrote:

> 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.
>

Buffer overflow bugs are certainly an important issue, but if you believe
that there's a 100x factor in productivity between your programmers (if
you believe _The Mythical Man Month_) then buffer overflow is probably a
secondary issue. With static analysis tools like SPARK and non-executable
stacks (recently added to OpenBSD) problems like buffer overflow are
becoming _less_ (still important!) of an issue for application developers,
meanwhile the problems Brooks pointed out long ago are still here.

> 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.

I agree with PG on java (http://www.paulgraham.com/javacover.html). From
my experience Java's adds enough expense and complexity to compensate for
its features. You can't get a buffer overflow but the Oracle driver makes
the JVM core dump every 2 weeks. I'll get flamed for this but I think
Ada95 is a better alternative to C++. I'm certainly glad the Boeing 777
flight control is not coded in Java or C++.

> 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.

No question that academic advances help, I just think we're at a point
where tools are no longer the #1 issue. BTW Lisp solved these problems
almost half a century earlier. Java generics are a great example of how
long it takes to get a feature from academia to industry, not only that
they are pretty poor. Try overloading a generic method, oops, you can't
because its mostly syntactic rewriting to avoid the nasty casting issues.
I'll move on, the why many smart people don't like java thread is too
often repeated.

> [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...]

Dynamic languages are on the upswing, and very popular in industry (I'm
sure you know that). Notice that most langs discussed at LL1 were
dynamically typed! I've found them to be very effective in commercial
development when used in conjunction with extensive automated unit
testing.

> > 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.
>

I don't ignore the shifted costs, I just think they are thwarted by other
ones. I don't accept that most programmers have to be mediocre. The
java/tools buy and develop our way out of the problem perspective seems to
be the status quo from my POV. I think better quality developers using
existing tools is better than more and more tools and mediocre developers.
If we did a better job in academia/industry creating and training software
developers we might not need 1001 java plugins and IDES. Seems like
inefficient resource allocation to me. In many undergraduate CS programs
you can graduate without doing more than 1 group programming project, for
e.g. as something broken. Thats a much bigger problem than what AOP
solves.

> 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

I think these issues are the hardest to address, which is why they're
still here! If these problems (productivity/code quality/correctness/etc)
are so easy to address then why are they still here? Effective management
and group work are certianly as hard and as complicated as PL tool
development. We might be talking about two sides of the same coin, for
example when the SQL Server worm caused some of MSs servers to fail you
could blame it on (a) the C codebase or (b) the MS development
organization (why don't they autoupdate critical patches?). Either is
valid in my opinion.

> 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?

I agree. Tools are certainly important. But now that we have incredible
development environments as compared to then (not that we shouldn't still
improve them!) I think its time to focus on some other issues which might
get more bang for the buck.

> 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

Funny you should mention this. In my graduate compilers course our
semester long group project is to write a Python compiler which generates
x86 machine code. I couldn't agree more here!

> 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.

I'm all for academic advances in industry. I would love to see ML replace
Java/C# as the language your pointy headed boss demands. I just think
businesses have bigger programming problems than tools. Just out of
curiosity, do most people on this list accept as fact that most
programmers have to be mediocre?

Thanks so much for the long and detailed response!

Eli