3 ms·

> Overly terse named types and keywords that don't communicate their purpose, like Vec and Cell i'm of the opposite view here; though, i think i get where this

by abiox 10y ago

> Overly terse named types and keywords that don't communicate their purpose, like Vec and Cell i'm of the opposite view here; though, i think i get where this is coming from. for me, if i look at it from a "broader timeline perspective", the length of keywords (like say "function" in JS) is mildly annoying to me. especially if they're high frequency. over time, familiarized keywords essentially "fade into the background" and afterward just occupy precious horizontal space, but provide a valuable sort of visual shaping or pattern. given this, i love the elements of terseness in rust syntax. my identifiers are what i want to be more expressive and descriptive. this combos well: terse keywords and stdlib elements contrast excellently with longer identifiers and make it easier and faster to read (for me).

edejong 10y ago
In some of my programming environments, such as Emacs, I choose to prettify keywords to unicode characters such as 'function' (λ), 'lambda' (λ), 'forall' (∀) and others. It takes a bit getting used to, but it brings the focus where it needs to be: the code and data flow. The brain quickly adopts new pattern-matchable structures, so why bother with long keywords? [1] http://emacsredux.com/blog/2014/08/25/a-peek-at-emacs-24-dot-4-prettify-symbols-mode/ http://emacsredux.com/blog/2014/08/25/a-peek-at-emacs-24-dot...
imron 10y ago
Some things are obvious, some are not. Keywords are not really the problem, it's more when people start abbreviating their identifiers. One I saw in some codebase a while back was xxxxRec and it took me a while to realise it was an abbreviation for Receiver because for whatever reason my initial mental auto-complete was Record and that wasn't making much sense. And while it will always be obvious to the person writing the code, it might not always be obvious to the person reading the code. Sometimes that's even the same person. So I agree that Rust feels a little too heavy on abbreviations at times.
bluejekyll 10y ago
As the IDEs for Rust becomes more powerful, the name length issue will probably go away. I get terseness, but there is a balance. I am definitely in the camp of expressive naming, as it reduces confusion. In fact, I find myself waffling on generic names as well, T is common, but when you get up to 3 or 4 generics in a function, it starts looking like more expression is needed. Though I still use single or double characters, I do think about changing my mind here.
- sitkack 10y ago
  Maybe there needs to be an idiom where T is generic, requiring little or not traits on it. N,M,... is a numeric type thing, S,T,U,.. is a container type thing. When one starts to get multiple generics in a function, usually they interact in some way, what names we should give them to describe that interaction, I don't know. Naming is hard, naming in generic code is x^y harder.
erikpukinskis 10y ago
I used to be annoyed by "function" in JavaScript. That was when I thought the main job of a programming language was to help brilliant programmers write code in the most efficient possible way. My thinking has changed. Lately I think the job of the language is just to provide variable assignment, function calls, and a couple other basics. Most programming languages go far above and beyond and they become impossible to use for beginners, which means they can't be used on a diverse team. And worse, they tempt intermediate programmers into using complex control structures instead of doing the design work to figure out which boring-ass array processing functions they actually need to write. I think the core challenge of programming is to write code that inexperienced people can understand quickly. Partly because your teammates may be inexperienced. Partly because 2 years from now you will be inexperienced with respect to this part of the code. Advanced programming language features are generally antithetical to that. Terseness is antithetical to that. Instead, we get giant codebases that require full time attention from an expert programmer, in order to have any chance of extending anything. I want code that uses the most basic possible programming primitives. I names to be as verbose as necessary so you don't have to look a lot of places to see what's happening. And I want the data model to be as simple as possible. I want to see that the programmer told the rest of the organization "No" over and over, and that the code does very little, and uses childlike tools to do basic things. I am not impressed by wizardry, and trivialities like "function" versus "def" don't matter to me anymore at all. I am impressed when someone makes something small and simple and good.
- parenthephobia 10y ago
  > the core challenge of programming is to write code that inexperienced people can understand quickly This is a pipe dream. For anything significantly non-trivial, programming is inherently complex. Designing the language so that code is forced to be "simple" at the lowest scale just pushes that complexity up to larger scale code structures. Trying to make programs easier to understand by limiting the expressivity of the language is like trying to make quantum physics easier by reformulating it without using complex numbers. Whilst it may well make each individual step of a calculation easier to understand, it doesn't make the whole any easier to comprehend.
