• Petr Janda (20/20) Jul 19 2012 Hi,
• David (6/23) Jul 19 2012 => → New Lambda Syntax
• Petr Janda (2/5) Jul 19 2012 Ok, but what is map!(). What's the point of the exclamation mark,
• =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (8/14) Jul 19 2012 It means template instantiation. The parameter list following the
• q66 (7/13) Jul 19 2012 stuff after ! specifies template arguments, in this case a
• q66 (3/17) Jul 19 2012 for example, auto x = [ 5, 10, 15, 20 ]; assert(map!(x => x +
• travert phare.normalesup.org (Christophe Travert) (10/17) Jul 19 2012 Yes, !(...) is template specialization.
• =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (9/24) Jul 19 2012 No, please, template instantiation. Specialization is something
• travert phare.normalesup.org (Christophe Travert) (3/29) Jul 19 2012 You are right, its my mistake (well, I can still send the mistake back
• Petr Janda (3/5) Jul 19 2012 Sorry, my fault. I'm a non-native english speaker.
• David (4/10) Jul 19 2012 without UFCS: map!(x => to!string(x))(my_range)
• q66 (10/30) Jul 19 2012 (arguments) => result-expression is a lambda expression; sort of
• q66 (4/4) Jul 19 2012 btw - as for your complains - I would blame poor D documentation
• travert phare.normalesup.org (Christophe Travert) (3/5) Jul 19 2012 rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter
• Petr Janda (6/12) Jul 19 2012 Ok, but the empty parenthesis is is important, it tells you about
• travert phare.normalesup.org (Christophe Travert) (10/25) Jul 19 2012 property (functions that behaves like fields) don't require
• Nick Sabalausky (6/27) Jul 19 2012 That's already happening. It's just that for the moment you have to
• Timon Gehr (9/20) Jul 19 2012 (No, it does not. And even if it would, )
• Jacob Carlborg (4/6) Jul 19 2012 I love that :)
• Robik (12/23) Jul 19 2012 Here's list what happens:
• travert phare.normalesup.org (Christophe Travert) (3/21) Jul 19 2012 To be more precise, `r` variable is a lazy range, equivalent to this
• =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (22/39) Jul 19 2012 No, it's just trying to make the developer's life easier.
• Jacob Carlborg (7/13) Jul 19 2012 In C++ it's even better (irony). It depends on what kind of variable is
• Paulo Pinto (6/17) Jul 19 2012 That is why any C or C++ project should have static analysis tools
• Nick Sabalausky (9/30) Jul 19 2012 No, this is why any C/C++ project should be replaced by D ;)
• Jacob Carlborg (6/13) Jul 19 2012 I used Boost, for a C++ project I was working on, to make it more
• Paulo Pinto (22/37) Jul 20 2012 I like D as a better C++, but in face of the available tooling, librarie...
• Marco Leise (10/16) Jul 20 2012 =20
• Jacob Carlborg (4/6) Jul 20 2012 Is it defined what is placed in the executable?
• Marco Leise (6/13) Jul 21 2012 P.S.: s/section/segment/
• Stuart (12/12) Jul 21 2012 Let me just add, I really *like* the terse syntax of D. Lambdas,
• Nick Sabalausky (30/37) Jul 21 2012 Yea. I used Java in college and ever since then I've been a fan of
• Andrei Alexandrescu (9/11) Jul 21 2012 On slide 19 of the OSCON slides there's this sample:
• Nick Sabalausky (9/23) Jul 21 2012 Exactly. And what many people (depressingly) don't realize, is
• Jens Mueller (3/29) Jul 21 2012 Where is argmin defined? I couldn't find it.
• monarch_dodra (9/11) Jul 22 2012 Argmin don't exist, but it could, and that's what counts. The
• David Nadlinger (3/4) Jul 22 2012 On the slide before that… ;)
• Andrei Alexandrescu (5/8) Jul 22 2012 I think argmin is intuitive, popular, and useful enough to warrant a
• monarch_dodra (33/43) Jul 22 2012 Are you asking for the _actual_ argmin as defined in the paper?
• Jens Mueller (3/7) Jul 24 2012 :)
• Paulo Pinto (22/59) Jul 22 2012 Actually that verbose sintax is quite helpful when dealing with gigantic
• Nick Sabalausky (19/39) Jul 22 2012 Yea, I've dealt with far too many such "programmers" myself. I'm
• Paulo Pinto (8/37) Jul 22 2012 Actually in our case it is because management only wants to pay for
• Nick Sabalausky (13/58) Jul 22 2012 Perhaps I forgot to mention that 90% of managers belong under the same
• Nick Sabalausky (13/36) Jul 23 2012 "verbose sintax"...Was that deliberate spelling or a very coincidental
• H. S. Teoh (13/25) Jul 23 2012 [...]
• Chris NS (8/14) Jul 23 2012 I'm reminded of a close friend of mine... once he was asked to
• Nick Sabalausky (3/20) Jul 24 2012 That's...hilarious. Disturbing, but hilarious.
• Era Scarecrow (29/42) Jul 24 2012 I remember seeing some stupid production code that was used at a
• Era Scarecrow (3/4) Jul 24 2012 Sorry my filter stripped that out. They couldn't understand what
• Andrei Alexandrescu (3/7) Jul 24 2012 x >>= 2; // if x much greater than 2, assign 2 to it
• Chris NS (6/20) Jul 24 2012 I just died a little inside...
• Nick Sabalausky (5/9) Jul 24 2012 Nah, I know exactly where it went wrong.
• Stuart (26/26) Jul 24 2012 I've only recently discovered D, and I already think it's great.
• Stuart (4/5) Jul 23 2012 Precisely what I have been thinking. It's a loose wrapper around
• Paulo Pinto (7/13) Jul 23 2012 Only due to the lack of modules.
• Stuart (18/30) Jul 23 2012 Hardly. No RTTI. No GC. No properties. No events. No closures. No
• Stuart (4/6) Jul 23 2012 Or perhaps I should've said "named tuples". I dunno what the
• Simen Kjaeraas (10/13) Jul 23 2012 You mean like this?
• Andrei Alexandrescu (6/17) Jul 23 2012 We could make
• Simen Kjaeraas (10/17) Jul 24 2012 [snip]
• Andrei Alexandrescu (3/20) Jul 24 2012 Library solution.
• Jonathan M Davis (3/25) Jul 24 2012 That's what alias this is for.
• Simen Kjaeraas (12/40) Jul 24 2012 Well, sorta. See, I'm asking for an unbounded set of possible
• Stuart (5/16) Jul 24 2012 You mean it's already supported? Nice! Although, It'd still be
• Regan Heath (5/23) Jul 24 2012 Sadly the comma operator (inherited from C/C++) blocks this syntax.
• Stuart (3/13) Jul 24 2012 Well, how about "auto {a,b} = ", or "auto [a,b] = ", or something
• H. S. Teoh (9/18) Jul 24 2012 [...]
• Andrej Mitrovic (14/15) Jul 24 2012 The comma operator needs to die a fast but painful death. I've had
• Simen Kjaeraas (20/24) Jul 24 2012 That would be nice, and has been on the table numerous times.
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (16/20) Jul 24 2012 Works in foreach loops:
• Russel Winder (18/26) Jul 24 2012 Or possibly better:
• Simen Kjaeraas (16/32) Jul 24 2012 On Tue, 24 Jul 2012 19:02:07 +0200, Russel Winder ...
• Nick Sabalausky (14/33) Jul 23 2012 Null-terminated strings. Preprocessor. No reflection. Effectively
• Nick Sabalausky (4/35) Jul 23 2012 Speaking of, I understand he had C++ in mind when he wrote this song:
• Paulo Pinto (28/62) Jul 24 2012 Null-terminated strings are a consequence of C compatibility, which is v...
• Paulo Pinto (15/34) Jul 24 2012 RTTI is available last time I checked. Sure it is not a full reflection
• David Piepgrass (10/17) Jul 19 2012 Actually, C# has no default initialization* of local variables,
• Nick Sabalausky (3/22) Jul 19 2012 I've always wished D worked that way, too.
• Faux Amis (2/24) Jul 19 2012 vote++
• Damian (4/21) Jul 19 2012 It would be great if D did do this, surely it would not be all
• Jeff Nowakowski (5/14) Jul 19 2012 Walter doesn't like it. Past discussions:
• Jacob Carlborg (5/10) Jul 19 2012 Floats and doubles initialized to NaN can be really annoying when
• renoX (4/16) Jul 20 2012 I think that the worse part of this is that it make integers and
• Era Scarecrow (43/57) Jul 20 2012 chars initialize to 0xff by default. By putting the values as
• Timon Gehr (15/36) Jul 19 2012 'int', if you like.
• Petr Janda (4/7) Jul 19 2012 Not if "eliminating noise" equals to making things harder to
• Timon Gehr (8/13) Jul 19 2012 Harder to understand to whom? Optimizing stuff for beginners usually
• Brad Anderson (13/19) Jul 19 2012 Nothing is stopping someone from being explicit with their types like th...
• Timon Gehr (3/22) Jul 19 2012 ^
• Brad Anderson (4/26) Jul 19 2012 Ehm...forgot the return:
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (14/19) Jul 19 2012 Others beat me to it but the anonymous function can be written more
• Jacob Carlborg (4/9) Jul 19 2012 It's equally clear when you see: =>.
• David Nadlinger (6/23) Jul 19 2012 Additionally, allowing to omit auto is actually consistent with
• Bernard Helyer (3/3) Jul 19 2012 What the _fuck_ guys? How did you get this many posts on what is
• FeepingCreature (2/3) Jul 19 2012 In other words, see subject.
• Chad J (18/21) Jul 19 2012 On 07/19/2012 10:21 AM, Petr Janda wrote:

"Petr Janda" <janda.petr gmail.com> writes:

Hi,

I'm an occasional lurker on the D forums just to see where the 
language is going,but I'm a little puzzled. In another thread I 
found this code

auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);

I don't understand whats going on here. Int array is getting 
sorted, then Uniqued, then what? What type is x? What kind of 
operator is =>, why is x.to!string allowed template 
specialization should say x.to!(string), which leads me to think 
that there are multiple syntaxes for things(why I hate dynamic 
languages, love compiled)

On another note, (copied from wikipedia)

foreach(item; set) {
   // do something to item
}

what's with the lax syntax being allowed? Shouldn't it be at 
least specified "auto item"?

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.

