Perhaps we spend a lot per probe relatively speaking, but NASA has had a great track record since giving up the "cheapo" approach of the 90's. The NASA/JPL Mars rovers and orbiters have done wonderful science.
In fact, the USA is the only country to land a working probe(s) on Mars. Both UK and USSR have attempted. (The Soviets came close, but it's debatable whether a certain attempt actually sent usable measurements back.)
Even if you deem it expensive, at least we got our money's worth, unlike some expensive Military boondoggles.
TFA pointed out that India is a lot more forgiving of failure and fast iteration than the US is today.
NASA tried the "faster, better, cheaper" (FBC) approach in the 90's with roughly a 50% success rate. UK also tried a "cheap" Mars lander, the Beagle, that was a bust.
If India can demonstrate they can KEEP going cheap and be successful, then we can conclude they are on to something. NASA's FBC also looked good at the start.
It's too early to tell for India. And even if they could get up to a 70% success rate, the 30% failure rate could be seen as a national embarrassment by some standards. Although, maybe a 3rd-world country may be more tolerable of such, being seen as underdog newbies.
It's also hard to plan science and control staffing if 30% of your probes are duds; and by sheer probability, 2 or 3 could fail in a row even at a 70% average, leaving a decade of gaps.
You are missing the point of dual typing it seems. If you don't want dual typing, there are already plenty of existing languages that are not dual typed. I'll give up convincing anybody that heavy typing or scripting (light typing) is the best way to go because the choice of those already exists for those who want them in fairly common languages. But give those of us who want dual typing a viable choice if you are in the interpreter implementation business so all 3 camps can be happy. (ColdFusion has it to some extent, but is lacking in other areas.)
In my opinion the basic trade-off is that "scriptish" languages can be written to be closer to pseudo-code and thus easier to read and grok. Strong/heavy typing tends to be verbose and redundant, slowing down reading.
Better grokkability often means less "conceptual" errors, but at the expense of more "technical" errors, such as type mismatches. There's no free lunch, only trade-offs.
In some projects the conceptual side overpowers the technical-error side, and vice verse. It also depends on the personality of the coder or team.
I don't want it inferred at times: I want to explicit declare my parameter intentions at times so it's "documented" and verified at the entrance to the castle, not deep inside the dungeon somewhere. Sure, the machine can figure that out, but it's not necessarily easy for human readers to figure that out when reading the code.
The problem with.NET was already described near 'you have to keep declaring everything "object" [to emulate dual typing]'.
If you receive an ID number from a URL parameter and it's already scrubbed to be a "number" in terms of proper digit characters etc., then there is no reason to have to explicitly cast it to "Integer" to pass it a routine that wants a parameter (interpretable as) "Integer". That's eye-real-estate-wasting redundant busy-work.
Dealing with semi-hidden type-tags is anti-WYSIWYG PITA. A language that gets rid of the distinction between "interpretable as" and "is-a" type has less sneaky surprises. That's my opinion, at least, after comparing and debating the trade-offs. I agree it may sacrifice some run-time efficiency, but it's the job of machines to slave away harder so humans don't have to.
I'm not proposing a scripting language, but a dual-typing language so that "types" are optionally required. "Best practices" are to require types on "infrastructure" (lower level) routines, but not the higher-level business-logic routines, at least for custom internal software. Commercial high-customer-volume software may be different.
The only language I've used in production that comes close is ColdFusion (although it's awkward in other areas).
My past attempts to find clear definitions of such produced long angry debates. Often how one views types depends on what mental model they personally use to "run" types in their head. There are many different ways to model the same or very similar type behavior such that selecting a canon model is futile unless we all agree to be arbitrary in order to have a common reference point.
How a compiler or interpreter is actually written is one modelling approach, but that assumes a language is "defined" by a given implementation at a given point in time rather than externally observable behavior (I/O), and "punishes" clones unfairly.
Difference enforcement policies work under different circumstances. While I agree such may make a nice option, I wouldn't want to force it on all methods ever written in the language.
And I'm against heavy use of exceptions. If one wants to programmatically "catch" a bad number, they can do an "isNumber(x)" test before calling the method. But everybody has a different opinion about such.
have to debug your crappy scripts (reverse engineer) what the object-types need to be (or what the contents of the String need to be).
Wouldn't the call signature give that info? Granted, existing IDE's are often crappy at providing such info from dynamic languages, but that's mostly an IDE issue.
The carrot instead of the stick of the law should be tried first: offer rewards for reporting rather than spankings for not. Laws like this just clog up police departments and courts, and probably increase insurance rates for trash collection companies.
50's Cadillacs had bumpy rides? That's news to me. And airbags and anti-lock brakes does not seem like the kind of thing that would wow somebody. "That's kind of neat" perhaps, but not "woooow!".
But I thought your standard was about predictions, not about what would seem impressive to average Joe.
My point was that because we know the "tricks" Siri and Deep Blue uses to appear/be semi-intelligent, we tend to down-play them.
Intelligence" implies an adaptability, a creativity, an ability to process abstract concepts and learn, etc.
That's part of it, but much of it is also the ability to do useful tasks that "regular" machines cannot pull off. How it achieves those "useful tasks" is secondary to the AI user. Even a human that suddenly was UNable to learn anything new could perform a good many useful tasks that are not trivial to automate.
As I said in my first reply to you, most of our "progress" toward AI has been made possible by the computer and electronics revolution you mentioned, which was not predicted in the 50s.
Again, the "how" is secondary to the fact it can do impressive stuff. Yes, we "cheat" using massive processing, mass statistics, and big-ass databases, but so what, it "works" to a large extent at achieving a level of AI or AI-like results. "Cheating" is relative.
Why aren't there more languages that allow strong typing were desired but weak typing where not? One can kind of emulate such with generic "variant" or "object" types in some languages, but you have to keep declaring everything "object". If I want dynamic parameters, I shouldn't have to put any type-related keyword in the parameter definition.
For example, one should be able to type: function foo(x, y)... versus function foo(x:int, y:string)... for weak and strong typing, respectively. And types could be converted as needed for strong parameters rather than require an explicit conversion/casting. For example, if you send a string to x in the 2nd function def above, it would attempt to parse and convert it to an integer.
Strong typing tends to be best for the "root" routines and deeper infrastructure guts of a system, but weak typing for the top-layer business logic, where being closer to pseudo-code helps one read and fiddle with ever-changing business logic. Dual typing would allow a single language to better fill both roles.
And one should be able to specify that a given class or module or name-space requires all variable and parameter definitions to be explicitly typed to enforce strong-typing for selected sections.
The idea that a language must be type-heavy OR type-light seems false; a mere habit of the industry.
Depends on the reader. Anyhow, coding is the art of balancing trade-offs among many factors, but readability by an average programmer (future maintainer) should be among the top priorities. It's best to learn what code style is the easiest for a random programmer to digest.
Too much abstraction and factoring can sometimes throw readers off, I hate to say. Those who personally enjoy making "symbolically optimized" code don't like to hear that, but one is not coding on an island, but rather in the City of Fungible Cubicles.
Somebody from the 1950's given Siri to play with for a few hours would be quite impressed. No, it's not human-level, but human level would be "A". Also keep in mind that back then they considered winning at chess a strong test of AI. (We've since come to appreciate the complexity of more basic tasks like washing dishes.)
Slashdot Mirror
"If you shove it up your anus, it's better protected."
Explains why he was so grumpy to employees.
Where did this word "bendy" come from? It sounds like a Gumby pal. Isn't it "bendable" or "flexible" or "pliable"?
Somebody is trying to make English bendy.
It's called Fox News Anchor Women
It may be one or few jerks doing this. It's difficult to tell with the info given. Every org has jerks.
So Pluto is alive? Settled!
Perhaps we spend a lot per probe relatively speaking, but NASA has had a great track record since giving up the "cheapo" approach of the 90's. The NASA/JPL Mars rovers and orbiters have done wonderful science.
In fact, the USA is the only country to land a working probe(s) on Mars. Both UK and USSR have attempted. (The Soviets came close, but it's debatable whether a certain attempt actually sent usable measurements back.)
Even if you deem it expensive, at least we got our money's worth, unlike some expensive Military boondoggles.
NASA tried the "faster, better, cheaper" (FBC) approach in the 90's with roughly a 50% success rate. UK also tried a "cheap" Mars lander, the Beagle, that was a bust.
If India can demonstrate they can KEEP going cheap and be successful, then we can conclude they are on to something. NASA's FBC also looked good at the start.
It's too early to tell for India. And even if they could get up to a 70% success rate, the 30% failure rate could be seen as a national embarrassment by some standards. Although, maybe a 3rd-world country may be more tolerable of such, being seen as underdog newbies.
It's also hard to plan science and control staffing if 30% of your probes are duds; and by sheer probability, 2 or 3 could fail in a row even at a 70% average, leaving a decade of gaps.
There are about a dozen politician jokes to be mined from this story.
You are missing the point of dual typing it seems. If you don't want dual typing, there are already plenty of existing languages that are not dual typed. I'll give up convincing anybody that heavy typing or scripting (light typing) is the best way to go because the choice of those already exists for those who want them in fairly common languages. But give those of us who want dual typing a viable choice if you are in the interpreter implementation business so all 3 camps can be happy. (ColdFusion has it to some extent, but is lacking in other areas.)
Sometimes advice carries more weight to the listener if they paid and arm and a leg for it.
In my opinion the basic trade-off is that "scriptish" languages can be written to be closer to pseudo-code and thus easier to read and grok. Strong/heavy typing tends to be verbose and redundant, slowing down reading.
Better grokkability often means less "conceptual" errors, but at the expense of more "technical" errors, such as type mismatches. There's no free lunch, only trade-offs.
In some projects the conceptual side overpowers the technical-error side, and vice verse. It also depends on the personality of the coder or team.
I don't want it inferred at times: I want to explicit declare my parameter intentions at times so it's "documented" and verified at the entrance to the castle, not deep inside the dungeon somewhere. Sure, the machine can figure that out, but it's not necessarily easy for human readers to figure that out when reading the code.
The problem with .NET was already described near 'you have to keep declaring everything "object" [to emulate dual typing]'.
If you receive an ID number from a URL parameter and it's already scrubbed to be a "number" in terms of proper digit characters etc., then there is no reason to have to explicitly cast it to "Integer" to pass it a routine that wants a parameter (interpretable as) "Integer". That's eye-real-estate-wasting redundant busy-work.
Dealing with semi-hidden type-tags is anti-WYSIWYG PITA. A language that gets rid of the distinction between "interpretable as" and "is-a" type has less sneaky surprises. That's my opinion, at least, after comparing and debating the trade-offs. I agree it may sacrifice some run-time efficiency, but it's the job of machines to slave away harder so humans don't have to.
I'm not proposing a scripting language, but a dual-typing language so that "types" are optionally required. "Best practices" are to require types on "infrastructure" (lower level) routines, but not the higher-level business-logic routines, at least for custom internal software. Commercial high-customer-volume software may be different.
The only language I've used in production that comes close is ColdFusion (although it's awkward in other areas).
My past attempts to find clear definitions of such produced long angry debates. Often how one views types depends on what mental model they personally use to "run" types in their head. There are many different ways to model the same or very similar type behavior such that selecting a canon model is futile unless we all agree to be arbitrary in order to have a common reference point.
How a compiler or interpreter is actually written is one modelling approach, but that assumes a language is "defined" by a given implementation at a given point in time rather than externally observable behavior (I/O), and "punishes" clones unfairly.
Difference enforcement policies work under different circumstances. While I agree such may make a nice option, I wouldn't want to force it on all methods ever written in the language.
And I'm against heavy use of exceptions. If one wants to programmatically "catch" a bad number, they can do an "isNumber(x)" test before calling the method. But everybody has a different opinion about such.
Wouldn't the call signature give that info? Granted, existing IDE's are often crappy at providing such info from dynamic languages, but that's mostly an IDE issue.
The carrot instead of the stick of the law should be tried first: offer rewards for reporting rather than spankings for not. Laws like this just clog up police departments and courts, and probably increase insurance rates for trash collection companies.
50's Cadillacs had bumpy rides? That's news to me. And airbags and anti-lock brakes does not seem like the kind of thing that would wow somebody. "That's kind of neat" perhaps, but not "woooow!".
My point was that because we know the "tricks" Siri and Deep Blue uses to appear/be semi-intelligent, we tend to down-play them.
That's part of it, but much of it is also the ability to do useful tasks that "regular" machines cannot pull off. How it achieves those "useful tasks" is secondary to the AI user. Even a human that suddenly was UNable to learn anything new could perform a good many useful tasks that are not trivial to automate.
Again, the "how" is secondary to the fact it can do impressive stuff. Yes, we "cheat" using massive processing, mass statistics, and big-ass databases, but so what, it "works" to a large extent at achieving a level of AI or AI-like results. "Cheating" is relative.
Does he throw a fit if you divide by zero?
Why aren't there more languages that allow strong typing were desired but weak typing where not? One can kind of emulate such with generic "variant" or "object" types in some languages, but you have to keep declaring everything "object". If I want dynamic parameters, I shouldn't have to put any type-related keyword in the parameter definition.
For example, one should be able to type: function foo(x, y)... versus function foo(x:int, y:string)... for weak and strong typing, respectively. And types could be converted as needed for strong parameters rather than require an explicit conversion/casting. For example, if you send a string to x in the 2nd function def above, it would attempt to parse and convert it to an integer.
Strong typing tends to be best for the "root" routines and deeper infrastructure guts of a system, but weak typing for the top-layer business logic, where being closer to pseudo-code helps one read and fiddle with ever-changing business logic. Dual typing would allow a single language to better fill both roles.
And one should be able to specify that a given class or module or name-space requires all variable and parameter definitions to be explicitly typed to enforce strong-typing for selected sections.
The idea that a language must be type-heavy OR type-light seems false; a mere habit of the industry.
Depends on the reader. Anyhow, coding is the art of balancing trade-offs among many factors, but readability by an average programmer (future maintainer) should be among the top priorities. It's best to learn what code style is the easiest for a random programmer to digest.
Too much abstraction and factoring can sometimes throw readers off, I hate to say. Those who personally enjoy making "symbolically optimized" code don't like to hear that, but one is not coding on an island, but rather in the City of Fungible Cubicles.
Somebody from the 1950's given Siri to play with for a few hours would be quite impressed. No, it's not human-level, but human level would be "A". Also keep in mind that back then they considered winning at chess a strong test of AI. (We've since come to appreciate the complexity of more basic tasks like washing dishes.)
Roachzilla!
Because they outsource to themselves at 1/3 the cost of Americans.
Right now they merely watch; they don't throw you into Re-education Camp.