APL95 
Author Message
 APL95

I agree somewhat with the ideas for APL95, but I still
think you are missing the boat.

The APL conferences now attract a certain class of people -
developers of APL interpreters, and people who do use APL (and
J) to solve scientific or other problems but could just as
easily use something else (i.e. they can choose), and people
who just happen to love APL.  This I think happens to be the
same class of people who dominate the discussion in this forum.
These people want to discuss control structures and other
language issues.

I talk to customers all the time in my job.   Granted, these
are only IBM customers, but still.    I never had <one> of
them ask if I knew of any good tutorials on Neural Nets they
could go to, and only one or two have ever wanted to discuss
language extensions and theory.

There is a whole other class of APL user out there.  These
are the ones whose job it is to maintain and write applications
in APL.  They work for corporations, big and small.  They have
an APL.  They want to know how to use what they have better.
They usually don't have the ability to change what APL they use.
Most of them don't know anything about SIGAPL or APL conferences.

If you want to attract this kind of user to an APL conference
you have to offer them something they can show their manager
which will justify that manager spending his/her money.

What kind of things do these people usually want to know?
  - how can I improve the performance of my application?
  - how do I migrate APL code from platform/vendor x to
    platform/vendor y?
  - What are my options for data storage/function storage
    and what are the pros/cons of each?
  - What new features in the latest release of my APL are
    there and why should I start using them?
  - Where can I find a class on advanced programming in APL?
  - What is the best way to do APL training? find new APL
    programmers?
  - How do I solve the printing/terminal emulator character
    set problem?

These are just a few examples.  Note that the focus is on
how to use what they have, not what there might be in the
future.  If you could get some of these people
to the conference they might be convinced to participate
in discussions about the future.  But proposals for the future
and reports on somebody else's successful application
is not what will get them there.  Useful practical stuff is
what will.

I would suggest a full-week track of tutorials directed at
this audience.  I know it will be difficult with the multiple
APL vendors to address all the environments, but the vendors
just might be willing to help in getting the word out to their
customers and in presenting.  It definitely should be balanced
(i.e. the issues of data/function storage, and performance
tuning, etc. will be different for the different vendors.)

Hope I haven't offended anyone's sensibilities.....just
trying to offer a more practical point of view.

Nancy Wheeler
IBM APL Products



Mon, 24 Mar 1997 00:07:58 GMT  
 APL95

Quote:

>I agree somewhat with the ideas for APL95, but I still
>think you are missing the boat.

{Lots of good stuff deleted}

Quote:

>There is a whole other class of APL user out there.  These
>are the ones whose job it is to maintain and write applications
>in APL.  They work for corporations, big and small.  They have
>an APL.  They want to know how to use what they have better.
>They usually don't have the ability to change what APL they use.
>Most of them don't know anything about SIGAPL or APL conferences.

>If you want to attract this kind of user to an APL conference
>you have to offer them something they can show their manager
>which will justify that manager spending his/her money.

>What kind of things do these people usually want to know?
>  - how can I improve the performance of my application?
>  - how do I migrate APL code from platform/vendor x to
>    platform/vendor y?
>  - What are my options for data storage/function storage
>    and what are the pros/cons of each?
>  - What new features in the latest release of my APL are
>    there and why should I start using them?
>  - Where can I find a class on advanced programming in APL?
>  - What is the best way to do APL training? find new APL
>    programmers?
>  - How do I solve the printing/terminal emulator character
>    set problem?

>These are just a few examples.  Note that the focus is on
>how to use what they have, not what there might be in the
>future.  If you could get some of these people
>to the conference they might be convinced to participate
>in discussions about the future.  But proposals for the future
>and reports on somebody else's successful application
>is not what will get them there.  Useful practical stuff is
>what will.

>I would suggest a full-week track of tutorials directed at
>this audience.  I know it will be difficult with the multiple
>APL vendors to address all the environments, but the vendors
>just might be willing to help in getting the word out to their
>customers and in presenting.  It definitely should be balanced
>(i.e. the issues of data/function storage, and performance
>tuning, etc. will be different for the different vendors.)

>Hope I haven't offended anyone's sensibilities.....just
>trying to offer a more practical point of view.

Fantastic! This is the first breath of fresh air I've seen in
this discussion yet! Other ideas, please!

Bob



