4 ms·

This quite a shallow observation, but I really wish new languages would cut down on verbosity and boilerplate. Making people type out “function” instead of “fn”

This quite a shallow observation, but I really wish new languages would cut down on verbosity and boilerplate. Making people type out “function” instead of “fn”, “def”, or nothing at all feels like unneeded friction. I’m not looking for APL levels of terseness, but I also don’t want to have my code mistaken for an essay filled with what amounts to scaffolding.

hyperhello 3y ago
I’d like it to just look exactly like C, but with new ideas in some incompatible syntax showing it is not part of C.
- all2 3y ago
  Zig? Or Nim? Both of those are Algol-ish. Ooh! What about [0]? Gambit Scheme has what they call `six-script` which is essentially a refactoring of Scheme grammar to fit into an Algol-esque syntax. [0] http://gambitscheme.org/latest/manual/#GSI http://gambitscheme.org/latest/manual/#GSI, see section 2.6.1
- hardwaregeek 3y ago
  Ehh C is a pretty miserable language to parse. No function definition keyword means you have to get pretty far to realize that you're parsing a function. Pointer syntax is ambiguous with expression grouping. And let's not even get started with the preprocessor. I'd say a good model for simple syntax is Go. Rust has a nice compromise of syntax too, but there are some awkward edge cases.
  - jimbob45 3y ago
    Shame they never fixed this. Would have been nothing to add a fn keyword at the beginning of all function definitions and then use the MS EEE strategy to bring it into the standard. Of the many changes the committee could make with C, I have to believe a function keyword would be among the least contentious.
    - hardwaregeek 3y ago
      Probably couldn’t since people could have named functions “fn”. Although idk, one keyword breaking in 50 years is probably excusable
      - lelanthran 3y ago
        Well they didn't mind trampling all over symbols that start with 'str', which is bigger breakage in my opinion, so they could have added a function keyword.
    - __d 3y ago
      Least, perhaps? But certainly contentious. In my view, the job of the C committee should be to eliminate undefined behaviour and any remaining specification ambiguities (or errors) and otherwise leave the damned language alone. If you want a new language every 3 years, you can always use C++.
linguae 3y ago
The language’s syntax seems to be influenced by languages designed by Wirth, such as Pascal, Modula-2, and Oberon. These languages have many fans, but they have quite verbose syntax compared to either languages influenced by C or those influenced by the ML family. Personally I prefer more terse syntax, but I’ve heard some people defend the style of more verbose languages like Pascal and Java when writing large programs.
- eterps 3y ago
  Looks more like Ada to me.
dustingetz 3y ago
\ the ultimate
amw-zero 3y ago
For every person that says this, there's 5 people that say the opposite.
- wredue 3y ago
  That’s because it fundamentally doesn’t actually impact all that much. By most people’s account, the actual coding part of programming isn’t really a majority of their time. Domain research, speccing, debugging, testing, planning, etc. the microscopic savings in key presses are just really such a strange thing to even debate about when you think about it. Major tersness pushes also tend to cause “symbol soup” and, personally, I find symbol soup very hard to digest.
  - Yasuraka 3y ago
    >the microscopic savings in key presses are just really such a strange thing to even debate It's about readability
    - cpeterso 3y ago
      Studies of program verbosity have shown that long vs short names have little impact in other programmers' reading comprehension or code maintainability.
      - lelanthran 3y ago
        TIL. Do you remember which languages they looked at?
        cpeterso 3y ago
        I can't find the study I was thinking about, but here are two other studies I found. Neither study directly supports what I had recalled, but one study concludes longer names are more productive and the other concludes shorter names. :) How well these academic studies apply to production code is another question... * "Shorter [C#] identifier names take longer to comprehend" (2019) https://link.springer.com/article/10.1007/s10664-018-9621-x https://link.springer.com/article/10.1007/s10664-018-9621-x In this paper, we investigate the effect of different identifier naming styles (single letters, abbreviations, and words) on program comprehension. We conducted an experimental study with 72 professional C# developers who had to locate defects in source code snippets. ... We found that word identifiers led to a 19% increase in speed to find defects compared to meaningless single letters and abbreviations, but we did not find a difference between letters and abbreviations. * "[Java] Identifier length and limited programmer memory" (2009) https://www.sciencedirect.com/science/article/pii/S0167642309000343 https://www.sciencedirect.com/science/article/pii/S016764230... names used in existing production code are long enough to crowd programmer’s short-term memory. This provides evidence that software engineers need to consider shorter, more concise names. As the study considers individual names extracted from production code, it tends to underestimate the demand on memory because there is no need to remember context as well. * "Evaluation of Rust code verbosity, understandability and complexity" (2021) https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/
