Live data from Hacker News

Ruby is beautiful (but I'm moving to Python)

wit.io

61–68 of 68 posts

Re: Ruby is beautiful (but I'm moving to Python)

#61
post #19

I wrote this article almost a year ago as a tribute to my favorite language at the time. (That title now belongs to Clojure.) It feels like if you want to do scientific computing in Ruby, you're met with obstacles at every turn, but with Python, you're greeted with open arms and tested libraries. That could change (and I'm beginning work on a stats library for Ruby), but it will take time. This was partially a call t…

What is the state of Incantr (or something like that was the name)? A Scientific Computing framework for Clojure.

Re: Ruby is beautiful (but I'm moving to Python)

#62
post #61
post #19

I wrote this article almost a year ago as a tribute to my favorite language at the time. (That title now belongs to Clojure.) It feels like if you want to do scientific computing in Ruby, you're met with obstacles at every turn, but with Python, you're greeted with open arms and tested libraries. That could change (and I'm beginning work on a stats library for Ruby), but it will take time. This was partially a call t…

What is the state of Incantr (or something like that was the name)? A Scientific Computing framework for Clojure.

For Clojure, there's also Clojuratica: " rel="nofollow">http://clojuratica.weebly.com/>, which lets you trade data between Clojure and Mathematica seamlessly.

Re: Ruby is beautiful (but I'm moving to Python)

#63
post #13

Seems like it would be a huge opportunity for people to start creating these science Ruby gems. Not my field, personally...

It's been tried before. mum, Numerical Ruby and SciRuby were all attempts. The fundamental issue I believe they all had is lack of community. There is a quite large community of folks using Python for scientific computing. Many are not professional developers but rather scientists / engineers who aren't as open to jumping around to different languages as a developer would be. These issues combined with the fact that…

SciRuby "were?" We rebooted the project a few months ago. Making some progress. sciruby-dev at googlegroups dot com, and #sciruby on IRC.

Re: Ruby is beautiful (but I'm moving to Python)

#64

Earlier quoted context omitted.

I fail to see how i.even? is any more convenient than even? i except that even? has now somehow entered into the set of functions worthy to be part of the integer-fake-object while others have not.

It's more consistent (no wondering what's a method and what's not for most common situations) and it stops the global namespace getting littered up with functions that are only relevant to certain types. To a Rubyist, knowing that Ruby is an object oriented language, it is clear one is sending a message to i . With the latter example, it is not clear what even? belongs to and what it expects to receive.

Then namespace it. As I said, there's nothing stopping you from having namespaces and modules.

    import Arithmetic (even)

    even :: Integer -> Bool
    even i
Also, you can call function calls messages or object operations or dictionary lookups, but I don't see the benefit in 99% of cases. I guess the dynamism may be useful in GUI code where it's not that hard to see if you're wrong and if you are wrong, nobody's world really ends. In most other cases functions are best described as having a formal mathematical definition so you can reason about them with some accuracy.

Re: Ruby is beautiful (but I'm moving to Python)

#65

Earlier quoted context omitted.

I fail to see how i.even? is any more convenient than even? i except that even? has now somehow entered into the set of functions worthy to be part of the integer-fake-object while others have not.

Because the former reads more like english. I would ask "is 2 even?" but I would never ask "does the quality of evenness apply to 2?" One of the things I dislike about python is the word order you end up with. My eyes have to jump about to work out whats going on. Its like german ;)

Your order is like English, but your semantics are the exact opposite. My code asks "is 2 even?" -- it calls the even? function to check to see if it's a boolean. If you notice, the even? object function is referentially transparant and implicitly contains its own argument. It's not really a function. It's a field. What Ruby has done is define a field of every Integer instance which returns True or False based on a separate function call that determines whether or not the object is even. It's irrelevant how the function is implemented because those are the semantics -- you have defined a method that answers if the quality of evenness applies to 2. Your own example is exactly why I dislike the semantics of this object method.

Re: Ruby is beautiful (but I'm moving to Python)

#66
post #61
post #19

I wrote this article almost a year ago as a tribute to my favorite language at the time. (That title now belongs to Clojure.) It feels like if you want to do scientific computing in Ruby, you're met with obstacles at every turn, but with Python, you're greeted with open arms and tested libraries. That could change (and I'm beginning work on a stats library for Ruby), but it will take time. This was partially a call t…

What is the state of Incantr (or something like that was the name)? A Scientific Computing framework for Clojure.

Pardon, here's a link that works: http://clojuratica.weebly.com/

Re: Ruby is beautiful (but I'm moving to Python)

#67

Earlier quoted context omitted.

Your rant isn't an argument, it's an opinion. I can just as well say integers are objects like any other and even? makes perfect sense as a method on them because that's the entire point of objects in the first place, binding state and behavior together into a single smarter package because it's a convent method of organizing code.

I agree 100% that it is my opinion. I would wager that most rants are opinions. As far as this being the point of objects -- I see no state. I see no behavior. All I see is a function which maps the set of integers to booleans. That's it. It's just a function. The only reason we need packaging or modules at all is to prevent name collisions and importing the world.

The integer is state, deciding if it's odd or even is behavior. Yes, it's a query method, but it's a good one. The only reason we need objects is to make programming convenient. I don't want my namespace polluted by a free floating function named even?/odd? when it can be restricted to the only type it cares about by being bound to it.

In some strictly ease of use sense, object.function() is better than function(object) because it better helps me organize and scope my code; I don't have to worry about function name clashes because every instance is essentially a module for those functions.

My tools also work better when they can see I'm asking what methods are on integer rather than just show me all functions visible to me right now. It's easier to say hey Integer, what can you do rather than hey world, what works with integers.

If you can only see functions, integers, and booleans and you can't realize those are all themselves perfectly good objects, then that's a failure of your imagination. Me, I like my functions, methods, booleans, integers, and all other types being objects because it's damn useful and damn convenient in making my day to day life easier.

Re: Ruby is beautiful (but I'm moving to Python)

#68

Earlier quoted context omitted.

Because the former reads more like english. I would ask "is 2 even?" but I would never ask "does the quality of evenness apply to 2?" One of the things I dislike about python is the word order you end up with. My eyes have to jump about to work out whats going on. Its like german ;)

Your order is like English, but your semantics are the exact opposite. My code asks "is 2 even?" -- it calls the even? function to check to see if it's a boolean. If you notice, the even? object function is referentially transparant and implicitly contains its own argument. It's not really a function. It's a field. What Ruby has done is define a field of every Integer instance which returns True or False based on a s…

Yes, but I like it like that you see.
Post reply on HN