Large Ruby Apps ?

W

Warren Seltzer

I am coming to Ruby having used the usual list of scripting and C* =
languages. Since Ruby
has such powerful programming features, I think it may be used for some =
really large
system. My decades long observation of software is that small programs =
that succeed
become large programs.

But I am concerned about Ruby's suitability for programming in the =
large. First off, the
lack of the requirement to declare variables sounds like an invitation =
to programming
bugs. It's just too easy to assign something to a misspelling of a =
variable name. Make
the same spelling mistake again and you won't even get a warning about =
an undefined
variable.

For example this 1-line program issues no error:

puts @whatever

This is a code bug that a statically typed compiler would scream about.

-------------------

Also: Is anybody doing a port to 64-bit systems?

-------------------

Also, a history question. With Ruby coming out of Japan, why wasn't =
Unicode support done
earlier? You'd think it would be insulated mono-lingual Americans who =
would delay that...


Warren Seltzer
 
G

Gary Shea

I am coming to Ruby having used the usual list of scripting and C* languages. Since Ruby
has such powerful programming features, I think it may be used for some really large
system. My decades long observation of software is that small programs that succeed
become large programs.

But I am concerned about Ruby's suitability for programming in the large. First off, the
lack of the requirement to declare variables sounds like an invitation to programming
bugs. It's just too easy to assign something to a misspelling of a variable name. Make
the same spelling mistake again and you won't even get a warning about an undefined
variable.

I've only been developing in Ruby for a few months, and in a very limited problem domain. Some years ago I wrote most of a fairly large Perl and Java system, over the course of maybe five years. It was written without any kind of automated testing. That code always made me nervous, although at the time I didn't really understand that there was a way to avoid that.

My recent coding experience with Ruby, written with full
unit/integration/acceptance tests, feels far more solid. At this point
I only have 16K lines of ruby files (meaning of course far less actual
code), but with good testing I do not feel that sense of impending doom
that I have felt before.

The biggest issue it seems to me is tools. I've been writing a lot of
infrastructure tools that aren't available in Ruby, or are only
available in lightweight forms. That can really slow you down!

Gary
 
P

Phrogz

Regarding Unicode - do a bit of googling, and you'll find that not
everyone is happy about it. Including many Japanese. It isn't the
perfect, does-everything solution.
 
J

Joe Van Dyk

Also: Is anybody doing a port to 64-bit systems?

Ruby should work fine on a 64-bit system. At least, I used it fine
for a couple weeks on my A64 running 64bit linux.
 
W

Warren Seltzer

Yeah, but it blows away 7-bit ASCII for i18n work.

Warren Seltzer


-----Original Message-----
From: Phrogz [mailto:[email protected]]
Sent: Wednesday, September 21, 2005 11:57 PM
To: ruby-talk ML
Subject: Re: Large Ruby Apps ?


Regarding Unicode - do a bit of googling, and you'll find that not
everyone is happy about it. Including many Japanese. It isn't the
perfect, does-everything solution.
 
A

Alex Fenton

Warren said:
But I am concerned about Ruby's suitability for programming in the large.
For example this 1-line program issues no error:

puts @whatever

It's sometimes thought better style to use method calls to refer even to
private instance variables (for this reason among others). eg.

class Foo
attr_reader :whatever
private :whatever # if desired
def initialize()
@whatever = "hello"
end
def do_something()
puts whatevah
end
end

The typo will give you
typo.rb:8:in `do_something': undefined local variable or method
`whatevah' for # said:
This is a code bug that a statically typed compiler would scream about.

compilers .... $> make *clunk*whirr* ... *whirr*

I've written a mid-sized (6000+ LOC, excluding tests) end-user Ruby app,
and I typo a lot -
but it's very rarely responsible for subtle / long-lived bugs.
Also, a history question. With Ruby coming out of Japan, why wasn't Unicode support done
earlier? You'd think it would be insulated mono-lingual Americans who would delay that...

