Thank you for a very pleasant 8 minutes. It's always good to see an engineer sit down and think about important concepts such as these; and even better when be produces a video tutorial to explain himself.
I hope you don't mind if I make two small comments as feedback.
Firstly, though I applaud your presentation of the problem and proposed solution, I'm not sure that the phrase, "Temporal loose coupling," is entirely helpful. As you say yourself in your video, there are a lot of defintions of the phrase, "Loose coupling," bandied around, but we are fortunate to have the original definition and, whereas we may not entirely agree with it, we can obtain some degree of clarity by acknowledging the association between our re-definitions and the original. In this respect, I fear some might question your particular expanded definition.
The original paper is here: http://www.research.ibm.com/journal/sj/382/stevens.pdf
“Coupling,” is defined as, “A measure of the strength of association established by a connection from one module to another,” where, "Association," is evaluated by examining, "Connections," which are, "... reference(s) to some label or address defined elsewhere."
As defined, there is no temporal aspect to coupling.
Your expanded definition might still be fine, but it may be beneficial to point out this difference between your definition and the original. Another problem might arise, furthermore, because the paper also introduces, "Cohesion," and there is indeed a temporal variety of cohesion; yet cohesion describes modules in and of themselves, whereas coupling describes the connections between modules.
And perhaps more basically: why do you need to use the term, "Loose coupling," when something along the lines of your own wording such as, "Asynchronous dependencies," more accurately conveys your fine point?
And for my second and far less important point: I don't think your hand-drawings do you credit. They seem, if you'll forgive me, unprofessional, and might detract from your overall excellence. Yes, engineers around the world huddle at whiteboards and make sketches precisely like those you drew, but I think that the difference between a whiteboard and the internet is one of expectation: presentations on the internet are simply more glossy than those in engineers' war room. Even pre-designed slides onto which you could draw would, I think, have represented you better. An entirely subjective opinion, of course.
Thanks again for a thoughtful piece of video journalism.
Ed
PS What is that noise rising towards the end of the piece? It's not a kettle coming to the boil in the background, is it?
You mentioned that this type of system (asynchronous) is harder to design/think about; have you looked much at Erlang?
In Erlang, it's harder *not* to think of programs like this!
One of the main features is that asynchronous messaging is built into the language. A program usually creates many processes (which are kind of like green threads) which can send messages to each other; each process has a 'mailbox' queue for receiving messages. When the time comes to distribute your program, you can just spawn some of those processes on separate machines.
Thanks for the comments. The many definitions of critical things like loose coupling and cohesion make discussions very problematic. My definitions definitely differ from those of other and that creates a communications problem. The best way to resolve it would be for a controlled vocab to take root but thats a lot of work, is best done in some academic setting, and few have to time to do it :-) Case in point, in discussions about REST its great to have Roy Fieldings detailed thesis to refer to. regards, Sean
I completely agree! Linguistic determinism plays a very important role in s/w engineering. This was the subject of an article I wrote some time ago : In Praise of IT Multi-lingualism (http://www.itworld.com/nl/ebiz_ent/10282003/).
I believe that the only way distributed/massively-parallel systems will be viable is if we get past the C/C++ based notions of processor, data and function call.
I doubt Erlang will be the killer language of the next decade but whatever it is will have a very clear lineage back to it :-)
6 comments:
Hej, Sean.
Thank you for a very pleasant 8 minutes. It's always good to see an engineer sit down and think about important concepts such as these; and even better when be produces a video tutorial to explain himself.
I hope you don't mind if I make two small comments as feedback.
Firstly, though I applaud your presentation of the problem and proposed solution, I'm not sure that the phrase, "Temporal loose coupling," is entirely helpful. As you say yourself in your video, there are a lot of defintions of the phrase, "Loose coupling," bandied around, but we are fortunate to have the original definition and, whereas we may not entirely agree with it, we can obtain some degree of clarity by acknowledging the association between our re-definitions and the original. In this respect, I fear some might question your particular expanded definition.
The original paper is here:
http://www.research.ibm.com/journal/sj/382/stevens.pdf
“Coupling,” is defined as, “A measure of the strength of association established by a connection from one module to another,” where, "Association," is evaluated by examining, "Connections," which are, "... reference(s) to some label or address defined elsewhere."
As defined, there is no temporal aspect to coupling.
Your expanded definition might still be fine, but it may be beneficial to point out this difference between your definition and the original. Another problem might arise, furthermore, because the paper also introduces, "Cohesion," and there is indeed a temporal variety of cohesion; yet cohesion describes modules in and of themselves, whereas coupling describes the connections between modules.
And perhaps more basically: why do you need to use the term, "Loose coupling," when something along the lines of your own wording such as, "Asynchronous dependencies," more accurately conveys your fine point?
And for my second and far less important point: I don't think your hand-drawings do you credit. They seem, if you'll forgive me, unprofessional, and might detract from your overall excellence. Yes, engineers around the world huddle at whiteboards and make sketches precisely like those you drew, but I think that the difference between a whiteboard and the internet is one of expectation: presentations on the internet are simply more glossy than those in engineers' war room. Even pre-designed slides onto which you could draw would, I think, have represented you better. An entirely subjective opinion, of course.
Thanks again for a thoughtful piece of video journalism.
Ed
PS What is that noise rising towards the end of the piece? It's not a kettle coming to the boil in the background, is it?
Hi Sean,
You mentioned that this type of system (asynchronous) is harder to design/think about; have you looked much at Erlang?
In Erlang, it's harder *not* to think of programs like this!
One of the main features is that asynchronous messaging is built into the language. A program usually creates many processes (which are kind of like green threads) which can send messages to each other; each process has a 'mailbox' queue for receiving messages. When the time comes to distribute your program, you can just spawn some of those processes on separate machines.
-JB
A transcript would be nice for deaf persons and those too lazy to watch screencasts.
(I belong to the latter group. Listening to people talk is just so much slower than reading text.)
@Ed,
Thanks for the comments. The many definitions of critical things like loose coupling and cohesion make discussions very problematic. My definitions definitely differ from those of other and that creates a communications problem. The best way to resolve it would be for a controlled vocab to take root but thats a lot of work, is best done in some academic setting, and few have to time to do it :-) Case in point, in discussions about REST its great to have Roy Fieldings detailed thesis to refer to.
regards,
Sean
@Anonymous,
I completely agree! Linguistic determinism plays a very important role in s/w engineering. This was the subject of an article I wrote some time ago : In Praise of IT Multi-lingualism (http://www.itworld.com/nl/ebiz_ent/10282003/).
I believe that the only way distributed/massively-parallel systems will be viable is if we get past the C/C++ based notions of processor, data and function call.
I doubt Erlang will be the killer language of the next decade but whatever it is will have a very clear lineage back to it :-)
regards,
Sean
@Marius,
Point taken. I'll keep this in mind if we proceed to do more of these techtorials!
regards,
Sean
Post a Comment