The "two wolves and a sheep" argument is a favorite among people of a certain ideology.
But we're not talking wolves and sheep here, or the poor people at the top wouldn't be wailing about the theiving masses and the masses wouldn't have ever have done things like the French Revolution when they got fed up with the people at the top. Or would be doing them every day instead of as a last resort. Everybody at this table has more wolf than sheep at some point.
As for the "Standing on Principles" thing, that's made for a really effective government over the last few years, hasn't it?
You mean "special skills", nudge, nudge, wink, wink? 'Cause they told us that we're all interchangeable cogs and therefore don't deserve to be paid like we had really special skills. As in Upper Management. People who deserve to get paid more for their failures than us cogs get paid for working hard and then being laid off.
A java guy who doesn't explicitly close a file isn't much better than a C guy. I knew someone like that, and he left resources hanging loose right and left. And occasionally lost data, since it didn't flush to disk until the file was closed. And maybe not then, if the close was done by the garbage collector.
But Cisco was at the forefront of the cheap offshoring boom. They outsourced support ages ago, then their outsourcers offshored it. Connoiseurs of Cisco support knew which country was going to provide the most helpful people and tried to ensure that their calls got directed there.
Cisco got a lot of its growth through mergers and acquisitions, not direct technical excellence, which is one reason why their stock stalled after they ran out of victims to buy.
Yes, the rich should be paying more back into the economy (through taxes or spending) instead of hoarding wealth, and the H-1Bs and other outsourcing of costs has to be curtailed.
However, when the poor stop getting earned income credits totaling in the several thousands every year (which goes up with the number of children claimed as dependents), while they don't pay a penny in income tax because they're unemployed for whatever reason, then you'll have a solid argument. Until then, too many of the "poor" are getting a free ride on the backs of bad government policy - and they have no skin in the game. Maybe they need to get rid of their iPhones, stop buying $250 Nikes, and cut their cable to pay some taxes back into the system that's paying for those luxuries.
This is a very emotionally appealing "solution". But notice that these "freeloading poor" are contributing to the economy by buying iPhones, $250 Nikes, and cable. Keeping money in circulation and creating jobs.
On the other hand, how many iPhones, numerically speaking, are 1% of the population going to be buying? How many pairs of Nikes? Probably more that any single poor person, but there are so many poor people. Companies like Cartier may be able to prosper serving only the wealthy, but Apple didn't get to be the behemoth it is by selling solely to the well-to-do, even at Apple's notoriously high prices.
We more or less respect the "idle rich" whose money comes not from working, but from investments, whether direct or inherited.
Maybe we can spare a little love for the "idle poor" as well.
Poor people also pay a disproportionate part of their income on food, clothing, energy, housing and transportation. Should all of those things be cheaper for poor people as well?
Should I have done an income analysis on my neighborhood and if I found that I was on the low-end of the income spectrum, should I have demanded a lower price on my house simply because I make less than my neighbors?
I understand charity for the poor, but demanding that poor people pay less for everything simply because they are poor defeats the point of a market economy. If you are going to do that, why not go all the way to a state planned economy?
I'll tell you why.
Because a pure 100% ideological solution to anything is a recipe for failure.
Sometimes a capitalistic approach works. Sometimes a socialistic approach works. Sometimes some other approach entirely works.
If you can achieve a good blend, where you take advantages of systems at their strong points and use some better approach at their weak points, you'll be better off than you will if you live in a binary all-or-nothing world. Where you may get the best of an ideology, but you'll pay for it by getting the worst as well.
I recently was affronted by a "modern" Spanish-language course. The actual books were awful, the course itself was online - a very bad idea, I think for a subject where the ultimate test in mastery is how well you can converse with teachers and fellow students. And this particular abomination is the almost universal text for colleges in about 5 states. Oh, and this is one of those courses where half your learning materials disappear in a puff of smoke at the end of the term.
Spanish is a living language and is used in the contexts of changing cultures, so its textbooks do need updating occasionally. However, the fundamentals remain the same and there's no reason why an open-source, even crowd-sourced text couldn't be adopted. Certainly no reason for it to require a multi-decade mortgage to buy.
The same can be said for a lot of mathematics.
Other subjects are more volatile and it makes sense to have specialized, continually-updated texts. And to have to pay for it. But give us a break on the basics!
You think right. HTML is a content markup language, not a format-preserving one. And when you're dealing with varying display sizes, that can be an advantage, although there's also an option to make PDF documents reflow.
The main problems come from graphics, which typically either get butchered or displayed at unreadable sizes.
If the book's graphics were designed with smaller screen sizes in mind, it's possible to make them more readable, but of course, there are limits.
Their professors' course material should all be online, and in many cases it already is. That way it is accessible to everyone who needs it and pays for it.
For the life of the course. If, Chthulu forbid! you actually intended to learn something from the course, and wanted to go back and review material after the term ended, often your online resources have been terminated.
I've got books from courses taken years ago, since I tended not to sell back. They aren't even remotely related to my career or daily life. But occasionally I'll take one off the shelf and page through one. They're a lot more entertaining now that I'm not under pressure to use them for class.
Please no! Not the GIFS! It's more like people know what buttons to push because it's so obvious.
Better GIFs than auto-playing audio/video clips.
I'm about to the point where I'm going to give up on getting news from the Internet and re-subscribing to dead-tree newspapers. At least THEY don't start making a racket the minute you open them.
And the lunatic rants are mostly confined to the editorial pages where the professional lunatics and amateur lunatics can both be ignored by simply skipping that section.
You want stupid dress codes. Come to Florida. The executives wear suits so the building A/C is set for Chicago. Although at least they got rid of the vests.
Actually, many of the most successful products I know of were slapped out in a hurry by 1 or 2 people who just needed to get something running. Often these products will then run in production for years, warts and all. And any attempt to replace them with something cleaner is likely to collapse from Fred Brook's "Second System Effect".
Of course, Brooks wrote that before there were quite as many faddish ways to screw up management of a project. Although the one he espoused - Chief Programmer Team - has basically dropped off the face of the Earth.
Java isn't merely object-oriented, it's object-based, just as Smalltalk was. It may be possible to have an object-based system with no standard functions in it, but I'm not sure I'd want to meet it. And yes, Java's was exceptionally large.
I'm afraid that C resources back then were much dicier. As mentioned, there were a few vendor-specific libraries, some user-group libraries, and some commercial libraries. But no real common denominator libraries beyound the Unix basics like stdlib. If you wanted to produce an open-source C/C++ project or if you worked for employers too cheapskate to buy commercial libraries, it was pretty much roll-your-own and one-off. Fortunately, gnu/Linux/BSD has filled in some of those gaps since then.
I worked with GNU even before Linux came out - a lot of GNU was adopted for CP/M while Linus Torvalds was still practically a toddler. But it was mostly complete programs, so doing things like extracting the pattern-matching logic from grep to use in a different app could require a certain amount of work.
Developers 20 years ago "did not have libraries". Meaning that you had math function libraries (dating back to the 1960s or before) and you maybe had a semi-standard high-level library or 2 such as Microsoft's MFC, Borland's OWL, the C++ STL.
However, the rise of ecosystem languages such as Java - with its rich set of built-in packages, Python, with its cheese store, even Perl's often-dodgy CPAN has caused modern programmers to consider libraries as more the rule than the exception.
Even in COBOL, core dumps are not the ideal diagnostic tool and haven't been for a long time. Most high-level languages have their own more developer-friendly means of presenting failure information. A core dump for Java is only produced if the JVM itself fails. Street-level programmers work with stack traces and stack and heap dumps.
Most developers I know couldn't read a core dump at gunpoint. The ones that can are working mostly with pure compiled languages such as C/C++ or (rarely) assembler. But since the current fad is heavily biased towards scripting languages, there aren't that many younger people I know who deal with static compiled languages.
For "compiling" to machine code, there is a 1:1 mapping of assembler, unless you count macros as something fancy.
However, there is no longer a 1:1 mapping of machine code (assembler or not) to internal machine operations. Well, for some machines, like IBM's microcode-based mainframes, there hasn't been for quite a long while, but they were still one machine instruction = a predetermined number of microcode cycles.
At one time, machine language was more or less determinate. You knew precisely how long each instruction would take to execute and you could add it up on your HP calculator. Even into the early 1980s, DMA and interrupt services could have impact on execution time, but they could be allowed for.
Modern processors are heavily pipelined, use predictive methods have multiple cache levels, and so forth. Computing the execution time is essentially impossible except as a statistical exercise unless the code is very short and you know precisely what all the data is.
This is why assembler is no longer widespread in applications. Functionally speaking, it's considered a general rule that it takes on average 5-10 assembler instructions to do what a single line of almost any high-level language code can do, but the amount of time it takes a programmer to create and debug a single line is roughly the same, whether they're assembler lines, COBOL lines, or C++ lines. Practically speaking, computers (compilers) are much better at the tedious job of tracking minutae and selecting the (presumed) optimal rendition of higher-level functions into hardware-level fundtions.
Only a fool puts the business logic in the client if they have any understanding or concern for transaction consistency and application reliability. You have to assume the presentation client is going to break half way through processing something and leave the database in an inconsistent state if you put the business logic in the front end.
Actually, while that's a valid concern, a much bigger reason for not putting the application logic in the client is that anything in the client can be hacked for malicious purposes.
Server-side code may not be as immediate, but at least access to the code is restricted to functional invocations and not inherently at risk at the instruction level.
OK, I'm going to have to agree with you there. I entered computing at the end of the COBOL era, and it felt like - for all its awkwardness - it was actually written by adults with a particular need, for adults with a particular need. It was designed. It was serious.
Javascript feels like it was written by children who like playing about, and who have genuinely smart guys in the office next door who know how to sell toys to adults.
Ironically, COBOL was designed by a committee (CODASYL) for the government.
By all that we are constantly being told, that means that JavaScript, lacking such encumbrances, should be light-years better.
These red tide problems have been going on for decades, long before the oil spill. The oil spill has been devastating but I dont think its causing this.
To the best of my knowledge, there have been red tides there since before the Spaniards hit the beaches.
The question here, as in so many other cases, isn't whether it's something new, but whether people have been doing things that make it more intense and/or more frequent.
And since it's not a simply provable binary condition, people will argue about it.
IBM provides service? Not from what I've seen lately. In fact, I'm not sure what IBM provides any more except a way for companies with too much money on their hands with a drain to pour it down.
I count the actual Beginning of the End for Microsoft to be about Windows 2003 - when they stopped being Santa with all the freeebies and started being the Grinch - restricting some kinds of multimedia and copy-protecting the OS (before then, the security keys were mostly cosmetic).
Still, with Windows 8, they basically fell off a cliff.
MacOS, Android, and yes, even Linux on the Desktop are now all "good enough", but for a lot of people, Windows 8 isn't. And Windows never had dominance for being actually superior, just for being "good enough".
Well on one side, we have the PC crowd with their "everyone is really the same, so anyone can succeed" and it's just the Big Bad Meanies holding some people back because of their race/religion/whatever and take away their will to succeed.
On the other, we have the Meritocracy crowd, with their "anyone can succeed, they just need to work at it" and the Big Bad Meanies want to punish the people who succeeded and take away their will to succeed.
The idea that some people simply aren't going to succeed, period, isn't tolerated by either wing. If they don't succeed, it's got to be someone's fault. and the only real difference is who they want to blame for it.
There are, in fact, inherently bad coders. Coding is just like anything else. Some people have the apitude, some do not.
I am an inherently bad bookkeeper, since I work by scanning the big picture and integrating it, and a meticulous line-by-line process will only result in my dropping lines.
I am an inherently bad sales person, because it's actually painful to me to approach people, and my persuasive skills are probably measured in negative numbers.
But I can execute prodigies in software coding without even straining.
This idea that anybody can do anything (except CEOs, who therefore require special levels of compensation) really needs to die. We're not all interchangeable cogs, no matter how hard you flog us.
Slashdot Mirror
The "two wolves and a sheep" argument is a favorite among people of a certain ideology.
But we're not talking wolves and sheep here, or the poor people at the top wouldn't be wailing about the theiving masses and the masses wouldn't have ever have done things like the French Revolution when they got fed up with the people at the top. Or would be doing them every day instead of as a last resort. Everybody at this table has more wolf than sheep at some point.
As for the "Standing on Principles" thing, that's made for a really effective government over the last few years, hasn't it?
You mean "special skills", nudge, nudge, wink, wink? 'Cause they told us that we're all interchangeable cogs and therefore don't deserve to be paid like we had really special skills. As in Upper Management. People who deserve to get paid more for their failures than us cogs get paid for working hard and then being laid off.
H1B's are less likely to be NSA spies anyway.
Hey, H1B's like money too! How else are they going to earn as much as the people they displaced?
A java guy who doesn't explicitly close a file isn't much better than a C guy. I knew someone like that, and he left resources hanging loose right and left. And occasionally lost data, since it didn't flush to disk until the file was closed. And maybe not then, if the close was done by the garbage collector.
But Cisco was at the forefront of the cheap offshoring boom. They outsourced support ages ago, then their outsourcers offshored it. Connoiseurs of Cisco support knew which country was going to provide the most helpful people and tried to ensure that their calls got directed there.
Cisco got a lot of its growth through mergers and acquisitions, not direct technical excellence, which is one reason why their stock stalled after they ran out of victims to buy.
Yes, the rich should be paying more back into the economy (through taxes or spending) instead of hoarding wealth, and the H-1Bs and other outsourcing of costs has to be curtailed.
However, when the poor stop getting earned income credits totaling in the several thousands every year (which goes up with the number of children claimed as dependents), while they don't pay a penny in income tax because they're unemployed for whatever reason, then you'll have a solid argument. Until then, too many of the "poor" are getting a free ride on the backs of bad government policy - and they have no skin in the game. Maybe they need to get rid of their iPhones, stop buying $250 Nikes, and cut their cable to pay some taxes back into the system that's paying for those luxuries.
This is a very emotionally appealing "solution". But notice that these "freeloading poor" are contributing to the economy by buying iPhones, $250 Nikes, and cable. Keeping money in circulation and creating jobs.
On the other hand, how many iPhones, numerically speaking, are 1% of the population going to be buying? How many pairs of Nikes? Probably more that any single poor person, but there are so many poor people. Companies like Cartier may be able to prosper serving only the wealthy, but Apple didn't get to be the behemoth it is by selling solely to the well-to-do, even at Apple's notoriously high prices.
We more or less respect the "idle rich" whose money comes not from working, but from investments, whether direct or inherited.
Maybe we can spare a little love for the "idle poor" as well.
Poor people also pay a disproportionate part of their income on food, clothing, energy, housing and transportation. Should all of those things be cheaper for poor people as well?
Should I have done an income analysis on my neighborhood and if I found that I was on the low-end of the income spectrum, should I have demanded a lower price on my house simply because I make less than my neighbors?
I understand charity for the poor, but demanding that poor people pay less for everything simply because they are poor defeats the point of a market economy. If you are going to do that, why not go all the way to a state planned economy?
I'll tell you why.
Because a pure 100% ideological solution to anything is a recipe for failure.
Sometimes a capitalistic approach works. Sometimes a socialistic approach works. Sometimes some other approach entirely works.
If you can achieve a good blend, where you take advantages of systems at their strong points and use some better approach at their weak points, you'll be better off than you will if you live in a binary all-or-nothing world. Where you may get the best of an ideology, but you'll pay for it by getting the worst as well.
I recently was affronted by a "modern" Spanish-language course. The actual books were awful, the course itself was online - a very bad idea, I think for a subject where the ultimate test in mastery is how well you can converse with teachers and fellow students. And this particular abomination is the almost universal text for colleges in about 5 states. Oh, and this is one of those courses where half your learning materials disappear in a puff of smoke at the end of the term.
Spanish is a living language and is used in the contexts of changing cultures, so its textbooks do need updating occasionally. However, the fundamentals remain the same and there's no reason why an open-source, even crowd-sourced text couldn't be adopted. Certainly no reason for it to require a multi-decade mortgage to buy.
The same can be said for a lot of mathematics.
Other subjects are more volatile and it makes sense to have specialized, continually-updated texts. And to have to pay for it. But give us a break on the basics!
You think right. HTML is a content markup language, not a format-preserving one. And when you're dealing with varying display sizes, that can be an advantage, although there's also an option to make PDF documents reflow.
The main problems come from graphics, which typically either get butchered or displayed at unreadable sizes.
If the book's graphics were designed with smaller screen sizes in mind, it's possible to make them more readable, but of course, there are limits.
Their professors' course material should all be online, and in many cases it already is. That way it is accessible to everyone who needs it and pays for it.
For the life of the course. If, Chthulu forbid! you actually intended to learn something from the course, and wanted to go back and review material after the term ended, often your online resources have been terminated.
I've got books from courses taken years ago, since I tended not to sell back. They aren't even remotely related to my career or daily life. But occasionally I'll take one off the shelf and page through one. They're a lot more entertaining now that I'm not under pressure to use them for class.
Please no! Not the GIFS!
It's more like people know what buttons to push because it's so obvious.
Better GIFs than auto-playing audio/video clips.
I'm about to the point where I'm going to give up on getting news from the Internet and re-subscribing to dead-tree newspapers. At least THEY don't start making a racket the minute you open them.
And the lunatic rants are mostly confined to the editorial pages where the professional lunatics and amateur lunatics can both be ignored by simply skipping that section.
You want stupid dress codes. Come to Florida. The executives wear suits so the building A/C is set for Chicago. Although at least they got rid of the vests.
> Where you may not see the connection is that full control over all military could result in a coup
Well, that and monoculture problems for weapons systems - even going back before they were computerized. Different tools for different jobs.
I think it's more like different weapons systems for different congresscritter pork projects.
Actually, many of the most successful products I know of were slapped out in a hurry by 1 or 2 people who just needed to get something running. Often these products will then run in production for years, warts and all. And any attempt to replace them with something cleaner is likely to collapse from Fred Brook's "Second System Effect".
Of course, Brooks wrote that before there were quite as many faddish ways to screw up management of a project. Although the one he espoused - Chief Programmer Team - has basically dropped off the face of the Earth.
Java isn't merely object-oriented, it's object-based, just as Smalltalk was. It may be possible to have an object-based system with no standard functions in it, but I'm not sure I'd want to meet it. And yes, Java's was exceptionally large.
I'm afraid that C resources back then were much dicier. As mentioned, there were a few vendor-specific libraries, some user-group libraries, and some commercial libraries. But no real common denominator libraries beyound the Unix basics like stdlib. If you wanted to produce an open-source C/C++ project or if you worked for employers too cheapskate to buy commercial libraries, it was pretty much roll-your-own and one-off. Fortunately, gnu/Linux/BSD has filled in some of those gaps since then.
I worked with GNU even before Linux came out - a lot of GNU was adopted for CP/M while Linus Torvalds was still practically a toddler. But it was mostly complete programs, so doing things like extracting the pattern-matching logic from grep to use in a different app could require a certain amount of work.
Developers 20 years ago "did not have libraries". Meaning that you had math function libraries (dating back to the 1960s or before) and you maybe had a semi-standard high-level library or 2 such as Microsoft's MFC, Borland's OWL, the C++ STL.
However, the rise of ecosystem languages such as Java - with its rich set of built-in packages, Python, with its cheese store, even Perl's often-dodgy CPAN has caused modern programmers to consider libraries as more the rule than the exception.
Even JavaScript has libraries. So many libraries!
Even in COBOL, core dumps are not the ideal diagnostic tool and haven't been for a long time. Most high-level languages have their own more developer-friendly means of presenting failure information. A core dump for Java is only produced if the JVM itself fails. Street-level programmers work with stack traces and stack and heap dumps.
Most developers I know couldn't read a core dump at gunpoint. The ones that can are working mostly with pure compiled languages such as C/C++ or (rarely) assembler. But since the current fad is heavily biased towards scripting languages, there aren't that many younger people I know who deal with static compiled languages.
Even a bytecode dump is beyond most of them.
For "compiling" to machine code, there is a 1:1 mapping of assembler, unless you count macros as something fancy.
However, there is no longer a 1:1 mapping of machine code (assembler or not) to internal machine operations. Well, for some machines, like IBM's microcode-based mainframes, there hasn't been for quite a long while, but they were still one machine instruction = a predetermined number of microcode cycles.
At one time, machine language was more or less determinate. You knew precisely how long each instruction would take to execute and you could add it up on your HP calculator. Even into the early 1980s, DMA and interrupt services could have impact on execution time, but they could be allowed for.
Modern processors are heavily pipelined, use predictive methods have multiple cache levels, and so forth. Computing the execution time is essentially impossible except as a statistical exercise unless the code is very short and you know precisely what all the data is.
This is why assembler is no longer widespread in applications. Functionally speaking, it's considered a general rule that it takes on average 5-10 assembler instructions to do what a single line of almost any high-level language code can do, but the amount of time it takes a programmer to create and debug a single line is roughly the same, whether they're assembler lines, COBOL lines, or C++ lines. Practically speaking, computers (compilers) are much better at the tedious job of tracking minutae and selecting the (presumed) optimal rendition of higher-level functions into hardware-level fundtions.
Only a fool puts the business logic in the client if they have any understanding or concern for transaction consistency and application reliability. You have to assume the presentation client is going to break half way through processing something and leave the database in an inconsistent state if you put the business logic in the front end.
Actually, while that's a valid concern, a much bigger reason for not putting the application logic in the client is that anything in the client can be hacked for malicious purposes.
Server-side code may not be as immediate, but at least access to the code is restricted to functional invocations and not inherently at risk at the instruction level.
Other than the "this" misfunction, which is rememdied by the hack defining "that", what are the terrible misfeatures of JS?
It's not like C/Java/COBOL/FORTRAN/whatever other language someone is used to using.
Well, there's that whole "null", "nothing", "empty string" crapshoot.
OK, I'm going to have to agree with you there. I entered computing at the end of the COBOL era, and it felt like - for all its awkwardness - it was actually written by adults with a particular need, for adults with a particular need. It was designed. It was serious.
Javascript feels like it was written by children who like playing about, and who have genuinely smart guys in the office next door who know how to sell toys to adults.
Ironically, COBOL was designed by a committee (CODASYL) for the government.
By all that we are constantly being told, that means that JavaScript, lacking such encumbrances, should be light-years better.
Wait, so you're saying all of this is Kevin Bacon's fault?
Everything is Kevin Bacon's fault. Remember, no more than 6 degrees of separation between Bacon and the leaders of Al-Qaeda.
Examine the metadata. Why doesn he hate our Freedoms???!!
These red tide problems have been going on for decades, long before the oil spill. The oil spill has been devastating but I dont think its causing this.
To the best of my knowledge, there have been red tides there since before the Spaniards hit the beaches.
The question here, as in so many other cases, isn't whether it's something new, but whether people have been doing things that make it more intense and/or more frequent.
And since it's not a simply provable binary condition, people will argue about it.
IBM provides service? Not from what I've seen lately. In fact, I'm not sure what IBM provides any more except a way for companies with too much money on their hands with a drain to pour it down.
I count the actual Beginning of the End for Microsoft to be about Windows 2003 - when they stopped being Santa with all the freeebies and started being the Grinch - restricting some kinds of multimedia and copy-protecting the OS (before then, the security keys were mostly cosmetic).
Still, with Windows 8, they basically fell off a cliff.
MacOS, Android, and yes, even Linux on the Desktop are now all "good enough", but for a lot of people, Windows 8 isn't. And Windows never had dominance for being actually superior, just for being "good enough".
Well on one side, we have the PC crowd with their "everyone is really the same, so anyone can succeed" and it's just the Big Bad Meanies holding some people back because of their race/religion/whatever and take away their will to succeed.
On the other, we have the Meritocracy crowd, with their "anyone can succeed, they just need to work at it" and the Big Bad Meanies want to punish the people who succeeded and take away their will to succeed.
The idea that some people simply aren't going to succeed, period, isn't tolerated by either wing. If they don't succeed, it's got to be someone's fault. and the only real difference is who they want to blame for it.
There are, in fact, inherently bad coders. Coding is just like anything else. Some people have the apitude, some do not.
I am an inherently bad bookkeeper, since I work by scanning the big picture and integrating it, and a meticulous line-by-line process will only result in my dropping lines.
I am an inherently bad sales person, because it's actually painful to me to approach people, and my persuasive skills are probably measured in negative numbers.
But I can execute prodigies in software coding without even straining.
This idea that anybody can do anything (except CEOs, who therefore require special levels of compensation) really needs to die. We're not all interchangeable cogs, no matter how hard you flog us.