David <d dav1d.de> writes:

Am 19.07.2012 16:21, schrieb Petr Janda:
 Hi,

 I'm an occasional lurker on the D forums just to see where the language
 is going,but I'm a little puzzled. In another thread I found this code

 auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);

 I don't understand whats going on here. Int array is getting sorted,
 then Uniqued, then what? What type is x? What kind of operator is =>,
 why is x.to!string allowed template specialization should say
 x.to!(string), which leads me to think that there are multiple syntaxes
 for things(why I hate dynamic languages, love compiled)

 On another note, (copied from wikipedia)

 foreach(item; set) {
    // do something to item
 }

 what's with the lax syntax being allowed? Shouldn't it be at least
 specified "auto item"?

 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.

=> → New Lambda Syntax
.sort.uniq.map(…) → UFCS (Uniform Function Call Syntax, iirc)

Array gets sorted, then doubles are removed (uniq) and then everything 
is converted to a string (map).

Everything was recently introduced around 2.059.

"Petr Janda" <janda.petr gmail.com> writes:

 Array gets sorted, then doubles are removed (uniq) and then 
 everything is converted to a string (map).

 Everything was recently introduced around 2.059.

Ok, but what is map!(). What's the point of the exclamation mark, 
is it a template specialization?

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 19-07-2012 16:31, Petr Janda wrote:
 Array gets sorted, then doubles are removed (uniq) and then everything
 is converted to a string (map).

 Everything was recently introduced around 2.059.

 Ok, but what is map!(). What's the point of the exclamation mark, is it
 a template specialization?

It means template instantiation. The parameter list following the 
exclamation mark are passed to the template, while the second parameter 
list contains the normal runtime arguments.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"q66" <quaker66 gmail.com> writes:

On Thursday, 19 July 2012 at 14:31:41 UTC, Petr Janda wrote:
 Array gets sorted, then doubles are removed (uniq) and then 
 everything is converted to a string (map).

 Everything was recently introduced around 2.059.

 Ok, but what is map!(). What's the point of the exclamation 
 mark, is it a template specialization?

stuff after ! specifies template arguments, in this case a 
predicate; "map" is a standard function in many languages; what 
it does basically is to go over an iterable object, apply the 
predicate function given in the template argument to each element 
and returns a new iterable containing the results of the 
predicate call on each element.

"q66" <quaker66 gmail.com> writes:

On Thursday, 19 July 2012 at 14:33:49 UTC, q66 wrote:
 On Thursday, 19 July 2012 at 14:31:41 UTC, Petr Janda wrote:
 Array gets sorted, then doubles are removed (uniq) and then 
 everything is converted to a string (map).

 Everything was recently introduced around 2.059.

 Ok, but what is map!(). What's the point of the exclamation 
 mark, is it a template specialization?

 stuff after ! specifies template arguments, in this case a 
 predicate; "map" is a standard function in many languages; what 
 it does basically is to go over an iterable object, apply the 
 predicate function given in the template argument to each 
 element and returns a new iterable containing the results of 
 the predicate call on each element.

for example, auto x = [ 5, 10, 15, 20 ]; assert(map!(x => x + 
1)(x) == [ 6, 11, 16, 21 ])

travert phare.normalesup.org (Christophe Travert) writes:

"Petr Janda" , dans le message (digitalmars.D:172719), a écrit :
 Array gets sorted, then doubles are removed (uniq) and then 
 everything is converted to a string (map).

 Everything was recently introduced around 2.059.

 
 Ok, but what is map!(). What's the point of the exclamation mark, 
 is it a template specialization?

Yes, !(...) is template specialization.
It is the equivalent of <...> in c++.
The parentheses can be omited if only one argument is passed after the 
exclamation mark.

map is a template of the std.algorithm module.
http://dlang.org/phobos/std_algorithm.html#map

This kind of questions should go in digitalmars.D.learn.

-- 
Christophe

=?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:

On 19-07-2012 16:36, Christophe Travert wrote:
 "Petr Janda" , dans le message (digitalmars.D:172719), a écrit :
 Array gets sorted, then doubles are removed (uniq) and then
 everything is converted to a string (map).

 Everything was recently introduced around 2.059.

 Ok, but what is map!(). What's the point of the exclamation mark,
 is it a template specialization?

 Yes, !(...) is template specialization.
 It is the equivalent of <...> in c++.
 The parentheses can be omited if only one argument is passed after the
 exclamation mark.

 map is a template of the std.algorithm module.
 http://dlang.org/phobos/std_algorithm.html#map

 This kind of questions should go in digitalmars.D.learn.

No, please, template instantiation. Specialization is something 
completely different, and doesn't happen at the call site.

I don't mean to be overly pedantic, but I think OP has a C++ background 
or similar, so wrong terminology is not going to be helpful.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

travert phare.normalesup.org (Christophe Travert) writes:

Alex Rønne Petersen , dans le message (digitalmars.D:172728), a écrit :
 On 19-07-2012 16:36, Christophe Travert wrote:
 "Petr Janda" , dans le message (digitalmars.D:172719), a écrit :
 Array gets sorted, then doubles are removed (uniq) and then
 everything is converted to a string (map).

 Everything was recently introduced around 2.059.

 Ok, but what is map!(). What's the point of the exclamation mark,
 is it a template specialization?

 Yes, !(...) is template specialization.
 It is the equivalent of <...> in c++.
 The parentheses can be omited if only one argument is passed after the
 exclamation mark.

 map is a template of the std.algorithm module.
 http://dlang.org/phobos/std_algorithm.html#map

 This kind of questions should go in digitalmars.D.learn.

 
 No, please, template instantiation. Specialization is something 
 completely different, and doesn't happen at the call site.
 
 I don't mean to be overly pedantic, but I think OP has a C++ background 
 or similar, so wrong terminology is not going to be helpful.

You are right, its my mistake (well, I can still send the mistake back 
to Petr...).

"Petr Janda" <janda.petr gmail.com> writes:

 No, please, template instantiation. Specialization is something 
 completely different, and doesn't happen at the call site.

Sorry, my fault. I'm a non-native english speaker.

What I meant is calling function<string>(args)

I think it's called instantiation.

David <d dav1d.de> writes:

Am 19.07.2012 16:31, schrieb Petr Janda:
 Array gets sorted, then doubles are removed (uniq) and then everything
 is converted to a string (map).

 Everything was recently introduced around 2.059.

 Ok, but what is map!(). What's the point of the exclamation mark, is it
 a template specialization?


without UFCS: map!(x => to!string(x))(my_range)
Map is a template which takes a function/delegate/string at compile 
time, basic template usage.

"q66" <quaker66 gmail.com> writes:

On Thursday, 19 July 2012 at 14:21:47 UTC, Petr Janda wrote:
 Hi,

 I'm an occasional lurker on the D forums just to see where the 
 language is going,but I'm a little puzzled. In another thread I 
 found this code

 auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);

 I don't understand whats going on here. Int array is getting 
 sorted, then Uniqued, then what? What type is x? What kind of 
 operator is =>, why is x.to!string allowed template 
 specialization should say x.to!(string), which leads me to 
 think that there are multiple syntaxes for things(why I hate 
 dynamic languages, love compiled)

 On another note, (copied from wikipedia)

 foreach(item; set) {
   // do something to item
 }

 what's with the lax syntax being allowed? Shouldn't it be at 
 least specified "auto item"?

 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.

(arguments) => result-expression is a lambda expression; sort of 
shorthand for (arguments) { return result-expression; } anonymous 
function. x.to!string thingy is the new UFCS stuff which 
basically allows you to transform any foo(x, y, z) to x.foo(y, z) 
(so instead of calling a(b(c(d(e(f))))) you can just call 
a.b.c.d.e.f())

dynamic languages are awesome, they have their pros and cons, for 
some things they're way better than static languages but for 
other things static will fit better.

"q66" <quaker66 gmail.com> writes:

btw - as for your complains - I would blame poor D documentation 
more than the feature itself; as for "what type is x", it's 
inferred from the prototype of the called function; type 
inference is a standard feature in many static languages.

travert phare.normalesup.org (Christophe Travert) writes:

"q66" , dans le message (digitalmars.D:172716), a écrit :
 (so instead of calling a(b(c(d(e(f))))) you can just call 
 a.b.c.d.e.f())

rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter 
(but f).

"Petr Janda" <janda.petr gmail.com> writes:

On Thursday, 19 July 2012 at 14:31:53 UTC, 
travert phare.normalesup.org (Christophe Travert) wrote:
 "q66" , dans le message (digitalmars.D:172716), a écrit :
 (so instead of calling a(b(c(d(e(f))))) you can just call 
 a.b.c.d.e.f())

 rather f.e.d.c.b.a, if you omit the empty parenthesis after 
 each letter
 (but f).

Ok, but the empty parenthesis is is important, it tells you about 
whether it's a an object or a function.

It's another thing I hate about Ruby is that a parenthesis 
enforcement is weak.

travert phare.normalesup.org (Christophe Travert) writes:

"Petr Janda" , dans le message (digitalmars.D:172727), a écrit :
 On Thursday, 19 July 2012 at 14:31:53 UTC, 
 travert phare.normalesup.org (Christophe Travert) wrote:
 "q66" , dans le message (digitalmars.D:172716), a écrit :
 (so instead of calling a(b(c(d(e(f))))) you can just call 
 a.b.c.d.e.f())

 rather f.e.d.c.b.a, if you omit the empty parenthesis after 
 each letter
 (but f).

 
 Ok, but the empty parenthesis is is important, it tells you about 
 whether it's a an object or a function.
 
 It's another thing I hate about Ruby is that a parenthesis 
 enforcement is weak.

property (functions that behaves like fields) don't require 
empty parenthesis. This feature has been extended to all function, 
leading to the current situation. Some people would like this to 
disappear, and enforce strict property. To take the function object, and 
not its result, take its adress.
f == f() : the result
&f : the function.

Indeed, by looking at f, you can't tell if it is a function or an 
object. You can never tell much when you see an isolated symbol...

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Thu, 19 Jul 2012 14:44:20 +0000 (UTC)
travert phare.normalesup.org (Christophe Travert) wrote:

 "Petr Janda" , dans le message (digitalmars.D:172727), a =E9crit=A0:
 On Thursday, 19 July 2012 at 14:31:53 UTC,=20
 travert phare.normalesup.org (Christophe Travert) wrote:
 "q66" , dans le message (digitalmars.D:172716), a =E9crit=A0:
 (so instead of calling a(b(c(d(e(f))))) you can just call=20
 a.b.c.d.e.f())

 rather f.e.d.c.b.a, if you omit the empty parenthesis after=20
 each letter
 (but f).

