Discussion:
Just where has this language gone wrong?
Petr Janda
2012-07-19 14:21:46 UTC
Permalink
Hi,

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

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

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

On another note, (copied from wikipedia)

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

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

I'm sorry I don't mean to be a criticizer, but it seems to me
that D is trying to be a dynamic-like compiled language way too
hard.
David
2012-07-19 14:25:35 UTC
Permalink
Hi,
I'm an occasional lurker on the D forums just to see where the language
is going,but I'm a little puzzled. In another thread I found this code
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);
I don't understand whats going on here. Int array is getting sorted,
then Uniqued, then what? What type is x? What kind of operator is =>,
why is x.to!string allowed template specialization should say
x.to!(string), which leads me to think that there are multiple syntaxes
for things(why I hate dynamic languages, love compiled)
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
what's with the lax syntax being allowed? Shouldn't it be at least
specified "auto item"?
I'm sorry I don't mean to be a criticizer, but it seems to me that D is
trying to be a dynamic-like compiled language way too hard.
=> ? New Lambda Syntax
.sort.uniq.map(?) ? UFCS (Uniform Function Call Syntax, iirc)

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

Everything was recently introduced around 2.059.
Petr Janda
2012-07-19 14:31:40 UTC
Permalink
Post by David
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?
Alex Rønne Petersen
2012-07-19 14:33:17 UTC
Permalink
Post by David
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 at lycus.org
http://lycus.org
q66
2012-07-19 14:33:48 UTC
Permalink
Post by Petr Janda
Post by David
Array gets sorted, then doubles are removed (uniq) and then
everything is converted to a string (map).
Everything was recently introduced around 2.059.
Ok, but what is map!(). What's the point of the exclamation
mark, is it a template specialization?
stuff after ! specifies template arguments, in this case a
predicate; "map" is a standard function in many languages; what
it does basically is to go over an iterable object, apply the
predicate function given in the template argument to each element
and returns a new iterable containing the results of the
predicate call on each element.
q66
2012-07-19 14:36:11 UTC
Permalink
Post by q66
Post by Petr Janda
Post by David
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 ])
Christophe Travert
2012-07-19 14:36:26 UTC
Permalink
Post by Petr Janda
Post by David
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
Alex Rønne Petersen
2012-07-19 14:41:52 UTC
Permalink
Post by Christophe Travert
Post by Petr Janda
Post by David
Array gets sorted, then doubles are removed (uniq) and then
everything is converted to a string (map).
Everything was recently introduced around 2.059.
Ok, but what is map!(). What's the point of the exclamation mark,
is it a template specialization?
Yes, !(...) is template specialization.
It is the equivalent of <...> in c++.
The parentheses can be omited if only one argument is passed after the
exclamation mark.
map is a template of the std.algorithm module.
http://dlang.org/phobos/std_algorithm.html#map
This kind of questions should go in digitalmars.D.learn.
No, please, template instantiation. Specialization is something
completely different, and doesn't happen at the call site.

I don't mean to be overly pedantic, but I think OP has a C++ background
or similar, so wrong terminology is not going to be helpful.
--
Alex R?nne Petersen
alex at lycus.org
http://lycus.org
Christophe Travert
2012-07-19 14:46:11 UTC
Permalink
Post by Alex Rønne Petersen
Post by Christophe Travert
Post by Petr Janda
Post by David
Array gets sorted, then doubles are removed (uniq) and then
everything is converted to a string (map).
Everything was recently introduced around 2.059.
Ok, but what is map!(). What's the point of the exclamation mark,
is it a template specialization?
Yes, !(...) is template specialization.
It is the equivalent of <...> in c++.
The parentheses can be omited if only one argument is passed after the
exclamation mark.
map is a template of the std.algorithm module.
http://dlang.org/phobos/std_algorithm.html#map
This kind of questions should go in digitalmars.D.learn.
No, please, template instantiation. Specialization is something
completely different, and doesn't happen at the call site.
I don't mean to be overly pedantic, but I think OP has a C++ background
or similar, so wrong terminology is not going to be helpful.
You are right, its my mistake (well, I can still send the mistake back
to Petr...).
Petr Janda
2012-07-19 14:51:20 UTC
Permalink
Post by Alex Rønne Petersen
No, please, template instantiation. Specialization is something
completely different, and doesn't happen at the call site.
Sorry, my fault. I'm a non-native english speaker.

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

I think it's called instantiation.
David
2012-07-19 14:38:09 UTC
Permalink
Post by David
Array gets sorted, then doubles are removed (uniq) and then everything
is converted to a string (map).
Everything was recently introduced around 2.059.
Ok, but what is map!(). What's the point of the exclamation mark, is it
a template specialization?
without UFCS: map!(x => to!string(x))(my_range)
Map is a template which takes a function/delegate/string at compile
time, basic template usage.
q66
2012-07-19 14:26:35 UTC
Permalink
Post by 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.
(arguments) => result-expression is a lambda expression; sort of
shorthand for (arguments) { return result-expression; } anonymous
function. x.to!string thingy is the new UFCS stuff which
basically allows you to transform any foo(x, y, z) to x.foo(y, z)
(so instead of calling a(b(c(d(e(f))))) you can just call
a.b.c.d.e.f())

