www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Interview at Lang.NEXT

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/

Andrei
Jun 03 2014
next sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
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/


wtf, the "Mid Quality" video is 1280x720 resolution HD video, 
guess they think every programmer has a super-fast internet 
connection. ;) The mp4 for Android/iPhone is a bandwidth-friendly 
640x360 resolution.
Jun 04 2014
next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Wed, 04 Jun 2014 07:33:01 +0000
Joakim via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> 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/


 wtf, the "Mid Quality" video is 1280x720 resolution HD video,
 guess they think every programmer has a super-fast internet
 connection. ;) The mp4 for Android/iPhone is a bandwidth-friendly
 640x360 resolution.


Well, regardless of the internet connection speeds, I would have considered
720p to be "mid quality," but I work with video for a living and tend to be a
bit of a videophile. Between work and doing stuff like messing with encoding
settings for transcoding Blu-rays, I've pretty much been ruined. I practically
can't watch DVDs anymore, and even Blu-rays frequently look pretty bad to me.

But obviously, streaming high quality video over the internet can be expensive
(and networks tend to behave badly even when you're just streaming a lot of
video locally).

- Jonathan M Davis
Jun 04 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/4/14, 9:33 AM, Joakim 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/


 wtf, the "Mid Quality" video is 1280x720 resolution HD video, guess they
 think every programmer has a super-fast internet connection. ;) The mp4
 for Android/iPhone is a bandwidth-friendly 640x360 resolution.


FWIW I'm not sure high resolution is necessary or recommended when 
watching me :o). -- Andrei
Jun 04 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/4/2014 2:08 AM, Andrei Alexandrescu wrote:

 FWIW I'm not sure high resolution is necessary or recommended when watching me
 :o). -- Andrei



I look better at low res.
Jun 04 2014
prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
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


I never post on Reddit myself, but I noticed the guy asking about 
Qt ports. Someone else can tell him about my work on DQt if they 
want. My big annoyance on that at the moment is recreating the 
output of moc in D, which is something I've been putting off 
doing for more fun things (like the dlang.org redesign recently.)
Jun 04 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/4/2014 4:27 AM, w0rp 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


 I never post on Reddit myself, but I noticed the guy asking about Qt ports.
 Someone else can tell him about my work on DQt if they want. My big annoyance
on
 that at the moment is recreating the output of moc in D, which is something
I've
 been putting off doing for more fun things (like the dlang.org redesign
recently.)


Write here what you want to say, including links to your work, and I'll post it 
for you.
Jun 04 2014
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
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.
Jun 04 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Jun 04 2014
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote:

 You still have to worry about types, though.


Yes, but you can often get away without explicitly writing types 
in D, and there's always std.variant.Variant when you don't want 
to bother with them.
Jun 04 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Meta:


 and there's always std.variant.Variant when you don't want to 
 bother with them.


How many good usages of D Variant do you know?

Bye,
bearophile
Jun 04 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 4 June 2014 at 17:55:15 UTC, bearophile wrote:

 How many good usages of D Variant do you know?

 Bye,
 bearophile


It depends on what you mean by a good usage. I rarely ever use 
Variant, but you *can* use it if you need weak and/or dynamic 
typing.
Jun 04 2014
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 04.06.2014 19:57, schrieb Meta:

 On Wednesday, 4 June 2014 at 17:55:15 UTC, bearophile wrote:

 How many good usages of D Variant do you know?

 Bye,
 bearophile


 It depends on what you mean by a good usage. I rarely ever use
 Variant, but you *can* use it if you need weak and/or dynamic
 typing.


but D+Variant is still far away from an untyped language - because
everything needs to be based on Variant - every signature... so
it isn't an ~"correct"~ solution in this context
Jun 04 2014
parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 4 June 2014 at 18:01:04 UTC, dennis luehring wrote:

 Am 04.06.2014 19:57, schrieb Meta:

 On Wednesday, 4 June 2014 at 17:55:15 UTC, bearophile wrote:

 How many good usages of D Variant do you know?

 Bye,
 bearophile


 It depends on what you mean by a good usage. I rarely ever use
 Variant, but you *can* use it if you need weak and/or dynamic
 typing.


 but D+Variant is still far away from an untyped language - 
 because
 everything needs to be based on Variant - every signature... so
 it isn't an ~"correct"~ solution in this context


You're right, but you can get fairly close. You will never be 
able to completely forget about types in D.
Jun 04 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/4/14, 2:50 PM, Meta wrote:

 On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote:

 You still have to worry about types, though.


 Yes, but you can often get away without explicitly writing types in D,
 and there's always std.variant.Variant when you don't want to bother
 with them.


Even in function signatures?
Jun 04 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 4 June 2014 at 17:57:40 UTC, Ary Borenszweig wrote:

 Even in function signatures?


alias var = std.variant.Variant;

auto DoStuff(var x, var y)
{
     //Do stuff with x and y
}
Jun 04 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/4/14, 2:59 PM, Meta wrote:

 On Wednesday, 4 June 2014 at 17:57:40 UTC, Ary Borenszweig wrote:

 Even in function signatures?


 alias var = std.variant.Variant;

 auto DoStuff(var x, var y)
 {
      //Do stuff with x and y
 }


