www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D benchmark code review

reply "logicchains" <jonathan.t.barnard gmail.com> writes:
I've posted a couple of benchmarks involving D previously and 
received complaints that the D implementation was ugly and 
un-idiomatic, so I thought I'd seek code review before posting 
the next one. The code is at 
https://github.com/logicchains/ParticleBench/blob/master/D.d; 
it's an OpenGL particle animation, and my D code is essentially 
just a direct port of the C implementation. Note however that, as 
the animation is gpu-bound, there's not much scope for 
optimisation of the code (in hindsight, it was a pretty poor 
topic for a benchmark, but hindsight always sees farthest and 
whatnot).
Dec 13 2013
next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 13 December 2013 at 12:41:53 UTC, logicchains wrote:
 I've posted a couple of benchmarks involving D previously and 
 received complaints that the D implementation was ugly and 
 un-idiomatic, so I thought I'd seek code review before posting 
 the next one. The code is at 
 https://github.com/logicchains/ParticleBench/blob/master/D.d; 
 it's an OpenGL particle animation, and my D code is essentially 
 just a direct port of the C implementation. Note however that, 
 as the animation is gpu-bound, there's not much scope for 
 optimisation of the code (in hindsight, it was a pretty poor 
 topic for a benchmark, but hindsight always sees farthest and 
 whatnot).
You have a lot of global variables of same type. With very similar default values. Example windX and runTmr. They are both doubles. Perhaps an alternative way to write it is like this: double windX = 0, runTmr = 0; You also have a lot of enums that like WIDTH and HEIGHT that could be transformed into a single enum. e.g. enum int WIDTH = 800; enum int HEIGHT = 600; Would become: enum : int { WIDTH = 800, HEIGHT = 600 } Adds a couple extra lines but hey when you got 20 odd values and repeating the type it kinda looks ugly. Nothing really huge to say. I would say not use e.g. Derelict for bindings but when you're not timing that then no point. Also check your formatting currently its not consistent. There is some brackets with and without spaces before / after. Otherwise not too badly done.
Dec 13 2013
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Rikki Cattermole" <alphaglosined gmail.com> wrote in message 
news:otjpativnfoecwjqethp forum.dlang.org...
 You have a lot of global variables of same type. With very similar default 
 values.
 Example windX and runTmr. They are both doubles.

 Perhaps an alternative way to write it is like this:
 double
  windX = 0,
  runTmr = 0;

 You also have a lot of enums that like WIDTH and HEIGHT that could be 
 transformed into a single enum.
 e.g.
 enum int WIDTH = 800;
 enum int HEIGHT = 600;

 Would become:
 enum : int {
  WIDTH = 800,
  HEIGHT = 600
 }

 Adds a couple extra lines but hey when you got 20 odd values and repeating 
 the type it kinda looks ugly.
I would not consider either of those an improvement.
Dec 13 2013
next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 13 December 2013 at 13:34:07 UTC, Daniel Murphy wrote:
 "Rikki Cattermole" <alphaglosined gmail.com> wrote in message
 news:otjpativnfoecwjqethp forum.dlang.org...
 You have a lot of global variables of same type. With very 
 similar default values.
 Example windX and runTmr. They are both doubles.

 Perhaps an alternative way to write it is like this:
 double
  windX = 0,
  runTmr = 0;

 You also have a lot of enums that like WIDTH and HEIGHT that 
 could be transformed into a single enum.
 e.g.
 enum int WIDTH = 800;
 enum int HEIGHT = 600;

 Would become:
 enum : int {
  WIDTH = 800,
  HEIGHT = 600
 }

 Adds a couple extra lines but hey when you got 20 odd values 
 and repeating the type it kinda looks ugly.
I would not consider either of those an improvement.
Depends on style I guess. To me its less to read so = good.
Dec 13 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-12-13 14:47, Rikki Cattermole wrote:

 Depends on style I guess. To me its less to read so = good.
It's two additional lines == more to read :) -- /Jacob Carlborg
Dec 13 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 December 2013 at 13:34:07 UTC, Daniel Murphy wrote:
 I would not consider either of those an improvement.
Longer code with less data duplication is better than shorter one with copy-paste.
Dec 13 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
On 13 December 2013 23:34, Daniel Murphy <yebblies nospamgmail.com> wrote:

 "Rikki Cattermole" <alphaglosined gmail.com> wrote in message
 news:otjpativnfoecwjqethp forum.dlang.org...
 You have a lot of global variables of same type. With very similar
default
 values.
 Example windX and runTmr. They are both doubles.

 Perhaps an alternative way to write it is like this:
 double
  windX = 0,
  runTmr = 0;

 You also have a lot of enums that like WIDTH and HEIGHT that could be
 transformed into a single enum.
 e.g.
 enum int WIDTH = 800;
 enum int HEIGHT = 600;

 Would become:
 enum : int {
  WIDTH = 800,
  HEIGHT = 600
 }

 Adds a couple extra lines but hey when you got 20 odd values and
repeating
 the type it kinda looks ugly.
I would not consider either of those an improvement.
Me either.
Dec 13 2013
prev sibling parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Friday, 13 December 2013 at 13:24:43 UTC, Rikki Cattermole 
wrote:
 Perhaps an alternative way to write it is like this:
 double
  windX = 0,
  runTmr = 0;

 You also have a lot of enums that like WIDTH and HEIGHT that 
 could be transformed into a single enum.
 e.g.
 enum int WIDTH = 800;
 enum int HEIGHT = 600;

 Would become:
 enum : int {
  WIDTH = 800,
  HEIGHT = 600
 }
I didn't realise D could do that; I've updated the code to use that style of variable declaration. It's interesting to be able to declare two arrays at once like so: double[RUNNING_TIME * 1000] frames, gpuTimes; Is there some way to initialise multiple values to zero without writing the zero more than once, so that the following only needs one zero: double windX = 0, runTmr = 0; I am timing, there just isn't much different in results between the different implementations. Why would you say not to use Derelict for bindings?
Dec 13 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 13.12.2013 14:56, schrieb logicchains:
 I didn't realise D could do that; I've updated the code to use
 that style of variable declaration. It's interesting to be able
 to declare two arrays at once like so:
please revert - it looks terrible newbie like, no one except Rikki writes it like this it makes absolutely no sense to pseudo-scope these enums and variable declarations, they do not share anything except the type AND that is not enough for pseudo-scope
Dec 13 2013
next sibling parent "logicchains" <jonathan.t.barnard gmail.com> writes:
On Friday, 13 December 2013 at 15:58:43 UTC, dennis luehring 
wrote:
 please revert - it looks terrible newbie like, no one except 
 Rikki writes it like this

 it makes absolutely no sense to pseudo-scope these enums and 
 variable declarations, they do not share anything except the 
 type AND that is not enough for pseudo-scope
I thought it seemed useful in that it'd make it easier to e.g. change all those doubles to floats. If it's generally considered unidiomatic D, however, then I can revert it. On Friday, 13 December 2013 at 16:06:10 UTC, Manu wrote:
 Is it idiomatic to use egyptian braces in D? I've never seen D 
 code written
 this way... looks like Java.
It's just the style I've been using in the benchmark; even the lisp implementations use it. I think it's due to the influence of programming in Go, where that style is mandated (the compiler throws an error if you put a newline before the {).
 You have a lot of globals, and they're all TLS. That seems 
 inefficient, and
 potentially incorrect if there were threads.
You're right; I just copied the C code, I didn't consider that it being TLS in D might reduce efficiency. I don't mind it not being threadsafe, as I don't have any intention to parallelise the benchmark, due to most of the time being spent on rendering that can't be parallelised.
 Why do you build the vertex array from literal data at runtime? 
 Why not
 just initialise the array?
 It's a static array, so it's not allocated at runtime, so it 
 shouldn't be
 any different. You'd probably save a lot of LOC to initialise 
 the array,
 perhaps better for clarity. It should probably also be 
 immutable?
I left initialising the array to runtime for clarity; I think it's easier to read that way than if it's just declared as a really long array literal. I'd be happy to populate the array at compile time though, if there's an easy way to change the initialisation functions to run at compile time. Making it immutable is a good idea, although it wouldn't help performance as the array is only read once, when it's being fed into the vertex buffer.
 Those integer for loops might be nicer as: foreach(i; 0 .. n)
Updated it to use that. I was wondering how to do foreach over a numerical range in D; now I know, thanks.
 I'm not personally in the camp that agrees:
   double
     x = 0,
     y = 10,
     z = 15;
 is a good thing... but each to their own :)
I just assumed it'd be better as it allows for easier refactoring (only need to change 'double' one).
 Why are you using 'double' in realtime software? That's weird 
 isn't it?
 Granted, it will make no difference on x86, but I'd never 
 personally do
 this for portability reasons.
Because in my previous benchmarks I've found it performs no differently from float on this system, and because it's a direct port of the C implementation, where I paranoidly used double in order to avoid precision errors if it's ever run on a system where float is 16 bit. It also makes for fairer comparison with the Go code, which uses 64 bit floats as the standard maths library doesn't support f32s.
 But generally looks fine. Any opengl code is naturally going to 
 look C-ish
 by nature. And yes, as you said, it's not really a very good 
 benchmark,
 since you're really benchmarking the GPU (and the legacy 
 fallback
 non-shader pipeline at that) ;) .. The mainloop barely does 
 anything, and
 has very few iterations.
Yep. I tried with shaders but it didn't really improve the speed at all, as most of the time's spent rendering, so I'm using the legacy pipeline for convenience.
 Nitpick: I think properness would have you update the velocity 
 before the
 position, or you'll always run 1 frame behind.
 There are a lot more really minor performance hazards that I'd 
 never let
 slip if they were invoked in hot loops, but they won't make any 
 difference
 here.
You're right; I've reordered doWind, checkColls and movePts. Thanks for all the tips! On Friday, 13 December 2013 at 14:45:49 UTC, qznc wrote:
 Use std.algorithm instead of for-loops for sum calculation:

 sum = reduce!"a + b"(0, frames);