dynamic languages are awesome, they have their pros and cons, for
some things they're way better than static languages but for
other things static will fit better.
q66
2012-07-19 14:28:31 UTC
Permalink
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.
Christophe Travert
2012-07-19 14:31:53 UTC
Permalink
Post by q66
(so instead of calling a(b(c(d(e(f))))) you can just call
a.b.c.d.e.f())
rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter
(but f).
Petr Janda
2012-07-19 14:39:11 UTC
Permalink
On Thursday, 19 July 2012 at 14:31:53 UTC,
Post by Christophe Travert
Post by q66
(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.
Christophe Travert
2012-07-19 14:44:20 UTC
Permalink
Post by Petr Janda
On Thursday, 19 July 2012 at 14:31:53 UTC,
Post by Christophe Travert
Post by q66
(so instead of calling a(b(c(d(e(f))))) you can just call
a.b.c.d.e.f())
rather f.e.d.c.b.a, if you omit the empty parenthesis after
each letter
(but f).
Ok, but the empty parenthesis is is important, it tells you about
whether it's a an object or a function.
It's another thing I hate about Ruby is that a parenthesis
enforcement is weak.
property (functions that behaves like fields) don't require
empty parenthesis. This feature has been extended to all function,
leading to the current situation. Some people would like this to
disappear, and enforce strict property. To take the function object, and
not its result, take its adress.
f == f() : the result
&f : the function.

Indeed, by looking at f, you can't tell if it is a function or an
object. You can never tell much when you see an isolated symbol...
Nick Sabalausky
2012-07-19 18:55:47 UTC
Permalink
On Thu, 19 Jul 2012 14:44:20 +0000 (UTC)
Post by Christophe Travert
Post by Petr Janda
On Thursday, 19 July 2012 at 14:31:53 UTC,
Post by Christophe Travert
Post by q66
(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.
That's already happening. It's just that for the moment you have to
pass -property into DMD. Then it'll enforce "Function calls always need
parens, propertied always omit parens". Supposedly, this behavior will
become the default at some point.
Timon Gehr
2012-07-19 15:16:09 UTC
Permalink
On Thursday, 19 July 2012 at 14:31:53 UTC, travert at phare.normalesup.org
Post by Christophe Travert
(so instead of calling a(b(c(d(e(f))))) you can just call a.b.c.d.e.f())
rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter
(but f).
Ok, but the empty parenthesis is is important,
It is not.
it tells you about whether it's a an object or a function.
(No, it does not. And even if it would, )

There is usually nothing that makes this distinction terribly
important.

Furthermore, to learn the meaning of a symbol, being able to look at its
documentation or declaration is fully sufficient / required.
It's another thing I hate about Ruby is that a parenthesis enforcement
is weak.
I take that to mean you dislike ruby's function call syntax. That is a
very poor thing to dislike, there is no objective justification for it.
Jacob Carlborg
2012-07-19 20:37:50 UTC
Permalink
It's another thing I hate about Ruby is that a parenthesis enforcement
is weak.
I love that :)
--
/Jacob Carlborg
Robik
2012-07-19 14:31:16 UTC
Permalink
Post by Petr Janda
Hi,
Hi
Post by Petr Janda
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"]
Post by Petr Janda
What type is x?
Type of x is inferred.
Post by Petr Janda
What kind of operator is =>
Syntatic sugar for delegates.
Post by Petr Janda
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.
Christophe Travert
2012-07-19 14:38:32 UTC
Permalink
Post by Robik
Post by Petr Janda
Hi,
Hi
Post by Petr Janda
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);
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.
Alex Rønne Petersen
2012-07-19 14:50:16 UTC
Permalink
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 at lycus.org
http://lycus.org
Jacob Carlborg
2012-07-19 20:43:17 UTC
Permalink
Post by Alex Rønne Petersen
I suspect that you have a C++ background. If this is not accurate,
ignore the rest. But if it is accurate, my plea to you is: Learn other
languages. C++ has next to no innovative language features (even C++11's
take on lambdas is an abomination) and encourages defensive programming
to the point where it's ridiculous (I mean, no default initialization of
variables? In 2012?).
In C++ it's even better (irony). It depends on what kind of variable is
declared. I.e. a global variable, a local, instance or a class variable
(static). Some of these are default initialized, some are not. I have no
idea which are initialized and which are not.
--
/Jacob Carlborg
Paulo Pinto
2012-07-19 20:45:10 UTC
Permalink
Post by Jacob Carlborg
Post by Alex Rønne Petersen
I suspect that you have a C++ background. If this is not accurate,
ignore the rest. But if it is accurate, my plea to you is: Learn other
languages. C++ has next to no innovative language features (even C++11's
take on lambdas is an abomination) and encourages defensive programming
to the point where it's ridiculous (I mean, no default initialization of
variables? In 2012?).
In C++ it's even better (irony). It depends on what kind of variable is
declared. I.e. a global variable, a local, instance or a class variable
(static). Some of these are default initialized, some are not. I have no
idea which are initialized and which are not.
That is why any C or C++ project should have static analysis tools
integrated in the continuous integration build system, plus compiling
all warnings as errors.