Cool! It also looks nice too.
Jun 04 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 4 June 2014 at 18:03:48 UTC, Ary Borenszweig wrote:

 Cool! It also looks nice too.


you should check out my jsvar too

https://github.com/adamdruppe/arsd/blob/master/jsvar.d

weak typing and dynamic like javascript:

import arsd.jsvar;

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.
Jun 04 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 Of course, sometimes the type still matters,


Haskell programmers have a very different attitude toward types. 
They do a kind of type-driven programming, even in small 
programs. They lay down the data types (like the algebraic data 
types that describe the data structures of the problem), and then 
let the compiler, the type errors (and even a recent feature of 
the compiler named type holes) to write down the solutions and be 
guided toward correct code. This is kind of the opposite of 
trying to remove types using dynamic typing, and it's also far 
from the kind of strong static typing you see in Ada language.

Bye,
bearophile
Jun 04 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jun 04 2014
prev sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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'?
Jun 04 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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 ~.
Jun 04 2014
prev sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Jun 04 2014
parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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.
Jun 04 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 4 June 2014 at 21:02:21 UTC, Craig Dillabaugh wrote:

 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.


Yeah, I'm generally against it... but I have a weird view of 
typing.

The way I see it, you should go either strong and static or 
dynamic and weak - I hate the middle ground.

So, in my view:

Best (like D):
string a = "10"; int b = 20;
a + b; // compile time error: cannot do string + int

Sometimes ok (my jsvar/script language also PHP and some others):
var a = "10"; var b = 20;
a + b; // 30

Blargh (javascript):
var a = "10"; var b = 20;
a + b; // "1020"

Hatred:
var a = "10"; var b = 20;
a + b; // throws an exception at run time



The D one is best because it draws your attention to something 
that is imperfect immediately and reliably via a compilation 
error. Then you can solve it with to!int or
whatever easily.

The weak+dynamic is passable to me because it actually mostly 
works. The operator you choose coerces the arguments and gives 
something basically usable. I'd be ok if it
threw an exception in the case of a string that cannot be sanely 
converted to int, but if it can be made to work, just do it.

The javascript one is blargh just because + is overloaded, making 
it easy to accidentally do the wrong thing (this just bit me in a 
real world code thing like 20
minutes ago, coincidentally). But I still prefer it to the last 
one..

Which cares about the types enough to throw an exception, but 
makes you wait for runtime to tell you about it. Pain in the butt 
that leads to fragile code that just
breaks a lot.


For example, one version of a library returns numbers typed as 
strings so you do some string stuff on them... then the next 
version returns them typed as numbers and
the old string concat pieces now randomly break next time you run 
it.

Pain! If I need to know what the type is anyway, please just give 
me a compiler to catch this stuff.

Alas, the latter model is what Ruby and Python do :(
Jun 04 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 4 June 2014 at 22:02:37 UTC, Adam D. Ruppe wrote:

 Yeah, I'm generally against it... but I have a weird view of 
 typing.

 The way I see it, you should go either strong and static or 
 dynamic and weak - I hate the middle ground.

 So, in my view:

 Best (like D):
 string a = "10"; int b = 20;
 a + b; // compile time error: cannot do string + int

 Sometimes ok (my jsvar/script language also PHP and some 
 others):
 var a = "10"; var b = 20;
 a + b; // 30

 Blargh (javascript):
 var a = "10"; var b = 20;
 a + b; // "1020"

 Hatred:
 var a = "10"; var b = 20;
 a + b; // throws an exception at run time


Yup, you choose the right tradeoff. I wish std.json has something
in the same style as our jsvar.


 The D one is best because it draws your attention to something 
 that is imperfect immediately and reliably via a compilation 
 error. Then you can solve it with to!int or
 whatever easily.

 The weak+dynamic is passable to me because it actually mostly 
 works. The operator you choose coerces the arguments and gives 
 something basically usable. I'd be ok if it
 threw an exception in the case of a string that cannot be 
 sanely converted to int, but if it can be made to work, just do 
 it.


We all have to handle JSON or XML or some other thing like that
at some point. When it come to these, having variant typing is
huge for ease of use.
Jun 06 2014
prev sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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.
Jun 04 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.)
Jun 04 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jun 04 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
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?
Jun 04 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/4/2014 3:43 PM, 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 :-)


So let me get this straight: There are programmers out there who find 
the occasional type annotations on some declarations to be significantly 
more work than following a convention of nearly *quadrupling* the amount 
of code they have to write? Two to three lines of tests for every one 
line of real code is considered rapid development, "saving developer 
time", "just getting things done", etc? And all that's considered a 
"style" of coding?

You're right, I really don't understand that style of coding at all. ;)

Don't get me wrong, I am pretty big on unittests, but even still: If 
people are trying to save developer time by replacing each minor type 
annotation with several extra unittests (which are less reliable anyway 
- greater room for human error), then something's gone horribly wrong.


 It's usually quite hard to explain such
 differences in coding stile to people that are used to static typing.


