Re: Which compiled language is closest to Ruby?

"Uwe Schnitker" <[e-mail]> schrieb im
Newsbeitrag news:[e-mail]...
> "Robert Klemme" <[e-mail]> wrote in message
news:<[e-mail]>...
> > "Uwe Schnitker" <[e-mail]> schrieb im
> > Newsbeitrag news:[e-mail]...
> > > Gully Foyle <[e-mail]> wrote in message
> >  news:<hXHKc.38807$[e-mail]>...
> > > > 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.

That's what I figured when reading on. :-)

> > > > 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.

Well, that's precisely the reason why I call C++ less OO: in C++ object
orientation is just a part of the language, while it's all over Ruby.  In
Ruby everything is an object and thus can be treated as such.  In C++ it's
not.

> 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?

That depends to a certain degree *how* it is done.

> 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?

I'd call it less OO because C++ has POD, templates etc.

> > C++ has POD's,
> > functions, static etc.
>
> Yes, and Ruby has all this Perl stuff: Globally accessible
> handles, non-oo regexp syntax, ... So what?

Even those global vars in Ruby reference objects.  I'm not sure why you
cite non-oo syntax for regular expressions here; regular expressions are
just another built in type with a speical syntax to create them - same
holds for integers and Strings.  Fact is, that each Regexp is an object
and can be treated that way.

> > 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.

Well you can, but that does not have any implications on the OO-ness. :-)

> > > (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.

I was referring to

"... but my point is that, unlike with (earlier versions of) Java, C#,
etc., you
can write (and call) free functions, ..."

I don't know whether there was ever a Java version that didn't have
'static', but if there was, this must've been quite an old version.  So
maybe your wording was just a bit confusiong (at least for me).

> > > 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.

I wanted to make a distinction between generic code (i.e. code that
applies to all sorts of types) and "generic programmin".  The latter is
realized by C++ templates and there is no such thing in Ruby as it is not
statically typed.  Maybe a bit picky, but it's really a difference.  For
example, you can specialize generic code for certain types in C++ (and
even the STL does this in several places) but you can't in Ruby.

> > (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.

Exactly.

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

True.

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

That was my point.  Not a contradiction really, but I attempted a
clarification.

> 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.

It's really a stretch and I wouldn't go so far.

> > > 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.

That's what I understood.  Still those concepts are quite abstract:

> 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

Hm, to me OO rather means: program elements are objects which encapsulate
data and functionality.  Inheritance is important also.  Common behavior
has more to do with polymorphism.

> 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.]

Naah, I prefer Veltins over Bit(burger).  ;-)

> > > > 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.

Definitely!

> But the original question
> was about "coming close".

The lack of convenience is one of the aspects that make me say C++ is not
near Ruby at all.

> <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.

Yes, of course.  But you always do it with objects.  You can choose ways
without objects in C++.  That's what I meant to say.

> > 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,

Ha!  Finally you admit it! :-))

> but also so much the same, that's a
> pleasure to use Ruby when opportunity arises.

Definitely!

> (I just wish that someone with more relevant
> experience would write a Boost.Ruby lib soon.)

What's in boost that we don't have in Ruby at the moment?  I don't know
boost good enough, maybe you can shed some light on this.

Thanks for the interesting exchange!

Kind regards

    robert