Whither Scientific & Engineering APL?

I learned APL as a tool for doing electrical engineering, and I still use
for that. I heard that at one time all engineering students at U.
Waterloo had to take APL. Somehow I doubt that is still true. I know
there are a few dwindling pockets of APL usage out there (MIT Lincoln
Laboratory for one, JPL possibly), but 99% of the focus of the APL
community seems to be on business applications. I suspect that this is
"where the money is", but there used to be a thriving market for APL that
has apparently been abandoned.

All of the new features I hear about are focussed on Windows &
networking, most of which is of limited interest to the engineering
crowd. As far as I know, IBM's APL2 is (after a decade or two?) the only
APL with native support for complex numbers.

I'm trying (in my very limited spare time) to resurrect at least a piece
of the engineering APL world through the release of the MARTHA circuit
analysis package into the public domain (http://www.marthallama.org).
The initial vesion is configured to run in APLSE to keep the entry cost
(at least in $$) to zero.

The next step is to move it to a more capable & modern APL. I've been an
STSC/Manugistics/APL2000 user for about 25 years, but their product and
their pricing is clearly geared towards businesses with deep pockets.
Their "cheapest" product is $1,750, which gets you no support. In the
engineering world, you are competing with Matlab. It's hard to find
individual pricing for it, but I doubt the basic package is that much,
and I know you'd get support.

APL could/should be Matlab's toughest competitoin, but it's probably too
late. I view this as a serious missed opportunity that could have made a
big difference in APL's stature in the world.

Because I'm old & cranky, I refuse to give in & convert all of MARTHA to
Matlab. I need to pick a modern, well supported APL that is affordable
by individuals (not just students). The best way to make inroads in the
enginering community if you can't sneak in through the academic market is
through the radio amateur & homebrew circuit builders. Most of them work
in engineering for their day jobs, and if they have a good tool they use
at home, there is at least a chance they will bring it into their
professional work. Thus spreads the virus...

I'd appreciate feedback on what folks feel would be the best APL to use
moving forward. Here are my thoughts, based on heresay & vague
recollections:

APL2000 would be nice because I've already got an ancient copy of
APL+WIN. However, there is no way an individual is going to fork over
the cash they want for a license. I am stuck at APL+WIN version 3
because I couldn't justify the cost of support & upgrades for my personal
use, much less buy a new license. I _know_ how valuable APL can be, but
it's an impossible sell at thsoe prices for somebody who isn't familiar
with it.

Because of IBM's complex number support, they are a definite contender.
However, I'm a bit leery of their mainframe heritage. I don't know how
much of the internals are still tied to EBCDIC, auxiliary processors &
mainframe file handling concepts. I have no idea what their pricing
structure is these days.

I used MicroAPL's APL68000 in the early 1990's, and even ported MARTHA to
it. The experience was not pleasant. The code was buggy, and the
support was poor. I had to re-write their SLT conversion program myself
before I could even begin. Once bitten, twice shy. I haven't paid any
attention to their offerings since.

Dyalog looks very promising. They seem A) very active, and B) friendly
towards small users who can't afford to pay full freight to experiment.
I can't recall every hearing anything negative about their product or
service. The one annoyance is (I believe) the lack of complex number
support.

Those seem to be the big players. I'd be happy to learn if there is
something viable that I missed. I have no interest in struggling with
beta versions of open source APL's, although I wish them all the luck in
the world.

Thanks!

Doug White

On Jun 1, 1:17*pm, gwh...@alum.mit.edu (Doug White) wrote:
> crowd. *As far as I know, IBM's APL2 is (after a decade or two?) the only
> APL with native support for complex numbers.

J has a native support for imaginary numbers

http://www.jsoftware.com/jwiki/Essay...lex_Operations

> The next step is to move it to a more capable & modern APL. *

...........

> I need to pick a modern, well supported APL that is affordable
> by individuals (not just students). *

.....

> I'd appreciate feedback on what folks feel would be the best APL to use
> moving forward. *

I personally use both Dyalog and J
I like them both and they both have their positive sde.

