Same! I never used Rails much but did learn Ruby and used it a lot for the kind of stuff people tend to use Python for nowadays. Data crunching, prototyping, sciency stuff.. It's excellent for that.

I mean, Ruby is so much more elegant and consistent than Python, I'll never understand how Python became the more widely appreciated language of the two, especially with the effective head start that Ruby had through Rails' popularity.

I don't have any data to back this up, but I suspect solid Windows support was a big driver of that. I used to do a fair bit of Python before Ruby and there was a nice MSI installer for the runtime and plenty of libraries had precompiled Windows installers available. This was important because we were working with some software that necessitated running Windows.

I love Ruby, but when I started developing in it, I was surprised at how much the Windows experience lagged behind just about everything else I had tried up until that point (Java, Python, Perl, x86 Assembly, at least). Even today, it's not really easy to run for anything requiring native extensions. You have to set up a separate compiler* just to build those extensions because most gems don't push binaries out. That may be better for security, but I don't think that's the driving factor. You're better off just running JRuby, assuming WSL isn't an option.

* Granted, RubyInstaller makes this a lot easier nowadays.

> I’ll never understand how Python became the more widely appreciated language

IMO syntax is a major factor. Python looks like pseudocode, while Ruby looks like Perl.

You can write Ruby that looks like Perl, but in my experience (6 years of fulltime Ruby) this is very rare in the wild.

I don't think I've ever seen a popular Rubygem with dense, nasty, Perl-like code.

That sort of style may have been more prevalent in the early days of Ruby, which I'm roughly defining as the days before Rails.

Genuinely curious, what makes Python look more like pseudocode? The use of colons?

Regardless, I’ve always thought that Ruby is more like pseudocode because with Ruby, I’m able to worry less about syntax and more about what I’m trying to do. Maybe it’s just me?

> Genuinely curious, what makes Python look more like pseudocode? The use of colons?

I used to think it was significant indentation, but if you look at the pseudocode on e.g. Wikipedia, there is no significant preference for either whitespace or begin/end.

Therefore, it’s probably things like `if value in my_map` vs `if my_map.contains(value)` and `[x * 2 for x in my_list]` vs `my_list.map(x -> x * 2)`.

- `if value in my_map` is a one off special case - ugly, nasty, hard to figure out how to extend it (what if I invented my_map to have special logic for `in` ...I need to search the docs for a magic method called for that operator ...if I even know for what keywords to search, ugh)

- `if my_map.contains(value)` is nice and consistent, easy to search for the code of the .contains method and figure out what it does

- `[x * 2 for x in my_list]` another ugly special case syntax, instead of general purpose higher order functions, even in Python while a `.map` method could've been easily added to dictionaries too, we had to wait years (decades?) for dictionary comprehensions to land in the language, and it's another damn special syntax one has to remember. ugh! - a sane solution not involving higher order functions usage would've been to make everything in the language an expression and have `for ...` expressions return lists or dictionaries or sets, still better than the fugly "list comprehension", I really can't comprehend why people like them

- `my_list.map(x -> x * 2)` nice, clean, and general. If I work with a weirder list like thingy and want to see the logic of mapping, I can easily jump to the definition of it's `.map` method

Most pseudocode is ugly and ambiguous and actually hard to read without special context from the text around it because you're never sure what something actually means, can't easily "jump to its implementation code and read it". Same like natural language, hard to non-ambiguously understand and ugly as hell in technical context where math and diagrams work 1000x times better.

I can't understand why people who are trained in math, physics and/or other sciences would ever choose something just because it "looks more like pseudocode"... To me pseudocode rhymes with... pseudoscience! It's never what you want when you can choose something better.

List comprehension in python it’s absolutely hideous. It’s reversed and you have to define first the function and after where it is applied. The code completion it’s completely broken in that way since it has no idea on which elements you are operating. And also are you saying that “list.include? 2” doesn’t look more like English than “2 in list”?

Ah, yeah. In that regard, I agree, Ruby could use some improvement.

