www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why I'm Excited about D

reply "Adam Hawkins" <adam hawkins.io> writes:
Hello everyone, this is my first post on the forum. I've been 
investigating the language for the past few weeks. I was able to 
complete my first useful program thanks to very helpful people in 
#d on IRC . The experience made me very interested in the 
language and improving the community around it.

I'm primarily Ruby developer (been so about the last 7-8 years) 
doing web stuff with significant JavaScript work as well. I wrote 
a blog post on why I'm excited about D. You can read it here: 
http://hawkins.io/2015/04/excited-about-d/.

I've been reading the forums here so I can see that there is a 
focus on improving the marketing for the language and growing the 
community. I see most of the effort is geared towards C++ 
programmers, but have you considered looking at us dynamic 
languages folk? I see a big upside for us. Moving from Ruby to D 
(my case) gives me power & performance. I still have OOP 
techniques but I still have functional things like closures and 
all that good stuff. Only trade off in the Ruby case is 
metaprogramming. All in all I think there is a significant value 
promise for those of us doing backend services for folks like me.

Regardless, I figured it might be interesting to hear about some 
experience coming to the language from a different perspective. 
Cheers!
Apr 06 2015
next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Monday, 6 April 2015 at 23:51:17 UTC, Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum. I've been 
 investigating the language for the past few weeks. I was able 
 to complete my first useful program thanks to very helpful 
 people in #d on IRC . The experience made me very interested in 
 the language and improving the community around it.

 I'm primarily Ruby developer (been so about the last 7-8 years) 
 doing web stuff with significant JavaScript work as well. I 
 wrote a blog post on why I'm excited about D. You can read it 
 here: http://hawkins.io/2015/04/excited-about-d/.

 I've been reading the forums here so I can see that there is a 
 focus on improving the marketing for the language and growing 
 the community. I see most of the effort is geared towards C++ 
 programmers, but have you considered looking at us dynamic 
 languages folk? I see a big upside for us. Moving from Ruby to 
 D (my case) gives me power & performance. I still have OOP 
 techniques but I still have functional things like closures and 
 all that good stuff. Only trade off in the Ruby case is 
 metaprogramming. All in all I think there is a significant 
 value promise for those of us doing backend services for folks 
 like me.

 Regardless, I figured it might be interesting to hear about 
 some experience coming to the language from a different 
 perspective. Cheers!
I'm glad you like the language and felt enthusiatic enough to write an article about it. That's pretty much how D makes me feel. I think for pulling in Ruby people, it might be mostly the same as pulling in web people. I think the way I see it, I'd take vibe.d, an ORM with migrations, and runtime templates. The last two haven't been written yet. Then I'd be happy as far as replacing my web language of choice goes. At the moment I use Python and Django myself because of how little code I have to write to do a lot of things.
Apr 06 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 7 April 2015 at 00:15:51 UTC, w0rp wrote:
 [...]and runtime templates. The last two haven't been written 
 yet.
Really? Runtime templates aren't even hard to implement.... What I do with my web libs is use a minimal templating system based on dom.d. Basic things are inserted with placeholders (which can also pipe variables through various transformation things, like myvar|capitalize), then advanced things are done with the dom api - you can easily define custom tags and such to do what you need to do. I like it. Of course, I'm perhaps a bit weird in that I like having plain html templates for the most part and find little value in the weird things other languages do. Ruby on Rails with its stupid erb and form "helpers" are far more cumbersome to use than straight html if you ask me - especially if you have a server side dom to help do convenience transformations. And stuff like haml, wtf is even the point of that nonsense. .... but still, stuff like erb or haml isn't that hard to implement, it is strange to me that vibe wouldn't have them.
Apr 06 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-04-07 02:29, Adam D. Ruppe wrote:
 On Tuesday, 7 April 2015 at 00:15:51 UTC, w0rp wrote:
 [...]and runtime templates. The last two haven't been written yet.
Really? Runtime templates aren't even hard to implement....
vibe.d has a template system. It's based on Jade, which seems to be based on Haml. -- /Jacob Carlborg
Apr 06 2015
next sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/07/2015 08:28 AM, Jacob Carlborg wrote:

 
 vibe.d has a template system. It's based on Jade, which seems to be
 based on Haml.
There is also a runtime template system, http://code.dlang.org/packages/mustache-d. See https://github.com/D-Programming-GDC/gdcproject for an example.
Apr 07 2015
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 7 April 2015 at 06:28:49 UTC, Jacob Carlborg wrote:
 vibe.d has a template system. It's based on Jade, which seems 
 to be based on Haml.
Aye, though it is compile time rather than runtime which hurts the edit/run cycle - you have to recompile, redeploy (maybe), and restart just to see a quick text change. In my web projects. I used compile time stuff sometimes too, but the runtime loading ultimately won out for the ease of editing by me and by the frontend team - they can edit html too without needing to worry about rerunning a compiler.
Apr 07 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-04-07 18:06, Adam D. Ruppe wrote:

 Aye, though it is compile time rather than runtime which hurts the
 edit/run cycle - you have to recompile, redeploy (maybe), and restart
 just to see a quick text change.
Oh, right, that was what he meant with "runtime" :) -- /Jacob Carlborg
Apr 07 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/07/2015 06:06 PM, Adam D. Ruppe wrote:
 In my web projects. I used compile time stuff sometimes too, but the
 runtime loading ultimately won out for the ease of editing by me and by
 the frontend team - they can edit html too without needing to worry
 about rerunning a compiler.
That's why I spent quite some time reducing that cycle and worked on a dub watch command. https://github.com/D-Programming-Language/dub/pull/388 https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html https://github.com/D-Programming-Language/dub/pull/446 What's still missing is a faster AST interpreter for CTFE though.
Apr 07 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 11:42 AM, Martin Nowak wrote:
 What's still missing is a faster AST interpreter for CTFE though.
A JIT would be nice. -- Andrei
Apr 07 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 7 April 2015 at 22:22:35 UTC, Andrei Alexandrescu 
wrote:
 On 4/7/15 11:42 AM, Martin Nowak wrote:
 What's still missing is a faster AST interpreter for CTFE 
 though.
A JIT would be nice. -- Andrei
I'm not so sure CTFE would ever get out of the warmup debt JITs incur, ctfe bits usually don't live very long.
Apr 07 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 3:29 PM, Adam D. Ruppe wrote:
 On Tuesday, 7 April 2015 at 22:22:35 UTC, Andrei Alexandrescu wrote:
 On 4/7/15 11:42 AM, Martin Nowak wrote:
 What's still missing is a faster AST interpreter for CTFE though.
A JIT would be nice. -- Andrei
I'm not so sure CTFE would ever get out of the warmup debt JITs incur, ctfe bits usually don't live very long.
A JIT would pay off where it matters - intensive use of CTFE leading to long compilations. -- Andrei
Apr 07 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 7 April 2015 at 22:30:17 UTC, Andrei Alexandrescu 
wrote:
 On 4/7/15 3:29 PM, Adam D. Ruppe wrote:
 On Tuesday, 7 April 2015 at 22:22:35 UTC, Andrei Alexandrescu 
 wrote:
 On 4/7/15 11:42 AM, Martin Nowak wrote:
 What's still missing is a faster AST interpreter for CTFE 
 though.
A JIT would be nice. -- Andrei
I'm not so sure CTFE would ever get out of the warmup debt JITs incur, ctfe bits usually don't live very long.
A JIT would pay off where it matters - intensive use of CTFE leading to long compilations. -- Andrei
I can talk from first hand experience here, as SDC uses ONLY JIT for CTFE. It turns out that it is slower in the general case where you some small computation, but way faster as soon as you run something non trivial. I don't think it would be a good move to integrate it as this, but coupled with some heuristic, it would be great.
Apr 07 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2015 3:30 PM, Andrei Alexandrescu wrote:
 A JIT would pay off where it matters - intensive use of CTFE leading to long
 compilations. -- Andrei
A decent interpreter would fix most of CTFE's performance problems, no need to go as far as a JIT.
Apr 07 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 7 April 2015 at 22:59:00 UTC, Walter Bright wrote:
 On 4/7/2015 3:30 PM, Andrei Alexandrescu wrote:
 A JIT would pay off where it matters - intensive use of CTFE 
 leading to long
 compilations. -- Andrei
A decent interpreter would fix most of CTFE's performance problems, no need to go as far as a JIT.
What is a JIT if not an interpreter with hardware support ?
Apr 07 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 4:54 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 22:59:00 UTC, Walter Bright wrote:
 On 4/7/2015 3:30 PM, Andrei Alexandrescu wrote:
 A JIT would pay off where it matters - intensive use of CTFE leading
 to long
 compilations. -- Andrei
A decent interpreter would fix most of CTFE's performance problems, no need to go as far as a JIT.
What is a JIT if not an interpreter with hardware support ?
Nah. It's a fundamentally different approach to the same problem. -- Andrei
Apr 07 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 8 April 2015 at 00:28:50 UTC, Andrei Alexandrescu 
wrote:
 On 4/7/15 4:54 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 22:59:00 UTC, Walter Bright wrote:
 On 4/7/2015 3:30 PM, Andrei Alexandrescu wrote:
 A JIT would pay off where it matters - intensive use of CTFE 
 leading
 to long
 compilations. -- Andrei
A decent interpreter would fix most of CTFE's performance problems, no need to go as far as a JIT.
What is a JIT if not an interpreter with hardware support ?
Nah. It's a fundamentally different approach to the same problem. -- Andrei
Not really when you think about it. CPU instruction is a bytecode like another, with provided hardware interpreter for it. It is becoming common to have VM not going through the interpreter step (ie software interpreter) to go directly to low quality but fast codegen. V8 is doing this for instance.
Apr 07 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2015 5:59 PM, deadalnix wrote:
 Not really when you think about it. CPU instruction is a bytecode like another,
 with provided hardware interpreter for it.
Oh, I have thought about it. There's at least a couple orders of magnitude difference in complexity, even for the dumbest code generator.
 It is becoming common to have VM not going through the interpreter step (ie
 software interpreter) to go directly to low quality but fast codegen. V8 is
 doing this for instance.
