How to Win Programming Language Battles … and Maybe the In-House Applications Development War

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 100

A good start to winning the next war is to have lost the last war. APL lost its war. But it can be part of a team that can win the next one. This article presents one prospective strategy and related set of tactics. It might well infuriate you, but it will be for a good cause if it inspires you to come up with a better plan.

I suppose I should explain the meaning of the first sentence for readers not familiar with military history. The concept is that winners tend to rest on their laurels — after all, they won, so they must have done things right. Losers often realize they did things wrong, and study their defeat in order to correct defects and do better next time. (This does not always happen if correcting the key problems is beyond the capability of the loser; a Belgium without allies is always almost certain to be defeated by a Germany. Other defeated nations tend not to self-examine, but place blame elsewhere: ‘We are betrayed!’)

The first step to winning the next programming language battles is to admit that the previous war was lost. So far as I can tell, almost all APLers concede that APL will not rule the programming world, as they had hoped in the late 1960s and early 1970s. Some have given up completely. Others have been scurrying to survive, popping out useful ideas and sales points — but the impact has been scattered and small.

I will start with a limited outline of the defeat. Then I present my interested bystander’s perspective on the current situation, followed by a plan for the next campaign.

The Defeat¶

What is history cannot be undone. Even if the betrayal theorists are correct that IBM (consciously or unconsciously) did APL in by promoting PL/I in the early 1970s, that does not matter; besides, today PL/I seems to be more out of the picture than APL! Aside from the PL/I theory, what went wrong?

I am sure the data processing management view that APL systems were unpredictable mainframe memory-hogs was based on experience. Hostile management does not guarantee defeat, but it makes life pretty hard. I think this is what started APL’s slide beginning in the mid-’70s. DP management was also hostile to personal computers, but the sheer sense of the PC concept along with the killer-application spreadsheet and its champions in other realms of corporate management more than neutralised DP’s position.

When PCs did come along, APL was past its usage peak, and early-’80s PCs were too small and slow to make effective use of APL. It was not until the late 1980s and the advent of 32-bit CPUs and simple memory mapping that APL had a chance to shine; but, by then, the damage had been done.

Language-specific problems are well-known, even though many APLers do not consider them to be problems. These include: (1) the character set — elegant, but until recently not easy to integrate into the computing environment; (2) the fact that APL is interpreted rather than compiled — unless the computer itself is lightning-fast, commercial ‘shrink-wrap’ applications are to be avoided in APL; (3) the APL workspace — a convenience in interactive computing, but its operating system-like qualities have made APL hard to integrate with host OS’s, particularly in application development. There are other intrinsic problems, but the above were more than enough keep APL sliding over the past two decades.

The Present Situation¶

Where do matters stand today? Computer technology has continued behaving according to Moore’s Law: speed increases while cost of equipment (of a given performance level) decreases. Many desktop computers have the speed and memory to overcome slow interpreter speed perception in many application settings. Regarding operating systems, APL is often packaged as simply another library or library set (DLLs in Windows) and can communicate with other applications and code libraries. The symbols remain controversial and a potential problem so far as keyboards are concerned for the programmer. But symbols and keyboard drop out of the picture in applications — which was true even in mainframe days.

An important fact is that a number of APL-offshoot languages have sprung up since the mid-1980s. These include Nial, J, A, A+, K, and the SAS IML language. Mathematica claims more remote kinship. Apart from A and perhaps A+ (I haven’t seen A+ code), these languages do not use the APL character set. J has eliminated the workspace and strives to link with all manner of other applications on the host computer or even over the Internet. A+ and K are number-cruncher languages tailored to the needs of Wall Street firms; this too is important, as we shall see.

And, of course, it is well known within the array-language community that programming (if not execution) speeds are far greater than for conventional computer languages.

Given the above as well as other factors not covered for lack of space, many prerequisites for a successful renewed struggle are in place or nearly so. What is missing is a plan for taking advantage of the situation. We turn to that next.

The Plan: Introduction¶

