Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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!
Re: Interview at Lang.NEXT
Andrei's D Talk (Day 2) is up: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/D Matheus.
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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. ;)
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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 :)
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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 ;-)
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
On Wed, 04 Jun 2014 07:33:01 + 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
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.)
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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
}
Re: Interview at Lang.NEXT
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?
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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 ~.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.)
Re: Interview at Lang.NEXT
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
Re: Interview at Lang.NEXT
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?
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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 :(
Re: Interview at Lang.NEXT
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.
Re: Interview at Lang.NEXT
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
