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.

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.

My /. account still works. Havent' used it in ...err... a few years.

Just here to bump this article for my friend Mike and his fantastic work on RC.

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!