1) In any sufficiently large collection of people, there will be some who are unstable.
2) Linux will not wither because of the nuts -- there's too much value in Linux to business and as long as the value proposition is there, so will Linux.
3) John, and almost any journalist, is probably feeling a little threatened by the MOG story.
So, I'm an older programmer (35 to be exact) and I've been coding for a *LONG* time. I was self taught starting at 10.
My work in the industry has always been praised. I've been constantly promoted and paid well.
A few years ago, I was doing some security work and wanted to understand the math behind the crypto libraries that I was using, so I tried to brush off my math. I ended up going back and I'm now in the process of finishing up my math degree. So, I can tell you a few of things from very direct and current experience.
1) Not doing well at math doesn't mean you can't code well. Until I went back, I was not terribly good at math.
2) At my school, University of Washington, the CS majors are math pussies. They bail on math dept. classes after a year of calc, a quarter of linear algebra and a quarter of stats. Yes, they get some math later in algorithms classes and the like but I know CS *PHDS* from good schools who are crappy at math.
3) I find that I occassionally use math in my work but not very much and it's hardly ever the calc -- it's almost always the linear algebra, number theory, and set theory.
Now, I think that you have to be smart enough to be able to handle math (as I obviously was) but that's different actually using math as part of the job or needing to take it as a condition of getting the degree.
While I agree that the problem is price, I disagree with the assertion that things will be flat or declining.
The world price for programming talent is lower than in the US which implies, that, absent a tarrif, that the US programmer's salaries should almost immediately go to the world price. However, in many ways, the incremental costs associated with managing software projects from afar are a sort of tarrif.
The problem, from the US programmers point of view, is that the tarrif has been cut over the last few years with the proliferation of the internet. However, I think that we are now (mostly) up against the fundamental complexities of the issue not just the accidental ones (like moving bits from place to place).
So, I would expect the tarrif not to be lowered much further. This means that for the US programmers position to get worse, the world price for engineering talent has to drop. It's possible that as China continues to come online that this will happen, but, since India competes against China in exports (for which the tarrif rate doesn't matter) I don't suspect it will have as much of an impact as India did.
The gatekeepers to medical care have an interest in keeping it as cheap as possible. That means downward pressure on physician pay. Don't think that a few doctors are going to stand in the way of insurance industry profits over the long term.
Are you seriously this big of a mathtard? Your "Hint" is from Gauss, hence the original poster's reference to him.
if I had no computer, I would probably be forced to think of something clever, like Gauss, and actually learn something.
So, either you're a mathtard who doesn't even know who Gauss is or you we in such a rush to prove you intellectual superiority that you couldn't be bothered to actually read the post.
So which kind of retard are you? Did you eat paint chips as a kid?
Re:I've noticed this at work...
on
Got Game
·
· Score: 1
Yes, but they run that loop incredibly fast, so while they may not actually accomplish a whole lot, it sure is entertaining to watch. That is as long as you're not the guy that's going to get slammed when they fail.
These are public companies. The directors are legally required to maximize profits. Does that mean that they are greedy bastards, not really. I'm not saying it's right, it's just the law. Two different things, you know.
These guys are simply saying, through this move, that they think they'll make more money by raising prices. See, there's this thing in economics call the price elasticity of demand. Which is just a fancy way of saying, how much will the demand change for a given change in price.
These guys think that the price elasticity of demand for music is low enough that, if they change the price, they'll more than make up for the lost sales. The only hope that we have is to show them that they're wrong.
But, we will fail because the majority of music buyers are in their teens. These are the same folks who think that emulating Paris Hilton is a good idea. Don't look for intelligent consumer behavior from that demographic.
The problem isn't that American companies require that employees compete globally, it's that governments do not have to compete for thier citizens.
See, we could choose which government we wanted to "buy" by paying taxes, you can sure bet that American programmers could relocate to locales with lower costs of living and compete globally.
That means that governments would have to compete on standard of living. If I can get a good wage and a low cost of living in another country, why can't I choose that? Mainly because it doesn't suit those in power, that's why.
If this were done overnight, the standard of living in the US would plummet overnight as a vast influx arrived. However, the standard of living in developing nations would skyrocket as people with "virtualizable jobs" brought thier higher earning potential into developing nations.
So, like the market liberialization experiences of South America, there would be a global wave of economic hardship in the short run, but in the long run a set of governments that *HAD* to be efficient, open, and responsive would be a huge plus.
Yes, it happened but it was in the context of the boy's drug trial. The evidence obtained from the mother's evesdropping was ruled inadmissable. So the court didn't say she couldn't do it but rather said that the information couldn't be used to convict someone else.
I could post may innapropriate comments in source code. In my youth one was:/* Go away Jeff XXXX. You do not understand this code even though you think you do. I'm tired of being forced to revert your changes to this file. */
Unfortunatly many of the best ones have been in proprietary code that is still in use and would be recognized if posted here.
Re:is this stupid?
on
EFF's Logfinder
·
· Score: 2, Insightful
Don't use it. Seriously. If you are comfortable with the level of logging you have, okay. There are others, who may be in the positions of not wanting log files that identify users because of the expense associated with discovery or complying with a subpeona.
Note, this is why large companies have email retention policies -- because having to do discovery or comply with a subpeona on email records going back years is expensive. So doing this type of thing isn't anything new or sinister.
Speedups like a factor of 1000 can only come from high level optimisations (like replacing an O(n^2) with an O(n log n) algo).
Nope. Technically, there are two constant burried in here. The definition is g(x) = O(f(x)) => g(x) <= k*f(x) where x > a for some orbitrary a. If you don't change algorithms, all you can do is manipulate the k. For a given k and a given level of improvement, I can give you a new k that hits that level of improvement.
Honestly: TO be able to get a 1000 times boost, your original code must have been beyond bullshit.
Also, his original code may have been "bullshit" but it may not have. It depends a lot on the algorithm in question. The higher the exponent on an exponential algorithm, they more sensitive its running time is to some optimization in an inner loop.
And of course using simd is better than not using it, but i would rather stay on a "let the compiler vectorize it" level. I mean, doing your inner loop in leet assambler only to NOT know after a long simulation if ther results are real or you just botched some line isnt worth it.
This is a simple matter of economics. There's a cost/benifit to expending the effort to optimize in assembly. If the compiler generates good code, then obviously, the cost/benefit of recoding in assembly is pretty high. However, without specific knowledge of *HIS* economics, I would suggest that you not spout off.
IANALBRTSOALSWIHSAL (I am not a lawyer but rather the spouse of a law student who I help study a lot)...and you saved me from having to correct everybody. Now if I just had mod points.
They're coming -- sorta. I would expect to see the CLR become the prefered way of doing things for user-programmable stuff. Stored Procs in SQL Server, VB-Script replacement, etc.
I know that at least some of the projects are under way but, from an external point of view, a lot of things seem to be bound up with Longhorn, so they won't see the light of day anytime soon.
This all makes me wonder if we'll see some published introspection about what went wrong with Longhorn.
However, I don't know of any ground-up rewrited of major MS product, so you are correct. However, I'm not sure that it's an indictment of.NET. They are huge codebases and a complete rewrite in any language even if 100x better may not be worth it.
Agreed. However, his point is that, since we're both respectable developers and neither of us would omit the unit tests, C/C++-style type checking is redundant book keeping and that type inference is of limited practical value.
I have to say, however, I've worked on a number of projects where developers wrote a large volume of unit tests. Then later, brought in code coverage tools. Invariably, everyone is dismayed at the truely huge amount of work required to simply get every line executed. (Simulating full/failing disks, torn database pages, dropped packets, other extenal events in such a way to get code coverage is hard.)
The first one I was involved in had automated tests that took >24hrs to run. When they brought in code coverage tools they found that they had a 60% coverage. A large proportion of the uncovered code was in error handling. (BTW, This claims that trying to get more that 80% code coverage is a mistake.)
Anyway, my point has always been that, even good tests aren't going to exercise every line so it's nice (but not a substitute) to be able to prove that some aspect the code is correct.
On a similar note, I haven't played with the BitC theorem prover:
--- Snip from the docs --- 11.1 Proof Obligations: Theorems The defthm form introduces a proof obligation that must be discharged by the BitC Prover. The body of a theorem is a boolean expression that is considered to be discharged if its result is #t for all possible variable instantiations:
(defthm name truth-expr)
---
However, it looks interesting but kinda insane.
I keep thinking that I should just go out and develop a new language -- people have paid me for developing language implementation before (C, SQL, XQuery, and Java). However, <whine>I don't wanna. Can't somebody else do it.</whine>;-)
I have a running argument with one of my friends about this. My position is that there are whole classes of errors that are caught at compile time with type inference.
His position is that, yes, that's true. But that the same class of errors is caught by even the most rudimentary unit tests.
I think he's correct for code that gets exercised. However, it's pretty difficult to get really great code coverage on unit tests -- especially of error handling code.
However, I think everyone can agree that putting the burden of type book keeping on the programmer (as in C/C+/Java) isn't as productive as a language with TI or dynamic typing.
There are plenty of reasons to dislike Ayn Rand but it's valuable to understand where she's coming from because, IMHO, she's right about many things.
In this particular excerpt, she's arguing essentially, that taxing the rich to support the poor is immoral and the person who does is is scum.
One of her core tenets is that "Man--every man--is an end in himself." People who abdicate that duty or entice other to abdicate that duty are immoral. Granted, I'm just some guy whose read a couple of books, but to me that means that giving a man a fish is immoral but teaching a man to fish is moral. In one instance you are saying, "It's okay to not learn to fish, I'll do it for you." in the other, you are saying "Here, take responsibility for your own fish." In the end the man that was taught to fish is not beholden (although maybe grateful) to the teacher. The man was given a fish is beholden to the giver (if he wants another fish).
Now, think about the people who do this in the modern world. She's basically talking about politicians. These folks take money from the those that have it (and I don't mean just the rich but middle and lower classes as well) and set up social services, which although well intentioned, have the effect of making the poor dependent on the politician. Essentially the politicians, in most not all cases, just give the poor a fish.
That sucks.
So, I'm all over government-sponsored training and short term help to complete the training. I think we do far less than we should.
However, the "give a man a fish" type of help should be limited to the period of time where you're also "teaching a man to fish".
Slashdot Mirror
Watch this now. Try it in a little while.
1) In any sufficiently large collection of people, there will be some who are unstable.
2) Linux will not wither because of the nuts -- there's too much value in Linux to business and as long as the value proposition is there, so will Linux.
3) John, and almost any journalist, is probably feeling a little threatened by the MOG story.
There have been many notable instances of national ID used to limit citizens rights.
So, I'm an older programmer (35 to be exact) and I've been coding for a *LONG* time. I was self taught starting at 10.
My work in the industry has always been praised. I've been constantly promoted and paid well.
A few years ago, I was doing some security work and wanted to understand the math behind the crypto libraries that I was using, so I tried to brush off my math. I ended up going back and I'm now in the process of finishing up my math degree. So, I can tell you a few of things from very direct and current experience.
1) Not doing well at math doesn't mean you can't code well. Until I went back, I was not terribly good at math.
2) At my school, University of Washington, the CS majors are math pussies. They bail on math dept. classes after a year of calc, a quarter of linear algebra and a quarter of stats. Yes, they get some math later in algorithms classes and the like but I know CS *PHDS* from good schools who are crappy at math.
3) I find that I occassionally use math in my work but not very much and it's hardly ever the calc -- it's almost always the linear algebra, number theory, and set theory.
Now, I think that you have to be smart enough to be able to handle math (as I obviously was) but that's different actually using math as part of the job or needing to take it as a condition of getting the degree.
While I agree that the problem is price, I disagree with the assertion that things will be flat or declining.
The world price for programming talent is lower than in the US which implies, that, absent a tarrif, that the US programmer's salaries should almost immediately go to the world price. However, in many ways, the incremental costs associated with managing software projects from afar are a sort of tarrif.
The problem, from the US programmers point of view, is that the tarrif has been cut over the last few years with the proliferation of the internet. However, I think that we are now (mostly) up against the fundamental complexities of the issue not just the accidental ones (like moving bits from place to place).
So, I would expect the tarrif not to be lowered much further. This means that for the US programmers position to get worse, the world price for engineering talent has to drop. It's possible that as China continues to come online that this will happen, but, since India competes against China in exports (for which the tarrif rate doesn't matter) I don't suspect it will have as much of an impact as India did.
The gatekeepers to medical care have an interest in keeping it as cheap as possible. That means downward pressure on physician pay. Don't think that a few doctors are going to stand in the way of insurance industry profits over the long term.
Are you seriously this big of a mathtard? Your "Hint" is from Gauss, hence the original poster's reference to him.
if I had no computer, I would probably be forced to think of something clever, like Gauss, and actually learn something.
So, either you're a mathtard who doesn't even know who Gauss is or you we in such a rush to prove you intellectual superiority that you couldn't be bothered to actually read the post.
So which kind of retard are you? Did you eat paint chips as a kid?
Yes, but they run that loop incredibly fast, so while they may not actually accomplish a whole lot, it sure is entertaining to watch. That is as long as you're not the guy that's going to get slammed when they fail.
You know the sad thing is that they bought a lot of the people that could really make this happen.
Simon Peyton Jones for one of them.
These are public companies. The directors are legally required to maximize profits. Does that mean that they are greedy bastards, not really. I'm not saying it's right, it's just the law. Two different things, you know.
These guys are simply saying, through this move, that they think they'll make more money by raising prices. See, there's this thing in economics call the price elasticity of demand. Which is just a fancy way of saying, how much will the demand change for a given change in price.
These guys think that the price elasticity of demand for music is low enough that, if they change the price, they'll more than make up for the lost sales. The only hope that we have is to show them that they're wrong.
But, we will fail because the majority of music buyers are in their teens. These are the same folks who think that emulating Paris Hilton is a good idea. Don't look for intelligent consumer behavior from that demographic.
Thank you, I'm an econ major and I thought my face was going to catch on fire.
The problem isn't that American companies require that employees compete globally, it's that governments do not have to compete for thier citizens.
See, we could choose which government we wanted to "buy" by paying taxes, you can sure bet that American programmers could relocate to locales with lower costs of living and compete globally.
That means that governments would have to compete on standard of living. If I can get a good wage and a low cost of living in another country, why can't I choose that? Mainly because it doesn't suit those in power, that's why.
If this were done overnight, the standard of living in the US would plummet overnight as a vast influx arrived. However, the standard of living in developing nations would skyrocket as people with "virtualizable jobs" brought thier higher earning potential into developing nations.
So, like the market liberialization experiences of South America, there would be a global wave of economic hardship in the short run, but in the long run a set of governments that *HAD* to be efficient, open, and responsive would be a huge plus.
Yes, it happened but it was in the context of the boy's drug trial. The evidence obtained from the mother's evesdropping was ruled inadmissable. So the court didn't say she couldn't do it but rather said that the information couldn't be used to convict someone else.
At least that's my recollection.
Or add:
Bite your thumb at them and go play another MMOMPPRPGQRSTUZWXYZ.
Down with the Capulets! down with the Montagues!
I could post may innapropriate comments in source code. In my youth one was: /* Go away Jeff XXXX. You do not understand this code even though you think you do. I'm tired of being forced to revert your changes to this file. */
Unfortunatly many of the best ones have been in proprietary code that is still in use and would be recognized if posted here.
Don't use it. Seriously. If you are comfortable with the level of logging you have, okay. There are others, who may be in the positions of not wanting log files that identify users because of the expense associated with discovery or complying with a subpeona.
Note, this is why large companies have email retention policies -- because having to do discovery or comply with a subpeona on email records going back years is expensive. So doing this type of thing isn't anything new or sinister.
Speedups like a factor of 1000 can only come from high level optimisations (like replacing an O(n^2) with an O(n log n) algo).
Nope. Technically, there are two constant burried in here. The definition is g(x) = O(f(x)) => g(x) <= k*f(x) where x > a for some orbitrary a. If you don't change algorithms, all you can do is manipulate the k. For a given k and a given level of improvement, I can give you a new k that hits that level of improvement.
Honestly: TO be able to get a 1000 times boost, your original code must have been beyond bullshit.
Also, his original code may have been "bullshit" but it may not have. It depends a lot on the algorithm in question. The higher the exponent on an exponential algorithm, they more sensitive its running time is to some optimization in an inner loop.
And of course using simd is better than not using it, but i would rather stay on a "let the compiler vectorize it" level. I mean, doing your inner loop in leet assambler only to NOT know after a long simulation if ther results are real or you just botched some line isnt worth it.
This is a simple matter of economics. There's a cost/benifit to expending the effort to optimize in assembly. If the compiler generates good code, then obviously, the cost/benefit of recoding in assembly is pretty high. However, without specific knowledge of *HIS* economics, I would suggest that you not spout off.
IANALBRTSOALSWIHSAL (I am not a lawyer but rather the spouse of a law student who I help study a lot) ...and you saved me from having to correct everybody. Now if I just had mod points.
They're coming -- sorta. I would expect to see the CLR become the prefered way of doing things for user-programmable stuff. Stored Procs in SQL Server, VB-Script replacement, etc.
.NET. They are huge codebases and a complete rewrite in any language even if 100x better may not be worth it.
I know that at least some of the projects are under way but, from an external point of view, a lot of things seem to be bound up with Longhorn, so they won't see the light of day anytime soon.
This all makes me wonder if we'll see some published introspection about what went wrong with Longhorn.
However, I don't know of any ground-up rewrited of major MS product, so you are correct. However, I'm not sure that it's an indictment of
Agreed. However, his point is that, since we're both respectable developers and neither of us would omit the unit tests, C/C++-style type checking is redundant book keeping and that type inference is of limited practical value.
;-)
I have to say, however, I've worked on a number of projects where developers wrote a large volume of unit tests. Then later, brought in code coverage tools. Invariably, everyone is dismayed at the truely huge amount of work required to simply get every line executed. (Simulating full/failing disks, torn database pages, dropped packets, other extenal events in such a way to get code coverage is hard.)
The first one I was involved in had automated tests that took >24hrs to run. When they brought in code coverage tools they found that they had a 60% coverage. A large proportion of the uncovered code was in error handling. (BTW, This claims that trying to get more that 80% code coverage is a mistake.)
Anyway, my point has always been that, even good tests aren't going to exercise every line so it's nice (but not a substitute) to be able to prove that some aspect the code is correct.
On a similar note, I haven't played with the BitC theorem prover:
--- Snip from the docs ---
11.1 Proof Obligations: Theorems
The defthm form introduces a proof obligation that must be discharged by the BitC Prover. The body of a theorem is a boolean expression that is considered to be discharged if its result is #t for all possible variable instantiations:
(defthm name truth-expr)
---
However, it looks interesting but kinda insane.
I keep thinking that I should just go out and develop a new language -- people have paid me for developing language implementation before (C, SQL, XQuery, and Java). However, <whine>I don't wanna. Can't somebody else do it.</whine>
...generate enough electromagnetic fields to shrivel the balls off your legs ...
Um. If your balls are attached to your legs instead of your crotch, you need to see a doctor.
I have a running argument with one of my friends about this. My position is that there are whole classes of errors that are caught at compile time with type inference.
His position is that, yes, that's true. But that the same class of errors is caught by even the most rudimentary unit tests.
I think he's correct for code that gets exercised. However, it's pretty difficult to get really great code coverage on unit tests -- especially of error handling code.
However, I think everyone can agree that putting the burden of type book keeping on the programmer (as in C/C+/Java) isn't as productive as a language with TI or dynamic typing.
Listen to older SUCCESSFUL managers who offer advice.
The key is to recognize who these people are. Official title is not always correlated.
There are plenty of reasons to dislike Ayn Rand but it's valuable to understand where she's coming from because, IMHO, she's right about many things.
In this particular excerpt, she's arguing essentially, that taxing the rich to support the poor is immoral and the person who does is is scum.
One of her core tenets is that "Man--every man--is an end in himself." People who abdicate that duty or entice other to abdicate that duty are immoral. Granted, I'm just some guy whose read a couple of books, but to me that means that giving a man a fish is immoral but teaching a man to fish is moral. In one instance you are saying, "It's okay to not learn to fish, I'll do it for you." in the other, you are saying "Here, take responsibility for your own fish." In the end the man that was taught to fish is not beholden (although maybe grateful) to the teacher. The man was given a fish is beholden to the giver (if he wants another fish).
Now, think about the people who do this in the modern world. She's basically talking about politicians. These folks take money from the those that have it (and I don't mean just the rich but middle and lower classes as well) and set up social services, which although well intentioned, have the effect of making the poor dependent on the politician. Essentially the politicians, in most not all cases, just give the poor a fish.
That sucks.
So, I'm all over government-sponsored training and short term help to complete the training. I think we do far less than we should.
However, the "give a man a fish" type of help should be limited to the period of time where you're also "teaching a man to fish".
At least get the history right. Here's a decent chronology.