Live data from Hacker News

Pattern Matching in Ruby 2.7 (2019)

speakerdeck.com

71–80 of 110 posts

Re: Pattern Matching in Ruby 2.7 (2019)

#71
post #53
post #26

Earlier quoted context omitted.

> functional programming features What features? Smalltalk-80 already had lambdas and LINQ, they were just called blocks and collection methods instead. Pattern matching in OOP languages was a path pursued by BETA, Simula's successor by the same authors, where even classes are instances of patterns as concept.

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

Re: Pattern Matching in Ruby 2.7 (2019)

#72
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…

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#73
post #28
post #10

Earlier quoted context omitted.

Why can't pattern matching fit in OOP? It's not really functional, despite being in most functional languages. It's just sugar for more lengthy imperative conditionals and unpacking.

Indeed, Objective Caml is a multi-paradigm language with pattern matching.

And Scala. The poster child of oop + functional

Re: Pattern Matching in Ruby 2.7 (2019)

#74
post #21

Earlier quoted context omitted.

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.

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

Re: Pattern Matching in Ruby 2.7 (2019)

#75
post #47
post #21

Earlier quoted context omitted.

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#76

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

Re: Pattern Matching in Ruby 2.7 (2019)

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

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#78
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…

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.

Re: Pattern Matching in Ruby 2.7 (2019)

#79
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…

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

Re: Pattern Matching in Ruby 2.7 (2019)

#80
post #63
post #33

Earlier quoted context omitted.

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

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?
Post reply on HN