Ruby vs. Python comes down to the for loop

https://softwaredoug.com/blog/2021/11/12/ruby-vs-python-for-loop.html

by softwaredoug • 5 years ago

373 302 5 years ago

behnamoh• 5 years ago

Kinda opinionated and biased against Python.

Author here. Interesting! I personally write almost Python exclusively and find Ruby to be awkward in many ways. I'm learning Ruby, so if that comes through, maybe cause I'm learning it and more excited about new concepts? :)

ewalk153• 5 years ago

I read it as the opposite of the GP.

You've highlighted the idiomatic differences in the language design and how each lends itself to a different style of thinking. Neat.

rpmisms• 5 years ago

Kinda like Ruby :P

stevev2• 5 years ago

In the end it is about preferences. It’s going to be biased given the subject at hand. I do prefer ruby. It’s more object oriented. The language really focuses on this. Example, the plus sign symbol (+) can have Methods or even be a class or be anything. That’s Ruby.

inanutshellus• 5 years ago

IMHO the author successfully remained neutral. Every point about the way one language works was neither criticism nor compliment, merely observation, and was immediately followed by the other language's differentiating take on a particular feature.

ARandomerDude• 5 years ago

So what? At a certain point in your career you should have opinions about how problems should be solved.

revskill• 5 years ago

def f():

    s = "Me too."

    print(s)

# Global scope

s = "I love Geeksforgeeks"

f()

print(s)

This one returns `I love Geeksforgeeks`

Holy mogy, God bless someone doing codereview or inherit python code from some bad developers.

tmerr• 5 years ago

It prints "Me Too." then "I love Geeksforgeeks". What is strange about this?

sgc4• 5 years ago

I would expect it to print "me too", because I would expect the assignment in the function to change the global variable when it is called, not create another variable.

Kichererbsen• 5 years ago

this is totally expected behavior... "Me too." is local to f... what did you expect?

DangitBobby• 5 years ago

This prints:

    Me too
    I love Geeksforgeeks

The s introduced in f is local to the function unless you use the nonlocal or global keyword with it. To do otherwise seems like a really bad idea to me...

kevinmgranger4• 5 years ago

You can explicitly reference a global variable if you want this behavior:

    def f_global():
        global s
        s = "Me too."
        print(s)

    print(s)
    f_global()
    print(s)

Will print:

    I love Geeksforgeeks
    Me too.
    Me too.

Of course... please don't do global mutable variables.

trufas• 5 years ago

The tradeoff here is that you don't have to explicitly declare new variables (something like `var` in js). Most people who work with python on a daily basis know you need the `global` keyword to avoid shadowing.

I think it was a good choice in the sense that it discourages mutable global state and makes the most common case more concise.

friedman234• 5 years ago

this works exactly how I would expect it to?

gilbetron2• 5 years ago

Seems odd to not talk about Python generators in an article about this topic.

softwaredoug11• 5 years ago

Author here - True! though generators are a specialization of iterators discussed in this article. I had considered it, but didn't want to get too bogged down.

isaacimagine• 5 years ago

At a deeper level, this comes down to internal vs. external iteration, and, more generally, how languages weave together concurrent threads of execution:

https://journal.stuffwithstuff.com/2013/01/13/iteration-insi...

DFHippie• 5 years ago

The discussion of Ruby could use a mention of Enumerable.

https://ruby-doc.org/core-3.0.2/Enumerable.html

softwaredoug11• 5 years ago

Author here, wow that's great! I am still learning Ruby (hence the article to try to grok things).

pelasaco2• 5 years ago

as suggestion, regarding the following code:

Stuff.new().each do |item|

  puts item

end

In idiomatic ruby, we drop this parenthesis, so the code will look like Stuff.new.each ...

usefulcat• 5 years ago

If one is having to implement an each or map or select method in ruby, then I can definitely appreciate the differences you point out. Even though I've been using ruby a long time, it would frankly still be a bit of a pain to have to remember the details of how yield works.

Because Enumerable provides so much functionality, I almost never need to implement methods like those. So what I really care about a lot more are the ergonomics of using each, map, select, reject, all?, any?, etc, which I use very frequently.

busterarm2• 5 years ago

Indeed.

The real magic is when you start doing things like:

some_enum.collect(&:+)

This simple line will do everything from sum numbers to concatenate strings, etc.

mikepurvis• 5 years ago

Not a rubyist, but I love that collect() made it into Rust, too. I feel like it takes the role that generators have in Python, but is much easier to reason about in terms of the control flow and what data is being passed where.

rubyist5eva2• 5 years ago

While this is cool, you can also just do `some_enum.sum` (also works with string concacts)

One thing that is cool about the .to_proc shorthand though is, for example, you have a method

def square_it(x); x * 2; end;

people tend to write an enumeration that uses it like

items.map {|i| square_it i }

but you can actually write it like this

items.map(&method(:square_it))

So not only can you write shorthands to methods on the object itself, you can write shorthands to other methods and "automagically" pass the item as its argument. Nifty stuff.

ericwood• 5 years ago

Enumerable is one of my favorite aspects of the Ruby standard library! I've been writing it off and on for quite some time and still discover incredibly useful and elegant functions in there. It's incredibly rare to not find what I need when working with collections.

benbristow3• 5 years ago

C# .NET implements quite a lot of these too via LINQ, albeit with different names (e.g. map is called Select).

https://docs.microsoft.com/en-us/dotnet/api/system.linq.enum...

TheRealDunkirk3• 5 years ago

Oy vey, LINQ. Meshuggeneh. Nothing like dropping COMPLETELY out of your language's idiom for a line or two to implement some Enumerable-like behavior.

epage• 5 years ago

For me, its the explicitness in Python that is killer. I can see a name and match that to an import and match that to a package. Grabbing a function pointer works exactly as I would expect.

Stealing from Krister Stendahl's laws for religious discourse, Ruby's composable iteration is one area I have holy envy, particularly after I got used to it in Rust. I've used Python's generators many times just to have to switch to an explicit for loop. Things are generally better with a composable iteration model but occasionally I find myself switching to explicit loops in Rust.

Unlike Ruby, Rust does pull-iteration like Python, though there are experiments with Ruby-style push-iteration [0] [1].

[0] https://github.com/AndWass/pushgen

[1] https://epage.github.io/blog/2021/07/pushgen-experiment/

qsort• 5 years ago

I agree.

I'm not the biggest Python fan myself and would not recommend it for large projects, but I use it a lot both at work and personally for scripting/small stuff. It feels dumb, but I like dumb for those use cases.

rgoulter2• 5 years ago

I can see a name and match that to an import and match that to a package.

I like this too, but... I don't find dynamic languages to be very explicit.

Given that Python is a dynamic language, I only going to know what I can do with (or what is true about) the arguments to some function if I have worked with the codebase previously (or have sufficiently good documentation, and unit test coverage).

horsawlarway6• 5 years ago

At least with an explicit import you have something to search for.

I have often spent several minutes trying to find a definition for a ruby method/modules/class only to finally have to run it and dump the file location manually with `source_location` to find out it's really a 3rd party gem added to the project.

Admittedly, Rails makes this much worse.

efxhoy• 5 years ago

I can see a name and match that to an import and match that to a package.

I miss this so much. I'm a python dev now working on a big Rails monolith. Where does all this stuff come from?

handrous• 5 years ago

Onboarding to all but the most perfectly-written-and-maintained Rails codebase is pure hell, for exactly that reason. I've done lots of Rails in the past, but sworn it off after enough such experiences.

