What learning APL taught me about Python

I feel like this kind of operation on a list feels more naturally expressed by filtering the list and taking the length of the filtered list.<p>Like this line of JS feels so much easier to read than that line of python:<p><pre><code> ages.filter(age =&gt; age &gt; 17).length </code></pre> Directly translating this approach to python:<p><pre><code> len(list(filter(lambda age: (age &gt; 17), ages))) </code></pre> Although a better way to write this in python I guess would be using list comprehensions:<p><pre><code> len([age for age in ages if age &gt; 17]) </code></pre> which I feel is more readable (but less efficient) than the APL inspired approach. Overall, none of these python versions seem as readable to me as my JS one liner. Obviously if the function is on a hot path iterating and summing with a number is far more efficient versus filtering. In that case i&#x27;d probably still use something like reduce instead of summing booleans because the code would be more similar to other instances where you need to process a list to produce a scalar value but need to do something more complex than simply adding.

Years ago I stumbled across <a href="http:&#x2F;&#x2F;nsl.com&#x2F;papers&#x2F;kisntlisp.htm" rel="nofollow noreferrer">http:&#x2F;&#x2F;nsl.com&#x2F;papers&#x2F;kisntlisp.htm</a> which is similar in sentiment.<p>I think APL&#x27;s ability to lift loop patterns into tensor patterns is interesting. It certainly results in a lot less syntax related to binding single values in an inner loop.

Kenneth E Iverson, the inventor of APL was truly a genius and his primary mission was about how to bridge the world of computing and mathematics.<p>To do this he invented the APL notation.<p>If you find the article interesting, you might enjoy my curation of his work &quot;Math For The Layman&quot; [0] where he introduces several math topics using this &quot;Iversonian&quot; thinking.<p>[1] Look this up to install the J interpreter.<p>[0]: <a href="https:&#x2F;&#x2F;asindu.xyz&#x2F;math-for-the-lay-man&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;asindu.xyz&#x2F;math-for-the-lay-man&#x2F;</a><p>[1]: <a href="https:&#x2F;&#x2F;code.jsoftware.com&#x2F;wiki&#x2F;System&#x2F;Installation&#x2F;J9.4&#x2F;Zips" rel="nofollow noreferrer">https:&#x2F;&#x2F;code.jsoftware.com&#x2F;wiki&#x2F;System&#x2F;Installation&#x2F;J9.4&#x2F;Zip...</a>

As a beginner I definitely thought list comprehensions were easier than apply&#x2F;filter style of operations.<p>They amount to the same, but the explicit loop was much easier for me to understand (and I’m still not sure if one applies a function to a value or a value to a function, so I never remember if the function or the values go first in an apply filter call)

Someone else has mentioned it, but I would have gone with:<p><pre><code> sum(1 for age in ages if age &gt; 17) </code></pre> with the other method you&#x27;re treating a boolean as an int. Weak typing.

&gt; <i>Another big thing that APL made me realise is that the Boolean values True&#x2F;False and the integers 1&#x2F;0 are tightly connected</i><p>Amen! It&#x27;s of course also a C language tenet, and a great one. Life is so much simpler and more flexible when true and false are 1 and 0. It drives me crazy when I need to use a language where the logical operators only work on bools and the arithmetic only on ints, or some coercions work and others don&#x27;t. When I incorporate somebody else&#x27;s code into mine, first thing I get rid of is anything called &quot;bool&quot;, a completely useless type. (as a nice side effect, that frees up the bool keyword for Boolean sets, which are quite useful)<p>a disappointment with unix is that process retval has this a bit backward, 0 is success, nonzero is failure (probably because errno does want for more bits than a singleton) but it&#x27;s easily enough remedied with a !<p>I did love everything else about APL for the brief time I used it long ago (except the difficulty of entering the symbols)

I guess I&#x27;m a real computational scientist, because that first line to me wasn&#x27;t special, that&#x27;s how I&#x27;ve always written python.

Article OP here! Thanks everyone for reading and for your feedback.<p>If you have suggestions for improvements for the article, let me know here! Thanks again.

The author of this blogpost presented it a couple of days ago on Functional Programming Sweden:<p>How APL made me a better Python developer by Rodrigo Girão Serrão: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=tDy-to9fgaw">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=tDy-to9fgaw</a>

What is it about Python? A pretty trivial feature that has been known for 30 years (and is present in NumPy) is made into a whole blog post, linked to APL to sound more interesting and is on the front page for a day.<p>If the allegedly &quot;most popular language&quot; (confirmed by Gartner and Netcraft) needs that much proselytizing, perhaps it is artificially popular? Or has voting rings?

I know nothing about APL. But I think I would write it the same way as the OP. I also think use len is better to convey counting operation:<p><i>len(age for age in ages if age &gt; 17)</i>

And hence the numpy API.

The only thing this does for me is ask why its not named count instead of sum.

This is completely off topic (though possibly still on the topic of maximal readability) but the correct way to express this logic is as follows:<p><pre><code> age &gt;= 18 </code></pre> If your code is specifically about the magical age of adulthood then it ought to include that age as a literal, somewhere.<p>It becomes more obvious when you consider replacing the inline literal with a named constant:<p><pre><code> CHILD_UPTO = 17 # awkward </code></pre> compared with:<p><pre><code> ADULT = 18 # oh the clarity </code></pre> My fellow turd polishers and I would probably also add a tiny type:<p><pre><code> Age = int ADULT: Age = 18 # mwah! </code></pre> (The article was a good read, btw.)

I find that the more language you learn the better you can utilize all of them.<p>Also, Python is a wonderful functional language when used functionally.

APL makes a lot of sense in the era of 110 baud teletypes in which it was invented. Brevity was of extreme importance in that era.