Live data from Hacker News

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

softwaredoug.com

181–190 of 193 posts

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

#181
post #11

I think the article leaves out the main difference in Ruby vs Python. Ruby is built for humans, Python is built for machines. This example used to be illustrated on Ruby on Rail's website. https://rubyonrails.org/doctrine They are philosophical vastly different languages. This isn't to say one is better or worse over the other. Just use the right tool for the job. If I was going to do anything with machine learning o…

Have you ever seen algorithms written as "pseudo code"?

Why do you think they do that?

Answer: To make algorithms easier to understand for other humans.

Python more closely resemble pseudo-code compared to Ruby.

Hence Python is more aligned toward "built for humans" than Ruby.

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

#182

Earlier quoted context omitted.

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

The joke misses the mark because Lisp code usually coalesces all the parentheses in the same line at the end of the block. It does make sense for Ruby, though.

Interestingly enough, this type of response ("Lisp parentheses isn't indented like that") was the most usual type of response.

Apparently joke-killers aren't a new thing :-)

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

#183

The whole premise here IMO is quite flawed. In real Ruby code I almost never use a for-loop. I can't think of a single use base for it. You always use .each or one of the other methods like .map or .select. while loops might get used, but I'm not sure I've ever seen a for loop in Ruby on any of the projects I've worked on with the exception of PRs from people who are brand new to Ruby Edit: much more interesting woul…

Ruby has 'protected' which is not Java-like protected, but implements "another instance can see my internals" semantics. It is useful for methods which take another instance as an argument like binary operators (e.g. `def ===(other)`) where you might need access to both objects internals.

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

#184
post #49

Earlier quoted context omitted.

>* It seems to encourage highly dynamic code where even identifiers are dynamically created, so often you'll find an identifier, and try to search for its definition but get zero results. I've had to take care of 3 large ruby codebases at different companies and this is what kills ruby for me. A lot of ruby programmers think they are being clever when writing crazy dynamic ruby code, but they are only creating techni…

Agreed. As a long time Ruby developer, I smack knuckles every time someone dynamically defines methods. If I can’t find def method or def self.method, your code is not passing my review.

I'll take dynamically defining methods over method_missing

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

#185

Earlier quoted context omitted.

Okay, I'll bite: how much of this is the responsibility of the language designers versus how much of it is the responsibility of the language user? If I had a junior programmer complain to me about this case, I'd simply tell them "you didn't RTFM", because RTFM'ing before you use a language is not only the professional thing to do, but vital to your accurate and correct use of the language. Sure, language designers s…

If a language clearly states in the FM that something "criminal", in the words of your parent comment, is known to be criminal but they leave it as it is without any clear reason behind it (even recognizing it as a past error they have to carry for backward compatibility), the junior has all the right to think the language is criminal and is against them. In the extreme case, take something like brainfuck. Everything…

>Because the key here is that this is not the 1970's anymore, when all guns were complicated.

I take issue with this - computers are far, far more complex now than they were in the 70's, which is why denying the language-users responsibility for fully understanding the language-designers intentions is such a farce.

>If a language requires me to RTFM is at a big disadvantage with any other language that allows me to easily learn by doing.

There are no languages under the sun which do not require some degree of study, and to claim that it should not be so is simply delusional. All language must be learned before it can be properly used - some people learn by making huge mistakes with the language they use, its true, but the productive, professional use of any and all human language requires its study.

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

#186

Earlier quoted context omitted.

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

Thanks for the added information. I'll argue that `Process.exit!` does modify the state of the program in place (which isn't the typical thing one thinks of when thinking of values). Without the bang, it's just a function call that throws an error, which can be caught and handled, so the logical state machine is unchanged. With the bang, it replaces the set of states the current program can be in to a single exit nod…

That's exactly what I meant about the modification of the state in that case not being what you care about. Technically true, actually irrelevant. Mostly.

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

#187
post #170

Earlier quoted context omitted.

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

!-suffixed being dangerous is a rails convention (throws exception). !-suffixed methods are a ruby convention for instance mutation. Calling mutation dangerous isn't a justification for your argument, as there are intrinsic benefits to using those where justified and contained, such as memory savings.

That's simply not true. matz has said this explicitly in the past:

> The bang (!) does not mean “destructive” nor lack of it mean non destructive either. The bang sign means “the bang version is more dangerous than its non bang counterpart; handle with care”. Since Ruby has a lot of “destructive” methods, if bang signs follow your opinion, every Ruby program would be full of bangs, thus ugly.

(from https://www.ruby-forum.com/t/conventions-in-ruby-and-the-pri..., a quote from 2009)

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

#188
post #175
post #14

Earlier quoted context omitted.

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

Why WordPress? I'll take a simple static website over wordpress anytime. With wordpress: - you are now suddenly also a database administrator - the different people touching the admin interface will break things in subtle ways - welcome an incomprehensible security nightmare into your life Yes, wordpress is extremely easy to set up. Maintain? Nope!

In my experience there is absolutely nothing "simple" about a static website, especially one that is going to be used by other people. If it was my personal blog or something, sure. A website for a non-technical friend with a business who wants to be able to post updates, etc? Omg no. No no no no no.

Good managed wordpress starts at like $10-20/month. All those problems you mention go away, you can even do things like rollbacks if someone breaks something. If what you want to do fits into what WP can do pretty well, it's a no-brainer.

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

#189

This is because Ruby inherits it's approach to flow control from Smalltalk, while Python comes from a C/Algol-like heritage. In fact, Smalltalk takes this much further, such that basically all flow control (including if-then-else) is handled as message sends (e.g. if-then is just a message sent to the Boolean object taking a block as it's argument). The downside is the syntax can feel a tad clunky. The upside is incr…

Also, Perl's history adds an additional layer of flavor. Ruby started as somewhat "Perl 2.0" where beauty and flexibility > all things and Python started as "anti-Perl" one way to rule them all(tm) where fast and standard > perfection of beauty.

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

#190
post #38

Earlier quoted context omitted.

Python has a `sorted` function which will return a new sorted list. I agree with you about the general inconsistency though.

Python’s weird mix of OOP but also global methods like `sorted` and `filter` is very weird to me. (Not to mention list comprehensions.) In Ruby, control flow pretty much always moves from left to right as you add successive method calls.

I agree. Python is not consistent, probably because features kept being added. Ruby is a little younger though, so its creator could use lessons learned from its predecessors.
Post reply on HN