www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Just where has this language gone wrong?

reply "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.
Jul 19 2012
next sibling parent reply 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.
Jul 19 2012
next sibling parent =?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
Jul 19 2012
prev sibling next sibling parent reply 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
Jul 19 2012
parent reply =?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 Rnne Petersen alex lycus.org http://lycus.org
Jul 19 2012
parent travert phare.normalesup.org (Christophe Travert) writes:
Alex Rnne 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...).
Jul 19 2012
prev sibling parent 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.
Jul 19 2012
prev sibling next sibling parent reply "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.
Jul 19 2012
parent reply 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).
Jul 19 2012
next sibling parent 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...
Jul 19 2012
prev sibling next sibling parent 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.
Jul 19 2012
prev sibling parent 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
Jul 19 2012
prev sibling next sibling parent "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.
Jul 19 2012
prev sibling next sibling parent reply "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?

 What kind of operator is =>

 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.
Jul 19 2012
parent 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.
Jul 19 2012
prev sibling next sibling parent "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?
Jul 19 2012
prev sibling next sibling parent "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.
Jul 19 2012
prev sibling next sibling parent "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 ])
Jul 19 2012
prev sibling next sibling parent "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.
Jul 19 2012
prev sibling next sibling parent reply =?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 features of modern statically typed languages. See ML, C#, Scala, F#, 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
Jul 19 2012
next sibling parent reply 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
Jul 19 2012
next sibling parent reply 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
Jul 19 2012
parent reply 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
Jul 19 2012
parent "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 seems to be planning to offer native code compiler for C#, from their job postings. To become a widspread systems programming language, D needs to get support from an OS or driver vendor. -- Paulo
Jul 20 2012
prev sibling next sibling parent reply 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
Jul 20 2012
next sibling parent reply 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
Jul 21 2012
parent 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
Jul 22 2012
prev sibling next sibling parent reply 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. Already C# is highly advanced for some of them! 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
Jul 22 2012
next sibling parent 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. Already C# is highly advanced for some of them!

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
Jul 22 2012
prev sibling parent 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
Jul 24 2012
prev sibling next sibling parent reply 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
Jul 23 2012
next sibling parent reply 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
Jul 23 2012
parent 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 );
 }


 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
Jul 24 2012
prev sibling next sibling parent "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
Jul 24 2012
prev sibling parent =?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
Jul 24 2012
prev sibling next sibling parent "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.
Jul 24 2012
prev sibling parent 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.
Jul 24 2012
prev sibling parent 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
Jul 24 2012
prev sibling next sibling parent 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?).

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

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

It would be great if D did do this, surely it would not be all that difficult! and wouldn't it also help in finding unused variables?

Walter doesn't like it. Past discussions: http://forum.dlang.org/post/gon06s$1nbe$1 digitalmars.com http://forum.dlang.org/post/ha37cf$4l2$1 digitalmars.com http://forum.dlang.org/post/i4mlee$5a2$1 digitalmars.com
Jul 19 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-20 00:32, David Piepgrass wrote:

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

Floats and doubles initialized to NaN can be really annoying when interfacing to C or porting to D from another language. -- /Jacob Carlborg
Jul 19 2012
prev sibling next sibling parent "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.
Jul 19 2012
prev sibling next sibling parent reply 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.
Jul 19 2012
next sibling parent 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.
Jul 19 2012
prev sibling next sibling parent 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

Jul 19 2012
prev sibling next sibling parent =?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
Jul 19 2012
prev sibling parent 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
Jul 19 2012
prev sibling next sibling parent "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.
Jul 19 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--e89a8f3ba7fbbe896304c53052fb
Content-Type: text/plain; charset=ISO-8859-1

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 --e89a8f3ba7fbbe896304c53052fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <span dir=3D"ltr">&lt;<a href= =3D"mailto:janda.petr gmail.com" target=3D"_blank">janda.petr gmail.com</a>= &gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> It&#39;s just syntax. Eliminating syntax noise is fine. Code should look<br=

</blockquote> <br></div> Not if &quot;eliminating noise&quot; equals to making things harder to unde= rstand.<br> <br> When you say (int x) { return x; } it&#39;s clear about what it is, a _func= tion_ without name.<br> </blockquote></div><div><br></div>Nothing is stopping someone from being ex= plicit with their types like that, of course.<div><br></div><div>Here is th= e original code written in a way that is probably more familiar to you:</di= v> <div><br></div><div>auto r =3D map!((int x) { to!(string)(x); })(uniq(sort(= [5, 3, 5, 6, 8])));</div><div><br></div><div>Personally I find the original= version to be much more readable but that does require a basic knowledge o= f D&#39;s syntax. People coming from other languages are free to use the mo= re classic way if they wish. =A0It&#39;s better to learn idiomatic usage of= a language, though, instead of forcing it to be a language you are more co= mfortable in.</div> <div><br></div><div>Regards,</div><div>Brad Anderson</div> --e89a8f3ba7fbbe896304c53052fb--
Jul 19 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--e89a8f3ba7fb476e5304c5307776
Content-Type: text/plain; charset=ISO-8859-1

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

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

--e89a8f3ba7fb476e5304c5307776 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2012 at 9:20 AM, Brad Anderson <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:eco gnuk.net" target=3D"_blank">eco gnuk.net</a>&gt;</span> wro= te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Thu, Jul 19, 2012 at 9:03 AM, Pe= tr Janda <span dir=3D"ltr">&lt;<a href=3D"mailto:janda.petr gmail.com" targ= et=3D"_blank">janda.petr gmail.com</a>&gt;</span> wrote:<br><div class=3D"g= mail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"> It&#39;s just syntax. Eliminating syntax noise is fine. Code should look<br=

