4 ms·

This is so subjective. Some people do want to write such code as that is “cleaner” because it’s compact. Some wants to explain every single step because that’s

by he0001 4y ago

This is so subjective. Some people do want to write such code as that is “cleaner” because it’s compact. Some wants to explain every single step because that’s “cleaner”. Some tries to do something in between and it’s somehow “cleaner”. But in the end, it’s mostly subjective.

overgard 4y ago
Here's conway's game of life in APL: life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵} Is that shorter than essentially every other language implementation. Yep! However, to even begin to understand it you have to read an article from the original writer: https://aplwiki.com/wiki/John_Scholes%27_Conway%27s_Game_of_Life https://aplwiki.com/wiki/John_Scholes%27_Conway%27s_Game_of_... To me, that is objectively, not subjectively, less clear than the longer implementations.
- rak1507 4y ago
  'However, to even begin to understand it you have to read an article from the original writer' - or just know APL? If you know APL, it's clear.
  - overgard 4y ago
    While I'm not going to go collect a bunch of APL programmers to confirm this (where would one even find them?), I highly doubt that claim. Knowing a language doesn't mean dense code is suddenly obvious. This is a silly example, but years ago I wanted to prove that you could write a non-trivial program in python using a single expression (because python's lambda only allows you to use expressions, not statements). And I managed to do that. And it's hideous. Any python programmer could theoretically understand what this is doing, but I doubt they would. Bonus points if you can guess what it does without running it! (lambda: not globals().__setitem__('sys', __import__('sys')) and not globals().__setitem__('this', sys.modules[globals()['__name__']]) and not globals().__setitem__('time', __import__('time')) and #program [setattr(this, k, v) for k,v in { 'set_color': (lambda c: w(['*', ' '][c])), 'abs': (lambda t: (int(t) + (int(t) >> 31)) ^ (int(t) >> 31)), 'w': lambda x: sys.stdout.write(x) == 0, 'smash': (lambda t: -((t * -1) >> 31)), 'color': (lambda n,k: set_color(smash (k & (n - k)))), 'col': (lambda n, k: k <= n and not color(n,k) and col(n,k + 1)), 'row': (lambda n: ( not w(' ' * (40-abs(int(n/2)))) and (col(abs(n), 0) or True) and not w("\n") and (abs(n) < 63 or n < 0) and not time.sleep(0.05) and row(n+1))), 'triangle': lambda: row(-60) }.items() ] and triangle() )()
    - ParetoOptimal 4y ago
      That example isn't like APL though because of it's verbosity. Also APL has more universal abstractions to express a lot of this kind of logic. That lack of verbosity makes it easier to pick out the intention revealing code, which isn't the case here.
      - overgard 4y ago
        Well, of course that code was meant as a joke, and I did some things intentionally weird. I mention it just to point out that a metric like "it's only a single expression!" doesn't mean that something is actually simple.
    - rak1507 4y ago
      You don't need a bunch - you need 1. I am an APL programmer, and I can tell you 100% for certain that anyone who knows any APL would find that easy to read. (Want to find more though? Go to one of these: https://aplwiki.com/wiki/Chat_rooms_and_forums https://aplwiki.com/wiki/Chat_rooms_and_forums) Knowing a language absolutely does mean 'dense' code is obvious (fwiw that APL code is not at all dense, you can do go a lot shorter). It's comparable to chinese characters or something like that. It only looks dense/unreadable to someone who doesn't know it.
- ParetoOptimal 4y ago
  Can you objectively say that familiarity isn't the primary reason APL is less understandable? Put another way, if you had 2 years of APL experience and 2 years of Python experience, would you maintain that the APL code is objectively less clear? Is it really fair to judge languages we aren't familiar with to the extent of the language we are comparing to?
  - overgard 4y ago
    Well, it'd be fairly easy to test: teach a first year coding course, give one group python and the other group APL, and monitor the grades and the drop rate. I can't prove it, but I'm highly confident that python would win. Because it has a lot of analogies to things people already know: - In simple cases, you can read it as a set of commands, like a recipe. People are familiar with recipes - Syntax mostly uses well know words (or abbreviations of well known words), or very simple symbols that you'd pick up in basic math (+,-, *, comma, etc.) - Variable names make clear what the result of a particular expression maps back to in the real world (ideally) - The whitespace indented structure of the code is fairly obvious if you've ever written an outline APL has... - Unfamiliar symbols - Terse, confusing names I mean, look at this example for getting the average from a list of numbers: {(+⌿⍵)÷≢⍵} Since I don't know greek or math particularly well, in my head I read that as "plus minus sign with a slash through it and curly w divided by triple equals curly w with a slash through it". I'm nowhere. Here's the python code: def average(numbers): return sum(numbers) / len(numbers) I couldn't write that if I didn't know python, but if I had never written a line of code in my life I could give you a decent guess as to what it does. Is it verbose? I guess in character count, but not in any meaningful sense. You're right, familiarity IS why python is easier to understand. But it's not programming familiarity, it's that almost every aspect of it is more familiar. The only people that (might) find APL more familiar are mathematicians in my opinion, and they could easily understand python.
    - mlochbaum 4y ago
      I know a few people who've taught APL to kids or other non-programmers and the most common remark is how much quicker they get it than students who've worked with other languages. I don't know what the result of the experiment you describe would be but you're definitely biased by your experience. And as a counterpoint to your example, here's the code to multiply several numbers by two in both Python in APL: x = [1,2,3] [n*2 for n in x] 2 × 1 2 3 We have forums: APL Farm is the most consistently active. If you'd like to talk to real live APLers just hop in. https://aplwiki.com/wiki/Chat_rooms_and_forums https://aplwiki.com/wiki/Chat_rooms_and_forums
- he0001 4y ago
  Well, to you it is, for someone else it’s “clean”. APL is a fun language and kind of my point here. Someone thought that other languages were too verbose and tried to write a language that was more expressive which a “normal” language never can achieve.

by he0001 4y ago

overgard 4y ago

Here's conway's game of life in APL: life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵} Is that shorter than essentially every other language implementation. Yep! However, to even begin to understand it you have to read an article from the original writer: https://aplwiki.com/wiki/John_Scholes%27_Conway%27s_Game_of_Life https://aplwiki.com/wiki/John_Scholes%27_Conway%27s_Game_of_... To me, that is objectively, not subjectively, less clear than the longer implementations.

rak1507 4y ago
'However, to even begin to understand it you have to read an article from the original writer' - or just know APL? If you know APL, it's clear.
- overgard 4y ago
  While I'm not going to go collect a bunch of APL programmers to confirm this (where would one even find them?), I highly doubt that claim. Knowing a language doesn't mean dense code is suddenly obvious. This is a silly example, but years ago I wanted to prove that you could write a non-trivial program in python using a single expression (because python's lambda only allows you to use expressions, not statements). And I managed to do that. And it's hideous. Any python programmer could theoretically understand what this is doing, but I doubt they would. Bonus points if you can guess what it does without running it! (lambda: not globals().__setitem__('sys', __import__('sys')) and not globals().__setitem__('this', sys.modules[globals()['__name__']]) and not globals().__setitem__('time', __import__('time')) and #program [setattr(this, k, v) for k,v in { 'set_color': (lambda c: w(['*', ' '][c])), 'abs': (lambda t: (int(t) + (int(t) >> 31)) ^ (int(t) >> 31)), 'w': lambda x: sys.stdout.write(x) == 0, 'smash': (lambda t: -((t * -1) >> 31)), 'color': (lambda n,k: set_color(smash (k & (n - k)))), 'col': (lambda n, k: k <= n and not color(n,k) and col(n,k + 1)), 'row': (lambda n: ( not w(' ' * (40-abs(int(n/2)))) and (col(abs(n), 0) or True) and not w("\n") and (abs(n) < 63 or n < 0) and not time.sleep(0.05) and row(n+1))), 'triangle': lambda: row(-60) }.items() ] and triangle() )()
  - ParetoOptimal 4y ago
    That example isn't like APL though because of it's verbosity. Also APL has more universal abstractions to express a lot of this kind of logic. That lack of verbosity makes it easier to pick out the intention revealing code, which isn't the case here.
    - overgard 4y ago
      Well, of course that code was meant as a joke, and I did some things intentionally weird. I mention it just to point out that a metric like "it's only a single expression!" doesn't mean that something is actually simple.
  - rak1507 4y ago
    You don't need a bunch - you need 1. I am an APL programmer, and I can tell you 100% for certain that anyone who knows any APL would find that easy to read. (Want to find more though? Go to one of these: https://aplwiki.com/wiki/Chat_rooms_and_forums https://aplwiki.com/wiki/Chat_rooms_and_forums) Knowing a language absolutely does mean 'dense' code is obvious (fwiw that APL code is not at all dense, you can do go a lot shorter). It's comparable to chinese characters or something like that. It only looks dense/unreadable to someone who doesn't know it.
ParetoOptimal 4y ago
Can you objectively say that familiarity isn't the primary reason APL is less understandable? Put another way, if you had 2 years of APL experience and 2 years of Python experience, would you maintain that the APL code is objectively less clear? Is it really fair to judge languages we aren't familiar with to the extent of the language we are comparing to?
- overgard 4y ago
  Well, it'd be fairly easy to test: teach a first year coding course, give one group python and the other group APL, and monitor the grades and the drop rate. I can't prove it, but I'm highly confident that python would win. Because it has a lot of analogies to things people already know: - In simple cases, you can read it as a set of commands, like a recipe. People are familiar with recipes - Syntax mostly uses well know words (or abbreviations of well known words), or very simple symbols that you'd pick up in basic math (+,-, *, comma, etc.) - Variable names make clear what the result of a particular expression maps back to in the real world (ideally) - The whitespace indented structure of the code is fairly obvious if you've ever written an outline APL has... - Unfamiliar symbols - Terse, confusing names I mean, look at this example for getting the average from a list of numbers: {(+⌿⍵)÷≢⍵} Since I don't know greek or math particularly well, in my head I read that as "plus minus sign with a slash through it and curly w divided by triple equals curly w with a slash through it". I'm nowhere. Here's the python code: def average(numbers): return sum(numbers) / len(numbers) I couldn't write that if I didn't know python, but if I had never written a line of code in my life I could give you a decent guess as to what it does. Is it verbose? I guess in character count, but not in any meaningful sense. You're right, familiarity IS why python is easier to understand. But it's not programming familiarity, it's that almost every aspect of it is more familiar. The only people that (might) find APL more familiar are mathematicians in my opinion, and they could easily understand python.
  - mlochbaum 4y ago
    I know a few people who've taught APL to kids or other non-programmers and the most common remark is how much quicker they get it than students who've worked with other languages. I don't know what the result of the experiment you describe would be but you're definitely biased by your experience. And as a counterpoint to your example, here's the code to multiply several numbers by two in both Python in APL: x = [1,2,3] [n*2 for n in x] 2 × 1 2 3 We have forums: APL Farm is the most consistently active. If you'd like to talk to real live APLers just hop in. https://aplwiki.com/wiki/Chat_rooms_and_forums https://aplwiki.com/wiki/Chat_rooms_and_forums
he0001 4y ago
Well, to you it is, for someone else it’s “clean”. APL is a fun language and kind of my point here. Someone thought that other languages were too verbose and tried to write a language that was more expressive which a “normal” language never can achieve.