Mon, 24 Mar 1997 07:53:49 GMT  
 APL95
Nancy Wheeler:
: I talk to customers all the time in my job.  Granted, these are only
: IBM customers, but still.  I never had <one> of them ask if I knew
: of any good tutorials on Neural Nets they could go to, and only one
: or two have ever wanted to discuss language extensions and theory.

Right, and I wouldn't discuss such ideas with my APL vendor.  In my
experience, APL vendors are not very receptive to just broad sweeping
conceptual discussions -- APL vendors want focussed issues that can be
dealt with to get the user over some immediate stumbling block.  For
example, I'd be more likely to want to discuss things like defects in
file handling, or maybe I'd wish for better mechanisms for dealing
with "very large variables".

In other words, with an APL vendor I'd discuss implementation issues,
not language issues.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Mon, 24 Mar 1997 09:07:39 GMT  
 APL95
Nancy Wheeler talks about making APL95 a real "user's" conference,
a venue for teaching more people more APL.  That is a worthy goal, but
obviously quite different from what Bob has in mind, a "superuser's"
conference.  Perhaps it can be both, I don't know.  I would like to
comment on just one point:

Quote:
>What kind of things do these people usually want to know?
>  - What new features in the latest release of my APL are
>    there and why should I start using them?

This suggests, to get greater participation (and revenue) the APL vendors
should introduce new features.  Which is exactly what they have been doing
the last dozen years.  The problem for us is that this is vendor driven, not
(super?)user driven.  The result is not always progress, but incompatibility.
Many of us here would like to see a users' initiative or even revolt.
However there simply aren't enough superusers to make a difference (on the
bottom line), and many seem to be afraid to tell typical users the truth,
that APL needs help, even when everyone already knew APL is becoming
increasingly a niche product (read: dying).