I tried 'auto sum = reduce!"a + b"(0, frames);' but I get an error: algorithm.d(782): Error: cannot implicitly convert expression (binaryFun(result._expand_field_0, elem)) of type double to int std/conv.d(3606): Error: cannot implicitly convert expression (_param_1) of type double to int algorithm.d(794): Error: template instance std.conv.emplace!(int, double) error instantiating D.d(308): instantiated from here: reduce!(int, double[25000LU])
Dec 13 2013
prev sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 13 December 2013 at 15:58:43 UTC, dennis luehring 
wrote:
 Am 13.12.2013 14:56, schrieb logicchains:
 I didn't realise D could do that; I've updated the code to use
 that style of variable declaration. It's interesting to be able
 to declare two arrays at once like so:
please revert - it looks terrible newbie like, no one except Rikki writes it like this it makes absolutely no sense to pseudo-scope these enums and variable declarations, they do not share anything except the type AND that is not enough for pseudo-scope
Honestly I've never written code like that. But then again I've never had 10+ constants of same type in one file before... For me personally its easier to read as not having the type duplicated. I'd rather read it once and keep it in mind for a whole block of them. But I don't mind being unique in this way.
Dec 13 2013
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Saturday, 14 December 2013 at 05:44:43 UTC, Rikki Cattermole 
wrote:
 Honestly I've never written code like that. But then again I've 
 never had 10+ constants of same type in one file before...
 For me personally its easier to read as not having the type 
 duplicated. I'd rather read it once and keep it in mind for a 
 whole block of them. But I don't mind being unique in this way.
I realised it was possible to use untyped constants in D and removed the types, allowing me to declare all the constants in a single enum. Now it looks quite similar to the Go constant declarations.
Dec 13 2013
parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Saturday, 14 December 2013 at 06:23:28 UTC, logicchains wrote:
 On Saturday, 14 December 2013 at 05:44:43 UTC, Rikki Cattermole 
 wrote:
 Honestly I've never written code like that. But then again 
 I've never had 10+ constants of same type in one file before...
 For me personally its easier to read as not having the type 
 duplicated. I'd rather read it once and keep it in mind for a 
 whole block of them. But I don't mind being unique in this way.
I realised it was possible to use untyped constants in D and removed the types, allowing me to declare all the constants in a single enum. Now it looks quite similar to the Go constant declarations.
Personally for me its going a little far just having enum { with multiple types being used as a value. But hey as long as everyone can understand it, no problems!
Dec 14 2013
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Saturday, 14 December 2013 at 09:09:21 UTC, Rikki Cattermole 
wrote:
 Personally for me its going a little far just having enum { 
 with multiple types being used as a value. But hey as long as 
 everyone can understand it, no problems!
I prefer untyped constants as they can be used as different types in different places, like #define'd constants in C. If constants are too strongly typed, it can lead to awkward situations such as in the Rust code where two constants for the same value were used in order to avoid a heap of ugly casts: static StartRangei : u32 = 15; static StartRangef : f64 = StartRangei as f64;
Dec 14 2013
parent reply Mike Parker <aldacron gmail.com> writes:
On 12/14/2013 7:45 PM, logicchains wrote:
 On Saturday, 14 December 2013 at 09:09:21 UTC, Rikki Cattermole wrote:
 Personally for me its going a little far just having enum { with
 multiple types being used as a value. But hey as long as everyone can
 understand it, no problems!
I prefer untyped constants as they can be used as different types in different places, like #define'd constants in C. If constants are too strongly typed, it can lead to awkward situations such as in the Rust code where two constants for the same value were used in order to avoid a heap of ugly casts: static StartRangei : u32 = 15; static StartRangef : f64 = StartRangei as f64;
There's no such thing as an untyped constant in D. If you don't specify a type, it will auto infer the type of anything you assign it. If there's no value assigned, it defaults to int.
Dec 14 2013
parent "logicchains" <jonathan.t.barnard gmail.com> writes:
On Saturday, 14 December 2013 at 12:46:43 UTC, Mike Parker wrote:
 There's no such thing as an untyped constant in D. If you don't 
 specify a type, it will auto infer the type of anything you 
 assign it. If there's no value assigned, it defaults to int.
Oh, thanks for clarifying that.
Dec 14 2013
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Friday, 13 December 2013 at 12:41:53 UTC, logicchains wrote:
 I've posted a couple of benchmarks involving D previously and 
 received complaints that the D implementation was ugly and 
 un-idiomatic, so I thought I'd seek code review before posting 
 the next one. The code is at 
 https://github.com/logicchains/ParticleBench/blob/master/D.d; 
 it's an OpenGL particle animation, and my D code is essentially 
 just a direct port of the C implementation. Note however that, 
 as the animation is gpu-bound, there's not much scope for 
 optimisation of the code (in hindsight, it was a pretty poor 
 topic for a benchmark, but hindsight always sees farthest and 
 whatnot).
Use std.algorithm instead of for-loops for sum calculation: sum = reduce!"a + b"(0, frames); I don't think you can do much about it. Most code is just OpenGL API boilerplate or game logic.
Dec 13 2013
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 13 December 2013 22:41, logicchains <jonathan.t.barnard gmail.com> wrote:

 I've posted a couple of benchmarks involving D previously and received
 complaints that the D implementation was ugly and un-idiomatic, so I
 thought I'd seek code review before posting the next one. The code is at
 https://github.com/logicchains/ParticleBench/blob/master/D.d; it's an
 OpenGL particle animation, and my D code is essentially just a direct port
 of the C implementation. Note however that, as the animation is gpu-bound,
 there's not much scope for optimisation of the code (in hindsight, it was a
 pretty poor topic for a benchmark, but hindsight always sees farthest and
 whatnot).
Is it idiomatic to use egyptian braces in D? I've never seen D code written this way... looks like Java. You have a lot of globals, and they're all TLS. That seems inefficient, and potentially incorrect if there were threads. Why do you build the vertex array from literal data at runtime? Why not just initialise the array? It's a static array, so it's not allocated at runtime, so it shouldn't be any different. You'd probably save a lot of LOC to initialise the array, perhaps better for clarity. It should probably also be immutable? Those integer for loops might be nicer as: foreach(i; 0 .. n) I'm not personally in the camp that agrees: double x = 0, y = 10, z = 15; is a good thing... but each to their own :) Why are you using 'double' in realtime software? That's weird isn't it? Granted, it will make no difference on x86, but I'd never personally do this for portability reasons. But generally looks fine. Any opengl code is naturally going to look C-ish by nature. And yes, as you said, it's not really a very good benchmark, since you're really benchmarking the GPU (and the legacy fallback non-shader pipeline at that) ;) .. The mainloop barely does anything, and has very few iterations. Nitpick: I think properness would have you update the velocity before the position, or you'll always run 1 frame behind. There are a lot more really minor performance hazards that I'd never let slip if they were invoked in hot loops, but they won't make any difference here.
Dec 13 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/13/2013 05:05 PM, Manu wrote:
 Is it idiomatic to use egyptian braces in D?
Brackets? Yes.
 I've never seen D code written this way...
 looks like Java.
Not really, no.
Dec 13 2013
parent reply Manu <turkeyman gmail.com> writes:
On 14 December 2013 02:12, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 12/13/2013 05:05 PM, Manu wrote:

 Is it idiomatic to use egyptian braces in D?
Brackets? Yes.
[] is brackets, {} is braces. I've never seen D code written this way...
 looks like Java.
Not really, no.
No, as in, people 'not really' write D code that way, or no as in, it doesn't look like java, except that it does, because only it and javascript have idiomatic egyptian braces... ;) I'm just saying, if it's code to be compared against other languages, then it should conform to the general standards of the language. I've never seen D code use egyptian braces. Certainly the vast majority of D code doesn't. I don't care which, but stick with one as a 'standard'. D has clearly chosen C braces, not Java braces, all the standard libraries agree. If you were going to publish some Java code using C braces, how would you feel about that?
Dec 13 2013
next sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Friday, 13 December 2013 at 16:40:13 UTC, Manu wrote:
 I'm just saying, if it's code to be compared against other 
 languages, then
 it should conform to the general standards of the language.
 I've never seen D code use egyptian braces.
You've never read TDPL. .. or Ali Cehreli's D tutorial. ... or looked at the D Rosetta code examples
 Certainly the vast majority of
 D code doesn't. I don't care which, but stick with one as a 
 'standard'. D
 has clearly chosen C braces,
D is not a sentient being and can't choose anything. Some group of D coders chose that brace placement and 8 space indentation. Others have chosen a style which favors less extravagant usage of screen or book page real estate.
 If you were going to publish some Java code using C braces, how 
 would you feel about that?
Feel free! I acknowledge that Phobos has specified a style, but this isn't a Phobos submission. I can read either (and more!) but I have noticed that what you're calling Java style is catching on across a number of languages with C inspired syntax. There are advantages to that. If you feel strongly about this you may prefer Nimrod, which removes the choice from you, like Python. There are advantages to that, too. -- Brian
Dec 13 2013
parent reply Manu <turkeyman gmail.com> writes:
On 14 December 2013 03:10, Brian Rogoff <brogoff gmail.com> wrote:

 On Friday, 13 December 2013 at 16:40:13 UTC, Manu wrote:

 I'm just saying, if it's code to be compared against other languages, then
 it should conform to the general standards of the language.
 I've never seen D code use egyptian braces.
You've never read TDPL.
Published material, optimised for print. Andrei admits this. He uses C braces in his code. .. or Ali Cehreli's D tutorial.

Possibly following Andrei's lead, and possible consideration for print?

... or looked at the D Rosetta code examples


No, not really. That's a bit sad. I'd make the same argument there if it's
as you say though.

 Certainly the vast majority of
 D code doesn't. I don't care which, but stick with one as a 'standard'. D
 has clearly chosen C braces,
D is not a sentient being and can't choose anything. Some group of D coders chose that brace placement and 8 space indentation. Others have chosen a style which favors less extravagant usage of screen or book page real estate. If you were going to publish some Java code using C braces, how would you
 feel about that?
Feel free!
You're saying you wouldn't find it unconventional, and perhaps ammateur looking? I acknowledge that Phobos has specified a style, but this isn't a Phobos
 submission.
I take druntime and phobos as they are the largest and most widely used body of D code, along with many other projects I've run into that also follow that lead. I'm yet to encounter any exceptions. I can read either (and more!) but I have noticed that what you're calling
 Java style is catching on across a number of languages with C inspired
 syntax. There are advantages to that.

 If you feel strongly about this you may prefer Nimrod, which removes the
 choice from you, like Python. There are advantages to that, too.
I only feel strongly about not being ambivalent on the matter. When I write Java, I use egyptian braces, and then it looks like Java code. Most people seem to understand that that's an expectation in Java. When I write C code, I use C braces. I think C became widely confused soon after university CS courses started teaching Java primarily, then you have inexperienced post-grads bring their Java habits into their C code. If D deliberately commits to the 'university post-grad syndrome' principle that C has found itself in, then I find that to be sad. However, clearly, since there's debate on this, D _has_ already inadvertently made that commitment. Oh well.
Dec 13 2013
next sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Friday, 13 December 2013 at 17:30:09 UTC, Manu wrote:
 On 14 December 2013 03:10, Brian Rogoff <brogoff gmail.com>
 You've never read TDPL.
Published material, optimised for print. Andrei admits this. He uses C braces in his code.
I don't see why 'optimized for print' isn't a strong argument for code being read from a terminal or browser or IDE or whatever, but I accept that this is a matter of taste.
 .. or Ali Cehreli's D tutorial.

 Possibly following Andrei's lead, and possible consideration 
 for print?
Or possibly Ali just prefers this style?
 ... or looked at the D Rosetta code examples


 No, not really. That's a bit sad. I'd make the same argument 
 there if it's
 as you say though.
It is as I say. Also with much of the C++ and Java (as you would guess) submissions. I don't find it sad. I find it sadder that 8 spaces was chosen for the Phobos indentation.
  If you were going to publish some Java code using C braces, 
 how would you
 feel about that?
Feel free!
You're saying you wouldn't find it unconventional, and perhaps ammateur looking?
No, I'm not saying that. I would find it unusual. As I said, I've noticed that the publication style indentation is becoming more widely used in C and C++ as well. I'm just saying that I've grown used to reading many different styles, so I wouldn't assume amateurism, but given the code I've been reading and what I said above anything that isn't publication style looks a bit unusual to me. More so in Java, as you say. BTW, I like the term 'Egyptian style', but 'publication style' more accurately suggests its rationale.
 I only feel strongly about not being ambivalent on the matter. 
 When I write
 Java, I use egyptian braces, and then it looks like Java code. 
 Most people
 seem to understand that that's an expectation in Java. When I 
 write C code,
 I use C braces.
 I think C became widely confused soon after university CS 
 courses started
 teaching Java primarily, then you have inexperienced post-grads 
 bring their
 Java habits into their C code.
I remember discussion of this in C long before Java became popular. I learned to just use whatever other programmer's had used on any given project. If there is a choice, some people will make different choices.
 If D deliberately commits to the 'university post-grad 
 syndrome' principle
 that C has found itself in, then I find that to be sad.
 However, clearly, since there's debate on this, D _has_ already
 inadvertently made that commitment. Oh well.
I don't think it's a university thing. Nor am I suggesting that there is debate: the course for Phobos has been charted. What I'm suggesting is that the entire D community isn't committed to that style. You can enforce it on your own projects, but that's your choice. -- Brian
Dec 13 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 12/13/2013 10:20 AM, Brian Rogoff wrote:

 On Friday, 13 December 2013 at 17:30:09 UTC, Manu wrote:
 Possibly following Andrei's lead, and possible consideration for print?
Or possibly Ali just prefers this style?
I used to dislike it until I started working at my current job where Egyptian style is the standard. I am happy that it is common D-style as well. I am still not sure why I don't like it everywhere (e.g. struct, class, function definitions, etc.) :) void foo() { // <-- why not here as well? I don't know. :p if (cond) { // ... } } Ali
Dec 13 2013
next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Friday, 13 December 2013 at 22:10:13 UTC, Ali Çehreli wrote:
 I used to dislike it until I started working at my current job 
 where Egyptian style is the standard.

 I am happy that it is common D-style as well.

 I am still not sure why I don't like it everywhere (e.g. 
 struct, class, function definitions, etc.) :)

 void foo()
 {                  // <-- why not here as well? I don't know. :p
     if (cond) {
         // ...
     }
 }

 Ali