atombender 10y ago
I don't mind the aforementioned abbrevations, but I think certain choices — "fn" in particular — make poor "visual anchors". Rust generally suffers from a Perl-like visual clutter, caused by a proliferation of punctuation (I have a particular hatred for "::") and also the unfortunate choice of snake_case for identifiers. Some of these things work in Ruby and Python because they're otherwise very uncluttered languages, but in Rust they only exacerbate the noisiness. (As a minor aside, it's always bothered me that almost all snakecase languages don't Capitalize_Like_This, so they're not symmetrical here. Oh, well.) The Rust devs always bite back when I complain about the above. I know they put a lot of thought into it; I just think they could have put in more. The visual aspect of code is almost always underestimated by language designers. (On a semi-related note, I really like how Facebook's Reason cleans up OCaml's syntax.)
- lomnakkus 10y ago
  I think the choice of snake_case may be somewhat supported by empirical research[1, 2]. (The first link is a summary of the study.) No idea if the Rust designers knew of this study. [1] https://whathecode.wordpress.com/2013/02/16/camelcase-vs-underscores-revisited/ https://whathecode.wordpress.com/2013/02/16/camelcase-vs-und... [2] www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
  - atombender 10y ago
    Interesting, thanks. Those studies seem to look at readability in isolation, but in my opinion the readability problem emergeces when combined with many other sources of "noise". Snakecase works perfectly fine in less noisy languages like Ruby and Python where there's little clutter in the first place. In a noisier language like Rust, camelcase would have helped give it more visual cohesiveness. That said, I'd love a programming font that could actually align the underscore with the font baseline. In all of today's fonts, the underscore breaks up the identifier into little pieces. Compare the vertical cohesiveness (not perfect, but closer) of: an⎽underscore⎽identifier with: an_underscore_identifier

by abiox 10y ago

edejong 10y ago

In some of my programming environments, such as Emacs, I choose to prettify keywords to unicode characters such as 'function' (λ), 'lambda' (λ), 'forall' (∀) and others. It takes a bit getting used to, but it brings the focus where it needs to be: the code and data flow. The brain quickly adopts new pattern-matchable structures, so why bother with long keywords? [1] http://emacsredux.com/blog/2014/08/25/a-peek-at-emacs-24-dot-4-prettify-symbols-mode/ http://emacsredux.com/blog/2014/08/25/a-peek-at-emacs-24-dot...

imron 10y ago

Some things are obvious, some are not. Keywords are not really the problem, it's more when people start abbreviating their identifiers. One I saw in some codebase a while back was xxxxRec and it took me a while to realise it was an abbreviation for Receiver because for whatever reason my initial mental auto-complete was Record and that wasn't making much sense. And while it will always be obvious to the person writing the code, it might not always be obvious to the person reading the code. Sometimes that's even the same person. So I agree that Rust feels a little too heavy on abbreviations at times.

bluejekyll 10y ago

As the IDEs for Rust becomes more powerful, the name length issue will probably go away. I get terseness, but there is a balance. I am definitely in the camp of expressive naming, as it reduces confusion. In fact, I find myself waffling on generic names as well, T is common, but when you get up to 3 or 4 generics in a function, it starts looking like more expression is needed. Though I still use single or double characters, I do think about changing my mind here.

sitkack 10y ago
Maybe there needs to be an idiom where T is generic, requiring little or not traits on it. N,M,... is a numeric type thing, S,T,U,.. is a container type thing. When one starts to get multiple generics in a function, usually they interact in some way, what names we should give them to describe that interaction, I don't know. Naming is hard, naming in generic code is x^y harder.

erikpukinskis 10y ago

I used to be annoyed by "function" in JavaScript. That was when I thought the main job of a programming language was to help brilliant programmers write code in the most efficient possible way. My thinking has changed. Lately I think the job of the language is just to provide variable assignment, function calls, and a couple other basics. Most programming languages go far above and beyond and they become impossible to use for beginners, which means they can't be used on a diverse team. And worse, they tempt intermediate programmers into using complex control structures instead of doing the design work to figure out which boring-ass array processing functions they actually need to write. I think the core challenge of programming is to write code that inexperienced people can understand quickly. Partly because your teammates may be inexperienced. Partly because 2 years from now you will be inexperienced with respect to this part of the code. Advanced programming language features are generally antithetical to that. Terseness is antithetical to that. Instead, we get giant codebases that require full time attention from an expert programmer, in order to have any chance of extending anything. I want code that uses the most basic possible programming primitives. I names to be as verbose as necessary so you don't have to look a lot of places to see what's happening. And I want the data model to be as simple as possible. I want to see that the programmer told the rest of the organization "No" over and over, and that the code does very little, and uses childlike tools to do basic things. I am not impressed by wizardry, and trivialities like "function" versus "def" don't matter to me anymore at all. I am impressed when someone makes something small and simple and good.

parenthephobia 10y ago
> the core challenge of programming is to write code that inexperienced people can understand quickly This is a pipe dream. For anything significantly non-trivial, programming is inherently complex. Designing the language so that code is forced to be "simple" at the lowest scale just pushes that complexity up to larger scale code structures. Trying to make programs easier to understand by limiting the expressivity of the language is like trying to make quantum physics easier by reformulating it without using complex numbers. Whilst it may well make each individual step of a calculation easier to understand, it doesn't make the whole any easier to comprehend.

atombender 10y ago

I don't mind the aforementioned abbrevations, but I think certain choices — "fn" in particular — make poor "visual anchors". Rust generally suffers from a Perl-like visual clutter, caused by a proliferation of punctuation (I have a particular hatred for "::") and also the unfortunate choice of snake_case for identifiers. Some of these things work in Ruby and Python because they're otherwise very uncluttered languages, but in Rust they only exacerbate the noisiness. (As a minor aside, it's always bothered me that almost all snakecase languages don't Capitalize_Like_This, so they're not symmetrical here. Oh, well.) The Rust devs always bite back when I complain about the above. I know they put a lot of thought into it; I just think they could have put in more. The visual aspect of code is almost always underestimated by language designers. (On a semi-related note, I really like how Facebook's Reason cleans up OCaml's syntax.)

lomnakkus 10y ago
I think the choice of snake_case may be somewhat supported by empirical research[1, 2]. (The first link is a summary of the study.) No idea if the Rust designers knew of this study. [1] https://whathecode.wordpress.com/2013/02/16/camelcase-vs-underscores-revisited/ https://whathecode.wordpress.com/2013/02/16/camelcase-vs-und... [2] www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
- atombender 10y ago
  Interesting, thanks. Those studies seem to look at readability in isolation, but in my opinion the readability problem emergeces when combined with many other sources of "noise". Snakecase works perfectly fine in less noisy languages like Ruby and Python where there's little clutter in the first place. In a noisier language like Rust, camelcase would have helped give it more visual cohesiveness. That said, I'd love a programming font that could actually align the underscore with the font baseline. In all of today's fonts, the underscore breaks up the identifier into little pieces. Compare the vertical cohesiveness (not perfect, but closer) of: an⎽underscore⎽identifier with: an_underscore_identifier