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

101–110 of 193 posts

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

#101

Post by wlll »

bhaak wrote: post #56
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.

One of the central arguments for Ruby is that performance is not everything (it was always slow compared to other programming languages) but programmer satisfaction is more important. I'd say Ruby is the programming language I want to program in but Rails pays the bills.

As someone who has worked in Rails performance for quite a long time now I suggest that Rails performance is largely fine. Most Rails performance problems are database and/or architecture issues and not with the language or framework.

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

#102

Post by dosinga »

FWIW the Python implementation of Stuff seems not all that Pythonic. Returning self from __iter__ and keeping state where the iteration is works, but breaks if you over the same object from an iter. To me that really distracts from the argument since the idiomatic implementation in Python and Ruby look almost exactly the same

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

#103

Post by bhaak »

mihaaly wrote: post #74
bhaak wrote: post #62

Earlier quoted context omitted.

Does any of the programming languages Guy Steele worked with do the former and not the latter? Java certainly doesn't: https://godbolt.org/z/b847KeaGv There's a good reason for this. Computer numbers are not the same as numbers in mathematics. Floating point numbers are not real numbers and ints are not natural numbers.

It was not debated that there is no reason some languages behave one way or the other - it is quite the opposite - only that for supporting the pratical use cases - which is the sole purpose of any language, to be useful for practical cases - then it is not a good reason. When one has to jump hoops of the language - being the user for the whims of the language and not the language for the user - that is wasting effor…

Pretty harsh words for an issue that is not really language specific.

Numbers are not as easy as they seem. Computer numbers are not the same as the numbers from mathematics.

Is "0.5" supposed to be a floating point number or a rational data type? What about conversion of types?

Sometimes you just need to know what happens in the particular language you are programming in.

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

#104

Post by sanderjd »

zilti wrote: post #89
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…

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.

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

#105

Post by nordsieck »

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…

> If the creator of Ruby had broadened their horizon, and instead realised that outside the world of experienced software developers, the expression "1/2" means something totally different, maybe they could have chosen a different behaviour.

IMO, that would be a tragedy.

In every language that does it implicit type coercion is the cause of a litany of bugs.

It's the cause of many problems in php. It's why people are told not to use == in javascript.

Maybe it is more difficult for beginners. But people are only beginners for a couple of weeks. It makes no sense to design the language to make those couple of weeks a little better and the rest of their programming lives a lot worse.

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

#106

Post by mgaunard »

Hamuko wrote: post #91
xdennis wrote: post #88

Earlier quoted context omitted.

But it's not. In second grade I was taught that 1/2 is 0 (with a remainder of 1). Fractions, real numbers, complex... are taught afterwards.

I don't think the target audience of Python are second-graders, but rather people who have graduated elementary school and realise that 1/2 comes out to 0.5.

That's silly, in math those two are just different notations for the same thing, and usually fractions are preferred.

Also anyone who's done any bit of programming should know that numbers as represented by a computer are discrete, while mathematics deal with symbolic relations which might require infinite amount of data to numerically represent.

Binary floating-point can't even represent 0.1.

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

#107

Post by mgaunard »

Joker_vD wrote: post #95
mgaunard wrote: post #57

Earlier quoted context omitted.

0 is also the behaviour of C and of pretty much any serious programming language.

I've always suspected that Pascal and Haskell were not serious programming languages, thank you for confirming my suspicion.

Notice how I said most; also I would argue that yes, those aren't really serious programming languages.

Haskell is an academic experiment and is mostly esoteric in the industry. It has however impacted a number of other languages that do get some use.

Pascal is way past its prime and no major company is giving it significant support anymore.

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

#108

Post by Lio »

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…

I respect Guy Steel a lot but this argument is like complaining that

b = 1

doesn't compare b to 1 and return a boolean.

Lots of novice programmer think that's what equals should do based on familiarity with mathematics.

Using = for assignment doesn't help them solve problems either but it's what those with experience of programming generally expect.

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

#109

Post by te_chris »

Asmod4n wrote: post #35
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?

Glimmer is a award winning GUI Toolkit for ruby which supports every major platform (gtk, qt, wxwidgets, swt, swing, java fx, etc), it can also output as SVG or CSS: https://github.com/AndyObtiva/glimmer Glimmer has been around for a while and is in active development. Here is a extensive list about NLP in ruby: https://github.com/arbox/nlp-with-ruby . If you want a fast running and fast starting GUI you should take…

I've been using a few NLP libs in ruby lately and it seems they're mostly all dead - at least the ones I've seen. I feel like everyone gave up and just moved on to python - or deep learning or something else more interesting.

Not saying they don't work, but if you click on a few from that last you'll mostly see last commit >5 years ago - in my experience.

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

#110

Post by kayodelycaon »

xtracto wrote: post #49
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…

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

Post reply on HN