www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D and Nim

reply "Jonathan" <jadit2 gmail.com> writes:
Hey folks,

I've been recently checking out Nim/rod and feel like it takes a 
lot of inspiration from D (I think the creator was in the D 
community too as some point). How do you think it compares? What 
areas does D, in principle, makes it a better choice? To give you 
my background, I like creating games (mostly using SDL bindings) 
using new languages, aiming for the most efficient yet concise 
way to write the engine and game logic.

FYI, this is NOT a language war thread. I'm just curious about 
what separates them from a principle level.
Jan 04 2015
next sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2015-01-04 18:10:51 +0000, Jonathan said:


 Hey folks,
 
 I've been recently checking out Nim/rod and feel like it takes a lot of 
 inspiration from D (I think the creator was in the D community too as 
 some point). How do you think it compares? What areas does D, in 
 principle, makes it a better choice? To give you my background, I like 
 creating games (mostly using SDL bindings) using new languages, aiming 
 for the most efficient yet concise way to write the engine and game 
 logic.
 
 FYI, this is NOT a language war thread. I'm just curious about what 
 separates them from a principle level.


I just heard about this language the other hanging out with some other 
techies.   I like that it makes some common idioms in D first-class 
citizens.   For example, imperative type declarations are first-class 
citizens so all the boiler plate around "if (isInputRange!(R))" type 
stuff goes away in Nim.  Unfortunately, they decided to use whitespace 
to define scope :/

-S.
Jan 04 2015
prev sibling next sibling parent "JN" <666total wp.pl> writes:
It's compiling to C, I suppose it should be much easier to port 
to other platforms than for example D?
Jan 04 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:

 Hey folks,

 I've been recently checking out Nim/rod and feel like it takes 
 a lot of inspiration from D (I think the creator was in the D 
 community too as some point). How do you think it compares? 
 What areas does D, in principle, makes it a better choice? To 
 give you my background, I like creating games (mostly using SDL 
 bindings) using new languages, aiming for the most efficient 
 yet concise way to write the engine and game logic.

 FYI, this is NOT a language war thread. I'm just curious about 
 what separates them from a principle level.


AFAIK nim has a much better GC implementation for soft real-time 
applications because it can be paused.
Jan 04 2015
parent "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Sunday, 4 January 2015 at 19:06:34 UTC, weaselcat wrote:

 AFAIK nim has a much better GC implementation for soft 
 real-time applications because it can be paused.


What about GC.disable?
Jan 04 2015
prev sibling next sibling parent "Mengu" <mengukagan gmail.com> writes:
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:

 Hey folks,

 I've been recently checking out Nim/rod and feel like it takes 
 a lot of inspiration from D (I think the creator was in the D 
 community too as some point). How do you think it compares? 
 What areas does D, in principle, makes it a better choice? To 
 give you my background, I like creating games (mostly using SDL 
 bindings) using new languages, aiming for the most efficient 
 yet concise way to write the engine and game logic.

 FYI, this is NOT a language war thread. I'm just curious about 
 what separates them from a principle level.


i agree. i first saw nim related threads on HN and they were 
mentioning it has CTFE, UFCS and many things that D already has. 
it got me wondering whether nim was inspired by D.
Jan 04 2015
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/4/15 3:10 PM, Jonathan wrote:

 Hey folks,

 I've been recently checking out Nim/rod and feel like it takes a lot of
 inspiration from D (I think the creator was in the D community too as
 some point). How do you think it compares? What areas does D, in
 principle, makes it a better choice? To give you my background, I like
 creating games (mostly using SDL bindings) using new languages, aiming
 for the most efficient yet concise way to write the engine and game logic.

 FYI, this is NOT a language war thread. I'm just curious about what
 separates them from a principle level.


In my opinion Nim is superior than D in every aspect (and I say this as 
my personal opinion, not to trigger a language war).

There are examples of D code in these two repos:

https://github.com/logicchains/LPATHBench
https://github.com/kostya/benchmarks

Take a look at for example the first one in D and Nim:

https://github.com/logicchains/LPATHBench/blob/master/d.d
https://github.com/logicchains/LPATHBench/blob/master/nim.nim

According to the writeup:

https://github.com/logicchains/LPATHBench/blob/master/writeup.md

Nim is faster than D. And it does so with much less code.

Then look at kostya/benchmarks: D is always behind Nim (except matuml, 
where they are similar, but all statically compiled languages are 
similar in that one). And Nim's code is always shorter and cleaner. (and 
before you reply to this with "but if you add pure nothrow  safe 
 abracadabra", continue reading)

There was a time I liked D. But now to make the code fast you have to 
annotate things with pure nothrow  safe to make sure the compiler 
generates fast code. This leads to code that's uglier and harder to 
understand.

Another point is that Nimrod has CTFE but does so with a virtual 
machine, so I'm sure it's faster than D in that aspect.

Then, Nim is written in Nim. Having the compiler be written in itself is 
a good way to immediately have the developers of the language get the 
feeling of the language, find bugs and improve it. Nim has 363 issues 
accoring to https://github.com/Araq/Nim/issues . D has 2444 according to 
https://issues.dlang.org/buglist.cgi?component=DMD&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=D&query_format=adv
nced&resolution=--- 
. Also, because the compiler is written in itself, everything is garbage 
collected, so there are no worried when doing CTFE (D's CTFE consumes a 
lot of memory, I read in this newsgroup). Nim compiles itself in between 
2.5 and 5 seconds.

Also, I get the feeling that D has too many features and not all of them 
work in harmony with the rest of them. So people always find small bugs 
and others suggest workarounds and eventually people learn to program in 
a WDD way (Workaround-development-driven).

Back to LPATHBench, I find things like minimallyInitializedArray and 
uninitializedArray, which are great for optimizing things, but it's sad 
that one has to use these special functions instead of regular ones 
(idiomatic code) to achieve better performance. Also, "uninitialized" 
sounds unsafe... And then you must compile your code with -noboundscheck 
to get more performance, but that's so unsafe...

But then, both D and Nim have things which I dislike: too many built-in 
things. Static arrays, arrays, sequences, etc. Can't these be just 
implemented in D/Nim? Why the need for special built-in types with 
special operations?

Anyway, just my opinion :-)
Jan 04 2015
next sibling parent "Jonathan" <jadit2 gmail.com> writes:
I will say that Nim's documentation is severely lacking, even 
compared to D. For example, it took me far more time figuring out 
Nim's file io operations.
Jan 04 2015
prev sibling next sibling parent "Bioinfornatics" <bioinfornatics fedoraproject.org> writes:
Thanks I will try it.  It seems really cool. Maybe my new
favorite language.
Jan 04 2015
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 But now to make the code fast you have to annotate things with 
 pure nothrow  safe to make sure the compiler generates fast 
 code.


Do you have any proof of this?



 Nim has 363 issues accoring to 
 https://github.com/Araq/Nim/issues . D has 2444 according to


So are Nim developers still in need to find more than two 
thousand unknown issues? ;-)

Bye,
bearophile
Jan 04 2015
parent "Meta" <jared771 gmail.com> writes:
On Sunday, 4 January 2015 at 22:55:52 UTC, bearophile wrote:

 Nim has 363 issues accoring to 
 https://github.com/Araq/Nim/issues . D has 2444 according to


 So are Nim developers still in need to find more than two 
 thousand unknown issues? ;-)


