Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

softwaredoug.com

Post reply on HN
Print view View original

141–150 of 193 posts

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

#141

Post by celdon25 »

resource_waste wrote: post #51
graboid wrote: post #19

Ruby always seems so appealing. Can anybody tell me how the Ruby ecosystem looks like w.r.t. - (Desktop) GUI - Natural language processing I would really like to learn Ruby, but I can only justify the effort if I can use its ecosystems for some private projects, and I often have been burned by languages not offering too much in those two areas. And speed-wise, as I understand, Ruby is the same ball-park as Python?

15 years ago I made the choice between Python and Ruby. Without a doubt, choosing python was the correct move. I can't imagine with the current trajectory, Ruby will be better.

I tried both and Python was an absolute disaster in comparison, but I suppose that depends on what you’re trying to build and who you’re working with.

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

#142

Post by roelschroeven »

ochoseis wrote: post #97
nomilk wrote: post #52

First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values…

FWIW that comparison would’ve been identical in Python 2, where to get floating point division in Python would’ve been: >>> 1//2

1//2 always resulted in an integer, even in Python 2, with or without "from __future__ import division". To get floating point division in Python 2, you had to convert at least on of the operands to float (much like in C or C++).

You can try it online at tio.run, they still have Python 2 among their available languages, as well as Python 3.

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

#143

Post by celdon25 »

IshKebab wrote: post #34

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

> No static typing (I think there is Sorbet but apparently it's not very good and Gitlab doesn't use it).

Sorbet is great, just not with generics yet. And if you use it the LSP will allow for finding references to method calls. If Gitlab doesn’t use it they’re missing out. Maybe they are too busy writing about how great their culture is to worry about such things…

If you don’t want dynamic identifiers, configure rubocop to prohibit it and enforce it through CI builds.

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

#144

Post by thangngoc89 »

zbentley wrote: post #129
ajmurmann wrote: post #123

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's private methods being not accessible by other instances of the same class whereas Python's are (to be bizarrely) accessible by instances of the same class Not sure what you mean here; Python doesn't really have private methods.

Isn’t the double underscores __name would makes the method private?

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

#145

Post by Spivak »

danielheath wrote: post #4

> 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 Once you implement `each`, `include Enumerable` is all it takes to get the full set of collection methods (including `max`/`min` etc, if the entries define ` `).

Surprised that the author is shocked about this. This is what collections.abc is for in Python.

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

#146

Post by celdon25 »

sanderjd wrote: post #104
zilti wrote: post #89

Earlier quoted context omitted.

Since when does Python have proper static typing? Also, why grep in the age of lsp?

Does lsp work well for Ruby? Back when I was writing Ruby (about a decade ago), static analysis tools typically had an even harder time finding things than grep.

It works fairly well if you use Sorbet, which has only been around for a few years.

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

#147

Post by foobarbaz321 »

foobarbaz321 wrote: post #7

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…

[dead]

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

#148

Post by zbentley »

thangngoc89 wrote: post #144
zbentley wrote: post #129

Earlier quoted context omitted.

> Ruby's private methods being not accessible by other instances of the same class whereas Python's are (to be bizarrely) accessible by instances of the same class Not sure what you mean here; Python doesn't really have private methods.

Isn’t the double underscores __name would makes the method private?

No, that trick merely renames ("mangles") the method name: https://docs.python.org/3/reference/expressions.html#atom-id...

This is very rarely used to try to achieve privacy in practice, not least because it's extremely easy to get around.

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

#149

Post by shermantanktop »

lelanthran wrote: post #113
bhaak wrote: post #47

Earlier quoted context omitted.

You don't seem to have any knowledge about the history of programming languages. There have been several lines of PL syntaxes since the 50s. You are crazy if you think that a C style for loop is good designed. It's way to powerful but terse and obtuse to do correctly beyond the simplest application. C style syntax as a whole is also nothing special if you mean semicolons and braces. If you include stupid design decis…

> You are crazy if you think that a C style for loop is good designed. It's way to powerful but terse and obtuse to do correctly beyond the simplest application. I wouldn't go as far as calling someone crazy for thinking C-style for loops are good. The expressions in a C-style for loop is a 1:1 mapping to sigma notation, so is intuitively understood by anyone who has done high school mathematics, even if they didn't…

I read the term “crazy” this way:

“We are having the same ridiculous heated arguments about syntax that programmers have over and over and over so wink I’ll use hyperbolic rhetoric to insult people and wink you shouldn’t take my words to mean very much.”

I find it tiresome. It’s excusable by youth and something that people should grow out of but some never do.

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

#150

Post by lbhdc »

thangngoc89 wrote: post #144
zbentley wrote: post #129

Earlier quoted context omitted.

> Ruby's private methods being not accessible by other instances of the same class whereas Python's are (to be bizarrely) accessible by instances of the same class Not sure what you mean here; Python doesn't really have private methods.

Isn’t the double underscores __name would makes the method private?

The names get mangled, but are still accessible.

    class Foo:
        __bar = 1

    f = Foo()
    assert(f._Foo_bar == 1)
Post reply on HN