So stop pretending that "pointers are bad". If your program crash and you cannot figure it out, you're too stupid for the work.
Well, there's sloppy or bad programmers out there whether you want that to be the case or not. Languages can protect them from themselves to some degree at the expense of speed/resources by avoiding pointer or pointer-like constructs. That's often considered the more economical choice for domain-specific and custom applications. You can't reboot the human race.
[not too different from other common production languages.] That is not a worthy goal. The common production languages invariably suck in a *design* sense.
There are a lot of "interesting" languages, but the industry seems to like Java and C# overall. Whether that's "good" or "rational" perhaps is highly debatable, but it seems they struck the right chord in the industry as a preferred tool. I'm not here to debate the "ideal" language from a purely language design standpoint.
If Object Pascal and Ada are too complex...
I meant only Ada, not Pascal. Complexity is a common complaint against Ada. If you want to label the complainers as "dumb", that's fine, but again I'm talking about what the industry seems to want, not the ideal way to be.
You can compile Python to native executables...
But they still lack the strong typing. The up-front type and reference verification done by compilers is one of the top selling points of compilers, arguably more than speed.
The problem with epicycles is they very quickly did not match data from observations, even with the attempts to nest epicycles within epicycles.
I'm not sure that's the case. I've never seen a proof that epicyces CANNOT be made to match observations within a reasonable observation time-frame. Whether they actually got them "good enough" in practice before Newton's work, I don't know. I'm mostly talking about potential.
Seeing how accurate nested epicycles COULD be would make an interesting research paper. (This is assuming the epicycles don't re-invent a sun-centered model.)
As somebody else mentioned, using an Earth-centric assumption was also part of the "problem" with the epicycle model, not just the usage of epicycles. But that doesn't change the general point. It was a model with (potentially?) sufficient predictive power, but didn't mirror the actual mechanism and system layout.
How does one know their model actually reflects the underlying mechanism, or is merely a fudging trick to produce a good-enough approximation?
(Incidentally, some say string theory is throwing dimensions at the problem similar to epicycles throwing nested circles at the problem. "Dimensional regression" of sorts.)
you can't just assume some simpler or easier theory exists.
That is indeed true. But QM models smell like kludges. That can be seen as an indicator that there may be a simpler explanation/model lurking out there to be discovered. Hunches are often the first step.
But that's possibly like saying, "epicycles are straight forward to model if you remember your math". (Circular regression?) While possibly true, epicycles were the "wrong model" to begin with for orbital mechanics.
One can model just about any fake or spooky thing that follows patterns with math/algorithms, but that doesn't mean the model reflects the underlying mechanism well.
It's like the analysts produce sloppy pseudo-code or an equivalent and the programmers then have to find a way to turn that into concrete code. That's often not trivial such that the programmers are doing a degree of "analysis", and that's why it's often not cookie-cutter.
If the analysts *did* produce sufficiently "tight" specs, then that spec indeed might as well be a program such you don't need a middle-person programmer. But that puts a lot of burden on the analyst, who essentially is then a programmer/analyst.
But for larger projects it's usually best to let analysts focus on business/domain logic and programmers focus on the lower-level guts of getting it to run in practice, working around goofy bugs in the libraries/API's, and communicating ambiguities to analysts. Both positions require skill and experience to do WELL.
Yeah, but if Enron, Comcast, SCO, Oracle, and Microsoft mess things up they go out of business.
True, but that doesn't stop them from being stupid. I believe Alan Greenspan said in his book that he was shocked that so many banks & co's knowingly shot themselves in the foot by over-gambling in the ponzi-like run-up to the mortgage financial crash.
Sometimes punishment is not enough to keep humans from being humans.
And there are ways to be slimy YET stay in business. Crime sometimes does pay.
And the heads of gov't institutions ARE often replaced or "encouraged" out if bleep happens, similar to CEO's losing their reign. Witness Jesse W. Moore per Shuttle disaster.
Agreed, but the problem is that there is no alternative statically-typed ("compile-y") language out there that seems ready in terms of being road-tested and not too different from other common production languages.
C# is too MS-tied with a similar legal-greed risk, and C++ is too low-level to replace Java and C#.
Object Pascal? Ada? too complex. Eiffel? too much like Pascal such that you might as well go Pascal.
Python, Ruby, Php, etc. are dynamic languages. They have their place, but for certain classes of applications you need a static/strict typed language.
I give up, quantum stuff makes sorcery sound logical in comparison.
Too bad Einstein's not still around; maybe he could find a more down-to-earth or simpler explanation. He seemed to be the only prominent one questioning that something seems really out of whack, as if we are missing a yuuuuuge piece of the puzzle.
He solved the ether weirditity by plugging in relativity. Similarly, maybe the probability and multi/ghostiverses games will fade away when the equivalent of relativity is applied to quantum stuff.
Maybe particles are like sperm in that when one photon is apparently emitted, there's really many particles emitted, and the first one to hit (react) shuts off the other particles so that they are invisible, almost like neutrinos, so that we don't detect them.
Thus, the interference pattern really *is* a wave; it only looks like a lone particle upon detection because the others cloak. Well, I'm rambling, but you get the idea: there's a BIG IDEA out there to be discovered...
Science took an unfortunate whack to the guts. I'm glad to see resources spent on science instead of war, however. Even with occasional failures like this, the overall payoff is usually far better than war of late.
I can play the same game: "I'm from Enron, Comcast, SCO, Oracle, and Microsoft, and I am here to help."
Gov't and private industry are BOTH economic tools. If you don't regularly inspect, monitor, and keep them clean; they can rust, corrode, fail, and even put an eye out.
A lot of problem solving is balancing trade-offs, something that is rarely taught in school until financing. There's rarely a free lunch, but rather sacrificing something in one area to get more in another. And one has to be able to communicate such trade-offs in a way that makes sense to managers, such as spending 2k more on software to save 4k on labor.
Don't forget to factor in overhead when it comes to labor costing. On the flip side, procurement is often expensive and tricky in larger organizations such that throwing labor at the problem may actually be easier. Knowing the org matters.
told me that programmers were "like bricklayers". In other words, the difficult part was done by analysts and the like, and the programmers simply had to "code up" their designs.
That depends on how the organization is set up. It is possible for analysts to write up detailed specifications so that programmers only have to follow instructions, but in practice it's far more give and take because writing good specs is hard, and because there will be surprises.
Thus, it takes programming knowledge on the analysts side and analyst skills on the programming side to weave it all together.
Use protectionism as a negotiating tool, not as an end-goal. Threaten to tariff trade of low-wage countries if they don't encourage local consumerism, have labor/safety/pollution laws, and/or increase their exchange rate.
They often artificially tilt things toward low wages so that their population doesn't riot. Jobs are more important to their populations than cheap stuff. We seem to have it reversed.
When Word first added auto-correct and nobody knew it was active, a lady's name, "Jina Brennan" was re-converted as "Jina Pregnant" because the typist at first typed the name in lower case. He/she corrected the capital, but not the name. HR went nuts.
Slashdot Mirror
China has a history of building walls to keep foreign people or things out. Old habits die hard.
Well, there's sloppy or bad programmers out there whether you want that to be the case or not. Languages can protect them from themselves to some degree at the expense of speed/resources by avoiding pointer or pointer-like constructs. That's often considered the more economical choice for domain-specific and custom applications. You can't reboot the human race.
There are a lot of "interesting" languages, but the industry seems to like Java and C# overall. Whether that's "good" or "rational" perhaps is highly debatable, but it seems they struck the right chord in the industry as a preferred tool. I'm not here to debate the "ideal" language from a purely language design standpoint.
I meant only Ada, not Pascal. Complexity is a common complaint against Ada. If you want to label the complainers as "dumb", that's fine, but again I'm talking about what the industry seems to want, not the ideal way to be.
But they still lack the strong typing. The up-front type and reference verification done by compilers is one of the top selling points of compilers, arguably more than speed.
I'm not sure that's the case. I've never seen a proof that epicyces CANNOT be made to match observations within a reasonable observation time-frame. Whether they actually got them "good enough" in practice before Newton's work, I don't know. I'm mostly talking about potential.
Seeing how accurate nested epicycles COULD be would make an interesting research paper. (This is assuming the epicycles don't re-invent a sun-centered model.)
As somebody else mentioned, using an Earth-centric assumption was also part of the "problem" with the epicycle model, not just the usage of epicycles. But that doesn't change the general point. It was a model with (potentially?) sufficient predictive power, but didn't mirror the actual mechanism and system layout.
How does one know their model actually reflects the underlying mechanism, or is merely a fudging trick to produce a good-enough approximation?
(Incidentally, some say string theory is throwing dimensions at the problem similar to epicycles throwing nested circles at the problem. "Dimensional regression" of sorts.)
That is indeed true. But QM models smell like kludges. That can be seen as an indicator that there may be a simpler explanation/model lurking out there to be discovered. Hunches are often the first step.
But that's possibly like saying, "epicycles are straight forward to model if you remember your math". (Circular regression?) While possibly true, epicycles were the "wrong model" to begin with for orbital mechanics.
One can model just about any fake or spooky thing that follows patterns with math/algorithms, but that doesn't mean the model reflects the underlying mechanism well.
It's like the analysts produce sloppy pseudo-code or an equivalent and the programmers then have to find a way to turn that into concrete code. That's often not trivial such that the programmers are doing a degree of "analysis", and that's why it's often not cookie-cutter.
If the analysts *did* produce sufficiently "tight" specs, then that spec indeed might as well be a program such you don't need a middle-person programmer. But that puts a lot of burden on the analyst, who essentially is then a programmer/analyst.
But for larger projects it's usually best to let analysts focus on business/domain logic and programmers focus on the lower-level guts of getting it to run in practice, working around goofy bugs in the libraries/API's, and communicating ambiguities to analysts. Both positions require skill and experience to do WELL.
True, but that doesn't stop them from being stupid. I believe Alan Greenspan said in his book that he was shocked that so many banks & co's knowingly shot themselves in the foot by over-gambling in the ponzi-like run-up to the mortgage financial crash.
Sometimes punishment is not enough to keep humans from being humans.
And there are ways to be slimy YET stay in business. Crime sometimes does pay.
And the heads of gov't institutions ARE often replaced or "encouraged" out if bleep happens, similar to CEO's losing their reign. Witness Jesse W. Moore per Shuttle disaster.
Agreed, but the problem is that there is no alternative statically-typed ("compile-y") language out there that seems ready in terms of being road-tested and not too different from other common production languages.
C# is too MS-tied with a similar legal-greed risk, and C++ is too low-level to replace Java and C#.
Object Pascal? Ada? too complex. Eiffel? too much like Pascal such that you might as well go Pascal.
Python, Ruby, Php, etc. are dynamic languages. They have their place, but for certain classes of applications you need a static/strict typed language.
Object-Fortran? :-) I dunno
I give up, quantum stuff makes sorcery sound logical in comparison.
Too bad Einstein's not still around; maybe he could find a more down-to-earth or simpler explanation. He seemed to be the only prominent one questioning that something seems really out of whack, as if we are missing a yuuuuuge piece of the puzzle.
He solved the ether weirditity by plugging in relativity. Similarly, maybe the probability and multi/ghostiverses games will fade away when the equivalent of relativity is applied to quantum stuff.
Maybe particles are like sperm in that when one photon is apparently emitted, there's really many particles emitted, and the first one to hit (react) shuts off the other particles so that they are invisible, almost like neutrinos, so that we don't detect them.
Thus, the interference pattern really *is* a wave; it only looks like a lone particle upon detection because the others cloak. Well, I'm rambling, but you get the idea: there's a BIG IDEA out there to be discovered...
Rest In Pieces
Science took an unfortunate whack to the guts. I'm glad to see resources spent on science instead of war, however. Even with occasional failures like this, the overall payoff is usually far better than war of late.
More like the volcano is drooling. God must be ringing a bell.
She actually did say something similar to that. Fey merely "decorated" and exaggerated it for comedy purposes.
I can play the same game: "I'm from Enron, Comcast, SCO, Oracle, and Microsoft, and I am here to help."
Gov't and private industry are BOTH economic tools. If you don't regularly inspect, monitor, and keep them clean; they can rust, corrode, fail, and even put an eye out.
That's not "mental stimulation", that's laughter.
Both Palin and Putin can see it from their houses.
Has an organization ever won a Darwin Award?
A lot of problem solving is balancing trade-offs, something that is rarely taught in school until financing. There's rarely a free lunch, but rather sacrificing something in one area to get more in another. And one has to be able to communicate such trade-offs in a way that makes sense to managers, such as spending 2k more on software to save 4k on labor.
Don't forget to factor in overhead when it comes to labor costing. On the flip side, procurement is often expensive and tricky in larger organizations such that throwing labor at the problem may actually be easier. Knowing the org matters.
That depends on how the organization is set up. It is possible for analysts to write up detailed specifications so that programmers only have to follow instructions, but in practice it's far more give and take because writing good specs is hard, and because there will be surprises.
Thus, it takes programming knowledge on the analysts side and analyst skills on the programming side to weave it all together.
Too bad we can't tap that energy. We could get massive power and cool down the problem magma zit at the same time.
Use protectionism as a negotiating tool, not as an end-goal. Threaten to tariff trade of low-wage countries if they don't encourage local consumerism, have labor/safety/pollution laws, and/or increase their exchange rate.
They often artificially tilt things toward low wages so that their population doesn't riot. Jobs are more important to their populations than cheap stuff. We seem to have it reversed.
The "big wealth" is indeed becoming trans-national, ironically, not unlike terrorist groups.
Maybe nations are becoming obsolete, not just workers.
To have a head or not have a head
That may explain the rings, but probably not new moons, unless it was a really large moon.
Why would that happen, Mr. Selin?
When Word first added auto-correct and nobody knew it was active, a lady's name, "Jina Brennan" was re-converted as "Jina Pregnant" because the typist at first typed the name in lower case. He/she corrected the capital, but not the name. HR went nuts.