[EDIT] Which sucks, because I really like Ruby.

Lio• 5 years ago

If you ever wonder where something comes from and you can't get your editor/IDE to tell you, you can always try asking the runtime.

Drop a debugger statement in above the code in question, then at the prompt turn the method into a Method object using something like:

  bar_method = foo.method(:bar)

and then

  bar_method.source_location

Once you have a Method object you can pass it around as a stand alone function, rebind it or call too.

#source_location only works for methods defined in ruby itself i.e. not C or Java but it's still a handy tool on big ruby projects.

Most of the time I just use ctags to navigate new codebases but we also have things like Solargraph via LSP too.

joelbluminator3• 5 years ago

Are you using a good IDE? With Rubymine (which indexes all of your gems) this is a much less big a deal.

rubyist5eva2• 5 years ago

I use Rubymine and can cmd+click on anything and it shows me exactly where it came from. Been developing in rails for a decade and the auto loading has bitten me at most 5 times.

gls2ro• 5 years ago

Here it is important to notice that Rails is like a superset of Ruby. Rails = Ruby + conventions + helpers.

So if you want to always be aware where things come from choose Sinatra, Padrino or Hanami.

softwaredoug11• 5 years ago

Author here - I agree on explicitness, it can be a bit maddening to trace where a symbol comes from in Ruby. Though a good IDE helps.

lamontcg• 5 years ago

https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debugger...

qudat• 5 years ago

I can see a name and match that to an import and match that to a package. Grabbing a function pointer works exactly as I would expect.

Autoloading is one of the worst features ever introduced into a language/framework.

https://erock.io/2021/11/01/on-autoloading.html

friedman234• 5 years ago

Ah yes, now I remember why I stopped learning ruby and was generally disgusted with the language. Along with the standard library having numerous ways to do the same thing and the general use of monkey patching (and the ruby users actually thinking monkey patching is good)

pas5• 5 years ago

I have no problem with PHP autolading, or TS dependency injection (as seen in Angular, NestJS, TSed), or even in Scala (Play! framework via Guice). Because it's not magic (since you need to import the types you know what you are getting, for PHP there's the autoload.php generated by Composer, for TS everything is in the node_modules and in the lockfile, and for both Scala and TS the compiler checks things too. Of course in TS there are sometimes problems for non-native [ie. JS + .d.ts] libs, when the typing becomes outdated).

But in Python the amount of magic shit one had to do to get things loaded in a sane manner was always somehow a serious burden.

.. but in Ruby (Rails). Well, yeah, all you have is a lockfile, and nothing else. No imports, no typing. That gets crazy really fast. :)

byroot• 5 years ago

Again, your complaint, while valid, has nothing to do with autoloading, but with namespacing: https://news.ycombinator.com/item?id=29117535

Groxx• 5 years ago

Well.... except when the package doesn't match the import path. Then you can get stuck in a merry search for "what the heck is X and why is it not in our lockfile".

errcorrectcode2• 5 years ago

I use Crystal more these days because it looks like Ruby but it's typed and statically compiled.

derwiki• 5 years ago

More for professional or hobby projects?

errcorrectcode2• 5 years ago

Hobby mostly. Not very often. Use Rust mostly.

friedman234• 5 years ago

Crystal does look interesting, it also supports parallelism with green threads right? The thing that always bothered me about ruby is that there are multiple ways to do the same thing in the standard library.

yxhuvud• 5 years ago

Yes, it has green threads.

Crystal don't have the same tradition of having aliases of common methods as Ruby does, no.

lottospm• 5 years ago

I was never a fan of ruby until I had to use it at work.

I think my main superficial turn-off was indeed the non-traditional loops and I was a fan of python whitespace indentation.

But on the whole ruby just feels very coherent and language features mesh very well together - it often feels like a true lisp with self-style object orientation done very well [1].

Python otoh feels like an imperative language with classical OOP added on and extended via magic methods.

See e.g. functional programming in python vs ruby with map, filter, reduce and so on and how blocks and procs in ruby interact with those vs lambdas in python.

I still use python often but have to say I tend to miss ruby when I do.

[1] https://news.ycombinator.com/item?id=1803815

pelasaco2• 5 years ago

Peter Norvig is always a pleasure to read, even on HN. Imagine how precious is the history of HN Threads... i hope someday someone compiles it in a consumable fashion.

petre• 5 years ago

was a fan of python whitespace indentation

That's what turns me off about Python (and f-strings), being a Perl programmer. I've had to do some proof of concept for reading smart cards and the Perl PCSC library sucks. So I did it in Ruby, which like Perl has pack/unpack methods for converting hex strings to binary and back. It's just great. Now I have not two programs to read smart cards, one using the Ruby smartcard library and another one using rubyserial and doing serial communication directly with the card reader, with a partial implementation of the T1 protocol, all in under 1k lines of code.

hk1337• 5 years ago

This doesn't have anything to do with Python but Ruby feels more of a natural language for doing rapid application development and active record than Laravel does.

jimbokun2• 5 years ago

In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.

"the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement" should be the working definition of "agile" development in almost every context. Would save a lot of confusion and pointless arguments about the true definition of agile, kanban, extreme programming, or what have you.

lostcolony• 5 years ago

https://agilemanifesto.org/

Most of the things you list are things you may or may not get right the first time; what makes something agile, at least, when the term was first floated, was the ability for the team to own the solution, say "this is not working" (be that architecture, team structure, process, etc), and change it easily. Agile was "ability to (rapidly) change", not "adherence to a defined set of rules called 'Agile' ".

Most places don't actually seek out that definition of agile, though. And so there's a lot of bikeshedding around "what process is the one true way (and what can we add to it to make it work when it fails us)" rather than "how do we empower the teams to make their own decisions on how to best be effective"

sam0x173• 5 years ago

I think my main superficial turn-off was indeed the non-traditional loops and I was a fan of python whitespace indentation

I've always been perplexed that this, a very small thing that barely ever comes up since 99% of the time you are doing a for each loop anyway, is the main turn-off for people learning Ruby, when Python has those crazy weird if statements and indentation-sensitivity

burnished• 5 years ago

What do you mean crazy weird if statements? You can do one liners, or if you don't your indentation is similar to what you'd see in C++.

if condition: return expression if condition: foo = value

if condition: body statements elif condition: body statements else: body statements

pkulak• 5 years ago

It's always been the global functions in Python that put me off. My brain just doesn't think like that. When I want the length of an array, I look for a method on the array. Same with map, and anything else.

That said... pretty small gripe in the grand scheme (no pun intended, maybe) of things. When I've written projects in Python, I've enjoyed it.

echelon• 5 years ago

It's always been the global functions in Python that put me off.

I'd argue it's the inconsistency. Some things are methods, some things are functions. The name choices are also a bit boneheaded (eg. "dumps"). It's a lot like PHP in these regards.

Ruby, on the other hand, is beautifully designed. But it gives you a bazillion ways to skin a cat, and people love to be "clever" with their cat skinning. In those cases, I appreciate the utilitarian approach and "zen" of Python.

My biggest gripe with Python, though, is the totally 80s feel of the version and package management. It's one of the worst experiences in my daily engineering life. I can never know if complex ML code will work on my system without thirty minutes of patching things up.

I'll gladly use Python to get work done or Ruby for small websites. But I'm looking for a new daily driver for scripting that learns from the last thirty years of mistakes. (Modern language, sensible packaging/dependencies/version switch, optional static typing, and optional static binary output.) Nim, perhaps?