When you've got unlimited resources, you can do that.
Apr 07 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 6:26 PM, Walter Bright wrote:
 On 4/7/2015 5:59 PM, deadalnix wrote:
 Not really when you think about it. CPU instruction is a bytecode like
 another,
 with provided hardware interpreter for it.
Oh, I have thought about it. There's at least a couple orders of magnitude difference in complexity, even for the dumbest code generator.
That's about the case for hhvm. -- Andrei
Apr 07 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 5:59 PM, deadalnix wrote:
 On Wednesday, 8 April 2015 at 00:28:50 UTC, Andrei Alexandrescu wrote:
 On 4/7/15 4:54 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 22:59:00 UTC, Walter Bright wrote:
 On 4/7/2015 3:30 PM, Andrei Alexandrescu wrote:
 A JIT would pay off where it matters - intensive use of CTFE leading
 to long
 compilations. -- Andrei
A decent interpreter would fix most of CTFE's performance problems, no need to go as far as a JIT.
What is a JIT if not an interpreter with hardware support ?
Nah. It's a fundamentally different approach to the same problem. -- Andrei
Not really when you think about it. CPU instruction is a bytecode like another, with provided hardware interpreter for it.
Classical interpretation via tree walking does not use a bytecode. -- Andrei
Apr 07 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2015 6:30 PM, Andrei Alexandrescu wrote:
 Classical interpretation via tree walking does not use a bytecode. -- Andrei
And this is proven to work by CTFE. (CTFE walks the AST.) Note that walking the AST, instead of generating bytecode, is not at all why CTFE is slow. CTFE is slow because it allocates memory for every step in the computation.
Apr 07 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Apr 07, 2015 at 06:48:58PM -0700, Walter Bright via Digitalmars-d wrote:
 On 4/7/2015 6:30 PM, Andrei Alexandrescu wrote:
Classical interpretation via tree walking does not use a bytecode. --
Andrei
And this is proven to work by CTFE. (CTFE walks the AST.) Note that walking the AST, instead of generating bytecode, is not at all why CTFE is slow. CTFE is slow because it allocates memory for every step in the computation.
Is this fixable within reasonable effort, or does it require what essentially amounts to rewriting CTFE from scratch? T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Apr 07 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 8 April 2015 at 01:30:02 UTC, Andrei Alexandrescu 
wrote:
 Not really when you think about it. CPU instruction is a 
 bytecode like
 another, with provided hardware interpreter for it.
Classical interpretation via tree walking does not use a bytecode. -- Andrei
Yes, but this is pretty much what is done right now, so that wouldn't be an improvement.
Apr 07 2015
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"deadalnix"  wrote in message news:qranzmdfsbaxpxlwikmj forum.dlang.org...

 Classical interpretation via tree walking does not use a bytecode. --  
 Andrei
Yes, but this is pretty much what is done right now, so that wouldn't be an improvement.
The allocation problems are not caused by the tree walking, and they can be fixed without changing to a bytecode interpreter or a JIT.
Apr 07 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 7:33 PM, deadalnix wrote:
 On Wednesday, 8 April 2015 at 01:30:02 UTC, Andrei Alexandrescu wrote:
 Not really when you think about it. CPU instruction is a bytecode like
 another, with provided hardware interpreter for it.
Classical interpretation via tree walking does not use a bytecode. -- Andrei
Yes, but this is pretty much what is done right now, so that wouldn't be an improvement.
You went ouroboros. This means your point has been destroyed so thoroughly, you lost the thread of the dialog. Own the destruction and move on. -- Andrei
Apr 07 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 8 April 2015 at 05:03:03 UTC, Andrei Alexandrescu 
wrote:
 On 4/7/15 7:33 PM, deadalnix wrote:
 On Wednesday, 8 April 2015 at 01:30:02 UTC, Andrei 
 Alexandrescu wrote:
 Not really when you think about it. CPU instruction is a 
 bytecode like
 another, with provided hardware interpreter for it.
Classical interpretation via tree walking does not use a bytecode. -- Andrei
Yes, but this is pretty much what is done right now, so that wouldn't be an improvement.
You went ouroboros. This means your point has been destroyed so thoroughly, you lost the thread of the dialog. Own the destruction and move on. -- Andrei
You are the one making about winning.
Apr 08 2015
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 7 April 2015 at 22:22:35 UTC, Andrei Alexandrescu 
wrote:
 On 4/7/15 11:42 AM, Martin Nowak wrote:
 What's still missing is a faster AST interpreter for CTFE 
 though.
A JIT would be nice. -- Andrei
Maxine understood the point, see http://dconf.org/2013/talks/chevalier_boisvert.pdf p. 61 ff, an AST interpreter is something you can write over a long weekend, a JIT is rather unlikely to happen any time soon. Even a bytecode interpreter might hardly be worth the effort.
Apr 08 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 7/04/2015 11:51 a.m., Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum. I've been
 investigating the language for the past few weeks. I was able to
 complete my first useful program thanks to very helpful people in #d on
 IRC . The experience made me very interested in the language and
 improving the community around it.

 I'm primarily Ruby developer (been so about the last 7-8 years) doing
 web stuff with significant JavaScript work as well. I wrote a blog post
 on why I'm excited about D. You can read it here:
 http://hawkins.io/2015/04/excited-about-d/.

 I've been reading the forums here so I can see that there is a focus on
 improving the marketing for the language and growing the community. I
 see most of the effort is geared towards C++ programmers, but have you
 considered looking at us dynamic languages folk? I see a big upside for
 us. Moving from Ruby to D (my case) gives me power & performance. I
 still have OOP techniques but I still have functional things like
 closures and all that good stuff. Only trade off in the Ruby case is
 metaprogramming. All in all I think there is a significant value promise
 for those of us doing backend services for folks like me.

 Regardless, I figured it might be interesting to hear about some
 experience coming to the language from a different perspective. Cheers!
I was slightly surprised that you didn't mention CTFE in there as it is one of D's unique and powerful features. But only because I'm a little invested https://leanpub.com/ctfe in it. I am very interested in feedback on https://github.com/DNetDev from you. I do have a web service framework also being written. But it really needs the web server first.
Apr 06 2015
parent reply "Jens Bauer" <doctor who.no> writes:
On Tuesday, 7 April 2015 at 00:28:11 UTC, Rikki Cattermole wrote:
 I was slightly surprised that you didn't mention CTFE in there 
 as it is one of D's unique and powerful features.
 But only because I'm a little invested https://leanpub.com/ctfe 
 in it.
It is very cool, that you can generate tables without the need for writing a perl-script or some "additional" C/C++ program. Having table-generation at compile-time is an excellent feature. -Yes, that's only one of the features, but it's a feature I'll be using more than once! :)
Apr 06 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 7/04/2015 12:52 p.m., Jens Bauer wrote:
 On Tuesday, 7 April 2015 at 00:28:11 UTC, Rikki Cattermole wrote:
 I was slightly surprised that you didn't mention CTFE in there as it
 is one of D's unique and powerful features.
 But only because I'm a little invested https://leanpub.com/ctfe in it.
It is very cool, that you can generate tables without the need for writing a perl-script or some "additional" C/C++ program. Having table-generation at compile-time is an excellent feature. -Yes, that's only one of the features, but it's a feature I'll be using more than once! :)
CTFE could have some pretty awesome applications for embedded I suspect. After all, you can pregenerate data structures ext. For faster execution. I don't think anybody has toyed with this yet.
Apr 06 2015
parent reply "Jens Bauer" <doctor who.no> writes:
On Tuesday, 7 April 2015 at 00:57:09 UTC, Rikki Cattermole wrote:
 CTFE could have some pretty awesome applications for embedded I 
 suspect. After all, you can pregenerate data structures ext. 
 For faster execution.
Yes, they're particularly useful for embedded devices. I've often used tables in assembly language in this regard. -Things that seem to be impossible, because the normal approach is to "write optimized code" suddenly becomes possible, when optimizing (rearranging) the data to fit the hardware.
 I don't think anybody has toyed with this yet.
With D, advanced table-generation will become much easier. I bet I'm one of those people, who will have a lot of fun using this feature. ;)
Apr 06 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 7/04/2015 1:02 p.m., Jens Bauer wrote:
 On Tuesday, 7 April 2015 at 00:57:09 UTC, Rikki Cattermole wrote:
 CTFE could have some pretty awesome applications for embedded I
 suspect. After all, you can pregenerate data structures ext. For
 faster execution.
Yes, they're particularly useful for embedded devices. I've often used tables in assembly language in this regard. -Things that seem to be impossible, because the normal approach is to "write optimized code" suddenly becomes possible, when optimizing (rearranging) the data to fit the hardware.
 I don't think anybody has toyed with this yet.
With D, advanced table-generation will become much easier. I bet I'm one of those people, who will have a lot of fun using this feature. ;)
I'm watching your progress closely. I think we are ready to get D properly on micro controllers and you are really testing, exploring it even. I would be very surprised in the next year or so, if you don't make atleast one breakthrough!
Apr 06 2015
parent "Jens Bauer" <doctor who.no> writes:
On Tuesday, 7 April 2015 at 01:28:03 UTC, Rikki Cattermole wrote:
 I'm watching your progress closely. I think we are ready to get 
 D properly on micro controllers and you are really testing, 
 exploring it even.
Johannes made some very important additions for regarding this. It might already be possible for me to write a complete startup file entirely in D, because of these additions.
 I would be very surprised in the next year or so, if you don't 
 make atleast one breakthrough!
I'm looking forward to the first one; it's just around the corner: The file "startup.d". :) -I'll be sure to create a thread about it, when it's complete (it's at something like 98% already). One thing I'd like to add to why I like D, is that it feels "limitless". I don't feel like I'm restricted by the language or the compiler; in other words, I feel a lot of 'freedom'.
Apr 07 2015
prev sibling next sibling parent "Jens Bauer" <doctor who.no> writes:
On Monday, 6 April 2015 at 23:51:17 UTC, Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum.
Then as a fellow newcomer to D, let me be the first to welcome you. :)
 I wrote a blog post on why I'm excited about D. You can read it 
 here: http://hawkins.io/2015/04/excited-about-d/.
