3 ms·

Object orientation kills traceability. Classes are instantiated in one trace, then methods are called in another trace, and if something goes wrong in the latte

Object orientation kills traceability. Classes are instantiated in one trace, then methods are called in another trace, and if something goes wrong in the latter, it is not trivial to find the wrong settings passed in the former. I think some functional programming languages solve that by running a good chunk (if not all) of the application in a single trace.

gombosg 3y ago
Yes, this is why we love functional programming! "What happened along the way" equals to the call stack, as long as there is no field mutation involved. And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.
- asimpletune 3y ago
  Yeah, exactly. Referring back to the DI comment earlier... In FP, "DI" is literally just calling a function.
- gpderetta 3y ago
  """The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""
  - afiori 3y ago
    OOP is actually class oriented programming and classes are orthogonal the object/closure duality. For example in php class A { public $a = new B;} is not valid https://onlinephp.io/c/31246 https://onlinephp.io/c/31246 Such a restriction makes no sense in a "closures are a poor man's object" world.
    - gpderetta 3y ago
      Not sure what are you trying to say. My point was that a invoking a function that will act on arguments that have been defined away from the callsite is not a OO specific feature.
- giovannibonetti 3y ago
  > And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time. I think there is still hope on that front. Following structured concurrency patterns like the supervisor model should handle it. See the discussion about "Notes on structured concurrency, or: Go statement considered harmful" [1]. [1] https://news.ycombinator.com/item?id=16921761 https://news.ycombinator.com/item?id=16921761
Blackthorn 3y ago
I disagree. Pretty much any program of enough size, including those written in functional languages, are going to have state that outlives the lifetime of a single call stack.
- preseinger 3y ago
  hopefully not it's certainly not a given
  - Blackthorn 3y ago
    Simple example: the web server that takes in the HTTP requests? That one definitely got initialized outside the call trace that's serving the HTTP request. No different from an object that got constructed and then a method called on it.
    - preseinger 3y ago
      ah, sorry, i misinterpreted what you meant -- obviously, yes, you're correct i thought you meant state that is created from a call stack and persists after that call stack returns -- which is something else

gombosg 3y ago

Yes, this is why we love functional programming! "What happened along the way" equals to the call stack, as long as there is no field mutation involved. And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.

asimpletune 3y ago
Yeah, exactly. Referring back to the DI comment earlier... In FP, "DI" is literally just calling a function.
gpderetta 3y ago
"""The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""
- afiori 3y ago
  OOP is actually class oriented programming and classes are orthogonal the object/closure duality. For example in php class A { public $a = new B;} is not valid https://onlinephp.io/c/31246 https://onlinephp.io/c/31246 Such a restriction makes no sense in a "closures are a poor man's object" world.
  - gpderetta 3y ago
    Not sure what are you trying to say. My point was that a invoking a function that will act on arguments that have been defined away from the callsite is not a OO specific feature.
giovannibonetti 3y ago
> And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time. I think there is still hope on that front. Following structured concurrency patterns like the supervisor model should handle it. See the discussion about "Notes on structured concurrency, or: Go statement considered harmful" [1]. [1] https://news.ycombinator.com/item?id=16921761 https://news.ycombinator.com/item?id=16921761

Blackthorn 3y ago

I disagree. Pretty much any program of enough size, including those written in functional languages, are going to have state that outlives the lifetime of a single call stack.

preseinger 3y ago
hopefully not it's certainly not a given
- Blackthorn 3y ago
  Simple example: the web server that takes in the HTTP requests? That one definitely got initialized outside the call trace that's serving the HTTP request. No different from an object that got constructed and then a method called on it.
  - preseinger 3y ago
    ah, sorry, i misinterpreted what you meant -- obviously, yes, you're correct i thought you meant state that is created from a call stack and persists after that call stack returns -- which is something else