--
Paulo
Nick Sabalausky
2012-07-19 22:05:23 UTC
Permalink
On Thu, 19 Jul 2012 22:45:10 +0200
Post by Paulo Pinto
Post by Jacob Carlborg
Post by Alex Rønne Petersen
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.
No, this is why any C/C++ project should be replaced by D ;)

I'm knee-deep in a C++ project right now, and the language is such a
pedantic, anachronistic turd. C++'s *only* saving graces are:

- It's a systems language (ie, native compiled with low-level access).
- It isn't PHP, JS, a JS-derivitive (ex, ActionScript), or Son-Of-Flash
(aka Corona).
- D isn't mature on all platforms yet.
Jacob Carlborg
2012-07-20 06:38:43 UTC
Permalink
Post by Nick Sabalausky
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
- It's a systems language (ie, native compiled with low-level access).
- It isn't PHP, JS, a JS-derivitive (ex, ActionScript), or Son-Of-Flash
(aka Corona).
- D isn't mature on all platforms yet.
I used Boost, for a C++ project I was working on, to make it more
D-like. Foreach, auto, lambda, default initialization and other things.
Most of these things are available in C++11 now.
--
/Jacob Carlborg
Paulo Pinto
2012-07-20 07:33:59 UTC
Permalink
Post by Nick Sabalausky
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
- 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
Marco Leise
2012-07-20 14:33:34 UTC
Permalink
Am Thu, 19 Jul 2012 22:43:17 +0200
Post by Jacob Carlborg
In C++ it's even better (irony). It depends on what kind of variable is
declared. I.e. a global variable, a local, instance or a class variable
(static). Some of these are default initialized, some are not. I have no
idea which are initialized and which are not.
I think C++ uses a pragmatic approach: No overhead for explicit initialization. But everything that goes into the executable and doesn't have a specific value, will go into the BSS section, where it A) takes up no space and B) the OS will take care of zero initializing it _anyways_.

If it is stored in the .exe, it is 0!
--
Marco
Jacob Carlborg
2012-07-20 14:43:18 UTC
Permalink
Post by Marco Leise
I think C++ uses a pragmatic approach: No overhead for explicit initialization. But everything that goes into the executable and doesn't have a specific value, will go into the BSS section, where it A) takes up no space and B) the OS will take care of zero initializing it _anyways_.
If it is stored in the .exe, it is 0!
Is it defined what is placed in the executable?
--
/Jacob Carlborg
Marco Leise
2012-07-21 09:39:22 UTC
Permalink
Am Fri, 20 Jul 2012 16:43:18 +0200
Post by Jacob Carlborg
Post by Marco Leise
I think C++ uses a pragmatic approach: No overhead for explicit initialization. But everything that goes into the executable and doesn't have a specific value, will go into the BSS section, where it A) takes up no space and B) the OS will take care of zero initializing it _anyways_.
If it is stored in the .exe, it is 0!
Is it defined what is placed in the executable?
P.S.: s/section/segment/

Someone else would have to answer that question. I assume anything that is kind of static, like globals, class variables, D's .init blocks. It makes sense to me, because the compiler can issue static references to that data, instead of generating code that creates space for it e.g. on the heap and have the program use a pointer to get at it.
--
Marco
Stuart
2012-07-21 21:14:12 UTC
Permalink
Let me just add, I really *like* the terse syntax of D. Lambdas,
uniform function call syntax, and so on.

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

Garbage-collection I can live without. Closures, properties and
events I really miss when they're not available. But header files
were the single worst thing to ever befall coders.
Nick Sabalausky
2012-07-21 22:16:40 UTC
Permalink
On Sat, 21 Jul 2012 23:14:12 +0200
Post by Stuart
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 ;)
Post by Stuart
Garbage-collection I can live without. Closures, properties and
events I really miss when they're not available. But header files
were the single worst thing to ever befall coders.
I agree, a proper module system was one of the first, biggest things
that drew me to D - It was one of the handful of things Java actually
got *right* compared to C++ (another big one being reference semantics
for classes). When I use C++, a proper module system is one of the
biggest things I miss.

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

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

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

C++ is living in the 70's. It should have a mascot wearing a leisure
suit.
Andrei Alexandrescu
2012-07-21 22:24:04 UTC
Permalink
Post by Nick Sabalausky
Yea. I used Java in college and ever since then I've been a fan of
non-verbose systax - ie syntax that's the *opposite* of Java ;)
On slide 19 of the OSCON slides there's this sample:

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

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


Andrei
Nick Sabalausky
2012-07-21 22:51:54 UTC
Permalink
On Sat, 21 Jul 2012 18:24:04 -0400
Post by Andrei Alexandrescu
Post by Nick Sabalausky
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 ;)
auto s = ["abc", "a", "xz"];
auto m = s.argmin!((x) => x.length);
People in the audience were quite pleasantly surprised to figure that
although there's no mention of a type, that code is all the compiler
needs to figure there's a lambda that takes a string and returns an
unsigned integer etc.
Exactly. And what many people (depressingly) don't realize, is
that dynamic typing (or OO boxing) is NOT needed to achieve that.