Very nice article. I think I came across a minor error (please correct me if I'm wrong)... In your runTests 'in' part - shouldn't "results" be "tests" ? ... As for myself, I sense a lot of power in the D language; but curently I'm only in the process of starting the engine. My goal is to work with D for microcontrollers like ARM Cortex-M and ARM Cortex-A later. D is *very* suitable for this; perhaps the most suitable language I've ever come across. To me, D is appealing because: 1: I am crazy about optimizing my code. Assembly language and optimization is one of my greatest hobbies. 2: I would like my code to be easy and simple. 3: I would like an object-oriented programming language which does not bloat everything out of proportions. ;) 4: I like 'universal', 'general' and 'generic' very much. I think D covers those points very well. From what I've seen and read so far, the produced binary is short and quite fast; the source code for a program does not need to be huge and ugly, but can be small and easy to overview. Furthermore, I hate "C++ string classes". In D, a string is a native type; pretty cool. Just start typing your code and run it. And for a long time, I've wanted something as easy as Javascript, but just able to generate executable code, which works outside the Web-browser. D is clearly a language designed by experienced developers. It shows the best side of open source. (My favorites: Redis, GCC and D - and yes, I've already noticed Tiny Redis, and i'm going to use try it out sometime, perhaps even on a microcontroller).
Apr 06 2015
prev sibling next sibling parent reply "bachmeier" <no spam.net> writes:
On Monday, 6 April 2015 at 23:51:17 UTC, Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum. I've been 
 investigating the language for the past few weeks. I was able 
 to complete my first useful program thanks to very helpful 
 people in #d on IRC . The experience made me very interested in 
 the language and improving the community around it.

 I'm primarily Ruby developer (been so about the last 7-8 years) 
 doing web stuff with significant JavaScript work as well. I 
 wrote a blog post on why I'm excited about D. You can read it 
 here: http://hawkins.io/2015/04/excited-about-d/.

 I've been reading the forums here so I can see that there is a 
 focus on improving the marketing for the language and growing 
 the community. I see most of the effort is geared towards C++ 
 programmers, but have you considered looking at us dynamic 
 languages folk? I see a big upside for us. Moving from Ruby to 
 D (my case) gives me power & performance. I still have OOP 
 techniques but I still have functional things like closures and 
 all that good stuff. Only trade off in the Ruby case is 
 metaprogramming. All in all I think there is a significant 
 value promise for those of us doing backend services for folks 
 like me.

 Regardless, I figured it might be interesting to hear about 
 some experience coming to the language from a different 
 perspective. Cheers!
The thing I liked, coming from languages like R and Ruby, was that I could write D code in the most convenient, least efficient manner possible and still get good enough performance that it wouldn't matter. I find D to be easier to write than any scripting language. When I write D I always have to remind myself that I can just write, without concern for efficiency. And in the few cases that performance is critical I know I can do as well as C.
Apr 06 2015
parent reply "cym13" <cpicard openmailbox.org> writes:
On Tuesday, 7 April 2015 at 01:12:20 UTC, bachmeier wrote:
 The thing I liked, coming from languages like R and Ruby, was 
 that I could write D code in the most convenient, least 
 efficient manner possible and still get good enough performance 
 that it wouldn't matter. I find D to be easier to write than 
 any scripting language. When I write D I always have to remind 
 myself that I can just write, without concern for efficiency. 
 And in the few cases that performance is critical I know I can 
 do as well as C.
This! This is really the thing I like about D overall! I used to prototype in python and either rewrite part of it in C (process involving lots of latent rage for missing common features) or give up on performance (which, honestly, was most of the time a good answer). In D I feel like I don't have this tradeoff. I start prototyping in D putting auto everywhere and not anotating anything and when the prototype works I just start cleaning the code, annotating it, etc.... The fact that where I used two languages I can now use only one is what convinced me (even if, to be fair, the prototyping part is way much easier in python... But that may be due to the gab of experience).
Apr 07 2015
parent reply "Laeeth Isharc" <laeeth nospamlaeeth.com> writes:
even if,
 to be fair, the prototyping part is way much easier in 
 python... But that may be due to the gab of experience).
what - beyond a richer choice of libraries (and documentation, including examples) would make D comparable to python in terms of prototyping ease?
Apr 07 2015
parent "Laeeth Isharc" <laeeth nospamlaeeth.com> writes:
We are clearly blessed here with an abundance of expertise in 
Ruby in the forum.

If anyone would like to share some of their knowledge, this page 
could use some filling out:

http://wiki.dlang.org/Coming_From/Ruby

Concrete examples and links to personal stories are helpful - as 
well as more theoretical explorations of language concepts.

It's better to make a start than worry about it not being perfect.
Apr 07 2015
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Monday, 6 April 2015 at 23:51:17 UTC, Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum. I've been 
 investigating the language for the past few weeks. I was able 
 to complete my first useful program thanks to very helpful 
 people in #d on IRC . The experience made me very interested in 
 the language and improving the community around it.

 I'm primarily Ruby developer (been so about the last 7-8 years) 
 doing web stuff with significant JavaScript work as well. I 
 wrote a blog post on why I'm excited about D. You can read it 
 here: http://hawkins.io/2015/04/excited-about-d/.

 I've been reading the forums here so I can see that there is a 
 focus on improving the marketing for the language and growing 
 the community. I see most of the effort is geared towards C++ 
 programmers, but have you considered looking at us dynamic 
 languages folk? I see a big upside for us. Moving from Ruby to 
 D (my case) gives me power & performance. I still have OOP 
 techniques but I still have functional things like closures and 
 all that good stuff. Only trade off in the Ruby case is 
 metaprogramming. All in all I think there is a significant 
 value promise for those of us doing backend services for folks 
 like me.

 Regardless, I figured it might be interesting to hear about 
 some experience coming to the language from a different 
 perspective. Cheers!
Very nice article. I have two suggestions: import std.stdio, std.parallelism; auto names = [ "Adam Hawkins", "Peter Esselius" ]; foreach(name; taskPool.parallel(names)) { writeln(name); } There is a convenience function in std.parallelism that allows you to write the following instead for your foreach loop: foreach (name; names.parallel) { writeln(name); } Also, system, trusted, safe don't really have much to do with optimization or access levels, but safety. Theoretically, if all of your code is safe, then it is impossible for your program to corrupt memory. Also, have you considered posting this article to Hacker News/Reddit?
Apr 06 2015
parent reply "ixid" <adamsibson hotmail.com> writes:
 import std.stdio, std.parallelism;

 auto names = [ "Adam Hawkins", "Peter Esselius" ];

 foreach(name; taskPool.parallel(names)) {
     writeln(name);
 }

 There is a convenience function in std.parallelism that allows 
 you to write the following instead for your foreach loop:

 foreach (name; names.parallel) {
     writeln(name);
 }

 Also,  system,  trusted,  safe don't really have much to do 
 with optimization or access levels, but safety. Theoretically, 
 if all of your code is  safe, then it is impossible for your 
 program to corrupt memory.

 Also, have you considered posting this article to Hacker 
 News/Reddit?
Or to be more consistent with UFCS: foreach (name; names.parallel) { name.writeln; }
Apr 07 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
     name.writeln;
 }
no.please
Apr 07 2015
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
     name.writeln;
 }
no.please
wat
Apr 07 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
 On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
    name.writeln;
 }
no.please
wat
unreadable.is.ufcs.using.over
Apr 07 2015
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 4/7/15 3:34 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
 On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
    name.writeln;
 }
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like "writeln" being used with UFCS, it's an abuse. My point is that every language has WATs :-)
Apr 07 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Apr 07, 2015 at 04:46:07PM -0300, Ary Borenszweig via Digitalmars-d
wrote:
 On 4/7/15 3:34 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:

foreach (name; names.parallel) {
   name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like "writeln" being used with UFCS, it's an abuse. My point is that every language has WATs :-)
My current favorite WAT in D is: import std.stdio; void fun(string text) { import std.conv; writeln(text); } void main() { fun("Hello world"); } This program outputs a blank line. :-) T -- A mathematician is a device for turning coffee into theorems. -- P. Erdos
Apr 07 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 1:11 PM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Apr 07, 2015 at 04:46:07PM -0300, Ary Borenszweig via Digitalmars-d
wrote:
 On 4/7/15 3:34 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
 On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
    name.writeln;
 }
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like "writeln" being used with UFCS, it's an abuse. My point is that every language has WATs :-)
My current favorite WAT in D is: import std.stdio; void fun(string text) { import std.conv; writeln(text); } void main() { fun("Hello world"); } This program outputs a blank line. :-)
Yeah, I think it's urgent we fix that. -- Andrei
Apr 07 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 7 April 2015 at 22:24:21 UTC, Andrei Alexandrescu 
wrote:
 My current favorite WAT in D is:

 	import std.stdio;
 	void fun(string text) {
 		import std.conv;
 		writeln(text);
 	}
 	void main() {
 		fun("Hello world");
 	}

 This program outputs a blank line. :-)
Yeah, I think it's urgent we fix that. -- Andrei
My favorite next: void function() f; static assert(is(f == function)); // OK void delegate() dg; static assert(is(f == delegate)); // Nope... Note that even phobos can get confused with that one in some cases.
Apr 07 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 3:27 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 22:24:21 UTC, Andrei Alexandrescu wrote:
 My current favorite WAT in D is:

     import std.stdio;
     void fun(string text) {
         import std.conv;
         writeln(text);
     }
     void main() {
         fun("Hello world");
     }

 This program outputs a blank line. :-)
Yeah, I think it's urgent we fix that. -- Andrei
My favorite next: void function() f; static assert(is(f == function)); // OK void delegate() dg; static assert(is(f == delegate)); // Nope...
(I assume you meant "dg" here.) This doesn't strike me as big, but it is weird.
 Note that even phobos can get confused with that one in some cases.
Are there bugzillas for these two matters? Andrei
Apr 07 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Apr 07, 2015 at 03:29:26PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 4/7/15 3:27 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 22:24:21 UTC, Andrei Alexandrescu wrote:
My current favorite WAT in D is:

    import std.stdio;
    void fun(string text) {
        import std.conv;
        writeln(text);
    }
    void main() {
        fun("Hello world");
    }
