It DOES seem to be true that:
1. Some APL vendors never successfully made the transition from the
mainframe to the PC.
2. Some APL programmers with grey or white hair only see others with
the same hair colour, and do not know any of the many young APL
programmers who joined the community recently
3. Unlike in 1980, it is very hard to find a consulting job where all
you need to know is how to programme in APL.
4. It is almost impossible to interest Computer Science departments in
APL.
5. If you work in a traditional software department you are unlikely
to be allowed to start a new project in APL: Software engineers still
don't think APL looks like anything they learned at school and that it
is "broken" (the fact that they can't deliver software on time, on
budget and to spec is only just starting to shake their faith that
they are doing the right thing).
Over the past few weeks, we have seen a number of people post messages
to comp.lang.apl, expressing the belief that APL is dying, due to
various combinations of the above. Fortunately, it is simply not the
case: APL and other array languages are well established in certain
niches. The value of solutions based on these technologies is measured
in billions of dollars per year, and their existence is NOT
threatened.
It IS a hard time to be an APL programmer. I think it is fair to say
that most of us once chose APL because it offers a very high level of
abstraction, allowing us to very quickly turn ideas involving data
manipulation into executable code. But today, the platforms upon which
we are expected to deliver software are changing rapidly, and we
expected to take interest in the very issues that we picked APL in
order to avoid getting snarled up in. In particular, user interfaces
and databases now require extensive (layers of) toolkits, and these
layers are shifting under our feet. XAML, Silverlight, Virtual
Machines of one description or another. ODBC, JDBC, ADO, ADO.NET. We
are expected to embed APL software in browsers which are not allowed
to use local storage, even though this is obviously a bad idea for
software which is used to analyze huge amounts of data. Remember CICS?
It's the same story all over again: Traditional web development
techniques are another example of mainstream technology trying to beat
APL into a mould which was created for lightweigh transactional
systems. Keep your data in an SQL database, look at one record at a
time...
Architectures get more and more complex. If you are a computer
scientist or software engineer, rewriting the software every few years
in order increase the beauty of the code IS what you love - why you
chose the job. If you are an APLer, chances are you find all this
depressing. Fortunately, while the higher layers of tools are still in
a state of flux, the lowest levels of the new infrastructures ARE now
stabilizing. We should soon see tools and interfaces from vendors that
allow APLers to integrate solutions with popular platforms without all
of us having to go out and learn the details of the latest advances.
The big APL vendors of old, staffed by people who loved APL and often
had the same problem-oriented (rather than technology-oriented)
attitudes, were slow to realize the impact of the technology shift.
Consulting, timesharing and licensing revenues dropped sharply as the
PC took over from the mainframe. Almost no marketing has been done
since the late 1980's, and no new educational materials have been
produced - with the notable exception of those written for J. The
traditional vendors were caught in a negative feedback loop, from
which several did not pull out.
Accelerating the decline was the fact that much of the early revenue
was a function of a huge but fundamentally temporary business in the
1970's and 1980's, where all large companies were building their own
software for just about every purpose. APL was one of the best tools
on the market for this pioneering work. However, the production of -
and competition in the market for - the "shrinkwrapped" software which
replaced most of the APL systems written in this period is a different
game entirely: Key factors are a cheap and easily recruited/fired
workforce, documentation, procedures, and marketing. I think that most
APLers that I know would not want to work in these jobs, which the
industry is trying to turn into outsourceable "unskilled" jobs, even
if APL was an acceptable technology to these businesses.
We can argue about whether this or that system which was converted
would have been cheaper to maintain and more useful if the technology
had remained APL. I have personally witnessed many extraordinarily bad
business decisions to replace APL systems, made by management teams
with absolutely no understanding of what they were doing (some of whom
are now back in the fold as customers, I am happy to report). But in
many situations, the business logic which caused managers to replace
the use of APL by more "predictable" workforces and technologies are
"sound business decisions". It is in the nature of APL to be used as
an "executable specification language": APL is often used as much to
discover the specification as to implement the system. Having an
executable spec makes "agile" interaction with the user much easier
than with many other technologies.
In many businesses (the financial industry being the prime example),
the specifications never quite settle down. Fortunately, APL
interpreters are highly efficient and capable platforms, which support
the use of APL in high volume production applications. Although APL is
dynamic and interpreted, APL-coded solutions in this market often
perform better than traditional solutions. I believe that this is
because the layered approach of traditional software development tends
to drive the development in the direction of reuse of overly general
components, which need to be bent a bit too much and therefore perform
badly. Too many layers in an object hierarchy lead to inefficient
code, even after compilation.
So yes: There ARE many large APL (based) businesses which have died -
but the APL family of languages will not die unless they are one day
replaced by something MORE CAPABLE in the areas where APL is strong.
This is quite simply because it provides unique value in a number of
situations. The market that these situations represent is rapidly
growing, and very poorly served by other technologies, so there is
significant room for growth for APL, J, K and other new dynamic and
array-oriented software development methodologies. The mainstream
software industry is only just starting to shift its focus from
administrative systems to analytical software, and we have a 40-year
head start. If you look at trends in modern programming languages,
they are heading in OUR direction: Dynamic languages, Type inference
in languages like C#, growing use of "Reflection" (inspecting types
and doing different things depending on what was passed to you), all
of these are signs that mainstream technology is waking up to the fact
that if you want to write code quickly, and especially if it needs to
do anything analytical, you need the kind of flexibility that APL
already has.
This would be a VERY BAD TIME to start moving the language towards
where everyone else is now!
This message is too long already, so I'll better try to wrap up. I
admit that:
a. The golden age of cushy (mainframe) consulting jobs will not return
b. Trying to sell APL in head-to-head competition with Java and C# for
traditional "software construction" projects is almost impossible
c. APL is pretty useless in a Computer Science department. It is not
the goal of these institutions to teach the art of extracting
specifications or the construction of working software so APL has
little to offer them (OK, I admit have a chip on my shoulder: I
dropped out of CS pretty early on after discovering that only 15-20%
of the marks were given for arriving at a working solution).
However, unless you specifically want to achieve one of the above
three "goals", there is no reason to despair. The market for turning
complex ideas into working software is growing rapidly, and all the
brilliant ideas that Ken Iverson and the early APL developers put into
the language are more relevant than ever before.
Today, the successful (growing) users of APL seem to be entrepreneurs
(or entrepreneurial businesses) with novel ideas that they want to
bring to the market ahead of the competition, or before conditions
change. If you want to be an "APL Consultant" (internal or external),
you must learn how to wrap APL as components to be embedded in - or
communicate with - mainstream components. You must learn about SQL and
XML and other emerging technologies, and how to help the "Domain
Experts" who have the ideas and the skill to write APL for the
application core.
In rare cases, one person can do all of the above (for a while), but
generally we need to build teams combining domain- and technical
experts. The vendors must do what they can to make the jobs of both
these groups easier, and also explain the mechanics to managers who
need to understand how to make this work.
At Dyalog, we firmly believe that we can safely ignore the decline of
the APL market which followed the "unnatural blip" in the 70's and
80's (even though some old APL systems are still in their final death
throes). It is a false signal with respect to the fundamental value of
the technology. The truth is that APL is actually still ahead of its
time. It is our good fortune that we never had a mainframe business,
as it means that for us, APL has been always been growing - and that
growth now seems to be accelerating. We believe that we can further
accelerate the growth through:
i. Working hard to improve integration with platforms (Microsoft.Net,
Mono, perhaps Java). We've been working hard for the last several
years, with the addition of the .Net interface, Object Orientation and
finally Unicode support in v12.0, we feel we have made big steps in
the right direction. Although it is one of the fundamental values of
our product that people who are not software engineers have a complete
package which allows them to build all the components of an
application, we must also support large organizations who want to
build multi-layered, and "multi-tiered" applications using a
combination of teams skilled in APL and other technologies.
ii. Producing new books, training materials, "code patterns" - and
provide new tools for sharing code between APL users. Expect to see
the first results of this work to appear during 2008.
iii. Cultivating contacts in the dynamic/agile programming
communities, where we believe we will soon see the first openings for
marketing APL directly to developent teams (as opposed to going via
the users first).
We don't think it will be long before we'll be back in the business of
"cold calling" certain types of development teams to sell APL as a
modern technology. We are already working to start new academic
programmes using APL (it is too early to say when we will succeed with
this, but we are optimistic).
So hang in there! If you have good ideas, we'd love to hear them. But
PLEASE, PLEASE don't post messages proclaiming that "APL is dead" to
comp.lang.apl. We have shipped hundreds of educational and non-
commercial licenses over the last 18 months. Some of these new users
might be reading this news group! Don't be surprised if these people
do not contribute to comp.lang.apl. As things are today, if they
should ever read more than a few messages on this forum, they need to
be made of stern stuff to stay with us!
If you can only see grey- or white-haired APL developers and would
like to see some new APL users, come to the Dyalog User Meeting in
Denmark, October 12-15th 2008. More information about this even will
soon appear at http://www.dyalog.com/dyalog_08.htm.
Morten Kromberg
Dyalog Ltd.
|