=20
 Ok, but the empty parenthesis is is important, it tells you about=20
 whether it's a an object or a function.
=20
 It's another thing I hate about Ruby is that a parenthesis=20
 enforcement is weak.

=20
 property (functions that behaves like fields) don't require=20
 empty parenthesis. This feature has been extended to all function,=20
 leading to the current situation. Some people would like this to=20
 disappear, and enforce strict property.

That's already happening. It's just that for the moment you have to
pass -property into DMD. Then it'll enforce "Function calls always need
parens, propertied always omit parens". Supposedly, this behavior will
become the default at some point.

Timon Gehr <timon.gehr gmx.ch> writes:

On 07/19/2012 04:39 PM, Petr Janda wrote:
 On Thursday, 19 July 2012 at 14:31:53 UTC, travert phare.normalesup.org
 (Christophe Travert) wrote:
 "q66" , dans le message (digitalmars.D:172716), a écrit :
 (so instead of calling a(b(c(d(e(f))))) you can just call a.b.c.d.e.f())

 rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter
 (but f).

 Ok, but the empty parenthesis is is important,

It is not.

 it tells you about whether it's a an object or a function.

(No, it does not. And even if it would, )

There is usually nothing that makes this distinction terribly
important.

Furthermore, to learn the meaning of a symbol, being able to look at its 
documentation or declaration is fully sufficient / required.

 It's another thing I hate about Ruby is that a parenthesis enforcement
 is weak.

I take that to mean you dislike ruby's function call syntax. That is a
very poor thing to dislike, there is no objective justification for it.

Jacob Carlborg <doob me.com> writes:

On 2012-07-19 16:39, Petr Janda wrote:

 It's another thing I hate about Ruby is that a parenthesis enforcement
 is weak.

I love that :)

-- 
/Jacob Carlborg

"Robik" <szadows gmail.com> writes:

On Thursday, 19 July 2012 at 14:21:47 UTC, Petr Janda wrote:
 Hi,

Hi

 I'm an occasional lurker on the D forums just to see where the 
 language is going,but I'm a little puzzled. In another thread I 
 found this code

 auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);

Here's list what happens:

  1) Array gets sorted
  2) Duplicate elements gets removed (only unique stay)
  3) Then it get's maped by delegate. It converts numbers into 
strings.
     `r` variable will be ["3", "5", "6", "8"]

 What type is x?

Type of x is inferred.

 What kind of operator is =>

Syntatic sugar for delegates.

 On another note, (copied from wikipedia)

 foreach(item; set) {
   // do something to item
 }

Item type is inferred from `set`, it's just syntactic sugar. Of 
course you can use `auto` but you don't have to.

travert phare.normalesup.org (Christophe Travert) writes:

"Robik" , dans le message (digitalmars.D:172718), a écrit :
 On Thursday, 19 July 2012 at 14:21:47 UTC, Petr Janda wrote:
 Hi,

 
 Hi
 
 I'm an occasional lurker on the D forums just to see where the 
 language is going,but I'm a little puzzled. In another thread I 
 found this code

 auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);

 
 Here's list what happens:
 
   1) Array gets sorted
   2) Duplicate elements gets removed (only unique stay)
   3) Then it get's maped by delegate. It converts numbers into 
 strings.
      `r` variable will be ["3", "5", "6", "8"]

To be more precise, `r` variable is a lazy range, equivalent to this 
array. r.array would be this array.

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 19-07-2012 16:21, Petr Janda wrote:
 Hi,

 I'm an occasional lurker on the D forums just to see where the language
 is going,but I'm a little puzzled. In another thread I found this code

 auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);

 I don't understand whats going on here. Int array is getting sorted,
 then Uniqued, then what? What type is x? What kind of operator is =>,
 why is x.to!string allowed template specialization should say
 x.to!(string), which leads me to think that there are multiple syntaxes
 for things(why I hate dynamic languages, love compiled)

 On another note, (copied from wikipedia)

 foreach(item; set) {
    // do something to item
 }

 what's with the lax syntax being allowed? Shouldn't it be at least
 specified "auto item"?

 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.

No, it's just trying to make the developer's life easier.

What you see here is uniform function call syntax (UFCS), type 
inference, array literals, etc. These are all more or less standard 

Rust, ...

And please, don't use a title like "what has gone wrong with this 
language?" if you're not sure how half of the features work. I don't 
blame you for not understanding, but dlang.org has plenty of 
documentation on these things (and TDPL certainly, too). Don't expect to 
know exactly what some piece of code from an arbitrary language does 
without knowing that language first.

I suspect that you have a C++ background. If this is not accurate, 
ignore the rest. But if it is accurate, my plea to you is: Learn other 
languages. C++ has next to no innovative language features (even C++11's 
take on lambdas is an abomination) and encourages defensive programming 
to the point where it's ridiculous (I mean, no default initialization of 
variables? In 2012?).

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

Jacob Carlborg <doob me.com> writes:

On 2012-07-19 16:50, Alex Rønne Petersen wrote:

 I suspect that you have a C++ background. If this is not accurate,
 ignore the rest. But if it is accurate, my plea to you is: Learn other
 languages. C++ has next to no innovative language features (even C++11's
 take on lambdas is an abomination) and encourages defensive programming
 to the point where it's ridiculous (I mean, no default initialization of
 variables? In 2012?).

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.

-- 
/Jacob Carlborg

Paulo Pinto <pjmlp progtools.org> writes:

Am 19.07.2012 22:43, schrieb Jacob Carlborg:
 On 2012-07-19 16:50, Alex Rønne Petersen wrote:

 I suspect that you have a C++ background. If this is not accurate,
 ignore the rest. But if it is accurate, my plea to you is: Learn other
 languages. C++ has next to no innovative language features (even C++11's
 take on lambdas is an abomination) and encourages defensive programming
 to the point where it's ridiculous (I mean, no default initialization of
 variables? In 2012?).

 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.

That is why any C or C++ project should have static analysis tools 
integrated in the continuous integration build system, plus compiling 
all warnings as errors.

--
Paulo

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Thu, 19 Jul 2012 22:45:10 +0200
Paulo Pinto <pjmlp progtools.org> wrote:

 Am 19.07.2012 22:43, schrieb Jacob Carlborg:
 On 2012-07-19 16:50, Alex R=F8nne Petersen wrote:

 I suspect that you have a C++ background. If this is not accurate,
 ignore the rest. But if it is accurate, my plea to you is: Learn
 other languages. C++ has next to no innovative language features
 (even C++11's take on lambdas is an abomination) and encourages
 defensive programming to the point where it's ridiculous (I mean,
 no default initialization of variables? In 2012?).

 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.

=20
 That is why any C or C++ project should have static analysis tools=20
 integrated in the continuous integration build system, plus compiling=20
 all warnings as errors.
=20

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.

Jacob Carlborg <doob me.com> writes:

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

"Paulo Pinto" <pjmlp progtools.org> writes:

"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

postings.

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

--
Paulo

Marco Leise <Marco.Leise gmx.de> writes:

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

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

=20
 idea which are initialized and which are not.

I think C++ uses a pragmatic approach: No overhead for explicit initializat=
ion. But everything that goes into the executable and doesn't have a specif=
ic 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!

--=20
Marco

Jacob Carlborg <doob me.com> writes:

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

Marco Leise <Marco.Leise gmx.de> writes:

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

"Stuart" <stugol gmx.com> writes:

Let me just add, I really *like* the terse syntax of D. Lambdas, 
uniform function call syntax, and so on.

Although the most important difference between C++ and D, in my 
opinion, is the absence of the damn #include statement!! That 
archaic assembly-language-inspired way of cramming billions of 
lines of code into a single text document; then compiling it; and 
then bitching about redefined symbols and incompatibilities 
between headers has caused me more hours of hair-tearing 
frustration than any single other language "feature".

Garbage-collection I can live without. Closures, properties and 
events I really miss when they're not available. But header files 
were the single worst thing to ever befall coders.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 21 Jul 2012 23:14:12 +0200
"Stuart" <stugol gmx.com> wrote:
 Let me just add, I really *like* the terse syntax of D. Lambdas, 
 uniform function call syntax, and so on.
 

Yea. I used Java in college and ever since then I've been a fan of
non-verbose systax - ie syntax that's the *opposite* of Java ;)

 
 Garbage-collection I can live without. Closures, properties and 
 events I really miss when they're not available. But header files 
 were the single worst thing to ever befall coders.

I agree, a proper module system was one of the first, biggest things
that drew me to D - It was one of the handful of things Java actually
got *right* compared to C++ (another big one being reference semantics
for classes). When I use C++, a proper module system is one of the
biggest things I miss.

Aside from the issues you mention, there's another big benefit to
killing off the #include system and switching to D: Type names and other
identifiers aren't cluttered up with the noise of a make-shift module
system. (Yea, there's namespaces, but not everyone seems to use them.
I assume there's probably good reasons for that...besides easier
integration with D ;) )

For example, I'm using the IwGame C++ library
( http://www.drmop.com/index.php/iwgame-engine/ ) and fucking *EVERY*
type name is prefixed with "CIwGame...". And anything from the
underlying Marmalade starts with "CIw..." so basic vectors are
named convoluted shit like "CIwFVec2". Of course, this is on top of the
fact that until C++11 becomes more widespread there isn't a damn bit of
type inference anywhere, so those horrific full names have to be used
EVERYWHERE. With a proper module system like D's, there'd be no
problem with names like "ImageActor" and "FVec2" instead of
"CIwGameImageActor" and "CIwFVec2", because conflicts could be easily
detected and dealt with.

And of course the other real obvious benefit of killing #include: None
of that separate cpp/h file bullshit.

C++ is living in the 70's. It should have a mascot wearing a leisure
suit.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/21/12 6:16 PM, Nick Sabalausky wrote:
 Yea. I used Java in college and ever since then I've been a fan of
 non-verbose systax - ie syntax that's the *opposite* of Java ;)

On slide 19 of the OSCON slides there's this sample:

auto s = ["abc", "a", "xz"];
auto m = s.argmin!((x) => x.length);

People in the audience were quite pleasantly surprised to figure that 
although there's no mention of a type, that code is all the compiler 
needs to figure there's a lambda that takes a string and returns an 
unsigned integer etc.


Andrei

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 21 Jul 2012 18:24:04 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 7/21/12 6:16 PM, Nick Sabalausky wrote:
 Yea. I used Java in college and ever since then I've been a fan of
 non-verbose systax - ie syntax that's the *opposite* of Java ;)

 
 On slide 19 of the OSCON slides there's this sample:
 
 auto s = ["abc", "a", "xz"];
 auto m = s.argmin!((x) => x.length);
 
 People in the audience were quite pleasantly surprised to figure that 
 although there's no mention of a type, that code is all the compiler 
 needs to figure there's a lambda that takes a string and returns an 
 unsigned integer etc.
 

Exactly. And what many people (depressingly) don't realize, is
that dynamic typing (or OO boxing) is NOT needed to achieve that.

I was actually impressed with that slide, too, but for a different
reason: I've come across need for a function like argmin on occasion,
but I didn't know it existed (Don't recall if it was actually in D, may
have been another language I was using). That really is a fantastically
useful function.

