On 07/19/2012 10:21 AM, Petr Janda wrote:
...
I think the other points have been adequately covered.
...
> auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);
...
>
> I'm sorry I don't mean to be a criticizer, but it seems to me that D is
> trying to be a dynamic-like compiled language way too hard.
>

Everything in that snippet is statically (and probably strongly too?) typed at compile-time.

What's going on is a lot of type inference and syntax sugar that allows for very terse code.  You'll still get immediate compiler errors if you screw up the types and you try to treat "r" like it isn't a range of strings.  There won't be any bugs introduced in your programs due to breaches of type safety.  This is the beauty of it: the code is terse, does what it says it does, potentially very optimized, and also heavily verified at compile-time.  The anonymous function is even passed at compile-time for easy inlining (not sure how aggressively dmd handles that right now though).  It's hard to get that combo of (development speed)|(correctness)|(execution speed) in other places, in my not-so-humble opinion. ;)

On 07/19/2012 09:35 PM, Damian wrote:
> On Thursday, 19 July 2012 at 22:32:04 UTC, David Piepgrass wrote:
>>
>> Actually, C# has no default initialization* of local variables, and I
>> love it. Instead, it is a compile-time error to read a variable if the
>> compiler cannot guarantee that you have initialized it. IMO this is
>> much better than D's "let's initialize doubles to NaN so that
>> something fishy will happen at runtime if you forget to initialize it" :)
>
> It would be great if D did do this, surely it would not be all
> that difficult! and wouldn't it also help in finding unused variables?

Walter doesn't like it. Past discussions:

http://forum.dlang.org/post/gon06s$1nbe$1@digitalmars.com
http://forum.dlang.org/post/ha37cf$4l2$1@digitalmars.com
http://forum.dlang.org/post/i4mlee$5a2$1@digitalmars.com

On 2012-07-20 00:05, Nick Sabalausky wrote:

> No, this is why any C/C++ project should be replaced by D ;)
>
> I'm knee-deep in a C++ project right now, and the language is such a
> pedantic, anachronistic turd. C++'s *only* saving graces are:
>
> - It's a systems language (ie, native compiled with low-level access).
> - It isn't PHP, JS, a JS-derivitive (ex, ActionScript), or Son-Of-Flash
>    (aka Corona).
> - D isn't mature on all platforms yet.

I used Boost, for a C++ project I was working on, to make it more D-like. Foreach, auto, lambda, default initialization and other things. Most of these things are available in C++11 now.

-- 
/Jacob Carlborg

On 2012-07-20 00:32, David Piepgrass wrote:

> Actually, C# has no default initialization* of local variables, and I
> love it. Instead, it is a compile-time error to read a variable if the
> compiler cannot guarantee that you have initialized it. IMO this is much
> better than D's "let's initialize doubles to NaN so that something fishy
> will happen at runtime if you forget to initialize it" :)

Floats and doubles initialized to NaN can be really annoying when interfacing to C or porting to D from another language.

-- 
/Jacob Carlborg

"Jacob Carlborg"  wrote in message news:juaudk$2slh$1@digitalmars.com...

>On 2012-07-20 00:05, Nick Sabalausky wrote:
>
>> No, this is why any C/C++ project should be replaced by D ;)
>>
>> I'm knee-deep in a C++ project right now, and the language is such a
>> pedantic, anachronistic turd. C++'s *only* saving graces are:
>>
>> - It's a systems language (ie, native compiled with low-level access).
>> - It isn't PHP, JS, a JS-derivitive (ex, ActionScript), or Son-Of-Flash
>>    (aka Corona).
>> - D isn't mature on all platforms yet.
>
>I used Boost, for a C++ project I was working on, to make it more D-like. Foreach, auto, lambda, default initialization and other things. Most of these things are available in C++11 now.
>
>-- 
>/Jacob Carlborg

I like D as a better C++, but in face of the available tooling, libraries and with
the support C++11 is getting lateley, I'm still using C++ for private projects,
while at work I spend most of my time in JVM and .NET worlds.

It is a case of "worse is better".

D, Go, Rust have a  big problem to gain adoption in the native world renaissance.

As another programing language to develop normal applications, there are already
lots of more established languages. Even if a VM free language is the prefered tool,
there are actually native code compilers for JVM/.NET languages, and even Microsoft
seems to be planning to offer native code compiler for C#, from their job postings.

To become a widspread systems programming language, D needs to get support from an OS
or driver vendor.

--
Paulo

