25 ms·

I always get tempted to switch to Ruby * whenever i remember that Matz intended to make programmers happy. However, I don't think i'd feel comfortable with a la

I always get tempted to switch to Ruby * whenever i remember that Matz intended to make programmers happy. However, I don't think i'd feel comfortable with a language that only allows object-oriented programming, and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) Additionally, the MRI is perhaps the slowest implementation of a dynamic language out there (besides "R"). I know there are alternative implementations; is there any implementation that is significantly faster (at least as fast as Google V8 for ECMAScript) and that supports the full Ruby language without compatibility issues? * in place of Python

smitherfield 9y ago
> However, I don't think i'd feel comfortable with a language that only allows object-oriented programming Ruby is multi-paradigm; in particular it's easily the most "functional"-feeling of the major scripting languages. > and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) I'm unsure what you mean by this. Ruby has one of the most flexible OOP systems in existence, a good deal more flexible than Python's, and lets you create more or less any conceivable relationship between methods and objects. (Which is why Ruby is slow). > Additionally, the MRI is perhaps the slowest implementation of a dynamic language out there (besides "R"). I know there are alternative implementations; is there any implementation that is significantly faster (at least as fast as Google V8 for ECMAScript) and that supports the full Ruby language without compatibility issues? Ruby's not fast, but it's improved quite a bit from the 1.8 days. It's comparable to Python. As for high-performance alternative implementations, there's TruffleRuby,[1] but it still has compatibility issues and isn't ready for production use. There's also Crystal,[2] which is a very similar (but incompatible) compiled language with performance on par with Go/Java/Swift. It's also still in beta but they plan to have a 1.0 release by the end of the year. [1] https://github.com/graalvm/truffleruby https://github.com/graalvm/truffleruby [2] https://crystal-lang.org https://crystal-lang.org
- flavio81 9y ago
  First of all, thank you very much for your informative reply on the implementations. >I'm unsure what you mean by this. I believe that any OOP system that wants to be flexible, modern, and powerful, should have most of the features that CLOS (Common Lisp Object System) has. Julia (language) did, for example. It would be lengthy to explain all the features and benefits of CLOS here, but in CLOS, methods are not tied to objects, and all methods do multiple-dispatch. This also allows doing OOP in a functional-like way (this is easier to understand once you see how CLOS works.) In comparison, most other OOP systems feel limited and restrictive, and very different from CLOS. >a good deal more flexible than Python's Probably, but OTOH Python's OOP system is perhaps one of the weakest OOP systems out there, and speaking from my 2 years of professional experience with Python. I find it acceptable, but not good.
  - jasonwatkinspdx 9y ago
    There are plenty of lispers in the ruby world. "Ruby is an acceptable lisp" is a decently common saying. While Ruby's OO is not a verbatim copy of CLOS, it is much more versatile than you've described above. The best way to think of it is it's delegation under the hood using a little syntax sugar to resemble classes. It's not multiple dispatch, but methods can be aggregated into modules that can be mixed into classes or objects arbitrarily. Dispatch is dynamic and structural (duck typing). All of this combined with ruby's meta programming features make for an expressive system. It's not restrictive, in fact it runs the risk of the opposite problem, which is people over use the flexibility and write overly magic code that proves difficult to maintain down the road.
    - flavio81 9y ago
      >"Ruby is an acceptable lisp" is a decently common saying. I got excited the first time I read that phrase (i think it was Matz who said it?), but they are very very different languages; for example metaprogramming is a piece of cake in Lisp, while it is something reserved for advanced Ruby users, to put just one example. And for me, metaprogramming is extremely important. In any case, I think i'll give Ruby a second look.
lloeki 9y ago
> significantly faster (at least as fast as Google V8 for ECMAScript) Not by a long shot. > and that supports the full Ruby language And that's not even counting that. Your best bet for speed with some remotely Ruby flavored language would be Crystal. Your best bet for parallelism (using JVM threads) with full Ruby support would be JRuby. Topaz is dead. There's the experimental TruffleRuby but I'd rather not bet on this yet.
- cutler 9y ago
  You left out Substrate VM.
