3 ms·

This feels a little nitpicky/idealistic, I don't think the post does a good job of conveying why it's more beneficial. > This means that the vertical offset of

This feels a little nitpicky/idealistic, I don't think the post does a good job of conveying why it's more beneficial. > This means that the vertical offset of names stays consistent, regardless of whether a type annotation is present (and how long it is) or not. Why is this necessarily desirable? Strong typing systems have very expressive types, to the point where if something is typed correctly, most of the time my property names are just an alternative casing of the type. Types can be just as expressive or even more expressive than variable names. > The i: Int syntax naturally leads to a method syntax where the inputs (parameters) are defined before the output (result type), which in turn leads to more consistency with lambda syntax (whose inputs are also defined before its output). Maybe this is nice in theory? But `Int` really isn't an output here, and the value being assigned isn't either. Rather this seems more like `f(i, Int, value) -> assignment`. It seems just as arguable that `f(Int, i, value) -> assignment` is appropriate. It seems like some of these are rooted in a "pure mathematical" approach which I can surely appreciate, but ultimately lambda calculus is as much a language as any other programming language, saying "lambda syntax does it this way" doesn't convince me very much.

echelon 6y ago
I've been using Rust a lot recently, which puts names before types and inputs before outputs, and I will absolutely attest to how much mental work is saved by ordering things this way. Skimming or reading Rust comes twice as easy as reading Java, and I do a lot of both. Sure it's an anecdotal report, but I have a real sense here that I feel compelled to report. As other posters have stated, this order makes parsing easier. But I also suggest this benefit extends to your own brain's parsing ability as well. The old order is indirect and suboptimal and makes you think harder.
- kevmo314 6y ago
  Typescript also orders its parameters this way. Between all the Rust and Typescript vs Java and C++ code I've written, I really haven't found that either is better than other, it just seems like a largely arbitrary choice. Making parsing easier for the compiler is a convincing benefit, would have been nice to see that mentioned in the article. I think that's a substantially stronger reason to prefer types after names. I'm not sure if I parse either faster or slower though.
- dntbnmpls 6y ago
  > and I will absolutely attest to how much mental work is saved by ordering things this way. As you yourself noted, personal anecdotes are really not an argument. Someone could say they find Java easier to skim than Rust and we'd be nowhere. Like arguing which end of a boiled egg to crack first. > As other posters have stated, this order makes parsing easier. Programming languages don't exist to make itself easier to parse. They exist to make it easier for programmers to program. Otherwise, we wouldn't have such things like syntactic sugar. Hell we would just write in machine code and do away with assembly and higher level programming language. And parsing is a simple and superficial one time step. Being a tad bit more difficult is not a convincing argument. > But I also suggest this benefit extends to your own brain's parsing ability as well. Based on what evidence? This is the problem with tech evangelism. It has the same problems as religions, lots of claims, no evidence.
  - kelnos 6y ago
    > As you yourself noted, personal anecdotes are really not an argument. Then what is? If you're looking for a randomized sampling of programmers with sufficient sample size, you're not going to find it here. > Programming languages don't exist to make itself easier to parse. No, but a fine example is that of C++: the difficulty in parsing means that if you make a typo, the error message you get might be bizarre and confusing. A compiler for a language that's easier to parse will have a much better idea of the programmer's intent and can provide a much better error message. I find it astounding how often rustc can figure out exactly what I wanted to do and suggest it as a note after the error message. I would think that more-useful error messages pass your test of "make it easier for programmers to program". While we're talking about making it easier to program, "name: Type" make it possible to avoid typing out "Type" at all, and letting the compiler infer it (no, this isn't good and readable to do in all situations, but often it's fine). If you have "Type name" style, and try to add the ability to infer types, you end up with Java's "var" abomination. Regardless, I'm in agreement: I find "name: Type = blah" much easier to read. I read it as "name is a Type that is equal to blah". This also is an improvement in parameter lists, when they're lined up vertically: def foo(bar: String, baz: Int, quux: Foo) I find that much easier to mentally parse to determine parameter order than void foo(String bar, int baz, Foo quux) Worse, imagine that all three parameters were of the same type, requiring a scan to the right to read the names. The important information to me at a glance is the name of the parameter, not its type. As someone who cut his teeth on C and later Java, much later learning Scala and Rust, I immediately liked the style of the latter two much better. Lately I've been doing a lot of Java and get constantly annoyed at the "backwards" order. > This is the problem with tech evangelism. It has the same problems as religions, lots of claims, no evidence. I suppose you could argue that what I've written above is just personal preference, but I see it as a bit stronger than that.
