12 ms·

You are obviously referring to Python and so I would like to note a few things. (I have nothing against Ruby) > Ruby ... its combined attributes of brevity, ex

You are obviously referring to Python and so I would like to note a few things. (I have nothing against Ruby) > Ruby ... its combined attributes of brevity, expressive power, and feature consistency. > [Python] lacks the elegance and consistency First I would argue Python is very consistent in its design, it aims to only have one obvious way to do things and so it's easy to guess how apis will work. It also aims for explicitness, which makes code very easy to follow and reason about. Secondly on "brevity" and "expressiveness", I don't really see them as an attribute that make a language "better". Sure for experienced developers who like a personal game of code golf (don't we all at times!) those are attributes can can make coding more "fun". But that doesn't necessarily translate to code that is ideal when working as part of a team, or code that is easy to follow when a new developer starts on an existing codebase. Ultimately I think that's why Python has gained more traction than Ruby, it's an "easer" language to follow and start with. Ruby is probably a more fun and intellectually stimulating language to work with though.

Mikeb85 4y ago
Python gained traction because of Google (Google used it initially then Guido worked for them for a decade+, vs. Matz at Heroku/salesforce) and then because it's the easiest way to use ML libs. That's it. It's slower than Ruby, has worse package management and less consistent syntax but if you want to use Tensorflow, PyTorch, etc..., it's the default.
- yla92 4y ago
  > It's slower than Ruby. Any reference/numbers to back this up ? Just genuinely curious about this.
  - Mikeb85 4y ago
    Basically any benchmark that uses just the language. Throw some loops and maths in there. It doesn't really matter though, both languages are used typically for scripting. But just shows it's not really about the "language", it's about the ecosystem.
  - j_mo 4y ago
    In all the language comparisons I've found over the years, Python consistently comes out slightly slower, for example: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks Bearing in mind these are probably not even using YJIT, which makes Ruby considerably faster in some scenarios.
    - yxhuvud 4y ago
      Ruby used to be slower though, during the 1.8.7 times. But that was a long time ago now.
  - deleted 4y ago
    [deleted]
- mypalmike 4y ago
  Revisionist history. Python was huge before Google even existed.
  - mtrower 4y ago
    ...for some value of "huge" that others might take issue with. From my perspective, python was just starting to gain real popularity in the mid 2000s, more than half a decade after Google was founded...
  - dagw 4y ago
    Python was huge before Google even existed. I first started using Python slightly after that time and for years it was a pretty niche language that relatively few people used, especially compared to the other 'P' languages, Perl and PHP. I'd estimate 2001-2002 as when it would say it started to become a 'normal' language and I wouldn't say it really started taking off until around 2005ish.
  - Mikeb85 4y ago
    ??? Python was huge in the 90's? News to me. No one I knew knew about it until like 2010.
    - programmer_dude 4y ago
      LOL, you and your friends have been living under a rock. I have been using Python since (at most) 2002.
      - Mikeb85 4y ago
        > I have been using Python since (at most) 2002. So 4 years after Google. Which made my point to the parent. And apparently everyone's been living under a rock because Python didn't become truly huge until maybe 10 years ago.
        programmer_dude 4y ago
        I did not start using python because it was adopted by Google. It was / is useful with or without Google.
- samwillis 4y ago
  That's a fairly Silicone Valley focused argument. I don't subscribe to the theory at all that Google closed internal use of Python was instrumental in its adoption. Django was released in 2005 and RoR in 2004. I suspect my journey was similar around then (late 2005), I had used PHP, classic ASP and a little Perl. I was looking for something better, read the tutorials for both Django and RoR. Had a look at what desktop GUI toolkits were available for both Ruby and Python (I wanted to lean one new language), Python had a few more options and so went with Python and Django. At the same time Python was gaining significant traction in the scientific community with NumPy (2006/1995) and SciPy (2001). Ruby I don't believe had an answer to that back then. I was vaguely aware of that and it somewhat influenced my decision. Ultimately it was the two pronged (web + scientific) development of the ecosystem that pushed Python ahead of Ruby.
  - piva00 4y ago
    Had a similar journey, started with ASP in the 2000s, then PHP around 2003, then worked with both RoR and Django professionally for a few years. As much as I liked RoR for its scaffolding and easiness of bootstrapping new CRUD projects, over time with larger codebases and teams it just starts to be a mess. Ruby programmers love the terseness of the language and write some of the most ungrokable code I've encountered (second only to some Scala codebases I worked with). That and the magic of autoloading modules which then could introduce a DSL, the usage of mixins that are hard to trace where they are loaded from, and a lot of other magic features that are extremely opaque to parse through and debug is, ultimately, what made me abandon Ruby and RoR. It has its uses but I've yet to see a decent legacy RoR codebase without these pitfalls of magic, after so many years professionally working with code I prefer any language environment that is explicit, Ruby is not explicit.
    - nuker 4y ago
      > most ungrokable code I've encountered (second only to some Scala Perl!
  - satvikpendem 4y ago
    > Silicone Valley I think Silicone Valley is, uh, another type of valley.
- pjmlp 4y ago
  Python was already in the gold path years before Rails, thanks to Zope, being an alternative to Perl, and research labs like CERN and Fermilab starting to adopt it, this is back in 2000 - 2004. When Ruby and Rails started to make an appearance in European circles, around 2007, it hardly mattered when Python was already around.
- wiseowise 4y ago
  > It's slower than Ruby That’s like saying that Dodge Neon is Slower than Mazda Miata. Both are bottom of the barrel compared to any compiled language.
  - Mikeb85 4y ago
    > Both are bottom of the barrel compared to any compiled language. Scripting languages and compiled languages are used for different things. And you're right, both are slow as hell and speed doesn't really matter for scripting, but when all else is equal, it matters, a lil...
    - FpUser 4y ago
      JavaScript is a scripting language but wipes the floor with either (like 25 and more times faster) and can be used to actually do something other than being a glue.
      - Mikeb85 4y ago
        JS was slow before V8. Also TruffleRuby brings Ruby very close to V8 speeds. I just didn't consider that because it's not really a drop-in CRuby replacement. Also JS is still too slow for most things compiled languages are used for.
  - cpursley 4y ago
    A Miata will smoke a Neon in the corners and is just more pleasant to drive. Miatas are the number one hobby motorsport (racing) vehicles of choice for a reason. Which is actually a great analogy for Ruby vs Python!
    - wiseowise 4y ago
      > Which is actually a great analogy for Ruby vs Python! I know. :^) Both are shit compared to better cars, though.