mixmastamyk7• 5 years ago

It's meant to be more readable by being closer to English:

When I want the length of an array

    len(array)

thedracle• 5 years ago

I think in Python, I saw a good deal of adoption in the Sciences early on.

I worked on a Physics experiment almost 15 years ago, there were inklings of Python dripping in to doing numerical analysis.

NumPy just using existing Fortran libraries is a good example of it just being bootstrapped by the scientific community.

Most of these guys come from a Fortran background, and some used the C++ ROOT framework.

Ruby was just too alien for them.

ROOT had made some excellent Ruby bindings, and I spent some time showing some of my colleagues how much time they could save using them, but they just found it to be too different.

It's sort of funny to think, because languages made for AI originally like LISP used functional concepts like map, collect, etc etc...

I think the AI trend using Python was boosted by numerical analysis/computing libraries already being present.

a-dub3• 5 years ago

out of curiosity, how do people here feel about using python's functional features in production code in the workplace?

ledauphin• 5 years ago

I've done it and i love it.

The caveat is that Python is only _fine_ at functional programming, and that only because it's very, very malleable. The deeper you go into functional programming with Python, the more you wish you were programming in Clojure, or F#, or whatever.

But I'd still rather use a functional style in Python than an OO or procedural style.

stevev2• 5 years ago

Developer happiness, I believe, was one of the main pinnacles and design choice of Ruby according to Matz. Meaning he wanted developers to enjoy coding in Ruby.

gilbetron2• 5 years ago

I think there are just multiple kinds of developers. I've programmed a fair amount, professionally, in Smalltalk and Ruby, and quite a bit in Python (along with lots of other languages). If I squint I can see why some kinds of developers like Smalltalk and Ruby more, but I am not that kind of developer. Python is better (for me) for small to medium projects, and then I prefer strict typing for larger projects (currently Go, which I'm ok with).

But I know plenty of people that love, love, love Ruby and I respect them as developers, but what we enjoy in a language is just different.

TheRealDunkirk3• 5 years ago

I think there are just multiple kinds of developers.

I've seen this very glaringly. I love Ruby and Rails, and want to leverage the stack as much as is reasonable. I've come to realize that there are people who really would like to write 100-200 lines of Java for every line of Ruby I write, just so that they "have control." I think they have no idea what they're talking about, but I have no influence over them. The fact that I'm writing my 3rd application in 6 years which does something that entire teams of outsourced developers could not do is, surely, just coincidence.

joelbluminator3• 5 years ago

Yes this is mostly it. Some of us just have a different world experience and are wired differently; the thing with engineers is that they don't like subjectivity - they need absolute answers, but it's really like debating who is better Metallica or Nirvana. The type of programmer who likes Ruby usually appreciates aesthetic code, freedom and expressiveness. The type of programmer that likes Go usually appreciates strictness, one way of doing things and performance. In the end to the average SAAS startup it really doesn't matter which of the popular languages you choose, it's been proven countless times that any of these languages can build monster size companies

thanatos519• 5 years ago

I believe it, and it shows! Coming from a longtime Perl background and switching to Python (which has its pros and cons) and then finally trying out Ruby, I felt like Ruby was what Perl should have become.

kbenson• 5 years ago

