I’m not so worried about the one who hasn’t seen the idiom before.

I’m more worried about the person who has seen the idiom many times before, and has learned to “read” it as a unit.

Example: Did anyone actually notice the bug in the inlined code I used in my example? I wanted to prove a point: Inlining of control flow constructs out of fear that abstraction would make the code abstruse and unreadable is not only morally wrong; it can actually cause its own class of bugs.

(let me apologize for the dishonest phrasing of my first comment — I wanted to show how easy it is to misread inlined code, and I couldn’t figure out a way to be frank about it without ruining the “example”)

You ask “does the difference in code size really make it worth the complexity of not being able to see inline what the mappedWith() function does?”

The problem with idioms is that apart from the metaphorical meaning (the reason why you chose to use the idiom) they also have a concrete meaning, which is often much more concrete than, or completely different from, the situation in which you use the idiom. If somebody does not know the idiom and takes you literally, it’s comedy time.

Translating this to code, the problem is that the expanded form - the idiom - prescribes more than it should. Is it really necessary that a variable “iter” is introduced (and can be inspected in a debugger) that is bound to an object with a unique identity? And that the results of the iterator are delivered one after the other?

I would say - no, code size alone is not it. The real difference is between

ListUtil.map(l,fun(String s){ s.toUpperCase() })

and

l.map(fun(String s){ s.toUpperCase() })

the latter being object-oriented, with an implementation that depends on the concrete type of collection, and the former being just an abbreviation (where the implementation might be exchanged in theory, but not in practice, for backwards compatibility reasons).

There’s more to say about this - probably enough for another post!

I can’t think of a post yet, maybe you’ll think of one. But the title jumps out and begs for someone, anyone to write an essay:

“HOOOP Dreams”

http://www.imdb.com/title/tt0110057/

All of these are mechanisms for avoiding to name things that do not need names. My line still is: OOP is an advance over functional programming. Because functional programming tempts you to name too few things, and makes you create abstractions in a way that is hard to communicate to anyone unfamiliar with your code.

The challenge in my view is in adding functional features to an OO language without falling into the nameless abstraction trap.

To Warren: I am not talking about the complexity of the language, but about the complexity of a typical program written in that language. Schemers have a tendency to outsmart themselves (at least I did when I was hacking Scheme). About math being the perfect world description, I doubt it - math is not very good at anchoring your model in a conceptual context, math’s power kicks in as soon as you leave the reallity plane and start working purely at the level of abstraction. Lots of software today is not system software, so we need to relate to “real” requirements. And does OOP make software easy? Well, a systematic approach always means not doing everything you could, so that the things you do have some guaranteed properties. Which implies restricting yourself to the things you can now do with sensible effort. And about design patterns: Have you seen the “OO” design pattern in Scheme? Ugly as hell. Scala: always wanted to take a look at that, and I definitely will, if I just wasn’t in an office full of screaming morons most of my time

Sorry, it’s late, I’ll come back to the points I missed!

What about HOOOP? (Higher-Order Object-Oriented Programming)

“Language is not understood best when you have removed as much as possible. Would you rather read a novel, or an algebra textbook?”

Actually, the notation and other measures taken to ensure brevity in math arose by no accident. They are essential. Math must consider difficult abstract concepts and the only way to effectively communicate that is to do it in a special way. Math is understood far, far better when you have symbols instead of words. The brevity there makes things that would otherwise be impossible to explain possible. This is the math that makes it possible to build suspension bridges and all the other things in our daily lives we take for granted.

“Conciseness comes at a price: The more compressed your code, the harder it is to understand what the consequence of some change would be.”

What?

“I strongly associate higher-order functional programming with long stretches of uninterrupted concentrated programming work, and single-person projects.”

Object-oriented programming is therefore for when you are in an office full of screaming morons and no one gets any work done? Does OOP magically make software easy? I doubt it.

“Object-oriented programming was introduced to fill a need not satisfied by functional and imperative languages. Remember: Going from functional to OO is an advance.”

Thinking you don’t need to take functions seriously is ridiculous and is why you have entire “design patterns” that are invisible in functional languages.

Have you heard about the Scala programming language? You’ve been claiming throughout this article that functional programming and OOP are somehow incompatible and it’s undesirable to have both; I think that’s an unreasonable bifurcation. think both are useful in different situations. Scala unifies functional programming and object-oriented programming nicely. It runs on the JVM. You should have a look. http://scala-lang.org .

http://weblog.raganwald.com/2007/02/hof-or-oop-yes.html

The thing is, after you have read the for loop version many times, it
becomes just as easy to read. You see it, you *know* what it is doing,
and you sort of tune out the boilerplate, and just see the code that
is actually doing the work.

Once that has happened, does the difference in code size between

return list.mappedWith({
String s => s.toUpperCase()
});

and

List newList = new ArrayList();
for(Iterator iter = newList.iterator(); iter.hasNext(); iter.next()) {
String element = (String) iter.next();
newList.add(element.toUpperCase());
}
return newList();

really make it worth the complexity of not being able to see inline
what the mappedWith() function does?