MartinMond 4y ago
When I looked at Python vs Ruby many years ago, I found the opposite: Why does Python have (special) functions like len() and map(), instead of 'properly' supporting both OOP (len should just be a method on objects) and/or FP (support multi-line lambdas so I can actually use map/filter etc). I never understood how this can be considered consistent at all, and those IMHO language design warts made me look into Ruby at the time. Has this improved since? I know print was changed in Python3 to make it not-special.
- duckerude 4y ago
  map() and filter() being functions means you can run them on any object that implements __iter__(). To make them methods they'd have to be added to each individual type that might want to use them. IIRC Ruby does that using mixins but that takes up a lot of room in the namespace of each type and makes it a little harder to figure out where the methods come from. The justification for len() is thinner: Guido van Rossum thinks it looks better, and it enforces a consistent name with a consistent meaning (you don't get length methods with different names, or with the right name but strange behavior). Under the hood it just calls obj.__len__(), so it's only the notation that's not OOP. There are no multi-line lambdas because nobody could come up with an indentation-based syntax for them that Guido van Rossum was happy with. In short: none of them improved, all of them have reasons, some of those reasons are bad.
- aidos 4y ago
  Those functions take any object that supports the iteration protocol. There’s no need for adding say, len, to every object that needs a len function. I’d argue that is consistent. Sure, multi line lambdas might be nice, but equally you can define functions wherever you need them so it’s not really all that different.
  - ajanuary 4y ago
    > There’s no need for adding say, len, to every object that needs a len function. fwiw, Ruby does the same thing, but using the Enumerable mixin rather than a free floating function. > I’d argue that is consistent. I don’t understand this argument. It’s convenient and more efficient to write, yes. But how is it more consistent to have two different calling conventions? The claim that there’s one way to do something irks me as well. There’s one way to find the length of something, but that introduces two ways of querying an object. It’s a good guiding principle, but when people use it to make stronger claims, it ends up superficial.
revskill 4y ago
I think the elegance here is "lacking" of parenthese in function call. Also block. Ruby code has no parenthese.
- Y_Y 4y ago
  What are parenthose?
- Alifatisk 4y ago
  Ruby has paranthese, but it’s optional