You can get J for free and Dyalog does not cost much and in many
situations (for students like me) it is free.
I started going to school (learning about growing trees and tending
woods in a University) and a side effect of that is I got Dyalog for
free.

Learning J is not so hard for anyone.

Learning the really complicated one-liners may take some time if you
are so inclined but you may never need it.
There are a number of utilities to call upon and lots of demos to copy
from so with going through some labs and using copy and paste you can
be up and running in no time.

So as far as I am concerned J is an APL.
It has imaginary/complex numbers.
It is very modern.
It is free.

If you are considering anything outside of APL then why not look at J
too?

Gosi wrote:

> If you are considering anything outside of APL then why not look at J
> too?

I'd bet that Doug knows about J but is interested in APL. Further, I'd bet that
everyone reading comp.lang.apl knows about J but is interested in APL.


Bob
--

"Things should be described as simply as possible, but no simpler."

A. Einstein

On Jun 1, 1:17*pm, gwh...@alum.mit.edu (Doug White) wrote:

> crowd. *As far as I know, IBM's APL2 is (after a decade or two?)
the only
> APL with native support for complex numbers.

What about IPSA and SAX?

" The code was buggy"

Which code please ?
My experience over decades was 0 bugs in the interpreter !
External Drivers are another matter of course !

On 1 Jun, 14:17, gwh...@alum.mit.edu (Doug White) wrote:
> I used MicroAPL's APL68000 in the early 1990's, and even ported MARTHA to
> it. The experience was not pleasant. The code was buggy, and the
> support was poor. I had to re-write their SLT conversion program myself
> before I could even begin. Once bitten, twice shy. I haven't paid any
> attention to their offerings since.
>
> ...

> Those seem to be the big players. I'd be happy to learn if there is
> something viable that I missed.

Doug, I think that if you are going to make negative comments in
public about our products and service, it would be both sensible and
courteous not to base your views on something which may or may not
have happened about 15 years ago. If you are indeed happy to learn if
there is something viable that you might have missed, please feel free
to download either our zero-cost APLX for Linux, or our time-limited
but full-featured Windows or Mac demo versions, and give them a try.

Richard Nabavi
MicroAPL Ltd

> I used MicroAPL's APL68000 in the early 1990's, and even ported MARTHA to
> it. The experience was not pleasant. The code was buggy, and the
> support was poor. I had to re-write their SLT conversion program myself
> before I could even begin. Once bitten, twice shy. I haven't paid any
> attention to their offerings since.

Hmmmm.

Is it really a good idea to make those comments decades later? Your
comment will live forever thanks to Google. Well, almost.

I used APL68000 very intensivly in the eighties. Cannot report
anything regarding support since I was never in need for this. The
interpreter was stable and fast.

I looked into APLX recently. I had no chance to use it in a real
project but it looked very promising. Has not much to do with APL68000
anyway. It is like comparing APLSV with APL2.

Doug,

The internals of Workstation APL2 are not tied to EBCDIC, or to
mainframe file handling concepts.

APL2 on all platforms uses the shared variable design model for
asynchronous data sharing between its processes. Some of those
processors are undoubtedly what you are thinking of when you say
auxiliary processors - interfaces to things like databases, files,
graphics, and GUI. The workstation auxiliary processors are written
specifically for workstations, although some of them use the same syntax
as their mainframe counterparts. We also provide synchronous call
interfaces to external programs written in APL2 or other languages, and
to things like COM and Tcl/Tk.

IBM's price structure is similar to what you quoted for the other
vendors, although a price like that would include the first year's
service contract. A tradeup price is available to licensees of Version
1 workstation APL2 products.

Nancy Wheeler
APL Products and Services
IBM

Doug White wrote:

> Because of IBM's complex number support, they are a definite contender.
> However, I'm a bit leery of their mainframe heritage. I don't know how
> much of the internals are still tied to EBCDIC, auxiliary processors &
> mainframe file handling concepts. I have no idea what their pricing
> structure is these days.

