On Wednesday, 4 June 2014 at 18:14:22 UTC, Adam D. Ruppe wrote:
> On Wednesday, 4 June 2014 at 18:03:48 UTC, Ary Borenszweig wrote:
clip
>
> void main() {
>         var a = 10;
>         var b = "20";
>         b += a;
>         b -= 4;
>         import std.stdio;
>         writeln(b);
>
>         b = [1,2,3];
>         b[0] *= "5";
>         writeln(b);
>
>         b = var.emptyObject;
>         b.foo = (var a) {
>                 foreach(i; 0 .. a.get!int)
>                         writeln("Hello");
>         };
>
>         b.foo()(5); // would be nice if @property worked!
> }
>
> 26
> [5, 2, 3]
> Hello
> Hello
> Hello
> Hello
> Hello
>
>
> Of course, sometimes the type still matters, like the a.get!int in there, but oh well.

But shouldn't the '26' be '1016'?

On Wednesday, 4 June 2014 at 18:37:24 UTC, Craig Dillabaugh wrote:
> But shouldn't the '26' be '1016'?

In javascript it would, but I hate that so I did something more sane: + always coerces both operands to be numbers, then adds them. To get concat, we use the D operator ~.

On Wednesday, 4 June 2014 at 18:29:49 UTC, bearophile wrote:
> Haskell programmers have a very different attitude toward types.

Aye, that's more like how I prefer to do it - I like to use separate types for virtually everything in real code.

On 6/4/14, 2:37 PM, Craig Dillabaugh wrote:
> On Wednesday, 4 June 2014 at 18:14:22 UTC, Adam D. Ruppe wrote:
>> On Wednesday, 4 June 2014 at 18:03:48 UTC, Ary Borenszweig wrote:
> clip
>>
>> void main() {
>>         var a = 10;
>>         var b = "20";
>>         b += a;
>>         b -= 4;
>>         import std.stdio;
>>         writeln(b);
>>
>>         b = [1,2,3];
>>         b[0] *= "5";
>>         writeln(b);
>>
>>         b = var.emptyObject;
>>         b.foo = (var a) {
>>                 foreach(i; 0 .. a.get!int)
>>                         writeln("Hello");
>>         };
>>
>>         b.foo()(5); // would be nice if @property worked!
>> }
>>
>> 26
>> [5, 2, 3]
>> Hello
>> Hello
>> Hello
>> Hello
>> Hello
>>
>>
>> Of course, sometimes the type still matters, like the a.get!int in
>> there, but oh well.
>
> But shouldn't the '26' be '1016'?

That should only occur when the concatenation operator (~) is used, in which case the result would be '2006' not '1016'. Since only arithmetic operators are used in this example, the result is as expected.

On 6/4/2014 2:33 PM, Craig Dillabaugh wrote:
>
> But using function templates and the like you can still get fairly
> 'Python-like' code in D.  I find dealing with types to be one of the
> areas that requires the 'least' amount of mental effort in software
> development. I don't understand why people see 'untyped' languages as
> simpler for the most part.

In my experience, using heavy dynamic typing throughout a program creates far more work (mainly debugging) than it avoids. Even in tiny ~100 line programs, I've spent large amounts of time tracking down bugs a sane compiler would have immediately pointed out with a comparatively negligible amount of my effort spent on typing. Aside from C++ or Java, it's like you say: static types are one of the easiest parts to deal with.