TBH I'm more of an egyptian style user myself. But for function definitions, struct definitions, etc... I feel it's better to give it its own line because of other D features. For instance: --- void foo(T)(T input) if(isIntegral!T) { //... } --- It emphasizes its significance to give it its own line, despite it being a bit more verbose: --- void foo(T)(T input) if(isIntegral!T) { //... } --- Plus consider in/out/body like things: --- void foo(T)(T input) in { assert(input > 0); } body { //... } --- vs. --- void foo(T)(T input) in { assert(input > 0); } body { //... } --- IMO, it looks like the "in" section is actually the body initially. This would especially matter when the in section is a bit larger. (And before you suggest giving "in {" its own line in the first example, I don't like that because it seems like too special of a rule, but that was typically what I did originally). So, Ali, I'm like you that I prefer declarations to have braces on their own line but other things to use egyptian style.
Dec 13 2013
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Friday, 13 December 2013 at 22:10:13 UTC, Ali Çehreli wrote:
 I used to dislike it until I started working at my current job 
 where Egyptian style is the standard.
I've always disliked it... It's almost as painful as nails on a chalkboard for me. The last job I worked at was a small Java shop that used this style exclusively, and I did get used to writing code in it after awhile, but I would never use it if given the choice. I vastly prefer Allman style.
Dec 13 2013
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 14 December 2013 08:10, Ali =C3=87ehreli <acehreli yahoo.com> wrote:

 On 12/13/2013 10:20 AM, Brian Rogoff wrote:

 On Friday, 13 December 2013 at 17:30:09 UTC, Manu wrote:
 Possibly following Andrei's lead, and possible consideration for print=
?
 Or possibly Ali just prefers this style?
I used to dislike it until I started working at my current job where Egyptian style is the standard. I am happy that it is common D-style as well. I am still not sure why I don't like it everywhere (e.g. struct, class, function definitions, etc.) :) void foo() { // <-- why not here as well? I don't know. :p if (cond) { // ... } }
Mmm, I prefer C braces for this reason. I just can't feel comfortable with egyptian braces applied universally. I figure, if I can't accept it universally, I can't accept it at all ;) .. Where are the lines drawn? What are the rules? I don't even know! It's chaos! Obviously, I suffer from OCD... I'm one of those whitespace nazi's too :/
Dec 13 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
 Mmm, I prefer C braces for this reason.
There is no such thing as "C-braces" or idiomatic C. C is defined by anarchy and chaos. The reason old C-code (and guides) have braces on the next line for function calls is that the type was specified under the parameter-list in old-style C. http://en.wikipedia.org/wiki/Indent_style Fixed rules for whitespace leads to poor legibility, creating legible layout is a context sensitive design problem. No wonder the D-language is stuck in a state of poor usability with discussions like this eating all the bandwidth… And, why, why, why would anyone think that it is a good idea to use the boolean negate-operator for templates? Talk about making my eyes sore! D has a large heap of usability and inconsistency problems that makes freedom-of-whitespace a drop in a biiiig ocean. Get real, you need to focus on real challenges if you want D to take off! (back to lurking)
Dec 13 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
I only made the point (among a bunch of other points!) because I wondered
if it was worth presenting consistency in D code intended for public
scrutiny. It's all good, it's settled now. It's not my fault, or my intent,
that the most trivial point in my list of comments is the one that
apparently stimulated the most discussion... :/
On 14 Dec 2013 14:00, <&quot;Ola Fosheim Gr=C3=B8stad\&quot; &
lt;ola.fosheim.grostad+dlang gmail.com&gt;&quot; puremagic.com> wrote:

 Mmm, I prefer C braces for this reason.

 There is no such thing as "C-braces" or idiomatic C. C is defined
 by anarchy and chaos. The reason old C-code (and guides) have
 braces on the next line for function calls is that the type was
 specified under the parameter-list in old-style C.

 http://en.wikipedia.org/wiki/Indent_style

 Fixed rules for whitespace leads to poor legibility, creating legible
 layout is a context sensitive design problem.

 No wonder the D-language is stuck in a state of poor usability
 with discussions like this eating all the bandwidth=E2=80=A6

 And, why, why, why would anyone think that it is a good idea to
 use the boolean negate-operator for templates? Talk about making
 my eyes sore! D has a large heap of usability and inconsistency
 problems that makes freedom-of-whitespace a drop in a biiiig
 ocean. Get real, you need to focus on real challenges if you want
 D to take off!

 (back to lurking)
Dec 13 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 14 December 2013 at 04:17:16 UTC, Manu wrote:
 It's all good, it's settled now. It's not my fault, or my 
 intent, that the most trivial point in my list of comments is 
 the one that apparently stimulated the most discussion... :/
Oh well, don't feel bad, I wrote tongue-in-cheek and needed motivation to de-lurk. If people can't stand opinions about whitespace they should get off the net. :-) In my opinion you would need an editor with good taste who develops the style guide and enforces it. That's the best way for a volunteer-like project, I think, because enforcing a style you don't enjoy is no fun so it is important that the one responsible for fixing code-layout LOVES the "design". (I personally suspect that the lots-of-extra-lines styles were developed, not out of taste, but as a strategy to get impressive Lines-Of-Code-counts! Lines of code used as a measure of productivity by clueless managers.) On another note, now that I am here: I find the D-forums to be very entertaining, lots of fun discussions comparing different languages. So I keep coming back. I once had great hope for D as a better C++, but I have kind of given up, even though I find the other C-family members kind of distasteful too, but their compilers are better (for now). I am also kind of wondering if Dart will replace Javascript and then a more static version of that language eventually will replace C++. It makes little sense to have all these almost-the-same imperative languages… Regarding using the not-operator for non-not-operations: anything would be better than reusing operators that are commonly used to affect control-flow. It makes it difficult to comprehend control flow when you skim code you are not familiar with. "not" tends to be used for completely changing the flow of a program so those "!" are attention-seekers when trying comprehend unfamiliar code. What makes me sit on the fence regarding D (I have used it actively a couple of years ago) is: 1. Not enough improvement on syntax (In some areas better than C++, in others worse. In regards to templates it is even worse, and C++ is kind of bad.) 2. No way to get rid of garbage-collection without making the language crippled. This is a show-stopper. 3. No high performing authoritative compiler suite. When the efforts are spread over 3 compilers I just don't expect any of them to improve to a state where it becomes excellent (like having excellent error-messages, analytic features, tight IDE-integration etc). It gives an impression of a lack of direction and leadership, and makes me feel like there is no hope of D ever to catch up. Other languages keep improving too… So obviously, it is not the semantics that makes me a lurking fence-sitter. The issues that makes me sit on the fence are certainly in areas that could be fixed, but I don't expect it will be. So I stick to the forums, for now… ;-) Though I do really wish you the best, and will certainly use/contribute to D when/if it resolves the issues listed above. Ola.
Dec 14 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 14/12/13 17:22, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" puremagic.com wrote:
 What makes me sit on the fence regarding D (I have used it actively a couple of
 years ago) is:

 1. Not enough improvement on syntax (In some areas better than C++, in others
 worse. In regards to templates it is even worse, and C++ is kind of bad.)