(Any statistics on the number of APL users or on revenue?  Are the vendors
getting bigger or smaller?  What happened to I.P.Sharp's people?)

Quote:
>These are just a few examples.  Note that the focus is on
>how to use what they have, not what there might be in the
>future.  If you could get some of these people
>to the conference they might be convinced to participate
>in discussions about the future.  But proposals for the future
>and reports on somebody else's successful application
>is not what will get them there.  Useful practical stuff is
>what will.

Structured programming techniques in APL, and why it would be simpler in
a better/future APL.  Many of us here could teach a tutorial on it (and
would teach very differently!).

Quote:
>I would suggest a full-week track of tutorials directed at
>this audience.  I know it will be difficult with the multiple
>APL vendors to address all the environments, but the vendors
>just might be willing to help in getting the word out to their
>customers and in presenting.  It definitely should be balanced
>(i.e. the issues of data/function storage, and performance
>tuning, etc. will be different for the different vendors.)

It might become cut-throat competitive...  Users would love it, so the
vendors would probably nix the idea.




Mon, 24 Mar 1997 04:27:20 GMT  
 APL95

Quote:
>Nancy Wheeler talks about making APL95 a real "user's" conference,
>a venue for teaching more people more APL.  That is a worthy goal, but
>obviously quite different from what Bob has in mind, a "superuser's"
>conference.  Perhaps it can be both, I don't know.  I would like to
>comment on just one point:

Actually, Nancy and I have very similar strategic goals:
  - increase the # people at APL conferences
  - increase the # people using APL and exposed to it.
  - increase the # people using APL applications

Our tactics may vary, but our strategies are strongly aligned.

I think there is room for both applications and theory stuff at a conference.

Quote:

>This suggests, to get greater participation (and revenue) the APL vendors
>should introduce new features.  Which is exactly what they have been doing

Not clear to me at all. Rampant featureism hasn't helped one whit.

Quote:
>(Any statistics on the number of APL users or on revenue?  Are the vendors
>getting bigger or smaller?  What happened to I.P.Sharp's people?)

They got canned when/soonafter Reuters bought the company for its
database biz, and decided that "APL isn't strategic".

Quote:

>Structured programming techniques in APL, and why it would be simpler in
>a better/future APL.  Many of us here could teach a tutorial on it (and
>would teach very differently!).

To attract a good audience here, you'll have to focus on very pragmatic
ends:
   - Why SP will reduce your development time
   - Why SP will reduce maintenance costs
   - Why SP will improve product reliability
   - Why SP will enable higher performance

Rather than preach The Religion Of Structured Programming. Hmm, maybe
the above IS the religion...  At any rate, if you address, as Nancy
suggested, professional applications writers' needs, you'll be able to
draw a good crowd. Please submit your tutorial plans to the Conference
ASAP!

Quote:
>>this audience.  I know it will be difficult with the multiple
>>APL vendors to address all the environments, but the vendors
>>just might be willing to help in getting the word out to their
>>customers and in presenting.  It definitely should be balanced
>>(i.e. the issues of data/function storage, and performance
>>tuning, etc. will be different for the different vendors.)

>It might become cut-throat competitive...  Users would love it, so the
>vendors would probably nix the idea.

I doubt that. Difference vendors have different markets and different
price points. Their users differ greatly in their needs. I think such
sessions would complement one another nicely.

Bob



Tue, 25 Mar 1997 01:02:35 GMT  
 APL95

Quote:

>As one of the users Nancy Wheeler described in her posting, I think
>she has brought up an important point.  The APL community is a spectrum
>of people ranging from 'super users' who are interested in esoteric
>uses and extensions to the language, to people who are just trying to
>get their work done efficiently using APL (or J) as their prefered tool.

>If the concern is lack of attendance at APL conferences, I agree with
>Nancy.  I'm a microwave circuit designer, NOT a computer scientist/
>programmer.  There is no way my boss is going to foot the bill for me
>to go to Helsinki unless I can convince him that the conference will
>significantly improve my effectiveness.  They can get a lot more out

This is generally the case. Most of the theory discussions is NOT
relevant to large conferences, where the spread in knowledge is
great in both breadth and depth. Conferences are good places do to
"Look at the stuff I can do with this here new thingy our product has"
but are NOT good places to discuss/design/argue about theory: Too much
time is spent going over old turf.

This stuff is best dealt with at small workshops, such as those organized
by Garth Foster, where a FEW people can put their heads together and
powwow. However, a conference CAN be a good place to rattle cages, and
get vendors to respond to users' needs.

Quote:
>of their money by sending me to a vendor class than by shipping me off
>to a conference where the program is dominated by discussions of
>language extensions and theory.  If you can pad the program with more
>tutorials and workshops, then I might have a good excuse to attend.

Done. Your wish is our command. Except it won't be padding, but an
integral part of the conference.

Quote:
>Just to give a bit of perspective on what that means, I'm not ALLOWED
>to use any of the new features of APL II or III, because all of the
>code I develop has to usable by people still running APL*PLUS/PC and
>APL.68000 Level I.  Unless I want to support numerous different
>versions of everything (fat chance), I won't use a feature available in
>only one implementation, unless there is a REALLY compeling reason.

So, it looks to me as if what you'd REALLY want from a pragmatic
standpoint [in terms of changes in vendor products] is TRUE compatibility
at a higher level than is available now. Perhaps you'd like to lead
a panel or run a small vendor powwow followed by a presentation
to the assembled hordes on concrete steps vendors have agreed to
make to their products within timeframe X? This is the kind of thing
that would be best done NOW, working with vendors {"Hey, we're having
a meeting at MIT to talk about convergence of APL. Don't miss out!"}
so that the hard work can be done now, and APL95 can merely announce
what's been accomplished.

Bob



Tue, 25 Mar 1997 02:06:36 GMT  
 APL95
Doug White:
: Just to give a bit of perspective on what that means, I'm not
: ALLOWED to use any of the new features of APL II or III, because all
: of the code I develop has to usable by people still running
: APL*PLUS/PC and APL.68000 Level I.  Unless I want to support
: numerous different versions of everything (fat chance), I won't use
: a feature available in only one implementation, unless there is a
: REALLY compeling reason.  ..  I'd love to use APL*PLUS III, only
: NONE of the graphics software I've written will run under it.

Interesting.

It would be nice to have a description of what features you
use/consider essential for cross platform compatibility.  In
particular, what graphics primitives do you use?  [I imagine you're
using cover functions of some sort -- but what are they like, and what
sorts of things do they rely on?]

If you make this kind of information known, you make it significantly
more probably that future APL implementations will be useful to you.

It wouldn't take much to turn this (description of your environment,
and especially how you approach i/o) into an APL95 presentation.  From
what I've seen, this is a wheel that frequently needs to be
reinvented.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Tue, 25 Mar 1997 03:44:30 GMT  
 APL95
Robert Bernecky:
: Which vendors did you have in mind?
...
: Usually, vendors have to keep asking users over and over again:
: "What problem are you trying to solve", because it's RARE for users
: to pose problems; they are always proposing solutions.

I work in a rather strange environment -- STSC (now Manugistics)
APL*PLUS/VM on a CMS machine, with OS hacks also introduced by STSC.
Furthermore, the application has more dusty deck apl coding than any
I've ever heard of (megabytes of code, dating back to the 70s in some
cases).  Plus, there's gigabytes of data encoded in a form specific to
this interpreter (so, while migration to another platform has been
discussed endlessly we're still using this same configuration).

The APL platform I work with is not "a current product" of
Manugistics.  So, everything that's done on the APL environment is
piece work.

Problems I have to face (because of these restriction) are about 12M
workspace size, about 6000 symbols in an active workspace, and a file
locking mechanism that will under a well documented circumstance
(relating to the OS hacks) kill the APL program which asserted the
lock.

And, since we're not talking about a system where you can casually
rewrite the code, these are problems that become visible to customers
at inopportune times.

Now, it's true that *most* code doesn't run into these limits.
However, as one of the people responsible for the trouble-free
operation of this system, I still run into situations where these
limits stand squarely in the way of a timely problem solution.  And
into situations where purchased utilities (perhaps 10 years old, or
more) don't quite work the way they're documented to work.

And, all these problems can be dealt with.

And, of all these problems, the one that currently bothers me the most
is the limit on symbol table size.  This interfers rather strongly
with some "good coding style" practices (small functions, significant
names).

Anyways, most of the time I don't talk to the vendor -- most of the
time I talk to our locals systems admin.  Occasionally, I find a bug
that is recognized as an implementation bug (as opposed to a site
specific problem), and that gets reported to the vendor -- sometimes
then, I've wound up talking to them.

Of course, this is a highly unstable situation so things are likely to
change somehow -- hopefully for the better.

Worst comes to worst, I'll re-write the APL interpreter myself (on my
own time).  It's that frustrating.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Tue, 25 Mar 1997 04:14:39 GMT  
 APL95

Quote:

>...  They can get a lot more out
>of their money by sending me to a vendor class than by shipping me off
>to a conference where the program is dominated by discussions of
>language extensions and theory.  If you can pad the program with more
>tutorials and workshops, then I might have a good excuse to attend.

Let's follow the artists and call them Master Classes.  The point being,
there can be multiple classes on similar topics, taught by different people.

Quote:
>Some of the 'super users' may feel that the purpose of the conferences
>is solely for the discussions for the 'super user' crowd...
>If the goal of the conferences is to serve the
>_entire_ APL community, you need more stuff for the blighters in the
>trenches.  

The goal of EVERYTHING should be to get (more) people to learn (more) APL...

(Anyone here learned APL recently?)

Quote:
>Just to give a bit of perspective on what that means, I'm not ALLOWED
>to use any of the new features of APL II or III, because all of the
>code I develop has to usable by people still running APL*PLUS/PC and
>APL.68000 Level I.  Unless I want to support numerous different
>versions of everything (fat chance), I won't use a feature available in
>only one implementation, unless there is a REALLY compeling reason.
>I'm doing my best to steer everyone towards APL*PLUS II/386, but I
>still have several Mac die-hards to contend with, and a large installed
>base of APL*PLUS/PC users running on site licensed software who can't
>justify the expense of upgrading to APL*PLUS II/386.  I'd love to use
>APL*PLUS III, only NONE of the graphics software I've written will run
>under it.  THESE are the problems _I_ have to deal with, and I haven't
>seen a lot of stuff in the conference procedings that's going to help
>me solve them.

Mostly because, there are no simple solutions.  For a reason.

Quote:
>I'm not shopping for sympathy, just trying to point
>out that there may be a lot of avid APL users that have more mundane
>things to worry about than the latest control structures and paradigms.

There are four recurrent themes: efficiency, control, glyphs, and standards.
Eventually "our" focus will turn to standards.  In fact, these issues are
deeply inter-related, and all stem from one root: there has never been a free,
fun-to-use "alternative" APL (J might get there...), so it is to every single
implementor's near-term advantage (survival) to stay compatible with the past
but incompatible (or one-way compatible) with one another.  Indeed, we call
them "APL vendors", a curious term.  Until we users and superusers _together_
change the basic fact that APL has always been vendor-driven, not user-driven,
APL will never standardize and (y)our problems will never be solved.  Right
now it probably costs a million dollars to do a port, and since only a few
people have the skills _and_ access to the code, APL will never appear on the
latest or nonstandard hardware such as inexpensive multiprocessors.  There
must be an OPEN implementation of APL that can be ported to various machines
by various people (including vendors) at very low cost.  It doesn't have to be
industrial strength but must be fun to use.  Once people used it they will
want to go to the vendors for better implementation or support.  They will
even ASK for nested blocks and local functions because without them it
wouldn't be real APL :-)




Tue, 25 Mar 1997 05:11:34 GMT  
 APL95

As one of the users Nancy Wheeler described in her posting, I think
she has brought up an important point.  The APL community is a spectrum
of people ranging from 'super users' who are interested in esoteric
uses and extensions to the language, to people who are just trying to
get their work done efficiently using APL (or J) as their prefered tool.

If the concern is lack of attendance at APL conferences, I agree with
Nancy.  I'm a microwave circuit designer, NOT a computer scientist/
programmer.  There is no way my boss is going to foot the bill for me
to go to Helsinki unless I can convince him that the conference will
significantly improve my effectiveness.  They can get a lot more out
of their money by sending me to a vendor class than by shipping me off
to a conference where the program is dominated by discussions of
language extensions and theory.  If you can pad the program with more
tutorials and workshops, then I might have a good excuse to attend.

I find the 'super user' discussions that occur in c.l.a interesting to
browse through, and a number of the conference papers look interesting,
but not 'useful' in any immediate sense for _my_ work.  I think it's great
that this sort of stuff is going on, and I regret that I don't have the
time to participate more fully.

Some of the 'super users' may feel that the purpose of the conferences
is solely for the discussions for the 'super user' crowd.  If that's
the case, they shouldn't expect overwhelming popularity and big
attendance numbers.  If the goal of the conferences is to serve the
_entire_ APL community, you need more stuff for the blighters in the
trenches.  

Just to give a bit of perspective on what that means, I'm not ALLOWED
to use any of the new features of APL II or III, because all of the
code I develop has to usable by people still running APL*PLUS/PC and
APL.68000 Level I.  Unless I want to support numerous different
versions of everything (fat chance), I won't use a feature available in
only one implementation, unless there is a REALLY compeling reason.
I'm doing my best to steer everyone towards APL*PLUS II/386, but I
still have several Mac die-hards to contend with, and a large installed
base of APL*PLUS/PC users running on site licensed software who can't
justify the expense of upgrading to APL*PLUS II/386.  I'd love to use
APL*PLUS III, only NONE of the graphics software I've written will run
under it.  THESE are the problems _I_ have to deal with, and I haven't
seen a lot of stuff in the conference procedings that's going to help
me solve them.  I'm not shopping for sympathy, just trying to point
out that there may be a lot of avid APL users that have more mundane
things to worry about than the latest control structures and paradigms.

Doug White
MIT Lincoln Laboratory    



Mon, 24 Mar 1997 23:32:29 GMT  
 APL95

Quote:
>Nancy Wheeler:
>: I talk to customers all the time in my job.  Granted, these are only
>: IBM customers, but still.  I never had <one> of them ask if I knew
>: of any good tutorials on Neural Nets they could go to, and only one
>: or two have ever wanted to discuss language extensions and theory.

>Right, and I wouldn't discuss such ideas with my APL vendor.  In my
>experience, APL vendors are not very receptive to just broad sweeping
>conceptual discussions -- APL vendors want focussed issues that can be
>dealt with to get the user over some immediate stumbling block.  For

Which vendors did you have in mind?

Quote:
>example, I'd be more likely to want to discuss things like defects in
>file handling, or maybe I'd wish for better mechanisms for dealing
>with "very large variables".

>In other words, with an APL vendor I'd discuss implementation issues,
>not language issues.

Huh? I never heard a user or an APL vendor talk that way.
I get this kind of stuff from GOOD users:

a. I want APL to run 10x faster.
b. I need better security for xxx.
c. My system bogs down when I get more than 1000 concurrent users.

I get this kind of stuff from BAD users:

a. Our Firm wants you to implement the BELCHFIRE primitive. This
   will make our Most Important Application run 10x faster,
   and Save Our International Bacon. We want this next week.

b. Next week: Our Firm wants you to implement the BRIMSTONE
   primitive. This will ... MIA ...SOIB... We want this tomorrow.

   US: What about BELCHFIRE?
   THEM: Oh, the guy heading up that department Is No Longer With
    The Firm. We aren't running that Application any more.

c. ALL the problems of the APL world would be solved if you'd
   just introduce a function that would solve systems of non-linear
   equations and display graphics while sending email all at once.
   You have no idea how important this is.

Now, to be fair, all of these have a common thread: The user has a
REAL problem, and they're trying to make things EASIER for the vendor
by proposing what they view as a solution to it. Granted, (a) and
(b) are a bit vile, but if the vendor is listening, it's usually
possible to step a bit away from the problem, and produce a more
effective solution that is relevant to a much larger audience.

For example, one user bugged me on a regular basis for a "string search"
primitive, claiming that his entire application was bogged down by
string search time. A look at the application showed that string
search time was about 3% of the entire system, so an infinitely fast
string search would have reduced his cost to 97%. Whoopie.
However, a conjunction that did string-search-like stuff [by
taking AND, EQUAL] as an argument would also be beneficial for
applications like convolution [PLUS,TIMES], and hence be usable to
a larger audience.

Usually, vendors have to keep asking users over and over again:
"What problem are you trying to solve", because it's RARE for
users to pose problems; they are always proposing solutions.

Bob



Tue, 25 Mar 1997 01:19:12 GMT  
 APL95

Quote:

>>This suggests, to get greater participation (and revenue) the APL vendors
>>should introduce new features.  Which is exactly what they have been doing
>Not clear to me at all. Rampant featureism hasn't helped one whit.

That's because you deleted the previous three lines, quoted from Nancy.
Go back and re-read.

The rest are differences at guesswork.




Tue, 25 Mar 1997 05:52:44 GMT  
 APL95

writes:
.......deleted.
Quote:
>>I'm doing my best to steer everyone towards APL*PLUS II/386, but I
>still have several Mac die-hards to contend with, and a large installed
>base of APL*PLUS/PC users running on site licensed software who can't
>justify the expense of upgrading to APL*PLUS II/386.  I'd love to use
>APL*PLUS III, only NONE of the graphics software I've written will run
>under it.  THESE are the problems _I_ have to deal with, and I haven't
>seen a lot of stuff in the conference procedings that's going to help
>me solve them.  I'm not shopping for sympathy, just trying to point
>out that there may be a lot of avid APL users that have more mundane
>things to worry about than the latest control structures and paradigms.

>Doug White
>MIT Lincoln Laboratory    

ditto on the unabelievable decision to leave graphics ( i.e. plotting ) out
of APL*PLUS III. Even more unvelievable was Manugistics response when I
complained that it made the product useless for me; they seemed surprised
anyone would need graphics support...essentially 'too bad' was their
attitude.

--------------------------------------------------------------
Tom Corrigan
The Johns Hopkins University / Applied Physics Laboratory



Wed, 26 Mar 1997 02:59:46 GMT  
 APL95


writes:

Quote:
> Doug White:
> : Just to give a bit of perspective on what that means, I'm not
> : ALLOWED to use any of the new features of APL II or III, because all
> : of the code I develop has to usable by people still running
> : APL*PLUS/PC and APL.68000 Level I.  Unless I want to support
> : numerous different versions of everything (fat chance), I won't use
> : a feature available in only one implementation, unless there is a
> : REALLY compeling reason.  ..  I'd love to use APL*PLUS III, only
> : NONE of the graphics software I've written will run under it.

> Interesting.

> It would be nice to have a description of what features you
> use/consider essential for cross platform compatibility.  In
> particular, what graphics primitives do you use?  [I imagine you're
> using cover functions of some sort -- but what are they like, and what
> sorts of things do they rely on?]

> If you make this kind of information known, you make it significantly
> more probably that future APL implementations will be useful to you.

> It wouldn't take much to turn this (description of your environment,
> and especially how you approach i/o) into an APL95 presentation.  From
> what I've seen, this is a wheel that frequently needs to be
> reinvented.