lmm 6y ago
> Maybe this is nice in theory? But `Int` really isn't an output here, and the value being assigned isn't either. Rather this seems more like `f(i, Int, value) -> assignment`. It seems just as arguable that `f(Int, i, value) -> assignment` is appropriate. The point is that you want variable declarations and function signatures to be consistent, so you either write val i : Int def f(x: Int) : String Or Int i String f(Int x) And if you do the latter then you have a confusing syntax because the output type comes before the input type, and it's very hard to do lambdas in a way that looks consistent.
on_and_off 6y ago
>Why is this necessarily desirable? Because rythm makes text easier to parse for the human eye >most of the time my property names are just an alternative casing of the type String or int are very rarely appropriate variable names
- dllthomas 6y ago
  > String or int are very rarely appropriate variable names I very much agree, but that only undermines the point if they are often appropriate type names. In the sorts of languages the GP was trying to restrict that sentence to, I don't think that's the case. I even have some doubts that it's true in C.

echelon 6y ago

I've been using Rust a lot recently, which puts names before types and inputs before outputs, and I will absolutely attest to how much mental work is saved by ordering things this way. Skimming or reading Rust comes twice as easy as reading Java, and I do a lot of both. Sure it's an anecdotal report, but I have a real sense here that I feel compelled to report. As other posters have stated, this order makes parsing easier. But I also suggest this benefit extends to your own brain's parsing ability as well. The old order is indirect and suboptimal and makes you think harder.

kevmo314 6y ago
Typescript also orders its parameters this way. Between all the Rust and Typescript vs Java and C++ code I've written, I really haven't found that either is better than other, it just seems like a largely arbitrary choice. Making parsing easier for the compiler is a convincing benefit, would have been nice to see that mentioned in the article. I think that's a substantially stronger reason to prefer types after names. I'm not sure if I parse either faster or slower though.
dntbnmpls 6y ago
> and I will absolutely attest to how much mental work is saved by ordering things this way. As you yourself noted, personal anecdotes are really not an argument. Someone could say they find Java easier to skim than Rust and we'd be nowhere. Like arguing which end of a boiled egg to crack first. > As other posters have stated, this order makes parsing easier. Programming languages don't exist to make itself easier to parse. They exist to make it easier for programmers to program. Otherwise, we wouldn't have such things like syntactic sugar. Hell we would just write in machine code and do away with assembly and higher level programming language. And parsing is a simple and superficial one time step. Being a tad bit more difficult is not a convincing argument. > But I also suggest this benefit extends to your own brain's parsing ability as well. Based on what evidence? This is the problem with tech evangelism. It has the same problems as religions, lots of claims, no evidence.
- kelnos 6y ago
  > As you yourself noted, personal anecdotes are really not an argument. Then what is? If you're looking for a randomized sampling of programmers with sufficient sample size, you're not going to find it here. > Programming languages don't exist to make itself easier to parse. No, but a fine example is that of C++: the difficulty in parsing means that if you make a typo, the error message you get might be bizarre and confusing. A compiler for a language that's easier to parse will have a much better idea of the programmer's intent and can provide a much better error message. I find it astounding how often rustc can figure out exactly what I wanted to do and suggest it as a note after the error message. I would think that more-useful error messages pass your test of "make it easier for programmers to program". While we're talking about making it easier to program, "name: Type" make it possible to avoid typing out "Type" at all, and letting the compiler infer it (no, this isn't good and readable to do in all situations, but often it's fine). If you have "Type name" style, and try to add the ability to infer types, you end up with Java's "var" abomination. Regardless, I'm in agreement: I find "name: Type = blah" much easier to read. I read it as "name is a Type that is equal to blah". This also is an improvement in parameter lists, when they're lined up vertically: def foo(bar: String, baz: Int, quux: Foo) I find that much easier to mentally parse to determine parameter order than void foo(String bar, int baz, Foo quux) Worse, imagine that all three parameters were of the same type, requiring a scan to the right to read the names. The important information to me at a glance is the name of the parameter, not its type. As someone who cut his teeth on C and later Java, much later learning Scala and Rust, I immediately liked the style of the latter two much better. Lately I've been doing a lot of Java and get constantly annoyed at the "backwards" order. > This is the problem with tech evangelism. It has the same problems as religions, lots of claims, no evidence. I suppose you could argue that what I've written above is just personal preference, but I see it as a bit stronger than that.

lmm 6y ago

> Maybe this is nice in theory? But `Int` really isn't an output here, and the value being assigned isn't either. Rather this seems more like `f(i, Int, value) -> assignment`. It seems just as arguable that `f(Int, i, value) -> assignment` is appropriate. The point is that you want variable declarations and function signatures to be consistent, so you either write val i : Int def f(x: Int) : String Or Int i String f(Int x) And if you do the latter then you have a confusing syntax because the output type comes before the input type, and it's very hard to do lambdas in a way that looks consistent.

on_and_off 6y ago

>Why is this necessarily desirable? Because rythm makes text easier to parse for the human eye >most of the time my property names are just an alternative casing of the type String or int are very rarely appropriate variable names

dllthomas 6y ago
> String or int are very rarely appropriate variable names I very much agree, but that only undermines the point if they are often appropriate type names. In the sorts of languages the GP was trying to restrict that sentence to, I don't think that's the case. I even have some doubts that it's true in C.