2009/3/10 Heinrich Apfelmus

Sergey V. Mikhanov wrote:

...

... some code ...

...

What would you do different (including stylistic changes)? What are the general comments about efficiency (not of the algorithm, but of the implementation: for example, is it fine to use break at every invocation of doFactors?) and elegance of the solution?

Stylistically, one usually uses shorter variable names in Haskell.

<beginner rant> Sometime too short peraphs? At least, this is one of the things that slows down my understanding of code posted on this list on or on various haskell tutorial. In any other language I know, programmers learn to give meaningful names to variable and functions, so when one reads a program, one can use the name to remember what the function does. Then one cames to haskell ... I guess the short names comes from mathematic background, but still ... haskell is already very succint - even more so when you use pointfree programming - and if one also uses names like a,e,i ( look at Array function definitions ), ... Rant apart, I notice that in my own excercises I tend to shorten names, so maybe there is a reason for that. Nevertheless readability tends to be a big issue in languages used in IT industry, and my feeling is that haskell tends to err on the laconic side of the balance. Out of curiosity, there is any reason why you called the auxiliary function 'go' ? Ciao ------- FB

Francesco Bochicchio wrote:

Heinrich Apfelmus wrote:

...

Stylistically, one usually uses shorter variable names in Haskell.

<beginner rant> Sometime too short peraphs? At least, this is one of the things that slows down my understanding of code posted on this list on or on various haskell tutorial. In any other language I know, programmers learn to give meaningful names to variable and functions, so when one reads a program, one can use the name to remember what the function does. Then one cames to haskell ... I guess the short names comes from mathematic background, but still ... haskell is already very succint - even more so when you use pointfree programming - and if one also uses names like a,e,i ( look at Array function definitions ), ...

Rant apart, I notice that in my own excercises I tend to shorten names, so maybe there is a reason for that. Nevertheless readability tends to be a big issue in languages used in IT industry, and my feeling is that haskell tends to err on the laconic side of the balance.

The goal is of course to make code readable, that's why I recommend short names. :D Abstraction is the one driving force for very short names. For example, take the definition of foldr foldr f z [] = z foldr f z (x:xs) = f x (foldr f z xs) Since this function is polymorphic, so f , z and the xs can be anything, using more "descriptive" variable names is simply not possible; the key point of fold is its generality. A second, and my main reason for short names, or rather against long names, is that names should be to the point. None of the names newPrimes topPrime doFactors doFilter accurately describe the object they represent. The primes are not "new", the prime is not "on top". The "do" is a prefix does not carry a meaning either, it just conveys that doFactors has something to do with factors . This is best expressed by making doFactors a local definition in the where-block of factors . The name eratosthenesFilter is ok, but since there is no other eratosthenes around, no meaning is lost by shortening it to simply eratosthenes . Not to mention that the conventional term is "sieve", not "filter". The documentation has to elaborate on it anyway. The generality of the name num hints that a single letter name is preferable. The names that I think are great because they are to the point are factors primes

Out of curiosity, there is any reason why you called the auxiliary function 'go' ?

Convention. Often, an auxiliary function that does basically the same thing as the main function factors but with an extra parameter will be named factors' . The apostrophe has the drawback that it's easy to forget, so some people now name such auxiliary functions go instead. Regards, apfelmus -- http://apfelmus.nfshost.com

...

...

...

...

"Heinrich" == Heinrich Apfelmus writes:

Heinrich> Abstraction is the one driving force for very short Heinrich> names. For example, take the definition of foldr Heinrich> foldr f z [] = z foldr f z (x:xs) = f x (foldr f z Heinrich> xs) Heinrich> Since this function is polymorphic, so f , z and the xs Heinrich> can be anything, using more "descriptive" variable names Heinrich> is simply not possible; the key point of fold is its Heinrich> generality. Wouldn't unit be a better descriptive name than z? -- Colin Adams Preston Lancashire

2009/3/13 Heinrich Apfelmus

Francesco Bochicchio wrote:

...

Heinrich Apfelmus wrote:

...

Stylistically, one usually uses shorter variable names in Haskell.

<beginner rant> ...

Rant apart, I notice that in my own excercises I tend to shorten names, so maybe there is a reason for that. Nevertheless readability tends to be a big issue in languages used in IT industry, and my feeling is that haskell tends to err on the laconic side of the balance.

The goal is of course to make code readable, that's why I recommend short names. :D

Abstraction is the one driving force for very short names. For example, take the definition of foldr

foldr f z [] = z foldr f z (x:xs) = f x (foldr f z xs)

Since this function is polymorphic, so f , z and the xs can be anything, using more "descriptive" variable names is simply not possible; the key point of fold is its generality.

Ok but one could still hint at their structure or purpose: foldr function value (x:xs) = function x ( foldr function value xs ) I believe this would give a little more information to the casual reader.

A second, and my main reason for short names, or rather against long names, is that names should be to the point. None of the names

newPrimes topPrime doFactors doFilter

accurately describe the object they represent. The primes are not "new", the prime is not "on top". The "do" is a prefix does not carry a meaning either, it just conveys that doFactors has something to do with factors . This is best expressed by making doFactors a local definition in the where-block of factors .

I agree that well-documented shared name conventions are better than roll-your-own. (x:xs) is one example of such convention, although I tend to adopt slight variations like (n:nums) for list of numbers and (ch:chars) for list of characters. But roll-your-own is still better than cryptic.

The name eratosthenesFilter is ok, but since there is no other eratosthenes around, no meaning is lost by shortening it to simply eratosthenes . Not to mention that the conventional term is "sieve", not "filter". The documentation has to elaborate on it anyway.

The generality of the name num hints that a single letter name is preferable.

The names that I think are great because they are to the point are

factors primes

I have some resistance to use nouns for functions. In the imperative world,

nouns are for variables, verbs are for functions. I know that in pure functional programming there is not such a thing as variables, but still I would reserve nouns for function parameters and bound expressions. Hence if I have a function that find factors, I would call it findFactors rather than just factors. One such example of misnaming - from a beginner point of view - is the length function in prelude: if it was called count, I believe more beginners would have realized that works by actually counting the elements of a list and not by accessing to some already available 'property' of the list.

...

Out of curiosity, there is any reason why you called the auxiliary function 'go' ?

Convention. Often, an auxiliary function that does basically the same thing as the main function factors but with an extra parameter will be named factors' . The apostrophe has the drawback that it's easy to forget, so some people now name such auxiliary functions go instead.

I tend to use _ instead of '. Is more visible and keep conveying the idea that the auxiliary function is just a slight variation of the main one.

Regards, apfelmus

Ciao ------ FB