Any Slashdotters out there read the Washington Post? I was surprised to see her name atop this op-ed piece on Saturday, Oct. 16. The column ends with this brief description of her:
The writer is former chairman and chief executive of the Recording Industry Association of America and a volunteer for gay rights causes.
And along came.NET. This was a grand project, the super-duper unifying project to clean up the whole mess once and for all. It would have memory management, of course. It would still have Visual Basic, but it would gain a new language, one which is in spirit virtually the same as Visual Basic but with the C-like syntax of curly braces and semicolons. And best of all, the new Visual Basic/C hybrid would be called Visual C#, so you would not have to tell anyone you were a "Basic" programmer any more.
There once was a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system", replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system", he said.
"Not so", said the programmer, "when designing an accounting package, the programmer operates as a mediator between people having different ideas: How it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
Can you own a condo or home in Canada without being taxed to death?
I'm not sure how property taxes compare, but in Canada you can't deduct your mortgage payments from income tax like you can in the U.S., so houses are effectively more expensive (and Canadians have more incentive to pay off their mortgages). On the other hand, some say that houses in the U.S. are just proportionally more expensive than Canadian houses because Americans effectively have more purchasing power when it comes to home ownership.
I believe that Comeau has historically had the most compliant C++ compilers. I'm not sure if they fully implement the standard, but if anybody does, it's them.
Isn't the art of good coding to make things as efficient as possible?
Yes, but it depends what you mean by "efficient". Do you mean efficient in processing time, memory usage, programmer time? It makes no sense to spend hours optimizing a section of code if your program almost never executes that section of code. It makes a lot more sense to optimize a program for memory on a PDA, but it may be a waste of time if it will run on a desktop and it only takes up 200K unoptimized.
The art of good coding is solving the right problem, not optimizing just for optimizing's sake.
I believe it was Hume who argued that you inductive reasoning will never tell you if something is true or not (e.g. you can't prove that "all crows are black" through observation, because no matter how many black crows you see, there is always the possibility that the next crow you see will not be black).
one-way function != non-invertible functions. A function f is one-way way if, given f and a value Y, it's *really hard* to find an X such that f(X)=Y. (Where *really hard* means that the probability of guessing a valid X decays exponentially with the number of bits).
That's the difference between the mindset of Microsoft (one big tool that does everything) and that of the *nix world (many small tools, each that does something in particular)
*cough* Emacs *cough* Perl *cough*
I know, I know, they're the exceptions that prove the rule. And they're also evidence that in the *nix world, text files are king.
There's a less cynical version why large organizations are not always the most innovative, what Clayton Christensen calls "the innovator's dilemma". Large, successful companies will tend to optimize towards the products that makes them the most money. The newer technologies are initially not as profitable as their older, more established counterparts, so it isn't economical for the larger companies to invest in them. However, the new technologies have a lot of room to improve, and will eventually supplant the old technology, and by the time the large company realizes this is happening, it's too late.
Christensen's book has a lot of examples of these types of disruptive technologies, from hard drives to hydraulics.
Did anyone catch the NPR story on Choicepoint today? They're the folks you go to if you want a background check done on somebody. They get some (all?) of their info from publicly accessible government sources, like court records. I don't know how directly relevant it is to this particular discussion, but I hadn't heard of these folks before, thought they were worth mentioning.
There will always be lots of back and forth between those who want the software written, and those who are writing it.
I was reading an article in either an IEEE magazine or an ACM magazine not too long ago, and the authors claimed that outsourced software might be of higher quality precisely because of the absence of back and forth that's around in-house. Management (or whoever wants the software written) is forced to spend more time defining requirements properly before handing them over to the programmers.
There are really two separate issues: 1. Management doesn't tell the programmers what they really want in the software, and 2. Management doesn't actually know what they really want in the software. If #1 is the dominant problem, then outsourcing might get you better software because the requirement docs might be better on average, but if #2 is the dominant problem, then outsourcing might get you worse software because there isn't enough feedback getting back to management.
Bandwidth has nothing to do with the current through a line (or not much....)
Doesn't that depend on what type of "bandwidth" you are talking about? If you're talking about bandwidth in the traditional "frequency-response" sense (e.g. bandwidth of a filter), then yes, it doesn't matter how much power you send over the lines, the bandwidth of the same.
But if you mean "bandwidth" in the sense of number of bits transmitted per second (which is really channel capacity, not bandwidth, though it's a function of bandwidth), then your available signal power matters a lot!
I'm talking strictly from a theoretical point of view here. I have no idea how much of the total power you can use to transmit your data over these lines, or what the other practical issues are. I was just trying to draw the distinction between bandwidth and channel capacity, since people use "bandwidth" interchangeably.
Sure, you can explain a microwave with QM, but you can also explain a rifle round, and no one claims that we wouldn't have bullets w/o QM.
An even better example would be glass. We couldn't properly explain why glass was transparent until quantum theory came around, but we had been making glass for a looooong time before that.
Chess, is not as some people seem to believe, the absolute sign of intelligence.
Well, it used to be, back before people really thought about how to build a chess program. One of the problems with AI is that we don't really know what "intelligence" is. Every time we are able to write a computer program to solve a problem that we thought required intelligence, we conclude, "Oh, then that can't be what we meant by intelligence" rather than "The computer has now achieved intelligence."
Dave Parnas is rarely mentioned as one of the "great computer science", but his ideas have been very influential in software engineering. He wrote on information hiding and separation of concerns well before object-oriented programming existed. His discussion of "undesired events" was a forerunner to exception handling mechanisms. He wrote of families of software products decades ago which is only now being actively pursued under the term "product lines".
A number of his papers have been collected into a book called "Software Fundamentals: Collected Papers by David L. Parnas".
people who know they are going to drive like maniacs will select cars without blackboxes
As someone else suggested, one way to deal with this is to allow insurance companies to take the presence of a black box into account when setting their rates. You can bet that insurance companies are going to charge a lot more to those who don't want these boxes, since (as you pointed out) they're more likely to be the riskier drivers.
Slashdot Mirror
Remember the Clipper chip? Ashcroft sided with the ACLU in opposing it. Even more ironically, Kerry supported it.
Any Slashdotters out there read the Washington Post? I was surprised to see her name atop this op-ed piece on Saturday, Oct. 16. The column ends with this brief description of her:
The writer is former chairman and chief executive of the Recording Industry Association of America and a volunteer for gay rights causes.
We refer to this fallacy as post hoc ergo propter hoc.
(Well, not "we". I don't actually speak Latin).
Don't forget the Washington Times, and the (Opinion page of) the Wall Street Journal. Not exactly lefty rags, those.
On the other hand, if it just malfunctions...
Well, in that case C# comes from VB too.
.NET. This was a grand project, the super-duper unifying project to clean up the whole mess once and for all. It would have memory management, of course. It would still have Visual Basic, but it would gain a new language, one which is in spirit virtually the same as Visual Basic but with the C-like syntax of curly braces and semicolons. And best of all, the new Visual Basic/C hybrid would be called Visual C#, so you would not have to tell anyone you were a "Basic" programmer any more.
You wouldn't be the first to suggest that. To wit, see Joel Spolsky's column, as found on Slashdot yesterday:
And along came
(I couldn't resist...)
There once was a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system", replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system", he said.
"Not so", said the programmer, "when designing an accounting package, the programmer operates as a mediator between people having different ideas: How it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
The programmer made no reply.
-- Geoffrey James, "The Tao of Programming"
Can you own a condo or home in Canada without being taxed to death?
I'm not sure how property taxes compare, but in Canada you can't deduct your mortgage payments from income tax like you can in the U.S., so houses are effectively more expensive (and Canadians have more incentive to pay off their mortgages). On the other hand, some say that houses in the U.S. are just proportionally more expensive than Canadian houses because Americans effectively have more purchasing power when it comes to home ownership.
I believe that Comeau has historically had the most compliant C++ compilers. I'm not sure if they fully implement the standard, but if anybody does, it's them.
Free doesn't have to mean, free for anyony to get and use. Free can also mean, as gosling pointed out, free of charge.
:)
Well, that's English for you.
I believe that people in the community differentiate between the two meanings by using the words gratis and libre.
How would you know whether or not to trust it? It's not like the patch could be released as source, is it? Not all of us have the code.
I am half-Canadian (read: french Quebecer).
Of course they did blame Canada! It is the American way!
Funny, I thought it was the Quebecois way!
I keed, I keed. I am half-Quebecois (read: english Quebecer)
Isn't the art of good coding to make things as efficient as possible?
Yes, but it depends what you mean by "efficient". Do you mean efficient in processing time, memory usage, programmer time? It makes no sense to spend hours optimizing a section of code if your program almost never executes that section of code. It makes a lot more sense to optimize a program for memory on a PDA, but it may be a waste of time if it will run on a desktop and it only takes up 200K unoptimized.
The art of good coding is solving the right problem, not optimizing just for optimizing's sake.
Actually, Microsoft Research is doing some interesting anti-spam work.
I believe it was Hume who argued that you inductive reasoning will never tell you if something is true or not (e.g. you can't prove that "all crows are black" through observation, because no matter how many black crows you see, there is always the possibility that the next crow you see will not be black).
one-way function != non-invertible functions. A function f is one-way way if, given f and a value Y, it's *really hard* to find an X such that f(X)=Y. (Where *really hard* means that the probability of guessing a valid X decays exponentially with the number of bits).
That's the difference between the mindset of Microsoft (one big tool that does everything) and that of the *nix world (many small tools, each that does something in particular)
*cough* Emacs *cough* Perl *cough*
I know, I know, they're the exceptions that prove the rule. And they're also evidence that in the *nix world, text files are king.
There's a less cynical version why large organizations are not always the most innovative, what Clayton Christensen calls "the innovator's dilemma". Large, successful companies will tend to optimize towards the products that makes them the most money. The newer technologies are initially not as profitable as their older, more established counterparts, so it isn't economical for the larger companies to invest in them. However, the new technologies have a lot of room to improve, and will eventually supplant the old technology, and by the time the large company realizes this is happening, it's too late.
Christensen's book has a lot of examples of these types of disruptive technologies, from hard drives to hydraulics.
Did anyone catch the NPR story on Choicepoint today? They're the folks you go to if you want a background check done on somebody. They get some (all?) of their info from publicly accessible government sources, like court records. I don't know how directly relevant it is to this particular discussion, but I hadn't heard of these folks before, thought they were worth mentioning.
There will always be lots of back and forth between those who want the software written, and those who are writing it.
I was reading an article in either an IEEE magazine or an ACM magazine not too long ago, and the authors claimed that outsourced software might be of higher quality precisely because of the absence of back and forth that's around in-house. Management (or whoever wants the software written) is forced to spend more time defining requirements properly before handing them over to the programmers.
There are really two separate issues: 1. Management doesn't tell the programmers what they really want in the software, and 2. Management doesn't actually know what they really want in the software. If #1 is the dominant problem, then outsourcing might get you better software because the requirement docs might be better on average, but if #2 is the dominant problem, then outsourcing might get you worse software because there isn't enough feedback getting back to management.
Bandwidth has nothing to do with the current through a line (or not much....)
Doesn't that depend on what type of "bandwidth" you are talking about? If you're talking about bandwidth in the traditional "frequency-response" sense (e.g. bandwidth of a filter), then yes, it doesn't matter how much power you send over the lines, the bandwidth of the same.
But if you mean "bandwidth" in the sense of number of bits transmitted per second (which is really channel capacity, not bandwidth, though it's a function of bandwidth), then your available signal power matters a lot!
I'm talking strictly from a theoretical point of view here. I have no idea how much of the total power you can use to transmit your data over these lines, or what the other practical issues are. I was just trying to draw the distinction between bandwidth and channel capacity, since people use "bandwidth" interchangeably.
Sure, you can explain a microwave with QM, but you can also explain a rifle round, and no one claims that we wouldn't have bullets w/o QM.
An even better example would be glass. We couldn't properly explain why glass was transparent until quantum theory came around, but we had been making glass for a looooong time before that.
Chess, is not as some people seem to believe, the absolute sign of intelligence.
Well, it used to be, back before people really thought about how to build a chess program. One of the problems with AI is that we don't really know what "intelligence" is. Every time we are able to write a computer program to solve a problem that we thought required intelligence, we conclude, "Oh, then that can't be what we meant by intelligence" rather than "The computer has now achieved intelligence."
Dave Parnas is rarely mentioned as one of the "great computer science", but his ideas have been very influential in software engineering. He wrote on information hiding and separation of concerns well before object-oriented programming existed. His discussion of "undesired events" was a forerunner to exception handling mechanisms. He wrote of families of software products decades ago which is only now being actively pursued under the term "product lines".
A number of his papers have been collected into a book called "Software Fundamentals: Collected Papers by David L. Parnas".
people who know they are going to drive like maniacs will select cars without blackboxes
As someone else suggested, one way to deal with this is to allow insurance companies to take the presence of a black box into account when setting their rates. You can bet that insurance companies are going to charge a lot more to those who don't want these boxes, since (as you pointed out) they're more likely to be the riskier drivers.