lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Languages with first-class arrays


From: Greg Chicares
Subject: Re: [lmi] Languages with first-class arrays
Date: Fri, 26 Mar 2021 20:47:27 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 3/26/21 2:32 AM, Vadim Zeitlin wrote:
[...]
>  The old that is strong does not wither, so being old is not necessarily
> disqualifying, but is APL actually still used anywhere? I believe some of
> its ideas survive in MATLAB, but that's the closest I've ever come into
> contact with it.

Descendants also include R, as well as Iverson's J and Morgan Stanley's A+.
And of course now, at last, we have
  https://www.gnu.org/software/apl/
But no, I don't know anyone who writes APL or any of the others except R.
Yet the examples here:
  https://en.wikipedia.org/wiki/R_(programming_language)#Basic_syntax
are just ASCII-ified APL.

In the 1980s, APL had a substantial community in many types of financial
institutions, and was taught to all actuarial students. It was a
language for people who used mathematics and needed answers fast (what
was called "end-user programming" in the 1980s), but didn't want to waste
time wrestling with JCL and all that.

Then spreadsheets arose to fill that need, less elegantly but with an
easier early learning curve. And APL vendors tried to add frills like
GUI menus and event loops...
  http://www.ccs.neu.edu/home/jrslepak/typed-j.pdf
"The beautiful, crystalline structure of the core language accreted
non-general ad hoc additions."

Here:
  https://www.sacrideo.us/is-apl-dead/
is someone, who wrote his PhD thesis only two years ago, trumpeting APL's
virtues, and saying that historical trends have
  "positioned APL in this decade to emerge like a phoenix from obscurity"
so it's kind of like, say, polyphony: as long as new generations of young
composers are still awed by JS Bach, his ideas will never die. At the
very least it's a goldmine of ideas awaiting rediscovery in a world that
follows fashion too closely and discards culture too readily.

And, of course, those who do not understand array-oriented programming
are condemned to reinvent APL, verbosely.

  Year 1962:

    1↑⌽1 2 3 4 5 6
6

  Year 2021:

std::vector vec{1, 2, 3, 4, 5, 6};
auto v = std::views::reverse(vec);
std::cout << *v.begin() << '\n';

>  I'm also not sure if APL really ever was a general programming language.

It was originally designed as a consistent mathematical notation.
It was never a really good language for routine data processing.

> Raku has all these nice features, but it also has excellent support for
> many common programming tasks and all text processing proficiency you'd
> expect from a language of Perl family. E.g. I don't think I would have
> wanted to write https://github.com/vadz/gcc-warnings-tools using APL

Probably not. I couldn't figure out in just a few minutes how it works,
but I think you parse gcc sources to get lists of warnings, leading to a
tree structure with parent nodes that imply sets of individual warnings
in leaf nodes. For parsing, you want nice file and string handling;
that's not APL. For logic trees, you want appropriate data structures
and algorithms; APL's data module is N-dimensional matrices, so it would
probably be a difficult fit for this application.

In the early 1980s, I wrote a word processor in APL. It represented a
document as a long character string, which could be turned into a matrix
of characters. If you form a boolean vector of the positions of blanks,
and manipulate that vector mathematically, you can easily segment the
string into rows that won't break any word, and then concatenate them
all together to form the matrix. Then right- or left-justification was
simple. But one shouldn't design a word processor with a golden hammer.

>  Good luck with your continued lack of side effects!

At first, I thought you were talking about functional programming, but
now I understand. Yes, after resting all day, I'm as free of side
effects as Haskell.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]