Just as someone who got on the Ruby bandwagon back in the mid 00's there was definitely a feel of Ruby being a "Japanese import language" and at the time for myself, comparing Matz and van Rossom the latter felt like a little bit more of a scientist/engineer than the former who seemed very humanity focused.

Also I think the mantra of "developer happiness is the #1 goal of ruby" kind of makes ruby seem a bit more fanciful and flowery than python.

These are just my personal anecdotes, though, I am assuming that most people (myself included) start eyeing seemingly superficial things like the attitude of the language author when a lot of other qualities of the language are similar.

It’s your point of view. From my point of view ruby looks much more like pseudo code than python. It reads almost like English. And the closures syntax is way better and much more powerful given that it’s not sillily limited to one expression.

On the closure front, you are assuming that `lambda` is the only way of writing a closure in Python. That is not true. You can write a named function (`def blah():`) in the same place, pass it around (within that scope the name is now `blah`), and it will still have access to the variables in the original scope. So it is a closure, just a named one.

At first I rebelled against not having unnamed closures, but then you hit the first problem in a complex case, and the backtrace having sane names suddenly makes it all more than worth it.

I can think of two reasons:

A sort of Dutch Disease caused by Rails is probably the biggest one. When one killer feature drives the adoption of a language, everyone who is interested and good at the language is involved with that ecosystem, and it becomes self sustaining.

The other one (already alluded to elsewhere here) is the culture of monkey patching and meta-code. I worked professionally in Rails for years, and I really enjoy Ruby, but every time I had a problem or question that required digging into the Rails source I was tearing my hear out. Almost everything is a cascade of hundreds of single line methods built on an avalanche of DSL abstraction and depending on implicit monkey patching and other crazy stuff that's a nightmare to understand.

It's not a culture of readable code in sizeable projects, which is what you need if you want to be widely adopted by people who don't primarily write code for a living (scientific work, other general work). Ironic considering how expressive and beautiful Ruby can be.

>I'll never understand how Python became the more widely appreciated language of the two

NumPy, maybe? Lots of resources make it easy to get small impressive projects off the ground quickly.

I guess the answer is - Google. As it used Python and the word was out. Also, Python had been released a few years earlier and so was adopted by universities.

Google had little influence on scientific python. I agree python did not have technically much advantage over ruby, but:

1. Old history of using python for scripting linux, starting from mid-late 90ies, especially around clusters and HPC, i.e. where you find applied scientists in academia.

2. A full C API. Not especially good, but powerful enough. I don't think ruby is much different, but wrapping C with python, again for HPC (or GUI libs). Lua C API is definitely better.

3. Communities matter

4. Different people starting to talk to each other more and more, and right timings. First mid 90ies (numeric/numarray, use in astronomy, etc.), then early-mid 2000ies (NumPy/SciPy consolidation, matplotlib, ipython), then late 2000 with scikit learn, and pandas.

Also, while I know little about ruby, I fail to see how much better it is than python. Both are essentially the same w/ some minor syntactic differences, and different communities. I have never seen an example where ruby was much better than python or vice versa for non trivial code. I mean is RoR that much better than Django ? I doubt that stuff matters very much.

From my perspective, it was the was the ipython notebook (now jupyter) that was the killer app leading to Python being adopted for data science.

I'd say python was pretty big in academic circles even before that if memory serves.

I wrote Ruby as my primary language professionally for over 10 years. These last few years though I write more python and javascript than anything else, but damn do I miss the joy of full time Ruby - what a beautiful, pleasant, productive language it is!

As someone who sometimes steps out of the comfort of writing scheme, I agree with you. I spent a lot more time writing python than I did ruby, but with ruby I can just jump right in and things work like I expect them to. With python there is always small semantic things that moves the whole experience into slightly uncomfortable territory.

But whatever floats people's boats. If I had to do numeric computation I would chose python as well, but personally I would become a grumpy fart that would complain way too much

