It wouldn't take much work to make a text editor that lets you switch this:
if (username == "alice") {
results[5] = true;
}
into this:
if username valueequals STRINGaliceSTRING begin
let results index 5 be true stop
endif
because symbols are incomprehensible, words are much clearer, and you don't care about saving "a couple of characters" and you don't like codegolf. Would you use it? If not, why not? How do you know the amount of symbols you use is the perfect amount and not merely the amount you are habituated to?
> "Why not give the symbols more descriptive names and let people use those names
For the same reason almost nobody wants {} to be BEGIN/END; the symbols are so ingrained, so well understood, so automatic and habitual that there's no benefit to trying to turn them back into words. Why not move towards doing the same for other common operations? Once you've used ⌊ as floor and ⌈ as ceiling, Math.Floor() feels like a drag. Once you're familiar with 4↑list to get the first 4 items, list[0..4] is a drag and it has more symbols! list.take(4) has more symbols and is no clearer. How do you stop a forever-expanding proliferation of symbols? I don't know, but APL seems to have done a surprisingly good job of general purpose computing in under ~80 symbols which has hardly grown in 70 years.
> "APL seems to be designed for people who place an extremely, extremely high weight on code golf-level terseness."
Would you be surprised that this is valid Dyalog APL for a function to find the highest value in an array of positive integers?
result←findMax data
max←0
:For i :In data
:If i>max
max←i
:EndIf
:EndFor
result←max
then
findMax 5 1 2 3 5 6 3 1
6
Dyalog has keywords, classes, namespaces, methods, libraries, and they get laughed at because who wants :EndFor . It's a bit of a PR issue - if you head to APL it's largely because you like golf, because if that's not what you want you may as well use Python/etc. But once you get there even if APL remains too opaque to use for everything it becomes annoying to know a short way to express what you want that you are comfortable with and have to laboriously boilerplate it out in another language with many lines, and have those lines contain more symbols into the bargain. And we say that one of the hard problems is "naming things", symbols and tacit programming can help avoid putting a name to variables that only hold some intermediate state you don't actually care about but need for the next couple of lines.
> "Why not give the symbols more descriptive names and let people use those names
For the same reason almost nobody wants {} to be BEGIN/END; the symbols are so ingrained, so well understood, so automatic and habitual that there's no benefit to trying to turn them back into words. Why not move towards doing the same for other common operations? Once you've used ⌊ as floor and ⌈ as ceiling, Math.Floor() feels like a drag. Once you're familiar with 4↑list to get the first 4 items, list[0..4] is a drag and it has more symbols! list.take(4) has more symbols and is no clearer. How do you stop a forever-expanding proliferation of symbols? I don't know, but APL seems to have done a surprisingly good job of general purpose computing in under ~80 symbols which has hardly grown in 70 years.
> "APL seems to be designed for people who place an extremely, extremely high weight on code golf-level terseness."
Would you be surprised that this is valid Dyalog APL for a function to find the highest value in an array of positive integers?
then Dyalog has keywords, classes, namespaces, methods, libraries, and they get laughed at because who wants :EndFor . It's a bit of a PR issue - if you head to APL it's largely because you like golf, because if that's not what you want you may as well use Python/etc. But once you get there even if APL remains too opaque to use for everything it becomes annoying to know a short way to express what you want that you are comfortable with and have to laboriously boilerplate it out in another language with many lines, and have those lines contain more symbols into the bargain. And we say that one of the hard problems is "naming things", symbols and tacit programming can help avoid putting a name to variables that only hold some intermediate state you don't actually care about but need for the next couple of lines.