I was actually impressed with that slide, too, but for a different
reason: I've come across need for a function like argmin on occasion,
but I didn't know it existed (Don't recall if it was actually in D, may
have been another language I was using). That really is a fantastically
useful function.
Jens Mueller
2012-07-22 03:06:14 UTC
Permalink
Post by Nick Sabalausky
On Sat, 21 Jul 2012 18:24:04 -0400
Post by Andrei Alexandrescu
Post by Nick Sabalausky
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 ;)
auto s = ["abc", "a", "xz"];
auto m = s.argmin!((x) => x.length);
People in the audience were quite pleasantly surprised to figure that
although there's no mention of a type, that code is all the compiler
needs to figure there's a lambda that takes a string and returns an
unsigned integer etc.
Exactly. And what many people (depressingly) don't realize, is
that dynamic typing (or OO boxing) is NOT needed to achieve that.
I was actually impressed with that slide, too, but for a different
reason: I've come across need for a function like argmin on occasion,
but I didn't know it existed (Don't recall if it was actually in D, may
have been another language I was using). That really is a fantastically
useful function.
Where is argmin defined? I couldn't find it.

Jens
monarch_dodra
2012-07-22 15:13:20 UTC
Permalink
Post by Jens Mueller
Where is argmin defined? I couldn't find it.
Jens
Argmin don't exist, but it could, and that's what counts. The
important thing in these slides is proof of concept, rather than
actual code snippets.

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

Anyways, this gets you the same result:

auto m = s.minPos!((a, b) => a.length < b.length).front;
David Nadlinger
2012-07-22 16:32:11 UTC
Permalink
Post by Jens Mueller
Where is argmin defined? I couldn't find it.
On the slide before that? ;)

David
Andrei Alexandrescu
2012-07-22 21:10:07 UTC
Permalink
Post by David Nadlinger
Post by Jens Mueller
Where is argmin defined? I couldn't find it.
On the slide before that? ;)
I think argmin is intuitive, popular, and useful enough to warrant a
presence in std.algorithm. Would anyone want to do the honors?


Thanks,

Andrei
monarch_dodra
2012-07-23 06:39:09 UTC
Permalink
On Sunday, 22 July 2012 at 21:10:08 UTC, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by David Nadlinger
Post by Jens Mueller
Where is argmin defined? I couldn't find it.
On the slide before that? ;)
I think argmin is intuitive, popular, and useful enough to
warrant a presence in std.algorithm. Would anyone want to do
the honors?
Thanks,
Andrei
Are you asking for the _actual_ argmin as defined in the paper?

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

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

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

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

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

I actually _just_ rewrote these two methods (they are in my pull
requests). I'm on it if you you like the idea of being able to
call these functions with a unary predicated (I do): It sure
beats writing "(a, b) => pred(a) < pred(b)" when you could just
write "a => pred(a)"
Jens Mueller
2012-07-24 07:58:45 UTC
Permalink
Post by David Nadlinger
Post by Jens Mueller
Where is argmin defined? I couldn't find it.
On the slide before that? ;)
:)

Jens
Paulo Pinto
2012-07-22 18:24:19 UTC
Permalink
Post by Nick Sabalausky
On Sat, 21 Jul 2012 23:14:12 +0200
Post by Stuart
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.
Post by Nick Sabalausky
Post by Stuart
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.
Post by Nick Sabalausky
For example, I'm using the IwGame C++ library
( http://www.drmop.com/index.php/iwgame-engine/ ) and fucking *EVERY*
type name is prefixed with "CIwGame...". And anything from the
underlying Marmalade starts with "CIw..." so basic vectors are
named convoluted shit like "CIwFVec2". Of course, this is on top of the
fact that until C++11 becomes more widespread there isn't a damn bit of
type inference anywhere, so those horrific full names have to be used
EVERYWHERE. With a proper module system like D's, there'd be no
problem with names like "ImageActor" and "FVec2" instead of
"CIwGameImageActor" and "CIwFVec2", because conflicts could be easily
detected and dealt with.
And of course the other real obvious benefit of killing #include: None
of that separate cpp/h file bullshit.
C++ is living in the 70's. It should have a mascot wearing a leisure
suit.
Very true.

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

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

--
Paulo
Nick Sabalausky
2012-07-22 19:28:19 UTC
Permalink
On Sun, 22 Jul 2012 20:24:19 +0200
Post by Paulo Pinto
Post by Nick Sabalausky
On Sat, 21 Jul 2012 23:14:12 +0200
Post by Stuart
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.
Paulo Pinto
2012-07-22 21:15:06 UTC
Permalink
Post by Nick Sabalausky
On Sun, 22 Jul 2012 20:24:19 +0200
Post by Paulo Pinto
Post by Nick Sabalausky
On Sat, 21 Jul 2012 23:14:12 +0200
Post by Stuart
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
Nick Sabalausky
2012-07-23 04:50:50 UTC
Permalink
On Sun, 22 Jul 2012 23:15:06 +0200
Post by Paulo Pinto
Post by Nick Sabalausky
On Sun, 22 Jul 2012 20:24:19 +0200
Post by Paulo Pinto
Post by Nick Sabalausky
On Sat, 21 Jul 2012 23:14:12 +0200
Post by Stuart
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.
Post by Paulo Pinto
When things go wrong, then some of us need to play fireman to bring
the project back into safe waters, but hey at least on the official
expenses, the project is still "cheap".
--
Paulo
Nick Sabalausky
2012-07-24 02:00:24 UTC
Permalink
On Sun, 22 Jul 2012 20:24:19 +0200
Post by Paulo Pinto
Post by Nick Sabalausky
On Sat, 21 Jul 2012 23:14:12 +0200
Post by Stuart
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?
Post by Paulo Pinto
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!
Post by Paulo Pinto
What I hate in Java is the abuse of annotations to avoid introducing
Heh, sounds vaguely similar to another language I've heard of...Hmm,
what was it called...? Not C...Something after that... ;)

