ML is changing the world.
Wrong thread?
Pattern Matching in Ruby 2.7 (2019)
101–110 of 110 posts
Re: Pattern Matching in Ruby 2.7 (2019)
#102Earlier quoted context omitted.
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?
> Genuinely curious, what makes Python look more like pseudocode? The use of colons? I used to think it was significant indentation, but if you look at the pseudocode on e.g. Wikipedia, there is no significant preference for either whitespace or begin/end. Therefore, it’s probably things like `if value in my_map` vs `if my_map.contains(value)` and `[x * 2 for x in my_list]` vs `my_list.map(x -> x * 2)`.
List comprehension in python it’s absolutely hideous.
It’s reversed and you have to define first the function and after where it is applied.
The code completion it’s completely broken in that way since it has no idea on which elements you are operating.
And also are you saying that “list.include? 2” doesn’t look more like English than “2 in list”?
Re: Pattern Matching in Ruby 2.7 (2019)
#103Earlier quoted context omitted.
Agreed... 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. But it didn't turn out that way. And since people using Python don't strike me as particularly stupid or anything, there must be something about that language I'm still missing, or it w…
> 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…
> Idiomatic Python is just much clearer and more straight forward for most. They explicitly spent time to minimize how many language concepts and constructs you need to get basic things done. [...] The syntax/grammar are often more regular, use keywords and fewer symbols, and optional bits.
This is similar to a native-English speaker boldly asserting that Dutch is a 'clearer and more straight forward' and 'more regular' language than Japanese.
It might be absolutely true for your own experience and upbringing, but it's still completely subjective.
Re: Pattern Matching in Ruby 2.7 (2019)
#104...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…
[deleted]
Re: Pattern Matching in Ruby 2.7 (2019)
#105...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…
As one of my favorite HN comments of all time said:
> Ruby's C implementation is a mess of support for language-level flexibility. Python's C implementation is so clean you get the unsettling thought that you could probably write Python using C macros.
Re: Pattern Matching in Ruby 2.7 (2019)
#106Earlier quoted context omitted.
> 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.
On the closure front, you are assuming that `lambda` is the only way of writing a closure in Python. That is not true. You can write a named function (`def blah():`) in the same place, pass it around (within that scope the name is now `blah`), and it will still have access to the variables in the original scope. So it is a closure, just a named one.
At first I rebelled against not having unnamed closures, but then you hit the first problem in a complex case, and the backtrace having sane names suddenly makes it all more than worth it.
Re: Pattern Matching in Ruby 2.7 (2019)
#107Earlier quoted context omitted.
Refinements was also at some point marked as "experimental", and jruby maintainers have at some point declared not wanting to support it. It's 2020, refinements are still here, and jruby supports them, even with all its imperfections. I'm wondering: how would you showcase an experimental feature to the community? Cuz if you're saying "3rd party library", there were already 3/ 4 different pattern matching libraries.
> how would you showcase an experimental feature to the community? How do other languages do it? Python has the PEP process for discussing design on paper, but I don’t know how they handle experimental implementations.
Standard library packages can be declared "provisional": https://www.python.org/dev/peps/pep-0411/
The PEP says "A provisional package is one which has been deliberately excluded from the standard library's backwards compatibility guarantees."
But there's no equivalent for language features, AFAIR.
Re: Pattern Matching in Ruby 2.7 (2019)
#108I 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…
Refinements was also at some point marked as "experimental", and jruby maintainers have at some point declared not wanting to support it. It's 2020, refinements are still here, and jruby supports them, even with all its imperfections. I'm wondering: how would you showcase an experimental feature to the community? Cuz if you're saying "3rd party library", there were already 3/ 4 different pattern matching libraries.
The aim, from memory, is to gemify most of the standard library so why not release it as a "blessed" gem?
Edit: I see there is already the pattern-match gem [1], released as a proof of concept, although obviously it has slightly different syntax. Still, the reason why `case` is chosen (because `match` cannot be used) seems very thin.
Should've stayed as a gem, IMO.
Re: Pattern Matching in Ruby 2.7 (2019)
#109Earlier 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…
> Idiomatic Python is just much clearer and more straight forward for most. They explicitly spent time to minimize how many language concepts and constructs you need to get basic things done. [...] The syntax/grammar are often more regular, use keywords and fewer symbols, and optional bits. This is similar to a native-English speaker boldly asserting that Dutch is a 'clearer and more straight forward' and 'more regul…
I know! That's why the sentence right before it was: That said, I do do have reasons I prefer python, though I doubt they're solely why it "won".
Re: Pattern Matching in Ruby 2.7 (2019)
#110Earlier quoted context omitted.
"it's called non-leaky abstraction" Is there such thing?
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...
For example, different implementations may have different performance characteristics depending on the object they are operating on. This way implementation details leak out through the time or space complexity, or through the constant factor.