News for hackers. Stuff that matters.
Re:Pattern Matching in Ruby 2.7 (2019) by lmm on Thursday January 09, 2020 @03:38AM (#21999504)
I shudder to think what datascience code would look like if a language with a culture of monkeypatching/metaclassing had won. Clear code is nice, but not when the price is sweeping all of the details too deeply under the carpet.
Re:Pattern Matching in Ruby 2.7 (2019) by nnq on Thursday January 09, 2020 @03:44AM (#21999538)
> 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 like Go that are all about NOT sweeping things under the rug. But that's a different niche.

Re:Pattern Matching in Ruby 2.7 (2019) by workthrowaway on Thursday January 09, 2020 @06:48AM (#22000398)
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 instead of trying to be clever. i am sure method_missing could be implemented in python using various tricks but nobody, afaik, is doing that.

Re:Pattern Matching in Ruby 2.7 (2019) by pansa on Thursday January 09, 2020 @07:20AM (#22000570)
> 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) by nnq on Thursday January 09, 2020 @08:19AM (#22000928)
> It’s not just culture - Python’s object model is so complex that it would be hard to get right

Exactly! Python is flexible too... using module import hooks and AST transformations you can even implement common-lisp-style-macros... but the language and model is so darn messy and special-case-y that it would blow up in your face if you tried to use it in a real world project :|

Whereas in Ruby you can whip up a nice clean DSL in no time, and people can actually understand how it's implemented and read it's source without being gurus. Whereas the number of Python programmers who properly understand metaclasses and AST wrangling and other stuff you'd need to do DSL-like stuff and have it work correctly can be counted on not that many fingers...

Re:Pattern Matching in Ruby 2.7 (2019) by coldtea on Thursday January 09, 2020 @05:13AM (#21999945)
>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.

Those are just external libraries written in C/fortran/etc. Not monkeypatching.

Re:Pattern Matching in Ruby 2.7 (2019) by agumonkey on Thursday January 09, 2020 @06:21AM (#22000254)
I never looked at the source but it seems that there's an object layer with a lot of meta-programming to turn the oo syntax into more pleasant ergonomics.

I don't applaud ruby dark voodoo tricks, but I think it's the same spirit.

Re:Pattern Matching in Ruby 2.7 (2019) by gdy on Thursday January 09, 2020 @04:21AM (#21999690)
"it's called non-leaky abstraction"

Is there such thing?

Re:Pattern Matching in Ruby 2.7 (2019) by pwm on Thursday January 09, 2020 @05:29AM (#22000010)
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...
Re:Pattern Matching in Ruby 2.7 (2019) by gdy on Friday January 10, 2020 @07:53PM (#22017197)
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.
Re:Pattern Matching in Ruby 2.7 (2019) by wwright on Thursday January 09, 2020 @07:31AM (#22000629)
Have you heard of “divide by zero?” ;)

(I agree that math abstractions are less leaky than others, of course)

Re:Pattern Matching in Ruby 2.7 (2019) by omaranto on Thursday January 09, 2020 @10:00AM (#22001704)
I'm confused: how is dividing by zero an example of a leaky abstraction in mathematics?
Re:Pattern Matching in Ruby 2.7 (2019) by look_lookatme on Thursday January 09, 2020 @10:58AM (#22002227)
I don't think OP is talking about metaprogramming, but more about syntax and how ergonomic Enumerable chains are, which I can see being really nice in data wrangling.