Live data from Hacker News

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

soc.me

111–120 of 192 posts

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

#111
post #58

Earlier quoted context omitted.

> In 2020, not sure we should care that much about how hard compilers have to work to achieve this. That's not right. Long compile times are a real issue for some programming languages even today (Rust and C++). > Computers and software are here to support us--we're not here to support them. A false dichotomy, and not a perspective that offers any insight. Sometimes a low-level language is appropriate, and sometimes…

C++ is stuck in this trap where because it's slow to compile, the compiler maintainers increase the amount of optimizations the compiler does to make it faster. Which of course makes the compiler even slower. Which motivates them to increase the amount of optimizations. Which makes the compiler yet slower. I feel part of the problem with rust is it doesn't have quick and dirty mode thats fast and a production ready m…

C++ debug builds (i.e. without optimizations) are not that much faster in my experience. So it's not optimizations that are the culprit.

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

#112
post #85

Earlier quoted context omitted.

The checks are not the most expensive part of compiling Rust.

What is it then?

The codegen is. This is partially because the IR passed to LLVM is not the best, but it’s also not terrible.

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

#113
post #10
post #7

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…

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 e…

> 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.

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

#114
The most important result of this design is that the syntax unambiguously determines whether you are referencing the type or value axis, and enables you to split them accordingly. Having worked with Scala and been forced to return to a C-style language, this is probably one of Scala's most overlooked features.

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

#115
post #20

Earlier quoted context omitted.

Ah, C not originally having typedefs explains why the syntax wasn't thrown out as too annoying to begin with. Syntax creep I guess. An easy solution to the problem would be to do what e.g. Haskell does where case-sensitivity determines a type name. For better or worse, C didn't do that.

In Dylan all types were delimited with . Personally I always found that very aesthetically pleasing.

Same in Powershell except they use square brackets

[string] $foo = "foo"

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

#116
post #88

Earlier quoted context omitted.

But a colon is also often used to indicate a mapping of names or categories to value. For instance: Breakfast: eggs and bacon Lunch: falafel sandwich Dinner: BBQ pork and slaw The type of the variable is the "explanation" here. val x: String "x, which is a String" val x: String = "hello" "x, which is a String, is initialized with 'hello'"

Your examples have the things on the right and the type on the left, and then used it to describe why examples on the left and [types] on the right makes sense... If anything you've just argued that String: x, y is a preferable declaration style.

The point of the list isn't to say "eggs and bacon is a kind of breakfast", it's to say "breakfast is eggs and bacon". It's "name: details about name", not "type: instance".

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

#117

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…

Arguably a programming language is ultimately a user interface, and the more intuitive the interface, the better. In 2020, not sure we should care that much about how hard compilers have to work to achieve this. Computers and software are here to support us --we're not here to support them .

A parser tends to get confused in the same places where a less experienced human would get confused. Making a language that's easy to parse dovetails with making one that's easy to read.

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

#118
post #88

Earlier quoted context omitted.

But a colon is also often used to indicate a mapping of names or categories to value. For instance: Breakfast: eggs and bacon Lunch: falafel sandwich Dinner: BBQ pork and slaw The type of the variable is the "explanation" here. val x: String "x, which is a String" val x: String = "hello" "x, which is a String, is initialized with 'hello'"

What's the point of the 'val' keyword? It reminds me of Visual Basic's "Dim x As String".

Having a keyword for variable initialization makes parsing easier and less ambiguous. "let", "var", etc. are also used for this purpose, but I was going along with the example.

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

#119

Earlier quoted context omitted.

It's Turing complete because it could simulate a Turing machine, not because of metaprogramming. The language brainfuck is Turing complete, for example.

Checking if a Brainfuck program is well formed (i.e. can be run) is a linear time operation. In C++ this can take forever. They have different complexities.

The original comment was about Turing completeness, and it was defined incorrectly. I was giving an example of a dead-simple language that was Turing complete, because the claim was that metaprogramming made C++ Turing complete.

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

#120
post #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…

> 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.

You can write it as

    val x = "hello" : String
if you prefer. In fact that's a great advantage of this syntax: any expression can be optionally ascribed with a type. If you write the type first then it becomes too intrusive (and too much like a typecast, which absolutely should be intrusive).

> And human-language wise, colon is "description: explanation"

True enough, but what other syntax would fit in postfix position? In human language we'd probably use commas ("Bob, chef"), but that seems a bit too ambiguous in a programming language.

Post reply on HN