Live data from Hacker News

Language Design: Use 'ident: Type' not 'Type ident'

soc.me

31–40 of 192 posts

Re: Language Design: Use 'ident: Type' not 'Type ident'

#31
post #25

Language Design: This stuff doesn't matter that much. Focus on more important things. Syntax isn't unimportant, but don't waste energy on trivial matters like these. Just pick something and people will get used to it. Focus on the semantics of your language - that's what really matters.

>Syntax isn't unimportant #104#101#108#108#111,[Space]world![Space][Space][Tab][Space][Space][Tab][Space][Space][Space][LF] [Tab][LF][Space][Space] [Space][Space][Space][Tab][Tab][Space][Space][Tab][Space][Tab][LF] [Tab][LF][Space][Space] [Space][Space][Space][Tab][Tab][Space][Tab][Tab][Space][Space][LF] [Tab][LF][Space][Space] [Space][Space][Space][Tab][Tab][Space][Tab][Tab][Space][Space][LF] [Tab][LF][Space][Space]…

I didn't say "syntax doesn't matter, pick any ridiculous thing you want". That's what I mean by "not unimportant", though I admit it's not exactly clear that's what I meant. My point is that within the space of reasonable, comprehensible syntaxes, there are no demonstrable differences worth arguing about.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#32

I’m surprised this didn’t touch on the IDE autocomplete suggesting variable names. In Java you would have something like `LocationBuilder locationBuilder` which makes users just tab complete the variable name to quickly have access to a variable. The argument in this article was about names being prioritized and I think forcing no auto completion on a variable name would force the developer to be slightly more descri…

Maybe a little orthogonal -- I could easily imagine IDEs still doing something like transforming the input ": FooType" into "fooType: FooType" w/ the name selected and ready to be tabbed past.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#33

Earlier quoted context omitted.

That seems to be the main problem. Otherwise it’s just something to get used to in my view.

I think it also makes more human sense. The parameter name should in some sense be telling you more than just the type. Like "size: Size" is kind of repetitive.

I don't know. Seems programming languages are cryptic no matter what.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#34
I disagree. The syntax design should flow from the design of the language itself and whether or not you use prefix or postfix notation for type annotations depends heavily on what makes sense within the semantics of the type system.

Design a language before you design a syntax.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#35

I’m surprised this didn’t touch on the IDE autocomplete suggesting variable names. In Java you would have something like `LocationBuilder locationBuilder` which makes users just tab complete the variable name to quickly have access to a variable. The argument in this article was about names being prioritized and I think forcing no auto completion on a variable name would force the developer to be slightly more descri…

In Kotlin, IntelliJ has no problem with this. As you type a new value: `val id`, and you have `IdentName` defined in scope, the value `identName` is suggested automatically.

Not all IDEs are the same, though, and I'm not sure how sophisticated this feature was to implement.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#36

A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…

It's possible to argue here that the problem is not so much the order of type-then-name but the overloaded meanings of * and < at the grammar level.

More generally this falls into a discussion of context-specific vs context-free grammars. Of which C++ falls into the former, Java falls into the latter.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#37

Earlier quoted context omitted.

I think it also makes more human sense. The parameter name should in some sense be telling you more than just the type. Like "size: Size" is kind of repetitive.

I don't know. Seems programming languages are cryptic no matter what.

They are not cryptic. They are trying really hard to come up with good syntaxes and semantics actually. I think that modern programming languages tend to have very clean syntaxes.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#38

I’m surprised this didn’t touch on the IDE autocomplete suggesting variable names. In Java you would have something like `LocationBuilder locationBuilder` which makes users just tab complete the variable name to quickly have access to a variable. The argument in this article was about names being prioritized and I think forcing no auto completion on a variable name would force the developer to be slightly more descri…

JetBrains' autocomplete does pretty well either way, you can be similarly lazy in Scala or Kotlin.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#39

A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…

`int * A` and `A * int` both seem ambiguous unless a) you require "int-pointer" naming instead of "pointer-int", and/or b) you have a separator (like the title uses) so this becomes `A * B` vs `A: * B` which is indeed unambiguous but in a very different way.

i.e. without extra rules you can't tell either way, so it comes down to the extra rules. `A * B` is unambiguous for type-before-name if you require "pointer-int" since it would need to be `* A B` for A to be a type.

(quite possibly there are counter-examples when you get into weirder corners, but my point is that it's not as simple as presented)

Re: Language Design: Use 'ident: Type' not 'Type ident'

#40
Strong disagreement here. "type ident" flows with the data during assignment, doesn't confuse the infix operators, and doesn't misuse ":" from a human-language standpoint.

For example:

  val x: String = "hello"
The type interrupts the flow of data from "hello" to x, so one thing that pops into mind is that this is typecasting the value to a string before storing it. Nope.

Another possibility I instinctively see this as is doing a comparison and assigning the result (either true or false in this case) to x. Nope.

And human-language wise, colon is "description: explanation" (or more generally: general to specific), which actually fits this syntax better:

  val String: x = "hello"
...and at that point, just remove the extraneous stuff:

  String x = "hello"
Post reply on HN