arnvald 4y ago
I explored this topic a while ago on my blog [0] In essence, I don't think it has anything to do with elegance, syntax, or "easiness". It's more about timing + origin + corporate adoption: * Python was created in Europe, Ruby was created in Japan - when Ruby gained more recognition in English-speaking world (~2004), Python has already been present and used worldwide for a decade * Ruby was created as a personal, hobby project; Python was created while Guido worked in research institutions, and it helped Python gain recognition in academia environment * Guido joined Google in 2005, boosting the adoption of Python; Ruby has never gained such a large corporate backing Eventually I believe it was the combination of the latter 2 that pushed Python to top spot in popularity - scientists all over the world were familiar with Python, and with the rise of Data Science/ML (with Google being one of the main forces behind it), it became the most obvious choice for the new tools. [0] https://www.notonlycode.org/why-python-has-won/ https://www.notonlycode.org/why-python-has-won/
- skywal_l 4y ago
  > * Ruby was created as a personal, hobby project; Python was created while Guido worked in research institutions, and it helped Python gain recognition in academia environment As a data point, I remember interviewing for an internship in a research institution doing some work on medical images around 2002/2003 and the supervisor telling me that Python was the lingua franca in this domain (from a research and POC development perspective).
  - pjmlp 4y ago
    While I was at CERN during early 2000's, it was already being used for the build tooling and package management of HLT. Trainings for getting Python skills were a common offering.
    - 4m1rk 4y ago
      These explain why Python is the defacto for AI/ML which is interesting but I still totally agree with the idea of Python's simplicity making it just a better choice to get things done. I had a journey from Scala, a compile-time type-safe, flexible and exciting language to Python a dynamic, simple and boring one. Python code just end up being done fast and clean. Scala one never gets the team consensus and is never consistent.
MattPalmer1086 4y ago
Certainly that was the case for me. Way back I was wondering what language to learn next. It came down to Ruby or Python. Python was just clear to read. Ruby looked a bit cleverer but was not so simple. Coming from working on a large C++ code base, I decided Python was the one to do next. Simplicity, clarity and one obvious way to do things as a philosophy.
sergioisidoro 4y ago
As someone who loves both Python and Ruby, and uses them both daily, I really though they were referring to JavaScript (with node/deno et all).
- deleted 4y ago
  [deleted]
xigoi 4y ago
One aspect in which Ruby is much more consistent than Python: sorted(arr) arr.sort() versus arr.sort arr.sort!
- samwillis 4y ago
  Personally I think the Python syntax make its more explicit which is an in-place sort vs returning a sorted copy. And also what's a method call vs an attribute access. Someone new to Ruby will be WTF is the ! for?
  - xigoi 4y ago
    How does having a function instead of a method indicate that it's out-of-place? Every Ruby tutorial explains that an exclamation mark means in-place, and this convention is consistent across Ruby libraries, unlike Python.
    - aidos 4y ago
      It's a convention, quite a nice one, but not all libraries are consistent and it does have different meanings too (! is sometimes used for "raise an error instead of returning a boolean"). In the Python case, `list.sort()` operates on the object, so you can kind of expect it to do mutation (but there's no convention / guarantee). Though it only makes sense as a function that the list object itself implements. `sorted` is a general function that gives you a sorted list from any iterable, and because working with iterables is such a common thing in software, Python has a bunch of standard functions like that. It's nice because you learn them once and they apply absolutely everywhere. Ultimately you learn the behaviours of a language and they become second nature. I find both Ruby and Python very clean and easy to read.
      - peoplefromibiza 4y ago
        > it does have different meanings too the meaning is the same high level: it has side effects, being it a destructive update, an in place operation or throwing an exception. > `sorted` is a general function that gives you a sorted list from any iterable iterable in Python is a very loose concept though. And it's not very consistent too sorted("gheliabciou") ['a', 'b', 'c', 'e', 'g', 'h', 'i', 'i', 'l', 'o', 'u'] you give it a str it returns a list of char in Ruby it makes much more sense "gheliabciou".chars.sort.join "abceghiilou" You take out the chars from the string, sort them and then join them together again because a string cannot be sorted, sorting a string makes no sense, you sort the chars composing it. Also, Python could not do this for many years, while Ruby could no prob sorted("gheliabciouß⌚⌨⌛🆔🉑🈶🈚🈸🈺🈷🆚🉐㊙㊗🈴") edit: Python also shows some very counterintuitive semantic take the example above, to return a string you use ''.join(sorted("gheliabciou")) 'abceghiilouß' which is probably the last thing someone would think of. sorting a list does not produce any output, because sort is _always_ in place, so you have to waste a variable to sort a list because you can't sort it inline list("fedcba") ['f', 'e', 'd', 'c', 'b', 'a'] print(list("fedcba").sort()) None # <-- where did the list go? # you have to do l = list("fedcba") l.sort() print(l) ['a', 'b', 'c', 'd', 'e', 'f'] again, highly unexpected my favourite print([c for c in "bca"].sort()) None # <- WTF? list comprehension is a functional concept! # this is how you "intuitively" do it print(''.join(sorted([c for c in "cba"]))) abc