[...]
 Are there bugzillas for these two matters?
[...] The blank output one has been known for a while now (since June 2013), under various guises: https://issues.dlang.org/show_bug.cgi?id=10378 The above test case, though, strikes me as a particularly compelling example of why this bug is so nasty. T -- Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes
Apr 07 2015
prev sibling parent reply "ixid" <adamsibson hotmail.com> writes:
On Tuesday, 7 April 2015 at 19:46:07 UTC, Ary Borenszweig wrote:
 On 4/7/15 3:34 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig 
 wrote:
 On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
   name.writeln;
 }
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like "writeln" being used with UFCS, it's an abuse. My point is that every language has WATs :-)
Why is it 'an abuse'? Do you special case any other functions or is names.parallel unacceptable as well? Are longer chains ending in writeln acceptable or do you insist in putting the whole chain inside a parens writeln? name.reverse.writeln or writeln(name.reverse) or surely that would break your dislike of single UFCS arguments so you should stick to: writeln(reverse(name)) Which is proper yoda speak.
Apr 08 2015
next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 8 April 2015 at 08:35:52 UTC, ixid wrote:
 On Tuesday, 7 April 2015 at 19:46:07 UTC, Ary Borenszweig wrote:
 On 4/7/15 3:34 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig 
 wrote:
 On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
  name.writeln;
 }
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like "writeln" being used with UFCS, it's an abuse. My point is that every language has WATs :-)
Why is it 'an abuse'? Do you special case any other functions or is names.parallel unacceptable as well? Are longer chains ending in writeln acceptable or do you insist in putting the whole chain inside a parens writeln? name.reverse.writeln or writeln(name.reverse) or surely that would break your dislike of single UFCS arguments so you should stick to: writeln(reverse(name)) Which is proper yoda speak.
At the very least, put () after the writelne: name.reverse.writeln(); Using the property getter style for a function used solely for it's side-effects kind of conceals what you are trying to do here... At any rate, since UFCS allows you to choose the order your code will be read in, you should try give as much information as soon as possible: `writeln(name.reverse);` - the first word is `writeln`, so I know it's a statement that's going to write something to stdout. `name.reverse.writeln();` - the first word is `name`, so I know it has something to do with the name. Decide which one to use based on the first impression you want people to get from that statement.
Apr 08 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Apr 08 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu 
wrote:
 On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Yes.
Apr 08 2015
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 8 April 2015 at 16:49:27 UTC, Dicebot wrote:
 On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu
 No. -- Andrei
Yes.
FILE_NOT_FOUND
Apr 08 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 16:49:27 UTC, Dicebot wrote:
 On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu 
 wrote:
 On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Yes.
And, by the way, this is not a just personal taste thing. This stupid style has costed me many wasted debugging ours during project maintenance. Considering I am far from the only person having problems with it in our team and such style is extremely common because of being easy - this can easily be one of most damaging language features in D in terms of wasted developer time.
Apr 08 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 9:53 AM, Dicebot wrote:
 On Wednesday, 8 April 2015 at 16:49:27 UTC, Dicebot wrote:
 On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote:
 On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Yes.
And, by the way, this is not a just personal taste thing.
It is.
 This stupid
 style has costed me many wasted debugging ours during project
 maintenance.
Not buying it.
 Considering I am far from the only person having problems
 with it in our team and such style is extremely common because of being
 easy - this can easily be one of most damaging language features in D in
 terms of wasted developer time.
Again trying with ad populum. Not buying it. Andrei
Apr 08 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei Alexandrescu 
wrote:
 Considering I am far from the only person having problems
 with it in our team and such style is extremely common because 
 of being
 easy - this can easily be one of most damaging language 
 features in D in
 terms of wasted developer time.
Again trying with ad populum. Not buying it.
I don't even slightly care about your opinion here. It is just another annoying custom style rule I have to deal with. Casual necessity for actually getting work done with D. And if "not buying it" is all you can say about actual experience report (however opinionated it is) this tells quite a lot about how justified _your_ preference is.
Apr 08 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 10:04 AM, Dicebot wrote:
 On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei Alexandrescu wrote:
 Considering I am far from the only person having problems
 with it in our team and such style is extremely common because of being
 easy - this can easily be one of most damaging language features in D in
 terms of wasted developer time.
Again trying with ad populum. Not buying it.
I don't even slightly care about your opinion here. It is just another annoying custom style rule I have to deal with. Casual necessity for actually getting work done with D.
I guess I deserve this for making my point as a jerk. I shouldn't engage in brief bickering when I don't have time. My point was: you'd need some detail to back up your claim about those wasted hours because I also work on a large D project at work with others and that hasn't been an issue, like, ever. We ended up just not adding the pesky "()"s simply because sitting down and deciding which deserves and which doesn't was a waste of time. E.g. front and empty shouldn't, but popFront should. Really no reason for it.
 And if "not buying it" is all you can say about actual experience report
 (however opinionated it is) this tells quite a lot about how justified
 _your_ preference is.
Yah, I do think it's a matter of preference. Andrei
Apr 08 2015
next sibling parent reply "Dmitri Makarov" <dmakarv gmail.com> writes:
On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu 
wrote:
 ... I also work on a large D project at work ...
Which compiler do you use?
Apr 08 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 11:50 AM, Dmitri Makarov wrote:
 On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote:
 ... I also work on a large D project at work ...
Which compiler do you use?
dmd -- Andrei
Apr 08 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 8 April 2015 at 22:19:11 UTC, Andrei Alexandrescu 
wrote:
 On 4/8/15 11:50 AM, Dmitri Makarov wrote:
 On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei 
 Alexandrescu wrote:
 ... I also work on a large D project at work ...
Which compiler do you use?
dmd -- Andrei
Is this for both production and development?
Apr 08 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 3:28 PM, weaselcat wrote:
 On Wednesday, 8 April 2015 at 22:19:11 UTC, Andrei Alexandrescu wrote:
 On 4/8/15 11:50 AM, Dmitri Makarov wrote:
 On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote:
 ... I also work on a large D project at work ...
Which compiler do you use?
dmd -- Andrei
Is this for both production and development?
Both. -- Andrei
Apr 08 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 08 Apr 2015 22:28:58 +0000, weaselcat wrote:

 On Wednesday, 8 April 2015 at 22:19:11 UTC, Andrei Alexandrescu wrote:
 On 4/8/15 11:50 AM, Dmitri Makarov wrote:
 On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote:
 ... I also work on a large D project at work ...
Which compiler do you use?
dmd -- Andrei
=20 Is this for both production and development?
i'm using DMD for production code too. most of the time code waits for i/o (being that disk, network or user interaction). ah, even my 2d game=20 engine is ok with -release.=
Apr 08 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 08 Apr 2015 23:14:23 +0000, ketmar wrote:

 On Wed, 08 Apr 2015 22:28:58 +0000, weaselcat wrote:
=20
 On Wednesday, 8 April 2015 at 22:19:11 UTC, Andrei Alexandrescu wrote:
 On 4/8/15 11:50 AM, Dmitri Makarov wrote:
 On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu
 wrote:
 ... I also work on a large D project at work ...
Which compiler do you use?
dmd -- Andrei
=20 Is this for both production and development?
=20 i'm using DMD for production code too. most of the time code waits for i/o (being that disk, network or user interaction). ah, even my 2d game engine is ok with -release.
to be honest, "-release" doesn't make much difference, as i'm already=20 using `.ptr` to avoid range checking where it isn't appropriate.=
Apr 08 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu 
wrote:
 On 4/8/15 10:04 AM, Dicebot wrote:
 On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei 
 Alexandrescu wrote:
 Considering I am far from the only person having problems
 with it in our team and such style is extremely common 
 because of being
 easy - this can easily be one of most damaging language 
 features in D in
 terms of wasted developer time.
