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...
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
···
On Thu, 2005-09-22 at 05:30 +0900, Warren Seltzer wrote:
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...
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.
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 #<Foo:0x1cf79c @whatever="hello"> (NameError)
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.
First off, the lack of the requirement to declare variables sounds
> like an invitation to programming bugs.
I don't want to be *required* to declare variables, but I'd like to be *allowed* to, and have the system warn me if I use an undeclared one in the scope containing declarations...
Unfortunately, the Ruby community has a religious objection to allowing variable declaration. It's just one of those arguments it's best not to go into, like suggesting that maybe Python would be better if it wasn't subject to tab damage, or that the Pope should allow people to use condoms.
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--
···
On 9/21/05, Warren Seltzer <warrens@actcom.net.il> wrote:
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...
Yeah, but it blows away 7-bit ASCII for i18n work.
Warren Seltzer
···
-----Original Message-----
From: Phrogz [mailto:gavin@refinery.com]
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.
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:joevandyk@gmail.com]
Sent: Thursday, September 22, 2005 12:42 AM
To: ruby-talk ML
Subject: Re: Large Ruby Apps ?
On 9/21/05, Warren Seltzer <warrens@actcom.net.il> wrote:
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.
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 :
···
On Thu, 2005-09-22 at 05:30 +0900, Warren Seltzer wrote:
> 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
> 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
>
>
>
typo.rb:8:in `do_something': estuary English not supported `whatevah'
···
In message <4331dd7b$0$19476$cc9e4d1f@news-text.dial.pipex.com>, Alex Fenton <alex@deleteme.pressure.to> writes
The typo will give you
typo.rb:8:in `do_something': undefined local variable or method `whatevah' for #<Foo:0x1cf79c @whatever="hello"> (NameError)
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
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.
···
On Fri, 2005-09-30 at 22:00 +0900, slonik.az@gmail.com wrote:
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--
On 9/21/05, Warren Seltzer <warrens@actcom.net.il> wrote:
> 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
>
>
>
>
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 :).
···
On 9/30/05, slonik.az@gmail.com <slonik.az@gmail.com> wrote:
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--
On 9/21/05, Warren Seltzer <warrens@actcom.net.il> wrote:
> 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
>
>
>
>
You compiled it for 64 bit? No -- I'll bet you ran it in 32-bit compatibility mode.
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.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
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
···
On Thu, 2005-09-22 at 14:52 +0900, Jurgen Stroo wrote:
### 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 :
> On Thu, 2005-09-22 at 05:30 +0900, Warren Seltzer wrote:
> > 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
>
> > 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
> >
> >
> >
>
>
>
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
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
···
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.
On Fri, 2005-09-30 at 22:00 +0900, slonik.az@gmail.com wrote:
> 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
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--
···
On 9/30/05, Kent Sibilev <ksruby@gmail.com> wrote:
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.
On Fri, 2005-09-30 at 22:00 +0900, slonik.az@gmail.com wrote:
> 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--
>
>
> On 9/21/05, Warren Seltzer <warrens@actcom.net.il> wrote:
> > 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
> >
> >
> >
> >
>
I believe this is incorrect. It should be possible to do a lot of
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.
That reference is based on work done in the language Self, which is
prototype based, and contains the same challenges as (pure) Ruby.
Things get much more complex if C is thrown into the mix, of course.
···
On 9/30/05, Leonardo Eloy <leonardo.eloy@gmail.com> wrote:
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,
