"Robert Klemme" <bob.news / gmx.net> wrote in message news:<2m4dhrFis860U1 / uni-berlin.de>...
> "Uwe Schnitker" <schnitkerAffenschaukel / sigma-c.com> schrieb im
> Newsbeitrag news:30381f67.0407192151.25675ec2 / posting.google.com...
> > Gully Foyle <nospam / nospamnospamnospam.com> wrote in message
>  news:<hXHKc.38807$eH1.18448437 / newssvr28.news.prodigy.com>...
> > > I am currently using C++ as my compiled language but fell in love with
> > > Ruby recently :)
> > >
> > > Which compiled language is the closest to ruby?
> >
> > Isn't that obvious?  C++, of course.
> 
> You are kidding, are you?

No.

> > > Are there any that are
> > > object-oriented
> >
> > Both C++ and Ruby are multi-paradigm languages that support OO
>  programming,
> > but don't try to enforce OO programming.
> 
> I don't subscribe to that.  Ruby is much more OO than C++. 

IMHO this depends on how you define OO. It's clear that Ruby
supports some programming techniques that C++ doesn't. If you 
consider these techniques to be esential for OO, your statement
would be correct.

OTOH, I think it's bogus to call a language "less OO" because it 
supports programming techniques that are not OO >> in addition 
to << those that are.

Would you consider Ruby to become "less OO" if Matz added e.g.
direct support for Prolog-style logic programming, or for finite 
state machines, or whatever?

So why do you call C++ "less OO" just because it supports 
procedural programming and programming with concrete 
non-polymorphic classes >> in addition to << programming
with polymorphic objects?

> C++ has POD's,
> functions, static etc.  

Yes, and Ruby has all this Perl stuff: Globally accessible
handles, non-oo regexp syntax, ... So what?

> In Ruby, everything is an object and every method
> has a receiver.

Yes, and this has some nice effects.

But I find it important that you can ignore this: I can, e.g., 
write a global function in Ruby like I could write it in C++, 
even if it's implemented in a totally different way. 

> > (Unless, of course, you define OO
> > to necessarily include dynamic typing. And please note that I also
>  understand
> > that Ruby is implemented in an OO-centric way - "everything is an
>  object" -
> > but my point is that, unlike with (earlier versions of)
> 
> I don't see the point in comparing current Ruby with old versions of Java
> or whatsoever.

I just wanted to take into account that Java and C# are being 
enhanced with generics now. The "earlier version" I wrote about 
are what is currently used.
 
> > Java, C#, etc., you
> > can write (and call) free functions,
> 
> If you are referring to static methods, then that's not true for Ruby.
> There is no such thing as a static method in Ruby.

I'm referring to what other people call global functions (this 
term just doesn't make that much sense any more now that these 
are typically put into a namespace).

> > you can write generic code without casts,
> 
> You can write generic code,

That's what I want to do.

> because Ruby is dynamically typed, but Ruby
> does not support generic programming

If I can write generic code, I can do generic programming.

The important issue is the thought process: With statically 
typed OO, you have to say "this algorithm can sort objects of
any class that implements the ISortable interface" or "with 
this objects, objects of any class that implements IListener 
can register for notification", with generic programming you
say "this algorithm can sort objects of any type that defines
a suitable comparison" or "with this object, you can register 
for notifiction any (member) function, to be called on any
object".

> (like C++ with templates, Java
> Generics and others do).  Although this may sound paradox, I'd say that a
> static typed language is prerequisite for having generics.  And sice Ruby
> is not static typed there's simply no need for generics.

So there is no need for explicit generic programming support. 

Fine with me. 

My claim was "you can write generic code", not "Ruby has some 
special features to support generic programming".

You might say that a truly object-oriented language intrinsically 
supports this king of generic programming. No problem.

But this amounts to almost the same as saying that a truly
object-oriented language must be dynamically typed, which is 
quite a stretch. But I've no problem with that either, it's 
just a differently scoped definition of OO.
 
> > you can write "functional" code, ... That's multi-paradigm programming.)
> 
> I get the impression that you base your measure for closeness on this buzz
> word.  Personally I don't think this is a good choice.  Of course, there's
> always a perspective from which certain things look similar.  But the
> question is how much information do you gain by stating "C++ and Ruby are
> similar because they share some very abstract concepts".  That'll be true
> for Ruby and other programming languages, too.

Pardon, but you misunderstood me. I'm not talking about abstract
concepts regarding programming language research. I'm talking about
abstract concepts regarding designing and implementing code, which
is - or at least should be, sigh - my daily work.

Need an algorithm to work on objects of any specified type
  -> think generic
Need to process different objects using only their common behavour 
  -> think OO
Need to dispatch any operation created by the batch file parser 
  -> combine OO and generic thinking and use a polymorphic functor
     template facillity.

[I'm caricaturing - is that a word? - here. But just a bit.]

> > > and have support for blocks/closures?
> >
> > OK, C++ doesn't support blocks/closures, but with templates and function
> > objects etc. you can get fairly close. (Using libraries like function,
>  bind
> > and lamda from boost it's even quite easy and straightforward to write.)
> 
> Blocks and closures are built into Ruby, while functors and such are an
> add on of the std lib. 

Yes, but C++ was specifically designed - and continues to evolve - 
this way: Never add good stuff if it can be done with the standard 
library just as well. (Of course, defining the border is alway
debatable, but the principle stands.)

> And they are not as convenient and easy to use as
> Ruby blocks.  My 0.02EUR.

Well, I suppose that >>anything<< can be said to be "not as convenient
and easy to use" in C++ compared to Ruby. But the original question 
was about "coming close".

<SNIP>

> > When I first learned about Ruby, I instantly liked it, thinking:
> > Hey, that's great, all the cool techniques I have been using in C++,
> > especially when programming with STL and stuff (boost, Loki, whatever
>  ...,
> > and that I really like to use with C++, will be available in Ruby, too.
> 
> Ruby forces (or convinces) you much more to use these technics while C++
> can be used in much more different ways and styles.  

From what I've seen of - and programmed in - Ruby so far, you can 
often use a lot of different techniques in Ruby to achieve the 
same goal.

That you can write code in C++ using FORTRAN style, C style or 
Java style, often, but not neccessarily, with very bad results, 
is true. But you can do the same in Ruby, or any other language,
as well. (Maybe the difference is that some C++ sub-communities 
are dedicated to doing so. But won't you find "typical
(Perl|Phyton|Java|whatever) converts" in Ruby as well?)

> The fact, that you
> can apply some of the technics Ruby uses in C or Assembler does not make
> these languages similar to Ruby IMHO.

In theory, you can simulate any technique in any language. The 
difference between C++ and, say, C in this regard is that C++ 
allows library writers to support addition programming 
techniques >> in an abstract way <<.

E.g., a C library can never make sure that every object is 
initialized correctly, but has to rely on the user calling 
an init function. A C library can support sophisticated 
user-defined callbacks, but can not ensure type safety
and allow flexibillity at the same time.

But, hey, this is getting theoretical, language 
categorizing, again.

I'm just a programmer, so I care more about how a language
feels when I work with it. And to me, C++ and Ruby are so 
totally different, but also so much the same, that's a 
pleasure to use Ruby when opportunity arises.
(I just wish that someone with more relevant
experience would write a Boost.Ruby lib soon.)
 
> Regards
> 
>     robert

Regards,

Uwe