I agree, it's more likely that there are more undiscovered bugs 
in Nim than D, not fewer bugs, if both languages have around the 
same number of features. Nim also probably has a smaller 
development team and fewer users to find and submit bugs.
Jan 04 2015
prev sibling next sibling parent reply "anonymous" <anonymous example.com> writes:
On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:

 On 1/4/15 3:10 PM, Jonathan wrote:

 Hey folks,

 I've been recently checking out Nim/rod and feel like it takes 
 a lot of
 inspiration from D (I think the creator was in the D community 
 too as
 some point). How do you think it compares? What areas does D, 
 in
 principle, makes it a better choice? To give you my 
 background, I like
 creating games (mostly using SDL bindings) using new 
 languages, aiming
 for the most efficient yet concise way to write the engine and 
 game logic.

 FYI, this is NOT a language war thread. I'm just curious about 
 what
 separates them from a principle level.


 In my opinion Nim is superior than D in every aspect (and I say 
 this as my personal opinion, not to trigger a language war).


You do want a language war because your spewing too much
bullshit. I dabbled in both d and nim/rod. All interesting in nim
is whats taken from d.


 There are examples of D code in these two repos:

 https://github.com/logicchains/LPATHBench
 https://github.com/kostya/benchmarks

 Take a look at for example the first one in D and Nim:

 https://github.com/logicchains/LPATHBench/blob/master/d.d
 https://github.com/logicchains/LPATHBench/blob/master/nim.nim

 According to the writeup:

 https://github.com/logicchains/LPATHBench/blob/master/writeup.md

 Nim is faster than D. And it does so with much less code.