Related note: I find it somewhat amusing (and a little depressing) that you can always identify the inexperienced programers by pulling out the "dynamic creates more debugging work" argument. The inexperienced (or experienced-but-still-sub-par) are always the ones who then try to tell you good programmers are better and more careful at avoiding silly mistakes. :) (And it's often stated using poor typing skills, too.)

Nick Sabalausky:

> In my experience, using heavy dynamic typing throughout a program creates far more work (mainly debugging) than it avoids. Even in tiny ~100 line programs, I've spent large amounts of time tracking down bugs a sane compiler would have immediately pointed out with a comparatively negligible amount of my effort spent on typing.

I think often this happens because you are trying to write Python/Ruby code like you are using C++/Java, you assume the compiler will catch certain kinds of bugs. If you write Python with the kind of coding Python requires, taking more care of the things the Python interpreter is not able to spot for you, you will use much less time to debug Python code, and the overall coding time will be quite low. In Python you write 2-3 lines of tests every 1 line of code, and you test every functions for the corner cases you can think of. You don't write more than few 3-6 lines of code without testing them immediately. So for certain aspects you need more discipline to write Python, while for other things it needs less. For small and medium programs this leads to sufficiently correct Python code :-) It's usually quite hard to explain such differences in coding stile to people that are used to static typing.

Bye,
bearophile

On Wednesday, 4 June 2014 at 19:43:53 UTC, bearophile wrote:
> Nick Sabalausky:
>
>> In my experience, using heavy dynamic typing throughout a program creates far more work (mainly debugging) than it avoids. Even in tiny ~100 line programs, I've spent large amounts of time tracking down bugs a sane compiler would have immediately pointed out with a comparatively negligible amount of my effort spent on typing.
>
> I think often this happens because you are trying to write Python/Ruby code like you are using C++/Java, you assume the compiler will catch certain kinds of bugs. If you write Python with the kind of coding Python requires, taking more care of the things the Python interpreter is not able to spot for you, you will use much less time to debug Python code, and the overall coding time will be quite low. In Python you write 2-3 lines of tests every 1 line of code, and you test every functions for the corner cases you can think of. You don't write more than few 3-6 lines of code without testing them immediately. So for certain aspects you need more discipline to write Python, while for other things it needs less. For small and medium programs this leads to sufficiently correct Python code :-) It's usually quite hard to explain such differences in coding stile to people that are used to static typing.
>
> Bye,
> bearophile

I hear this concept again and again, still can't really get it. You are trying to save some tiny portion of time of writing down actual type to spend much more time in different mental context to write several lines of tests to achieve exactly the same thing? How can this ever be a reasonable trade-off?

On 6/4/14, 3:33 PM, Craig Dillabaugh wrote:
> On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote:
>> On 6/4/14, 1:27 PM, Meta wrote:
>>> On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote:
>>>> http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/
>>>>
>>>>
>>>>
>>>> Andrei
>>>
>>> When that person made the statement about expressing his mental model in
>>> a simpler way that is still somewhat fast, and then optimizing/adding
>>> annotations/etc. after he gets it working, I kept expecting you to
>>> mention RDMD and D's ability to be used for scripting, and
>>> purity/nothrow/@safe/@nogc inference. This is an advantage D has over
>>> Rust and C++. With Rust especially, there is no way to avoid dealing
>>> with its pointer semantics, as they permeate the language. With D, you
>>> can write in a C or even Python-like way (while not having to worry
>>> about ownership, memory, etc. as the GC handles it for you), but you can
>>> then optimize and add annotations to your code to get a lot more
>>> performance and safety once your initial implementation is working.
>>
>> You still have to worry about types, though.
>
> But using function templates and the like you can still get fairly
> 'Python-like' code in D.  I find dealing with types to be one of the
> areas that requires the 'least' amount of mental effort in software
> development. I don't understand why people see 'untyped' languages as
> simpler for the most part.

I was actually talking about having to specify types everywhere, like in function signatures, the fields of classes and structs, etc.

You can still have a language that feels dynamic but is statically typed. The compiler catches type-related bugs for you, and you can prototype something very fast. Then you can add type annotations (if you want). I wouldn't say this language is 'untyped'.

One such language is Julia.

On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig wrote:
> I was actually talking about having to specify types everywhere, like in function signatures, the fields of classes and structs, etc.
>
> You can still have a language that feels dynamic but is statically typed. The compiler catches type-related bugs for you, and you can prototype something very fast. Then you can add type annotations (if you want). I wouldn't say this language is 'untyped'.
>
> One such language is Julia.

Another is Haskell, a language with very strong typing.

On Wednesday, 4 June 2014 at 18:54:00 UTC, Andrew Edwards wrote:
> On 6/4/14, 2:37 PM, Craig Dillabaugh wrote:
>> On Wednesday, 4 June 2014 at 18:14:22 UTC, Adam D. Ruppe wrote:
>>> On Wednesday, 4 June 2014 at 18:03:48 UTC, Ary Borenszweig wrote:
clip
>>
>> But shouldn't the '26' be '1016'?
>
> That should only occur when the concatenation operator (~) is used, in which case the result would be '2006' not '1016'. Since only arithmetic operators are used in this example, the result is as expected.

I must be dyslexic .. I concatenated in the wrong way, and you (and Adam) are both right about the ~ operator in D.   However, my primary point was that adding a string to a number is really an 'undefined' operation.  So I don't think such automatic casting is (generally) helpful.