5 ms·

Let's put it this way... when you absolutely must syntax highlight code in order to be able to explain Rust syntax.. it's ugly. Let's just go with a really con

Let's put it this way... when you absolutely must syntax highlight code in order to be able to explain Rust syntax.. it's ugly. Let's just go with a really contrived and stupid example... "pub fn". Would it really have killed them to spell it out? Why do we need 'fn'? Functions with a return type (i.e. `fn add(a: i32, b:i32) -> i32`) is just not easy to read. Yes, I'm aware that someone here will find this 'beautifully terse and concise', as well as easy to read. But without syntax highlighting, it's just a jumble of characters to me. We read code more than we write, so clarity of code should be the goal of any 'modern' languages these days.

JoshTriplett 4y ago
Brevity isn't always a bug even when optimizing for reading rather than writing. Spending extra characters spelling out `function` doesn't necessarily make code more readable. I do, in general, think keywords should not be abbreviated. We have "return" rather than "ret", "continue" rather than "cont", and so on. This wasn't always the case; ancient (pre-1.0) versions of Rust had a lot more abbreviation in the language and library than current versions.
- geoelectric 4y ago
  I think there's a good reason for the function keyword to be abbreviated. We know that when people read lines of text, they pay a lot of attention to the beginning and the end and comparatively less attention to the middle. One result is that lines with common prefixes tend to blur together. To get around this, you want the reader to encounter the unique portion of the line ASAP, which makes it desirable that any kind of necessary prefix be brief. Upshot is you want the function signature to be what you see as you scan down the left side of the page, so it does make sense to keep the function keyword particularly concise.
