Live data from Hacker News

Ruby vs. Python comes down to the for loop (2021)

softwaredoug.com

51–60 of 193 posts

Re: Ruby vs. Python comes down to the for loop (2021)

#51
post #19

Ruby always seems so appealing. Can anybody tell me how the Ruby ecosystem looks like w.r.t. - (Desktop) GUI - Natural language processing I would really like to learn Ruby, but I can only justify the effort if I can use its ecosystems for some private projects, and I often have been burned by languages not offering too much in those two areas. And speed-wise, as I understand, Ruby is the same ball-park as Python?

15 years ago I made the choice between Python and Ruby.

Without a doubt, choosing python was the correct move.

I can't imagine with the current trajectory, Ruby will be better.

Re: Ruby vs. Python comes down to the for loop (2021)

#52
First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful.

Paraphrasing Guy Steele [1]:

> It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values nowhere near one-half.

Python

>>> 1/2

0.5

Ruby

irb(main):001> 1/2

0

To a novice programmer, ruby's result makes no sense, and introduces an incredible degree of doubt into the mind of the user. Sure, they could explore why it gives that result, but if that's not helping them get toward solving the problem they're using the programming language for in the first place, then it could seem like an indulgent tangent.

[1] https://www.youtube.com/watch?v=agw-wlHGi0E&t=19m27s

Re: Ruby vs. Python comes down to the for loop (2021)

#53
post #50
post #2

I've done a lot of SRE work and two stints at companies with RoR stacks. Really have kinda soured on Ruby and Python at this point and it has little to do with loops. If I had to choose though it would be Python for asyncio.

Python has two killer use cases, being a better Perl that one can read one month later, and a better BASIC for introduction to programming and IoT stuff. Trying to use it for application code, eventually ends up in pain, rewriting code into C and calling it "Python".

Was this written in 2008?

Re: Ruby vs. Python comes down to the for loop (2021)

#54
post #41

Earlier quoted context omitted.

[flagged]

Smalltalk and C both came out in 1972 and it really isn't clear to me that C's crazy for-loop design -- one that actually isn't used by many programming languages -- is somehow better than the one used by Algol, so I am struggling to find even a single thing you said which is making any sense to me :(.

I have programmed C since the 1980's, and I still avoid C for loops when writing C because they're hideous.

Re: Ruby vs. Python comes down to the for loop (2021)

#55
post #52

First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values…

Notable that this was python behaviour until Py3.

Re: Ruby vs. Python comes down to the for loop (2021)

#56
post #28

Earlier quoted context omitted.

There is an enormous Ruby ecosystem completely outside of Rails.

I would argue that the main selling point of using Ruby is Rails, for sure there are a lot of things you do in Ruby, but for sure in 2024 there are more performant alternatives.

One of the central arguments for Ruby is that performance is not everything (it was always slow compared to other programming languages) but programmer satisfaction is more important.

I'd say Ruby is the programming language I want to program in but Rails pays the bills.

Re: Ruby vs. Python comes down to the for loop (2021)

#57
post #52

First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values…

0 is also the behaviour of C and of pretty much any serious programming language.

Re: Ruby vs. Python comes down to the for loop (2021)

#58

> Ruby keeps going with its methods-first approach, except instead of each we have a new set of methods commonly implemented on collections, as below Once you implement `each`, `include Enumerable` is all it takes to get the full set of collection methods (including `max`/`min` etc, if the entries define ` `).

Indeed.

The entire article largely read like "Python developer learns Ruby", and on top of that now fairly dated Ruby, though I'll make some concessions for him wanting to show a close parallel to the Python. I wish he'd signposted more clearly that these are examples, though, because as it stands it implies this is how to do things, while it really is not.

E.g. his "Stuff" example can be reduced to:

    class Stuff
      def initialize
        @a_list = [1, 2, 3, 4]
      end
  
      # The ellipses here are part of the Ruby code for 'forward
      # all the arguments, including the a block if passed'
      def each(...) = @a_list.each(...)

      include Enumerable
    end

    Stuff.new.each {|item| puts item }
    puts Stuff.new.map {|item| item}
    puts Stuff.new.select{|item| item.even?}
One could argue about my use of "..." and endless def, but one certainly would not typically implement each when forwarding to an Array by using a for loop to iterate over it other than to make it relatable to Python developers...

And, more controversially perhaps, the last three lines can be reduced to:

    Stuff.new.each { puts _1 }
    puts Stuff.new.map.to_a
    puts Stuff.new.select(&:even?)
The first one is one that will cause arguments. The second just showcases that map is pointless here other than as an example - map here effectively just a slow way of duplicating the array, but notably first when forcible evaluated as map without a block will return an Enumerator, and "&:even?" is fairly idiomatic for "call to_proc on this symbol and apply it to the argument", but some might still not be familiar with it.

Re: Ruby vs. Python comes down to the for loop (2021)

#59
post #55
post #52

First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values…

Notable that this was python behaviour until Py3.

The shift towards // vs / also shows great acumen by the Python designers: they tried (and arguably, largely succeeded) in catering to the greater data science/statistics/numerical analysis communities, where 1/2=0.5 is obvious, rather than sticking to the "compsci-obvious" 1/2=0.

Re: Ruby vs. Python comes down to the for loop (2021)

#60
post #43
post #29

What I like in Ruby: Every expression returns a value. In Python my_list.sort() will return `none`. So if I do `sorted_list = my_list.sort()`, my `sorted_list` will be `none`. And I have been shooting a lot in my foot in the beginning. - I love Python now, but not because I find it aesthetically appealing (I prefer Lisps or functional languages) but because it is ubiquitously available, the ecosystem is phantastic, a…

The `sorted_list = my_list.sort()` is a bit of an odd case, though, because, as you've written it, `sorted_list` looks like a new list, even though `sort` does an in-place sort. (Javascript has exactly this problem, where `.sort` mutates the existing list, but can be chained in such a way that it looks like just another step, leading to surprises later on when the input data is suddenly different to how it used to be…

Ruby conventionally separates methods which modify the object from ones that don't by appending an exclamation mark to the method name. So `sort` returns a new sorted list, whereas `sort!` modifies the original list.
Post reply on HN