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