Live data from Hacker News

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

softwaredoug.com

41–50 of 193 posts

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

#41

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…

[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 :(.

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

#42

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…

[flagged]

Ah, a brilliant idea, design all languages so people who only know C can make small changes to existing Ruby code without getting confused. Definitely don't want to enable different abstractions or models of computation. Are these core principles in codebases you mentioned mostly "how to write stuff using C paradigms"? After all, "the Real Programmer can write FORTRAN in any language"

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

#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.)

In that regard, separating `sorted` (immutable, returns a new sorted list) and `sort` (mutates, returns nothing) helps a lot in terms of preventing subtle mistakes.

I don't know how Ruby handles this case though.

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

#44

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…

Just a sidenote that for performance reasons, control flow messages are actually optimized in most implementations, even though they also look like regular messages.

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

#45
post #28
post #21

Earlier quoted context omitted.

Ruby is only relevant because of Rails, and if those two things are your use-cases then you’ll be better off with Python

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.

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

#46
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 :(.

It really isn't, as I have lost count of how many get clever uses out of that loop.

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

#47

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…

[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 decisions like braceless blocks in "C style syntax" I wouldn't even know what to think of that opinion.

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

#48
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?

As usual language and implementations aren't the same thing.

While Ruby community has pursuded many implementations in regards to JIT, the reference implementation even has two currently, on the Python side outside PyPy, nothing else has actually got any community support.

Only now thanks to the pressure of Python being the "2nd coming of Lisp for AI", but without its native code generation, there is some real pressure that actually writing C,C++,Fortran and calling it "Python" isn't that practical and a JIT on CPython would be welcomed.

On the other hand, those native libraries can be equally called from Ruby.

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

#49

Hmm I'm no Python fan but I'd take it over Ruby any day, because it's so much easier to read a codebase. This is based on me trying to follow Gitlab's code. The problems with Ruby seem to be: * No static typing (I think there is Sorbet but apparently it's not very good and Gitlab doesn't use it). * The lack of "syntax" makes it hard to grep for things. For example you can't find where `foo` is called by searching for…

>* It seems to encourage highly dynamic code where even identifiers are dynamically created, so often you'll find an identifier, and try to search for its definition but get zero results.

I've had to take care of 3 large ruby codebases at different companies and this is what kills ruby for me.

A lot of ruby programmers think they are being clever when writing crazy dynamic ruby code, but they are only creating technical debt.

Years later when they have left and the "context knowledge " is gone from the team, the Ruby code is a huge mess of "magical" code.

And rails with its "implicit" functionality depending on method name. A lot of Ruby feels like "magical" to me (in that, things work because of some hidden implicit readmson).

I prefer code that is explicit, in your face. You can quickly see what it does and how it does it. Principle of least surprise and "don't make me think".

As a language it's pretty, I like to say that Ruby is really object oriented while python is a mix of stuff (why len(x) instead of x.len??)

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

#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".

Post reply on HN