Very curious about what you mean here -- I think most of us find that D's template syntax is much superior to C++, so I'd really like to understand what you find problematic.
 2. No way to get rid of garbage-collection without making the language
crippled.
 This is a show-stopper.
Out of curiosity, is this a show-stopper for theoretical reasons, or did you actually run into practical problems with the GC? I ask because despite having fairly stiff performance requirements, I've not generally had any problems getting C/C++-like speed while using the GC. Then again, I don't rely on any kind of real-time performance, only overall speed.
 3. No high performing authoritative compiler suite. When the efforts are spread
 over 3 compilers I just don't expect any of them to improve to a state where it
 becomes excellent (like having excellent error-messages, analytic features,
 tight IDE-integration etc). It gives an impression of a lack of direction and
 leadership, and makes me feel like there is no hope of D ever to catch up.
Other
 languages keep improving too…
I don't think things are actually as spread out as you think. In reality, there is one compiler frontend that everyone collaborates on. That frontend is ported to different backends, which each have different advantages in terms of speed and optimizations. But most of the things you are concerned with seem to be things that depend only on the frontend.
 So obviously, it is not the semantics that makes me a lurking fence-sitter. The
 issues that makes me sit on the fence are certainly in areas that could be
 fixed, but I don't expect it will be. So I stick to the forums, for now… ;-)
 Though I do really wish you the best, and will certainly use/contribute to D
 when/if it resolves the issues listed above.
I think it might be worth giving things another spin. If the last time you tried using D was a couple of years ago, you will find that things have changed a great deal in terms of performance, features and general quality. And, if you're up for contributing, why not see if you can address some of the issues you raise? For example, as you want to avoid the GC, one area that could use some input is going through Phobos working out what allocates when it doesn't need to, and fixing it.
Dec 14 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 14 December 2013 at 18:46:50 UTC, Joseph Rushton 
Wakeling wrote:
 Very curious about what you mean here -- I think most of us 
 find that D's template syntax is much superior to C++, so I'd 
 really like to understand what you find problematic.
I dislike the syntax. :-) And well, as far as I can tell I also dislike the semantics, but it is no worse than C++. I would like to see a modern language with templates to do it well. That is to be more in the direction of readable term-rewriting, pattern-matching with constraints that will make it possible to do clean operator-overloading etc. More in the direction of legible Pure, Haskell etc.
 Out of curiosity, is this a show-stopper for theoretical 
 reasons, or did you actually run into practical problems with 
 the GC?
It is a showstopper because I only do C++ like stuff that is realtime, like graphics and audio. I use Python for things that can be done as batch. I once wrote a D-program to sort my email archives in memory, it took a while for the GC to kick in, but it got kind of slow… Still, this was a couple of years ago. What I want is a programming language that I can write clean code in and that allows me to have a mental map of how it maps onto the hardware. C does this, except it does not allow for clean programming.
 I don't think things are actually as spread out as you think.  
 In reality, there is one compiler frontend that everyone 
 collaborates on.
You could be right, I am only talking about the impression I am getting. "The smoke-signals being received from a distance". When you don't have one excellent compiler, but three in-the-works, it sends signals of a lack of direction and implies a lack of a leader that can rally everyone into something cohesive. This is not a critique of anyone, most programmers want to be creative and argumentative, not to "nurture", "manipulate" and "wave the whip" ( I am not even sure I like people who are "great leaders" ;^).
 I think it might be worth giving things another spin.  If the 
 last time you tried using D was a couple of years ago, you will 
 find that things have changed a great deal in terms of 
 performance, features and general quality.
Let me rephrase what I am perceiving like this: for me D is currently a solution without a problem. D is probably a better language than Dart, but Dart is addressing a real problem: writing programs for browsers that are longer than 1000 lines without javascript. And it does so by compiling to javascript. So I am using Dart now. Dart is currently the only sane solution for web-app programming. D is probably a better language than Python, but Python has many great libraries (like importing excel), is available for AppEngine with fast spin-up, and have a nice interpreter for experimenting with text-manipulation and code-snippets. So I am using Python, even though a dynamic language is crap on a server (runtime errors). D is probably a better language than Go, but it isn't available on AppEngine and the Go team is making it work well for web servers so while it is still in experimental status it probably will be support fully on AppEngine. So I am spending some time with Go. D is probably a better language than C++ in many areas (like header files!), but I cannot easily and effortlessly get rid of the GC and I will probably have performance problems with real time program code (audio is hard realtime, if you don't fill the buffer you get "pops"). D is certainly a much better language than Objective-C/Objective-C++, but it won't run on iOS. So when doing app-programming I'd use Objective-C++ (and do as much as possible in the C++ part). The only hobbyist project I have that I would like to use D for is to do a little bit of experimenting with creating a tiny hobbyist OS in 64-bit mode, but I have no idea what it takes to do that with D. My personal opinion is that D would get much more traction if it was a true C/C++ replacement. That is to have the same level of minimal runtime-system/mental-mapping-to-hardware. So, if there was a tar-ball with a small mini-OS/D-compiler that I could dabble with I most certainly would give D a spin, but as of today I see D as a solution with no obvious problem to solve. There is no "best-application-area" for D, which in turns leads it to not being the first choice for any given problem even though it probably is a better language in many areas than the languages that "win" in their respective areas. I think the ideal direction for D would be to take clang, rip out the c++ parser and allow D to interface with (llvm based) C++ seamlessly and to add the ability to generate c++ code from D code. That way programmers could start integrating D into their C++ projects with no risk. As of today, I feel that it is better to just stick to C++ without D, because the risks of using D does not outweigh the advantages it may provide for me. Do you think I am unfair? Ola.
Dec 14 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/14/13 11:46 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Saturday, 14 December 2013 at 18:46:50 UTC, Joseph Rushton Wakeling
 wrote:
 Very curious about what you mean here -- I think most of us find that
 D's template syntax is much superior to C++, so I'd really like to
 understand what you find problematic.
I dislike the syntax. :-)
It should be mentioned that years ago I proposed using '.' instead of '!' for templates. Walter actually gave me a patched compiler that I used for a few weeks. The code didn't look much better, but one important simplification did result from that push: we eliminated parens wherever only one argument was involved. That turned out to be a good thing.
 And well, as far as I can tell I also dislike
 the semantics, but it is no worse than C++. I would like to see a modern
 language with templates to do it well. That is to be more in the
 direction of readable term-rewriting, pattern-matching with constraints
 that will make it possible to do clean operator-overloading etc.  More
 in the direction of legible Pure, Haskell etc.
This is vague, and as many cool while vague things, may turn out to be less attractive when the details are worked out. In particular "clean operator-overloading" has been discussed in this group as a distinct non-goal and potential anti-pattern if taken too far.
 I don't think things are actually as spread out as you think. In
 reality, there is one compiler frontend that everyone collaborates on.
You could be right, I am only talking about the impression I am getting.
Well he is factually right. And facts are prone to changing impressions.
 "The smoke-signals being received from a distance". When you don't have
 one excellent compiler, but three in-the-works, it sends signals of a
 lack of direction and implies a lack of a leader that can rally everyone
 into something cohesive. This is not a critique of anyone, most
 programmers want to be creative and argumentative, not to "nurture",
 "manipulate" and "wave the whip" ( I am not even sure I like people who
 are "great leaders" ;^).
One lone compiler that everybody hangs on for dear life would be a distinctly bad place to be. A mishmash of a dozen alpha-state compilers would be just as bad. Three compilers that share the core language and complement it with distinct backends is quite the sweet spot to be in. I had no idea one could frame it as a bad thing.
 I think it might be worth giving things another spin.  If the last
 time you tried using D was a couple of years ago, you will find that
 things have changed a great deal in terms of performance, features and
 general quality.
Let me rephrase what I am perceiving like this: for me D is currently a solution without a problem.
[snip]
 Do you think I am unfair?
Fairness has little to do with it. By and large I'd say, if you don't have a problem for which D is the best or at least a advantageous solution, it's entirely reasonable to not reach for it. Andrei
Dec 14 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2013 11:46 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 You could be right, I am only talking about the impression I am getting. "The
 smoke-signals being received from a distance". When you don't have one
excellent
 compiler, but three in-the-works, it sends signals of a lack of direction and
 implies a lack of a leader that can rally everyone into something cohesive.
