Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

soc.me

Post reply on HN
Print view View original

181–190 of 192 posts

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

#181

Post by dllthomas »

iso-8859-1 wrote: post #122
mhh__ wrote: 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 .

Not really relevant to the broader discussion, but Haskell's whitespace sensitivity is defined in terms of automatic insertion of braces and semicolons, and you can write it that way instead if you want. A few people do write Haskell that way (SPJ maybe?) but the community is mostly united around using whitespace. That said, it's useful to know about the braces and semicolons if you're generating Haskell code, because that's often easier. Also occasionally at the GHCI prompt, where it will let you keep things on one line.

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

#182

Post by dllthomas »

on_and_off wrote: post #146
kevmo314 wrote: 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…

>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

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

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

#183

Post by mariodiana »

tomjupiter wrote: post #61
klyrs wrote: post #57

Earlier quoted context omitted.

> It should be this: > int* a; I must disagree... the following sends the wrong message the reader: int* a, b; Though I also agree that dereferencing is best without a space. Perhaps the correct suggestion is to not declare pointers and instances on the same line, but that's a convenience that many seem to enjoy

I think mariodiana is describing a hypothetical language where a and b would both be int-pointers in this case.

If I'm describing a hypothetical language, then I'm actually describing a hypothetical language where you wouldn't declare more than one variable per line.

It's been a long, long time since C required a programmer to declare his variables at the top, and best practice argues that you declare a variable as close to its use as possible. So, there really isn't the same case for multiple variables on one line, whereas it may have been a little more forgivable, once upon a time.

Moreover, when I was first learning C, I learned from an O'Reilly book by Steve Oualline. I remember him saying, when it came to operator precedence, that coding style that relied on the rules was a really bad idea. I think he said something like, "Multiplication and division come before addition and subtraction, and use parentheses for everything else."

My bottom line is C has a little too much "convenience" to it. (Granted, to my taste.) It goes back to my van Rossum comment. I'm against special cases and loosey-goosey stuff.

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

#184

Post by perl4ever »

ogoffart wrote: post #140
mamcx wrote: post #81

Earlier quoted context omitted.

> The difference between Python, C++, Haskell, Common Lisp, Prolog, and SQL isn’t syntax Ok, let's try: Do SQL without the SQL syntax. P.D: I don't think we are that in disagreement ("The syntax just needs to be a decent enough interface to the semantics"), is that the claim of "syntax don't matter" make it look is just an irrelevant aspect of the language. Can be argued how much relevant, but after years on this tra…

> Ok, let's try: Do SQL without the SQL syntax. Select(`my_table`, [`column_A`, `column_B`]) .Filter(`column_C` > 53 && `column_D` == $varA) .Sort_by(`column_C`) There you go: you have the exact semantic as a traditional SQL query (1:1 mapping) and only the syntax is different. Now, one may argue that the syntax is "ugly", less familiar, that the ` are hard to type or whatever, but this is just taste. One simply get…

One thing that I've found myself doing a lot after using SQL for a while is writing SQL to produce SQL. Maybe the syntax could be more oriented towards that, which would not be just a matter of taste.

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

#185

Post by downerending »

lmm wrote: post #117
downerending wrote: post #42

Earlier quoted context omitted.

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.

That's a reasonable point. As long as it's the "good for humans" that driving things, this makes total sense. It's "good for computers" but "bad for humans" that needs to go away these days.

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

#187

Post by Ar-Curunir »

MaxBarraclough wrote: post #167
steveklabnik wrote: post #166

Earlier quoted context omitted.

Fast er , yes. Still lots to do.

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

To add to Steve’s point, Rust adds more checks during debug (non-release) more, which can makes the IR larger. So it’s not always the case that debug mode is faster to compile (though it generally is)

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

#188

Post by djur »

htfu wrote: post #159
djur wrote: post #116

Earlier quoted context omitted.

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

Wouldn’t that argue in favor of val breakfast: “eggs and bacon” = String and not val breakfast: String = “eggs and bacon”

My intention was solely to counter the idea that using ":" to mean "is" or "is a" is somehow inconsistent with written English. I don't think it's always necessary or even desirable to match the use of symbols in programming with English orthography, in any case.

The use of a declaration with initialization as the example here muddies the water. Whatever syntax you use has to work for uninitialized declaration of variables, function arguments, and structure members:

  val breakfast: String
  fun serveBreakfast(breakfast: String)
  struct MealPlan {
    breakfast: String
  }
Declaration with initialization just needs to be consistent with these.

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

#189

Post by nyanpasu64 »

littlestymaar wrote: post #139
nyanpasu64 wrote: post #82

Earlier quoted context omitted.

In Rust, you can write: let x = 5i32; Sadly it's nowhere near as elegant for string literals.

> Sadly it's nowhere near as elegant for string literals. What do you mean? For string literals you just do let foo= "bar"; and that's it. BTW, in Rust you can omit most variable type annotations since the compiler is able to infer them. You have to give type annotations to functions though.

I meant turning string literals into heap-allocated strings.

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

#190

Post by littlestymaar »

nyanpasu64 wrote: post #189
littlestymaar wrote: post #139

Earlier quoted context omitted.

> Sadly it's nowhere near as elegant for string literals. What do you mean? For string literals you just do let foo= "bar"; and that's it. BTW, in Rust you can omit most variable type annotations since the compiler is able to infer them. You have to give type annotations to functions though.

I meant turning string literals into heap-allocated strings.

Ah yes, in this case it's indeed a bit more verbose:

let foo= "bar".to_string();

It's on purpose though, because Rust likes to make heap allocations explicit, and I find it fine to be honest, but you mileage may vary.

Post reply on HN