How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?

[Paul Prescod]

Re: How does Ruby compare to Python?? How good is DESIGNof Rubycompared to Python?

Joe Mason wrote:
[color=blue]
>...
>
>
> I've always found the performance differences between functional and imperative
> languages fascinating (well, ever since I found out about it) - on the
> one hand, pure functional languages can prove facts about the code
> mathematically, so in theory the compiler can optimize much more away.
> But on the other hand, supporting all the extra function state they need
> is very costly.[/color]

What do you mean by "extra function state?" Are you talking about LAZY
functional languages?
[color=blue]
> Of course, hybrid languages like Python and Ruby have the worst of both
> worlds - side effects everywhere AND extra function baggage to pass
> around.[/color]

I don't know what you mean by "extra function baggage" and I don't see
how (e.g.) Python has some and Java or C# dn't. Maybe Haskell (but maybe
not). I don't know what you mean about Python.

Paul Prescod

[Duncan Booth]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

Joe Mason <joe@notcharles .ca> wrote in
news:slrnc3q0j8 .jm5.joe@gate.n otcharles.ca:
[color=blue]
> A better example of buond vs. unbound methods is this:
>
> def boundFunc(callb ack):
> print callback(5, 6)
>
> def unboundFunc(obj , callback):
> print callback(obj, 5, 6)
>
> def functionCallbac k(a, b):
> return a + b
>
> class Foo:
> def methodCallback( self, a, b):
> return a * b + self.c
> def setc(self, c):
> self.c = c
>[color=green][color=darkred]
>>>> boundFunc(funct ionCallback)[/color][/color]
> 11[color=green][color=darkred]
>>>> f = Foo()
>>>> f.setc(3)
>>>> boundFunc(f.met hodCallback)[/color][/color]
> 33[color=green][color=darkred]
>>>> unboundFunc(f, Foo.methodCallb ack)[/color][/color]
> 33[/color]

Say I modify your example so that we only have one Func which accepts
either a bound or unbound (functionCallba ck and Foo definitions are
unchanged):
[color=blue][color=green][color=darkred]
>>> def Func(callback, *extra_args):[/color][/color][/color]
print callback(*(extr a_args+(5,6)))

