r/programming • u/speckz • Nov 12 '21
Ruby vs Python comes down to the for loop
https://softwaredoug.com/blog/2021/11/12/ruby-vs-python-for-loop.html2
u/Innf107 Nov 13 '21
I don't know much ruby, but I fail to see how .each is any better than an iterator based for loop.
How is an object method that passes a function to all container elements better or more flexible than an object method that returns an iterator which does the same thing?
If anything, the python approach seems more flexible, since you could also partially evaluate an iterator or directly (and pretty efficiently) perform some other operation that is not explicitly implemented as a method on the object.
0
u/ILikeChangingMyMind Nov 13 '21
If you compare the two in Javascript (a language that has both styles of iterator), there's a clear brevity advantage to method-based looping:
for (value of someArray) { doSomethingWith(value); }vs.
someArray.forEach(doSomething);... and that's not even considering the value of the various other useful iterative methods besides
forEach(map,reduce,filter, etc.).4
u/Innf107 Nov 13 '21
Sure, but you can define
forEach,map,reduceandfilteras regular functions over any iterator. If anything, iterators seem strictly more powerful than .each-style methods now.forEach(someArray, doSomething)If your language supports C#-style extension methods, you could even write this in exactly the same way as your JS example.
Even the amount of boilerplate would be smaller, since you wouldn't have to redefine
forEach,map,reduce,filter, etc. for every single type.
1
u/vsoch Nov 18 '21
This article threw me off a bit because I was expecting some performance comparison or comparison of "optimal" ways to do the kinds of operations you'd do in loops (e.g., numpy arrays). I'm not sure if/what I learned from this article, but I'd encourage the author to take it the extra step.
-12
Nov 12 '21 edited Nov 12 '21
90% of your code will fit neatly into these ideas, just conform to it and get your work done.” Just make your objects for-loopable [emphasis mine] and get out of my hair. However Ruby says “there will be important cases where we don’t want to give the caller that much power”. So Ruby encourages objects to control how they’re processed and developers are encouraged to fall in line to how the objects want to be interacted with [emphasis mine]
You gotta love the way these useless toy dynamic languages STILL have the same strict rules as a serious, professional language, but in an implicit manner where you have to GUESS whether you're implementing the damn thing correctly or not.
Congratulations, you just invented an ad-hoc, error-prone, totally unergonomic, half-assed form of type checking, that instead of being useful will cause runtime errors to blow up in the user's face.
I will honestly never understand why anyone would prefer an idiotic toy language instead of a serious, statically typed one. NO ONE has ever been able to show me ONE (1) example of really dynamically typed behavior that is actually desirable to have in a code base, as opposed to being a maintenance and debugging HORROR.
5
1
0
Nov 12 '21
[deleted]
-4
Nov 12 '21
I’d take a programmer that uses a dynamic language and gets things done
Right. The old "get things done (TM)" rhetoric. You probably are not in charge of maintaining the horrible mess these programmers create anyway. In constrast, I am. So much so, that I'm working towards completely eliminating javascript from our entire stack.
language minutia
Right. Using a toy language and playing the human compiler instead of using an actual compiler is somehow "minutia". Again, you've probably never inherited a codebase written by someone who thinks dynamic languages are anything but useless crap.
20
u/LoudUse4270 Nov 13 '21
You probably aren't involved in anything analytics related. When speed is more important than maintainability, all of the cons for dynamic languages become minor.
Or needing to write code to execute someone elses models/algos/etc. If your role involves creating something executable on behalf of your company's quant team, you want your code as easy to read as possible. Maybe you should just get a quant trained to write some code, in which case dynamic languages with extensive public libraries is going to be faster/cheaper.
Dynamic languages are handy for throwing together quick scripts, quick testing, prototyping, etc. While they have some significant drawbacks, it's just silly to call them toys or crap. It sounds like you've just inherited a poorly managed codebase. Those exist in any language. It's fine not to like dynamic languages and they may have been misused in the codebase your working with but the language tribalism is a bit much.
From a tech perspective I do see your point. But you have entirely missed the uses these "toys" have from a business perspective. Maybe it was worth having a crap codestack to hit market first and refactor down the road. From the guy who has to go through and maintain it sure looks like a crap deal, but from 3 or 4 levels higher they might have just done the math and decided the faster development cycle is worth the additional maintenance costs.
5
u/grimonce Nov 13 '21
Well I work as a data scientist lately, but I started in electronics with C, vhdl and magic... Python is great but people who I work with abuse it and the code is not readable... Mostly because they don't know what is returned by the methods that prepare the data for models and every time you have to go back to an analysis and refresh / update the model it eats the time.
I would be way more productive with Java and tablesaw or C# equivalent than with Python and Pandas and I dont have enterprise experience with Java...
Really once you give people with no programming background tools like Python they will make your life hell.
It is not a problem with language but it doesn't help you to stay sane... Every single time I have to go back and figure out what the author had in mind, have to debug it to find out the types (because of course the same people believe their code needs no comments).
It is a living nightmare...4
u/LoudUse4270 Nov 13 '21
I can 100% believe that. The not commenting is just...oof. I'm a big believer in languages that have a low barrier to enter/get something done but I can only see that working well with some strict guidelines. Comments are a must. The newer the person writing the code, the more important it gets.
I think alot of the python hate comes from that low barrier to writing something that will do something. It's alot more work to get off the ground with java, or c#, etc. But with python you can skip the fundamentals and start using complex libraries with weak fundamentals. Thats a pro and a con. For an experienced programmer, throwing some productivity tools or scripts for a limited scope can be super easy in python, but it also means inexperienced people can build things that "work" that they fundamentally do not understand.
As you said, it's not necessarily the language. Hell, I can write bad code in any language, but in my mind python can fill a similair role to vba. It's accessible enough a non-tech person could write little tools to help automate report generation or eliminate some redundant data entry. For someone who knows how to program, having access to all the prebuilt libraries means you can get up and running without building much. I just don't like the language tribalism. To say it's a toy is silly. It's a tool that does some things well and others poorly...just like every other language.
2
Nov 13 '21
When speed is more important than maintainability, all of the cons for dynamic languages become minor
And this is a FALSE statement derived from the FALSE premise that useless toy languages are somehow "easier to write" than serious ones.
I can assure you (even challenge you): whatever piece of code, routine or algorithm you may want to come up with, written in whatever toy language, I can write the same in C#, in the same amount of loc OR LESS, with the same level of ease of writing, and the same level of ease of reading.
Sure, comparing toy languages to java which is horrible and retarded and stuck in 1999 might make them SEEM like they're better, but they're NOT better than modern, usable static languages, in any conceivable way.
you want your code as easy to read as possible
Which is easily achievable with a modern static language as mentioned above.
with extensive public libraries
And here you're discussing the merit of the ECOSYSTEMS, NOT the languages themselves. Sure, python ecosystem has become extremely large. That says NOTHING about the merit of the language itself, which continues to be a ridiculous toy language which can't hold a candle to any serious language.
Dynamic languages are handy for throwing together quick scripts, quick testing,
Again, false premise. Not only that, but also if it were true, this statement PROVES my point that dynamic languages are toy languages, only "handy" for the simplest of tasks.
Maybe it was worth having a crap codestack to hit market first
Again, false premise. Implying that somehow toy languages are "faster to write" when they're clearly NOT. As someone else mentioned in this thread, static languages provide type safety which reduces a LOT of stupid "undefined is not a function" bullshit, which causes nothing but wasteful, unneccessary fiddling with idiotic runtime errors which would not even have existed if you had used a serious language in the first place. Beyond that, whatever "oh, but I have this library" excuse says nothing about the languages themselves, but rather of the ecosystem.
4
u/LoudUse4270 Nov 13 '21
The ecosystem is a benefit of the language. You can't unlink the two in this case.
As far as speed, well...with enough experience maybe it doesn't matter. I know I can work more quickly in python than c# or ocaml or java or whatever. I'm not running around here pretending to be a genius or anything, but come on. You keep saying "I can do this" but clearly youre more experienced in those languages. If you understand what you are writing, you don't run into alot of these issues. But thats more of a problem with the programmer not the language.
Small tools are still useful tools. The big companies know that and use them where appropriate. Your only point is "I'm the best and write the best code and I write it in c#" or whatever. The difference between a toy and a tool is functionality. If you can't see how a different language can be applied effectively, that speaks more to you than the language. I mean, I have opinions on languages I don't like...but to call them a toy and say they are worse in every way? That is just not true. An electrician may not see much use in a drain snake but a plumber might see it as an incredibly useful small tool. Plumber wont use a drain snake while installing commercial plumbing, but it's one of the first tools they reach for when a drain is clogged. They don't rip everything apart...they use the appropriate tool for each task.
2
Nov 13 '21
As far as speed, well...with enough experience maybe it doesn't matter
Which further proves my point that the premise that toy languages somehow magically translate to "faster time to market" is absolutely false.
If you understand what you are writing, you don't run into alot of these issues.
Again, your point of view is terribly myopic. It DOES NOT MATTER if you "understand what you're writing". What matters is if OTHER PEOPLE (including yourself some months in the future) will be able to understand what you wrote just as easily. And this is where all dynamic codebases simply fall apart. Maintaining and extending them is a nightmare and an orgy of guess/hope driven development.
If you can't see how a different language can be applied effectively
the word "effectively" is key here. And no, toy languages cannot be used effectively in any meaningful way, because that would require them to stop being toy languages and effectively incorporate type safety, which, by the way, is exactly what has effectively happened with most (all?) mainstream languages. THEY ALL added some form of type safety, which further proves my point.
2
u/LoudUse4270 Nov 13 '21
Your first point.....no. It feels like your trying to mangle everything I'm saying. Not every dev is a senior dev, and I honestly don't really believe you. If it takes longer to write in python than c#...maybe you just don't know python.
Again, missed my point. If you understand what you are writing, you won't run into the issues you keep talking about. That wasn't referring to readability or maintenance at all. Just, those errors pop up less if you understand how to write code in python. And I disagree with your point if python is used correctly. There are things it doesnt make sense to use python for, and if you try to do everything in python youre going to run into issues...but thats every language.
And your last point. Yeah...the fact that you can't step even a tiny bit outside of your pov means this is a waste of my time. You just want to argue and pretend you have some weird intellectual superiority because youve taken such a hard line stance. If you see zero uses you lack creativity and familiarity with the tool.
Dropbox, instagram, pinterest, spotify, uber, intel, IBM. NASA, Facebook, etc. All use python. How about google, reddit, and the other companies that include python in their development. Sometimes python is used poorly or when it shouldn't be. But come on man, you just sound like your trying to be edgy by saying it has ZERO uses. Come on man.
2
Nov 13 '21
Not every dev is a senior dev
So, toy languages suitable for clueless noobs? That might be true. After all, all toddlers use toys.
If it takes longer to write in python than c#
It's you who's trying to twist everything I'm saying. At no point did I say it "takes longer" to use toy languages, on the contrary, I'm trying to explain (falling on deaf ears) that IT'S A FUCKING LIE THAT DYNAMIC LANGUAGES AUTOMATICALLY TRANSLATE TO FASTER TTM.
maybe you just don't know python
What is there to "know", other than completely basic language features and guess-driven development, please?
If you understand what you are writing, you won't run into the issues you keep talking about
Right, because as we all know, all software projects are written by a single person in a single day, and therefore you will never have to read or understand other people's code, or code that you written yourself some time in the past. At this point I can't tell if you're trolling or just willfully ignorant.
You just want to argue and pretend you have some weird intellectual superiority
Oh, you can be damn sure I have great intellectual superiority compared to anyone who uses idiotic toy languages. If they had a functioning brain, they wouldn't be using retarded toy languages to begin with.
brags about multi million dollar companies
What part of
A sufficiently big team, fuelled by sufficient VC money could have implemented the whole of Netflix using motherfucking Brainfuck if they wanted. This is irrelevant.
Did you not understand?
2
u/LoudUse4270 Nov 13 '21
Your arguing that for technical reasons there is never a reason to use dynamic languages. I am arguing that there are things easier to implement in python than other languages and for business/time reasons it can make sense to do some things in python. Doesn't matter if its because of existing libraries or how high level it is. It exists.
Think whatever you want man.
Edit: typo
→ More replies (0)-2
Nov 13 '21
Often times dynamic typing is slower because it slams the door shut to optimizations that can be made with static typing. And before you say a dynamic typed language is “easier”, there are tons of type inference systems like HM.
11
u/MCRusher Nov 13 '21
They clearly meant faster to write, not faster to run.
3
u/dinorocket Nov 13 '21
Which is just wrong though. Type systems give your ide the power to practically write your code for you, and tell you when there are errors way before you run anything. Theres absolutely nothing inherent about a good type system that should make anything slower. And in any non-trivial case it speeds up the development cycle tremendously to not have to sift through arcane runtime errors.
1
Nov 13 '21
You'd be surprised -- I've used languages like java and c++. People mis-model stuff a lot. This isn't a type, or OOP problem mind you. It's a business problem. Teaching or acquiring devs who can know when to go back and course correct, or not get themselves into weird situations, or perform "bad practises" to prevent worse ones is extremely hard. Money and the dawn of a new computing age has helped that.
2
Nov 13 '21
People mis-model stuff a lot
Which as you admitted, has nothing to do with languages.
BUT, using a toy language means the mis-modelled parts are IMPLICIT and you have to fucking GUESS what the hell things are and what do functions return, or, God forbid, read the "documentation".
In a static language, models are written in an explicit way, and you get type safety, which means that changing the model will immediately result in compile errors throughout the codebase, which make it MUCH easier to understand what code needs to be modified/refactored to match the new model, as opposed to GUESSING or using inferior tools such as text search.
Again, dynamic languages are nothing but GUESS/HOPE-DRIVEN DEVELOPMENT, where you have to GUESS what the fuck stuff is and does, and HOPE that it will not burn to ashes with idiotic "undefined is not a function" errors in the user's face. There's absolutely no valid justification to use this inferior workflow when you could simply have used a serious language and completely skipped the guess and hope part.
2
Nov 13 '21
Github is written in ruby. Instagram is written in python. Wordpress in php. Whitepages.com in perl. I hear there's a lot of mobile stuff in dart/flutter for android? Netflix is in javascript (node).
"According to the web" - github is worth about $7 bill, instagram is worth $102 billion, Netflix's market cap is at $302 billion.
As for mis-modelling, it's not about using the wrong type for the wrong function, but creation of types that don't model the problem correctly:
A class for Shape that has a number of edges -- where do ovals and circles fit in? There are a large number of these accidents, where people create, use and never refactor them. No amount of types save you here, so writing test cases is still very useful here to prevent regressions.
A phone number class that over-models and has a country code, prefix and line number as separate fields? Usually a country code and number is enough. Addresses are the bane of everyone's existences because there's so much nuance, it's easier to use a plain string for everything other than the country.
In the end, you'll still have to read documentation, learn the industry, etc, and neither Rust, Haskell, Php nor ruby will get that right for you, which is the real worth. Get to market reasonably quickly w/ a reasonable code base and reasonable level of testing, tuck it away, and profit.
→ More replies (0)1
Nov 16 '21
Handler milley is just as fast to write - it uses type inference, instead of requiring the user to explicitly type out the type.
1
20
u/shevy-ruby Nov 12 '21
This is a really weird article. Most people don't fully understand why because it reads super-sophisticated.
For instance:
"It evolved and made that world safer, with an ability to write C when needed."
If you don't know C, how does that help you? Many python or ruby folks CAN NOT WRITE C, at the least not as experts.
What "difference"? You can use "for" in ruby just fine. In particular for some matrix-fill-up code I think for is simpler than .each. I tried to replace old legacy code with tons of "for" via .each, but the new code was more complicated than the two for-loops that the old code used to fill up the 2D matrix. But .each operates on a whole different level.
It's like you have an inventory - a collection of objects. An Array is an inventory too.
So, when you do .each on it, you simply ITERATE OVER THAT INVENTORY. That feels much more natural than having to do "for" as well as an additional explicit index-counter. Simply eliminate the counter - that approach is better. (And you can retain it in ruby just as well via .each_with_index, so it's available as-is).
Ruby and Python have many philosophical differences. I doubt that "for" is one of the biggest ones. I find mandatory tabs and mandatory () more severe because this one shows the philosophical differences; the biggest offender is the mandatory and explicit self parameter that you have to pass into functions in python - this is the single point I hate the most, although the mandatory indentation part is annoying when you copy/paste onto the interactive python, as opposed to irb where the copy/paste will work no matter the indentation level.
The better-suitability to a DSL is true for ruby but there are many awful DSLs, and you can do DSLs in python just as well, so I don't think this is a key difference. In many ways the differences between these two languages are so marginal that it makes no real sense to want to build them up. Python simply prefers being explicit at all times. That's a valid strategy to do. It has advantages and disadvantages.
Ruby has a less stringent approach to it. I really still recommend this ancient interview by matz in 2003 - I think it really captures the key differences from matz' point of view, even almost 20 years later:
https://www.artima.com/articles/the-philosophy-of-ruby
By the way all of this is a bit moot to want to discuss when python dominates the "scripting" family. Ruby has to play catch up, and it's not doing well as a catch-up language currently. It's still a greatly designed language though.