8 ms·
One of the things that annoys me most is when people suggest that the power of array-oriented programming is in having a boatload of built-in array processing f
by kd0amg 12y ago
One of the things that annoys me most is when people suggest that the power of array-oriented programming is in having a boatload of built-in array processing functions with short names. As noted in the article, that kind of thing is simple to build as a library in most languages. There is a deeper thing, built into the semantics itself -- the way operators are automatically generalized to work on arbitrarily high-dimensional arrays, which can be manipulated by the programmer. Append (`,` in J) isn't just for tacking a vector onto a vector. It's also for sticking an extra element onto every row of a matrix (or every column), or for tacking the rows of two matrices together (or their columns), extending a rectuangular prism with a new plane (along which dimension? whichever you want!)... I'd talk about 4-, 5-dimensional, and higher if we had convenient prose terms for them. All this is from manipulating how the append function gets lifted to multi-dimensional structures. Or maybe you want to just add a matrix and a vector... do you want to treat the vector as a row or as a column? How about getting an outer product? Operate on the entirety of one argument and individual cells of the other, still just by manipulating how lifting is done. If you haven't been messing with verbs' ranks, you've only had a superficial look at array-oriented programming.
This kind of flexibility is not specific to the functions that come in the standard library. It's part of the language semantics, so it applies to every function the programmer writes. That's a fair bit harder to package up as a library (I've done it in Racket by more or less temporarily redefining function application), so I tend to be dubious of claims to have brought this paradigm into another language. Array-oriented programming is not just a combinator library.
- kiyoto 12y ago>One of the things that annoys me most is when people suggest that the power of array-oriented programming is in having a boatload of built-in array processing functions with short names. I agree, and that's unfortunate because that's not the most differentiating thing about array languages. As you point out, it is the semantics: some of it appears in other functional languages (like doing away without loop constructions) but some are unique to array languages (like using various properties of matrix/vector operations to express certain computations concisely). I am a big believer of linear algebra as a great tool of thought for computation that most people have little to no knowledge of, and the APL family (and actually, Excel) brings home this point. EDIT: And I definitely speak from my experience. I was a professional q programmer for two years, and I came to realize what makes q difficult for many people is not just its cryptic notation but also the general lack of understanding of linear algebra/matrix operations.
- buckie 12y agoFor anyone curious, here's a comparison (that I wrote a couple days ago) of FizzBuzz in K vs. q vs. python... please note the insane syntax for K4 (which is a proprietary language of KX Systems and is thus undocumented). K \c 150 100 c:{$[0=x-5*x div 5;$[0=x-3*x div 3;"CracklePop";"Pop"];$[0=x-3*x div 3;"Crackle";x]]}'1_!101 r:{x@&~x in "\""} p:{-1 r .Q.s x} p c \\ q (the "readable" wrapper around K4") \c 150 100 c:{$[0=x mod 5;$[0=x mod 3;"CracklePop";"Pop"];$[0=x mod 3;"Crackle";x]]} each 1_til 101 -1 ssr[.Q.s c;"\"";""] \\ Here’s a python (2.7) version of the program written in as unreadable as I could muster for i in map(lambda x: "CracklePop" if not x % 3 and not x % 5 else "Crackle" if not x % 3 else "Pop" if not x % 5 else x, xrange(1,101)): print i Here it is in normal python (2.7) for x in xrange(1,101): if not x % 5: if not x % 3: print "CracklePop" else: print "Pop" elif not x % 3: print "Crackle" else: print x