Ruby was fun while I worked with it professionally but now I don't really like it or reach for it. It's a combination of monkey patching, imports being affected by their filesystem location, games of is this a function or a variable. I don't miss it.

I've been working with Elixir for the past three years and it's boring and predictable. I want that moving forward from my tools. I want boring and predictable.

That's why I actually do a lot of my data science work with Groovy. I just find Python awkward, frustrating and way underpowered as a language (both in terms of language itself but, of course performance as soon as you need to implement anything and not just glue other things together). Groovy + JVM accessible numerical libraries (Smile, ND4J etc) actually make a pretty good combination, even if you do not have access to the state of the art stuff that is going on in R / Python.

>I just find Python awkward, frustrating and way underpowered as a language (both in terms of language itself but, of course performance as soon as you need to implement anything and not just glue other things together).

Compared to Groovy and Java?

Groovy absolutely. Java is .... Java.

I shudder to think what datascience code would look like if a language with a culture of monkeypatching/metaclassing had won. Clear code is nice, but not when the price is sweeping all of the details too deeply under the carpet.

> sweeping all of the details too deeply under the carpet

Ever worked with numpy, scipy, pandas etc. in Python? It's ALL about what you call "sweeping the details under the carpet", or what is generally called abstraction. When abstraction is well "swept under the rug", eg. "you can use it without understanding it much" it's called non-leaky abstraction, and is the best kind of abstraction.

Sure, there's languages like Go that are all about NOT sweeping things under the rug. But that's a different niche.

imo, python won because the community does not condone monkey-patching and dark magic tricks. it's totally possible, yes, but it is frown up. i just realized how important language communities are, actually!

i, unlike GP, do not get a smile on my face when i read ruby code full of implicit tricks. even when i understand some of them, it is still annoying.

why don't people just write clear, explicit, maintainable code instead of trying to be clever. i am sure method_missing could be implemented in python using various tricks but nobody, afaik, is doing that.

> I am sure method_missing could be implemented in python using various tricks but nobody, afaik, is doing that.

You could probably implement method_missing in Python using either __getattribute__ or __getattr__.

I think this is a small example of why nobody is doing so. It’s not just culture - Python’s object model is so complex that it would be hard to get right.

> why don't people just write clear, explicit, maintainable code instead of trying to be clever

But that’s boring. Seriously, it always amazes me how many programmers allow their decisions to be guided by what’s best for their personal enjoyment rather than what’s best for the project.

> It’s not just culture - Python’s object model is so complex that it would be hard to get right

Exactly! Python is flexible too... using module import hooks and AST transformations you can even implement common-lisp-style-macros... but the language and model is so darn messy and special-case-y that it would blow up in your face if you tried to use it in a real world project :|

Whereas in Ruby you can whip up a nice clean DSL in no time, and people can actually understand how it's implemented and read it's source without being gurus. Whereas the number of Python programmers who properly understand metaclasses and AST wrangling and other stuff you'd need to do DSL-like stuff and have it work correctly can be counted on not that many fingers...

>Ever worked with numpy, scipy, pandas etc. in Python? It's ALL about what you call "sweeping the details under the carpet", or what is generally called abstraction.

Those are just external libraries written in C/fortran/etc. Not monkeypatching.

I never looked at the source but it seems that there's an object layer with a lot of meta-programming to turn the oo syntax into more pleasant ergonomics.

I don't applaud ruby dark voodoo tricks, but I think it's the same spirit.

"it's called non-leaky abstraction"

Is there such thing?

Sure. Math based abstractions are non-leaky. This is one of the main thing FP people rave about. Eg. map works without bias on all functors regardless whether the concrete thing is a list or a tree or an IO action, etc...

For example, different implementations may have different performance characteristics depending on the object they are operating on. This way implementation details leak out through the time or space complexity, or through the constant factor.

Have you heard of “divide by zero?” ;)

(I agree that math abstractions are less leaky than others, of course)

I'm confused: how is dividing by zero an example of a leaky abstraction in mathematics?

I don't think OP is talking about metaprogramming, but more about syntax and how ergonomic Enumerable chains are, which I can see being really nice in data wrangling.