Jens Mueller <jens.k.mueller gmx.de> writes:

Nick Sabalausky wrote:
 On Sat, 21 Jul 2012 18:24:04 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 
 On 7/21/12 6:16 PM, Nick Sabalausky wrote:
 Yea. I used Java in college and ever since then I've been a fan of
 non-verbose systax - ie syntax that's the *opposite* of Java ;)

 
 On slide 19 of the OSCON slides there's this sample:
 
 auto s = ["abc", "a", "xz"];
 auto m = s.argmin!((x) => x.length);
 
 People in the audience were quite pleasantly surprised to figure that 
 although there's no mention of a type, that code is all the compiler 
 needs to figure there's a lambda that takes a string and returns an 
 unsigned integer etc.
 

 
 Exactly. And what many people (depressingly) don't realize, is
 that dynamic typing (or OO boxing) is NOT needed to achieve that.
 
 I was actually impressed with that slide, too, but for a different
 reason: I've come across need for a function like argmin on occasion,
 but I didn't know it existed (Don't recall if it was actually in D, may
 have been another language I was using). That really is a fantastically
 useful function.

Where is argmin defined? I couldn't find it.

Jens

"monarch_dodra" <monarchdodra gmail.com> writes:

On Sunday, 22 July 2012 at 03:06:28 UTC, Jens Mueller wrote:
 Where is argmin defined? I couldn't find it.

 Jens

Argmin don't exist, but it could, and that's what counts. The
important thing in these slides is proof of concept, rather than
actual code snippets.

However, std.algorithm does have minPos, but it works a little
differently. For starters, it requires a binary pred, as opposed
to an unary weight function. second, it returns a range.

Anyways, this gets you the same result:

auto m = s.minPos!((a, b) => a.length < b.length).front;

"David Nadlinger" <see klickverbot.at> writes:

On Sunday, 22 July 2012 at 03:06:28 UTC, Jens Mueller wrote:
 Where is argmin defined? I couldn't find it.

On the slide before that… ;)

David

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/22/12 12:32 PM, David Nadlinger wrote:
 On Sunday, 22 July 2012 at 03:06:28 UTC, Jens Mueller wrote:
 Where is argmin defined? I couldn't find it.

 On the slide before that… ;)

I think argmin is intuitive, popular, and useful enough to warrant a 
presence in std.algorithm. Would anyone want to do the honors?


Thanks,

Andrei

"monarch_dodra" <monarchdodra gmail.com> writes:

On Sunday, 22 July 2012 at 21:10:08 UTC, Andrei Alexandrescu 
wrote:
 On 7/22/12 12:32 PM, David Nadlinger wrote:
 On Sunday, 22 July 2012 at 03:06:28 UTC, Jens Mueller wrote:
 Where is argmin defined? I couldn't find it.

 On the slide before that… ;)

 I think argmin is intuitive, popular, and useful enough to 
 warrant a presence in std.algorithm. Would anyone want to do 
 the honors?


 Thanks,

 Andrei

Are you asking for the _actual_ argmin as defined in the paper?

Because I think it would be much better if we provided an 
overload for the existing minPos/minRange to accept a unary pred:

----
Range minPos(alias pred, Range)(Range range)
   if (is(typeof(unaryFun!pred(range.front))))
{
   ...
}
----
Tuple!(ElementType!(Range), size_t)
minCount(alias pred, Range)(Range range)
   if (is(typeof(unaryFun!pred(range.front))))
{
   ...
}
----

Where pred if the unary weight function. This code would then 
work as such:

----
auto m = s.minPos!((x) => x.length).front;
----
auto m = s.minCount!((x) => x.length)[1];
----

Both versions require an extra .front/[1], but that's because 
that's just how the algorithms work.

I actually _just_ rewrote these two methods (they are in my pull 
requests). I'm on it if you you like the idea of being able to 
call these functions with a unary predicated (I do): It sure 
beats writing "(a, b) => pred(a) < pred(b)" when you could just 
write "a => pred(a)"

Jens Mueller <jens.k.mueller gmx.de> writes:

David Nadlinger wrote:
 On Sunday, 22 July 2012 at 03:06:28 UTC, Jens Mueller wrote:
Where is argmin defined? I couldn't find it.

 
 On the slide before that$B!D(B ;)

:)

Jens

Paulo Pinto <pjmlp progtools.org> writes:

Am 22.07.2012 00:16, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 23:14:12 +0200
 "Stuart"<stugol gmx.com>  wrote:
 Let me just add, I really *like* the terse syntax of D. Lambdas,
 uniform function call syntax, and so on.

 Yea. I used Java in college and ever since then I've been a fan of
 non-verbose systax - ie syntax that's the *opposite* of Java ;)

Actually that verbose sintax is quite helpful when dealing with gigantic
code bases in big corporation projects like where I work.

The type of "programmer clogs" we have in our projects are so low skill,
that I have bad dreams what they could do in more powerfull languages.



What I hate in Java is the abuse of annotations to avoid introducing new
keyworks, like  overload. This recalls me of a software project where 
the DSL in use, got so many annotations that it become unmanageable.

 Garbage-collection I can live without. Closures, properties and
 events I really miss when they're not available. But header files
 were the single worst thing to ever befall coders.

 I agree, a proper module system was one of the first, biggest things
 that drew me to D - It was one of the handful of things Java actually
 got *right* compared to C++ (another big one being reference semantics
 for classes). When I use C++, a proper module system is one of the
 biggest things I miss.

 Aside from the issues you mention, there's another big benefit to
 killing off the #include system and switching to D: Type names and other
 identifiers aren't cluttered up with the noise of a make-shift module
 system. (Yea, there's namespaces, but not everyone seems to use them.
 I assume there's probably good reasons for that...besides easier
 integration with D ;) )

Legacy code. As some compilers took several years to fully support the
standard. This was one of the things that got my interest in Java back 
in 1996.

