I have seen excessive usage of one liners in some high level language code snippets, that’s not wrong at all as long as the programmer has been able to keep the right balance between the code being concise and readable.

Precisely the point I made in the first four sentences of this blog post.

readability of code becomes much more important, especially in the case of high level duck typed languages such as python as compared to other middle level languages such as c++ etc.

Interesting.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.

I look forward to continuing to use reduce in Python 3000 from the functools package, as much as I am likely to also want to use functools.partial. The issue isn’t coolness, it is appropriateness. There are a number of scenarios where as an example, writing a separate function and passing it to another which uses it in a for loop, or in a map / apply / reduce function helps separate different concerns. I fully believe using these capabilities to achieve separation of concerns (where appropriate and applicable) is extremely helpful in terms of improving maintainability and testability of code. In fact in a larger number of cases, I have observed that using functions through such functional constructs helps substantially improve testability. Maybe a 100 line function looks cool when it is similar to a 100 line pseudocode, but break it down and you are likely to get a much better testable software and concise code even though the code may not be as obvious. Decomposition is a matter of taste, judgement and consistency with a set of priorities. I don’t think there is one way which is necessarily superior to another.

Python’s awesomeness lies in the fact that it allows you to write code which is consistent with your design thoughts, philosophies and temporal objectives. It doesn’t require you to choose between object oriented, functional or for that matter even the traditional procedural programming. That diversity is what makes it healthy.

Having said that I do believe, there are likely to be some situations where our opinions may differ.

• I think there are likely to be many situations where brevity increases readability. However that is a possibility not a rule. Brevity could but doesn’t always improve maintainability
• I believe there are more factors than just fealty to pseudocode. Testability and separation of concerns as I mentioned above are some. Improved ability to deal with concurrency might be another.

Python’s awesomeness lies in the fact that it allows you to write code which will be as readable as in pseudocode, or in another words executable pseudocode.
The question one should ask himself while writing code in python should be, is this the way i will explain what the code is trying to do in pseudocode, also does the concept of one liner makes sense in pseudocode as well.

I reread Lau’s post and it isn’t obvious whether he wanted the ordered semantics (per the text), though the code does reflect the ordered semantics. So assuming ordered semantics is required, the second solution would be the way to go.

@Dhananjay: I think you’re solution with Python’s “set” is not comparable to the task described in Lau Jensens ceremony blog post, since “set” doesn’t care about the order of the elements. But Lau’s task was to only “remove duplicats”, i.e. list as input, list as output, no change in the order of the elements left.

Your algorithm changed the order to ‘baz’, ‘foo’, ‘bar’, which would remove the duplicates and changes the order. The same would be true for the Java solution if I wouldn’t use LinkedHashMap instead of HashMap.

Thanks for that nice blog post! I really enjoyed reading it

Yes, am in full agreement on the LOC comment. On the Java HashSet matter, yes thats what a good java programmer would want to do. Though even under a shorter code, the implication of the ceremony (boilerplate) will not be lost. Again goes back to my point of selecting appropriate pieces of code to draw inferences and learnings from.

Dhananjay

Cheers
Stephan

Cheers
Stephan