On Friday, 20 July 2012 at 06:40:18 UTC, Jacob Carlborg wrote:
> On 2012-07-20 00:32, David Piepgrass wrote:
>
>> Actually, C# has no default initialization* of local variables, and I
>> love it. Instead, it is a compile-time error to read a variable if the
>> compiler cannot guarantee that you have initialized it. IMO this is much
>> better than D's "let's initialize doubles to NaN so that something fishy
>> will happen at runtime if you forget to initialize it" :)
>
> Floats and doubles initialized to NaN can be really annoying when interfacing to C or porting to D from another language.

I think that the worse part of this is that it make integers and floats needlessly different..

renoX

Am Thu, 19 Jul 2012 22:43:17 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2012-07-19 16:50, Alex Rønne Petersen wrote:
> 
> In C++ it's even better (irony). It depends on what kind of variable is declared. I.e. a global variable, a local, instance or a class variable (static). Some of these are default initialized, some are not. I have no idea which are initialized and which are not.

I think C++ uses a pragmatic approach: No overhead for explicit initialization. But everything that goes into the executable and doesn't have a specific value, will go into the BSS section, where it A) takes up no space and B) the OS will take care of zero initializing it _anyways_.

If it is stored in the .exe, it is 0!

-- 
Marco

On 2012-07-20 16:33, Marco Leise wrote:

> I think C++ uses a pragmatic approach: No overhead for explicit initialization. But everything that goes into the executable and doesn't have a specific value, will go into the BSS section, where it A) takes up no space and B) the OS will take care of zero initializing it _anyways_.
>
> If it is stored in the .exe, it is 0!

Is it defined what is placed in the executable?

-- 
/Jacob Carlborg

On Friday, 20 July 2012 at 08:17:03 UTC, renoX wrote:
> On Friday, 20 July 2012 at 06:40:18 UTC, Jacob Carlborg wrote:
>> On 2012-07-20 00:32, David Piepgrass wrote:
>>
>>> Actually, C# has no default initialization* of local variables, and I love it. Instead, it is a compile-time error to read a variable if the compiler cannot guarantee that you have initialized it. IMO this is much better than D's "let's initialize doubles to NaN so that something fishy will happen at runtime if you forget to initialize it" :)
>>
>> Floats and doubles initialized to NaN can be really annoying when interfacing to C or porting to D from another language.
>
> I think that the worse part of this is that it make integers and floats needlessly different..

  chars initialize to 0xff by default. By putting the values as
close to a invalid state as possible helps them to stand out as
uninitialized. There's a small part in walter's article on
demystifying the floating point, where he went onto the bugs
involved which were hard to figure out.

http://dlang.org/d-floating-point.html

[quote]
My first floating-point nightmare occurred in a C++ program which
hung once in every hundred runs or so. I eventually traced the
problem to a while loop which occasionally failed to terminate.
The essence of the code is shown in Listing 1.

[code]
double q[8];
...
int x = 0;
while (x < 8) {
   if ( q[x] >= 0 ) return true;
   if ( q[x] < 0 ) ++x;
}
return false;
[/code]

Initially, I was completely baffled as to how this
harmless-looking loop could fail. But eventually, I discovered
that q had not been initialized properly; q[7] contained random
garbage. Occasionally, that garbage had every bit set, which mean
that q[7] was a Not-a-Number (NaN), a special code which
indicates that the value of the variable is nonsense. NaNs were
not mentioned in the compiler's documentation - the only
information I could find about them was in Intel's assembly
instruction set documentation! Any comparison involving a NaN is
false, so q[7] was neither >= 0, nor < 0, killing my program.
Until that unwelcome discovery, I'd been unaware that NaNs even
existed. I had lived in a fool's paradise, mistakenly believing
that every floating point number was either positive, negative,
or zero.

My experience would have been quite different in D. The "strange"
features of floating point have a higher visibility in the
language, improving the education of numerical programmers.
Uninitialized floating point numbers are initialized to NaN by
the compiler, so the problematic loop would fail every time, not
intermittently.
[/quote]

Am Fri, 20 Jul 2012 16:43:18 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2012-07-20 16:33, Marco Leise wrote:
> 
> > I think C++ uses a pragmatic approach: No overhead for explicit initialization. But everything that goes into the executable and doesn't have a specific value, will go into the BSS section, where it A) takes up no space and B) the OS will take care of zero initializing it _anyways_.
> >
> > If it is stored in the .exe, it is 0!
> 
> Is it defined what is placed in the executable?

P.S.: s/section/segment/

Someone else would have to answer that question. I assume anything that is kind of static, like globals, class variables, D's .init blocks. It makes sense to me, because the compiler can issue static references to that data, instead of generating code that creates space for it e.g. on the heap and have the program use a pointer to get at it.

-- 
Marco