6 ms·

They have to write the crazy paragraphs because the code is ugly to look at, so they have to spend 18 hours convincing someone to use it. They could choose sym

They have to write the crazy paragraphs because the code is ugly to look at, so they have to spend 18 hours convincing someone to use it. They could choose symbols that don't look so ugly next to each other, then they would not have to spend as much time convincing people the language does not suck.

gitonthescene 3y ago
Maybe the criticism could be a bit more precise than “it sucks”. Though I am a fan of the animated series The Critic.
jodrellblank 3y ago
Your criticism amounts to "if it isn't pretty, it isn't worth it". Haven't we got past judging worth on surface beauty yet? Didn't we hear the story of the ugly duckling as children? Haven't we learned that there are tastes which can be developed (like cheeses, beers, spirits, cigars) and worthwhile skills that need time and effort and perseverance to develop? > "They could choose symbols that don't look so ugly next to each other," Not as easily as you might think, given all the Unicode symbols exist because they already have a meaning to someone, and many of those might not render in typical font which computers already have installed.
- Analemma_ 3y ago
  That's a very reductive and bad-faith interpretation of the criticism. A much better one would be: "You can write either write a symbol soup with multiple paragraphs explaining what the soup does and why it is good, or you could write an equivalent amount of code in a verbose, readable language. The former option introduces two places for errors: they could be either in the code, or in the mapping from the code to the prose, while the latter only has one."
  - zozbot234 3y ago
    Symbol soup is just fine when you're working in a highly restricted domain with limited scope for novel abstractions - which may well suit the idiomatic usage of array languages. Math expressions are symbol soup, but a trained mathematician can read them quite directly.
    - sudosysgen 3y ago
      Math expressions and notations are far more expressive than APL or J, because they are graphical, highly flexible, and not meant to be compiled. They also tend to be accompanied by text for whatever cannot be efficiently conveyed by the notation.
  - jodrellblank 3y ago
    This is an argument which has been going on for years; "crazy paragraphs because the code is ugly" is a thoughtless low effort criticism and it doesn't deserve a steelman fleshed out rebuttal if the person hasn't put any effort in. You say "a symbol soup with multiple paragraphs explaining what the soup does and why it is good" - honestly, do you think people write multiple paragraphs explaining the code to beginners who can't read APL every single time they write any APL? Of course they don't! Your proposal relies on "symbol soup" being a fair and accurate description, which it isn't. And, are you suggesting that people don't write comments explaining their code in common popular languages? Of course they do! (and should) And, are you suggesting that people don't have to learn and practise to be able to read common popular languages when they learn to program? Of course they do, look at posts around the internet on people learning Java and Rust and C# and C++ and Python asking what some code means, what some syntax means, and not only beginners, lots of people ask like "I can code but what is this syntax?" and it's a Python generator comprehension, or a ternary operator, or a C# LINQ SQL style or a pattern match or an anonymous function or a compiler hint or a documentation generator template or a generic type or a turbofish or whatever thing they hadn't seen before in their previous languages or codebases. And, are you suggesting that comments getting out of sync with code is only a problem in array languages? Of course it isn't. Or that nobody ever complains about the readability of Java because it's so verbose and has so much abstraction you can't see what's supposed to be happening? People do. I do. And as always, what about regex? It's so useful as a text processing language that it's often still shorter and cleaner to write a complex regex and paragraphs of comments explaining it, than to code the equivalent in classic string indexing and slicing and if/else branches. You'd end up writing a Greenspun-esque ad hoc, informally-specified, bug-ridden, slow implementation of half a regex engine. That's not to say there is no criticism of APL's style possible, but if you want people to take the criticism seriously, have something new to say about it or some solid support and explanation for it. "Whenever you look at a problem somebody’s been working on for a week or a month or maybe years and propose a simple, obvious solution that just happens to be the first thing that comes into your head, then you’re also making it crystal clear to people what you think of them and their work." - https://exple.tive.org/blarg/2019/04/17/why-dont-you-just/ https://exple.tive.org/blarg/2019/04/17/why-dont-you-just/
