APL in 2020 at APL 2010 Berlin - Will you be there?
Phil Last
From the conference web-site:
--------------------------------------------------
Bob Smith (Chair) (Sudley Place Software): APL in 2020
While the future is notoriously hard to predict, talking about it with
the leading industry experts is an excellent way to begin to picture
it. As such, the idea to start an online discussion of “APL in 2020”
is a highly laudable goal with the APL conference in Berlin as the
next stepping stone in this sequence.
This forum expects to use the following format to cover these topics:
* An initial presentation of the why this is such an important
topic, the rationale for starting the online exchange, an in-depth
summary of the topics covered so far, what topics might be covered in
the future, how the audience can contribute, and the next steps. This
part is given by Phil Last, one of the four originators of the "APL in
2020" idea.
* A panel to discuss the previous topics, what new topics should
be discussed either then or in the comp.lang.apl newsgroup, next
actions, etc.
* A discussion of these topics and more with the audience. We're
allotting plenty of time for audience interaction, so come prepared to
discuss your ideas on this vital window into the future of APL.
----------------------------------
If you are going to be there please come prepared to have your say.
One of the aims, perhaps the prime aim, of the APL in 2020 project is
to create a record of what present users of APL want to see in ten
years' time. Not what the vendors would like to implement 'though we
hope they are broadly similar. The vendors, no less than the rest of
us, can only guess what the future holds. If we let them know the
directions we want to move in we can keep APL ahead of the game rather
than following the pack.
Do we want different APLs to converge to a new standard with vendors
cooperating on new features.
Do we want to rid APL of its anomolies as Ken Iverson hoped to do
first with APL and then with J?
Do we want to incorporate all the latest software trends into APL or
to be able to tap into any available technology via standard
interfaces?
APL has often been the language of choice of professionals from other
spheres wanting to create their own software. Should this be
encouraged? How?
Perhaps you cannot make it to Berlin.
You have an audience here who will be there.
Post your wishes here, now, under the APL in 2020 banner before the
weekend and we will do what we can to add them to the debate.
You are the agenda.
Phil Last
pp. APL in 2020
Dick Bowman
> [... deleted ...]
> Post your wishes here, now, under the APL in 2020 banner before the
> weekend and we will do what we can to add them to the debate.
>
> You are the agenda.
> Phil Last
> pp. APL in 2020
Here's my view (possibly not fully thought through) - I won't be in Berlin,
maybe just as well...
I'd like to think that the APL of 2020 will be substantially different from
the APLs we know today.
The core is good (multidimensional data, functions, operators, all that
stuff) - the originators back in the 1960s did great things, so we stay
with that.
But its got untidy over the years and deserves the sort of rethink that
launched J. There are residuals that never got fully sorted out and sit
there untidily from the early days (you know the sort of thing I'm thinking
about). I think APL should become much more strictly functional, we should
grasp the questions like lexical scoping, be bold enough to say "this is
new, for new applications, and we'll let the past stay with "old APL").
We have to be more confident in ourselves, not forever looking over our
shoulders and worrying about what other programming langauges look like.
We need interfaces, and to do something about the way that there's been a
creeping requirement for nerd-knowhow. I think APL's role to fill is
"you've got a pile of data and a problem, here's the natural way to deal
with it". Expecting "domain experts" to make sense of mishmashes like
Microsoft's WPF is daft, the nerds amongst us need to present easy routes
to multi-tooling.
I'd like to see heaps more writing about APL - to stop throwing people back
onto thirty year old textbooks.
I like having multiple vendors, but I'd like to see more commonality
between them. For example, the benefits of Dyalog's namespaces for
partitioning code are so obvious - why don't all APLs have this?
I'd like a genuinely affordable APL so that price isn't an obstacle to the
curious; let's make money from services like consulting. And I'd like it
to be on all sorts of platforms, remember "APL Is A Tool Of Thought".
Anyhow, that's enough from me. In the original spirit of the APL In 2020
project I'd encourage people that the thing to do at the moment is to offer
their viewpoints, not to argue about detail. Just toss ideas into the pot
- we can sort out the valuable from the tosh later.
Bjorn
>
> Do we want different APLs to converge to a new standard with vendors
> cooperating on new features.
Yes but it is hardly likely to happen
>
> Do we want to rid APL of its anomolies as Ken Iverson hoped to do
> first with APL and then with J?
>
YES
> Do we want to incorporate all the latest software trends into APL or
> to be able to tap into any available technology via standard
> interfaces?
>
Yes to the or part
Michael Jenkins
> On Monday will be the APL in 2020 open forum chaired by Bob Smith.
I won't be in Berlin, but I would like to endorse this session on APL
in 2020.
I've inserted a few opinions below.
> If you are going to be there please come prepared to have your say.
> One of the aims, perhaps the prime aim, of the APL in 2020 project is
> to create a record of what present users of APL want to see in ten
> years' time. Not what the vendors would like to implement 'though we
> hope they are broadly similar. The vendors, no less than the rest of
> us, can only guess what the future holds. If we let them know the
> directions we want to move in we can keep APL ahead of the game rather
> than following the pack.
Gathering the ideas is an essential starting point.
>
> Do we want different APLs to converge to a new standard with vendors
> cooperating on new features.
There are two issues here.
First, is it possible to get agreement on a standard language based on
APL concepts.
I'll call it APL3 in this note.
For this to happen a significant group of APLers (both vendors and
users) would have to work on defining what is APL3.
As a preliminary step there would need to be a clear separation
between the language concepts, implementation concepts and the
programming environment.
Second, is the migration of current APL systems to adopt or become
compatible with the standard.
It might be possible to get agreement on the language concepts that
most vendors would support.
Each could then continue developing the other two aspects as they
decide on their customers needs.
>
> Do we want to rid APL of its anomolies as Ken Iverson hoped to do
> first with APL and then with J?
>
This task is not as simple as it sounds.
First we have to get agreement on what the anomalies are and then
agree on the "correct" solution.
My experience in designing Nial with Trenchard More is that there are
often several choices removing an anomaly and one needs to make each
individual decision so that the end result is coherent.
There is undoubtedly a lot of personal taste in making such judgments,
so don't expect agreement to be easy.
> Do we want to incorporate all the latest software trends into APL or
> to be able to tap into any available technology via standard
> interfaces?
Use standard interfaces in order to keep the core language small.
>
> APL has often been the language of choice of professionals from other
> spheres wanting to create their own software. Should this be
> encouraged? How?
Yes, it should be encouraged.
How is difficult to answer.
Making APL3 programs easier to understand might be a starting point.
In my opinion J programs, when written in the very concise form using
tacit expressions, are very difficult to digest. Some of the recent
discussion about ways to make such programs easier to read should be
looked at in the APL3 context.
The difficulty of reading APL and J expressions is due to the need to
understand complex parsing rules in your head as you examine an
expression as a linear string of symbols. Using formatting conventions
involving spacing and possibly colouring of the symbolic units would
aid this process significantly. I encourage the development of a
standard approach to using such conventions.
>
> Perhaps you cannot make it to Berlin.
> You have an audience here who will be there.
I look forward to hearing the outcome of the sessions.
Please ensure they are posted on the APLin2020 website.
Have fun!
Mike
Richard Nabavi
able to make it to APL 2010. But we at MicroAPL have been very
interested in the 'APL in 2020' discussions, and we look forward to
hearing more about the views expressed in this session. It promises
to be a very interesting input which will help us plan enhancements
and additions to our APL product range.
Richard Nabavi
MicroAPL Ltd