Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Austral Programming Language

austral-lang.org

Post reply on HN
Print view View original

121–124 of 124 posts

Re: The Austral Programming Language

#121

Post by cpeterso »

lelanthran wrote: post #114
cpeterso wrote: post #73

Earlier quoted context omitted.

Studies of program verbosity have shown that long vs short names have little impact in other programmers' reading comprehension or code maintainability.

TIL. Do you remember which languages they looked at?

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

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/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/

Re: The Austral Programming Language

#122

Post by Yasuraka »

cpeterso wrote: post #73
Yasuraka wrote: post #37

Earlier quoted context omitted.

>the microscopic savings in key presses are just really such a strange thing to even debate It's about readability

Studies of program verbosity have shown that long vs short names have little impact in other programmers' reading comprehension or code maintainability.

Experts[1] agree that boilerplatey declarations and verbose keyword groupings are bad and Java has been deemed inhumane because of this.

[1]Me

Re: The Austral Programming Language

#123

Post by creata »

meindnoch wrote: post #117
creata wrote: post #93

Earlier quoted context omitted.

But there's no .cpp file for many (most?) uses of templates.

If you think about what templates are, it's not hard to understand why they must go completely in the header files. It's literally a source code template . It's a set of instructions to generate code at compile time, depending on the template parameters, hence 100% of the source code must be available at the point of instantiation. Just the interface is not enough.

Of course, but it still breaks the split between interface and implementation that people are talking about here.

Re: The Austral Programming Language

#124

Post by lelanthran »

zetalyrae wrote: post #67
imglorp wrote: post #49

Flashbacks to TA'ing freshman programming 101 in Pascal: every student got hung up on when to use a period or semicolon or end. And from Austral's fib example (snipped) module body Fib is function fib(n: Nat64): Nat64 is if n We here all understand BNF, Ada, Modula, etc and parsing but imagine explaining to the first day student: Why is there no "end function" like for the other contexts? When do I use a semicolon vs…

Declarations don't need `end function` because it's always clear what you're closing. Statements need an `end if`, `end for` etc. because it lets you find your way in nested code. The rationale for the syntax explains it a bit: https://austral-lang.org/spec/spec.html#rationale-syntax FWIW I will probably get rid of the `module is ... end module.` bit because it adds unnecessary nesting.

> Statements need an `end if`, `end for` etc. because it lets you find your way in nested code. The rationale for the syntax explains it a bit: https://austral-lang.org/spec/spec.html#rationale-syntax

From the link:

>> }

>> }

>> }

>> }

>> }

>> Which one of these corresponds to the second for loop? Unless we have an editor with folding support, we have to find the column where the second for loop begins, scroll down to the closing curly brace at that column position, and insert the code there. This is manual and error-prone.

I'm not fully convinced of that argument. Here's a devil's advocate take...

The keywords do indeed help when the corresponding nested control structures are off-screen, but if the code you are reading is not refactored to move the control structures into their own function so that the indentation doesn't get that much out of hand, you likely have bigger problems with the code than determining which `end` corresponds to which control structure.

IOW, having this sort of identification is moot: if it is needed, then the code itself is in such poor condition that it's likely not very readable anyway. In many cases it won't make a difference anyway (nested 'if's, for example - seeing multiple `end if` doesn't help) and the developer is still going to place a comment specifying which particular `if ()` is being ended.

Having the unadorned closing braces (`}`) leaves the developer one of three options:

1. Refactor that code just to be able to read it, or

2. As you point out, add in comments like `// end if`, etc, or

3. Leave it as it is.

If it's left as is, there's bigger problems in the code anyway.

Post reply on HN