</blockquote> <br></div> Not if &quot;eliminating noise&quot; equals to making things harder to unde= rstand.<br> <br> When you say (int x) { return x; } it&#39;s clear about what it is, a _func= tion_ without name.<br> </blockquote></div><div><br></div></div></div>Nothing is stopping someone f= rom being explicit with their types like that, of course.<div><br></div><di= v>Here is the original code written in a way that is probably more familiar= to you:</div> <div><br></div><div>auto r =3D map!((int x) { to!(string)(x); })(uniq(sort(= [5, 3, 5, 6, 8])));</div><div><br></div></blockquote><div><br></div><div>Eh= m...forgot the return:</div><div><br></div><div>auto r =3D map!((int x) { r= eturn to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div></div><div>Personally I f= ind the original version to be much more readable but that does require a b= asic knowledge of D&#39;s syntax. People coming from other languages are fr= ee to use the more classic way if they wish. =A0It&#39;s better to learn id= iomatic usage of a language, though, instead of forcing it to be a language= you are more comfortable in.</div> <div><br></div><div>Regards,</div><div>Brad Anderson</div> </blockquote></div><br> --e89a8f3ba7fb476e5304c5307776--
Jul 19 2012
prev sibling next sibling parent "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
Jul 19 2012
prev sibling next sibling parent 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).

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.

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.
Jul 19 2012
prev sibling next sibling parent reply "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?".
Jul 19 2012
parent 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.
Jul 19 2012
prev sibling next sibling parent 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.

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.
Jul 19 2012
prev sibling next sibling parent "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?).

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

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

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

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

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

I think that the worse part of this is that it make integers and floats needlessly different.. renoX
Jul 20 2012
prev sibling next sibling parent 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=

 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
Jul 20 2012
prev sibling next sibling parent "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:

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

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

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

chars initialize to 0xff by default. By putting the values as close to a invalid state as possible helps them to stand out as uninitialized. There's a small part in walter's article on demystifying the floating point, where he went onto the bugs involved which were hard to figure out. http://dlang.org/d-floating-point.html [quote] My first floating-point nightmare occurred in a C++ program which hung once in every hundred runs or so. I eventually traced the problem to a while loop which occasionally failed to terminate. The essence of the code is shown in Listing 1. [code] double q[8]; ... int x = 0; while (x < 8) { if ( q[x] >= 0 ) return true; if ( q[x] < 0 ) ++x; } return false; [/code] Initially, I was completely baffled as to how this harmless-looking loop could fail. But eventually, I discovered that q had not been initialized properly; q[7] contained random garbage. Occasionally, that garbage had every bit set, which mean that q[7] was a Not-a-Number (NaN), a special code which indicates that the value of the variable is nonsense. NaNs were not mentioned in the compiler's documentation - the only information I could find about them was in Intel's assembly instruction set documentation! Any comparison involving a NaN is false, so q[7] was neither >= 0, nor < 0, killing my program. Until that unwelcome discovery, I'd been unaware that NaNs even existed. I had lived in a fool's paradise, mistakenly believing that every floating point number was either positive, negative, or zero. My experience would have been quite different in D. The "strange" features of floating point have a higher visibility in the language, improving the education of numerical programmers. Uninitialized floating point numbers are initialized to NaN by the compiler, so the problematic loop would fail every time, not intermittently. [/quote]
Jul 20 2012
prev sibling next sibling parent 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
Jul 21 2012
prev sibling next sibling parent "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.
Jul 21 2012
prev sibling next sibling parent 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.
Jul 21 2012
prev sibling next sibling parent 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.
Jul 21 2012
prev sibling next sibling parent 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
Jul 21 2012
prev sibling next sibling parent "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;
Jul 22 2012
prev sibling next sibling parent "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
Jul 22 2012
prev sibling next sibling parent 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. Already C# is highly advanced for some of them!

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.
Jul 22 2012
prev sibling next sibling parent 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. Already C# is highly advanced for some of them!

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
 
 

Jul 22 2012
prev sibling next sibling parent "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)"
Jul 22 2012
prev sibling next sibling parent "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.
Jul 23 2012
prev sibling next sibling parent "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.
Jul 23 2012
prev sibling next sibling parent "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.
Jul 23 2012
prev sibling next sibling parent "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
Jul 23 2012
prev sibling next sibling parent reply 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.
Jul 23 2012
parent "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. Luckly there are quite a few languages where their spirit lives on, C# and D being two of them. -- Paulo
Jul 24 2012
prev sibling next sibling parent 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
Jul 23 2012
prev sibling next sibling parent 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.
 
 Already C# is highly advanced for some of them!

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.
Jul 23 2012
prev sibling next sibling parent "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.
 
 Already C# is highly advanced for some of them!

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"...
Jul 23 2012
prev sibling next sibling parent "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
Jul 23 2012
prev sibling next sibling parent 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.
Jul 24 2012
prev sibling next sibling parent "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 );
 }


 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
Jul 24 2012
prev sibling next sibling parent 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
Jul 24 2012
prev sibling next sibling parent "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  

 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
Jul 24 2012
prev sibling next sibling parent "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();
Jul 24 2012
prev sibling next sibling parent "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/
Jul 24 2012
prev sibling next sibling parent "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?
Jul 24 2012
prev sibling next sibling parent "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
Jul 24 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
Jul 24 2012
prev sibling next sibling parent "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
Jul 24 2012
prev sibling next sibling parent "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).
Jul 24 2012
prev sibling next sibling parent "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.
Jul 24 2012
prev sibling next sibling parent "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!
Jul 24 2012
prev sibling next sibling parent 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.
Jul 24 2012
prev sibling parent "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 
in C# and VB.NET). Then again, iterators are bloody awesome 
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?
Jul 24 2012