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

111–120 of 193 posts

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

#111

Post by alexcosan »

dosinga wrote: post #102

FWIW the Python implementation of Stuff seems not all that Pythonic. Returning self from __iter__ and keeping state where the iteration is works, but breaks if you over the same object from an iter. To me that really distracts from the argument since the idiomatic implementation in Python and Ruby look almost exactly the same

On the same note, the implementation of Stuff in Ruby is not very ruby-like. It could have just used `.each` on the `@a_list` (in that case, you just delegate the implementation to `@a_list`, no reason to use a for-loop.

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

#112

Post by kayodelycaon »

sho wrote: post #14
SkyPuncher wrote: post #9

Earlier quoted context omitted.

I’ve tried so many stacks on side projects and always come back to RoR (with a bit of a grudge). I dislike many things about Ruby, but RoR is extremely hard to beat. Basically, everything you need in a stack is provided or readily available in the community.

Yeah. My usual advice to anyone who asks is "Use Rails unless you have a very good reason not to". Those reasons do exist, but they're pretty specific and don't apply 90% of the time. Of course if we're being really real, the first piece of advice should actually be "Can this be Wordpress?"

> Can this be Wordpress?

Yup. I’m a huge fan of rails, but I’m an even larger fan of not writing code in the first place.

If a spreadsheet can solve your problem, I’m going to suggest a spreadsheet.

If a vendor can solve your problem well enough, I’ll suggest a vendor.

My time, energy, and attention is valuable. I’m here for the problems you can’t or shouldn’t outsource.

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

#113

Post by lelanthran »

bhaak wrote: post #47
anal_reactor wrote: post #22

Earlier quoted context omitted.

[flagged]

You don't seem to have any knowledge about the history of programming languages. There have been several lines of PL syntaxes since the 50s. You are crazy if you think that a C style for loop is good designed. It's way to powerful but terse and obtuse to do correctly beyond the simplest application. C style syntax as a whole is also nothing special if you mean semicolons and braces. If you include stupid design decis…

> You are crazy if you think that a C style for loop is good designed. It's way to powerful but terse and obtuse to do correctly beyond the simplest application.

I wouldn't go as far as calling someone crazy for thinking C-style for loops are good.

The expressions in a C-style for loop is a 1:1 mapping to sigma notation, so is intuitively understood by anyone who has done high school mathematics, even if they didn't realise there's a 1:1 mapping.

Maybe you'd like something different, but it's been a staple of mathematicians for centuries now, so it's kinda hard to complain that it isn't readable.

Easy to make mistakes? Sure!

Hard to read and/or write? Only if you have never seen sigma notation before.

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

#114

Post by regularfry »

harrisi wrote: post #60
MrJohz wrote: post #43

Earlier quoted context omitted.

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.

Strictly speaking the exclamation mark convention is for things that are "dangerous", in some sense. Modifying in-place is one sort of dangerous, but there are others, Process.exit! being one notable instance where the "modifying in place" thing is a bit of a stretch, and not really the thing you care about.

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

#115

Post by lelanthran »

self wrote: post #37
submeta wrote: 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…

it's a meme (image), so i can't copy it here: https://twitter.com/stylewarning/status/1772795474589987226

Old joke from usenet:

> I have reverse engineered secret security algorithms used by the CIA and can break any message they encrypt. As proof, here is the last few lines of an implementation of their encryption function in Lisp

                ))
            )))
        )))
    ))))

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

#116

Post by adolph »

devjab wrote: post #40
anal_reactor wrote: post #22

Earlier quoted context omitted.

[flagged]

I think you’re mistaking C-style syntax for what modern C languages have adopted and become. How many C style context even really exist today? The block separation by single characters is ok. Using (), [] and {} to separate things makes things easier on the compiler, but it’s probably down to personal preference whether you like that syntax or not. I certainly vastly prefer the more simplistic approach where you don’…

> I guess {} is better than BEGIN END, but maybe not in terms of readability.

AFAIK, {} lacks initialization and finalization blocks, like a sql statement without transaction wrapper. Example is awk:

https://www.gnu.org/software/gawk/manual/html_node/Using-BEG...

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

#117

Post by regularfry »

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

I have, in the past, thought that it might be a good idea to allow `en+d` as a delimiter.

So you'd have

    module A
      module B
        class C
    ennnd
Fortunately, I am no longer suffering from whatever fever-induced hallucination brought on that particular deviation from good taste and decency.

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

#118

Post by stouset »

norman784 wrote: post #45
stouset wrote: 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.

Performance is worth infinitely less than the sheer developer productivity of Ruby, at least when used by experienced engineers capable of restraint.

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

#119

Post by regularfry »

wlll wrote: post #101
bhaak wrote: post #56

Earlier quoted context omitted.

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.

As someone who has worked in Rails performance for quite a long time now I suggest that Rails performance is largely fine. Most Rails performance problems are database and/or architecture issues and not with the language or framework.

And also YJIT has landed, which should help.

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

#120

Post by tinco »

nordsieck wrote: post #105
tinco wrote: post #78

Earlier quoted context omitted.

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…

> 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. IMO, that would be a tragedy. In every language that does it implicit type coercion is the cause of a litany of bugs. It's the cause of many problems in php. It's why people are…

I agree, but I didn't suggest implicit type coercion. The bugs in Javascript are because of type coercion, but that has nothing to do with the fact that numbers in typescript are all floats. I don't think there are many bugs in Javascript that are due to numbers being floats, though I bet there's some companies who decided to build their backend in Javascript that might eventually run into problems.

There's ways to design a number class that doesn't suffer from any of these problems (obviously it would have to sacrifice performance to some degree).

Post reply on HN