I wish Ruby was “the data science language” tbh. Ruby has some of the most beautiful and concise idioms of any language. I remember the first time I learned procs, blocks and lambdas my mind was blown with how elegant ruby solutions to problems can be. It’s a shame I have to use python instead.
Agreed. Ruby is more consistent than Python IMO, and has especially beautiful semantics for the list processing.
It’s interesting, Ruby can be a bit more performant too. I discovered this when I taught some ML stuff to a ruby group, and converted some Q Learning programs and maze navigating stuff from Python to Ruby, and was surprised to see the Ruby version run around 1.3-1.8x faster depending on what the code was doing. It’s not enough difference to really matter, but it just reinforced my “aww shucks” feeling that Ruby could have served that ecosystem very well.
All the performance benchmarks I've seen over the years have shown Python to be significantly faster than Ruby. Keep in mind it doesn't matter a whole lot as the scientific stuff calls out to C or Fortran anyway.
I’ll admit, despite having developed professionally on ruby for 6+ years I do not get this attitude of ruby being “beautiful”. Some things are easy to read and interpret in ruby (well-written DSLs come to mind) but it doesn’t strike me as anything special in terms of general purpose programming—closures are now common, macros are gaining ground in more formal languages, syntax is carried on in successive languages like Crystal (and is highly subjective anyway, I’d give my hand not to structure my programs with english keywords), and ruby is missing proven features that have hit other languages devs may or may not have noticed.
Ruby has a great liquid hiring pool and can be used to write functional software rapidly. That’s the beauty I see, and it comes at a cost like all languages. There’s nothing especially beautiful about the way that it expresses algorithms; most languages have great aesthetic by leaning into the features and idioms designed into the language. How can a language have aesthetic in a general sense if languages have expressive tradeoff?
Where it really shines, when you have to manipulate, transform data. You can chain commands as you do with Unix pipes. You can read left to right, and know what is your data structure looks like at each step.
Is all programming not manipulating/transforming data?
Regardless, i’m interested in how the syntax actually supports this. You can build monads in any language to support chaining! I’ve found the block syntax often makes this less readable if you can’t use a method identifier—ruby doesn’t have syntax for anonymous arguments that would allow expressions like `arr.map(someFunc(“arg”, @0))`, so the resulting block is more verbose and distracts. There’s also no currying.
yes it's very much about having to go with the flow: in the past I've used Ruby for a swathe of scripting and prototyping tasks, fell in love with it and assumed it'd always be the go-to tool of choice, but now working on locked-down Red Hat envs where Ruby is not installed but Python is, so purely for that reason was forced to transition to using Python instead. Over the years since I've come to appreciate Python's virtues more, but still agree with your sentiment.
I think it’s about 95% the academic thing. Not sure exactly how Python came into favor as the preferred scripting language of Academia, but once it did that basically ensured the math and science ecosystem would be very robust, which in turn made Python an obvious good choice for data science, ML, etc.
I think what happened was that Jim Hugunin wrote Numeric (Numerical Python) in 1995 with help from a bunch of other people, and Travis Oliphant and some other people put together SciPy in 2001 from modules they'd been working on previously. A hecking lot of work had already gone into Numeric and SciPy by the time I first tried using it, around 2003, and so it was already pretty stable, with a broad range of capabilities. It had already left Perl's PDL far behind (except for 3-D plotting support), and Ruby's NArray barely existed, being under 10KLOC when it was imported from CVS in 2001: https://github.com/masa16/narray/commits/master?after=447c96...
So Numeric and then SciPy (2001), numarray (2001), and Numpy (2005) just had a big head start on the other free-software numerical computation libraries, basically because a few early Pythonistas were interested in the field, and it kept accruing more and more powerful stuff: FFTW (1998), SparsePy (1999), the ability to read MATLAB files (1999), matplotlib (2001), IPython (2001), and so on. It got popular enough that dozens of people started contributing code to it, making it grow faster and faster.
At the time, most scientists were still using MATLAB; other alternatives for array-based computing included R, Bell Labs's Lush, and if you were a real masochist, PV-WAVE's IDL. Octave, the free-software MATLAB clone, wasn't yet a reasonable replacement. And all of these languages had the disadvantage that they were sort of trapped in their own little library ecosystems: if you wanted to do Gaussian quadrature or calculate a Kullback-Leibler divergence or plot some data, you were golden, but if you wanted to scrape some data out of some web pages with regular expressions, parse command-line flags, read members of a zip file, or run as a CGI process on a web server, you were shit out of luck. Numpy's syntax for a vector of numbers is pretty shitty compared to Octave or APL, but it's worlds better than R or especially IDL, and most people prefer it to Lush's Lisp syntax, although I have a soft spot for Lush myself. And Python and Numpy have reasonable language semantics too, unlike Octave or R.
(I think Lush may have been a bit late to the free-software party, too, so it wasn't really an option.)
So academia started switching over from MATLAB to Numpy, I think around 2010. The transition isn't over yet; the numerical-methods class I audited last year is still using Octave. R is dominant in statistics and will probably stay that way. But Numpy is pretty broadly adopted.
It basically came down to a head start due to a lot of hard work done in the 1990s that just happened to be done in Python. It's maybe not entirely coincidence that the people whose taste ran to reimplementing Gaussian quadrature were fans of Python and not Perl, Ruby, Lua, or Tcl, but they could have been.
IMO matplotlib was the inflection point. Once you could capture students and junior researchers at the "first plotting solution after Excel" on-ramp (on which MATLAB previously had a department-mandated stranglehold) the mind share exploded.
Well, python was created by a Dutch guy who worked at the research center for math, later some other research positions.
the CWI has ties with the university, so that makes sense.
Python is older than ruby, and matz probably had less ties, and probably uses more JP than guido did Dutch.
Yeah even if Ruby is not much younger than Python, it only gained popularity outside of Japan somewhere around 2003, and only extreme popularity after the release of rails.
I was using Ruby regularly circa 2001. It wasn't unknown in the West, as various magazines had pointed out this neat Smalltalk-like scripting language and the first version of the Pickaxe book was also published in 2001.
While I think this is helpful as a way to understand the APL original, the title is sort of false advertising.
It's sort of not one Ruby statement if it starts with
require 'apl'
and uses some APL::Ary class that, as far as I can tell, isn't in the Ruby standard library. I was hoping to see how Enumerable enabled this, not how you can implement APL in some arbitrarily large amount of Ruby code offscreen, because of course you can do that.
The APL module is in the `lib` directory of the repo holding the code, you can see the implementation there.
It wouldn't be that bad to pull all the library code out into the 'main' command, but it would lose the 'single statement' impact and probably be harder for people to follow along with.
Anyway, I think it probably should lose the "single statement" impact, because in that context it's just misdirection, magician's patter. Yes, a single Ruby statement can invoke an arbitrarily complex piece of library code written for the article, but that doesn't tell you anything interesting about either Ruby or how to use it — the same is true of any programming language that supports programs in multiple modules, even assembly language:
start: CALLQ play_life
Now, the particular statement in question is considerably more illuminating than that, but presumably if you wanted to do almost anything else in an APLish style in Ruby, you'd probably have to implement more operations in apl.rb. I see that it doesn't include, for example, scan, slicing, or any broadcasting operations other than +, &, and |. (*, -, and / are missing, for example.)
I mean, I've certainly written worse implementations of APLish operations. You could certainly extend apl.rb into something practically useful. I just don't think it's fair to put four pages of code in one file and then direct people's attention to the single statement in another file that invokes it.
That "ofcourse" you can implement Game of Life in one statement if you implement (parts of) the standard library of APL is not obvious to many people. The point of the blog is to introduce people to the concepts of APL, not to pitch some innovation.
As a Ruby programmer who already knew about APL, I thought the title exactly matched the article. I was pleasantly surprised at how clean he designed the apl library, and the nice explanations.
Oh, I guess that's true. I remember when I was a kid I didn't have any idea how the BASIC interpreter worked either, and I didn't have any idea about how to build a tower of abstractions. So surely there are Ruby programmers who hadn't thought of trying to implement APL primitives in Ruby (especially if they haven't seen NArray.) Still, Ruby is pretty big on building embedded DSLs, so I'd think novice programmers learning Ruby would encounter that idea pretty early on.
But there's always today's lucky ten thousand! I hope I didn't make any of them feel condescended to. Welcome to the wonderful world of implicitly parallel vector operations!
Not really a oneliner if it requires a 1/4 page of code, but I'll let it slide
I was more surprised by the fact that the GitHub repo containing it actually has quite a few files; I was not expecting it to contain more than 2 or perhaps 3 files.
Though, I don't think there's really a problem with just doing I/O in q directly. The theoretical performance won't be as good, but since I/O is, well, I/O bound, it shouldn't really matter. And besides, I bet that even when doing non-array operations, q is faster than Python or Ruby.
Well mostly but the explanation forgets to mention the ravel (comma/array flatten) operator in the comment section and the article doesn’t really explain the inner product bit (matrix multiplication in the rig of or and and), which I think is more confusing. In particular the 1 ω part.
(author here) I noticed the thing about flatten an hour ago and fixed it (somehow thought +/, is "reduce 2 times", then understood it is flatten + reduce, and my lib already had flatten, so it was easy to fix). As for "inner product", I just haven't found suitable Ruby metaphor and fell back to zip+reduce, which seems to be equivalent.
Btw I love that Ruby methods return a value, so method chaining works so good. That‘s something I appreciate in Mathematica‘s postfix notation (for instance `x // Sin`), and also what I love in R‘s pipe operator, Unix‘s pipe. So many other languages like Elixir offer it. Unfortunately this does not work out-of-the box in my beloved Python.
No, it is not. Python's `my_list.sort()` will sort the list in-place without returning the sorted list. If I wanted to have a return value (without changing the original list), I'd have to use `sorted(my_list)`.
Off-topic, sorry, but could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
You needn't use your real name of course, but for HN to be a community, users need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
A very large number of SAAS products are built in (or started out in) Ruby, including these that I know of: Github, Gitlab, Twitter, Shopify, Stripe, AirBNB. There are more but those are the ones that come to the top of my mind.
The engineers working at those places represent a non-trivial chunk of the software engineering world, especially in San Francisco, and SWE’s (especially in San Francisco) are a major cohort of HN readers.
Additionally, the Ruby ecosystem had a major influence on many other ecosystems that spun out for various reasons. For example, Sinatra popularized the “minimal REST framework” and has been a major design influence on dozens of others, like ExpressJS and Flask. CoffeeScript, which established “transpile into JavaScript” as a thing, and profoundly influenced the shape of ES6, was heavily adopted and made prominent by the Rails team. Similarly notable projects like Ember, Elixir and Phoenix, were created by former Ruby and Rails core team members, Crystal is inspired by it, and plenty of older projects like SailsJS or Grails for groovy, etc. IIRC Rust’s cargo package management system and JS Yarn were also inspired by and contributed to by Ruby core folks. It’s influence is a lot bigger than its footprint.
So Ruby is a nice, elegant language with a lot of influence in the software world, it’s used by many readers here, and a lot of people here have “warm fuzzy feelings” about it enjoy sharing and discussing interesting news or tidbits about it.
Assuming you are new to HN and not a new Account. Ruby is not popular on HN, in fact it is quite unpopular.
May be popular is not the correct word, I still remember when HN ( I didn't have an account then ) was basically an Erlang site. It was hype, and in the grand scheme of things it certainly wasn't "popular" in usage.