Gigachad 4y ago
There has to be a more objective way to rank uglyness. The example function you provided looks perfectly fine to me. I don't see how syntax highlighting makes it any better.
- deafpolygon 4y ago
  I did mention it will look perfectly fine to someone here. [ and what better, to someone's nickname is Gigachad :) ] But if you had a sea of functions that looked just like that.. it'd be hard to pick things out without syntax highlighting.
  - Gigachad 4y ago
    How can we actually prove this statement though? I work with TS, Ruby, and Rust daily and I honestly can't think of a single time I had any problem reading Rust once I understood the language. But saying "works for me" is just as anecdotal as "doesn't work for me". There needs to be a better way of talking about the problem to progress on this.
    - eddsh1994 4y ago
      When the function name & types are harder to grok than the body I think it’s an issue. Looking at you, TypeScript.
      - bmacho 4y ago
        For me it is an issue as well, but it doesn't seem to be an issue for the others. I strongly prefer Haskell/math notation for denoting the types of functions, but all the new languages choose other syntax.
        Gigachad 4y ago
        I don't think the syntax of TS is the problem. It's that people are trying to define types for massively dynamic JS that is inherently hard to express as a type.
    - deafpolygon 4y ago
      You can run a survey.
kazinator 4y ago
That's another thing. I don't want to see 32 and 64 crap in code that is supposed to be high level and portable. i32 means I'm doing FFI with C libraries. If you check the Rust documentation, you see it has no integer types that are not a fixed size. "All the world is x86/ARM (formerly DEC VAX / Sun SparcStation )" C started on 18 bit machines. A program that correctly used "int argc" for the main argument count runs on an 18 bit machine or a 16 bit machine without modification.
- lmm 4y ago
  > C started on 18 bit machines. A program that correctly used "int argc" for the main argument count runs on an 18 bit machine or a 16 bit machine without modification. I'm guessing you're too young to remember the 32 -> 64 bit transition, because this is backwards in practice. Non-fixed integer sizes are a nightmare for portability and the reason why some C code still hasn't been ported even today, whereas programs in e.g. Java or OCaml ran without modification on the new machines. A modern language should make it easy and first-class to use arbitrary-precision integers and decimals though.
  - kazinator 4y ago
    Java programs run without modification on a new machine for basically the same reason why, say, a Nintento Game Boy program runs without modification on an emulator, more or less. The machine has been ported, taking the programs with it, which have not been ported.
    - lmm 4y ago
      Not necessarily; in that era compiling with GCJ was a viable option too. And in the case of something like OCaml there's no VM. The point is that running the program on a different machine does not result in random changes to when arithmetic does or doesn't overflow.
      - kazinator 4y ago
        Compiling doesn't mean you don't have a virtual machine. Don't forget that emulators (good ones) use dyanamic translation techniques. Executor, Valgrind ... (This one: https://en.wikipedia.org/wiki/Executor_(software) https://en.wikipedia.org/wiki/Executor_(software) ) MC68K MacOS software running on x86 via executor has not been "ported", even though it is transpiled to x86 code. That's approximately the same as Java portability. There is a Java virtual machine (whether interpreted or compiled). Programs are written to that, and the virtual machine semantics is what is ported. The programs are running on the Java machine, just like the programs running under Executor are running on a 68K Mac (as far as they know).
interroboink 4y ago
Funnily, nearby on the frontpage is The Python Paradox[1], an essay which contains: > At the mention of ugly source code, people will of course think of > Perl. But the superficial ugliness of Perl is not the sort I mean. Real > ugliness is not harsh-looking syntax, but having to build programs out > of the wrong concepts. Perl may look like a cartoon character swearing, > but there are cases where it surpasses Python conceptually. I do think there's something to be said for the notion of "conceptually ugly" rather than "syntactically ugly", though the latter is what people tend to focus on. Perhaps we need a better word than "ugly," with its superficial connotations. [1] https://news.ycombinator.com/item?id=34541933 https://news.ycombinator.com/item?id=34541933
- nequo 4y ago
  A “conceptually beautiful” language would consist of orthogonal concepts, right? What would be good examples of such languages? Interestingly, Python’s aspiration to have only one (obvious) way to do things could be understood as an aspiration to achieve conceptual beauty.
  - interroboink 4y ago
    I suppose there's also a distinction between "beautiful in implementation/concepts available" vs. "beautiful/pleasant to work with." Harping on Perl again, one could see its roots in natural language with sigils representing different kinds of "nouns", and ability to rearrange conditions to be more like spoken language ("do X if Y vs. if Y do X") as an aspiration towards "beautiful to work with." And of course the various notions of beauty can get in each others' way. But they're all a lot more fruitful to consider than a mere "yuck, too much punctuation."
deleted 4y ago
[deleted]
timeon 4y ago
> stupid example... "pub fn". I just don't get why this even gives someone pause.
zanellato19 4y ago
Wait, do you want functions _without_ a return type? I don't understand this complaint on a statically typed language.
- conradludgate 4y ago
  In theory the return type can be inferred by the body of the function given the fixed argument types. However rust has made the stance that the full signature is required for the reason of local static analysis. If you have a function A that calls another function B, you shouldn't need to analyse B in order to analyse A (both as a human and as a compiler)

JoshTriplett 4y ago

Brevity isn't always a bug even when optimizing for reading rather than writing. Spending extra characters spelling out `function` doesn't necessarily make code more readable. I do, in general, think keywords should not be abbreviated. We have "return" rather than "ret", "continue" rather than "cont", and so on. This wasn't always the case; ancient (pre-1.0) versions of Rust had a lot more abbreviation in the language and library than current versions.

geoelectric 4y ago
I think there's a good reason for the function keyword to be abbreviated. We know that when people read lines of text, they pay a lot of attention to the beginning and the end and comparatively less attention to the middle. One result is that lines with common prefixes tend to blur together. To get around this, you want the reader to encounter the unique portion of the line ASAP, which makes it desirable that any kind of necessary prefix be brief. Upshot is you want the function signature to be what you see as you scan down the left side of the page, so it does make sense to keep the function keyword particularly concise.

Gigachad 4y ago

There has to be a more objective way to rank uglyness. The example function you provided looks perfectly fine to me. I don't see how syntax highlighting makes it any better.

deafpolygon 4y ago
I did mention it will look perfectly fine to someone here. [ and what better, to someone's nickname is Gigachad :) ] But if you had a sea of functions that looked just like that.. it'd be hard to pick things out without syntax highlighting.
- Gigachad 4y ago
  How can we actually prove this statement though? I work with TS, Ruby, and Rust daily and I honestly can't think of a single time I had any problem reading Rust once I understood the language. But saying "works for me" is just as anecdotal as "doesn't work for me". There needs to be a better way of talking about the problem to progress on this.
  - eddsh1994 4y ago
    When the function name & types are harder to grok than the body I think it’s an issue. Looking at you, TypeScript.
    - bmacho 4y ago
      For me it is an issue as well, but it doesn't seem to be an issue for the others. I strongly prefer Haskell/math notation for denoting the types of functions, but all the new languages choose other syntax.
      - Gigachad 4y ago
        I don't think the syntax of TS is the problem. It's that people are trying to define types for massively dynamic JS that is inherently hard to express as a type.
  - deafpolygon 4y ago
    You can run a survey.

kazinator 4y ago

That's another thing. I don't want to see 32 and 64 crap in code that is supposed to be high level and portable. i32 means I'm doing FFI with C libraries. If you check the Rust documentation, you see it has no integer types that are not a fixed size. "All the world is x86/ARM (formerly DEC VAX / Sun SparcStation )" C started on 18 bit machines. A program that correctly used "int argc" for the main argument count runs on an 18 bit machine or a 16 bit machine without modification.

lmm 4y ago
> C started on 18 bit machines. A program that correctly used "int argc" for the main argument count runs on an 18 bit machine or a 16 bit machine without modification. I'm guessing you're too young to remember the 32 -> 64 bit transition, because this is backwards in practice. Non-fixed integer sizes are a nightmare for portability and the reason why some C code still hasn't been ported even today, whereas programs in e.g. Java or OCaml ran without modification on the new machines. A modern language should make it easy and first-class to use arbitrary-precision integers and decimals though.
- kazinator 4y ago
  Java programs run without modification on a new machine for basically the same reason why, say, a Nintento Game Boy program runs without modification on an emulator, more or less. The machine has been ported, taking the programs with it, which have not been ported.
  - lmm 4y ago
    Not necessarily; in that era compiling with GCJ was a viable option too. And in the case of something like OCaml there's no VM. The point is that running the program on a different machine does not result in random changes to when arithmetic does or doesn't overflow.
    - kazinator 4y ago
      Compiling doesn't mean you don't have a virtual machine. Don't forget that emulators (good ones) use dyanamic translation techniques. Executor, Valgrind ... (This one: https://en.wikipedia.org/wiki/Executor_(software) https://en.wikipedia.org/wiki/Executor_(software) ) MC68K MacOS software running on x86 via executor has not been "ported", even though it is transpiled to x86 code. That's approximately the same as Java portability. There is a Java virtual machine (whether interpreted or compiled). Programs are written to that, and the virtual machine semantics is what is ported. The programs are running on the Java machine, just like the programs running under Executor are running on a 68K Mac (as far as they know).

interroboink 4y ago

Funnily, nearby on the frontpage is The Python Paradox[1], an essay which contains: > At the mention of ugly source code, people will of course think of > Perl. But the superficial ugliness of Perl is not the sort I mean. Real > ugliness is not harsh-looking syntax, but having to build programs out > of the wrong concepts. Perl may look like a cartoon character swearing, > but there are cases where it surpasses Python conceptually. I do think there's something to be said for the notion of "conceptually ugly" rather than "syntactically ugly", though the latter is what people tend to focus on. Perhaps we need a better word than "ugly," with its superficial connotations. [1] https://news.ycombinator.com/item?id=34541933 https://news.ycombinator.com/item?id=34541933

nequo 4y ago
A “conceptually beautiful” language would consist of orthogonal concepts, right? What would be good examples of such languages? Interestingly, Python’s aspiration to have only one (obvious) way to do things could be understood as an aspiration to achieve conceptual beauty.
- interroboink 4y ago
  I suppose there's also a distinction between "beautiful in implementation/concepts available" vs. "beautiful/pleasant to work with." Harping on Perl again, one could see its roots in natural language with sigils representing different kinds of "nouns", and ability to rearrange conditions to be more like spoken language ("do X if Y vs. if Y do X") as an aspiration towards "beautiful to work with." And of course the various notions of beauty can get in each others' way. But they're all a lot more fruitful to consider than a mere "yuck, too much punctuation."

deleted 4y ago

[deleted]

timeon 4y ago

> stupid example... "pub fn". I just don't get why this even gives someone pause.

zanellato19 4y ago

Wait, do you want functions _without_ a return type? I don't understand this complaint on a statically typed language.

conradludgate 4y ago
In theory the return type can be inferred by the body of the function given the fixed argument types. However rust has made the stance that the full signature is required for the reason of local static analysis. If you have a function A that calls another function B, you shouldn't need to analyse B in order to analyse A (both as a human and as a compiler)