Most humans who are really good at a task are so because of absorbing decadeds or centuarys of previously learned knowledge. Your point is?
There are a class of problems where it's possible to train a computer to absorb enormous amounts of history, find patterns, and potentially produce improvements on what it was taught. Games and music are easy to convert into computer form for the system to assimilate and train from. It's important not to extrapolate too far from successes in these areas though, because I don't believe that are actually that many problems in that class.
Deep Blue beat Kasparov after being trained on a giant library of Kasparov games. If Emmy can be trained to compose like Mozart after being exposed to his music I'm similarly unimpressed. The fact that it's possible to extract patterns from analyzing human behavior and then replicate those patterns as well as a person isn't all that special. Deep Blue had its occasional moment where it did something really brilliant that no person was likely to have ever considered, but even that's only after having consumed centuries of human knowledge to reach that point.
HDMI signals that aren't quite good enough for the transmission length and bit rate they're being challenged with do not necessarily fail in a binary "get a picture/don't get a picture" way. On the edge of failure, there's a class of bit errors that are measurable and possibly visible but not so bad that the connection drops altogether. There's a decent intro the topic on the Blue Jeans HDMI Cables Overview, and the visual pattern just before the connection becomes unusable is usually described as a "sparkle". This is not unique to HDMI; similar DVI sparkles have been described for years.
This is not intended as a defense of Monster's products though. Even those paying attention to sparkle issues and the like know that there are plenty of cheap models from sources like Monoprice that work just fine; the comments at CNET on HDMI are a fair description of the marketplace.
I'm not sure they're just measuring memory consumption. It looks like the metric used may be what is described by the vendor as:
"The Peak Memory Pressure Index is calculated by comparing a series of 4 independent Windows metrics – the Memory\Committed Bytes counter, the Memory\Pages Input/sec counter, the PageFile\% Usage counter and the aforementioned event duration value – against a set of user-defined threshold values. The resulting individual ratios are then weighted and combined to create the single number Peak Memory Pressure Index value."
That seems equally bogus and needlessly complicated to boot though; I wouldn't want to be the guy who had to defend that measurement as useful.
The debugging version of the 50:50 is easy. Get two completely disconnected teams of people to write the same software. Track the bug rates on each for a while. Then throw away the one that has the worse track record; it's probably got more as yet unknown bugs, too.
This is actually something the open-source community does sometimes. You'll get two sets of people develop more or less the same app/library/etc., and after a while only one of them survives because the other one dies under the weight of its bugs.
So your opinion is that my suggesting two books to read, followed by notes on how to find the extensive academic library on this subject, added nothing worthy to the discussion? Interesting.
I corrected one point in your otherwise useful commentary, admittedly in a somewhat snarky fashion--that was meant to be a bit of a joke by the way, which you didn't take well. The cherry picking out of context started when you decided to pick on one word I used, rather than considering that perhaps my quick spoof suggesting literature in this area was just alluding to a larger issue in how you described it. You don't quite seem to have gotten that still; "less coverage than it deserves" is just not a defensible position, given that there are in fact two major books and thousands of research papers on this very specific topic.
Let's me preempt your next comment: "but how many of those are 'professional journals or books'?". Well, 2,640 of those are from the journal of the ACM. That's just a bit more than few now, isn't it? Looks like you have some reading besides dictionary.com to do.
I inherited some code where the developer used names of girlfriends in variable names, it was just dumb and completely unprofessional.
I once inherited a coding project where the naming conventions involved anti-depressant, anti-anxiety, and sleeping drugs. Let me tell you, that's a fun preview of how one's future working on the project might turn out.
Sure, if you only have a trivial 250K lines of code, I guess you can use crappy tools like Xcode and Visual Studio to maintain your project. The rest of us have to use grown-up tools that look like this:
There's only one way to learn your way around a new codebase, and the worst thing you can do is use a tool that aims to help with the job. Want to know how stuff flows through the program? Find where the program starts and draw the diagram yourself as you map it out. What I do is find something that I think I need to change, and a clear goal for what change I want to make to it, then map out exactly how the program reaches that point. You need to have a targeted goal to make progress with a stack of new code; just trying to read the whole thing or stare at diagrams of it won't teach you anything. Put the sucker into version control, generate regression tests of its output, figure out how to build after making a trivial change, and then try making a small non-trivial one. That's the only real way to learn how a program really works that internalizes enough of it into your brain that you can move upward to bigger maintenance tasks.
And, for the record, I would like to tell everyone who suggested using a debugger to trace through the code instead of figuring it out by inspection and experiments that you are all a bunch of pussies. Good luck with that when the code breaks in production and you've got nothing but log files from the period loading up to the crash to work with. If I can get a debugger to attach to a broken program when the problem exists, it is by definition a trivial problem to solve; if I can even get a backtrace of where the thing is stuck at when it goes bad that's automatically an easy one. The only way to learn what you should be logging and defensively doing is by only relying on logs, assertions, and testing all the time--never a debugger. Because when things go really wrong, you won't have your debugger to save your ass--but if you built in good testing and logging capabilities, they'll be there.
Hmm... I can't reprogram the computer built into my new car - by your logic, I don't own my car, and Toyota hates tinkerers.
That's your fault for having no skills. People who do love to Hack the Prius car computer to improve the mileage. Sort of the opposite of the earlier breed who liked to hack their car for better horsepower etc. This stuff has been going on for years now.
The BASIC interpreter was also the operating system, such as it was. I can imagine the howls of protest from slashdotters if someone praised a computer that had an MS operating system built into it, in rom:-) Today if you want to run an alternative OS like linux on your mac or PC, all you have to do is pop a CD in the drive and click OK. Then, the alternative OS was CP/M, and you couldn't run CP/M without hardware modifications.
Applesoft Basic was sitting in ROM and functional without an operating system, but it by no means was a proper operating system. It barely knew enough to boot a proper disk-based OS.
You needed a card to run CP/M because it wasn't ported to the 6502. No reason they couldn't have done it, just nobody gave a damn.
There were multiple operating systems available for the Apple II series. There was the original Apple DOS, with both integer basic and floating point variations. Apple ProDOS was a second. And in a completely different vein, there was Apple Pascal. That required a hardware upgrade initially--you needed a smarter disk controller ROM and more RAM to make it run in an Apple II+--but by the time the 64K Apple IIe came out all that stuff was integrated into the standard package and it was just another piece of software.
There isn't remotely enough information included in the paperwork the IRS receives for it to compute the tax you owe on stock trading related capital gains. To give an idea of the scope of the problem for those who execute trades, one year I was late submitting my return due to problems getting the trading portions accounted for properly. The IRS helpfully sent me a form saying they had done the math for me, and if I just paid their computed amount I could skip filing the return. In the end, I was due a small refund, a few thousand dollars; the estimate they sent was that I owed $250K.
However, the existence of odd cases like trading and self-employed people who the IRS cannot know how to handle doesn't change that fact that everybody filling out a 1040-EZ and the like would likely have ended up with the same return regardless of whether they filed or not. You can't say that there's not a net saving for the country at large just because there are a small number of difficult corner cases floating around. So long as you can file a return if you want to, things shouldn't have to change for people in those groups, while the people with simple returns could save a lot of processing work.
OP had the origin right. See There ain't no such thing as a free lunch for a history here. First documented use in an economics context in the 1940's, popularized by Heinlein's "The Moon is a Harsh Mistress" in 1966. The Second law of thermodynamics predates both of those, but there's no evidence that this particular phrase was used in that context before being applied to economics.
The fundamental unit of all SCMs is the changeset. It's possible to convert between the various changeset formats using a tool like Tailor. So you could build a useful prototype of something like this by running incoming and outgoing changesets through that sort of tool to convert to the native format of the server SCM. You can convert them to the native format on the server, so no need to invent a new distribution protocol. People end up building one-offs for this sort of thing out of simple shell scripts sometimes while doing a VCS migration, like attaching an exporter to the post-commit hook on the master to handle the distribution side. I think part of the reason there's been little uptake on a more universal approach is because it's not that hard to hack together something that handles any two of the options here.
As you can see on the Tailor documentation page, there's already other projects building in the direction of more universal changesets too. One major issues with aiming for really broad support here is testing to make sure every possible operation works, and in cases where they don't figuring out how to limit the subset of work to the common denominator.
The issues here are not around carrying digital data, they're about carrying a clock signal. In the Denon Link example, there is no data besides the clock anymore, there's no data bits to be extracted, so comments about zeros and ones aren't even relevant to that case. If I send you the right data, but it's at the wrong time, that's not really the right data anymore, and that's going to be audible once that lag ("clock jitter") becomes high enough and random enough. I doubt that's really the case here, because of the internals of how the clocks are transmitted and recovered nowadays make it really unlikely for jitter to show up in any quantity, but looking at the data bits isn't the right area to discuss what might be happening. Digital audio transmission doesn't just have to get the right bits there, they have to show up at the right time, and in some cases you can't just put a buffer and reclock in the middle.
The purpose of Denon Link nowadays is to provide a better path to line up the signal and clock on audio it transmits. It's not taking the audio data, converting it into packets, and sending it over something Ethernet-like. As such, some of the criticisms that are based on presuming it operates just like a network cable are misinformed. It's unlikely the cable is anything special, but reasoning about it from the position that it's just transmitting Ethernet isn't appropriate.
US Doctors are barely trained on diet related issues at all, so they just don't know. For example, much of the training of a gastroenterologist--the person you'll end up at if a gluten issue is suspected--is focused on surgical procedures and recovery from life-threatening conditions. If you need a section of your colon removed, or are about to die from toxic megacolon, this is exactly the training you want them to have. But if you just have a mild condition that's linked to diet instead, they're not so much help.
The same principle applies to other doctors too. Do you want your family doctor trained on how to spot life threatening issues, or techniques to track down food sensitivity? There's really not enough time to learn everything in this field. I know a ton about this whole gluten/celiac intersection because my quality of life depends on it (I'm gluten sensitive but not a classic celiac case), and I've never found a doctor who was as informed as I am about it. I know whose knowledge I'm going to yield to if I need surgery or emergency treatment though.
There's a difference between "sensitivity" and "allergy"
I would object to the idea that there's a real line between the two. The difference between a mild allergy and a bad sensitivity is not so clear, and that's particularly obvious when it comes to gluten. The difference between Idiopathic gluten sensitivity and the obvious allergy of celiac disease is quite fuzzy.
Diagnosing someone with celiac disease is hard. The sort of tissue damage they look for on the biopsy can heal if it's mild, only showing up as mild inflammation which may not even be visible. That means that it can only prove you do have celiac disease, not really the inverse. Mild gluten sensitivity cases can show up on something like an antigliadin antibody test even if there's no visible damage to the tissue yet.
Sure it did; a big one at that. The fact that they crapped out a terrible movie and it grossed more than the first or second is exactly why they're following this path.
Playing Pac-Man well requires intense concentration, memory, and plain old fashioned stamina. If you don't find that intellectually stimulating, you have failed to understand the game.
you have to have concurrency issues completely nailed down (ideally with row level locking and ACID).
Even row-level locking ends up being a scalability issue eventually. This is why PostgreSQL uses MVCC for transaction isolation by default instead, which is one of the reasons it can scale upward well for some types of workloads.
Slashdot Mirror
Most humans who are really good at a task are so because of absorbing decadeds or centuarys of previously learned knowledge. Your point is?
There are a class of problems where it's possible to train a computer to absorb enormous amounts of history, find patterns, and potentially produce improvements on what it was taught. Games and music are easy to convert into computer form for the system to assimilate and train from. It's important not to extrapolate too far from successes in these areas though, because I don't believe that are actually that many problems in that class.
Deep Blue beat Kasparov after being trained on a giant library of Kasparov games. If Emmy can be trained to compose like Mozart after being exposed to his music I'm similarly unimpressed. The fact that it's possible to extract patterns from analyzing human behavior and then replicate those patterns as well as a person isn't all that special. Deep Blue had its occasional moment where it did something really brilliant that no person was likely to have ever considered, but even that's only after having consumed centuries of human knowledge to reach that point.
HDMI signals that aren't quite good enough for the transmission length and bit rate they're being challenged with do not necessarily fail in a binary "get a picture/don't get a picture" way. On the edge of failure, there's a class of bit errors that are measurable and possibly visible but not so bad that the connection drops altogether. There's a decent intro the topic on the Blue Jeans HDMI Cables Overview, and the visual pattern just before the connection becomes unusable is usually described as a "sparkle". This is not unique to HDMI; similar DVI sparkles have been described for years.
This is not intended as a defense of Monster's products though. Even those paying attention to sparkle issues and the like know that there are plenty of cheap models from sources like Monoprice that work just fine; the comments at CNET on HDMI are a fair description of the marketplace.
I'm not sure they're just measuring memory consumption. It looks like the metric used may be what is described by the vendor as:
"The Peak Memory Pressure Index is calculated by comparing a series of 4 independent Windows metrics – the Memory\Committed Bytes counter, the Memory\Pages Input/sec counter, the PageFile\% Usage counter and the aforementioned event duration value – against a set of user-defined threshold values. The resulting individual ratios are then weighted and combined to create the single number Peak Memory Pressure Index value."
That seems equally bogus and needlessly complicated to boot though; I wouldn't want to be the guy who had to defend that measurement as useful.
The debugging version of the 50:50 is easy. Get two completely disconnected teams of people to write the same software. Track the bug rates on each for a while. Then throw away the one that has the worse track record; it's probably got more as yet unknown bugs, too.
This is actually something the open-source community does sometimes. You'll get two sets of people develop more or less the same app/library/etc., and after a while only one of them survives because the other one dies under the weight of its bugs.
So your opinion is that my suggesting two books to read, followed by notes on how to find the extensive academic library on this subject, added nothing worthy to the discussion? Interesting.
I corrected one point in your otherwise useful commentary, admittedly in a somewhat snarky fashion--that was meant to be a bit of a joke by the way, which you didn't take well. The cherry picking out of context started when you decided to pick on one word I used, rather than considering that perhaps my quick spoof suggesting literature in this area was just alluding to a larger issue in how you described it. You don't quite seem to have gotten that still; "less coverage than it deserves" is just not a defensible position, given that there are in fact two major books and thousands of research papers on this very specific topic.
Results 1 - 10 of about 1,070,000 for "legacy code"
Let's me preempt your next comment: "but how many of those are 'professional journals or books'?". Well, 2,640 of those are from the journal of the ACM. That's just a bit more than few now, isn't it? Looks like you have some reading besides dictionary.com to do.
It's kind of neat to work in an engineering operation attached to a factory. You get to see your designs turned into real problems.
Fixed that for you.
it is a sizeable task, and is the type of topic that few professional journals or books will ever be written about.
Right, no one has ever written a single book on that topic.
I inherited some code where the developer used names of girlfriends in variable names, it was just dumb and completely unprofessional.
I once inherited a coding project where the naming conventions involved anti-depressant, anti-anxiety, and sleeping drugs. Let me tell you, that's a fun preview of how one's future working on the project might turn out.
Sure, if you only have a trivial 250K lines of code, I guess you can use crappy tools like Xcode and Visual Studio to maintain your project. The rest of us have to use grown-up tools that look like this:
src$ find . -print | xargs wc | tail -n 1
1950894 7085675 56777966
There's only one way to learn your way around a new codebase, and the worst thing you can do is use a tool that aims to help with the job. Want to know how stuff flows through the program? Find where the program starts and draw the diagram yourself as you map it out. What I do is find something that I think I need to change, and a clear goal for what change I want to make to it, then map out exactly how the program reaches that point. You need to have a targeted goal to make progress with a stack of new code; just trying to read the whole thing or stare at diagrams of it won't teach you anything. Put the sucker into version control, generate regression tests of its output, figure out how to build after making a trivial change, and then try making a small non-trivial one. That's the only real way to learn how a program really works that internalizes enough of it into your brain that you can move upward to bigger maintenance tasks.
And, for the record, I would like to tell everyone who suggested using a debugger to trace through the code instead of figuring it out by inspection and experiments that you are all a bunch of pussies. Good luck with that when the code breaks in production and you've got nothing but log files from the period loading up to the crash to work with. If I can get a debugger to attach to a broken program when the problem exists, it is by definition a trivial problem to solve; if I can even get a backtrace of where the thing is stuck at when it goes bad that's automatically an easy one. The only way to learn what you should be logging and defensively doing is by only relying on logs, assertions, and testing all the time--never a debugger. Because when things go really wrong, you won't have your debugger to save your ass--but if you built in good testing and logging capabilities, they'll be there.
Hmm ... I can't reprogram the computer built into my new car - by your logic, I don't own my car, and Toyota hates tinkerers.
That's your fault for having no skills. People who do love to Hack the Prius car computer to improve the mileage. Sort of the opposite of the earlier breed who liked to hack their car for better horsepower etc. This stuff has been going on for years now.
The BASIC interpreter was also the operating system, such as it was. I can imagine the howls of protest from slashdotters if someone praised a computer that had an MS operating system built into it, in rom :-) Today if you want to run an alternative OS like linux on your mac or PC, all you have to do is pop a CD in the drive and click OK. Then, the alternative OS was CP/M, and you couldn't run CP/M without hardware modifications.
Applesoft Basic was sitting in ROM and functional without an operating system, but it by no means was a proper operating system. It barely knew enough to boot a proper disk-based OS.
You needed a card to run CP/M because it wasn't ported to the 6502. No reason they couldn't have done it, just nobody gave a damn.
There were multiple operating systems available for the Apple II series. There was the original Apple DOS, with both integer basic and floating point variations. Apple ProDOS was a second. And in a completely different vein, there was Apple Pascal. That required a hardware upgrade initially--you needed a smarter disk controller ROM and more RAM to make it run in an Apple II+--but by the time the 64K Apple IIe came out all that stuff was integrated into the standard package and it was just another piece of software.
Yes, I hear they've got her locked up tight in a sanctuary.
There isn't remotely enough information included in the paperwork the IRS receives for it to compute the tax you owe on stock trading related capital gains. To give an idea of the scope of the problem for those who execute trades, one year I was late submitting my return due to problems getting the trading portions accounted for properly. The IRS helpfully sent me a form saying they had done the math for me, and if I just paid their computed amount I could skip filing the return. In the end, I was due a small refund, a few thousand dollars; the estimate they sent was that I owed $250K.
However, the existence of odd cases like trading and self-employed people who the IRS cannot know how to handle doesn't change that fact that everybody filling out a 1040-EZ and the like would likely have ended up with the same return regardless of whether they filed or not. You can't say that there's not a net saving for the country at large just because there are a small number of difficult corner cases floating around. So long as you can file a return if you want to, things shouldn't have to change for people in those groups, while the people with simple returns could save a lot of processing work.
OP had the origin right. See There ain't no such thing as a free lunch for a history here. First documented use in an economics context in the 1940's, popularized by Heinlein's "The Moon is a Harsh Mistress" in 1966. The Second law of thermodynamics predates both of those, but there's no evidence that this particular phrase was used in that context before being applied to economics.
The fundamental unit of all SCMs is the changeset. It's possible to convert between the various changeset formats using a tool like Tailor. So you could build a useful prototype of something like this by running incoming and outgoing changesets through that sort of tool to convert to the native format of the server SCM. You can convert them to the native format on the server, so no need to invent a new distribution protocol. People end up building one-offs for this sort of thing out of simple shell scripts sometimes while doing a VCS migration, like attaching an exporter to the post-commit hook on the master to handle the distribution side. I think part of the reason there's been little uptake on a more universal approach is because it's not that hard to hack together something that handles any two of the options here.
As you can see on the Tailor documentation page, there's already other projects building in the direction of more universal changesets too. One major issues with aiming for really broad support here is testing to make sure every possible operation works, and in cases where they don't figuring out how to limit the subset of work to the common denominator.
The issues here are not around carrying digital data, they're about carrying a clock signal. In the Denon Link example, there is no data besides the clock anymore, there's no data bits to be extracted, so comments about zeros and ones aren't even relevant to that case. If I send you the right data, but it's at the wrong time, that's not really the right data anymore, and that's going to be audible once that lag ("clock jitter") becomes high enough and random enough. I doubt that's really the case here, because of the internals of how the clocks are transmitted and recovered nowadays make it really unlikely for jitter to show up in any quantity, but looking at the data bits isn't the right area to discuss what might be happening. Digital audio transmission doesn't just have to get the right bits there, they have to show up at the right time, and in some cases you can't just put a buffer and reclock in the middle.
The purpose of Denon Link nowadays is to provide a better path to line up the signal and clock on audio it transmits. It's not taking the audio data, converting it into packets, and sending it over something Ethernet-like. As such, some of the criticisms that are based on presuming it operates just like a network cable are misinformed. It's unlikely the cable is anything special, but reasoning about it from the position that it's just transmitting Ethernet isn't appropriate.
US Doctors are barely trained on diet related issues at all, so they just don't know. For example, much of the training of a gastroenterologist--the person you'll end up at if a gluten issue is suspected--is focused on surgical procedures and recovery from life-threatening conditions. If you need a section of your colon removed, or are about to die from toxic megacolon, this is exactly the training you want them to have. But if you just have a mild condition that's linked to diet instead, they're not so much help.
The same principle applies to other doctors too. Do you want your family doctor trained on how to spot life threatening issues, or techniques to track down food sensitivity? There's really not enough time to learn everything in this field. I know a ton about this whole gluten/celiac intersection because my quality of life depends on it (I'm gluten sensitive but not a classic celiac case), and I've never found a doctor who was as informed as I am about it. I know whose knowledge I'm going to yield to if I need surgery or emergency treatment though.
There's a difference between "sensitivity" and "allergy"
I would object to the idea that there's a real line between the two. The difference between a mild allergy and a bad sensitivity is not so clear, and that's particularly obvious when it comes to gluten. The difference between Idiopathic gluten sensitivity and the obvious allergy of celiac disease is quite fuzzy.
Diagnosing someone with celiac disease is hard. The sort of tissue damage they look for on the biopsy can heal if it's mild, only showing up as mild inflammation which may not even be visible. That means that it can only prove you do have celiac disease, not really the inverse. Mild gluten sensitivity cases can show up on something like an antigliadin antibody test even if there's no visible damage to the tissue yet.
There's plenty of data showing gluten causes migraines in some people; see Migraine Headaches: Gluten Triggers Severe Headaches in Sensitive Individuals and Migraine Linked to Celiac Disease as two examples, there are a couple more. Your wife probably has something in the Gluten-sensitive idiopathic neuropathies family of issues.
If he's trying to find one that's super hot...[and] not a deranged bitch
You realize you described something less likely than alien life with just these two requirements, right?
And yet the film still hasn't turned a profit.
Sure it did; a big one at that. The fact that they crapped out a terrible movie and it grossed more than the first or second is exactly why they're following this path.
Playing Pac-Man well requires intense concentration, memory, and plain old fashioned stamina. If you don't find that intellectually stimulating, you have failed to understand the game.
you have to have concurrency issues completely nailed down (ideally with row level locking and ACID).
Even row-level locking ends up being a scalability issue eventually. This is why PostgreSQL uses MVCC for transaction isolation by default instead, which is one of the reasons it can scale upward well for some types of workloads.