RubyConf 2017: 4 Programming Paradigms in 45 Minutes by Aja Hammerly

[@squirlmy]

I don't understand why the Coding Tech republication of this video gets so much more views and comments. And of course there are a lot of criticisms there from people who aren't taking this video in the right context. She's taken on a task that, to programmers and even students of some experience, is patently impossible. Considering how difficult the challenge, she does an excellent job. She's also providing an antidote to a series of presentations which would surely focus exclusively on Ruby. It's a very rebellious subject to take on, given the context. I don't think this is appreciated in Coding Tech comments.

[@oysteinsoreide4323]

Reuse is allowed. It is more important to spread the video, than that it is the one who made the video that spread it.

[@tobiasfuchs7016]

Enjoyed your talk, deep technical expertise and raw teaching talent. Just some Wisenheimer remarks - you are apparently well aware of all this, but some viewers might not: 3:00 Methods are (conceptually, in case of C++ also technically) not associated with the object, but with the object's type. Objects encapsulate state, like you explained (the only definition of 'Object' I personally use), but semantics are specified for *types*. A method is a mapping from a given well-defined state to a modified well-defined state, possibly depending on some parameters (aka method arguments). Technically, for a method Foo::mogrify(int), there only is exactly one implementation that is located within class Foo with internal and inaccessible interface `Foo::_mogrify(Foo * this, int)`. Calling `foo.mogrify(123)` is syntactic sugar for `Foo::_mogrify(&foo, 123)`. The method only depends on the state of the associated Foo object (= its fields, like you explained) which is accessible from the `this` argument. This also explains the mechanism behind virtual methods: there is an additional vtable (virtual table) which in principle maps object addresses (like &foo) to sections of function pointers. These principles are not specific to C++, even oldskool Javascript "class" protoypes work like this.

[@micalevisk]

slides: www.thagomizer.com/files/ParadigmsRubyConf2017.pdf

[@ShinobiEngineer]

EXCELLENT TALK ! ! ! REALLY HELPFUL ! ! ! THANK YOU AJA ! ! !

[@simply4est]

Loved it!

[@oysteinsoreide4323]

The object oriented cash drawer example was in a more procedural style. Had there been some actual cash in the drawers ther object oriented solution would become more interesting.

[@LukSilva12]

Does anyone have access to her slides?

[@Strategiusz]

I got "Lost In Stupid Parentheses" in 20:00

[@-taz-]

The parens don't matter much if you just go by the indentation.