So you like COX then? Are they big, COX? How much did it cost you to get hooked up? When was your first experience with COX, and what convinced you to stick with 'em?
It does sound like you generally feel good about your experiences with COX - I guess you're getting a lot of uptime...
There's a lot of posts accusing of Cisco of intentionally violating the GPL; even an alleged ex-employee saying that Cisco "didn't care".
It could be a misunderstanding of the GPL or bad advice from an expert. Why, if I asked a question about the GPL, I would get dozens of posts each having their own and differing "expert" opinion of what is meant.
...Generally prefixed with "IANAL"...
Well, Cisco has to consult some people who do not anal... Those people should have a much less ambiguous view of the GPL.
I thank all the gods for the Slashdot link location notifier.
Me too. And for the first time in my life, I thought to myself, that I would be safer visiting a site from work than from my own home. At work I'm somewhat more anonymous. This is getting ridiculous!
Yeah, but do you think your employers would hesitate to dive into the logs and see who pulled up that URL, if the police asked?
Not that I think that scenario is terribly likely - I'm just saying, I don't expect that "somewhat anonymous" by virtue of connecting through your employer's net connection gets you much...
Indeed, if I saw that cover without the tag "child pornography" as input in my mind I would have not thought of anything to do with child pornography in the first place, rather some deeper meaning, maybe what could have been the actual intention of the band. (http://en.wikipedia.org/wiki/Virgin_Killer)
From the article it sounds like it wasn't the band's idea at all - but you never know... They did say that they were enjoying the benefits of the attention drawn to them by the controversy...
OK, so there was this guy with Alzheimer's, right? And one time some people came to his room. He was very tired, and so he mostly just lay in his bed. When he thought they might be saying something that needed a response he'd say "sure". Mostly, however, he kept quiet.
After a bit, someone else came in and asked him to eat some crushed-up pills and drink some juice. When presented with the straw for the juice, instead of drinking, he blew some bubbles through the straw - and everybody there got a good laugh.
I don't have a problem with people who make jokes about Alzheimer's... Nothing should be beyond the scope of humor. But this is a sample of what Alzheimer's is to me.
In the TV series, she gets her first body at the hospital as a child after a plane crash. Swapping her cyborg body gender in that situation seems unlikely.
Ever read "Pretty Face"?
...Yeah, it's pretty unlikely. But your post reminded me of Pretty Face.:D
My favorite way to deal with the issue you mentioned with the ambiguity of f (g x, y) was is to base the decision by looking at whitespace. f( g x, y ) is calling f with 2 arguments, while f (g x, y) is calling it with one. This could have something to do with that's how I happen to think about argument lists, anyway, so other people might not agree with that convention.:) Ruby actually treats the 2 expressions the same (both are passing 2 arguments to f), but issues a warning when you use the latter syntax. In Python's case (since f (x, y) is not valid Ruby syntax), f (x, y) could call f with a tuple, while f( x, y ) would call it with 2 arguments.
I've been working on a design where I face similar issues - in that it'd be totally unnatural in the basic language design to have parens for an invocation (It's Unix shell-based)...
I have a real problem with the language being whitespace-sensitive in the way you describe... In my design, to a certain extent it can't be avoided - it just seems like making the language do two totally different things depending on a slight difference in whitespace is asking for trouble...
A simple way to deal with f x, g y, h z would be for the parser to always try to read as much as it can of the current parameter list. So this expression would be parsed as (f x (g y (h z))). You shouldn't write code like that, but I think you can define the rules of the language in a simple way so that at least it is not ambiguous.
All that said, Ruby doesn't handle things quite as I expect.
But (assuming Python tuples are in play), this expression...
(f x, g y, h z)
could be a three-member tuple (f(x), g(y), h(z)) or a call to f with three arguments (f(x, g(y), h(z)) or (as you described) a call to f with one argument (f(x, (g(y, h(z))))
It's possible to define a rule that disambiguates the invocation, but it seems like going that far would create a language that looks ambiguous - which is nearly as bad as a language that is ambiguous.
Why not make print a function, but then change the language to not require parentheses for any function call? You'd still have to use them when calling a function with zero arguments, and in sub-expressions, but to not require parens for top-level function calls would, if nothing else, make playing around in interactive mode or with short scripts a lot more pleasant.
There's a specific problem there with Python - which is that not requiring parenthesis on a function call (but allowing them) creates an ambiguity... Is "f (x, y)" a one-argument function call (tuple of x and y) or two? This is in addition to the usual ambiguities involving nested calls and the general disparity between that form and the syntax that governs the rest of the language.
Still, Ruby does OK with that strategy, right?
My impression of Ruby so far (not having done much with it) is that it's a little more Perl-like in its treatment of syntax. Syntax isn't always consistent (for instance, some kinds of invocations will automatically "splat" an array, others won't) - it's more heuristically determined in some cases. Generally I find that a bit distasteful - though on the other hand, if it truly is a successful approach (including in terms of long-term maintenance of the parser, etc.) I want to learn more about it.
methods exist to examine what the encoding of a string is
These methods can merely intelligently guess, and they can easily go wrong. See this well-known example.
You misunderstand.
In Ruby 1.8, a "string" stored just a sequence of bytes, generally used to represent text. The application was responsible for knowing what encoding a string was in and handling the contents appropriately.
In Ruby 1.9, the string object includes some extra data fields: one of these explicitly records the encoding of the string. Obviously, some piece of application code must be responsible for setting this field correctly - but once it's set, no one has to guess what the encoding of a string is.
The "method" rubycodez referred to is a "method" of the string class, called "encoding".
Obviously, to explicitly store the encoding for a string as part of the string object requires more storage space than just mandating that all strings will encode Unicode... But the result is that the string object is better suited to safely handling other character encodings that you might want to process natively (without cross-encoding) due to the sort of (usually minor) losses of information that can occur in such translations.
You'd have to have a mapping of all encodings to a common encoding to know this sort of thing.
If I understand Unicode correctly, the entire point is that Unicode provides a code point space, which defines all the possible characters available. The various encodings are then ways to represent those code points as a set of bytes. So if you're comparing a UTF-8 string to a UTF-16 string, you just decode both and compare the code points.
Right?
Well, the thing is, Unicode doesn't quite represent all possible characters. There are some different representations of (approximately) the same character in East Asian encodings, for instance, which map to the same character in Unicode... Or if you're processing Japanese text, the SHIFT-JIS encoding defines a range for katakana, and then another whole range for the same characters displayed at half width. Converting this to Unicode would preserve the meaning, but not the full character of the original source data...
This is why it's useful for a programming language to support different character encodings besides Unicode... And, of course, if you're going to give different strings different encodings, you need to keep information about what the encoding is in order to handle the string correctly...
w = 8000000 liters r = w *.0001/sec = 8000 liters/sec
So when the tank is first filled it's leaking 8000 liters per second (ridiculous! But what do you expect from Wilson's crappy valves?) Basically it's a decay rate calculation:
dw/dt = -.0001w/sec w(t) = w(0)*e^(-.0001t/sec)
So after 30 * 24 * 60 * 60 seconds there would be a vanishingly small amount of water left in the tank no matter which of the two valves you use. (I should have made those leak rates daily... they were way too large for per-second rates...) I guess Morrison Valve Company will be wanting their money back...
The volume of the tank is given in liters, and thus also the leak rate formulas yield units of liters/sec... So if you're trying to say that the problem description is missing specification of units, you're wrong.:)
Of course, I didn't specify which month - so the period over which the tank is left alone after being filled could be as little as 28 days or as much as 31......Not to mention I said the tank was filled "at the beginning of the week", when I should have said "beginning of the month"... That fouls things a bit I guess...
I agree with your idea very much, but it does not even need to be in the shell!
It can be *programs*. Imagine there is a program called "progressbar" and you can somehow pipe cp to it or something.
That approach works fine for programs like cp, where the output isn't really important... It's more of a problem if the program itself generates output that is meant to be piped to another program - particularly if that output does not naturally include progress data. Once you deal with a program that does a large amount of stdio and needs to communicate with a module that would provide a progress bar display, then you start having to look at more substantial changes to how you handle the problem.
Progress info could go out over stderr and not disturb the program's regular I/O - but unless the program uses some extensible data format for its communications over stderr, then this usage would make it difficult to also use stderr for other things (like reporting errors...) Also, somehow or other, all programs intending to use that feature would have to agree upon the format of stderr messages, so one can easily pipe any app's stderr to the progress bar maker. Also, the shell you use would have to nicely support piping stderr (I think bash syntax for this is a bit awkward, at least if you're handling stdout separately...)
The reason I suggested that the shell should control display of the progress bar is that it's a good place for the user's basic, session-local preferences to be collected. Some of that stuff would just be environment variables, but some of it requires coordination. (For instance, what if the user wants more than one progress bar running simultaneously? Then some program has to coordinate the display of all those...)
Also, personally, in a GUI environment I'd put the progress bar within the shell's window, rather than popping up a new one. Same for dialogs, possibly... Unless the script implements a real GUI of its own, interaction should take place within the shell window.
One of the basic problems with making programs to act as "modules" at the shell level is that the shell really has no concept of what constitutes a "module". In a programming language like C++ or Python there's a pretty clear idea of what a module is and how to load it, and how to interface with it. At the shell level all you can do is call a program, control where its stdin, stdout, stderr file descriptors go, determine what set of environment variables it gets, and so on. There's no consensus for a mechanism to interact with the program while it's running (there are IPC mechanisms, but no consensus on how they are to be used... and there are things like object brokers, but their use is far from universal...)
For something like a file chooser this isn't a huge deal - usually all you need is a starting point, maybe some information about what kinds of file types (or filename extensions - bleah) should be accepted, information on whether you're looking to find a single file or a set of files, whether you're looking to create a new file, etc... And then all you need to get back is the file the user picked... For a usage like that, just exec()ing the program with certain arguments and listening to its stdout is sufficient.
But now suppose you want to go a bit farther... Say you're writing an image editor, and you want the file chooser to get a preview of an image when a user clicks on it. (Suppose also the file chooser doesn't naturally know about this file format - like if the app were providing support for a brand new format...) If the file chooser were a library, the chooser could call-back the application asking it to provide a preview. If the file chooser were a separate application, it would have a harder time providing that kind of feature. You would either need both the application and the file chooser to support an IPC mechanism (and corresponding protocol) for exchanging that kind of information, or else the file chooser would have
Perhaps it's a new transport mechanism, designed to compress, transport and unpack data objects(we can call them "clowns"). The cool thing would be that you get more data out during the unpack stage than you'd ever think would fit in so small a transport (we could call that a "car"!).
There you go.
Oh, great... One more car analogy added to the world of computer science.:D
A colleague called me to his office the other day. His PowerMac was "locking up" not responsive to clicks. And when he'd reboot the optical drive would eject. Turns out his Logitech USB mouse was stuck in the left click position. (Macs eject their optical disk on restart if the mouse button is clicked.)
You know, about that...
I have a Logitech Optical Trackball - the original 3-button model... I probably bought it in 1997 or so. It started failing within the last year or so - buttons started failing. I could probably pop it open, replace those switches, and get another ten years of service out of it - apart from the fact that it's a PS/2 trackball and I don't feel like getting an adaptor or converting it... So when I overhauled my computer last month I also replaced the trackball with a newer Logitech model.
Now, on the other hand, my current Logitech trackball at work is a later model of the same basic design: one of the silver ones with the scroll wheel, instead of the old beige one like I had at home. I got it in 2002 or so, still working great. However... - this model has a painted-on silver finish and some rubber external parts (including the scroll wheel itself...). Over time the silver finish has started flaking off and some of the rubber has dry-rotted. Basically it looks and feels like shit but it still works fine.
I really wish they'd drop the metallic finish and the rubber parts. There's no reason why the actual working parts should be able to stand up to ten years of use but the outer shell should fall apart after less than six...
A water tank on West Street has shutoff valves produced by Wilson Valve Company, which leak water at a rate given by the formula:
r = w *.0001/sec
where w is the volume of water currently in the tank. If the tank is filled to its full capacity of 8000000 liters at the beginning of the week and left alone for a full month, how much water would be saved by using shutoff valves from Morrison Valve Company, which have a leak rate of only (r = w *.000025/sec)?
I agree. This article was heavy on opinion and serves very little purpose. Who cares what this guy thinks about how certain, similar patterns are named?!
Well, in any case I'm very excited about this new "Circus Support Mechanism" (CSM) pattern... What's it do? I don't know! But it's cool!
Slashdot Mirror
How the hell are we supposed to know what that means?!
It's really quite simple...
Wine: the thing that lets you run Windows programs...
64: specifies that it runs on the Nintendo 64
So you like COX then? Are they big, COX? How much did it cost you to get hooked up? When was your first experience with COX, and what convinced you to stick with 'em?
It does sound like you generally feel good about your experiences with COX - I guess you're getting a lot of uptime...
There's a lot of posts accusing of Cisco of intentionally violating the GPL; even an alleged ex-employee saying that Cisco "didn't care".
It could be a misunderstanding of the GPL or bad advice from an expert. Why, if I asked a question about the GPL, I would get dozens of posts each having their own and differing "expert" opinion of what is meant.
...Generally prefixed with "IANAL"...
Well, Cisco has to consult some people who do not anal... Those people should have a much less ambiguous view of the GPL.
You know, I was just going to say, seems like this guy just got himself some experience writing nagware...
And they'll call it... Everything2!
Didn't Andrew Probert design the Enterprise 2.0?
"researchers working on development of a space elevator (an idea we have discussed numerous times) have determined that the concept is not stable."
Not entirely stable... Chewie, take the professor in the back and hook him up to the hyperdrive!
Me too. And for the first time in my life, I thought to myself, that I would be safer visiting a site from work than from my own home. At work I'm somewhat more anonymous. This is getting ridiculous!
Yeah, but do you think your employers would hesitate to dive into the logs and see who pulled up that URL, if the police asked?
Not that I think that scenario is terribly likely - I'm just saying, I don't expect that "somewhat anonymous" by virtue of connecting through your employer's net connection gets you much...
Indeed, if I saw that cover without the tag "child pornography" as input in my mind I would have not thought of anything to do with child pornography in the first place, rather some deeper meaning, maybe what could have been the actual intention of the band. (http://en.wikipedia.org/wiki/Virgin_Killer)
From the article it sounds like it wasn't the band's idea at all - but you never know... They did say that they were enjoying the benefits of the attention drawn to them by the controversy...
OK, so there was this guy with Alzheimer's, right? And one time some people came to his room. He was very tired, and so he mostly just lay in his bed. When he thought they might be saying something that needed a response he'd say "sure". Mostly, however, he kept quiet.
After a bit, someone else came in and asked him to eat some crushed-up pills and drink some juice. When presented with the straw for the juice, instead of drinking, he blew some bubbles through the straw - and everybody there got a good laugh.
I don't have a problem with people who make jokes about Alzheimer's... Nothing should be beyond the scope of humor. But this is a sample of what Alzheimer's is to me.
In the TV series, she gets her first body at the hospital as a child after a plane crash. Swapping her cyborg body gender in that situation seems unlikely.
Ever read "Pretty Face"?
...Yeah, it's pretty unlikely. But your post reminded me of Pretty Face. :D
My favorite way to deal with the issue you mentioned with the ambiguity of f (g x, y) was is to base the decision by looking at whitespace. f( g x, y ) is calling f with 2 arguments, while f (g x, y) is calling it with one. This could have something to do with that's how I happen to think about argument lists, anyway, so other people might not agree with that convention. :) Ruby actually treats the 2 expressions the same (both are passing 2 arguments to f), but issues a warning when you use the latter syntax. In Python's case (since f (x, y) is not valid Ruby syntax), f (x, y) could call f with a tuple, while f( x, y ) would call it with 2 arguments.
I've been working on a design where I face similar issues - in that it'd be totally unnatural in the basic language design to have parens for an invocation (It's Unix shell-based)...
I have a real problem with the language being whitespace-sensitive in the way you describe... In my design, to a certain extent it can't be avoided - it just seems like making the language do two totally different things depending on a slight difference in whitespace is asking for trouble...
A simple way to deal with f x, g y, h z would be for the parser to always try to read as much as it can of the current parameter list. So this expression would be parsed as (f x (g y (h z))). You shouldn't write code like that, but I think you can define the rules of the language in a simple way so that at least it is not ambiguous.
All that said, Ruby doesn't handle things quite as I expect.
But (assuming Python tuples are in play), this expression...
(f x, g y, h z)
could be a three-member tuple (f(x), g(y), h(z))
or a call to f with three arguments (f(x, g(y), h(z))
or (as you described) a call to f with one argument (f(x, (g(y, h(z))))
It's possible to define a rule that disambiguates the invocation, but it seems like going that far would create a language that looks ambiguous - which is nearly as bad as a language that is ambiguous.
Reread the summary in Davros's voice, in creasing the volume and excitement as you get closer to the end. Come on -- it'll be fun.
What happens when you crease volume and excitement? Is it like one of those Mad fold-ins? Like it'll work out to be "volent" or "exume" or something?
Why not make print a function, but then change the language to not require parentheses for any function call? You'd still have to use them when calling a function with zero arguments, and in sub-expressions, but to not require parens for top-level function calls would, if nothing else, make playing around in interactive mode or with short scripts a lot more pleasant.
There's a specific problem there with Python - which is that not requiring parenthesis on a function call (but allowing them) creates an ambiguity... Is "f (x, y)" a one-argument function call (tuple of x and y) or two? This is in addition to the usual ambiguities involving nested calls and the general disparity between that form and the syntax that governs the rest of the language.
Still, Ruby does OK with that strategy, right?
My impression of Ruby so far (not having done much with it) is that it's a little more Perl-like in its treatment of syntax. Syntax isn't always consistent (for instance, some kinds of invocations will automatically "splat" an array, others won't) - it's more heuristically determined in some cases. Generally I find that a bit distasteful - though on the other hand, if it truly is a successful approach (including in terms of long-term maintenance of the parser, etc.) I want to learn more about it.
methods exist to examine what the encoding of a string is
These methods can merely intelligently guess, and they can easily go wrong. See this well-known example.
You misunderstand.
In Ruby 1.8, a "string" stored just a sequence of bytes, generally used to represent text. The application was responsible for knowing what encoding a string was in and handling the contents appropriately.
In Ruby 1.9, the string object includes some extra data fields: one of these explicitly records the encoding of the string. Obviously, some piece of application code must be responsible for setting this field correctly - but once it's set, no one has to guess what the encoding of a string is.
The "method" rubycodez referred to is a "method" of the string class, called "encoding".
Obviously, to explicitly store the encoding for a string as part of the string object requires more storage space than just mandating that all strings will encode Unicode... But the result is that the string object is better suited to safely handling other character encodings that you might want to process natively (without cross-encoding) due to the sort of (usually minor) losses of information that can occur in such translations.
You'd have to have a mapping of all encodings to a common encoding to know this sort of thing.
If I understand Unicode correctly, the entire point is that Unicode provides a code point space, which defines all the possible characters available. The various encodings are then ways to represent those code points as a set of bytes. So if you're comparing a UTF-8 string to a UTF-16 string, you just decode both and compare the code points.
Right?
Well, the thing is, Unicode doesn't quite represent all possible characters. There are some different representations of (approximately) the same character in East Asian encodings, for instance, which map to the same character in Unicode... Or if you're processing Japanese text, the SHIFT-JIS encoding defines a range for katakana, and then another whole range for the same characters displayed at half width. Converting this to Unicode would preserve the meaning, but not the full character of the original source data...
This is why it's useful for a programming language to support different character encodings besides Unicode... And, of course, if you're going to give different strings different encodings, you need to keep information about what the encoding is in order to handle the string correctly...
w = 8000000 liters .0001/sec = 8000 liters/sec
r = w *
So when the tank is first filled it's leaking 8000 liters per second (ridiculous! But what do you expect from Wilson's crappy valves?) Basically it's a decay rate calculation:
dw/dt = -.0001w/sec
w(t) = w(0)*e^(-.0001t/sec)
So after 30 * 24 * 60 * 60 seconds there would be a vanishingly small amount of water left in the tank no matter which of the two valves you use. (I should have made those leak rates daily... they were way too large for per-second rates...) I guess Morrison Valve Company will be wanting their money back...
194.4 units.
The volume of the tank is given in liters, and thus also the leak rate formulas yield units of liters/sec... So if you're trying to say that the problem description is missing specification of units, you're wrong. :)
Of course, I didn't specify which month - so the period over which the tank is left alone after being filled could be as little as 28 days or as much as 31... ...Not to mention I said the tank was filled "at the beginning of the week", when I should have said "beginning of the month"... That fouls things a bit I guess...
I agree with your idea very much, but it does not even need to be in the shell!
It can be *programs*. Imagine there is a program called "progressbar" and you can somehow pipe cp to it or something.
That approach works fine for programs like cp, where the output isn't really important... It's more of a problem if the program itself generates output that is meant to be piped to another program - particularly if that output does not naturally include progress data. Once you deal with a program that does a large amount of stdio and needs to communicate with a module that would provide a progress bar display, then you start having to look at more substantial changes to how you handle the problem.
Progress info could go out over stderr and not disturb the program's regular I/O - but unless the program uses some extensible data format for its communications over stderr, then this usage would make it difficult to also use stderr for other things (like reporting errors...) Also, somehow or other, all programs intending to use that feature would have to agree upon the format of stderr messages, so one can easily pipe any app's stderr to the progress bar maker. Also, the shell you use would have to nicely support piping stderr (I think bash syntax for this is a bit awkward, at least if you're handling stdout separately...)
The reason I suggested that the shell should control display of the progress bar is that it's a good place for the user's basic, session-local preferences to be collected. Some of that stuff would just be environment variables, but some of it requires coordination. (For instance, what if the user wants more than one progress bar running simultaneously? Then some program has to coordinate the display of all those...)
Also, personally, in a GUI environment I'd put the progress bar within the shell's window, rather than popping up a new one. Same for dialogs, possibly... Unless the script implements a real GUI of its own, interaction should take place within the shell window.
One of the basic problems with making programs to act as "modules" at the shell level is that the shell really has no concept of what constitutes a "module". In a programming language like C++ or Python there's a pretty clear idea of what a module is and how to load it, and how to interface with it. At the shell level all you can do is call a program, control where its stdin, stdout, stderr file descriptors go, determine what set of environment variables it gets, and so on. There's no consensus for a mechanism to interact with the program while it's running (there are IPC mechanisms, but no consensus on how they are to be used... and there are things like object brokers, but their use is far from universal...)
For something like a file chooser this isn't a huge deal - usually all you need is a starting point, maybe some information about what kinds of file types (or filename extensions - bleah) should be accepted, information on whether you're looking to find a single file or a set of files, whether you're looking to create a new file, etc... And then all you need to get back is the file the user picked... For a usage like that, just exec()ing the program with certain arguments and listening to its stdout is sufficient.
But now suppose you want to go a bit farther... Say you're writing an image editor, and you want the file chooser to get a preview of an image when a user clicks on it. (Suppose also the file chooser doesn't naturally know about this file format - like if the app were providing support for a brand new format...) If the file chooser were a library, the chooser could call-back the application asking it to provide a preview. If the file chooser were a separate application, it would have a harder time providing that kind of feature. You would either need both the application and the file chooser to support an IPC mechanism (and corresponding protocol) for exchanging that kind of information, or else the file chooser would have
Perhaps it's a new transport mechanism, designed to compress, transport and unpack data objects(we can call them "clowns"). The cool thing would be that you get more data out during the unpack stage than you'd ever think would fit in so small a transport (we could call that a "car"!).
There you go.
Oh, great... One more car analogy added to the world of computer science. :D
A colleague called me to his office the other day. His PowerMac was "locking up" not responsive to clicks. And when he'd reboot the optical drive would eject. Turns out his Logitech USB mouse was stuck in the left click position. (Macs eject their optical disk on restart if the mouse button is clicked.)
You know, about that...
I have a Logitech Optical Trackball - the original 3-button model... I probably bought it in 1997 or so. It started failing within the last year or so - buttons started failing. I could probably pop it open, replace those switches, and get another ten years of service out of it - apart from the fact that it's a PS/2 trackball and I don't feel like getting an adaptor or converting it... So when I overhauled my computer last month I also replaced the trackball with a newer Logitech model.
Now, on the other hand, my current Logitech trackball at work is a later model of the same basic design: one of the silver ones with the scroll wheel, instead of the old beige one like I had at home. I got it in 2002 or so, still working great. However... - this model has a painted-on silver finish and some rubber external parts (including the scroll wheel itself...). Over time the silver finish has started flaking off and some of the rubber has dry-rotted. Basically it looks and feels like shit but it still works fine.
I really wish they'd drop the metallic finish and the rubber parts. There's no reason why the actual working parts should be able to stand up to ten years of use but the outer shell should fall apart after less than six...
A water tank on West Street has shutoff valves produced by Wilson Valve Company, which leak water at a rate given by the formula:
r = w * .0001/sec
where w is the volume of water currently in the tank. If the tank is filled to its full capacity of 8000000 liters at the beginning of the week and left alone for a full month, how much water would be saved by using shutoff valves from Morrison Valve Company, which have a leak rate of only (r = w * .000025/sec)?
I agree. This article was heavy on opinion and serves very little purpose. Who cares what this guy thinks about how certain, similar patterns are named?!
Well, in any case I'm very excited about this new "Circus Support Mechanism" (CSM) pattern... What's it do? I don't know! But it's cool!
Windows sucks and there's your proof.
Only from a certain point of view.
A certain point of view??
"I am Ben Franklin! Master of sex and Voodoo!" - Benjamin Franklin