good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Or, should I chuck it all Learning a new language, especially in order to become familiar with a new paradigm, does not imply that you forget or stop using what you already know. Not even vaguely. Over the last 8 years I've experimented with a variety of FP languages--Haskell, Caml, Mozart/Oz, Erlang, Q/Pure amongst others--specifically to get a handle on FP. And I believe that those efforts have greatly benefitted my approach to solving some types of problems. But I still use Perl as my first choice when I need to get something done. And revert to C when I need to do (parts of) it more quickly. I encountered Eiffel--actually an OU teaching variant call Small Eiffel--and OOSC when mentoring a mature OU undergrad, 15 or so years ago. I'd done various forms of OO programming before that, including some fairly in-depth (v.large project; huge overall system complexity) in C++. My C++ skills were rated (by others) as "above average"; but I hated it! I hated it because nothing was simple; nothing was intuitive; nothing was elegant. Nothing ever seemed to be really "right". There were always compromises. Too many compromises. Even as we were gathering the plaudits for a job well done, having met all the requirements & performance criteria; and passed all the tests. The customer had signed off and agreed to completion bonuses. I still had nagging doubts. And I was not the only one on the team with them, though we mostly kept them to ourselves. It wasn't until I read OOSC, and worked with Eiffel that I understood why. The 'add-on' nature of C++, especially back then, means that it is not just far too easy, but you are actively encouraged, to think of OO as a way to create a convenient set of name-spaces in which to stick your data and subroutines. And for large numbers of OO programmers in many languages, that is pretty much all they get from OO; and they are happy that way. What Meyer taught me was that OO is far less about the mechanics of hiding your data & methods behind name-spaces; and far more about modeling your application in its own terms. Sorry for the emphasis, but its an important point that I will strive to explain. Far too often, classes and class hierarchies are modelled around concepts like numbers(subdivided into integers and reals(further subdivided into 8/16/32/64-bits etc.), strings(subdivided into various fixed and variable lengths), Persons(subdivided into employees, customers; and then managers etc.), polygons(subdivided into squares, circles etc.). And each of these low-level classes are written (or supplied or bought in as libraries) to be complete. So numeric classes not only know how to add, subtract, multiply, divide and compare themselves; but also how to integrate and differentiate and calculate Bessel functions et al. that a complete math library should. The problem is, at the top levels of any particular application (suite), the entities required are hybrid. The data comes into the program in a file that contains strings. Within those strings are names, ages, addresses, zipcodes, versions, dates, times, places, quantities in a variety of units, sounds, colors, distances, routes, feelings, truths and speculations. And those high-level entities are constructed--through composition or multi-inheritance--from a rag bag of the low-level entities. And so you end up with things like: Addresses split into:
Personnel applications where job description is an attribute of the Employee, when the jobs are the constant and the people come go and move. Version number stored as floats. And each of those objects brings in huge chunks of the underlying class library code that the application will never use. Eg. You'll never need to run a Bessel function on a version number. And with it, you get a whole bunch of parameter validation at each of those lower levels that is (should be) redundant, because the higher level composing classes perform their parameter validation where it should be done--on input. To answer your 3 questions.
The (my) bottom line. If you have the time, try all three: Perl basic OO; Moose; and Eiffel+OOSC. If you don't have the time, make the time. If not now, then over the next few weeks or months. Each will benefit you. If I didn't know PBOO, and had to get something together now. I'd go the Moose route. But I'd stick to the Moose basics, and not get caught up in trying to use every bell and whistle. I'd use only what I needed. To avoid lock-in and overhead. And then make the time to go back and try the other two. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
In reply to Re^3: kind of effort required for learning OO perl ?!
by BrowserUk
|
|