jbergens 4y ago
> Ultimately I think that's why Python has gained more traction than Ruby, it's an "easer" language to follow and start with I don't know enough Python to say anything about how easy it is but Python existed for a decade or so before it became popular and that was after Ruby had became popular. That points to it not being popular because it is easy but for some other reason. My guess is BI and AI made Python popular.
wbkang 4y ago
I also explored why Ruby is so hard to learn for people like me on my blog [1]. I totally agree with you. I had to use Ruby at work and I really struggled to grok it. I've picked up many programming languages in my career but Ruby was one of the hardest to really understand. [1] https://wbk.one/article/a463c360/the-ruby-tutorial-i-wish-i-had https://wbk.one/article/a463c360/the-ruby-tutorial-i-wish-i-...
- czbond 4y ago
  To me, Python felt like R. Designed by an academic - possibly without computer science knowledge. In a manner where humans bow to how a computer does things. Whereas a similar language of the time, C++ was a more properly designed language. Ruby more like a philosophy major designing an OOP language - getting done and enjoying getting there were the goals. I took to Ruby more because i never cared about the "engineering" part of languages - just using them as tools to get things done.
SSLy 4y ago
> I would argue Python is very consistent in its design, it aims to only have one obvious way to do things This argument is dead the second one stumbles upon the string interpolation/formatting situation. Or the list comprehensions, ew.
- justin_oaks 4y ago
  For the benefit of those not familiar with the Python string interpolation/formatting situation, I present 4 ways to perform the same string formatting: who='World' #1 - string concatenation 'Hello, ' + who + '!' #2 - % operator 'Hello, %s!' % who #3 - format() method 'Hello, {}!'.format(who) #4 - f-strings f'Hello, {who}!'
  - jonnytran 4y ago
    Don't forget all the variations on how to use the format() method. # In order 'Hello, {}!'.format(who) # Numbered 'Hello, {0}!'.format(who) # Named 'Hello, {name}!'.format(name = who)
x98asfd 4y ago
> Ultimately I think that's why Python has gained more traction than Ruby, it's an "easer" language to follow and start with. Ruby is probably a more fun and intellectually stimulating language to work with though. May be now, but for a long time when RoR first came out, many people pick python instead of Ruby because scalability. Maybe a lot has improved with Ruby, and with introduction of Crystal, that may not be an issue any more.
latexr 4y ago
> it aims to only have one obvious way to do things and so it's easy to guess how apis will work. I’ve seen that statement multiple times, but in my experience it’s far from the truth. For every thing I ever had to look up in Python I often found more than one way of accomplishing the same task and all of them were (subjectively) uglier and less straightforward than Ruby. > on "brevity" and "expressiveness", I don't really see them as an attribute that make a language "better". Sure for experienced developers It’s an attribute including for inexperienced developers. Perhaps especially for them. Even for something as basic¹ as writing a file, one needs multiple lines of code and know about `with` or opening and closing the file². In Ruby: `File.write("/path/to/write.txt", "file contents")`. One line, immediately understandable. > that doesn't necessarily translate to code that is ideal when working as part of a team, or code that is easy to follow when a new developer starts on an existing codebase. Agreed. Though in Ruby I have found myself thinking “I wonder if this keyword will work” and it does exactly what I expected. With Python, the norm is frustration with the impossibility of doing the simplest of things like defining a constant. ¹ From the coder’s point of view, never mind the underlying implementation. ² Failing the goal of one and only one obvious way to do something.
ilyt 4y ago
> Ultimately I think that's why Python has gained more traction than Ruby, it's an "easer" language to follow and start with. Ruby is probably a more fun and intellectually stimulating language to work with though. Working with various Ruby-adjacent stuff for 10+ years and nothing about Ruby was even "fun" to work with, it was mix of "WTF" and "who designs language like that!". Python is also not "easier" to start with, I'd put Ruby/JS/Python to be at pretty similar level there. No worrying much about types (till they bite you, inevitably, of course, and cause untold bugs), simple things are simple and actual proper (i.e. "not send it to some piece of C code to calculate) multithreading sucks donkey balls.
- gorjusborg 4y ago
  (Years ago) Ruby made a lot of sense to me coming from Perl, and I'd bet that Perl-inspiration might explain many of the WTF language design choices.
