10 ms·

Oh but it does.... I don't know first thing about F#, so "x::xs" looks alien and very unapproachable (and also will make the rest of method body confusing). In

by watt 14y ago

Oh but it does.... I don't know first thing about F#, so "x::xs" looks alien and very unapproachable (and also will make the rest of method body confusing). In my mind it's that code readability is at last being discussed, signals that F# might be nearing mainstream.

sdevlin 14y ago
Surely questions of readability should be decided with an eye towards experienced users of the language and not those who "don't know the first thing about F#". I agree with the GP that x::xs is more appropriate.
- watt 14y ago
  You will end up with just another fringe write-only language.
  - chc 14y ago
    I do not think that phrase means what you think it means. If the code is readable to somebody of average skill who has learned the language, it is not "write-only." The fact that you can't read code in a language you don't know shouldn't surprise you any more than the fact that I can't read a book in Vietnamese. My inability to read Vietnamese does not make it "write-only" — it's just a sign that I haven't learned the language. As for "fringe," that may or may not be true. It's pretty subjective. But really, who cares? Back when Ruby was the weird new thing gaining visibility, I heard the same complaints about its idioms. Last I checked, it's still doing fine. I'm OK using "fringe" languages like Ruby.
abraininavat 14y ago
Is readability to people who don't know the first thing about F# at all relevant? If that's the most important metric then we should write out all our programs in plain English. Readability to F# programmers is what matters, along with a host of other concerns, such as terseness.
- kvb 14y ago
  Actually, I think there's some merit to writing code that is readable to outsiders, for several reasons. First of all, with a not-quite-mainstream language like F#, you're more likely to have team members joining your projects who are lacking the relevant in-language expertise. Making code more readable for them without significantly harming readability for an expert seems like a fine tradeoff. Secondly, one benefit to F# is that the code can read almost like pseudocode, which opens up the possibility of having domain experts (that is, non-programmers) review code, in which case the same tradeoff also makes sense (see e.g. Jane St. Capital, where traders review some/most of their OCaml code).
