#1 geophile: 8 days ago

APL, (which is the array language I had some exposure to), had three interesting characteristics:

1. It implements an algebra: Operators take arrays as input and yield arrays as output.

2. The special characters bound to those array operators.

3. It is functional.

#2 definitely gave APL programs a distinct and elegant personality, but probably didn't help with widespread adoption.

But #1 and #3 are powerful ideas, and have showed up in other forms. SETL was a set-oriented language from the late 70s/early 80s. I took compiler courses from the guy behind it, R. B. K. Dewar (of Spitbol fame). Fantastic teacher. SETL programs were concise and powerful like APL programs, exactly because of #1 and #3.

Later in my grad school career, I got into relational algebra, which also has these characteristics. My advisor was T. H. Merrett who engaged on a many-years, quixotic quest to explore relational algebra as the basis of a general-purpose programming language. I didn't buy into all of that, but as a database guy, I find relational algebra to be powerful and useful on a day-to-day basis.

Finally, I really like functional stream approaches as a great way to bridge set-at-a-time programming (for lack of a better term) with ordinary, low-level programming. Java 8 streams and lambdas is a great (if flawed) example of this approach. Even Map/Reduce is, under the vast amounts of complexity.

I like this approach so much that I built a command-line tool, osh (http://github.com/geophile/osh) based on it. The idea there is the Unix idea of composing simple commands using pipes, except in osh, the pipes carry streams of Python objects. And the commands that operate on the objects in these streams are Python. E.g., to print the pids and commands of processes whose commandline contains "emacs":

    $ osh ps ^ select 'p: "emacs" in p.commandline' ^ f 'p: (p.pid, p.commandline)' $
    (37268, '/usr/bin/emacs24 ')
    (42107, 'emacs ')
    (63758, '/usr/bin/python /usr/bin/osh ps ^ select p: "emacs" in p.commandline ^ f p: (p.pid, p.commandline) $ ')
    (113605, '/usr/bin/emacs24 ')

#2 sumanthvepa: 8 days ago

I had the good? fortune of programming in A+ (a derivative of APL) at Morgan Stanley in the mid 90s. Not sure if it is used there anymore. For someone coming from a background in object-oriented languages like C++ and Java (only just introduced in 1995,) A+ was utterly alien and incredibly powerful. A single line could accomplish stuff that would take 50-100 lines of C++. But that single line looked like Egyptian hieroglyphics! To even read or write code in A+ required a special font addition to XEmacs to work as the glyphs would not render in any other font. I never fully understood the art of programming in A+ in the year or so I had to work on the product that was written it it, but I was amazed at the things the experts in my team could achieve with it.

#3 segmondy: 8 days ago

The key thing is "Notation as a tool of thought" What would mathematics or music be without notation? It might be hard to believe but there was once a time mathematics didn't have notation for "+, - * /" or even the decimal point "." Mathematics was solved by writing words, it was slow, it was painful and it didn't progress as fast. Likewise with music, sure we can write music by writing do re mi fa so la ti, but really?

Yet, this is how we program today with words, writing english words that don't mean what they claim to be. SomethingManager, SomethingDelegator, etc. Bah! The very ideal behind APL is to notations, to represent code with symbols which are non ambiguous and always mean the same thing.

There's a lot that we have lost. It's still worth taking a look at. For those interested, J (www.jsoftware.com) is a free version with lots of great learning resources.

#4 sharpercoder: 8 days ago

With many languages adopting LINQ object querying, I find it more and more suitable to start using math's set operators for them. Many languages have almost identical behavioral sequence operators (.find in js, .Where in C#, etc) but math sort-of standardizes them all with a sound theoretical background. I'm not entirely sure if they all map 1-to-1, but at least most will.

    const items = ∅; // empty set
    if (myItem ∈ items) { ... } // is element of
    const union = items ∪ otherSet;
    assert items ≌ ∅; // items are all equal

#5 pjc50: 8 days ago

This reminds me of "[semantic] compression oriented programming": https://caseymuratori.com/blog_0015

The arary languages have always struck me as the extreme end of this. The semantics are very dense: each operator does a lot. Intermediate results aren't granted names. The few people who can follow this find it pleasant as the "extraneous" information is removed. Most people find it hard to adapt to. And it doesn't readily suit a lot of business logic.

Possibly the one context where arrays-as-language-primitive has really taken off is the 3D processing world, first with OpenGL's matrix stack computation and later with shader programming. Note that shader programming is the other way round: you don't start with a screen object and apply functions to it mapped across all the pixels (fragments), you write a small program as if for one pixel. Even if the end result is executed in a highly parallel fashion.

#6 bitminer: 8 days ago

I remember APL as part of learning how to program at my high school in the early 1970s.

I could touch type APL on the IBM 2741 text terminals (basically Selectric typewriters with serial interface.). And could compose simpler APL codes at that speed.

The principal weakness was APLs narrow view of data type. Text was a 3rd class citizen. There was no substring searching in the early IBM implementation. As a result one had to:

  Form a cross product of text with the substring, testing for equality of each character

  Rotate each row of the cross product by n steps where n is the row number

  (This aligns the tests along columns)

  Perform AND reduction along the columns to find the full matches.

#7 pklausler: 8 days ago

Arrays in array languages are functions of their indices, and many array operations can be viewed as compositions of functions on those indices.

#8 poster123: 8 days ago

I have used Fortran 90+, Python with Numpy, R, and (rarely) Matlab/Octave, all of which allow operations on whole arrays and array sections. Would they be considered array languages? What is qualitatively different about APL, J, and K?

#9 protomyth: 8 days ago

F-Script was an interesting array language object combo that was originally written on OPENSTEP. It fit great with Cocoa later and was quite nice to program in.

https://en.wikipedia.org/wiki/F-Script_(programming_language...

#10 tabtab: 7 days ago

They kind of got replaced by "table oriented" query languages, like SQL. Arrays can get very unruly to coordinate, manage, and/or comprehend. Tables tend to ensure a bit more structure and can "do" most of the same things as arrays if you normalize properly.

SQL is probably not the ideal "table processing" language, but it's good enough and a strong enough standard such that competitors have yet to unseat it (although I'd like to see more competition, such as Tutorial-D/Rel, SMEQL, etc. fight it out in the market-place.)

#11 undefined: 8 days ago