Again trying with ad populum. Not buying it.
I don't even slightly care about your opinion here. It is just another annoying custom style rule I have to deal with. Casual necessity for actually getting work done with D.
I guess I deserve this for making my point as a jerk. I shouldn't engage in brief bickering when I don't have time. My point was: you'd need some detail to back up your claim about those wasted hours because I also work on a large D project at work with others and that hasn't been an issue, like, ever. We ended up just not adding the pesky "()"s simply because sitting down and deciding which deserves and which doesn't was a waste of time. E.g. front and empty shouldn't, but popFront should. Really no reason for it.
So, to be more specific, here is one of cases where it actually caused trouble in practice. Someone has originally written code that looked roughly like this: while (something) { // ... auto str = format("%s", parser.node); } Long time later I have been adding trace logs to that module and this has become akin to while (something) { log(parser.node); // ... auto str = format("%s", parser.node); } Which resulted in broken application. It took almost an hour to bisect all changed to trace the failure to this specifc line and realize that `parser.node` wasn't just trivial getter but method which actually advanced internal iterator to next node while returning current one. Yes, this does seem to bother only some people and others actually enjoy omitting parens everywhere. But it comes up often enough to cause actual damage which makes aesthetical point much less convincing. I don't have any good statistics for how often it strikes or what kind of workflow is more likely to clash with such style - all I know that such cases happen, and happen often enough to not be dismissed as purely accidental. Considering that following more permissive coding style does not actually give you any benefits than saving at most one pair of () per line, choice feels obvious. We don't currently have any strict style rules about this but general direction seems to be "mandatory () for last call in a call chain" with an exception for side-effect free trivial getters. tl; dr: I can commonly be wrong in identifying the problem, evalutating its importance or proposing solutions but it feels offending when you suggest I don't actually have a problem at all. "Those are not the droids you are looking for" style ;)
Apr 08 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 11:45 PM, Dicebot wrote:
 It took almost an hour to bisect all changed to trace the failure to
 this specifc line and realize that `parser.node` wasn't just trivial
 getter but method which actually advanced internal iterator to next node
 while returning current one.
Thanks. The matter seems like a C++ false friend. -- Andrei
Apr 09 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 April 2015 at 07:00:56 UTC, Andrei Alexandrescu 
wrote:
 On 4/8/15 11:45 PM, Dicebot wrote:
 It took almost an hour to bisect all changed to trace the 
 failure to
 this specifc line and realize that `parser.node` wasn't just 
 trivial
 getter but method which actually advanced internal iterator to 
 next node
 while returning current one.
Thanks. The matter seems like a C++ false friend. -- Andrei
Actually, C++ had the very same issue, just the other way around. Stuff like length() was still called like method even if trivial and I remember resorting to naming convention to avoid wasting time on following all symbol references. It was roughly the same rule - no side effects or costly computations in methods named `getXXX`, simply attached to naming convention as opposed to calling convention. And it was even more unpleasant than current D state of affairs. I had much more pleasant experience of maintaining code in plain C where separation between data and code is more forced by language simplicity. It is much better in languages that do support dedicated properties because language rules can be used to express the same notion without resorting to any conventions. And properly naming things is unreasonably time consuming so this "by convention" approach hardly works anyway. The way I see situation in D is that it had an opportunity to actually get things better than in C/C++ with property but that was killed in favor of seemingly "nice" syntax. Which feels completely disproportional approach to me because saving one pair of () per line of code is hardly comparable to being able to better reason about the code without resorting to IDE. Everyone who has pointed out that naming in original snippet sucks is completely right. However, this is not really helping - bad names will inevitably slip through here and there. Which naturally makes me annoyed about language features that make the issue worse instead of largely diminishing it. Mandatory () are probably not that important on their own - but thet at least add something to to the language, while alternative is simply syntax sugar with no practical value.
Apr 12 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/12/15 10:43 AM, Dicebot wrote:
 It is much better in languages that do support dedicated properties
 because language rules can be used to express the same notion without
 resorting to any conventions.
Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, wouldn't C# code need to resort to conventions to avoid surprising behavior? -- Andrei
Apr 12 2015
next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu 
wrote:
 On 4/12/15 10:43 AM, Dicebot wrote:
 It is much better in languages that do support dedicated 
 properties
 because language rules can be used to express the same notion 
 without
 resorting to any conventions.
Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, wouldn't C# code need to resort to conventions to avoid surprising behavior? -- Andrei
I'd be surprised if there is any language that prevents you from causing side-effects in getters(beside functional languages that prevent you from causing side-effects anywhere) or non-setting-related side-effects in setters. These kind of limitations prevent many useful patterns, like calculating-and-caching a value the first time a getter is called, or updating a visual component on the screen when it's setters are called. I don't think relying-purely-on-conventions-with-no-language-support and the-language-strictly-forbids-stuff are the only choices. With a grain (syntactic) salt a language can promote the right way by turning the wrong way into code smell. If you see a getter function declared as getter(be it with C#'s getter declaration syntax or with D's doesn't-actually-do-anything property attribute or whatever used in that language) that causes side-effects other than the ones pragmatically needed for getting the value, you can immediately see that something is wrong. But if you look at such a function at the call site you can't guess that it's doing that stuff. In C#, if you can't rely on other developers to only use the getter-setter syntax for actual getters and setters, then that is probably the least of your worries... In D, you don't need to not rely on other developers to do that, because EVERY method without arguments and EVERY function with a single argument are getters, and there is nothing you can do about it(unless you use the seems-to-be-abandoned -property flag). BTW - the exact definition of getters and setters may vary(can querying a webservice be considered a getter?), but under no sane definition is writeln a getter!
Apr 12 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu 
wrote:
 On 4/12/15 10:43 AM, Dicebot wrote:
 It is much better in languages that do support dedicated 
 properties
 because language rules can be used to express the same notion 
 without
 resorting to any conventions.
Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, wouldn't C# code need to resort to conventions to avoid surprising behavior? -- Andrei
This is totally reasonable way to put it but in practice there are enough differences to keep it maintainable. With dedicated getters decision (and reviewer attention) is focused on definition of getter and done there once and for all. Some tough decisions are inevitable but it is at least possible to ensure that all such decisions are deliberate. In D such decision is done at call site which makes it very hard to review as changes are distributed everywhere. Though DScanner can possibly help here and I am really looking forward trying to it in our code control. That said, I think the main reason why this notion didn't work well for D when property was introduces is because of extremely vague range semantics. I find it important that you have mentioned exactly `front` and `popFront` as examples for unclear parens placement - problem with those is that there isn't. `front` may or may not be trivial getter depending on (sometimes arbitrary) decision by range implementor, there is no uniformity between those. Which makes impossible to enforce consistent calling style and makes "drop everything" approach much more tempting.
Apr 12 2015
next sibling parent "Dominikus Dittes Scherkl" writes:
On Monday, 13 April 2015 at 05:46:32 UTC, Dicebot wrote:
 [...]
 That said, I think the main reason why this notion didn't work 
 well for D when  property was introduces is because of 
 extremely vague range semantics. I find it important that you 
 have mentioned exactly `front` and `popFront` as examples for 
 unclear parens placement - problem with those is that there 
 isn't. `front` may or may not be trivial getter depending on 
 (sometimes arbitrary) decision by range implementor, there is 
 no uniformity between those. Which makes impossible to enforce 
 consistent calling style and makes "drop everything" approach 
 much more tempting.
At work we use a tool that uses a kind of attribute "no side effects". I would love it if the D could do just that - the compiler is already able to check if a function has side effects or not (if it has none it can warns about simple function call statements), than only functions with no side effects should be callable without parantheses. That would be straight and a clear visible for the reader of some code. And than the attribute property could be used to allow even a function WITH side effects to be called without parantheses - the developer has to ensure that what ever is done in such a function does something sensible (e.g. calculate something at first call and then only works as getter afterwards), but the reader of the code is warned: the attribute proberty was used, so he better take a look what this function really does. Maybe also a new attribute nonprop could be introduced, to force that a function must be called with parantheses even if it has no side effects, but I'm not sure where this would be useful.
Apr 13 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 13 April 2015 at 05:46:32 UTC, Dicebot wrote:
 On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu 
 wrote:
 On 4/12/15 10:43 AM, Dicebot wrote:
 It is much better in languages that do support dedicated 
 properties
 because language rules can be used to express the same notion 
 without
 resorting to any conventions.
Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, wouldn't C# code need to resort to conventions to avoid surprising behavior? -- Andrei
This is totally reasonable way to put it but in practice there are enough differences to keep it maintainable. With dedicated getters decision (and reviewer attention) is focused on definition of getter and done there once and for all. Some tough decisions are inevitable but it is at least possible to ensure that all such decisions are deliberate. In D such decision is done at call site which makes it very hard to review as changes are distributed everywhere. Though DScanner can possibly help here and I am really looking forward trying to it in our code control. That said, I think the main reason why this notion didn't work well for D when property was introduces is because of extremely vague range semantics. I find it important that you have mentioned exactly `front` and `popFront` as examples for unclear parens placement - problem with those is that there isn't. `front` may or may not be trivial getter depending on (sometimes arbitrary) decision by range implementor, there is no uniformity between those. Which makes impossible to enforce consistent calling style and makes "drop everything" approach much more tempting.
Very good point. I've been bitten by range semantic many times, especially map, which is lazy and does the work on front call, rather than popFront as I would have expected. Thinking about it, this is probably the right thing to do, but the range interface makes it non obvious and confusing.
Apr 13 2015
parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Monday, 13 April 2015 at 16:43:00 UTC, deadalnix wrote:
 Thinking about it, this is probably the right thing to do, but 
 the range interface makes it non obvious and confusing.
Some time ago there was a long thread about formalising the interface for ranges, i.e. a clear and precise definition of what each method should do. Was a consensus reached and documented?
Apr 13 2015
prev sibling parent reply "Araq" <rumpf_a web.de> writes:
 So, to be more specific, here is one of cases where it actually 
 caused trouble in practice. Someone has originally written code 
 that looked roughly like this:

 while (something)
 {
     // ...
     auto str = format("%s", parser.node);
 }

 Long time later I have been adding trace logs to that module 
 and this has become akin to

 while (something)
 {
     log(parser.node);
     // ...
     auto str = format("%s", parser.node);
 }

 Which resulted in broken application. It took almost an hour to 
 bisect all changed to trace the failure to this specifc line 
 and realize that `parser.node` wasn't just trivial getter but 
 method which actually advanced internal iterator to next node 
 while returning current one.