That doesn't surprise me. It's also very difficult to explain 2+2==5 to 
people who are accustomed to basic arithmetic. ;)
Jun 04 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/5/14, 7:59 AM, Nick Sabalausky wrote:

 So let me get this straight: There are programmers out there who find
 the occasional type annotations on some declarations to be significantly
 more work than following a convention of nearly *quadrupling* the amount
 of code they have to write? Two to three lines of tests for every one
 line of real code is considered rapid development, "saving developer
 time", "just getting things done", etc? And all that's considered a
 "style" of coding?

 You're right, I really don't understand that style of coding at all. ;)

 Don't get me wrong, I am pretty big on unittests, but even still: If
 people are trying to save developer time by replacing each minor type
 annotation with several extra unittests (which are less reliable anyway
 - greater room for human error), then something's gone horribly wrong.

  > It's usually quite hard to explain such
  > differences in coding stile to people that are used to static typing.
  >

 That doesn't surprise me. It's also very difficult to explain 2+2==5 to
 people who are accustomed to basic arithmetic. ;)


I have to confess this echoes a few similar confusions I have about the 
use and advocacy of dynamically-typed languages. One argument I've heard 
a while back was that static type errors are not "proportional response" 
and that static types only detect the most trivial of bugs, so why 
bother at all. But then the heavy-handed approach to unittesting 
espoused by dynamic languages, of which arguably a good part would be 
automated by a static type system, seems to work against that argument.


Andrei
Jun 05 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-05 09:30, Andrei Alexandrescu wrote:


 I have to confess this echoes a few similar confusions I have about the
 use and advocacy of dynamically-typed languages. One argument I've heard
 a while back was that static type errors are not "proportional response"
 and that static types only detect the most trivial of bugs, so why
 bother at all. But then the heavy-handed approach to unittesting
 espoused by dynamic languages, of which arguably a good part would be
 automated by a static type system, seems to work against that argument.


Since the software we write today is so complex, even detecting the most 
trivial bugs are useful. We need every help we can get.

-- 
/Jacob Carlborg
Jun 05 2014
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Thu, 05 Jun 2014 09:30:44 +0200
Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:


 On 6/5/14, 7:59 AM, Nick Sabalausky wrote:

 So let me get this straight: There are programmers out there who
 find the occasional type annotations on some declarations to be
 significantly more work than following a convention of nearly
 *quadrupling* the amount of code they have to write? Two to three
 lines of tests for every one line of real code is considered rapid
 development, "saving developer time", "just getting things done",
 etc? And all that's considered a "style" of coding?

 You're right, I really don't understand that style of coding at
 all. ;)

 Don't get me wrong, I am pretty big on unittests, but even still: If
 people are trying to save developer time by replacing each minor
 type annotation with several extra unittests (which are less
 reliable anyway
 - greater room for human error), then something's gone horribly
 wrong.

  > It's usually quite hard to explain such
  > differences in coding stile to people that are used to static
  > typing.
  >

 That doesn't surprise me. It's also very difficult to explain
 2+2==5 to people who are accustomed to basic arithmetic. ;)


 I have to confess this echoes a few similar confusions I have about
 the use and advocacy of dynamically-typed languages. One argument
 I've heard a while back was that static type errors are not
 "proportional response" and that static types only detect the most
 trivial of bugs, so why bother at all. But then the heavy-handed
 approach to unittesting espoused by dynamic languages, of which
 arguably a good part would be automated by a static type system,
 seems to work against that argument.


Indeed. It just makes no sense to claim that using dynamic typing is simpler
and easier when you're then forced to write a bunch of test code just to catch
bugs that the compiler in a statically typed language would have caught for
you anyway.

Though I confess what horrifies me the most about dynamic languages is code
like this

if(cond)
    var = "hello world";
else
    var = 42;

The fact that an if statement could change the type of a variable is just
atrocious IMHO. Maybe I've just spent too much of my time in statically typed
languages, but I just do not understand the draw that dynamically typed
languages have for some people. They seem to think that avoiding a few simple
things that you have to do in your typical statically typed language is
somehow a huge improvement when it causes them so many serious problems that
static languages just don't have.

- Jonathan M Davis
Jun 05 2014
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 05.06.2014 11:42, schrieb Jonathan M Davis via Digitalmars-d-announce:

 if(cond)
      var = "hello world";
 else
      var = 42;

 The fact that an if statement could change the type of a variable is just
 atrocious IMHO. Maybe I've just spent too much of my time in statically typed
 languages, but I just do not understand the draw that dynamically typed
 languages have for some people. They seem to think that avoiding a few simple
 things that you have to do in your typical statically typed language is
 somehow a huge improvement when it causes them so many serious problems that
 static languages just don't have.


