Hi All
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!
Does Ruby have a mechanism for avoiding this?
Thanks
Tim
On 14.11.2010 00:02, Tim D. wrote:
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. 
Kind regards
robert
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!
On Sun, Nov 14, 2010 at 11:25 AM, Tim D. [email protected] 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.
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.
Tim D. wrote in post #961268:
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?
Does bundler do what you want?
http://gembundler.com/