I never actually stuck around in Java long enough to see the annotation
stuff (though I've heard about it). I think 1.3 or 1.4 was about when I
fled.
H. S. Teoh
2012-07-24 02:52:53 UTC
Permalink
Post by Nick Sabalausky
On Sun, 22 Jul 2012 20:24:19 +0200
[...]
Post by Nick Sabalausky
Post by Paulo Pinto
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"...
Chris NS
2012-07-24 06:40:13 UTC
Permalink
Post by H. S. Teoh
Reminds of a certain individual who shall remain unnamed, with
whom I
argued about why he should *not* implement IPv6 prefix checking
by
converting the address and prefixes to strings and then using
strncmp()... Truly boggles the mind.
I'm reminded of a close friend of mine... once he was asked to
review some code, after the sole author had spent a few weeks on
it. I was lucky (?) enough to be in the room to hear him
actually say: "That's... cute. Not *wise* but cute. Do you
remember what functions are?" I don't recall there being a
response.

-- Chris NS
Nick Sabalausky
2012-07-24 07:33:18 UTC
Permalink
On Tue, 24 Jul 2012 08:40:13 +0200
Post by Chris NS
Post by H. S. Teoh
Reminds of a certain individual who shall remain unnamed, with
whom I
argued about why he should *not* implement IPv6 prefix checking
by
converting the address and prefixes to strings and then using
strncmp()... Truly boggles the mind.
I'm reminded of a close friend of mine... once he was asked to
review some code, after the sole author had spent a few weeks on
it. I was lucky (?) enough to be in the room to hear him
actually say: "That's... cute. Not *wise* but cute. Do you
remember what functions are?" I don't recall there being a
response.
That's...hilarious. Disturbing, but hilarious.
Era Scarecrow
2012-07-24 22:38:06 UTC
Permalink
Post by Chris NS
Post by H. S. Teoh
Reminds of a certain individual who shall remain unnamed, with
whom I argued about why he should *not* implement IPv6 prefix
checking by converting the address and prefixes to strings and
then using strncmp()... Truly boggles the mind.
I'm reminded of a close friend of mine... once he was asked to
review some code, after the sole author had spent a few weeks
on it. I was lucky (?) enough to be in the room to hear him
actually say: "That's... cute. Not *wise* but cute. Do you
remember what functions are?" I don't recall there being a
response.
I remember seeing some stupid production code that was used at a
company I worked at for a while. They were developing jsp pages
as part of their training until they got sections hired out
(sorta lowest bidder thing, where you would go to them rather
than export work over seas).

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

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

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

return ID;
}
[/code]

It didn't help the company's Java class that they taught didn't
go into low level operations like And and Or and bit shifting. I
ended up rewriting it, then they wanted it 'super documented'
because they couldn't understand what > were for. (I think there
was more documentation commenting low level explanations of what
it was doing than actual code).
Era Scarecrow
2012-07-24 22:48:44 UTC
Permalink
documented' because they couldn't understand what > were for.
Sorry my filter stripped that out. They couldn't understand what
<< and >> were for.
Andrei Alexandrescu
2012-07-24 22:57:56 UTC
Permalink
documented' because they couldn't understand what > were for.
Sorry my filter stripped that out. They couldn't understand what << and
Post by Era Scarecrow
were for.
x >>= 2; // if x much greater than 2, assign 2 to it

Andrei
Chris NS
2012-07-25 01:52:28 UTC
Permalink
Post by Era Scarecrow
[code]
//remember, java
String toGuid(byte input[16]) {
String ID = "{";
if (Integer.toHexString(input[5]).length < 2)
ID = ID + "0";
ID = ID + Integer.toHexString(input[5]);
if (Integer.toHexString(input[6]).length < 2)
ID = ID + "0";
ID = ID + Integer.toHexString(input[6]);
//repeat for other 14 bytes, plus adding dashes and ending brace
return ID;
}
[/code]
I just died a little inside...

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

Erm, so that I'm not completely off-topic: I know where D has
truly gone wrong. There's just too many damn semi-colons!
Nick Sabalausky
2012-07-25 02:10:57 UTC
Permalink
On Wed, 25 Jul 2012 03:52:28 +0200
Post by Chris NS
Erm, so that I'm not completely off-topic: I know where D has
truly gone wrong. There's just too many damn semi-colons!
Nah, I know exactly where it went wrong.

Albuquerque.

Shoulda gone left.
Stuart
2012-07-25 04:21:22 UTC
Permalink
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?