maybe some sort of misunderstanded generic style
of programming in prior D times :)
Jun 05 2014
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 5 June 2014 at 09:43:13 UTC, Jonathan M Davis via 
Digitalmars-d-announce wrote:

 On Thu, 05 Jun 2014 09:30:44 +0200
 Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:


 On 6/5/14, 7:59 AM, Nick Sabalausky wrote:

 So let me get this straight: There are programmers out there 
 who
 find the occasional type annotations on some declarations to 
 be
 significantly more work than following a convention of nearly
 *quadrupling* the amount of code they have to write? Two to 
 three
 lines of tests for every one line of real code is considered 
 rapid
 development, "saving developer time", "just getting things 
 done",
 etc? And all that's considered a "style" of coding?

 You're right, I really don't understand that style of coding 
 at
 all. ;)

 Don't get me wrong, I am pretty big on unittests, but even 
 still: If
 people are trying to save developer time by replacing each 
 minor
 type annotation with several extra unittests (which are less
 reliable anyway
 - greater room for human error), then something's gone 
 horribly
 wrong.

  > It's usually quite hard to explain such
  > differences in coding stile to people that are used to 
 static
  > typing.
  >

 That doesn't surprise me. It's also very difficult to explain
 2+2==5 to people who are accustomed to basic arithmetic. ;)


 I have to confess this echoes a few similar confusions I have 
 about
 the use and advocacy of dynamically-typed languages. One 
 argument
 I've heard a while back was that static type errors are not
 "proportional response" and that static types only detect the 
 most
 trivial of bugs, so why bother at all. But then the 
 heavy-handed
 approach to unittesting espoused by dynamic languages, of which
 arguably a good part would be automated by a static type 
 system,
 seems to work against that argument.


 Indeed. It just makes no sense to claim that using dynamic 
 typing is simpler
 and easier when you're then forced to write a bunch of test 
 code just to catch
 bugs that the compiler in a statically typed language would 
 have caught for
 you anyway.

 Though I confess what horrifies me the most about dynamic 
 languages is code
 like this

 if(cond)
     var = "hello world";
 else
     var = 42;

 The fact that an if statement could change the type of a 
 variable is just
 atrocious IMHO. Maybe I've just spent too much of my time in 
 statically typed
 languages, but I just do not understand the draw that 
 dynamically typed
 languages have for some people. They seem to think that 
 avoiding a few simple
 things that you have to do in your typical statically typed 
 language is
 somehow a huge improvement when it causes them so many serious 
 problems that
 static languages just don't have.

 - Jonathan M Davis


No, it's not just that you're statically-minded. Your example 
above is definitely atrocious, and more often than not a bug.

I don't know, but the only language I've used with no static 
types that made me comfortable was Common Lisp. That was a long 
time ago, but I think it was the ease of manually testing the 
code in a REPL that did it. Obviously today I'd write unit tests 
anyway.

Atila
Jun 05 2014
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Thursday, 5 June 2014 at 12:46:24 UTC, Atila Neves wrote:

 I don't know, but the only language I've used with no static 
 types that made me comfortable was Common Lisp. That was a long 
 time ago, but I think it was the ease of manually testing the 
 code in a REPL that did it. Obviously today I'd write unit 
 tests anyway.

 Atila



Scala, to name a few) that have REPLs as well, and they're quite 
useful there too.

I'm fond of Lisp, and I think Lisp macros are very powerful and 
useful. I like Python's (really ISWIM's) indentation sensitive 
syntax. But, as someone who uses 'dynamically typed' languages 
daily, I think static typing is a huge win and don't understand 
why anyone would not want to use a language with static types, 
especially if they were mostly inferred and so the annotation 
burden was minimal. ML is the language of the future ;-)
Jun 05 2014
next sibling parent Bill Baxter via Digitalmars-d-announce writes:
On Thu, Jun 5, 2014 at 6:34 AM, Brian Rogoff via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


  ML is the language of the future ;-)


Yeh, it hasn't really caught on in the first 40 years since it was
invented, but I'm sure it's about to explode any day now.  :-)

--bb
Jun 05 2014
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 5 June 2014 at 13:34:03 UTC, Brian Rogoff wrote:

 On Thursday, 5 June 2014 at 12:46:24 UTC, Atila Neves wrote:

 I don't know, but the only language I've used with no static 
 types that made me comfortable was Common Lisp. That was a 
 long time ago, but I think it was the ease of manually testing 
 the code in a REPL that did it. Obviously today I'd write unit 
 tests anyway.

 Atila



 Scala, to name a few) that have REPLs as well, and they're 
 quite useful there too.


Oh, I know. There's also this: http://drepl.dawg.eu/

My point was that, way back when nearly 20 years ago, manually 
testing the Common Lisp code I wrote one function at a time was 
probably the reason I was ok with not having static types. I'm 
not even sure I'd feel the same way now.


 I'm fond of Lisp, and I think Lisp macros are very powerful and 
 useful. I like Python's (really ISWIM's) indentation sensitive 
 syntax. But, as someone who uses 'dynamically typed' languages 
 daily, I think static typing is a huge win and don't understand 
 why anyone would not want to use a language with static types, 
 especially if they were mostly inferred and so the annotation 
 burden was minimal. ML is the language of the future ;-)


Yep, inferred types are a massive win in my book. Having to 
explicitly write types whenever I have the misfortune of writing 
C or old C++ is painful after C++11, D, and the very little 
Haskell I've done so far.

Atila
Jun 05 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 5 June 2014 at 09:43:13 UTC, Jonathan M Davis via 
Digitalmars-d-announce wrote:

 if(cond)
     var = "hello world";
 else
     var = 42;


I've sometimes wished for this functionality. It's not even a big 
deal in a statically typed language with built-in algebraic types 
and flow-based typing. The type of var is just String|Integer, 
and you have to disambiguate before you use its value.
Jun 05 2014
prev sibling parent "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Thursday, 5 June 2014 at 09:43:13 UTC, Jonathan M Davis via 
Digitalmars-d-announce wrote:

 Though I confess what horrifies me the most about dynamic 
 languages is code
 like this

 if(cond)
     var = "hello world";
 else
     var = 42;

 The fact that an if statement could change the type of a 
 variable is just
 atrocious IMHO. Maybe I've just spent too much of my time in 
 statically typed
 languages, but I just do not understand the draw that 
 dynamically typed
 languages have for some people. They seem to think that 
 avoiding a few simple
 things that you have to do in your typical statically typed 
 language is
 somehow a huge improvement when it causes them so many serious 
 problems that
 static languages just don't have.

 - Jonathan M Davis