[color=blue][color=green][color=darkred]
>>> Func(functionCa llback)[/color][/color][/color]
11[color=blue][color=green][color=darkred]
>>> f = Foo()
>>> f.setc(3)
>>> Func(f.methodCa llback)[/color][/color][/color]
33[color=blue][color=green][color=darkred]
>>> Func(Foo.method Callback, f)[/color][/color][/color]
33[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Python doesn't care what type of callable it is passed, so long as it
somehow ends up with the right arguments to call it. Can Ruby handle this
case?

[Stephen Horne]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

On Thu, 26 Feb 2004 02:48:30 GMT, Joe Mason <joe@notcharles .ca> wrote:
[color=blue]
>In article <t5fq30l29nidjh 1tsksm8jlld03ff 3av5o@4ax.com>, Stephen Horne wrote:[color=green]
>> I don't know how widespread it is among very high level languages, but
>> there is a reason (in the not-that-high-level sense) that C++, and
>> other 3GLs with classes hacked on don't. I'm assuming object Pascals
>> and Basics (esp Delphi and VB) count here, though don't sue me if I'm
>> wrong - I'm not familiar with object support in either.[/color]
>
>I didn't think Pascals and Basics supported function pointers at all,
>but I haven't used them since high school, so maybe I just didn't
>encounter them at the time.[/color]

I'd be surprised if Delphi and VB don't have function pointers.
Without them, it would be impossible to use Windows API calls that
require callback functions for instance. Whether they are in the
Pascal and Basic standards, though, is an entirely different thing.
[color=blue][color=green]
>> Anyway, from this perspective, the bound method is an interesting
>> in-between concept. I've sometimes wondered if full currying support
>> may have been a better choice, but then a bound method is much more
>> efficient simply because it's simpler - not to mention avoiding some
>> syntactic difficulties I ignored above.[/color]
>
>I've always found the performance differences between functional and imperative
>languages fascinating (well, ever since I found out about it) - on the
>one hand, pure functional languages can prove facts about the code
>mathematically , so in theory the compiler can optimize much more away.
>But on the other hand, supporting all the extra function state they need
>is very costly.[/color]

Hmmm - I think you may be confusing the functional vs imperative
distinction with something else. Supporting a functional style does
not, in itself, require any special baggage.

Python carries some extra baggage in each object. However, that
baggage has nothing to do with functional support - it is needed for
dynamic typing, run-time binding, reference counting etc. In the case
of dynamic typing and run-time binding, for instance, Python objects
use a system similar to that used in C++ for run-time binding (ie
virtual methods) and run-time type identification - each object has a
pointer to a block of data describing its type and how to use it (a
virtual table in C++, the type object in Python).

Haskell is a good pure-functional language to use as a comparison.
Haskell has dynamic typing, but you can restrict types in a static way
when you choose. Haskell therefore only includes dynamic typing
'baggage' when it is necessary.


In Python, we pay a bit in runtime efficiency for scripting-language
flexibility - for dynamic typing, garbage collection, run-time symbol
tables etc - and we get pretty good value, or else we'd be using some
other language. But I can't really think of a functional-style feature
of Python that results in extra baggage for Python objects.

Perhaps first class functions? No - the necessary 'overhead' in
comparison with, say, C function pointers is already present in order
to support dynamic typing.


Imperative languages can have run-time efficiency advantages, of
course. One is that a human programmer usually knows whether in-place
modification or replacement of data is appropriate, and tells an
imperitive language which to use. In a functional language, the
compiler has to work this out for itself as an optimisation, and it
can't always be sure.

For instance, it can be quite hard for programmers with imperitive
blinkers on to understand how Haskell can handle sorting. Many have
claimed that it can't - and immediately been proved wrong by someone
presenting the code that does it. But to imperitive-biassed eyes, that
code may look a lot like a joke.

To illustrate, a literal Python translation of a Haskell quicksort
would be something like...

def quicksort (p) :
if len(p_Data) > 1 :
l_Pivot = p [0]

return quicksort ([i for i in p [1:] if i < l_Pivot])
+ [l_Pivot]
+ quicksort ([i for i in p [1:] if i >= l_Pivot])

else :
return p_Data

In Python, of course, this would be bad code - it creates huge numbers
of small sorted sequences only to discard them almost instantly. The
average performance is still the same old O(n long n) and the worst
case still O(n^2), but the problem is the scaling constants involved
in all the unnecessary work.

The key difference between Python and Haskell here is that a good
Haskell compiler should be able to optimise out all the throwaway
intermediate lists, and should even be able to determine for itself
whether an in-place modification of the original list is valid.
Python, of course, does not - it is the programmers responsibility to
handle sorting in a more efficient way.

My guess would be that Haskells method might fall down when, for
instance, the quicksort function is held in a separately compiled
library. In that case, the compilers analysis of the quicksort cannot
determine whether the initial unsorted list is used again after the
sort, so it can't know whether it is safe to overwrite the unsorted
list using an in-place method or not. Though even then, the library
could hold variants for both cases. I don't know enough about Haskell
to say, really.


One possibility where both Python and Haskell might have related
run-time issues is in cache friendliness. In Pythons case, this
results from the fact that all variables are bound using references,
all values are passed using references, etc. If you access a C
array-of-simple-values/structs sequentially, the way that RAM caching
and virtual memory operate on modern machines tends to mean that most
accesses are to fast cache memory because the data has been brought in
already along with earlier items. In Python, that doesn't tend to work
out because the actual values within the list are not normally
adjacent in memory - only the references are adjacent. This happens in
Haskell for much the same reason, though a Haskell compiler should
have a much better chance of optimising.

But even with cache friendliness, this isn't 'baggage from functional
features' in any sense. In fact, it often happens in C++ too - if you
are not certain of the concrete type of an object (you only know that
it is a subtype of a particular base class) you have to pass and store
a pointer rather than the object itself because you can't know at
compile time how much space the object takes up in memory, so you
can't reserve the space for it statically. So if you need (perhaps in
a drawing program) an array of shape objects, where each shape may be
an arbitrary subtype of the main shape base class, you actually have
to implement that as an array of pointers to shape objects. And the
shape objects are not likely to be at adjacent locations in memory, so
the drawing loop will make a much higher proportion of accesses to
relatively slow memory.

