Live data from Hacker News

The Austral Programming Language

austral-lang.org

41–50 of 124 posts

Re: The Austral Programming Language

#41
post #5

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.

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

You’re right, and that’s part of the reason I remarked my comment’s shallowness. It was more of a personal lament rather than a strong criticism of what looks like a really interesting language.

Re: The Austral Programming Language

#42

Earlier quoted context omitted.

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.

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.

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.

Re: The Austral Programming Language

#43
Looking nice, I like the rationale.

Some questions from my side:

- 1. As far as I understand, there are multiple models for a linear type system. Which one does Austral implement? Is it verified to be correct?

- 2. Since there is a static checker: What are the limits on 1. expressivity and 2. scalability?

- 3. What is the intended memory model (pointer and synchronisation)?

Re: The Austral Programming Language

#44
post #16

This language looks super promising. With the exceptions of 'no type inference' and 'no arithmetic precedence', I really like its anti-features list. With regard to 'no arithmetic precedence', I tried printLn((1 + 2) + 3); and printLn(1 + 2 + 3); Sure enough, the first one compiles, but the second doesn't. Also, (n-1) is a parse error unless you put a space after the minus. I got curious if recursion was properly han…

I prefer the rule in my own languages of "no arithmetic expressions whose meaning can be changed by adding parentheses". So `x + y - z` is allowed but `x - y + z` is not.

Re: The Austral Programming Language

#46
post #45

> designed to be simple enough to be understood by a single person Interesting that this was mentioned. Are there languages that are not simple enough to be understood by a single person?

Yes. C++ is it’s entirety is (probably) not understood by anyone.

Re: The Austral Programming Language

#47
post #16

This language looks super promising. With the exceptions of 'no type inference' and 'no arithmetic precedence', I really like its anti-features list. With regard to 'no arithmetic precedence', I tried printLn((1 + 2) + 3); and printLn(1 + 2 + 3); Sure enough, the first one compiles, but the second doesn't. Also, (n-1) is a parse error unless you put a space after the minus. I got curious if recursion was properly han…

I prefer the rule in my own languages of "no arithmetic expressions whose meaning can be changed by adding parentheses". So `x + y - z` is allowed but `x - y + z` is not.

If operators are over-loadable, you support floats (in a non ffast-math mode), or you treat overflow in most non-modular-arithmetic ways, (x + y) - z and x + (y - z) are different.

Maybe it's worth saying "they're close enough to the same that parentheses should be optional", but I can definitely see the argument for just requiring them regardless.

Re: The Austral Programming Language

#48
post #5

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.

Reminds me of this talk: 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 s…

"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.

Re: The Austral Programming Language

#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 a period to close a context? You shouldn't need the "railroad diagram" to understand the syntax.

Re: The Austral Programming Language

#50
I appreciated that it listed "no destructors" immediately after the top-line "no garbage collection", so I didn't need to read any further. What it means is it offers no ability to encapsulate resource management, so not useful for me. That doesn't mean it is not useful to others.
Post reply on HN