Ruby was heavily inspired by Perl. I know a few people that moved from Perl to Ruby and felt quite a home. (Personally, my path away from Perl is likely to be to TypeScript on Deno, since if I'm going to make a change I might as well pick up some major benefits along with the normal set of trade-offs).

stefanchrobot• 5 years ago

Why not both? I want the language to provide an iterable/enumerable interface with the usual generic workhorses (map, reduce, etc.) and allow me to implement that interface as a free function for any type. If I'm authoring a type, I'll add specialized functions as needed.

aardvark179• 5 years ago

Ruby manages to do this. The default implementations of all the methods you want are on the enumerable module, so if you implement the “each” method you get everything, including the ability to get an enumerator object that you can pass round and use for anything else you want.

dvdhnt• 5 years ago

I'll be absolutely subjective here.

Python seems fine, except that I can't get comfortable in a language that uses whitespace as part of its syntax.

I know the typical arguments of "linter, etc" but I believe my ruby and JS code, which includes using a linter and formatter, is easy to reason because brackets allow for better mental encapsulation.

All personal experience, I can't speak to the technical differences.

drcongo3• 5 years ago

I think once you get more used to it you'll find the complete opposite. All those brackets are extra things your brain needs to process when reading the code, strip them away and it becomes just like reading written language. Ruby to my eyes, even when well formatted, looks as ugly as PHP - a mess of unnecessary indications that destroy the readability of the code (for me).

arcticfox• 5 years ago

As a Python->Ruby convert like the parent here, I'm curious, which indications do you find unnecessary? The only one I can really think of is `end`, which, sure. But the implicit return is also much cleaner after I got used to it, so I think that's a wash.

dragonwriter9• 5 years ago

All those brackets are extra things your brain needs to process when reading the code, strip them away and it becomes just like reading written language

No, it doesn't, because written language explicitly marks ends, and sometimes also begginings, of structural units (programming gets brackets from natural language), it doesn't just use white space (until you get to units bigger than sentences.)

kevinmgranger4• 5 years ago

I really wish there were languages with tooling to expose the source as either whitespace-using or bracket-using. It would solve so many conflicts.

Let's have it handle tabs or spaces while we're at it. The answer could always be "whatever you prefer".

My kingdom for better tooling!

dagw• 5 years ago

Let's have it handle tabs or spaces while we're at it. The answer could always be "whatever you prefer".

As long as you don't mix tabs and spaces in the same file python is fine with either.

chaxor2• 5 years ago

I also love the cleanliness of Python compared to bracketed languages. When I was younger and learning the language it seemed to be beneficial in forcing more structure and readability in the code (no ridiculous obfuscation by single line programs).

There was an article the other day showing how to take latex math notes in neovim the other day. They showed a plugin that displays a render of text on lines that the cursor is not on.

Perhaps there is a way to set that up for languages with brackets? Just show the brackets relevant to that line (and the closing ones perhaps)

intrepidhero2• 5 years ago

I've been thinking a lot about that too. I wonder if we could have tools where the primary artifact is some kind of AST (a concrete syntax tree maybe?) that the tools translate into the language of the programmers choice. Seems sort of like the next step beyond bytecode. But I'm just speculating and daydreaming at this point.

stavros4• 5 years ago

I'm subjective the other way, why do I need to type brackets when my indentation already carries my intention?

addicted• 5 years ago

A language that uses parentheses does not preclude one from also using indentation to convey code structure. In fact, this is usually standard practice.

Python, however, does indeed preclude one from using additional signifiers of code structure beyond indentation.

And in practice you don’t type out parentheses. You put in a single opening parentheses and your editor will add the closing parentheses and add the appropriate indentation (and if desired, newlines) for you. In practice the only difference in typing is typing a single ( character vs a single <tab> character.

All that being said, this is the very definition of bike shedding, so it’s really not a factor when picking one language over another.

jimbokun2• 5 years ago

Because there are places where indentation signifying intention breaks down.

The classic example being the arbitrary restrictions on the Python lambda syntax.

Ruby is more orthogonal and systematic. Everything is an object, and you call methods on those objects. And sending a block as a method parameter gives you something that very much resembles functional programming (minus the immutability).

There are a few other constructs (it's not quite so dogmatic about object orientation as Smalltalk), but Ruby is very regular and so you can understand how everything works with a small number of syntactic constructs.

setpatchaddress• 5 years ago

You need to spend a couple of days debugging scripts where someone has fucked up the indentation by copying and pasting with a program messes with leading whitespace. Or where someone has inserted an extra whitespace character in a random line in a long script.

tonmoy2• 5 years ago

Having used both professionally I love Ruby and I think python is an ok language. However, if there is one thing I do like about Python it is the white space syntax. It forces all coders including the not-so-technical people to write scripts using proper indentation and it makes inheriting Python scripts a little bit easier

derac• 5 years ago

You can have your IDE indent code in the style you prefer automatically.

cardanome• 5 years ago

Do you have "show whitespace" enabled on your IDE?

I think it really helps being able to see the characters properly. (Also helps avoiding mixing tabs and spaces like some bloody animal.)

While there is some value in whitespace-insensitive syntax, I think using whitespace is a neat and human friendly way to keep things separated and to show structure. We are good at spatial thinking

For example this text is using whitespace between words to tell you where which words starts and ends. It uses paragraphs to further split up certain ideas. (Same with math notation which also uses whitespace)

{[Do; you; think; that; this; is; easier; to; read; ?][Does; it; feel; more; comfortable;?]}

Getting used to new syntax is not as hard as people pretend it is. Never understood the aversion of some people. For Python being whitespace sensitive is a great choice as it helps the pseudocode look of it and is often used as a beginner language. You want beginners to learn how to properly indent code and to suffer if they mix tabs and spaces. (Though maybe now that we have automatic code formatting in many languages, maybe less so.)

UncleOxidant• 5 years ago

I was a Ruby early adopter - early 2001 - because I needed to move from Perl to a new scripting language (OO Perl just seemed like such a hack and there really was something to the Write Once aspect of Perl - I'd come back to a Perl program 6 months after I wrote it and wonder what the heck was going on). I took one day to play with Python. I got burned by the significant whitespace thing right away. Next day I looked at Ruby and it seemed like the perfect fit for what we were doing. Over the next dozen years or so I was a huge Ruby fan. But then around 2014 I got a different job in a Python shop. I thought I was going to have a rough time with the significant whitespace, but I ended up liking it a lot. That's not to say that I don't miss features from Ruby, but I found that I could get along fine with Python's significant whitespace.

edmcnulty101• 5 years ago

This is a great article. I really enjoy reading articles comparing two languages and these kinds of posts are not as easy to come by as discussions about a single language.

petercooper• 5 years ago

I'm a longtime Rubyist who's dabbling in Python a fair bit nowadays due to the growth of the ecosystem and the libraries available. I find Python enjoyable to work with but the thing it makes me love more about Ruby is how in most cases you think about objects and the capabilities of those objects, whereas in Python it feels like a crapshoot (I'm sure it's not, it's just how it feels as a dabbler) as to whether you pass objects into a function (e.g. `len`), use methods on objects, or whether to even think of OOP at all :-)

Now, that's not entirely a negative, I quite like Python's freewheeling "do whatever works and feels best for you" ways, but that feels somewhat contrary to the Zen of Python's "There should be one-- and preferably only one --obvious way to do it." (!)

vikingerik• 5 years ago

Those last aren't mutually exclusive. The idea is that there should be one obvious way, such that you'll find that what works and feels best is that way. The idea is that you will simply want to comply, not to demand that you do.

mixmastamyk7• 5 years ago

https://news.ycombinator.com/item?id=29202044

bkovacev• 5 years ago

I know it's not completely related to the thread - but how is Rails vs Django in terms of performance? I'm getting subjective information that Rails is much faster for APIs in terms of response times, serialization speed etc. although I have been using django for the past 7-8 years and have to say that the best response times was 200-300ms w/o caching for some heavy json responses. And something that should be blazing <100ms, still takes 200ms to respond.

trimbo• 5 years ago

There are too many factors to make a broad comparison in milliseconds. Are you running the code on a RaspPi or on the latest Zen3?

Serialization should be implemented in C so unless the JSON is megabytes in size, whatever is happening here probably has to do with the business logic implemented in Python. Python and Ruby are equally slow when they aren't wrapping frameworks primarily written in C (e.g. tensorflow), so choosing between them is IMO a stylistic or compatibility choice.

zitterbewegung• 5 years ago

In my opinion it doesn’t matter which language you use as long as it’s the right tool for the job . Usually this goes for familiarity of either who you can hire and or you.

Python has some obvious syntax weirdness and Ruby looks like it encourages more DSL and that might make it closer to lisp.

But, Python has so many more libraries and a good editor can help you manage the white space indentation . Also Python scales well too.

To be honest I rather have some kind of different framing of this. Instead of an argument it could have been a comparison but that doesn’t get people to click the link.

FpUser• 5 years ago

In my opinion it doesn’t matter which language you use as long as it’s the right tool for the job"

And "the right tool for the job" is of course language one knows and loves ;)

mgraczyk• 5 years ago

Hmmm, I don't think this article accurately represents how people write python since ~2005. I'm biased because I use python every day, but there's a big objective mistake.

Ruby flips the script, giving the objects deeper customizability.

Not really, because python allows you to do things the Ruby way, but I'm not sure the reverse is true.

    class Stuff:
      def __init__(self):
        self.a = [1, 2, 3, 4]

      def __iter__(self):
        for item in self.a:
          yield item

and you can write it more simply in this case.

    def Stuff():
      a = [1, 2, 3, 4]
      for item in a:
        yield item

What about the select and map example?

    class Stuff:
      def __init__(self):
        self.a = [1, 2, 3, 4]

      def __iter__(self):
        for item in self.a:
          yield item

      def map(self, f):
        for item in self.a:
          yield f(item)

Which can be used just like the ruby example, with syntax of similar ugliness.

    print(Stuff().map(lambda item: item))

I think I could come up with a python example that maps 1:1 onto pretty much any ruby example, but I don't think it's possible in general to find ruby examples that map onto more complicated python.

softwaredoug11• 5 years ago

Author here! Very true, though I was trying to focus on idiomatic python that pushes logic into for loops, list comprehensions, etc w/ composable iterators through tools like those found in itertools (zip, etc...)

Since Python doesn't have Ruby's blocks, you have to define a non-trivial function as a free function, so it's less likely you'll do this. (Python's lambda's are far more limited than Ruby's blocks.)

You can also trick Ruby to return a new value every time a method is called for iteration, but again my focus on what I see as idiomatic in the two languages

gvx• 5 years ago

Your Python example is far from idiomatic, though. If a Python programmer were forced to write `Stuff`, they'd write something like:

    class Stuff:
        def __init__(self):
            self.a_list = [1,2,3,4]
        def __iter__(self):
            return iter(self.a_list)

--- or do what the other person did, and make `__iter__` a generator, which isn't necessary in this case but is much more flexible.

zedr• 5 years ago

think I could come up with a python example that maps 1:1

My take on it:

    class Stuff:
        def __init__(self):
            self._list = [1, 2, 3, 4]
        
        @property
        def each(self):
            for el in self._list:
                yield el
    
    for item in Stuff().each:
        print(item)

It's even less verbose than the Ruby equivalent in the original article, thanks to the indentation-defined blocks.

teddyh• 5 years ago

AFAIK, there is no reason to use the form “for el in self._list: yield el”, unless you are running Python 3.2 or older.

Why not:

  each = self._list

Or, if you need to be able to re-assign self._list to a new object:

  @property
  def each(self):
    return self._list

Or, if you for some reason need it to return an iterator:

  @property
  def each(self):
    return iter(self._list)

Or, if you really want it to be a generator function:

  @property
  def each(self):
    yield from self._list

tomp• 5 years ago

Also known as "external" vs "internal" iterator.

Bottom line: external iteration is composable, internal iteration isn't. Try implementing zip or early stopping using internal iteration (hint: you can't).

chubot• 5 years ago

Yup this is a great article about it that I coincidentally re-read yesterday:

https://journal.stuffwithstuff.com/2013/01/13/iteration-insi...

I find it easier to think of as "push-pull" though. In Python and Go, you "pull" from iterators. In Ruby, JavaScript, and Rust, you're "pushed" upon. You can do both styles in any language, but there's one way that's favored.

To break the dilemma, you need 2 call stacks, which means threads / coroutines / generators.

(There was a recent blog post about writing an iterator to do the powerset calculation, which is a bit tricky, and made me think of this post)

gpderetta• 5 years ago

You can if your language supports first class continuations! (Which ruby has: yield work differently from python I think).

Then you can turn any internal iterator into an external one.

racl101• 5 years ago

As a guy who uses a lot of languages and having started on C-like languages I appreciate Python in that it doesn't make me work terribly hard to get what I need to get done. I'm far from a Python expert cause I don't use it exclusively.

In spite of all that, it's pretty intuitive, reads like pseudo code. Plenty of data types and packages to get the job done.

The few times that I've touched Ruby, however, even though it's succinct and beautiful language, I always have to find myself relearning its super object oriented centric paradigm.

Everything takes 2-3 times as long to achieve and, arguably, not that fast a language either.

I suppose if i worked on web app project exclusively, maybe Ruby might be my language of choice, but I don't.

I'm sort of a jack of all trades master of none position (but that's ok cause in my particular situation I get paid pretty well for it).

So that's why I prefer Python at the moment.

StefanKarpinski2• 5 years ago

This feels a bit ironic given how much the for loop has been villainized in numerical computing, by none other than languages like Python—and Matlab and R—where for loops are so awfully slow that you can only get performance if you avoid them like the plague and write (sometimes awkward) vectorized code that pushes all the for loops down into some C library (or C++ or Fortran). Compared with, say, Julia, where people are encouraged to "just write yourself a dang for loop"—because it's not only effective and simple, but also fast. I guess what I'm saying is that it feels like even though Python may embrace the for loop as syntax, that affinity seems superficial at best, since if you care at all about performance then Python immediately rejects the for loop.

anonpython• 5 years ago

In Python numeric computing it's common for your outer loops to be for loops and your inner loops to be vectorized PyTorch/whatever.

I personally like being able to easily comprehend and control what's being vectorized. Maybe it would be nice if my compiler could automatically replace any inefficient loops with vectorized equivalents, and I could think in whichever idiom came more naturally to the problem at hand. But I don't think there's anything too illogical about looping over epochs and batches, and then computing your loss function with matrices. Maybe I'm just used to a suboptimal way of doing things :)

StefanKarpinski2• 5 years ago

Maybe it would be nice if my compiler could automatically replace any inefficient loops with vectorized equivalents

The trouble is that a for loop is much more expressive than vectorized operations, so most for loops cannot be transformed into vectorized equivalents. The reason convincing people to write vectorized code works for performance is that you're constraining what they can express to a small set of operations that you already have fast code for (written in C). Instead of relying on compiler cleverness, this approach relies on human cleverness to express complex computations with that restricted set of vectorized primitives. Which is why it can feel like such a puzzle to write vectorized code that does what you want—because it is! So even if a compiler could spot some simple patterns and vectorize them for you, it would be incredibly brittle in the sense that as soon as you change the code just a little, it would immediately fall off a massive performance cliff.

I guess that's actually the second problem—the first problem is that there isn't any compiler in CPython to do this for you.

mixmastamyk7• 5 years ago

With hindsight, the languages turned out to be a bit "too dynamic" for their own good. Very few are changing variable types often enough for that feature to be useful. The downside, makes typing bugs possible/more likely, and slows down every access. Par for the course, would say that slow loops are a symptom not a cause.

a-dub3• 5 years ago

matlab has been jit compiled for years now, the "for loops are slow" dogma is over.

numerical computing in python is kinda weird as it wasn't the original purpose and the fast math libraries were bolted on as an afterthought, but even then tools like numba do the same in python, although there's a bunch of nuance in writing simple enough python and hinting at the correct types for the variables in order to get it to compile something reasonable.

julia's let's use strict types, jit compile everything from day one and avoid locking approach is nice though.

toxik3• 5 years ago

After numba’ing several nontrivial pieces of numpy code in my life, you might as well just rewrite it in nopython mode for Cython unless it’s very trivial stuff. Numba errors and partial coverage of numpy is a huge time sink in my experience.

qwertox• 5 years ago

I have nothing to contribute to the content of this article, but I really want to express my gratitude to the author.

I've been using Python for over a decade and installed Ruby once or twice just to touch it, and I really like how this article has managed to bring Ruby onto my radar, not as something which I should use, but should appreciate.

For me it was just a Python alternative which some companies really do like, but this article told me a bit about the beauty of the language. Nice differences.

softwaredoug11• 5 years ago

Thanks! I appreciate the kind words!

dorianmariefr• 5 years ago

This is not idiomatic ruby, you would do

    class Stuff
      attr_reader :list

      def initialize
        @list = [1, 2, 3, 4]
      end
    end

Then:

    Stuff.new.list.each { |item| ... }
    Stuff.new.list.map { |item| ... }
    Stuff.new.list.select { |item| ... }

And if you want top-level each/map/select methods, you could do

    delegate :each, :map, :select, to: :list

softwaredoug11• 5 years ago

Author here, nice! TIL :)

stouset• 5 years ago

I have written Ruby professionally for like fifteen years and I have not once witnessed a `for` loop.

I’m genuinely confused as to where you picked this up. Enumerator and Enumerable are endemic.

retbull• 5 years ago

From an entirely tongue in cheek perspective isn't all ruby idiomatic.

bwilliams• 5 years ago

It's also worth mentioning the Enumerable module that can be mixed in to classes, which gives you `map`, `select`, and much more for free by implementing `each`.

https://ruby-doc.org/core-3.0.2/Enumerable.html

werdnapk• 5 years ago

Including `Enumberable` and implementing `each` gets you all those other methods for "free".

    class Stuff
      include Enumerable

      def initialize
        @list = [1, 2, 3, 4]
      end

      def each
        @list.each{ yield _1 }
      end
   end

gfunk911• 5 years ago

Exactly. It is an interesting idea, but it makes me question the examples when `Enumerable` does not appear in the post.

bullfightonmars• 5 years ago

I thought the examples were just for illustration about how iteration works in Ruby.

rplnt• 5 years ago

Wouldn't it be similar to use this in the python example?

   class Stuff(list):
       pass

kinda makes the article pointless. List obviously only serves as an easy to understand example, not something you are actually trying to implement.

lern_too_spel• 5 years ago

The very first code block has a fundamental error. It allows only one iterator per Stuff instance.

Mikeb854• 5 years ago

Ruby is the first language I learned (apart from dabbling with Visual Basic as a kid). I still reach for it to actually get things done. One thing I always appreciated about it was the consistency of everything being an object and how that allows you to just chain methods together. Kind of reminds me of Lisp in it's consistency (although in Lisp everything is data or a list, not an object). Later I dabbled in Smalltalk (Pharo) just for fun to try to understand what inspired Ruby's object model.

I've tried Python, hated the inconsistency of it, but then again I never tried any C family language before learning Ruby. Calling Each then feeding it a block feels more natural and consistent than a for loop IMO, even if for loops are the standard 'programming' way of doing it. It does make sense to use it as an analogy to describe the differences between the languages.

peterthehacker5• 5 years ago

I've tried Python, hated the inconsistency of it

Can you elaborate on this? I’ve written in both Python and Ruby, but I’m not sure what you mean by this critique of python. I wouldn’t characterize either language as “inconsistent.”

chucke• 5 years ago

a[0]. a is an array. If the array is empty, what's the result, in both languages?

Mikeb854• 5 years ago

In Python some standard operations are global functions and some are methods. Which are which isn't exactly clear. It's also kind of irrational and random but I hate seeing __init__ everywhere.

For example, to find the length of an array in Python you use the function len(). In Ruby you call the method .length. As the article is about, loops in Python are for blah in blah. In Ruby they're blah.each and for loops are just sugar (not sure why they're there but you can avoid them). In Ruby pretty much everything is an object and you just call methods. Very few keywords, global functions, etc...