stronglikedan 3y ago
I'm the opposite. I find the code much easier to read when it's verbose, including very long, descriptive function names and the like. And with modern IDEs and autocomplete, it's not really making people type out anything longer than the first couple of letters anyway. The gains are on the backend, where people are reading the code. And don't even get me started on unnecessary aliases in SQL!
- RussianCow 3y ago
  With syntax highlighting being ubiquitous, does it really matter whether the keyword is "function" or "fn"? And at that point, why not make it terse instead of taking up more space and adding unnecessary noise?
  - stephenr 3y ago
    If you're going to take that approach why have any keyword? `foo(){}` is just as clear as `fn foo(){}`
    - fijiaarone 3y ago
      A block is a namespace that has an entry point, and optionally a return value and arguments. There is no need to distinguish between functions, modules classes, lambdas, or whatever. Hence, no need to distinguish their start or ending with keywords, as long as you can determine their scope. Brackets determine scope, and unlike indentation or words, that is all they are used for.
Yasuraka 3y ago
Reminds me of this talk: https://www.youtube.com/watch?v=5kj5ApnhPAE https://www.youtube.com/watch?v=5kj5ApnhPAE And the quote to go along with it: "I'm always delighted by the light touch and stillness of early programming languages. Not much text; a lot gets done. Old programs read like quiet conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who'd have guessed sophistication bought such noise?"
- jll29 3y ago
  "I'm always delighted by the light touch and stillness of early programming languages." Except for COBOL, of course, which is one of the oldest.
  - masklinn 3y ago
    Or Fortran being terse in all the wrong ways.
khiqxj 3y ago
[flagged]
zetalyrae 3y ago
I'll say the Ada-style syntax grows on you.
ralfn 3y ago
Have you ever seen the d3 javascript visualisation examples? The author has a physics background, so the code ends up being very verbose with lots of comments about simple programming stuff, yet incredibly terse when it comes to heavy mathematics. I would have done the opposite. It made me realize that people naturally want to be more verbose when they are less comfortable with the concepts and less verbose when they are very familiar with the concepts. It also made me realize it is totally subjective and there may not be a right answer, that it depends on someone's background and familiarities.
- fijiaarone 3y ago
  Or it means they cut and pasted the algorithm and don’t understand it.
steve_taylor 3y ago
I agree. For a language designed to appeal to grumpy old programmers (see the list of so-called anti-features), it’s not exactly arthritis-friendly.

hyperhello 3y ago

I’d like it to just look exactly like C, but with new ideas in some incompatible syntax showing it is not part of C.

all2 3y ago
Zig? Or Nim? Both of those are Algol-ish. Ooh! What about [0]? Gambit Scheme has what they call `six-script` which is essentially a refactoring of Scheme grammar to fit into an Algol-esque syntax. [0] http://gambitscheme.org/latest/manual/#GSI http://gambitscheme.org/latest/manual/#GSI, see section 2.6.1
hardwaregeek 3y ago
Ehh C is a pretty miserable language to parse. No function definition keyword means you have to get pretty far to realize that you're parsing a function. Pointer syntax is ambiguous with expression grouping. And let's not even get started with the preprocessor. I'd say a good model for simple syntax is Go. Rust has a nice compromise of syntax too, but there are some awkward edge cases.
- jimbob45 3y ago
  Shame they never fixed this. Would have been nothing to add a fn keyword at the beginning of all function definitions and then use the MS EEE strategy to bring it into the standard. Of the many changes the committee could make with C, I have to believe a function keyword would be among the least contentious.
  - hardwaregeek 3y ago
    Probably couldn’t since people could have named functions “fn”. Although idk, one keyword breaking in 50 years is probably excusable
    - lelanthran 3y ago
      Well they didn't mind trampling all over symbols that start with 'str', which is bigger breakage in my opinion, so they could have added a function keyword.
  - __d 3y ago
    Least, perhaps? But certainly contentious. In my view, the job of the C committee should be to eliminate undefined behaviour and any remaining specification ambiguities (or errors) and otherwise leave the damned language alone. If you want a new language every 3 years, you can always use C++.

linguae 3y ago

The language’s syntax seems to be influenced by languages designed by Wirth, such as Pascal, Modula-2, and Oberon. These languages have many fans, but they have quite verbose syntax compared to either languages influenced by C or those influenced by the ML family. Personally I prefer more terse syntax, but I’ve heard some people defend the style of more verbose languages like Pascal and Java when writing large programs.