Wouldn't static-if accomplish much of the same?

```
static if (cond)
     auto var = "hello world";
else
     auto var = 42;
```

I understand it is horrible, and unexperienced programmers often 
make the mistaken of forgetting the definition of var in the 
*else* condition, while painstakingly try to use it *after* it.

Now the first time I saw `auto`, in D or C++, I was horrified. 
But in essence it is a move towards not having to think about the 
type, or in other cases having to actually type it out, but just 
have the compiler infer it auto-matically. A dynamic language is 
just having auto everywhere without having to type even that, and 
giving up compile time type checking in turn.

On the other hand, some dynamic languages allow you to restict a 
variable entering a function by its type. In essence, I see both 
static and dynamic languages trying to meet in the middle.

The middle ground is the idea that data has a type and a variable 
is just a reference to some data; a way for use humans to express 
data flow. In other words, relying more on compile-time type 
inference.

That is the direction I see in general; programmers more and more 
relying on tools and analysers to do their work.
Jul 01 2014
prev sibling next sibling parent reply Bill Baxter via Digitalmars-d-announce writes:
On Thu, Jun 5, 2014 at 2:42 AM, Jonathan M Davis via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:


 Though I confess what horrifies me the most about dynamic languages is code
 like this

 if(cond)
     var = "hello world";
 else
     var = 42;

 The fact that an if statement could change the type of a variable is just
 atrocious IMHO.



Yeh, that's possible, but that doesn't look like something anyone with any
sense would do.

The things I found most enjoyable about working on javascript were
1) REPL / fully interactive debugger
    When you hit a break point you can just start typing regular js code
into the console to poke the state of your system.
    And the convenience of the REPL for seeing what bits of code do as you
write them.
2) Duck typing / introspection ability
    If you have a bunch of objects that have a .width property, and that's
all you care about, you can just look for that.  No need to declare an
IWidthHaver interface and make all of your objects declare that they
implement it.
3) Relative ease of writing tests
    We used the Closure compiler for the js I worked on, so it wasn't
totally wild west.  It has a fair amount of static type checking.
    But when it comes to tests, it's very convenient to just be able to
fake any object by slapping some dummy functions in between curly braces.
 For example if I want a fake "IWidthHaver" instance, I just have to write
x = { width: 10 }, and I'm done.  Plus I can monkey patch things in tests,
replacing whatever method I want with a wrapper that does some custom
monitoring before or after calling the real method.  Writing tests for C++
is a pain in the butt in comparison.

--bb
Jun 05 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2014 6:31 AM, Bill Baxter via Digitalmars-d-announce wrote:

      But when it comes to tests, it's very convenient to just be able to fake
 any object by slapping some dummy functions in between curly braces.  For
 example if I want a fake "IWidthHaver" instance, I just have to write x = {
 width: 10 }, and I'm done.  Plus I can monkey patch things in tests, replacing
 whatever method I want with a wrapper that does some custom monitoring before
or
 after calling the real method.  Writing tests for C++ is a pain in the butt in
 comparison.


It's an interesting observation. It is why the functions in Warp are nearly all 
templates - so I can slap together dummy objects to unittest those functions.
Jun 05 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-05 15:31, Bill Baxter via Digitalmars-d-announce wrote:

 On Thu, Jun 5, 2014 at 2:42 AM, Jonathan M Davis via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>> wrote:


     Though I confess what horrifies me the most about dynamic languages
     is code
     like this

     if(cond)
          var = "hello world";
     else
          var = 42;

     The fact that an if statement could change the type of a variable is
     just
     atrocious IMHO.


 Yeh, that's possible, but that doesn't look like something anyone with
 any sense would do.

 The things I found most enjoyable about working on javascript were
 1) REPL / fully interactive debugger
      When you hit a break point you can just start typing regular js
 code into the console to poke the state of your system.
      And the convenience of the REPL for seeing what bits of code do as
 you write them.
 2) Duck typing / introspection ability
      If you have a bunch of objects that have a .width property, and
 that's all you care about, you can just look for that.  No need to
 declare an IWidthHaver interface and make all of your objects declare
 that they implement it.
 3) Relative ease of writing tests
      We used the Closure compiler for the js I worked on, so it wasn't
 totally wild west.  It has a fair amount of static type checking.
      But when it comes to tests, it's very convenient to just be able to
 fake any object by slapping some dummy functions in between curly
 braces.  For example if I want a fake "IWidthHaver" instance, I just
 have to write x = { width: 10 }, and I'm done.  Plus I can monkey patch
 things in tests, replacing whatever method I want with a wrapper that
 does some custom monitoring before or after calling the real method.
   Writing tests for C++ is a pain in the butt in comparison.


In D you can use a wrapper and opDispatch to delegate and intercept 
method calls.

