Live data from Hacker News

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

soc.me

161–170 of 192 posts

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

#161
post #106

Earlier quoted context omitted.

I think a better (subjective of course) lesson might be to enforce a style. I have been thinking about making a toy compiler (I wanted to write a borrow checker) that treats bad code as an error, solely aimed at numerical code - I have recently had "Scientific Programming in Python for physics etc." inflicted on me. Slight tangent, but I think if Haskell enforced some kind of whitespace a la Python it would be much m…

What do you mean? Whitespace does mean something in Haskell, see http://echo.rsmw.net/n00bfaq.html .

As in Python, whitespace in the form of indentation matters in Haskell.

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

#162

Earlier quoted context omitted.

I'd consider compile time as part of the UI, so in that sense I think we agree. (If the compile is long because the implementation is poor, that needs to be fixed.) Not sure what you mean on the dichotomy. If someone says that a language needs to have X because that will make things simpler for the computer, I say that they are wrong. The goal, the only reasonable goal, is to make things better for humans.

> If the compile is long because the implementation is poor, that needs to be fixed The compile time could be long because the implementation is poor. But it's also possible that the specific requirements do not allow for a significantly faster compile time. That's why the requirements matter. They determine the space of possible implementations. If the requirements eliminate all "fast" implementations, then the resu…

The best example of this problem is probably SPARK, a variant of Ada which permits formal verification.

Its verifiers are awfully finicky, and tuning the parameters (including selecting the most appropriate verifier) can mean the difference between successful completion in a few seconds, and outright non-termination/timeout-with-failure.

It's true that the answer is to have better verifiers, but that's not just a matter of tweaking the verifier code, it's a serious research challenge. One of the most serious problems with formal methods is the ability to scale.

https://en.wikipedia.org/wiki/SPARK_(programming_language)

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

#163
post #56

Earlier quoted context omitted.

I think the vast majority of code that exists in the world today has at most one space between a variable and its type.

There’s a difference between “things that are implemented in popular programming languages” and “things that are implemented in most programming languages”

Yes but you’re clearly making some sort of argument by authority and I think that works both ways. I just don’t see any reason to hold firm beliefs either way on such a trivial issue unless someone has a citation that I’m missing that proves one form increases comprehension or productivity, or reduces bugs.

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

#164

Earlier quoted context omitted.

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.

The claim wasn’t that C++ is Turing complete, that’s trivially true. The claim was that C++’s grammar is Turing complete. I don’t know if that’s exactly the right way to phrase it, but C++’s template expansion stuff is Turing complete.

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

#165

Earlier quoted context omitted.

Metaprogramming in C++ is TC, but it's not what makes C++ TC by itself.

Yes, but it is the difference to other programming languages. In C you cannot encode a Turing machine that is executed by the compiler at compile time . In Brainfuck you cannot encode a Turing machine that is executed by the compiler at compile time . In C++ you can encode a Turing machine that is executed by the compiler at compile time . That is the difference we are discussing here.

>In C you cannot encode a Turing machine that is executed by the compiler at compile time.

But you can get quite close with macros

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

#166

Earlier quoted context omitted.

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

Does Rust allow for fast unoptimised builds then? Perhaps I'd missed that.

Faster, yes. Still lots to do.

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

#167

Earlier quoted context omitted.

Does Rust allow for fast unoptimised builds then? Perhaps I'd missed that.

Fast er , yes. Still lots to do.

You're saying LLVM is slow even when generating code without optimisations?

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

#168

Earlier quoted context omitted.

Fast er , yes. Still lots to do.

You're saying LLVM is slow even when generating code without optimisations?

Yes.

The thing that will massively speed up rustc is the current re-architecting of it. We’re at the point of “few percent here, few percent there” with the current design. These add up over time, of course, but batch compilers are inherently slower than the newer style ones (after an initial compile).

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

#169

Earlier quoted context omitted.

Yes, but it is the difference to other programming languages. In C you cannot encode a Turing machine that is executed by the compiler at compile time . In Brainfuck you cannot encode a Turing machine that is executed by the compiler at compile time . In C++ you can encode a Turing machine that is executed by the compiler at compile time . That is the difference we are discussing here.

>In C you cannot encode a Turing machine that is executed by the compiler at compile time. But you can get quite close with macros

No. You would need the ability to write unbounded loops or unbounded recursion. You don't have that with the C preprocessor.

Yes, you can do a lot with the C preprocessor. You can also do a lot in languages that only have bounded loops and are therefore not Turing complete. You can either express nonterminating computations (Turing completeness), or you can't (still powerful, but dramatically less poweful). This question is binary. There is no fuzziness, there is no approximation, there is no "quite close".

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

#170
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…

I was going to say the same thing about meaning flow. But here's an idea. The OP wants meaning to flow left to right for lambda declarations. Why not have assignment go that way too. "Hello" => x: string Might work. Computer science pseudocode uses notation kind of like that. Also, I understand now why Scala and Rust always seemed clunky to me.

> Computer science pseudocode uses notation kind of like that.

Does it? In my time at the university, assignments in pseudocode were usually written as

  x 
Post reply on HN