Correctness – A paradigm for sustainable software development

Post by pubby » Sat, Apr 06, 2019, 2:04 AM UTC

dragonwriter wrote: post #107

gambler wrote: post #14

>The thing you need to look at if you’re using say, a dynamic language, or object oriented design, is that in the long term, what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? I am sick and tired of the arrogant, willfully ignorant developers toutin…

> However, large-scale systems almost always have state Managing state is a central part of what FP systems do; a normal Haskell program is, in a sense, a function that returns an imperative program for handling stateful interaction. The stateful and stateless parts are clearly distinguished so that the problems associated with state can be managed more effectively and don't make it hard to reason about parts of the…

Post by gambler » Sat, Apr 06, 2019, 2:33 AM UTC

beders wrote: post #128

gambler wrote: post #65

Earlier quoted context omitted.

Sorry, but you're just validating my stereotype of a typical OOP critic. OOP != Java. >OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). Most problems most programmers solve are simulation in some sense. Including DevOps. I wish larger number of people realized this. Things would become much simpler. The problem with class-oriented languages…

You arguments are all nice and dandy - but who uses OOP like this? And you still have the state being all over the place problem. I think I made it clear that OOP is fine if you can afford to live in that space. In practice you often can't. Re the boundary problem: Sending objects over wire doesn't solve it at all, it makes it worse. Object identity for once and incompatible classes between client/server. Hiding data…

Post by hderms » Sat, Apr 06, 2019, 3:22 AM UTC

l_t wrote: post #38

Jtsummers wrote: post #24

Earlier quoted context omitted.

> 1. OOP is a higher-level paradigm than FP , so people comparing them directly usually are missing the point to begin with. [emphasis added] How so?

Not the OP, but I might have some context. I think of OOP as a message passing paradigm . It's concerned with how messages are passed from one part of the system to another. It is not particularly concerned with how those messages are implemented under the hood. In that sense it's a higher level paradigm because OOP is all about building abstractions ("objects") and defining how they communicate, rather than wiring c…

Post by cannabis_sam » Sat, Apr 06, 2019, 4:09 AM UTC

pubby wrote: post #131

dragonwriter wrote: post #107

Earlier quoted context omitted.

> However, large-scale systems almost always have state Managing state is a central part of what FP systems do; a normal Haskell program is, in a sense, a function that returns an imperative program for handling stateful interaction. The stateful and stateless parts are clearly distinguished so that the problems associated with state can be managed more effectively and don't make it hard to reason about parts of the…

Writing stateful code in Haskell is super clunky though. State monads and lens? - Yuck! I'd take an OO language over that mess any day.

Post by int_19h » Sat, Apr 06, 2019, 4:21 AM UTC

agsamek wrote: post #37

gambler wrote: post #14

>The thing you need to look at if you’re using say, a dynamic language, or object oriented design, is that in the long term, what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? I am sick and tired of the arrogant, willfully ignorant developers toutin…

To add more specific examples. If you want to understand OOP idea do not think about Java/C# classes and inheritance. Think about OS processes/IPC or microservices. These are Objects. This is the basic idea behind OOP. Getter/setter is the main anti-pattern of OOP design.