a couple of guesses:
1) Unicode is hard, and hard to do well.
2) Native encodings have remained popular in Japan generally, for
example in encoding
monolingual web pages and email attachments.

a
 
W

Warren Seltzer

You compiled it for 64 bit? No -- I'll bet you ran it in 32-bit compatibility mode.

Warren Seltzer


-----Original Message-----
From: Joe Van Dyk [mailto:[email protected]]
Sent: Thursday, September 22, 2005 12:42 AM
To: ruby-talk ML
Subject: Re: Large Ruby Apps ?


Also: Is anybody doing a port to 64-bit systems?

Ruby should work fine on a 64-bit system. At least, I used it fine
for a couple weeks on my A64 running 64bit linux.
 
L

Lothar Scholz

Hello Warren,

WS> You compiled it for 64 bit? No -- I'll bet you ran it in 32-bit compatibility mode.

WS> Warren Seltzer

There are some persons running a 64 bit ruby interpreter.
I know this because this does not work with the ArachnoRuby debugger
and so i have to answer to there question from time to time.
 
J

Jurgen Stroo

Well, supply these tools you've written to the community then, so the next
time someone is in need of these tools, they actually *are* there, and
this will help to get Ruby bigger and more useful for even more projects,
so the 'lack of tools in Ruby' issue will be history sooner.
:)

Jurgen

### http://bash.org/?23601 - bash.org goodie ###
<mage> what should I give sister for unzipping?
<Kevyn> Um. Ten bucks?
<mage> no I mean like, WinZip?

Although very unlikely, it seems Gary Shea stated on Sep 22 that :
 
G

Gary Shea

Well, supply these tools you've written to the community then, so the next
time someone is in need of these tools, they actually *are* there, and
this will help to get Ruby bigger and more useful for even more projects,
so the 'lack of tools in Ruby' issue will be history sooner.
:)

Jurgen

An excellent idea! In fact, two of them are on RubyForge already: Seep
and Mockery, a Spring-like DI tool and a EasyMock-like mock-object
generator.