Here we bring in marketing and public relations, trying to effectively blend them into the mix of technology and office politics discussed thus far. And please don’t let your dislike of ‘suits’ prejudice your reaction to what I am about to discuss. Marketing does not have to be the slick stuff that many APLers disliked about STSC/Manugistics in the era 1985-95. Properly done marketing and PR, coupled with acceptably good technology, can take you far. You cannot deny the success of Microsoft as a case in point.

The plan is presented in three parts. First, strategy is outlined; this is likely to be the most controversial point. Then some tactical steps are proposed. Finally, there are a few cautionary notes.

One caution can be noted at the outset, namely: in war, plans seldom survive contact with the enemy (read von Clausewitz). My notion is that the plan should be simple, but not so tightly focused that unanticipated successes cannot be exploited due to its mindless pursuit (‘exploit success, not reinforce failure’ is useful military maxim). And remember that even simple plans are very difficult to execute (I think this is from Napoleon).

Strategy¶

APL is mostly used for: (1) in-house applications; (2) preparation of data for access or sale to outsiders — i.e., the LegiSlate information system, the demographic data I sell; and (3) ad hoc interactive computing by engineers of scientists. ‘Shrink-wrap’ APL-based products hardly exist. In-house application development is clearly the strategic target because it is a huge field and it plays to APL’s strengths (efficient development, new abilities to link to other software) and minimises its weaknesses (shrink-wrapping and slow execution do not seem to mix well). If there is success in the in-house arena, the data product and ad hoc areas should benefit as side effects.

Now for the controversial part. APL’s image (such as it exists today) largely stinks. I see no easy way to turn that image around by focusing on APL in isolation.

This means APL should hardly – if ever – be mentioned in our rehabilitation campaign.

Instead, we promote Array Languages as the next big thing in information systems productivity.

And, since Array Languages are more than just APL, we APLers must be able and willing to write in J, K, Nial, or whatever good new Array Language comes along. It can become a marketable skill area.

All Array Languages are small players, and uniting them for public relations purposes is likely to yield more short-run benefit to all than promoting each in isolation. If the Array Language concept becomes a hit, then the alternative languages can fight over a much larger market than before.

Let me summarize the strategy: Use the concept of rapid-development Array Languages as the next step in information processing. There was OOP for interfaces and data bases, now there’s Java for the Internet, next come Array Languages for core, mission-critical number crunching.

Themes¶

The most important thing is to show that existing Array Languages are already being used successfully for core, mission-critical number crunching.

Where does this happen? Wall Street. Billions of dollars are at risk in lightning-paced trading situations. Very high stakes. And what kind of computer language do key Wall Street firms turn to for this crucial task? – Array Languages, of course!

To me, the above is a powerful sales point.

And it can be reinforced by other, similar points: An Array Language was a key item in developing anti-missile defences – could your company use that kind of performance?

I hope you get the idea — find the most impressive examples and stress the Array Language aspect. The actual Array Language used becomes a ‘for instance’.

I also believe that practical appeals are stronger than theoretical appeals for the target audience. Yes, everyone can be swayed by emotion, and many can be swayed by ideas. But the key is to take a rational appeal and make it emotionally appealing. Thus, someone who buys into the concept of the Array Language solution can use the rational part of the argument as justification. The examples above are intended to convey the idea that Array Languages offer powerful solutions in settings where failure might be disastrous. The reader of the messages thinks his own work, even if on a smaller scale, is pretty important too; so he has reason to be motivated to learn more about the Array Language solution.

How is the message to be spread?

Tactics¶

Now we are at the hard part: execution. This is a black art that even marketing and public relations professionals do not fully understand, mostly because causes and effects are hard to trace and measure. (As an aside, the only really measurable advertising is direct-response, where the customer inquiry or purchase can be traced to a specific mailer, print ad, or television appeal — the contact address or toll-free phone extension varies from advertisement to advertisement and the effect of each ad is thereby measured.) Since we are doing public relations, we must fall back on industry folklore and published comments by successful practitioners.

