On Wednesday, 16 October 2013 at 20:00:45 UTC, Walter Bright wrote:
> On 10/16/2013 8:37 AM, Sean Kelly wrote:
>> I'm reasonably okay with dynamic languages so long as you can require a
>> variable to be declared before it's used.  Those that implicitly declare on
>> first assignment are a nightmare however. I once spent an entire day
>> debugging a Lua app that turned out to be broken because of a typo in an
>> assignment. Never again.
>
> Implicit declaration is such a bad idea; I wonder why it keeps reappearing in every new dynamic language du jour.

Hail CoffeeScript!

On Wed, Oct 16, 2013 at 09:14:14PM +0200, Jacob Carlborg wrote:
> On 2013-10-16 19:26, H. S. Teoh wrote:
> 
> >Yeah, this is exactly what makes Javascript a royal pain in the neck to work with.  I have the dubious pleasure of having to work on a large non-trivial JS codebase at work, and it has a reputation of simply displaying a blank page when something goes wrong. Worse yet, there is some default error handler somewhere that swallows all JS errors, so no errors get logged to the browser's JS console at all -- you have to debug the entire 50k or so lines of JS with a blank page as your only clue as to what blew up.
> 
> Yeah, you really need to use the browser's developer tools to have any chance when working with JavaScript.

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.


> >(And don't get me started on IE6, which used to be the de facto standard demanded by every customer some years ago, which doesn't even *have* an error console. Fortunately, the world has moved on since.)
> 
> Actually, just a couple of weeks ago I found Firebug Lite. It's like Firebug but it's a booklet in pure JavaScript (ironically). That means you can use it in any browser, include IE6 (yes it works in IE6), iOS and other browsers missing developer tools.
[...]

Nice! I'll have to keep that in mind when I next have to deal with that horrendous JS code.


T

-- 
Political correctness: socially-sanctioned hypocrisy.

On Wed, Oct 16, 2013 at 10:48:03PM +0200, Tourist wrote:
> On Wednesday, 16 October 2013 at 20:43:30 UTC, H. S. Teoh wrote:
> >On Wed, Oct 16, 2013 at 09:26:13PM +0200, Jacob Carlborg wrote:
> >>On 2013-10-16 21:23, simendsjo wrote:
> >>
> >>>Yes, sorry. I was thinking about a new __trait and running a loop. Is this when we should be dreaming of the all-powerful AST macros again?
> >>
> >>Yes, AST macros will solve everything :)
> >[...]
> >
> >Including world hunger and world peace. :P
> >
> >
> >T
> 
> "I would change the world, but God won't release the source code" :)

Well even if you have the source code, do you have a way to compile it? :P


T

-- 
Some days you win; most days you lose.

On Wednesday, 16 October 2013 at 20:00:45 UTC, Walter Bright wrote:
> On 10/16/2013 8:37 AM, Sean Kelly wrote:
>> I'm reasonably okay with dynamic languages so long as you can require a
>> variable to be declared before it's used.  Those that implicitly declare on
>> first assignment are a nightmare however. I once spent an entire day
>> debugging a Lua app that turned out to be broken because of a typo in an
>> assignment. Never again.
>
> Implicit declaration is such a bad idea; I wonder why it keeps reappearing in every new dynamic language du jour.

Kind of like null : it is easy to implement.

On Wed, 16 Oct 2013 13:57:50 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Wed, Oct 16, 2013 at 10:48:03PM +0200, Tourist wrote:
> > 
> > "I would change the world, but God won't release the source code" :)
> 
> Well even if you have the source code, do you have a way to compile it? :P
> 

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

On Wed, Oct 16, 2013 at 05:08:38PM -0400, Nick Sabalausky wrote:
> On Wed, 16 Oct 2013 13:57:50 -0700
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> > On Wed, Oct 16, 2013 at 10:48:03PM +0200, Tourist wrote:
> > > 
> > > "I would change the world, but God won't release the source code" :)
> > 
> > Well even if you have the source code, do you have a way to compile it? :P
> > 
> 
> Compiling it shouldn't be a problem:
> http://xkcd.com/224/

Ah but if the code were written in Perl, good luck finding the bugs...


T

-- 
Heads I win, tails you lose.

On Tuesday, October 15, 2013 15:15:45 Walter Bright wrote:
> http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language /ccs8yr8

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). I've never seen static typing as a burden. Rather, it's finding bugs in your program for you.

- Jonathan M Davis

On Wed, Oct 16, 2013 at 10:16:17PM -0400, Jonathan M Davis wrote:
> On Tuesday, October 15, 2013 15:15:45 Walter Bright wrote:
> > http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language /ccs8yr8
> 
> 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;
	}

;-)


> I've never seen static typing as a burden. Rather, it's finding bugs in your program for you.
[...]

I think many people got the false impression of static typing being a burden from historical languages where type annotations have to be explicit all the time. With the advent of type inference, much of this burden has been lifted, and this argument is no longer relevant.


T

-- 
Caffeine underflow. Brain dumped.

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 wrote:
>> On Tuesday, October 15, 2013 15:15:45 Walter Bright wrote:
>> > http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language
>> > /ccs8yr8
>> 
>> 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.

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
> > 
> > wrote:
> >> On Tuesday, October 15, 2013 15:15:45 Walter Bright wrote:
> >> > http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_lan guage /ccs8yr8
> >> 
> >> 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. 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.

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.

- Jonathan M Davis