81–90 of 133 posts
Earlier quoted context omitted.
I mean, lots of people can't read for crap, but at some point, some of the failure to communicate has to fall on the one doing the talking.
Actually. It's always the sender's responsibility, not the receiver. Or, as it's been said: It's not what you say, it's what they hear.
Design patterns are good practices that emerge when a language is used by a lot of people. That's it. Nothing less, nothing more. There are two kinds of languages: languages that have design patterns and languages that don't have a lot of users.
The thing very few people seem to get about Design Patterns (in the gang-of-four sense): they are not a Good Thing, desirable and worthy of study in and of themselves. They are a necessary evil to compensate for fundamental deficiencies in C-like programming languages.
Especially object oriented languages.
I remember this whole talk now. I actually have an acknowledgement credit... holy crap. That was a long time ago.
Here's how I see GoF: it was a brand new idea to programmers. GoF was trying to open some eyes to the idea that there were already all these patterns in a lot of software. They called out a few of them. Some are really classic. Some were total misses (how many of you have implemented State?)
GoF was also coming from the Smalltalk world and trying to preach what they'd learned so C programmers could understand it.
So in 2002 when MJ Dominus wrote this, a lot of us were feeling a lot of stress about the rise of Java and C#. A lot of the appeal of these languages was the promise of never having a memory leak. A side benefit was that Java especially didn't enable some of the really risky C++ practices (MI, overloading short circuit operators... basically most of Scott Meyers' "Effective C++" books). But if you were any good at C++, you gave up a lot. Generics were the big pain but I remember at the time really missing the STL library.
MJ was (is?) a Perl / dynamic languages guy. There was vigorous discussion in the "blogosphere" (gag) over the static/dynamic language debate. MJ was basically saying to think bigger than these trivial little patterns. GoF is to software architecture is like nails & drywall are to an architect.
1) Iterators are pointless because perl has foreach. (Which entirely misses the point of why you'd want to abstract the concept of iteration from the container. (Hint: try using foreach on a tree.))
2) A bunch of trash talking about other languages type systems. (Incidentally, even when this was written, those criticisms were untrue.)
However..
3) According to the postscript, we should ignore the bogus parts I just mentioned above and just focus on the parts that are right. I'm guessing this is the "throw spaghetti against the wall and see what parts stick" school of persuasion, where you can just say a bunch of shit that's obviously wrong and then tell people to ignore those bits.
So basically, the point of this talk is "go read Christopher Alexander's book"
Earlier quoted context omitted.
To be fair, it was pretty snarky. It was meant to be silly not hurtful. In my experience, people pick and choose what they need at the time. I don't think it's unreasonable to say conversations like this happen all the time. Dev1: Hey, i need to test my control flow, but i need the register allocator. Dev2: Oh yeah, I put together a facade for register allocation that just does LRU and injects the push/pop pairs to d…
The problem is you buried your point in the 5th sentence in the 5th paragraph of basically a rant. And it's wrong. No modern programmer does that any more. When I first came here 9 years ago people would refer to patterns all the time. But this is the first time I've seen the GoF even mentioned in a year or so. People stopped caring about design patterns years ago because they stopped being relevant. And good riddanc…
Number one on HN at the moment for me is "Async/Await support landed in Firefox Nightly". With Async/Await, instead of explicitly queuing callbacks in the main event loop and then returning control to the main event loop (ala Reactor Pattern), I create a queue of callbacks that are scheduled to run one after the other when each one terminates. This is different from a Continuation, where I queue my current state, schedule a callback to be run and then restore my state.
I often use Rails (not usually by choice ;-) ). Data is mapped from relational tables into objects using a pattern known as Active Record. In this scheme you generally have one model object per table and the model object itself is responsible for writing data to the database. There are other schemes for mapping relational data to model objects. Active Record is very convenient for simple data models, but is not great for more complex systems.
The opinion you express (that modern programmers need know nothing of patterns) is one of the reasons why programmers don't understand the tradeoffs between Reactor, Async/Await, and Continuations. It is one of the reasons I have to pull out my hair dealing with domain object models that mirror relational layout exactly.
I haven't mentioned a single pattern from GoF, but it's all the same. These are design techniques that are appropriate in some situations, but not in others. Even the very, very simple design pattern in GoF are unknown by a large proportion of programmers out there. Things like Flyweight pattern should be basics for any programmer, but most people haven't got a clue. And if I had a nickle for every time I've seen Composite Pattern where one of the terminating objects is not a subclass of the container (with obvious hilarity ensuing), I'd be a rich man.
How many times have I seen people deriding OOP and espousing the advantages of pattern matching? We can write functions that are polymorphic to their parameters so that we can group all the functions doing a particular thing in one place, regardless of type! The same people will chop my hands off if I mention Visitor pattern.
The paradigms you espouse are patterns. They even have names. And they have situations where they are appropriate and where they are not. If you get it into your head that the language designer will tell you how to do it, so that you don't have to know, it will limit your growth as a programmer dramatically. If you think that your programming culture will somehow allow you to escape the need to think about and discuss techniques -- using names, and describing situations where the techniques are beneficial and when they are unwanted -- then you will never understand what you are doing.
I don't for a minute believe that you intend to stay so ignorant, but the words that you type have been used to keep many from improving their abilities beyond basic repetition.
Christopher Alexander's books: https://archive.org/details/TheTimelessWayOfBuilding https://archive.org/details/APatternLanguage It's also worth reading Patterns of Software by Richard Gabriel: http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf who draws heavily on Alexander's work.