There is time to think about this before taking action. Ordinarily, my instinct would be to start immediately, but there is the small problem that the computer world is abuzz with the Internet and the Java language. I think it would be a waste of resources be go full-blast with an Array Language campaign while everyone is still focused on Java. This does not mean that seeds cannot be planted; it means that the Big Push will fail if it is launched before Java becomes commonplace and the Next Big Thing needs to be found to occupy the attention of the computer elite.

What kinds of timelines exist for computer industry fads? My impression is that there is usually a period of gestation or build-up. This can take a decade or even more. For this reason, seed-planting should begin soon. The Java explosion (which began in 1995) is an exception. C had been around for several years before the rush to ‘software portability’ became the craze in the mid-1980s. C++ was little known until object-oriented programming exploded in the collective programming mindspace around 1990. The practice of OOP was launched at the famous Xerox PARC in the late 1970s (though the ideas were manifested in Simula in the late ’60s), and Byte magazine had a cover story on the Smalltalk language in the early ’80s. Graphical interfaces made the need for object-orientation concrete. C++ was the commercial winner thanks to the fact that C was, by that time, the prime language for shrink-wrap software, and moving from C to C++ was a smaller step than from C to something else. OOP is far from dead. The latest database concept is object-orientation (to supplement or complement the relational paradigm). And there have been both theoretical and practical efforts to make APL OOP-compliant. At any rate, OOP’s gestation from concept to mania can be pegged at roughly a dozen years, if Smalltalk is taken as the start-point. The time from the invention of structured programming languages (Algol, around 1960), to the frenzy for top-down programming was about the same.

I stress fads because the fad is the expression of the attention and energy focused on a particular programming concept. And, unlike fads in clothing and automobile styling, programming fads tend to become honorably installed as part of mainstream practice once the hype wears off and the most extravagant claims are shown to have been false (for instance, pure-OOP, as exemplified by Smalltalk, has not taken over the world). Even APL has become a structured language. Top-down programming is the best approach for many tasks. Graphical interfaces are almost unthinkable without OOP elements. And Java might legitimize interpreted languages.

To return to my point: the groundwork for a surge in Array Languages has been going on since about 1990, when APL was about to become better integrated with other software on the host computer and when J and A were under development. This suggests that the technical phase is well underway, and that the promotional effort should begin soon, even before the Java hype starts to fade, with expectation of success around 2000-2003. We are approaching the window of opportunity.

One public relations strategy — advocated by Regis McKenna of Intel and Apple fame — is to capture the attention of ‘industry influentials’. In the case of Apple Computer, this meant getting key venture capitalists to invest early on as well as gaining the favorable interest of Ben Rosen, at that time a respected industry observer and newsletter publisher (who later became involved with Compaq Computer from the VC side). McKenna contends that, thanks to their prestige and connections, opinions of influentials will seep down the chain to news media, corporate purchasers, and the general public. This concept worked for Apple, but it is not sure-fire, and might not even apply to our problem of publicising a family of programming languages rather than a particular branded product.

Nevertheless, programming language influentials exist and should be cultivated. Here are some fairly obvious examples to get your thinking launched. Consider Bill Gates. It is known that he was once intrigued with APL, so the idea of using an Array Language as part of the Visual Basic package or as an adjunct to the Access database product might not be rejected out of hand at the highest levels at Redmond, a few miles up the road from where these words are being written. I suppose Bill himself probably isn’t a primary target — but if an Array Language buzz starts, some folks at Microsoft, including Bill, will surely be aware of it.

Besides Bill, there are the usual media suspects. Someone with a better sense of history than me can correct this, but my impression is that commercial computer magazines are better at following trends than creating them. But they too should be cultivated. And this cultivation will not be effective as a one-shot deal. I recall that, a few months after APL89, Ed Cherlin was able to get a nice amount of APL2 material into John Dvorak’s column in PC Magazine. Trouble is, nothing else appeared, and the effort was wasted.

