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 pressure to make C# shine in the C++ domain...
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