BTW - the reason this came to mind is because I'm currently working on
a Python extension module which supports a dynamically constructed
C-like struct (which can hold both Python objects and simple C-like
values - various sizes of integers and floats, plus fixed-length
null-padded string buffers using either 8- or 16-bit characters) and
can use them as both keys and values in a range of containers. For
records with no Python objects at all, I may add some
fixed-record-size file access stuff - but I have concerns about
portability and things ending with 'endian' etc. I've covered some of
the ground using the Boost/Python libraries before, but am now
discovering that the Python/C APIs aren't so very hard after all ;-)


Anyway, the real costs of using functional languages don't occur at
run-time. They occur at compile-time, as deep optimisations are very
far from trivial. I can't imagine turning off optimisations in a C++
compiler just to improve build speed, but in the Haskell world there
are compilers considered appropriate for development and prototyping
(minimal optimisations) and compilers considered appropriate for the
final release. I don't have the Haskell experience to know, but when
programmers make the effort to use a completely different compiler
just to reduce build times, I figure the difference must be pretty
substantial for large programs.
[color=blue]
>Of course, hybrid languages like Python and Ruby have the worst of both
>worlds - side effects everywhere AND extra function baggage to pass
>around.[/color]

Not true. You do get quite high run-time costs in Python (and Perl,
and ...), but you get a lot in return - very good value IMO. And the
run-time costs in Python don't derive from functional features.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Stephen Horne]

Re: Foundations of computing languages (was: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?)

On Thu, 26 Feb 2004 04:24:28 -0000, claird@lairds.c om (Cameron Laird)
wrote:
[color=blue]
>In article <103qr5nhpiojv2 5@corp.supernew s.com>, I griped:[/color]
[color=blue][color=green]
>>Ouch! I'm old enough to take some of this personally.
>>Unless you're making some extremely recondite point
>>(about Skolem's influences?), "a century" is too rough
>>an approximation for me. Church and Kleene introduced
>>the lambda calculus in the '30s; Schoenfinkel, then
>>Curry, invented currying the decade before.[/color][/color]

Oops - sorry
[color=blue]
>Wrong. Well, true, all of it, but I'm neglecting Frege.[/color]

That's interesting, but I was actually thinking of Church and Kleene.
I'm just so rusty on my history that I only had a *very* vague sense
of the dates and didn't even remember that anonymous functions and
currying predate lambda calculus. You can rest assured that my wrist
has been slapped.

I don't think I ever heard of Frege before. Nor Skolem. Which is quite
bad, really, if the impressions I've just got from some quick searches
are right.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Joe Mason]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

In article <Xns949B61515EF D1duncanrcpcouk @127.0.0.1>, Duncan Booth wrote:[color=blue]
> Say I modify your example so that we only have one Func which accepts
> either a bound or unbound (functionCallba ck and Foo definitions are
> unchanged):
>[color=green][color=darkred]
>>>> def Func(callback, *extra_args):[/color][/color]
> print callback(*(extr a_args+(5,6)))
>
>[color=green][color=darkred]
>>>> Func(functionCa llback)[/color][/color]
> 11[color=green][color=darkred]
>>>> f = Foo()
>>>> f.setc(3)
>>>> Func(f.methodCa llback)[/color][/color]
> 33[color=green][color=darkred]
>>>> Func(Foo.method Callback, f)[/color][/color]
> 33[color=green][color=darkred]
>>>>[/color][/color]
>
> Python doesn't care what type of callable it is passed, so long as it
> somehow ends up with the right arguments to call it. Can Ruby handle this
> case?[/color]

Sure, you'd just have to check if "callback" is of class Method or
UnboundMethod, and call bind on the first member of extra_args if
necessary. Again, Python does this for you, so it's definitely a
difference in the language, but it's not impossible (or even difficult).

With Ruby, you'd probably use blocks instead of functions for most
things that need this anyway.

Joe

[Joe Mason]

Functional languages vs. hybrids (was Re: How does Ruby compare to Python?? How good is DESIGN ofRubycompared to Python?)

Following Cameron's lead, I think it's time to retitle this thread...

In article <mailman.145.10 77775035.8594.p ython-list@python.org >, Paul Prescod wrote:[color=blue][color=green]
>> I've always found the performance differences between functional and imperative
>> languages fascinating (well, ever since I found out about it) - on the
>> one hand, pure functional languages can prove facts about the code
>> mathematically, so in theory the compiler can optimize much more away.
>> But on the other hand, supporting all the extra function state they need
>> is very costly.[/color]
>
> What do you mean by "extra function state?" Are you talking about LAZY
> functional languages?[/color]