> --
> Raul D. Miller

Graphics is always going to be a pain when you are working on different
platforms.  Now that the world is headed towards a window-based model
(i.e. Mac, MS Windows, X), there may be some hope.  Unfortunately, I'm
not convinced that is possible yet for language vendors to produce
platform independent graphics primitives.

When I first started using APL, MIT Lincoln Laboratory had a very nice
graphics package that ran on the old Tektronix 4015 storage-tube terminals.
At the core, it was based on PLOT10 (a Tektronix APL package), but it
had been _extensively_ embellished.  This ran on our mainframe, originally
under IBM's APL, and later (with some help from Lincoln) under STSC's
APL.

Then the PC came out, and when I had a PC/AT, I got STSC APL*PLUS.  
Because I wanted at least some of the same sort of graphics capability,
I started trying to create a similar package using the #Gxxx type
graphics.  Almost EVERYTHING was handled in a completely different
fashion between the 2 systems.  The resolution was limited, the coordinate
system was different, I couldn't rotate text, etc.  I ended up writing
most of the code almost from scratch.  There were still some applications
that required higher resolution than I could get with the #Gxxx that had
to be left on the mainframe.

THEN, the powers-that-be decided that the mainframe was too expensive, and
that they should get rid of it!  One person aptly described the expression
on many users' faces as 'looking like a deer caught in someone's headlights'.
Fortunately (?), STSC had released their GSS/CGI/VDI graphics capability.
IF you could get drivers from GSS, it was theoretically possible to obtain
the resolution I needed.  So I started porting to that.  Guess what?  GSS
uses ANOTHER coordinate system, and a completely different approach to
producing hardcopy, color changes etc..  After a major re-write, GSS folded,
and I couldn't get drivers for most of the video cards people were buying.
I've got one workspace that will only work on one type of video card, and
that card has already become obsolete.  I understand that new drivers are
being written to the GSS standard in Germany, but I don't have time to mess
with it.