Agreed... I can write typical data-wrangling code at close to the speed of typing in ruby. In Python it takes forever, and I notice how every fibre of my soul tries to avoid even looking at it, much less enjoying and wanting to learn.

But it didn't turn out that way. And since people using Python don't strike me as particularly stupid or anything, there must be something about that language I'm still missing, or it wouldn't have succeeded as it did.

I do insist, however, that the documentation is overseen by sadists. Half the time the first 10 hits are to the C interface. The others sometimes link circularly between two "see: x" declarations, etc.

> I can write typical data-wrangling code at close to the speed of typing in ruby. In Python it takes forever, and I notice how every fibre of my soul tries to avoid even looking at it, much less enjoying and wanting to learn.

See I can say the same thing in reverse. I suspect it's just frustrating that once you know one of the two well, the other just dosen't do enough different to be worth learning as much. They have plenty of differences in the specifics but they're incredible similar in the domains they shine in. Similarly between Java and C#.

Add to that the fact that Python is now so established and used so many domains that the package availability that it attracts so many more people as a first language.

That said, I do do have reasons I prefer python, though I doubt they're solely why it "won". Idiomatic Python is just much clearer and more straight forward for most. They explicitly spent time to minimize how many language concepts and constructs you need to get basic things done. Compare:

some_list.each do |this_item| puts this_time end

for this_item in some_list: print(this_time)

