Whither APL or wither APL ?? 
Author Message
 Whither APL or wither APL ??

Does APL have a future ?  
If so, which way will it develop - mainframe, PC or Unix based ?  
Large multi-user applications or small, one-off systems ?
Bespoke applications or packaged systems ?

Or, as David Ness implied recently, is APL dead but just won't lie
down ?

I'm looking for some pertinent comments that I can include in the
Editorial for the next issue of Quote Quad.

I'll kick off by saying that the demise of APL has long been rumoured,
but every time I've been involved in maintaining an old system that
was being "replaced" the replacement never seemed to succeed. APL was
supposed to be past its sell-by date when I first started - that was
21 years ago, and now I'm back developing code in the same flavour of
APL that I first learnt - Sharp APL on an IBM mainframe under MVS.
Even in my days at IBM in the mid 1990's the old mainframe APL system
I was working on had seen off three attempts to replace it, each of
which failed.  Eventually it was withdrawn and replaced by a nice
Windows-based system, but the replacement had lost 50% of the
functionality of the original.

Any more evidence to support my view that APL will be around for a
while yet?

John Warden, APL Quote-Quad Executive Editor

(aka Henry Crun, an ancient Goon and APLer)



Fri, 09 Sep 2005 20:40:27 GMT  
 Whither APL or wither APL ??


Quote:
>Any more evidence to support my view that APL will be around for a
>while yet?

You could have a word with Dyadic about their .net stuff. This is an
example of APL keeping up with the latest ideas from Redmond.
--
John Sullivan


Fri, 09 Sep 2005 23:25:04 GMT  
 Whither APL or wither APL ??

Quote:
> Does APL have a future ?
> If so, which way will it develop - mainframe, PC or Unix based ?
> Large multi-user applications or small, one-off systems ?
> Bespoke applications or packaged systems ?
> Or, as David Ness implied recently, is APL dead but just won't lie
> down ?

I think the people who don't use APL are dead!

Fred



Sat, 10 Sep 2005 21:11:26 GMT  
 Whither APL or wither APL ??

Quote:


> > Or, as David Ness implied recently, is APL dead but just won't lie
> > down ?

> I think the people who don't use APL are dead!

> Fred

I guess it all very much depend on the definition of being dead.

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer



Sat, 10 Sep 2005 21:39:25 GMT  
 Whither APL or wither APL ??


Quote:
> Does APL have a future ?

> <snip>

> Even in my days at IBM in the mid 1990's the old mainframe APL system
> I was working on had seen off three attempts to replace it, each of
> which failed.  Eventually it was withdrawn and replaced by a nice
> Windows-based system, but the replacement had lost 50% of the
> functionality of the original.

> Any more evidence to support my view that APL will be around for a
> while yet?

Mr Crun (or may I call you "Henry"?)  --  I believe your last two
sentences are a little contradictory  --  the "lost 50% of the
functionality of the original" was the price they were prepared to pay
for a Windows-based system  --  packaging is everything  --  form is
more important than content  --  the medium is the message  --  spin
counts for more than facts  --  while this is true, a language aimed at
building better solutions is going to be at a disadvantage against its
more glitzy competitors

the madness does not end there  --  I cannot be alone in this
experience, but I have seen people s{*filter*}working systems, start on
insanely ambitious replacements, then look surprised and hurt when the
negative impact this has on the company's profits is reflected in a
reduced end-of-year bonus

also, the smaller teams required are a drawback  --  who wants to be
project manager of 4 highly productive people, when they can be in
charge of 20 average developers, turning out results at half the rate?
when it comes to project teams, size matters

sure, APL will be around for a while yet  --  in areas where the project
sponsor sees the success of the project as materially important to
his/her own bank balance  --  and I fear these are the minority

there again, I could be wrong   . . .   /phil



Sun, 11 Sep 2005 21:40:20 GMT  
 Whither APL or wither APL ??

Quote:
> a language aimed at
> building better solutions is going to be at a disadvantage against its
> more glitzy competitors

