Do we have something similar in python, if not I am going to make one.
IIRC Guido himself is planning on adding a `match` statement to Python.
Pattern Matching in Ruby 2.7 (2019)
51–60 of 110 posts
Re: Pattern Matching in Ruby 2.7 (2019)
#52I personally love pattern matching (one of the best features of Elixir and Erlang for my taste) and would be screaming in enjoyment if something similar would be introduced to Ruby but I'm kind of meh about the whole ordeal. This is experimental. Even when we upgrade production systems to 2.7 I'm still going to refute usage of pattern matching in the code (and it still boggles my mind why add experimental feature to…
> in function header definition Hmmm, I can kind of see it, but then you'd also need function overloading, right? With this you'd just do outer/inner functions, where the outer determines the pattern match and dispatches along to the appropriate inner function. If you want to just make sure the function only accepts arguments that match a pattern, you're basically talking a guard pattern. Maybe a `return unless foo i…
You mean that guards + destructuring would effectively be the same as pattern matching in function's params? Pattern matching would allow matching against more complex data structures more comfortably though.
Re: Pattern Matching in Ruby 2.7 (2019)
#53I 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…
> 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.
Re: Pattern Matching in Ruby 2.7 (2019)
#54Is pattern matching implemented sequentially in order of declaration in other languages? My naive brain took the pattern resolution to be based on some kind of map of types and values to implementation.
It is, from top to bottom.
Re: Pattern Matching in Ruby 2.7 (2019)
#55I mean I get it - but, it doesn't feel like ruby to me. It lacks clarity. Maybe it's just me, but i'm not psyched to see this. It feels like a scope creep of some sort.
The ^ operator is maybe a bit confusing, and that Hashes need to use symbol keys to work here is just another example that symbols are a mess. But did you see the JSON-matching example in the slides? That made it totally clear to me how this is supposed to work and what the advantage of having this would be. Very powerful, very useful, and the code in that scenario is much clearer.
Re: Pattern Matching in Ruby 2.7 (2019)
#56Earlier 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.
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?
Re: Pattern Matching in Ruby 2.7 (2019)
#57...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…
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/
Re: Pattern Matching in Ruby 2.7 (2019)
#58Earlier 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…
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/
Re: Pattern Matching in Ruby 2.7 (2019)
#59Earlier quoted context omitted.
> 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 li…
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…
> 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.
Re: Pattern Matching in Ruby 2.7 (2019)
#60I 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…
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.
It's typical in statically typed functional languages to match against Algebraic data type value constructors. These ADTs have a fixed amount of variants, which makes it suitable to do a clean pattern match.
ADTs don't exist in OOP. It gets more complicated to do matches against classes whose abstractions are not really decomposable so easily.