I was just being over-general. Lemme see how much of this I can remember
without walking across the room to get a textbook...

Down in the depths of the compiler, the simplest way to implement
(C-style) functions is just to total up all the parameters and local
space it will need and lay out a stack frame. Then the optimizer runs
through and tries to remove as much overhead as possible, inlines some
functions, etc. The basic C++ object method is just a C function with
an extra parameter, just like Python's "self".

This works fine if functions are just named subroutines that can't be
passed around as values. If you add the ability to pass functions
around - C can do this with function pointers - that's fine too.

If you add nested functions, but not function pointers, you still don't
need to change too much. The only difference is that the amount of data
you need to make accessible goes up: as well as the function local
variables and parameters, and the global scope, you need to add all the
enclosing scopes. You can either just append all these to the local
scope, and then optimize out any variables that aren't actually used, or
add a pointer to the enclosing stack frame. This works because, since
you can't pass functions around, you're guaranteed that a nested
function can only be entered while its parent function has a frame on
the stack.

As soon as you add both function pointers and nested functions, this
isn't good enough. Now you can call a function, creating a scope, and
then return a function that needs access to that scope. If you destroy
the scope on return like usual, the function you just returned will
break. So scope is no longer just a stack frame. In functional
languages, all functions are full closures (meaning they carry with them
all the environment they need to run), which is more expensive.

The reason C is fast is that it's pretty close to the bare machine -
it's really just a thin shell over assembly language. C++ isn't much
more, for all it's bells and whistles. (Of course, the more the
machines mangle the code in complicated ways - branch prediction and
code morphing and whatnot - the less that's true. But of course CPU's
are designed to run mainly C/C++ code, so of course none of these
optimizations will hurt.) In pure functional languages, ironically,
functions hurt performance, but in theory they can be optimized much
more because the sections which can have side effects are clearly marked
off. I haven't actually looked at any benchmarks to see what this
translates to in the real world, but I thought it was interesting.
(Maybe "fascinatin g" was too strong.)

Now somebody will surely chime in about Lisp machines...
[color=blue][color=green]
>> Of course, hybrid languages like Python and Ruby have the worst of both
>> worlds - side effects everywhere AND extra function baggage to pass
>> around.[/color]
>
> I don't know what you mean by "extra function baggage" and I don't see
> how (e.g.) Python has some and Java or C# dn't. Maybe Haskell (but maybe
> not). I don't know what you mean about Python.[/color]