7thaccount 3y ago
I think I'd rather have a half page of APL with a page of explanations (given a little time to learn the language better than I do now) than 20 pages of Java that I have to scroll through with comments and unintelligible class paths. Either way it takes time to consume the logic, but it's nice to have it all in one place than scattered about all over creation. I think that's what he's getting at with Aaron's more macro based view. He wrote thousands and thousands of loc before being able to whittle it down to such a terse amount. I can't read it, but that's less to do with APL and a lot more to do with knowing nothing of the domain of compilers. The symbols actually make a lot of sense and can help you remember what they do. I can remember quite a few after only playing around with it a bit and reading a book on it ages ago.
- ryan-duve 3y ago
  Do you remember which book it was you read?
  - 7thaccount 3y ago
    For APL I started with the Mastering Dyalog APL book they have for free on their website which is good, but long. Someone recommended an ancient book I found on Amazon called "APL An Interactive Approach 2nd Ed." I think by Gilman and Rose that is very easy to follow. There are plenty of tutorials online now too (a lot more than when I started looking 8 years ago). For J, I read a good bit of "Numerical Programming in J" or something along those lines. I've found J to be more difficult than APL or K to pick up tbh. The tacit trains is just a bit too hard for me to follow.
goatlover 3y ago
The language doesn't suck for people who use it. They learn the symbols just fine and are able to understand what's going on. Same thing for math, which can also be very terse. Which is better, compact or verbose code? That's a style issue and it all depends on who you ask. Verbose code requires you to read more. And more code to maintain.
scrubs 3y ago
Agree. Plus matrix multiplication is essentially is array oriented by the domain of the problem. Writing a mutex, or any number of distributed search/sort algos with disk io approaching dbs isn't. Network io isn't either is any natural sense
- rak1507 3y ago
  You can do 'regular' stuff in array languages too. And distributed searching/sorting sounds like something array languages would be good at anyway. kdb being the obvious example. The IPC in q for example is very easy to use, and seems better than most languages that aren't Erlang.
  - scrubs 3y ago
    Well, I agree in the absolute sense. Not in the practical sense. In fact there is a ranking because on natural affinity and baseline-existence-of-what's-already in the domain. That's is what it is ...

gitonthescene 3y ago

Maybe the criticism could be a bit more precise than “it sucks”. Though I am a fan of the animated series The Critic.

jodrellblank 3y ago

Your criticism amounts to "if it isn't pretty, it isn't worth it". Haven't we got past judging worth on surface beauty yet? Didn't we hear the story of the ugly duckling as children? Haven't we learned that there are tastes which can be developed (like cheeses, beers, spirits, cigars) and worthwhile skills that need time and effort and perseverance to develop? > "They could choose symbols that don't look so ugly next to each other," Not as easily as you might think, given all the Unicode symbols exist because they already have a meaning to someone, and many of those might not render in typical font which computers already have installed.

Analemma_ 3y ago
That's a very reductive and bad-faith interpretation of the criticism. A much better one would be: "You can write either write a symbol soup with multiple paragraphs explaining what the soup does and why it is good, or you could write an equivalent amount of code in a verbose, readable language. The former option introduces two places for errors: they could be either in the code, or in the mapping from the code to the prose, while the latter only has one."
- zozbot234 3y ago
  Symbol soup is just fine when you're working in a highly restricted domain with limited scope for novel abstractions - which may well suit the idiomatic usage of array languages. Math expressions are symbol soup, but a trained mathematician can read them quite directly.
  - sudosysgen 3y ago
    Math expressions and notations are far more expressive than APL or J, because they are graphical, highly flexible, and not meant to be compiled. They also tend to be accompanied by text for whatever cannot be efficiently conveyed by the notation.