In Java many people would have done this instead: while (something) { log(parser.getNode()); // ... String str = format("%s", parser.getNode()); } Because trivial accessors are everywhere in Java one usually has to assume it has no side-effects. I fail to see the relevance of the missing () in your example; () doesn't scream side-effect in C++/Java/C#/C. The real issue here is that 'node' or 'getNode' is simply poorly named suggesting it has no side-effects. 'nextNode' for instance doesn't have this problem.
Apr 09 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 9 April 2015 at 16:12:17 UTC, Araq wrote:
 side-effect in C++/Java/C#/C. The real issue here is that 
 'node' or 'getNode' is simply poorly named suggesting it has no 
 side-effects. 'nextNode' for instance doesn't have this problem.
"next" is a common name for next-pointers. You need to pick a verb that cannot be mistaken for an adjective. E.g. "moveToNextNode". Anyway, being explicit is important for maintainability. Some language designers are very much against even overloading for this reason. There's a convenience-maintenance trade off between weakly typed implicit languages and statically/strictly/strongly typed explicit code (suitable for large vocabulary, large source base, long running). Here's the semiotics I tend to go by: - Dot-notation indicates an accessor/interface provided by the object, e.g. penetrating an encapsulation. - A parametric accessor ("()" is empty) indicates work being done using reference semantics. - Free form functions indicates value-semantics with results derived from values/objects. Consistent mapping from syntax to semantics makes for more readable and, more importantly, more easily maintainable code.
Apr 09 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/9/2015 9:12 AM, Araq wrote:
 Because trivial accessors are everywhere in Java one usually has to assume it
 has no side-effects. I fail to see the relevance of the missing () in your
 example; () doesn't scream side-effect in C++/Java/C#/C. The real issue here is
 that 'node' or 'getNode' is simply poorly named suggesting it has no
 side-effects. 'nextNode' for instance doesn't have this problem.
I agree, it seems the method is poorly named as a simple noun that implies a static computation, rather than as a verb that implies some sort of action.
Apr 09 2015
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei Alexandrescu 
wrote:
 On 4/8/15 9:53 AM, Dicebot wrote:
 On Wednesday, 8 April 2015 at 16:49:27 UTC, Dicebot wrote:
 On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei 
 Alexandrescu wrote:
 On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Yes.
And, by the way, this is not a just personal taste thing.
It is.
He is coming with actual feedback from people using D. This is not opinion, this is fact (considering he can be trusted, but then request more precise data instead of stating it is opinion).
 Considering I am far from the only person having problems
 with it in our team and such style is extremely common because 
 of being
 easy - this can easily be one of most damaging language 
 features in D in
 terms of wasted developer time.
Again trying with ad populum. Not buying it.
It is not ad populum, it is actual feedback from people using D having wasted time.
Apr 08 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
Also, I've noted the general trend lately were you seems value 
more "winning" the debate than actually coming to some conclusion.

I'm not sure what's up with that, but nothing good can come out 
of this on the long run.
Apr 08 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 1:21 PM, deadalnix wrote:
 Also, I've noted the general trend lately were you seems value more
 "winning" the debate than actually coming to some conclusion.

 I'm not sure what's up with that, but nothing good can come out of this
 on the long run.
Hmmm... Could you please give a few examples. You seem to be disproportionately sore over this specious claim of yours:
 What is a JIT if not an interpreter with hardware support ?
which I found worth spending time to refute (in hindsight, not really worth the drama). For that distraction I'm sorry. If you want to chat about improving my manners, let's talk over a coffee. I guess I'll have a little list as well :o). Andrei
Apr 08 2015
prev sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu 
wrote:
 On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions. `names.reverse` is OK, because you can imagine that `names` has a member field called `reverse` that holds it reversed(this is not really true because `names.reverse` is mutating the original array, but the point is that we are not calling `reverse` for it's side - we are only interested in it's return value). `names.reverse.writeln;` - not so much. We are not treating `writeln` as a property - we don't really care what it returns - we treat it as a method, and therefore it should use the method call syntax. In matter of fact - if `writeln` was a member field - the very same thing the combination of UFCS and property syntax is trying to emulate - this code wouldn't compile: struct Foo { string writeln; } struct Bar { Foo reverse; } void main() { Bar names; names.reverse.writeln; } source/app.d(10): Error: dotvar has no effect in expression (names.reverse.writeln)
Apr 08 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 4:15 PM, Idan Arye wrote:
 On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote:
 On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions.
It seems to be a difference without a distinction. One day I got tired of writing r.empty and r.front but r.popFront(). Furthermore I got tired to spend time thinking where I should insert parens vs. where I shouldn't. So I dropped parens from that. And then from other places. Apparently I didn't get struck by lightning where I stood. Andrei
Apr 08 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 9 April 2015 at 01:28:05 UTC, Andrei Alexandrescu 
wrote:
 On 4/8/15 4:15 PM, Idan Arye wrote:
 On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei 
 Alexandrescu wrote:
 On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions.
It seems to be a difference without a distinction. One day I got tired of writing r.empty and r.front but r.popFront(). Furthermore I got tired to spend time thinking where I should insert parens vs. where I shouldn't. So I dropped parens from that. And then from other places. Apparently I didn't get struck by lightning where I stood. Andrei
This is not about being struck by lightning. This is about being struck by the next developer who has to read your code.
Apr 09 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/9/15 10:31 AM, Idan Arye wrote:
 On Thursday, 9 April 2015 at 01:28:05 UTC, Andrei Alexandrescu wrote:
 On 4/8/15 4:15 PM, Idan Arye wrote:
 On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote:
 On 4/8/15 2:24 AM, Idan Arye wrote:
 At the very least, put () after the writelne:
No. -- Andrei
Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions.
It seems to be a difference without a distinction. One day I got tired of writing r.empty and r.front but r.popFront(). Furthermore I got tired to spend time thinking where I should insert parens vs. where I shouldn't. So I dropped parens from that. And then from other places. Apparently I didn't get struck by lightning where I stood. Andrei
This is not about being struck by lightning. This is about being struck by the next developer who has to read your code.
Apparently they didn't either. -- Andrei
Apr 09 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 08:35:52 UTC, ixid wrote:
 On Tuesday, 7 April 2015 at 19:46:07 UTC, Ary Borenszweig wrote:
 On 4/7/15 3:34 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig 
 wrote:
 On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
  name.writeln;
 }
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like "writeln" being used with UFCS, it's an abuse. My point is that every language has WATs :-)
Why is it 'an abuse'? Do you special case any other functions or is names.parallel unacceptable as well? Are longer chains ending in writeln acceptable or do you insist in putting the whole chain inside a parens writeln?
There are two main use cases for UFCS: 1) akin to extension methods in C#. It only ever makes sense to use UFCS syntax for cases where you would consider actually having method like this in used data type. 2) more readable syntax for functional style processing pipeline There is no way anyone would ever add method called "writeln" to user data type and it is clearly not pipeline function. This is plain and disgusting abuse of the syntax, I am fully with deadalnix here. For parallel it may be feasible if data set is actually intended for parallelization by design but I would personally consider that fishy too. Omitting parens from function calls with side effects is another horrible sin but that is more of a personal taste thing.
Apr 08 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 6:42 AM, Dicebot wrote:
 There is no way anyone would ever add method called "writeln" to user
 data type
File defines it.
 and it is clearly not pipeline function.
Oh but it is.
 This is plain and
 disgusting abuse of the syntax, I am fully with deadalnix here.
No. Andrei
Apr 08 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 8 April 2015 at 16:51:53 UTC, Andrei Alexandrescu 
wrote:
 File defines it.
Last time this came up on reddit, I explained that *this* was exactly why I think "string".writeln is mistaken. writeln does NOT operate on its string, it doesn't tell the string to do something, it doesn't transform the string. It tells a *File* to do something.
Apr 08 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/8/2015 9:58 AM, Adam D. Ruppe wrote:
 On Wednesday, 8 April 2015 at 16:51:53 UTC, Andrei Alexandrescu wrote:
 File defines it.
Last time this came up on reddit, I explained that *this* was exactly why I think "string".writeln is mistaken. writeln does NOT operate on its string, it doesn't tell the string to do something, it doesn't transform the string. It tells a *File* to do something.
writeln is an OutputRange. It takes its input from the pipeline and places it in a container (the screen).
Apr 08 2015
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 17:17:21 UTC, Walter Bright wrote:
 On 4/8/2015 9:58 AM, Adam D. Ruppe wrote:
 On Wednesday, 8 April 2015 at 16:51:53 UTC, Andrei 
 Alexandrescu wrote:
 File defines it.
Last time this came up on reddit, I explained that *this* was exactly why I think "string".writeln is mistaken. writeln does NOT operate on its string, it doesn't tell the string to do something, it doesn't transform the string. It tells a *File* to do something.
writeln is an OutputRange. It takes its input from the pipeline and places it in a container (the screen).
But it is actually a method of stdout file, which was what Adam has pointed out. Hiding it behind free function and abusing that fact for UFCS is just mixing semantics and, well, abuse.
Apr 08 2015
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 8 April 2015 at 17:17:21 UTC, Walter Bright wrote:
 writeln is an OutputRange.
No, it isn't. It isn't even remotely close to one - an OutputRange is a type, writeln is a function. isOutputRange doesn't even return false for it, it outright fails to compile! File isn't an output range either btw. An output range is defined by the presence of a put method, which File doesn't have. b.d(4): Error: static assert (isOutputRange!(File, char)) is false Even putting aside the formal definition of output range, output is NOT part of the pipeline! Pipelines can be composed and they keep pumping data through them. writeln does not transform its input nor does it forward it to the next item in the pipe. It just eats it. That's totally different than everything else in the sequence. And that's not even bringing in writeln's sister function, writefln, whose first argument isn't what is to be printed at all! (it can show something to print but passing arbitrary strings to writef as the first argument is a major program bug, you should never do it)
Apr 08 2015
next sibling parent reply "ixid" <adamsibson hotmail.com> writes:
 Even putting aside the formal definition of output range, 
 output is NOT part of the pipeline! Pipelines can be composed 
 and they keep pumping data through them. writeln does not 
 transform its input nor does it forward it to the next item in 
 the pipe. It just eats it.
"nor does it forward it to the next item in the pipe" This is something I think writeln should do and have suggested before. It would be useful for debugging pipelines to be able to drop in writeln in the middle of the pipeline and pass on the data unchanged.
Apr 08 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 17:41:01 UTC, ixid wrote:
 Even putting aside the formal definition of output range, 
 output is NOT part of the pipeline! Pipelines can be composed 
 and they keep pumping data through them. writeln does not 
 transform its input nor does it forward it to the next item in 
 the pipe. It just eats it.
"nor does it forward it to the next item in the pipe" This is something I think writeln should do and have suggested before. It would be useful for debugging pipelines to be able to drop in writeln in the middle of the pipeline and pass on the data unchanged.
http://dlang.org/library/std/range/tee.html ?
Apr 08 2015
parent "ixid" <adamsibson hotmail.com> writes:
On Wednesday, 8 April 2015 at 17:43:27 UTC, Dicebot wrote:
 On Wednesday, 8 April 2015 at 17:41:01 UTC, ixid wrote:
 Even putting aside the formal definition of output range, 
 output is NOT part of the pipeline! Pipelines can be composed 
 and they keep pumping data through them. writeln does not 
 transform its input nor does it forward it to the next item 
 in the pipe. It just eats it.
"nor does it forward it to the next item in the pipe" This is something I think writeln should do and have suggested before. It would be useful for debugging pipelines to be able to drop in writeln in the middle of the pipeline and pass on the data unchanged.
http://dlang.org/library/std/range/tee.html ?
Thanks, I wasn't aware of that function. Will use that.
Apr 08 2015
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 8 April 2015 at 17:41:01 UTC, ixid wrote:
 It would be useful for debugging pipelines to be able to drop 
 in writeln in the middle of the pipeline and pass on the data 
 unchanged.