eterps 3y ago
Looks more like Ada to me.

dustingetz 3y ago

\ the ultimate

amw-zero 3y ago

For every person that says this, there's 5 people that say the opposite.

wredue 3y ago
That’s because it fundamentally doesn’t actually impact all that much. By most people’s account, the actual coding part of programming isn’t really a majority of their time. Domain research, speccing, debugging, testing, planning, etc. the microscopic savings in key presses are just really such a strange thing to even debate about when you think about it. Major tersness pushes also tend to cause “symbol soup” and, personally, I find symbol soup very hard to digest.
- Yasuraka 3y ago
  >the microscopic savings in key presses are just really such a strange thing to even debate It's about readability
  - cpeterso 3y ago
    Studies of program verbosity have shown that long vs short names have little impact in other programmers' reading comprehension or code maintainability.
    - lelanthran 3y ago
      TIL. Do you remember which languages they looked at?
      - cpeterso 3y ago
        I can't find the study I was thinking about, but here are two other studies I found. Neither study directly supports what I had recalled, but one study concludes longer names are more productive and the other concludes shorter names. :) How well these academic studies apply to production code is another question... * "Shorter [C#] identifier names take longer to comprehend" (2019) https://link.springer.com/article/10.1007/s10664-018-9621-x https://link.springer.com/article/10.1007/s10664-018-9621-x In this paper, we investigate the effect of different identifier naming styles (single letters, abbreviations, and words) on program comprehension. We conducted an experimental study with 72 professional C# developers who had to locate defects in source code snippets. ... We found that word identifiers led to a 19% increase in speed to find defects compared to meaningless single letters and abbreviations, but we did not find a difference between letters and abbreviations. * "[Java] Identifier length and limited programmer memory" (2009) https://www.sciencedirect.com/science/article/pii/S0167642309000343 https://www.sciencedirect.com/science/article/pii/S016764230... names used in existing production code are long enough to crowd programmer’s short-term memory. This provides evidence that software engineers need to consider shorter, more concise names. As the study considers individual names extracted from production code, it tends to underestimate the demand on memory because there is no need to remember context as well. * "Evaluation of Rust code verbosity, understandability and complexity" (2021) https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7959618/

stronglikedan 3y ago

I'm the opposite. I find the code much easier to read when it's verbose, including very long, descriptive function names and the like. And with modern IDEs and autocomplete, it's not really making people type out anything longer than the first couple of letters anyway. The gains are on the backend, where people are reading the code. And don't even get me started on unnecessary aliases in SQL!

RussianCow 3y ago
With syntax highlighting being ubiquitous, does it really matter whether the keyword is "function" or "fn"? And at that point, why not make it terse instead of taking up more space and adding unnecessary noise?
- stephenr 3y ago
  If you're going to take that approach why have any keyword? `foo(){}` is just as clear as `fn foo(){}`
  - fijiaarone 3y ago
    A block is a namespace that has an entry point, and optionally a return value and arguments. There is no need to distinguish between functions, modules classes, lambdas, or whatever. Hence, no need to distinguish their start or ending with keywords, as long as you can determine their scope. Brackets determine scope, and unlike indentation or words, that is all they are used for.

Yasuraka 3y ago

Reminds me of this talk: https://www.youtube.com/watch?v=5kj5ApnhPAE https://www.youtube.com/watch?v=5kj5ApnhPAE And the quote to go along with it: "I'm always delighted by the light touch and stillness of early programming languages. Not much text; a lot gets done. Old programs read like quiet conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who'd have guessed sophistication bought such noise?"

jll29 3y ago
"I'm always delighted by the light touch and stillness of early programming languages." Except for COBOL, of course, which is one of the oldest.
- masklinn 3y ago
  Or Fortran being terse in all the wrong ways.

khiqxj 3y ago

[flagged]

zetalyrae 3y ago

I'll say the Ada-style syntax grows on you.

ralfn 3y ago

Have you ever seen the d3 javascript visualisation examples? The author has a physics background, so the code ends up being very verbose with lots of comments about simple programming stuff, yet incredibly terse when it comes to heavy mathematics. I would have done the opposite. It made me realize that people naturally want to be more verbose when they are less comfortable with the concepts and less verbose when they are very familiar with the concepts. It also made me realize it is totally subjective and there may not be a right answer, that it depends on someone's background and familiarities.

fijiaarone 3y ago
Or it means they cut and pasted the algorithm and don’t understand it.

steve_taylor 3y ago

I agree. For a language designed to appeal to grumpy old programmers (see the list of so-called anti-features), it’s not exactly arthritis-friendly.