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

161–170 of 193 posts

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

#161

Post by crabbone »

lou1306 wrote: post #154
crabbone wrote: post #84

Earlier quoted context omitted.

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 i…

My wife's mom is a statistician (and has been since like 70's). She also used to do a lot of programming in the line of her work (working for a telco, and later as biostatistician), in the latest iteration in R, where things are like you expect them to be. But, before then it was also Matlab, where 1 / 2 = 0.

But, none of that is really relevant. Both operations are useful and common in statistics. Which one is more common will depend on your domain.

> the designers took note of Python [...] made changes

That's putting too much faith in designers of Python. Even calling these people "designers" is giving them too much credit. By their own admission they don't have any sort of vision or strategy for how to deal with the language, they just add random stuff and see if a lot of people complain or thank them.

In other words, matrix multiplication operator is there not because there was some kind of intention or design on the part of the small group of people who are responsible for releasing the language, it was more of a "genetic algorithm" kind of thing: change - iterate - see if change optimizes some metric - repeat.

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

#162

Post by crabbone »

Joker_vD wrote: post #93
crabbone wrote: post #79

Earlier quoted context omitted.

> The upside is incredibly simple and consistent language grammar I hope you don't mean Ruby (I haven't investigated Smalltalk grammar). Ruby grammar is atrocious due to string interpolation stuff. Nothing to do with handling loops or conditionals, but still... Ruby is not at all an example of a language with good grammar. Unfortunately, it's surprisingly rare for popular languages to have good grammar. If you look a…

Could you perhaps write a blog post on what you consider bad decisions in a PL grammar? That'd be interesting to read, esp. for all the aspiring PL developers/makers here.

Well... I don't even have a blog.

But, I believe, size is a very good heuristic (i.e. the number of rules, the number of variables in rules, the number of branches in rules).

Another valuable metric to optimize is entropy. I.e. rules that look very similar aren't very good rules.

Expressiveness: how long does the program have to be to capture a useful concept.

Things like these obviously need a lot of counting and coming up with some kinds of constants, hopefully justified by experiments... That's a lot of work that will also require a lot of resources to do. But this is not to say that it is unknowable or that a programmer cannot develop an intuition which allows for rough assessment of language grammar.

So, I'm sorry, I don't have a good answer... I only offer one based on my intuition and limited experience of dealing with various language grammars.

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

#163

Post by lelanthran »

Joker_vD wrote: post #157
lelanthran wrote: post #156

Earlier quoted context omitted.

> 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…

> 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.

And? I didn't claim that all the multi-expression, body-in-the-conditional possibilities are a 1:1 mapping with sigma notation, did I?

Why do you think this is more representative of for loops in C than simpler examples I gave?

> or you meant by "1:1 mapping" something quite different from what I mean.

Well, yes. I meant that the 1:1 mapping is from sigma notation to C, not the other way around, because sigma notation was not invented after the C language.

Maybe I shouldn't have said 1:1 mapping; it's much clearer to say "The `for` loop in C is just a way to write sigma notation in programming languages".

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

#164

Post by lelanthran »

marcosdumay wrote: post #158
lelanthran wrote: post #113

Earlier 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…

> 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.

Sure, but .. we aren't really talking advanced mathematics, here, right? We're looking at an ascii representation of high school maths.

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

#165

Post by igouy »

celdon25 wrote: post #136
pprotas wrote: post #21

Earlier quoted context omitted.

Ruby is only relevant because of Rails, and if those two things are your use-cases then you’ll be better off with Python

Rails is hardly what I would call Ruby’s selling point. Not even the top 5. Unfortunately the ecosystem suffers from rot because it was a language for trend-followers at one point. But it is still a better developer experience than just about everything else I’ve worked with.

So tell us what are top 5 and why.

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

#166

Post by igouy »

stouset wrote: post #118
norman784 wrote: post #45

Earlier quoted context omitted.

I would argue that the main selling point of using Ruby is Rails, for sure there are a lot of things you do in Ruby, but for sure in 2024 there are more performant alternatives.

Performance is worth infinitely less than the sheer developer productivity of Ruby, at least when used by experienced engineers capable of restraint.

So it's the people not the programming language?

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

#167

Post by maleldil »

lelanthran wrote: post #115
self wrote: post #37

Earlier quoted context omitted.

it's a meme (image), so i can't copy it here: https://twitter.com/stylewarning/status/1772795474589987226

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.

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

#168

Post by igouy »

tinco wrote: post #78
kibwen wrote: post #71

Earlier quoted context omitted.

> it's criminal that you can write 1/2 and get values nowhere near one-half This is a foolish argument and Guy Steele should know better. What makes 1/2, which has an accurate floating point representation, any more important than 1/10, which doesn't? Every novice programmer, every single one, trips over floating point, and pretending that floating point numbers match our intuition from mathematics doesn't do anyone…

I don't think his attention was specifically to have 1/2 be a floating point number, like for example Javascript does, but to call to attention the fact that we design programming languages for a specific audience, not realising that if we widened our perspective it could be intuitive for a much wider audience. For example, Ruby was designed for experienced software developers. Experienced software developers expect…

> In a different universe

"Cuis-Smalltalk computes with rational numbers."

https://cuis-smalltalk.github.io/TheCuisBook/Writing-your-fi...

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

#169

Post by ajmurmann »

celdon25 wrote: post #134
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…

> 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?

I have used all of those, but the design decision still doesn't make sense to me. Two instances of the same type might have absolutely nothing to do with each other in my domain.

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

#170

Post by chucke »

regularfry wrote: post #114
harrisi wrote: post #60

Earlier quoted context omitted.

Ruby conventionally separates methods which modify the object from ones that don't by appending an exclamation mark to the method name. So `sort` returns a new sorted list, whereas `sort!` modifies the original list.

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.
Post reply on HN