That might be useful for debugging but I'd also be annoyed if someone used that in production code too because then your pipeline would have global side effects!
Apr 08 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/8/2015 10:33 AM, Adam D. Ruppe wrote:
 On Wednesday, 8 April 2015 at 17:17:21 UTC, Walter Bright wrote:
 writeln is an OutputRange.
No, it isn't. It isn't even remotely close to one - an OutputRange is a type,
I meant an instance of a type, as in: i is an int meaning i has type int.
 writeln is a function. isOutputRange doesn't even return false for it, it
 outright fails to compile!
I understand that a true OutputRange would require one to write: arg.copy(writeln); and that a common idiom is to write it so the copy() can be implicit. I haven't made up my mind as to the right style here.
 File isn't an output range either btw. An output range is defined by the
 presence of a put method, which File doesn't have.

 b.d(4): Error: static assert  (isOutputRange!(File, char)) is false


 Even putting aside the formal definition of output range, output is NOT part of
 the pipeline! Pipelines can be composed and they keep pumping data through
them.
An output range is the caboose of a pipeline (to mix metaphors).
 writeln does not transform its input nor does it forward it to the next item in
 the pipe. It just eats it.
It places its input into a container.
 That's totally different than everything else in the sequence. And that's not
 even bringing in writeln's sister function, writefln, whose first argument
isn't
 what is to be printed at all!
It's true that a lot of Phobos code was designed pre-ranges, and the parameters aren't set up ideally for it. I've been doing some work to fix that.
Apr 08 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 16:51:53 UTC, Andrei Alexandrescu 
wrote:
 and it is clearly not pipeline function.
Oh but it is.
Oh really? And what does it transform the input data to? Just to be clear - I wouldn't allow range.copy(stdout) in my projects either, requiring any consumer to be written as dedicated expression.
Apr 08 2015
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 8 April 2015 at 16:59:27 UTC, Dicebot wrote:
 Just to be clear - I wouldn't allow range.copy(stdout) in my 
 projects either, requiring any consumer to be written as 
 dedicated expression.
Worth noting that std.range.put's documentation also says use the freestanding syntax. (This is surely to avoid ambiguity with member puts on output ranges, but still.)
Apr 08 2015
prev sibling next sibling parent "ixid" <adamsibson hotmail.com> writes:
On Tuesday, 7 April 2015 at 18:34:01 UTC, deadalnix wrote:
 On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
 On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
   name.writeln;
 }
no.please
wat
unreadable.is.ufcs.using.over
UFCS doesn't give you yoda speak. It's more consistent to use it for single as well as multiple function chains and it's cleaner. Some users' distaste for UFCS cramps D's developing its own consistent idiomatic approach. Do you have any argument for your dislike that isn't just personal preference? You're fine with names.parallel but for some reason balk at name.writeln?
Apr 08 2015
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 7 April 2015 at 18:34:01 UTC, deadalnix wrote:
 On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
 On 4/7/15 2:16 PM, deadalnix wrote:
 On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
 Or to be more consistent with UFCS:

 foreach (name; names.parallel) {
   name.writeln;
 }
no.please
wat
unreadable.is.ufcs.using.over
I love UFCS. I'd definitely write names.parallel myself. Atila
Apr 08 2015
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
deadalnix:

 foreach (name; names.parallel) {
    name.writeln;
 }
no.please
I think "foo.writeln;" is acceptable. You just need to get a bit used to it. Bye, bearophile
Apr 08 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 13:52:22 UTC, bearophile wrote:
 deadalnix:

 foreach (name; names.parallel) {
   name.writeln;
 }
no.please
I think "foo.writeln;" is acceptable. You just need to get a bit used to it. Bye, bearophile
No.
Apr 08 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/15 7:00 AM, Dicebot wrote:
 On Wednesday, 8 April 2015 at 13:52:22 UTC, bearophile wrote:
 deadalnix:

 foreach (name; names.parallel) {
   name.writeln;
 }
no.please
I think "foo.writeln;" is acceptable. You just need to get a bit used to it. Bye, bearophile
No.
Ja, ja, ja. -- Andrei
Apr 08 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 8 April 2015 at 13:52:22 UTC, bearophile wrote:
 I think "foo.writeln;" is acceptable. You just need to get a 
 bit used to it.
The whole dot-notation for pipelining is semantically flawed en relies on knowing what names stand for rather than more universal symbols with known interpretations. It has been (ab)used quite a bit in OO-libraries for other languages, for chaining, which can be rather confusing when you use many libraries. Dedicated pipeline operators look much better ("input->process->output"). Add dataflow with multiple paths and high level optimization, then you have something.
Apr 08 2015
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 8 April 2015 at 14:57:15 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 8 April 2015 at 13:52:22 UTC, bearophile wrote:
 I think "foo.writeln;" is acceptable. You just need to get a 
 bit used to it.
The whole dot-notation for pipelining is semantically flawed en relies on knowing what names stand for rather than more universal symbols with known interpretations. It has been (ab)used quite a bit in OO-libraries for other languages, for chaining, which can be rather confusing when you use many libraries. Dedicated pipeline operators look much better ("input->process->output"). Add dataflow with multiple paths and high level optimization, then you have something.
I kind of agree with this one. Range based pipeline has established rather late as core D idiom but in general it is distinct enough to warrant own syntax.
Apr 08 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-04-07 01:51, Adam Hawkins wrote:

 Only trade off in the Ruby case is metaprogramming.
You can do metaprogramming in D, it's just a bit different compared to Ruby. -- /Jacob Carlborg
Apr 06 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 06 Apr 2015 23:51:16 +0000, Adam Hawkins wrote:

 I've been reading the forums here so I can see that there is a focus on
 improving the marketing for the language and growing the community. I
 see most of the effort is geared towards C++ programmers, but have you
 considered looking at us dynamic languages folk?
it seems that there are not so many people that comes from some dynamic=20 language. i believe that most of us using c/c++ (c#/java/etc.), so while=20 we know bits and pieces about dynamic land, we generally not using it for=20 something "serious" (unless we are forced to do so ;-).
 Regardless, I figured it might be interesting to hear about some
 experience coming to the language from a different perspective.
sure. you're welcome, it's always good to have more opinions, both=20 positive (yay!) and negative (heh... so what we can do with that?).=
Apr 07 2015
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 6 April 2015 at 23:51:17 UTC, Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum. I've been 
 investigating the language for the past few weeks. I was able 
 to complete my first useful program thanks to very helpful 
 people in #d on IRC . The experience made me very interested in 
 the language and improving the community around it.

 I'm primarily Ruby developer (been so about the last 7-8 years) 
 doing web stuff with significant JavaScript work as well. I 
 wrote a blog post on why I'm excited about D. You can read it 
 here: http://hawkins.io/2015/04/excited-about-d/.

 I've been reading the forums here so I can see that there is a 
 focus on improving the marketing for the language and growing 
 the community. I see most of the effort is geared towards C++ 
 programmers, but have you considered looking at us dynamic 
 languages folk? I see a big upside for us. Moving from Ruby to 
 D (my case) gives me power & performance. I still have OOP 
 techniques but I still have functional things like closures and 
 all that good stuff. Only trade off in the Ruby case is 
 metaprogramming. All in all I think there is a significant 
 value promise for those of us doing backend services for folks 
 like me.

 Regardless, I figured it might be interesting to hear about 
 some experience coming to the language from a different 
 perspective. Cheers!
This is awesome :) A few notes on the blog: "peaked my interest" should be "piqued my interest" You can have as many unittest blocks as you want in a file/module. property isn't really about parentheses-less calls (parentheses are optional for all function calls), it's more for this sort of thing: struct S { private int a_; enum flagMask = 1u << 31; property void val(int v) { a_ = (a_ & flagMask) & (v & ~flagMask); } property int val() { return a_ & ~flagMask; } property void flag(bool b) { a_ = ((cast(uint)b) << 31) & (a_ & ~mask); } property bool flag() { return a_ & flagMask; } } unittest { S s; s.flag = true; s.val = 75; assert(s.flag); assert(s.val == 75); } Note that the assignments are calling the property functions.
Apr 07 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-04-07 10:33, John Colvin wrote:

 (parentheses are optional for all function calls),
Optional for all function calls taking no arguments. Note that in Ruby parentheses are optional for function calls taking arguments as well. -- /Jacob Carlborg
Apr 07 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 7 April 2015 at 11:16:56 UTC, Jacob Carlborg wrote:
 On 2015-04-07 10:33, John Colvin wrote:

 (parentheses are optional for all function calls),
Optional for all function calls taking no arguments. Note that in Ruby parentheses are optional for function calls taking arguments as well.
Sorry, yes my mistake
Apr 07 2015
prev sibling parent reply "Jens Bauer" <doctor who.no> writes:
On Tuesday, 7 April 2015 at 08:33:58 UTC, John Colvin wrote:
  property isn't really about parentheses-less calls 
 (parentheses are optional for all function calls), it's more 
 for this sort of thing:
 [snip]
      property void val(int v)
     {
         a_ = (a_ & flagMask) & (v & ~flagMask);
     }
This is *really* cool and very useful on microcontrollers and is superior to C's bit-fields. Imagine that your microcontroller has 24 GPIO pins. Such pins are usually grouped in 'ports', for instance Port A and Port B. Each port could for instance support up to 32 pins: PA0 ... PA31 and PB0 ... PB31. But there's a problem here: Our microcontroller has only 24 pins, and our microcontroller vendor chose to make the following pins available to us: PA1 ... PA5, PA7, PA13, PA17, PA18 .. PA19, PA23 ... PA28 PB0 ... PB3, PB8 ... PB12 Every developer will think this is annoying. We want to write a byte to a port, but it has to be converted first. If just incrementing a value, one could do as follows: PortB = (PortB | 0x00f0) + 1; ... oposite for decrementing: PortB = (PortB & 0xff0f) - 1; But the property can make all this transparent, so our sources become very easy to overview and understand.
Apr 07 2015
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 7 April 2015 at 14:20:58 UTC, Jens Bauer wrote:
 On Tuesday, 7 April 2015 at 08:33:58 UTC, John Colvin wrote:
  property isn't really about parentheses-less calls 
 (parentheses are optional for all function calls), it's more 
 for this sort of thing:
 [snip]
     property void val(int v)
    {
        a_ = (a_ & flagMask) & (v & ~flagMask);
    }