Finally a C++ like language, where I could make use of modern C++ 
features, without getting the source code full of #ifdef.

 For example, I'm using the IwGame C++ library
 ( http://www.drmop.com/index.php/iwgame-engine/ ) and fucking *EVERY*
 type name is prefixed with "CIwGame...". And anything from the
 underlying Marmalade starts with "CIw..." so basic vectors are
 named convoluted shit like "CIwFVec2". Of course, this is on top of the
 fact that until C++11 becomes more widespread there isn't a damn bit of
 type inference anywhere, so those horrific full names have to be used
 EVERYWHERE. With a proper module system like D's, there'd be no
 problem with names like "ImageActor" and "FVec2" instead of
 "CIwGameImageActor" and "CIwFVec2", because conflicts could be easily
 detected and dealt with.

 And of course the other real obvious benefit of killing #include: None
 of that separate cpp/h file bullshit.

 C++ is living in the 70's. It should have a mascot wearing a leisure
 suit.

Very true.

I never understood why C++ could not have a module system. It would 
still be possible to compile C code anyway. In fact, in Turbo Pascal you
get both, a preprocessor with includes and modules(units).

The sad thing is that most languages designed in the early 80's all had
proper modules.

--
Paulo

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sun, 22 Jul 2012 20:24:19 +0200
Paulo Pinto <pjmlp progtools.org> wrote:

 Am 22.07.2012 00:16, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 23:14:12 +0200
 "Stuart"<stugol gmx.com>  wrote:
 Let me just add, I really *like* the terse syntax of D. Lambdas,
 uniform function call syntax, and so on.

 Yea. I used Java in college and ever since then I've been a fan of
 non-verbose systax - ie syntax that's the *opposite* of Java ;)

 
 Actually that verbose sintax is quite helpful when dealing with
 gigantic code bases in big corporation projects like where I work.
 
 The type of "programmer clogs" we have in our projects are so low
 skill, that I have bad dreams what they could do in more powerfull
 languages.
 

 

Yea, I've dealt with far too many such "programmers" myself. I'm
convinced, no hyperbole, that such people need to be unemployed (I hear
McDonald's is always looking for mindless drones.) All they ever do is
fuck things up, get in the way, make 100x more work for the rest of us,
and collect a salary for THAT. And then get promoted to management
where they can do even more damage (at least it gets their inept,
retarded ass out of the fucking codebase).

Yea, I have no sympathy for such...subhumans.

And the whole reason those societal leeches ever gets hired in the first
place is because the even MORE retarded HR fuckwads actually look
specifically FOR revolving-door-moron-certificates (aka "college
degree") and 500 years experience in *one and ONLY one* language and
it's inevitably something rancid like PHP.

If they would just kick these fucks out in the street where they
belong (and I genuinely mean that), then productivity would skyrocket,
costs would plummet, and there's be no need for such kiddie, retard,
"tricycle *with* training wheels" languages like Java.

Paulo Pinto <pjmlp progtools.org> writes:

Am 22.07.2012 21:28, schrieb Nick Sabalausky:
 On Sun, 22 Jul 2012 20:24:19 +0200
 Paulo Pinto<pjmlp progtools.org>  wrote:

 Am 22.07.2012 00:16, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 23:14:12 +0200
 "Stuart"<stugol gmx.com>   wrote:
 Let me just add, I really *like* the terse syntax of D. Lambdas,
 uniform function call syntax, and so on.

 Yea. I used Java in college and ever since then I've been a fan of
 non-verbose systax - ie syntax that's the *opposite* of Java ;)

 Actually that verbose sintax is quite helpful when dealing with
 gigantic code bases in big corporation projects like where I work.

 The type of "programmer clogs" we have in our projects are so low
 skill, that I have bad dreams what they could do in more powerfull
 languages.



 Yea, I've dealt with far too many such "programmers" myself. I'm
 convinced, no hyperbole, that such people need to be unemployed (I hear
 McDonald's is always looking for mindless drones.) All they ever do is
 fuck things up, get in the way, make 100x more work for the rest of us,
 and collect a salary for THAT. And then get promoted to management
 where they can do even more damage (at least it gets their inept,
 retarded ass out of the fucking codebase).

Actually in our case it is because management only wants to pay for 
cheap developers, to avoid having project costs too high.

When things go wrong, then some of us need to play fireman to bring the
project back into safe waters, but hey at least on the official 
expenses, the project is still "cheap".

--
Paulo

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sun, 22 Jul 2012 23:15:06 +0200
Paulo Pinto <pjmlp progtools.org> wrote:

 Am 22.07.2012 21:28, schrieb Nick Sabalausky:
 On Sun, 22 Jul 2012 20:24:19 +0200
 Paulo Pinto<pjmlp progtools.org>  wrote:

 Am 22.07.2012 00:16, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 23:14:12 +0200
 "Stuart"<stugol gmx.com>   wrote:
 Let me just add, I really *like* the terse syntax of D. Lambdas,
 uniform function call syntax, and so on.

 Yea. I used Java in college and ever since then I've been a fan of
 non-verbose systax - ie syntax that's the *opposite* of Java ;)

 Actually that verbose sintax is quite helpful when dealing with
 gigantic code bases in big corporation projects like where I work.

 The type of "programmer clogs" we have in our projects are so low
 skill, that I have bad dreams what they could do in more powerfull
 languages.



 Yea, I've dealt with far too many such "programmers" myself. I'm
 convinced, no hyperbole, that such people need to be unemployed (I
 hear McDonald's is always looking for mindless drones.) All they
 ever do is fuck things up, get in the way, make 100x more work for
 the rest of us, and collect a salary for THAT. And then get
 promoted to management where they can do even more damage (at least
 it gets their inept, retarded ass out of the fucking codebase).

 
 Actually in our case it is because management only wants to pay for 
 cheap developers, to avoid having project costs too high.
 

Perhaps I forgot to mention that 90% of managers belong under the same
semitruck tire as the rest of the HR folks and Java/PHP monkeys ;)

Besides, a manager's role is administration, ie shitwork: Their job is
to enable the REAL talent to do the REAL work, make sure they have what
they need to do it, and then get the fuck out of the way. And maybe
keep the sales monkeys in line with a good caning every now and then.

But when a manager either oversteps those boundaries, or get even just
gets paid *as* much as the real workers (let alone more), then they
belong locked in a cell. What I'm *not* sure about is whether the cell
should be the padded or concrete variety...Meh, I suppose I don't care
which as long as they're no longer damaging society.

 When things go wrong, then some of us need to play fireman to bring
 the project back into safe waters, but hey at least on the official 
 expenses, the project is still "cheap".
 
 --
 Paulo
 
 

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sun, 22 Jul 2012 20:24:19 +0200
Paulo Pinto <pjmlp progtools.org> wrote:

 Am 22.07.2012 00:16, schrieb Nick Sabalausky:
 On Sat, 21 Jul 2012 23:14:12 +0200
 "Stuart"<stugol gmx.com>  wrote:
 Let me just add, I really *like* the terse syntax of D. Lambdas,
 uniform function call syntax, and so on.

 Yea. I used Java in college and ever since then I've been a fan of
 non-verbose systax - ie syntax that's the *opposite* of Java ;)

 
 Actually that verbose sintax

"verbose sintax"...Was that deliberate spelling or a very coincidental
accident?

 is quite helpful when dealing with
 gigantic code bases in big corporation projects like where I work.
 
 The type of "programmer clogs" we have in our projects are so low
 skill, that I have bad dreams what they could do in more powerfull
 languages.
 


Actually, that may be a good reason NOT to use a training-wheels
language like Java - one they finally do *that* much damage, maybe
they'll finally get the boot ;) Mwa ha ha ha ha!
 
 What I hate in Java is the abuse of annotations to avoid introducing
 new keyworks, like  overload.
 

Heh, sounds vaguely similar to another language I've heard of...Hmm,
what was it called...? Not C...Something after that... ;)

I never actually stuck around in Java long enough to see the annotation
stuff (though I've heard about it). I think 1.3 or 1.4 was about when I
fled.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Mon, Jul 23, 2012 at 10:00:24PM -0400, Nick Sabalausky wrote:
 On Sun, 22 Jul 2012 20:24:19 +0200
 Paulo Pinto <pjmlp progtools.org> wrote:

[...]
 The type of "programmer clogs" we have in our projects are so low
 skill, that I have bad dreams what they could do in more powerfull
 languages.
 


 
 Actually, that may be a good reason NOT to use a training-wheels
 language like Java - one they finally do *that* much damage, maybe
 they'll finally get the boot ;) Mwa ha ha ha ha!

[...]

Unfortunately, that usually happens only after they burned down your
project. It only takes one twig to burn down a forest; it only takes one
twit to burn down a project.

Reminds of a certain individual who shall remain unnamed, with whom I
argued about why he should *not* implement IPv6 prefix checking by
converting the address and prefixes to strings and then using
strncmp()... Truly boggles the mind.


T

-- 
I'm still trying to find a pun for "punishment"...

"Chris NS" <ibisbasenji gmail.com> writes:

On Tuesday, 24 July 2012 at 02:51:44 UTC, H. S. Teoh wrote:
 Reminds of a certain individual who shall remain unnamed, with 
 whom I
 argued about why he should *not* implement IPv6 prefix checking 
 by
 converting the address and prefixes to strings and then using
 strncmp()... Truly boggles the mind.

I'm reminded of a close friend of mine... once he was asked to 
review some code, after the sole author had spent a few weeks on 
it.  I was lucky (?) enough to be in the room to hear him 
actually say: "That's... cute.  Not *wise* but cute.  Do you 
remember what functions are?"  I don't recall there being a 
response.

-- Chris NS

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Tue, 24 Jul 2012 08:40:13 +0200
"Chris NS" <ibisbasenji gmail.com> wrote:

 On Tuesday, 24 July 2012 at 02:51:44 UTC, H. S. Teoh wrote:
 Reminds of a certain individual who shall remain unnamed, with 
 whom I
 argued about why he should *not* implement IPv6 prefix checking 
 by
 converting the address and prefixes to strings and then using
 strncmp()... Truly boggles the mind.

 
 I'm reminded of a close friend of mine... once he was asked to 
 review some code, after the sole author had spent a few weeks on 
 it.  I was lucky (?) enough to be in the room to hear him 
 actually say: "That's... cute.  Not *wise* but cute.  Do you 
 remember what functions are?"  I don't recall there being a 
 response.
 

That's...hilarious. Disturbing, but hilarious.

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

On Tuesday, 24 July 2012 at 06:40:14 UTC, Chris NS wrote:
 On Tuesday, 24 July 2012 at 02:51:44 UTC, H. S. Teoh wrote:
 Reminds of a certain individual who shall remain unnamed, with 
 whom I argued about why he should *not* implement IPv6 prefix 
 checking by converting the address and prefixes to strings and 
 then using strncmp()... Truly boggles the mind.

 I'm reminded of a close friend of mine... once he was asked to 
 review some code, after the sole author had spent a few weeks 
 on it.  I was lucky (?) enough to be in the room to hear him 
 actually say: "That's... cute.  Not *wise* but cute.  Do you 
 remember what functions are?"  I don't recall there being a 
 response.

  I remember seeing some stupid production code that was used at a 
company I worked at for a while. They were developing jsp pages 
as part of their training until they got sections hired out 
(sorta lowest bidder thing, where you would go to them rather 
than export work over seas).

  The code in question was to convert the input 16byte input from 
a database into it's GUID id as a text string in java. I don't 
remember it exactly, but it went something like...

[code]
//remember, java
String toGuid(byte input[16]) {
   String ID = "{";
   if (Integer.toHexString(input[5]).length < 2)
     ID = ID + "0";
   ID = ID + Integer.toHexString(input[5]);
   if (Integer.toHexString(input[6]).length < 2)
     ID = ID + "0";
   ID = ID + Integer.toHexString(input[6]);

//repeat for other 14 bytes, plus adding dashes and ending brace

   return ID;
}
[/code]

  It didn't help the company's Java class that they taught didn't 
go into low level operations like And and Or and bit shifting. I 
ended up rewriting it, then they wanted it 'super documented' 
because they couldn't understand what > were for. (I think there 
was more documentation commenting low level explanations of what 
it was doing than actual code).

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

On Tuesday, 24 July 2012 at 22:38:07 UTC, Era Scarecrow wrote:
 documented' because they couldn't understand what > were for.

  Sorry my filter stripped that out. They couldn't understand what 
<< and >> were for.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/24/12 6:48 PM, Era Scarecrow wrote:
 On Tuesday, 24 July 2012 at 22:38:07 UTC, Era Scarecrow wrote:
 documented' because they couldn't understand what > were for.

 Sorry my filter stripped that out. They couldn't understand what << and
  >> were for.

x >>= 2; // if x much greater than 2, assign 2 to it

Andrei

"Chris NS" <ibisbasenji gmail.com> writes:

On Tuesday, 24 July 2012 at 22:38:07 UTC, Era Scarecrow wrote:
 [code]
 //remember, java
 String toGuid(byte input[16]) {
   String ID = "{";
   if (Integer.toHexString(input[5]).length < 2)
     ID = ID + "0";
   ID = ID + Integer.toHexString(input[5]);
   if (Integer.toHexString(input[6]).length < 2)
     ID = ID + "0";
   ID = ID + Integer.toHexString(input[6]);

 //repeat for other 14 bytes, plus adding dashes and ending brace

   return ID;
 }
 [/code]

I just died a little inside...

If not for Andrei's little joke, I don't know what I might have 
done.

Erm, so that I'm not completely off-topic: I know where D has 
truly gone wrong.  There's just too many damn semi-colons!

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Wed, 25 Jul 2012 03:52:28 +0200
"Chris NS" <ibisbasenji gmail.com> wrote:
 
 Erm, so that I'm not completely off-topic: I know where D has 
 truly gone wrong.  There's just too many damn semi-colons!
 

Nah, I know exactly where it went wrong.

Albuquerque.

Shoulda gone left.

"Stuart" <stugol gmx.com> writes:

I've only recently discovered D, and I already think it's great. 
I mean, where else am I going to find a language that [a] 
compiles to native code, [b] has classes, [c] has no stupid 
flat-file #include system, and [d] has a GC? Honestly, I can't 
think of any others!

I really don't understand it when people yell "no more syntax!!!" 
though. Someone in this thread suggested using the ? operator to 
denote "nullable", and someone else objected to additional 
syntax. Personally I'm in favour of new syntax. One syntax 
addition that'd be really helpful is something that'd let me 
shorten "a != null ? a : b" to something like "a??b". Sort of an 
in-line "orelse". You could even chain them - e.g. "a??b??c". Of 
course, it'd have to work with nullable types (when null), 
integers (0), bools (false), and empty or uninitialised strings.

I reckon no pointers or references should be allowed null unless 
specified as such. That's one thing they even got wrong in .NET. 
Alternatively, to avoid breaking new code, use some kind of 
suffix to denote non-nullable.

I'd also like to see native support for embedded XML, like VB.NET 
has. Of course, it'd be next to useless without LINQ, and that'd 
require first-class support for iterators (see the YIELD keyword 

anyway in their own right, LINQ or no LINQ. D should have 
iterators.

Incidentally, does D have any real RTTI, or are we still in 
CPP-land on that?

"Stuart" <stugol gmx.com> writes:

On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky wrote:
 C++ is living in the 70's.

Precisely what I have been thinking. It's a loose wrapper around
assembly, nothing more. Certainly not the "high-level language"
it's touted as.

Paulo Pinto <pjmlp progtools.org> writes:

Am 23.07.2012 14:49, schrieb Stuart:
 On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky wrote:
 C++ is living in the 70's.

 Precisely what I have been thinking. It's a loose wrapper around
 assembly, nothing more. Certainly not the "high-level language"
 it's touted as.

Only due to the lack of modules.

Everything else is a pretty modern language I would say.

Personally as I referred here in multiple threads I don't have any
big issues dealing with C++, but maybe that is just me.

--
Paulo

"Stuart" <stugol gmx.com> writes:

On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote:
 Am 23.07.2012 14:49, schrieb Stuart:
 On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky 
 wrote:
 C++ is living in the 70's.

 Precisely what I have been thinking. It's a loose wrapper 
 around
 assembly, nothing more. Certainly not the "high-level language"
 it's touted as.

 Only due to the lack of modules.

 Everything else is a pretty modern language I would say.

Hardly. No RTTI. No GC. No properties. No events. No closures. No 
extension methods. No interfaces. No writable references.

I can live without a GC; and interfaces can be simulated using 
pure virtual base classes; but all the others are standard in 
pretty much any modern language and impossible to reproduce in 
C++.

Incidentally, it'd be really handy to have anonymous tuples in D. 
Not many languages let you do that. For example:

    tuple!(int, float) fn() { ... }

    int a;
    float b;
    (a, b) = fn();

    auto (c, d) = fn();

Saves us having to create a struct for every goddamn little 
function; or using tuples directly, which means we have to refer 
to variables like .value1 and .value2 instead of something 
meaningful.

"Stuart" <stugol gmx.com> writes:

On Monday, 23 July 2012 at 20:51:19 UTC, Stuart wrote:
 Incidentally, it'd be really handy to have anonymous tuples in 
 D.

Or perhaps I should've said "named tuples". I dunno what the 
correct term might be. All I know is, I've only seen it in one or 
two obscure languages, and I've always wished .NET had it.

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Mon, 23 Jul 2012 22:51:19 +0200, Stuart <stugol gmx.com> wrote:

 Saves us having to create a struct for every goddamn little function; or  
 using tuples directly, which means we have to refer to variables like  
 .value1 and .value2 instead of something meaningful.

You mean like this?

Tuple!(float, "x", float, "y") bar() {
     return typeof(return)( 0.0, 0.0 );
}

auto xCoord = bar().x;


I dislike the typeof(return) in there, as assignment between tuples with
and without named fields works perfectly. Bring me the sky, Walter?

--
Simen

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/23/12 5:14 PM, Simen Kjaeraas wrote:
 On Mon, 23 Jul 2012 22:51:19 +0200, Stuart <stugol gmx.com> wrote:

 Saves us having to create a struct for every goddamn little function;
 or using tuples directly, which means we have to refer to variables
 like .value1 and .value2 instead of something meaningful.

 You mean like this?

 Tuple!(float, "x", float, "y") bar() {
 return typeof(return)( 0.0, 0.0 );
 }

 auto xCoord = bar().x;


 I dislike the typeof(return) in there, as assignment between tuples with
 and without named fields works perfectly. Bring me the sky, Walter?

We could make

return tuple(0.0, 0.0);

to work. I can't imagine a scenario in which this relaxation would cause 
a bug.


Andrei

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Tue, 24 Jul 2012 04:21:18 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Tuple!(float, "x", float, "y") bar() {
 return typeof(return)( 0.0, 0.0 );
 }


[snip]
 We could make

 return tuple(0.0, 0.0);

 to work. I can't imagine a scenario in which this relaxation would cause  
 a bug.

I would argue it should work, for the exact reasons outline above. And as
you say, it should cause no bugs.

But can it be made to work in current D, as a library solution? Or do you
mean the language should be changed? (This looks to me a lot like the old
opImplicitCast)

-- 
Simen

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/24/12 5:03 AM, Simen Kjaeraas wrote:
 On Tue, 24 Jul 2012 04:21:18 +0200, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Tuple!(float, "x", float, "y") bar() {
 return typeof(return)( 0.0, 0.0 );
 }


 [snip]
 We could make

 return tuple(0.0, 0.0);

 to work. I can't imagine a scenario in which this relaxation would
 cause a bug.

 I would argue it should work, for the exact reasons outline above. And as
 you say, it should cause no bugs.

 But can it be made to work in current D, as a library solution? Or do you
 mean the language should be changed? (This looks to me a lot like the old
 opImplicitCast)

Library solution.

Andrei

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, July 24, 2012 11:03:16 Simen Kjaeraas wrote:
 On Tue, 24 Jul 2012 04:21:18 +0200, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:
 Tuple!(float, "x", float, "y") bar() {
 return typeof(return)( 0.0, 0.0 );
 }


 
 [snip]
 
 We could make
 
 return tuple(0.0, 0.0);
 
 to work. I can't imagine a scenario in which this relaxation would cause
 a bug.

 
 I would argue it should work, for the exact reasons outline above. And as
 you say, it should cause no bugs.
 
 But can it be made to work in current D, as a library solution? Or do you
 mean the language should be changed? (This looks to me a lot like the old
 opImplicitCast)

That's what alias this is for.

- Jonathan M Davis

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Tue, 24 Jul 2012 13:00:44 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Tuesday, July 24, 2012 11:03:16 Simen Kjaeraas wrote:
 On Tue, 24 Jul 2012 04:21:18 +0200, Andrei Alexandrescu

 <SeeWebsiteForEmail erdani.org> wrote:
 Tuple!(float, "x", float, "y") bar() {
 return typeof(return)( 0.0, 0.0 );
 }


 [snip]

 We could make

 return tuple(0.0, 0.0);

 to work. I can't imagine a scenario in which this relaxation would  

 cause
 a bug.

 I would argue it should work, for the exact reasons outline above. And  
 as
 you say, it should cause no bugs.

 But can it be made to work in current D, as a library solution? Or do  
 you
 mean the language should be changed? (This looks to me a lot like the  
 old
 opImplicitCast)

 That's what alias this is for.

Well, sorta. See, I'm asking for an unbounded set of possible
conversions, as Tuple!int should be implicitly convertible to
Tuple!(int, "a"), Tuple!(int, "b"), Tuple!(int, "Help"), and
Tuple!(int, "AnotherOneBitesTheDust").

And that's just the ones with int as the first parameter. Then comes
float, double, long, and so on.

I may be wrong, but I don't think alias this can handle that. In fact,
I just tried, and got DMD to hang.

-- 
Simen

"Stuart" <stugol gmx.com> writes:

On Monday, 23 July 2012 at 21:14:31 UTC, Simen Kjaeraas wrote:
 On Mon, 23 Jul 2012 22:51:19 +0200, Stuart <stugol gmx.com> 
 wrote:

 Saves us having to create a struct for every goddamn little 
 function; or using tuples directly, which means we have to 
 refer to variables like .value1 and .value2 instead of 
 something meaningful.

 You mean like this?

 Tuple!(float, "x", float, "y") bar() {
     return typeof(return)( 0.0, 0.0 );
 }

 auto xCoord = bar().x;

You mean it's already supported? Nice! Although, It'd still be 
awesome to be able to do things like:

    auto a,b = bar();

    auto c,_ = bar();

"Regan Heath" <regan netmail.co.nz> writes:

On Tue, 24 Jul 2012 15:42:19 +0100, Stuart <stugol gmx.com> wrote:

 On Monday, 23 July 2012 at 21:14:31 UTC, Simen Kjaeraas wrote:
 On Mon, 23 Jul 2012 22:51:19 +0200, Stuart <stugol gmx.com> wrote:

 Saves us having to create a struct for every goddamn little function;  
 or using tuples directly, which means we have to refer to variables  
 like .value1 and .value2 instead of something meaningful.

 You mean like this?

 Tuple!(float, "x", float, "y") bar() {
     return typeof(return)( 0.0, 0.0 );
 }

 auto xCoord = bar().x;

 You mean it's already supported? Nice! Although, It'd still be awesome  
 to be able to do things like:

     auto a,b = bar();

     auto c,_ = bar();

Sadly the comma operator (inherited from C/C++) blocks this syntax.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

"Stuart" <stugol gmx.com> writes:

On Tuesday, 24 July 2012 at 14:50:02 UTC, Regan Heath wrote:
 On Tue, 24 Jul 2012 15:42:19 +0100, Stuart <stugol gmx.com> 
 wrote:

 You mean it's already supported? Nice! Although, It'd still be 
 awesome to be able to do things like:

    auto a,b = bar();

    auto c,_ = bar();

 Sadly the comma operator (inherited from C/C++) blocks this 
 syntax.

Well, how about "auto {a,b} = ", or "auto [a,b] = ", or something 
like that?

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Tue, Jul 24, 2012 at 03:49:14PM +0100, Regan Heath wrote:
 On Tue, 24 Jul 2012 15:42:19 +0100, Stuart <stugol gmx.com> wrote:

[...]
You mean it's already supported? Nice! Although, It'd still be
awesome to be able to do things like:

    auto a,b = bar();

    auto c,_ = bar();

 
 Sadly the comma operator (inherited from C/C++) blocks this syntax.

[...]

The comma operator must go.

I know, I know, it ain't gonna happen with D2. One can still hope,
though.


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 7/24/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 The comma operator must go.

The comma operator needs to die a fast but painful death. I've had
this sort of bug recently:

int getInt(string op)
{
    if (op, "a")
        return 1;
    else
    if (op == "b")
        return 2;
    else
        return 3;
}

Guess which number it always returns regardless of input.

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Tue, 24 Jul 2012 16:42:19 +0200, Stuart <stugol gmx.com> wrote:

 You mean it's already supported? Nice!

That's what I mean. :p


 Although, It'd still be awesome to be able to do things like:

     auto a,b = bar();

     auto c,_ = bar();

That would be nice, and has been on the table numerous times.
Nothing has yet been implemented, and I don't think even a
syntax has been decided upon, so we might never see that.

The closest thing we have is probably this:

int a = 1;
int b = 3;
TypeTuple!(a,b) = tuple(b,a); // Look ma, I'm swapping!
assert(a == 3);
assert(b == 1);

...which inspired me to write this implementation of fibonacci:

T fib(T = int)(int n, T a = 0, T b = 1) {
     while ( n-- ) {
         TypeTuple!(a,b) = tuple(b, a +b);
     }
     return a;
}

-- 
Simen

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 07/24/2012 07:42 AM, Stuart wrote:

 You mean it's already supported? Nice! Although, It'd still be awesome
 to be able to do things like:

 auto a,b = bar();

 auto c,_ = bar();

Works in foreach loops:

     foreach (a, b; hasTupleElements)

The element type of the following range of map results is a tuple:

import std.stdio;
import std.algorithm;

void main()
{
     auto values = [1.25, 2.50, 3.75];
     auto results = map!(a => a / 4, a => a * 10)(values);

     writeln(" Quarters  Ten Times");

     foreach (quarterResult, tenTimesResult; results) {
         writefln("%8.2f%8.2f", quarterResult, tenTimesResult);
     }
}

Ali

Russel Winder <russel winder.org.uk> writes:

On Tue, 2012-07-24 at 16:59 +0200, Simen Kjaeraas wrote:
[=E2=80=A6]
 ...which inspired me to write this implementation of fibonacci:
=20
 T fib(T =3D int)(int n, T a =3D 0, T b =3D 1) {
      while ( n-- ) {
          TypeTuple!(a,b) =3D tuple(b, a +b);
      }
      return a;
 }

Or possibly better:

long fibonacci ( immutable long n ) {
  return array ( takeExactly ( recurrence ! ( "a[n-1] + a[n-2]" ) ( 0L , 1L=
 ) , cast ( size_t ) ( n + 1 ) ) ) [ n ] ;
}

?
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Tue, 24 Jul 2012 19:02:07 +0200, Russel Winder <russel winder.org.uk>=
  =

wrote:

 On Tue, 2012-07-24 at 16:59 +0200, Simen Kjaeraas wrote:
 [=E2=80=A6]
 ...which inspired me to write this implementation of fibonacci:

 T fib(T =3D int)(int n, T a =3D 0, T b =3D 1) {
      while ( n-- ) {
          TypeTuple!(a,b) =3D tuple(b, a +b);
      }
      return a;
 }

 Or possibly better:

 long fibonacci ( immutable long n ) {
   return array ( takeExactly ( recurrence ! ( "a[n-1] + a[n-2]" ) ( 0L=

 ,  =

 1L ) , cast ( size_t ) ( n + 1 ) ) ) [ n ] ;
 }

 ?

I had to fix things a bit (I have reasons to want the template parameter=
  =

there):

T fib(T =3D int)(int n, T a =3D to!T(0), T b =3D to!T(1)) {
     while ( n-- ) {
         TypeTuple!(a,b) =3D tuple(b, a +b);
     }
     return a;
}

Now, try asking each of these for fib!BigInt(1_000_000). :p

-- =

Simen

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Mon, 23 Jul 2012 22:51:19 +0200
"Stuart" <stugol gmx.com> wrote:

 On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote:
 Am 23.07.2012 14:49, schrieb Stuart:
 On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky 
 wrote:
 C++ is living in the 70's.

 Precisely what I have been thinking. It's a loose wrapper 
 around
 assembly, nothing more. Certainly not the "high-level language"
 it's touted as.

 Only due to the lack of modules.

 Everything else is a pretty modern language I would say.

 
 Hardly. No RTTI. No GC. No properties. No events. No closures. No 
 extension methods. No interfaces. No writable references.
 

Null-terminated strings. Preprocessor. No reflection. Effectively
undefined sizes for primitive types. Undefined behavior galore. Neither
default initialization nor enforced initialization before variable
usage. No reference types (Foo& isn't what I mean). Horrendous type
syntax for mixed arrays/ptrs or functions ptrs, etc. No forward
references (or at least very limited). And a grammar that forces
compilation to be very, very slow.

And a lot more still that's lacking if you don't count C++11 which
isn't widely supported yet (ex: foreach, basic type inference).

And the fact that static analysis tools are as super useful as they are
is plenty proof alone that the language itself is WAAAY behind the
curve.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Mon, 23 Jul 2012 17:19:09 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Mon, 23 Jul 2012 22:51:19 +0200
 "Stuart" <stugol gmx.com> wrote:
 
 On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote:
 Am 23.07.2012 14:49, schrieb Stuart:
 On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky 
 wrote:
 C++ is living in the 70's.

 Precisely what I have been thinking. It's a loose wrapper 
 around
 assembly, nothing more. Certainly not the "high-level language"
 it's touted as.

 Only due to the lack of modules.

 Everything else is a pretty modern language I would say.

 
 Hardly. No RTTI. No GC. No properties. No events. No closures. No 
 extension methods. No interfaces. No writable references.
 

 
 Null-terminated strings. Preprocessor. No reflection. Effectively
 undefined sizes for primitive types. Undefined behavior galore.
 Neither default initialization nor enforced initialization before
 variable usage. No reference types (Foo& isn't what I mean).
 Horrendous type syntax for mixed arrays/ptrs or functions ptrs, etc.
 No forward references (or at least very limited). And a grammar that
 forces compilation to be very, very slow.
 

Speaking of, I understand he had C++ in mind when he wrote this song:
https://www.youtube.com/watch?v=DOj3wDlr_BM

"Paulo Pinto" <pjmlp progtools.org> writes:

"Nick Sabalausky"  wrote in message news:20120723171909.00000527 unknown...

On Mon, 23 Jul 2012 22:51:19 +0200
"Stuart" <stugol gmx.com> wrote:

 On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote:
 Am 23.07.2012 14:49, schrieb Stuart:
 On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky
 wrote:
 C++ is living in the 70's.

 Precisely what I have been thinking. It's a loose wrapper
 around
 assembly, nothing more. Certainly not the "high-level language"
 it's touted as.

 Only due to the lack of modules.

 Everything else is a pretty modern language I would say.

 Hardly. No RTTI. No GC. No properties. No events. No closures. No
 extension methods. No interfaces. No writable references.

Null-terminated strings. Preprocessor. No reflection. Effectively
undefined sizes for primitive types. Undefined behavior galore. Neither
default initialization nor enforced initialization before variable
usage. No reference types (Foo& isn't what I mean). Horrendous type
syntax for mixed arrays/ptrs or functions ptrs, etc. No forward
references (or at least very limited). And a grammar that forces
compilation to be very, very slow.

Null-terminated strings are a consequence of C compatibility, which is very 
70's.
Nowadays I mostly use std::string or QtString, no null-terminated strings 
for me, unless talking
with C apis.

Preprocessor is quite handy as long as you don't abuse it.

Undefined sizes for primitive types is the only way to have a language that 
doesn't impose restrictions
on the target processor. D on the other hand is not able to target anything 
lower than 32 bits, if I understand
correctly.

Compilation slowness is true,  that was my complaint regarding modules. It 
all boils down to
the 70's compiler/linker model inherited from C, instead of the module 
system introduced by languages
like Modula-2 already in 1983.


And a lot more still that's lacking if you don't count C++11 which
isn't widely supported yet (ex: foreach, basic type inference).

And the fact that static analysis tools are as super useful as they are
is plenty proof alone that the language itself is WAAAY behind the
curve.

This is valid for C as well.

My main point is that despite C++ issues it still feels very modern to me, 
specially
when you compare with what Go, a modern language from 2009 offers. I'll take 
C++
over Go any day.

But in the end I really miss that Turbo Pascal/Delphi lost the mainstream 
language game.


being two of them.

--
Paulo

"Paulo Pinto" <pjmlp progtools.org> writes:

"Stuart"  wrote in message news:nnyvtncaxpgnjtklvyhd forum.dlang.org...
On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote:
 Am 23.07.2012 14:49, schrieb Stuart:
 On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky wrote:
 C++ is living in the 70's.

 Precisely what I have been thinking. It's a loose wrapper around
 assembly, nothing more. Certainly not the "high-level language"
 it's touted as.

 Only due to the lack of modules.

 Everything else is a pretty modern language I would say.

Hardly. No RTTI. No GC. No properties. No events. No closures. No extension 
methods. No interfaces. No writable references.

I can live without a GC; and interfaces can be simulated using pure virtual 
base classes; but all the others are standard in pretty much any modern 
language and impossible to reproduce in C++.


RTTI is available last time I checked. Sure it is not a full reflection 
runtime,
but from my daily job experience with Enterprise Architecture with 
reflection everywhere
in JVM and .NET languages, not sure if C++ really needs a full reflection 
API.

GC is optional since C++11, sure it a nice to have, but reference pointers 
alleviate a bit the issue.

Extension methods are nice, but if you look at our Enterprise Architectures, 
they can surely be
abused to death, monkey patch hurray!

Interfaces are only required as such in languages that don't support MI.

If you need a writable references use pointers.

--
Paulo

"David Piepgrass" <qwertie256 gmail.com> writes:

 I suspect that you have a C++ background. If this is not 
 accurate, ignore the rest. But if it is accurate, my plea to 
 you is: Learn other languages. C++ has next to no innovative 
 language features (even C++11's take on lambdas is an 
 abomination) and encourages defensive programming to the point 
 where it's ridiculous (I mean, no default initialization of 
 variables? In 2012?).


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" :)

* technically the compiler asks the runtime to bitwise 0-fill 
everything, but that's just an implementation detail required for 
the .NET verifier, and the optimizer can ignore the request to 
preinitialize.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 20 Jul 2012 00:32:03 +0200
"David Piepgrass" <qwertie256 gmail.com> wrote:

 I suspect that you have a C++ background. If this is not 
 accurate, ignore the rest. But if it is accurate, my plea to 
 you is: Learn other languages. C++ has next to no innovative 
 language features (even C++11's take on lambdas is an 
 abomination) and encourages defensive programming to the point 
 where it's ridiculous (I mean, no default initialization of 
 variables? In 2012?).

 

 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" :)
 
 * technically the compiler asks the runtime to bitwise 0-fill 
 everything, but that's just an implementation detail required for 
 the .NET verifier, and the optimizer can ignore the request to 
 preinitialize.

I've always wished D worked that way, too.

Faux Amis <faux amis.com> writes:

On 20/07/2012 00:49, Nick Sabalausky wrote:
 On Fri, 20 Jul 2012 00:32:03 +0200
 "David Piepgrass" <qwertie256 gmail.com> wrote:

 I suspect that you have a C++ background. If this is not
 accurate, ignore the rest. But if it is accurate, my plea to
 you is: Learn other languages. C++ has next to no innovative
 language features (even C++11's take on lambdas is an
 abomination) and encourages defensive programming to the point
 where it's ridiculous (I mean, no default initialization of
 variables? In 2012?).


 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" :)

 * technically the compiler asks the runtime to bitwise 0-fill
 everything, but that's just an implementation detail required for
 the .NET verifier, and the optimizer can ignore the request to
 preinitialize.

 I've always wished D worked that way, too.

vote++

"Damian" <damianday hotmail.co.uk> writes:

On Thursday, 19 July 2012 at 22:32:04 UTC, David Piepgrass wrote:
 I suspect that you have a C++ background. If this is not 
 accurate, ignore the rest. But if it is accurate, my plea to 
 you is: Learn other languages. C++ has next to no innovative 
 language features (even C++11's take on lambdas is an 
 abomination) and encourages defensive programming to the point 
 where it's ridiculous (I mean, no default initialization of 
 variables? In 2012?).


 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" :)

 * technically the compiler asks the runtime to bitwise 0-fill 
 everything, but that's just an implementation detail required 
 for the .NET verifier, and the optimizer can ignore the request 
 to preinitialize.

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?

Jeff Nowakowski <jeff dilacero.org> writes:

On 07/19/2012 09:35 PM, Damian wrote:
 On Thursday, 19 July 2012 at 22:32:04 UTC, David Piepgrass wrote:

 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

Jacob Carlborg <doob me.com> writes:

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


 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

"renoX" <renozyx gmail.com> writes:

On Friday, 20 July 2012 at 06:40:18 UTC, Jacob Carlborg wrote:
 On 2012-07-20 00:32, David Piepgrass wrote:


 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

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

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:


 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]

Timon Gehr <timon.gehr gmx.ch> writes:

On 07/19/2012 04:21 PM, Petr Janda wrote:
 Hi,

 I'm an occasional lurker on the D forums just to see where the language
 is going,but I'm a little puzzled. In another thread I found this code

 auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);

 I don't understand whats going on here. Int array is getting sorted,
 then Uniqued, then what?

Then it is mapped to string representations, just as the code says.

 What type is x?

'int', if you like.

 What kind of operator is =>,

Lambda function. It is the same as (...){ return ...; }, just without 
the noise.

 why is x.to!string allowed template specialization should say
 x.to!(string),

Why should it say that?

 which leads me to think that there are multiple syntaxes
 for things

There always are 'multiple syntaxes for things' if writing code should
be productive and validating code for static correctness should be
decidable.

(why I hate dynamic languages, love compiled)

This is unrelated to dynamic vs. compiled. (those two terms do not
contradict each other anyway.)

 On another note, (copied from wikipedia)

 foreach(item; set) {
 // do something to item
 }

 what's with the lax syntax being allowed?

s/lax/to the point/

 Shouldn't it be at least specified "auto item"?

Why on earth would that be the case?

 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.

It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.

"Petr Janda" <janda.petr gmail.com> writes:

 It's just syntax. Eliminating syntax noise is fine. Code should 
 look
 like what it does.

Not if "eliminating noise" equals to making things harder to 
understand.

When you say (int x) { return x; } it's clear about what it is, a 
_function_ without name.

Timon Gehr <timon.gehr gmx.ch> writes:

On 07/19/2012 05:03 PM, Petr Janda wrote:
 It's just syntax. Eliminating syntax noise is fine. Code should look
 like what it does.

 Not if "eliminating noise" equals to making things harder to understand.

Harder to understand to whom? Optimizing stuff for beginners usually
makes it a PITA to work with.

 When you say (int x) { return x; } it's clear about what it is, a
 _function_ without name.

That expression looks eg. like this in Haskell:
\x->x

(If the type of x cannot be inferred to Int, then it is (\x->x)::Int->Int)

I agree that there is some non-uniformity. It should be possible to use
=> in named function declarations.

Brad Anderson <eco gnuk.net> writes:

On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr gmail.com> wrote:

 It's just syntax. Eliminating syntax noise is fine. Code should look
 like what it does.

 Not if "eliminating noise" equals to making things harder to understand.

 When you say (int x) { return x; } it's clear about what it is, a
 _function_ without name.

Nothing is stopping someone from being explicit with their types like that,
of course.

Here is the original code written in a way that is probably more familiar
to you:

auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));