This
 is not a critique of anyone, most programmers want to be creative and
 argumentative, not to "nurture", "manipulate" and "wave the whip" ( I am not
 even sure I like people who are "great leaders" ;^).
Back when there was only one D compiler, people said they wouldn't use it because there was only one. Now people won't use it because there are 3. Essentially, if you want to find a reason not to use D, you'll find one. But if you want to use D, there are lots of reasons to. I personally find D to be satisfying and exciting to program in. I can get the code to look like the way the algorithm works in my head, and it runs fast, too.
Dec 14 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 15 December 2013 at 04:50:20 UTC, Walter Bright wrote:
 Back when there was only one D compiler, people said they 
 wouldn't use it because there was only one. Now people won't 
 use it because there are 3.
Not quite, I think people were unhappy because it wasn't fully open source back then. I am currently (possibly being wrong) perceiving the current D-compiler community to be fragmented. In the same sense that BSD is fragmented. Linux isn't fragmented, and stronger because of it, there is one authoritative kernel and some minor spin-offs. Compilers are usually never 100% compatible so having one dominating compiler that "everybody" use is beneficial.
 Essentially, if you want to find a reason not to use D, you'll 
 find one. But if you want to use D, there are lots of reasons 
 to.
Actually, I wouldn't track dlang.org for years if I wasn't looking for a reason to use it. I do try it from time to time, but it never fits the things I want it to do, because D like Go is claiming to be a better C, but is not giving me the level of control I want. And I really do want a better C/C++, if for no other reason than that header files sucks. In general I think programming languages get traction, not because they are good languages, but because they are best-fit for a particular application domain. So I think a language like D would benefit from being the best "modern" solution in one particular area, like embedded programming. When creating a programming environment it is important to realize that human brains are bad at logic, dog slow, it cannot do it. It does approximations to logic, the approximations are worse when you get noise into the system. When you are programming the brain is more or less saturated constantly and stutters because information is relayed in and out of "working memory" (which is a fuzzy process and a source of errors). However, the brain has very powerful "hardwired" spatial/visual subsystems with spatial mapping and classification that work very well if the visual patterns are distinct and tailored to the kind of "visual fields" that you see in landscapes/faces etc which it has be evolved to deal with. You want to utilize that to it's fullest potential. In c++ some symbols are very easy to detect, like "::" and "[", you don't have to think to classify spatial areas where those visual constructs occur as regions of namespacedness and arrayish, because they are not used for other things. So you can train the subconscious cognitive pattern to correctly classify them without doing any resolution. There is a reason for why road signs differ in shape, colours and have very distinct silhouettes as symbols, it supports recognition without disturbing the conscious parts of the brain that deals with avoiding danger while driving. The moment you have to think about what a sign means you are much more likely to make errors, which while driving can be fatal. When programming it isn't fatal, but you get more bugs, or become slower. IIRC Manu thinks that it is better to have "{" on a separate line. Is he correct? Yes, in terms of pattern recognition he is. Visual marks that are surrounded by open space is more likely to be correctly grouped, detected and visually classified. If you use the Egyptian style you basically don't rely on the braces as symbols to the same extent, you rely on line-detection of indentation. So you need larger indentation in order to establish horisontal lines. Why is that? Because the visual subsystems of the brain is hardwired to detect contours of objects/regions. If the indentation is too small the visual subsystems will fail to detect breaks in the vertical lines and will group nested blocks as one block, until the conscious parts of the brain says "no-no-wait" and has to resolve the error/ambiguity. When programming in assembly programmers tend to do sketches on paper, why is that? Because that makes it possible for them to utilize the visual cognitive capabilities of the brain in addition to the dog-slow-quasi-logical-reasoning of the human brain. That creates a mental map of the program which assembly doesn
Dec 15 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
(No edit button? Posted by accident. :)

Continuing:

When programming in assembly programmers tend to do sketches on
paper, why is that? Because that makes it possible for them to
utilize the visual cognitive capabilities of the brain in
addition to the dog-slow-quasi-logical-reasoning of the human
brain. That creates a mental map of the program which assembly
doesn't support very well due to it's poor utilization of 
distinct visual cues and patterns. Assembly code is visually too 
uniform to "activate" visual cognition.
Dec 15 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 15 Dec 2013 09:55:23 +0100
schrieb "Ola Fosheim Gr=C3=B8stad"
<ola.fosheim.grostad+dlang gmail.com>:

 (No edit button? Posted by accident. :)
No, the forum is backed by a NNTP server which supports posting and downloading articles, but not editing. Deletion is technically possible, but currently only done by an administrator to remove spam as far as I can tell. Thanks for your little explanation on why it is important to support the brain's pattern recognition with the programming language. Other than that things have to be easy to type. E.g. BEGIN and END. might be visually distinct, but { and } are shorter. <[int]> jumps to the eye, but !int is more concise. --=20 Marco
Dec 15 2013
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Saturday, 14 December 2013 at 19:46:36 UTC, Ola Fosheim 
Grøstad wrote:
 Do you think I am unfair?
I don't think it's a matter of fair or unfair. If a use-case for D doesn't stand out for you, that's your call. What I do think is that a lot of your arguments are either fairly abstract theoretical ones, or impressions based on a fairly limited amount of experience at a time when D was much less developed compared to where it is today. Bear in mind you're speaking to someone who had a similar initial experience -- "Hmm, this seems pretty cool but doesn't give me the performance I need and get from C++, file it as 'one to watch'..." and has since come back to the language and used it extensively. (For me it was the availability of a D2-supporting GDC in Ubuntu 12.04 that did it: ease of access combined with performance on par with C++.) Your contention about fragmentation due to the 3 compilers is, I think, objectively false, however. On the contrary, what differences there are have been continuously narrowing for the whole period of time that I've been actively using D, to the point where pretty soon the frontends of GDC, LDC and DMD will be 100% identical code. Oh, and -- I can't see that rewriting the compilers to output to C++ would really be easier than just implementing better direct support for interfacing with C++ in the language. It honestly just seems like a good way to introduce a new opportunity for difficulty in debugging performance issues. Bottom line -- with any language there is a hurdle of initial use that has to be jumped before one can really evaluate its practical usefulness. If what you see in D today doesn't convince you that it's worth trying to take that jump a second time, then that's your judgement to make. But I think you might get more out of spending a couple of hours trying things out in a playful way, rather than writing long emails debating fairly abstract philosophical ideas and desires for the language. TL;DR I don't think it matters whether you're fair to D or not, but it matters that you're fair to yourself in giving yourself the chance to properly assess what D can do for you today :-)
Dec 15 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 15 December 2013 at 10:30:36 UTC, Joseph Rushton 
Wakeling wrote:
 Your contention about fragmentation due to the 3 compilers is, 
 I think, objectively false, however.  On the contrary, what 
 differences there are have been continuously narrowing for the 
 whole period of time that I've been actively using D, to the 
 point where pretty soon the frontends of GDC, LDC and DMD will 
 be 100% identical code.
Ok, that is quite possible, but I that might also be the case for BSD… FreeBSD is probably on par with Linux, but it is still perceived as being part of a fragmented ecosystem. Open source projects that fragment tend to die, so I think people are a bit uneasy about that in general. I agree that it is a superficial measurement.
 Oh, and -- I can't see that rewriting the compilers to output 
 to C++ would really be easier than just implementing better 
 direct support for interfacing with C++ in the language.
If I write an engine in D and then want to port it to iOS…
 practical usefulness.  If what you see in D today doesn't 
 convince you that it's worth trying to take that jump a second 
 time, then that's your judgement to make.  But I think you 
 might get more out of spending a couple of hours trying things 
 out in a playful way, rather than writing long emails debating 
 fairly abstract philosophical ideas and desires for the 
 language.
Actually, my arguments are not philosophical. They are pragmatic. D is not high level enough to be high level and not low level enough to give sufficient low level control. I would want a C++-replacement to give me convinient access to hardware-level features such as transactional memory in the Haswell processor etc. Making 3 compiler backends support stuff like that seems a bit unrealistic.
 TL;DR I don't think it matters whether you're fair to D or not, 
 but it matters that you're fair to yourself in giving yourself 
 the chance to properly assess what D can do for you today :-)
Well, if it did support transactional memory and was more clearly dedicated towards low-level programming I would use it to have lock free concurrent programming in a relatively clean programming language. O.
Dec 15 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 15/12/13 12:40, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" puremagic.com wrote:
 If I write an engine in D and then want to port it to iOS…
Again, better I think to create first-class iOS support in D itself. The alternative you suggest really feels like sticking one's feet in the flames to get out of having to do a firewalk ... :-)
 Actually, my arguments are not philosophical. They are pragmatic.
I was thinking more of your remarks about the semantics/syntax of templates here, although I concede that there is a practical side to that as well. I agree that e.g. your concerns over real-time control and the GC are pragmatic, but that's only one use-case. If that's the use-case that matters to you, then fair enough.
 D is not high level enough to be high level and not low level enough to give
 sufficient low level control.
I don't think that your remarks about the low-level side really stand up to scrutiny. You can go as low as you like, but admittedly this may currently involve having to avoid much of the existing library functionality.
 Well, if it did support transactional memory and was more clearly dedicated
 towards low-level programming I would use it to have lock free concurrent
 programming in a relatively clean programming language.
If that's the use-case you're looking for, fair enough. What I was concerned with was whether you were overlooking other use-cases that might potentially benefit you, because while looking at D through the prism of "C++ replacement" is valid, it misses a whole load of other things one can do with the language.
Dec 15 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 15 December 2013 at 12:29:46 UTC, Joseph Rushton 
Wakeling wrote:
 Again, better I think to create first-class iOS support in D 
 itself.  The alternative you suggest really feels like sticking 
 one's feet in the flames to get out of having to do a firewalk 
 ... :-)
