I'm a huge advocate of bringing usability/ergonomic considerations to programming languages. That said, I have strong opinions about syntax decisions that hinder those goals.
For example, writing out words instead of using symbols is easier to understand at first glance, but it's much harder to skim (even after becoming familiar with the language). SQL is a really hard language to skim. Of course, the opposite end of the spectrum (C is close) is also hard to skim.
There are tradeoffs. The syntax was explicitly designed to be eminently readable, because our target audience were groups who were not traditionally programmers, but who might still be highly technical. For this group of people, they may not take readily to C++, but are instead more comfortable with languages like Python and SQL. Perhaps skimming code suffers from this design, but we thought we could mitigate that by adding other avenues for navigating code, such as a table of contents. We also made some progress in automatically annotating blocks of code based on what they do, to make filtering, sorting, and searching code richer.
You're being snarky, but I think there's something to the parent comment.
I like the idea that most of the words that someone sees in a program are words in the domain of the program itself — its nouns and verbs — and not words in the domain of the underlying implementation language.
For example, though I visually like the way Ruby's "begin" and "end" look for delimiters, I think braces are better in that they reduce the "word clutter" of the code.
You can probably take this too far. I wouldn't want to use punctuation for control flow. But perhaps that's an argument that, like Smalltalk, control flow should be an API and not built in syntax.
I agree! Anecdotally, I prefer `x >>= y` over `x .then y`, and `f <$> xs` over `map f xs` because the symbols "read quieter" to my mind, which helps me maintain focus.
Syntax highlighting usually is used to set apart the language's keywords from the rest of the program. They become less like words and more like standard symbols.
Great point! One of the things I really like about syntax highlighting is this separation. It's important enough that when I'm toying with syntax for my hobby languages, it's really hard for me to get a feel for how something looks if it isn't highlighted correctly.
I agree. I prefer to have both. It's hard to argue that either SQL or Brainfuck is more readable than, say, JavaScript (to an experienced eye), so a happy medium must exist.
Comments
I'm a huge advocate of bringing usability/ergonomic considerations to programming languages. That said, I have strong opinions about syntax decisions that hinder those goals.
For example, writing out words instead of using symbols is easier to understand at first glance, but it's much harder to skim (even after becoming familiar with the language). SQL is a really hard language to skim. Of course, the opposite end of the spectrum (C is close) is also hard to skim.
There are tradeoffs. The syntax was explicitly designed to be eminently readable, because our target audience were groups who were not traditionally programmers, but who might still be highly technical. For this group of people, they may not take readily to C++, but are instead more comfortable with languages like Python and SQL. Perhaps skimming code suffers from this design, but we thought we could mitigate that by adding other avenues for navigating code, such as a table of contents. We also made some progress in automatically annotating blocks of code based on what they do, to make filtering, sorting, and searching code richer.
So is APL easy to skim?
You're being snarky, but I think there's something to the parent comment.
I like the idea that most of the words that someone sees in a program are words in the domain of the program itself — its nouns and verbs — and not words in the domain of the underlying implementation language.
For example, though I visually like the way Ruby's "begin" and "end" look for delimiters, I think braces are better in that they reduce the "word clutter" of the code.
You can probably take this too far. I wouldn't want to use punctuation for control flow. But perhaps that's an argument that, like Smalltalk, control flow should be an API and not built in syntax.
I agree! Anecdotally, I prefer `x >>= y` over `x .then y`, and `f <$> xs` over `map f xs` because the symbols "read quieter" to my mind, which helps me maintain focus.
Those aren't so bad if you have something like hasklig installed. But otherwise the stilted typography just drives me crazy.
Syntax highlighting usually is used to set apart the language's keywords from the rest of the program. They become less like words and more like standard symbols.
Great point! One of the things I really like about syntax highlighting is this separation. It's important enough that when I'm toying with syntax for my hobby languages, it's really hard for me to get a feel for how something looks if it isn't highlighted correctly.
I agree. I prefer to have both. It's hard to argue that either SQL or Brainfuck is more readable than, say, JavaScript (to an experienced eye), so a happy medium must exist.
I prefer Erlang's approach: dispense with the words and the braces. Unfortunately Elixir decided words were friendlier.