Seep is very much ready for serious use -- I have maybe 6 different
projects using it, in some cases configuring as many as 100 objects. It
has not found much of an audience yet, which I suspect means that most
DI applications in Ruby are still fairly small. Then again, I may have
a failure of vision :) If I can ever get the current revision finished
(it's a big one, introducing multiple containers), there will be a gem
available.

Mockery is usable but is still under pretty heavy development. See the
announcement on this list from a few weeks back. Mockery has a gem
(under 'mockery', I hope!).

Regards,

Gary
 
S

Stephen Kellett

Alex said:
The typo will give you
typo.rb:8:in `do_something': undefined local variable or method
`whatevah' for #<Foo:0x1cf79c @whatever="hello"> (NameError)

That compiler error message needs updating:

typo.rb:8:in `do_something': estuary English not supported `whatevah'
 
J

Joe Van Dyk

You compiled it for 64 bit? No -- I'll bet you ran it in 32-bit compatib=
ility mode.

I built Ruby from scratch, using the 64 bit distribution of Ubuntu.=20
Worked just fine, AFAIK.
 
W

Warren Seltzer

No I did not. Yes I did.

Warren Seltzer


-----Original Message-----
From: Eric Hodel [mailto:[email protected]]
Sent: Thursday, September 22, 2005 2:48 AM
To: ruby-talk ML
Subject: Re: Large Ruby Apps ?


You compiled it for 64 bit? No -- I'll bet you ran it in 32-bit
compatibility mode.

Did you search the mailing list? No -- I'll bet you just assumed
that nobody's built a 64 bit Ruby ever.
 
G

Guest

Very useful discussion that highlights quite few misconceptions.
So far in this thread posters were contrasting "old school" static
type and variable checking versus Ruby's dynamic nature with run-time
Unit Testing properly done. The truth of the matter is that a
programmer's life is easier when one has both:

1: Static (aka compile time) program analysis that captures many
"human" errors like typos, obvious flow control flaws, etc.
2: Dynamic, run-time program verification consisting of unit tests and
integration tests.

Ruby clearly lacks static analysis tools.

Just my 2 cents
--Leo--
 
K

Kent Sibilev

I don't agree. Static analysis captures errors that are not usually a
big problem. If your unit tests have enough coverage they will capture
all these errors, but static typing makes your programs too noisy since
you have to feed your compiler with a lot of crap. Very good example of
how bad it could be, check out java with generics. By increasing the
size of your program you increase the possibility of making a mistake
and your program becomes harder to read.

Kent.
 
I

Isaac Gouy

Kent said:
I don't agree. Static analysis captures errors that are not usually a
big problem.

That's a huge generalization - can you substantiate it?

afaict a trivial error can be a big problem when it causes a failure
that has significant consequences.

If your unit tests have enough coverage they will capture
all these errors

If I was as good a programmer as my ego pretends I wouldn't make any
errors and the whole issue would be moot.

If I was as good a programmer... I would have unit tests with enough
coverage (and I wouldn't have made any errors writing the unit
tests)...

Errare humanum est.

but static typing makes your programs too noisy since you have to feed your
compiler with a lot of crap.

The comment was about "static analysis" not about "static typing".

Here's an example of static analysis of source code written in the
dynamically typed language Erlang:
Detecting Software Defects in Telecom Applications Through Lightweight
Static Analysis: A War Story
http://user.it.uu.se/~kostis/Papers/bugs05.pdf
http://user.it.uu.se/~kostis/Papers/war_story.pdf


Here's an example of static analysis of source written in C:
SLAM and Static Driver Verifier: Technology Transfer of Formal Methods
inside Microsoft
http://www.cse.ogi.edu/~byron/papers/history.pdf
 
L

Leonardo Eloy

------=_Part_3195_4717008.1128107939700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I agree that some sort of static analysis would allow Ruby codes to more
tightly immune to "bugs" (as Seltzer said).

But the nature of Ruby's dynamism wouldn't allow that any sort of effort in
this area will work properly, as Leo said below, in a Dynamic environment,
run-time verifications can be done via unit and integration testing.

So, for me, It's essential that in a Ruby code variables should be declared
as they're needed, the same applies to "dynamic Class modifications". This
is the dynamic paradigm as Sebesta predicted in his book.

IMHO, static analysis or typing doesn't fit in Ruby's reality, since its
proposal is a different one :).
 
G

Guest

Kent,
first of all in my post I emphasized static *analysis* not static typing.
Secondly, we are talking *large* applications here. Testing such
applications is a big *combinatorial* problem. In a large application
there are so many logical flows through your program that it is
infeasible to create a test suit that covers them all. If you are
interested in the subject of testing, verification and analysis of
large computer programs, please, use Google as a good starting point.
It is a vast and well developed field of Computer Science. Also see
[ruby-talk 158461] for some links.

Just my two cents.
--Leo--
 
E

Eivind Eklund

I agree that some sort of static analysis would allow Ruby codes to more
tightly immune to "bugs" (as Seltzer said).

But the nature of Ruby's dynamism wouldn't allow that any sort of effort = in
this area will work properly,

I believe this is incorrect. It should be possible to do a lot of=20
static analysis in Ruby, it's just that there is some type inference
etc that needs to be done first, and that is a significant amount of
work to implement.

An oldish reference that cover this fairly well is Ole Agesen's PhD
thesis "Concrete Type Inference: Delivering Object-Oriented
Applications" (available from
http://research.sun.com/techrep/1996/abstract-52.html)

That reference is based on work done in the language Self, which is
prototype based, and contains the same challenges as (pure) Ruby.=20
Things get much more complex if C is thrown into the mix, of course.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top