This is *really* cool and very useful on microcontrollers and is superior to C's bit-fields. Imagine that your microcontroller has 24 GPIO pins. Such pins are usually grouped in 'ports', for instance Port A and Port B. Each port could for instance support up to 32 pins: PA0 ... PA31 and PB0 ... PB31. But there's a problem here: Our microcontroller has only 24 pins, and our microcontroller vendor chose to make the following pins available to us: PA1 ... PA5, PA7, PA13, PA17, PA18 .. PA19, PA23 ... PA28 PB0 ... PB3, PB8 ... PB12 Every developer will think this is annoying. We want to write a byte to a port, but it has to be converted first. If just incrementing a value, one could do as follows: PortB = (PortB | 0x00f0) + 1; ... oposite for decrementing: PortB = (PortB & 0xff0f) - 1; But the property can make all this transparent, so our sources become very easy to overview and understand.
and, for convenience there is http://dlang.org/phobos/std_bitmanip.html#.bitfields
Apr 07 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 07 Apr 2015 14:20:57 +0000, Jens Bauer wrote:

 If just incrementing a value, one could do as follows:
 PortB =3D (PortB | 0x00f0) + 1;
 ... oposite for decrementing:
 PortB =3D (PortB & 0xff0f) - 1;
=20
 But the  property can make all this transparent, so our sources become
 very easy to overview and understand.
and gcc can optimise function calls away (especially with=20 ` attribute("forceinline")`), so it effectively compiles to the same code.=
Apr 07 2015
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/6/15 4:51 PM, Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum. I've been
 investigating the language for the past few weeks. I was able to
 complete my first useful program thanks to very helpful people in #d on
 IRC . The experience made me very interested in the language and
 improving the community around it.
[snip] http://www.reddit.com/r/programming/comments/31rdp1/excited_about_d/ https://twitter.com/D_Programming/status/585472101349462020 https://www.facebook.com/dlang.org/posts/1046466315367049 Share away! Andrei
Apr 07 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2015 4:51 PM, Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum. I've been investigating the
 language for the past few weeks. I was able to complete my first useful program
 thanks to very helpful people in #d on IRC . The experience made me very
 interested in the language and improving the community around it.

 I'm primarily Ruby developer (been so about the last 7-8 years) doing web stuff
 with significant JavaScript work as well. I wrote a blog post on why I'm
excited
 about D. You can read it here: http://hawkins.io/2015/04/excited-about-d/.

 I've been reading the forums here so I can see that there is a focus on
 improving the marketing for the language and growing the community. I see most
 of the effort is geared towards C++ programmers, but have you considered
looking
 at us dynamic languages folk? I see a big upside for us. Moving from Ruby to D
 (my case) gives me power & performance. I still have OOP techniques but I still
 have functional things like closures and all that good stuff. Only trade off in
 the Ruby case is metaprogramming. All in all I think there is a significant
 value promise for those of us doing backend services for folks like me.

 Regardless, I figured it might be interesting to hear about some experience
 coming to the language from a different perspective. Cheers!
This is a nice article, thanks! I noticed a bug in one of the examples: assert("Adam Hawkins" == myName()); should be: assert("Adam Hawkins" == myName());
Apr 07 2015
next sibling parent reply "Jens Bauer" <doctor who.no> writes:
On Tuesday, 7 April 2015 at 16:29:40 UTC, Walter Bright wrote:
 I noticed a bug in one of the examples:

   assert("Adam Hawkins" == myName());

 should be:

   assert("Adam Hawkins" == myName());
-It already is. :) By the way; the reason to switch from C to D can be put *very* simple: :C -> :D ... or if you prefer the longer version: :-C -> :-D
Apr 07 2015
parent "Jens Bauer" <doctor who.no> writes:
On Tuesday, 7 April 2015 at 16:39:39 UTC, Jens Bauer wrote:
  :C  ->  :D
Even better (includes the meaning of '=' in place of 'when'): =C -> =D
Apr 07 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2015 9:28 AM, Walter Bright wrote:
 I noticed a bug in one of the examples:

    assert("Adam Hawkins" == myName());
er, the example is: assert("Adam Hawkins" = myName());
 should be:

    assert("Adam Hawkins" == myName());
Apr 07 2015
parent reply "bachmeier" <no spam.com> writes:
On Tuesday, 7 April 2015 at 17:03:55 UTC, Walter Bright wrote:
 On 4/7/2015 9:28 AM, Walter Bright wrote:
 I noticed a bug in one of the examples:

   assert("Adam Hawkins" == myName());
er, the example is: assert("Adam Hawkins" = myName());
 should be:

   assert("Adam Hawkins" == myName());
You're such a good programmer that you can't write code with a bug in it even if you try.
Apr 07 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2015 10:33 AM, bachmeier wrote:
 You're such a good programmer that you can't write code with a bug in it even
if
 you try.
We're all susceptible to making certain types of errors. Over time, we learn to compensate for those errors, and don't make them any more. I can't remember the last time I made the = == mistake. It's probably why that error in the article glared out at me. If you really want to mess with my head, design a language with = and == reversed.
Apr 07 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Apr 07, 2015 at 11:04:35AM -0700, Walter Bright via Digitalmars-d wrote:
 On 4/7/2015 10:33 AM, bachmeier wrote:
You're such a good programmer that you can't write code with a bug in
it even if you try.
We're all susceptible to making certain types of errors. Over time, we learn to compensate for those errors, and don't make them any more. I can't remember the last time I made the = == mistake. It's probably why that error in the article glared out at me. If you really want to mess with my head, design a language with = and == reversed.
Actually, I find the current use of = vs. == in programming languages rather counterintuitive, even though I myself have become accustomed to it as you have. If I were ever to invent my own programming language, I'd use = for equality and := for assignment. (I wouldn't include ==, though; I think it's an eyesore.) T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Apr 07 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 7 April 2015 at 18:21:44 UTC, H. S. Teoh wrote:
 Actually, I find the current use of = vs. == in programming 
 languages
 rather counterintuitive, even though I myself have become 
 accustomed to
 it as you have. If I were ever to invent my own programming 
 language,
 I'd use = for equality and := for assignment. (I wouldn't 
 include ==,
 though; I think it's an eyesore.)
Simula uses =, <=, >=, <> for value comparison. For references comparison: ==, =/=. Value assignment is done with := and :- is used for reference assignment. I am not sure if I like the visual confusion of references and values in languages like C# and D, but I am also not happy about having to type *this in C++... With reference operators you bypass all the dereferencing clutter.
Apr 07 2015
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 4/6/15 8:51 PM, Adam Hawkins wrote:
 Hello everyone, this is my first post on the forum. I've been
 investigating the language for the past few weeks. I was able to
 complete my first useful program thanks to very helpful people in #d on
 IRC . The experience made me very interested in the language and
 improving the community around it.

 I'm primarily Ruby developer (been so about the last 7-8 years) doing
 web stuff with significant JavaScript work as well. I wrote a blog post
 on why I'm excited about D. You can read it here:
 http://hawkins.io/2015/04/excited-about-d/.

 I've been reading the forums here so I can see that there is a focus on
 improving the marketing for the language and growing the community. I
 see most of the effort is geared towards C++ programmers, but have you
 considered looking at us dynamic languages folk? I see a big upside for
 us. Moving from Ruby to D (my case) gives me power & performance. I
 still have OOP techniques but I still have functional things like
 closures and all that good stuff. Only trade off in the Ruby case is
 metaprogramming. All in all I think there is a significant value promise
 for those of us doing backend services for folks like me.

 Regardless, I figured it might be interesting to hear about some
 experience coming to the language from a different perspective. Cheers!
"Ruby was never intended to be correct" -> I think Ruby is the most correct language I've seen around. ~~~ a = [] a << a p a #=> [[...]] p a == a[0] #=> true ~~~ This is just an example. Using Ruby and reading its source code I found so many things that they get right, like border-cases, that I'm surprised you say that. It's true that Ruby is slow, but only because their priority is correctness.
Apr 07 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 7 April 2015 at 17:46:45 UTC, Ary Borenszweig wrote:
 It's true that Ruby is slow, but only because their priority is 
 correctness.
https://www.destroyallsoftware.com/talks/wat
Apr 07 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-04-07 19:53, deadalnix wrote:

 https://www.destroyallsoftware.com/talks/wat
That is mostly for JavaScript. -- /Jacob Carlborg
Apr 08 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-04-07 19:46, Ary Borenszweig wrote:

 It's true that Ruby is slow, but only because their priority is
 correctness.
I don't think it's so much about the correctness, it's rather the complicated features it supports, like metaprogramming. eval and bindings are causing problems, also promoting Fixnum to Bignum when it doesn't fit is a problem. I also read somewhere that since you can replace any method in Ruby, all calls to a method needs to check if the method has been replaced. Here's a blog that talks about the problems of optimizing Ruby [1] [1] http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby.html -- /Jacob Carlborg
Apr 08 2015
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 4/8/15 4:59 AM, Jacob Carlborg wrote:
 On 2015-04-07 19:46, Ary Borenszweig wrote:

 It's true that Ruby is slow, but only because their priority is
 correctness.
I don't think it's so much about the correctness, it's rather the complicated features it supports, like metaprogramming. eval and bindings are causing problems, also promoting Fixnum to Bignum when it doesn't fit is a problem.
The autopromotion of Fixnum to Bignum is interesting. It always leads to correct code, although it's slow. Without this feature you start to realize how week are other languages. For example, take the simple problem of parsing a number out of a string. In Ruby it's: "123".to_i #=> 123 But this also works: "12398123091823091823091823091823091820318203123".to_i #=> 12398123091823091823091823091823091820318203123 In typed language one would be forced to make a decision for the return type of to_i. Maybe if it doesn't fit in an Int32 or Int64 raise an exception or signal an error somehow. In Ruby you just forget about these little problems, it will always work and give the correct result. That's one of the reasons I think it's bad to say that Ruby is not a "correct" language.
Apr 08 2015