....hybrid languages like Python and Ruby and Java and C#, then. It's
the combination of first-order functions *and* side effects that kills
you. (I don't know enough Java/C# to know if they have nested functions
and "function pointers" or equivalent - it actually wouldn't surprise me
if Java doesn't.)

Dynamic scripting languages aren't trying to go toe to toe with C on
performance, of course, so this isn't a criticism.

Joe

[Ville Vainio]

Re: How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?

>>>>> "MetalOne" == MetalOne <jcb@iteris.com > writes:

MetalOne> Ruby is a fine language, but the community is smaller,
MetalOne> the bindings to external libraries are smaller and the
MetalOne> number of extra packages are smaller.

So, basically, it's probably not worth the trouble. It's a less mature
implementation of pretty much the same ideas.

If you are jonesing for a new language to play with, you could as well
play with Lisp. At least you would learn something new.

--
Ville Vainio http://tinyurl.com/2prnb

[A.M. Kuchling]

Re: How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?

On 27 Feb 2004 10:36:39 +0200,
Ville Vainio <ville@spammers .com> wrote:[color=blue]
> If you are jonesing for a new language to play with, you could as well
> play with Lisp. At least you would learn something new.[/color]

That's pretty much my reaction to Ruby, too. It's kind of neat, and if I
was a Perl person I'd go use Ruby instead of waiting for Perl 6, but it
isn't so different from the existing scripting languages. If your interest
is in learning new ways of programming that turn your head around, you'd
need to look farther afield (Haskell, ML, Lisp, etc.).

--amk

[Paul Prescod]

Re: Functional languages vs. hybrids (was Re: How does Ruby compareto Python?? How good is DESIGN ofRubycompared to Python?)

Joe Mason wrote:
[color=blue]
>...
> Down in the depths of the compiler, the simplest way to
> implement (C-style) functions is just to total up all the
> parameters and local space it will need and lay out a
> stack frame.[/color]

We're talking about Python and the Python compiler generates Python
bytecodes, not machine code!
[color=blue]
> ...hybrid languages like Python and Ruby and Java and C#, then. It's
> the combination of first-order functions *and* side effects that kills
> you. (I don't know enough Java/C# to know if they have nested functions
> and "function pointers" or equivalent - it actually wouldn't surprise me
> if Java doesn't.)[/color]

Python function calling was never even remotely close to machine
function calls for a variety of reasons (primarily the fact that we're
talking about an interpreter rather than a compiler).

You may well be right that Python _would_ pay a cost for nested
functions if its function model was not already substantially more
complicated, sophisticated and expensive than C's. But there are all
sorts of reasons that Python function calls are slow and I frankly think
that nested scopes are the least of them:

* Python functions use a stack that is different than the C stack
(that's why stackless is even possible)

* Python functions have complicated calling conventions (varargs,
optional args, keyword args)

* Python functions are called through a protocol that supports other
types of "callables"

* Python integers etc. must be unboxed after the function call to do
anything useful with them

All of these performance-sucking features were in Python long before
nested functions.

Paul Prescod

[Joe Mason]

Re: Functional languages vs. hybrids (was Re: How does Ruby compare to Python?? How good is DESIGN ofRubycompared to Python?)

In article <mailman.246.10 77987607.8594.p ython-list@python.org >, Paul Prescod wrote:[color=blue]
> Joe Mason wrote:
>[color=green]
>>...
> > Down in the depths of the compiler, the simplest way to
> > implement (C-style) functions is just to total up all the
> > parameters and local space it will need and lay out a
> > stack frame.[/color]
>
> We're talking about Python and the Python compiler generates Python
> bytecodes, not machine code![/color]

I wasn't anymore, which is why I changed the thread title.
[color=blue]
> Python function calling was never even remotely close to machine
> function calls for a variety of reasons (primarily the fact that we're
> talking about an interpreter rather than a compiler).[/color]

That's a good thing to point out, though. I didn't mean to imply that
the first-order-function price was the main, or even an important, thing
that made Python slower than C. (I actually said that a couple of
times, and kept snipping it because it kept coming out sounding like I
was dumping on Python for being slow. Should've kept it in.)

Joe

[Mark 'Kamikaze' Hughes]

Re: How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?

A.M. Kuchling <amk@amk.ca>
wrote on Fri, 27 Feb 2004 07:42:42 -0600:[color=blue]
> On 27 Feb 2004 10:36:39 +0200,
> Ville Vainio <ville@spammers .com> wrote:[color=green]
>> If you are jonesing for a new language to play with, you could as well
>> play with Lisp. At least you would learn something new.[/color]
> That's pretty much my reaction to Ruby, too. It's kind of neat, and if I
> was a Perl person I'd go use Ruby instead of waiting for Perl 6, but it
> isn't so different from the existing scripting languages.[/color]

The primary virtue of Perl used to be that it was the only language
with decent regexp support. But now everyone has good regexp support.
[color=blue]
> If your interest
> is in learning new ways of programming that turn your head around, you'd
> need to look farther afield (Haskell, ML, Lisp, etc.).[/color]

And I'd second either OCaml or Haskell as good languages if you want
to learn something new, while still being useful for real work. Pure ML
is rather awful to do real work in, though it can be done if you're
sufficiently functional-minded. OCaml is a pragmatic compromise of ML
with programming reality. Haskell, too, is a fairly pragmatic design.
I don't think you should deploy either one where someone else might have
to maintain your code, but they're educational.

Self would be another good educational language, but its current
implementation is not very portable.

--
<a href="http://kuoi.asui.uidah o.edu/~kamikaze/"> Mark Hughes </a>
"Doing the impossible makes us mighty." -Captain Malcolm Reynolds, Firefly

[David MacQuigg]

Re: How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?

On 24 Feb 2004 14:43:03 -0800, seberino@spawar .navy.mil (Christian
Seberino) wrote:
[color=blue]
>How does Ruby compare to Python?? How good is DESIGN of Ruby compared to Python?[/color]

This question was recently asked in the UserLinux mailing list, in
connection with our selection of Python as the primary scripting
language. I put together a page of links to other good discussions
and documents http://userlinux.com/cgi-bin/wiki.pl?RubyPython and got
some comments from the Ruby mailing list

http://www.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=9k3k30l67d7j1beguaqg24uc2tmgvtefl1%404ax.com&rnum=1&prev=/groups%3Fq%3Dcompare%2Bruby%2Bpython%2Bgroup:comp.lang.ruby%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D9k3k30l67d7j1beguaqg24uc2tmgvtefl1%25404ax.com%26rnum%3D1

I was considering only the language aspects of the comparison, leaving
aside the number of users, projects, libraries, etc. I had to sift
through tons of stuff in the mailing lists look for examples of
anything beyond personal preferences for one style over another. I
came up with two fundamental differences ( see the link above ):
1) Ruby seems to have a slight advantage in handling complex sequences
of string operations, especially operations that can be stated
concisely as a string of method calls. I say slight advantage,
because the missing string and list methods could easily be added.
2) Ruby allows you to change the fundamental behavior of core classes
and operations. If you want string comparisons to be
case-insensitive, for example, you can modify the language to make
that happen. In Python, you make a subclass of string, and over-ride
the __eq__ method -- not as convenient if what you are trying to do is
change the behavior of a large body of already written code.

Alex Martelli, the source of example 2 above, pointed out that this is
not a deficiency of Python, but a deliberate design choice, making
Python more suitable for production work, but less advantageous as an
experimental language. In a production environment, we really *don't*
want to make it easy to redefine the behavior of the string class ( as
opposed to over-riding it in your own class ). We all need to share a
common language.

There is also a frequently stated difference between the use of code
blocks in Ruby and Generators in Python, but I was never able to find
an example where the Python code couldn't be made equivalent to Ruby.
The example on the wiki page above shows that the two differ only in
calling style. My tenetative conclusion is that there must be some
impressive difference in the way these features work internally, but
to the user it's just a matter of personal preference -- Do you want
to say:
fibUpTo(1000) { |f| print f, " " }
or
for f in fibUpTo(1000): print f,

If there are any Ruby experts here, please take a look at this
generator example. If there really is some fundametal difference
relevant to the user, I would like to know.

-- Dave

[Greg Ewing (using news.cis.dfn.de)]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

Joe Mason wrote:[color=blue]
> I don't see the distinction. "normal calling syntax" in ruby involves
> an object, so "unbound function" isn't a meaningful concept.[/color]

Which is just what I was trying to say, really. Ruby doesn't
have functions, only methods. I'm not saying one is better
than the other, just pointing out the difference.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing (using news.cis.dfn.de)]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?

Cameron Laird wrote:[color=blue]
> While I'm all in favor of distinguishing superficial from
> fundamental characteristics , I think the last sentence
> above is misleading. Ruby is a direct descendant from
> Perl, I'm sure; I thought I had the word from Matz himself
> that he deliberately modeled a great deal of Ruby on Perl
> (and Smalltalk, of course).[/color]

I'm just going by what I see in the language. Beneath the
syntax, I see a lot that's very Smalltalk-like in Ruby.
I don't see anything that's fundamentally Perl-like,
on the other hand.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing (using news.cis.dfn.de)]

Re: How does Ruby compare to Python?? How good is DESIGN of Rubycomparedto Python?

Joe Mason wrote:[color=blue]
> I didn't think Pascals and Basics supported function pointers at all,
> but I haven't used them since high school, so maybe I just didn't
> encounter them at the time.[/color]

Some Basics would let you use the result of an expression as a
line number in a GOTO or GOSUB, just in case there weren't already
enough ways to turn your code into spaghetti. Those that didn't
usually had ON...GOTO and ON...GOSUB statements that could be used
to achieve much the same effect.

Pascal lets you pass a procedure as a parameter to another
procedure (but not store it in a variable, due to scope issues).
It's likely this wouldn't have been mentioned in an introductory
Pascal course, however, as it would have been considered a
somewhat esoteric feature.

Later Wirth languages (Modula, Oberon) do let you have procedure
variables. But they can only point to top-level procedures, not
nested ones. One step forward, one back...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg