From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11232c,ab67bdd1ff50fd8,start X-Google-Attributes: gid11232c,public X-Google-Thread: 103376,c8086456b887be55 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-23 22:31:26 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!62.112.0.25!newsfeed.online.be!ams.uu.net!news.mailgate.org!smtp.well.com!not-for-mail From: xanthian@well.com (Kent Paul Dolan) Newsgroups: comp.lang.ada,misc.misc Subject: Re: License to Steal Date: Tue, 24 Apr 2001 05:31:22 +0000 (UTC) Organization: Mailgate.ORG Server - http://www.Mailgate.ORG Message-ID: <200104240531.WAA01552@well.com> References: <92HD6.3345$D4.334091@www.newsranger.com> NNTP-Posting-Host: smtp.well.com X-Trace: news.mailgate.org 988090282 9347 208.178.101.27 (Mon, 23 Apr 2001 22:31:20 -0700 (PDT)) X-Complaints-To: smtp.well.com@abuse.net abuse@mailgate.org NNTP-Posting-Date: Tue, 24 Apr 2001 05:31:22 +0000 (UTC) Mail-From: xanthian@well.com from smtp.well.com [208.178.101.27] X-URL: http://www.Mailgate.ORG Xref: newsfeed.google.com comp.lang.ada:6877 misc.misc:2548 Date: 2001-04-24T05:31:22+00:00 List-Id: 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. 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 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