Also, as the other poster said, if you call a[0] on an empty array, in Ruby you get nil, in Python it throws an error. Not sure which is better or considered more 'proper', but Ruby's behaviour is what I'd personally expect in a dynamic language.

jrochkind12• 5 years ago

This was definitely written by a pythonist! If I tried to write it, as a rubyist, I'm sure I'd get some things about python wrong. (I find it notable how few people there are that are actually familiar with both).

The standard alternative to `for` in ruby does involve `each` and blocks... but definitely doesn't involve defining a custom `each` method on your class... That is a specialty thing that most developers have probably done rarely. Let alone defining it in terms of `for`, which is just weird!

But the basic principle stated "Instead of passing data back to the for loop (Python) you pass the code to the data (Ruby)" -- is more or less accurate.

blocks -- syntactic support in the language for cleanly passing a single in-line defined lambda/closure object as an argument -- are possibly the thing that are most special to ruby.

Python builds on for-like constructs for all kinds of processing; Ruby pushes other kinds of data processing work to methods.

OK, maybe, although not totally sure what you mean.

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:

Um. I'm not sure where the author is getting this. It is certainly possible, as shown, but definitely not common to implement `select` or `map` or other methods provided by Enumerable directly on your custom class. It is a bit more common to implement `each` alone and let the `Enumerable` mixin provide the rest. But even that I'm not sure how "common" I'd call it.

