This ignores the rise of effect systems, which take monadic effect-handling and place it into the realm of static analysis, where it belongs.
Disciple is the future.
What's wrong with Object-Oriented Programming and Functional Programming
41–50 of 145 posts
Re: What's wrong with Object-Oriented Programming and Functional Programming
#42Functional programming wouldn't be useful if side-effects didn't exist. So, arguing that functional programming isn't useful because:
> There exists things that are not pure. Side-effects are very real.
Is nonsensical.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#43Earlier quoted context omitted.
>> There are a lot of things wrong with Java, of course, which does not mean that they are also issue of object-oriented programming. Inheritance (sorry...) doesn't work both ways: the fact that a Lexus is prohibitively expensive doesn't mean moving vehicles are prohibitively expensive. But isn't the main point of the article that OOP just doesn't always fit the problem domain, that sometimes you want to model someth…
> But isn't the main point of the article that OOP just doesn't always fit the problem domain, that sometimes you want to model something in a way where forcing it into objects (nouns and verbs) only adds complexity without benefits? Perhaps that's the point of the article, but the fact that a programmer might want to use a paradigm in an unfit manner is arguably not a problem of the paradigm . OOP is fairly foreign…
> not a problem of the paradigm
Correct. The main problem I see with OOP is that some people advocate it as the only correct way to write maintainable code, which, of course is completely wrong. In fact, OOP doesn't translate well to some problems. There are also problems where FP doesn't work as nicely as other paradigms. In short, there is no silver bullet and advocates of any paradigm should be more open about that.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#44Reminds me of this paper;
"The Interactive Nature of Computing: Refuting the Strong Church-Turing Thesis" -- http://cs.brown.edu/people/pw/strong-cct.pdf
"The theoretical nature of computing is currently based on what we call the mathematical worldview. We discuss this worldview next, contrasting it with the interactive worldview."
Re: What's wrong with Object-Oriented Programming and Functional Programming
#45This is a gross mischaracterization of functional programming and basically attacks a straw man--one that's lamentably common when talking about functional programming. I'm going to repost a comment I wrote on the blog. It's long and really needs editing, but I hope it gets my thoughts across. I think the part about OOP is also misguided, but it's so obviously tacked on to a rant about functional programming that I j…
The way Haskell manages side effects is inspired, and I don't think anyone can say that Haskell is not a beautiful and coherent language. I only dabbled in Haskell a bit so I may be wrong, but I think that the problem with the way it manages side effects is that it does so through lazy evaluation, and lazy evaluation is hard to wrap your head around.
So I think that if there is one big problem with Haskell, it is this: you say Haskell is about "software engineering". Indeed, the guarantees it provides may assist with software engineering, but those guarantees aren't free. They require programmers to think and program solely within Haskell's lambda calculus and lazy evaluation framework, which is neither the way people think nor the way computers do (the latter is important when doing performance analysis on your code). This constrained framework also takes its toll on software engineering, then. The question is, therefore, when are the guarantees provided by Haskell worth their price? I think there are cases where they certainly are, and cases where they certainly aren't.
(A tangential point: when thinking about software engineering, there are vital issues that have little to do with the choice of the language. For example, a language would have to be truly magical for me to forsake the JVM's vast ecosystem, runtime linking, and runtime profiling and monitoring capabilities – that's why I won't use GHC in my projects, but may certainly give Frege a try)
Re: What's wrong with Object-Oriented Programming and Functional Programming
#46[deleted]
Re: What's wrong with Object-Oriented Programming and Functional Programming
#47This is a gross mischaracterization of functional programming and basically attacks a straw man--one that's lamentably common when talking about functional programming. I'm going to repost a comment I wrote on the blog. It's long and really needs editing, but I hope it gets my thoughts across. I think the part about OOP is also misguided, but it's so obviously tacked on to a rant about functional programming that I j…
The way Haskell manages side effects is inspired, and I don't think anyone can say that Haskell is not a beautiful and coherent language. I only dabbled in Haskell a bit so I may be wrong, but I think that the problem with the way it manages side effects is that it does so through lazy evaluation, and lazy evaluation is hard to wrap your head around. So I think that if there is one big problem with Haskell, it is thi…
> the way it manages side effects is that it does so through lazy evaluation
This is actually not true. Lazy evaluation forced Haskell to stay pure, but it is purity that provides the tools for constraining effects. You could have a strict Haskell-like language that manages effects in the same way, indeed such languages exist.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#48This article is remarkably low on arguments , despite being so long. Just a few of its gems: > OOP is wrong because of its definition of an “object”, and its attempt of trying to fit everything into it. When that goes to the extreme, you arrive at the notion “everything is an object“. But this notion is wrong, because: > There exists things that are not objects. Functions are not objects. This has two problems: 1. It…
> A typical CRUD application the web kids like to write can be written so that the only side effects involved are in fact modifications of the database, in which case the side effects are confined to SQL. Well, writing the response is a side effect as well, so no. But the business logic itself can (usually) be pure, even if it's sandwiched between effectful layers (web and SQL). And looking at how a well-crafted CRUD…
Well, that's for theory. In practice I have yet to see a big CRUD like Facebook rewritten functional style, and would very interested to check how this magically dissolve the inherent complexity of such a beast.
Until then, I'd continue to think that functional is shiny and sexy but that the proven and pragmatic way to keep complexity in check is still the good old and boring oop way.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#49Earlier quoted context omitted.
>> There are a lot of things wrong with Java, of course, which does not mean that they are also issue of object-oriented programming. Inheritance (sorry...) doesn't work both ways: the fact that a Lexus is prohibitively expensive doesn't mean moving vehicles are prohibitively expensive. But isn't the main point of the article that OOP just doesn't always fit the problem domain, that sometimes you want to model someth…
> I don't think the article condemns OOP in any way except when it becomes a religious dogma that everything needs to be an object, as it is in Java. But Java doesn't make everything an object. The obvious one is that 'primitive types' aren't objects (int, bool, float, etc.), but also Java has hard-wired control structures (for, while, if, try, etc.) which aren't OO (compare to Smalltalk, for example; where "ifTrue"…
My favorite in Java are String instances, which are objects, but adding them with + is not a method call, because Strings are also primitives, sort of, hence + is in fact either eliminated (if adding two constant values) or the code gets translated to a concatenation powered by an ad-hoc StringBuilder instance. The JVM doesn't even pretend that a static method was invoked. It simply pukes some bytecode.
For example there is no interface in Java that you can use to add stuff, because from the language's point of view, adding integers is totally different from adding strings which is also totally different from adding BigIntegers, which is totally different from adding BigDecimals. Well, to be pedantic, Strings addition is in fact concatenation, as Strings are in fact Lists of Chars. I know, not fair to put them in the same bucket.
But, but, wait for it - BigDecimal and BigInteger actually do implement a Number class. But apparently Numbers in Java's vision are not even monoids, let alone rings (because duh, you also have multiplication). Let's not even mention that all real numbers have natural ordering. Like seriously, how can one get this so wrong?
Coupled with the explicit typing needed and the lack of type-classes or anything similar, it means that you simply can't write functions that operate on Numbers, as there is no such thing and you can't implement it by yourself.
People that bitch about Java being too OOP, missed a couple of lessons on their way to enlightenment.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#50Earlier quoted context omitted.
>> There are a lot of things wrong with Java, of course, which does not mean that they are also issue of object-oriented programming. Inheritance (sorry...) doesn't work both ways: the fact that a Lexus is prohibitively expensive doesn't mean moving vehicles are prohibitively expensive. But isn't the main point of the article that OOP just doesn't always fit the problem domain, that sometimes you want to model someth…
> I don't think the article condemns OOP in any way except when it becomes a religious dogma that everything needs to be an object, as it is in Java. But Java doesn't make everything an object. The obvious one is that 'primitive types' aren't objects (int, bool, float, etc.), but also Java has hard-wired control structures (for, while, if, try, etc.) which aren't OO (compare to Smalltalk, for example; where "ifTrue"…
Just once I'd like to see someone lament the "not everything should have to be an object" using as an example a language where everything actually is an object.