10 ms·

> Onyx is strictly type-checked. However, the type-inference systems in Onyx usually allow you to omit types. > > x := 10 I... Why is this a feature in ever

by moss2 3y ago

> Onyx is strictly type-checked. However, the type-inference systems in Onyx usually allow you to omit types. > > x := 10 I... Why is this a feature in every new language? Can't we have a language that is more verbose and explicit, not less? I'd love it if named parameters were mandatory, not optional. (Named parameters is when you name parameters/arguments you pass on to functions, like you can do in python and groovy: `foobar(arg1: 123, arg2: 'hello')`) Most of my problems I run into is due to implicit behaviour that no one bothers to explain. In Onyx here, having type-inference means I now how to remember that x := 10 means x will be a signed 32-bit integer instead of, you know, the code that I'm writing remembering it for me. And I'm just guessing here. Maybe x is a double. Or unsigned since its initial value isn't negative. Or maybe it was signed 32-bit integer but the Onyx developers changed it to 128-bit long long for version 666.0.0. The point is I have to look this stuff up or remember it instead of, you know, it being right there. I don't even know what you gain by doing this. Less code is less messy but also hides a lot of information from you. Hiding information should be something an IDE does, not the language itself. Thank you for reading my rant.

otabdeveloper4 3y ago
> Can't we have a language that is more verbose and explicit, not less? What's wrong with the old verbose languages?
Joker_vD 3y ago
Reasonably, x in this case would be generic/polymorphic (just as 10 is a generic/polymorphic constant) with its type bounded by the equivalent of Num trait. Haskell (and to some extent Go) gets it right. Also reasonably, each source file should start with declaring the version of a language it was written in, so that e.g. Onyx 666.0 changing its default integer width wouldn't affect the code in the file with "///OnyxVer=665.0" at the top of it. Now that is a feature I would like every new language to have.
giraffe_lady 3y ago
The other side of "why do I have to remember this when I could write it" is "why do I have to write it when the compiler already knows it?" I love complete inferred type systems, using one has completely changed how I think about types and what I expect from a programming language. I feel ill every time I have to use go or typescript. Like I am teaching the compiler how to compile. This is not my job, it's a waste of time and energy, it should already know. Things like rescript and ocaml are where my attention is going for typed languages in the future.
cobbal 3y ago
Same reason we don't have to type `(((2int + 2int)int) / 8int)int`. Type inference already exists in any ALGOL-like. Modern languages just tend to remove the arbitrary restriction that variables are the places where types must be added.
- Joker_vD 3y ago
  Well, technically int(int(int(2) +::<int> int(2)) /::<int> int(8)) We must disambiguate integer- and float-point arithmetic operators for sure.
- dragonwriter 3y ago
  > Same reason we don't have to type `(((2int + 2int)int) / 8int)int`. Type inference already exists in any ALGOL-like. That's not why you don't have to do that. Many (most statically typed?) Algol-likes have strict types for literals (e.g., 2 is always a signed int, if you if you want specifically unsigned you might say 2u and if you want a double you say 2.0, and if you want a single-precision float you say 2.0f, or something) and strict rules at how math between them works and what types it produces, this has been true since long before tyoe inference became common, and is why you don't have to say 2int+2int — 2 is syntactically defined as int. There is no inference
  - goto11 3y ago
    It is still type inference though. If 2 is an int, the compiler perform type inference to figure out that the expression 2 + 2 is also an int. It is just that traditional languages only use type inference for expressions, not declarations.
    - dllthomas 3y ago
      It's type propagation. Which can be seen as a form of inference or not, depending just where you draw the line.
      - gpderetta 3y ago