Ruby, however, inverts this. Ruby puts object-orientation as the foundation of the pyramid. Ruby contains the messy procedural world in blocks, letting objects work with those procedural blocks.

OK, true. The author is getting the details wrong, but I guess their overall picture is still right?

pas5• 5 years ago

It's the norm in Scala too.

And it's a bit overdone in (older) JS (libraries).

jrochkind12• 5 years ago

I don't know scala, but the notable thing about ruby vs JS is how ruby provides _syntactic_ support for passing an inline-defined function.

In JS:

    someObj.someMethod(function(something) {
       something
    });

Compare to ruby with the block arg:

    someObj.someMethod do |something|
      something
    end

That `do` is a special syntactic thing avaialble for passing a single inline-defined closure arg. (You can pass one held in a reference instead of inline-defined, but it actually takes an extra somewhat obtuse step -- the syntax is optomized for inline-defined).

This "affordance" says "Yes, we make it really easy to do this, the stdlib does it a lot, please consider doing it all the time in your own code", which goes along with some of what the OP is discussing. Why we write `collection.each {|something| something}` (the braces are an alternate way to pass a block) instead of `for something in collection do...`

jrumbut• 5 years ago

I didn't think the author was saying you should always implement a .each method. I thought the implementations were for demonstration purposes, that .each is a method like any other that can be overridden.

greenie_beans• 5 years ago

that's how i read it too, for the purpose of the technical demonstration

chowells2• 5 years ago

blocks -- syntactic support in the language for cleanly passing a single in-line defined lambda/closure object as an argument -- are possibly the thing that are most special to ruby.

Too bad ruby stopped short of doing the trivial obvious thing and just making blocks be regular values. Instead the language is complicated by special syntax and functions for sending and receiving blocks, and bizarrely limited by the inability to do anything with a block literal other than send it.

Blocks were so close to being good. They managed the triple flip with a double twist, but they couldn't stick the landing. It's not quite a faceplant at the end, but it clearly shows how much better they could have been.

gwright• 5 years ago

Too bad ruby stopped short of doing the trivial obvious thing and just making blocks be regular values. Instead the language is complicated by special syntax and functions for sending and receiving blocks, and bizarrely limited by the inability to do anything with a block literal other than send it.

Blocks are syntactical structures. Your statement is like saying that the parens and commas that are part of the argument list should be "regular values".

I'm not sure what you want to do with a "block literal". If you want to do something with the closure represented by the block, then reify the block into an object to pass it around, wrap it, introspect etc.

I think a lot of confusion about blocks in Ruby is really inconsistent terminology. Using "block" to mean the syntactic expression of a closure, i.e. part of the method call syntax I think helps to disambiguate the syntactical nature of closures from the closure reified into an object that you can pass around, call, etc. (i.e. an instance of the Proc class)

dragonwriter9• 5 years ago

Too bad ruby stopped short of doing the trivial obvious thing and just making blocks be regular values.

Abstractly, I kind of see the point, in practice, I don't see it makes much difference, and given Ruby’s two flavors of function-like objects, it seems to work out for the best.

the inability to do anything with a block literal other than send it.

But sending lets you do anything else you’d want to to do with it. Specifically, to get either of the flavors of callables, you pass it to “proc” or “lambda”, and then use the result.

masa331• 5 years ago

You have that with procs and lambdas

hnav• 5 years ago

What do you mean by inability to do anything with a literal? You can capture it, turn into a variable, turn it into a "lambda" (make next, break, return local), use it like callbacks are used in any other language. Blocks are a bit special in that they go in their own slot for message sends (method calls) which allows the syntax to be unambiguous and the yield keyword allows for optimized calls to passed in blocks because methods that don't reference a block as data don't have to worry about the block outliving the stack frame.

hvis• 5 years ago