This might be true of J or K, (as a current thread on the J Forum would
indicate)  but the modern APL's have also focused on the development
environment and Windows, to the chagrin of some purists, so it is now
possible to build pure APL solutions that are quite glitzy. When my company
delivers an APL application, the end user feels he is in an app just like
Word or Excel.  In fact, compared to other in-house development efforts
using the the "glitzy" tools, our applications are much better from a visual
and user interface standpoint because the vast majority of programmers
developing in-house corportate software have no clue about GUI design.


Sun, 11 Sep 2005 22:01:13 GMT  
 Whither APL or wither APL ??

Quote:
> > a language aimed at
> > building better solutions is going to be at a disadvantage against its
> > more glitzy competitors

> This might be true of J or K, (as a current thread on the J Forum would
> indicate)  but the modern APL's have also focused on the development
> environment and Windows, to the chagrin of some purists, so it is now
> possible to build pure APL solutions that are quite glitzy

point taken  --  it is "possible" to build such systems in APL  --  is there,
however, any inherent _advantage_ in using APL?

Quote:
> . . . When my company
> delivers an APL application, the end user feels he is in an app just like
> Word or Excel.  In fact, compared to other in-house development efforts
> using the the "glitzy" tools, our applications are much better from a visual
> and user interface standpoint because the vast majority of programmers
> developing in-house corporate software have no clue about GUI design.

but this isn't a property of the language, surely?

here, I must include one case I know of, from the early days of OLE,
where the developer switched to Dyadic, because their OLE interface was
the only one that worked properly  --  but again, I don't think this is
a property of the language

regards   . . .   /phil



Sun, 11 Sep 2005 22:52:42 GMT  
 Whither APL or wither APL ??


Quote:
> point taken  --  it is "possible" to build such systems in APL  --  is
there,
> however, any inherent _advantage_ in using APL?
> but this isn't a property of the language, surely?

I think the answer is yes, for two reasons.

1) Independent of any particular language, there is an advantage to using
fewer tools and environments to the extent possible. Every additional tool
used in delivering an application increases complexity by an order of
magnitude. It is better to use 1 tool that is second best at solving each of
10 problems, than it is using 10 tools each of which is the absolute best at
solving one of the 10 problems.  The  saying "use the right tool for the
right job" ignores the often significant costs of using other tools. Aside
from the dollar costs of the software itself, the costs of bugs,
maintenance, and most importantly , the acquisition of knowledge, can be
huge. My feeling is "use the right tool for the right job, but only use one
tool."  If that won't work, redefine the job.

2) The advances in the Dyalog APL interpreter of  GUI, namespaces, refs, dot
syntax and dynamic functions allows the APL programmer to use his array
manipulation and functional programming skills to creating and managing GUI.
As a programmer, not a language theorist, it seems to me that Dyalog has
seamlessly integrated GUI, ACTIVE X, COM, etc, into the very language of APL
iteself.  What is the difference between an array of numbers and an array of
buttons? Or an array of forms?  The practical advantages of this are hard to
overstate. It seems to me that it is a testament to the sheer genius of the
original language that this is possible.

Thus, I think it is not only "possible" to build glitzy systems in APL, but
there are huge advantages to doing so. I am presenting a tutorial along
these lines at the APL conference in San Diego.

Regards,

Paul



Mon, 12 Sep 2005 00:22:37 GMT  
 Whither APL or wither APL ??


Quote:

> ...What is the difference between an array of numbers and an array of
> buttons? Or an array of forms?  The practical advantages of this are hard
to
> overstate. It seems to me that it is a testament to the sheer genius of
the
> original language that this is possible.

> Thus, I think it is not only "possible" to build glitzy systems in APL,
but
> there are huge advantages to doing so...