Stuart
2012-07-23 12:49:58 UTC
Permalink
Post by Nick Sabalausky
C++ is living in the 70's.
Precisely what I have been thinking. It's a loose wrapper around
assembly, nothing more. Certainly not the "high-level language"
it's touted as.
Paulo Pinto
2012-07-23 15:56:39 UTC
Permalink
Post by Stuart
Post by Nick Sabalausky
C++ is living in the 70's.
Precisely what I have been thinking. It's a loose wrapper around
assembly, nothing more. Certainly not the "high-level language"
it's touted as.
Only due to the lack of modules.

Everything else is a pretty modern language I would say.

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

--
Paulo
Stuart
2012-07-23 20:51:19 UTC
Permalink
Post by Paulo Pinto
On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky
Post by Nick Sabalausky
C++ is living in the 70's.
Precisely what I have been thinking. It's a loose wrapper
around
assembly, nothing more. Certainly not the "high-level language"
it's touted as.
Only due to the lack of modules.
Everything else is a pretty modern language I would say.
Hardly. No RTTI. No GC. No properties. No events. No closures. No
extension methods. No interfaces. No writable references.

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

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

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

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

auto (c, d) = fn();

Saves us having to create a struct for every goddamn little
function; or using tuples directly, which means we have to refer
to variables like .value1 and .value2 instead of something
meaningful.
Stuart
2012-07-23 20:55:45 UTC
Permalink
Post by Stuart
Incidentally, it'd be really handy to have anonymous tuples in
D.
Or perhaps I should've said "named tuples". I dunno what the
correct term might be. All I know is, I've only seen it in one or
two obscure languages, and I've always wished .NET had it.
Simen Kjaeraas
2012-07-23 21:14:05 UTC
Permalink
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
Nick Sabalausky
2012-07-23 21:19:09 UTC
Permalink
On Mon, 23 Jul 2012 22:51:19 +0200
Post by Stuart
Post by Paulo Pinto
On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky
Post by Nick Sabalausky
C++ is living in the 70's.
Precisely what I have been thinking. It's a loose wrapper
around
assembly, nothing more. Certainly not the "high-level language"
it's touted as.
Only due to the lack of modules.
Everything else is a pretty modern language I would say.
Hardly. No RTTI. No GC. No properties. No events. No closures. No
extension methods. No interfaces. No writable references.
Null-terminated strings. Preprocessor. No reflection. Effectively
undefined sizes for primitive types. Undefined behavior galore. Neither
default initialization nor enforced initialization before variable
usage. No reference types (Foo& isn't what I mean). Horrendous type
syntax for mixed arrays/ptrs or functions ptrs, etc. No forward
references (or at least very limited). And a grammar that forces
compilation to be very, very slow.

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

And the fact that static analysis tools are as super useful as they are
is plenty proof alone that the language itself is WAAAY behind the
curve.
Nick Sabalausky
2012-07-23 21:27:24 UTC
Permalink
On Mon, 23 Jul 2012 17:19:09 -0400
Post by Nick Sabalausky
On Mon, 23 Jul 2012 22:51:19 +0200
Post by Stuart
Post by Paulo Pinto
Post by Stuart
Post by Nick Sabalausky
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:

Paulo Pinto
2012-07-24 07:21:54 UTC
Permalink
Post by Nick Sabalausky
On Mon, 23 Jul 2012 22:51:19 +0200
Post by Stuart
Post by Paulo Pinto
On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky
Post by Nick Sabalausky
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.
Post by Nick Sabalausky
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
Andrei Alexandrescu
2012-07-24 02:21:18 UTC
Permalink
Post by Simen Kjaeraas
Saves us having to create a struct for every goddamn little function;
or using tuples directly, which means we have to refer to variables
like .value1 and .value2 instead of something meaningful.
You mean like this?
Tuple!(float, "x", float, "y") bar() {
return typeof(return)( 0.0, 0.0 );
}
auto xCoord = bar().x;
I dislike the typeof(return) in there, as assignment between tuples with
and without named fields works perfectly. Bring me the sky, Walter?
We could make

return tuple(0.0, 0.0);

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


Andrei
Simen Kjaeraas
2012-07-24 09:03:16 UTC
Permalink
On Tue, 24 Jul 2012 04:21:18 +0200, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Simen Kjaeraas
Tuple!(float, "x", float, "y") bar() {
return typeof(return)( 0.0, 0.0 );
}
[snip]
Post by Andrei Alexandrescu
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
Jonathan M Davis
2012-07-24 11:00:44 UTC
Permalink
Post by Simen Kjaeraas
On Tue, 24 Jul 2012 04:21:18 +0200, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Simen Kjaeraas
Tuple!(float, "x", float, "y") bar() {
return typeof(return)( 0.0, 0.0 );
}
[snip]
Post by Andrei Alexandrescu
We could make
return tuple(0.0, 0.0);
to work. I can't imagine a scenario in which this relaxation would cause
a bug.
I would argue it should work, for the exact reasons outline above. And as
you say, it should cause no bugs.
But can it be made to work in current D, as a library solution? Or do you
mean the language should be changed? (This looks to me a lot like the old
opImplicitCast)
That's what alias this is for.

- Jonathan M Davis
Simen Kjaeraas
2012-07-24 11:24:28 UTC
Permalink
On Tue, 24 Jul 2012 13:00:44 +0200, Jonathan M Davis <jmdavisProg at gmx.com>
Post by Jonathan M Davis
Post by Simen Kjaeraas
On Tue, 24 Jul 2012 04:21:18 +0200, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Simen Kjaeraas
Tuple!(float, "x", float, "y") bar() {
return typeof(return)( 0.0, 0.0 );
}
[snip]
Post by Andrei Alexandrescu
We could make
return tuple(0.0, 0.0);
to work. I can't imagine a scenario in which this relaxation would
cause
Post by Andrei Alexandrescu
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
Andrei Alexandrescu
2012-07-24 13:49:46 UTC
Permalink
Post by Simen Kjaeraas
On Tue, 24 Jul 2012 04:21:18 +0200, Andrei Alexandrescu
Post by Andrei Alexandrescu
Post by Simen Kjaeraas
Tuple!(float, "x", float, "y") bar() {
return typeof(return)( 0.0, 0.0 );
}
[snip]
Post by Andrei Alexandrescu
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
Paulo Pinto
2012-07-24 07:05:29 UTC
Permalink
Post by Paulo Pinto
Post by Stuart
Post by Nick Sabalausky
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
Stuart
2012-07-24 14:42:19 UTC
Permalink
On Mon, 23 Jul 2012 22:51:19 +0200, Stuart <stugol at gmx.com>
Post by Stuart
Saves us having to create a struct for every goddamn little
function; or using tuples directly, which means we have to
refer to variables like .value1 and .value2 instead of
something meaningful.
You mean like this?
Tuple!(float, "x", float, "y") bar() {
return typeof(return)( 0.0, 0.0 );
}
auto xCoord = bar().x;
You mean it's already supported? Nice! Although, It'd still be
awesome to be able to do things like:

auto a,b = bar();

auto c,_ = bar();
Regan Heath
2012-07-24 14:49:14 UTC
Permalink
Post by Simen Kjaeraas
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
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/
H. S. Teoh
2012-07-24 15:00:14 UTC
Permalink
[...]
Post by Regan Heath
Post by Stuart
You mean it's already supported? Nice! Although, It'd still be
auto a,b = bar();
auto c,_ = bar();
Sadly the comma operator (inherited from C/C++) blocks this syntax.
[...]

The comma operator must go.

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


T
--
To provoke is to call someone stupid; to argue is to call each other stupid.
Andrej Mitrovic
2012-07-24 16:58:15 UTC
Permalink
Post by H. S. Teoh
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.
Stuart
2012-07-24 14:57:08 UTC
Permalink
On Tue, 24 Jul 2012 15:42:19 +0100, Stuart <stugol at gmx.com>
Post by Stuart
You mean it's already supported? Nice! Although, It'd still be
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?
Simen Kjaeraas
2012-07-24 14:59:25 UTC
Permalink
Post by Stuart
You mean it's already supported? Nice!
That's what I mean. :p
Post by Stuart
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
Russel Winder
2012-07-24 17:02:07 UTC
Permalink
On Tue, 2012-07-24 at 16:59 +0200, Simen Kjaeraas wrote:
[?]
Post by Simen Kjaeraas
T fib(T = int)(int n, T a = 0, T b = 1) {
while ( n-- ) {
TypeTuple!(a,b) = 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 ] ;
}

?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120724/d74d6044/attachment.pgp>
Simen Kjaeraas
2012-07-24 18:07:53 UTC
Permalink
On Tue, 24 Jul 2012 19:02:07 +0200, Russel Winder <russel at winder.org.uk>
Post by Russel Winder
[?]
Post by Simen Kjaeraas
T fib(T = int)(int n, T a = 0, T b = 1) {
while ( n-- ) {
TypeTuple!(a,b) = tuple(b, a +b);
}
return a;
}
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 = int)(int n, T a = to!T(0), T b = to!T(1)) {
while ( n-- ) {
TypeTuple!(a,b) = tuple(b, a +b);
}
return a;
}

