# Large Ruby Apps? **URL:** \ **Category:** ruby-talk\ **Created:** [21 September 2005 20:30 UTC](https://rubytalk.org/t/large-ruby-apps/20980 "2005-09-21T20:30:18Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![W11](https://avatars.discourse-cdn.com/v4/letter/w/8e7dd6/32.png) [@W11](https://rubytalk.org/u/W11)\ **Post date:** [21 September 2005 20:30 UTC](https://rubytalk.org/t/large-ruby-apps/20980/1 "2005-09-21T20:30:18Z")
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 ---
**Author:** ![Gary\_Shea](https://avatars.discourse-cdn.com/v4/letter/g/779978/32.png) [@Gary\_Shea](https://rubytalk.org/u/Gary_Shea)\ **Post date:** [21 September 2005 20:53 UTC](https://rubytalk.org/t/large-ruby-apps/20980/2 "2005-09-21T20:53:01Z")
> 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... > > > > Warren Seltzer ---
**Author:** ![Gavin\_Kistner2](https://avatars.discourse-cdn.com/v4/letter/g/b9e5f3/32.png) [@Gavin\_Kistner2](https://rubytalk.org/u/Gavin_Kistner2)\ **Post date:** [21 September 2005 20:56 UTC](https://rubytalk.org/t/large-ruby-apps/20980/3 "2005-09-21T20:56:39Z")
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. ---
**Author:** ![J-Van](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@J-Van](https://rubytalk.org/u/J-Van)\ **Post date:** [21 September 2005 21:42 UTC](https://rubytalk.org/t/large-ruby-apps/20980/4 "2005-09-21T21:42:17Z")
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. > **···** > > On 9/21/05, Warren Seltzer \ wrote: > > > Also: Is anybody doing a port to 64-bit systems? ---
**Author:** ![Alex\_Fenton2](https://avatars.discourse-cdn.com/v4/letter/a/7ab992/32.png) [@Alex\_Fenton2](https://rubytalk.org/u/Alex_Fenton2)\ **Post date:** [21 September 2005 22:26 UTC](https://rubytalk.org/t/large-ruby-apps/20980/5 "2005-09-21T22:26:38Z")
Warren Seltzer wrote: > 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 #\ (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. a ---
**Author:** ![mathew](https://avatars.discourse-cdn.com/v4/letter/m/5daacb/32.png) [@mathew](https://rubytalk.org/u/mathew)\ **Post date:** [30 September 2005 05:31 UTC](https://rubytalk.org/t/large-ruby-apps/20980/6 "2005-09-30T05:31:44Z")
Warren Seltzer wrote: > 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. mathew > **···** > > -- > \           WE HAVE TACOS ---
**Author:** ![slonik\_AZ](https://avatars.discourse-cdn.com/v4/letter/s/2bfe46/32.png) [@slonik\_AZ](https://rubytalk.org/u/slonik_AZ)\ **Post date:** [30 September 2005 13:00 UTC](https://rubytalk.org/t/large-ruby-apps/20980/7 "2005-09-30T13:00:19Z")
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 \ 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 ---
**Author:** ![W11](https://avatars.discourse-cdn.com/v4/letter/w/8e7dd6/32.png) [@W11](https://rubytalk.org/u/W11)\ **Post date:** [21 September 2005 22:21 UTC](https://rubytalk.org/t/large-ruby-apps/20980/8 "2005-09-21T22:21:40Z")
Yeah, but it blows away 7-bit ASCII for i18n work. Warren Seltzer > **···** > > -----Original Message----- > From: Phrogz [[mailto:gavin@refinery.com](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. ---
**Author:** ![W11](https://avatars.discourse-cdn.com/v4/letter/w/8e7dd6/32.png) [@W11](https://rubytalk.org/u/W11)\ **Post date:** [21 September 2005 22:26 UTC](https://rubytalk.org/t/large-ruby-apps/20980/9 "2005-09-21T22:26:29Z")
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 \ 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. ---
**Author:** ![Jurgen\_Stroo](https://avatars.discourse-cdn.com/v4/letter/j/f17d59/32.png) [@Jurgen\_Stroo](https://rubytalk.org/u/Jurgen_Stroo)\ **Post date:** [22 September 2005 05:52 UTC](https://rubytalk.org/t/large-ruby-apps/20980/10 "2005-09-22T05:52:48Z")
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](http://bash.org/?23601) - bash.org goodie ### \ what should I give sister for unzipping? \ Um. Ten bucks? \ 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 > > \> > > \> > > \> ---
**Author:** ![Stephen\_Kellett](https://avatars.discourse-cdn.com/v4/letter/s/87869e/32.png) [@Stephen\_Kellett](https://rubytalk.org/u/Stephen_Kellett)\ **Post date:** [22 September 2005 09:16 UTC](https://rubytalk.org/t/large-ruby-apps/20980/11 "2005-09-22T09:16:39Z")
That compiler error message needs updating: typo.rb:8:in `do_something': estuary English not supported `whatevah' > **···** > > In message \<4331dd7b$0$19476$cc9e4d1f@news-text.dial.pipex.com\>, Alex Fenton \ writes > > > The typo will give you > > typo.rb:8:in `do_something': undefined local variable or method `whatevah' for #\ (NameError) > > -- > Stephen Kellett > Object Media Limited [http://www.objmedia.demon.co.uk/software.html](http://www.objmedia.demon.co.uk/software.html) > Computer Consultancy, Software Development > Windows C++, Java, Assembler, Performance Analysis, Troubleshooting ---
**Author:** ![Kent\_Sibilev1](https://avatars.discourse-cdn.com/v4/letter/k/9d8465/32.png) [@Kent\_Sibilev1](https://rubytalk.org/u/Kent_Sibilev1)\ **Post date:** [30 September 2005 14:26 UTC](https://rubytalk.org/t/large-ruby-apps/20980/12 "2005-09-30T14:26:36Z")
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 \ 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 > > \> > > \> > > \> > > \> ---
**Author:** ![Leonardo\_Eloy](https://avatars.discourse-cdn.com/v4/letter/l/7c8e57/32.png) [@Leonardo\_Eloy](https://rubytalk.org/u/Leonardo_Eloy)\ **Post date:** [30 September 2005 19:19 UTC](https://rubytalk.org/t/large-ruby-apps/20980/13 "2005-09-30T19:19:02Z")
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 \ 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 \ 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 > > \> > > \> > > \> > > \> > > -- > Leonardo Eloy, LPIC-1, FCSE, SCPJ ---
**Author:** ![Eric\_Hodel1](https://avatars.discourse-cdn.com/v4/letter/e/a9adbd/32.png) [@Eric\_Hodel1](https://rubytalk.org/u/Eric_Hodel1)\ **Post date:** [21 September 2005 23:47 UTC](https://rubytalk.org/t/large-ruby-apps/20980/14 "2005-09-21T23:47:41Z")
Did you search the mailing list? No -- I'll bet you just assumed that nobody's built a 64 bit Ruby ever. [http://blade.nagaokaut.ac.jp/cgi-bin/namazu.rb?key=64+bit&cginame=namazu.rb&submit=Search&dbname=ruby-talk&max=50&whence=0&ref=http://blade.nagaokaut.ac.jp/ruby/ruby-talk/index.shtml](http://blade.nagaokaut.ac.jp/cgi-bin/namazu.rb?key=64+bit&cginame=namazu.rb&submit=Search&dbname=ruby-talk&max=50&whence=0&ref=http://blade.nagaokaut.ac.jp/ruby/ruby-talk/index.shtml) > **···** > > On 21 Sep 2005, at 15:26, Warren Seltzer wrote: > > > You compiled it for 64 bit? No -- I'll bet you ran it in 32-bit compatibility mode. > > -- > Eric Hodel - drbrain@segment7.net - [http://segment7.net](http://segment7.net) > FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 ---
**Author:** ![Lothar\_Scholz2](https://avatars.discourse-cdn.com/v4/letter/l/f14d63/32.png) [@Lothar\_Scholz2](https://rubytalk.org/u/Lothar_Scholz2)\ **Post date:** [22 September 2005 00:06 UTC](https://rubytalk.org/t/large-ruby-apps/20980/15 "2005-09-22T00:06:02Z")
Hello Warren, > 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](http://www.ruby-ide.com) > CTO Scriptolutions Ruby, PHP, Python IDE 's ---
**Author:** ![Gary\_Shea](https://avatars.discourse-cdn.com/v4/letter/g/779978/32.png) [@Gary\_Shea](https://rubytalk.org/u/Gary_Shea)\ **Post date:** [22 September 2005 06:31 UTC](https://rubytalk.org/t/large-ruby-apps/20980/16 "2005-09-22T06:31:31Z")
> 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](http://bash.org/?23601) - bash.org goodie ### > > \ what should I give sister for unzipping? > > \ Um. Ten bucks? > > \ 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 > > \> \> > > \> \> > > \> \> > > \> > > \> > > \> ---
**Author:** ![J-Van](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@J-Van](https://rubytalk.org/u/J-Van)\ **Post date:** [22 September 2005 18:55 UTC](https://rubytalk.org/t/large-ruby-apps/20980/17 "2005-09-22T18:55:11Z")
I built Ruby from scratch, using the 64 bit distribution of Ubuntu. Worked just fine, AFAIK. > **···** > > On 9/21/05, Warren Seltzer \ wrote: > > > You compiled it for 64 bit? No -- I'll bet you ran it in 32-bit compatibility mode. ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [30 September 2005 17:31 UTC](https://rubytalk.org/t/large-ruby-apps/20980/18 "2005-09-30T17:31:45Z")
Kent Sibilev wrote: > 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 > **[bugs05.pdf](https://user.it.uu.se/~kostis/Papers/bugs05.pdf)** > > 80.96 KB > **[war\_story.pdf](https://user.it.uu.se/~kostis/Papers/war_story.pdf)** > > 235.02 KB 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](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 ---
**Author:** ![slonik\_AZ](https://avatars.discourse-cdn.com/v4/letter/s/2bfe46/32.png) [@slonik\_AZ](https://rubytalk.org/u/slonik_AZ)\ **Post date:** [1 October 2005 11:21 UTC](https://rubytalk.org/t/large-ruby-apps/20980/19 "2005-10-01T11:21:41Z")
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 \ 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 \ 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 > > \> \> > > \> \> > > \> \> > > \> \> > > \> ---
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [2 October 2005 12:33 UTC](https://rubytalk.org/t/large-ruby-apps/20980/20 "2005-10-02T12:33:15Z")
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. 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\](http://research.sun.com/techrep/1996/abstract-52.html%5C)) 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 \ 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, > > -- > Hazzle free packages for Ruby? > RPA is available from [http://www.rubyarchive.org/](http://www.rubyarchive.org/) [Next page](https://rubytalk.org/t/large-ruby-apps/20980.md?page=2)