From: Robert Klemme Date: 2004-07-21T20:52:05+09:00 Subject: Re: Which compiled language is closest to Ruby? "Uwe Schnitker" schrieb im Newsbeitrag news:30381f67.0407210016.4d0e6a33@posting.google.com... > "Robert Klemme" wrote in message news:<2m4dhrFis860U1@uni-berlin.de>... > > "Uwe Schnitker" schrieb im > > Newsbeitrag news:30381f67.0407192151.25675ec2@posting.google.com... > > > Gully Foyle wrote in message > > news:... > > > > 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. > > > > > 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