I'm sorry you got Troll for this... I found this immensely funny
Thanks! I initially got mod-slammed for this, but seems things are turning around. You never know how controversial jokes go over on slashdot. Criticizing Linux or that M.E. country that starts with an "i" here is a gamble.
This means that you can never fully prove anything....Even with brain in a jar or simulations there is something that thinks your thoughts....There is a flaw in this reasoning...
It's okay, we are all just simulated cows. Relax, say "moo", and chew some cud.
I believe they announce a "find" when a certain statistical confidence level is reached.
For example, if the statistical confidence threshold is 95%, then they have to be at least 95% confident, based on statistical analysis of the data, before they formally announce.
But that would also mean that the "new" find, when formally announced, has a 5% chance of being wrong.
If the press or public complains often about false finds, they may decide to raise the threshold. (I don't know the actual current target level.)
I won't get into an argument about whether and when to "be careful" about such. (If you pay me, generally I'm more careful about such and look up rules as needed.)
But I would point out that there are a fair number of coders who are not native English speakers and otherwise write pretty solid code, if you ignore their comment and documentation grammar.
I can always find something to complain about in other people's comments and documentation if I wanted to. A lot of it is not "formal" mistakes, but otherwise poor decisions such as unnecessary words. It's easy to find crap to complain about in writing.
I didn't mean to imply the poor are dumb. Many just lack discipline, people skills, or hit hard-luck beyond their control. I encounter may working idiots also who use BS to get a paycheck.
I should have said, "The lawyers always filter out those who are too smart or experienced anyhow."
At the rate at which folks around here respond to jury summons, a robot substitute would be a big seller.
Why can't they tap all the unemployed/underemployed people? Jury duty is a PITA for working folks. Maybe a working person can pay a small fee to supplement their jury stipend.
I know it may bias the jury poll toward the poor, but it may not matter much for many types of trials. The lawyers always filter out those who are too smart anyhow.
Indeed, and the documentation is not always clear or accurate. One often has to fiddle to experiment, adjust, and find work-arounds for glitches.
That's where skill comes in such that it's often not as simple and sticking parts together and filling in parameters: that's the easy part.
Lego's with personality quirks is probably a better metaphor. The long blue Lego may not like being connected to the short yellow Lego on Tuesdays for reasons only known to Microsoft, Oracle, Google, or God.
Is this a complaint about typo's, or light/leaky abstractions? If the second, I do agree that certain kinds of applications require "tighter" or bigger frameworks. For accounting or medical applications, for example, time-saving abstractions are less important than reliable software, at the expense of requiring more coding time. Large, overarching frameworks are common and expected for such.
But if say it's a tracking system for internal restroom supplies, then nobody's going to want to spend the resources for ultra-reliable software to prevent toilet paper from occasionally getting lost. I'm not saying such is good or bad, only that by experience I know that time-saving "light" abstractions are more welcome and/or expected for such by management and/or owners. They don't want enterprise bills for non-enterprise stuff.
he couldn't maintain or debug because he'd abstracted things so much it was impossible for him to follow his own code, or know where to look when things went wrong. A small enhancement request left him squealing how the code wasn't designed to do that and he'd have to rebuild it. Meanwhile the rest of us went "so, all of that is in here, and if I just nudge this a little it's all done".
I've sometimes been accused of doing something similar. Good abstractions allow one to be productive by not having to micro-manage details; snapping together high-level modules like Logo's. But, they indeed can also entrap you when new requirements don't fit their design grain, or grow too confusing for new developers to figure out.
I've since been leaning toward abstractions that you "date instead of marry". The "test" is that one should be able to toss the abstraction if needed without too much code rework. It should be considered a "helper", not an "API kingdom".
A helper function can save you a dozen lines of code, but you shouldn't be obligated to use if you want to take advantage of the rest of the framework or helper utilities.
For example, it's nice to have a compact function or object to draw and validate form fields. However, it should also be possible to hand-draw the form field (raw markup) and/or do the validation separate without the drawing part. One shouldn't be forced to use it for all form fields or all validation to have the form work smoothly.
You may end using the shortcut function on say 80% of the fields, but can still do 20% outside the function/framework. Plus, it can simplify the helper functions/objects by not having to put every possible feature in there. Forceful frameworks often have to include every bell in whistle because one "should not" have to go outside the framework; making the framework have to handle every contingency. A function/object that only has to cover 80% of the cases is usually far simpler than one that has to cover 100%.
(That's one thing I don't like about Microsoft's API's and frameworks: you are either forced to be all in or all out; they don't make the middle ground very easy. I suspect this is to lock you into their world so that you have to buy more MS in the future.)
Microsoft does a lot wrong, but I'll give them kudos where due. Their Common Language Runtime has allowed one to code in either VB style or C style using mostly the same constructs and language processor engine.
If you design a new language, allow it to have 3 syntax styles:
1. C style 2. VB-ish style (x...end x, with underscore for continuation, type-name after variable.) 3. Python/Ruby style with white-space block nesting
At least one of these styles should make a given coder sufficiently happy (except maybe Lisp fans).
Make a translator that can convert between each style so that if a person or shop gets the style they don't want, they can convert, and/or allow them to mix their code with the code in the other style. (There may be edge cases where direct conversion may require human intervention.)
Thus, one module could be written in C-style, but work with a module in the VB style.
I was thinking of a compiler/interpreter that would look at function declarations to determine the style of that function. If it starts with "def", then assume the rest of the function has the Python/Ruby style. If the function body starts with "{", then assume C-style, otherwise it's VB-style.
You don't have to be a computer scientist to fiddle with AI as a hobby.
For example, I'm not a computer scientist nor a (formal) music expert, but have built music composing software as a hobby with "web" languages of Php's kin, by studying and experimenting with chord and melody patterns. It's largely a matter of experimenting and tuning based on feedback of those experiments.
Any "formal" scientist will probably have to do similar fiddle-change-fiddle cycles (although may use more theory up front). The difference is I don't have to stop to document anything and won't get fired if I produce nothing of value since it's not my day job. I have freedom to fail.
I don't expect to win any awards or accolades; I just fiddle for the fun of fiddling. If somebody else enjoys my works, which I sometimes put online, that's even better, but not prerequisite.
Slashdot Mirror
The fact you explicitly stated "in the lab" makes me concernedly wonder about the alternatives.
Thanks! I initially got mod-slammed for this, but seems things are turning around. You never know how controversial jokes go over on slashdot. Criticizing Linux or that M.E. country that starts with an "i" here is a gamble.
and if a car were designed like Linux?
- The mechanic would tell you to "RTFM and fix it yourself!"
- The brake pedal would be on the right and accelerator on the left.
- You'd have dashboard buttons with names like "bt", "nrf", and "xs2".
- You push "xs2" to see what happens, and the car accelerates forward without warning.
- Only 15% of all seat covers would fit and you'd have to drive to New Mexico to find tires that fit.
- Sometimes the brakes don't work, and TFM tells you to enter "stop -pd -V" in the command line as an alternative.
- You accidentally type a lower case "-v" in the above command set, and the car goes faster instead of stopping.
- You then smash into a brick wall at 70mph, and oddly the engine can still run.
- You'd get beat up by Linux Car fans if you dare criticized it (or modded to hell, like I'm about to be).
- The fans above usually take the body and dashboard off, and drive by pulling and splicing wires.
- They actually drive better that way.
Just put it in a Toyota, then you wouldn't expect it to stop.
"Data shot first"
Investing in real-estate wiped mine also
It's okay, we are all just simulated cows. Relax, say "moo", and chew some cud.
Good luck with that; the mailing address is on the "missing" planet.
I believe they announce a "find" when a certain statistical confidence level is reached.
For example, if the statistical confidence threshold is 95%, then they have to be at least 95% confident, based on statistical analysis of the data, before they formally announce.
But that would also mean that the "new" find, when formally announced, has a 5% chance of being wrong.
If the press or public complains often about false finds, they may decide to raise the threshold. (I don't know the actual current target level.)
I won't get into an argument about whether and when to "be careful" about such. (If you pay me, generally I'm more careful about such and look up rules as needed.)
But I would point out that there are a fair number of coders who are not native English speakers and otherwise write pretty solid code, if you ignore their comment and documentation grammar.
I can always find something to complain about in other people's comments and documentation if I wanted to. A lot of it is not "formal" mistakes, but otherwise poor decisions such as unnecessary words. It's easy to find crap to complain about in writing.
I'd always make 2 copies of anything important on different disks. Duplicate copies are still good advice because bleep happens.
It would be a slow-motion terminator. Not as flashy, but still bleeping up lives.
Computer, build me a slut with big tits
I didn't mean to imply the poor are dumb. Many just lack discipline, people skills, or hit hard-luck beyond their control. I encounter may working idiots also who use BS to get a paycheck.
I should have said, "The lawyers always filter out those who are too smart or experienced anyhow."
Why can't they tap all the unemployed/underemployed people? Jury duty is a PITA for working folks. Maybe a working person can pay a small fee to supplement their jury stipend.
I know it may bias the jury poll toward the poor, but it may not matter much for many types of trials. The lawyers always filter out those who are too smart anyhow.
What, outsourcing them to Timbuktu was not enough?
Who will be the last one standing?
Probably the plutocrat owners of it all.
Indeed, and the documentation is not always clear or accurate. One often has to fiddle to experiment, adjust, and find work-arounds for glitches.
That's where skill comes in such that it's often not as simple and sticking parts together and filling in parameters: that's the easy part.
Lego's with personality quirks is probably a better metaphor. The long blue Lego may not like being connected to the short yellow Lego on Tuesdays for reasons only known to Microsoft, Oracle, Google, or God.
Is this a complaint about typo's, or light/leaky abstractions? If the second, I do agree that certain kinds of applications require "tighter" or bigger frameworks. For accounting or medical applications, for example, time-saving abstractions are less important than reliable software, at the expense of requiring more coding time. Large, overarching frameworks are common and expected for such.
But if say it's a tracking system for internal restroom supplies, then nobody's going to want to spend the resources for ultra-reliable software to prevent toilet paper from occasionally getting lost. I'm not saying such is good or bad, only that by experience I know that time-saving "light" abstractions are more welcome and/or expected for such by management and/or owners. They don't want enterprise bills for non-enterprise stuff.
Corrections and clarifications:
Re: "...snapping together high-level modules like Logo's"
Should be "Lego's".
Re: "...often have to include every bell in whistle"
Should be "...bell and whistle".
Re: "One shouldn't be forced to use it for all form fields or all validation to have the form work smoothly."
Clarified: "One shouldn't be forced to use it for all form fields or all validation in order that the form work smoothly or properly."
I've sometimes been accused of doing something similar. Good abstractions allow one to be productive by not having to micro-manage details; snapping together high-level modules like Logo's. But, they indeed can also entrap you when new requirements don't fit their design grain, or grow too confusing for new developers to figure out.
I've since been leaning toward abstractions that you "date instead of marry". The "test" is that one should be able to toss the abstraction if needed without too much code rework. It should be considered a "helper", not an "API kingdom".
A helper function can save you a dozen lines of code, but you shouldn't be obligated to use if you want to take advantage of the rest of the framework or helper utilities.
For example, it's nice to have a compact function or object to draw and validate form fields. However, it should also be possible to hand-draw the form field (raw markup) and/or do the validation separate without the drawing part. One shouldn't be forced to use it for all form fields or all validation to have the form work smoothly.
You may end using the shortcut function on say 80% of the fields, but can still do 20% outside the function/framework. Plus, it can simplify the helper functions/objects by not having to put every possible feature in there. Forceful frameworks often have to include every bell in whistle because one "should not" have to go outside the framework; making the framework have to handle every contingency. A function/object that only has to cover 80% of the cases is usually far simpler than one that has to cover 100%.
(That's one thing I don't like about Microsoft's API's and frameworks: you are either forced to be all in or all out; they don't make the middle ground very easy. I suspect this is to lock you into their world so that you have to buy more MS in the future.)
Fewer people will vote if spammers etc. can get their personal information.
Microsoft does a lot wrong, but I'll give them kudos where due. Their Common Language Runtime has allowed one to code in either VB style or C style using mostly the same constructs and language processor engine.
If you design a new language, allow it to have 3 syntax styles:
1. C style
2. VB-ish style (x...end x, with underscore for continuation, type-name after variable.)
3. Python/Ruby style with white-space block nesting
At least one of these styles should make a given coder sufficiently happy (except maybe Lisp fans).
Make a translator that can convert between each style so that if a person or shop gets the style they don't want, they can convert, and/or allow them to mix their code with the code in the other style. (There may be edge cases where direct conversion may require human intervention.)
Thus, one module could be written in C-style, but work with a module in the VB style.
I was thinking of a compiler/interpreter that would look at function declarations to determine the style of that function. If it starts with "def", then assume the rest of the function has the Python/Ruby style. If the function body starts with "{", then assume C-style, otherwise it's VB-style.
One of these days a nefarious group will hack into ISP meta-data and publish it to the world, and this gov't requirement will then be questioned.
You don't have to be a computer scientist to fiddle with AI as a hobby.
For example, I'm not a computer scientist nor a (formal) music expert, but have built music composing software as a hobby with "web" languages of Php's kin, by studying and experimenting with chord and melody patterns. It's largely a matter of experimenting and tuning based on feedback of those experiments.
Any "formal" scientist will probably have to do similar fiddle-change-fiddle cycles (although may use more theory up front). The difference is I don't have to stop to document anything and won't get fired if I produce nothing of value since it's not my day job. I have freedom to fail.
I don't expect to win any awards or accolades; I just fiddle for the fun of fiddling. If somebody else enjoys my works, which I sometimes put online, that's even better, but not prerequisite.
So what happened if he drank alcohol? Did he go moo or something?
Oops, I mentioned cows on slashdot.