Keywords:
In article <b4515ac7-640b-4cc9-8ac1-6c7a57e1adfe@z72g2000hsb.googlegroups.com>, microapl@microapl.demon.co.uk wrote:
>On 1 Jun, 14:17, gwh...@alum.mit.edu (Doug White) wrote:
>> I used MicroAPL's APL68000 in the early 1990's, and even ported MARTHA to
>> it. The experience was not pleasant. The code was buggy, and the
>> support was poor. I had to re-write their SLT conversion program myself
>> before I could even begin. Once bitten, twice shy. I haven't paid any
>> attention to their offerings since.
>>
>> ...
>
>> Those seem to be the big players. I'd be happy to learn if there is
>> something viable that I missed.
>
>Doug, I think that if you are going to make negative comments in
>public about our products and service, it would be both sensible and
>courteous not to base your views on something which may or may not
>have happened about 15 years ago. If you are indeed happy to learn if
>there is something viable that you might have missed, please feel free
>to download either our zero-cost APLX for Linux, or our time-limited
>but full-featured Windows or Mac demo versions, and give them a try.

I'm doing this on my own time, on my own nickel, and unless I see a lot
of protests from folks OUTSIDE the company, I'm not going to consider
your products. If they wanted my business, the company should have
thought of that 15 years ago. You don't win repeat business & customer
loyalty by selling a buggy product and then supporting it poorly.
Welcome to the marketplace. Yes, that was a long time ago, and the fact
that you are still in business is an indication that (hopefully) things
have improved. Do I want to play guinea pig to see if that is the case?
Not really. I don't have time to do the work I have already decided to
tackle, and the last thing I want to do is waste time on an APL
vendor that doesn't treat their customers with more respect. MicroAPL
may be wonderful, with superb support. I haven't seen anyone supporting
that case here.

I would have been OK with the occasional bug, but what really frosted me
was the attitude I dealt with when I reported them. I tried hard to come
up with simple examples to invoke the problems, and to document them
carefully. No "Thank you for pointing this out", no "We'll try to fix
that in the next release". In many instances, I don't think I even got
the courtesy of a reply. That spoke of a corporate culture I had/have no
wish to deal with. Corporate cultures don't tend to change overnight,
which is why I am leery of going down that road again. It was
particularly annoying in contrast with the excellent support I got
regularly from STSC at that time.

If _users_ think I should reconsider MicroAPL's products, I'm willing to
listen. I already explained that I have no interest in a Linux APL. If
people feel strongly that the Windows version is A) well written, B) well
documented, and C) well supported, I will at least compare it to Dyalog,
APL2, APL+Win, etc. Unless it has compelling features or benefits, I
plan on taking my business elsewhere.

Doug White

Keywords:
In article <4845b641$1@news.greennet.net>, Nancy Wheeler <apl2@vnet.ibm.com> wrote:
>Doug,
>
>The internals of Workstation APL2 are not tied to EBCDIC, or to
>mainframe file handling concepts.
>
>APL2 on all platforms uses the shared variable design model for
>asynchronous data sharing between its processes. Some of those
>processors are undoubtedly what you are thinking of when you say
>auxiliary processors - interfaces to things like databases, files,
>graphics, and GUI. The workstation auxiliary processors are written
>specifically for workstations, although some of them use the same syntax
>as their mainframe counterparts. We also provide synchronous call
>interfaces to external programs written in APL2 or other languages, and
>to things like COM and Tcl/Tk.

So, if I want to do custom graphics operations, do I need to pass shared
variables to an auxiliary processor, or can I call Windows graphics
functions directly using something like []WIN system functions? Or is it
all the same sort of operation under a different name?

It's been a very long time since I had to deal with shared variables. I
had to remove a lot of shared variable operations when I ported some IBM
mainframe code to STSC's PC APL's. Fortunately, most of it was entirely
unneccessary and was easy to fix, but it left me with the impression that
SV's encouraged (or at least permitted) sloppy programming.

I'd be interested in comparison's of how the various APL's handle things
like executing Windows graphics operations. I know roughly how APL+WIN
does it, and I _think_ I understand IBM's approach, but I have no clue
how Dyalog deals with this.

Thanks!

Doug White