[ruby-core:34789] Re: [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?

On Thu, Jan 20, 2011 at 06:30:29PM +0900, Zeno Davatz wrote:
> Issue #4239 has been updated by Zeno Davatz.

Dear Zeno,

Thank you for your deep concern and support of making it easier to
move from Ruby 1.8 to Ruby 1.9. I understand that major breakage can
be very frustrating and people tend to then generalize things.

I hope I can be of help by reducing the amount of effort put into this
discussion and come to quick conclusions. I see that most (if not all)
people on this list are more clever and knowledgeable than myself.
And also extremely helpful and responsive, respectful, polite and
direct. I hope I can learn the same.

This is why I trust the core team with almost all the technical and
political decisions, changing my code and habits to adapt. Unless
something obviously wrong comes up (e.g. a segfault).

I also feel assured that any risky proposal will quickly be noticed by
the many experts subscribed to this mailing list. I also trust that
any changes breaking compatibility are well thought out, and after a
lot of digging, they always turned out for the better (like m17n, for
example).

As I continue to read messages from this list, my respect for the
whole community continues to grow.

With so much happening in the programming world today, keeping Ruby a
great language to use (the goal) probably requires more work and
sacrifice, than it probably seems from the outside. I personally would
at least prefer to "stay out of the way" if possible.

I understand that you can be frustrated with the amount of costs
necessary to "port" an application from Ruby 1.8 to the 1.9 -
intentionally a different "dialect" if you will.

So, please allow me to respectfully disagree with you, on issues which
(IMHO) are not really aligned to the philosophy of Ruby or even
related to Ruby itself. 

  - comparing Linux kernel development with Ruby doesn't make sense
    (comparing with GCC/c++0x would more likely make much more sense)
    Elaborating on this within this list would be pointless, but feel
    free to contact me if you want an explanation. 

  - arguing that consistency and compatibility is very important from
    Ruby core-devs point of view, instead of treating it as a specific
    problem specific to you and your business (e.g. agile
    methodologies promote "embracing change" as a solution)

  - stating modularity of microkernels as a better way of adding
    changes, instead of allowing more modularity in your own
    applications the amortize long term changes in Ruby. Basically you
    should have a compatibility layer over *every* assumption about
    external library and behavior that can change during your
    product's lifecycle

  - expecting additional compatibility work from core team to reduce
    your own business costs, that could have been avoided by the same
    things I try to do, which are:

      - follow Ruby core list to discover incompatibilities years
        before they become official

      - work on and experiment with ruby-head to mitigate business
        risks before you are left with broken software and missed
        deadlines.

      - ask about breakage as soon as it happens (test trunk versions
        of software critical to your business for early warnings)
      
      - use extensive test suites (TDD, BDD) which allow you to make
        drastic adaptations while minimizing quality impact - even
        when outsourcing

      - strategic thinking when selecting a language for critical
        projects (maybe JAVA or COBOL would be better - they survived
        a very long time and many corporations still rely on them)

      - not giving a reason *why* you *must* switch to Ruby 1.9 (or
        forgive me if I missed it, but you should have made it more
        clear than comparisons with kernel development)
      
  - not providing patches, fixes and concrete examples/problems but
    instead expecting core team do something that is a complete waste
    of excellent minds: 'maintenance' work, that is actually your
    responsibility towards your own clients.

> Yes, Ruby is "cool" but in my respect it cares to much about the
> coolness and the HIP-Style and not enough about consistency. 

  I see Matz providing the next generations of software developers
  with tools they enjoy and make them productive for any worthwhile
  project - corporate or not. I believe this goal is unique among
  languages.

  In my opinion, focusing on realizing visions of a great future,
  while sacrificing near-team goals denotes *strategic thinking* that
  require great resources, determination and obviously, knowledge. 

  Something to be envied by corporations and businesses. And not waved
  of as a pursuit of "coolness" or being "hip".

> The bigger your App grows the more important consistency is.

  And over the years, the more difficult it will become to hire great
  individuals that would prefer to maintain an obsolete project
  instead of rewriting it from scratch in less time using advanced
  languages and tools designed specifically with that in mind. 

If you would want to continue this discussion outside this list, I
would be more than happy to provide you with what little advice and
feedback I can. This includes cases where I have misunderstood or need
to be corrected.

Otherwise, I would prefer to leave non Ruby-development discussions
from distracting others away from the important issues that are being
solved. And to prevent opinion wars from flooding this list. 

I hope your bad experiences will pale in comparison to the benefits
you have gained from choosing Ruby.

And I apologize to everyone on the mailing list if I went to far with
my reply or its length. 

Cheers,

Cezary

-- 
Cezary Baginski