Whither Scientific & Engineering APL?

Doug,

As Nancy Wheeler said, APL2 generally uses shared variables for asynchronous
components. Primarily for historical reasons, we also still use shared
variables for some conceptually synchronous operations (like some flavors of
file IO.)

Basically, we support shared variable interfaces for:

Network communication
Graphics
GUI screen access (dialogs, listboxes, edit fields etc.)
Old 3270 style (formatted field) screen access
Some types of file IO
Database access
Stack processing
Issuing commands to the host environment
Running multiple APL2 interpreters

We provide cover functions for many of these operations so users often do
not need to fiddle with shared variables if they don't want to.

We also provide synchronous interfaces for file IO and calls to other
languages. Most of our Unix customers use these facilities to call Java
and/or Tcl to access those languages libraries for GUI screen IO.

You can call operating system APIs either using a synchronous interface or
on WIndows from our GUI processor (using shared variables) so you can use
the API in the context of either the APL2 interpreter or GUI processor
(which run in separate processes.)

If you want to try it out, you can download a free time-limited
demonstration version for Windows at www.ibm.com/software/awdtools/apl;
select the Trials and Demos link. Our documentation is available at the
Library link.

David Liebtag
IBM APL Products and Services

Doug,

In APL2, for graphics, you can do it either way. You can use our own AP
207, and pass requests using its syntax through shared variables, or you
can call Windows graphics API's directly from APL2. You can call
Windows API's two ways - using Associated Processor 11 which is our
general interface to external routines, or using AP 145, the Windows GUI
AP. As an example, there are demos of calling the OpenGL package in the
DEMO145 supplied workspace.

Which of these you would want to do depends on what you want to
accomplish and on what platforms. Certainly graphics packages like
OpenGl are much more sophisticated than what is provided by AP 207. But
AP 207 allows you to code something entirely in APL2, that's portable
across Windows and the Unix systems we support.

On APL2 systems where the shared variable interactions were not truly
asynchronous, (VM, DOS, and some of the older MVS AP's) it's true that
the programmer could get away with things like skipping return code
references, spec'ing multiple requests without intervening waits, etc.
On the workstation systems of today, where the processors are actually
running in separate processes, that kind of coding falls apart fast.
However, for most of the AP's, cover workspaces are provided to assist
the APL programmer, removing much of the need for low-level shared
variable interaction and enforcing proper access control.

If you want to learn about how APL2 does interfaces, I would suggest
having a look at the APL2 User's Guide, which tells you all the gory
detail about this type of stuff for Workstation APL2. Look at the
introductory sections on Associated Processors and Auxiliary Processors
and then under each of those sections, and the sections "Supplied
External Routines" and "Suppplied Workspaces" you will find the detail
on each of the processors and routines we supply.
You can get the book on-line at our web site:

http://www.ibm.com/software/awdtools/apl

Click on "library" for the books and "Trials and Demos" for our
time-limited demo version.

Nancy Wheeler
APL Products and Services
IBM

Doug White wrote:
> 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

> 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.

Doug, I strongly believe that you are making a catastrophic error in
judgement here. APLX is a clean and resilient APL provided by a
company that spends more time planning/designing new features than in
actually building those new features.

I took part in the beta trials of V3 and then of V4 (albeit to a
lesser extent) and I know not only how short the development cycle was
but also how robust the new features were.

Like you, I use APL+Win.

..... and no one makes the case for APL+Win in this forum either!

On Jun 2, 11:49 pm, gwh...@alum.mit.edu (Doug White) wrote:
> Keywords:
> In article <b4515ac7-640b-4cc9-8ac1-6c7a57e1a...@z72g2000hsb.googlegroups.com>, micro...@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

You might find helpful Beau Webber's review of APLX v4 at

http://www.vector.org.uk/archive/v233/webber.htm

Stephen Taylor

editor@vector.org.uk
http://www.vector.org.uk/
http://aplwiki.aplteam.com/

On Jun 3, 12:08 am, gwh...@alum.mit.edu (Doug White) wrote:
....
>
> 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.
>

You can see on the APL Wiki at

http://aplteam2.com/aplwiki/moin.cgi/SolitaireGame

the complete code for the game of Solitaire. It's written as a class,
which might be more of a jump into the future than you want; but one
doesn't have to use classes to write GUI in Dyalog.

(You can download and run the script in Dyalog 12, or even paste it
from the web page into the editor.)

You should be able to get a fair idea of how the GUI is built and
callbacks set and processed. I'd be glad to answer questions about it.

Stephen Taylor
sjt@dyalog.com

Keywords:
In article <9fb8310d-d287-42c7-9acf-8e6bda603d6f@25g2000hsx.googlegroups.com>, AAsk <AA2e72E@lycos.co.uk> wrote:
>..... and no one makes the case for APL+Win in this forum either!

That's one of the reasons I'm looking around. I certainly haven't been
impressed by their shift in business focus post-Manugistics. I've sent
them a few questions over the years about things like what it would cost
to upgrade my Version 3 license to the latest version. I think I've only
gotten replies to about half of my queries. The impression I have is
that they are a dwindling operation that is focussing their efforts on
big corporate accounts. If that's what it takes to stay afloat, I can't
fault them for it, but I miss the days when they were willing to work
with smaller customers.

Doug White

Keywords:
In article <26f9d9f6-8162-4492-b453-4570f21106e8@a70g2000hsh.googlegroups.com>, "Stephen Taylor <editor@vector.org.uk>" <StephenTaylorFRSA@googlemail.com> wrote:
>On Jun 2, 11:49 pm, gwh...@alum.mit.edu (Doug White) wrote:
>> Keywords:
>> In article
> <b4515ac7-640b-4cc9-8ac1-6c7a57e1a...@z72g2000hsb.googlegroups.com>,
> micro...@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
>
>You might find helpful Beau Webber's review of APLX v4 at
>
>http://www.vector.org.uk/archive/v233/webber.htm

OK, that got my attention. I have a couple of questiosn for APLX users:

There is a LOT of web/HTML/.NET stuff that I will probably never have
much use for. Does it get in the way?

They now have a far more complex product than APL68000, which I had
issues with in the past. So:

1) How good is the documentation

