Earlier quoted context omitted.
The biggest difference between both is mainly their machine learning story but if you don't intend to go in it (this is a very specific career choice), I'd say both are equally good options. I'd say both are pretty bad at performance critical tasks or UI stuff where usually you would use neither of those.
Python is so much bigger than Ruby. It's not just machine learning. There's also numpy and Jupyter for the scientific community, which are huge. There's arcade for making 2D games. There's Micropython for microcontrollers. There are async database drivers and web frameworks. There's interop for many other programming languages, and it's really easy to make a distributable package with Python runtime included. And tha…
Ruby's exceptional creatures
61–70 of 133 posts
Re: Ruby's exceptional creatures
#62It's painful to see method_missing called out as a first class solution in the first creature https://www.exceptionalcreatures.com/bestiary/NoMethodError.... . "Practical Ruby" has three chapters dedicated to method_missing. "define_method" is more common these days and also painful to see. Ruby gets a lot of criticism for embracing magic and indirection ("Ruby, the bad parts of Perl"). It has some good parts (no fun…
Respectfully mostly disagree. Ruby is full of sharp knives. Other languages have dull knives. Writing code without thinking will cut you either way. Things like method missing are exactly the right solution for a certain set of problems. If used thoughtfully, they’re amazing. If used thoughtlessly, bloody mess. But this is true in every language.
Re: Ruby's exceptional creatures
#63Earlier quoted context omitted.
The biggest difference between both is mainly their machine learning story but if you don't intend to go in it (this is a very specific career choice), I'd say both are equally good options. I'd say both are pretty bad at performance critical tasks or UI stuff where usually you would use neither of those.
Python is so much bigger than Ruby. It's not just machine learning. There's also numpy and Jupyter for the scientific community, which are huge. There's arcade for making 2D games. There's Micropython for microcontrollers. There are async database drivers and web frameworks. There's interop for many other programming languages, and it's really easy to make a distributable package with Python runtime included. And tha…
Re: Ruby's exceptional creatures
#64Earlier quoted context omitted.
The biggest difference between both is mainly their machine learning story but if you don't intend to go in it (this is a very specific career choice), I'd say both are equally good options. I'd say both are pretty bad at performance critical tasks or UI stuff where usually you would use neither of those.
Python is so much bigger than Ruby. It's not just machine learning. There's also numpy and Jupyter for the scientific community, which are huge. There's arcade for making 2D games. There's Micropython for microcontrollers. There are async database drivers and web frameworks. There's interop for many other programming languages, and it's really easy to make a distributable package with Python runtime included. And tha…
For games, none of the big engines are python or ruby based and Micropython is more of a Python dialect to me with some partial compatibility, you can't just pip install what you want.
Re: Ruby's exceptional creatures
#65Earlier quoted context omitted.
Respectfully mostly disagree. Ruby is full of sharp knives. Other languages have dull knives. Writing code without thinking will cut you either way. Things like method missing are exactly the right solution for a certain set of problems. If used thoughtfully, they’re amazing. If used thoughtlessly, bloody mess. But this is true in every language.
Calling method_missing a sharp knife is like calling GOTO a sharp knife
Re: Ruby's exceptional creatures
#66It's painful to see method_missing called out as a first class solution in the first creature https://www.exceptionalcreatures.com/bestiary/NoMethodError.... . "Practical Ruby" has three chapters dedicated to method_missing. "define_method" is more common these days and also painful to see. Ruby gets a lot of criticism for embracing magic and indirection ("Ruby, the bad parts of Perl"). It has some good parts (no fun…
Respectfully mostly disagree. Ruby is full of sharp knives. Other languages have dull knives. Writing code without thinking will cut you either way. Things like method missing are exactly the right solution for a certain set of problems. If used thoughtfully, they’re amazing. If used thoughtlessly, bloody mess. But this is true in every language.
Point being: In Ruby, sharp knives are too accessible, come with no warning or even encouragement.
Yet contrary to actual sharp knives (or guns pointed at feet) the feedback loop is slow. When you shoot yourself in the foot, or cut your finger, you feel it right away and (hopefully) adjust before more accidents happen. With Ruby, a footgun is fired today. Or a sharp knife carelessly tossed in the bag yesterday. But you'll feel the pain in months or years only. And probably not even you, but the person who followed your follow up.
Sharp knives are cool. But they need education on their dangers and responsibilities.
Re: Ruby's exceptional creatures
#67Earlier quoted context omitted.
I don't appreciate how it seems like an elaborate ad though: Every error has a link to the paid service they're selling , with the error/exception "Enemies" list as their product
Why so? This is in my book the best form of advertising. It provides anyway something useful for the interested reader, while exposing the (alleged, at least) usefulness of their services. Much better this that a banner or a pop-up in some random website that tracked you down as a Ruby developer.
For a reference, I want something I can trust to give information relevant to my purpose, something that is complete and valid. Not a playful hidden advertisement, funneling me into a single paid solution. Maybe this is why I prefer python, even after working with rails for many years. As I said, I might be a bit dull.
Re: Ruby's exceptional creatures
#68Earlier quoted context omitted.
Antoine de Saint Exupéry once said, 'If you want to build a ship, don't drum up people to collect wood or assign them tasks and work. Instead, teach them to long for the endless immensity of the sea.' This resonates with how I feel about programming languages. Python might be more practical, but does it ignite a passion for coding like Ruby has historically done? I remember dabbling in Python, Perl, and JavaScript (E…
This is more or less personal preference though. When you say that Ruby ignites a passion for coding for you then that might not happen for other people. For example I only feel a headache when I look at Ruby code. For context: I worked with C, C#, some Python and now mostly work in Go.
There are plenty of things I'd like to be different about Ruby and the tooling, but with Ruby I feel like I'm crafting something that at least has the potential for elegance, whereas looking at Python code is like staring at a brutalist building that spews its innards all over its surface.
(and yes, I realise some people love brutalist buildings, and I can too, sometime, when particularly well done, and that's why I chose that example - it's possible to do amazing and elegant things in any language, even - as ugly as I personally find it - Python)
Re: Ruby's exceptional creatures
#69Re: Ruby's exceptional creatures
#70Earlier quoted context omitted.
Better than Python? 15 years ago I would have agreed. Today, Python is a "gateway" to programming that is also the real thing. It's like one of those old languages designed for beginners to learn coding... and then you can continue to use the same language for your entire professional career as a software engineer, to build just about any production-ready application. Ruby is a beautiful language, but unless you are…
I never 'learned' python and ruby is the path I went with and still use for 90% of my own software. However Python is a easy transition. I rarely struggle to do anything with it when I need it. Even Django wasn't to weird to grasp after years of rails. IMO it's not to relevant which language you choose to learn in the beginning of your career. Whatever is more fun or works better for your interests.
Early on you should aim to get exposure to multiple languages, ideally at least some very different ones.
So I agree with whatever is more fun. Anything that makes you want to stick with learning is great. Then you can, and should, explore.
If you want something that'll be a marketable skill right away, maybe Python will be a shortcut in the short term, but a developer who knows only one language - whichever one - is eventually going to be at a disadvantage.
The most important skill is not any specific language, but learning how to think about software.