As a long-time Rubyist dipping my toes in the Python world, I find decorators to be my favorite feature so far, and a much nicer way of wrapping functionality than blocks.
Ruby vs. Python comes down to the for loop (2021)
151–160 of 193 posts
Re: Ruby vs. Python comes down to the for loop (2021)
#152The 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…
> Python's are (to be bizarrely) accessible by instances of the same class (like I can use your heart because we are both human?) Have you never used C#, C++, or Java?
Yes.
Unfortunately.
Re: Ruby vs. Python comes down to the for loop (2021)
#153Hmm 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…
Since when does Python have proper static typing? Also, why grep in the age of lsp?
Python type hints with Pylance/pyright are surprisingly good. Not Typescript good, but still pretty decent.
> Also, why grep in the age of lsp?
I'd rather not! But Gitlab doesn't use static type hints so I have no choice.
Re: Ruby vs. Python comes down to the for loop (2021)
#154Earlier quoted context omitted.
The shift towards // vs / also shows great acumen by the Python designers: they tried (and arguably, largely succeeded) in catering to the greater data science/statistics/numerical analysis communities, where 1/2=0.5 is obvious, rather than sticking to the "compsci-obvious" 1/2=0.
Neither is obvious in either community... And this isn't the reason Python succeeded. Nor is this the reason for the particular change. The reason Python succeeded with data-science is NumPy and related group of libraries. They happened to be the first to offer easy access to R-like features of other statistically-flavored languages in an all-purpose language. I.e. it makes it easy to combine general-purpose code wit…
Surely 1/2 = 0.5 is what a statistician would expect? Whereas 1/2 = 0 is what happens in C, C++, Ruby, Java, C#, F#, Rust... Essentially most of the popular programming languages with the exception of Python and JS/Typescript.
Anyway. Maybe my original comment was poorly phrased, but I was not implying that Python succeeded because of this form of catering. Rather, the designers took note of Python becoming popular in that field and made changes (see also the matrix multiplication operator @) that accommodate those users rather than the more "typical" CompSci crowd.
Re: Ruby vs. Python comes down to the for loop (2021)
#155Earlier 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…
But it's not a 1-by-1 mapping. The FOR-loops of FORTRAN, ALGOL, and Pascal have 1-to-1 mapping to the sigma notation because the increment part is either a) omitted entirely and forced to be +1; b) allowed to be some other integer constant, but definitely not an integer expression.
FOR i := 1 TO 10 DO ...
FOR i := 20 STEP -2 UNTIL 0 DO ...
for (i=0, j=10; s[i]; t[j--] = s[i++]); // huh?Re: Ruby vs. Python comes down to the for loop (2021)
#156Earlier quoted context omitted.
> 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…
But it's not a 1-by-1 mapping. The FOR-loops of FORTRAN, ALGOL, and Pascal have 1-to-1 mapping to the sigma notation because the increment part is either a) omitted entirely and forced to be +1; b) allowed to be some other integer constant , but definitely not an integer expression . FOR i := 1 TO 10 DO ... FOR i := 20 STEP -2 UNTIL 0 DO ... for (i=0, j=10; s[i]; t[j--] = s[i++]); // huh?
> for (i=0, j=10; s[i]; t[j--] = s[i++]); // huh?
If you need to mischaracterise and mislead with your examples, you probably don't have a a good argument.
The equivalent C code to your other examples are:
for (i = 1; i = 0; i -= 2) { ... }
Re: Ruby vs. Python comes down to the for loop (2021)
#157Earlier quoted context omitted.
But it's not a 1-by-1 mapping. The FOR-loops of FORTRAN, ALGOL, and Pascal have 1-to-1 mapping to the sigma notation because the increment part is either a) omitted entirely and forced to be +1; b) allowed to be some other integer constant , but definitely not an integer expression . FOR i := 1 TO 10 DO ... FOR i := 20 STEP -2 UNTIL 0 DO ... for (i=0, j=10; s[i]; t[j--] = s[i++]); // huh?
> for (i=0, j=10; s[i]; t[j--] = s[i++]); // huh? If you need to mischaracterise and mislead with your examples, you probably don't have a a good argument. The equivalent C code to your other examples are: for (i = 1; i = 0; i -= 2) { ... } Your argument makes less sense when you write the counter-example out correctly, see?
My argument is that there is no 1:1 mapping: for instance, "for (i=0, j=10; s[i]; t[j--] = s[i++])" has no direct correspondence with sigma notation. Does it? I don't believe so. This code also has no direct correspondence to Pascal's FOR or FORTRAN's DO, or ALGOL's FOR-STEP loops. Hence, C's for loop has no 1:1 mapping to sigma notation.
Of course, I can be mistaken and either there actually is a 1:1 mapping, or you meant by "1:1 mapping" something quite different from what I mean.
Re: Ruby vs. Python comes down to the for loop (2021)
#158Earlier 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…
> so it's kinda hard to complain that it isn't readable
Hum, no, it's very easy.
Almost all of mathematics was created without any care for readability. Mathematicians working with structures that take more than a couple of lines is a very new phenomenon, and the culture of the area didn't even fully adapt yet.
Re: Ruby vs. Python comes down to the for loop (2021)
#159Hmm 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…
> 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 guess the only reason this doesn't happen the same way in Python is because developers are told to repeat "explicit is better than implicit" 100 times before joining the community.
I can't find any single reason why the language would discourage it.
Re: Ruby vs. Python comes down to the for loop (2021)
#160Earlier quoted context omitted.
> If I had to choose though it would be Python for asyncio. I can think of lots of reasons to prefer Python over Ruby, but asyncio in Python compared to Ruby’s async is not at all one of them.
What about it?
“Not an advantage” is sort of the default case; Ruby supports async, too (and, unlike Python, doesn't have function coloring.) So, I don't see why asyncio is an advantage.
I like Python -- I use it more than Ruby -- and asyncio is fine, just, IMO, not an advantage of Python over Ruby.