LeonidasXIV 14y ago
> Oh but it does.... I don't know first thing about F#, so "x::xs" looks alien and very unapproachable (and also will make the rest of method body confusing). I use OCaml and I think of it as idiomatic naming for pattern matching on a list, in a similar way to how iteration variables are often named `i`, although `index` might be more superficially clear, but in reality it is not really since one "knows" `i` is the interation variable, just like `x::xs` means `x` is an element and `xs` is a list of x'es, that is elementy of the same type as x. Pretty clear in my opinion.
chc 14y ago
I do like the principle of thinking about code readability. But unless you're writing an introductory tutorial, your code should absolutely not be optimized for reading by people who know nothing about the language. You should try to make it readable for the people who will actually be working with the code. Optimizing code for people who don't know anything about the language basically means sticking as close to the C or Python way of doing things as possible. If your language is significantly different from C, this is obviously not going to be a global maximum of readability.
papsosouid 14y ago
>so "x::xs" looks alien and very unapproachable And how is head::tail any better? That's like insisting for loops use "counter" instead of "i".
- klibertp 14y ago
  It's better - in so many ways that I will necessarily offer you just a short summary of some of them. Being able to figure out a meaning of something is crucial in programming. We spend much more time reading the code than writing it and most of the time during reading is spent on resolving the meaning of symbols. To be able to tell what a symbol means, one needs to take into account many things - from OS it's running on to language it's written in to declared variables in the scope. And much more, of course. Now back to your example: to be able to understand `x::xs` I need to know that `::` is a cons operator. Or more precisely, to understand the meaning of `x` symbol I need to take into account another symbol. On the other hand of the spectrum is something like this: `first_element_of_list :: rest_of_list`. To understand the meaning of the first symbol in this expression you need to know exactly one symbol - itself. That's one benefit. The second is that someone who doesn't know what consing is, let alone how it's written in OCaml, can still understand this expression. So that's the second benefit. It's worth remembering that we do not write the code for ourselves nor for the computers. We write the code to be read by other humans (always - don't argue). As with any kind of writing, then, it's helpful to know the audience. If I was writing a tutorial on constructing lists in OCaml (for beginners), I would use the second example above. But if I was writing production code (so for me and my team to read) I would use something shorter, like `head :: tail` for example. And if I was writing a quick and dirty script for my personal use, or if I was contributing to the work of hardcore OCaml hackers I would probably write `x :: xs` - because in case of script I'd be convinced that readability doesn't matter and in second case I would be certain that everyone reading and working with the code I wrote would be already so used to the construction that they would read it without problems. That's another thing to consider: after using a language for a long enough time we tend to internalize its idioms; when this happens we are able to treat bigger constructs as one symbol. This ability helps in reading the code quickly, but it's worth remembering that not everyone developed it. Also, because longer names do not hinder quick-reading of idioms for those who know them, that's not a counterargument to longer names. As for loops... Well, I do - sometimes - use `i` as a variable name, but I tend not to. Most often, after a while I come back to the code and replace `i` with `idx`. But to even use `i` as a name in the first place it needs to refer to the nonnegative integer value. In Python you generally iterate over collection directly, so you write `for what_is_it in a_collection:` instead of for example: `for i in 1 to 10: an_element = a_collection[i]`. Anyway, I use single letter variables very sparingly and in the smallest scope possible. What I want to say, I guess, is that descriptive names are important in good programming and that there is really no argument for using non-descriptive ones.

by watt 14y ago

sdevlin 14y ago

Surely questions of readability should be decided with an eye towards experienced users of the language and not those who "don't know the first thing about F#". I agree with the GP that x::xs is more appropriate.

watt 14y ago
You will end up with just another fringe write-only language.
- chc 14y ago
  I do not think that phrase means what you think it means. If the code is readable to somebody of average skill who has learned the language, it is not "write-only." The fact that you can't read code in a language you don't know shouldn't surprise you any more than the fact that I can't read a book in Vietnamese. My inability to read Vietnamese does not make it "write-only" — it's just a sign that I haven't learned the language. As for "fringe," that may or may not be true. It's pretty subjective. But really, who cares? Back when Ruby was the weird new thing gaining visibility, I heard the same complaints about its idioms. Last I checked, it's still doing fine. I'm OK using "fringe" languages like Ruby.

abraininavat 14y ago

Is readability to people who don't know the first thing about F# at all relevant? If that's the most important metric then we should write out all our programs in plain English. Readability to F# programmers is what matters, along with a host of other concerns, such as terseness.

kvb 14y ago
Actually, I think there's some merit to writing code that is readable to outsiders, for several reasons. First of all, with a not-quite-mainstream language like F#, you're more likely to have team members joining your projects who are lacking the relevant in-language expertise. Making code more readable for them without significantly harming readability for an expert seems like a fine tradeoff. Secondly, one benefit to F# is that the code can read almost like pseudocode, which opens up the possibility of having domain experts (that is, non-programmers) review code, in which case the same tradeoff also makes sense (see e.g. Jane St. Capital, where traders review some/most of their OCaml code).

LeonidasXIV 14y ago

> Oh but it does.... I don't know first thing about F#, so "x::xs" looks alien and very unapproachable (and also will make the rest of method body confusing). I use OCaml and I think of it as idiomatic naming for pattern matching on a list, in a similar way to how iteration variables are often named `i`, although `index` might be more superficially clear, but in reality it is not really since one "knows" `i` is the interation variable, just like `x::xs` means `x` is an element and `xs` is a list of x'es, that is elementy of the same type as x. Pretty clear in my opinion.

chc 14y ago

I do like the principle of thinking about code readability. But unless you're writing an introductory tutorial, your code should absolutely not be optimized for reading by people who know nothing about the language. You should try to make it readable for the people who will actually be working with the code. Optimizing code for people who don't know anything about the language basically means sticking as close to the C or Python way of doing things as possible. If your language is significantly different from C, this is obviously not going to be a global maximum of readability.

papsosouid 14y ago

>so "x::xs" looks alien and very unapproachable And how is head::tail any better? That's like insisting for loops use "counter" instead of "i".

klibertp 14y ago
It's better - in so many ways that I will necessarily offer you just a short summary of some of them. Being able to figure out a meaning of something is crucial in programming. We spend much more time reading the code than writing it and most of the time during reading is spent on resolving the meaning of symbols. To be able to tell what a symbol means, one needs to take into account many things - from OS it's running on to language it's written in to declared variables in the scope. And much more, of course. Now back to your example: to be able to understand `x::xs` I need to know that `::` is a cons operator. Or more precisely, to understand the meaning of `x` symbol I need to take into account another symbol. On the other hand of the spectrum is something like this: `first_element_of_list :: rest_of_list`. To understand the meaning of the first symbol in this expression you need to know exactly one symbol - itself. That's one benefit. The second is that someone who doesn't know what consing is, let alone how it's written in OCaml, can still understand this expression. So that's the second benefit. It's worth remembering that we do not write the code for ourselves nor for the computers. We write the code to be read by other humans (always - don't argue). As with any kind of writing, then, it's helpful to know the audience. If I was writing a tutorial on constructing lists in OCaml (for beginners), I would use the second example above. But if I was writing production code (so for me and my team to read) I would use something shorter, like `head :: tail` for example. And if I was writing a quick and dirty script for my personal use, or if I was contributing to the work of hardcore OCaml hackers I would probably write `x :: xs` - because in case of script I'd be convinced that readability doesn't matter and in second case I would be certain that everyone reading and working with the code I wrote would be already so used to the construction that they would read it without problems. That's another thing to consider: after using a language for a long enough time we tend to internalize its idioms; when this happens we are able to treat bigger constructs as one symbol. This ability helps in reading the code quickly, but it's worth remembering that not everyone developed it. Also, because longer names do not hinder quick-reading of idioms for those who know them, that's not a counterargument to longer names. As for loops... Well, I do - sometimes - use `i` as a variable name, but I tend not to. Most often, after a while I come back to the code and replace `i` with `idx`. But to even use `i` as a name in the first place it needs to refer to the nonnegative integer value. In Python you generally iterate over collection directly, so you write `for what_is_it in a_collection:` instead of for example: `for i in 1 to 10: an_element = a_collection[i]`. Anyway, I use single letter variables very sparingly and in the smallest scope possible. What I want to say, I guess, is that descriptive names are important in good programming and that there is really no argument for using non-descriptive ones.