BurningFrog 4y ago
Ruby is typically brief and clear. I work in Python now, and I often have to use 5-7 lines for what would have been 2-4 in Ruby. Because you have to clutter the Python with trivial details, not because the Ruby code is "magic".

Mikeb85 4y ago

Python gained traction because of Google (Google used it initially then Guido worked for them for a decade+, vs. Matz at Heroku/salesforce) and then because it's the easiest way to use ML libs. That's it. It's slower than Ruby, has worse package management and less consistent syntax but if you want to use Tensorflow, PyTorch, etc..., it's the default.

yla92 4y ago
> It's slower than Ruby. Any reference/numbers to back this up ? Just genuinely curious about this.
- Mikeb85 4y ago
  Basically any benchmark that uses just the language. Throw some loops and maths in there. It doesn't really matter though, both languages are used typically for scripting. But just shows it's not really about the "language", it's about the ecosystem.
- j_mo 4y ago
  In all the language comparisons I've found over the years, Python consistently comes out slightly slower, for example: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks Bearing in mind these are probably not even using YJIT, which makes Ruby considerably faster in some scenarios.
  - yxhuvud 4y ago
    Ruby used to be slower though, during the 1.8.7 times. But that was a long time ago now.
- deleted 4y ago
  [deleted]
mypalmike 4y ago
Revisionist history. Python was huge before Google even existed.
- mtrower 4y ago
  ...for some value of "huge" that others might take issue with. From my perspective, python was just starting to gain real popularity in the mid 2000s, more than half a decade after Google was founded...
- dagw 4y ago
  Python was huge before Google even existed. I first started using Python slightly after that time and for years it was a pretty niche language that relatively few people used, especially compared to the other 'P' languages, Perl and PHP. I'd estimate 2001-2002 as when it would say it started to become a 'normal' language and I wouldn't say it really started taking off until around 2005ish.
- Mikeb85 4y ago
  ??? Python was huge in the 90's? News to me. No one I knew knew about it until like 2010.
  - programmer_dude 4y ago
    LOL, you and your friends have been living under a rock. I have been using Python since (at most) 2002.
    - Mikeb85 4y ago
      > I have been using Python since (at most) 2002. So 4 years after Google. Which made my point to the parent. And apparently everyone's been living under a rock because Python didn't become truly huge until maybe 10 years ago.
      - programmer_dude 4y ago
        I did not start using python because it was adopted by Google. It was / is useful with or without Google.
samwillis 4y ago
That's a fairly Silicone Valley focused argument. I don't subscribe to the theory at all that Google closed internal use of Python was instrumental in its adoption. Django was released in 2005 and RoR in 2004. I suspect my journey was similar around then (late 2005), I had used PHP, classic ASP and a little Perl. I was looking for something better, read the tutorials for both Django and RoR. Had a look at what desktop GUI toolkits were available for both Ruby and Python (I wanted to lean one new language), Python had a few more options and so went with Python and Django. At the same time Python was gaining significant traction in the scientific community with NumPy (2006/1995) and SciPy (2001). Ruby I don't believe had an answer to that back then. I was vaguely aware of that and it somewhat influenced my decision. Ultimately it was the two pronged (web + scientific) development of the ecosystem that pushed Python ahead of Ruby.
- piva00 4y ago
  Had a similar journey, started with ASP in the 2000s, then PHP around 2003, then worked with both RoR and Django professionally for a few years. As much as I liked RoR for its scaffolding and easiness of bootstrapping new CRUD projects, over time with larger codebases and teams it just starts to be a mess. Ruby programmers love the terseness of the language and write some of the most ungrokable code I've encountered (second only to some Scala codebases I worked with). That and the magic of autoloading modules which then could introduce a DSL, the usage of mixins that are hard to trace where they are loaded from, and a lot of other magic features that are extremely opaque to parse through and debug is, ultimately, what made me abandon Ruby and RoR. It has its uses but I've yet to see a decent legacy RoR codebase without these pitfalls of magic, after so many years professionally working with code I prefer any language environment that is explicit, Ruby is not explicit.
  - nuker 4y ago
    > most ungrokable code I've encountered (second only to some Scala Perl!
