I very much agree. Significant Names become a problem when the point of the code is to communicate the naked structure. In that case, single letter names emphasize the ‘wiring pattern’ that is the actual content.

How about x + (length . unlines . take y $ contents)?

josh: You mean: x + (length . unlines . take y . lines) contents

I’ll have to try that out.

If your code is sufficiently abstract to properly capture domain concepts, its naming conventions should be the naming convention of the domainn it models (e.g. statistics, cryptography, finance ..).

Same rules for good DSLs and EDSLs apply here.

I like:

(x+) . length . unlines . take y . lines

Also, if you define:

withLines = (unlines .) . (. lines)

then you can do:

(x+) . length . withLines (take y)

How about:

sum . zipWith ($) (replicate y length ++ [const x]) $ terminatedLines contents

Or, “take the sum of the length of the first y lines, and x for the line after that.”

Jake: That’s wild. Is that a section of function composition?

lilac: I’m going to have to work on understanding that one.

Yes. (. lines) takes a function f and creates f . lines. That is then applied to (unlines .), which results in this:

unlines . f . lines

I normally avoid sections with function composition, but I think it is visually meaningful in this kind of simple case.

Correction to the above:

(unlines .) is then applied to that, which results in this [...]

It might be clearer to rewrite my suggestion as:

length $ charsUpTo x y contents
  where charsUpTo x y = withLines (zipWith ($) (replicate y id ++ [take x]))

About this game of rephrasing haskell programs into mysterious expressions involving hordes of composition operators and other higher-level combinators being applied to eachother, with few meaningful identifier names:

For higher mathematics, maybe there are real advantages in the use of abstracted language and definitions. Maybe the abstractions used really elevate you to a higher level of discourse, where you can work in peace and clarity free of the irrelevant details. Perhaps this is also true for well-designed DSLs in a language like haskell.

But for simple bits of programming, taking this kind of thing to the extreme seems counter-productive. It doesn’t raise you cleanly to a higher level of abstracted discourse, it just adds indirection to a simple idea, requiring a lot of mental energy to unpack the definition of something which is trivial.

Matthew: I agree. The question seems to be where do you stop? I suspect a lot of it has to do with what you assume about your audience.. whether some idioms common enough to avoid head-scratching.

Matthew: I think my version is a good example of the goal of this whole exercise, though. I have expressed the whole idea of “take y lines, get the length of that, then add x to that” rather clearly, I think. Far more clearly than the original, certainly.

@Matthew: You don’t understand functional programming, so of course this looks very foreign to you. And, by understand, I truly mean eat, breath, sleep, and think in it. You’re an OO coder, and it shows, just by your comment.

@Michael: Matthew’s point is valid, but what I think you’re going through is the classic “newbie” phase of functional programming. You know just enough to be dangerous—that is, you can speak the language, but you’re not fluent in it like a native coder/speaker would be. As you indicate, much of functional coding is body language

The funny thing is, Lisp and Forth coders have been trying to tell people this FOR DECADES. The real question is, why hasn’t anyone been listening?

@Matthew: Taking anything to extremes is liable to be more trouble than it’s worth, but these examples are hardly extreme. As for “unpacking the definition”, using function composition and eschewing names for intermediate parts often simplifies the reading because there is less to unpack. In the C/Java/Perl world I often have to run around in circles reading function after function before finally getting to the real code; in Haskell things are usually a lot more direct.

(++) might be space equivalent, but I think it’s not time equivalent:

14:22 ~ % cat test.hs
import System

atEnd [] = []
atEnd (x:xs) = (atEnd xs) ++ [x]

main = do
  (n:_) <- getArgs
  putStrLn $ show $ sum$  atEnd [1..(read n)]

14:21 ~ % time ./test 10000 
50005000
./test 10000  1.26s user 0.02s system 96% cpu 1.332 total

14:22 ~ % cat test2.hs
import System

atBeginning [] = []
atBeginning (x:xs) = [x] ++ (atBeginning xs)

main = do
  (n:_) <- getArgs
  putStrLn $ show $ sum$  atBeginning [1..(read n)]

14:22 ~ % time ./test2 10000     
50005000
./test 10000  0.00s user 0.00s system 74% cpu 0.008 total

Actually, terminatedLines isn’t a good idea, because (++) is slow (Rule of thumb: Putting things in front of a list is good, appending things at the end is bad, because in the latter case you first have to traverse the whole list).

For the example in question, I’d just use a list comprehension:

absPosition (Buffer (x,y) contents) = 
  x + sum [length l + 1 | l <- take y $ lines $ contents]

No need to make code harder to read than necessary.

Mark: Thx.

Dirk: I was hoping that with lazy evaluation, the reduction order for something like [1,2,3] + [4,5,6] would be 1:(2:([3]+[4,5,6])). In other words, we consume elements from the head and then the append happens sort of as a cons and at end of the consumption. from the definition of (++) it looks like that is what happens.

Michael Feathers,

re: Dirk: terminatedLines isn’t a good idea

While [1,2,3] + [4,5,6] indeed reduces to 1:(2:([3]+[4,5,6])), the cost of that reduction is the length of the first list. In the context of your map (++”\n”) code, it’s decidedly non-trivial. That’s Dirk’s point.

In other words, append doesn’t do automagical, never mind zero-cost, consing “at the end of the consumption.” That said, you might want to check out difference lists.

When to extract and not to is a good question. I tend to only give names and extract when there’s some redundancy to be exploited. Otherwise, it always makes sense to me to inline—proper formatting and occasional comments are enough otherwise. Nice Haskell can read very fluently already, I think.

Viewing the simple stuff inline can also expose all sorts of other nice optimizations such as why “terminatedLines” can be replaced with, e.g., Jake’s very elegant code above.

“editor combinators” and variants such as the above are really nice ways to denoise your code—abstracting out views on data, so to speak, rather than operations on it.

I personally love the terseness of functional programming for a very good reason: It breaks the ungodly, pretentious habit programmers have of “nice-naming” – that is, naming functions and procedures with names that suggest what the function is meant to do, but doesn’t.

I suppose the reason the practice gets on my nerves so much is because I tend to run into the mid-level-skill types – the people who think they’re much cleverer than they are. There’s nothing that makes a team member want to step back and watch a drowning man go under, than hearing, “Jeez, can’t you read?!? It’s OBVIOUS what my program does! It’s called ‘addStudentToTutors’!” It’s obvious what the program is supposed to do, yes…

One of the nice thing about doing all of those Flying Wallendas-style functions, is that it breaks your functions up into dense nuggets of power, that you are then “compelled” to comment. It’s never bad to just throw a line of commentary that says: ”—‘withLines’ takes a function, and makes a new function that applies ‘lines’ to its argument, runs your function on that, and then does ‘unlines’ to the result”.

Functional programming in general, gives you the idea that you’re describing what you want to happen, instead of what you have to set up to get it to happen.