Then the Mac crowd starts clamoring for support.  APL.68000's approach to
graphics is to allow you to call 'QuickDraw' commands through their
operating system interface.  QuickDraw turns out to be rather simple-minded,
and many standard operations can't be performed without writting Mac
assembly language routines.  In addition, the approach to graphics is a
mix of the GSS stuff and #Gxxx, with windows and event driven processes
thrown in for laughs.  Another major re-write consumed my lunch hours for
six months, and resulted in a very crude (but usable) system.

Now Manugistics has come out with APL*PLUS III, with no support for GSS or
#Gxxx graphics.  The good news is that one should (in theory) have access
to the Windows graphics environment.  This is (once again) very different
from the previous 4 graphics systems I've used.  Windows appears to have
a wonderfully rich set of graphics commands, only the higher level functions
Manugistics provides have been hard-wired in certain annoying ways.
Windows has flags to set text justification, but Manugistics cover function
doesn't allow them to be accessed.  This means I have to write my own
cover functions from scratch.  Manugistics' high level functions don't
support the 'picture' class of objects, which means you can't cut and
paste your results.  This is supposed to be fixed in the next release.  I'm
using this as an excuse to use my nights and weekends for other pursuits.

I view the possibility of platform independent graphics as a fantasy.  I
have seen fairly significant variations in the way graphics is handled
with every one of these systems.  It has little to do with the language,
and a lot to do with operating system and hardware differences.  Unless
Apple and Microsoft start from scratch, the two {*filter*} PC platforms
may never meet at a useful common ground.  The way that they THINK about
graphics is different.

Once Manugistics polishes up their Windows graphics interface, I'm going to
go through this exercise ONE last time.  Then I'm going to shoot the next
person that even SUGGESTS that it needs to be moved to another platform.

Doug White
MIT Lincoln Laboratory



Tue, 25 Mar 1997 22:55:43 GMT  
 
 [ 23 post ]  Go to page: [1] [2]

 Relevant Pages 

1. APL95 software exchange: last call

2. APL95 Session Chairs

3. APL95 Conference Registration -- seat sale extended

4. APL95 Software Exchange

5. Consultants: advertise in APL95 Final Program

6. APL95 Prelim Pgm and Invitation

7. APL95 Preliminary Program and Invitation

8. APL95 software exchange

9. APL95 Software Exchange

10. APL95 Refereed Paper Abstracts

11. APL95 Program

12. APL95 Paper reviews

 

 
Powered by phpBB® Forum Software