81–90 of 123 posts
Earlier quoted context omitted.
Personally most of the time id rather have 10: main(int c,char v){return!m(v[1],v[2]);}m(char s,char t){return t-42? s?63== t| s== t&&m(s+1,t+1):! t:m(s,t+1)||*s&&m(s+1,t);}
But I meant return p, not some gibberish that obviously should be formatted better. It's just that for some developers "formatting better" doesn't translate to "make it shorter and sweeter".
Say I want to migrate from OOP to Functional and avoid doing things the wrong way the first time, like we supposedly did with OOP and it's too late to fix. What book/code/etc is a good reference for high-quality, practical proven Functional programming best practices?
http://dev.stephendiehl.com/hask/
As for "best practices", there are some interesting answers on http://stackoverflow.com/questions/842026/principles-best-pr...
There certainly aren't as many 'design patterns' style things in functional programming as there are in OO. In general, it seems to be because:
- FP systems are much smaller than OO systems (due to conciseness and not as much large-scale use)
- FP favours immutability over encapsulation, so you can re-use existing map/fold/filter/etc. functions rather than having to rewrite them in small pieces spread throughout your app. Hence you don't need to decide how they're implemented.
- Pure functions take everything in via arguments and give everything out via return values. There aren't many ways to get that wrong. In OO any method can affect the application in all kinds of ways, so there are all kinds of ways to get it wrong, requiring best-practices to avoid them.
- In FP, we're generally turning some input into some output. If we're writing code that doesn't seem to get anything from our input closer to something in our output, we should stop and think for a minute. In OO we're encouraged not to think in terms of solving a problem: instead we try to define ontologies and hierarchies, implement models of the domain, etc. only then, once we've bootstrapped a simulation of our business entities and their interactions, do we write the actual code for the problem we have: `Order::newFromFile('input.csv').ship()`
Say I want to migrate from OOP to Functional and avoid doing things the wrong way the first time, like we supposedly did with OOP and it's too late to fix. What book/code/etc is a good reference for high-quality, practical proven Functional programming best practices?
* Real-World Functional Programming - With Examples in F# and C# by Thomas Petricek
This helped me a lot because I'd been working solidly with C# for 8 years leading up to it (C++ before, and C before that), so I was very much in C mode. It presents reasons for the functional approach and shows side-by-side C# and F# examples of the various topics covered. It also takes a more practical approach, rather than 'yet another fibonacci example' which you'll see on lots of functional programming tutorials.
* Programming in Haskell by Graham Hutton
Basically a text-book on learning Haskell, but covers a lot of fundamentalist functional thinking.
* Pearls of Functional Algorithm Design
Once you have the basics of functional programming knocked then go for this. It teaches you how to think about reducing problems.
What I would love to see monthly or quarteryearly "competition" between functional and object oriented programmers. For each competition a jury selects a problem and then everybody can try to solve this problem as nice and clean as possible for his preferred programming language / paradigm. The best solutions are then judged / commented on by experts and put on a website. By this you would have perfect examples how e…
It would be interesting to do a contest where each month a jury selects one of those problems and everyone focuses on that problem. The "boilerplate" is already there.
Earlier quoted context omitted.
The same goes the opposite direction, though. While I'm sure your actual arguments are more cogent, simply complaining about something specific isn't an argument against OOP in general. And I doubt that anybody claims Java isn't verbose, or that the IDE "handles" it--regardless of who's doing the typing, Java is verbose. The only people that hold up Java as a good example of OOP are people that don't really know any…
He does argue that OOP introduces complexity without any unique strengths.
Having programmed a lot of OO in Python and PHP (yeah, yeah, I know, but its OO implementation is actually rather good), I always felt OO was a pretty good way of doing things... Until I hit the Java scene. Boy, is it a big mess. There I found some of the worst unreadable, unmaintainable, ungrokable, complex and brittle code I've ever seen. And that's not an exception, rather it's the standard. I suddenly understood…
One of the major points of the article is the "no True OO Programmer" fallacy: this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant. If I complain that Java is verbose, I’m told that True OOP Programmers let the IDE take care of some of the boilerplate, or perhaps I am told that Scala is better. If I compl…
It would be quite simple to turn the argument around by doing the exact opposite thing - cherrypicking nice things from OO languages and warts from FP languages and then use the same argument about scotsmen in the other direction.
Arguments about whole categories of languages when not limiting yourself to least common denominators end up stupid pretty fast as it is always possible to find one example or another that fit the point you want to claim.
Earlier quoted context omitted.
One of the major points of the article is the "no True OO Programmer" fallacy: this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant. If I complain that Java is verbose, I’m told that True OOP Programmers let the IDE take care of some of the boilerplate, or perhaps I am told that Scala is better. If I compl…
One really big problem with how your argument is structured is that you cherry pick warts from OO languages, while at the same time cherry picking good solutions from FP languages. It would be quite simple to turn the argument around by doing the exact opposite thing - cherrypicking nice things from OO languages and warts from FP languages and then use the same argument about scotsmen in the other direction. Argument…
I'll sink back into the corner now....
Another 'the sky is falling' article ;) Can someone provide a TL;DR who worked through the entire write-up? When I hear 'OOP must die' I can't help but think that we're throwing away the good bits too and will reinvent the wheel in a few years. It would be good to define the absolute essence of OOP first, because in 30 years it has been overloaded so much with different meaning that it means everything today. For ins…
> To me the pragmatic essence of OOP is that it groups the data and the code which works on that data. If there's a pure C library which has a function to create some sort of 'context' and then has functions which take a context pointer as argument, then this is object-oriented to me. Most other features, like classes, inheritance, runtime polymorphism is just sugar-topping; useful in some cases, but not the essence.…
Are the OOP language features the essence of OOP? 'Everything is an object'? Multiple inheritance?
if an object can be reduced to a symbol like a void-pointer to data or a function that returns data and this object can be related to others on a graph, then that's still general enough.
Imperative Programms as well as Object models can be well organized in graphs. The CPU or bytecode doesn't know about objects anyway. So it's an abstraction and you need to applay that in a moderate fashion, depending on the complexity of the problem, so for simple or efficient procedures imperative style is not to be replaced by OOP. fopen, fread etc. all are abstractions of underying system calls, but depend on speed, so light OOP is a good fit there,
Having programmed a lot of OO in Python and PHP (yeah, yeah, I know, but its OO implementation is actually rather good), I always felt OO was a pretty good way of doing things... Until I hit the Java scene. Boy, is it a big mess. There I found some of the worst unreadable, unmaintainable, ungrokable, complex and brittle code I've ever seen. And that's not an exception, rather it's the standard. I suddenly understood…
One of the major points of the article is the "no True OO Programmer" fallacy: this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant. If I complain that Java is verbose, I’m told that True OOP Programmers let the IDE take care of some of the boilerplate, or perhaps I am told that Scala is better. If I compl…
A: Java is too verbose.
B: Java isn't really a OOP language.
This is more like:
A: Java is too verbose.
B: Sure, but that's a statement about Java, not a statement about OOP.
If you list a bunch of criticisms of OOP languages, that doesn't mean that those criticisms automatically become criticisms of OOP as a concept, merely those of the languages themselves. Especially when you can find OOP languages that don't match that criticism. Java is verbose, yes. But it doesn't mean OOP languages are verbose (what the article author would like to claim), and it doesn't mean that Java isn't an OOP language (what the author believes other people use to deflect the criticism). It means that Java is verbose.
Earlier quoted context omitted.
One of the major points of the article is the "no True OO Programmer" fallacy: this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant. If I complain that Java is verbose, I’m told that True OOP Programmers let the IDE take care of some of the boilerplate, or perhaps I am told that Scala is better. If I compl…
One really big problem with how your argument is structured is that you cherry pick warts from OO languages, while at the same time cherry picking good solutions from FP languages. It would be quite simple to turn the argument around by doing the exact opposite thing - cherrypicking nice things from OO languages and warts from FP languages and then use the same argument about scotsmen in the other direction. Argument…
Any attempt to fuse aspects of other languages or paradigms with OOP in order to mitigate the listed problems are dismissed as "not OOP" to serve the purpose of illustrating that OOP sucks.
My experience is that any pure paradigm has limited context in which it's ideal and many pitfalls outside that context. OOP is no different. Foolish adherence to consistency, hobgoblin of little minds, etc.
Where I will agree, at least in spirit, is that OOP has a few different aspects, including the implementation in a given language, the current understanding of best practices for a given context, and the cult of context-independent "design correctness". That last one has major issues.
When the cult drives the implementation, you get high-ceremony languages like Java. And when the cult drives best practices, you get maintenance issues like those currently being acknowledged around invasive unit testing, etc.
The key there isn't the design paradigm, IMO, but the fallacy of trying to apply a best practice without understanding why it's useful or analyzing whether it's the right thing to do for the current situation.
An analogy would be normalizing a relational database. There's a "correct way" to do it, which in theory reduces maintenance if you go to third+ normal form. In practice, knowing when to relax normalization is the difference between success and a mess. So goes DRY, SOLID, etc.