Live data from Hacker News

Pattern Matching in Ruby 2.7 (2019)

speakerdeck.com

91–100 of 110 posts

Re: Pattern Matching in Ruby 2.7 (2019)

#91

Earlier quoted context omitted.

> 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 ha…

> 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`)

Re: Pattern Matching in Ruby 2.7 (2019)

#92
post #12

...semi off-topic, but man, how I wish Ruby had won the hearts of data-science and machine-learning practitioners instead of Python or R! It looks like such a wonderful and extensible and programmer friendly language compared to all the others in the "multi-purpose dynamic 'scripting' languages class". Every time I read Ruby code it almost puts a smile on my face, it seems such a joy to write and think in, so sad it…

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 Rail…

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#93
post #71
post #53

Earlier quoted context omitted.

You got any links to share on this? I'm doing a bit of academic study on the subject of pattern matching in OOP.

BETA programming language, https://beta.cs.au.dk/ Chapter 3, Objects and Patterns Oberon-2 type guards, which are basic but still have the same idea somehow, https://cseweb.ucsd.edu/~wgg/CSE131B/oberon2.htm Modula-3 type case, https://www.cs.purdue.edu/homes/hosking/m3/reference/typecas...

Thanks!

Re: Pattern Matching in Ruby 2.7 (2019)

#94

I hope... this is not another feature that is added to Ruby at the sake of the functional programming trend. Rubycop’s author criticized[0] Ruby 2.7 for losing a direction/vision where Ruby should go (which sparked controversial operators that were quickly removed). Most of them looks like, at least to me, trying to fit a functional programming features in an inherently object-oriented language to be ‘hip’. Like... t…

Definitely agree regarding the strange semantics recently like the pipeline[0] or `.:` method reference[1] operators. I do think those kind of functional features would be handy if they behaved correctly and had a more Ruby-like syntax instead of introducing foreign looking operators.

Luckily this new pattern matching feature appears to behave like expected and feels pretty natural - just a new `in` keyword and some variable binding syntax to familiarize ourselves with (which we already kind of use with statements like `rescue`).

Awhile back we experimented with an alternative Ruby pipe operator proof of concept[2] that is "operator-less" and looks just like regular old Ruby blocks with method calls inside of it. Maybe there's still a chance for something like this now that those other implementations have been reverted!

  # regular inverted method calls
  JSON.parse(Net::HTTP.get(URI.parse(url)))

  # could be written left to right
  url.pipe { URI.parse; Net::HTTP.get; JSON.parse }

  # or top to bottom for even more clarity
  url.pipe do
    URI.parse
    Net::HTTP.get
    JSON.parse
  end
[0] Revert pipeline operator: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/...

[1] Revert method reference operator: https://bugs.ruby-lang.org/issues/16275

[2] Experimental "operator-less" Ruby pipe operator proof of concept: https://github.com/lendinghome/pipe_operator

Re: Pattern Matching in Ruby 2.7 (2019)

#95
post #12

...semi off-topic, but man, how I wish Ruby had won the hearts of data-science and machine-learning practitioners instead of Python or R! It looks like such a wonderful and extensible and programmer friendly language compared to all the others in the "multi-purpose dynamic 'scripting' languages class". Every time I read Ruby code it almost puts a smile on my face, it seems such a joy to write and think in, so sad it…

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 Rail…

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#96
post #12

...semi off-topic, but man, how I wish Ruby had won the hearts of data-science and machine-learning practitioners instead of Python or R! It looks like such a wonderful and extensible and programmer friendly language compared to all the others in the "multi-purpose dynamic 'scripting' languages class". Every time I read Ruby code it almost puts a smile on my face, it seems such a joy to write and think in, so sad it…

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#97
post #79

Earlier quoted context omitted.

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#98
post #12

...semi off-topic, but man, how I wish Ruby had won the hearts of data-science and machine-learning practitioners instead of Python or R! It looks like such a wonderful and extensible and programmer friendly language compared to all the others in the "multi-purpose dynamic 'scripting' languages class". Every time I read Ruby code it almost puts a smile on my face, it seems such a joy to write and think in, so sad it…

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#99
post #44

Earlier quoted context omitted.

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 Rail…

> 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.

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#100

Earlier quoted context omitted.

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 o…

> 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/

[deleted]
Post reply on HN