Facilitating the Spread of Knowledge and Innovation in Professional Software Development
Write for InfoQSee what’s next in Large Language Model (LLM) architectures used in tools like ChatGPT.
Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or get video-only pass to recordings.
Discover new ideas and insights from senior practitioners driving change in software. Attend in-person.
Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.
InfoQ Homepage News InfoQ Article: Will the Enterprise change Ruby, or will Ruby change the Enterprise?
Ruby is often criticized for lacking the features required for developing large applications and maintaining them over long periods of time with large teams. Are we missing something fundamental for widescale adoption of Ruby in the enterprise?
Read Will the Enterprise change Ruby, or will Ruby change the Enterprise?
Community comments
Enterprise Ruby
by paul browne,
Versioning, SOA, and duck typing
by Evan Leonard,
Re: Versioning, SOA, and duck typing
by Sam Wilson,
interesting pov
by Alex Popescu,
RE: Will the Enterprise change Ruby, or will Ruby change the Enterprise?
by Lasantha Kularatne,
OO/Java stagnation
by Bill Culp,
Re: OO/Java stagnation
by Jonathan Allen,
Enterprise Ruby
by paul browne,
Your message is awaiting moderation. Thank you for participating in the discussion.
Good post , especially given that with the latest release of JRuby, Ruby on rails effectively can run in an existing JVM (an easier path into to enterprise than 'install this new bit of software').
To expand an underlying theme of this post. 6 or 7 years back , Java was the domain of alpha-geeks - the early adopters that 'did things right'. Later , Java went mainstream with people 'who just got things done' - not a bad thing , but not pretty code. Ruby is probably going to follow the same path.
Paul , Technology in Plain English
Versioning, SOA, and duck typing
by Evan Leonard,
Your message is awaiting moderation. Thank you for participating in the discussion.
Service versioning is certainly a problem that requires attention. The mix of duck typing and meta-programming within ruby does make it a candidate to solvoe this problem. However, I know others in the strong-typing camp that have plans to make ML rise to the top to solve difficult problems than these. Although ML has a way to go to gain the wide exposure that Ruby has earned in the last few years.
I would like to see competing solutions posed by both of these camps. The results would benefit all!
Re: Versioning, SOA, and duck typing
by Sam Wilson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I like ML, but it'll never be a mainstream enterprise language.
It's just too much of a stretch from how must people learn programming (functionally). Widespread adoption of ML would require changes to the basic CS curriculum and years of work before there are sufficient numbers of quality developers to make it a viable solution for any large business.
interesting pov
by Alex Popescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
Very interesting point of view. I have, though, some comments.
I haven't been reading (or hearing) this argument for quite a while (many years ago, it was one of the most used arguments when people were discussing about C/C++ and Java). After all these years of Java, I would tend to completely disagree with it. If somebody is gonna write bad/sloppy code, he will do it in any PL. Moreover, I guess we should move to PL/development that allows us to work on the important aspects of the systems we are building and not manage repetitive and small details each and every day. IMO, this all comes down to productivity.
I agree with you, and I am not sure there are so many people suggesting changes to the language itself. What I have noticed being around Ruby for almost 2 years is the need for specialized tools that are perceived as absolutely necessary when talking about adopting a new direction (f.e. decent debuggers, etc.). Other than this, Ruby is a nice thing happening to developer's world.
./alex
--
.w( the_mindstorm )p.
RE: Will the Enterprise change Ruby, or will Ruby change the Enterprise?
by Lasantha Kularatne,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is a good analysis of Ruby. I think Ruby should evolve more. The reason why Java captured the market so heavily was because of its powerful collection of libraries come with JDK. And when it comes to the large enterprise developments, its ability to handle multithreaded aplications and concurrency made Java to grab that share of the market. So I wonder how Ruby can atack these areas.
Lasantha Kularatne
University of Texas at Austin
OO/Java stagnation
by Bill Culp,
Your message is awaiting moderation. Thank you for participating in the discussion.
Off the SOA track a bit. The disappointment with Java can be summed up in that OO patterns even when combined in frameworks have not proved sufficiently effective in easing the pain associated with building large systems.
Whats the difference between doing byte code manip and simply using libraries? (The POJO approach) Both avoid all OO techniques of inheritance and encapsulation and polymorphism. The core of OO has not proved especially valuable in years of Java development aside from the idea that a domain model is a good thing.
"I've been thinking a lot about building a distributed object framework in Ruby, that would provide a range of system services to plain old Ruby objects and objects written in other languages."
Thats library speak right there. So we are taking a step back.
And thats OK as long as we all ackowledge that the happy OO path we were on has reached a dead end at least in Java even with AOP on top.
Ill conceived? Maybe...Java permits polymorphism using multiple interfaces but I cant implement Map and List in the same class.
Theoretical notions aside how well thought out is that notion?
Not very. Maybe SUN underestimated the importance of hybrid collection types or maybe static typing is not the way to go.
But given that SUN cant even plan an interface correctly that is going to be in use for many many years by thousands of programmers maybe design by contract is a bit stuffy.
Re: OO/Java stagnation
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
I find it hard to believe those boneheads still haven't fixed that. That bug was reported back in 1998.
Can't implement Map and List in the same class because of remove(Object) method
Instead of acknowledging the underlying problem with their interface implementation syntax was broken, they just blew-off the bug that uncovered it. What about all the other cases where a class needs to implement two interfaces that may have overlapping methods?
I still believe in OOP and static typing as techniques. What I don't agree with is Java's narrow-minded obession with pure OO code (as they define it) or their insistance that you only do things their way.