kstrauser 3y ago
I see what you mean, but do appreciate the quality of life improvement of such things. In your example, that looks a lot like a native int. It might be something different, but 99.9% of the time it’s going to be an int. I think it’s reasonable to say that unless told otherwise, a thing that looks like an int is an int. Same with `x:=3.14`. That could be a long double, but it’s vastly more likely to be a plain old float. Why not make that the default? An extra advantage I see is that non-default types stand out. At a glance at the code, `x:=10` is the most common int type. It’s plain, unadorned. It’s the usual, boring thing. Things that are less common stand out: oh, this is unsigned for some reason. Guess I should see why. I like the pattern where unusual things are easier to visually scan for. But at the end of the day, darn it, compiler, you know very well that I mean 3.14 to be a float. Stop making me say so each time!
- moss2 3y ago
  I can't remember which language, but there is one where every number is a double and there is no int type. Is Onyx like that? I don't know. It would take me maybe two minutes to look up. The point is I have to look it up to be certain when that certainty could be part of the language.
goto11 3y ago
But that would only help you if you assign the numeric literal directly to a variable. If you use it in an expression like `foo(10)` or `10 * bar` you would still not see the numeric type specified. So if you want the type to be always explicit, the type specifier should be coupled with the literal like `10[i32]` or similar, so you can write `foo(10[i32])`.
- moss2 3y ago
  I might not be against that... Assigning variables or calling methods (when you discard the return value) would look the same as is typical in many languages: int x = foo(); // foo() returns int but we can see that in what type x is foo(); // we don't care what foo() returns Named variables in method calls would have to have the type so as to not hide what type a method-as-parameter returns: CoolObject cool_obj = bar(int arg1: foo())
