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…
Language Design: Use 'ident: Type' not 'Type ident'
111–120 of 192 posts
Re: Language Design: Use 'ident: Type' not 'Type ident'
#112Re: Language Design: Use 'ident: Type' not 'Type ident'
#113This 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…
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'
#114Re: Language Design: Use 'ident: Type' not 'Type ident'
#115Earlier 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.
[string] $foo = "foo"
Re: Language Design: Use 'ident: Type' not 'Type ident'
#116Earlier 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.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#117A 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 .
Re: Language Design: Use 'ident: Type' not 'Type ident'
#118Earlier 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".
Re: Language Design: Use 'ident: Type' not 'Type ident'
#119Earlier 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.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#120Strong 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…
> 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.