Hacker News Reader

It appears to me that almost everyone who commented on my comment completely missed the point, even though i made it three different ways.

Why do people focus on paragraph 2, when paragraph 5 is where i make the real point? Facing a big coding challenge is hard, and having an abstract language for describing how to structure a solution is valuable to the point of protecting sanity. I have a few theories. One theory is that most of these people are technical experts. They're equipped to consider technical issues, but not much else. When all you have is a hammer, all you can see are the nails.

fyi i don't understand why you're getting downvoted, and touché.

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 do the right thing. I couldn't get away with a simple interface because there's some weird shared state. The graph coloring allocator is hard, and will take me some time to get ready.

Facade is kind of code for a leaky abstraction. It communicates a lot about how the api really works. Most of the stuff in GoF got picked over and teams took what they needed. Are you doing design patterns? well, kinda. In that sense, i think it did a lot in the Christopher Alexander spirit.

The original author wasn't wrong, just look at FactoryFactoryBuilderFactoryMadness from java's crazy times. But i don't think that's a fair characterization of the entire field of programming.

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 riddance, the whole thing was a farce that spawned factoryFactoryFactories and newbies constantly asking how to implement a singleton because actually they wanted glorified global variables because they can't program properly.

Where the GoF completely failed, javascript, ironically, saved us (with Crockford doing the nudging). It forced functional paradigms, lambda expressions, anonymous types, function objects, etc. into the mainstream languages where lisp had failed and almost overnight made design patterns obsolete. It fundamentally changed how we programmed so that the problems the patterns aimed to solve weren't problems any more.

Design patterns aren't obsoleted by JavaScript; they've just been given trendy new names like reducers and sagas.

Precisely. Each language and domain of programming gets its own set of patterns. Some patterns are obsoleted (by virtue of being unneeded, or baked into the language), some new ones are created. Some are amalgams of old ones.

This is the way of the world, design patterns are intended to offer a language, and languages evolve. The uniqueness of design patterns to certain domains/languages can be seen as equivalent to the jargon between different technical fields. It doesn't mean that one set of jargon is obsoleted, it just means it's inappropriate. The failure, if any, in our world (programming) is to recognize and emphasize that different levels of programming, different languages, different operating systems, require different jargon and patterns and approaches.

> And good riddance, the whole thing was a farce that spawned factoryFactoryFactories and newbies constantly asking how to implement a singleton because actually they wanted glorified global variables because they can't program properly.

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.

Just some comments to your response.