- jodrellblank 3y ago
  This is an argument which has been going on for years; "crazy paragraphs because the code is ugly" is a thoughtless low effort criticism and it doesn't deserve a steelman fleshed out rebuttal if the person hasn't put any effort in. You say "a symbol soup with multiple paragraphs explaining what the soup does and why it is good" - honestly, do you think people write multiple paragraphs explaining the code to beginners who can't read APL every single time they write any APL? Of course they don't! Your proposal relies on "symbol soup" being a fair and accurate description, which it isn't. And, are you suggesting that people don't write comments explaining their code in common popular languages? Of course they do! (and should) And, are you suggesting that people don't have to learn and practise to be able to read common popular languages when they learn to program? Of course they do, look at posts around the internet on people learning Java and Rust and C# and C++ and Python asking what some code means, what some syntax means, and not only beginners, lots of people ask like "I can code but what is this syntax?" and it's a Python generator comprehension, or a ternary operator, or a C# LINQ SQL style or a pattern match or an anonymous function or a compiler hint or a documentation generator template or a generic type or a turbofish or whatever thing they hadn't seen before in their previous languages or codebases. And, are you suggesting that comments getting out of sync with code is only a problem in array languages? Of course it isn't. Or that nobody ever complains about the readability of Java because it's so verbose and has so much abstraction you can't see what's supposed to be happening? People do. I do. And as always, what about regex? It's so useful as a text processing language that it's often still shorter and cleaner to write a complex regex and paragraphs of comments explaining it, than to code the equivalent in classic string indexing and slicing and if/else branches. You'd end up writing a Greenspun-esque ad hoc, informally-specified, bug-ridden, slow implementation of half a regex engine. That's not to say there is no criticism of APL's style possible, but if you want people to take the criticism seriously, have something new to say about it or some solid support and explanation for it. "Whenever you look at a problem somebody’s been working on for a week or a month or maybe years and propose a simple, obvious solution that just happens to be the first thing that comes into your head, then you’re also making it crystal clear to people what you think of them and their work." - https://exple.tive.org/blarg/2019/04/17/why-dont-you-just/ https://exple.tive.org/blarg/2019/04/17/why-dont-you-just/

7thaccount 3y ago

I think I'd rather have a half page of APL with a page of explanations (given a little time to learn the language better than I do now) than 20 pages of Java that I have to scroll through with comments and unintelligible class paths. Either way it takes time to consume the logic, but it's nice to have it all in one place than scattered about all over creation. I think that's what he's getting at with Aaron's more macro based view. He wrote thousands and thousands of loc before being able to whittle it down to such a terse amount. I can't read it, but that's less to do with APL and a lot more to do with knowing nothing of the domain of compilers. The symbols actually make a lot of sense and can help you remember what they do. I can remember quite a few after only playing around with it a bit and reading a book on it ages ago.

ryan-duve 3y ago
Do you remember which book it was you read?
- 7thaccount 3y ago
  For APL I started with the Mastering Dyalog APL book they have for free on their website which is good, but long. Someone recommended an ancient book I found on Amazon called "APL An Interactive Approach 2nd Ed." I think by Gilman and Rose that is very easy to follow. There are plenty of tutorials online now too (a lot more than when I started looking 8 years ago). For J, I read a good bit of "Numerical Programming in J" or something along those lines. I've found J to be more difficult than APL or K to pick up tbh. The tacit trains is just a bit too hard for me to follow.

goatlover 3y ago

The language doesn't suck for people who use it. They learn the symbols just fine and are able to understand what's going on. Same thing for math, which can also be very terse. Which is better, compact or verbose code? That's a style issue and it all depends on who you ask. Verbose code requires you to read more. And more code to maintain.

scrubs 3y ago

Agree. Plus matrix multiplication is essentially is array oriented by the domain of the problem. Writing a mutex, or any number of distributed search/sort algos with disk io approaching dbs isn't. Network io isn't either is any natural sense

rak1507 3y ago
You can do 'regular' stuff in array languages too. And distributed searching/sorting sounds like something array languages would be good at anyway. kdb being the obvious example. The IPC in q for example is very easy to use, and seems better than most languages that aren't Erlang.
- scrubs 3y ago
  Well, I agree in the absolute sense. Not in the practical sense. In fact there is a ranking because on natural affinity and baseline-existence-of-what's-already in the domain. That's is what it is ...