Artima Developer Spotlight Forum - Are Ruby's Open Classes a Poor Fit for Large Projects?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Artima Developer Spotlight Forum
Are Ruby's Open Classes a Poor Fit for Large Projects?

51 replies on 4 pages. Most recent reply: Sep 1, 2006 3:33 PM by Joao Pedrosa

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 51 replies on 4 pages [ « | 1 2 3 4 ]

Andrew Norris

Posts: 8
Nickname: wanorris
Registered: Aug, 2006

Re: Are Ruby's Open Classes a Poor Fit for Large Projects?

Posted: Aug 29, 2006 12:00 AM

> Instead of trying to spread your dogma, why don't you look
> at this side by side comparison of Python and Ruby:
> http://www.dmh2000.com/cjpr/cmpframe.html

Perhaps I missed it, but where does this article substantiate what seem to have been your main insinuations up until now:

(1) Ruby's syntax is not now and was never influenced in any way by Perl, and anyone who claims otherwise is a vicious partisan.

(2) There are no syntactic or conventional differences between Ruby and Python that would lead any group of users to prefer one of the languages over the other.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Are Ruby's Open Classes a Poor Fit for Large Projects?

Posted: Aug 29, 2006 1:32 AM

Declaration of object attributes/methods determine public accessors for such variables in Ruby, while in Python you may create an object attribute on the fly, like in a mistyped variable. Let me try it:

a) Python:

>>> class Foo:
... pass
...
>>> o = Foo()
>>> o.bar = 10
>>> print o.bar
10
>>>

b) Ruby

b.1)

irb(main):001:0> class Foo
irb(main):002:1> end
=> nil
irb(main):003:0> o = Foo.new
=> #<Foo:0xb7e02ad0>
irb(main):004:0> o.bar = 10
NoMethodError: undefined method `bar=' for #<Foo:0xb7e02ad0>
from (irb):4
from :0
irb(main):005:0> print o.bar
NoMethodError: undefined method `bar' for #<Foo:0xb7e02ad0>
from (irb):5
from :0
irb(main):006:0>

b.2)

irb(main):001:0> class Foo
irb(main):002:1> attr_accessor :bar
irb(main):003:1> end
=> nil
irb(main):004:0> o = Foo.new
=> #<Foo:0xb7dd8f40>
irb(main):005:0> o.bar = 10
=> 10
irb(main):006:0> print o.bar
10=> nil
irb(main):007:0>

I prefer Ruby's version. It seems more explicit and clearer and a nicer convention overall. How is that for a language that does not have the slogan of being as explicit about things as Python does? Can you imagine thousands of lines of Python where if you mistype a variable like that you may cause some bug? Also, note that Python could break backwards compatibility and fix it, but is that desirable? Even if you have a way to trigger some warning, it's still a matter of not being explicit in the declaration of the attribute that's the problem.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Are Ruby's Open Classes a Poor Fit for Large Projects?

Posted: Aug 29, 2006 1:44 AM

Also, Python's indentation is an inviting for bugs caused on purpose or not.

Taking the chance:

"If you think the Ruby is ideal for environments with high turnover and dozens of programmers, some of which may be incompetents or even saboteurs, please elaborate."

Can you imagine what those folks could do with Python's indentation? :-)

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: Are Ruby's Open Classes a Poor Fit for Large Projects?

Posted: Aug 29, 2006 8:16 AM

> Instead of trying to spread your dogma, why don't you look
> at this side by side comparison of Python and Ruby:
> http://www.dmh2000.com/cjpr/cmpframe.html

That is really bad Ruby style.

This:

def find(key)
  result = nil
  if (key == @val) then
    result = self
  elsif (key < @val) then
    result = @left.find(key)  unless left.nil?
  else
    result = @right.find(key) unless right.nil?
  end
  return result
end

Should be (untested):

def find(key)
  if key == @val
    self
  else
    leaf = (key < @val) ? @left : @right
    leaf.find(key) unless leaf.nil?
  end
end

Also (from the article): "11. lack of multiline comments in Python/Ruby was annoying" is false, Ruby does have multiline comments.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Are Ruby's Open Classes a Poor Fit for Large Projects?

Posted: Aug 31, 2006 12:36 AM

> It's too early for anyone with a sizable investment in
> other tools to just cut everything over and move to a
> dynamic language.

Given that both Perl and Python predate Java, what would you define as "too early". Alternatively, when would you consider it to be no longer too early.

Mike O'Keefe

Posts: 16
Nickname: kupci2
Registered: Mar, 2005

Re: Are Ruby's Open Classes a Poor Fit for Large Projects?

Posted: Sep 1, 2006 1:55 PM

and the question is about
> > long
> > > term projects and the whether or not stability can be
> > > achieved with non-static objects.
>
> This is a question you have? Seriously? There are a LOT
> of long term large scale systems written in dynamic

But Smalltalk is a entirely different language. [And as an aside, so many folks like Bruce Tate do not understand, Java is actually very close to Objective-C and Smalltalk (and *not* C++.] Surely we can find some large Ruby apps, given it has been around quite some time?

>
> These are not small systems. This entire thread is fear
> mongering from the C++/Java bigots.
>
And whining from Ruby zealots ;)

(And it's quite amusing to see the Python vs. Ruby slams also)

Anyway, it's a good question. So far I haven't seen a good answer. Along with good coders, good frameworks might help, facilitating good coding practices. But then see the point below.

Now, here's another question along similar lines, which speaks to the philosophy behind a language like Ruby, which again I think is a legitimate subject for discussion, no need for flame wars.

We've all been impressed by the Rails framework, the killer app for Ruby. But in this blog, the author "rails" against the users, telling them to stop using instance variables they didn't create, which, seems to me to support the argument the original poster is making:

http://glu.ttono.us/articles/2006/08/30/guide-things-you-shouldnt-be-doing-in-rails

Now, to play devil's advocate, is this simply Beta version 1.0 blues, where we never expected Rails would hit the trails as it did, and thus would've coded it much more differently? Or is this a design flaw in the language itself, which makes designing APIs and frameworks very difficult?

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Are Ruby's Open Classes a Poor Fit for Large Projects?

Posted: Sep 1, 2006 3:33 PM

"Now, to play devil's advocate, is this simply Beta version 1.0 blues, where we never expected Rails would hit the trails as it did, and thus would've coded it much more differently?"

Or is it a known issue, and whatever language/framework/library might have their own issues as well?

"Or is this a design flaw in the language itself, which makes designing APIs and frameworks very difficult?"

I don't think so, having designed some of my own. Now if the question is changed to "which makes designing APIs and frameworks very __easy__?"

That may be a problem, though evolution has taken care of the unpopular things for you so you are guaranteed to use the "best" evolved approach, by whatever metrics the __environment__ chooses. :-) Aren't popular things super evolved or what? :-)

Flat View: This topic has 51 replies on 4 pages [ « | 1 2 3 4 ]

Previous Topic

Next Topic