Today I've started investigating this ruby/rails thing. Love the
concept. Worked for many years in java projects and am constantly
frustrated by the number of times i configure the same old frameworks
and components.
A concern I have with java which i'd hoped Ruby would solve is class
versioning. In java we're often confronted by cryptic errors due to
conflicts in the versions of required libraries. Spring-1.0.0 needs
commons-1.0.0 but hibernate-1.2.2 wants commons-1.1.0. You select
commons-1.1.0 because it's the best option you have but the new version
breaks an interface contract in some minor way and suddenly you've lost
a week of work!
Today I've started investigating this ruby/rails thing. Love the
concept. Worked for many years in java projects and am constantly
frustrated by the number of times i configure the same old frameworks
and components.
Java certainly looks a lot more engineered compared to Ruby. If that haunts you in the Java world you will feel a lot more at home here. OTOH complex systems are - well - complex. So if you build the same thing in Ruby it will have similar complexity. Although some things are significantly less verbose in Ruby because of the dynamic nature and absence of static typing.
A concern I have with java which i'd hoped Ruby would solve is class
versioning. In java we're often confronted by cryptic errors due to
conflicts in the versions of required libraries. Spring-1.0.0 needs
commons-1.0.0 but hibernate-1.2.2 wants commons-1.1.0. You select
commons-1.1.0 because it's the best option you have but the new version
breaks an interface contract in some minor way and suddenly you've lost
a week of work!
Does Ruby have a mechanism for avoiding this?
Not directly but please note that because of Duck Typing (and hence lack of interfaces) the issue is less dramatic in Ruby. And since many Gems are Ruby only you even have the option to fix them yourself.
Judging from this forum's history the issue you are bringing up does not seem to be prevalent. I suggest you put your worries aside for the moment, try it out and see how it goes.
Thanks Robert. Be interesting to see how it pans out once I start using
Ruby in anger. I figure rails "convention over configuration" will
reduce the combinations so hopefuly that practice alone will be enough
to reduce the issue to a point where it's no big deal.
In thinking about it the issues in the java space (and particularly with
spring) are often more to do with tutorials, examples and documentation
that rely on particular versions of components. In a mature enterprise
codebase you don't have the luxury of using only the versions the
examples support.
I suppose that's just part of life as a software developer!
A concern I have with java which i'd hoped Ruby would solve is class
versioning. In java we're often confronted by cryptic errors due to
conflicts in the versions of required libraries. Spring-1.0.0 needs
commons-1.0.0 but hibernate-1.2.2 wants commons-1.1.0. You select
commons-1.1.0 because it's the best option you have but the new version
breaks an interface contract in some minor way and suddenly you've lost
a week of work!
Hi Tim,
I have worked in Java for years, and I am familiar with the versioning
issues of which you speak. Strictly speaking this is library dependency
versioning. Things like dynamic typing in Ruby provide powerful tools for
assisting library compatibility, and these tools compound in value with
scale. The only time I ever have library versioning issues was when you are
dealing with very complicated dependency trees (DataMapper 0.10.x and its
dependency trees of adapters etc. on unusual platforms like JRuby or Heroku
comes to mind).
I can recall the simplest dependency chains being upgrade hell in Java.
But I have never noticed his problem being significant in Ruby.
···
On Sun, Nov 14, 2010 at 11:25 AM, Tim D. <timdeboerz@gmail.com> wrote:
Thanks Robert. Be interesting to see how it pans out once I start using
Ruby in anger. I figure rails "convention over configuration" will
reduce the combinations so hopefuly that practice alone will be enough
to reduce the issue to a point where it's no big deal.