2) How bug-free is the code?

3) How good is the support?

If I don't want to mess with Linux, the price is still pretty steep for
an individual non-commercial user.

Thanks!

Doug White

Keywords:
In article <cd950453-0cca-42ee-b56e-76239cc5b537@b1g2000hsg.googlegroups.com>, "Stephen Taylor <editor@vector.org.uk>" <StephenTaylorFRSA@googlemail.com> wrote:
>On Jun 3, 12:08 am, gwh...@alum.mit.edu (Doug White) wrote:
>....
>>
>> 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.
>>
>
>You can see on the APL Wiki at
>
>http://aplteam2.com/aplwiki/moin.cgi/SolitaireGame
>
>the complete code for the game of Solitaire. It's written as a class,
>which might be more of a jump into the future than you want; but one
>doesn't have to use classes to write GUI in Dyalog.
>
>(You can download and run the script in Dyalog 12, or even paste it
>from the web page into the editor.)
>
>You should be able to get a fair idea of how the GUI is built and
>callbacks set and processed. I'd be glad to answer questions about it.

Yikes! I'll start with a simplified version my original question
"Whither APL?".

There are (occasional) APL operators scattered about, but 90% of this is
unrecognizable to someone who has been stuck working with the APL of old.
Upon further examination, I think I must have a font issue, because there
are lots of question marks where I would expect "lamp" comment symbols.

Is there a simple way to convince Firefox to display this correctly?

Thanks!

Doug White

On Jun 3, 6:25 pm, gwh...@alum.mit.edu (Doug White) wrote:
> Yikes! I'll start with a simplified version my original question
> "Whither APL?".
>
> There are (occasional) APL operators scattered about, but 90% of this is
> unrecognizable to someone who has been stuck working with the APL of old.
> Upon further examination, I think I must have a font issue, because there
> are lots of question marks where I would expect "lamp" comment symbols.
>
> Is there a simple way to convince Firefox to display this correctly?
>
> Thanks!
>
> Doug White

Doug, I am another long time apl user who finds many things
"unrecognizable" with APL today. I feel your pain. Hang in there.
And thanks for you input. I'm learning stuff I need to know from this
discussion. I still think apl is a great tool. And the systems are
real good mostly performance wise, I believe.

Marvin Smoak