bhaak 9y ago
> a method must be tied to only one object What do you mean by that? You can do this: class A; def m; 'A'; end; end class B; def m; 'B'; end; end [A.new, B.new].map(&:m) => ["A", "B"] Or you can use mixins if you want to share the behavior of code across classes without using inheritance. I like Ruby especially because "everything is an object". That's a simple concept that you can understand easily. Every time I use Python I stumble over how it does things differently. I can't wrap my head around the Python way. Note, I don't like the metaprogramming approach that Rails popularized. Metaprogramming in small doses is okay but when everything you touch has some kind of indiscernible magic around it, it's just too much.
- flavio81 9y ago
  >What do you mean by that? "m" is a method in class A, "m" is a (different) method in class B. Each method is tied to only one class. While in CLOS i can do the following: let's say i have class Vehicle -> subclasses Spaceship and Car then i have class Person i can define, for example, the method "drive" two times: drive (Spaceship, Person) drive (Car, Person) Method "drive" is not tied to Spaceship nor Car. The class definition for Spaceship or Car does not include the definition of "drive". "Drive" is a method that is applied over the combination of two objects. "Drive" is not specific to a class, but to a combination of two (or more) classes. To put it in another way, drive (Spaceship, Person) is not¨ "a method of the Spaceship class that takes a Person as an argument". It is: A method that works for the combination of Spaceship AND Person. Thus if i call the method "drive" and pass it two objects (a,b) , the language will check if there is an implementation of "drive" for the specific combination of class-of "a" and class-of "b" and apply the correct method. CLOS also allows, for example, doing other interesting stuff, like, for example, if we have method "xxx" and when we call method "xxx" with some objects as arguments, there is more than one method that could apply, i can also configure things such as: a) all methods are called and the results of all methods are collected in a list b) the maximum of all results is used c) the minimum etc etc (you can define your own behavior) This is called "method combinations". There are much more features as well. For example, on your code you can specify the code that should execute whenever any vehicle is driven by a person; also, in separate, the code that should execute when a person drives a Spaceship, and also some piece of code that should be executed after any kind of vehicle is driven. These three methods aren't tied to a particular class definition, and will be called accordingly with just one line of code that calls the method "drive". The point to all these features is that they allow mapping your problem domain to OOP in an easier way, because the language's limitations do not get in your way. You directly tell the OOP system what do you want it to do; there's less need to do workarounds. My explanation, of course, is weak compared to the excellent explanation/tutorial here: http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html http://www.gigamonkeys.com/book/object-reorientation-generic...
cutler 9y ago
Ruby string processing is faster than Python due to Ruby's built-in regular expressions. Numeric computation is generally faster in Python though Ruby does have some shortcuts which make it faster for certain types of calculation. I think these are due to memoisation.
hota_mazi 9y ago
> I always get tempted to switch to Ruby * whenever i remember that Matz intended to make programmers happy. However, I don't think i'd feel comfortable with a language that only allows object-oriented programming, and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) That's a pretty strange stance. OOP is around and alive, and with the prudent addition of functional constructs, you get the best of both worlds. To me, the deal breaker about a language is static typing: if the language is dynamically typed (like Ruby, Python and Smalltalk), it's a non starter.

smitherfield 9y ago

> However, I don't think i'd feel comfortable with a language that only allows object-oriented programming Ruby is multi-paradigm; in particular it's easily the most "functional"-feeling of the major scripting languages. > and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) I'm unsure what you mean by this. Ruby has one of the most flexible OOP systems in existence, a good deal more flexible than Python's, and lets you create more or less any conceivable relationship between methods and objects. (Which is why Ruby is slow). > Additionally, the MRI is perhaps the slowest implementation of a dynamic language out there (besides "R"). I know there are alternative implementations; is there any implementation that is significantly faster (at least as fast as Google V8 for ECMAScript) and that supports the full Ruby language without compatibility issues? Ruby's not fast, but it's improved quite a bit from the 1.8 days. It's comparable to Python. As for high-performance alternative implementations, there's TruffleRuby,[1] but it still has compatibility issues and isn't ready for production use. There's also Crystal,[2] which is a very similar (but incompatible) compiled language with performance on par with Go/Java/Swift. It's also still in beta but they plan to have a 1.0 release by the end of the year. [1] https://github.com/graalvm/truffleruby https://github.com/graalvm/truffleruby [2] https://crystal-lang.org https://crystal-lang.org

