4 ms·

OOP has never been just about computing. It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written. Whe

OOP has never been just about computing. It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written. When both parts of this process are performed by the same person it loses much of it's value (until the problem gets larger and you need more than one person). As we have better computing tools in modern languages it is more often the same person. It has never been considered more efficient or easier for the programmer alone, just the whole problem solving process in general, especially in teams.

hackinthebochs 14y ago
> It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written. Absolutely this. Discussions around OOP vs functional always seem to ignore this massive boon to productivity that OOP brings. Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win. The trick is to design your objects and operations such that the salient rules "rise to the top" of the stack, and thus can be easily programmed and verified at the highest level of abstraction. Of course a DSL comes with its own drawbacks. Having to learn a new "language", with operations that are sometimes just renaming more basic operations has an extra cognitive load that can't be ignored. This is why there is a threshold of complexity below which you're better off just writing it straight imperative/functional style.
- crntaylor 14y ago
  > Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win. Hold on - how is this a concept specific to object-oriented programming? Creating a DSL for your problem domain and solving the problem in the new language is exactly what functional programmers have been doing for decades! E.g. here's a mini-DSL in Haskell for parsing CSVs, built on top of the Parsec parsing DSL: cellContents = many (noneOf ",\n") -- match up to first comma/newline remainingCells = (char ',' >> cells) -- comma => parse more cells <|> (return []) -- else done cells = do first <- cellContents rest <- remainingCells return (first : rest) eol = char '\n' -- match newline character line = do result <- cells eol return result Building DSLs is most emphatically not something specific to OO programming.
  - hackinthebochs 14y ago
    Of course, anything you can create abstractions with you can create a DSL of sorts. But I think most would agree that OOP is the more natural paradigm for this.
    - papsosouid 14y ago
      Most would agree because most have never used anything other than OOP. That isn't saying anything interesting. I find OOP to be most often awkward and difficult to express the rules of my application in. Functional programming does it quite naturally, as it is all about creating small simple components and combining them to produce larger components. My rules are simply the combination of smaller rules applied in order.
      - se85 14y ago
        This is exactly how I feel also. This simple logic of fitting smaller things together to make bigger things has always delivered superior results for me regardless of the language in use. OOP seems ass backwards to me but everyone I talk to generally doesn't have a clue how FP is different to OOP!
    - swift 14y ago
      If anything it's quite the opposite; most OOP languages are extremely limiting for DSL creation as compared to most FP languages.
  - debacle 14y ago
    The difference, at least in my eyes, is that OO languages have a convention for the grammar of the DSL.
    - tikhonj 14y ago
      At some point--well before Java--sufficiently constrained syntax turns your DSLs into libraries, which tend to be less close in design to the given domain than actual DSLs. Put another way: with Java or Python, you coerce your problem domain to fit the language. With Lisp and Haskell, you coerce the language to fit the problem. I personally like the latter approach, but I suspect it's also a matter of preference.
barrkel 14y ago
Many of the business rules I've seen would be (and often are) better handled by rule engines; and these tend to be functional or functional reactive in nature. There's usually lots of complicated conditions; if the customer is grandfathered in, then apply rules R1, if they got discount X, apply R2X, otherwise apply R2. Then a new set of rules come in and you need to grandfather the old ones in, and so on; the conditions grow like weeds. When you have rule engines designed around decomposing these conditions, they make them easier to develop, test, they can do things like warn you when certain cases are impossible to reach, etc.

hackinthebochs 14y ago

> It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written. Absolutely this. Discussions around OOP vs functional always seem to ignore this massive boon to productivity that OOP brings. Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win. The trick is to design your objects and operations such that the salient rules "rise to the top" of the stack, and thus can be easily programmed and verified at the highest level of abstraction. Of course a DSL comes with its own drawbacks. Having to learn a new "language", with operations that are sometimes just renaming more basic operations has an extra cognitive load that can't be ignored. This is why there is a threshold of complexity below which you're better off just writing it straight imperative/functional style.

crntaylor 14y ago
> Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win. Hold on - how is this a concept specific to object-oriented programming? Creating a DSL for your problem domain and solving the problem in the new language is exactly what functional programmers have been doing for decades! E.g. here's a mini-DSL in Haskell for parsing CSVs, built on top of the Parsec parsing DSL: cellContents = many (noneOf ",\n") -- match up to first comma/newline remainingCells = (char ',' >> cells) -- comma => parse more cells <|> (return []) -- else done cells = do first <- cellContents rest <- remainingCells return (first : rest) eol = char '\n' -- match newline character line = do result <- cells eol return result Building DSLs is most emphatically not something specific to OO programming.
- hackinthebochs 14y ago
  Of course, anything you can create abstractions with you can create a DSL of sorts. But I think most would agree that OOP is the more natural paradigm for this.
  - papsosouid 14y ago
    Most would agree because most have never used anything other than OOP. That isn't saying anything interesting. I find OOP to be most often awkward and difficult to express the rules of my application in. Functional programming does it quite naturally, as it is all about creating small simple components and combining them to produce larger components. My rules are simply the combination of smaller rules applied in order.
    - se85 14y ago
      This is exactly how I feel also. This simple logic of fitting smaller things together to make bigger things has always delivered superior results for me regardless of the language in use. OOP seems ass backwards to me but everyone I talk to generally doesn't have a clue how FP is different to OOP!
  - swift 14y ago
    If anything it's quite the opposite; most OOP languages are extremely limiting for DSL creation as compared to most FP languages.
- debacle 14y ago
  The difference, at least in my eyes, is that OO languages have a convention for the grammar of the DSL.
  - tikhonj 14y ago
    At some point--well before Java--sufficiently constrained syntax turns your DSLs into libraries, which tend to be less close in design to the given domain than actual DSLs. Put another way: with Java or Python, you coerce your problem domain to fit the language. With Lisp and Haskell, you coerce the language to fit the problem. I personally like the latter approach, but I suspect it's also a matter of preference.

barrkel 14y ago

Many of the business rules I've seen would be (and often are) better handled by rule engines; and these tend to be functional or functional reactive in nature. There's usually lots of complicated conditions; if the customer is grandfathered in, then apply rules R1, if they got discount X, apply R2X, otherwise apply R2. Then a new set of rules come in and you need to grandfather the old ones in, and so on; the conditions grow like weeds. When you have rule engines designed around decomposing these conditions, they make them easier to develop, test, they can do things like warn you when certain cases are impossible to reach, etc.