 |
Why You Might Want to Try Ruby
by Phil Tomson, in Editorials - Sat, Jan 5th 2002 00:00 UTC
Ruby. Perhaps you've heard of it? "Oh, yeah, I think it's one of
those new object oriented scripting languages", you say. I know a lot
of you might be thinking "Not another new language! I'm perfectly
happy with [COBOL|C|cshell|awk|Perl|...]; why does the world need
another programming language?!", while a few others are thinking
"Cool, a new language to explore".
Copyright notice: All reader-contributed material on freshmeat.net
is the property and responsibility of its author; for reprint rights, please contact the author
directly.
Those of you in the former camp should ask yourselves this question:
What if all programmers back in the days when COBOL ruled the
mainframe had the same attitude? Fortran would still be an academic
curiosity, and we might all be programming in COBOL at work, while C
might not even exist yet. Not a pretty picture. That's why we need
some folks around who are in the latter, early adopter camp. The
purpose of this article is to persuade some early adopters to give
Ruby a try (no hidden agendas here :).
Why should you try Ruby? Remember Maslow's hierarchy of human needs
from that Psych 101 class you took way-back-when? At the bottom of
the pyramid, there are things like food, water, and shelter. It
progresses up to things like security, and finally, at the top,
there's a category called "self-actualization", which basically means
(my paraphrase) "fun stuff". No, you don't learn Ruby to secure food,
shelter, and security (at least not yet); that's why you learn languages
like C/C++, Java, and Perl. (Though after you learn Ruby, you'll certainly
hope that you can start using it soon at work.) You learn Ruby, at this
point, primarily because it's fun.
Ok, so what kind of language is Ruby, anyway?
Ruby is a "dynamically strongly typed", single-inheritance object
oriented programming language. It's dynamically typed in that types
are checked at runtime, and types of variables don't need to be
declared. It's strongly typed in that if you try to use an object of a
certain type in a way that the type doesn't understand, an exception
(or error) will be raised. The term "object oriented" is applied to a
lot of things these days. There's object oriented Perl, for example,
but though you can do OO in Perl, it's not a pretty sight. In the
early 90s, the creator of Ruby, Yukihiro Matsumoto (AKA "Matz") was
looking for an object oriented scripting language which had the text
processing capabilities of Perl. He looked at Python, but even it was
not OO enough for his tastes, so he ended up creating Ruby. If
SmallTalk dwells in the most OO region of ProgrammingLanguageLand (as
many believe), then Ruby lives right next door.
Numbers, string literals, regular expressions... these are all objects
in Ruby. Here are a few examples of this in Ruby code ("==>"
means "results in"):
3.times { print " hey " } |
==> |
" hey hey hey " |
" this is a string ".length |
==> |
21 |
/^IF .. ^END/.type |
==> |
Regexp |
Ruby has a large number of built-in types, including
Array, Hash, String,
File, Thread, and Time. Each
of these types or classes has a very complete set of methods which act
on objects of that type. This lets you get more done with less
code. For example, let's say you have a string with leading and
trailing whitespace, and you want to get rid of them:
string = " this is a string "
You can apply the strip! method to it, like this:
string.strip! |
==> |
"this is a string" |
Methods which have a "!" at the end are destructive; they change the
object they are applied to.
Now, let's capitalize our string:
string.capitalize! |
==> |
"This is a string" |
If you want to change "string" to "phrase", do this:
string.gsub!(/string/,"phrase")
And there are a lot more actions that can be performed on strings...
Even though Ruby's built-in classes have very complete sets of methods
to act upon them, you're bound to find a need for some action that may
not be built-in to a type, so Ruby allows you to extend its built-in
types. For example, I wanted to rotate the contents of an
Array. Ruby's Array class doesn't have a built-in rotate method, so I
made my own and added it to the Array class:
class Array
def rotate!
self.unshift( self.pop)
return self[0]
end
end
After that declaration, all objects of type Array in my program will
respond to the rotate! method. This implies that classes
in Ruby are not closed; you can always extend either built-in classes
or classes you define. In fact, you can even do this at runtime, which
makes Ruby a very dynamic language indeed.
As mentioned earlier, Ruby is a single inheritance OO language. Some
might see the single inheritance part as a liability, but, in fact,
Ruby allows for something called mixins. A mixin is a set of behaviors
or functions defined within a module which can be included (mixed in)
to a class. In practice, mixins tend to make up for the lack of multiple
inheritance.
Perhaps the coolest feature of the Ruby language is the
iterator. Iterators are methods that can invoke blocks of code. For
example, all of the collection classes in Ruby implement the each
method, which is an iterator that accepts a code block.
hobbits = ['frodo','sam', 'pippin']
hobbits.each { |name|
puts "my name is: #{name}"
}
prints:
my name is frodo
my name is sam
my name is pippin
You can create your own iterators by using the yield statement:
def iterate(max)
i = 0
while i < max
yield i
i += 1
end
end
iterate(10){|val| puts " val is: #{val}" }
prints:
val is: 0
...
val is: 10
Hopefully, these examples have illustrated Ruby's clean, consistent
syntax. One of Matz's goals in designing Ruby is that it should follow
the "principle of least surprise", and in my experience, it does tend
to follow that maxim. There are many other cool features of Ruby
(like GUI toolkits, Ruby's easy-to-use distributed object system
(dRuby), Threads, etc.); I've just scratched the surface here to whet
your appetite. You can find more information on Ruby at:
The newsgroup comp.lang.ruby is also
quite informative and newbie friendly. Ruby is quite popular in Japan,
the land of its beginnings, and it is growing in popularity in the
West as well (I notice that there are 40 projects on freshmeat which
are Ruby-related). There are currently two English language Ruby
books, Programming Ruby: The Pragmatic Programmer's Guide by
Dave Thomas and Andrew Hunt (you can find the full text of the book
online at http://www.rubycentral.com/book/)
and Ruby in a
Nutshell by Matz himself. Three other Ruby books are planned
for release early next year.
Go explore; have fun!
Author's bio:
Phil Tomson has been a
software engineer for the last 8 years. He is currently in the midst
of a sabbatical during which he is writing Open Source Ruby modules
and an article or two.
T-Shirts and Fame!
We're eager to find people interested in writing articles on
software-related topics. We're flexible on length, style, and
topic, so long as you know what you're talking about and back up
your opinions with facts. Anyone who writes an article gets a
t-shirt from ThinkGeek
in addition to 15 minutes of fame. If you think you'd like to try
your hand at it, let jeff.covey@freshmeat.net
know what you'd like to write about.
[Comments are disabled]
Comments
[»]
What does "more OO" mean?
by Phillip J. Eby - Jan 11th 2002 11:10:19
I've noticed that few promoters of Ruby have much to say about why Ruby
is better than Python, except that it's "more OO". But I haven't seen what
these "more OO" features are, that aren't available in Python 2.2.
For example, iterators and generators. Your example:
def iterate(max)
i = 0
while i < max
yield i
i += 1
end
end
iterate(10){|val| puts " val is: #{val}" }
reads like this in Python 2.2:
from __future__ import generators
def iterate(max):
i = 0
while i < max:
yield i
i += 1
for val in iterate(10):
print "val is:", val
Same feature, but a bit more readable. And a whole lot more things built
in. Also, as of 2.2 you can subclass Python built-ins like integers,
strings, etc., if you need or want to, as well as any extension type you
define in C.
I really am curious to know what these other "OO" features are.
[reply]
[top]
[»]
Re: What does "more OO" mean?
by Adde - Jan 16th 2002 07:08:01
> I've noticed that few promoters of Ruby
> have much to say about why Ruby is
> better than Python, except that it's
> "more OO". But I haven't seen what
> these "more OO" features are, that
> aren't available in Python 2.2.
>
> For example, iterators and generators.
> Your example:
>
>
> def iterate(max)
> i = 0
> while i < max
>
> yield
> i
> i
> += 1
> end
> end
>
> iterate(10){|val| puts " val is:
> #{val}" }
>
>
> reads like this in Python 2.2:
>
>
> from __future__ import generators
>
> def iterate(max):
> i = 0
> while i < max:
>
> yield
> i
> i
> += 1
>
> for val in iterate(10):
> print "val is:",
> val
>
>
>
> Same feature, but a bit more readable.
> And a whole lot more things built in.
> Also, as of 2.2 you can subclass Python
> built-ins like integers, strings, etc.,
> if you need or want to, as well as any
> extension type you define in C.
>
> I really am curious to know what these
> other "OO" features are.
Here are some examples for you:
"Hello".length
5.times { print "hey" }
Where .length is a method of class String and .times is a method of class
Integer.
[reply]
[top]
[»]
Re: What does "more OO" mean?
by Phillip J. Eby - Jan 16th 2002 10:01:53
>
> %
> % I really am curious to know what
> these
> % other "OO" features are.
>
>
> Here are some examples for you:
>
> "Hello".length
>
> 5.times { print "hey" }
>
> Where .length is a method of class
> String and .times is a method of class
> Integer.
So how is that "more OO" than the methods available on strings
and integers in Python, except in which methods they have and how they're
named? That doesn't strike me as being "more", just
"different". And that you didn't give any examples other than
those mentioned in the article, seems to suggest that there's not really a
whole lot else different, which was the point of my question.
[reply]
[top]
[»]
Re: What does "more OO" mean?
by Adde - Jan 16th 2002 10:25:24
>
> %
> % %
> % % I really am curious to know what
> % these
> % % other "OO" features are.
> %
> %
> % Here are some examples for you:
> %
> % "Hello".length
> %
> % 5.times { print "hey" }
> %
> % Where .length is a method of class
> % String and .times is a method of
> class
> % Integer.
>
>
> So how is that "more OO"
> than the methods available on strings
> and integers in Python, except in which
> methods they have and how they're named?
> That doesn't strike me as being
> "more", just
> "different". And that you
> didn't give any examples other than
> those mentioned in the article, seems to
> suggest that there's not really a whole
> lot else different, which was the point
> of my question.
>
In Ruby, everything is an object. That's the difference.
Python:
>>> "Hello".count
<built-in method count of string object at 008A1D80>
Ruby:
irb(main):001:0> "Hello".length
5
Every class is an object, 'true' is an object, 'false' is an object, even
'nil' is an object.
[reply]
[top]
[»]
Re: What does "more OO" mean?
by Phillip J. Eby - Jan 16th 2002 20:27:38
>
> In Ruby, everything is an object.
> That's the difference.
>
> Python:
> >>> "Hello".count
> <built-in method count of string
> object at 008A1D80>
>
> Ruby:
> irb(main):001:0>
> "Hello".length
> 5
>
> Every class is an object, 'true' is an
> object, 'false' is an object, even 'nil'
> is an object.
I don't get you. All those things are objects in Python, also. Note, by
the way, that "Hello".count("l") returns 2, and
"Hello".__len__() returns 5. I'm not sure what you're trying to
say here. Everything in Python is an object, including functions, code,
modules, classes, instances, types, metaclasses/metatypes, methods,
iterators, generators... They're the same all the way down to sharing the
same C header structure. And that's been the case for every version of
Python I've ever worked with.
In Python versions prior to 2.2, extending types developed in C couldn't
be done without either coding in C or the use of the ExtensionClasses
add-on. But that didn't change things being objects - there were simply
limits to which types could be extended without C code being involved.
I've dug through the Ruby FAQ looking for a meaningful Ruby-Python
comparison, and the only such information that I saw was written by a
Python programmer who mostly listed the differences which went away as of
Python 2.2. I did notice that Ruby offers continuations, however, and a
few other little odds and ends that are difficult in Python without special
extensions (such as the Stackless Python patch).
But nobody seems to mention these features in comparison situations,
instead repeating the "everything's an object" mumbo jumbo which
is not actually a difference from Python. If folks are serious about
having Python programmers check out Ruby, it would be good for them to
mention some actual feature differences.
[reply]
[top]
[»]
Re: What does "more OO" mean?
by Adde - Jan 17th 2002 06:45:54
>
> %
> % In Ruby, everything is an object.
> % That's the difference.
> %
> % Python:
> % >>>
> "Hello".count
> % <built-in method count of
> string
> % object at 008A1D80>
> %
> % Ruby:
> % irb(main):001:0>
> % "Hello".length
> % 5
> %
> % Every class is an object, 'true' is
> an
> % object, 'false' is an object, even
> 'nil'
> % is an object.
>
>
> I don't get you. All those things are
> objects in Python, also. Note, by the
> way, that
> "Hello".count("l")
> returns 2, and
> "Hello".__len__() returns 5.
> I'm not sure what you're trying to say
> here. Everything in Python is an
> object, including functions, code,
> modules, classes, instances, types,
> metaclasses/metatypes, methods,
> iterators, generators... They're the
> same all the way down to sharing the
> same C header structure. And that's
> been the case for every version of
> Python I've ever worked with.
>
> In Python versions prior to 2.2,
> extending types developed in C couldn't
> be done without either coding in C or
> the use of the ExtensionClasses add-on.
> But that didn't change things being
> objects - there were simply limits to
> which types could be extended without C
> code being involved.
>
> I've dug through the Ruby FAQ looking
> for a meaningful Ruby-Python comparison,
> and the only such information that I saw
> was written by a Python programmer who
> mostly listed the differences which went
> away as of Python 2.2. I did notice
> that Ruby offers continuations, however,
> and a few other little odds and ends
> that are difficult in Python without
> special extensions (such as the
> Stackless Python patch).
>
> But nobody seems to mention these
> features in comparison situations,
> instead repeating the "everything's
> an object" mumbo jumbo which is not
> actually a difference from Python. If
> folks are serious about having Python
> programmers check out Ruby, it would be
> good for them to mention some actual
> feature differences.
Ok, after poking around a bit i have to admit it looks better than i
thought, they've somehow gotten most of the language to behave mostly like
real Python objects.
* Getters and Setters
Automatically generated getters/setters for class attributes, which can
later be custom implemented without affecting the surrounding code.
* Attributes are private
The only way to access to the internals of an object is through getters
and setters, see above.
* Messagebased instead of procedural
No need for (self, ....) method declarations
* Module mixins
A compromise between multiple interitance and Java's interfaces.
* Default method
A default method can be declared to handle all messages that doesn't have
a corresponding method.
Makes it easier to implement many design patterns, like for example the
Proxy pattern.
* Reflection
It's E-A-S-Y to get a list of methods or attributes for a
class/object.
It's E-A-S-Y to declare new functions and new attributes at runtime.
* Ability to extend single objects
Objects can be further extended.
That is, you can make different objects of the same class behave
differently.
All in all ruby is ObjectOriented in a cleaner more consistent way than
Python.
We're obviously seing this from different perspectives. As I see it, I
don't gain anything from you checking out Ruby. In fact, the only one
gaining anything would be YOU. I'm doing you a favour ;)
[reply]
[top]
[»]
Re: What does "more OO" mean?
by avdi - Jan 21st 2002 13:14:20
I learned Python and Ruby at about the same time, and I've spent some
time comparing their OO-ness. I'll say right from the start that I *do*
believe that Ruby os "more OO" than Python, but I hope to give some fairly
plausable reasons for that statement.
Often, in comparisons of Ruby and Python, the statement is made that
"Python 2.2 now has iterators and generators and subclassable built-ins".
This is true. Does this mean that Python and Ruby are now equivalent? I
would say no.
In many ways Ruby's OO nature is what Python has been striving towards
for years. Only recently have iterators and generators been added to
Python. Only recently has the type/class sytem been unified. In Ruby,
those features have been incorporated since day one. This may seem like an
academic point; after all, Python has those features /now/. Here's why it
isn't: because iterators have always been in Ruby, each built-in Ruby class
has a rich set of methods which exploit the power of iterators. With
arrays, for instance, you can apply an arbitrary block of code to every
element with each(); you can collect the result of applying a block to
every element with collect(); delete every element for which the block
matches with delete_if(); sort using an arbitrary code block; and other
operations. Every other built-in type has a large set of opertations that
exploit iterators to the fullest. Python provides iterators; but the
built-in classes do not (to my knowledge) lend themselves to iterative
operations out-of-box. In addition, the vast amount of libraries
available for Python do not yet have pervasive support for iterators.
In a similar vein, built-in objects in python simply don't have as many
methods available as Ruby objects. Python's built-in types cause Python's
procedural heritage to show through. Much old code uses the old
string.method("mystring") functions, making it hard for the beginner to
know whether to use the string.* functions or the built-in string methods.
Worse, it is hard for the beginner to predict whether a particular
operation will be implemented as a free function or as a method. For
example, to find out if the string 'my_str' is all alphabetic, I call
my_str.isalpha; but if I want to know how long it is I must call
len(my_str). In Ruby, there would never be any ambiguity - any built-in
operation on a string is callable as a method of the string. Even worse is
the inconsistency between tuples and lists. Despite tuples being (to all
intents and purposes) the equivalent of a constant list, tuples have no
methods, whereas lists have many. There is no apparent reason for this
inconsistency.
Thus, while Python provides many of the same features as Ruby, because
they were added so late in the game, it does not provide them in anything
like the pervasive way that Ruby does.
On to other areas of comparison...
1. Ruby has no free functions. Like smalltalk, every function is
either a class method or an object method. Even when you define a function
outside of any class, you're actually defining a class method of the class
Object. Not that this is inherently "better"; but it is more purely OO,
according to academic definitions of OO.
2. Ruby has true open classes. Python allows you to redefine existing
classes; but when you do, existing instances of the redefined class do not
reflect any changes you made to the class. Only objects created after the
redefinition pick up on the changes. This can result in objects in the
same program that report the same type, but behave differently. When a
class is modified in Ruby, every object of that class immediately exhibits
the changed behavior/interface.
3. 'self' as a keyword. In Python, you must put 'self' in the argument
declaration of every method; but you must remember to pretend that argument
doesn't exist when calling the method. Many Pythoneers have praised the
explicitness of having to define 'self'; but the Python FAQ makes it quite
clear that the only reason for this misfeature is that when OO was being
added to Python, this was simply the easiest way to hack it in. In effect,
Python forces the programmer to help the interpreter to remember what
object the method has been called on. In Ruby, 'self' is a keyword; in a
method body, 'self' always refers to the object that the method was called
from. No need to define 'self' in the argument list.
[reply]
[top]
[»]
Re: What does "more OO" mean?
by Det - Jun 18th 2002 05:47:55
[Ack. so far]
> 2. Ruby has true open classes. Python
> allows you to redefine existing classes;
> but when you do, existing instances of
> the redefined class do not reflect any
> changes you made to the class. Only
> objects created after the redefinition
> pick up on the changes.
That's definitely not true (following code tested
on Jython 2.1):
class MyClass:
myAttrib = "one"
def showMyAttrib(self):
print 'here is: -%s-' %
self.myAttrib
def changeAClass(klasse):
def aPrinter(self):
print "once again -%s-" %
self.newestAttrib
def makeNewestAttrib(self):
self.newestAttrib = 'three'
klasse.__dict__["makeNewestAttrib"] = makeNewestAttrib
klasse.__dict__["printNewestAttrib"] = aPrinter
myObject = MyClass()
print myObject.myAttrib
myObject.showMyAttrib()
print "--- The Change ---"
changeAClass(MyClass)
myObject.makeNewestAttrib()
print myObject.newestAttrib
myObject.printNewestAttrib()
Gives following output:
one
here is: -one-
--- The Change ---
three
once again -three-
>This can result
> in objects in the same program that
> report the same type, but behave
> differently. When a class is modified
> in Ruby, every object of that class
> immediately exhibits the changed
> behavior/interface.
1.) You see above, that Python does the same.
2.) Ruby has been praised for the ability to
do exactly what you find fault:
Have the possibility to change a dedicated _object_
with object.extend without changing the whole class.
So what?
> 3. 'self' as a keyword. In Python, you
> must put 'self' in the argument
> declaration of every method;
which allows the class extension you see above.
> In effect, Python forces
> the programmer to help the interpreter
> to remember what object the method has
> been called on.
Yes, its annoying, especially if you work with
different languages in parallel. You everytime forget
to write this to the signature.
> In Ruby, 'self' is a
> keyword; in a method body, 'self' always
> refers to the object that the method was
> called from. No need to define 'self'
> in the argument list.
[reply]
[top]
[»]
Re: What does "more OO" mean?
by brixen3 - May 14th 2004 13:07:11
>
> [Ack. so far]
>
> > 2. Ruby has true open classes. Python
> > allows you to redefine existing classes;
> > but when you do, existing instances of
> > the redefined class do not reflect any
> > changes you made to the class. Only
> > objects created after the redefinition
> > pick up on the changes.
>
>
>
> That's definitely not true (following
> code tested
> on Jython 2.1):
>
>
> class MyClass:
> myAttrib = "one"
> def
> showMyAttrib(self):
> print
> 'here is: -%s-' % self.myAttrib
>
>
> def changeAClass(klasse):
> def aPrinter(self):
> print
> "once again -%s-" % self.newestAttrib
> def
> makeNewestAttrib(self):
> self.newestAttrib
> = 'three'
> klasse.__dict__["makeNewestAttrib"]
> = makeNewestAttrib
> klasse.__dict__["printNewestAttrib"]
> = aPrinter
>
>
>
> myObject = MyClass()
> print myObject.myAttrib
> myObject.showMyAttrib()
> print "--- The Change ---"
> changeAClass(MyClass)
> myObject.makeNewestAttrib()
> print myObject.newestAttrib
> myObject.printNewestAttrib()
>
> Gives following output:
>
> one
> here is: -one-
> --- The Change ---
> three
> once again -three-
>
>
>
> > This can result in objects in the same program that
> > report the same type, but behave differently.
> > When a class is modified in Ruby, every object of
> > that class immediately exhibits the changed
> > behavior/interface.
>
>
> 1.) You see above, that Python does the
> same.
I may misunderstand, but I think the original author's point can be
demonstrated as follows:
Python 2.3 (#1, Aug 19 2003, 15:54:06)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> class Foo:
... def func(self):
... print 5
...
>>> f = Foo()
>>> class Foo:
... def func(self):
... print 9
...
>>> g = Foo()
>>> f.func()
5
>>> g.func()
9
>>> f.__class__
[class __main__.Foo at 0x4036492c]
>>> g.__class__
[class __main__.Foo at 0x4036495c]
whereas in Ruby (1.8.1):
irb(main):001:0> class Foo
irb(main):002:1> def func()
irb(main):003:2> print 5, "\n"
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> f = Foo.new
=> #[Foo:0x400cbcb8]
irb(main):007:0> f.func
5
=> nil
irb(main):008:0> class Foo
irb(main):009:1> def func()
irb(main):010:2> print 9, "\n"
irb(main):011:2> end
irb(main):012:1> end
=> nil
irb(main):013:0> g = Foo.new
=> #[Foo:0x400b0ecc]
irb(main):014:0> g.func
9
=> nil
irb(main):015:0> f.func
9
=> nil
irb(main):016:0> g.class
=> Foo
irb(main):017:0> f.class
=> Foo
So, I think the point was that, while in Ruby the class is always open,
in Python an object of the previous definition of the class is not updated
when the class is updated, as shown.
[reply]
[top]
[»]
Re: What does "more OO" mean?
by paul vudmaska - Sep 2nd 2003 03:01:36
Thanks a bunch for this article. I've been working with
a few scripting languages, weening myself from asp/
javascript, looking for a new server-side/language/
platform(not because i do no like javascript...M$). I'd
come to the conclusion Ruby was 'better' than
most(certainly php, probably python, and javascript
because is not well supported server-side), but i could
not have said
why as succinctly as you have. I'd mention, as a
differentiating factor, the inherent capabilites of
iterators with
scoping...for example, calling an iterating method on a
file and closing it magically at the end. Ruby rocks. It
does what you think it should.
Can't wait for it to mature/harden and i can get it on a
prod server.
Thanks!
-- My other sig sucks less
[reply]
[top]
[»]
Experiences from integrating Ruby with Siag Office
by Ulric Eriksson - Jan 7th 2002 17:45:36
Siag Office 3.5.0 (just released) includes some preliminary support for the
Ruby language. I didn't have any previous experience from Ruby, but plenty
from interfacing with other interpreter libraries. It was fairly
painless.
The interface is *very* similar to Scheme interpreters I've worked with,
especially Guile. I don't know if that is by design, by coincidence or
because they are actually related in some way.
There was one showstopper problem: Ruby has an internal header file called
regex.h, which is for some reason installed into the same directory as all
other Ruby headers. Creating nonstandard headers with the same name as
standard Posix headers is a Really Bad Idea. I solved it for myself by
renaming the file to something else and hacking the Ruby source
accordingly.
There is also the problem with esp. macros called generic names like TYPE
or VALUE, which is bound to cause collisions with other things. But that
didn't happen in this case.
[reply]
[top]
[»]
Alternative Programming Language
by Dave - Jan 6th 2002 02:17:41
I frequent Freshmeat and I never found a need to post anything till now. I
enjoy learning about new things in the development scene and Ruby struck me
as one of those things, however, this happened a couple of months back.
I heard the suggestion on an Alternative Tech site
www.rantitraveit.com
http://www.rantitraveit.com/cgi-bin/ikonboard/topic.cgi?forum=8&topic=1
It's good to see Freshmeat start to talk about it now though
-- -- Dave
[reply]
[top]
[»]
Heh, who's old...
by X-Nc - Jan 5th 2002 17:11:18
Ok, so I personally do not think that COBOL is anything but a very good
thing. Modern COBOL is very nice. But Ruby is so sweet. It's got the
best mix of perl and smalltalk that I can't help loving it.
-- If I actually _could_ spell I'd have spelled it right in the first place.
[reply]
[top]
[»]
PHP -> eRuby
by Sean Chittenden - Jan 5th 2002 17:04:37
And for those of you who are PHP fans, check out eRuby. Ruby works
extremely well as an embedded language like PHP. One of the big wins with
eRuby over PHP is that when you want to add a module to Ruby, you don't
have to recompile the interpreter: it's just a module that you require from
your script (like Perl).
-- --
Sean Chittenden
[reply]
[top]
[»]
Re: PHP -> eRuby
by Peter Petermann - Jan 10th 2002 12:33:36
> One of the big wins with eRuby over PHP
> is that when you want to add a module to
> Ruby, you don't have to recompile the
> interpreter: it's just a module that you
> require from your script (like Perl).
Well, you dont need to recompile php.
just use dl()
for loading a module direct from script:
http://www.php.net/manual/en/function.dl.php
regards,
Peter Petermann
[reply]
[top]
[»]
irb -> two nits...
by Sean Chittenden - Jan 5th 2002 14:29:35
I'm a big ruby user (ruby-dbi + postgres is a thing of beauty) and by far
and away, amongst the numberous cool thing that have stopped me from using
other languages if at all possible, is irb. Here's a quick session that
shows some of it's usefulness and also points out a small nit (same applies
to the string.capitalize! example):
> irb
irb(main):001:0> string = " this is a string "
" this is a string "
main):002:0> string.strip
"this is a string"
irb(main):003:0> string
" this is a string "
irb(main):004:0> string.strip!
"this is a string"
irb(main):005:0> string
"this is a string"
irb(main):006:0> puts string
this is a string
nil
irb(main):007:0> p string
"this is a string"
nil
irb(irb(main):008:0> exit
>
After 5 years of working with Perl, programming is fun again. -sc
-- --
Sean Chittenden
[reply]
[top]
[»]
Error?
by Chaz - Jan 5th 2002 13:49:21
In your article you say:
3.times { print " hey " } ==> " hey hey hey "
Surely the correct result would be " hey hey hey "?
[reply]
[top]
[»]
Re: Error?
by James Skarzinskas - Jan 5th 2002 20:28:46
> In your article you say:
>
> 3.times { print " hey " } ==> " hey
> hey hey "
>
> Surely the correct result would be "
> hey hey hey "?
People get the general idea, you don't need to troll the author of the
article; he simply wants to inform you of a great programming language.
What harm does it do you to overlook a simple mistake?
[reply]
[top]
[»]
Re: Error?
by Chaz - Jan 6th 2002 03:27:42
>
> % In your article you say:
> %
> % 3.times { print " hey " } ==> "
> hey
> % hey hey "
> %
> % Surely the correct result would be
> "
> % hey hey hey
> "?
>
>
> People get the general idea, you don't
> need to troll the author of the article;
> he simply wants to inform you of a great
> programming language. What harm does it
> do you to overlook a simple mistake?
>
>
I'm sad that you think of me as a troll :( I'm merely pointing out a
simple mistake in his post, no malice is intended towards ruby or the
author.
[reply]
[top]
[»]
Re: Error?
by James Skarzinskas - Jan 6th 2002 11:47:58
>
> %
> % % In your article you say:
> % %
> % % 3.times { print " hey " } ==>
> "
> % hey
> % % hey hey "
> % %
> % % Surely the correct result would
> be
> % "
> % %
> hey hey hey
> % "?
> %
> %
> % People get the general idea, you
> don't
> % need to troll the author of the
> article;
> % he simply wants to inform you of a
> great
> % programming language. What harm does
> it
> % do you to overlook a simple
> mistake?
> %
> %
>
>
> I'm sad that you think of me as a
> troll :( I'm merely pointing out a
> simple mistake in his post, no malice is
> intended towards ruby or the author.
>
To carry on the trend of long and meaningful posts:
Oops.
[reply]
[top]
[»]
I have secured food and shelter...
by Gabriel Emerson - Jan 5th 2002 12:55:02
I work for a company that allowed me to rewrite one of our existing
Windows/Visual Foxpro/COM systems using Ruby, and development has been
rapid and clean. The community is extremely helpful, there are excellent
books available, and the syntax is familiar enough that someone from a Java
or Perl background can pick it up quickly. Ruby has given us an easy way to
express our UML diagrams in code. Wrapping C with it is very easy, and
this has allowed me to add features to wrappers around upstream code
without difficulty.
One double-edged sword is the dynamic typing, which lets you do amazing
things, but at the price of any useful compile-time checking. We
compensate for this by using pair programming and test-first development.
Test suites and other tools for eXtreme Programming and friends seem
important to the community and there are a few testing frameworks
available.
I wouldn't hesitate to use Ruby on our next project.
[reply]
[top]
[»]
Revisionist history strikes again
by cypherpunks - Jan 5th 2002 10:51:19
I'm sure Ruby is great. Next time though check
your history a little better. Fortran preceded
Cobol. We'ld all be programming in Fortran
rather then Cobol if people didn't try new things.
Here is a URL.
[reply]
[top]
[»]
My take on Ruby
by kinginyellow - Jan 5th 2002 09:53:10
I recently learned Ruby and I really like it. I can't speak to Python
(although there is a Ruby faq about
it), but I do have a reasonable amount of Perl experience.
I find that Ruby works just as well as Perl as a "glue" language because
Ruby borrows a lot of the things that make Perl so well suited to that role
(e.g. regexps, the backtick operator, pipes, easy text processing). You
also have added to that Ruby iterators, among other things. This is a
tremendously powerful and practical feature. Once you get used to it, you
will really find yourself missing it in other languages. There is also
Ruby's exception handling system, which can be very useful for this type of
thing. Perl's main advantage over Ruby in the glue language arena is its
huge number of add-on modules. Ruby is getting better in this area, but you
still won't find Ruby analogues for Perl's more esoteric modules.
Where Ruby really shines is in building more complex projects where OO
design strategies become useful. Ruby's OO features are simple, elegant,
extremely powerful, and much easier to understand than Perl's for
non-wizards. It really does seem more akin to Smalltalk than anything else
I've used (conceptually, if not syntactically), but not as "weird".
Anyway, just wanted to share the impressions I drew from my experience
with Ruby. It's an interesting language and I definitely recommend checking
it out.
[reply]
[top]
[»]
Iterators ain't nothing new,
by Guss - Jan 14th 2002 19:42:35
And perl implements something much more useful, and to my taste - better
designed : the anonymous subroutine or code block. for example, take this
piece of code (I could have written it better, I know - but it gets the job
done) :
@list = (1,2,3,4);
iterate (sub { print "number: $_[0]\n"; },@list);
sub iterate {
my ($code,@input) = @_;
foreach $num (@input) {
&$code($num);
}
}
there is no "magic" yield method, no "magic" code blocks apended to a
function call - you just pass a code block as a parameter to a term or a
subroutine. you can also pass code references if you like. if you've ever
used the sort term in perl, then you've used anonymouse code blocks.
Iterators in Perl are even more fun when using closures :
@list = (1,2,3,4);
$itr = make_itr(@list);
while (defined($next = &$itr)) {
print "number $next\n";
}
sub make_itr {
my @data_range = @_;
my $cur = 0;
return sub {
return undef unless ($cur < @data_range);
return $data_range[$cur++];
};
}
hmm.. comes to think of it, Perl has one more ace against Ruby - Perl
developers have better job security ;-)
[reply]
[top]
[»]
Re: Iterators ain't nothing new,
by r.fan - Jan 15th 2002 03:47:11
> And perl implements something much more
> useful, and to my taste - better
> designed : the anonymous subroutine or
> code block.
Ruby has those too. They're called procs.
They are also closures.
> there is no "magic" yield method, no
> "magic" code blocks apended to a
> function call - you just pass a code
> block as a parameter to a term or a
> subroutine. you can also pass code
> references if you like.
I suspect that I could do, in Ruby (without using
yield), exactly what you've done in Perl if I used
procs. But yield makes it so much easier and more
readable. Yes, I came from Perl-land as well and
initially I didn't see why I needed 'yield'
either, but look a bit more closely and perhaps
actually play with it and you'll come to really
apreciate it.
(BTW: yield is being added to Perl6)
>starquote%
> hmm.. comes to think of it, Perl has
> one more ace against Ruby - Perl
> developers have better job security ;-)
Yeah, they have to keep the perl developer around
because nobody else in the oragnization (including
other Perl programmers) can figure out what the
program was supposed to do. ;-)
pt
[reply]
[top]
[»]
Re: Iterators ain't nothing new,
by BluesMoon - Mar 19th 2002 05:29:09
% @list = (1,2,3,4);
> iterate (sub { print "number:
well, if your first argument is a code block, then the sub keyword is
optional. the parens are optional anyway, so you could really write it
like this:
iterate { CODE } @list;
which makes it much more along the lines of
map {CODE} @list;
grep {CODE} @list;
sort {CODE} @list;
functional programming in perl
[reply]
[top]
[»]
Re: Iterators ain't nothing new,
by Guss - Mar 19th 2002 13:40:12
> well, if your first argument is a code
> block, then the sub keyword is optional.
> the parens are optional anyway, so you
> could really write it like this:
>
> iterate { CODE } @list;
>
> which makes it much more along the
> lines of
>
> map {CODE} @list;
> grep {CODE} @list;
> sort {CODE} @list;
>
> functional programming in perl
Yea, well - the nice thing about Perl, is that it doesn't force you into
using a single programming technique or paradigm. although basicly if a
procedural language, you can write functional perl, OO perl, or plain old
a-la basic flat perl (with gotos sprinkled for good measure ;-)
[reply]
[top]
[»]
Re: Iterators ain't nothing new,
by Det - Jun 18th 2002 05:07:13
>
> % well, if your first argument is a
> code
> % block, then the sub keyword is
> optional.
> % the parens are optional anyway, so
> you
> % could really write it like this:
> %
> % iterate { CODE } @list;
> %
> % which makes it much more along the
> % lines of
> %
> % map {CODE} @list;
> % grep {CODE} @list;
> % sort {CODE} @list;
> %
> % functional programming in perl
>
>
> Yea, well - the nice thing about Perl,
> is that it doesn't force you into using
> a single programming technique or
> paradigm. although basicly if a
> procedural language, you can write
> functional perl, OO perl, or plain old
> a-la basic flat perl (with gotos
> sprinkled for good measure ;-)
Again this is nothing special. Python explicitly does the same, as you
can use it procedural and it has features for functional programming,
especially the map, reduce and filter functions, and a strong list type.
OTOH: You can use Ruby in a procedural way too, as you can define
functions without classes (although they will become methods of object ...
what does it matter?) , and have statements on file level without
surrounding methods (even like in a procedural script).
You can think of some Ruby features from a functional point of view, e.g.
when passing around Procs, or using the "anonymous function"
called 'block'...
No outstanding features of perl, these.
[reply]
[top]
[»]
The nicest language I've ever used.
by Stephen Ramsay - Jan 5th 2002 08:49:49
I try not to be terribly pedantic when it comes to languages, and I'm
happy using several in my professional life, but Ruby is far and away the
nicest language I've ever used. I love Perl, but I've always wanted better
OO support. Python is nice, but I think it's obvious that OO isn't Van
Rossum's preferred paradigm (which is fine). Java is a great language with
great OO facilities (like abstract classes and interfaces), but the syntax
is verbose and it lacks the text-manipulation power and ease-of-use of
either Perl or Python. C++ is, well, C++.
I still use all these other languages, but Ruby has definitely become
my favorite. The OO is outstanding (everything is an object; there are no
exceptions. period), and the syntax is incredibly clean. Once you're
introduced to blocks and iterators I guarantee you'll become an addict. I
haven't seen any benches, but it seems palpably faster than Python. All in
all, it feels like the language in which all the things that annoy me about
the other languages (sometimes minor things) have been done away with.
Someone characterized Ruby as the first "post-scripting" language. I
absolutely agree. I wouldn't hesitate to write a very large system in it,
and I definitely wouldn't hesitate to recommend it to anyone.
-- Stephen Ramsay
Senior Programmer
Institute for Advanced Technology in the Humanities
University of Virginia
[reply]
[top]
[»]
The expected (probably) Python 2.2 comment
by JohnBE - Jan 5th 2002 08:04:10
Ruby is a fine language, I have tried it.
However I would really recommend Python 2.2 [http://www.python.org/2.2/],
why?
Well, mainly because of the wealth of
bundled modules and classes. Most tasks can be
coded in a few minutes without thought!
Not neccisarily a good thing I beleive, but it does
allow rapid prototyping of the four in the morning
"hey I wonder if that will work" syndrome
allowing me to get some sleep.
The crossplatform consistancey of supplied
classes is also very good. My only niggle with the
old versions was the inbalance between types and
classes, this is now fixed in version 2.2.
Also, for colleagues, the code (although
probably not mine) is readable, almost like a object
orientated version of pseudocode (see caveat in
last brackets). Although maybe understanding of
classes is essential for quick pickup, but if you've
coded C++ it's very easy to pickup.
Da da, da da da Da Da Da, da da Da da Da
Daaa.
[reply]
[top]
[»]
A Suggested Cure for the Missing Ruby Module Problem
by GrepNinja - Jan 20th 2002 04:50:00
> Ruby is a fine language, I have tried
> it.
> However I would really recommend
> Python 2.2 [
>
> href=http://www.python.org/2.2/>http://www.python.org/2.2/],
> why?
> Well, mainly because of the wealth of
> bundled modules and classes.
[...snip...]
If you feel Ruby is missing some of the modules and class library support
available in Perl and Python, I would ask you to consider the relative ages
of these fine languages. As is self-evident from a cursory perusal of the
Library Reference, at http://www.rubycentral.com/ref/index.html, and the
Ruby Application Archive (RAA) at http://www.ruby-lang.org/en/raa.html,
volunteers have added a *huge* amount of functionality to Ruby in a *very*
short time.
My humble suggestion: Ruby is fully Open Source, with a great and
friendly user community. Feel free to contribute any modules you and your
chosen army of coding fiends and friends believe are needed. Your help
would be most welcome!
Grepninja -- (who appreciates and uses *all* of the aforementioned
languages *plus* Squeak SmallTalk, Java, and C# and finds Ruby the most
SmallTalk-comparable language he has seen outside of a SmallTalk Image and
it even has full block closures thrown in for free -- Ruby is immensely
cool!)
[reply]
[top]
|
 |