4 ms·
> Does this make sense? Are you asking "Is it possible that purely functional programming is yet another paradigm that, like OOP, is fantastically useful but i
by breckinloggins 13y ago
> Does this make sense?
Are you asking "Is it possible that purely functional programming is yet another paradigm that, like OOP, is fantastically useful but is still destined to be the square peg that is forced into too many round holes?"
If so, then yes, you're making sense. And yes, that's probably what will happen. However, as with OOP, the end result should be a net gain in knowledge and maturity for our very young field and yet another wonderful tool in our tool box.
Having said that, I think that with the "functional wave" comes a bit more understanding that this, too, may not be the perfect fit for every problem. Look at Clojure: they try hard to give you mutability in terms of abstractions that seem to encapsulate what it means for mutability to be a valuable thing.
In Haskell, monads are a great model of "what it means to be imperative". If you think of imperative programming as:
setup();
goLeft();
stop();
lookAround();
pickUp(ball);
turnAround();
Then monads try to make precise just what exactly those semi-colons are doing. To me, the fact that this is hard to understand is mainly the result of the language being the playground of mathematicians who have long since forgotten why such concepts are hard.
In other words: there is a "meta paradigm" going on here and it's just starting to emerge. That meta-paradigm is to provide a language that gives you the abstractions to build the right abstractions to ultimately build the star-shaped peg that fits into the star-shaped hole.
So yes, if you're taking the long view then Clojure might be too opinionated for your tastes (and I have in fact opined on another thread today about what it would take to back slightly away from that lofty perch), then it sometimes can look like yet another oversold silver bullet language. But in the long term, we seem to be converging on something much healthier than the "stop using that paradigm and start using this one because it solves everything!" approach of the past.
- taeric 13y agoClose. I'm more asking if there has been study into ways of plugging the different paradigms together into a whole solution. That is, I firmly believe that each have their strengths. To carry a sports analogy through to this, teams practice different strategies and techniques in isolation so that together they can operate better. Seems most of the reading is about this isolated level of practice. I would love a more holistic view that covers it all. Edit: So, monads help show what happens under the scenes for when you are writing imperatively, but they do little to illuminate when that style is beneficial. My contention is that this is up to the metaphors one has defined for their program.
- breckinloggins 13y agoMe too. I have a personal "research hobby" aimed at exactly this. For your monads example: one of the things I'm looking into is how to have the experts establish the monadic abstraction and have the system gain all of the benefit WITHOUT jRandomCoder at HugeCorp having to understand what a monad is... or even realize he's using one. Obviously Haskell falls short in that area.
- runT1ME 13y ago> or even realize he's using one. Uh, this happens all the time. Scala programmers everywhere are used to the pattern for { a <- optionA b <- optionB } yield ("Both options have values! A = " + a + " B ="+b)
- mathattack 13y agoIt would also seem that referential transparency takes away many real world applications. We need randomness and an ability to read files. This is coming from a big fan of functional programming and removing side effects.