Here is a concept for dealing with the media. At some point, there should be a hard-hitting barrage to a number of columnists such as Dvorak about a new class of ‘wonder languages’, namely Array Languages. Leading up to that, word could be spread amongst programmers in general via magazines or newsletters (or Internet venues such as chat forums with computer magazine editors and columnists) about great new ways to get code out. An example might be Jeff Duntemann’s magazine, Visual Developer. Its roots are as a magazine for Borland Turbo Pascal programmers, but it has evolved to focus on programming for Windows in Delphi and, yes, Visual Basic and Java. There are some good APL writers with experience of using J (or Dyalog APL/W) as DLL servers under VB, Delphi, and Visual C++. It seems to me that articles could be submitted to Visual Developer telling how really great, quickly-coded number processing routines can be attached to the various interface systems for use in one setting or another. If even one or two of these could reach print each year, that would be a reasonable start. And the effect would be multiplied if the same thing was happening in Dr. Dobb’s Journal and similar magazines.

Besides programmers, we must start to capture the minds of corporate IS managers and systems analysts. This is getting away from my experience, so I will be sketchy and brief. Magazines and journals read by such people should be a target. The concepts relating to Wall Street mentioned above could have great impact here.

Yet another target is the computer guru or management consultant. Getting consultants to buy into the concept of (comparatively) rapidly-programmed number-processing applications using Array Languages as vital adjuncts to existing DP tools could be a large win for our side.

How is all this going to take place? The cheapest way is to form a volunteer committee to orchestrate the effort, to coordinate the solicitation of articles, inclusion of panels in non-APL professional meetings, etc. But volunteers can be hard to recruit, and volunteer committees tend to lack staying power — an important consideration for a multiyear effort. Nevertheless, the option proposed next might well be even more impractical; then the volunteer committee would be the only option.

In my opinion, a good way to do things is to form an Array Language trade association, either formally chartered or simply an informal group. An association could have people helping in the coordination, marketing, and PR efforts while on company time, thus taking some pressure off volunteers (who would still be needed for writing books and articles and for making presentations or appearing on panels).

Another benefit of a trade association is that it could pool some money to hire a public relations firm or consultant to deal with PR basics such as maintaining contact lists, brokering articles in trade journals, and keeping an eye open for opportunities to publicise the Array Language concept. The consultant also ought to be able offer advice to the association regarding PR matters in general.

My guess is that a low-level, initial effort might cost something like $10,000 per year. If industry sales increase, and the consultant can demonstrate media placements and other measurable results of his activities, then the budget and effort could be increased.

Cautionary Notes¶

Probably the most important consideration is to be able to deliver what is promised. Here, I am thinking mostly of the ability of Array Languages to link to host computer applications or to the Internet or whatever connections become fashionable in the next few years.

Another need is to better assure that programmers taking up Array Language coding have the resources (books, manuals, training opportunities) to get going reasonable quickly without much pain and anger. Bitter experiences can damage a product or cause quickly and thoroughly. The risk of such problems is high when programmers must drop old habits. This was the case with APL in the early days — programmers writing scalar APL code. (More recently, programmers from many backgrounds have had to face the pain of coping with the OOP paradigm. The need or desire to change fuelled the publication of many articles and books on the subject to ease the shift.) On the APL side, perhaps ‘Gilman and Rose’ could be resurrected; in its day, it was a Godsend. J is notoriously hard to learn, partly for intrinsic reasons, and partly because good introductory material has been lacking. The User Manual is good for learning the environmental parts of J, and the Primer should have appeared long before it did. At least one more introductory book by a different author is needed, simply because different perspectives work better for different people when learning new material. I am not familiar with learning resources for Nial and K.

Finally, I think it would be helpful if APL programmers were more open-minded regarding changing the language as well as their own work habits. I don’t mean all APL programmers, of course. But each innovation (keyboard revisions, control structures, GUI environment) seems to lead to some angry letters to journal editors. As mentioned above, the Array Language concept can be the vehicle for exciting professional opportunities. The price of this might include abandoning component files, the workspace, and — yes — even the del editor to embrace evils such as control words.

Conclusion¶

We don’t have to lose. Array Languages can be the next programming sensation. Perhaps I didn’t get everything right in the way of diagnosis and prescription, but I hope it will stimulate folks in the APL community to seek new ways to spread the Array Language gospel to the outside world.