Live data from Hacker News

What learning APL taught me about Python

mathspp.com

71–80 of 104 posts

Re: What learning APL taught me about Python

#71
As a beginner I definitely thought list comprehensions were easier than apply/filter style of operations.

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)

Re: What learning APL taught me about Python

#72
post #64

Someone else has mentioned it, but I would have gone with: sum(1 for age in ages if age > 17) with the other method you're treating a boolean as an int. Weak typing.

I agree with the improvement in readability but still like the bool/int equivalence:

    sum(int(age > 17) for age in ages)
Every nanosecond is vital!

Re: What learning APL taught me about Python

#73
post #14

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. Like this line of JS feels so much easier to read than that line of python: ages.filter(age => age > 17).length Directly translating this approach to python: len(list(filter(lambda age: (age > 17), ages))) Although a better way to write this in python I guess would be using lis…

I feel like the numpy version is most concise, most readable, and most array-ish:

np.sum(age>17)

(Assumes age is a np.array)

Re: What learning APL taught me about Python

#74
post #64

Someone else has mentioned it, but I would have gone with: sum(1 for age in ages if age > 17) with the other method you're treating a boolean as an int. Weak typing.

bool is explicitly documented to be a subclass of int [1][2], so while it might be an obscure feature, or subjectively not someone's preferred style, I don't see any typing related issue. In general I don't think that treating an object as if it were an instance of one of its base classes is weak typing.

[1]: https://docs.python.org/3/library/functions.html?highlight=s...

[2]: https://docs.python.org/3/library/stdtypes.html#boolean-valu...

Re: What learning APL taught me about Python

#75
post #14

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. Like this line of JS feels so much easier to read than that line of python: ages.filter(age => age > 17).length Directly translating this approach to python: len(list(filter(lambda age: (age > 17), ages))) Although a better way to write this in python I guess would be using lis…

Your list comprehension is how I would naturally write this, and to me seems the most readable - it's almost like an English language sentence. The sum example in the article would probably be my second choice.

Re: What learning APL taught me about Python

#76
post #64

Someone else has mentioned it, but I would have gone with: sum(1 for age in ages if age > 17) with the other method you're treating a boolean as an int. Weak typing.

Its not weak typeing, bools are ints.

“I don’t know the type hierarchy used in language X” is not the same thing as “language X is weakly typed”.

  Python 3.11.4 (tags/v3.11.4:d2340ef, Jun  7 2023, 05:45:37) [MSC v.1934 64 bit 
  (AMD64)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> isinstance(True, int)
  True
  >>> isinstance(False, int)
  True
  >>> issubclass(bool, int)
  True

Re: What learning APL taught me about Python

#77
post #32

Earlier quoted context omitted.

It is a poor functional language. List comprehensions (from Haskell) are nice, but the rest is garbage. Crippled lambdas, no currying, "match" is a clumsy statement, weird name spaces and a rigid whitespace syntax. No real immutability.

IIRC, Haskell’s list comprehensions are lifted from Erlang.

I believe they were based on Miranda[0] (1985) but they have a longer history than that, maybe under a different name.

[0]:https://en.wikipedia.org/wiki/Miranda_(programming_language)...

Re: What learning APL taught me about Python

#78

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.

You're saying that brevity for typing on 110 baud teletypes was the primary reason for the density of APL operators, but that's not historically true. For one thing Iverson and pretty much everyone else high profile in the APL community has said that the conciseness was itself a major part of the power of APL. Further proof of that: APL began as a mathematical notation on chalkboards, and only later was it decided to…

Writing on a chalkboard is another situation where brevity is at a premium. There's limited space and the act of writing on it is slow and causes hand cramps if it's too verbose.

Re: What learning APL taught me about Python

#79
post #72
post #64

Someone else has mentioned it, but I would have gone with: sum(1 for age in ages if age > 17) with the other method you're treating a boolean as an int. Weak typing.

I agree with the improvement in readability but still like the bool/int equivalence: sum(int(age > 17) for age in ages) Every nanosecond is vital!

Interesting, so I did a little test:

  python -m timeit 'sum(1 for age in range(100000) if age > 17)'
  50 loops, best of 5: 5.08 msec per loop

  python -m timeit 'sum(int(age > 17) for age in range(100000))'
  50 loops, best of 5: 7.96 msec per loop

  python -m timeit 'sum(age > 17 for age in range(100000))'
  50 loops, best of 5: 4.78 msec per loop

Re: What learning APL taught me about Python

#80
post #14

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. Like this line of JS feels so much easier to read than that line of python: ages.filter(age => age > 17).length Directly translating this approach to python: len(list(filter(lambda age: (age > 17), ages))) Although a better way to write this in python I guess would be using lis…

I feel like the numpy version is most concise, most readable, and most array-ish: np.sum(age>17) (Assumes age is a np.array)

Yes, this is VERY close to the APL way: +/ages>17

OP here; maybe I'll add a comment to the article to make the comparison between NumPy and APL for this expression. Thanks!

Post reply on HN