Not having every block be a separate value makes it easier for the Ruby VM to optimize such code without escape analysis (which is something that's pretty hard to do in this language).

Don't have to allocate the container => don't need to use the heap one more time. Nor access the block's code through that indirection.

Same thing with methods: they aren't objects, but you can create an object pointing to a method any time you need one.

Buttons840• 5 years ago

Python and Ruby are quite different when writing code, but have almost the exact same technical abilities and limitations in the grand scheme of things. I've always felt there's little reason to learn both.

OJFord• 5 years ago

Yes exactly, you're not really going to learn anything (syntax aside) by picking up the second, unless you needed it for work reasons or whatever there's surely several other paradigmatically different languages that will be more interesting/instructive to learn.

cutler3• 5 years ago

Ruby is way more capable and expressive than Python. There is so much more you can do with Ruby metaprogramming and don't get me started on Python's feeble lambdas which bear the mark of a BDL imposing his distaste for functional programming. Python is the VHS of programming - widely adopted but technically inferior. Ruby appeals to devs who value elegance of design. Take Sonic Pi (https://sonic-pi.net), for example - I can't imagine sam Aaron producing anything like this in Python. The DSL is everything in this app as with Rails.

softwaredoug11• 5 years ago

but definitely doesn't involve defining a custom `each` method on your class...

Author here! Thanks for the feedback.

I suspected as much, and was more or less writing it to be illustrative. Though I agree I am bad at Ruby :)

tinco• 5 years ago

I don't think jrochkind is correct at all, if you want to make a library that has a datastructure that you want to implement custom iteration on, then it is most definitely idiomatic ruby to implement `each` for it. Your article was spot on in my opinion.

That said, in the almost 15 years I've been doing Ruby as my preferred programming language, I think I can count the amount of times I implemented a custom `each` method on one, maybe two hands.

As an example of how `each` is idiomatic, consider the Enumerable mixin: https://ruby-doc.org/core-3.0.2/Enumerable.html if you implement `each` on your class that mixin gives you all those methods (such as select) for free.

kache_• 5 years ago

as a rubyistpythonista citizen, i agree

necovek9• 5 years ago

Hah, as a Pythonista, I'd say it was definitely written by a Rubyist :D

That initial example would usually be, in Python:

  class Stuff:
    def __init__(self):
        self.a_list = [1,2,3,4]
    def __iter__(self):
        for value in self.a_list:
            yield value

Basically, iterators and generators are native constructs that for loop operates on in Python (lists, which are actual "data", are simply special-case optimized instances of those).

Instead of calling iterators/generators "data", I'd call them wrapper control-flow constructs that `for` really operates on which provide amazing syntactic power in Python.

Ruby, from the examples given, seems quite similar, except that the "syntactic sugar" is somewhat inverted. I don't think it makes for a huge difference, but I don't have any Ruby experience.

softwaredoug11• 5 years ago

Author here, I think this would have made the post better for sure, especially to contrast how `yield` does the opposite thing in each language

danudey• 5 years ago

Or, in Python 3.3 and above:

  class Stuff:
    def __init__(self):
        self.a_list = [1,2,3,4]
    def __iter__(self):
        yield from self.a_list

throwaway984393• 5 years ago

syntactic support in the language for cleanly passing a single in-line defined lambda/closure object as an argument

I think Perl has this too? Or, well, I should say that Perl allows you to do anything, so even if Perl doesn't let you do it, you can still do it in Perl.

atombender• 5 years ago

There are other details that are wrong. Ruby does have iterators — except they're called enumerators. The standard implementation is called Enumerator:

    >> [1, 2, 3].each
    => #<Enumerator: [1, 2, 3]:each>
    >> e = [1, 2, 3].each
    => #<Enumerator: [1, 2, 3]:each>
    >> e.next
    => 1
    >> e.next
    => 2
    >> e.next
    => 3
    >> e.next
    Traceback (most recent call last):
            2: from (irb):17
            1: from (irb):17:in `next'
    StopIteration (iteration reached an end)

Enumerators behave similarly to generators in Python thanks to utilities like #to_enum:

    class X
      def each
        yield 1
        yield 2
        yield 3
      end
    end

    >> x = X.new.to_enum
    >> x.each
    #<Enumerator: #<X:0x00007fd30c93dfa0>:each>
    >> x.next
    1
    [etc.]

Ruby's for loops actually use enumerators, just like Python. It's just not used as much, for cultural reasons; most devs these days favour Ruby's data-oriented inversion of control.

dehrmann2• 5 years ago

Interestingly, Java has both styles. You can do

    for (var i : list) {...}

    list.forEach(i -> ...);

Except for cases with local variables, I have absolutely no idea which I should prefer. Kotlin makes a cute case for the functional style with it's lambda shorthand:

    list.forEach {
        ...
    }

I've found the functional style helpful for times I want almost add a language feature to avoid boilerplate. The functional style was added without special-purpose language changes, but the iterator version required Java to add Collections, Iterators, and eventually fancy for-each syntactic sugar.

entropicdrifter• 5 years ago

The big advantage of the functional style in Java is that you are disallowed at the compiler level from modifying the contents of the collection you're iterating over. That sort of compiler-enforced good practice is definitely for the best.

dehrmann2• 5 years ago

you are disallowed at the compiler level from modifying the contents of the collection you're iterating over

This fails at runtime, not compile time for me:

    x.forEach(i -> x.add("a"));

mumblemumble• 5 years ago

You could dig even deeper. The reason for these differences in how the for loop works happen because Python comes from the procedural tradition, while Ruby comes from the Smalltalk tradition.

In other Smalltalk-inspired languages (but not Ruby), you can do the same thing with an even simpler language feature: if-statements. In procedural languages, including object-procedural languages such as Java and Python, an if-statement is a core language feature with its own syntax. In Smalltalk, conditions are kicked out of the core language and into the standard library. You have methods on the True and False objects that either take an anonymous function and execute it or perform a noop, or take two anonymous functions and decide which one to execute.

xfalcox• 5 years ago

Ruby, however, inverts this. Ruby puts object-orientation as the foundation of the pyramid.

I'm doing some work using Jupyter/Python and as a Rubyst on my day job this is definetly how I felt!

Since data science has so many data manipulation, the move from objects controlling the iterarion from language reserved words doing it was sooo weird at first.

dragonwriter9• 5 years ago

While people have pointed out that this is not idiomatic:

  class Stuff
    def initialize
      @a_list = [1, 2, 3, 4]
    end

    def each
      for item in @a_list
        yield item
      end
    end
  end

I haven't seen anyone point out the deepest reason why: unlike in many languages, “for” is not a basic, low-level construct in Ruby, it is syntax sugar. That is:

  for x in y
    x.stuff
    more_stuff
  end

is sugar for:

  y.each do |x|
    x.stuff
    more_stuff
  end

(Also, for quite a long time, for...in also had runtime overhead , so it was slower syntactic sugar.)

for...in is rarely used (it is syntactic sugar that is neither more concise bor more specific in intent, but more familiar to people with experience in non-Ruby languages), and mostly on scripts that consume but don’t implement collections. If you are getting deep enough to be implementing an #each method for a custom collection, that's an odd place to use for.

saghm• 5 years ago

I'm not sure if this was ever changed, but I remember running into something surprising regarding variable scoping with for loops (I think it was during an internship in 2014, so I think Ruby 2.x with some relatively low value for "x"). Unfortunately I can't remember exactly what it was; I think it was something about variables defined in the for loop still being in scope afterwards? That doesn't seem like it should be the case if it's just syntactic sugar for `each` though, so I might be remembering wrong

dragonwriter9• 5 years ago

Yes, for loops (and similar statements) don't introduce scope, so its not quite simple sugar for .each, and there are a few cases where you might use them over each for that property (if you are mutating values that you want to access afterward, it can be more concise than each) but they are mostly anti-idiomatic.

necovek9• 5 years ago

But that actually makes it more similar to Python.

In Python, `for value in iterator: x(value)` is syntactic sugar for (roughly)

  while True:
    try:
      value = next(iterator)
    except IterationError:
      break
    x(value)

Basically, it seems that `while conditional` are both low-level control flow constructs in both: how do they differ between languages?

alexfrydl• 5 years ago

Ruby's “for … in” is syntax sugar in the sense that is just another way to spell an identical piece of code. This would be like if Python let you write “foreach” instead of “for” if you wanted to. Another example in Ruby is how you can say “unless” instead of “if not”.

Python's “for … in” is syntax sugar in the sense that is an abstraction over constantly writing out the iterator protocol.

barefoot_coder• 5 years ago

If this was interesting to you I suggest reading https://journal.stuffwithstuff.com/2013/01/13/iteration-insi...

gorgoiler• 5 years ago

Prescient. I found myself wanting to pass a block of code to a Python class today, like what I used to do when I wrote Ruby. I very nearly hacked it up using cursors and an iterator but I saw sense before birthing a monster.

antod• 5 years ago

To me, the biggest fundamental difference between Ruby and Python seems to be that:

In Python methods are implemented via callable attributes (it's dicts all the way down)

In Ruby attributes are implemented via methods (it's messages all the way down)

I've been working professionally in Ruby for 5+ years, but non-professionally using/dabbling Python for 15 before that. Personally I still find Python more intuitive though even if I haven't used it for ages - it just fits my brain more automatically and quicker. Ruby is nice overall (ie the smalltalk inspired bits), but the more Perl inspired bits irk me, and parts of the Ruby community can produce some insane library/framework code trying to make interfaces as "elegant" as possible.

toxik3• 5 years ago

As an almost exclusive Python programmer, I’ve often looked at Ruby’s block syntax with jealous eyes. It would be so nice. But I wonder if that’s maybe the exact thing that I also like about Python: the language is pretty damn simple in its essence. You want to minimize cleverness wherever possible, and that idea is firmly planted in the community. Ruby has this sense that Ruby is almost a meta language, you create cool “DSLs” in it to accomplish your goal. That makes it harder to fit into the brain also.

burlesona2• 5 years ago

For what it’s worth, the language itself is extremely simple and composable, which is what makes it possible for people to use it as a kind of metalanguage.

That was really popular in Rails gems around the time that Rails itself peaked in popularity, but has since died off considerably. It was never especially common outside of Rails gems. There aren’t that many things that call for DSLs.

chillfox3• 5 years ago

I think that really comes down to how your brain works or the way you think about logic. For me Ruby is a lot easier to wrap my head around and understand than Python is.

nomoreusernames• 5 years ago

are we still doing the whole y vs x thing with languages? why are people wasting time on this? assembler wins. we already know this. the rest is just laziness. /this is sarcasm.

kazinator• 5 years ago

TXR Lisp:

  $ txr stuff.tl 
  1
  2
  3
  4

  $ txr stuff-cons-like.tl
  1
  2
  3
  4

  $ cat stuff.tl 
  (defstruct stuff ()
    (vec (vec 1 2 3 4))
    (:method length (me) (len me.vec))
    (:method lambda (me index) [me.vec index])
    (:method set-lambda (me index val) (set [me.vec index] val)))

  (each ((x (new stuff)))
    (prinl x))

  $ cat stuff-cons-like.tl 
  (defstruct stuff ()
    (list (list 1 2 3 4))
    (:method nullify (me) me.list)
    (:method car (me) (car me.list))
    (:method cdr (me) (cdr me.list)))

  (each ((x (new stuff)))
    (prinl x))


  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  1> (disassemble (compile-toplevel '(each ((x (new stuff))) (prinl x))))
  ** expr-1:1: warning: new: stuff does not name a struct type
  data:
      0: stuff
  syms:
      0: struct-from-plist
      1: iter-begin
      2: iter-more
      3: iter-step
      4: iter-item
      5: prinl
  code:              ;; manually annotated!
      0: 2001000A gcall t10 0 d0  ;; t10 <- (struct-from-plist 'stuff)
      1: 04000000
      2: 20010009 gcall t9 1 t10  ;; t9 <- (iter-begin t10) ; t9 is iterator
      3: 000A0001
      4: 20010006 gcall t6 2 t9   ;; t6 <- (iter-more t9) ; more items?
      5: 00090002
      6: 3800000F if t6 15        ;; if t6 not nil continue, else goto 15.
      7: 00000006
      8: 2001000A gcall t10 4 t9  ;; t10 <- (iter-item t9) ; get item
      9: 00090004
     10: 20010006 gcall t6 5 t10  ;; t6 <- (prinl t10)
     11: 000A0005
     12: 20010009 gcall t9 3 t9   ;; t9 <- (iter-step t9) ; step iter
     13: 00090003
     14: 34000004 jmp 4           ;; repeat
     15: 10000000 end nil         ;; terminate, yielding nil
  instruction count:
      9
  #<sys:vm-desc: 14fcb80>

dnautics5• 5 years ago

After spending years in functional-land, I find the for loop (and while loop) construct maddening; you have to maintain the state of the entire enclosing scope system in your head, whereas enumerable constructs like map and reduce close (ideally read only) over variables in scope and if you need to keep state you have to use reduce, which explicitly tracks what changes between iterations and nothing "unexpected"... In a general sense, FP enumerations are more explicit than control loops which are implicit state machines.

peterthehacker5• 5 years ago

After spending years in functional-land, I find the for loop (and while loop) construct maddening; you have to maintain the state of the entire enclosing scope system in your head.

This is only true if immutability is enforced. In js you see map used to mutate variables outside the scope of the map closure all the time.

  const o = {}
  const d = [1, 2, 3, 4]
  d.map(i => o[i] = i**2)

Which is equivalent to this python.

  o = {}
  d = [1, 2, 3, 4]
  for i in d:
    o[i] = i**2

The cognitive load is the same in both. The strength of pure FP languages come from enforced immutability, but that constraint often adds cognitive load in other ways.

dnautics5• 5 years ago

constraint often adds cognitive load in other ways

In my experience (and others) those constraint only reduces cognitive load, it can increase actual performance load, and can make certain algorithms "basically impossible", but you're also never actually writing those algorithms. When was the last time you ACTUALLY used dykstra's A*? Come on, most of us are writing SAASes, APIs/backends and basic frontends here (yes, the rest of you do exist), and even for shitty O(n^2) algos, your n is probably in the 10-20 range. Your bad algorithm will not take down the server.

weatherlight• 5 years ago

that's not equivalent.

      d.map(i => o[i] = i\*2)

Will produce a new array on top of mutated data, o, in the parent scope.

      d.forEach(i => o[i] = i**2)

would be the one-to-one equivlent

blindmute• 5 years ago

Nobody who writes JS professionally would ever use map like that. That's exactly what forEach is for.

mdavidn• 5 years ago

The author overlooked the most mind-bending feature of Ruby blocks, the thing that makes them so very different than lambdas in other languages: Blocks can return from the enclosing function.

  def process
    collection.each do |element|
      return element if condition
    end
  end

This has the effect of popping three (or more) frames off the stack. From the perspective of #each, yield never returns.

nixpulvis• 5 years ago

I'll link this, because it's mostly related, why not:

https://nixpulvis.com/ramblings/2020-03-16-set-builder-notat...

burlesona2• 5 years ago

If you want, you can write Ruby Enumerators (not Enumerables) as well, which work like the Python example.

A fairly concise example: https://garycordero1690.medium.com/ruby-enumerator-74b84615f...

vidarh8• 5 years ago

Of course writing an Enumerator is writing the equivalent to an "each" method, hence why you can also trivially turn any object that implements each into an Enumerator.

taeric• 5 years ago

It is funny to add other languages to this discussion. To wit, I'm reminded of the article regarding someone learning clojure where their coworker left them a note that read "just use a hashmap!" Indeed, in so much of lisp, it is all just some form of list. Either lists that have a first and a rest, or those that are alternations of names and values, or those that are pairs of items, etc.

jmalicki• 5 years ago

I wish someone wrote this in 2005 when both were coming up as popular languages!

Ruby vs. Python comes down to the for loop

Related Stories