Live data from Hacker News

Design Patterns – A comprehensible guide

github.com

11–20 of 112 posts

Re: Design Patterns – A comprehensible guide

#11

Object-oriented programming is a disease, and I can't wait until we're collectively done with it. All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language. The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and…

I dislike OOP. It's my least favorite paradigm. The "objects-first" approach to teaching programming was such a bad idea.

All that said, there is a place for OOP. And while a world without OOP would be a better place than a world without FP (if we had to choose), I think you'll be waiting a looong time for that world to materialize.

Re: Design Patterns – A comprehensible guide

#13

Object-oriented programming is a disease, and I can't wait until we're collectively done with it. All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language. The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and…

> arcane toxic names

Oh come on. It's not "arcane" and I don't see how "toxic" has anything to do with the names of these patterns.

Just an inflammatory comment.

Re: Design Patterns – A comprehensible guide

#14

The reason I like Lisp is because programming in it teaches you how to organize your code well using the most basic and important design pattern: the function.

You can implement design patterns with functions, but functions themselves are not a design pattern.

Re: Design Patterns – A comprehensible guide

#15
post #10

Object-oriented programming is a disease, and I can't wait until we're collectively done with it. All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language. The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and…

This sort of heated rant makes for a bad HN comment, regardless of how correct your views are. It leads to flamewars, which we don't want here, so please don't post like this. Even if you took out the rantiness, the comment is still too generic to actually be saying anything. So to convert it to a good HN comment, you would need to both de-flamebait it and add information (e.g. specific examples).

i enjoyed the conviction.

Re: Design Patterns – A comprehensible guide

#16

Object-oriented programming is a disease, and I can't wait until we're collectively done with it. All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language. The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and…

Why is it a disease, honest question.

Re: Design Patterns – A comprehensible guide

#17

Object-oriented programming is a disease, and I can't wait until we're collectively done with it. All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language. The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and…

> All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language.

If you think FP is mutually exclusive with OOP, you understand neither.

OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (something that's still awful to achieve in FP, regardless of the language you pick).

FP operates at a more granular level, basically how you implement your methods.

And by the way, FP has design patterns as well.

FP and OOP are extremely complementary.

Re: Design Patterns – A comprehensible guide

#18
post #10

Earlier quoted context omitted.

This sort of heated rant makes for a bad HN comment, regardless of how correct your views are. It leads to flamewars, which we don't want here, so please don't post like this. Even if you took out the rantiness, the comment is still too generic to actually be saying anything. So to convert it to a good HN comment, you would need to both de-flamebait it and add information (e.g. specific examples).

i enjoyed the conviction.

There is far too much conviction in the world. One of the reasons HN is so enjoyable is that the discussions tend to avoid the heat that you can find just about anywhere else.

Re: Design Patterns – A comprehensible guide

#19

Object-oriented programming is a disease, and I can't wait until we're collectively done with it. All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language. The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and…

Why is it a disease, honest question.

To do OOP good requires a lot of forward thinking and careful planning. Though most of the two are lacking supply when you're dealing with large teams of programmers and you end up with some IFactoryAbstractInterfaceInvoker eg... the kingdom of nouns game.

The other main concern was it was over-hyped with consultants running around to all businesses during the dot net time with xml with no empirical evidence to backup their claims.

The whole OOP was a giant experiment.

Re: Design Patterns – A comprehensible guide

#20
post #14

The reason I like Lisp is because programming in it teaches you how to organize your code well using the most basic and important design pattern: the function.

You can implement design patterns with functions, but functions themselves are not a design pattern.

Why not? They are general repeatable solution to a commonly occurring problem in software design - ie, a design pattern. You had non-structured code, then people started using small chunks of code that you'd jump to and back from multiple locations. It's a pattern, that just happened to get encoded directly into some languages, just like others (Norvig talks about the levels of implementation in his presentation on the subject: http://www.norvig.com/design-patterns/design-patterns.pdf)
Post reply on HN