On May 11, 1:14=A0pm, Morten Kromberg <mk...@[EMAIL PROTECTED]
> wrote:
> 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, =A0expressing 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 athttp://www.dyalog.com/dyalog_08.htm.
>
> Morten Kromberg
> Dyalog Ltd.
Brilliant!
The very first really positive article in a long long time.
I have marked my calender for a visit to good old Denmark in october.
|
