Post 1476676 by yogthos@mastodon.social
(DIR) More posts by yogthos@mastodon.social
(DIR) Post #1476676 by yogthos@mastodon.social
2018-11-25T14:18:27Z
0 likes, 2 repeats
The faster you unlearn OOP, the better for you and your softwarehttps://dpc.pw/the-faster-you-unlearn-oop-the-better-for-you-and-your-software
(DIR) Post #1476828 by museus@freespeech.firedragonstudios.com
2018-11-25T14:26:32Z
0 likes, 0 repeats
@yogthos I read this earlier, and while I agree with much of the critique, it quite glaringly offered no alternative solutions. What do they want to replace OOP with? Functional programming? If so how does that solve those problems? Or what? Without offering a solution it's next to useless.
(DIR) Post #1477332 by yogthos@mastodon.social
2018-11-25T14:44:18Z
0 likes, 1 repeats
@museus I've been working with FP in Clojure for the past 8 years now, and it completely solves the problem for me. Being data driven is the whole design philosophy behind the language.Here's an article explaining how this works in Clojure in more detail http://blog.cognitect.com/blog/2016/6/28/the-new-normal-data-leverage
(DIR) Post #1481499 by maxy@mastodon.social
2018-11-25T17:55:42Z
0 likes, 0 repeats
@museus @yogthos I think the main proposal was to work more directly on relational-style data, rather than wrapping a class around each entity. And to focus the design effort on internal, self-contained module APIs.There was a very interesting RustConf keynote tooting into the same horn (so to speak), with a very specific solution for game development and simulations: an entity-component-system (ECS).https://www.youtube.com/watch?v=aKLntZcp27M
(DIR) Post #1481610 by museus@freespeech.firedragonstudios.com
2018-11-25T18:00:52Z
0 likes, 0 repeats
@maxy @yogthos Thanks to you both for sharing perspectives on this. I've been taking a break from any professional dev to speak of for some years now, but I keep finding myself pulled (albeit reluctantly) back in that direction. So it's all worth bearing in mind. I've done my share of OOP and FP in the past, but tbh OOP was more the industry fad at the time, so I have a bit of learning to do if I decide I want to dust off my career and make some more bread. This will all help the thinking tbd.
(DIR) Post #1481615 by jasper@mastodon.nl
2018-11-25T14:41:21Z
0 likes, 0 repeats
@yogthos it can sometimes be handy to have an object carry it's own namespace? Class inheritance can be seen as making a namespace with things imported into it.Still has the .isHit vs .hits problem to which "namespace" you add things. Which is mixed with the issue of order of the arguments. (assuming the object itself is the first argument.)Function overloading might solve this aswel, can just use short names and have the types determine which function it is.. Maybe this is superior.
(DIR) Post #1481616 by jasper@mastodon.nl
2018-11-25T14:42:21Z
1 likes, 0 repeats
@yogthos function overloading is how Common Lisp's CLOS does it, btw.
(DIR) Post #1481617 by yogthos@mastodon.social
2018-11-25T14:46:13Z
0 likes, 1 repeats
@jasper I find the main issue with OO is that you quickly end up with a whole bunch of interdependent state machines, and you have to know their collective state to reason about the system.I think the main value OO traditionally provides is polymorphism, but turns out that works pretty seamlessly in FP as well with stuff like multimethods.
(DIR) Post #1481618 by jasper@mastodon.nl
2018-11-25T15:17:27Z
0 likes, 1 repeats
@yogthos "calculated members" i.e. methods that don't change state are fine though?And class derivation can just be how the overloading works. (also like CLOS)Suppose people might find it odd if a programming language defines a.b to be b(a) and automatically defines these for new structs..Tbh with programming languages, i kindah look to C interoperability and i kindah want the install to be lightweight.. (Suppose python at least doesnt have the latter.. It has a lot of libraries i see..)
(DIR) Post #1481619 by yogthos@mastodon.social
2018-11-25T17:42:27Z
0 likes, 1 repeats
@jasper I would say erlang is a good example of FP flavored OO actually where you can treat actors as communicating objects.
(DIR) Post #1481682 by mvz@mastodon.social
2018-11-25T17:51:18Z
0 likes, 1 repeats
@yogthos @jasper I'm dreaming of an OO language that explicitly differentiates between state machine objects and (lazily) immutable objects.
(DIR) Post #1509287 by mvz@mastodon.social
2018-11-25T17:54:54Z
0 likes, 0 repeats
@jasper @yogthos Reading this I get the feeling the author is not up-to-date on object-oriented design. The hits vs ishit problem should be solved using a third object that knows about fighting.
(DIR) Post #1509288 by jasper@mastodon.nl
2018-11-25T18:43:05Z
0 likes, 0 repeats
@mvz @yogthosfighting.hit(perp, victim)Could interpret above line `fighting` as package or instance of a class. What is the difference then?If it is a package, there no OO happening here. If you add more parameters, you put them after `victim`If it is an instance, it was created, and can have internal parameters.. So likely you'd put the extra parameters in there... Would also mean all the parameters "are together" in the fighting object conveniently. Might have an UnderwaterFighting()
(DIR) Post #1509289 by jasper@mastodon.nl
2018-11-25T18:51:36Z
0 likes, 0 repeats
@mvz @yogthos ... but what happens if you apply this everywhere, it might kindah be an explosion of classes..Do you make an `Interact` class from which `Fighting` derives? Or is the fighting happening in an `Environment`.. Does environment have a function that produces a fighting object specifying how two entities fight..I mean it _seems_ like that makes sense is some contexts, buuut... in others you just want that single function and the rest doesn't end up happening anyway.
(DIR) Post #1509290 by yogthos@mastodon.social
2018-11-25T19:01:30Z
0 likes, 0 repeats
@jasper @mvz and this is precisely the problem that data orientation solves. Instead of working with objects that all have their own behaviors that may or may not work together, you create data pipelines.This approach makes it much easier to handle context specific cases because you don't have to consider them up front. You don't have to know how the data might be used in the future when you produce it.
(DIR) Post #1509291 by mvz@mastodon.social
2018-11-26T09:30:43Z
0 likes, 0 repeats
@yogthos @jasper I'm having a hard time understanding what the problem is. Your objects contain your data. They either work together, or they don't and then you refactor. There is no upfront consideration involved.If it's all just data in pipelines, it becomes harder to change the data structure at the source without changing its use downstream.The question is, in which case is this change harder. I tend to prefer the ease of switching between attributes and methods.
(DIR) Post #1509292 by mvz@mastodon.social
2018-11-26T09:44:25Z
0 likes, 0 repeats
@yogthos @jasper In a sense, when it comes to data, OO allows you to keep all the changes needed when your stored data changes in one place. The rest of the system, whether organized like a pipeline or otherwise, doesn't have to change.
(DIR) Post #1509293 by yogthos@mastodon.social
2018-11-26T16:10:24Z
1 likes, 0 repeats
@mvz @jasper the problem with OO is that each object is a state machine, and your program consists of a large number of such interdependent state machines. Reasoning about large applications built in that style is pretty much impossible in my experience. You can't know what any piece of code is doing without knowing the overall state of the application.The best you can do is run it in a debugger, and hope to get it in the right state to inspect.