[#1649] Re: New Ruby projects — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1672] Re: Ruby 1.4 stable manual bug? — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1673] Re: Possible problem with ext/socket in 1.5.2 — itojun@...
[#1694] Conventions for our Ruby book — Dave Thomas <Dave@...>
[#1715] Install postgresql support — Ikhlasul Amal <amal@...>
Hi all,
Hi,
[#1786] Is this a bug? — Clemens Hintze <clemens.hintze@...>
(mailed & posted)
[#1814] Objects nested sometimes. — Hugh Sasse Staff Elec Eng <hgs@...>
I am attemptiong to write a package which consists of a workspace
[#1816] Ruby 1.5.3 under Tru64 (Alpha)? — Clemens Hintze <clemens.hintze@...>
Hi all,
Hi,
Yukihiro Matsumoto writes:
Hi,
Hi,
[#1834] enum examples? — Hugh Sasse Staff Elec Eng <hgs@...>
Has anyone any examplse of using the Enumerable module? I've had a
[#1844] Minor irritation, can't figure out how to patch it though! — Hugh Sasse Staff Elec Eng <hgs@...>
I was considering how difficult it would be to patch Ruby to accept
[#1889] [ruby-1.5.3] require / SAFE — ts <decoux@...>
[#1896] Ruby Syntax similar to other languages? — "David Douthitt" <DDouthitt@...>
[#1900] Enumerations and all that. — Hugh Sasse Staff Elec Eng <hgs@...>
Thank you to the people who responded to my questions about Enumerated
Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
On 16 Mar 2000, Dave Thomas wrote:
[#1929] Re: Class Variables — "David Douthitt" <DDouthitt@...>
| "David Douthitt" <DDouthitt@cuna.com> writes:
[#1942] no Fixnum#new ? — Quinn Dunkan <quinn@...>
Ok, I can add methods to a built-in class well enough (yes I know about succ,
[#1981] Time::at — "David Douthitt" <DDouthitt@...>
or whatever the right syntax is :-)
[#1989] English Ruby/Gtk Tutorial? — schneik@...
Hi,
SugHimsi(%HeIsSaidJustToLoseHisPatienceOnThisSubject;-).
[#2022] rb_global_entry — ts <decoux@...>
[#2036] Anonymous and Singleton Classes — B_DAVISON <Bob.Davison@...>
I am a Ruby newbie and having some problems getting my mind around certain
[#2069] Ruby/GTK+ question about imlib --> gdk-pixbug — schneik@...
[#2073] Re: eval.rb fails — "Dat Nguyen" <thucdat@...>
The doc is fine, this happens only if you try to execute 'until' block
On Wed, 22 Mar 2000, Dat Nguyen wrote:
[#2084] Scope violated by import via 'require'? — Clemens Hintze <c.hintze@...>
Hi,
[#2104] ARGF or $< — Hugh Sasse Staff Elec Eng <hgs@...>
Has anyone any examples of how to use ARGF or $< as I cannot find much
Hi.
[#2165] Ruby strict mode and stand-alone executables. — "Conrad Schneiker" <schneiker@...>
Some people want Ruby to have a strict compile mode.
[#2203] Re: parse bug in 1.5 — schneik@...
[#2212] Re: Ruby/Glade usage questions. — ts <decoux@...>
>>>>> "m" == mrilu <mrilu@ale.cx> writes:
[#2241] setter() for local variables — ts <decoux@...>
[#2256] Multiple assignment of pattern match results. — schneik@...
[#2267] Re: Ruby and Eiffel — h.fulton@...
[#2309] Question about attribute writers — Dave Thomas <Dave@...>
[ruby-talk:02162] Re: Scripting and OO -- thought question
From: <h.fulton@att.net> > Here's an opinion question for you all. > > I was telling a friend about Ruby the other day, > and I told him how it was OO from the ground up, > unlike Perl, etc. > > His interest level was mild. He said that he > thought object orientation was a good thing in > general, but that for the things scripting > languages are generally used for, it's not that > useful. > > In his words, "If I were going to write a 60,000 > line chess program or something, I wouldn't do it > in Perl or any other script; I'd use Java or C++ > or something. And if I were doing something like > a filter, like 'munging' a text file, I wouldn't > really need OO." Wait a minute! A 60,000 line chess program in Java or C++ could turn out to be a 10,000 line program Perl. This sort of comparison is like saying, if I had to power a large ship across the ocean, I would use 60,000 gallons of wood chips rather than 60,000 gallons of diesel fuel. Lines of code per task is a language-specific metric, just as energy per unit of fuel is a fuel-specific measure. Speaking of human performance, large programs are often more difficult to comprehend and maintain when there is 5x to 10x more stuff that you have to look at. For reasonably written/commented code, total size still turns out to be roughly correlated with support costs across many languages. > That's an interesting thought. How would you answer > him? > > I think I see his point; but perhaps one reason he > would not use a scripting language for a large > project is that he simply has never SEEN a scripting > language powerful enough for large projects. Well, the first thing to recall is that the requirements for large projects vary all over the map. In many cases solving an urgent problem is much more important (within certain bounds) than raw performance. Look at www.perl.com for Perl success stories or talk to head-hunters that are looking for serious Perl experts if you want to find out about large projects that were written in Perl, the so-called "duct tape of the web". Likewise, look at links off of www.python.org for info about the use of Python for large projects in corporations and national labs. Their respective newsgroups have bashed this topic mercilessly. Most of their considerations (with a few exceptions such as Perl's monster sized library of modules) apply just as much or even more so to Ruby. > There is also the speed issue; but he cites Java as > a "real" language, and we are certainly not > guaranteed that it will be speedy on every platform. Speed is often a much stronger function of design and modules/algorithms used than choice of language. If you look inside may Perl and Python and Ruby modules, you find C. The other thing to keep in mind is that it is almost always a much more effective use of your time to concentrate on converting those who are already predisposed to what you are selling when you have a very large market. As long as there are some 10 X to 100 X more Perl and Python users in the world than Ruby users, I'd leave it to them the substantially more difficult task of converting others to such types of tools, and concentrate on attracting the Perl and Python users who have run into the limitations of their tools, who already constitute a giant and ready-made market for Ruby. (Of course there are exceptions to this general policy, such as when you really want to save a friend's soul. :-) Conrad