Hear, hear. A colleague at IBM Research had one of these on his desk, and it was nothing short of phenomenal.

God yes. One of the early examples I saw of this was a Hello World that ran to a couple thousand lines of code, using every conceivable design pattern at once. It was horrendous.

Engineering is trade-offs, in almost every case. Adding an abstraction to encapsulate a bit of complexity doesn't dodge the fact that under that abstraction you are *adding complexity*. Sometimes the complexity is necessary, and sometimes it is a kludge. Knowing the difference requires understanding what the various underlying concepts you are adding actually mean, how they interact, and what they cost you in terms of implementation or design flexibility given your implementation language, constraints, etc.

The EDPs are a way of conveying that information about the underpinnings of the current design patterns literature, so that the huge amount of information at our fingertips gets new utility... and hopefully so rising programmers can have a smoother introduction to the literature than we did.

I see that as one very useful direction, absolutely. Frankly, this isn't that different than what we do now, in turning a set of concepts of programming (such as data types, functions, and so on) into bits.

The EDPs form a bridge between the higher-level abstractions of the existing design patterns literature, and language constructs. From there, it's turtles all the way down. :)

Do you by any chance mean Kerievsky's _Refactoring to Patterns_? Have a well-work copy on my desk, and between that and Fowler's _Refactoring_, I see a fairly clear path from the EDPs to patterns-based refactoring.

It was one of the use cases, after all. :)

*Absolutely*. To me, one of the biggest wins of design patterns is that they let me quickly solve, describe, or *avoid* problems that others have solved, described, and found ways around.

In fact, the material for the book came from my research in creating a system for the automated detection of design patterns in source code. It was originally intended to find the patterns to help document the system, but it quickly became obvious that the biggest benefit was that it defined the sections of the system that *didn't* need documentation. Other people had already done so. Instead, it let the developers concentrate on the portions of their code that were unique to their implementation. i.e., their innovation.

I find patterns to be incredibly useful, obviously, but they are often most useful not for what they define, but what they *don't*. The negative space of the system, once it is seen as a system of patterns, is where the real fun starts.

I think you understand design patterns better than most people, to be honest. Copying and pasting a design pattern is the worst way of going about it, IMO. The bit that most people seem to miss, is that if it's not what you need, alter it to suit your purpose.

That was actually a main reason for writing this book - to try and provide folks with an easier ramp-up to the existing design patterns literature in a way that got across the point that these patterns are both a) composed of smaller pieces that are understandable, and b) made to be custom-tailored.

It's not the structure of a design pattern that is important, it's the concepts that it embodies. Fulfill those concepts in a way particular to your language, problem, or system, and you're still using that pattern, even if it doesn't look much like the example source provided.

Of course, it really isn't obvious that that's the case when we haven't had a good underlying taxonomy for those concepts... hence the book.

"Unfortunately the Gang of Four book was written partly as a pattern reference, so it's not so easy going as a tutorial for those without either a CS degree or 10+ years programming experience."

Exactly. In my experience as an educator, I've seen both undergraduate and graduate students struggle with the GoF book when handed it with only the edict "Thou shalt do this." What inevitably happens is that they start copying and pasting the sample implementations as rote mantras, instead of seeing the underlying concepts as mutable pieces that they can work with to create a solution that fits what *they* need.

That's where the EDPs come in. They give a ground level set of concepts and taxonomy to start composing the more abstract notions in the GoF text. For those new to patterns, they give an introductory way of approaching the literature, and thinking about even the most basic concepts of programming independent of implementation details. For folks who have been using patterns for years, they give (perhaps) a new way of looking at the tools to give them new uses.

The design patterns literature is full of an immense amount of good information... when it's used well. When it's just copied and pasted, it can easily lead to worse problems.

I completely agree. In fact, in the book I show where some languages, such as C#, have started implementing some of these EDPs as basic primitives. I also show how these ideas are implemented in a number of languages (Java, C++, C#, Obj-C, Python, even straight C in a couple of cases) to demonstrate how the language feature set can radically change how you choose to implement a concept.

Ultimately, that's what design patterns are: concepts. How they get implemented is unique to a language, a problem domain, and a set of constraints and requirements you're working with.

Change the language expressibility, and you change how you can approach the concepts.

So, it can't be that they're targeting their own service people with this change to solve the problem of stripped screw heads. It MUST be that they're trying to screw over DIY consumers?

That makes no sense. A DIY consumer stayed home and replaced their battery. They didn't bring their phone to the Apple store and end up with new screws. This policy self selects against DIYers.

Seems more likely to me that they are trying to avoid paying a royalty for the new angular torx that is designed for tiny screws, so they used this instead. There isn't a regular torx this small.

Nobody intelligent believes in full transparency.

Go back and read that again, to let it sink in once you get past the "OMG this guy is just trolling" knee-jerk.

If there can't be secrecy in negotiations, the people we try to persuade to change or deal will instead pack up their toys and go home.

Quite frequently, the entire key to a diplomatic deal is exactly that it doesn't appear as it seems. Hell, that's made clear in these leaked documents. They make it perfectly clear, for example, that the situation with Libya would be much worse if things weren't done in secret. Since they explicitly made concessions in exchange for asking that we say something nice about them in public.... They couldn't have even asked for that if we had total transparency. So what would we have had to give them instead?

Maybe Assange is a tactical genius, and selectively revealed only the documents that he knew wouldn't cause war. Or maybe he's lucky. The stuff he released could easily have sparked World War 3, between the middle-east and korean/chinese revelations. We may never know which (or we might still end up at war in Korea).

So be careful before you lump everybody who stands up and calls for his head together with Sarah Palin. She's not always fundamentally wrong. She's just not sophisticated enough to understand the details, and she sensationalizes stuff 'cause she's a politician. She doesn't understand the consequences or side-effects of "using cyber tools to permanently disable WikiLeaks", but the overall sentiment is sound. Namely, we need to shut Assange up, and we need to shut his sources up, and we need to get control of the information that passes through our embassies. We just need to do it intelligently instead of invoking terms that we don't understand that amount to cries to nuke stuff from orbit.

I hate to say it, but Hillary seems to be handling this very well (and seems to agree with Palin on the basics).

If he uses electric heat for his house anyway, and needs to light the room anyway, the first law of thermodynamics disagrees with you.

You're fooling yourself.

People love Fox.

He's talking about Austin, not about sane parts of Texas.

The chances of you being caught with an illegal lock pick are, for all practical purposes, zero, unless you're using the lockpick to break some other law.

All bets are off if you decide to keep them in your car on a public road though.

So, yes it may be illegal, but no, you won't go to jail.

I also was counting junk mail.

And I don't think 11 to 20 covers "36 gallon trash bag full per week", but it was the highest option, so I picked it.