On Thursday, 17 October 2013 at 03:07:30 UTC, Jonathan M Davis wrote:
> I pretty much outright hate dynamic typing and expect that I will never heavily use a language that has it.

Be careful what you say: D has dynamic typing! (see: std.variant, or my arsd.jsvar)

The important thing though is that D doesn't *force* you to use it: it is there for the cases where you want it, and not when you don't want it.

On Thursday, October 17, 2013 05:12:48 Adam D. Ruppe wrote:
> On Thursday, 17 October 2013 at 03:07:30 UTC, Jonathan M Davis
> 
> wrote:
> > I pretty much outright hate dynamic typing and expect that I will never heavily use a language that has it.
> 
> Be careful what you say: D has dynamic typing! (see: std.variant,
> or my arsd.jsvar)
> 
> The important thing though is that D doesn't *force* you to use it: it is there for the cases where you want it, and not when you don't want it.

It's not quite the same thing. D itself is not dynamically typed. It just allows you to create it with your own types if you want to. But I also think that variants should be avoided unless they're absolutely necessary, and it's very rare that they're necessary. Certain specific stuff needs it (like the result from a database query), but the vast majority of code does not.

- Jonathan M Davis

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!

On 2013-10-16 23:08, Nick Sabalausky wrote:

> Compiling it shouldn't be a problem:
> http://xkcd.com/224/

So, it's written in Perl. That's why we haven't figured out how the universe works:

"You shoot yourself in the foot, but nobody can understand how you did it. Six months later, neither can you"

http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/

-- 
/Jacob Carlborg

On 2013-10-16 22:55, H. S. Teoh wrote:

> Even *with* developer tools, where would you even start? I mean, the
> blank page could have resulted from any one point of about 5kloc worth
> of JS initialization code (which BTW dynamically loads in a whole bunch
> of other JS code, each of which need to run their own initialization
> which includes talking to a remote backend server and processing the
> response data, all before anything even gets displayed on the page --
> don't ask me why it was designed this way, this is what happens when you
> take the browser-as-a-platform concept too far). I think (relatively)
> recently Opera's Dragonfly added a feature to break into the debugger as
> soon as an error is thrown (rather than only when it's unhandled), but
> even that doesn't seem to catch all of the errors.

If you get an error the developer tools will show you where. At least it's a start.

-- 
/Jacob Carlborg

On Thursday, 17 October 2013 at 07:42:22 UTC, Jacob Carlborg wrote:
> On 2013-10-16 23:08, Nick Sabalausky wrote:
>
>> Compiling it shouldn't be a problem:
>> http://xkcd.com/224/
>
> So, it's written in Perl. That's why we haven't figured out how the universe works:
>
> "You shoot yourself in the foot, but nobody can understand how you did it. Six months later, neither can you"
>
> http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/

So what's the D equivalent?

"You're only allowed to shoot yourself in the foot if you use system."

On 2013-10-17 11:15, Meta wrote:

> So what's the D equivalent?
>
> "You're only allowed to shoot yourself in the foot if you use system."

From the comments:

"D
You shoot yourself in the foot in two linse using a builtin Gun and Bullet[].

The experience is so enjoyable you shoot yourself again…."

-- 
/Jacob Carlborg

On Thursday, 17 October 2013 at 09:49:37 UTC, Jacob Carlborg wrote:
> From the comments:

I had to laugh at this one:

".Net

Microsoft hands you a gun and swears blind it’s a toenail clipper

Someone throws a fucking chair at you."

+1

What can I say? For the web I have to use JavaScript, PHP and Python. Imagine the amount of stupid-yet-hard-to-find bugs I've had to deal with. Bugs that you only become aware of at runtime.

Am much happier with D (or Java, Objective-C). As for the arguments concerning compile time, extra typing for typing, c'mon, they must be kidding.

Not to mention increased execution speed, not only in terms of script vs. binary, but also in terms of known type vs. dynamically assigned type.

Another issue I've come across is that languages like JS and PHP lend themselves to quick and dirty stuff, or rather seduce programmers to quick and dirty solutions. Languages like D guide you towards cleaner and better structured code.

On Thursday, 17 October 2013 at 07:43:07 UTC, Jacob Carlborg wrote:
> On 2013-10-16 22:55, H. S. Teoh wrote:
>
>> Even *with* developer tools, where would you even start? I mean, the
>> blank page could have resulted from any one point of about 5kloc worth
>> of JS initialization code (which BTW dynamically loads in a whole bunch
>> of other JS code, each of which need to run their own initialization
>> which includes talking to a remote backend server and processing the
>> response data, all before anything even gets displayed on the page --
>> don't ask me why it was designed this way, this is what happens when you
>> take the browser-as-a-platform concept too far). I think (relatively)
>> recently Opera's Dragonfly added a feature to break into the debugger as
>> soon as an error is thrown (rather than only when it's unhandled), but
>> even that doesn't seem to catch all of the errors.
>
> If you get an error the developer tools will show you where. At least it's a start.


Unless you are developing a f**** hybrid application targeting to mobiles.

No debugger there to talk to the corresponding native browser widgets. :( :(

--
Paulo