I still didn't see in the documentation what's supposed to happen in case of overflow..
[dead]
The Austral Programming Language
31–40 of 124 posts
Re: The Austral Programming Language
#32This is cool but everything is too verbose. `austral compile hello.aum --entrypoint=Hello:main --output=hello` vs `go build` Etc etc.
On the contrary, I like it when the interface to my tools err on the side of precision at the cost of verbosity. I can always write a shell script or Makefile that does all the boring stuff once I've learned what the inputs mean, but if a tool only provides an overly simplified interface, it is much less obvious what it's doing, or what the other options might be, if any. What does `go build` do? What files does it i…
You might, but I don't. In the argument `--entrypoint=Hello:main`, where does `Hello` come from? Is it some root module? What about `main`, is that some default, or the name of a file without an extension? This strikes me as just enough verbosity to be confusing, and not enough to be explicit.
Re: The Austral Programming Language
#33I can understand the intent behind most of the design 'no's - except for subtyping. why is this a problem? I was just looking at the union/sum distinction and the same thing came up. maybe this is a good learning moment.
Type systems invariably have soundness issues when subtyping is allowed. They might've fixed it in the last couple years, but as an example I'm pretty sure Java and C# both have bugs where some methods should be co/contra-variant and others should not but the language only supports subtyping acting one way or the other for the whole type. For a concrete example:
1. Suppose Civic is a subtype of Car
2. Suppose you have a List
3. Suppose a method asks for a List
4. You can "clearly" provide that original list of civics because every single thing in the list is a Car, and it's a list of those things, so it adheres to what the method seems to want -- maybe the method computes average cylinder count or something.
5. Everything we just described is fine and dandy so long as the list itself is immutable (the individual cars could still be mutable safely), but running some of the mutable list methods will cause runtime crashes and segfaults. E.g., if you append a toyota camry to the list then you've somehow snuck a camry into the original List.
In that example, some of the methods would be safe if you interpreted a List as a List (like grabbing the car at a particular index and finding that the particular car is a civic), but others require the subtyping relationship to go the other direction (e.g., if you interpreted the List as a List and appended a BlueCivic then the invariants expected by `append` work in both cases).
That sort of thing just scratches the tip of the iceberg, and as a rule of thumb all your type systems are unsound, _especially_ if they involve subtyping. Things you would hope would be caught at compile-time are punted off to scary runtime heisenbugs that might not be detected for ages. The type system is helpful at reducing errors but woefully incomplete even for the things it's supposed to catch.
Re: The Austral Programming Language
#34This 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.
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?
Re: The Austral Programming Language
#35This is cool but everything is too verbose. `austral compile hello.aum --entrypoint=Hello:main --output=hello` vs `go build` Etc etc.
On the contrary, I like it when the interface to my tools err on the side of precision at the cost of verbosity. I can always write a shell script or Makefile that does all the boring stuff once I've learned what the inputs mean, but if a tool only provides an overly simplified interface, it is much less obvious what it's doing, or what the other options might be, if any. What does `go build` do? What files does it i…
Feel free to invoke "go tool compile" manually. "go build" is just a frontend
Re: The Austral Programming Language
#36This 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.
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 progra…
Looks more like Ada to me.
Re: The Austral Programming Language
#37Earlier quoted context omitted.
For every person that says this, there's 5 people that say the opposite.
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, pe…
>the microscopic savings in key presses are just really such a strange thing to even debate
It's about readability
Re: The Austral Programming Language
#38> No arithmetic precedence.
Interesting. I've wondered about this when making an expression parser. Obviously it makes parsing way easier and mistaken precedence is often a cause of bugs (especially in C where some of the operator precedence is plain wrong). But on the other hand that's got to be quite annoying surely?
Re: The Austral Programming Language
#39> No arithmetic precedence. Interesting. I've wondered about this when making an expression parser. Obviously it makes parsing way easier and mistaken precedence is often a cause of bugs (especially in C where some of the operator precedence is plain wrong). But on the other hand that's got to be quite annoying surely?
It really depends on how you implement it. I don't think that requiring parentheses in something like a+b*c is annoying, but if they also prohibit a+b+c, that's a different story.
Re: The Austral Programming Language
#40Earlier quoted context omitted.
On the contrary, I like it when the interface to my tools err on the side of precision at the cost of verbosity. I can always write a shell script or Makefile that does all the boring stuff once I've learned what the inputs mean, but if a tool only provides an overly simplified interface, it is much less obvious what it's doing, or what the other options might be, if any. What does `go build` do? What files does it i…
You might, but I don't. In the argument `--entrypoint=Hello:main`, where does `Hello` come from? Is it some root module? What about `main`, is that some default, or the name of a file without an extension? This strikes me as just enough verbosity to be confusing, and not enough to be explicit.
Right above that line in the docs is a pretty clear view of 'Hello' and 'main'. Its a file "hello.aum" which declares a module 'Hello' with a function called 'main'. You compile the file to be an executable by giving it function to run as the entrypoint. This really couldn't be clearer I dont think.