Live data from Hacker News

What learning APL taught me about Python

mathspp.com

51–60 of 104 posts

Re: What learning APL taught me about Python

#51

Earlier quoted context omitted.

Multi-line lambdas are fine: Python will accept newlines in certain parts of an expression, and you can use '\' for others; e.g. f = lambda x: [ x + y for y in range(x) if y % 2 == 0 ] >>> f(5) [5, 7, 9] Lambdas which perform multiple sequential steps are fine, since we can use tuples to evaluate expressions in order; e.g. from sys import stdout g = lambda x: ( stdout.write("Given {0}\n".format(repr(x))), x.append(42…

Neat. I tried it with print(), works fine. Don't need return in a lambda. Assignment now has the walrus. Leaves raise and few other odds and ends. Do believe you've cracked it! Don't think I'll use it much, but you never know... in a pinch.

Ah yes, I've been doing this with stdout.write since Python 2; it didn't occur to me that when Python 3 turned print into a function that would make it usable in lambdas!

You're right that the walrus makes assignment more usable; we can also call methods like .__setitem__ to get similar effects. Unfortunately the walrus seems to suffer the same broken/ambiguous scoping as assignment statements, e.g.

  >>> a = 1
  >>> b = lambda: (print(a), a := 2)
  >>> b()
  Traceback (most recent call last):
    File "", line 1, in 
    File "", line 1, in 
  UnboundLocalError: cannot access local variable 'a' where it is not associated with a value
> Don't need return in a lambda

`return` is needed for early returns. Notice that my `abs` example is trying to do that with `return n` (to skip the `-1 *` operation, since `n` is non-negative in that case).

> Leaves raise and a few other odds and ends

Off the top of my head: yield, match, def, import, class, with, for, while, assert, try, except, async, await.

Re: What learning APL taught me about Python

#52

Earlier quoted context omitted.

Neat. I tried it with print(), works fine. Don't need return in a lambda. Assignment now has the walrus. Leaves raise and few other odds and ends. Do believe you've cracked it! Don't think I'll use it much, but you never know... in a pinch.

Ah yes, I've been doing this with stdout.write since Python 2; it didn't occur to me that when Python 3 turned print into a function that would make it usable in lambdas! You're right that the walrus makes assignment more usable; we can also call methods like .__setitem__ to get similar effects. Unfortunately the walrus seems to suffer the same broken/ambiguous scoping as assignment statements, e.g. >>> a = 1 >>> b =…

    b = lambda: (a := 2, print(a))
Hmm, need to put the assignment before. Can't access nonlocals unless you only read the the var and don't write to it. That's the way functions in python work as well.

Re: What learning APL taught me about Python

#53

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.

And how many Baud do you type at today?

I've gotten paid for working with APL code. Math professors who aren't great at typing love that stuff, but code has to be maintained and some mild verbosity, as python has, is a very reasonable price to pay for that maintainability.

If this was punch card input, or 110 baud teletypes, where program listings come back at a snails pace and use paper, then APL is great for that.

Re: What learning APL taught me about Python

#54
post #25

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. To do this he invented the APL notation. If you find the article interesting, you might enjoy my curation of his work "Math For The Layman" [0] where he introduces several math topics using this "Iversonian" thinking. [1] Look this up to install the J interpreter. [0]: http…

Thanks ex-APL2 coder here, will look up For Layman site later. My favorite APL story was somebody from morning yoga practice who grew up close to Yorktown Heights, in high school, his parents got him a job writing code for Iverson, which he described as a lot of fun.

It could have been a good career choice at one point, given how many FTE's were devoted to the language at Merrill Lynch, Morgan Stanley, Lehman etc but I took the other fork

Re: What learning APL taught me about Python

#55

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 implement as a programming language.

As an aside, Unix also began in the era of 110 baud teletypes, which motivated brevity of many of its common commands (ls, cat, etc), and those brief names have been criticized a lot -- but people still use Unix/Linux; the brevity is a side issue, not a deciding point. As usual with most things.

Re: What learning APL taught me about Python

#56
post #38

Earlier quoted context omitted.

If ages is a numpy array instead of a list: (ages > 17).sum()

Numpy is something close to APL semantics with Python syntax. There's no doubt it was heavily inspired by APL. One could argue that numpy's popularity vindicates the array model pioneered by APL, while driving a nail in the coffin of "notation as a tool of thought", or APL's version of it at any rate. Array programming has never been more popular but there's no demand for APL syntax.

I think the key to array programming success was due to the possibility of having fast interpreted languages for numerical computing. I'm very used to programming in array languages (Matlab, Python, Julia and even Mathematica has lot of vectorized ops) and still I think a lot in terms of for loops.

Re: What learning APL taught me about Python

#57
post #42

> Another big thing that APL made me realise is that the Boolean values True/False and the integers 1/0 are tightly connected Amen! It'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…

(replying to myself to add) I do use hungarian, and I do use a bool-like abstract type, and it is indicated in my type calculus, but semantically my implementation allows for mixing true=1 and false=0 with other ints and arithmetic operators. I eschew implementations that do not have the convenient semantics which I feel introduces no confusion, only convenience

Re: What learning APL taught me about Python

#59
post #38

Earlier quoted context omitted.

Numpy is something close to APL semantics with Python syntax. There's no doubt it was heavily inspired by APL. One could argue that numpy's popularity vindicates the array model pioneered by APL, while driving a nail in the coffin of "notation as a tool of thought", or APL's version of it at any rate. Array programming has never been more popular but there's no demand for APL syntax.

I think the key to array programming success was due to the possibility of having fast interpreted languages for numerical computing. I'm very used to programming in array languages (Matlab, Python, Julia and even Mathematica has lot of vectorized ops) and still I think a lot in terms of for loops.

This. Ideally we'd have jitted python loops be efficient. I love array syntax for simple examples but for more complex ops a loop is often clearer.

Re: What learning APL taught me about Python

#60
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…

Doing @WalterBright's job for a second to let you know that in the D language, given a function that is defined as taking, say, a list as the first argument, it can be called either

    myfun(list)
or

    list.myfun()
and this applies without exception. This means a lot of C-library code gets easier to read when used from D:

    Vector3 vec = (Vector3){ 1, 2, 3};
    Vector3 result = Vector3Add(vec, vec2);
becomes

    auto vec = Vector3(1, 2, 3);
    auto result = vec.Vector3Add(vec2);
I know its slightly off topic, but I want more people to use D, I really prefer it to C, C++ and Rust.
Post reply on HN