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.
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.
*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.
Agreed. I frequently get compliments on my Keynote presentations along the lines of "How the hell did you DO that?!?". Last week I gave a 104 slide talk in 90 minutes, with questions, and it was a huge hit.
If I have more than a dozen words on a slide, I consider it a bad slide, and break it up... or replace it with an illustration while I just, y'know... talk.
Uh, I think you were reading something else. Maybe FUD?
The store is the single point of revenue, reporting, and auditing. There is no personal audit. If you pay to a store, they are responsible for passing it along *JUST LIKE ANY OTHER SALES TAX*. Your tax reporting burden is... zero. None. Nada. Zilch.
The auditing process is done through the stores. There are already mechanisms for doing this for regular sales tax. The burden to the retail store is minimal as well, *and* HR25 includes financial aid for assisting businesses in setting it up.
There is no auditing.
There is no tax reporting on your part.
As for your stalled checks scenario - bzzzt. Everyone gets the same check, regardless of your income, it has nothing to do with your income level, or how poor you are. You get refunded the amount of sales tax you paid on the minimum amount needed to support the number of dependents you reported. That's it. Think of it as getting the sales tax on your standard deduction back in monthly installments.
I really think you need to read what FairTax is before you start spreading FUD around willy-nilly, it's obvious you've been fed a line.
I came on here to post that, but you beat me to it.
It neatly solves the whole "where are you taxed" vs. "where are you at" issue... when you're in NY, you're presumably paying for food, lodging, gas, etc -> NY gets a cut based on how long you're there. When you're in your home state, your home state gets the rest.
If you spend 36 days working in NY, you're going to be giving NY ~10% of your sales tax, assuming you spend as much (although it's usually more like 'as little' from my travelling). Automatically allocated according to location. Done.
FairTax is the best chance we've had in, well, 60 years, to get out from under the incredibly convoluted, oppressive, easily abused and easily dodged tax system we have now. And we're going to piss it away because fearmongers rule.
Right - I know I certainly have decision points that influenced the long term project design. I don't think either one is *right*, per se, just curious about the technical reasons that led to the choice.
Again, I'm not sure what the hierarchical vs. flat nature of the formats has to do with streaming. Obviously, QT containers can be streamed just dandily, the preprocessing is to provide a series of hints to the server to optimize for network load, client player, etc. The container still stays the same, as a series of tracks inside - one of which can be the data for links. We used the sprites datatype, and got the functionality built in. I *believe* that the MPEG-4 format has the same datatype, but I'd have to check. In any case, the track format allows you to insert the link data on the fly. Worst case scenario, you will have to insert the track as a post-processing step once a user is done annotating. This was the Distributed Manual scenario in the Hypertext paper... allowing multiple users to view the same stream at their own pace, and each marking up as they go, with annotations collated on the server and added back to the file for future use.
Very cool to see someone picking up the baton on this. Have been mildly sad we had to drop it when we did, it was just getting interesting. Would love to continue the conversation either here, or email. http://www.cs.unc.edu/~smithja/ for contact info.
Thanks, I was having a heck of a time getting through to the details due to that lovely/. effect.:)
I'm curious though - why couldn't you annotate while streaming with MPEG-4? (There are a number of open source projects to manipulate MPEG-4, which offers the same sort of multi-track format QT does. *We* just happened to be using QT because back in '98 when OvalTine was started, that was the only thing out there that came close to filling the bill. Now, MPEG-4 does, no QT necessary.) We looked into it, and decided it was in the Future Research list, but rather got distracted by other projects. We didn't see any reason why annotation information couldn't be pushed back to the hosting server to be added to the file. In fact, we described that exact scenario in the paper as an opportunity for distributed markup.
I can understand not getting around to it, but did you run into a technical reason why it couldn't be done, that we didn't see?
I'm not slamming on the work, I think it's a good step forward, I'm just confused by your choice of container is all.
I could swear I gave a talk on something very similar back in 2000 at ACM Hypertext. The OvalTine project at UNC (no, don't ask, it was a silly name) allowed a user to markup video by tracking faces/heads automatically from frame to frame, and attaching a URL to them once. (You could also attach URLs to any other object in the video stream, but the object tracker we had running best at that time was for heads.) Clicking on any object that was so tagged would pop up a browser window (or the appropriate application if it was a 'file:' URL opening a local document).
Since we did this in QuickTime, it also supported jumping within the video stream, or to other video streams via timecodes. The same file format is now MPEG-4... so why on earth didn't these folks just use that? That way, the link information is embedded directly in the movie file, no external files are necessary. They tend to get lost, after all. Any reasonable MPEG-4 player would then be able to be used, it would be using an open standard file format, and they would be showered with admiration for making the process much easier.
"WinFS however allows more then just searching, it is attempting to allow the sharing of data between applications, like a data soup (the Newton reborn on the desktop:-)."
Righto. And that's what CoreData in the 10.4 Preview allows.;) It's all in there.
"If he were to be convicted of murder, it would mean that all drunk driving fatalaties could now be classified as murders as well."
And about high fricking time, too.
If you voluntarily imbibe, then voluntarily get behind the wheel, and voluntarily put other people at extreme risk due to your apparent 'right' to get to the next bar, and you kill someone... you're a murderer, pure and simple. It's no different in my mind than loading a gun and firing into a crowd. Sure, you might not hit someone, and gee, you didn't really *mean* to, you were just putting everyone at a *random* risk, right?
When Teknekron became Tibco, the lawyers never transferred the trademark. Yeah, really stupid. Amazingly so.
It wasn't until they went to get their dander up towards Apple that anybody realized that, whoops, they didn't actually own the name any more.
Looks like a case of legal incompetence, coupled with not perfect corporate research, led to a situation where legally Apple had claim, but Tibco had a use claim. I suspect both parties declared no harm no foul. Apple will discontinue use, Tibco gets nada in cash, both parties avoid a costly lawsuit. Just a guess though.
We're going to just have to agree to disagree on this one for now. The visual orientation, the user interaction method, and the basic apparatus are all quite different.
Hopefully, if you are right, the PTO will deny the patent. (I'm not a huge software patent fan myself, I just disagree with you on the uniqueness test with relation to ClearBoard.)
Slashdot Mirror
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.
Scurrilous cad! Question your elders? Bah!
(Sir should know better than to post when vision is blurry.)
That was a low UID? huh.
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.
Agreed. I frequently get compliments on my Keynote presentations along the lines of "How the hell did you DO that?!?". Last week I gave a 104 slide talk in 90 minutes, with questions, and it was a huge hit.
If I have more than a dozen words on a slide, I consider it a bad slide, and break it up... or replace it with an illustration while I just, y'know... talk.
Uh, I think you were reading something else. Maybe FUD?
The store is the single point of revenue, reporting, and auditing. There is no personal audit. If you pay to a store, they are responsible for passing it along *JUST LIKE ANY OTHER SALES TAX*. Your tax reporting burden is... zero. None. Nada. Zilch.
The auditing process is done through the stores. There are already mechanisms for doing this for regular sales tax. The burden to the retail store is minimal as well, *and* HR25 includes financial aid for assisting businesses in setting it up.
There is no auditing.
There is no tax reporting on your part.
As for your stalled checks scenario - bzzzt. Everyone gets the same check, regardless of your income, it has nothing to do with your income level, or how poor you are. You get refunded the amount of sales tax you paid on the minimum amount needed to support the number of dependents you reported. That's it. Think of it as getting the sales tax on your standard deduction back in monthly installments.
I really think you need to read what FairTax is before you start spreading FUD around willy-nilly, it's obvious you've been fed a line.
I came on here to post that, but you beat me to it.
It neatly solves the whole "where are you taxed" vs. "where are you at" issue... when you're in NY, you're presumably paying for food, lodging, gas, etc -> NY gets a cut based on how long you're there. When you're in your home state, your home state gets the rest.
If you spend 36 days working in NY, you're going to be giving NY ~10% of your sales tax, assuming you spend as much (although it's usually more like 'as little' from my travelling). Automatically allocated according to location. Done.
FairTax is the best chance we've had in, well, 60 years, to get out from under the incredibly convoluted, oppressive, easily abused and easily dodged tax system we have now. And we're going to piss it away because fearmongers rule.
...to Knowledge Navigator, where the screen was also a scanner. Interesting.
Sorry, but it's already 'implemented'. The iPod still supports FireWire just like before.
The *ONLY* difference is that they are no longer shipping the FireWire *CABLE* by default. That's it. That's the only change.
Right - I know I certainly have decision points that influenced the long term project design. I don't think either one is *right*, per se, just curious about the technical reasons that led to the choice.
Again, I'm not sure what the hierarchical vs. flat nature of the formats has to do with streaming. Obviously, QT containers can be streamed just dandily, the preprocessing is to provide a series of hints to the server to optimize for network load, client player, etc. The container still stays the same, as a series of tracks inside - one of which can be the data for links. We used the sprites datatype, and got the functionality built in. I *believe* that the MPEG-4 format has the same datatype, but I'd have to check. In any case, the track format allows you to insert the link data on the fly. Worst case scenario, you will have to insert the track as a post-processing step once a user is done annotating. This was the Distributed Manual scenario in the Hypertext paper... allowing multiple users to view the same stream at their own pace, and each marking up as they go, with annotations collated on the server and added back to the file for future use.
Very cool to see someone picking up the baton on this. Have been mildly sad we had to drop it when we did, it was just getting interesting. Would love to continue the conversation either here, or email. http://www.cs.unc.edu/~smithja/ for contact info.
Thanks, I was having a heck of a time getting through to the details due to that lovely /. effect. :)
I'm curious though - why couldn't you annotate while streaming with MPEG-4? (There are a number of open source projects to manipulate MPEG-4, which offers the same sort of multi-track format QT does. *We* just happened to be using QT because back in '98 when OvalTine was started, that was the only thing out there that came close to filling the bill. Now, MPEG-4 does, no QT necessary.) We looked into it, and decided it was in the Future Research list, but rather got distracted by other projects. We didn't see any reason why annotation information couldn't be pushed back to the hosting server to be added to the file. In fact, we described that exact scenario in the paper as an opportunity for distributed markup.
I can understand not getting around to it, but did you run into a technical reason why it couldn't be done, that we didn't see?
I'm not slamming on the work, I think it's a good step forward, I'm just confused by your choice of container is all.
I could swear I gave a talk on something very similar back in 2000 at ACM Hypertext. The OvalTine project at UNC (no, don't ask, it was a silly name) allowed a user to markup video by tracking faces/heads automatically from frame to frame, and attaching a URL to them once. (You could also attach URLs to any other object in the video stream, but the object tracker we had running best at that time was for heads.) Clicking on any object that was so tagged would pop up a browser window (or the appropriate application if it was a 'file:' URL opening a local document).
Since we did this in QuickTime, it also supported jumping within the video stream, or to other video streams via timecodes. The same file format is now MPEG-4... so why on earth didn't these folks just use that? That way, the link information is embedded directly in the movie file, no external files are necessary. They tend to get lost, after all. Any reasonable MPEG-4 player would then be able to be used, it would be using an open standard file format, and they would be showered with admiration for making the process much easier.
Or am I missing something critical?
"WinFS however allows more then just searching, it is attempting to allow the sharing of data between applications, like a data soup (the Newton reborn on the desktop :-)."
;) It's all in there.
Righto. And that's what CoreData in the 10.4 Preview allows.
"If he were to be convicted of murder, it would mean that all drunk driving fatalaties could now be classified as murders as well."
And about high fricking time, too.
If you voluntarily imbibe, then voluntarily get behind the wheel, and voluntarily put other people at extreme risk due to your apparent 'right' to get to the next bar, and you kill someone... you're a murderer, pure and simple. It's no different in my mind than loading a gun and firing into a crowd. Sure, you might not hit someone, and gee, you didn't really *mean* to, you were just putting everyone at a *random* risk, right?
Fry the bastards.
Note the ORDERING of those last two.
When Teknekron became Tibco, the lawyers never transferred the trademark. Yeah, really stupid. Amazingly so.
It wasn't until they went to get their dander up towards Apple that anybody realized that, whoops, they didn't actually own the name any more.
Looks like a case of legal incompetence, coupled with not perfect corporate research, led to a situation where legally Apple had claim, but Tibco had a use claim. I suspect both parties declared no harm no foul. Apple will discontinue use, Tibco gets nada in cash, both parties avoid a costly lawsuit. Just a guess though.
We're going to just have to agree to disagree on this one for now. The visual orientation, the user interaction method, and the basic apparatus are all quite different.
Hopefully, if you are right, the PTO will deny the patent. (I'm not a huge software patent fan myself, I just disagree with you on the uniqueness test with relation to ClearBoard.)
Dead spot on.
Bump that puppy up, mods, if you don't mind.
Agreed. We're having fun with the various modes this can be put into.