Re: License to Steal

[xanthian@well.com (Kent Paul Dolan)]

There's a point to all this, though it is fairly far
along.

Richard said:

RDR> I was recounting the history of Ada for one of my
RDR> classes at Naval Postgraduate School today.

I was across town from you interviewing at your Fleet
Numerical annex a handful of weeks ago, this
discussion recalls that and my earlier stint there.

RDR> At one point, I came to fact that the original
RDR> Ada policy had been abrogated.

That's a nice way of expressing it.

Another way is to say that the separate military
services succeeded in a flagrant and determined
violation of direct orders from their Secretary,
turning heel dragging into the next best thing to
armed insurrection, and _so_ much more civilized.

I got fired from my contractor's job at Fleet seven
years ago for suggesting _around_ the chain of command
that perhaps a little attention to enforcing the Ada
mandate, say at my desktop, to reduce the current
chaos, would be in order.

I understand that the captain who ordered my dismissal
was pretty much frothing at the time that all his ways
of weaseling around the Ada mandate had been exposed
from under the rock where they dwelt.

Sigh.

RDR> Then I pointed out that, since the abrogation of
RDR> that policy, I see people using all kinds of new
RDR> languages.

Before, during, despite, and after, that is correct.

RDR> I predicted that over the next few years, we will
RDR> be right back to the situation that triggered the
RDR> need for Ada in the first place:  a proliferation
RDR> of programming languages that only a few people
RDR> know.

You are there already.  Go over to Fleet and check out
"Fortran 95", which they are using because it is the
latest and shiniest new thing despite admissions to me
during the interview process that no one there has a
clue how to write more than Fortran 77 in it.

RDR> This is already happening with so-called UDA's,
RDR> "user defined applications" written in everything
RDR> from Visual Basic to Perl.

Nice to know that open rebellion now has an acronym.

RDR> UDA's are popping up all over the place in the
RDR> DoD.

Nothing has changed.  My last job at Fleet, I was
handed an application suite written in 12 different
programming languages, and, it being among the
missing, added Ada 83 to the mix on my own.  Oh, in
1992 - 1994.

RDR> Once the person who created the UDA is
RDR> transferred, no one else knows what to do with it
RDR> or how to maintain it.

However, that is not the fault of the person leaving,
nor of the choice of some "little language".

RDR> Often is unmaintainable because it is in some
RDR> special version of some special language that is
RDR> not portable to the next [version of] an
RDR> operating system upgrade.

