A complex user interface, with controls being enabled and disabled depending on the previous interactions with the user (possibly intentionally, so as the "steer" the user toward valid interactions), is complex in the same way that a function with many internal GOTOs is complex, and just as "harmful", to use Dijkstra's words.
We shun GOTOs, yet we accept such interfaces, and the style of programming behind them -- does one mean that we've wrestled the inherent complexity to the ground in one case and not the other? Perhaps, but having looked at a lot of UI code over the years, not bloody likely.
We need appropriate abstractions to simplify complex code: With GOTOs, we can enforce structure and scope -- if-then-else, while-do, repeat-until, case, and a plethora of single scope and multi-scope break and continue statements are a testament to this -- one could argue that all you really needed was if and goto, and they'd be right, implementation-wise, but wrong when it comes to managing complexity.
The typical multi-control user interface maps more to the excessive use of GOTOs than it does to a structured approach and so, is "bad", in the same way.
Now, consider approaching the problem differentially: at any point you have some active controls, and some inactive ones. Activating one of the available active ones results in several actions, including the mapping of current active set and action to a new active set. With that model, the individual control activations and deactivations, likely peppered throughout the UI callbacks or event handlers, start to make sense. Ideally, this mapping would be expressed in code in one convenient place instead of willy-nilly.
I know of no programming languages that make this possible (well, C# delegates might help) or elegant.
Historically, the way to manage complexity has always been through abstraction, and most modern programming languages, while supporting more and varied abstraction models, never seam to reach the point where it is convenient to express arbitrary absractions: C++ templates try to do thi (and type traits are way cool), but the meta-syntax of C++ template programming is absolutely horrid.
I remember, as a child, my parents advising me to run cold water over the inside of my wrists to cool down on a hot day (insted of begging for an ice cold soft drink). There were many free-flowing fresh water streams at their property in the country -- some of them tapped to pipes to make filling watter bottles easy (amazing what a little gravity will do), and I'd routinely take a drink of the almost ice cold flowing water via cupped hands as well as cool my wrists on a hot day.
While this works well for Windows-only development, it is NOT a portable build environment, so that might eliminate it from consideration.
Previously, I worked in a place where we hade success using a cross-compiler running in a DOS box under Windows, with the mks tooklit. However, the target there was an embedded system and not Windows.
... which surprises me because he is one smart dude.
All his points are valid, but (a) dangerous when taken as gospel, and (b) miss the forest for the trees.
What kills software is complexity. I've been writing code professionally (i.e. getting paid for it) since I was 15. It's been 28 years. Starting with Dijkstra's "GOTOs Considered Harmful", I've seen fads to improve software reliability come and go: structured programming, object-oriented programming, garbage collection to handle memory leaks, etc; as well as programming languages prividing the syntactic and semantic sugar to support the fad du jure. Hasn't helped, has it?
The general problem is one of managing complexity: if you can "come from" anywhere to a snippet of code, how can you ensure that all your assumptions about the context you're in are valid? Similarly, if you can access a global variable, well, globally, how can you be sure it contains what you expect? How do you know all the ways your data can be accessed? How do you control when and where an object is destructed, or that all resources (memory being just one) are freed?
Either restrict who can do what, or restrict the assumptions you make about the things you are operating on.
Using a garbage collector restricts who can allocate and deallocate memory. Object oriented programming restricts who can muck with private members. Structured programming restricts how you can get somewhere. O.K. wise guy, how are you going to write a garbage collector without dealing with raw memory? Gee, you have to get your hands dirty. How are you going to deal with private members inside private member functions? Gee, looks a lot like functional programming with globals, doesn't it?. How, the heck are you going to compile that loop without a jump at the end? Gee, what was that about GOTOs?
The trend appears to be to try to find the "next great technique" which will provide the best bang for the buck when improving quality. All of them help. None of them enough. Frankly, this incremental approach is not going to solve the problem of defects that are a result of the product of human error and code complexity. We need to learn how to manage complexity on its own.
Are there any examples of success in managing complexity, and can we learn from them?
I think so.
The best example I can think of is a compiler. Look at how many different inputs it can handle and still produce correct machine code with a fairly low defect rate. I attribute this to the fact that its input is highly structured: it has to follow strict syntactic rulers. Thus, when compiling something, one has a great deal of knowledge about the context in which this occuring. Yes, you have to deal with semantic issues (types, declarations, etc.), but an unambiguous language should make this clear.
One can point out that programming languages are well-specified, so implementing a compiler is relatively easy. If only all requirements were so detailed. I don't think that's it, however: one can come up with very detailed specifications for a complicated system that's difficult to implement. A programming language, by contrast, can be syntactically expressed in a few pages of BNF.
Contrast this with a user interface, where various elements need to be enabled or disabled depending on what other elements have been previously activated, or used to gather data. How easy or difficult is it to "forget" to enable or disable a control? If you see a parallel with this problem and excessive use of GOTOs in a program, you're starting to get a feel for what I'm talking about.
What has happened in the past 25 years or so of programming language evolution is that the complexities of the past have been pushed and morphed into the complexities of the present. And tackling one in isolation (memory management) does nothing for a transformation of the same problem (resource management in general -- memory isn't the only thing that leaks), though it may provide the best bang defect-rate-reduction-wise
True for the mainstream brews, perhaps, but I have found plenty of decent microbrews in the U.S. as well as a few regional popular varieties: Sierra Nevada Pale Ale, Red Hook IPA (a.k.a. "Ballard Bitter"), for example, that share shelf space with the Bud's abnd Bud-clones. As the weather cools, double-bocks are nice, albeit perhaps too strong and heavy for some.
I don't see coffee-derivatives ANYWHERE in that list.
I agree with the parent: beer does not deserve to be adulterated like that. If you like alcohol in your coffee, you might try to give it "legs" with rum or whiskey, though I'd argue that this does justice to neither.
I'd like to question why the person would have to be "important" for you to mourn them, a man with a girlfriend and a family passed away tragically.
Well, many people die every day, and there's not many daily headlines available (hint: that's why they're headlines).
If you don't like the editors' discretion as to what's newsworthy, start your own site.
As for a living RMS being more important than a dead "unknown", well, he is: that's the definition of fame. A lot more people pay attention to what he has to say than what, I for example, have to say. When I had the honour of acting as his host for his visit to Teradyne in 2000, I put his comfort, convenience, and certainly safety ahead of my own as best as I could manage. I would think any host would do the same (otherwise, stand aside and let someone else do it).
Shit happens. And, when it does, its awful. But, to argue that one particular unremarkable life is "more important" than a widely publicized one is hipocracy: there are millions of unremarkable lives snuffed out every day, and many of those under less pleasant than "no one saw it coming" accidental circumstances.
So, note the tragedy, recognize and pay respects to the fallen, breath a sigh of relief for the spared, and be grateful for what was not lost.
No, I noted the fact that the motion is never periodic in an N-body system. However, it can be considered periodic if one ignores interactions between the various 2-body systems. This is a common simplifying assumption. But, the journalist ascribes the "fact" that the asteroid never presents the same orientation to it's odd two-mode rotation, and not gravitional affects.
The asteroid rotates around one axis once every 5.4 Earth days and, in turn, rotates around the other axis once every 7.3 Earth days. As such, "the orientation of the asteroid never repeats exactly," Ostro said.
I call bull.
It isn't clear to what the orientation is compared (...an observer on a fixed point on Earth?,...a fixed point in the asteroid's orbital plane?), but at some point it will have the same orientation with regard to anything in a periodic motion relative to it.
Let's take the simple example of the plane of it's orbit (ignoring pertubations caused by other objects: if you consider them, you'd come to the conclusion that no objects ever repeat their orientation toward one another, since there must be some object that moves in a non-periodic way relative to any of them -- even within periodic systems, the N-body problem has not been shown to have perfectly periodic solutions):
It rotates on two axis with a period of 5.4 and 7.3 Earth days. Let's assume those figures are exact. It thus rotates ten times on each axis in 54 and 73 days, respectively. In 54*73 = 3942 days, it rotates on one axis 54*73/5.4 = 730 times, and on the other 54*73/7.3 = 540 times. Nice, whole numbers, reflecting the same orientation toward the plane of it's orbit (around the sun).
Dividing by 10, in 394.2 days it rotates 73 times around one axis and 54 time around the other. As 54 and 73 are coprime (sharing no common factors except 1), this is the shortest interval in which it repeats it's orientation with respect to the plane of it's orbit around the sun.
We can use the same process to compare it's location in it's orbit around the sun, with the Earth's orbit around the sun, and the position of a person on the surface of the Earth, as it rotates about it's axis. We could even account for the precession of the Earth's axis if we wished. In every case, there is some interval in which the person has rotated about the Earth's axis an integral number of times, the Earth has revolved around the sun an integral number of times, the asteroid has revolved around the sun an integral number of times, and has rotated about each of it's axis an integral number of times. This only fails if one of the periods (of rotation or revolution) is irrational. But, even then, you can find the interval between repeated orientations to an arbitrary degree of precision.
Clearcase is an overbloated, expensive pig of an RCS.
Now, that's not to say that I haven't appreciated Multisite, or some of the hairier things I could do merge/branch-wise with Clearcase, so it's a clever pig, but overbloated and expensive nevertheless.
Any static display on a monitor will tend to "burn in" or weaken the phosphor. You'd think this would not be a problem for black areas, which aren't driven, but they remain more sensitive over time than the area that has been driven constantly, and thus will eventually appear brighter.
Newer sets are less prone to this than older ones, unless driven with a high contrast, but it does remain a problem: Every manual I've seen for a direct view CRT notes this and recommends not driving the display with such material more than 15% of the viewing time.
Some sets try to counteract this by displaying grey letterboxed material instead of black, but many people find that more objectionable.
My wife, OTOH, buys into bull too easily. I had HD cAble installed (while I run the structured cabling for satellite), and the installer was arguing that there is no "burn in" danger with letterboxed material on 4:3 sets. I said, "If you are so sure, but a note to that effect on the work order you'll ask me to sign and leave me a copy." Of course, he didn't, but my wife complained that I was being "difficult".
Sure, but the customer who doesn't know what they want take up the sales droid's time.
The customer who knows what they want, can drop a few thousand dollars in seconds, if the price is right.
I've used that kind of purchasing power to dicker over price when I know the sales droid is earning a commission: would you rather make half the commission in one minute, or spend 20 with the next customer and not even know if they'll make a purchase? Though, as the consumer electronics biz is cutthroat, this works best in other areas, like furniture: I once purchased a three piece $6k leather sofa set listed "on sale" for $3300 for $3000, delivered next Tuesday" in 5 minutes. Of course, I knew the going commission was 20% in that shop, so I suggested the droid take half that in exchange for a quick sale.
I'm not sure which one of us is correct, but if I was in error, I stand corrected.
In any event, I do distinctly remember it being difficult to find out which sets had YPbPr inputs because of all the marketting jargon.
I ended up purchasing a 4:3 format Sony direct view set (my wife watches a lot of SD material, so a 4:3 and letterboxing for the small amount of 16:9 material (I know about burn in)) made sense. Some people say Sony's quality control is awful, but I've always had good luck with their video products generally being a cut above their consumer-grade competition. In this case, letterboxed HD material was displayed in "full 1080i resolution" by reducing the overall vertical deflection (they had a marketting name for that feature too!) instead of downsampling (i.e. 1920 / 4 * 3 = 1152. 1080/1152 = 1012.5/1080, the 1080 being the full vertical resolution in a 4:3 frame instead of 16:9). Of course, on a 32" directview set, the shadow mask won't actually permit that kind of display resolution, but that's another issue).
Slashdot Mirror
There is a Libertarian Party of Canada. I am a member.
Anyone who csan theoretically capture enough electors should be invited to debate. IIRC, that makes 6 candidates.
Count this Libertarian Very pleased (though, as a non-U.S. citizen, I'm watching this one on the sidelines).
A complex user interface, with controls being enabled and disabled depending on the previous interactions with the user (possibly intentionally, so as the "steer" the user toward valid interactions), is complex in the same way that a function with many internal GOTOs is complex, and just as "harmful", to use Dijkstra's words.
We shun GOTOs, yet we accept such interfaces, and the style of programming behind them -- does one mean that we've wrestled the inherent complexity to the ground in one case and not the other? Perhaps, but having looked at a lot of UI code over the years, not bloody likely.
We need appropriate abstractions to simplify complex code: With GOTOs, we can enforce structure and scope -- if-then-else, while-do, repeat-until, case, and a plethora of single scope and multi-scope break and continue statements are a testament to this -- one could argue that all you really needed was if and goto, and they'd be right, implementation-wise, but wrong when it comes to managing complexity.
The typical multi-control user interface maps more to the excessive use of GOTOs than it does to a structured approach and so, is "bad", in the same way.
Now, consider approaching the problem differentially: at any point you have some active controls, and some inactive ones. Activating one of the available active ones results in several actions, including the mapping of current active set and action to a new active set. With that model, the individual control activations and deactivations, likely peppered throughout the UI callbacks or event handlers, start to make sense. Ideally, this mapping would be expressed in code in one convenient place instead of willy-nilly.
I know of no programming languages that make this possible (well, C# delegates might help) or elegant.
Historically, the way to manage complexity has always been through abstraction, and most modern programming languages, while supporting more and varied abstraction models, never seam to reach the point where it is convenient to express arbitrary absractions: C++ templates try to do thi (and type traits are way cool), but the meta-syntax of C++ template programming is absolutely horrid.
I remember, as a child, my parents advising me to run cold water over the inside of my wrists to cool down on a hot day (insted of begging for an ice cold soft drink). There were many free-flowing fresh water streams at their property in the country -- some of them tapped to pipes to make filling watter bottles easy (amazing what a little gravity will do), and I'd routinely take a drink of the almost ice cold flowing water via cupped hands as well as cool my wrists on a hot day.
While this works well for Windows-only development, it is NOT a portable build environment, so that might eliminate it from consideration.
Previously, I worked in a place where we hade success using a cross-compiler running in a DOS box under Windows, with the mks tooklit. However, the target there was an embedded system and not Windows.
All his points are valid, but (a) dangerous when taken as gospel, and (b) miss the forest for the trees.
What kills software is complexity. I've been writing code professionally (i.e. getting paid for it) since I was 15. It's been 28 years. Starting with Dijkstra's "GOTOs Considered Harmful", I've seen fads to improve software reliability come and go: structured programming, object-oriented programming, garbage collection to handle memory leaks, etc; as well as programming languages prividing the syntactic and semantic sugar to support the fad du jure. Hasn't helped, has it?
The general problem is one of managing complexity: if you can "come from" anywhere to a snippet of code, how can you ensure that all your assumptions about the context you're in are valid? Similarly, if you can access a global variable, well, globally, how can you be sure it contains what you expect? How do you know all the ways your data can be accessed? How do you control when and where an object is destructed, or that all resources (memory being just one) are freed?
Either restrict who can do what, or restrict the assumptions you make about the things you are operating on.
Using a garbage collector restricts who can allocate and deallocate memory. Object oriented programming restricts who can muck with private members. Structured programming restricts how you can get somewhere. O.K. wise guy, how are you going to write a garbage collector without dealing with raw memory? Gee, you have to get your hands dirty. How are you going to deal with private members inside private member functions? Gee, looks a lot like functional programming with globals, doesn't it?. How, the heck are you going to compile that loop without a jump at the end? Gee, what was that about GOTOs?
The trend appears to be to try to find the "next great technique" which will provide the best bang for the buck when improving quality. All of them help. None of them enough. Frankly, this incremental approach is not going to solve the problem of defects that are a result of the product of human error and code complexity. We need to learn how to manage complexity on its own.
Are there any examples of success in managing complexity, and can we learn from them?
I think so.
The best example I can think of is a compiler. Look at how many different inputs it can handle and still produce correct machine code with a fairly low defect rate. I attribute this to the fact that its input is highly structured: it has to follow strict syntactic rulers. Thus, when compiling something, one has a great deal of knowledge about the context in which this occuring. Yes, you have to deal with semantic issues (types, declarations, etc.), but an unambiguous language should make this clear.
One can point out that programming languages are well-specified, so implementing a compiler is relatively easy. If only all requirements were so detailed. I don't think that's it, however: one can come up with very detailed specifications for a complicated system that's difficult to implement. A programming language, by contrast, can be syntactically expressed in a few pages of BNF.
Contrast this with a user interface, where various elements need to be enabled or disabled depending on what other elements have been previously activated, or used to gather data. How easy or difficult is it to "forget" to enable or disable a control? If you see a parallel with this problem and excessive use of GOTOs in a program, you're starting to get a feel for what I'm talking about.
What has happened in the past 25 years or so of programming language evolution is that the complexities of the past have been pushed and morphed into the complexities of the present. And tackling one in isolation (memory management) does nothing for a transformation of the same problem (resource management in general -- memory isn't the only thing that leaks), though it may provide the best bang defect-rate-reduction-wise
True for the mainstream brews, perhaps, but I have found plenty of decent microbrews in the U.S. as well as a few regional popular varieties: Sierra Nevada Pale Ale, Red Hook IPA (a.k.a. "Ballard Bitter"), for example, that share shelf space with the Bud's abnd Bud-clones. As the weather cools, double-bocks are nice, albeit perhaps too strong and heavy for some.
I agree with the parent: beer does not deserve to be adulterated like that. If you like alcohol in your coffee, you might try to give it "legs" with rum or whiskey, though I'd argue that this does justice to neither.
Well, many people die every day, and there's not many daily headlines available (hint: that's why they're headlines).
If you don't like the editors' discretion as to what's newsworthy, start your own site.
As for a living RMS being more important than a dead "unknown", well, he is: that's the definition of fame. A lot more people pay attention to what he has to say than what, I for example, have to say. When I had the honour of acting as his host for his visit to Teradyne in 2000, I put his comfort, convenience, and certainly safety ahead of my own as best as I could manage. I would think any host would do the same (otherwise, stand aside and let someone else do it).
Shit happens. And, when it does, its awful. But, to argue that one particular unremarkable life is "more important" than a widely publicized one is hipocracy: there are millions of unremarkable lives snuffed out every day, and many of those under less pleasant than "no one saw it coming" accidental circumstances.
So, note the tragedy, recognize and pay respects to the fallen, breath a sigh of relief for the spared, and be grateful for what was not lost.
Canon won't take my Nikor lenses... waaaaah!!!! (Yes, I know: duh!, but still.... waaaaah!!!!)
Yes, I know. It was a typo that I missed, and not a gramatical error. There were a bunch of spelling errors in my haste to post as well.
No, I noted the fact that the motion is never periodic in an N-body system. However, it can be considered periodic if one ignores interactions between the various 2-body systems. This is a common simplifying assumption. But, the journalist ascribes the "fact" that the asteroid never presents the same orientation to it's odd two-mode rotation, and not gravitional affects.
I call bull.
It isn't clear to what the orientation is compared (...an observer on a fixed point on Earth?, ...a fixed point in the asteroid's orbital plane?), but at some point it will have the same orientation with regard to anything in a periodic motion relative to it.
Let's take the simple example of the plane of it's orbit (ignoring pertubations caused by other objects: if you consider them, you'd come to the conclusion that no objects ever repeat their orientation toward one another, since there must be some object that moves in a non-periodic way relative to any of them -- even within periodic systems, the N-body problem has not been shown to have perfectly periodic solutions):
It rotates on two axis with a period of 5.4 and 7.3 Earth days. Let's assume those figures are exact. It thus rotates ten times on each axis in 54 and 73 days, respectively. In 54*73 = 3942 days, it rotates on one axis 54*73/5.4 = 730 times, and on the other 54*73/7.3 = 540 times. Nice, whole numbers, reflecting the same orientation toward the plane of it's orbit (around the sun).
Dividing by 10, in 394.2 days it rotates 73 times around one axis and 54 time around the other. As 54 and 73 are coprime (sharing no common factors except 1), this is the shortest interval in which it repeats it's orientation with respect to the plane of it's orbit around the sun.
We can use the same process to compare it's location in it's orbit around the sun, with the Earth's orbit around the sun, and the position of a person on the surface of the Earth, as it rotates about it's axis. We could even account for the precession of the Earth's axis if we wished. In every case, there is some interval in which the person has rotated about the Earth's axis an integral number of times, the Earth has revolved around the sun an integral number of times, the asteroid has revolved around the sun an integral number of times, and has rotated about each of it's axis an integral number of times. This only fails if one of the periods (of rotation or revolution) is irrational. But, even then, you can find the interval between repeated orientations to an arbitrary degree of precision.
Now, that's not to say that I haven't appreciated Multisite, or some of the hairier things I could do merge/branch-wise with Clearcase, so it's a clever pig, but overbloated and expensive nevertheless.
Those that don't learn the mistakes of history are condemned to repeat them.
Televisions are different (in general, not as good) from computer monitors.
Mind sharing your iptables config?
You need to do traffic shaping and policing at your end. Though, it can be argued that traffic policing is less effective and a rather blunt approach.
Perhaps, but nothing beats Nixon's "I am not a crook!" performance. :-)
I've had good luck with Sony products, though their marketspeak is anonying.
Newer sets are less prone to this than older ones, unless driven with a high contrast, but it does remain a problem: Every manual I've seen for a direct view CRT notes this and recommends not driving the display with such material more than 15% of the viewing time.
Some sets try to counteract this by displaying grey letterboxed material instead of black, but many people find that more objectionable.
My wife, OTOH, buys into bull too easily. I had HD cAble installed (while I run the structured cabling for satellite), and the installer was arguing that there is no "burn in" danger with letterboxed material on 4:3 sets. I said, "If you are so sure, but a note to that effect on the work order you'll ask me to sign and leave me a copy." Of course, he didn't, but my wife complained that I was being "difficult".
The customer who knows what they want, can drop a few thousand dollars in seconds, if the price is right.
I've used that kind of purchasing power to dicker over price when I know the sales droid is earning a commission: would you rather make half the commission in one minute, or spend 20 with the next customer and not even know if they'll make a purchase? Though, as the consumer electronics biz is cutthroat, this works best in other areas, like furniture: I once purchased a three piece $6k leather sofa set listed "on sale" for $3300 for $3000, delivered next Tuesday" in 5 minutes. Of course, I knew the going commission was 20% in that shop, so I suggested the droid take half that in exchange for a quick sale.
In any event, I do distinctly remember it being difficult to find out which sets had YPbPr inputs because of all the marketting jargon.
I ended up purchasing a 4:3 format Sony direct view set (my wife watches a lot of SD material, so a 4:3 and letterboxing for the small amount of 16:9 material (I know about burn in)) made sense. Some people say Sony's quality control is awful, but I've always had good luck with their video products generally being a cut above their consumer-grade competition. In this case, letterboxed HD material was displayed in "full 1080i resolution" by reducing the overall vertical deflection (they had a marketting name for that feature too!) instead of downsampling (i.e. 1920 / 4 * 3 = 1152. 1080/1152 = 1012.5/1080, the 1080 being the full vertical resolution in a 4:3 frame instead of 16:9). Of course, on a 32" directview set, the shadow mask won't actually permit that kind of display resolution, but that's another issue).