Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

softwaredoug.com

Post reply on HN
Print view View original

71–80 of 193 posts

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

#71

Post by kibwen »

nomilk wrote: 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…

> it's criminal that you can write 1/2 and get values nowhere near one-half

This is a foolish argument and Guy Steele should know better. What makes 1/2, which has an accurate floating point representation, any more important than 1/10, which doesn't? Every novice programmer, every single one, trips over floating point, and pretending that floating point numbers match our intuition from mathematics doesn't do anyone any favors.

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

#72

Post by guenthert »

bhaak wrote: post #62
nomilk wrote: 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…

Does any of the programming languages Guy Steele worked with do the former and not the latter? Java certainly doesn't: https://godbolt.org/z/b847KeaGv There's a good reason for this. Computer numbers are not the same as numbers in mathematics. Floating point numbers are not real numbers and ints are not natural numbers.

Scheme, Common Lisp.

Neither Java nor CL were intended for the novice; I'm sure Mr. Steele had Scheme in mind.

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

#73

Post by nirse »

dang wrote: post #13

Discussed at the time: Ruby vs. Python comes down to the for loop - https://news.ycombinator.com/item?id=29199810 - Nov 2021 (302 comments)

Funny, I started typing a comment here, about the author not getting the Ruby side of things right, that actually the difference would rather be that Ruby uses a special language construct and Python just normal methods and conventions. But just skimming through the previous comments it seems that Python also has these a `yield` keyword that would be more idiomatic to use.

I think we're dealing with someone who had limited experience with both Python and Ruby. This article is somehow getting more attention then it merits.

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

#74

Post by mihaaly »

bhaak wrote: post #62
nomilk wrote: 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…

Does any of the programming languages Guy Steele worked with do the former and not the latter? Java certainly doesn't: https://godbolt.org/z/b847KeaGv There's a good reason for this. Computer numbers are not the same as numbers in mathematics. Floating point numbers are not real numbers and ints are not natural numbers.

It was not debated that there is no reason some languages behave one way or the other - it is quite the opposite - only that for supporting the pratical use cases - which is the sole purpose of any language, to be useful for practical cases - then it is not a good reason.

When one has to jump hoops of the language - being the user for the whims of the language and not the language for the user - that is wasting efforts and adding complications instead of helping. Being more like puzzle for fun that practical application.

Those want to keep close to the soul of the hardware and computing should use C or other low level languages, existing for long. Not made recently to make programming easier ... on paper only apparently...

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

#75

Post by pjmlp »

resource_waste wrote: post #53
pjmlp wrote: post #50

Earlier quoted context omitted.

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?

Written in 2024, with 38 years of experience reaching out to dynamic languages, some of which without any kind of JIT/AOT in the reference implementation, which Python happens to be one of them.

Eventually if the JIT POC from 3.13 evolves to something that can compete with a Common Lisp, or Smalltalk JIT, then I can change of opinion.

Note that I only mention those two languages on purpose.

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

#76

Post by [deleted] »

kibwen wrote: post #71
nomilk wrote: 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…

> it's criminal that you can write 1/2 and get values nowhere near one-half This is a foolish argument and Guy Steele should know better. What makes 1/2, which has an accurate floating point representation, any more important than 1/10, which doesn't? Every novice programmer, every single one, trips over floating point, and pretending that floating point numbers match our intuition from mathematics doesn't do anyone…

[deleted]

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

#77

Post by jon-wood »

vidarh wrote: post #65
resource_waste wrote: post #51

Earlier quoted context omitted.

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.

I made the opposite choice 20 years ago, and could say the same about my choice. But I wouldn't because realistically language choice is largely about what makes you happy. A good dev needs to be a polyglot anyway.

And I chose Ruby about the same amount of time ago, spent 18 years or so writing that professionally, and now write Python for a living. They’re not that dissimilar, if you can use Ruby you’ll pick up Python pretty quickly. (You will however swear profusely now and again as you encounter another incredibly clunky bit of syntax)

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

#78

Post by tinco »

kibwen wrote: post #71
nomilk wrote: 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…

> it's criminal that you can write 1/2 and get values nowhere near one-half This is a foolish argument and Guy Steele should know better. What makes 1/2, which has an accurate floating point representation, any more important than 1/10, which doesn't? Every novice programmer, every single one, trips over floating point, and pretending that floating point numbers match our intuition from mathematics doesn't do anyone…

I don't think his attention was specifically to have 1/2 be a floating point number, like for example Javascript does, but to call to attention the fact that we design programming languages for a specific audience, not realising that if we widened our perspective it could be intuitive for a much wider audience.

For example, Ruby was designed for experienced software developers. Experienced software developers expect that if you divide an integer by another integer, that it performs integer division, and 1/0 would be 0 in integer maths.

If the creator of Ruby had broadened their horizon, and instead realised that outside the world of experienced software developers, the expression "1/2" means something totally different, maybe they could have chosen a different behaviour.

In a different universe perhaps any numeric literal in Ruby would always be a `Number` (like in Javascript), that for division would instead return a `Rational`. So that the end user could at the end simply call `.to_i` or `.to_f` or `.to_s` according to their needs.

I don't know if that would be a better universe though. I agree with your point that every programmer eventually needs to learn about floating point numbers and their sometimes surprising properties. And in the end Ruby was designed for programming computers, and the goal of any programming language is to expose the abilities of a computer, which include at the core integer maths, however surprising that maths might be to a novice.

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

#79

Post by crabbone »

foobarbaz321 wrote: post #7

This is because Ruby inherits it's approach to flow control from Smalltalk, while Python comes from a C/Algol-like heritage. In fact, Smalltalk takes this much further, such that basically all flow control (including if-then-else) is handled as message sends (e.g. if-then is just a message sent to the Boolean object taking a block as it's argument). The downside is the syntax can feel a tad clunky. The upside is incr…

> The upside is incredibly simple and consistent language grammar

I hope you don't mean Ruby (I haven't investigated Smalltalk grammar). Ruby grammar is atrocious due to string interpolation stuff. Nothing to do with handling loops or conditionals, but still... Ruby is not at all an example of a language with good grammar.

Unfortunately, it's surprisingly rare for popular languages to have good grammar. If you look at it from up close, there are lots and lots of really bad decisions in virtually any language in common use today. I think, this is just not a high-priority concern for most users, but still...

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

#80

Post by MrJohz »

kibwen wrote: post #71
nomilk wrote: 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…

> it's criminal that you can write 1/2 and get values nowhere near one-half This is a foolish argument and Guy Steele should know better. What makes 1/2, which has an accurate floating point representation, any more important than 1/10, which doesn't? Every novice programmer, every single one, trips over floating point, and pretending that floating point numbers match our intuition from mathematics doesn't do anyone…

That's an argument for being more careful with floating point operations, and perhaps not using them as a default numeric value, but it's not what Steele is talking about there. After all `1/10` in Python is still pretty close to one tenth, even if it's not quite there.

The question here is whether or not we should assume integer semantics for numerical values.

Post reply on HN