-- 
/Jacob Carlborg
Jun 05 2014
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 5 June 2014 at 13:32:16 UTC, Bill Baxter via 
Digitalmars-d-announce wrote:

 On Thu, Jun 5, 2014 at 2:42 AM, Jonathan M Davis via 
 Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:


 Though I confess what horrifies me the most about dynamic 
 languages is code
 like this

 if(cond)
     var = "hello world";
 else
     var = 42;

 The fact that an if statement could change the type of a 
 variable is just
 atrocious IMHO.



 Yeh, that's possible, but that doesn't look like something 
 anyone with any
 sense would do.

 The things I found most enjoyable about working on javascript 
 were
 1) REPL / fully interactive debugger
     When you hit a break point you can just start typing 
 regular js code
 into the console to poke the state of your system.
     And the convenience of the REPL for seeing what bits of 
 code do as you
 write them.


That's an advantage of an interpreted language, regardless of 
typing.


 2) Duck typing / introspection ability
     If you have a bunch of objects that have a .width property, 
 and that's
 all you care about, you can just look for that.  No need to 
 declare an
 IWidthHaver interface and make all of your objects declare that 
 they
 implement it.



D's ranges are examples of this in a statically typed language. 
You don't care what the type of the range is, just so long as it 
has the right api.
Jun 06 2014
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 05/06/2014 08:30, Andrei Alexandrescu wrote:

 On 6/5/14, 7:59 AM, Nick Sabalausky wrote:

 So let me get this straight: There are programmers out there who find
 the occasional type annotations on some declarations to be significantly
 more work than following a convention of nearly *quadrupling* the amount
 of code they have to write? Two to three lines of tests for every one
 line of real code is considered rapid development, "saving developer
 time", "just getting things done", etc? And all that's considered a
 "style" of coding?

 You're right, I really don't understand that style of coding at all. ;)

 Don't get me wrong, I am pretty big on unittests, but even still: If
 people are trying to save developer time by replacing each minor type
 annotation with several extra unittests (which are less reliable anyway
 - greater room for human error), then something's gone horribly wrong.

  > It's usually quite hard to explain such
  > differences in coding stile to people that are used to static typing.
  >

 That doesn't surprise me. It's also very difficult to explain 2+2==5 to
 people who are accustomed to basic arithmetic. ;)


 I have to confess this echoes a few similar confusions I have about the
 use and advocacy of dynamically-typed languages. One argument I've heard
 a while back was that static type errors are not "proportional response"
 and that static types only detect the most trivial of bugs, so why
 bother at all. But then the heavy-handed approach to unittesting
 espoused by dynamic languages, of which arguably a good part would be
 automated by a static type system, seems to work against that argument.


 Andrei


Dicebot, Nick, Andrei: my thoughts exactly. And I get a lot of that, 
since my main development language (career-wise) is Java, which dynamic 
language proponents like to bash for it's verbosity (yes, it's more 
verbose that it needs to be, but still way better than a dynamic 
language having to write all those tests!)

I sometimes tried to convince dynamic language proponents - the ones 
that write unittests at least - of the benefits of static typing, by 
stating that static typing is really just "compile time unit-tests"! (it 
is actually)

It didn't work, they didn't get it...

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 16 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/16/2014 10:00 AM, Bruno Medeiros wrote:

 Java, which dynamic
 language proponents like to bash for it's verbosity


Static language proponents like to bash Java for its verbosity, too!
Jun 16 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 16/06/14 16:00, Bruno Medeiros wrote:


 I sometimes tried to convince dynamic language proponents - the ones
 that write unittests at least - of the benefits of static typing, by
 stating that static typing is really just "compile time unit-tests"! (it
 is actually)


You can actually do compile time unit tests in D, that is not the type 
system. I.e. unit tests for CTFE functions that runs at compile time. 
Pretty cool actually :)

-- 
/Jacob Carlborg
Jun 16 2014
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 17/06/2014 07:21, Jacob Carlborg wrote:

 On 16/06/14 16:00, Bruno Medeiros wrote:


 I sometimes tried to convince dynamic language proponents - the ones
 that write unittests at least - of the benefits of static typing, by
 stating that static typing is really just "compile time unit-tests"! (it
 is actually)


 You can actually do compile time unit tests in D, that is not the type
 system. I.e. unit tests for CTFE functions that runs at compile time.
 Pretty cool actually :)


I know, pretty cool yeah. But specific to D, I was talking about static 
typing in general.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 20 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 to three lines of tests for every one line of real code is 
 considered rapid development,


My Python development is just development, it's not meant to be 
particularly rapid :-)

And I don't think a 3:1 ratio is too much. Among the testing code 
I also count the doctests, the unittests, the other tests at 
higher level, the logic tests done with the Python version of 
QuickCheck, the contracts, the class/module invariants, the loop 
invariants, and the safety asserts spread in the code.

Take a look at this:
http://www.sqlite.org/testing.html


As of version 3.8.0, the SQLite library consists of 
approximately 84.3 KSLOC of C code. (KSLOC means thousands of 
"Source Lines Of Code" or, in other words, lines of code 
excluding blank lines and comments.) By comparison, the project 
has 1084 times as much test code and test scripts - 91452.5 
KSLOC.<


In my D code I have an average 2.5 lines of testing code or every 
1 line of D code, probably thanks to the stronger typing of D 
(and I think my D/Python code is less buggy than Phobos).