Personally I find the original version to be much more readable but that
does require a basic knowledge of D's syntax. People coming from other
languages are free to use the more classic way if they wish.  It's better
to learn idiomatic usage of a language, though, instead of forcing it to be
a language you are more comfortable in.

Regards,
Brad Anderson

Timon Gehr <timon.gehr gmx.ch> writes:

On 07/19/2012 05:20 PM, Brad Anderson wrote:
 On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr gmail.com
 <mailto:janda.petr gmail.com>> wrote:

         It's just syntax. Eliminating syntax noise is fine. Code should look
         like what it does.


     Not if "eliminating noise" equals to making things harder to understand.

     When you say (int x) { return x; } it's clear about what it is, a
     _function_ without name.


 Nothing is stopping someone from being explicit with their types like
 that, of course.

 Here is the original code written in a way that is probably more
 familiar to you:

 auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));

                          ^
                        return
 Personally I find the original version to be much more readable but that
 does require a basic knowledge of D's syntax. People coming from other
 languages are free to use the more classic way if they wish.  It's
 better to learn idiomatic usage of a language, though, instead of
 forcing it to be a language you are more comfortable in.

 Regards,
 Brad Anderson

Brad Anderson <eco gnuk.net> writes:

On Thu, Jul 19, 2012 at 9:20 AM, Brad Anderson <eco gnuk.net> wrote:

 On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr gmail.com> wrote:

  It's just syntax. Eliminating syntax noise is fine. Code should look
 like what it does.

 Not if "eliminating noise" equals to making things harder to understand.

 When you say (int x) { return x; } it's clear about what it is, a
 _function_ without name.

 Nothing is stopping someone from being explicit with their types like
 that, of course.

 Here is the original code written in a way that is probably more familiar
 to you:

 auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));

