> Rule of Diversity: Distrust all claims for “one true way”.
Although, does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ?
> Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
I wonder what rob pike has to say about OOP or java, I wish I could listen to it.
Also it says that text is a good representation of data, but I think he meant it as intermediary. I don't think xml or html are really good choices when you see all the CPU cycles spent parsing those.
> Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
I prefer this rules versus the "no premature optimization" rule.
“Object-oriented programming is an exceptionally bad idea which could only have originated in California.” – Edsger Dijkstra
“The phrase "object-oriented” means a lot of things. Half are obvious, and the other half are mistakes.“ – Paul Graham
“I used to be enamored of object-oriented programming. I’m now finding myself leaning toward believing that it is a plot designed to destroy joy.” – Eric Allman
“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” – Joe Armstrong
When I see the never end complaints about object-oriented programming, I'm reminded of Bjarne Stroustrup's quote "There are only two kinds of languages: the ones people complain about and the ones nobody uses." I think that applies equally well to software design concepts.
> does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ?
The irony is that Python has more ways of doing things in general and often the choice is very much non-obvious, compared to a language like Ruby which is supposedly embracing TIMTOWTDI. In other words, that Python rule doesn't match reality and I've always found it funny.
Is it the Python language or the Python ecosystem you are referring to?
The statement in question is from The Zen of Python and is more of a guiding principle for the design of Python than a rule.
The usual observation with Python is that it can have many libraries and frameworks which are quite similar and choosing one can be hard (e.g. web frameworks). This is a function of popularity and not something which can fairly be subject to that principle.
On a different note: missing is the Zen of Python's following line:
Although that way may not be obvious at first unless you're Dutch.
The language itself is a prime example of a language with features that aren't orthogonal. For example count how many features in Python are solved in other languages just with proper support for anonymous functions.
Python's support for closures is perfectly fine. Its anonymous function support is crappy, but it doesn't stop you from doing what you want, it just looks as ugly as sin.
Python only lets you have one line in a lambda - the return line. In languages with nicer anonymous function support I can make an anonymous function span multiple lines and branches eg. in C# you could assign to a delegate something like myObj.stringToHash = (s) => {int x = 0; foreach(var c in s) x += ... ; return x;}
I find python's restriction in this case fairly strange. If I wanted to do that in python I'd have to just declare a function body for what I want to put in the anonymous function elsewhere, which defeats the purpose.
The major difference is you do the function definition just prior to the assignment. The "namespace pollution" is literally limited to the scope of "some_method", so you have an extra local var in a function somewhere. The semantics of python mean that the function is created on the stack, and a closure is created each time the some_method is called, and the closure is later GCed as any other object would be, so there is nothing fundamentally different about the "named" function, and the "anonymous" function in you example, except a single local variable.
Perl is arguable much closer to the Unix philosophy than Python, for better or worse. That said, the "One obvious way" in Python is not exactly the same as "Only one true way".
The rule of composition is an important counterpoint to the rule of diversity. Unix's most important feature is treating everything as a file. That interface allows a lot of freedom in composition, but every process has to conform to exactly the same interface. Perhaps not surprisingly, TCP's stream-based interface has also allowed a great deal of freedom in composition in networks.
"Although, does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ?"
I don't think so. To me Python's design rule implies there should be one way clear path to solve a specific problem and generally you'd also want to stay as consistent as possible with other similar solutions.
The "one true way" argument is to force everything to fall into a pattern even when it's a less than ideal way to solve a problem. An example would be trying to force everyone to use the same language/database/framework combination in a company for everything. Sometimes you want to be flexible and use the right tools for the job (while also accounting for the cost of deviating from the general accepted standard in making that decision).
Funny how HNers have such a high regard for his opinion on a domain he is well known for being sceptical and yet disregard his opinion, as UNIX co-author, that UNIX is well past its due date and is time to move on.
Except he contributed to many of the userland tools and was part of the UNIX working group, which does make him a co-author, even if he didn't wrote the first kernel lines.
I must admit you have a strange way to ignore Pike's contributions to UNIX initial GUI architecture, his book together with Kernighan about the UNIX programming environment and other contributions.
That's where we disagree. You think Blit is one of things what makes UNIX UNIX while I don't. We have different interpretations of "co-author". I don't see any further benefit in discussing that.
Most developers touting OOP don't know those languages; so why should we care what their opinions are concerning OOP as a paradigm.
If you exclude one person because they disagree with X and don't know Y, then you must equally disregard all who agree with and disagree with X, because they don't know Y. Otherwise you're just cherrypicking :)
Fine by me, since those developers are doing so on behalf of systems like Java and Python, which fall far below the mark.
However, it has become quite trendy to bash OOP itself, especially here on HN, without acknowledging that there are less awful ways of doing it that just aren't mainstream. Try making similarly blanket criticisms of FP here using Python (Why, it has lambdas and list comprehensions after all--isn't that enough?) or some other impure language and see what happens.
> Rule of Diversity: Distrust all claims for “one true way”.
Although, does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ?
> Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
I wonder what rob pike has to say about OOP or java, I wish I could listen to it.
Also it says that text is a good representation of data, but I think he meant it as intermediary. I don't think xml or html are really good choices when you see all the CPU cycles spent parsing those.
> Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
I prefer this rules versus the "no premature optimization" rule.