Bullshit. dmd is easy to beat. also json parsing? library issue.


 Then look at kostya/benchmarks: D is always behind Nim (except 
 matuml, where they are similar, but all statically compiled 
 languages are similar in that one). And Nim's code is always 
 shorter and cleaner. (and before you reply to this with "but if 
 you add pure nothrow  safe  abracadabra", continue reading)


Bullshit. Main differences are nim has significant whitespace.
Code looks shorter because theres less {}. Second difference is
nim has code at top level. Great for short benchmarks but aweful
in large code.


 There was a time I liked D. But now to make the code fast you 
 have to annotate things with pure nothrow  safe to make sure 
 the compiler generates fast code. This leads to code that's 
 uglier and harder to understand.


Bullshit. That stuff makes d more modular than nim.


 Another point is that Nimrod has CTFE but does so with a 
 virtual machine, so I'm sure it's faster than D in that aspect.


How does that make the language superior? Bullshit again.


 Then, Nim is written in Nim.


How does that make the language superior? Bullshit again.


 Having the compiler be written in itself is a good way to 
 immediately have the developers of the language get the feeling 
 of the language, find bugs and improve it.


ddmd


 Nim has 363 issues accoring to 
 https://github.com/Araq/Nim/issues . D has 2444 according to 
 https://issues.dlang.org/buglist.cgi?component=DMD&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=D&query_format=advanced&resolution=---


Bullshit. Thats nimrod is less popular than dmd. Jesus i cant
believe you can smoke that.


 . Also, because the compiler is written in itself, everything 
 is garbage collected, so there are no worried when doing CTFE 
 (D's CTFE consumes a lot of memory, I read in this newsgroup). 
 Nim compiles itself in between 2.5 and 5 seconds.


How does that make the language superior? Bullshit again.


 Also, I get the feeling that D has too many features and not 
 all of them work in harmony with the rest of them. So people 
 always find small bugs and others suggest workarounds and 
 eventually people learn to program in a WDD way 
 (Workaround-development-driven).


Also, I get the feeling your bullshitting through your ears.


 Back to LPATHBench, I find things like 
 minimallyInitializedArray and uninitializedArray, which are 
 great for optimizing things, but it's sad that one has to use 
 these special functions instead of regular ones (idiomatic 
 code) to achieve better performance. Also, "uninitialized" 
 sounds unsafe... And then you must compile your code with 
 -noboundscheck to get more performance, but that's so unsafe...


Bullshit.


 But then, both D and Nim have things which I dislike: too many 
 built-in things. Static arrays, arrays, sequences, etc. Can't 
 these be just implemented in D/Nim? Why the need for special 
 built-in types with special operations?

 Anyway, just my opinion :-)


Just a load of bullshit.
Jan 04 2015
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/4/15 8:17 PM, anonymous wrote:

 On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:

 On 1/4/15 3:10 PM, Jonathan wrote:


 Bullshit. dmd is easy to beat. also json parsing? library issue.


If there are library issues (like a slow json parser, or an unusable 
one), these should be top priority instead of adding more features (C++ 
interop?) to the language. Once everything is smooth more things can be 
added. Otherwise there's always the feeling that things aren't quite 
stable and fast enough.
Jan 04 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/4/15 6:04 PM, Ary Borenszweig wrote:

 On 1/4/15 8:17 PM, anonymous wrote:

 On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:

 On 1/4/15 3:10 PM, Jonathan wrote:


 Bullshit. dmd is easy to beat. also json parsing? library issue.


 If there are library issues (like a slow json parser, or an unusable
 one), these should be top priority instead of adding more features (C++
 interop?) to the language. Once everything is smooth more things can be
 added. Otherwise there's always the feeling that things aren't quite
 stable and fast enough.


That's a good point. The new json is blocked on Sönke who is remodeling 
his home. -- Andrei
Jan 04 2015
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/4/15 8:17 PM, anonymous wrote:

 On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:

 On 1/4/15 3:10 PM, Jonathan wrote:

 Hey folks,

 I've been recently checking out Nim/rod and feel like it takes a lot of
 inspiration from D (I think the creator was in the D community too as
 some point). How do you think it compares? What areas does D, in
 principle, makes it a better choice? To give you my background, I like
 creating games (mostly using SDL bindings) using new languages, aiming
 for the most efficient yet concise way to write the engine and game
 logic.

 FYI, this is NOT a language war thread. I'm just curious about what
 separates them from a principle level.


 In my opinion Nim is superior than D in every aspect (and I say this
 as my personal opinion, not to trigger a language war).


 You do want a language war because your spewing too much
 bullshit. I dabbled in both d and nim/rod. All interesting in nim
 is whats taken from d.


As I said, it's just my personal opinion. Others have said D is superior 
to Nim and they gave their reasons.


 There are examples of D code in these two repos:

 https://github.com/logicchains/LPATHBench
 https://github.com/kostya/benchmarks

 Take a look at for example the first one in D and Nim:

 https://github.com/logicchains/LPATHBench/blob/master/d.d
 https://github.com/logicchains/LPATHBench/blob/master/nim.nim

 According to the writeup:

 https://github.com/logicchains/LPATHBench/blob/master/writeup.md

 Nim is faster than D. And it does so with much less code.


 Bullshit. dmd is easy to beat. also json parsing? library issue.


 Then look at kostya/benchmarks: D is always behind Nim (except matuml,
 where they are similar, but all statically compiled languages are
 similar in that one). And Nim's code is always shorter and cleaner.
 (and before you reply to this with "but if you add pure nothrow  safe
  abracadabra", continue reading)


 Bullshit. Main differences are nim has significant whitespace.
 Code looks shorter because theres less {}. Second difference is
 nim has code at top level. Great for short benchmarks but aweful
 in large code.


I actually meant all those annotations (pure nothrow safe immutable 
final) that appear every time someone ones to get their code run fast.


 There was a time I liked D. But now to make the code fast you have to
 annotate things with pure nothrow  safe to make sure the compiler
 generates fast code. This leads to code that's uglier and harder to
 understand.


 Bullshit. That stuff makes d more modular than nim.


How "pure nothrow  safe" make things more modular?


 Another point is that Nimrod has CTFE but does so with a virtual
 machine, so I'm sure it's faster than D in that aspect.


 How does that make the language superior? Bullshit again.


Many have complained that CTFE can take about 2 gigs of memory so they 
can't compile their programs (I think related to vibe.d templates). If 
that memory was garbage collected there would be no problem. Of course, 
DMD can have a GC, Walter said it before, but it slowed down things. Nim 
compiles itself in 2.5~5 seconds with a GC on (I think, please correct 
me if this is wrong). In any case Crystal compiles itself in about the 
same time with a GC on, so disabling a GC for speed shouldn't be an excuse.


 Then, Nim is written in Nim.


 How does that make the language superior? Bullshit again.


 Having the compiler be written in itself is a good way to immediately
 have the developers of the language get the feeling of the language,
 find bugs and improve it.


 ddmd


But the main D developers are using dmd, written in C++. I'm not sure 
they have written large D programs, as big as a compiler (but correct me 
if I'm wrong). Having a compiler written in D can make things more 
stable, and authors can improve the language as they get immediate 
feedback. At least that's how I feel it when I develop Crystal.


 Nim has 363 issues accoring to https://github.com/Araq/Nim/issues . D
 has 2444 according to
 https://issues.dlang.org/buglist.cgi?component=DMD&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=D&query_format=advanced&resolution=---


 Bullshit. Thats nimrod is less popular than dmd. Jesus i cant
 believe you can smoke that.


You might be right, I didn't think of that.


 . Also, because the compiler is written in itself, everything is
 garbage collected, so there are no worried when doing CTFE (D's CTFE
 consumes a lot of memory, I read in this newsgroup). Nim compiles
 itself in between 2.5 and 5 seconds.


 How does that make the language superior? Bullshit again.


 Also, I get the feeling that D has too many features and not all of
 them work in harmony with the rest of them. So people always find
 small bugs and others suggest workarounds and eventually people learn
 to program in a WDD way (Workaround-development-driven).


 Also, I get the feeling your bullshitting through your ears.


 Back to LPATHBench, I find things like minimallyInitializedArray and
 uninitializedArray, which are great for optimizing things, but it's
 sad that one has to use these special functions instead of regular
 ones (idiomatic code) to achieve better performance. Also,
 "uninitialized" sounds unsafe... And then you must compile your code
 with -noboundscheck to get more performance, but that's so unsafe...


 Bullshit.


Well, at least give me a reason why most people here recommend compiling 
with -noboundscheck to get optimal code.


 But then, both D and Nim have things which I dislike: too many
 built-in things. Static arrays, arrays, sequences, etc. Can't these be
 just implemented in D/Nim? Why the need for special built-in types
 with special operations?

 Anyway, just my opinion :-)


 Just a load of bullshit.


Maybe.
Jan 04 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2015 6:11 PM, Ary Borenszweig wrote:

 But the main D developers are using dmd, written in C++. I'm not sure they have
 written large D programs, as big as a compiler (but correct me if I'm wrong).


Does Javascript count?

https://github.com/DigitalMars/DMDScript
Jan 04 2015
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/5/15 12:42 AM, Walter Bright wrote:

 On 1/4/2015 6:11 PM, Ary Borenszweig wrote:

 But the main D developers are using dmd, written in C++. I'm not sure
 they have
 written large D programs, as big as a compiler (but correct me if I'm
 wrong).


 Does Javascript count?

 https://github.com/DigitalMars/DMDScript


Definitely!

I take my word then.
Jan 04 2015
prev sibling next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:

 There are examples of D code in these two repos:

 https://github.com/logicchains/LPATHBench
 https://github.com/kostya/benchmarks

 Take a look at for example the first one in D and Nim:

 https://github.com/logicchains/LPATHBench/blob/master/d.d
 https://github.com/logicchains/LPATHBench/blob/master/nim.nim

 According to the writeup:

 https://github.com/logicchains/LPATHBench/blob/master/writeup.md

 Nim is faster than D. And it does so with much less code.


the D implementation was a straight translation from C++ and the 
nim version was written by a regular nimrod contributor...
Jan 04 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2015 1:46 PM, Ary Borenszweig wrote:

 There are examples of D code in these two repos:

 https://github.com/logicchains/LPATHBench
 https://github.com/kostya/benchmarks

 Nim is faster than D. And it does so with much less code.


You could write the D version with about the same lines of code as the Nim 
version. For example, the D version has two implementations in it, the Nim one. 
The D version has an extra function it in that is manually inlined in the Nim
one.

The only significant difference is that Nim doesn't use { }, and so saves a
line 
here and there.

For another example,

Nim:

    for neighbour in nodes[nodeId].neighbours:

D:

    foreach(immutable route neighbour; nodes[nodeID].neighbours){

Correctly written D:

     foreach (neighbour; nodes[nodeID].neighbours){

Not a dime's worth of difference. For another,

Nim:

     echo result, " LANGUAGE Nim ", int(duration * 1000)

D:
     printf("%d LANGUAGE D %d\n", len, sw.peek().msecs);

Correctly written D:

     writeln(len, " LANGUAGE D ", sw.peek().msecs);

Pretty much the same for the rest.
Jan 04 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 Nim:

    for neighbour in nodes[nodeId].neighbours:

 D:

    foreach(immutable route neighbour; nodes[nodeID].neighbours){

 Correctly written D:

     foreach (neighbour; nodes[nodeID].neighbours){


I don't agree, the good D way is:

foreach (immutable neighbour; nodes[nodeID].neighbours) {

D programmers should apply const/immutable to every variable that 
doesn't need to mutate.

Bye,
bearophile
Jan 04 2015
next sibling parent "Jonathan" <jadit2 gmail.com> writes:
On a subjective note, I've always felt that D "gets" me as a 
developer. This is extremely subjective, but I found that in many 
cases I could just write code without consulting documentation 
when I was learning the language. Even talking about the 
"immutable" For statement, I discovered this by writing code that 
seemed logical to the situation.
Jan 04 2015
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/4/15 9:27 PM, bearophile wrote:

 Walter Bright:


 Nim:

    for neighbour in nodes[nodeId].neighbours:

 D:

    foreach(immutable route neighbour; nodes[nodeID].neighbours){

 Correctly written D:

     foreach (neighbour; nodes[nodeID].neighbours){


 I don't agree, the good D way is:

 foreach (immutable neighbour; nodes[nodeID].neighbours) {

 D programmers should apply const/immutable to every variable that
 doesn't need to mutate.


Why?
Jan 04 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 5 January 2015 at 01:56:20 UTC, Ary Borenszweig wrote:

 On 1/4/15 9:27 PM, bearophile wrote:

 Walter Bright:


 Nim:

   for neighbour in nodes[nodeId].neighbours:

 D:

   foreach(immutable route neighbour; 
 nodes[nodeID].neighbours){

 Correctly written D:

    foreach (neighbour; nodes[nodeID].neighbours){


 I don't agree, the good D way is:

 foreach (immutable neighbour; nodes[nodeID].neighbours) {

 D programmers should apply const/immutable to every variable 
 that
 doesn't need to mutate.


 Why?


Implies intention of the variable at declaration & gives the 
compiler more opportunities for optimization
Jan 04 2015
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/4/15 11:09 PM, weaselcat wrote:

 On Monday, 5 January 2015 at 01:56:20 UTC, Ary Borenszweig wrote:

 On 1/4/15 9:27 PM, bearophile wrote:

 Walter Bright:


 Nim:

   for neighbour in nodes[nodeId].neighbours:

 D:

   foreach(immutable route neighbour; nodes[nodeID].neighbours){

 Correctly written D:

    foreach (neighbour; nodes[nodeID].neighbours){


 I don't agree, the good D way is:

 foreach (immutable neighbour; nodes[nodeID].neighbours) {

 D programmers should apply const/immutable to every variable that
 doesn't need to mutate.


 Why?


 Implies intention of the variable at declaration & gives the compiler
 more opportunities for optimization


The first, maybe (for me it's noise: if I want to mutate it, I do, 
otherwise I don't).

For the second, the compiler can tell that if you don't assign anything 
more to it then it's immutable. So I'm not sure the second one is true.
Jan 04 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 5 January 2015 at 02:12:21 UTC, Ary Borenszweig wrote:

 For the second, the compiler can tell that if you don't assign 
 anything more to it then it's immutable. So I'm not sure the 
 second one is true.


I'm inclined to believe there's some benefit to explicitly using 
immutable as Walter has written about it more than once, and it's 
in D's own documentation.
While I'm sure the compiler can infer immutability, it probably 
becomes more difficult as the lifetime of the objects become more 
complicated... but I'm in no position to make a statement about 
it, maybe Walter or Andrei could chime in.

http://dlang.org/const3.html
http://www.drdobbs.com/architecture-and-design/optimizing-immutable-and-purity/228700592
Jan 04 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"weaselcat"  wrote in message news:nopttywdkgouyxnlrwcf forum.dlang.org...


 I'm inclined to believe there's some benefit to explicitly using immutable 
 as Walter has written about it more than once, and it's in D's own 
 documentation.
 While I'm sure the compiler can infer immutability, it probably becomes 
 more difficult as the lifetime of the objects become more complicated... 
 but I'm in no position to make a statement about it, maybe Walter or 
 Andrei could chime in.


You're exactly right, the compiler can sometimes tell a variable is never 
modified, but will have serious trouble when it comes to class members, 
indirections, global/tls variables, etc.
Jan 04 2015
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 D programmers should apply const/immutable to every variable 
 that
 doesn't need to mutate.


 Why?


Since some years Computer Science has found that the right
default for variables is to have them immutable, and to have them
mutable on request.

Immutable variables make the code simpler to understand for
programmers and more handy for compilers. The less moving parts
your code has, the better it's for you.

More explanations on request.

Bye,
bearophile
Jan 04 2015
parent reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Monday, 5 January 2015 at 03:56:31 UTC, bearophile wrote:

 Immutable variables make the code simpler to understand for
 programmers and more handy for compilers. The less moving parts
 your code has, the better it's for you.

 More explanations on request.


Can the compiler automatically make variables immutable if it can 
prove that they are never changed in some code?
Jan 04 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Vlad Levenfeld:


 Can the compiler automatically make variables immutable if it 
 can prove that they are never changed in some code?


This is very different from what I am saying. The C compilers 
don't go to add a "const" annotation to your source code (but 
perhaps the Rust compiler warns about mut variables that don't 
get mutated).

Inferring that a D template function is pure because it contains 
no side effects is not the same thing as stating it is pure in 
the source code. In the second case you get an error if you try 
to print from the function, it's part of the function contract.

Bye,
bearophile
Jan 04 2015
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/5/15 1:54 AM, bearophile wrote:

 Vlad Levenfeld:


 Can the compiler automatically make variables immutable if it can
 prove that they are never changed in some code?


 This is very different from what I am saying. The C compilers don't go
 to add a "const" annotation to your source code (but perhaps the Rust
 compiler warns about mut variables that don't get mutated).

 Inferring that a D template function is pure because it contains no side
 effects is not the same thing as stating it is pure in the source code.
 In the second case you get an error if you try to print from the
 function, it's part of the function contract.

 Bye,
 bearophile


Are there proofs of percentage of bugs caused by incorrectly mutating 
variables that were supposed to be immutable? I don't remember having 
such bug in my life.
Jan 04 2015
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ary Borenszweig"  wrote in message news:m8d6g5$hna$1 digitalmars.com... 


 Are there proofs of percentage of bugs caused by incorrectly mutating 
 variables that were supposed to be immutable? I don't remember having 
 such bug in my life.


Every C++ programmer has hit this bug at some point:

struct S
{
    int a;
    S(int a)
    {
        a = a;
    }
};
Jan 04 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jan 05, 2015 at 05:18:36PM +1100, Daniel Murphy via Digitalmars-d wrote:

 "Ary Borenszweig"  wrote in message news:m8d6g5$hna$1 digitalmars.com...
 

Are there proofs of percentage of bugs caused by incorrectly mutating
variables that were supposed to be immutable? I don't remember having such
bug in my life.


 
 Every C++ programmer has hit this bug at some point:
 
 struct S
 {
    int a;
    S(int a)
    {
        a = a;
    }
 };


I actually hit this bug in D. :-/


T

-- 
Nearly all men can stand adversity, but if you want to test a man's character,
give him power. -- Abraham Lincoln
Jan 04 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.4136.1420439089.9932.digitalmars-d puremagic.com...


 struct S
 {
    int a;
    S(int a)
    {
        a = a;
    }
 };


 I actually hit this bug in D. :-/


I like that I can just not define a constructor in D structs and it will 
still let me create them with S(0).  I get to drop at least some of my 
useless init functions.
Jan 04 2015
parent reply "Jonathan" <jadit2 gmail.com> writes:
Thanks everyone for the incite so far! Reading between the lines, 
I gather most thoughts are that both languages are similar in 
their positioning/objectives yet differ in certain domains (e.g. 
generic/template capabilities) and qualities (e.g. Nim 
opinionated choice of scope delimiters). Does that sound logical? 
This was kind of the thing I was fishing for when thinking of the 
post.
Jan 05 2015
next sibling parent reply "Suliman" <evermind live.ru> writes:
What is kill future of Nim?

D is successor of C++, but Nim? Successor of Python?
Jan 05 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 5 January 2015 at 09:51:22 UTC, Suliman wrote:

 What is kill future of Nim?

 D is successor of C++, but Nim? Successor of Python?


A C++ successor is any language that earns its place in a OS 
vendors SDK as the OS official supported language for all OS 
layers.

Which one it will be is still open game.
Jan 05 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 5 January 2015 at 10:21:12 UTC, Paulo  Pinto wrote:

 On Monday, 5 January 2015 at 09:51:22 UTC, Suliman wrote:

 What is kill future of Nim?

 D is successor of C++, but Nim? Successor of Python?


 A C++ successor is any language that earns its place in a OS 
 vendors SDK as the OS official supported language for all OS 
 layers.

 Which one it will be is still open game.


But C++ gained traction before any OS officially supported it 
(sans BeOS)?

Without an ABI, I think C++ will be it's own successor. And I 
think key C++ people know this and will avoid creating an ABI...

Besides that I don't think there will be a single replacement. It 
will more likely be several languages aiming at different domains 
where you have different hardware requirements (hpc, embedded, 
servers, interactive apps...)

D needs to pick one area, and do it well there.

* If D is aiming for conserving memory and realtime apps, then it 
needs better memory model/reference type system,

* if D is aiming for convenient server programmer (that can 
afford wasting memory), then it need to tune the language for 
better garbage collection.

With no tuning... other languages will surpass it. Be it Rust, 
Chapel, Go, Nim or one of the many budding language projects that 
LLVM has inspired...
Jan 05 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 5 January 2015 at 13:13:43 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 5 January 2015 at 10:21:12 UTC, Paulo  Pinto wrote:

 On Monday, 5 January 2015 at 09:51:22 UTC, Suliman wrote:

 What is kill future of Nim?

 D is successor of C++, but Nim? Successor of Python?


 A C++ successor is any language that earns its place in a OS 
 vendors SDK as the OS official supported language for all OS 
 layers.

 Which one it will be is still open game.


 But C++ gained traction before any OS officially supported it 
 (sans BeOS)?


Yes. It was almost immediately adopted by C compiler vendors 
given it came from AT&T and as compatible with C.

UNIX vendors jumped on it for CORBA and telecommunications (C++ 
original field) so by the early 90's pretty much all UNIXes had 
some form of C++ support.

Walter's work was also an influence, given it was the first C++ 
compiler to directly produce native code.

Epoch/Symbian and later OS/400 revisions were also done in C++.

On MS-DOS I was already using C++ back in 1993.


 Without an ABI, I think C++ will be it's own successor. And I 
 think key C++ people know this and will avoid creating an ABI...


C ABI only works in OS that happen to be written in C. There are 
a few where this is not the case. OS/400 is such an example.

For C++ there is the Itanium ABI, COM/WinRT on Windows and the 
upcoming C++17 ABI.


 Besides that I don't think there will be a single replacement. 
 It will more likely be several languages aiming at different 
 domains where you have different hardware requirements (hpc, 
 embedded, servers, interactive apps...)

 D needs to pick one area, and do it well there.

 * If D is aiming for conserving memory and realtime apps, then 
 it needs better memory model/reference type system,

 * if D is aiming for convenient server programmer (that can 
 afford wasting memory), then it need to tune the language for 
 better garbage collection.

 With no tuning... other languages will surpass it. Be it Rust, 
 Chapel, Go, Nim or one of the many budding language projects 
 that LLVM has inspired...


Yes there are lots of options, still the ones that live longer as 
system programming languages, are the ones that get OS vendor 
adoption.

So far, it has always been the case.

--
Paulo
Jan 05 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 5 January 2015 at 13:47:24 UTC, Paulo  Pinto wrote:

 For C++ there is the Itanium ABI, COM/WinRT on Windows and the 
 upcoming C++17 ABI.


If there will be a C++17 ABI and it is adopted, then that will be 
the beginning of the end for C++ IMO. (Wishful thinking... ;-)


 Yes there are lots of options, still the ones that live longer 
 as system programming languages, are the ones that get OS 
 vendor adoption.

 So far, it has always been the case.


By my definition of "system level programming" the only adopted 
system level programming language since the 1980s has been C (and 
C++ only as C-with-bells-and-whistles). Then you have some fringe 
languages such as Ada, and now probably also Rust as it is 
approaching version 1.0.

I cannot really see Nim or D taking that slot. They appear to 
have too wide a scope. I think only a focused language that can 
bring along better optimization and manual memory handling has a 
chance against C/C++ in system programming. (We have to remember 
that C/C++ are moving too with various extensions that also are 
gaining traction: OpenMP, Cilk...)
Jan 05 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 5 January 2015 at 14:22:04 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 5 January 2015 at 13:47:24 UTC, Paulo  Pinto wrote:

 For C++ there is the Itanium ABI, COM/WinRT on Windows and the 
 upcoming C++17 ABI.


 If there will be a C++17 ABI and it is adopted, then that will 
 be the beginning of the end for C++ IMO. (Wishful thinking... 
 ;-)


For your reference, http://isocpp.org/files/papers/n4028.pdf


 Yes there are lots of options, still the ones that live longer 
 as system programming languages, are the ones that get OS 
 vendor adoption.

 So far, it has always been the case.


 By my definition of "system level programming" the only adopted 
 system level programming language since the 1980s has been C 
 (and C++ only as C-with-bells-and-whistles). Then you have some 
 fringe languages such as Ada, and now probably also Rust as it 
 is approaching version 1.0.


Yes, C, C++, Ada have all been adopted by OS vendors for systems 
programming (bare metal/full OS stack).


 I cannot really see Nim or D taking that slot. They appear to 
 have too wide a scope. I think only a focused language that can 
 bring along better optimization and manual memory handling has 
 a chance against C/C++ in system programming. (We have to 
 remember that C/C++ are moving too with various extensions that 
 also are gaining traction: OpenMP, Cilk...)


Sadly me neither. I think C++11/14 has improved the language 
quite a lot.

For those willing to wait until 2017, it will look even better, 
assuming modules and concepts lite get in.

Clang/XCode also brought the .NET/JVM tooling capabilities to 
C++, which is being adopted by other vendors (JetBrains, 
Microsoft, ...).

However, the majority of C++ code out there is mostly pre-C++98 
in style. So what I got to learn from CppCon 2014 videos is that 
I should not miss my C++ days at work.

It also remains to be seen what Apple and Microsoft do with their 
new babies (Swift, .NET Native, Dafny).

--
Paulo
Jan 05 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 5 January 2015 at 14:52:00 UTC, Paulo  Pinto wrote:

 For your reference, http://isocpp.org/files/papers/n4028.pdf


Yeah, I saw that one, but when ABI was brought up in one of the 
CppCon videos I perceived a lack of enthusiasm among the other 
committee members. Maybe I got the wrong impression, we'll see...


 It also remains to be seen what Apple and Microsoft do with 
 their new babies (Swift, .NET Native, Dafny).


Yes. I bet the management of big corporations often focus more on 
what the competitors are doing than pure technical merits. So I 
am pretty sure that Microsoft is keen to have something like 
Swift, just in case. I guess that means increased internal
Jan 05 2015
prev sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Monday, 5 January 2015 at 10:21:12 UTC, Paulo  Pinto wrote:

 On Monday, 5 January 2015 at 09:51:22 UTC, Suliman wrote:

 What is kill future of Nim?

 D is successor of C++, but Nim? Successor of Python?




I'm not sure if you're being serious, but I'd say yes. The space 
where I see Nim being successful is mostly occupied by Python and 
Go. That it can compete with D in some systems programming, or 
for games, is nice, but games are dominated by C++ and I don't 
see how any new language displaces it in the near future. That 
doesn't mean that the OP shouldn't experiment though.

With some effort in the scientific space, I believe that Nim 
could compete with MATLAB/R/Julia, but currently the libraries 
just don't exist. But the language would appeal to scientific 
programmers I think, more so than would D.


 A C++ successor is any language that earns its place in a OS 
 vendors SDK as the OS official supported language for all OS 
 layers.


I think a C++ successor is a language that 'enough' people would 
choose where before they'd have chosen C++. Java has already 
cleared that bar.
Jan 05 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 5 January 2015 at 15:51:14 UTC, Brian Rogoff wrote:

 ...

 I think a C++ successor is a language that 'enough' people 
 would choose where before they'd have chosen C++. Java has 
 already cleared that bar.


Still it leaves out the systems programming space, which is what 
is being discussed.

Java might have again a shot at it, when AOT, value types and the 
new JNR (Java Native Runtime) land, but that is only planned to 
be fully available by Java 10 timeline.

There are implementations like JikesRVM, Excelsior JET Embedded, 
MicroEJ among others that target bare metal, but many developers 
aren't aware of them.


--
Paulo
Jan 05 2015
prev sibling parent "anonymous" <anonymous example.com> writes:
On Monday, 5 January 2015 at 09:51:22 UTC, Suliman wrote:

 What is kill future of Nim?

 D is successor of C++, but Nim? Successor of Python?


Nim is successor of Nimrod.
Jan 05 2015
prev sibling parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Monday, 5 January 2015 at 08:13:29 UTC, Jonathan wrote:

 Thanks everyone for the incite so far! Reading between the 
 lines, I gather most thoughts are that both languages are 
 similar in their positioning/objectives yet differ in certain 
 domains (e.g. generic/template capabilities) and qualities 
 (e.g. Nim opinionated choice of scope delimiters). Does that 
 sound logical? This was kind of the thing I was fishing for 
 when thinking of the post.


First sentence ... did you mean 'insight' or was that some sort
of Freudian slip :o)
Jan 05 2015
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Daniel Murphy:


 Every C++ programmer has hit this bug at some point:

 struct S
 {
    int a;
    S(int a)
    {
        a = a;
    }
 };


I have a bug report for something like that [TM]:
https://issues.dlang.org/show_bug.cgi?id=3878

Bye,
bearophile
Jan 05 2015
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 Are there proofs of percentage of bugs caused by incorrectly 
 mutating variables that were supposed to be immutable?


I don't know, probably not, but the progress in language design 
is still in its pre-quantitative phase (note: I think Rust 
variables are constant by default, and mutable on request with 
"mut").
It's not just a matter of bugs, it's also a matter of making the 
code simpler to better/faster understand what a function is doing 
and how.



 I don't remember having such bug in my life.


Perhaps you are very good, but a language like D must be designed 
for more common programmers like Kenji Hara, Andrei Alexandrescu, 
or Raymond Hettinger.

Bye,
bearophile
Jan 05 2015
next sibling parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Monday, 5 January 2015 at 11:01:51 UTC, bearophile wrote:

 I don't remember having such bug in my life.


 Perhaps you are very good, but a language like D must be 
 designed for more common programmers like Kenji Hara, Andrei 
 Alexandrescu, or Raymond Hettinger.

 Bye,
 bearophile



<kapow!>
Jan 05 2015
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/5/15 8:01 AM, bearophile wrote:

 Ary Borenszweig:


 Are there proofs of percentage of bugs caused by incorrectly mutating
 variables that were supposed to be immutable?


 I don't know, probably not, but the progress in language design is still
 in its pre-quantitative phase (note: I think Rust variables are constant
 by default, and mutable on request with "mut").
 It's not just a matter of bugs, it's also a matter of making the code
 simpler to better/faster understand what a function is doing and how.


You said "Computer Science has found that the right
default for variables is to have them immutable". I don't think "Rust == 
Computer Science". Otherwise their compiler would be fast (Computer 
Science knows how to do fast compilers).

At least I like that they are introducing a new feature to their 
language that none other has: lifetimes and borrows. But I find it very 
hard to read their code. Take a look for example at the lerp function 
defined in this article:

http://www.willusher.io/2014/12/30/porting-a-ray-tracer-to-rust-part-1/

Rust:
~~~
pub fn lerp<T: Mul<f32, T> + Add<T, T> + Copy<T>>(t: f32, a: &T, b: &T) 
-> T {
     *a * (1.0 - t) + *b * t
}
~~~

C++:
~~~
template<typename T>
T lerp(float t, const T &a, const T &b){
     return a * (1.f - t) + b * t;
}
~~~


 I don't remember having such bug in my life.


 Perhaps you are very good, but a language like D must be designed for
 more common programmers like Kenji Hara, Andrei Alexandrescu, or Raymond
 Hettinger.


I don't think those are common programmers :-)
Jan 05 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 5 January 2015 at 14:40:18 UTC, Ary Borenszweig wrote:

 You said "Computer Science has found that the right
 default for variables is to have them immutable". I don't think 
 "Rust == Computer Science". Otherwise their compiler would be 
 fast (Computer Science knows how to do fast compilers).


FWIW, proper computer scientists do not care about making fast 
compilers... They care about proving properties such as "why and 
when algorithm 1 is faster than algorithm 2 for data sets that 
approaches infinite size, given infinite memory"... Computer 
Science is the stepchild of Discrete Mathematics. Highly 
impractical, but very useful.
Jan 05 2015
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vlad Levenfeld"  wrote in message 
news:xrizfcicbvbkhtpvugvm forum.dlang.org...


 Can the compiler automatically make variables immutable if it can prove 
 that they are never changed in some code?


It can apply the same optimizations, yes.
Jan 04 2015
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"bearophile"  wrote in message news:bwxlgpicmmnvphyiqyxt forum.dlang.org... 


 D:

    foreach(immutable route neighbour; nodes[nodeID].neighbours){

 Correctly written D:

     foreach (neighbour; nodes[nodeID].neighbours){


 
 I don't agree, the good D way is:
 
 foreach (immutable neighbour; nodes[nodeID].neighbours) {
 
 D programmers should apply const/immutable to every variable that 
 doesn't need to mutate.


Reading Walter's post, I somehow knew you'd be posting this exact reply.
Jan 04 2015
prev sibling parent "logicchains" <jonathan.t.barnard gmail.com> writes:
On Monday, 5 January 2015 at 00:01:34 UTC, Walter Bright wrote:

 D:
     printf("%d LANGUAGE D %d\n", len, sw.peek().msecs);

 Correctly written D:

     writeln(len, " LANGUAGE D ", sw.peek().msecs);


Just a note that the reason it uses printf is because, when ldc 
was working on ARM, writeln produced gibberish characters.

On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:

There was a time I liked D. But now to make the code fast you
 have to annotate things with pure nothrow  safe to make sure 
 the compiler generates fast code. This leads to code that's 
 uglier and harder to understand.


For this particular benchmark I noticed little effect on the 
speed of the program from these annotations, I just originally 
added them for that warm fuzzy feeling that comes from marking 
things immutable/pure.

Also, in relation to comments about -boundscheck=off (aka 
noboundscheck), it's interesting to check out the latest Rust 
version. Previously, it was a bit slower than C++, D and Nimrod. 
Now, it matches them... by converting the code to use a tree in 
order to avoid bounds checks! 
https://github.com/logicchains/LPATHBench/blob/master/rs.rs. 
Personally I prefer D's approach.
Jan 05 2015
prev sibling next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 04/01/15 22:46, Ary Borenszweig via Digitalmars-d wrote:

 According to the writeup:

 https://github.com/logicchains/LPATHBench/blob/master/writeup.md

 Nim is faster than D. And it does so with much less code.


Meh, if you compare the code in detail you realize (i) the D example "wastes" a 
lot of lines with imports, { } brackets, and a second implementation of the
core 
algorithm using std.range/std.algorithm functionality instead of the "naive" 
(but it seems, faster) implementation.

The rest of the weight in lines is down to a not-so-nice "readPlaces" method 
that could be rewritten idiomatically in D in much less space, but no one's 
bothered because it's not actually part of the benchmark.

Now, to the numbers -- the x86-64 benchmark shows a 50ms difference between Nim 
and D.  That's such a trivial difference, it's difficult to know what is 
responsible; depending on whether the results are averaged over multiple runs, 
it might even just be random fluctuation, or differences in the implementation 
of the time measurement.  Looking at the runbench.sh code, I don't think there 
is any averageing, so it's not a very certain measure of what is best.

The results from the Haswell processor seem more clear-cut, but without more 
information, I'd hazard a guess that there the person concerned tweaked the 
build file to use dmd, rather than the superior (for code speed) ldc2 or gdc.
Jan 04 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2015 1:46 PM, Ary Borenszweig wrote:

 Nim is faster than D.


I bet the D version would be significantly faster if you didn't read the file
as 
a text string, then try breaking it up into an array of lines, then break those 
lines up into an array of strings, etc. This is a lot of memory allocation.

Instead, open the file and use byLine() on it, which does not allocate memory.
Jan 04 2015
next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 05/01/15 01:53, Walter Bright via Digitalmars-d wrote:

 I bet the D version would be significantly faster if you didn't read the file
as
 a text string, then try breaking it up into an array of lines, then break those
 lines up into an array of strings, etc. This is a lot of memory allocation.

 Instead, open the file and use byLine() on it, which does not allocate memory.


The timing shouldn't include the breaking up into strings etc., only the actual 
calculation of the longest path.  Are you concerned that some kind of GC event 
might be being triggered, skewing the timing of the latter?
Jan 04 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 5 January 2015 at 00:54:45 UTC, Walter Bright wrote:

 On 1/4/2015 1:46 PM, Ary Borenszweig wrote:

 Nim is faster than D.


 I bet the D version would be significantly faster if you didn't 
 read the file as a text string, then try breaking it up into an 
 array of lines, then break those lines up into an array of 
 strings, etc. This is a lot of memory allocation.

 Instead, open the file and use byLine() on it, which does not 
 allocate memory.


It doesn't time that part

Either way I sped it up by changing the non-fast(?) part a little 
bit

int getLongestPath(immutable(node[]) nodes, const int nodeID, 
bool[] visited) nothrow  safe{
     visited[nodeID] = true;
     scope(exit) visited[nodeID] = false;
     return reduce!(max)(0,
             nodes[nodeID].neighbours
             .filter!(x=>!visited[x.dest])
             .map!(x => x.cost + getLongestPath(nodes, x.dest, 
visited)));
}

I'm not that great at D though.
Compiled it with LDC, GDC and DMD seem to choke on the functional 
programming and run 4-5x slower.
~1120 ms with my version, ~1210 ms with the 'fast' version

the C++ version compiled with gcc still beats it by about 100ms 
on my machine, but it's the same exact performance as C++ when 
using clang/LLVM.

Why does reduce! take the seed as its first parameter btw? It 
sort of messes up function chaining.
Jan 04 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2015 5:07 PM, weaselcat wrote:

 It doesn't time that part


You're right, I overlooked that.

You can also speed things up by noticing that the nodes[] and visited[] 
arguments never change, so getLongestPath can be made as a nested function with 
those arrays as locals in the enclosing function.

This will reduce stack consumption, improving cache performance, and nodeID
will 
get passed in a register.
Jan 04 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Monday, 5 January 2015 at 01:30:08 UTC, Walter Bright wrote:

 On 1/4/2015 5:07 PM, weaselcat wrote:

 It doesn't time that part


 You're right, I overlooked that.

 You can also speed things up by noticing that the nodes[] and 
 visited[] arguments never change, so getLongestPath can be made 
 as a nested function with those arrays as locals in the 
 enclosing function.

 This will reduce stack consumption, improving cache 
 performance, and nodeID will get passed in a register.


Small improvement but almost put it equal to C++/gcc, also 
greatly sped up GDC weirdly(not quite LDC speed though)
Jan 04 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 5 January 2015 at 01:07:07 UTC, weaselcat wrote:

 Compiled it with LDC, GDC and DMD seem to choke on the 
 functional programming and run 4-5x slower.
 ~1120 ms with my version, ~1210 ms with the 'fast' version

 the C++ version compiled with gcc still beats it by about 100ms 
 on my machine, but it's the same exact performance as C++ when 
 using clang/LLVM.

 Why does reduce! take the seed as its first parameter btw? It 
 sort of messes up function chaining.


just realized I forgot the -release flag on ldmd, sped it up past 
clang and within ~40ms of C++ with gcc.
gdc and dmd still woefully slow with functional version.
Jan 04 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2015 5:33 PM, weaselcat wrote:

 just realized I forgot the -release flag on ldmd, sped it up past clang and
 within ~40ms of C++ with gcc.
 gdc and dmd still woefully slow with functional version.


You can also find dramatic differences in C++ performance from one C++ compiler 
to another.
Jan 04 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/4/15 5:07 PM, weaselcat wrote:

 Why does reduce! take the seed as its first parameter btw? It sort of
 messes up function chaining.


Mistake. -- Andrei
Jan 04 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Jan 04, 2015 at 07:25:28PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 1/4/15 5:07 PM, weaselcat wrote:

Why does reduce! take the seed as its first parameter btw? It sort of
messes up function chaining.


 
 Mistake. -- Andrei


When are we going to fix this?


T

-- 
Nothing in the world is more distasteful to a man than to take the path that
leads to himself. -- Herman Hesse
Jan 04 2015
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:


 When are we going to fix this?


Soon.

Bye,
bearophile
Jan 04 2015
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Monday, 5 January 2015 at 04:10:41 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Sun, Jan 04, 2015 at 07:25:28PM -0800, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 On 1/4/15 5:07 PM, weaselcat wrote:

Why does reduce! take the seed as its first parameter btw? It 
sort of
messes up function chaining.


 
 Mistake. -- Andrei


 When are we going to fix this?


 T


monarch dodra tried to make a reduce that was backward compatible 
while moving the seed but it didn't work out in the end. He was 
working on a "fold" which was basically reduce with the arguments 
swapped but I'm not sure what happened to it.
Jan 05 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jan 05, 2015 at 06:12:41PM +0000, Brad Anderson via Digitalmars-d wrote:

 On Monday, 5 January 2015 at 04:10:41 UTC, H. S. Teoh via Digitalmars-d
 wrote:

On Sun, Jan 04, 2015 at 07:25:28PM -0800, Andrei Alexandrescu via
Digitalmars-d wrote:

On 1/4/15 5:07 PM, weaselcat wrote:

Why does reduce! take the seed as its first parameter btw? It >sort
of messes up function chaining.


Mistake. -- Andrei


When are we going to fix this?


T


 
 monarch dodra tried to make a reduce that was backward compatible
 while moving the seed but it didn't work out in the end. He was
 working on a "fold" which was basically reduce with the arguments
 swapped but I'm not sure what happened to it.


Should somebody take over the implementation of "fold"? This is
something that ought to be fixed.


T

-- 
Laissez-faire is a French term commonly interpreted by Conservatives to mean
'lazy fairy,' which is the belief that if governments are lazy enough, the Good
Fairy will come down from heaven and do all their work for them.
Jan 05 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/5/15 11:03 AM, H. S. Teoh via Digitalmars-d wrote:

 On Mon, Jan 05, 2015 at 06:12:41PM +0000, Brad Anderson via Digitalmars-d
wrote:

 On Monday, 5 January 2015 at 04:10:41 UTC, H. S. Teoh via Digitalmars-d
 wrote:

 On Sun, Jan 04, 2015 at 07:25:28PM -0800, Andrei Alexandrescu via
 Digitalmars-d wrote:

 On 1/4/15 5:07 PM, weaselcat wrote:

 Why does reduce! take the seed as its first parameter btw? It >sort
 of messes up function chaining.


 Mistake. -- Andrei


 When are we going to fix this?


 T


 monarch dodra tried to make a reduce that was backward compatible
 while moving the seed but it didn't work out in the end. He was
 working on a "fold" which was basically reduce with the arguments
 swapped but I'm not sure what happened to it.


 Should somebody take over the implementation of "fold"? This is
 something that ought to be fixed.


If you could that would be great but please fix groupBy first :o) -- Andrei
Jan 05 2015
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
weaselcat:


 Why does reduce! take the seed as its first parameter btw? It 
 sort of messes up function chaining.


It's a design mistake, but there's a "fold" function replacement 
for reduce that has the right order of arguments. I don't know 
why "fold" isn't in Phobos yet.

Bye,
bearophile
Jan 04 2015
parent "bearophile" <bearophileHUGS lycos.com> writes:
 It's a design mistake, but there's a "fold" function 
 replacement for reduce that has the right order of arguments. I 
 don't know why "fold" isn't in Phobos yet.


https://github.com/D-Programming-Language/phobos/pull/1955
https://issues.dlang.org/show_bug.cgi?id=10670

Bye,
bearophile
Jan 04 2015
prev sibling next sibling parent reply "Elie Morisse" <syniurge gmail.com> writes:
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:

 Hey folks,

 I've been recently checking out Nim/rod and feel like it takes 
 a lot of inspiration from D (I think the creator was in the D 
 community too as some point). How do you think it compares? 
 What areas does D, in principle, makes it a better choice? To 
 give you my background, I like creating games (mostly using SDL 
 bindings) using new languages, aiming for the most efficient 
 yet concise way to write the engine and game logic.

 FYI, this is NOT a language war thread. I'm just curious about 
 what separates them from a principle level.


D and Nim have similar goals (conciseness, CTFE, other advanced 
metaprogramming features to reduce code redundancies to zero..), 
but although Nim has cool ideas it's not without some drawbacks:

- Only limited polymorphism, Nim doesn't use virtual tables but 
dispatch trees for performance, and that means that you can't 
have "opaque" base classes running derived methods if the 
overriding methods are unknown to the compiler:

  http://nim-lang.org/manual.html#multi-methods
  http://forum.nimrod-lang.org/t/278

- No conditional evaluation of code
- No type traits
- Declarations are order-dependent
- Generics are redundant with templates (they are going to be 
removed though: http://forum.nimrod-lang.org/t/638 )

IMHO the two languages are similar but D is more advanced, and 
apart from AST macros I don't see any notable appealing features 
from Nim compared to D.
Jan 04 2015
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 1/4/15 8:32 PM, Elie Morisse wrote:

 On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:



 - No conditional evaluation of code


It has 'when', which is similar to static if. I would say that's 
conditional evaluation of code.
Jan 04 2015
prev sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:

 Hey folks,

 I've been recently checking out Nim/rod and feel like it takes 
 a lot of inspiration from D (I think the creator was in the D 
 community too as some point).


I'm pretty sure that D was not a big inspiration to Nim, even 
though Araq (Andreas Rumpf) has commented here on occasion.


 How do you think it compares?


Overall, I much prefer Nim. The obvious first difference is 
syntax (Nim uses an offside rule like Python/Haskell/ISWIM) and 
for some people that's a huge difference which determines which 
they'll prefer.

Nim's parametric polymorphism is less powerful than D's I think 
(the words 'generic' and 'template' are used differently in the 
two communities so I'll try and be extra clear) but Nim has a 
powerful macro system and a (still unfinished) kind of "type 
classes" which give it an edge on D.

D has a simple class based OO that looks a lot like Java, and 
ties reference semantics to classes. D has a rather unique multi 
method based OO system.

There are quite a few more things (concurrency, effect system, 
iterators vs ranges, ..) but I'll just advise you to look.


 What areas does D, in principle, makes it a better choice?


Larger language community. Lower bus factor too, I think.

Subjectively, D feels to me like an attempt to fix and improve 
C++. Nim feels more like a language in the Delphi/Modula-3 
tradition with Python syntax. If you can't stand that syntax, 
stay away. It's not changing.


 To give you my background, I like creating games (mostly using 
 SDL bindings) using new languages, aiming for the most 
 efficient yet concise way to write the engine and game logic.


Nim's GC was designed with games in mind. D's GC (which can be 
disabled) is not usually considered a strong point of the 
language implementation.


 FYI, this is NOT a language war thread. I'm just curious about 
 what separates them from a principle level.


Quite a lot separates them, even though they both target similar 
areas. Best to read a few tutorials and write some small programs 
in each. You might also try asking on the Nim forum. I realize 
you say you're not starting a language flame war, but the 
etiquette of the question is a bit problematic. Hopefully I don't 
fan any flames with my answer.
Jan 04 2015
parent reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Monday, 5 January 2015 at 01:12:29 UTC, Brian Rogoff wrote:

 Nim's parametric polymorphism is less powerful than D's I think 
 (the words 'generic' and 'template' are used differently in the 
 two communities so I'll try and be extra clear) but Nim has a 
 powerful macro system and a (still unfinished) kind of "type 
 classes" which give it an edge on D.


Could you elaborate on the difference between D's 
templates/mixins and Nim's macros/type classes?
Jan 04 2015
parent "Brian Rogoff" <brogoff gmail.com> writes:
On Monday, 5 January 2015 at 01:21:07 UTC, Vlad Levenfeld wrote:

 Could you elaborate on the difference between D's 
 templates/mixins and Nim's macros/type classes?


I'd suggest you read the available documentation on each feature; 
for example Nim's user defined type classes are described here

http://nim-lang.org/manual.html#user-defined-type-classes

and the Nim's templates/macros are also described with examples 
in the manual. One caveat is that user defined type classes are 
not really useable now and will probably be feature gated (not 
removed as some other poster here suggested) so it's not fair to 
talk about them as though they actually exist now. They're more 
like multiple alias this or D's precise GC ;-). D templates (what 
is called generics in Nim) are more powerful than Nim generics. 
Maybe Nim will pick up some of those features (HKTs are a desired 
feature in Rust and maybe in Nim too) and maybe not.

It's really difficult to compare languages and features. Like I 
said, pick a small project and write some code in each. I found 
Nim really easy to pick up for small projects; a bit easier than 
D and much easier than Rust, which I like, but find slow going.
Jan 04 2015