APL in 2020 - A Series of Discussions
Dick Bowman
actual and potential APL users see the future shape of APL. They will be
conducted via posts to various APL discussion sites - principally
comp.lang.apl (because of its vendor-neutrality) - with summarised (but
unedited) collation to the website at APLin2020.org. In September there
will be a series of in-person forums at the APL2010 conference in Berlin,
followed by a final collection of topics and views to appear on the
APLin2020.org website and elsewhere before the end of 2010.
The direction of the discussions will be forward rather than retrospective.
Some of the topics will be profound (we hope) and others may be trivial.
Some will look inward at APL, others outward to our relationship with other
aspects of information technology.
APLin2020 emerged from the regular London APL meetings at at present
consists of (in alphabetical order) Dick Bowman, Chris Hogan, John Jacob
and Phil Last - we welcome anyone wishing to participate.
Our first topic is...
APL should become a more consistent language, abolishing syntactic
anomolies like bracket-indexing.
Roger Hui
> anomolies like bracket-indexing.
These are 2.5 different questions.
0. APL should become a more consistent language.
Yes.
1a. Abolish syntactic anomalies.
Yes, abolish the anomalies that I don't like.
1b. Abolish bracket-indexing.
You should know that one man's anomaly is another's
notational convenience, even notational essential.
The question is, is bracket indexing worth the
extra rule(s) in the syntax needed to make its
existence possible? I think the answer is not
cut and dry.
As an example of the first sentence of the preceding
paragraph, you could say that dyadic functions
are anomalous, from the point of view of having
only monadic functions. But I would argue that
dyadic functions are an "anomaly" worth having.
Simon Marsden
> > anomolies like bracket-indexing.
Personally I favour backwards-compatibility over cleaning up the
language.
In the specific case of bracket indexing, I actually prefer it to
using the index function. I find it more readable, and anything which
enhances readability gets my vote.
My own pet hates are []IO (because you can never tell what a statement
does without checking how []IO is set), and the rule whereby function
variables are global unless localised (It should be the other way
around). However I believe that it would cause too much confusion to
attempt to correct either of these now.
crishog
We want to know the opinions of the widest possible range of people
who use and or develop in array languages
Now that is possibly the worst ever sentence I've written on this
group, but what I'm trying to say is: we want feedback from Dyalog,
APL2000, APLX, J; we want vendors, developers and users; we want
conservatives and radicals.
Simply put, we are asking everyone and anyone who is interested in
APL, or its related languages, where they think we will be (and more
imprtantly where they want to be) in ten years time.
The Berlin 2010 conference is a "stake in the ground", a marker of
where we are now, so it's up to us to say what 2020 will bring.
Everyone join in, we are going to be annoying you with questions like
this for months, in preparation for the debates which will be held at
Berlin 2010.
We aren't going to have vague "talking shops", we want the discussions
to have a firm basis and to come to sensible conclusions - which will
be published at http://aplin2020.org - but to get to that point we
need the feedback from the whole community, starting now.
Feel free to comment, agree, disagree, hurl verbal abuse - anything,
but anything - just damn well express an opinion, or in 2020 we'll all
be saying "we missed our chance in 2010"
Chris
Bjorn
> This is, of course, a deliberately provocative first posting.
>
> We want to know the opinions of the widest possible range of people
> who use and or develop in array languages
>
> Now that is possibly the worst ever sentence I've written on this
> group, but what I'm trying to say is: we want feedback from Dyalog,
> APL2000, APLX, J; we want vendors, developers and users; we want
> conservatives and radicals.
>
> Simply put, we are asking everyone and anyone who is interested in
> APL, or its related languages, where they think we will be (and more
> imprtantly where they want to be) in ten years time.
>
> The Berlin 2010 conference is a "stake in the ground", a marker of
> where we are now, so it's up to us to say what 2020 will bring.
>
> Everyone join in, we are going to be annoying you with questions like
> this for months, in preparation for the debates which will be held at
> Berlin 2010.
>
> We aren't going to have vague "talking shops", we want the discussions
> to have a firm basis and to come to sensible conclusions - which will
> need the feedback from the whole community, starting now.
>
> Feel free to comment, agree, disagree, hurl verbal abuse - anything,
> but anything - just damn well express an opinion, or in 2020 we'll all
> be saying "we missed our chance in 2010"
>
> Chris
Very interesting!
Nice to see that people do care a lot and that APL is a life and well.
I have already booked APL in Berlin and looking forward to seeing this
debate and flames here in the forum.
Phil Last
If you can cope with maintaining other people's functions which have
been written using ⎕IO different from that to which you are used or
indeed different from one another then what confusion could it cause
if it were constant?
If you can use a lexically scoped language such as the direct
functions of Dyalog APL along with a dynamically scoped language such
as standard APL then what confusion could it cause if the choice were
taken away?
Nevertheless a desire for consistency should not be a search for
uniformity.
Until 30 or 40 years ago every seven- or eight-year-old child in
Britain learned decimal, duodecimal, hexadecimal & vigesimal number
systems. The removal of that part of the curriculum along with our
centuries-old currency and measures through a false perception of
redundancy certainly can't be accused of being a cause of confusion.
Nor can it be absolved from its contribution to the decline of the
nation's mathematical ability.
Dick Bowman
My position - I'm always pleased to see new language features that make APL
more powerful and useable. I like it when they fit smoothly into the
long-established models - for me the indexing function makes code much more
readable, the code flows under the eyes (although I didn't get that same
comfort from J's "amend"). I like to be able to verbalise code, and
"second element of this vector" is more natural (for me at least) than
"vector the second element of".
Equally I'm happy to use Dyalog's quadNEW and throw out my use of
quadWC/WS/WG - because it feels more comfortable. I have an ill-defined
notion of "flow", some code has it and some doesn't.
Sometimes there's a learning element - that's no bad thing, but I do wonder
whether there's an element out there in the code-generating world who feel
that they made an effort to learn APL once and would rather capitalise on
that effort than learn some more. Saw the same thing - a lot of resistance
to the new - when nested/boxed arrays first arrived and some people seemed
to feel that the new threatened their hard-earned toolboxes and techniques.
Anyhow - to make a meta-point to anyone who has got this far - the point of
the "APL In 2020" project is to draw opinions from as far and wide in the
APL world as we can. Not to have "winers and losers".
Bjorn
I would like to see more and better online demos, books for dummies
and up to date examples.
Better distinction between what dialect the documentation is aimed at.
I guess we have completely missed the standardization boat some years
ago and no use of trying to get on board again.
I like to see good support of all kind of web, mail, graphics and
unicode.
I would like to have better trace and documentation tools.
Of course get rid of quad io and default it to 0.
AAsk
- index origin is 0
- variables are local unless declared global
- it moves with platform developments i.e. the next defacto standard
of Dot Net and OS.
- you can mix languages to engineer your solutions
- your next compliance agenda is the industry standards ... today it
is 'rich' client for your GUI
- you are NOT required to be a domain expert (i.e. confine yourself to
the backwarters of what you know or have been taught) or to restrict
yourself to a vertical context.
- your prospect is as a software developer professional not ... as a
cottage industry professional who survives cosetted by the workspace
security blanket.
Read on ... there is more.
By 2020, there is likely to be
- 3 releases of the Windows OS
- Dyalog's APL# is likely to have been 'tried' in the market and
condemned to be either the ultimate 'success' or 'failure'
- Equally likely, MicroAPL's managed code APL will have gone through
the same 'trial' and seen its fate sealed
- Most of the proponents of WS bound APL enthusiasts (I did not say
professionals) will have retired or reached the past caring stage
- The basic means of interaction with computers will have changed
either to voice based or analogue (hand/fingers/facial expression
based input)
APL people are bright ... so bright that more often than not they end
up hoodwinking themselves ...
APL vendors strategy of catching up with industry standards will not
survive ... the trick is not to be able to do what the rest of the
programming community is doing but to do what they are doing and then
to do it just as well (if not better) ... in time ... on time ...
every time.
What APL does or makes possible today is not 'better' ...
Challenging enough?
Curtis A. Jones
> ...
> Of course get rid of quad io and default it to 0.
Or get rid of {quadIO} and default it to 1 - except when encode or
decode is involved....
Curtis
Bjorn
>
> We want to know the opinions of the widest possible range of people
> who use and or develop in array languages
>
> Now that is possibly the worst ever sentence I've written on this
> group, but what I'm trying to say is: we want feedback from Dyalog,
> APL2000, APLX, J; we want vendors, developers and users; we want
> conservatives and radicals.
>
> Simply put, we are asking everyone and anyone who is interested in
> APL, or its related languages, where they think we will be (and more
> imprtantly where they want to be) in ten years time.
>
> The Berlin 2010 conference is a "stake in the ground", a marker of
> where we are now, so it's up to us to say what 2020 will bring.
>
> Everyone join in, we are going to be annoying you with questions like
> this for months, in preparation for the debates which will be held at
> Berlin 2010.
>
> We aren't going to have vague "talking shops", we want the discussions
> to have a firm basis and to come to sensible conclusions - which will
> need the feedback from the whole community, starting now.
>
> Feel free to comment, agree, disagree, hurl verbal abuse - anything,
> but anything - just damn well express an opinion, or in 2020 we'll all
> be saying "we missed our chance in 2010"
>
> Chris
"Dyalog, APL2000, APLX, J"
This seems to be a very short list.
What about APL2?
PLJ
background. I learned APL in 1969 just before the release of APL
\360. I subsequently moved to IPSA in 1980 where I wrote several
shared variable processors as well as character thorn. I managed the
creation of SAX; beginning with STSC’s UNIX APL and designed Sharp’s
network shared variables. Reuters eliminated my group in 1992 and
I’ve been using VB both pre and post .Net ever since. I recently
retired, and I took the first few months to write my own APL
successor. Therefore, everything I’m about to say is based on
experience, not any prediction about the future.
To be considered a modern language, APL has to do several things.
1) Source should be source, not something reverse engineered with a
system function. This is because teams need source control. There
are also great benefits to the individual programmer looking for what
they changed between versions.
2) It should be fully integrated into modern development platforms so
that all of the code writing and debugging tools are available. This
includes dynamic help while writing or rewriting a line of code,
easily specifying where to stop on lines of code, as well as stepping
through or back out of functions. It also includes monitoring values
when they are accessed or set.
3) It should have as few system values as possible. I’ve limited
myself to Comparison Tolerance and Random Link. I would not be the
least offended if someone suggested a variant operator where these
could be applied rather then a calling function local, but I haven’t
seen a proposal that does this. I believe the only contentious one
missing is Index Origin, where I am firmly in the zero camp. Things
like Print Width are better left to display and print objects, which
all modern operating systems support.
4) I prefer bracket notation for subscripting arrays, but I have no
quarrel with providing a function as well. The issue here isn’t
really the syntax; both are quite regular, it is whether every
expression requires a new object be created. A lot could be done to
improve APL’s performance in this area.
5) I know a good deal about character thorn, and I would be happy to
see it removed. .Net provides a much more understandable candidate
for a character left argument.
6) I do not see a need for multiple assignments in one statement, and
I believe keeping them keeps APL away from being fully incorporated
into other languages.
7) I also do not need dynamic syntax in which a line of code changes
its meaning after it begins executing. This had some small merit when
workspaces were small and whole applications had to be “paged in.”
However, with objects one has a much better model for building
applications which use other applications. Eliminating this makes
compiling APL possible.
8) I prefer complete integration where APL is a collection of classes
which implement APL functionality and can be used in any modern
language. Most of my experience is with .Net, but I’ve done enough
with Java to believe it could be done there as well. For me, a
separate language which can be called is less appealing, but as long
as the classes it creates are usable by other languages and it can
create objects from other languages and use their methods, my needs
are satisfied.
9) Arrays of arrays opened up more reasonable result sets. However,
they also opened up some truly gruesome result structures. A
definitional model might be useful here, but I have made no attempt to
provide one. If you are going to provide arrays of arrays, you should
be able to do some of the obvious things with results one would
expect. I’ve found no other new APL which can sort a vector of
character vectors, but this is a hobby so there may be costly ones
which do.
10) The most significant thing modern APLs added was user defined
operators. However, without direct access to scalar primitives, their
usefulness is greatly reduced. Another way of saying this is, APL
programmers should not be second class citizens when using their own
language.
11) Modern control structures If Then Else, Do While, Select Case and
Try Catch are sufficient and branch arrows should be eliminated. I
also call attention to the fact that Try Catch provides statements
which can be compiled rather than use character strings that are
executed.
12) Use of Execute should be limited to evaluating an end user’s
expressions and not be used to write mainline code. Any time you have
to use Execute should be taken as an indication that a capability is
missing in the language.
13) While I do not wish to retrieve source from a Class, I do want to
be able to create a Class on the fly. I haven’t exposed this, but
since it is how I support Execute, I know it is doable.
14) While I wrote shared variable processors for years, I find modern
interfaces much more useful. I believe SOAP is a much better answer
to how to communicate between two systems than anything I’ve created.
For details of what I’ve created so far, please read
http://home.comcast.net/~paul.l.jackson/PLJsAPL/
Questions here, or in private are most welcome.
Paul
AAsk
... I would add that array of arrays is not such a bad thing (it
exists is VBA, VBScript, C# etc) except that with APL, it has become a
prominent way of hiding data i.e. creating data that cannot be shared.
... I also agree that code creation on the fly is the stuff that
creates debugging/maintenance nightmares.
... You seem to hint at multi-language programming (I agree) and for
this to happen truely, the APL IDE is always in the way both when
reacing out from APL or reaching into APL from another language.
To your checklist, I will add
1. APL needs to become naturally culture aware (globalisation) to be
an effective language for building GUIs, data access etc. I am talking
here about regional settings.
2. APL, I would have thought was the ideal candidate for offerring
what Dot Net offers what it cslls LINQ (Language Integrated Query)
with flavours of LINQ to Objects, LINQ to XML, LINQ to SQL etc. An
example:
Task: This sample uses Average to get the average price of each
category's products.
Code:
public void Linq91() {
List<Product> products = GetProductList();
var categories =
from prod in products
group prod by prod.Category into prodGroup
select new {Category = prodGroup.Key, AveragePrice =
prodGroup.Average(p => p.UnitPrice)};
ObjectDumper.Write(categories);
}
Result:
Category=Beverages AveragePrice=37.979166666666666666666666667
Category=Condiments AveragePrice=23.0625
Category=Produce AveragePrice=32.3700
Category=Meat/Poultry AveragePrice=54.006666666666666666666666667
Category=Seafood AveragePrice=20.6825
Category=Dairy Products AveragePrice=28.7300
Category=Confections AveragePrice=25.1600
Category=Grains/Cereals AveragePrice=20.2500
LINQ illustrates that solutions do not have to be crafted symbol by
symbol but 'described' much as SQL is a description of the results
sought and NOT the code that will fetch the results.
crishog
APL2, Q'Nial, K, Q, anything else in "the family" - I didn't mean the
list to be all encompassing, those are just the ones I've used
personally in recently times.
My apologies.
Chris
Bjorn
It would be interesting to see a list of all APLs and what years they
existed and which ones are still around.
Doug White
35abdd...@r9g2000vbk.googlegroups.com:
> The APL you are looking for exists today ... it is Visual APL
>
> - index origin is 0
> - variables are local unless declared global
> - it moves with platform developments i.e. the next defacto standard
> of Dot Net and OS.
> - you can mix languages to engineer your solutions
> - your next compliance agenda is the industry standards ... today it
> is 'rich' client for your GUI
> - you are NOT required to be a domain expert (i.e. confine yourself to
> the backwarters of what you know or have been taught) or to restrict
> yourself to a vertical context.
> - your prospect is as a software developer professional not ... as a
> cottage industry professional who survives cosetted by the workspace
> security blanket.
Speaking as a domain expert, if you want to turn APL into something that
only a "software professional" uses, you will be banging your head
against the same problem that has relegated APL to the software
backwaters. APL may be a better solution, but that hasn't stopped
Microsoft and C from dominating the industry. It's not enough to have
the best solution.
APL has already evolved from something a domain expert can use to easily
solve problems into something that requires a LOT of study. I have a ton
of good engineering code that runs in plain old APL, and it's been
waiting 20 years to get updated to a modern APL because I don't have time
to learn all of the Windows garbage that will be needed to redo all the
graphics. It would be lovely to re-code it all to use nested arrays &
the like, but it's just not worth it.
I love APL, and used to use it daily. I now use it once every 6 months
at best. I know dozens of domain experts who are in the same boat,
because they used to use the code I helped develop. There are now plenty
of competing programs (NOT written in APL) that will do the job. Most of
them aren't as good as what we put together, but without a glitzy Windows
user interface, nobody new will touch it. APL has become a VERY
expensive tool for software professionals, and is no longer relevant for
working engineers & scientists.
I think it's already too late to save APL's utility to domain experts.
The only folks using it are the diehards who learned it back in the
1970's, when it was a lot simpler and a lot less encumbered with
kowtowing to the business side of things and Microsoft.
APL used to be a required course in a number of engineering schools.
Now, nobody's heard of it. I view that as a terrible shame, but as long
as it is marketed solely to software professionals at large enterprises
for huge database work, it's never going to make a comeback.
Doug White
AAsk
I understand exactly how expensive APL is but almost certainly not in
the same way as you might have implied when making your statement.
- APL is expensive because it is unsupported by the wider developer/
programmer community ... if in doubt, just Google for a solution and
count how many threads provide a solution in APL. Actually, I'll tell
you how many: none.
- APL is expensive because it is difficult to recruit a professional
who knows APL and also what goes for requirements e.g. tier design,
code-reuse, data-sharing, version control etc.
- APL is expensive because it has become the single point of failure
in any organisation's arsenal of applications.
>Now, nobody's heard of it.
There is nothing that APL does that is not EQUALLY doable in another
environment. That APL might do it quicker is inconsequential what
matters is whether APL does it as it is expected to be done.
In the 70's and 80's APL was supreme but then it was competing with
BASIC, programmable calculators and the like. It never learn't to grow
up and begin to compete with all that came afterwards.
The world is not coming to APL: APL needs to embrace what the world
considers relevant.
Bjorn
> The APL you are looking for exists today ... it is Visual APL
I googled for Visual APL and got several hits but most links are
broken and not valid anymore.
This is one of the things I found looking through the hits
"This popular poem should give you an idea of why APL is not popular
anymore:
'Tis the dream of each programmer
Before his life is done,
To write three lines of APL
And make the damn thing run."
>
> - index origin is 0
> - variables are local unless declared global
> - it moves with platform developments i.e. the next defacto standard
> of Dot Net and OS.
> - you can mix languages to engineer your solutions
> - your next compliance agenda is the industry standards ... today it
> is 'rich' client for your GUI
> - you are NOT required to be a domain expert (i.e. confine yourself to
> the backwarters of what you know or have been taught) or to restrict
> yourself to a vertical context.
> - your prospect is as a software developer professional not ... as a
> cottage industry professional who survives cosetted by the workspace
> security blanket.
>
> Read on ... there is more.
>
> By 2020, there is likely to be
>
> - 3 releases of the Windows OS
Is that something to be looking forward to?
> - Dyalog's APL# is likely to have been 'tried' in the market and
> condemned to be either the ultimate 'success' or 'failure'
> - Equally likely, MicroAPL's managed code APL will have gone through
> the same 'trial' and seen its fate sealed
> - Most of the proponents of WS bound APL enthusiasts (I did not say
> professionals) will have retired or reached the past caring stage
> - The basic means of interaction with computers will have changed
> either to voice based or analogue (hand/fingers/facial expression
> based input)
>
> APL people are bright ... so bright that more often than not they end
> up hoodwinking themselves ...
Most of all they do not seem to realize the need to write
documentation and keep it up to date.
Let alone make it understandable by ordinary dummies.
AAsk
If you want to know about Visual APL, you might want to start here
http://www.vector.org.uk/?vol=24&no=2&art=askoolum.
Then you might want to investigate further here
http://forum.apl2000.com/viewforum.php?f=4&sid=9960f451e79ae8024c50bcd3003e07a8.
Ibeam2000
usage in the 1980s and has been slowly declining since. Modern APL
systems are faithful replicas of much older APL systems, APL language
evolution (I don't consider functions to access host features or build
GUIs central to the language) has stagnated. Whether or not to
include square bracket indexing doesn't seem to be a question
important for the acceptance of the language and growth of the
community. Some "APL" users in 2020 might not have been conceived yet
in 2010, thus the balanced opinion and mindshare of mostly very young
people plus a few seasoned experienced individuals is what may be
needed to shape and grow the community of the future.
Part of the problem is that the computer culture today is a very
ageist one, and APL being 42 or more years old suffers from the
downside of staying power - a kind of excess of historical knowledge
and too much reputation. The computer culture of 1968 was completely
different, computers were new, ideas were new, and the community in
the large had an open-mindedness to it which is not present today.
Pick up a copy of Ted Nelson's Computer Lib. Computing was also
extremely exclusive. Today the computing world is not exclusive at
all, the language choices being .Net (mostly C#) or Java, not much of
a choice considering it took us half a century to get this far. The
mainstream computing world seems to enjoy that low level of
abstraction these languages offer, coupled with the ease of use of
some of the development environments.
What needs to happen is that APL should pass its "genes" to a true
successor, which needs to come up through the ranks as did languages
like Python. (Trouble at the mill, that's all) The new language
needs to get rid of the baggage, technical and otherwise, which APL
has been accumulating over time. Language acceptance is probably the
most important topic, but not at the square bracket indexing level. A
new language needs to be designed from the bottom up, incorporating
the ideas which made APL exceptional with ideas which a much larger
potential new community can accept.
Aaron W. Hsu
> What needs to happen is that APL should pass its "genes" to a true
> successor, which needs to come up through the ranks as did languages
> like Python. (Trouble at the mill, that's all) The new language needs
> to get rid of the baggage, technical and otherwise, which APL has been
> accumulating over time. Language acceptance is probably the most
> important topic, but not at the square bracket indexing level. A new
> language needs to be designed from the bottom up, incorporating the
> ideas which made APL exceptional with ideas which a much larger
> potential new community can accept.
So, I'm not an APL user, yet. However, I do actually plan to try to use
APL, but not any of the APL systems out there right now. What you say
here is somewhat interesting to me, so let's see if I can provide a
perspective on how I plan to use APL.
As an outsider, APL as a language isn't the environments and
interepreters or compilers that are out there right now. It's a syntax on
operations. It's a unique approach to processing arrays. There may be
more to it that I don't understand, but that's what it seems like to me.
What I plan to do is write an APL syntax on top of Scheme. Scheme has a
number of array libraries out there, but none of them is really nice
enough. It strikes me that APL could be used here. So, I'd like to take
APL, and embed it into Scheme (which can be done rather easily).
For me at least, this is where APL might appeal to me. I'll let you all
know how it goes once I'm done. :-)
Aaron W. Hsu
Bjorn
> In my meager opinion, the language we commonly know as APL peaked in
> usage in the 1980s and has been slowly declining since.
Unfortunately I have not seen any real statistics that neither
conforms nor contradicts this statements.
The fact that there are APL systems still around and some claim to be
thriving do indicate that it is still alive even if we can probably
agree that the number of users should be many more.
> Modern APL
> systems are faithful replicas of much older APL systems, APL language
> evolution (I don't consider functions to access host features or build
> GUIs central to the language) has stagnated.
I do have to disagree on this statement in many ways.
There are systems today that do look like the old systems but there
are also quite a lot of new features in many dialects and if we count
J in this discussion then there is q huge difference compared to the
old APLs.
> Whether or not to
> include square bracket indexing doesn't seem to be a question
> important for the acceptance of the language and growth of the
> community.
J does not have this at all.
> Some "APL" users in 2020 might not have been conceived yet
> in 2010, thus the balanced opinion and mindshare of mostly very young
> people plus a few seasoned experienced individuals is what may be
> needed to shape and grow the community of the future.
>
J is certainly going in for changes towards the needs of the future.
Today I was installing a new beta version of J that has amazing
features for the web and using advanced features to combine with other
web toolkits to do graphics and grid.
There is also a very good connection to GTK which is a modern toolkit.
> Part of the problem is that the computer culture today is a very
> ageist one, and APL being 42 or more years old suffers from the
> downside of staying power - a kind of excess of historical knowledge
> and too much reputation. The computer culture of 1968 was completely
> different, computers were new, ideas were new, and the community in
> the large had an open-mindedness to it which is not present today.
> Pick up a copy of Ted Nelson's Computer Lib. Computing was also
> extremely exclusive. Today the computing world is not exclusive at
> all, the language choices being .Net (mostly C#) or Java, not much of
> a choice considering it took us half a century to get this far. The
> mainstream computing world seems to enjoy that low level of
> abstraction these languages offer, coupled with the ease of use of
> some of the development environments.
>
> What needs to happen is that APL should pass its "genes" to a true
> successor, which needs to come up through the ranks as did languages
> like Python. (Trouble at the mill, that's all) The new language
> needs to get rid of the baggage, technical and otherwise, which APL
> has been accumulating over time. Language acceptance is probably the
> most important topic, but not at the square bracket indexing level. A
> new language needs to be designed from the bottom up, incorporating
> the ideas which made APL exceptional with ideas which a much larger
> potential new community can accept.
Please take a look at what J has to offer and look at the new
development toeards the future there.
I do know that other APLs have very advanced features I would have
loved to have when I was more active in the old APLs.
There is every reason to consider why it is that we do not have a
bigger community than what we seem to do.
I for one think that we are often missing to write good up to date
documentation but that is rapidly changing thanks to access to good
web tools.
J is using standard characters, J is freely downloadable, there is an
old version open source and the current new front ends are also open
source.