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
There are languages with good static type systems (OCaml, F#, 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
There are languages with good static type systems (OCaml, F#, 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