Yes, I thought that too for a while, in general, but then it turns out that C++ has kind of become a "portable source-level object format" which most new platforms are claiming support for. And new platforms keep coming in areas where you least expect them to. Like Chrome PNaCl for the web. So, it is a moving target. Not being able to generate C/C++ if you later decide to port is a lock-in unless the runtime is so minimal and simple that you can make do with generic LLVM IR…
 If that's the use-case you're looking for, fair enough.  What I 
 was concerned with was whether you were overlooking other 
 use-cases that might potentially benefit you, because while 
 looking at D through the prism of "C++ replacement" is valid, 
 it misses a whole load of other things one can do with the 
 language.
I am looking for a language that let me do experimental realtime audio. C++ is not a good fit because of the "experimental" part suggest a clean language where you can quickly change the code. C++ is a bit verbose/tedious to be a good fit. There is nothing in D that prevents it from providing very clean low level support, but I sense that this is not the direction the language is going. I could be wrong though, maybe I'll give it a spin after new year. :) O.
Dec 15 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 15 December 2013 23:25, <"Ola Fosheim Gr=C3=B8stad\"
<ola.fosheim.grostad+dlang gmail.com>" puremagic.com> wrote:

 On Sunday, 15 December 2013 at 12:29:46 UTC, Joseph Rushton Wakeling wrot=
e:
 Again, better I think to create first-class iOS support in D itself.  Th=
e
 alternative you suggest really feels like sticking one's feet in the fla=
mes
 to get out of having to do a firewalk ... :-)
Yes, I thought that too for a while, in general, but then it turns out that C++ has kind of become a "portable source-level object format" which most new platforms are claiming support for. And new platforms keep comin=
g
 in areas where you least expect them to. Like Chrome PNaCl for the web. S=
o,
 it is a moving target. Not being able to generate C/C++ if you later deci=
de
 to port is a lock-in unless the runtime is so minimal and simple that you
 can make do with generic LLVM IR=E2=80=A6


  If that's the use-case you're looking for, fair enough.  What I was
 concerned with was whether you were overlooking other use-cases that mig=
ht
 potentially benefit you, because while looking at D through the prism of
 "C++ replacement" is valid, it misses a whole load of other things one c=
an
 do with the language.
I am looking for a language that let me do experimental realtime audio. C++ is not a good fit because of the "experimental" part suggest a clean language where you can quickly change the code. C++ is a bit verbose/tedious to be a good fit. There is nothing in D that prevents it from providing very clean low level support, but I sense that this is not the direction the language is going. I could be wrong though, maybe I'll give it a spin after new year. :)
I think D can do this well. D has fairly nice stream constructs and algorithms, and also has reasonable out-of-the-box threading features. Audio involves so much bit-twiddling, I'd never want to do audio work in a non-native language! I only worry about the garbage collector. Audio processing is my biggest fear case when there is a GC involved that is known to execute unpredictably, often taking a very long time in the rare event it does execute. More work, less often, is a workload pattern that is fundamentally incompatible with realtime software. Incidentally, this is a significant factor in the reasoning behind calling for a community music-game side project. I'd like to prove it out.
Dec 15 2013
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 15 December 2013 at 14:43:45 UTC, Manu wrote:
 Audio involves so much bit-twiddling, I'd never want to do 
 audio work in a non-native language!
True!
 I only worry about the garbage collector. Audio processing is 
 my biggest
 fear case when there is a GC involved that is known to execute
 unpredictably, often taking a very long time in the rare event 
 it does execute.
On OS-X there are at least two ways to do audio programming. The easiest is to use a large buffer and use a pre made AudioUnit. The low latency option is to write your own AudioUnit which is called as a callback by the kernel on a real time thread (20+ times per second) and communicate with this thread from the main program using CAS instructions to avoid race-conditions. I guess it doesn't matter too much if the main program is under GC if the called from the AudioUnit never is touched by GC and all objects transferred to the AudioUnit is not under GC. Might be possible, depending on how GC works on OS-X with D.
Dec 15 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2013 6:43 AM, Manu wrote:
 [...]
Manu, all your posts are about twice as many lines as show up. In examining the posting source, each is there twice - once as plain text, once as html text. The newsgroup readers ignore the html version - perhaps there's some setting in your n.g. reader that could be set to not emit the html version?
Dec 15 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 16 December 2013 07:17, Walter Bright <newshound2 digitalmars.com> wrote:

 On 12/15/2013 6:43 AM, Manu wrote:
 [...]
Manu, all your posts are about twice as many lines as show up. In examining the posting source, each is there twice - once as plain text, once as html text. The newsgroup readers ignore the html version - perhaps there's some setting in your n.g. reader that could be set to not emit the html version?
Really? Have my posts always behaved this way, or is a recent habit of mine? :) I access the mailinglist via gmail. I'll check the settings, but I'm not hopeful there'll be any options like that.
Dec 15 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2013 3:22 PM, Manu wrote:
 Really? Have my posts always behaved this way, or is a recent habit of mine? :)
 I access the mailinglist via gmail. I'll check the settings, but I'm not
hopeful
 there'll be any options like that.
In Thunderbird, "control U" will display the complete text of the posting. It's fairly obvious :-)
Dec 15 2013
prev sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
El 16/12/13 00:22, Manu ha escrit:
 On 16 December 2013 07:17, Walter Bright <newshound2 digitalmars.com
<mailto:newshound2 digitalmars.com>> wrote:
 
     On 12/15/2013 6:43 AM, Manu wrote:
     > [...]
 
     Manu, all your posts are about twice as many lines as show up. In
examining the posting source, each is there twice - once as plain text, once as
html text.
 
     The newsgroup readers ignore the html version - perhaps there's some
setting in your n.g. reader that could be set to not emit the html version?
 
 
 Really? Have my posts always behaved this way, or is a recent habit of mine? :)
 I access the mailinglist via gmail. I'll check the settings, but I'm not
hopeful there'll be any options like that.
Yes, there is. On Gmail, "compose", click on bottom right triangle, check "Plain text mode". This option will be set until you change it, not just for the current e-mail. -- Jordi Sayol
Dec 15 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/15/13, Manu <turkeyman gmail.com> wrote:
 I only worry about the garbage collector. Audio processing is my biggest
 fear case when there is a GC involved that is known to execute
 unpredictably, often taking a very long time in the rare event it does
 execute.
I think this is supposed to fix (or help fix) that problem: https://github.com/D-Programming-Language/druntime/pull/493
Dec 15 2013
prev sibling next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 14 December 2013 at 16:22:41 UTC, Ola Fosheim 
Grøstad wrote:
 Regarding using the not-operator for non-not-operations: 
 anything would be better than reusing operators that are 
 commonly used to affect control-flow. It makes it difficult to 
 comprehend control flow when you skim code you are not familiar 
 with. "not" tends to be used for completely changing the flow 
 of a program so those "!" are attention-seekers when trying 
 comprehend unfamiliar code.