i think paul is 100% correct. while i have no experience using dyalog apl,
i have extensive experience writing a+ and k gui apps. a+ has the original
"data-driven" gui designed by stevan apter at morgan stanley. it is
incredibly
powerful and productive. arthur whitney built a data-driven gui into the
current
version of k which is blazingly fast, but minimalist. at dfa, stevan and i
have
writen yet another data-driven gui for k using java's swing libraries
which is wonderful. dfa's ADVISE(tm) software is written completely in k,
yet it
looks and behaves like any other windows application. the leverage we get
for programming gui apps with our k/java software is really amazing.

mike



Tue, 13 Sep 2005 00:32:11 GMT  
 Whither APL or wither APL ??

Quote:



> > > Or, as David Ness implied recently, is APL dead but just won't lie
> > > down ?

> > I think the people who don't use APL are dead!

> > Fred

> I guess it all very much depend on the definition of being dead.

> Bye, Dragan

Dead is best defined as still thinks Cobol is pretty cool and insists
on 20 pages of documentation for every line of code ;)

Henry  Crun



Tue, 13 Sep 2005 18:40:51 GMT  
 Whither APL or wither APL ??


Quote:
> Does APL have a future ?

Hopefully, but i think there are some important issues. Speaking of Dyalog
APL only:

- Pete Donnelly & Co may get old some day, and decide to resign. Who will
continue?
- APL should cooperate/interact with the leading OS as much as possible.
- Should keep up with new technologies around that/these OS's.
- Should not focus on "maths, statistics, scientific etc".
- Should focus on business & free enterprise solutions, not government or
alike, as insurance (or even banking?).
- Free/better interaction between the vendors and the users.
- Should provide a better production framework in general.

Take a look at the J discussion forum. Even i have to sometimes spend time
before understanding what they talk about. Imagine a young programmer with a
VB background going there... he'll drop out before you can say 'bottle'.
This is not where APL to go.

There was a post favoring a single development tool over "the best language
for each task". I agree wholeheartedly. Mastering multiple languages
cannot/should not be the best solution. I think it would be best to use APL
for core code and having the ability to invoke C where needed. Unless we get
the option to compile APL code segments (was a discussion about that a few
months ago).

Instead of using the most appropriate language for each task, i'd use the
most appropriate task for this language. I.e. avoid doing things that don't
fit into the APL philosophy.

At the moment, we (me and one colleague) deliver applications for the
industry. Typically we focus on a few core products and split off custom
applications from these whenever possible. These are "fancy GUI" apps with
advanced logic behind. The strategy is that the custom apps may not be dead
ends in terms of product survival. Instead, they should be general purpose
enough to attract at least a handful of other users too. Going just into any
direction would create a chaos portfolio of delivered systems, and that we
couldn't support.

If the task is fit, we are able to produce a functional prototype within a
few days. Version 1 in a few months.

Seems to me that very much depends on the APL vendors and their actions. I
support the brute force thinking that a product always finds it's users if
it's good enough. Thus, APL still lacks something. Perhaps it would be best
if all APL vendors joined to fight. This is how other companies do too.

/ Tomas



Tue, 13 Sep 2005 19:26:05 GMT  
 Whither APL or wither APL ??
Whether the language will survive or not depends on a number
of factors, such as how many computer science students are
exposed to it at an early stage, the effectiveness of APL
enthusiasts at getting other people to try the language,
and so on.

