Eloquently sums up my feelings about the disadvantages of dynamic typing

[H. S. Teoh]

On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis wrote:
> On Thursday, October 17, 2013 04:49:29 growler wrote:
> > On Thursday, 17 October 2013 at 02:37:35 UTC, H. S. Teoh wrote:
> > > On Wed, Oct 16, 2013 at 10:16:17PM -0400, Jonathan M Davis
[...]
> > >> I can't possibly like any language where the type of a variable
> > >> could change based on whether the condition in an if statement is
> > >> true (because a variable gets assigned a completely different
> > >> type depending no the branch of the if statement).
> > >> 
> > > auto func(alias condition)()
> > > {
> > > 
> > > static if (condition())
> > > 
> > > int t;
> > > 
> > > else
> > > 
> > > float t;
> > > 
> > > return t;
> > > 
> > > }
> > > 
> > > ;-)
> > 
> > But if you make a mistake it is very likely that you'll see it at
> > compile time, not runtime. Plus D has very explicit casting which
> > also helps.
> 
> The key difference is that the type of a variable won't change on you
> in D.  Sure, the return type of a function could change depending on
> the types of its arguments or the value of its template arguments, but
> it's all known at compile time, and you'll get an error for any type
> mismatch.

Yes, I know that. :) I was only being half-serious. D actually "does it
right" in this case: if for whatever reason the resulting type from the
static if is incompatible with the surrounding code, then as you say the
static typing system will throw up its hands at compile-time, rather
than at runtime on a customer's production environment.


> In contrast, with a dynamically typed language, the type of a variable
> can actually change while your program is running, resulting in
> function calls being wrong due to the fact that they don't work with
> the new type. If you're dealing with static typing, the type of every
> variable is fixed, and the legality of code doesn't suddenly change at
> runtime.

	bool func(Variant x, Variant y) {
		return x < y;
	}

	func(1, 2);	// ok
	func(1.0, 2.0);	// ok
	func("a", 1);	// hmmm... ;-)


> And it's not like scripting requires dynamic typing (e.g. you can
> write scripts in D, which is statically typed), so as far as I'm
> concerned, there's no excuse for using dynamic typing. It just causes
> bugs - not only that, but the bugs that it causes are trivially caught
> with a statically typed language.  I pretty much outright hate dynamic
> typing and expect that I will never heavily use a language that has
> it.
[...]

Dynamic typing has its place... database query results, for example.

However, the trouble with today's so-called "dynamic languages" is that
you're forced to use dynamic typing everywhere, even where it doesn't
make sense (and TBH, most of the time it's not appropriate). It's great
for writing truly generic functions like:

	// Javascript
	function add(x,y) { return x+y; }

but seriously, how much of *real*-world JS code is *that* generic? Most
actual JS code looks like this:

	function checkInput(data) {
		if (data.name == 'myname' || data.age < 10 || ...)
			return 1;
		return 0;
	}

which presumes the existence of specific fields in the 'data' parameter,
which implies that 'data' is an object type (as opposed to, say, an
int), and which will fail miserably if 'data' just so happens to be a
non-object, or an object without the presumed fields, or an object with
those exact fields that just happen to be of the wrong type, etc..
There are just so many levels of wrong with using dynamic typing for
this kind of code that being *forced* to do it is simply asking for
bugs.

Not to mention that the name 'data' says absolutely nothing about
exactly what structure it must have in order for the function to work;
you have to read the function body to find out (and even then, it's not
always obvious exactly what is expected). You end up wasting so much
time trying to deduce what type(s) the function must take (where in a
statically-typed language you just read the type name and look it up) or
otherwise working around the type system (or lack thereof) in similar
ways that it completely negates the purported productivity benefit of
dynamic typing.  (And yes I know there are ways to improve code
readability -- by parameter naming conventions, for example, which are
essentially reinventing type annotations poorly -- you still won't have
the benefit of compile-time type checking.)

Static typing with automatic type inference is a far superior solution
in most cases. And in D, you even have std.variant for those occasions
where you *do* want dynamic typing (whereas in languages like C, you
have to use tricky type casts and void* dereferences, which are very
prone to bugs). Being forced one way or another never ends well.


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!