Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:I love beating the dealers to pieces (Score 4, Funny) 439

My folks would do that, but they'd take it one step further.

They'd play good cop/bad cop, my dad would really really want the car, my mom would not like it. So they'd argue in front of the salesperson, and my mom would just keep digging in her heels until the price came down a *LOT*.

Then they'd switch roles. Without warning or obvious signal, they'd reverse on the salesperson. Suddenly she's on board, but my dad wouldn't be sure anymore, and not happy about this, or that, or something else, and you know, she made him think about it a bit, and...

The poor salesdroids had no idea what to do, so they just kept going lower. They walked out one time with the sales manager almost in tears trying to satisfy them. When they 'reluctantly' agreed to the deal, he was falling all over himself in gratitude... even though he'd just gotten soaked, badly. Like five figures below sticker, four figures below cost badly.

My dad had been a very successful car salesman way back in the day, and knew every stupid little trick his colleagues would play on the unsuspecting. He quit because he couldn't handle the deceit and dishonesty any more. Flipping it around was highly satisfying to him.

Mom was just kind of evil.

Comment Re:What we need... (Score 2) 129

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.

Comment Re:Thats what I have been waiting for. (Score 1) 129

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. :)

Comment Re:The biggest problem with design patterns... (Score 2) 129

*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.

Comment Re:Patterns over hyped? (Score 2) 129

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.

Comment Re:Patterns over hyped? (Score 2) 129

"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.

Comment Re:The biggest problem with design patterns... (Score 2) 129

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.


Submission + - If you had one last lecture to give...

Jason Smith writes: Randy Pausch, a VR researcher at CMU known best for co-founding the Entertainment Technology Center, and being the creator of the Alice programming environment, did. He's been diagnosed with terminal pancreatic cancer, and has just a few months to live. This is his last lecture: "Really Achieving Your Childhood Dreams". I watched the webcast live on Tuesday, and... I couldn't look away. http://www.etc.cmu.edu/global_news/?q=node/42 It's almost two hours, all told, but worth every second spent. (I just noticed that it is, ironically, number 42. How appropriate.)

Slashdot Top Deals

When you make your mark in the world, watch out for guys with erasers. -- The Wall Street Journal