There is no question that APL is very useful for rapid
code development as it allows you to think at a higher
level and protects you from errors that often plague
programs written in other languages.  For example, the
most common type of error in C or C++ is a pointer error,
such as incrementing a pointer too far and running off of
the end of an array.  People are constantly finding security
holes caused by this type of error in system software. In
APL you'd immediately get an INDEX ERROR message with a
clear indication of where the error was in the code.
Moreover, APL code is usually much shorter than the
equivalent code in another language, so there is a lower
chance of typographical errors (especially if you are

on a particular interpreter's keyboard :-).

There are some changes that could be made to improve the
attractiveness of APL to those not currently using it,
including:

* Standardizing access to host system files.  I recall
  seeing an article in the APl Conference Proceedings
  suggesting that file handles be abandoned in favor of
  file names for identifying files to be operated on.
  The APLIWIN interpreter took this approach.  The most
  feasible approach, given the existing diversity of file
  access methods would probably be to define a set of
  standard cover functions for file access and asking
  vendors to implement these in a standard workspace
  bundled with the interpreter.

* Standardizing GUI operations.  There are certain basic
  operations that apply to all GUIs; there's no reason
  why these have to be supported in a different way by
  every vendor.  Again, a standardized workspace might
  be the easiest way to do this.

* A powerful, low-cost interpreter.  APLI386 and APLIWIN
  were amazing bargains, and were fully functional APL
  interpreters running on a standard PC.  They even
  supported complex numbers, which some of the major APL
  interpreters around today do not seem to do.  
  Unfortunately, APLIWIN's GUI system seems to experience
  some sort of memory problems when run under NT; I don't
  know how it would fare under Win2K.  I'd like to get it
  working with Wine under Linux if I can find the time.
  This sort of interpreter would be ideal for students;
  it would be cheaper than a typical textbook.

* More cross-fertilization.  SAX has some very useful
  and powerful J-like features such as the rank and cut
  operators and a more general form of "each".  On the
  other hand, APL2 has user-defined operators and the
  convenience of strand notation.  It would be nice to
  see all of these features in a single interpreter.

--- Brian



Tue, 13 Sep 2005 22:36:01 GMT  
 Whither APL or wither APL ??

Quote:
> the end of an array.  People are constantly finding security
> holes caused by this type of error in system software. In
> APL you'd immediately get an INDEX ERROR message with a
> clear indication of where the error was in the code.

Immediately, or, possibly, several months after it was released at the
customer's site.
--
  WildHeart'2k3


Wed, 14 Sep 2005 00:42:23 GMT  
 Whither APL or wither APL ??

Quote:
> <snip>
the
> most common type of error in C or C++ is a pointer error,
> such as incrementing a pointer too far and running off of
> the end of an array.

I have a C text somewhere which says that the three most common causes
of error are (i) uninitialised variables, (ii) dereferencing pointers
too little or too much, and (iii) addressing arrays out of bounds

all of these are pretty well impossible in APL, so why do people stick
with C/C++ ?

any suggestions?   . . .   /phil



Wed, 14 Sep 2005 01:18:27 GMT  
 Whither APL or wither APL ??

Quote:



>> <snip>
> the
>> most common type of error in C or C++ is a pointer error,
>> such as incrementing a pointer too far and running off of
>> the end of an array.

> I have a C text somewhere which says that the three most common causes
> of error are (i) uninitialised variables, (ii) dereferencing pointers
> too little or too much, and (iii) addressing arrays out of bounds

> all of these are pretty well impossible in APL,

All of these are also pretty well impossible in Java, one
reason why (many) people don't stick with C/C++.  In fact,
(i) is "less possible" in Java than in APL (compile time
error vs run-time error).  

Quote:
> so why do people stick with C/C++ ?

Why do people stick with C/C++?  Personal inertia (I know how to
do this) or institutional inertia (we have a lot of C/C++ maintain
and we have C/C++ expertise on staff).  And lots of people have
switched from C/C++ to Java (3 of 4 in the shop where I work).

If the real question is "why don't people switch from C/C++ to
APL/J/K/..." partly it's a -big- paradigm switch and partly it
can be hard to justify in terms of job prospects (thought the
economics are different for independent consultants).



Thu, 15 Sep 2005 07:18:55 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Whither APL or wither APL ??

2. APL on a chip [was Re: Whither APL or wither APL ??]

3. Whither rather than wither (was: Whither Smalltalk?

4. I-APL, Vanguard APL, and APL.68000

5. Whither APL users?

6. Whither APL News?

7. Toronto APL SIG Meeting - March 24 - Whither Windows?

8. Trying to hire APL and DYALOG APL for Dallas

9. Converting Dyalog APL Multiple Assignments to APL*PLUS

10. Special Functions for APL (and making APL atractive for Science)

11. APL! (APL bang)

12. APL News and I-APL (New World)

 

 
Powered by phpBB® Forum Software