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]
Ruby vs. Python comes down to the for loop (2021)
41–50 of 193 posts
Re: Ruby vs. Python comes down to the for loop (2021)
#42This 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]
Re: Ruby vs. Python comes down to the for loop (2021)
#43What 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…
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)
#44This 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…
Re: Ruby vs. Python comes down to the for loop (2021)
#45Earlier 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.
Re: Ruby vs. Python comes down to the for loop (2021)
#46Earlier 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 :(.
Re: Ruby vs. Python comes down to the for loop (2021)
#47This 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 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)
#48Ruby 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?
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)
#49Hmm 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…
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)
#50I'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.
Trying to use it for application code, eventually ends up in pain, rewriting code into C and calling it "Python".