Moving Beyond the OOP Obsession • Hacker News Board

Re: Moving Beyond the OOP Obsession

#21

Post by AndrewDucker » Mon, Mar 28, 2016, 12:33 PM UTC

golergka wrote: post #2

I've encountered this code a lot in C, and every time I thought that this style of > stuff_do_something(stuff, some_parameter) _is_ OOP and identical to > stuff.do_something(some_parameter) , although in language without support for OOP (of course, you can hack OOP on top of C with preprocessors and stuff, but let's pretend we forgot about that embarrassing abominations). And every time I saw that I wished that I cou…

Exactly. OOP is: a) A code naming/organisational issue b) Some formalisation of structure, so that developers can specify what is/isn't allowed in their code.

Both of thise have advantages and disadvantages, and the structure can be over-formalised and made too complex. But this doesn't make OOP bad. It makes bad design bad.

Re: Moving Beyond the OOP Obsession

#22

Post by l_dopa » Mon, Mar 28, 2016, 12:42 PM UTC

exprx wrote: post #12

>Now here's what this would look like in C++ without using objects: mixer_set_volume(m, 0.8); What is m, if not an object?

Assuming you're in some client code that shouldn't rely on the implementation of m, it's an https://en.wikipedia.org/wiki/Abstract_data_type

Re: Moving Beyond the OOP Obsession

#23

Post by exprx » Mon, Mar 28, 2016, 12:57 PM UTC

lexicality wrote: post #20

exprx wrote: post #12

>Now here's what this would look like in C++ without using objects: mixer_set_volume(m, 0.8); What is m, if not an object?

A struct.

A struct is an object. Even a plain integer is an object, considering the referred article was talking about C++.

(Yes, you cannot inherit all kinds of objects – but you definitely can inherit any kind of struct, POD or not.)

Re: Moving Beyond the OOP Obsession

#24

Post by exprx » Mon, Mar 28, 2016, 12:58 PM UTC

sklogic wrote: post #14

A value, with a type. Nothing else. Stop highjacking everything into your OO religion. If you take everything of a value that originated elsewhere, there will be nothing left in the OOD.

A value with a type is an object?

What else do we need? “Methods”? Why?

I very strongly support the proposed Unified call syntax.

Re: Moving Beyond the OOP Obsession

#25

Post by w8rbt » Mon, Mar 28, 2016, 1:07 PM UTC

There's a lot of non-OOP C++ outside of the classroom ;)

Procedural C++ is big in systems (and that's not just plain C compiled with a C++ compiler). Templates, strings, built-in containers and smart pointers are very popular and useful.

Re: Moving Beyond the OOP Obsession

#26

Post by jakub_h » Mon, Mar 28, 2016, 1:30 PM UTC

hcarvalhoalves wrote: post #18

jakub_h wrote: post #16

I could take that text more seriously if it at least discussed the limitations of the most powerful embodiments of OOP that we have today and not the accidental limitations of languages that for one reason or the other ended up not as good as they could have and force you to jump through hoops, as evidenced by the very mentions of classes, constructors, private methods etc., none of which are fundamental to OOP but a…

I agree, but OTH you can be a Platonist and refute every criticism with this argument. In the end the OOP you have is the OOP that has been implemented, so judging the implementations we have to work on is more down to earth.

True. But when it comes to learning the basics of programming, you can always pick better languages. There doesn't appear to a shortage of pedagogically useful ones.

Re: Moving Beyond the OOP Obsession

#27

Post by rfrey » Mon, Mar 28, 2016, 1:33 PM UTC

exprx wrote: post #23

lexicality wrote: post #20

Earlier quoted context omitted.

A struct.

A struct is an object. Even a plain integer is an object, considering the referred article was talking about C++. (Yes, you cannot inherit all kinds of objects – but you definitely can inherit any kind of struct, POD or not.)

Well, if everything is an object, I guess everything is an object.

Usually when people are talking about OO objects they mean data+behaviour.

Re: Moving Beyond the OOP Obsession

#28

Post by hintingonwhoiam » Mon, Mar 28, 2016, 1:45 PM UTC

exprx wrote: post #12

>Now here's what this would look like in C++ without using objects: mixer_set_volume(m, 0.8); What is m, if not an object?

The point is not a lack of objects but a lack of OOP. Yes, there are "objects" but there is also a separation between objects and methods etc..

The issue with m->set_volume(.08) is it becomes difficult to tell what happens inside set_volume() because in the method scope you have access to the internals of the "m" object, not just the interface.

With mixer_set_volume(m, .08) you have ".08" and "m" but only the interface "m" exposes anywhere else. Thus it becomes easier to reason about effects.

Re: Moving Beyond the OOP Obsession

#29

Post by CyberDildonics » Mon, Mar 28, 2016, 1:48 PM UTC

If you need an interface to your data, use structs/classes.

If you need genericness when the size of the data doesn't change, use templates.

If you need genericness when the size of the data does change, use inheritance.

If you need genericness with respect to part of an algorithm, use lambdas.

Re: Moving Beyond the OOP Obsession

#30

Post by Chirael » Mon, Mar 28, 2016, 2:00 PM UTC

whoisthemachine wrote: post #17

I agree with this post, and especially the main focus of the post, which seems to be: teach the basics before bogging students down in the crazy terminology-heavy industry we live in.

Yes absolutely. I learned OO with programming in the early 90s, around the birth of the OO religion. So it's definitely in my mental toolbox if needed... But in practice I'd say I rarely, if ever, need it. The only time it's come up in the last 5 years was during a job interview, when I mentally did an eye roll and thought "oh god OOP stuff again" Granted, I do more glue programming and scripting, vs full-fledged app development. I'm sure if I was doing Android apps I'd be using ActiveWindowAppAdapterFactoryConstructor (q.v., programming in the kingdom of nouns) but thankfully that's not something I have to do (yet).