_______ is Better Than _______
If explicit truly was better than implicit, Python code would look like this:
And let's face it, that's not enlightening to anyone.
StringBuilder s = new StringBuilder()And let's face it, that's not enlightening to anyone.
posted by casey at 4:12 PM
9 Comments:
That's not explicit; it's plain redundant.
Simple is better than complex.
Sparse is better than dense.
Readability Counts.
There should be one -- and preferably only one -- obvious way to do it.
So I think "explicit" is outnumbered here.
Explicit vs implicit means stuff you need to read the documentation or know the entire program to be aware of.
Imagine a program where suddenly a bunch of objects are used in the global namespace. Where did they come from?
Ah, some inoffensive looking function call imports them there, in other words you need to know about every function to know what's happening.
Another example: an object in a module starts doing something funky, why? the object itself is not failing, the calling code is not failing, ah somebody set up some import hooks that reloads some modules every 5 minutes, again not something you can tell by reading the current function or the current module but the whole application.
*THAT* is evil implicitness.
StringBuilder s = new StringBuilder()
doesn't tell you anything that
s = StringBuilder()
isn't telling you already.
If you really want to be explicit, toss Hungarian notation in there.
As already said this is redundancy, not explicitness.
Oh hai, I think Java is calling.
The Python version is already explicit - adding extra line noise without information is not 'more explicit'.
Saying it's not explicit, it's redundant and that the added declarations in the java code are "line noise" just proves to me that implicit is in the eye of the beholder.
That said, I am certainly not advocating the java style, I was writing it yesterday and was just struck by this line and its explicitness to the point of absurdity. Maybe I need to break it down a bit better. The direct python equivalent of a StringBuilder is StringIO, though in nearly all cases I would just use a list of strings to later join. So In python I would write this instead, assuming I didn't already have all of the pieces to accumulate directly in a list comprehension:
s = []
This has several implicit aspects. For one the variable s itself has no type. In Java I say "StringBuilder s" which states explicitly that s shall only reference a StringBuilder and no other type of object. Python has no such concept, the type of a variable is specified (I would say implied) by its value. At the very least the type of s is not explicitly specified, because there is no way to assign a type to s in Python, you may only assign a value that itself carries the type.
The next thing implied in the Python code is the construction of an object. In Java the new operator is used when instantiating a class. This can be hidden behind a factory method, but it still must occur somewhere in the code. New objects are implicitly created all of the time in Python. This is a good thing, as often in Java you find yourself explicitly newing up temporary object to use ones of its methods and throw it away. In Python just saying [] creates a new list object. The creation of the object is implied. Note that Python has more subtleties here than Java. Some similar operations do not always create new objects. For example assigning () returns a reference to the empty tuple. Since tuples are immutable Python does not need to create a new one every time. Python succeeds in letting object creation be implied because it "knows" when it needs to create one and when it doesn't, the programmer almost never needs to think about it.
The last bit of implicitness in the Python idiom is a bit more subtle. The use of a list in Python is common practice to accumulate a string to later be assembled. Python has a few very useful general-purpose data types that are leveraged for all sorts of duties. Java is littered with hundreds if not thousands of special-purposed data types. A benefit of the latter is that you can see the intent of the code much more explicitly from that one line of Java. If I instantiate a StringBuilder, I'm being very explicit about what I'm about to do, because that's about the only thing I can do with it. In Python I could use an empty list for a billion different things and that one line of code is not going to tell you what I'm about to do. Of course I could have used StringIO, but that's not the way I would write it in real life, because a list is much handier due to its ubiquity and special language support.
IMO Python is a lot less explicit about things than many languages. And if explicit really is better than implicit, I don't want to be better 8^)
Well, whilst I don't agree with everything you say - that last comment is better than the blog entry itself. :-)
If you haven't already you should read Bruce Eckel on the origin of the new keyword in Java (and C#).
Post a Comment
<< Home