flavio81 9y ago
First of all, thank you very much for your informative reply on the implementations. >I'm unsure what you mean by this. I believe that any OOP system that wants to be flexible, modern, and powerful, should have most of the features that CLOS (Common Lisp Object System) has. Julia (language) did, for example. It would be lengthy to explain all the features and benefits of CLOS here, but in CLOS, methods are not tied to objects, and all methods do multiple-dispatch. This also allows doing OOP in a functional-like way (this is easier to understand once you see how CLOS works.) In comparison, most other OOP systems feel limited and restrictive, and very different from CLOS. >a good deal more flexible than Python's Probably, but OTOH Python's OOP system is perhaps one of the weakest OOP systems out there, and speaking from my 2 years of professional experience with Python. I find it acceptable, but not good.
- jasonwatkinspdx 9y ago
  There are plenty of lispers in the ruby world. "Ruby is an acceptable lisp" is a decently common saying. While Ruby's OO is not a verbatim copy of CLOS, it is much more versatile than you've described above. The best way to think of it is it's delegation under the hood using a little syntax sugar to resemble classes. It's not multiple dispatch, but methods can be aggregated into modules that can be mixed into classes or objects arbitrarily. Dispatch is dynamic and structural (duck typing). All of this combined with ruby's meta programming features make for an expressive system. It's not restrictive, in fact it runs the risk of the opposite problem, which is people over use the flexibility and write overly magic code that proves difficult to maintain down the road.
  - flavio81 9y ago
    >"Ruby is an acceptable lisp" is a decently common saying. I got excited the first time I read that phrase (i think it was Matz who said it?), but they are very very different languages; for example metaprogramming is a piece of cake in Lisp, while it is something reserved for advanced Ruby users, to put just one example. And for me, metaprogramming is extremely important. In any case, I think i'll give Ruby a second look.

lloeki 9y ago

> significantly faster (at least as fast as Google V8 for ECMAScript) Not by a long shot. > and that supports the full Ruby language And that's not even counting that. Your best bet for speed with some remotely Ruby flavored language would be Crystal. Your best bet for parallelism (using JVM threads) with full Ruby support would be JRuby. Topaz is dead. There's the experimental TruffleRuby but I'd rather not bet on this yet.

cutler 9y ago
You left out Substrate VM.

bhaak 9y ago

> a method must be tied to only one object What do you mean by that? You can do this: class A; def m; 'A'; end; end class B; def m; 'B'; end; end [A.new, B.new].map(&:m) => ["A", "B"] Or you can use mixins if you want to share the behavior of code across classes without using inheritance. I like Ruby especially because "everything is an object". That's a simple concept that you can understand easily. Every time I use Python I stumble over how it does things differently. I can't wrap my head around the Python way. Note, I don't like the metaprogramming approach that Rails popularized. Metaprogramming in small doses is okay but when everything you touch has some kind of indiscernible magic around it, it's just too much.

flavio81 9y ago
>What do you mean by that? "m" is a method in class A, "m" is a (different) method in class B. Each method is tied to only one class. While in CLOS i can do the following: let's say i have class Vehicle -> subclasses Spaceship and Car then i have class Person i can define, for example, the method "drive" two times: drive (Spaceship, Person) drive (Car, Person) Method "drive" is not tied to Spaceship nor Car. The class definition for Spaceship or Car does not include the definition of "drive". "Drive" is a method that is applied over the combination of two objects. "Drive" is not specific to a class, but to a combination of two (or more) classes. To put it in another way, drive (Spaceship, Person) is not¨ "a method of the Spaceship class that takes a Person as an argument". It is: A method that works for the combination of Spaceship AND Person. Thus if i call the method "drive" and pass it two objects (a,b) , the language will check if there is an implementation of "drive" for the specific combination of class-of "a" and class-of "b" and apply the correct method. CLOS also allows, for example, doing other interesting stuff, like, for example, if we have method "xxx" and when we call method "xxx" with some objects as arguments, there is more than one method that could apply, i can also configure things such as: a) all methods are called and the results of all methods are collected in a list b) the maximum of all results is used c) the minimum etc etc (you can define your own behavior) This is called "method combinations". There are much more features as well. For example, on your code you can specify the code that should execute whenever any vehicle is driven by a person; also, in separate, the code that should execute when a person drives a Spaceship, and also some piece of code that should be executed after any kind of vehicle is driven. These three methods aren't tied to a particular class definition, and will be called accordingly with just one line of code that calls the method "drive". The point to all these features is that they allow mapping your problem domain to OOP in an easier way, because the language's limitations do not get in your way. You directly tell the OOP system what do you want it to do; there's less need to do workarounds. My explanation, of course, is weak compared to the excellent explanation/tutorial here: http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html http://www.gigamonkeys.com/book/object-reorientation-generic...

cutler 9y ago

Ruby string processing is faster than Python due to Ruby's built-in regular expressions. Numeric computation is generally faster in Python though Ruby does have some shortcuts which make it faster for certain types of calculation. I think these are due to memoisation.

hota_mazi 9y ago

> I always get tempted to switch to Ruby * whenever i remember that Matz intended to make programmers happy. However, I don't think i'd feel comfortable with a language that only allows object-oriented programming, and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) That's a pretty strange stance. OOP is around and alive, and with the prudent addition of functional constructs, you get the best of both worlds. To me, the deal breaker about a language is static typing: if the language is dynamically typed (like Ruby, Python and Smalltalk), it's a non starter.