I want societal expectations and systems to support the following.
I'll be glad to read a message from a stranger for a price. After my escrow agent informs me my message reading fee has been placed in escrow, I'll gladly look at the message. If I don't like the message, I'll cash your check. No problem! If I like the message, depending on how much I like it, I'll leave the money in escrow or refund it; and if I reply, I may send you an unguessable email address for future free correspondence.
Friends and relatives would have each have an unguessable email addresses for me (and presumably each other).
This would enable folks without a personal assistant to be reachable yet not open themselves up to the spamming scum of the earth.
This would be useful for social networking sites that focus on professional relationships, like LinkedIn.
It's essential that the terms be set by the recipient.
Beware of how you define your cultural identity. Cultural identity, like language, changes over time. Cultures that stridently resist all change eventually fall behind. Cultures that mindlessly accept whatever entertains them eventually fall down (or get pushed).
For metric vs imperial, the conversions and consequences are trivial. For other notions of 'us vs them' the consequences can be tragic.
'We're the ones with the one true god on our side.'
'We're the ones who know a woman's place.'
'Our ancestors were enslaved, therefore we are not responsible for our actions.'
'We were harmed therefore we have the right to retaliate indiscriminately.'
Modularity, encapsulation, separation of concerns or whatever you want to call it is still a good idea.
Aspect Oriented Programming claims to support a new kind of modularity, but what it really does is break encapsulation.
Imagine you're responsible for a module in a big system. Over the years, well meaning aspect oriented programmers stick more and more little hooks into your code. Eventually like Gulliver, when you try to move, e.g. fix or improve your code, you simply can't without breaking the hooks that tie you down.
If they had used your published interface and you designed a good interface, you would have been ok, but no! They reached into your code and created dependences on your implementation. If it's production code and you break someone else's code, you'll be seen as the bad guy.
Many years ago I used Xerox Lisp machines and worked near the inventors of Aspect Oriented Programming. I used two precursors of AOP. I used the advice mechanism in InterlispD and later Active Values in it's object oriented extension Loops.
When used very sparingly, advice was useful, especially for debugging and working around bugs. The advise function allowed you to add wrappers to functions that would replace, preceed or follow the invocation of the function. You could further restrict the advice to apply only when a function was called from within another function.
Active Values, on the other hand, were an advice mechanism applied to object field access. People quickly realized that the facility was a mess because there was rarely any hope that you could get your advice to run *only* when you wanted it to and rarely any hope that you could avoid a unreadable tangled mess. There were new getter and setter functions that didn't trigger the active values, but this just added even more complexity.
It would be much easier to design an explict hooks than to worry about what happens if someone sticks an active value in any and every object field. Especially when the field may already have an active value.
It's vital to be able to assume that when you read a line of code, you know what it means and if not, you know where to look up what it means. Rather than enabling hacks like aspect oriented programming, we need better tools for making clean changes that sweep across the source code and thereby do away with the urge for this perilous patching stratgy.
Slashdot Mirror
I want societal expectations and systems to support the following.
I'll be glad to read a message from a stranger for a price. After my escrow agent informs me my message reading fee has been placed in escrow, I'll gladly look at the message. If I don't like the message, I'll cash your check. No problem! If I like the message, depending on how much I like it, I'll leave the money in escrow or refund it; and if I reply, I may send you an unguessable email address for future free correspondence.
Friends and relatives would have each have an unguessable email addresses for me (and presumably each other).
This would enable folks without a personal assistant to be reachable yet not open themselves up to the spamming scum of the earth.
This would be useful for social networking sites that focus on professional relationships, like LinkedIn.
It's essential that the terms be set by the recipient.
Check out the description of "protection racket."
http://en.wikipedia.org/wiki/Protection_racket
How is what Microsoft is doing any different?
Modularity, encapsulation, separation of concerns or whatever you want to call it is still a good idea.
Aspect Oriented Programming claims to support a new kind of modularity, but what it really does is break encapsulation.
Imagine you're responsible for a module in a big system. Over the years, well meaning aspect oriented programmers stick more and more little hooks into your code. Eventually like Gulliver, when you try to move, e.g. fix or improve your code, you simply can't without breaking the hooks that tie you down.
If they had used your published interface and you designed a good interface, you would have been ok, but no! They reached into your code and created dependences on your implementation. If it's production code and you break someone else's code, you'll be seen as the bad guy.
Many years ago I used Xerox Lisp machines and worked near the inventors of Aspect Oriented Programming. I used two precursors of AOP. I used the advice mechanism in InterlispD and later Active Values in it's object oriented extension Loops.
When used very sparingly, advice was useful, especially for debugging and working around bugs. The advise function allowed you to add wrappers to functions that would replace, preceed or follow the invocation of the function. You could further restrict the advice to apply only when a function was called from within another function.
Active Values, on the other hand, were an advice mechanism applied to object field access. People quickly realized that the facility was a mess because there was rarely any hope that you could get your advice to run *only* when you wanted it to and rarely any hope that you could avoid a unreadable tangled mess. There were new getter and setter functions that didn't trigger the active values, but this just added even more complexity.
It would be much easier to design an explict hooks than to worry about what happens if someone sticks an active value in any and every object field. Especially when the field may already have an active value.
It's vital to be able to assume that when you read a line of code, you know what it means and if not, you know where to look up what it means. Rather than enabling hacks like aspect oriented programming, we need better tools for making clean changes that sweep across the source code and thereby do away with the urge for this perilous patching stratgy.