Bye,
bearophile
Jun 05 2014
parent reply "Burp" <brpy yahoo.com> writes:
  bearophile-

  Do you also have so much testing code in haskell?


 In my D code I have an average 2.5 lines of testing code or 
 every 1 line of D code, probably thanks to the stronger typing 
 of D (and I think my D/Python code is less buggy than Phobos).

 Bye,
 bearophile
Jun 07 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Burp:


  Do you also have so much testing code in haskell?


I am still a newbie in Haskell, so my Haskell usage patterns are 
not significant (but if you still want an answer: from what I've 
seen so far I need so much time and thinking to craft every 
single line of Haskell code that later tests are less needed).

Bye,
bearophile
Jun 07 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-04 21:30, Nick Sabalausky wrote:


 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.


Yeah, static typing can be a huge advantage. Currently I'm merging the 
latest changes in DMD to my D/Objective-C branch. I have no idea what 
I'm doing and fully rely on the compiler. No way in h*ll I would even 
think about doing that without static typing.

-- 
/Jacob Carlborg
Jun 05 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Jun 04 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
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.
Jun 04 2014
prev sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig wrote:

 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:








clip


 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.


OK, but my point was that specifying the type (at least for me) 
takes an insignificant amount of time (and is very useful months 
down the road when I am looking at the code, trying to figure out 
what it is supposed to do).

When declaring a variable, in almost every case, figuring out the 
proper type, and writing that type takes a fraction of a second.

I brought up templates because I figured one objection to my 
claim would be that it is easier to write functions in Python 
because you don't have to specify a type.  D templates take a bit 
more work, but for simple tasks (like you would commonly have in 
a scripting situtation) they should be about as simple as their 
Python equivalents.
Jun 04 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/4/14, 6:11 PM, Craig Dillabaugh wrote:

 On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig wrote:

 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:








 clip


 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.


 OK, but my point was that specifying the type (at least for me) takes an
 insignificant amount of time (and is very useful months down the road
 when I am looking at the code, trying to figure out what it is supposed
 to do).

 When declaring a variable, in almost every case, figuring out the proper
 type, and writing that type takes a fraction of a second.


The problem comes when you need to refactor your code and swap one type 
for another. You have to change all ocurrences of that type in that 
situation for another.
Jun 04 2014
next sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Wed, Jun 04, 2014 at 19:13:32 -0300, Ary Borenszweig via
Digitalmars-d-announce wrote:

 The problem comes when you need to refactor your code and swap one type 
 for another. You have to change all ocurrences of that type in that 
 situation for another.


That's what polymorphism and type inference is for. In Haskell at least,
you rarely need to actually put types in to your source. Usually you
decorate top-level API functions to make sure you got it right and for
making figuring out what the type of an argument is though. And those
types shouldn't be changing all that often.

--Ben
Jun 04 2014
prev sibling parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Wednesday, 4 June 2014 at 22:13:33 UTC, Ary Borenszweig wrote:

 On 6/4/14, 6:11 PM, Craig Dillabaugh wrote:

 On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig 
 wrote:

 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:








 clip


 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.


 OK, but my point was that specifying the type (at least for 
 me) takes an
 insignificant amount of time (and is very useful months down 
 the road
 when I am looking at the code, trying to figure out what it is 
 supposed
 to do).

 When declaring a variable, in almost every case, figuring out 
 the proper
 type, and writing that type takes a fraction of a second.


 The problem comes when you need to refactor your code and swap 
 one type for another. You have to change all ocurrences of that 
 type in that situation for another.


For sure there are situations where each approach will have some
ease of implementation/maintenance advantages.

The main point I have been trying to make is that I don't 
personally think that static typing is any more mentally 
challenging than dynamic typing - in most instances.
Jun 04 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Thu, 05 Jun 2014 12:46:23 +0000
Atila Neves via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:


 On Thursday, 5 June 2014 at 09:43:13 UTC, Jonathan M Davis via
 Digitalmars-d-announce wrote:

 On Thu, 05 Jun 2014 09:30:44 +0200
 Though I confess what horrifies me the most about dynamic
 languages is code
 like this

 if(cond)
     var = "hello world";
 else
     var = 42;

 The fact that an if statement could change the type of a
 variable is just
 atrocious IMHO.


 No, it's not just that you're statically-minded. Your example
 above is definitely atrocious, and more often than not a bug.


Well, of course it's a bug (or at least _horribly_ designed code if it's not).
The problem is that it's _legal_, and while that particular example might be
obvious, more complicated code could run into the same problem in more subtle
ways, causing bugs (and you won't even see the bug until you hit that
particular code path). Static typing avoids the whole problem.

As far as I can tell, dynamic typing doesn't really give you anything of value
over static typing. It just lets you type less (and features like auto
actually make it so that statically typed languages can eliminate a lot of the
same typing that dynamic languages eliminate but without reducing type
safety). You trade in a tool that automatically catches all kinds of bugs for
you just so that you don't have to type quite so much. It makes me wonder if
the folks who like dynamic languages ever write anything larger than a simple
script (and given how often we all screw up on even simple scripts, having the
compilers help there as well is still huge). I _definitely_ don't understand
the folks who write whole products in dynamic languages.

- Jonathan M Davis
Jun 05 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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


OK I noticed that I messed up in answering.

I was saying that you 2 seems to be confused between LLVM and
clang.
Jun 06 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/4/14, 3:19 AM, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/


 Andrei


