Re: [Bug-apl] [PATCH]: allow using lambdas in ]USERCMD

[Juergen Sauermann]

Hi Peter,

I fully support your view. However, it is my impression that we two are fairly isolated with that opinion.
In my opinion most, if not all, attempts to "improve" on APL have failed big style. That includes J and
its various successors, but also some APL interpreters.

On the other hand it is difficult to reject a reasonable improvement proposal.
As of today the bug-apl mailing list contains 5677 posts. Many errors but also many change
requests. My algorithm (you need one) for change requests is roughly this:

1. does the change create significant incompatibilities? If yes then reject.
2. Estimate the implementation effort and the benefit for the user. If the first is far bigger than
    the latter then reject the request.
3. Can it be achieved with existing means? If so, reject (unless the benefit is considerable).
4. Does it fit into the APL language? If not then reject.
5. Otherwise accept and implement.

An example for a "good" change request was. in my opinion,  the extension of the monadic ⍳ from
scalars to vectors. No incompatibilities, easy to implement, and fitting nicely into the language.

An example for a "bad" change was the introduction of {...}. It should have passed 1., but then
been rejected in 2. (I totally under-estimated the effort), and rejected in 4 at latest. My fault, apologies
to Kenneth I.

Regarding add-on modules, I also share your view. However, my attempt to accomplish this was by
means of native functions. That approach was compatible at APL level, much more powerful than
shared variables, simple to use, in other words: perfect. However, only very few people adopted it.
So we are back to adding more and more ⎕-functions to the interpreter.

As to elegance, I would say that yes, APL is elegant, but APL systems have never been. I wrote my
first programs on punch cards, just like you probably did. I still remember my first "Wow" when working
interactively with a CRT Terminal and an immediate response from the mainframe when entering a
command. At that time, the ∇-editor and the interactive APL mode was simply cool. But since then a
lot of things have changed and things that used to be cool (and efficient for the programmer) are no
longer so. From today's perspective I would rate the ∇-editor as odd and interactive APL mode as
merely a tool for trying out short APL expressions. You cannot write larger APL programs that way.

All in all I am afraid that we have to live with a number of compromises that neither you nor me are
happy with. I also see a trend, in particular with apparently younger programmers, to see their daily
work as a burden rather than a joyful opportunity to spend their time. Maybe that is a consequence
of turning programming from an art into an industry.

Best Regards,
Jürgen Sauermann

On 02/24/2017 04:47 AM, Peter Teeson wrote:

No offence intended but 

There seems to me to be a whole lot of accretion in the non language part of GNU APL.
Useful as it may be to certain people I don’t think it’s in the elegant spirit of APL.

What used to be a nice clean, simple and easily comprehended project is now
suffering from encrustations that everyone is burdened with.

Personally it would be nice to have a basic package that is simply the interpreter, quad fns and the system commands 
leaving the rest of the detritus in add-on packages of some form.

Just my grumpy 80-year old man's opinion…<grumble grumble>

with respect….

Peter