Now, try asking each of these for fib!BigInt(1_000_000). :p
--
Simen
Ali Çehreli
2012-07-24 15:46:51 UTC
Permalink
You mean it's already supported? Nice! Although, It'd still be awesome
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
David Piepgrass
2012-07-19 22:32:03 UTC
Permalink
Post by Alex Rønne Petersen
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.
Nick Sabalausky
2012-07-19 22:49:34 UTC
Permalink
On Fri, 20 Jul 2012 00:32:03 +0200
Post by David Piepgrass
Post by Alex Rønne Petersen
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.
Faux Amis
2012-07-20 00:45:52 UTC
Permalink
Post by Nick Sabalausky
On Fri, 20 Jul 2012 00:32:03 +0200
Post by David Piepgrass
Post by Alex Rønne Petersen
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.
vote++
Damian
2012-07-20 01:35:26 UTC
Permalink
Post by David Piepgrass
Post by Alex Rønne Petersen
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?
Jeff Nowakowski
2012-07-20 05:55:46 UTC
Permalink
Post by Damian
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 at digitalmars.com
http://forum.dlang.org/post/ha37cf$4l2$1 at digitalmars.com
http://forum.dlang.org/post/i4mlee$5a2$1 at digitalmars.com
Jacob Carlborg
2012-07-20 06:40:17 UTC
Permalink
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
renoX
2012-07-20 08:17:02 UTC
Permalink
Post by Jacob Carlborg
Post by David Piepgrass
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
Era Scarecrow
2012-07-20 22:02:58 UTC
Permalink
Post by renoX
Post by Jacob Carlborg
Post by David Piepgrass
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]
Timon Gehr
2012-07-19 14:52:04 UTC
Permalink
Hi,
I'm an occasional lurker on the D forums just to see where the language
is going,but I'm a little puzzled. In another thread I found this code
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);
I don't understand whats going on here. Int array is getting sorted,
then Uniqued, then what?
Then it is mapped to string representations, just as the code says.
What type is x?
'int', if you like.
What kind of operator is =>,
Lambda function. It is the same as (...){ return ...; }, just without
the noise.
why is x.to!string allowed template specialization should say
x.to!(string),
Why should it say that?
which leads me to think that there are multiple syntaxes
for things
There always are 'multiple syntaxes for things' if writing code should
be productive and validating code for static correctness should be
decidable.
(why I hate dynamic languages, love compiled)
This is unrelated to dynamic vs. compiled. (those two terms do not
contradict each other anyway.)
On another note, (copied from wikipedia)
foreach(item; set) {
// do something to item
}
what's with the lax syntax being allowed?
s/lax/to the point/
Shouldn't it be at least specified "auto item"?
Why on earth would that be the case?
I'm sorry I don't mean to be a criticizer, but it seems to me that D is
trying to be a dynamic-like compiled language way too hard.
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Petr Janda
2012-07-19 15:03:54 UTC
Permalink
Post by Timon Gehr
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if "eliminating noise" equals to making things harder to
understand.