justinpombrio 3y ago
Well on the other end of the extreme we had Java, which had an awful lot of this: HashMap<String, List<int>> hashmap = new HashMap<String, List<int>>(); Latest Java lets you omit the left type annotation (I hear, haven't tried it): var hashmap = new HashMap<String, List<int>>(); And in many languages the type parameters on the right can also be inferred --- so long as later code determines them --- so you get something like: var hashmap = new HashMap(); Hopefully we can all agree that the first option is needlessly verbose. There's more contention between the last two, I think. My preference would be to do some type inference, but maintain the property that you can tell the type of every expression without looking outside of it (except perhaps for an immediate enclosing function call). This requires, for example: - The third option isn't allowed, you need to write the second option instead. - You must annotate function argument types. - In Rust, you couldn't write `.collect()`, you'd instead write `.collect::<Vec<_>>()`. - The `x := 10` example is actually somewhat ambiguous. If the language fixes the type of `10` then `x := 10` is legal. If it's an unspecified type (as is typically the case), you'd have to write the type down.
- stcg 3y ago
  > The `x := 10` example is actually somewhat ambiguous. If the language fixes the type of `10` then `x := 10` is legal. If it's an unspecified type (as is typically the case), you'd have to write the type down. For that case I like a type signifier as part of the number literal expression, like this: `x := 10f32` or `x := 10i32`.
- Nevermark 3y ago
  I have often used a Java utility class of static inferring generic constructors: public static <E> ArrayList<E> newArrayList() { return new ArrayList<E>(); } public static <K,T> HashMap<K,T> newHashMap() { return new HashMap<K,T>(); } So code can look simpler, but just as clear: import static GenericConstructors.*; ... ArrayList<String> names = newArrayList(); HashMap<String, List<int>> hashmap = newHashMap() The "x := 10" example is one reason it feels safer to me to declare the variable type, and infer the constructor types, than the other way around. -- What would resolve this whole issue is standardized editor/IDE visualization support for showing all inferred types, just one toggle button/key away. Inferred types simplify writing code. But when reading code, why should we have to mentally emulate the language's inference algorithm? It is, by definition, supposed to be automating that for us.
mrweasel 3y ago
No no, I with you this, I hate that Go allows this as well. If you have a type system, then force the user to specify exactly what type they want something to be. It's completely reasonable in my mind to write var x float32 = 10, the compiler can then deal with adding the .0 if it wants.
thefaux 3y ago
Imagine if you had to write english sentences annotating every noun and verb "(Bob: Person) (went: Verb) to the (beach: Place)." That's what mandatory type annotation feels like to me.
wharvle 3y ago
I think it’s fine if and only if there are 1st party tools for editors to provide hints about the type the language will infer. If I can mouse over and see the type it thinks the var is, and see static analysis errors if I try to treat it as the wrong type without casting first, then it’s fine. That is, as long as the core tools for the language provide that info somewhere that’s not more than barely more hidden than explicitly typing it out, I think that’s Ok.
dragonwriter 3y ago
> Why is this a feature in every new language? Because superfluous type checker incantations are, aside from breaking up flow of thought when writing code, annoying visual noise when reading it. > I'd love it if named parameters were mandatory, not optional. Named parameters are a different thing than type incantations, and I agree that it would be good for any non-operator function that takes more than 1 argument to require named parameters.
- xigoi 3y ago
  I don't see the value of, say, dot_product(vector1=x, vector2=y) compared to dot_product(x, y).
  - dragonwriter 3y ago
    > I don't see the value of, say, dot_product(vector1=x, vector2=y) compared to dot_product(x, y). I would include functions which implement (especially unary/binary) mathematical operators where the operands either are interchangeable or have a clear conventional order, in languages where you cannot make them actual operators, within the exception for operators.
    - kstrauser 3y ago
      My personal rule of thumb is 3-ish. More than that, and I switch from positional to named args. I appreciate how Python can let you insist on named-only args for when you want to remove the temptation to use a long list of positional args.
  - Leherenn 3y ago
    2 parameters are usually fine, but then I have seen quite a few bugs with atan2(y,x).
- rstat1 3y ago
  >Because superfluous type checker incantations are, aside from breaking up flow of thought when writing code, annoying visual noise when reading it. I disagree. Implicit typing for the most part makes things harder read. The less I have guess about what type something is the better. I never use stuff like "var" or "auto", unless forced to for this very reason.
gpderetta 3y ago
Programming is not unlike writing on an human language. Sometimes you use a proper noun, sometimes a pronoun sometimes you omit subject or object completely, even in rigorous technical writing. There is no hard rule, learning to communicate unambiguously and efficiently it is an art.
bobbylarrybobby 3y ago
Eh, rust has pretty solid type inference (sounds like you'd hate it), but with the rust analyzer extension, you can get inlay hints that tell you the inferred type of every variable, so you're never actually left wondering. Seems like the best of both worlds.
- moss2 3y ago
  I'd prefer the other way around. If the language was verbose but its tools (IDEs, analyzer extension) hid redundant info from you.

by moss2 3y ago

otabdeveloper4 3y ago

> Can't we have a language that is more verbose and explicit, not less? What's wrong with the old verbose languages?

Joker_vD 3y ago

Reasonably, x in this case would be generic/polymorphic (just as 10 is a generic/polymorphic constant) with its type bounded by the equivalent of Num trait. Haskell (and to some extent Go) gets it right. Also reasonably, each source file should start with declaring the version of a language it was written in, so that e.g. Onyx 666.0 changing its default integer width wouldn't affect the code in the file with "///OnyxVer=665.0" at the top of it. Now that is a feature I would like every new language to have.

giraffe_lady 3y ago

The other side of "why do I have to remember this when I could write it" is "why do I have to write it when the compiler already knows it?" I love complete inferred type systems, using one has completely changed how I think about types and what I expect from a programming language. I feel ill every time I have to use go or typescript. Like I am teaching the compiler how to compile. This is not my job, it's a waste of time and energy, it should already know. Things like rescript and ocaml are where my attention is going for typed languages in the future.

cobbal 3y ago

Same reason we don't have to type `(((2int + 2int)int) / 8int)int`. Type inference already exists in any ALGOL-like. Modern languages just tend to remove the arbitrary restriction that variables are the places where types must be added.

Joker_vD 3y ago
Well, technically int(int(int(2) +::<int> int(2)) /::<int> int(8)) We must disambiguate integer- and float-point arithmetic operators for sure.
dragonwriter 3y ago
> Same reason we don't have to type `(((2int + 2int)int) / 8int)int`. Type inference already exists in any ALGOL-like. That's not why you don't have to do that. Many (most statically typed?) Algol-likes have strict types for literals (e.g., 2 is always a signed int, if you if you want specifically unsigned you might say 2u and if you want a double you say 2.0, and if you want a single-precision float you say 2.0f, or something) and strict rules at how math between them works and what types it produces, this has been true since long before tyoe inference became common, and is why you don't have to say 2int+2int — 2 is syntactically defined as int. There is no inference
- goto11 3y ago
  It is still type inference though. If 2 is an int, the compiler perform type inference to figure out that the expression 2 + 2 is also an int. It is just that traditional languages only use type inference for expressions, not declarations.
  - dllthomas 3y ago
    It's type propagation. Which can be seen as a form of inference or not, depending just where you draw the line.
    - gpderetta 3y ago

kstrauser 3y ago

I see what you mean, but do appreciate the quality of life improvement of such things. In your example, that looks a lot like a native int. It might be something different, but 99.9% of the time it’s going to be an int. I think it’s reasonable to say that unless told otherwise, a thing that looks like an int is an int. Same with `x:=3.14`. That could be a long double, but it’s vastly more likely to be a plain old float. Why not make that the default? An extra advantage I see is that non-default types stand out. At a glance at the code, `x:=10` is the most common int type. It’s plain, unadorned. It’s the usual, boring thing. Things that are less common stand out: oh, this is unsigned for some reason. Guess I should see why. I like the pattern where unusual things are easier to visually scan for. But at the end of the day, darn it, compiler, you know very well that I mean 3.14 to be a float. Stop making me say so each time!

moss2 3y ago
I can't remember which language, but there is one where every number is a double and there is no int type. Is Onyx like that? I don't know. It would take me maybe two minutes to look up. The point is I have to look it up to be certain when that certainty could be part of the language.

goto11 3y ago

But that would only help you if you assign the numeric literal directly to a variable. If you use it in an expression like `foo(10)` or `10 * bar` you would still not see the numeric type specified. So if you want the type to be always explicit, the type specifier should be coupled with the literal like `10[i32]` or similar, so you can write `foo(10[i32])`.

moss2 3y ago
I might not be against that... Assigning variables or calling methods (when you discard the return value) would look the same as is typical in many languages: int x = foo(); // foo() returns int but we can see that in what type x is foo(); // we don't care what foo() returns Named variables in method calls would have to have the type so as to not hide what type a method-as-parameter returns: CoolObject cool_obj = bar(int arg1: foo())

justinpombrio 3y ago

Well on the other end of the extreme we had Java, which had an awful lot of this: HashMap<String, List<int>> hashmap = new HashMap<String, List<int>>(); Latest Java lets you omit the left type annotation (I hear, haven't tried it): var hashmap = new HashMap<String, List<int>>(); And in many languages the type parameters on the right can also be inferred --- so long as later code determines them --- so you get something like: var hashmap = new HashMap(); Hopefully we can all agree that the first option is needlessly verbose. There's more contention between the last two, I think. My preference would be to do some type inference, but maintain the property that you can tell the type of every expression without looking outside of it (except perhaps for an immediate enclosing function call). This requires, for example: - The third option isn't allowed, you need to write the second option instead. - You must annotate function argument types. - In Rust, you couldn't write `.collect()`, you'd instead write `.collect::<Vec<_>>()`. - The `x := 10` example is actually somewhat ambiguous. If the language fixes the type of `10` then `x := 10` is legal. If it's an unspecified type (as is typically the case), you'd have to write the type down.

stcg 3y ago
> The `x := 10` example is actually somewhat ambiguous. If the language fixes the type of `10` then `x := 10` is legal. If it's an unspecified type (as is typically the case), you'd have to write the type down. For that case I like a type signifier as part of the number literal expression, like this: `x := 10f32` or `x := 10i32`.
Nevermark 3y ago
I have often used a Java utility class of static inferring generic constructors: public static <E> ArrayList<E> newArrayList() { return new ArrayList<E>(); } public static <K,T> HashMap<K,T> newHashMap() { return new HashMap<K,T>(); } So code can look simpler, but just as clear: import static GenericConstructors.*; ... ArrayList<String> names = newArrayList(); HashMap<String, List<int>> hashmap = newHashMap() The "x := 10" example is one reason it feels safer to me to declare the variable type, and infer the constructor types, than the other way around. -- What would resolve this whole issue is standardized editor/IDE visualization support for showing all inferred types, just one toggle button/key away. Inferred types simplify writing code. But when reading code, why should we have to mentally emulate the language's inference algorithm? It is, by definition, supposed to be automating that for us.

mrweasel 3y ago

No no, I with you this, I hate that Go allows this as well. If you have a type system, then force the user to specify exactly what type they want something to be. It's completely reasonable in my mind to write var x float32 = 10, the compiler can then deal with adding the .0 if it wants.

thefaux 3y ago

Imagine if you had to write english sentences annotating every noun and verb "(Bob: Person) (went: Verb) to the (beach: Place)." That's what mandatory type annotation feels like to me.

wharvle 3y ago

I think it’s fine if and only if there are 1st party tools for editors to provide hints about the type the language will infer. If I can mouse over and see the type it thinks the var is, and see static analysis errors if I try to treat it as the wrong type without casting first, then it’s fine. That is, as long as the core tools for the language provide that info somewhere that’s not more than barely more hidden than explicitly typing it out, I think that’s Ok.

dragonwriter 3y ago

> Why is this a feature in every new language? Because superfluous type checker incantations are, aside from breaking up flow of thought when writing code, annoying visual noise when reading it. > I'd love it if named parameters were mandatory, not optional. Named parameters are a different thing than type incantations, and I agree that it would be good for any non-operator function that takes more than 1 argument to require named parameters.

xigoi 3y ago
I don't see the value of, say, dot_product(vector1=x, vector2=y) compared to dot_product(x, y).
- dragonwriter 3y ago
  > I don't see the value of, say, dot_product(vector1=x, vector2=y) compared to dot_product(x, y). I would include functions which implement (especially unary/binary) mathematical operators where the operands either are interchangeable or have a clear conventional order, in languages where you cannot make them actual operators, within the exception for operators.
  - kstrauser 3y ago
    My personal rule of thumb is 3-ish. More than that, and I switch from positional to named args. I appreciate how Python can let you insist on named-only args for when you want to remove the temptation to use a long list of positional args.
- Leherenn 3y ago
  2 parameters are usually fine, but then I have seen quite a few bugs with atan2(y,x).
rstat1 3y ago
>Because superfluous type checker incantations are, aside from breaking up flow of thought when writing code, annoying visual noise when reading it. I disagree. Implicit typing for the most part makes things harder read. The less I have guess about what type something is the better. I never use stuff like "var" or "auto", unless forced to for this very reason.

gpderetta 3y ago

Programming is not unlike writing on an human language. Sometimes you use a proper noun, sometimes a pronoun sometimes you omit subject or object completely, even in rigorous technical writing. There is no hard rule, learning to communicate unambiguously and efficiently it is an art.

bobbylarrybobby 3y ago

Eh, rust has pretty solid type inference (sounds like you'd hate it), but with the rust analyzer extension, you can get inlay hints that tell you the inferred type of every variable, so you're never actually left wondering. Seems like the best of both worlds.

moss2 3y ago
I'd prefer the other way around. If the language was verbose but its tools (IDEs, analyzer extension) hid redundant info from you.