But still, _what exactly_ should be used instead of the "not-operator"? "Anything" is too vague and not true. You probably can't use these: ][+=-_,.|`\/"'><;:}{%^&* ("Can't" is a strong word. <>s are used by C++, for instance, but we already know of the challenges and issues caused by that) You might could _just_ use ()s but it'd lead to some parsing difficulties for both the programmer and the computer. I'm just curious, not trying to say you're wrong. I do think it's a huge step up from C++'s templates and, personally, I love the new syntax with an infix ! for instantiating templates. But if something better could be used, I'm interested in hearing the ideas too.
Dec 14 2013
next sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Saturday, 14 December 2013 at 19:32:45 UTC, Chris Cain wrote:
 On Saturday, 14 December 2013 at 16:22:41 UTC, Ola Fosheim 
 Grøstad wrote:
 Regarding using the not-operator for non-not-operations: 
 anything would be better than reusing operators that are 
 commonly used to affect control-flow. It makes it difficult to 
 comprehend control flow when you skim code you are not 
 familiar with. "not" tends to be used for completely changing 
 the flow of a program so those "!" are attention-seekers when 
 trying comprehend unfamiliar code.
But still, _what exactly_ should be used instead of the "not-operator"? "Anything" is too vague and not true. You probably can't use these: ][+=-_,.|`\/"'><;:}{%^&*
Composite brackets, a-la the SPECS 'C++ Resyntaxed' ** proposal, would work. <[]>, <[<[]>]> may be a bit heavy but not too bad. I haven't found the !() syntax for D templates to be a problem though and prefer it to <> from C++ and Java. If I were searching for D blemishes, I wouldn't look there first. -- Brian ** http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
Dec 14 2013
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 14 December 2013 at 20:00:30 UTC, Brian Rogoff wrote:
 "not-operator"? "Anything" is too vague and not true. You 
 probably can't use these: ][+=-_,.|`\/"'><;:}{%^&*
Depends on the parser-tech. Modern parsers (GLR?) can handle complex grammars. In D template syntax looks like it has been added as an afterthought.
 I haven't found the !() syntax for D templates to be a problem 
 though and prefer it to <> from C++ and Java. If I were 
 searching for D blemishes, I wouldn't look there first.
I am not talking about it "being a problem", but about not being user-friendly when you are faced with unknown code where you do not know the symbols, it will slow you down. "<>" is much more visually distinct, but I know the reasoning of keeping the parser simple. I just disagree with the solution. It is not as comprehensible as it should be. I also think D goes a bit too far in reusing symbols/keywords in general, sacrificing reader comprehension (reading speed). The grammar is not as clean as it should be for a new language IMHO. It has unnecessary clutter and lacks some visual cognitive support (for a clumsy human, not a compiler). It isn't worse than C++ though, but C++ is in whole an afterthought put in cement by the original c-front. O.
Dec 14 2013
next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 14 December 2013 at 20:37:21 UTC, Ola Fosheim 
Grøstad wrote:
 On Saturday, 14 December 2013 at 20:00:30 UTC, Brian Rogoff 
 wrote:
 "not-operator"? "Anything" is too vague and not true. You 
 probably can't use these: ][+=-_,.|`\/"'><;:}{%^&*
Depends on the parser-tech. Modern parsers (GLR?) can handle complex grammars. In D template syntax looks like it has been added as an afterthought.
I'm kind of taking this as "I don't know of any specific better alternative, but I'm not 100% satisfied in this and we have awesome technology, so a better solution must exist". I don't really know how else to interpret that.
Dec 14 2013
prev sibling next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 14 December 2013 at 20:37:21 UTC, Ola Fosheim 
Grøstad wrote:
 I am not talking about it "being a problem", but about not 
 being user-friendly when you are faced with unknown code where 
 you do not know the symbols, it will slow you down.  "<>" is 
 much more visually distinct, but I know the reasoning of 
 keeping the parser simple. I just disagree with the solution. 
 It is not  as comprehensible as it should be.
Also, I'm not sure I agree with any of this. You are minimally required to have some understanding of what symbols mean to use any programming language (Who would guess that blah<int> is a template instantiation in C++ or generic in other languages without being familiar with what <>s mean in that context?). Plus, even if your point is "just don't know that one symbol but don't want to spend time learning it", still, I've shown some D code to someone who actually didn't know D code but they fully understood and comprehended what "memoize!myFunc(a)" did despite not understanding the intricacies of its implementation.
Dec 14 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
 Also, I'm not sure I agree with any of this. You are minimally 
 required to have some understanding of what symbols mean to use 
 any programming language (Who would guess that blah<int> is a
No, if you have strong distinct visual cues the brain does not have to reason but you will use the pattern-recognition that your brain supports for classifying visual cues in our natural environment. The moment you have to think about what an identifier means you have started to strain the brain. You are being slowed down and will become more tired and make more mistakes because you can only "juggle" a limited set of symbols/challenges at the same time. Basically if you should visually "feel" that something is an array etc. "int" is so common so that symbol is not read but instantly recognised. Colours in an editor might also help. Layout helps. Redundant cues help. The basic goal should be that the logical structure of the program should be available as visual patterns that can be directly detected without reasoning, not as indirection (like names with no visual cues) that requires interpretation and conscious cognitive effort. Ola.
Dec 14 2013
parent "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 14 December 2013 at 21:47:52 UTC, Ola Fosheim 
Grøstad wrote:
 No, if you have strong distinct visual cues the brain does not 
 have to reason but you will use the pattern-recognition that 
 your brain supports for classifying visual cues in our natural 
 environment. The moment you have to think about what an 
 identifier means you have started to strain the brain. You are 
 being slowed down and will become more tired and make more 
 mistakes because you can only "juggle" a limited set of 
 symbols/challenges at the same time.

 Basically if you should visually "feel" that something is an 
 array etc. "int" is so common so that symbol is not read but 
 instantly recognised. Colours in an editor might also help. 
 Layout helps. Redundant cues help.  The basic goal should be 
 that the logical structure of the program should be available 
 as visual patterns that can be directly detected without 
 reasoning, not as indirection (like names with no visual cues) 
 that requires interpretation and conscious cognitive effort.
FWIW, I understand some what you're saying. I get your point that it'd be nice if some visual cue existed that made it obvious that it was a template instantiation without learning the meaning. What I don't understand is why you think that such a thing must exist. I suspect such a thing doesn't exist, but I, obviously, cannot prove that. Again, I'd love to see your idea of the syntax you're describing. From my perspective, I think that the "transparent instant recognition" thing you describe is learned. It's not unreasonable to require someone to learn the new syntax and now that I'm comfortable with D, infix !s (which are actually very distinct from prefix !s) give me the exact same visual feeling you're saying they should. I suspect you'd get comfortable with it over time as well. You should realize that your brain is far more powerful than you're giving it credit for. It's specifically designed to adapt over time to the environment and the pattern-recognition your brain has is more than capable of adapting to distinguishing the difference between an infix ! and a prefix !. That said, I'm not suggesting the syntax is perfect. I'd _still_ like to hear your ideas for better syntaxes ...
Dec 14 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2013 12:37 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 "<>" is much more visually distinct,
Only in trivial code. If it is mixed up with shifting and comparison operators, which are hardly rare, it becomes hellish.
Dec 14 2013
parent "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 15 December 2013 at 04:55:47 UTC, Walter Bright wrote:
 On 12/14/2013 12:37 PM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 "<>" is much more visually distinct,
Only in trivial code. If it is mixed up with shifting and comparison operators, which are hardly rare, it becomes hellish.
I used to find !() quite ugly as well, and <> nice, but that came from being used to how other languages did templates. In D template parameters can be much more complex which I feel the !() deals with better. For the ones that aren't complex, they're usually just a single argument and foo!arg handled that just fine.
Dec 14 2013
prev sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 14 December 2013 at 20:00:30 UTC, Brian Rogoff wrote:
 Composite brackets, a-la the SPECS 'C++ Resyntaxed' ** 
 proposal, would work. <[]>, <[<[]>]> may be a bit heavy but not 
 too bad.

 I haven't found the !() syntax for D templates to be a problem 
 though and prefer it to <> from C++ and Java. If I were 
 searching for D blemishes, I wouldn't look there first.

 -- Brian

 ** 
 http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
I'd like to note that I _loved_ that paper the first time I read it. I actually saved it to my Dropbox to refer back to if I ever decided to write my own language. But composite brackets honestly seem a bit too heavy, like you said. When I saw D's usage of an infix !, I was more intrigued. Especially after the ()s were made optional when the template instantiation was a single token long. Very convenient to type and, more importantly, read IMO.
Dec 14 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2013 11:32 AM, Chris Cain wrote:
 I'm just curious, not trying to say you're wrong. I do think it's a huge step
up
 from C++'s templates and, personally, I love the new syntax with an infix ! for
 instantiating templates. But if something better could be used, I'm interested
 in hearing the ideas too.
There have been a lot of proposals here over the years for a "something better" template syntax, and they were all worse.
Dec 14 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 12/14/2013 11:32 AM, Chris Cain wrote:

 But still, _what exactly_ should be used instead of the "not-operator"?
 "Anything" is too vague and not true. You probably can't use these:
 ][+=-_,.|`\/"'><;:}{%^&*
How about something closer: s = i.to¡string; :p Ali
Dec 14 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Sunday, 15 December 2013 at 05:28:51 UTC, Ali Çehreli wrote:
 How about something closer:

     s = i.to¡string;

 :p

 Ali
I know you were just kidding, but honestly if it didn't take some extra setup to get the average American keyboard to type like that, I think "special" (using that a bit liberally) characters like that would work out okay. I really wish we could change the keyboard to support that kinda thing... maybe like how the Macs do it. But, alas, it's never going to happen and it makes me sad :(
Dec 14 2013
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Sunday, 15 December 2013 at 05:40:17 UTC, Chris Cain wrote:
 On Sunday, 15 December 2013 at 05:28:51 UTC, Ali Çehreli wrote:
 How about something closer:

    s = i.to¡string;

 :p

 Ali
I know you were just kidding, but honestly if it didn't take some extra setup to get the average American keyboard to type like that, I think "special" (using that a bit liberally) characters like that would work out okay. I really wish we could change the keyboard to support that kinda thing... maybe like how the Macs do it. But, alas, it's never going to happen and it makes me sad :(
What about using a preprocessor? Wouldn't be hard to have it turn all ¡ into !.
Dec 14 2013
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Sunday, 15 December 2013 at 07:26:30 UTC, logicchains wrote:
 What about using a preprocessor? Wouldn't be hard to have it 
 turn all ¡ into !.
There is a Venn diagram of "things we can do" and "things that are really bad ideas". The overlap is surprisingly large.
Dec 14 2013
parent "Chris Cain" <clcain uncg.edu> writes:
On Sunday, 15 December 2013 at 07:56:12 UTC, Brian Schott wrote:
 There is a Venn diagram of "things we can do" and "things that 
 are really bad ideas". The overlap is surprisingly large.
You win my "quote of the day award". Your prize is ... the fact that you put a smile on my face! Enjoy.
Dec 15 2013
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 15 December 2013 at 07:26:30 UTC, logicchains wrote:
 What about using a preprocessor? Wouldn't be hard to have it 
 turn all ¡ into !.
That's my Spanish program buggered, then.
Dec 14 2013
parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Sun, Dec 15, 2013 at 8:59 AM, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On Sunday, 15 December 2013 at 07:26:30 UTC, logicchains wrote:
 What about using a preprocessor? Wouldn't be hard to have it turn all ¡
 into !.
That's my Spanish program buggered, then.
In Spanish D, we put ¡ *around* template instantiations: auto m = map¡(x => x+1)!(myRange);
Dec 15 2013
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 15 December 2013 at 08:05:42 UTC, Philippe Sigaud 
wrote:
 On Sun, Dec 15, 2013 at 8:59 AM, Joseph Rushton Wakeling
 <joseph.wakeling webdrake.net> wrote:
 That's my Spanish program buggered, then.
In Spanish D, we put ¡ *around* template instantiations: auto m = map¡(x => x+1)!(myRange);
auto response = ¿(joke == good)? laughter : bulls; :-)
Dec 15 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2013 8:22 AM, "Ola Fosheim Grøstad"
 Regarding using the not-operator for non-not-operations: anything would be
 better than reusing operators that are commonly used to affect control-flow. It
 makes it difficult to comprehend control flow when you skim code you are not
 familiar with. "not" tends to be used for completely changing the flow of a
 program so those "!" are attention-seekers when trying comprehend unfamiliar
code.
Since C uses * for thoroughly unrelated operations multiply and indirection, and I've never heard a complaint about that, I don't see the rationale that ! would be confusing to use as a binary operator as compelling.
 3. No high performing authoritative compiler suite.
Yes, there is one, and it is run automatically on every pull request to the compiler & libraries.
Dec 14 2013
prev sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 14 December 2013 at 03:55:29 UTC, Ola Fosheim 
Grøstad wrote:
 And, why, why, why would anyone think that it is a good idea to
 use the boolean negate-operator for templates? Talk about making
 my eyes sore!
I have to wonder about this point. What would you have used instead?
Dec 13 2013
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 13 December 2013 at 17:30:09 UTC, Manu wrote:
 I take druntime and phobos as they are the largest and most 
 widely used
 body of D code, along with many other projects I've run into 
 that also
 follow that lead. I'm yet to encounter any exceptions.
If you ever used the Derelict-style bindings for Assimp I threw together (and which are hopelessly out of date at this point), which I remember you mentioning quite some while ago, that's not true. ;) I prefer this style and use it for all my personal projects, as I feel it makes inferring the structure glancing over the code a bit easier for me. Though, honestly, it doesn't really matter to me at this point. I just want to point out that I would hardly consider it to be a Java-only thing. The style is not only used in the K&R book, but also in many well-known C/C++ projects such as LLVM, and IIRC is also called for in Google's internal C++ style guide. David
Dec 13 2013
next sibling parent Manu <turkeyman gmail.com> writes:
On 14 December 2013 04:53, David Nadlinger <code klickverbot.at> wrote:

 On Friday, 13 December 2013 at 17:30:09 UTC, Manu wrote:

 I take druntime and phobos as they are the largest and most widely used
 body of D code, along with many other projects I've run into that also
 follow that lead. I'm yet to encounter any exceptions.
If you ever used the Derelict-style bindings for Assimp I threw together (and which are hopelessly out of date at this point), which I remember you mentioning quite some while ago, that's not true. ;) I prefer this style and use it for all my personal projects, as I feel it makes inferring the structure glancing over the code a bit easier for me. Though, honestly, it doesn't really matter to me at this point. I just want to point out that I would hardly consider it to be a Java-only thing. The style is not only used in the K&R book, but also in many well-known C/C++ projects such as LLVM, and IIRC is also called for in Google's internal C++ style guide.
Fair enough. I concede. The reason I raise the issue is that I like the sense of agreement within Java. I'd like to think there's opportunity to promote a prevailing standard in D the same as in Java (especially in code presented for public scrutiny). The argument simply doesn't come up when writing Java code, and I like that everyone agrees that way. I don't care which, I just like consistency. And it seemed to me that the largest body of D code as maintained by the official community should probably define such a standard, but clearly that boat has long sailed, so I guess it doesn't matter.
Dec 13 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 14/12/13 03:17, Manu wrote:
 I don't care which, I just like consistency. And it seemed to me that the
 largest body of D code as maintained by the official community should probably
 define such a standard, but clearly that boat has long sailed, so I guess it
 doesn't matter.
For quite a long time I wrote D code using essentially the same coding style I'd adopted for C/C++: K&R style braces, tabs for indent/spaces for alignment, probably one or two other things I can't recall now. (Basically apart from the strict indentation rules, I swiped it from the Linux Kernel guidelines, on the grounds that this was probably A Good Thing:-) Then I started contributing to Phobos and realized that I'd have to adapt an alternative style for those contributions, and I didn't like it much; and I went so far as to use different editors for my personal D work and for Phobos work. Then when I came to the point of writing stuff of my own for immediate public distribution I realized that I was being silly and that if I wanted to write stuff that was usable for everyone, I might as well just use the standard D style guide for everything. And now I do, and to be honest I can't work out why I was so keen to hang on to my previous style (which I'd probably still use for C/C++ where it's more idiomatic). It's just a style, and as long as it's simple and easy to follow and to implement automatically in an editor, the details don't really matter. It just matters that we have a style and it would be a good thing if publicly-shared repositories all made use of it.
Dec 13 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/13/13 9:29 AM, Manu wrote:
 On 14 December 2013 03:10, Brian Rogoff <brogoff gmail.com
 <mailto:brogoff gmail.com>> wrote:

     On Friday, 13 December 2013 at 16:40:13 UTC, Manu wrote:

         I'm just saying, if it's code to be compared against other
         languages, then
         it should conform to the general standards of the language.
         I've never seen D code use egyptian braces.


     You've never read TDPL.


 Published material, optimised for print. Andrei admits this. He uses C
 braces in his code.
Facebook uses Egyptian braces in its D code. Andrei
Dec 13 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, December 13, 2013 13:04:13 Andrei Alexandrescu wrote:
 Facebook uses Egyptian braces in its D code.
My condolences. ;) - Jonathan M Davis
Dec 13 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 On Friday, December 13, 2013 13:04:13 Andrei Alexandrescu wrote:
 Facebook uses Egyptian braces in its D code.
My condolences. ;)
Rosettacode D entries code use Egyptian braces (also to reduce waste vertical space in the page). Bye, bearophile
Dec 13 2013
prev sibling next sibling parent John J <john.joyus gmail.com> writes:
On 12/13/2013 06:08 PM, Jonathan M Davis wrote:
 On Friday, December 13, 2013 13:04:13 Andrei Alexandrescu wrote:
 Facebook uses Egyptian braces in its D code.
My condolences. ;)
+1 I recently coded my first D program with Egyptian brackets, but when I later removed that style, my code instantly became clear and more readable!! I am going to stay away from the Egyptian brackets as if it's a curse of the Pharaohs! :)
Dec 13 2013
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 14.12.2013 00:08, schrieb Jonathan M Davis:
 On Friday, December 13, 2013 13:04:13 Andrei Alexandrescu wrote:
 Facebook uses Egyptian braces in its D code.
My condolences. ;) - Jonathan M Davis
I love them and it always an headache when using other styles. Anyway if you want to start a programmer civil war, you just need to ask for what is the right style in any given language. :) -- Paulo
Dec 14 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2013 1:04 PM, Andrei Alexandrescu wrote:
 Facebook uses Egyptian braces in its D code.
Egypt, Egypt! by The Egyptian Braces http://www.youtube.com/watch?v=qjFs9CPGhts (I actually have this record in the basement somewhere.)
Dec 15 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/13/2013 05:40 PM, Manu wrote:
 On 14 December 2013 02:12, Timon Gehr <timon.gehr gmx.ch
 <mailto:timon.gehr gmx.ch>> wrote:

     On 12/13/2013 05:05 PM, Manu wrote:


         Is it idiomatic to use egyptian braces in D?


     Brackets? Yes.


 [] is brackets, {} is braces.
 ...
[] // angle brackets {} // curly brackets, braces if(..){ // egyptian brackets } http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html Note that egyptian brackets is way easier to google than egyptian braces, and the latter term does not occur in any of the results on the first page as far as I can see.
         I've never seen D code written this way...
         looks like Java.


     Not really, no.


 No, as in, people 'not really' write D code that way, or no as in, it
 doesn't look like java, except that it does, because only it and
 javascript have idiomatic egyptian braces... ;)
 ...
D code does not look like Java code.
 I'm just saying, if it's code to be compared against other languages,
 then it should conform to the general standards of the language.
The language is whitespace-agnostic except for delimiting tokens.
 I've never seen D code use egyptian braces.
I've never heard the term egyptian braces. Also, I don't believe you. http://dlang.org
 Certainly the vast majority of D code doesn't.
The vast majority seems to use the term 'egyptian brackets'.
 I don't care which, but stick with one as a
 'standard'. D has clearly chosen C braces, not Java braces, all the
 standard libraries agree.
 ...
Well, Phobos is not even fully consistent here, ../dmd-2.064/src/phobos/std$ grep ")\s*{" *.d | wc -l 2070 even if we allow if(...){ } etc., .../dmd-2.064/src/phobos/std$ grep ")\s*{[^}]*$" *.d | wc -l 743
 If you were going to publish some Java code using C braces,
I don't.
 how would you feel about that?
Why does this matter?
Dec 13 2013
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 12/13/2013 08:40 AM, Manu wrote:

 On 14 December 2013 02:12, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 12/13/2013 05:05 PM, Manu wrote:

 Is it idiomatic to use egyptian braces in D?
Thanks for teaching me a new term. :)
 Brackets? Yes.
[] is brackets, {} is braces.
I used to call the latter "curly braces" as well but I was corrected some time ago. Now I call them curly brackets.
   I've never seen D code written this way...
It is very common in D.learn as well. Ali
Dec 13 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 14 December 2013 08:02, Ali =C3=87ehreli <acehreli yahoo.com> wrote:

 On 12/13/2013 08:40 AM, Manu wrote:
 Brackets? Yes.
[] is brackets, {} is braces.
I used to call the latter "curly braces" as well but I was corrected some time ago. Now I call them curly brackets.
http://en.wikipedia.org/wiki/Bracket The big text in the top right says braces. Reading further... seems there's a lot of disagreement on the matter. However, the very first term; it's unusual the UK and the US both allegedly agree on something. I accept that as a sign! ;)
Dec 13 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-12-14 03:24, Manu wrote:

 http://en.wikipedia.org/wiki/Bracket
 The big text in the top right says braces. Reading further... seems
 there's a lot of disagreement on the matter. However, the very first
 term; it's unusual the UK and the US both allegedly agree on something.
 I accept that as a sign! ;)
"Tuborg brackets" - best name ever :D. That should be the official name in D :) -- /Jacob Carlborg
Dec 14 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 13/12/13 23:02, Ali Çehreli wrote:
 Thanks for teaching me a new term. :)
Yea, my reaction was something like -- "What??!! [one Google later] Oh. K&R style." Except that strictly speaking, K&R style has functions' opening braces on a separate line and only conditionals' opening braces on the same line.
Dec 13 2013
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 13 December 2013 at 16:40:13 UTC, Manu wrote:
 No, as in, people 'not really' write D code that way, or no as 
 in, it
 doesn't look like java, except that it does, because only it 
 and javascript
 have idiomatic egyptian braces... ;)
I write all my D code that way, except that which is merged to Phobos (which is still written "Egyptian" and I have to later format it). You'll hate vibe.d since it seems to be the chaos you don't want: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/inet/webform.d Personally I don't care, reading, I won't notice. However I can't write the code any other way without spending lots of time on formatting. And I prefer the Egyptian.
Dec 13 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 December 2013 at 16:06:10 UTC, Manu wrote:
 Is it idiomatic to use egyptian braces in D? I've never seen D 
 code written
 this way... looks like Java.
If by "idiomatic" you mean "Phobos style guidelines", then - no. But idiomatic D is something I don't have clear grasp of :)
Dec 13 2013