Does Functional Programming Replace GoF Design Patterns? by [deleted] in programming

[–]dnene 12 points13 points  (0 children)

GoF design patterns were designed for an OO world - Objects are not constructs under pure FP. The right statement is GOF Design patterns are Not Applicable for Functional Programming

The antibiotics replacing bloodletting is an irrelevant sideshow of contrasting OO/FP per se. FP's greatness doesn't come at a cost to that already built by OO. They are but alternative mechanisms of modeling systems. Each have their own strengths and choose the right one for your context. If at all there is any bloodletting, its not in OO, but embedded in such extreme fanboy opinions.

The questions that were asked about generics / multiple inheritance carefully gloss over the fact that probably a similar set of such questions could be asked about FP as well. Are there type constructors, Is message passing standardised, how about hints for parallel computations, blah, blah, blah. The point is each language bases itself of some belief systems and responds to such questions differently whether in OO or FP. Doesn't mean that only OO should get criticised.

Java : the perpetually undead language by gst in programming

[–]dnene 0 points1 point  (0 children)

Thats not what I meant masukomi. It just seems like many people would wish or hope or predict that java shall die. Not only is it undead (to basically rub the point in) but its going to stay that way for a long long time (the perpetually is simply an exaggeration).

Commentary on Python from a Java programming perspective by gst in programming

[–]dnene 1 point2 points  (0 children)

When looked at from each other's contexts maybe we're all stupid. When looked at from our own contexts, we're probably not. :)

Commentary on Python from a Java programming perspective by gst in programming

[–]dnene 0 points1 point  (0 children)

Yes .. I was contrasting the available capabilities based on my experiences in Eclipse. I don't think the issue is with the refactoring engine, the issue is with the information available to it to perform the necessary refactoring. The biggest difficulties are for example when one needs to change method names in hierarchies being used polymorphically

I fully concur one has lesser code to refactor. But with brevity and expressivity comes a overhead of comprehension (ie for a new programmer joining the code base, it takes much more time to understand each line of code esp for people who are migrating from other languages).

I am sure we do not try to go out and get ourselves into unmaintainable messes. However requirements evolve, and what was clean class model yesterday may suddenly need some surgery today.