The syntax/grammar are often more regular, use keywords and fewer symbols, and optional bits. Python went through a heavy monkey-patching phase (that's all but rejected now) but never went full blown DSL-style like Ruby. I'd say they both gained popularity being fun to write languages but Python stayed a but more balanced in readability.

ps: parens are better on function calls. fight me.

> Idiomatic Python is just much clearer and more straight forward for most. They explicitly spent time to minimize how many language concepts and constructs you need to get basic things done. [...] The syntax/grammar are often more regular, use keywords and fewer symbols, and optional bits.

This is similar to a native-English speaker boldly asserting that Dutch is a 'clearer and more straight forward' and 'more regular' language than Japanese.

It might be absolutely true for your own experience and upbringing, but it's still completely subjective.

I know! That's why the sentence right before it was: That said, I do do have reasons I prefer python, though I doubt they're solely why it "won".

> some_list.each do |this_item| puts this_time end

> for this_item in some_list: print(this_time)

Just a nitpick:

for one liners you can write:

some_list.each { |this_time| puts this_time }

If each element of some_list responds to to_s with something sensible, which it would need to in order for puts to work in the first place, you can just write:

   puts some_list

This works as puts implicitly does the equivalent of calling Array() on its arguments and then calls `to_s` on each one.

`some_list.each ...` is somewhat more generic, as `puts some_list` requires `some_list` to respond to `to_ary` for it to work as expected, which is probably less common than implementing 'each'. (if you implement a collection class in Ruby, at least implement `each` and `to_ary`)

I don't really know much about python, but how is the C API? Because as nice as Ruby may be as a language, I wouldn't want to touch the C API with a laser pointer.

Maybe python just has a nicer API, leading to more people writing fast C libs for it instead of Ruby; and ultimately many people will just use the language with the fastest libraries for their domain (specially the kind of people that have some influence on their community).

Again, no idea if this is the case, but comparing the C APIs of Ruby and Lua, it's a huge difference.

I wouldn't say I'm a C programmer at all though I did manage to struggle through producing a very simple C-extension for Ruby once. Recently, I had to debug one that wouldn't install. Could I find well written, up to date documents?

No. I found bits and pieces scattered in blog posts and gists, and wildly different ways of making extensions.

It was incredibly vexing and I would've happily used Python - or anything else - at that moment. The number of times I find hardcoded paths in Ruby extensions is mind boggling. I guess "it works on my computer" is okay for some but to me it seems amateurish. I don't blame the library authors as much as the core team for this because the documentation and examples are so bad. Not a good look for a mature language.

I'm looking at learning Crystal and Elixir because they'll (hopefully in Crystal's case) fix a lot of the glaring-but-never-fixed problems in the Ruby ecosystem for me.

Ironically enough I've spent my afternoon fighting with a Ruby C-extension that won't install!

This is a big use case for me. I really want to use Perl but I favour Python because the CPython API vs XS, it's a no brainer. I haven't really looked into the Ruby C API but if it's sane I would use it as well.

Perhaps Raku is an alternative for you with its Perl roots and its NativeCall support: https://docs.raku.org/language/nativecall Also see this recent blog post for interfacing with C++ and Fortran from Raku: https://andrewshitov.com/2020/01/08/calling-cpp-and-fortran-...

Nice thank you. The last time I looked at Raku a few years ago when it was still called Perl 6 I hadn't considered native bindings. Will take a look.

> I really want to use Perl but I favour Python because the CPython API vs XS, it's a no brainer.

As I just mentioned in this thread, there is a project called SWIG[0] which might be something you'd want to check out.

0 - http://swig.org/

Thank you. I've heard of it and read about it a few times but haven't seriously considered it, but I will.

> I don't really know much about python, but how is the C API? Because as nice as Ruby may be as a language, I wouldn't want to touch the C API with a laser pointer.

You might want to check out SWIG[0] then. It can definitely help integrate C/C++ libraries into Ruby (as well as a dozen other languages) without having to work directly with the host language's C API.

HTH

0 - http://swig.org/

As one of my favorite HN comments of all time said:

> Ruby's C implementation is a mess of support for language-level flexibility. Python's C implementation is so clean you get the unsettling thought that you could probably write Python using C macros.

https://news.ycombinator.com/item?id=682364

And also, a decade before the Ruby community was the most inspiring community. One can really learn a lot from others, every day. It was like a hacker sanctuary while most programmers are still debating Java vs C++/C#.

Now the community is scattered into different communities - JavaScript, Go, Python, Rust, Scala, Elixir, etc. Those communities are still quite good, but none of them is as great as the previous Ruby community, or at least, gives me the same feeling IMHO.

Does Julia scratch that itch now?

I agree with this. I did rails for a long time and honestly became pretty disenchanted on Ruby as a web services platform. But now that I interact with data analyses in Python fairly regularly (because they are everywhere) I really miss Ruby. I wish Ruby had landed on a different killer app!

It's not on the same level as the R Python ecosystem, but you should check out Scala. It has the power and flexibility, but also a fairly solid backbone of data science libs.

Does it have (1) a RELP, (2) jupyter support and/or smth like it, (3) interpreted mode or a compiler fast enough that I can pretend it does not exist?

Without these it might be a a powerful tool, but it wouldn't be in the same niche as Python and R.

Also, having touched Scala once before, the complexity and learning curve, and the prerequisite of being knowledgeable about JVM ecosystem to be productive in it...

1) yes: https://docs.scala-lang.org/overviews/repl/overview.html 2) yes: https://almond.sh/, there are other options as well 3) The compile times don't bother me. I just set up sbt to watch for files saves and run tests. I'd say the dev cycle is faster than python due to compile time type checking.

It's not the same as Python or R, you are right. There is complexity, but it's rewarding once you get past the initial curve. I felt similarity regarding the JVM, but again, it's not that bad. Plus with GraalVM you can compile binaries, which I love for so many reasons.

Marv, yarv - how is the most downloaded standard implementation called before the language cops bite - is just so unbearably slow for anything besides gluing things together. After that many years it still leaves me baffling how such a mediocre implementation is still actually accepted by it's community.

The language is nice though. I wouldn't vote for the everything is an object paradigm today.

Python may be faster than Ruby, but it's not "C" faster. It's the language extensions like NumPy that do the heavy lifting, and those are usually written in compiled languages like, say, C.

> Every time I read Ruby code it almost puts a smile on my face, it seems such a joy to write and think in

Compared to Haskell, its performance is not good. Same with J for that matter.