- satvikpendem 4y ago
  > Silicone Valley I think Silicone Valley is, uh, another type of valley.
pjmlp 4y ago
Python was already in the gold path years before Rails, thanks to Zope, being an alternative to Perl, and research labs like CERN and Fermilab starting to adopt it, this is back in 2000 - 2004. When Ruby and Rails started to make an appearance in European circles, around 2007, it hardly mattered when Python was already around.
wiseowise 4y ago
> It's slower than Ruby That’s like saying that Dodge Neon is Slower than Mazda Miata. Both are bottom of the barrel compared to any compiled language.
- Mikeb85 4y ago
  > Both are bottom of the barrel compared to any compiled language. Scripting languages and compiled languages are used for different things. And you're right, both are slow as hell and speed doesn't really matter for scripting, but when all else is equal, it matters, a lil...
  - FpUser 4y ago
    JavaScript is a scripting language but wipes the floor with either (like 25 and more times faster) and can be used to actually do something other than being a glue.
    - Mikeb85 4y ago
      JS was slow before V8. Also TruffleRuby brings Ruby very close to V8 speeds. I just didn't consider that because it's not really a drop-in CRuby replacement. Also JS is still too slow for most things compiled languages are used for.
- cpursley 4y ago
  A Miata will smoke a Neon in the corners and is just more pleasant to drive. Miatas are the number one hobby motorsport (racing) vehicles of choice for a reason. Which is actually a great analogy for Ruby vs Python!
  - wiseowise 4y ago
    > Which is actually a great analogy for Ruby vs Python! I know. :^) Both are shit compared to better cars, though.

MartinMond 4y ago

When I looked at Python vs Ruby many years ago, I found the opposite: Why does Python have (special) functions like len() and map(), instead of 'properly' supporting both OOP (len should just be a method on objects) and/or FP (support multi-line lambdas so I can actually use map/filter etc). I never understood how this can be considered consistent at all, and those IMHO language design warts made me look into Ruby at the time. Has this improved since? I know print was changed in Python3 to make it not-special.

duckerude 4y ago
map() and filter() being functions means you can run them on any object that implements __iter__(). To make them methods they'd have to be added to each individual type that might want to use them. IIRC Ruby does that using mixins but that takes up a lot of room in the namespace of each type and makes it a little harder to figure out where the methods come from. The justification for len() is thinner: Guido van Rossum thinks it looks better, and it enforces a consistent name with a consistent meaning (you don't get length methods with different names, or with the right name but strange behavior). Under the hood it just calls obj.__len__(), so it's only the notation that's not OOP. There are no multi-line lambdas because nobody could come up with an indentation-based syntax for them that Guido van Rossum was happy with. In short: none of them improved, all of them have reasons, some of those reasons are bad.
aidos 4y ago
Those functions take any object that supports the iteration protocol. There’s no need for adding say, len, to every object that needs a len function. I’d argue that is consistent. Sure, multi line lambdas might be nice, but equally you can define functions wherever you need them so it’s not really all that different.
- ajanuary 4y ago
  > There’s no need for adding say, len, to every object that needs a len function. fwiw, Ruby does the same thing, but using the Enumerable mixin rather than a free floating function. > I’d argue that is consistent. I don’t understand this argument. It’s convenient and more efficient to write, yes. But how is it more consistent to have two different calling conventions? The claim that there’s one way to do something irks me as well. There’s one way to find the length of something, but that introduces two ways of querying an object. It’s a good guiding principle, but when people use it to make stronger claims, it ends up superficial.

revskill 4y ago

I think the elegance here is "lacking" of parenthese in function call. Also block. Ruby code has no parenthese.

Y_Y 4y ago
What are parenthose?
Alifatisk 4y ago
Ruby has paranthese, but it’s optional

arnvald 4y ago

I explored this topic a while ago on my blog [0] In essence, I don't think it has anything to do with elegance, syntax, or "easiness". It's more about timing + origin + corporate adoption: * Python was created in Europe, Ruby was created in Japan - when Ruby gained more recognition in English-speaking world (~2004), Python has already been present and used worldwide for a decade * Ruby was created as a personal, hobby project; Python was created while Guido worked in research institutions, and it helped Python gain recognition in academia environment * Guido joined Google in 2005, boosting the adoption of Python; Ruby has never gained such a large corporate backing Eventually I believe it was the combination of the latter 2 that pushed Python to top spot in popularity - scientists all over the world were familiar with Python, and with the rise of Data Science/ML (with Google being one of the main forces behind it), it became the most obvious choice for the new tools. [0] https://www.notonlycode.org/why-python-has-won/ https://www.notonlycode.org/why-python-has-won/

