I think that despite all mistakes that are in the article all agree that extreme OOP and extreme FP are almost equally bad and the balance between those gives the best results.
What's wrong with Object-Oriented Programming and Functional Programming
51–60 of 145 posts
Re: What's wrong with Object-Oriented Programming and Functional Programming
#52Have you noticed how easy it is to implement circular data structures or random number generators in C? The same is not true for Haskell. I might be wrong, but, isn't this a circular data structure (or, what they are referring to) http://www.haskell.org/haskellwiki/Tying_the_Knot ? In a language like Haskell, where Lists are defined as Nil | Cons a (List a), creating data structures like cyclic or doubly linked lists…
Yes. oneTwo = 1 : 2 : oneTwo is a circular singly-linked list containing 1 and 2. If you wanted to change the 1 to a 4 though, you would not be able to do so without creating an entire new list. You can use Vector or Array (i.e. fixed-size containers) to make yourself a circular buffer, but the implementation will be very similar to what you would do in C.
Wow. That looks hard. I bet you stayed up all night working on that. ;-)
Seriously: sometimes things are hard because you don't know the language all that well. Consider that possibility.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#53This 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…
>> 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…
Searching for the main point, when the arguments brought forth to support the conclusion are wrong, does not make sense.
From elementary mathematics, A => B only makes sense when A is true, because falsity implies anything. And I know that productivity and all the other traits that matter haven't been proven formally for the paradigms we talk about, but in our flame-wars we could at least pretend to be scientists.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#54This is a low quality article from someone who, given his qualifications, should know better. The criticisms of functional programming languages range from trivially true (you can't be purely functional and have side effects) to incorrect (it is certainly not difficult to create a circular data structure in Haskell - it's easy given laziness). The criticism of OOP is verging on nonsensical. Of course functions can be…
> This is a low quality article from someone who, given his qualifications, should know better.
It really depends which audience this article is targetting (Do you believe that S. Peyton Jones speaks in monads to his mother?). If this article was written in response of a talk between undergraduates in a TA session, it is perfectly acceptable, and even provides links to advanced material for the curious.
> A general definition of an object (following Cook somewhat) is something that satisfies an interface along with some form of dynamic dispatch. There is no reason why a function can't fall under that definition.
Yes, but why have that definition, if you already have functions as builtin types? Conversely, if there's a need for functions as builtin types, why force programmers in using that clunky alternative? That's pretty much the point made by the article: don't corner yourself in one paradigm when others might be better at some tasks.
> As several others have pointed out, the fact that Java doesn't have proper first-class functions is also utterly irrelevant. In fact, it is possible to program in a very pure OOP manner in any language with proper closures.
Careful, the wording is a bit lacking here imho: you join two different ideas and make it seem like the second one validates the first, while it's not the case.
> If the author is representative of the quality of researchers working on programming languages, it's no wonder the field seems stagnant.
That shows you probably don't follow much the field. Anyway, this article doesn't fit your standard (see first point), ergo this man's whole work doesn't, ergo the whole field doesn't? That twice too much stretching from someone who isn't very careful in his own argumentation.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#55Earlier quoted context omitted.
You can't have monads in Scheme due to the lack of a type system. What you can have are instances of monads, but the point of using the concept of a monad is to abstract over it, and to have functions that work with any possible instance.
http://karma-engineering.com/lab/wiki/Tutorial10
Genuinely wondering: does this provide type safety?
Re: What's wrong with Object-Oriented Programming and Functional Programming
#56This 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…
> but I think that the problem with the way it manages side effects is that it does so through lazy evaluation.
This is not so.
> and lazy evaluation is hard to wrap your head around.
technically haskell is non-strict, not lazy. (a + (b * c)) evaluates + then * instead of * then +. Also strictness annotations can change this behavior.
> 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
This is not supportable. You might be more familiar with strict evaluation, but don't pretend its a feature of humanity. All runtimes come with assumptions.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#57Earlier quoted context omitted.
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.
Isn't the side effect returned as an IO type which is later evaluated by the runtime? (I'm talking about Haskell)
Re: What's wrong with Object-Oriented Programming and Functional Programming
#58"The lack of first-class functions is the major reason why there are so many “design patterns” in Java. Once you have first-class functions, you will need almost none of the design patterns." Now this is a very bold statement. I'm dying to hear more on how you can get rid of design patterns with first-class functions. Does it mean getting rid as in: sharing knowledge is not needed anymore and programming becomes art…
FactoryFactoryFactoryClass, most of dependency injection frameworks, anonymous classes, several different one-method interfaces, (such as event handlers/observers), and probably more become unnecessary when you have first-class functions.
Note that it also becomes easier when class types (generally speaking) are available.
Also, one interesting aspect of interfaces is that they act as tags, allowing for stricter formal contract checking (as in: am I registering a function to this Observable which is meant to deal with its events, or is it just a coincidence that the function signature matches?).
Re: What's wrong with Object-Oriented Programming and Functional Programming
#59This 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…
Dabbling really is not enough to show you the problems with your assumptions. You are right that there is a cost, but it is really paid once up-front by each programmer.
I could have written this same comment five months ago, before I started down the long dark tunnel of doom which is to go beyond LYAH and trying to write a real application. I think it was two months before I saw a light at the end of that tunnel - and only recently that I have really begun to feel as productive in Haskell as I previously was in Ruby. At this point, the costs you speak of are paid up and I do not incur them when I write new code. Yes the type system does impose a lot of structure and some boilerplate, but the benefits are profound. Its the sort of statement I did not really fully credit before experiencing myself, but I will say that is profoundly amazing how frequently my code works perfectly once it compiles. This is particularly true when refactoring. I remember sometimes in Ruby despairing to refactor some code because I didn't want to fix all the tests...in Haskell once my tests are compiling they are passing, and the compiler errors are usually very easy to understand and fix (after several months of head-banging frustration).
Re: What's wrong with Object-Oriented Programming and Functional Programming
#60Earlier quoted context omitted.
> 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.
I don't think anybody is claiming that functional programming makes complexity magically go away. The claim is that functional programming (especially when backed by a strong static type system) makes several categories of issues essentially disappear. That's a much more reasonable claim to make.