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:

1. StreetNo (int)--which screws up when it is '221a'--despite that you never perform math with street numbers.
2. First line (char80) -- In the UK this is streetname; in the Netherlands it is the Town.
3. Second line (char80)
4. TownOrCity (char40) -- what if I live in a village or hamlet or on an island?
5. County/State/Region (char40)-- Um. Monaco (or Andorra).
6. Country (char20) -- Monaco (Andorra).
7. ZIPCODE/POSTCODE/ (char8) -- Just too damn bad if you live in Iran with their 10 digit post codes.

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.

• I believe that understanding how the mechanics of OO works is very important when it comes to debugging.

  Working out why your code is producing weird results, because you've derived from two classes that have a common method name, if you don't understand the mechanisms of inheritance, is almost impossible. And Perl's 'native OO' gives you a better insight to that than just about any other language I'm aware of.

  But it is far too easy to get wrapped up in the details of those mechanisms, and loose sight of the overall problem you are trying to solve. And that can lead to OO myopia. To the concentration upon writing good OO at the expense of solving the overall problem cleanly, efficiently, and maintainably.

  I think that OO-spaghetti is far harder to debug than procedural spaghetti. And that these days, OO-spaghetti is far more prevalent simply because the problems with gotos and globals etc. are very well known and talked about. But everything OO feels like you're doing the right thing.

• I think if you need to get something going quickly, you'll probably get there quicker with Moose than without it. And most of the time it will probably work.

  But without the grounding of understanding what Moose is doing for you under the covers, when it goes wrong, whether through your fault or theirs, you'll be up shit creek without a paddle.

  I also think that Moose comes with an agenda and an underlying philosophy that means if that is your first experience of OO, you're likely to find yourself bewildered and confused if you have to move away from that to (say) Java, C++ or JS.

  It may also lead to the same kind of OO myopia I mentioned above.

• Whether you will find the performance of Moose limiting will very much depend upon the type of programming you do.

  If everything you do is IO-limited, perhaps not. If you write anything that is CPU-bound for more than a few minutes, you'll definitely notice it.

  The problem is that it isn't really possible to just re-write the slow bits of your Moose application in Inline::C or XS, because the overhead is not in your code, but in the (now hidden) mechanics of the OO itself.

  OO encourages the use of myriad small methods calling other methods calling other methods. Put those in loops--and all CPU-bound code involves loops--and you multiply the cost of Perl's sluggish function calls over and over. Be overzealous with your parameter validation, add in a little runtime introspection, and you are going to notice.

  And once you notice, you might be tempted to measure. And once you measure, you might find yourself wondering what all that overhead is buying you.

• If you have the time, or the inclination to make the time, then I seriously doubt that you would ever regret learning enough Eiffel to get you through--the first few chapters at least--of OOSC.

  I also seriously doubt many people will move over to Eiffel as their main or only language; or even use it for paying commercial work. But like those that got to grips with Lisp early in their careers say, it will influence everything you write from then on, whatever language you write it in.

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.