skywal_l 4y ago
> * Ruby was created as a personal, hobby project; Python was created while Guido worked in research institutions, and it helped Python gain recognition in academia environment As a data point, I remember interviewing for an internship in a research institution doing some work on medical images around 2002/2003 and the supervisor telling me that Python was the lingua franca in this domain (from a research and POC development perspective).
- pjmlp 4y ago
  While I was at CERN during early 2000's, it was already being used for the build tooling and package management of HLT. Trainings for getting Python skills were a common offering.
  - 4m1rk 4y ago
    These explain why Python is the defacto for AI/ML which is interesting but I still totally agree with the idea of Python's simplicity making it just a better choice to get things done. I had a journey from Scala, a compile-time type-safe, flexible and exciting language to Python a dynamic, simple and boring one. Python code just end up being done fast and clean. Scala one never gets the team consensus and is never consistent.

MattPalmer1086 4y ago

Certainly that was the case for me. Way back I was wondering what language to learn next. It came down to Ruby or Python. Python was just clear to read. Ruby looked a bit cleverer but was not so simple. Coming from working on a large C++ code base, I decided Python was the one to do next. Simplicity, clarity and one obvious way to do things as a philosophy.

sergioisidoro 4y ago

As someone who loves both Python and Ruby, and uses them both daily, I really though they were referring to JavaScript (with node/deno et all).

deleted 4y ago
[deleted]

xigoi 4y ago

One aspect in which Ruby is much more consistent than Python: sorted(arr) arr.sort() versus arr.sort arr.sort!

samwillis 4y ago
Personally I think the Python syntax make its more explicit which is an in-place sort vs returning a sorted copy. And also what's a method call vs an attribute access. Someone new to Ruby will be WTF is the ! for?
- xigoi 4y ago
  How does having a function instead of a method indicate that it's out-of-place? Every Ruby tutorial explains that an exclamation mark means in-place, and this convention is consistent across Ruby libraries, unlike Python.
  - aidos 4y ago
    It's a convention, quite a nice one, but not all libraries are consistent and it does have different meanings too (! is sometimes used for "raise an error instead of returning a boolean"). In the Python case, `list.sort()` operates on the object, so you can kind of expect it to do mutation (but there's no convention / guarantee). Though it only makes sense as a function that the list object itself implements. `sorted` is a general function that gives you a sorted list from any iterable, and because working with iterables is such a common thing in software, Python has a bunch of standard functions like that. It's nice because you learn them once and they apply absolutely everywhere. Ultimately you learn the behaviours of a language and they become second nature. I find both Ruby and Python very clean and easy to read.
    - peoplefromibiza 4y ago
      > it does have different meanings too the meaning is the same high level: it has side effects, being it a destructive update, an in place operation or throwing an exception. > `sorted` is a general function that gives you a sorted list from any iterable iterable in Python is a very loose concept though. And it's not very consistent too sorted("gheliabciou") ['a', 'b', 'c', 'e', 'g', 'h', 'i', 'i', 'l', 'o', 'u'] you give it a str it returns a list of char in Ruby it makes much more sense "gheliabciou".chars.sort.join "abceghiilou" You take out the chars from the string, sort them and then join them together again because a string cannot be sorted, sorting a string makes no sense, you sort the chars composing it. Also, Python could not do this for many years, while Ruby could no prob sorted("gheliabciouß⌚⌨⌛🆔🉑🈶🈚🈸🈺🈷🆚🉐㊙㊗🈴") edit: Python also shows some very counterintuitive semantic take the example above, to return a string you use ''.join(sorted("gheliabciou")) 'abceghiilouß' which is probably the last thing someone would think of. sorting a list does not produce any output, because sort is _always_ in place, so you have to waste a variable to sort a list because you can't sort it inline list("fedcba") ['f', 'e', 'd', 'c', 'b', 'a'] print(list("fedcba").sort()) None # <-- where did the list go? # you have to do l = list("fedcba") l.sort() print(l) ['a', 'b', 'c', 'd', 'e', 'f'] again, highly unexpected my favourite print([c for c in "bca"].sort()) None # <- WTF? list comprehension is a functional concept! # this is how you "intuitively" do it print(''.join(sorted([c for c in "cba"]))) abc

jbergens 4y ago