`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 actually rather a domain model that mirrors the relational layout exactly, as this reduces my time spent in some god unknown framework who is over-engineering with `design patterns`.

`These are design techniques that are appropriate in some situations, but not in others`

Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others? Otherwise you're just kidding yourself.

'Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others? Otherwise you're just kidding yourself.'

Really? This requires proof? I would have thought it was self evident. Take the Flyweight pattern mentioned previously - appropriate when you have thousands (millions, billions...) of entities and memory is constrained.

How can it be self evident? You made a statement saying `Some are appropriate for some situation but not others`

You've listed one example of Flyweight, but without any sources to backup the claim it's appropriate when memory is constrained.

The whole premise of the GoF book is to offer patterns that are helpful in certain situations. They describe when a certain pattern will help and when it will not in detail. They also take care to tell you that you should think carefully before using a pattern and consider all the alternatives to be sure you're using the right tool for the job (or maybe a pattern that isn't in the book would work too of course)

To use the building architecture analogy FTFA, the "door" design pattern is good for some circumstances and the "window" pattern for others. This is the same thing. Not sure what proof you're after?

It's a great collection of patterns that you can pick and choose from, not the be all end all, and totally worth reading even if you only get 1 idea for how to solve a problem from it

I'm not sure if you're seriously questioning, or if you're trying to win an argument.

i'm going to go with the notion that you're genuinely curious.

I worked on a project with grids, an editable table like an excel sheet. Each grid, row, column, and cell could be styled. Font as Arial, Comic Sans ...; Color as rgb; padding top, left...; background color as rgb; Alignment as left, right or justified; format as freeform string, integer, float money or regex; decimal separator as . or , ; thousands separator as . or ,; and a whole bunch more.

The first cut just naively associated a style struct as part of each cell's data. Several customers complained that grids were very slow to start up, a few complained that they were running out of memory. They were using very large datasets for the grid, and the naive implementation wasted a lot of time on initialization, and a lot of memory on duplicate representation of style.

In retrospect it was a stupid mistake to make. We'd only tested against small amounts of data on relatively fast machines. Customers were using millions of rows.

The solution we went with was the aforementioned pattern. it saved a ton of memory and a ton of time avoiding all of that initialization. There were a few rounds dealing with smart lookup of style based on cell, row, column, and overall table.

My c++ is rusty, but i'm a little baffled by your confusion. Iterating over data structures in a uniform was was kind of a big deal back in the day. IIRC, implementing preorder, inorder and postorder iterators for a binary tree was homework. Have iterators fallen out of fashion?

I don't have a peer reviewed paper paper indicating flyweight is helpful. I don't have a peer reviewed paper saying multiplication is better than looping over adding m to itself n times. It's just better.

Some of them are mostly stupid, ala singleton. Of course even stupid singleton is a nice place to stick environment variables, because they are globals. I never thought decorator was all that great. I really like composite, but i like tree representations that i can recurse over.

If i had a scale, where you could place code on one side, and a design pattern on the other side, and it would balance if adding the design pattern was worth it, i would give it to you. To my knowledge, no such thing exists.

If you have questions, i'll try to answer. here or jfoutz at gmail.

It says so in GoF. The example in the book is having an object represent each character on the screen. You don't want to pay the overhead of an object for each byte in a file, so you use flyweight to share all the instances of each character.

> Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others?

It's hard to say what you mean by this. I have difficulty believing that you think that a technique used in one situation is always going to be the best technique to use.

As someone has already graciously described situations where Flyweight can be used, perhaps something simpler than that like the Singleton can be illustrative.

The OP opined that the Singleton is only useful to people who don't know how to use a global variable. If that were the case, it would not be useful at all. In fact, it's usually something to stay away from. However, it absolutely shines when you want to make sure that an entity's constructor is only called exactly once.

There are many situations where you need to do this -- often when interacting with hardware, this kind of thing is crucial. As the OP suggested, though, it's easy to misuse this pattern.

Spoken like a true perl programmer

> Why do people focus on pages 4, 5, and 6 of a 13-page talk, and forget all about slides 8, 9, 10, 11, 12, and 13

From a sample of one i.e. me it might be that they aren't forgetting slides 8+, it could be they just didn't bother getting that far.

I got as far as the Iterator example where he, effectively, says that there's no such thing as an iterator pattern because perl has a list iterator built in. Having read that, I didn't feel a huge drive to continue reading the rest.

I appreciate that's probably a failing on my part, it is unlikely to have been a huge drain on my life and I might have learnt something. But that was the path I took. I have a funny feeling others may have done the same.

EDIT: I have felt sufficiently guilty that I have read the rest. If I understood correctly, the author doesn't think that GOF design patterns are the same as Christopher Alexander's design patterns. He thinks that Alexander's patterns are important and applicable to software. He doesn't really say why.

It wasn't a huge drain. It wasn't particularly informative. The Iterator pattern is definitely a thing. Don't feel a pressing need to read Alexander's book again.

The takeaway I got was that in software as in building architecture, the design should result from a conversation between the architect and the users. Christopher Alexander's book presented a shared vocabulary that allows the eventual users to specify at a high level what they want ("entryway transition", "varying ceiling heights", etc) for the architect to synthesize into a coherent whole.

Christopher Alexander patterns are about the conversation between the maker and the user; GoF patterns are about the conversation between the maker and their tools.

If we drop out of the conversation about design patterns altogether and look at that kernel of the argument, I think there's a very valuable point there: makers need a way to effectively communicate with their users at the correct level of abstraction. This generally necessitates a design language that is useful to both parties.

Users don't care if their data is being stored in a relational database, or document store, or flat files; they just care that it's persisted. Linus Torvalds didn't build git because he wanted a content-addressable tree of objects, he wanted fast, distributed source code management with protection against data corruption.

Talking to our users is one of the hard problems in software architecture.

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.

Trivially, this is as impossible as not offending anybody.

That saying was before the internet, though. There are plenty of people who read something to say what they want it to say, and no amount of planning will ever change that.