The term "open source software" hasn't been heard
within the Armed Services then?  [Rhetorical question,
Richard, really, I'm still angry from 1994.]

RDR> As I was describing this situation, one of my
RDR> students said, paraphrasing, "It sounds like
RDR> cancelling the Ada mandate became a license to
RDR> steal."

No, it became a license to commit rebellion within the
US Armed Services by means short of force of arms.

That will not be forgotten when the next occasion
arises.

Were I the rest of the world foolishly depending on
the US to suppress enemies at home and abroad, losing
Ada, and with her the fiction that the US military is
firmly under the control of the US civilian
government, would not make me sleep better at night.

Ted replied:

TED> In all fairness, my impression is that the
TED> mandate was widely ignored when it was in effect
TED> (th[r]own down and danced upon would be a better
TED> description), and that today's proliferation of
TED> little scripting languages (Perl, Python, TCL,
TED> VisualBasic, JavaScript, Guile, Ruby, etc.) owe
TED> practialy nothing to DoD support.

True stuff.

There are, literally, thousands (less than five, more
than two, probably) of programming languages, a small
but significant portion of CS graduates worldwide
create one as a thesis project, for example.

I might have written one or two myself, but I had the
good grace to throw them away when I was done with
them.

The software industry being more pragmatic than most
realize, sometimes it is the best languages that
survive, sometimes really niche languages arise and
thrive.

I interviewed at a power controller manufacturer (for
stuff like electric cars, golf carts, and on down) and
was rather astounded to find that they had created
their own, in house, compiled programming language,
whose primitive concepts included bits appropriate to
power control closed feedback loops, this in an
enterprise so conservative they still had a company
pension plan.

One of the lessons to be learned there is that the
proliferation of programming languages is not likely
to end soon, so fighting it may not be a profitable
approach.

Another, more obscure one, is that maybe DoD ought to
get in on the game, and more like the controller
company and less like the Ada effort.

    I cannot envision a programming language whose
    primitive constructs are battlefield command and
    control, strategy and tactics, but I suspect
    someone can, and to a Forth programmer, something
    like OFtEotL ("outflank the enemy on the left")
    would be a perfectly natural next dictionary word
    to define, while to an OOPer, that kind of thing
    would dispatch dynamically based on a type of
    engagement tag.  <tiny grin>

A very interesting thesis project for one of your grad
students, Richard, would be to study what it is that
makes a programming language able to grab mindshare
despite being essentially a hacker's toy like C++,
TCL, Perl, or Python, to name ones familiar to me,
while for conceptually adequate other programming
languages, like Ada, even offering to force them down
the programmer's throats at gunpoint fails.

One well known and fairly major clue might be that
Larry Wall is a linguist by training.  Does he know
something the Ada team should have considered about
how the user wants to _think of_ a language?

Another major clue is that John Ousterhout is an
engineer by training.  Does he know something about
how the user wants to _use_ a language that the Ada
folks might have considered?

Of course, over time, the more mindshare a language
has, the more pressure / contributions it has to
improve, so eventually lots of these hacker languages
have gotten hoary and respectible.

TED> But whatever the causes, I'll grant you that the
TED> symmetry is interesting.

More than that, worth a lot of sincere introspection
and planning, both for DoD and for the software
industry as a global entity, this lest each get
blindsided yet again.

The DoD found it could not thrive (and so far as I
know, probably still does not) as a balkanized set of
programmers knowing one language very well and not
talking to the next encampment because that one knows
another language well, but not the same one.

Can it thrive under a still different model than
either "one programming language fits all" or "welcome
to Babel"?

I've been having an extensive offline discussion with
Brian Harvey at Berkeley, developer and maintainer of
ucblogo, a version of the Logo programming language
starring in a sibling newsgroup of this one,
comp.lang.logo.

I was pushing for more "first class programming
language" quality for even a programming language
targeted at kids, he was telling me why it won't ever
happen.

He asked me why I'd bothered to learn many dozen
programming languages over a long career.  Surely the
half dozen languages he named should suffice any sane
person?

Well, no, because as in the job at Fleet, where six of
the languages I had to use were unfamiliar to me even
by name, as an itinerent worker bee programmer, I
don't get the chance to choose which languages my
enterprise uses (usually), I get to use what they
have.

Check current online job listings for "competent
programmer, any language" and see how far you get
finding a job (actually, send me the listing, I'm
looking).

* So, one way out of the UDA morass is simply to train
  programmers to learn new languages quickly.

This lets you find a programmer and let him or her
learn the language by fixing the application written
in that language.

However, ike Ada as a Procrustean bed, that one size
solution also does not suit all, not all programmers
with something of value to contribute are wired that
way, so there are additional measures that need taking
for those workers.

And in general, here are other things that need adding
to finding a path out of the UDA mess before it is
(much worse of) one.

* Make sure that open source tools with source
  licenses are always highly ranked at the RFP level,
  for a couple of reasons.

Open source tools can, with incredible pain, be
upgraded by the customer.

Open source programming tools (at least popular ones)
probably inherently have more knowledgable potential
employees out there who can do such an upgrade, or
upgrade the application program, for that matter, than
do the closed source kinds of tools that only a vendor
could love.

* Attempt to choose tools with simple mental models,
  to assure ease of programmer training.

Follow, for example, the Modula-2 model, _not_ the Ada
model.

Follow the APL model, not the Fortran 95 model, of how
to talk about a multi-dimensional slice of a
right-ragged matrix, to get away from religious issues
probably not capable of rational discussion here.

If someone gets called a language lawyer, or needs to
be called as a language lawyer, in a discussion of how
to make something work, then you flunked.  however
good the intentions of the language designers, they've
built something that won't grab mindshare.

Brian and I in our discussion repeatedly dipped into
the issue of "scope" of an identifier.  This is
instant MEGO (my eyes glaze over) material for the
casual programmer.  Don't tell me about your problems,
language designer, just make it work, and not like
that.

If it is complex to do something, and your user has to
know about that complexity, you flunk again.

* Take into account from the beginning that
  enterprises outlast their staff, and make sure that
  the "Jill gets run over by a truck" plan is in place
  when a UDA begins, not some after-thought, and make
  that part of the check off list for beginning a UDA,
  before Jill writes a line of code.

* Make programmers as interested as managers in having
  the contingency plan in place.

Nobody gets promoted with a dangling project with "run
over by a truck" exposure.

Nobody gets bonuses, ditto.

Nobody gets a project accepted as "completed within
budget and time constraints", ditto.

Nobody gets rid of maintenance responsibility for a
project, ditto.

One nice side effect of all this is that something
like Ada that makes sure you and your potential
replacement can do a turnover quickly becomes a lot
more attractive.

  Gee, I only have to use this one language and all my
  turnovers will be easy?  Why don't I program in it
  from up front?

* Make the managers as invested as the programmers in
  having a contingency plan in place.

No project gets accepted as complete by higher
management until it is backed up offsite, both in
having people to maintain it, resources to run it,
data to drive it, all in place in case terrorists /
nature sap this site.

No manager gets promoted, bonuses, milestone
checkoffs, etc., ditto.

* The same scam works with obvious variations for
  vendors, interaction with other Armed services, etc.

All would work toward commonality of tools instead of
proliferation of tools.

What the Ada effort ignored was something an old FIPS
publication called "Organizational Preparedness for
Change" might have covered.

People protect fiefdoms, savagely, so those must be
disassembled, craftily, not by fiat from above.

The problem with the Ada mandate is that the services
protected their fiefdoms, and showed no higher
organizational level of discipline at all, just the
outward show of some.

This is human nature, and was ignored in the planning
phases for Ada.

Putting some higher level military service discipline
back in place would probably help a lot, wherever the
next attempt to untie this knot heads.

Think of it as an interesting exercise to undergo for
a proof of concept that it can be done at all.


Cheers!

xanthian.
--
Kent Paul Dolan <xanthian@well.com>

http://www.well.com/user/xanthian/resume.html

Yeah, right.


-- 
Posted from smtp.well.com [208.178.101.27] 
via Mailgate.ORG Server - http://www.Mailgate.ORG