> Ultimately I think that's why Python has gained more traction than Ruby, it's an "easer" language to follow and start with I don't know enough Python to say anything about how easy it is but Python existed for a decade or so before it became popular and that was after Ruby had became popular. That points to it not being popular because it is easy but for some other reason. My guess is BI and AI made Python popular.

wbkang 4y ago

I also explored why Ruby is so hard to learn for people like me on my blog [1]. I totally agree with you. I had to use Ruby at work and I really struggled to grok it. I've picked up many programming languages in my career but Ruby was one of the hardest to really understand. [1] https://wbk.one/article/a463c360/the-ruby-tutorial-i-wish-i-had https://wbk.one/article/a463c360/the-ruby-tutorial-i-wish-i-...

czbond 4y ago
To me, Python felt like R. Designed by an academic - possibly without computer science knowledge. In a manner where humans bow to how a computer does things. Whereas a similar language of the time, C++ was a more properly designed language. Ruby more like a philosophy major designing an OOP language - getting done and enjoying getting there were the goals. I took to Ruby more because i never cared about the "engineering" part of languages - just using them as tools to get things done.

SSLy 4y ago

> I would argue Python is very consistent in its design, it aims to only have one obvious way to do things This argument is dead the second one stumbles upon the string interpolation/formatting situation. Or the list comprehensions, ew.

justin_oaks 4y ago
For the benefit of those not familiar with the Python string interpolation/formatting situation, I present 4 ways to perform the same string formatting: who='World' #1 - string concatenation 'Hello, ' + who + '!' #2 - % operator 'Hello, %s!' % who #3 - format() method 'Hello, {}!'.format(who) #4 - f-strings f'Hello, {who}!'
- jonnytran 4y ago
  Don't forget all the variations on how to use the format() method. # In order 'Hello, {}!'.format(who) # Numbered 'Hello, {0}!'.format(who) # Named 'Hello, {name}!'.format(name = who)

x98asfd 4y ago

> Ultimately I think that's why Python has gained more traction than Ruby, it's an "easer" language to follow and start with. Ruby is probably a more fun and intellectually stimulating language to work with though. May be now, but for a long time when RoR first came out, many people pick python instead of Ruby because scalability. Maybe a lot has improved with Ruby, and with introduction of Crystal, that may not be an issue any more.

latexr 4y ago

> it aims to only have one obvious way to do things and so it's easy to guess how apis will work. I’ve seen that statement multiple times, but in my experience it’s far from the truth. For every thing I ever had to look up in Python I often found more than one way of accomplishing the same task and all of them were (subjectively) uglier and less straightforward than Ruby. > on "brevity" and "expressiveness", I don't really see them as an attribute that make a language "better". Sure for experienced developers It’s an attribute including for inexperienced developers. Perhaps especially for them. Even for something as basic¹ as writing a file, one needs multiple lines of code and know about `with` or opening and closing the file². In Ruby: `File.write("/path/to/write.txt", "file contents")`. One line, immediately understandable. > that doesn't necessarily translate to code that is ideal when working as part of a team, or code that is easy to follow when a new developer starts on an existing codebase. Agreed. Though in Ruby I have found myself thinking “I wonder if this keyword will work” and it does exactly what I expected. With Python, the norm is frustration with the impossibility of doing the simplest of things like defining a constant. ¹ From the coder’s point of view, never mind the underlying implementation. ² Failing the goal of one and only one obvious way to do something.

ilyt 4y ago

> Ultimately I think that's why Python has gained more traction than Ruby, it's an "easer" language to follow and start with. Ruby is probably a more fun and intellectually stimulating language to work with though. Working with various Ruby-adjacent stuff for 10+ years and nothing about Ruby was even "fun" to work with, it was mix of "WTF" and "who designs language like that!". Python is also not "easier" to start with, I'd put Ruby/JS/Python to be at pretty similar level there. No worrying much about types (till they bite you, inevitably, of course, and cause untold bugs), simple things are simple and actual proper (i.e. "not send it to some piece of C code to calculate) multithreading sucks donkey balls.

gorjusborg 4y ago
(Years ago) Ruby made a lot of sense to me coming from Perl, and I'd bet that Perl-inspiration might explain many of the WTF language design choices.

BurningFrog 4y ago

Ruby is typically brief and clear. I work in Python now, and I often have to use 5-7 lines for what would have been 2-4 in Ruby. Because you have to clutter the Python with trivial details, not because the Ruby code is "magic".