3 ms·

> Bundling behavior together means the behavior is out of the control of the object; the object's identity now becomes a critical part of the operation being p

> Bundling behavior together means the behavior is out of the control of the object; the object's identity now becomes a critical part of the operation being performed. IMO, putting the focus on behavior is the wrong approach here. Why? Do you have an example to better explain? If find people rarely talk about the evaluation criteria for which approach to programming is better. That is, what are you optimizing for?

trashburger 3y ago
I'll respond in reverse order ;) > That is, what are you optimizing for? I'm optimizing for other programmers to easily be able to see how objects fit together and behave, and for them to be able to easily extend the system without touching the behavior of other components (which you cannot do if you bundle behavior together). I've slowly shifted towards this approach throughout the last few years of my programming journey. > Do you have an example to better explain? Let me make an attempt to do so. Let's say that you have an HTML form builder in code (this is something I'm currently working on, if you can't tell ;). Your form builder lets you design the form such that you can split the form into sections, rows and columns. You might design a registration form like this, for example (I'm using Python-like pseudocode here): layout = FormLayout( Section( title=_("Account information"), contents=Column( Field("username"), Row( Column(Field("password")), Column(Field("password_repeat")), ), ), ), # etc. you get the idea ) Now, how would I go about rendering this into a tree? If I were to take the approach that the article suggests, I would have to do something like this: def render_element(element: Element) -> SafeString: # Let's use Python 3.10's match as an analogue for the Dart switch match element: case FormLayout(children): return "".join(render_element(child) for child in children) case Column(css_class, children): return format_html( '<div class="{css_class}">{children}</div>', css_class=css_class or "col-md", children=mark_safe( "".join(render_element(child) for child in children), ), ) # case Row, Field, ... As you can probably tell, this is bound to get super unwieldy over time. And this is just for one property of this HTML form builder; now imagine if we had to do some operation to the tree (like checking all fields in a form are actually rendered)! You might, at this point, suggest that we could just split the behavior into different functions... and that would just make us re-implement the dynamic dispatch system that's found in object programming already ;) You can see how we tend to move the behavior to the object in this case, because it lets each object only worry about its own behavior. I hope this helped with giving a bit of an idea of why I'm for a more object programming-based approach over the pattern matching described in the article.
- grumblingdev 3y ago
  It's interesting. I've gone the other direction. Everything as functions. I've realized that things always need to change in unexpected ways. Objects are sticky, people just cram stuff into them instead of re-thinking the hierarchy properly. There probably exists a really nice and cleanly separated object-hierarchy for a codebase at a given point in time, but requirements always evolve too rapidly to enjoy this for too long.
  - trashburger 3y ago
    I believe this to be an artifact of our current paradigm of software development, which is based purely around static "batch processing" where the software can't be molded easily. (I didn't want it to come off as a plug, so I didn't add it to my original message, but I'm working on something to solve that.) To get a better idea of what I think is the better approach, check out these talks: Tudor Gîrba - Moldable development - https://www.youtube.com/watch?v=Pot9GnHFOVU https://www.youtube.com/watch?v=Pot9GnHFOVU Jack Rusher - Stop Writing Dead Programs - https://www.youtube.com/watch?v=8Ab3ArE8W3s https://www.youtube.com/watch?v=8Ab3ArE8W3s
    - grumblingdev 3y ago
      Oh yes, I'm super interested in this space too. Really waiting for one of these ideas to breakthrough to mainstream.
- toastal 3y ago
  I think a lot about how these things might look in a ML-family layout : Element → SafeString = FormLayout [ Section { title : _ "Account information", ; contents : Column [ Field "username" ; Row [ Column [ Field "password" ] ] ; Column [ Field "password_repeat" ] ] ] ] } (* etc. you get the idea *) ]

trashburger 3y ago

I'll respond in reverse order ;) > That is, what are you optimizing for? I'm optimizing for other programmers to easily be able to see how objects fit together and behave, and for them to be able to easily extend the system without touching the behavior of other components (which you cannot do if you bundle behavior together). I've slowly shifted towards this approach throughout the last few years of my programming journey. > Do you have an example to better explain? Let me make an attempt to do so. Let's say that you have an HTML form builder in code (this is something I'm currently working on, if you can't tell ;). Your form builder lets you design the form such that you can split the form into sections, rows and columns. You might design a registration form like this, for example (I'm using Python-like pseudocode here): layout = FormLayout( Section( title=_("Account information"), contents=Column( Field("username"), Row( Column(Field("password")), Column(Field("password_repeat")), ), ), ), # etc. you get the idea ) Now, how would I go about rendering this into a tree? If I were to take the approach that the article suggests, I would have to do something like this: def render_element(element: Element) -> SafeString: # Let's use Python 3.10's match as an analogue for the Dart switch match element: case FormLayout(children): return "".join(render_element(child) for child in children) case Column(css_class, children): return format_html( '<div class="{css_class}">{children}</div>', css_class=css_class or "col-md", children=mark_safe( "".join(render_element(child) for child in children), ), ) # case Row, Field, ... As you can probably tell, this is bound to get super unwieldy over time. And this is just for one property of this HTML form builder; now imagine if we had to do some operation to the tree (like checking all fields in a form are actually rendered)! You might, at this point, suggest that we could just split the behavior into different functions... and that would just make us re-implement the dynamic dispatch system that's found in object programming already ;) You can see how we tend to move the behavior to the object in this case, because it lets each object only worry about its own behavior. I hope this helped with giving a bit of an idea of why I'm for a more object programming-based approach over the pattern matching described in the article.

grumblingdev 3y ago
It's interesting. I've gone the other direction. Everything as functions. I've realized that things always need to change in unexpected ways. Objects are sticky, people just cram stuff into them instead of re-thinking the hierarchy properly. There probably exists a really nice and cleanly separated object-hierarchy for a codebase at a given point in time, but requirements always evolve too rapidly to enjoy this for too long.
- trashburger 3y ago
  I believe this to be an artifact of our current paradigm of software development, which is based purely around static "batch processing" where the software can't be molded easily. (I didn't want it to come off as a plug, so I didn't add it to my original message, but I'm working on something to solve that.) To get a better idea of what I think is the better approach, check out these talks: Tudor Gîrba - Moldable development - https://www.youtube.com/watch?v=Pot9GnHFOVU https://www.youtube.com/watch?v=Pot9GnHFOVU Jack Rusher - Stop Writing Dead Programs - https://www.youtube.com/watch?v=8Ab3ArE8W3s https://www.youtube.com/watch?v=8Ab3ArE8W3s
  - grumblingdev 3y ago
    Oh yes, I'm super interested in this space too. Really waiting for one of these ideas to breakthrough to mainstream.
toastal 3y ago
I think a lot about how these things might look in a ML-family layout : Element → SafeString = FormLayout [ Section { title : _ "Account information", ; contents : Column [ Field "username" ; Row [ Column [ Field "password" ] ] ; Column [ Field "password_repeat" ] ] ] ] } (* etc. you get the idea *) ]