Re: Contributions

[Dr . Jürgen Sauermann]

Hi Tortus,

welcome to GNU APL and thank you for offering your help.

Let me first explain what I believe is the current state of the project. 
The most part of the development (in terms of
new C/C++ code) is done and I have currently no more ideas what else 
could be useful. For that reason adding
considerable amounts of new code is not something on our TODO list. Most 
of code changes that I am still doing
are about restructuring the exiting code without changing its function. 
In the early years of the GNU APL development
I created relatively huge amounts of C/C++ code in a very short time and 
often used hacks for quickly implementing
functions that looked not essential at that time. These days, when I 
discover such code (often when fixing bugs)
I tend to re-implement it in a cleaner or easier to understand way. 
Helping in this area means to look at the existing
C/C++ code and finding problematic or obscure parts. But be warned: the 
code base is quite large (around 110,000
LOC) and your work would be hardly visible to the outside world which 
could be somewhat frustrating. An interesting
job might be to improve the doxygen documentation in the GNU APL source 
code. Even though the job is somewhat
boring, I believe it is a good start into learning how GNU APL works.

One subsection of coding is the development of (automated) testcases. 
This area definitely deserve some
more efforts. Currently there are around 240 testcases in the 
src/testcases directory. Every testcase tests a single
function of feature (APL primitives in most cases). Initially I wrote 
one testcase per APL primitive (and the testcase
file is then named after the primitive). After some time I started 
adding all examples that I came across either
int the IBM APL Language reference document and in the ISO standard. I 
didn't do that too strictly, though, and
therefore there are still examples in both the IBM language reference 
and in the ISO standard.

Therefore one job still to be done is to read these two documents and 
create testcase files for not-too-trivial
examples from these two documents. The person doing that should not only 
be fit in APL programming but also
have a grasp on APL itself. There are contradictions between the 
language reference and the ISO standard and
the testcase designer should have a good judgement as to what solution 
is the best.

Another task related to testcases is coverage and the like. GNU APL can 
be ./configure'd to produce .gcov files.
After that, running *make test* produce these gcov files which can be 
analyzed with the gcov program. That in turn
tells how much (and which) if the GNU APL source code was executed by 
*make test*, i.e. by the testcases in
src/testcases. A separate job would be to create testcases so that the 
coverage is increased. Be warned that
this is a major effort and external visibility is somewhat low (even 
though you could put you name as a copyright
notice into the testcase files).

A completely different area is user documentation. One big problem that 
I have is that I am not a native English
speaker which makes the documentation that I wrote look a little odd. A 
review and rephrasing of existing user
documentation, primarily the doc/apl.texi file and the improvement of 
the English language iin it would be a valuable
job to do. Along the same lines, already some years ago I started a 
document named apl-intro which should be an
introduction to apl by examples kind of document. I used a somewhat cool 
approach which uses GNU APL itself to
produce the output of the examples (and therefore the examples are 
always correct). The document is in a half-finished
state and reviewing and finalizing it would be good. Even though I 
started the document I don't insist to be
named as the author. Whoever undertakes to finish this document could 
therefore become its author.

A final area that I always wanted to look into is APL libraries. I am 
still convinced that the reasons why APL
has become a mere niche language is 2 mistakes made by the APL vendors. 
Reason #1 is pricing of APL
interpreters (and GNU APL is an attempt to fix that, but came far too 
late). Reason #2 is that lack of useful
libraries (combined with a lack of visibility of those that exist). All 
successful languages that I know come with
(or have easy access to) libraries that solve the standard programming 
jobs. In the 1970s some APL vendors
were boasting about the productivity of APL. But the lack of APL 
libraries has rendered C/C++ more productive
than APL these days. I remember one vendor declaring FORTRAN a dead 
language in the 1970s. They were
right as far as FORTRAN is concerned (probably laso due to lack of 
libraries) but these folks are now a dead
APL vendor themselves). I believe that this topic deserves far more 
attention. I have tried to start something
at http://www.gnu.org/software/apl/Community.html but it hasn't really 
taken off. Unfortunately I have no idea
myself as to how to improve this.

Now, if anything above might interest you then please let me know and we 
can work out the details.
But other ideas are equally welcome.

Best Regards,
Jürgen



On 7/15/22 11:50 PM, Tortus Smash Stuff wrote:
> Hello,
>
> I’m Tortus, an aspiring APL programmer, and I’m interested in 
> contributing to this project, be it documentation or code, bug fixes 
> or adding functionality. Looking at the web-page, I’m finding it 
> slightly unclear as to where I could start. What sort of ways can I 
> help this project other than passively providing suggestions?
>
> Thank you!
>
> ︹̤ρ