It has been. The actual "Debt Ceiling" was reached back in May. But Lo! and behold! The government found some "extra cash" lying around, and managed to survive until now anyway. Of course you don't hear about this on the news.
"The government takes in enough tax revenue each month to pay the interest on bonds many times over. There is zero possibility of the government 'defaulting' and wiping out their credit rating."
The default scare is just another Big Lie. First, the government HAS defaulted on its debt before. The most recent time I know about was when Nixon nixed the Bretton Woods system in '71, eliminating any last vestige of a gold standard. The dollar (in International Trade) was almost instantly devalued, which for all practical purposes was a default on large portion of the huge foreign debt. In fact, that's why he did it: the U.S. government did not have enough money (including for repaying debt), by virtue of its gold reserves, to cover its exorbitant spending.
Second: not raising the debt ceiling will not automatically lead to a default. The government would simply have to spend less money! Of course, Obama has been showing that he'd rather cut spending on things The People find valuable (or are scared into thinking are essential), than cut spending on things that actually make sense.
Well, I don't disagree with you either, necessarily. But regarding terminology, I would call your "backend" people "programmers", and the other guys "hacks".
Just as a rivet-pounder building a bridge is not an engineer.
"There is absolutely no reason to have the various sorts memorized, no matter what you do for a living."
THAT is absurd. Seriously.
"Not once have I ever needed to write a sorting function or try to remember the differences in implementation of the different sort algorithms. It just isn't important."
And I'd be willing to bet that the fact that you don't even remember something so ridiculously simple and fundamental has a direct relationship to the quality of your code.
It's only a guess and I could be wrong. But if I were to bet on it, that's they way I'd bet.
"I've met coders who talk like you, and when they do, they're so impractical in their overarching decisions that often the software is DOA because it doesn't do enough, or it took too long to write, or it was endlessly being refactored."
Who talk like me? It's funny, because I'm not even disagreeing with most of what you say. But a quicksort is not rocket science, and anybody who studied programming or CS in college has been exposed to how they work. If they have any schooling behind them with significantly more depth that PHP scripting, they were probably also exposed to how hash tables are contstructed.
Why is it arrogant to insist that they remember some of the most basic things they learned? If I were to hire a mechanical engineer I'd want to be sure he knows trigonometry.
But if you're talking about some guy pounding rivets, well, he's not an engineer. He's a hack laborer, and he probably doesn't need to remember his trigonometry. And that's exactly the difference I was talking about.
"I dare say I could write one pretty quickly if asked, but it would be a much more efficient use of my time to just google for one since there are tons of them out there without any licence restrictions. "
Please read what I wrote a bit more carefully. I did not write that I think you should be writing such things on a daily basis. And I certainly don't recommend it. But you should be able to, should the need arise.
"Right - but if I catch a programmer ever actually implementing a quicksort by themselves though, they're fired."
Well, I won't argue with that. As I stated earlier, I don't think one should spend every day re-inventing the wheel. But knowing how to make a wheel if you have to is a valuable skill.
Haha. Point taken. Come to think of it, the only language I can recall off-hand that is officially all-capitalized is BASIC, because it's an acronym.
I was ribbing GP a little. In general, I agree that one should be able to pick up another language without TOO much difficulty. But many people I have spoken to (I have done some Perl but it was only to translate existing code to another language) have found existing programs in Perl to be singularly difficult to decipher. I understand that it is generally due to the flexibility of the language, but "magic" symbols don't help a lot.:)
And to be clear, I'm not referring to myself above, because the Perl code I worked on was in a very well-defined context and consistently structured. So I'm in no place to criticize it, myself.
By "Carteresque" I presume you mean "stagflation", which (maybe preaching to the choir?) Keynesians denied was even possible under their "scientific" projections... until it actually happened and lasted for years. (In fact it was not even the Keynesians, with all their "scientific" theory, who figured out a somewhat plausible mechanism for stagflation to fit the Philips curve... it was Milton Friedman, who was rather rabidly anti-Keynes.)
But it just goes to show you that just because you can reduce a theory to a nice "scientific" curve on a chart, the worth of your theory is still only how well it can predict... and Keynesians have historically scored near zero in that regard.
"But I was more talking about the notion of "raising the median income" as often trumpeted by the Left. You simply can't raise the purchasing power of the average family above what any reasonably efficient economy delivers - ignore all the currency, the actual cars and TVs and such per family are a matter of manufacturing capacity/efficiency, not income distribution. Growth in that regard comes from technological progress, not economic games."
I agree. I guess I should have clarified that when I wrote "median income", I meant "median income, adjusted for inflation". Because that compensates for buying power. *IF*, that is, you use real figures for inflation, not government's customary lie of "2%". Or -- Keynesians, please hide your eyes -- the mild deflation that would be an indication of an actually healthy economy.
I generally agree with you, but I would add that air travel and communication are pretty clearly subject to "interstate commerce" regulation, as firmly established in the Constitution, even under the strictest sense of interstate commerce. So there is no need to dream up an "extra-constitutional" authority for either FAA or FCC.
There ARE legitimate arguments that they have at times exceeded their authority. But that doesn't bear on the constitutionality of their very existence.
"1. Don't use proven libraries to solve common programming tasks (e.g., collections).
2. Write everything from scratch!
3. Argue that it is a time and budget advantage to do so."
No. That wasn't the point of this discussion at all.
I highly recommend that programmers DO use proven libraries to solve common tasks. BUT, a programmer who is worth a real programmer's salary COULD write them herself if she had to, which means she also has the skill to identify and preferably fix bugs in said libraries. After all... open source software is all bug-free, yes? (Not that it has to be open source... just an example.)
I wasn't saying a programmer should write everything from scratch every day. But if you don't know how to, you're SOL and at everybody else's mercy when something goes wrong. You're costing your company money. Because things go wrong.
"Sometimes you need more than a mass-produced transport designed to a price for the lowest common denominator."
Agreed. Just as engine mechanics fix engines -- for FAR less cost than simply buying a new one -- if you have a coder who actually knows how to code, maybe he or she can FIX a problem, rather than re-writing your whole application from scratch.
In some ways this is even more important than in the engine mechanic analogy, because your software likely WAS written from scratch. So it's a hell of a lot cheaper to hire a code "mechanic" who knows what she's doing to fix it, than it is to do it all over again from the ground up.
" Premature reports of the eminent death of hydrocarbon reserves have been circulating since Carter(76-80) in this fool's living memory"
Yes, I remember them too. But also remember Malthus: by his famous principle, we would all have eaten each other about 600 years ago.
The problem with these doomsayers is that they take any given short-term trend and extend it out to infinity, without regard for any other variables or changes. It's what Malthus did, it's what the Global Warmists did, it's what the "peak oil" people did.
"I agree with the anon poster. You are an idiot. A computer scientist better be able to write a QS in their sleep, but a programmer better know how to find a suitable implementation already written."
That's not a programmer, that's a hack just out of high school. There IS a big difference, and if you don't know what that difference is, you're paying too much money.
Now tell me again who's the idiot.
I wasn't suggesting that every programmer has to know how to do finite-elelement modeling, for fuck's sake. But if you don't know a Quicksort from a Bubble sort, or how to write them, you're not a programmer by any standard I ever heard of, and I've been around.
I didn't write manufacture a V8 from scratch, I wrote "build".
I rebuilt an engine, and I'm very far from an auto mechanic. And in the interest of keeping the record straight, I had help and advice. But that's my point here: I wrote "build", not "design and manufacture all the parts from scratch". It's all fine to get help and advice for coding, too. But I wasn't suggesting trying to independently re-invent internal combustion or anything like that.
"I would much rather my mechanic focus his efforts on being good at diagnosing problems and installing factory-made parts rather than troubling himself with building parts himself."
Cool. So when something fails, you can pay them to go find some other pre-built part, and follow the instructions to hopefully make it work.
That's fine, I suppose, if you have the time and the budget. I prefer to simply hire people who know what the hell they're doing.
"So why is Daniel trying to compile a list that everybody will agree with? That would be a list of what every non-master programmer agrees a master programmer should know, which is different than a list of what a programmer should know to be a master programmer..."
No, it isn't. It's INTENDED to be the opposite: a list that master programmers can agree every non-master should know.
You have to admit: there's a lot of master-level programming talent who check in to Slashdot.
"Quicksort is already implemented a thousand times, so there's no need to implement it again, just find which library you need."
Yes, that's true, but we're talking about education here, not building websites.
If you're a coder, and you don't know how to BUILD a hash table from genuinely fundamental, low-level components, or if you can't do a quicksort from those same fundamental building blocks, guess what? I won't hire you.
It's great to be able to buy or borrow a used V8, but if you don't know how to build one, you're not going to be my mechanic.
Correct. I wondered about that myself. Those are important but hardly basic.
A stack is a basic structure, as you say. A string is a basic structure, with several different but classic storage schemes. (Please don't start in with "That's a data type, not a structure." Nonsense. They're all structures.)
Integers are basic. As are longints, etc. They may vary from platform to platform, but they're still pretty basic. As is the byte, for example. The meaning of that has changed over the years (now meaning just 8 bits, period... it used to be variable depending on the architecture), but it's pretty basic and quite important.
Arrays are basic.
Hash tables are not "basic". In fact that used to be a rather lengthy section of basic CS classes; how to implement an efficient hash table in code. There is nothing even remotely basic about them; the data and underlying code of the class are quite complex compared to truly basic structures. Some modern languages just make them SEEM simple. But I know few coders today who could actually build a good one from really basic components.
Saying that a hash table is a basic data structure is like saying Quicksort is a native operator.
"As I explained in the first article: If you take away the "right to remain silent", a suspect can still say, "No, I didn't do it," and the police options for "coercing" them are the same as they were before."
Not their legal options. You argue against yourself. You appear to be saying that the existence of the law doesn't matter because police and courts will ignore it anyway. Yet we have 200+ years of history showing that it DOES make a difference.
If that isn't what you're arguing, then I don't understand what you're trying to say.
"That's why I said in the first article: the only answer I would accept is a specific scenario in which the outcome is different because of the Fifth Amendment."
Do you have any idea how many people were NOT convicted because they pled the 5th? You can look them up yourself... I'm not going to do it for you. But I would say that 99% of those made a difference.
But I can give you one (although I don't have an actual citation at hand... it shouldn't be hard to look it up). The recent Federal case in which the judge ruled that the suspect could not be compelled to hand over the password to his hard drive is a specific example of one situation in which it almost certainly made a difference.
"Take the cops trying to coerce a confession. With the Fifth Amendment, the suspect remains silent, which cops don't like. Without the Fifth Amendment, the suspect can say, "I didn't do it", and refuse to answer questions about anything else, which cops don't like. You haven't shown why the outcome in either case would be different. (If you think the cops are going to beat the suspect until they get the answer they want, that's a problem whether the suspect is remaining silent, or giving answers other than what the cops want to hear.)"
The reason this is a straw-man argument is that it isn't JUST the cops. It's our whole court system. The courts can't compel a confession, or accept testimony about one that was compelled, coerced or extorted.
"Even if the dollar becomes worthless, my employer will pay me in some form that people selling the basics will accept - some sort of barter-intermediary will be around."
It's happened before, even here, and the people it happened to would have laughed at your reasoning. If they weren't too hungry to laugh.
The consensus (among non-"Keynesian"... which pretty much means most non-Government) economists is that government monetary policy led directly to the crash of '29, and that FDR's subsequent monetary policy prolonged the depression for 10 years longer than it might otherwise have lasted. Which -- hint, hint -- is exactly the kind of inflationary, interventionist policy Obama has been following.
FDR's own Treasury Secretary thought he was nuts... and history pretty much agrees.
But to get back to the main point: it HAS happened before, it WAS bad, and "modern" economics isn't going to prevent it. On the contrary: they are making the very same mistakes that were made 80+ years ago.
"I'm not sure anything but technology affects the purchasing power of the median income much"
I am. Government spending, taxation, monetary policy, etc. all affect the median income. I fail to see how you do not recognize that. After all, we are right now, today, climbing out of a terrible recession that was largely caused by government regulation (or lack thereof). And we are right now starting to feel the real ill effects of government-influenced (Fed) monetary policy. Have you looked at your grocery bill lately? Commodities like food are usually the first things to go up when inflation hits.
Slashdot Mirror
"The Debt Ceiling can remain ignored for months."
It has been. The actual "Debt Ceiling" was reached back in May. But Lo! and behold! The government found some "extra cash" lying around, and managed to survive until now anyway. Of course you don't hear about this on the news.
"The government takes in enough tax revenue each month to pay the interest on bonds many times over. There is zero possibility of the government 'defaulting' and wiping out their credit rating."
The default scare is just another Big Lie. First, the government HAS defaulted on its debt before. The most recent time I know about was when Nixon nixed the Bretton Woods system in '71, eliminating any last vestige of a gold standard. The dollar (in International Trade) was almost instantly devalued, which for all practical purposes was a default on large portion of the huge foreign debt. In fact, that's why he did it: the U.S. government did not have enough money (including for repaying debt), by virtue of its gold reserves, to cover its exorbitant spending.
Second: not raising the debt ceiling will not automatically lead to a default. The government would simply have to spend less money! Of course, Obama has been showing that he'd rather cut spending on things The People find valuable (or are scared into thinking are essential), than cut spending on things that actually make sense.
Um... since about 2 months ago, give or take?
Admittedly, people were ridiculously slow in waking up to this threat, which many others of us warned about... but waking up, they are.
Well, I don't disagree with you either, necessarily. But regarding terminology, I would call your "backend" people "programmers", and the other guys "hacks".
Just as a rivet-pounder building a bridge is not an engineer.
"There is absolutely no reason to have the various sorts memorized, no matter what you do for a living."
THAT is absurd. Seriously.
"Not once have I ever needed to write a sorting function or try to remember the differences in implementation of the different sort algorithms. It just isn't important."
And I'd be willing to bet that the fact that you don't even remember something so ridiculously simple and fundamental has a direct relationship to the quality of your code.
It's only a guess and I could be wrong. But if I were to bet on it, that's they way I'd bet.
"I've met coders who talk like you, and when they do, they're so impractical in their overarching decisions that often the software is DOA because it doesn't do enough, or it took too long to write, or it was endlessly being refactored."
Who talk like me? It's funny, because I'm not even disagreeing with most of what you say. But a quicksort is not rocket science, and anybody who studied programming or CS in college has been exposed to how they work. If they have any schooling behind them with significantly more depth that PHP scripting, they were probably also exposed to how hash tables are contstructed.
Why is it arrogant to insist that they remember some of the most basic things they learned? If I were to hire a mechanical engineer I'd want to be sure he knows trigonometry.
But if you're talking about some guy pounding rivets, well, he's not an engineer. He's a hack laborer, and he probably doesn't need to remember his trigonometry. And that's exactly the difference I was talking about.
"I dare say I could write one pretty quickly if asked, but it would be a much more efficient use of my time to just google for one since there are tons of them out there without any licence restrictions. "
Please read what I wrote a bit more carefully. I did not write that I think you should be writing such things on a daily basis. And I certainly don't recommend it. But you should be able to, should the need arise.
"Right - but if I catch a programmer ever actually implementing a quicksort by themselves though, they're fired."
Well, I won't argue with that. As I stated earlier, I don't think one should spend every day re-inventing the wheel. But knowing how to make a wheel if you have to is a valuable skill.
Haha. Point taken. Come to think of it, the only language I can recall off-hand that is officially all-capitalized is BASIC, because it's an acronym.
:)
I was ribbing GP a little. In general, I agree that one should be able to pick up another language without TOO much difficulty. But many people I have spoken to (I have done some Perl but it was only to translate existing code to another language) have found existing programs in Perl to be singularly difficult to decipher. I understand that it is generally due to the flexibility of the language, but "magic" symbols don't help a lot.
And to be clear, I'm not referring to myself above, because the Perl code I worked on was in a very well-defined context and consistently structured. So I'm in no place to criticize it, myself.
But it just goes to show you that just because you can reduce a theory to a nice "scientific" curve on a chart, the worth of your theory is still only how well it can predict... and Keynesians have historically scored near zero in that regard.
"But I was more talking about the notion of "raising the median income" as often trumpeted by the Left. You simply can't raise the purchasing power of the average family above what any reasonably efficient economy delivers - ignore all the currency, the actual cars and TVs and such per family are a matter of manufacturing capacity/efficiency, not income distribution. Growth in that regard comes from technological progress, not economic games."
I agree. I guess I should have clarified that when I wrote "median income", I meant "median income, adjusted for inflation". Because that compensates for buying power. *IF*, that is, you use real figures for inflation, not government's customary lie of "2%". Or -- Keynesians, please hide your eyes -- the mild deflation that would be an indication of an actually healthy economy.
I generally agree with you, but I would add that air travel and communication are pretty clearly subject to "interstate commerce" regulation, as firmly established in the Constitution, even under the strictest sense of interstate commerce. So there is no need to dream up an "extra-constitutional" authority for either FAA or FCC.
There ARE legitimate arguments that they have at times exceeded their authority. But that doesn't bear on the constitutionality of their very existence.
"1. Don't use proven libraries to solve common programming tasks (e.g., collections).
2. Write everything from scratch!
3. Argue that it is a time and budget advantage to do so."
No. That wasn't the point of this discussion at all.
I highly recommend that programmers DO use proven libraries to solve common tasks. BUT, a programmer who is worth a real programmer's salary COULD write them herself if she had to, which means she also has the skill to identify and preferably fix bugs in said libraries. After all... open source software is all bug-free, yes? (Not that it has to be open source... just an example.)
I wasn't saying a programmer should write everything from scratch every day. But if you don't know how to, you're SOL and at everybody else's mercy when something goes wrong. You're costing your company money. Because things go wrong.
"Good software development is to a chemist As lego development is to a cook."
Well, I have to tell you honestly: I don't know whether that went over my head, or under.
But either way, it missed me completely.
"Sometimes you need more than a mass-produced transport designed to a price for the lowest common denominator."
Agreed. Just as engine mechanics fix engines -- for FAR less cost than simply buying a new one -- if you have a coder who actually knows how to code, maybe he or she can FIX a problem, rather than re-writing your whole application from scratch.
In some ways this is even more important than in the engine mechanic analogy, because your software likely WAS written from scratch. So it's a hell of a lot cheaper to hire a code "mechanic" who knows what she's doing to fix it, than it is to do it all over again from the ground up.
" Premature reports of the eminent death of hydrocarbon reserves have been circulating since Carter(76-80) in this fool's living memory"
Yes, I remember them too. But also remember Malthus: by his famous principle, we would all have eaten each other about 600 years ago.
The problem with these doomsayers is that they take any given short-term trend and extend it out to infinity, without regard for any other variables or changes. It's what Malthus did, it's what the Global Warmists did, it's what the "peak oil" people did.
So far, all of them have been wrong.
"I agree with the anon poster. You are an idiot. A computer scientist better be able to write a QS in their sleep, but a programmer better know how to find a suitable implementation already written."
That's not a programmer, that's a hack just out of high school. There IS a big difference, and if you don't know what that difference is, you're paying too much money.
Now tell me again who's the idiot.
I wasn't suggesting that every programmer has to know how to do finite-elelement modeling, for fuck's sake. But if you don't know a Quicksort from a Bubble sort, or how to write them, you're not a programmer by any standard I ever heard of, and I've been around.
"Find me a mechanic that can build a V8."
I didn't write manufacture a V8 from scratch, I wrote "build".
I rebuilt an engine, and I'm very far from an auto mechanic. And in the interest of keeping the record straight, I had help and advice. But that's my point here: I wrote "build", not "design and manufacture all the parts from scratch". It's all fine to get help and advice for coding, too. But I wasn't suggesting trying to independently re-invent internal combustion or anything like that.
"I would much rather my mechanic focus his efforts on being good at diagnosing problems and installing factory-made parts rather than troubling himself with building parts himself."
Cool. So when something fails, you can pay them to go find some other pre-built part, and follow the instructions to hopefully make it work.
That's fine, I suppose, if you have the time and the budget. I prefer to simply hire people who know what the hell they're doing.
"You should be able to pick up any language or environment on the job."
Tell that to somebody who's been doing PERL or Tcl for 10 years.
"So why is Daniel trying to compile a list that everybody will agree with? That would be a list of what every non-master programmer agrees a master programmer should know, which is different than a list of what a programmer should know to be a master programmer..."
No, it isn't. It's INTENDED to be the opposite: a list that master programmers can agree every non-master should know.
You have to admit: there's a lot of master-level programming talent who check in to Slashdot.
"Quicksort is already implemented a thousand times, so there's no need to implement it again, just find which library you need."
Yes, that's true, but we're talking about education here, not building websites.
If you're a coder, and you don't know how to BUILD a hash table from genuinely fundamental, low-level components, or if you can't do a quicksort from those same fundamental building blocks, guess what? I won't hire you.
It's great to be able to buy or borrow a used V8, but if you don't know how to build one, you're not going to be my mechanic.
"It goes in, it must come out"
... is actually Teslacle's Deviant to Fudd's Law, with an "L". But hey... could be a typo.
---
"Close B clothes mode on Deputy Dan."
"There is nothing basic about these."
Correct. I wondered about that myself. Those are important but hardly basic.
A stack is a basic structure, as you say. A string is a basic structure, with several different but classic storage schemes. (Please don't start in with "That's a data type, not a structure." Nonsense. They're all structures.)
Integers are basic. As are longints, etc. They may vary from platform to platform, but they're still pretty basic. As is the byte, for example. The meaning of that has changed over the years (now meaning just 8 bits, period... it used to be variable depending on the architecture), but it's pretty basic and quite important.
Arrays are basic.
Hash tables are not "basic". In fact that used to be a rather lengthy section of basic CS classes; how to implement an efficient hash table in code. There is nothing even remotely basic about them; the data and underlying code of the class are quite complex compared to truly basic structures. Some modern languages just make them SEEM simple. But I know few coders today who could actually build a good one from really basic components.
Saying that a hash table is a basic data structure is like saying Quicksort is a native operator.
"As I explained in the first article: If you take away the "right to remain silent", a suspect can still say, "No, I didn't do it," and the police options for "coercing" them are the same as they were before."
Not their legal options. You argue against yourself. You appear to be saying that the existence of the law doesn't matter because police and courts will ignore it anyway. Yet we have 200+ years of history showing that it DOES make a difference.
If that isn't what you're arguing, then I don't understand what you're trying to say.
"That's why I said in the first article: the only answer I would accept is a specific scenario in which the outcome is different because of the Fifth Amendment."
Do you have any idea how many people were NOT convicted because they pled the 5th? You can look them up yourself... I'm not going to do it for you. But I would say that 99% of those made a difference.
But I can give you one (although I don't have an actual citation at hand... it shouldn't be hard to look it up). The recent Federal case in which the judge ruled that the suspect could not be compelled to hand over the password to his hard drive is a specific example of one situation in which it almost certainly made a difference.
"Take the cops trying to coerce a confession. With the Fifth Amendment, the suspect remains silent, which cops don't like. Without the Fifth Amendment, the suspect can say, "I didn't do it", and refuse to answer questions about anything else, which cops don't like. You haven't shown why the outcome in either case would be different. (If you think the cops are going to beat the suspect until they get the answer they want, that's a problem whether the suspect is remaining silent, or giving answers other than what the cops want to hear.)"
The reason this is a straw-man argument is that it isn't JUST the cops. It's our whole court system. The courts can't compel a confession, or accept testimony about one that was compelled, coerced or extorted.
"Even if the dollar becomes worthless, my employer will pay me in some form that people selling the basics will accept - some sort of barter-intermediary will be around."
It's happened before, even here, and the people it happened to would have laughed at your reasoning. If they weren't too hungry to laugh.
The consensus (among non-"Keynesian"... which pretty much means most non-Government) economists is that government monetary policy led directly to the crash of '29, and that FDR's subsequent monetary policy prolonged the depression for 10 years longer than it might otherwise have lasted. Which -- hint, hint -- is exactly the kind of inflationary, interventionist policy Obama has been following.
FDR's own Treasury Secretary thought he was nuts... and history pretty much agrees.
But to get back to the main point: it HAS happened before, it WAS bad, and "modern" economics isn't going to prevent it. On the contrary: they are making the very same mistakes that were made 80+ years ago.
"I'm not sure anything but technology affects the purchasing power of the median income much"
I am. Government spending, taxation, monetary policy, etc. all affect the median income. I fail to see how you do not recognize that. After all, we are right now, today, climbing out of a terrible recession that was largely caused by government regulation (or lack thereof). And we are right now starting to feel the real ill effects of government-influenced (Fed) monetary policy. Have you looked at your grocery bill lately? Commodities like food are usually the first things to go up when inflation hits.
Lobbying money mostly goes to LOBBYISTS.