This is offtopic, but why are people obsessed with writing English acronyms?

I always have to lookup the meaning and then I'm polluting my head with 
acronyms.

Is there any difference in time/convenience between writing "Interviewee 
here. Ask me anything" Between "Interviewee. AMA"?

:-(
Jun 06 2014
next sibling parent reply "Tourist" <gravatar gravatar.com> writes:
On Friday, 6 June 2014 at 19:27:35 UTC, Ary Borenszweig wrote:

 On 6/4/14, 3:19 AM, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/


 Andrei


 This is offtopic, but why are people obsessed with writing 
 English acronyms?

 I always have to lookup the meaning and then I'm polluting my 
 head with acronyms.

 Is there any difference in time/convenience between writing 
 "Interviewee here. Ask me anything" Between "Interviewee. AMA"?

 :-(


AMA is kinda reddit thing.
http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_of_facebooks_hhvm_team_a_c_and_d/
Jun 06 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/6/14, 5:25 PM, Tourist wrote:

 On Friday, 6 June 2014 at 19:27:35 UTC, Ary Borenszweig wrote:

 On 6/4/14, 3:19 AM, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/



 Andrei


 This is offtopic, but why are people obsessed with writing English
 acronyms?

 I always have to lookup the meaning and then I'm polluting my head
 with acronyms.

 Is there any difference in time/convenience between writing
 "Interviewee here. Ask me anything" Between "Interviewee. AMA"?

 :-(


 AMA is kinda reddit thing.
 http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_of_facebooks_hhvm_team_a_c_and_d/


Interesting, I didn't know that. Thanks!
Jun 06 2014
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 6 June 2014 at 20:27:45 UTC, Ary Borenszweig wrote:

 On 6/6/14, 5:25 PM, Tourist wrote:

 On Friday, 6 June 2014 at 19:27:35 UTC, Ary Borenszweig wrote:
 AMA is kinda reddit thing.
 http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_of_facebooks_hhvm_team_a_c_and_d/


 Interesting, I didn't know that. Thanks!


What gets me is that there are two acronyms to learn.

IAMA = I Am A
AMA = Ask Me Anything

So: I'm doing an IAMA, AMA.

For a while, I thought people were just lazy and AMA was just the 
'am a" part.
Jun 06 2014
prev sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Friday, 6 June 2014 at 19:27:35 UTC, Ary Borenszweig wrote:

 On 6/4/14, 3:19 AM, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/


 Andrei


 This is offtopic, but why are people obsessed with writing 
 English acronyms?

 I always have to lookup the meaning and then I'm polluting my 
 head with acronyms.

 Is there any difference in time/convenience between writing 
 "Interviewee here. Ask me anything" Between "Interviewee. AMA"?

 :-(


Its all the fault of people texting on their cell phones and the 
like! Too much work to write proper English words.  Amirite?
Jun 06 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/7/2014 12:21 AM, Craig Dillabaugh wrote:

 Its all the fault of people texting on their cell phones and the like!
 Too much work to write proper English words.  Amirite?


On those things, it *is* work! Even I've started giving up on proper 
grammar/capitalization/punctuation/spelling when texting (Not my normal 
comms choice, but I have a couple siblings that are of "everything must 
be in SMS form" age).

Oh well, at least we're not still entering text on number pads. I used 
to work on a WAP/WPL site (anyone remember those? anyone even *used* 
those? ;) ) Entering text was bad enough, but entering test-server URLs? 
Ugh. I never understood why the last Smash Bros game copied that cell 
phone text interface *intentionally*.
Jun 06 2014
prev sibling next sibling parent "Mike James" <foo bar.com> writes:
On Saturday, 7 June 2014 at 04:21:15 UTC, Craig Dillabaugh wrote:

 On Friday, 6 June 2014 at 19:27:35 UTC, Ary Borenszweig wrote:

 On 6/4/14, 3:19 AM, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/


 Andrei


 This is offtopic, but why are people obsessed with writing 
 English acronyms?

 I always have to lookup the meaning and then I'm polluting my 
 head with acronyms.

 Is there any difference in time/convenience between writing 
 "Interviewee here. Ask me anything" Between "Interviewee. AMA"?

 :-(


 Its all the fault of people texting on their cell phones and 
 the like! Too much work to write proper English words.  Amirite?


You should see it in the rail industry - it's all TLAs.

-=mike=-
Jun 07 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-07 06:21, Craig Dillabaugh wrote:


 Its all the fault of people texting on their cell phones and the like!
 Too much work to write proper English words.  Amirite?


I'm not so sure about that. English is full of shortenings which is 
proper English: do not -> don't, you are -> you're. Then, at least in 
the USA, abbreviations are common as well. CIA, NYPD and so on. Even the 
name of the country is an abbreviation :)

-- 
/Jacob Carlborg
Jun 07 2014
prev sibling parent reply "Mattcoder" <fromtheotherside mail.com> writes:
Andrei's D Talk (Day 2) is up:

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/D

Matheus.
Jun 10 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/10/14, 6:28 AM, Mattcoder wrote:

 Andrei's D Talk (Day 2) is up:

 http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/D

 Matheus.


Topics overlap a tad with NDC's so if you watched that you may want to 
skip over the portion between 7:41 and 15:42.

Andrei
Jun 10 2014