I was never a fan of ruby until I had to use it at work.
I think my main superficial turn-off was indeed the non-traditional loops and I was a fan of python whitespace indentation.
But on the whole ruby just feels very coherent and language features mesh very well together - it often feels like a true lisp with self-style object orientation done very well [1].
Python otoh feels like an imperative language with classical OOP added on and extended via magic methods.
See e.g. functional programming in python vs ruby with map, filter, reduce and so on and how blocks and procs in ruby interact with those vs lambdas in python.
I still use python often but have to say I tend to miss ruby when I do.
> In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.
"the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement" should be the working definition of "agile" development in almost every context. Would save a lot of confusion and pointless arguments about the true definition of agile, kanban, extreme programming, or what have you.
Most of the things you list are things you may or may not get right the first time; what makes something agile, at least, when the term was first floated, was the ability for the team to own the solution, say "this is not working" (be that architecture, team structure, process, etc), and change it easily. Agile was "ability to (rapidly) change", not "adherence to a defined set of rules called 'Agile' ".
Most places don't actually seek out that definition of agile, though. And so there's a lot of bikeshedding around "what process is the one true way (and what can we add to it to make it work when it fails us)" rather than "how do we empower the teams to make their own decisions on how to best be effective"
I think in Python, I saw a good deal of adoption in the Sciences early on.
I worked on a Physics experiment almost 15 years ago, there were inklings of Python dripping in to doing numerical analysis.
NumPy just using existing Fortran libraries is a good example of it just being bootstrapped by the scientific community.
Most of these guys come from a Fortran background, and some used the C++ ROOT framework.
Ruby was just too alien for them.
ROOT had made some excellent Ruby bindings, and I spent some time showing some of my colleagues how much time they could save using them, but they just found it to be too different.
It's sort of funny to think, because languages made for AI originally like LISP used functional concepts like map, collect, etc etc...
I think the AI trend using Python was boosted by numerical analysis/computing libraries already being present.
Peter Norvig is always a pleasure to read, even on HN. Imagine how precious is the history of HN Threads... i hope someday someone compiles it in a consumable fashion.
It's always been the global functions in Python that put me off. My brain just doesn't think like that. When I want the length of an array, I look for a method on the array. Same with map, and anything else.
That said... pretty small gripe in the grand scheme (no pun intended, maybe) of things. When I've written projects in Python, I've enjoyed it.
> It's always been the global functions in Python that put me off.
I'd argue it's the inconsistency. Some things are methods, some things are functions. The name choices are also a bit boneheaded (eg. "dumps"). It's a lot like PHP in these regards.
Ruby, on the other hand, is beautifully designed. But it gives you a bazillion ways to skin a cat, and people love to be "clever" with their cat skinning. In those cases, I appreciate the utilitarian approach and "zen" of Python.
My biggest gripe with Python, though, is the totally 80s feel of the version and package management. It's one of the worst experiences in my daily engineering life. I can never know if complex ML code will work on my system without thirty minutes of patching things up.
I'll gladly use Python to get work done or Ruby for small websites. But I'm looking for a new daily driver for scripting that learns from the last thirty years of mistakes. (Modern language, sensible packaging/dependencies/version switch, optional static typing, and optional static binary output.) Nim, perhaps?
Nim is nice but it's not dynamic so replacing a lot of the use cases of Python/Ruby (or R) would be a pain. Like, I'm not going to do any data munging in Nim when the others exist, exploratory programming in Nim is also sub-optimal. That being said, it's a nice language, way easier to write than any other statically typed language I've used, I never used Pascal/Delphi but Nim makes me appreciate that whole family of languages a lot more (Nim is basically a modern Pascal with Python's significant whitespace that compiles to C).
Not really. Proc vs def, let and var keywords, Pascal style ranges and arrays, etc... I found C# is closer to Nim when it comes to translating code than Python is. The semantics are pretty different, especially since it seems everyone uses numpy in Python for any sort of array maths.
That's what turns me off about Python (and f-strings), being a Perl programmer. I've had to do some proof of concept for reading smart cards and the Perl PCSC library sucks. So I did it in Ruby, which like Perl has pack/unpack methods for converting hex strings to binary and back. It's just great. Now I have not two programs to read smart cards, one using the Ruby smartcard library and another one using rubyserial and doing serial communication directly with the card reader, with a partial implementation of the T1 protocol, all in under 1k lines of code.
This doesn't have anything to do with Python but Ruby feels more of a natural language for doing rapid application development and active record than Laravel does.
The caveat is that Python is only _fine_ at functional programming, and that only because it's very, very malleable. The deeper you go into functional programming with Python, the more you wish you were programming in Clojure, or F#, or whatever.
But I'd still rather use a functional style in Python than an OO or procedural style.
> I think my main superficial turn-off was indeed the non-traditional loops and I was a fan of python whitespace indentation
I've always been perplexed that this, a very small thing that barely ever comes up since 99% of the time you are doing a for each loop anyway, is the main turn-off for people learning Ruby, when Python has those crazy weird if statements and indentation-sensitivity
I think my main superficial turn-off was indeed the non-traditional loops and I was a fan of python whitespace indentation.
But on the whole ruby just feels very coherent and language features mesh very well together - it often feels like a true lisp with self-style object orientation done very well [1].
Python otoh feels like an imperative language with classical OOP added on and extended via magic methods.
See e.g. functional programming in python vs ruby with map, filter, reduce and so on and how blocks and procs in ruby interact with those vs lambdas in python.
I still use python often but have to say I tend to miss ruby when I do.
[1] https://news.ycombinator.com/item?id=1803815