On 1/5/15 11:03 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Jan 05, 2015 at 06:12:41PM +, 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
On Mon, Jan 05, 2015 at 06:12:41PM +, 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:
>
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 discus
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
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 i
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 suc
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.
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 beginni
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 compile
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
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 qualitie
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 lot
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 a
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 officia
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 produ
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
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, a
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
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
What is kill future of Nim?
D is successor of C++, but Nim? Successor of Python?
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 t
"H. S. Teoh via Digitalmars-d" wrote in message
news:mailman.4136.1420439089.9932.digitalmar...@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 i
"weaselcat" wrote in message news:nopttywdkgouyxnlr...@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
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 remembe
"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:
st
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
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 Walte
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 pe
"Vlad Levenfeld" wrote in message
news:xrizfcicbvbkhtpvu...@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.
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
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 var
H. S. Teoh:
When are we going to fix this?
Soon.
Bye,
bearophile
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
--
Not
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
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
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/DigitalM
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
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
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.
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 pa
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
"bearophile" wrote in message news:bwxlgpicmmnvphyiq...@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;
ed 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://gi
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
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
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[no
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
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 (i
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.
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 machin
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 fun
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 unfinis
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
thou
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 l
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.
I
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 al
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
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].neig
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
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
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
hem 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
x27;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 ni
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 undisc
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 develope
Thanks I will try it. It seems really cool. Maybe my new
favorite language.
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.
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
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
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?
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's compiling to C, I suppose it should be much easier to port
to other platforms than for example D?
On 2015-01-04 18:10:51 +, 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
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 crea
74 matches
Mail list logo