Ehm...forgot the return:

auto r = map!((int x) { return to!(string)(x); })(uniq(sort([5, 3, 5, 6,
8])));


 Personally I find the original version to be much more readable but that
 does require a basic knowledge of D's syntax. People coming from other
 languages are free to use the more classic way if they wish.  It's better
 to learn idiomatic usage of a language, though, instead of forcing it to be
 a language you are more comfortable in.

 Regards,
 Brad Anderson

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 07/19/2012 08:03 AM, Petr Janda wrote:
 It's just syntax. Eliminating syntax noise is fine. Code should look
 like what it does.

 Not if "eliminating noise" equals to making things harder to understand.

 When you say (int x) { return x; } it's clear about what it is, a
 _function_ without name.

Others beat me to it but the anonymous function can be written more 
completely as

   function string(int x) { return x.to!string(); }

(Or 'delegate' depending on the situation.)

Allow me to add a take(..., 2) to the entire expression, which is to me 
the strongest reason why UFCS can be great:

     writeln(take(map!(function string(int x) { return x.to!string(); 
})(uniq(sort([5, 3, 5, 6, 8]))), 2));

The problem is, the 2 is related to take() but they are too far apart 
above. UFCS puts them together:

   a_long_expression.take(2)

I don't like UFCS everywhere but it is very helpful in many cases.

