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

51–60 of 124 posts

Re: The Austral Programming Language

#51

Post by jll29 »

For me, this is of interest:

  Austral’s module system is inspired by those of Ada, Modula-2, and Standard ML, 
  with the restriction that there are no generic modules (as in Ada or Modula-3) 
  or functors (as in Standard ML or OCaml), that is: all modules are first-order.

  Modules are given explicit names and are not tied to any particular file system 
  structure. Modules are split in two textual parts (effectively two files), a 
  module interface and a module body, with strict separation between the two. The 
  declarations in the module interface file are accessible from without, and the 
  declarations in the module body file are private.

  Crucially, a module A that depends on a module B can be typechecked when the 
  compiler only has access to the interface file of module B. That is: modules 
  can be typechecked against each other before being implemented. This allows 
  system interfaces to be designed up-front, and implemented in parallel.
It was a mistake how C++, Java and other languages forgot to split interface declaration from implementation definition, IMHO. Good to see that Austral learned from Modula-2.

Before I can form an opinion regarding Austral, though, I would need to see some larger programs implemented in it, for instance some low-level systems code, a generic data structure, some high-level business logic.

Re: The Austral Programming Language

#52

Post by masklinn »

jll29 wrote: post #48
Yasuraka wrote: post #28

Earlier quoted context omitted.

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.

Or Fortran being terse in all the wrong ways.

Re: The Austral Programming Language

#53

Post by stephenr »

RussianCow wrote: post #34
stronglikedan wrote: post #25

Earlier quoted context omitted.

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!

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?

If you're going to take that approach why have any keyword?

`foo(){}` is just as clear as `fn foo(){}`

Re: The Austral Programming Language

#54

Post by lionkor »

angiosperm wrote: post #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.

didn't read it yet, but that are other ways, specifically something like `defer` in go or zig

Re: The Austral Programming Language

#55

Post by colanderman »

gpm wrote: post #47
colanderman wrote: post #44

Earlier quoted context omitted.

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.

Valid point, though my current language supports neither overloading, floats, nor non-modular integer overflow, and parentheses are permissible where not required (for extra-semantical cases where order does matter) :)

Re: The Austral Programming Language

#56

Post by khiqxj »

why are these new languages always built to solve problems in windows or unix or whatever

and the main problem in those os are that there are 21 languages and thats before you even start talking about build systems, config files, and query languages and serialization. how would adding a new language to fix memory leaks make anything better? i see much worse problems here like you still have to build an sql query out of a string. the whole rust having this was just to make c people more comfortable to using a post 90s language (i.e memory safe)

Re: The Austral Programming Language

#57

Post by adamrezich »

angiosperm wrote: post #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.

the page "What are linear types?" seems to address "resources" and the management thereof. not my cup of tea (but then, neither are destructors and garbage collection), but it's an interesting idea.

Re: The Austral Programming Language

#58

Post by danaugrs »

colanderman wrote: post #44
mrkeen wrote: 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.

This is a cool idea that I hadn't heard or thought of before.

Re: The Austral Programming Language

#59

Post by rprospero »

angiosperm wrote: post #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.

From my reading of it, it does have what you're looking for. Specifically, while there are "no destructors", you are required to call a function to consume the value. Failing to consume the value is a compile time error. You can roughly approximate thinking about this as having destructors, but you're required to explicitly call them and the compiler won't let you write code that doesn't call the destructor.

Re: The Austral Programming Language

#60

Post by zetalyrae »

pbarnes_1 wrote: post #9

This is cool but everything is too verbose. `austral compile hello.aum --entrypoint=Hello:main --output=hello` vs `go build` Etc etc.

The idea is the compiler has a bunch of explicit flags, but the build system (which doesn't exist yet) will have the `foo build`, `foo run` etc. commands and find the files using a package manifest.

Essentially like `cargo` vs. `rustc`. I have a little prototype of the build system in Python but haven't pushed it up yet.

Post reply on HN