Sign. Yet another discussion full of trolling pros and cons of FP vs. OO
Guys, listen to Simon Peyton Jones himself: "Haskell is useless". He's discussing stuff with Erik Meijer in this video:
What's wrong with Object-Oriented Programming and Functional Programming
81–90 of 145 posts
Re: What's wrong with Object-Oriented Programming and Functional Programming
#82I think all this blog post really highlights is that you can get a PhD without understanding OOP or functional programming.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#83Earlier 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…
Indeed; I'm used to writing systems software, so user interaction tends to elude me :). That being said, I would dare say that the business layer is the one which would benefit the most from a FP perspective. I can think of dozens of bugs in my code that originated in my inability to correctly keep track of what was otherwise needlessly exposed state. Being many layers closer to the silicon, I don't actually use any…
Indeed, many languages would benefit simply from having modifiers that reverse the typical use of "const". Make everything immutable / side-effect-free by default, and add a "mother may I" keyword that allows mutation / side-effects without giving a compile error.
Hopefully, programmers would learn to avoid writing code that requires the "stomps-all-over-shit" keyword except when they really did need it. (assuming tail call elimination for simple loops)
Re: What's wrong with Object-Oriented Programming and Functional Programming
#84This is solved long ago, without taking any extremes. In short, a language should be mostly-functional, which means when you really need to overwrite a value you just do it. In well-researched languages, such as Scheme you have set!, in CLs you have setf. All the monadic stuff (remember, that a monad is nothing but an ADT - Abstract Data Type) is already an extreme, because one must structure the code in a certain wa…
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.
> You can't have monads in Scheme due to the lack of a type system.
You can have monads in almost any language. The lack of static typing means you don't have static type safety with them, but monads aren't any different than anything else in that regard.
> 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.
How does not having static typing prevent you from abstracting over monads? You can still write functions that work with any possible instance of a monad in languages without static typing.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#85Earlier quoted context omitted.
> 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 calc…
This is another problem with Haskell: comments like this. But in order to be helpful, let me explain why. > technically Haskell is non-strict, not lazy. Now, see, I don't care. Neither does anyone really other than PL researchers. I mean, I can care in my spare time if I like spending it on PL research, but when I write a 2 MLOC software for a large customer, I couldn't care less whether "technically" it's "non-stric…
Laziness is an implementation detail that permits equational reasoning and a declarative programming model; the only reasons it's even useful to be aware of haskell's evaluation strategy are 1) to know that it isn't strict (if you're already a programmer), and 2) to solve and anticipate space leaks in production code (if you're using it for Real Work).
Anyway, you seem pretty [sure](http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm) of your opinion so it's probably not worth further discussion.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#86"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…
No, what it means is that instead of documenting pattern templates that you have to fill in with the bits that pertain to your use case, you can provide library functions (or, in some languages, library macros) that take well defined arguments and do what the pattern is intended for, rather than providing boilerplate fill-in-the-blanks code Mad Libs.
Instead of books of design patterns, you have code libraries with APIs, and you don't have to rewrite the code following the pattern for each new project.
The less expressive the language is, the more need there is for template-style design patterns. The more expressive the language is, the more patterns can be implemented in reusable code.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#87Is there a blend between the two? I really like loops...
Re: What's wrong with Object-Oriented Programming and Functional Programming
#88Earlier quoted context omitted.
This is another problem with Haskell: comments like this. But in order to be helpful, let me explain why. > technically Haskell is non-strict, not lazy. Now, see, I don't care. Neither does anyone really other than PL researchers. I mean, I can care in my spare time if I like spending it on PL research, but when I write a 2 MLOC software for a large customer, I couldn't care less whether "technically" it's "non-stric…
The laziness-vs-non-strictness part pretty much nailed one problem beginners may have with the Haskell community. On the other hand, I don't think your 99.something are a feature of humanity, they are the result of the last decades of mainstream programming development. It took me less than a year of on-and-off Haskell hobby fiddling to find functional and non-strict less awkward to think in than imperative and stric…
I think his point is that from an adoption perspective, whether or not it's actually a genetic feature of humanity or merely might as well be is basically irrelevant. Either way, it's a giant hurdle from a practical perspective, especially a commercial one.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#89This person is pursuing a PhD in Computer Science?
"If you look deep into them, monads make programs complicated and hard to write, and monad transformers are just ugly hacks."
Wow. Just... wow.
Re: What's wrong with Object-Oriented Programming and Functional Programming
#90This 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…
It looks like your comment has been "moderated" off the blog. Such a disappointment.