Ali

Jacob Carlborg <doob me.com> writes:

On 2012-07-19 17:03, Petr Janda wrote:
 It's just syntax. Eliminating syntax noise is fine. Code should look
 like what it does.

 Not if "eliminating noise" equals to making things harder to understand.

 When you say (int x) { return x; } it's clear about what it is, a
 _function_ without name.

It's equally clear when you see: =>.

-- 
/Jacob Carlborg

"David Nadlinger" <see klickverbot.at> writes:

On Thursday, 19 July 2012 at 14:51:59 UTC, Timon Gehr wrote:
 On another note, (copied from wikipedia)

 foreach(item; set) {
 // do something to item
 }

 what's with the lax syntax being allowed?

 s/lax/to the point/

 Shouldn't it be at least specified "auto item"?

 Why on earth would that be the case?

 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.

 It's just syntax. Eliminating syntax noise is fine. Code should 
 look
 like what it does.

Additionally, allowing to omit auto is actually consistent with 
the rest of the language, which also allows you to not explicitly 
write it if the code doesn't become ambiguous (for example, you 
don't need to do "immutable auto").

David

"Bernard Helyer" <b.helyer gmail.com> writes:

What the _fuck_ guys? How did you get this many posts on what is 
essentially "this looks weird and I can't be fucked reading the 
documentation?".

FeepingCreature <default_357-line yahoo.de> writes:

On 07/19/12 23:03, Bernard Helyer wrote:
 What the _fuck_ guys? How did you get this many posts on what is essentially
"this looks weird and I can't be fucked reading the documentation?".

In other words, see subject.

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

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. ;)