BT

InfoQ Article: Will the Enterprise change Ruby, or will Ruby change the Enterprise?

| by Obie Fernandez Follow 0 Followers on Jul 11, 2006. Estimated reading time: less than one minute |

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?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Enterprise Ruby by paul browne

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

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

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

Very interesting point of view. I have, though, some comments.

Java incrementally improves on C/C++ in many ways. But fundamentally, it has a tendency to encourage sloppy thinking among less-experienced programmers, because the language takes care of so many things for you.


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.

[...]but I don't think Ruby should be "improved" to fit traditional large-system methodology. I think the reverse (somehow) is closer to true.


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

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

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

Ill conceived? Maybe...Java permits polymorphism using multiple interfaces but I cant implement Map and List in the same class.


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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT