OO That Looks Like Procedural Programs
I wrote this to a couple of people on a private mailing list I am on:
"OO has never lived up to the potential for me, for precisely the
reason that most 'OO type' work I do (mostly via web apps) all tends to look like
procedural applications just with OO constructs around it. Get rid of
the OO constructs, and you pretty much got the same program, just
without the OO overhead. So why should I bother with OO? This is one
of the motivations that led me to functional programming. All the good
practices that is present OO still stand (like hiding implementation
from interface, the use of opaque values (related with the first one),
polymorphic functions), but it just doesn't think it is necessary to
bind data and bahavior together. Higher-order functions seem, right
now, to make sense more, for reusability purposes now than through
inheritance (ask my opinion on it after I developed some non-trivial
stuff with functional languages :))"
I worked in Rails and I played with Python a lot in these areas. My belief stems from this change in perspective:
Objects in Python are glorified dictionaries, or dictionaries with OO logic. If inheritance is necessary, then the OO logic is useful. But, eh ... I don't use inheritance. At most, I use tables to inherit similarities, using joins to accomplish that type of goal. I don't know what other people do, but I never used inheritance in such a grand way to actually see a use for it.
So, looking at something like ErlyDB, and its simple use of tuples, confirmed my point. I just got lazy a little.
The question is: is there anything special when it comes to merging data and functions together. For what I do, I just can't see it.
I said in the first tutorial that ErlyWeb (+ erlhive, but I haven't had a chance to look at that yet) is a Rails killer. Let me elaborate on that. It might not be flush with so many features as Rails does, but the constructs are much more simpler in ErlyWeb. The thing is that ErlyWeb is not this big opaque library of magic tricks; it doesn't need to be, no matter how many "opinions" are shoved into it.
But I think this pretty much reflects not so much the capabilties of a language, but the opinion of the language community. Where Rails says "you are stuck with the whole methodology that Rails has to offer", ErlyWeb should say "here is a few interesting tools to get you moving - other than that, everything is pretty much intuitive after that" This is why I think it could draw people to Erlang. I like that.
"OO has never lived up to the potential for me, for precisely the
reason that most 'OO type' work I do (mostly via web apps) all tends to look like
procedural applications just with OO constructs around it. Get rid of
the OO constructs, and you pretty much got the same program, just
without the OO overhead. So why should I bother with OO? This is one
of the motivations that led me to functional programming. All the good
practices that is present OO still stand (like hiding implementation
from interface, the use of opaque values (related with the first one),
polymorphic functions), but it just doesn't think it is necessary to
bind data and bahavior together. Higher-order functions seem, right
now, to make sense more, for reusability purposes now than through
inheritance (ask my opinion on it after I developed some non-trivial
stuff with functional languages :))"
I worked in Rails and I played with Python a lot in these areas. My belief stems from this change in perspective:
Objects in Python are glorified dictionaries, or dictionaries with OO logic. If inheritance is necessary, then the OO logic is useful. But, eh ... I don't use inheritance. At most, I use tables to inherit similarities, using joins to accomplish that type of goal. I don't know what other people do, but I never used inheritance in such a grand way to actually see a use for it.
So, looking at something like ErlyDB, and its simple use of tuples, confirmed my point. I just got lazy a little.
The question is: is there anything special when it comes to merging data and functions together. For what I do, I just can't see it.
I said in the first tutorial that ErlyWeb (+ erlhive, but I haven't had a chance to look at that yet) is a Rails killer. Let me elaborate on that. It might not be flush with so many features as Rails does, but the constructs are much more simpler in ErlyWeb. The thing is that ErlyWeb is not this big opaque library of magic tricks; it doesn't need to be, no matter how many "opinions" are shoved into it.
But I think this pretty much reflects not so much the capabilties of a language, but the opinion of the language community. Where Rails says "you are stuck with the whole methodology that Rails has to offer", ErlyWeb should say "here is a few interesting tools to get you moving - other than that, everything is pretty much intuitive after that" This is why I think it could draw people to Erlang. I like that.
posted by a at 9:43 AM
4 Comments:
Hi.
for me the best advantage of OO in python is not inheritance at all .. but namespaces. the relevant data and functions are packaged together in one simple namespace. in my experience it has made my code much more reusable. i usually start out writing simple functions and then as i go along arrange them into classes with the data.
rahul
hi.
forgot to mention that higher order functions are there in python too. so you can use them as well. its not a either/or issue. you can use both when you need them. depends on the use really.
i would say both paradigms have their uses and its nice that in python you can use both.
rahul
> The question is: is there anything special when it comes to merging data and functions together. For what I do, I just can't see it.
1. It makes is easier to organize your code.
You can look at a class and know not only what data it holds, but most of the ways that data is typically used.
2. It allows for inheritance.
For good main-line programmers, inheritance is very rarely used. You don't have a LameDuck class inheriting from Duck class, you have one class with a IsLame property.
On the other hand, inheritance is very, very important for framework developers. Toolkits like WinForms leverage inheritance very heavily because otherwise there would be a ton of duplicated code.
I believe assumptions drive development of products. If we assume inheritance, then it will be important for the development of a product (yes, like WinForms). Assuming that code and data work best together is another strong assumption.
However, the subjectivity is not a scientific measure. The fact is that wherever you put your data in context of your functions is a matter of being concious of the implications of that design. OO won't help you there.
And, yes, Python has higher-order functions. But I haven't seen many interfaces that use that as a main code reuse tool in Python. Am I wrong here?
Post a Comment
<< Home