When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
Timon Gehr
2012-07-19 15:14:42 UTC
Permalink
Post by Timon Gehr
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if "eliminating noise" equals to making things harder to understand.
Harder to understand to whom? Optimizing stuff for beginners usually
makes it a PITA to work with.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
That expression looks eg. like this in Haskell:
\x->x

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

I agree that there is some non-uniformity. It should be possible to use
=> in named function declarations.
Brad Anderson
2012-07-19 15:20:44 UTC
Permalink
Post by Timon Gehr
It's just syntax. Eliminating syntax noise is fine. Code should look
Post by Timon Gehr
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120719/7a5e2ada/attachment.html>
Brad Anderson
2012-07-19 15:30:57 UTC
Permalink
Post by Brad Anderson
Post by Timon Gehr
It's just syntax. Eliminating syntax noise is fine. Code should look
Post by Timon Gehr
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
auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));
Ehm...forgot the return:

auto r = map!((int x) { return to!(string)(x); })(uniq(sort([5, 3, 5, 6,
8])));
Post by Brad Anderson
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120719/73ba372b/attachment.html>
Timon Gehr
2012-07-19 15:31:29 UTC
Permalink
On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr at gmail.com
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
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
Ali Çehreli
2012-07-19 15:58:52 UTC
Permalink
Post by Timon Gehr
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if "eliminating noise" equals to making things harder to understand.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
Others beat me to it but the anonymous function can be written more
completely as

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

(Or 'delegate' depending on the situation.)

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

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

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

a_long_expression.take(2)

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

Ali
Jacob Carlborg
2012-07-19 20:45:59 UTC
Permalink
Post by Timon Gehr
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Not if "eliminating noise" equals to making things harder to understand.
When you say (int x) { return x; } it's clear about what it is, a
_function_ without name.
It's equally clear when you see: =>.
--
/Jacob Carlborg
David Nadlinger
2012-07-19 15:35:50 UTC
Permalink
Post by Timon Gehr
Post by Petr Janda
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/
Post by Petr Janda
Shouldn't it be at least specified "auto item"?
Why on earth would that be the case?
Post by Petr Janda
I'm sorry I don't mean to be a criticizer, but it seems to me
that D is
trying to be a dynamic-like compiled language way too hard.
It's just syntax. Eliminating syntax noise is fine. Code should look
like what it does.
Additionally, allowing to omit auto is actually consistent with
the rest of the language, which also allows you to not explicitly
write it if the code doesn't become ambiguous (for example, you
don't need to do "immutable auto").

David
Bernard Helyer
2012-07-19 21:03:25 UTC
Permalink
What the _fuck_ guys? How did you get this many posts on what is
essentially "this looks weird and I can't be fucked reading the
documentation?".
FeepingCreature
2012-07-19 21:11:24 UTC
Permalink
What the _fuck_ guys? How did you get this many posts on what is essentially "this looks weird and I can't be fucked reading the documentation?".
In other words, see subject.
Chad J
2012-07-20 01:53:50 UTC
Permalink
On 07/19/2012 10:21 AM, Petr Janda wrote:
...
I think the other points have been adequately covered.
...
Post by Petr Janda
auto r = [5, 3, 5, 6, 8].sort.uniq.map!(x => x.to!string);
...
Post by Petr Janda
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. ;)
Loading...