Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Sat, 31 May 2014 19:27:08 -0400, Walter Bright
wrote:
On 5/30/2014 5:37 AM, Steven Schveighoffer wrote:
On Thu, 29 May 2014 21:15:21 -0400, deadalnix
wrote:
On Thursday, 29 May 2014 at 19:06:15 UTC, Steven Schveighoffer
wrote:
Static if is certainly NOT an attribute, it doesn't make any sense.
Well... it sorta does. static if does not introduce a new scope, even
with
{}, and this only happens with attributes.
-Steve
in which case
static if(cond) {
immutable:
}
int x;
should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.
Ugh, that is really bad. It shouldn't do that. Is that intentional?
Yes. Semantic scope and lexical scope are different things. The ':'
thing applies to the remaining statements in the lexical scope. 'static
if' does not create a new semantic scope, even though the { } suggests
it does.
deadalnix's suggestion, at least to me, was that currently the compiler
would attribute immutable to int x. Testing, I see it does not. Maybe I
misinterpreted the implication. The statement "current behavior is not
consistent with attribute" seems wrong then.
There have been several suggestions to make 'static if' apply
independently of the rest of the grammar, i.e. allow things like:
int static if (cond) * else [ ] foo; // conditionally make foo a
pointer or an array
I think we can agree that looks awful, but it is the same thing as
suggesting that the 'immutable:' above extend outside of its lexical
scope.
I agree, I think we are arguing the same thing.
static if seems like an attribute in how it scopes things.
-Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Sat, 31 May 2014 18:56:17 -0400, Timon Gehr wrote:
On 05/30/2014 02:37 PM, Steven Schveighoffer wrote:
in which case
static if(cond) {
immutable:
}
int x;
should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.
Ugh, that is really bad. It shouldn't do that. Is that intentional?
enum cond=true;
static if(cond){
immutable:
}
int x;
static assert(is(typeof(x)==int));
What is the problem?
OK, so the original premise is not true? I was assuming deadalnix was
saying x would be immutable.
-Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Saturday, 31 May 2014 at 18:12:12 UTC, John Colvin wrote: I think you've misunderstood him. You say in the article "D does not provide decltype", he is saying that this is misleading: D does but it's just called typeof instead. No, I understood and had adjusted the article with "D does not provide a decltype as typeof already does the same thing;" I think this is ok since I'd already made use of typeof to assert expected types without explanation. Anyway, I've got Part 6 out there and it looks like I'll have 2 more short parts which follow.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/30/2014 5:37 AM, Steven Schveighoffer wrote:
On Thu, 29 May 2014 21:15:21 -0400, deadalnix wrote:
On Thursday, 29 May 2014 at 19:06:15 UTC, Steven Schveighoffer
wrote:
Static if is certainly NOT an attribute, it doesn't make any sense.
Well... it sorta does. static if does not introduce a new scope, even with
{}, and this only happens with attributes.
-Steve
in which case
static if(cond) {
immutable:
}
int x;
should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.
Ugh, that is really bad. It shouldn't do that. Is that intentional?
Yes. Semantic scope and lexical scope are different things. The ':' thing
applies to the remaining statements in the lexical scope. 'static if' does not
create a new semantic scope, even though the { } suggests it does.
There have been several suggestions to make 'static if' apply independently of
the rest of the grammar, i.e. allow things like:
int static if (cond) * else [ ] foo; // conditionally make foo a pointer or
an array
I think we can agree that looks awful, but it is the same thing as suggesting
that the 'immutable:' above extend outside of its lexical scope.
You might ask "why is semantic scope different from lexical scope" and the
reason is simply that 'static if' would not be very useful if that were the case.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 05/30/2014 02:37 PM, Steven Schveighoffer wrote:
in which case
static if(cond) {
immutable:
}
int x;
should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.
Ugh, that is really bad. It shouldn't do that. Is that intentional?
enum cond=true;
static if(cond){
immutable:
}
int x;
static assert(is(typeof(x)==int));
What is the problem?
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Saturday, 31 May 2014 at 17:49:18 UTC, Jesse Phillips wrote: On Saturday, 31 May 2014 at 07:32:22 UTC, Kagamin wrote: What do you mean "D does not provide a decltype"? typeof(cx) my_cx2 = cx; I'll blame this on my poor knowledge of C++, at this time typeof in C++ does not appear to compile, in the way I'm trying to use it. I thought using typeof in C++ would result in the same answer as the deduction auto provides. From that point of view, there is no need for decltype, because typeof already gives you the actual type in D (which will be the same as the type at declaration). I think you've misunderstood him. You say in the article "D does not provide decltype", he is saying that this is misleading: D does but it's just called typeof instead.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Saturday, 31 May 2014 at 07:32:22 UTC, Kagamin wrote: What do you mean "D does not provide a decltype"? typeof(cx) my_cx2 = cx; I'll blame this on my poor knowledge of C++, at this time typeof in C++ does not appear to compile, in the way I'm trying to use it. I thought using typeof in C++ would result in the same answer as the deduction auto provides. From that point of view, there is no need for decltype, because typeof already gives you the actual type in D (which will be the same as the type at declaration).
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Friday, 30 May 2014 at 04:21:18 UTC, Jesse Phillips wrote: I've got two posts complete[1]. Since C++ and D are exactly the same for the majority of the code I'm only showing D and talk of C++'s choice. While the rules governing D's behavior are fairly simple I feel that I've expanded on the content enough to provide useful information beyond fixing C++'s problems. 1. http://he-the-great.livejournal.com/52333.html What do you mean "D does not provide a decltype"? typeof(cx) my_cx2 = cx;
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/14, 9:21 PM, Jesse Phillips wrote: On Wednesday, 28 May 2014 at 07:21:56 UTC, dennis luehring wrote: woudl be nice to have some sort of example by example comparison or as an extension to the page http://dlang.org/cpptod.html I've got two posts complete[1]. Since C++ and D are exactly the same for the majority of the code I'm only showing D and talk of C++'s choice. While the rules governing D's behavior are fairly simple I feel that I've expanded on the content enough to provide useful information beyond fixing C++'s problems. 1. http://he-the-great.livejournal.com/52333.html http://www.reddit.com/r/programming/comments/26vy2i/comparing_scott_meyers_talk_examples_in_c_and_d/ Andrei
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Friday, 30 May 2014 at 11:31:18 UTC, safety0ff wrote: On Friday, 30 May 2014 at 04:21:18 UTC, Jesse Phillips wrote: 1. http://he-the-great.livejournal.com/52333.html Note that in the following code: import core.memory : GC; int* pxprime = cast(int*)GC.malloc(int.sizeof); version(none) assert(pxprime); // possibly zero GC.malloc currently doesn't initialize the memory if NO_SCAN is specified as attribute. I expect malloc to not initialize ever, that was the point. Initialization can be done with calloc. Also, I don't understand why half of your asserts have version(none) (it's distracting.) I can't guarantee the assert to pass, as the comment mentions it is possibly zero, which would cause failure. Also note that you're not dereferencing pxprime, I'm not sure if its intentional. Thanks, was intending to dereference. Thank you for feedback.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Friday, 30 May 2014 at 10:56:30 UTC, Andrei Alexandrescu wrote: Nice! I'll post it tomorrow on reddit and friends. You have an unmatched brace after "assert(a2[].all!(x => x == 0));". Andrei Actually a bunch of unmatched braces (formatter eats the closing one?) and at least one ";;" instead of ";". -- Andrei It is not unmatched, the whole article is one big program (with the exception of the conclusion), the final brace is at the end: static int[100] a3; assert(a3[].all!(x => x == 0)); } Though the ;; is just an accident.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 21:15:21 -0400, deadalnix wrote:
On Thursday, 29 May 2014 at 19:06:15 UTC, Steven Schveighoffer
wrote:
Static if is certainly NOT an attribute, it doesn't make any sense.
Well... it sorta does. static if does not introduce a new scope, even
with {}, and this only happens with attributes.
-Steve
in which case
static if(cond) {
immutable:
}
int x;
should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.
Ugh, that is really bad. It shouldn't do that. Is that intentional?
-Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Friday, 30 May 2014 at 04:21:18 UTC, Jesse Phillips wrote: 1. http://he-the-great.livejournal.com/52333.html Note that in the following code: import core.memory : GC; int* pxprime = cast(int*)GC.malloc(int.sizeof); version(none) assert(pxprime); // possibly zero GC.malloc currently doesn't initialize the memory if NO_SCAN is specified as attribute. Also, I don't understand why half of your asserts have version(none) (it's distracting.) Also note that you're not dereferencing pxprime, I'm not sure if its intentional.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/30/14, 3:53 AM, Andrei Alexandrescu wrote: On 5/29/14, 9:21 PM, Jesse Phillips wrote: On Wednesday, 28 May 2014 at 07:21:56 UTC, dennis luehring wrote: woudl be nice to have some sort of example by example comparison or as an extension to the page http://dlang.org/cpptod.html I've got two posts complete[1]. Since C++ and D are exactly the same for the majority of the code I'm only showing D and talk of C++'s choice. While the rules governing D's behavior are fairly simple I feel that I've expanded on the content enough to provide useful information beyond fixing C++'s problems. 1. http://he-the-great.livejournal.com/52333.html Nice! I'll post it tomorrow on reddit and friends. You have an unmatched brace after "assert(a2[].all!(x => x == 0));". Andrei Actually a bunch of unmatched braces (formatter eats the closing one?) and at least one ";;" instead of ";". -- Andrei
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/14, 9:21 PM, Jesse Phillips wrote: On Wednesday, 28 May 2014 at 07:21:56 UTC, dennis luehring wrote: woudl be nice to have some sort of example by example comparison or as an extension to the page http://dlang.org/cpptod.html I've got two posts complete[1]. Since C++ and D are exactly the same for the majority of the code I'm only showing D and talk of C++'s choice. While the rules governing D's behavior are fairly simple I feel that I've expanded on the content enough to provide useful information beyond fixing C++'s problems. 1. http://he-the-great.livejournal.com/52333.html Nice! I'll post it tomorrow on reddit and friends. You have an unmatched brace after "assert(a2[].all!(x => x == 0));". Andrei
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 20:40:10 +0100, Walter Bright wrote: On 5/29/2014 11:25 AM, Dmitry Olshansky wrote: Agreed. The simple dream of automatically decoding UTF and staying "Unicode correct" is a failure. Yes. Attempting to hide the fact that strings are UTF-8 is just doomed. It's like trying to pretend that floating point does not do rounding. It's far more practical to embrace what it is and deal with it. Yes, D programmers will need to understand what UTF-8 is. I don't see any way around that. And it's the right choice. 4 of the 7 billion people in the world today are in Asia and by 2100 80% of the worlds population will be in Asia and Africa. http://bigthink.com/neurobonkers/it-is-not-about-political-views-or-ideologies-it-is-blunt-facts-which-are-not-known R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tue, 27 May 2014 22:40:00 +0100, Walter Bright wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. I've always assumed some sort of sentence finishing laziness on their part. As in, "I could care less, but it would be pretty hard to do so" or something like that. R
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 07:21:56 UTC, dennis luehring wrote: woudl be nice to have some sort of example by example comparison or as an extension to the page http://dlang.org/cpptod.html I've got two posts complete[1]. Since C++ and D are exactly the same for the majority of the code I'm only showing D and talk of C++'s choice. While the rules governing D's behavior are fairly simple I feel that I've expanded on the content enough to provide useful information beyond fixing C++'s problems. 1. http://he-the-great.livejournal.com/52333.html
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 19:06:15 UTC, Steven Schveighoffer
wrote:
Static if is certainly NOT an attribute, it doesn't make any
sense.
Well... it sorta does. static if does not introduce a new
scope, even with {}, and this only happens with attributes.
-Steve
in which case
static if(cond) {
immutable:
}
int x;
should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/2014 3:19 PM, Dmitry Olshansky wrote:
With the reason being?
The same reason you might want to put:
@nogc:
...
at the beginning of a source module instead of:
@nogc: {
...
}
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
29-May-2014 23:29, Walter Bright пишет:
On 5/29/2014 11:11 AM, Dmitry Olshansky wrote:
Static if is certainly NOT an attribute, it doesn't make any sense.
Yes, it does make sense. It was not an accident that the frontend treats
it as it does, the code to do it was deliberately put there.
With the reason being? I could deliberately put any code anywhere.
The attributes are all designed to affect a block of code - so are
version/debug/staticif - why should they be different?
Because they are different constructs?
static if models if-else, so does the version statement BTW (else
version). debug doesn't model if-else. I could see *some* common ground
between them.
safe/pure/nogc etc. are different in that they all affect symbols and
have no conditional clause, *some* of them even have counterparts
(consistency? - I do not see any).
This for instance doesn't work:
static if(1):
int blah;
else
{}
while this does:
static if(1)
int blah;
else:
Does it make any sense? To me - no, not at all.
Not every decision must be taken on the grounds of making some code in
compiler more straightforward.
After all C's #include was so simple to implement and we know where this
way leads to.
--
Dmitry Olshansky
Re: [OT] Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/2014 9:14 AM, Steven Schveighoffer wrote: On Thu, 29 May 2014 04:57:14 -0400, Alix Pexton wrote: I couldn't resist looking up this debate, and its quite a fiery one with no clear winner! There is no clear origin to the phrase and equal arguments for and against both forms. If you think I'll let it go you're mad, you got another thing comin' Heh, I see I'm not the only one who's has that playing in their head through this whole conversation ;) Oddly enough, my mind plays it as the Pat Boone cover (from "In a Metal Mood"). His version is surprisingly good.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ https://news.ycombinator.com/newest (search that page, if not found click "More" and search again) https://www.facebook.com/dlang.org/posts/855022447844771 https://twitter.com/D_Programming/status/471330026168651777 Andrei YouTube mirror : http://youtu.be/48kP_Ssg2eY
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/2014 11:25 AM, Dmitry Olshansky wrote: Agreed. The simple dream of automatically decoding UTF and staying "Unicode correct" is a failure. Yes. Attempting to hide the fact that strings are UTF-8 is just doomed. It's like trying to pretend that floating point does not do rounding. It's far more practical to embrace what it is and deal with it. Yes, D programmers will need to understand what UTF-8 is. I don't see any way around that. My proposal for dealing with this, while retaining backwards compatibility, is adding the ranges byCodeunit, byChar, byWchar and byDchar which can be applied to any string arrays or string ranges.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 15:29:31 -0400, Walter Bright wrote: On 5/29/2014 11:11 AM, Dmitry Olshansky wrote: Static if is certainly NOT an attribute, it doesn't make any sense. Yes, it does make sense. It was not an accident that the frontend treats it as it does, the code to do it was deliberately put there. The attributes are all designed to affect a block of code - so are version/debug/staticif - why should they be different? private int x; // ok static if(1) int x; // ok private x = 5; // error static if(1) x = 5; // ok Static if/version/debug can affect both statements and declarations. attributes only apply to declarations. That is the major difference I see between them. Not arguing that it's bad for the syntax to exist, I think it kind of makes sense given that static if does not create a new scope. But they don't behave like normal attributes. -Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 15:24:06 -0400, Dmitry Olshansky wrote: Let it be just a declaration, as simple as that. Attributes affect other declarations in the scope, static if doesn't. Sure it does: private: int a; int b; equivalent to private int a; private int b; static if(x): int a; int b; equivalent to static if(x) int a; static if(x) int b; ;) Yes, I agree static if does not fit the understood meaning of an attribute. And it can apply to statements too, whereas attributes can only apply to declarations (right?). In reality, static if is in a league with version and debug, and they share similarities to both statements and attributes. -Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/2014 11:11 AM, Dmitry Olshansky wrote: Static if is certainly NOT an attribute, it doesn't make any sense. Yes, it does make sense. It was not an accident that the frontend treats it as it does, the code to do it was deliberately put there. The attributes are all designed to affect a block of code - so are version/debug/staticif - why should they be different?
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
29-May-2014 23:06, Steven Schveighoffer пишет:
On Thu, 29 May 2014 14:11:27 -0400, Dmitry Olshansky
wrote:
29-May-2014 04:58, Walter Bright пишет:
On 5/28/2014 5:35 PM, Brian Rogoff wrote:
Could you elaborate? Using some of the examples Brian gave, which ones
do you
think are are mathematically consistent/human inconsistent and which
the inverse?
Off the top of my head:
static if (condition)
else :
... declarations ...
All attributes apply to either:
1. the next statement or declaration
2. { ... }
3. : ...
That case is (3), as static if is set up as an attribute.
Static if is certainly NOT an attribute, it doesn't make any sense.
Well... it sorta does. static if does not introduce a new scope, even
with {}, and this only happens with attributes.
Let it be just a declaration, as simple as that. Attributes affect other
declarations in the scope, static if doesn't.
-Steve
--
Dmitry Olshansky
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 18:52:53 UTC, Brian Schott wrote: On Thursday, 29 May 2014 at 18:12:10 UTC, Dmitry Olshansky wrote: And no, it doesn't matter how the current frontend implements it, because you can argue next to any decisions this way. When issues like this come up the spec is almost always changed to match the DMD front end instead of the other way around. I believe that the result of this policy will be that the D community will need to have Scott Meyers or someone like him to explain some of these issues. :-) It may not be as bad as C++, but is that how we want to measure a language design? "Sure, it looks bad, but it could have been so much worse!" Why are we afraid of breaking code that relied on behavior that was not in the language specification? My guess is that the fear of 'breaking' some users' code is too great right now. That was one of the things I took from Meyers' talk; the D designers still have an opportunity to be bold in introducing changes that make the entire design better (more easily explainable) while in C++ that opportunity has probably passed. That makes it almost impossible to fix accepts-invalid bugs. It's a problem that needs to be addressed. Thanks for your efforts and for continually reminding people. I really liked your lightning talk; it could have followed Meyers' and maybe the right people would have been shamed into action.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 14:11:27 -0400, Dmitry Olshansky
wrote:
29-May-2014 04:58, Walter Bright пишет:
On 5/28/2014 5:35 PM, Brian Rogoff wrote:
Could you elaborate? Using some of the examples Brian gave, which ones
do you
think are are mathematically consistent/human inconsistent and which
the inverse?
Off the top of my head:
static if (condition)
else :
... declarations ...
All attributes apply to either:
1. the next statement or declaration
2. { ... }
3. : ...
That case is (3), as static if is set up as an attribute.
Static if is certainly NOT an attribute, it doesn't make any sense.
Well... it sorta does. static if does not introduce a new scope, even with
{}, and this only happens with attributes.
-Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 18:12:10 UTC, Dmitry Olshansky wrote: And no, it doesn't matter how the current frontend implements it, because you can argue next to any decisions this way. When issues like this come up the spec is almost always changed to match the DMD front end instead of the other way around. Why are we afraid of breaking code that relied on behavior that was not in the language specification? That makes it almost impossible to fix accepts-invalid bugs.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/2014 10:54 AM, Steven Schveighoffer wrote: Has anyone ever considered making the compiler build an 'optimized' init-blitting function instead of just defaulting to memcpy? In other words, the compiler knows at compile time the layout and initialization values of a struct. What about using the compiler and optimizer to create the most optimized, no-runtime-variables function to blit memory? We wouldn't even need compiler help, if we did it with RTInfo. I have, but obviously I haven't done anything about it.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
29-May-2014 02:10, Jonathan M Davis via Digitalmars-d-announce пишет: On Tue, 27 May 2014 06:42:41 -1000 Andrei Alexandrescu via Digitalmars-d-announce wrote: > http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ > > https://news.ycombinator.com/newest (search that page, if not found > click "More" and search again) > > https://www.facebook.com/dlang.org/posts/855022447844771 > > https://twitter.com/D_Programming/status/471330026168651777 Fortunately, for the most part, I think that we've avoided the types of inconsistencies that Scott describes for C++, but we do definitely have some of our own. The ones that come to mind at the moment are: Not talking about other moments, but Unicode kind of caught my eye.. 6. The situation with ranges and string is kind of ugly, with them being treated as ranges of code points. I don't know what the correct solution to this is, since treating them as ranges of code units promotes efficiency but makes code more error-prone, whereas treating them as ranges of graphemes would just cost too much. This is gross oversimplification of the matter. There is no more correct, less correct. Each algorithm requires its own level of consideration, if there is a simple truism about Unicode it is: Never operate on a single character, rather operate on slices of text. To sum up the situation: Unicode standard defines *all* of its algorithms in terms of code points and some use grapheme clusters. It never says anything about code units beyond mapping of code units --> code point. So whether or not you should actually decode is up to the implementation. Ranges of code points is _mostly_ correct but still incorrect and _more_ efficient than graphemes but still quite a bit less efficient than code units. So, it's kind of like it's got the best and worst of both worlds. The current situation causes inconsistencies with everything else (forcing us to use isNarrowString all over the place) and definitely requires frequent explaining, but it does prevent some classes of problems. So, I don't know. I used to be in favor of the current situation, but at this point, if we could change it, I think that I'd argue in faver of just treating them as ranges of code units and then have wrappers for ranges of code points or graphemes. Agreed. The simple dream of automatically decoding UTF and staying "Unicode correct" is a failure. It seems like the current situation promotes either using ubyte[] (if you care about efficiency) or the new grapheme facilities in std.uni if you care about correctness, whereas just using strings as ranges of dchar is probably a bad idea unless you just don't want to deal with any of the Unicode stuff, don't care all that much about efficiency, and are willing have bugs in the areas where operating at the code point level is incorrect. The worst thing about current situation is any generic code that works on UTF ranges has to jump through unbelievable amount of hoops to undo "string has no length" madness. I think what we should do is define an StringRange or some such, that will at least make the current special case of string more generic. -- Dmitry Olshansky
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
29-May-2014 04:58, Walter Bright пишет:
On 5/28/2014 5:35 PM, Brian Rogoff wrote:
Could you elaborate? Using some of the examples Brian gave, which ones
do you
think are are mathematically consistent/human inconsistent and which
the inverse?
Off the top of my head:
static if (condition)
else :
... declarations ...
All attributes apply to either:
1. the next statement or declaration
2. { ... }
3. : ...
That case is (3), as static if is set up as an attribute.
Static if is certainly NOT an attribute, it doesn't make any sense.
And no, it doesn't matter how the current frontend implements it,
because you can argue next to any decisions this way.
--
Dmitry Olshansky
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
Jesse Phillips, el 29 de May a las 14:28 me escribiste: > On Thursday, 29 May 2014 at 11:08:03 UTC, Leandro Lucarella wrote: > >I think void means "you don't know what the > >value is", not "is a random value" or "a value different from the > >default" (which is impossible for stack values, at least if the > >idea > >behind void is to avoid the extra runtime cost ;). > > The language docs state, "If the Initializer is void, however, the > variable is not initialized." Which I suspect is false in the case > of module scope and as Steven pointed out, other times doing special > "don't init" is costly. The thing is, you cannot not initialize a variable while writing the binary file to disk, you have to write something. Is not like with the stack that you can increase a pointer and leave the memory as is. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- We are born naked, wet and hungry Then things get worse
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 13:12:24 -0400, Walter Bright
wrote:
On 5/29/2014 6:11 AM, Steven Schveighoffer wrote:
struct X
{
int a;
int b = void; // also initialized to 0.
}
This is because X must blit an init for a, and it would be silly to go
through
the trouble of blitting X.init to a, but not b. Especially, for
instance, if you
had an array of X (you'd have to blit every other int!)
But it would not be silly for:
struct X {
int a;
int[100] b = void;
}
to only initialize X.a. The compiler is allowed to optimize that. And,
in fact, I wished for just this in Warp.
I don't disagree. I think the spec should not specify what happens, to
leave it open for future optimizations.
Has anyone ever considered making the compiler build an 'optimized'
init-blitting function instead of just defaulting to memcpy? In other
words, the compiler knows at compile time the layout and initialization
values of a struct. What about using the compiler and optimizer to create
the most optimized, no-runtime-variables function to blit memory? We
wouldn't even need compiler help, if we did it with RTInfo.
-Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 05/29/2014 08:22 AM, Jonathan M Davis via Digitalmars-d-announce wrote: > On Thu, 29 May 2014 07:32:48 -0700 > Ali Çehreli via Digitalmars-d-announce > wrote: > >> On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce >> wrote: >> > I don't see how you could argue that they don't have >> multi-dimensional arrays. >> >> Their specs don't have such a thing. It is possible to have arrays >> where elements are arrays but that does not make those concepts >> language constructs. > > And how as an array of arrays _not_ a multi-dimensional array? As far as I can > tell, they're exactly the same thing just phrased differently. It is not a multi-dimensional array from the point of view of the language spec. There is no such thing. Although, I agree that it exists as a concept and in human speech. What you seem to expect from the language is the acceptance of the concept of multi-dimensional array as a first-class language construct. You want the language to have a special multi-dimensional array declaration syntax. What I am saying is that since there is no such language construct, coming up with a special syntax just to satisfy some of the users would be an inconsistency in the language, which contradicts what everybody is looking for (Scott, you, be, etc. :) ) > > - Jonathan M Davis > Ali
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/2014 6:11 AM, Steven Schveighoffer wrote:
struct X
{
int a;
int b = void; // also initialized to 0.
}
This is because X must blit an init for a, and it would be silly to go through
the trouble of blitting X.init to a, but not b. Especially, for instance, if you
had an array of X (you'd have to blit every other int!)
But it would not be silly for:
struct X {
int a;
int[100] b = void;
}
to only initialize X.a. The compiler is allowed to optimize that. And, in fact,
I wished for just this in Warp.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/29/2014 7:28 AM, Jesse Phillips wrote: The language docs state, "If the Initializer is void, however, the variable is not initialized." Which I suspect is false in the case of module scope and as Steven pointed out, other times doing special "don't init" is costly. The language does not guarantee it is initialized. That doesn't mean it has no value, however. It means its initial value must not be relied upon. While the current implementations puts them in BSS which is set to 0 before program start, it doesn't have to be done that way. Embedded systems that don't have loaders, for example, may map it onto RAM and that RAM may have whatever garbage in them that appeared when power was applied.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 07:32:48 -0700 Ali Çehreli via Digitalmars-d-announce wrote: > On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce > wrote: > > I don't see how you could argue that they don't have > multi-dimensional arrays. > > Their specs don't have such a thing. It is possible to have arrays > where elements are arrays but that does not make those concepts > language constructs. And how as an array of arrays _not_ a multi-dimensional array? As far as I can tell, they're exactly the same thing just phrased differently. - Jonathan M Davis
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 10:20:39 -0400, Jesse Phillips wrote: On Thursday, 29 May 2014 at 13:11:52 UTC, Steven Schveighoffer wrote: IIRC, the entire section of global TLS data is initialized, and is all contiguous memory, so it would be anti-performant to initialize all but 4 bytes. int x2; float f2; These are both TLS and they init to different values, I suppose: float f2prime = void; would mean f2prime is 0 and not float.init. Otherwise what you state is kind of what I was expecting. This is not what I would have expected. But one can test easily enough :) http://dpaste.dzfl.pl/6619cf538f8e I find this interesting. I would have expected the TLS initialization to be one giant memcpy. If it is, I find it puzzling that these would be different. The only logical explanation is that TLS is initialized first with all zeros, and then specific inits are overlaid on types that have inits. Otherwise, what difference does it make if you are blitting 0's or nans? -Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce wrote: > On Thu, 29 May 2014 01:31:44 -0700 > Ali Çehreli via Digitalmars-d-announce >> Note that there is no such thing as a multi-dimensional array in C, >> C++, or D. Hence, there is no reading from any direction; there is a >> simple and consistent syntax. > > ??? C, C++, and D all have multi-dimensional arrays. e.g. I think we finally see the cause of the disagreement. Those languages do not provide a construct called multi-dimensional array. Multi-dimensional arrays emerge as an application artifact when the programmer defines an array where the element type is an array. Being able to create arrays of arrays by the following syntaxt does not change that fact. The followin syntax is just a convenience: auto bar = new int[][][](6, 5, 4); > int a[5][6]; // C/C++ > int[6][5] a; // D > int** a; // C/C++ That is a single pointer to a single pointer. Using it as an array is faith-based programming but what can one do? :) > int[][] a; // D > int* a[5]; // C/C++ That is an inconsistency in C and C++. See, how the element type is on the left of the identifier? That is not the case when the element type is an array. Coping from above: > int a[5][6]; // C/C++ Do you see the problem there? It is not written with the same syntax when the element type was a pointer: int[6] a[5];// not legal C or C++ syntax There: C and C++ are inconsistent. > int[5][] a; // D > > I don't see how you could argue that they don't have multi-dimensional arrays. Their specs don't have such a thing. It is possible to have arrays where elements are arrays but that does not make those concepts language constructs. This whole issue goes well with Scott's presentation: If it is simple to describe then we ded right. Repeating myself, the following is all one needs for the array definition syntax in D: Type[length] identifier; (And of course even this: 'Type[] identifier;') Done. Now we can go wild with it to define more complex types. That's not the case with C arrays: One needs to learn a new syntax for arrays of arrays there. Ali
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 11:08:03 UTC, Leandro Lucarella wrote: I think void means "you don't know what the value is", not "is a random value" or "a value different from the default" (which is impossible for stack values, at least if the idea behind void is to avoid the extra runtime cost ;). The language docs state, "If the Initializer is void, however, the variable is not initialized." Which I suspect is false in the case of module scope and as Steven pointed out, other times doing special "don't init" is costly.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 10:41:59 UTC, Kagamin wrote:
On Wednesday, 28 May 2014 at 05:40:26 UTC, Jesse Phillips wrote:
When he explained why C++ inferred a const int type as int, he
tripped me up because D does drop const for value types.
Hmm, this bit me (doesn't compile):
void f(in char[] s)
{
auto s1=s;
s1=s;
}
I suppose at this point you know:
void f(const(char)[] s);
I understanding that expected may not be the same as simple. But
you did ask for s1 to be const then tried to modify it.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 13:11:52 UTC, Steven Schveighoffer
wrote:
IIRC, the entire section of global TLS data is initialized, and
is all contiguous memory, so it would be anti-performant to
initialize all but 4 bytes.
int x2;
float f2;
These are both TLS and they init to different values, I suppose:
float f2prime = void;
would mean f2prime is 0 and not float.init. Otherwise what you
state is kind of what I was expecting.
Note:
struct X
{
int a;
int b = void; // also initialized to 0.
}
This is because X must blit an init for a, and it would be
silly to go through the trouble of blitting X.init to a, but
not b. Especially, for instance, if you had an array of X
(you'd have to blit every other int!)
-Steve
Thanks for the bonus example.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 2014-05-29 03:29, Jonathan M Davis via Digitalmars-d-announce wrote: 1. The order of the dimensions of multi-dimensional static arrays is backwards in comparison to what most everyone expects. int[4][5][6] foo; is the same as int foo[6][5][4]; and has the same dimensions as auto bar = new int[][][](6, 5, 4); IMO, it's the dynamic array creation syntax that's weird here. The static array syntax is sensible, easy to explain, and consistent with reading the type left to right. I've never used the syntax for creating a multidimensional dynamic array, so I was frankly surprised to see it worked that way. -- Simen
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 10:01:17 UTC, Jonathan M Davis via Digitalmars-d-announce wrote: ??? C, C++, and D all have multi-dimensional arrays. e.g. int a[5][6]; // C/C++ int[6][5] a; // D int** a; // C/C++ int[][] a; // D int* a[5]; // C/C++ int[5][] a; // D I don't see how you could argue that they don't have multi-dimensional arrays. I'd guess he's contrasting with the semantics offered by array-oriented languages. For example, can you determine the rank of those arrays programmatically in constant time? Does the type system understand the shape, and can it be reshaped trivially? Does an operator or function expecting rank n automatically lift to higher ranks? That sort of stuff. Maybe D does something I haven't learned about (yet) in that area, but I know C and C++ do not (hence the heap corruption I've been hunting all week). -Wyatt
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wed, 28 May 2014 22:38:55 -0400, Jesse Phillips
wrote:
On Wednesday, 28 May 2014 at 04:48:11 UTC, Jesse Phillips wrote:
I did a translation of most of the code in the slides.
http://dpaste.dzfl.pl/72b5cfcb72e4
I'm planning to transform it into blog post (or series). Right now it
just has some scratch notes. Feel free to let me know everything I got
wrong.
Hoping someone can confirm or deny this thought.
int x2prime = void; // (at global scope)
Since x2prime is module variable, I would expect that the compiler will
always initialize this to 0 since there isn't really a performance hit.
Or is using void guarantee it won't get initialized (so much value in
that guarantee)?
IIRC, the entire section of global TLS data is initialized, and is all
contiguous memory, so it would be anti-performant to initialize all but 4
bytes.
Note:
struct X
{
int a;
int b = void; // also initialized to 0.
}
This is because X must blit an init for a, and it would be silly to go
through the trouble of blitting X.init to a, but not b. Especially, for
instance, if you had an array of X (you'd have to blit every other int!)
-Steve
Re: [OT] Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 04:57:14 -0400, Alix Pexton wrote: On 28/05/2014 2:05 PM, Craig Dillabaugh wrote: On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. when they mean: I couldn't care less. and: If you think that, you have another thing coming. when they mean: If you think that, you have another think coming. Whats wrong with "If you think that, you have another thing coming."? I've always understood it sort of like say your Father saying: "If you think that [i.e. you can steal your little brother's ice cream cone], then you have another thing [i.e no ice cream, but maybe the leather strap] coming." I couldn't resist looking up this debate, and its quite a fiery one with no clear winner! There is no clear origin to the phrase and equal arguments for and against both forms. If you think I'll let it go you're mad, you got another thing comin' -Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
Jesse Phillips, el 29 de May a las 02:38 me escribiste: > On Wednesday, 28 May 2014 at 04:48:11 UTC, Jesse Phillips wrote: > >I did a translation of most of the code in the slides. > > > >http://dpaste.dzfl.pl/72b5cfcb72e4 > > > >I'm planning to transform it into blog post (or series). Right now > >it just has some scratch notes. Feel free to let me know > >everything I got wrong. > > Hoping someone can confirm or deny this thought. > > int x2prime = void; // (at global scope) > > Since x2prime is module variable, I would expect that the compiler > will always initialize this to 0 since there isn't really a > performance hit. Or is using void guarantee it won't get initialized > (so much value in that guarantee)? global/static variables are placed in a special section in the executable. You need to put some value on it, so it is sensible to put the same value you use for initialization, but a compiler implementation could use a different value. I think void means "you don't know what the value is", not "is a random value" or "a value different from the default" (which is impossible for stack values, at least if the idea behind void is to avoid the extra runtime cost ;). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- You should've seen her face. It was the exact same look my father gave me when I told him I wanted to be a ventriloquist. -- George Constanza
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 05:40:26 UTC, Jesse Phillips wrote:
When he explained why C++ inferred a const int type as int, he
tripped me up because D does drop const for value types.
Hmm, this bit me (doesn't compile):
void f(in char[] s)
{
auto s1=s;
s1=s;
}
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 02:38:56 UTC, Jesse Phillips wrote: Hoping someone can confirm or deny this thought. int x2prime = void; // (at global scope) Since x2prime is module variable, I would expect that the compiler will always initialize this to 0 since there isn't really a performance hit. Or is using void guarantee it won't get initialized (so much value in that guarantee)? Depends on the implementation of tls, usually the .tls section is initialized data.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 2014-05-28 16:56, Jesse Phillips wrote: D doesn't have global scope. C++ does not do TLS but that isn't relevant to the no cost position that C++ is taking. Since C++11 there's "thread_local". -- /Jacob Carlborg
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 01:31:44 -0700 Ali Çehreli via Digitalmars-d-announce wrote: > On 05/29/2014 12:59 AM, Jonathan M Davis via Digitalmars-d-announce > wrote: > > > So, unfortunately, I think that we're stuck. > > You make it sound like there is a problem. ;) > > > I don't see much of an argument for why it makes any sense for > > static > array > > dimensions be read from right-to-left in declarations. > > Language does not say anything about how people read declarations. > Both static array dimensions and indexing are consistent currently in > D. > > When declaring, it is always > > Type[length] > > when indexing it is always > > arr[index] It's consistent until you have multiple dimensions. Then you end up with the dimensions being listed right-to-left for static array declarations and left-to-right in all other cases. > Note that there is no such thing as a multi-dimensional array in C, > C++, or D. Hence, there is no reading from any direction; there is a > simple and consistent syntax. ??? C, C++, and D all have multi-dimensional arrays. e.g. int a[5][6]; // C/C++ int[6][5] a; // D int** a; // C/C++ int[][] a; // D int* a[5]; // C/C++ int[5][] a; // D I don't see how you could argue that they don't have multi-dimensional arrays. - Jonathan M Davis
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 03:29:31 UTC, Jonathan M Davis via Digitalmars-d-announce wrote: 1. The order of the dimensions of multi-dimensional static arrays is backwards in comparison to what most everyone expects. int[4][5][6] foo; is the same as int foo[6][5][4]; and has the same dimensions as auto bar = new int[][][](6, 5, 4); The reasons for it stem from the fact that the compiler reads types outward from the variable name (which is very important to understand in C because of its function pointer syntax but not so important in D). However, once we did const(int)* foo; and didn't allow (int)const* foo; I think that we threw that particular bit of consistency with C/C++ out the window, and we really should have just made static array dimensions be read from left-to-right. Unfortunately, I don't think that we can fix that at this point, because doing so would cause silent breakage (or at minimum, would be silent until RangeErrors were thrown at runtime). I don't see this as an inconsistency. Just read it as follows: int[6][5]* foo; - start with the type int - make an array from it - make an array from that - and finally, turn it into a pointer. const(int)* bar; Just read `const(int)` as one entity here (as its form suggests, some kind of "function call"): - start with a const(int) - make a pointer from it 3. const, immutable, and inout on the left-hand side of a function declaration are unfortunately legal. Agreed. At least it's possible to do it by convention (but see 4.). 4. There are some cases (such as with static constructors and unittest blocks) that the attributes have to go on the left for some reason. I don't remember the reasons for it, but it's an inconsistency which definitely trips up even seasoned D programmers from time to time. I don't know these cases, but the reason might be is that function declarations and unittests need to be followed by braces (or a semicolon in the case of functions), whereas some other keywords also allow non-compound statements. This could therefore lead to ambiguities as to whether the type qualifier applies to the declaration or the following statement. 5. The fact that pure is called pure is very problematic at this point as far as explaining things to folks goes. We should probably consider renaming it to something like @noglobal, but I'm not sure that that would go over very well given the amount of breakage involved. It _does_ require a lot of explaining though. Well, it's just a name, and it's for hysterical raisins ;-) I don't think it's so bad, because the purity concept already differs from language to language. 6. The situation with ranges and string is kind of ugly, with them being treated as ranges of code points. I don't know what the correct solution to this is, since treating them as ranges of code units promotes efficiency but makes code more error-prone, whereas treating them as ranges of graphemes would just cost too much. Ranges of code points is _mostly_ correct but still incorrect and _more_ efficient than graphemes but still quite a bit less efficient than code units. So, it's kind of like it's got the best and worst of both worlds. The current situation causes inconsistencies with everything else (forcing us to use isNarrowString all over the place) and definitely requires frequent explaining, but it does prevent some classes of problems. So, I don't know. I used to be in favor of the current situation, but at this point, if we could change it, I think that I'd argue in faver of just treating them as ranges of code units and then have wrappers for ranges of code points or graphemes. It seems like the current situation promotes either using ubyte[] (if you care about efficiency) or the new grapheme facilities in std.uni if you care about correctness, whereas just using strings as ranges of dchar is probably a bad idea unless you just don't want to deal with any of the Unicode stuff, don't care all that much about efficiency, and are willing have bugs in the areas where operating at the code point level is incorrect. My preferred solution would be to disallow iterating over bare char/wchar/dchar ranges, but require an explicit .byCodeUnit, .byCodePoint or .byGrapheme. Probably not going to happen, though...
[OT] Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 28/05/2014 2:05 PM, Craig Dillabaugh wrote: On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. when they mean: I couldn't care less. and: If you think that, you have another thing coming. when they mean: If you think that, you have another think coming. Whats wrong with "If you think that, you have another thing coming."? I've always understood it sort of like say your Father saying: "If you think that [i.e. you can steal your little brother's ice cream cone], then you have another thing [i.e no ice cream, but maybe the leather strap] coming." I couldn't resist looking up this debate, and its quite a fiery one with no clear winner! There is no clear origin to the phrase and equal arguments for and against both forms. My personal view is that the thinGists are right, because I often use the word believe in the first half, i.e. "if you believe that, then you have another thing coming." I wouldn't tell anyone that they had another belief coming, as in my experience my opinions have very little impact on the beliefs of others. Also, grammatically speaking, if I was expecting someone to change their mind, I like to think that I'd more likely say that they had another thought coming, or "If you think that, then you have another thought to come." Not because think can never be a noun, I often say "lets have a think." A...
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 05/29/2014 12:59 AM, Jonathan M Davis via Digitalmars-d-announce wrote: > So, unfortunately, I think that we're stuck. You make it sound like there is a problem. ;) > I don't see much of an argument for why it makes any sense for static array > dimensions be read from right-to-left in declarations. Language does not say anything about how people read declarations. Both static array dimensions and indexing are consistent currently in D. When declaring, it is always Type[length] when indexing it is always arr[index] Note that there is no such thing as a multi-dimensional array in C, C++, or D. Hence, there is no reading from any direction; there is a simple and consistent syntax. Ali
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thu, 29 May 2014 08:23:26 +0200 Timon Gehr via Digitalmars-d-announce wrote: > In any case, simply reversing the order for static array types using > an ad-hoc rewrite rule would be a huge wart, even more severe than > the other points you raised, and we definitely wouldn't be trading > one kind of consistency for another. In every other case, array dimensions are read from left-to-right, and thanks to const(int)* foo; we already threw out the whole idea of types really being read outward from the variable name, and outside of static arrays, I don't think that we have anything that would even care if we declared that types were always read left-to-right. If we had always had static array dimensions be read left-to-right in their declarations, I very much doubt that you would have much of anyone complaining about it being inconsistent. If anything, that's _more_ consistent with everything else. It's just that that doesn't fit with how C/C++ compilers read types. The only reason that I don't argue strongly for changing it is the fact that it would break every existing program which uses multi-dimensional static arrays, and the breakage would be easy to miss at compile time. So, unfortunately, I think that we're stuck. But aside from arguing that it's how C/C++ reads types, I don't see much of an argument for why it makes any sense for static array dimensions be read from right-to-left in declarations. - Jonathan M Davis
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 05/29/2014 05:35 AM, Jonathan M Davis via Digitalmars-d-announce wrote: On Wed, 28 May 2014 16:07:08 -0700 Walter Bright via Digitalmars-d-announce wrote: Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies. I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds. I don't disagree, but I also think that we need to be very careful when they're at odds, because it tends to result in buggy code when the rules are inconsistent from the human's perspective. In some cases, it's best to better educate the programmer, whereas in others, it's better to just make it consistent for the programmer - especially when you're dealing with a case where being consistent with one thing means being inconsistent with another. Overall, I think that we've done a decent job of it, but there are definitely places (e.g. static array declarations) where I think we botched it. - Jonathan M Davis I think this is not a point about "consistency", but about intuition. In any case, simply reversing the order for static array types using an ad-hoc rewrite rule would be a huge wart, even more severe than the other points you raised, and we definitely wouldn't be trading one kind of consistency for another. (In any case, the most elegant solution is to simply not have special syntax for language built-in types.)
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wed, 28 May 2014 16:07:08 -0700 Walter Bright via Digitalmars-d-announce wrote: > Some of the inconsistencies you mentioned and Brian mentioned in his > talk are actually the result of consistencies. > > I know this is a bit of a difficult thing to wrap one's head around, > but having something be mathematically consistent and humanly > consistent are often at severe odds. I don't disagree, but I also think that we need to be very careful when they're at odds, because it tends to result in buggy code when the rules are inconsistent from the human's perspective. In some cases, it's best to better educate the programmer, whereas in others, it's better to just make it consistent for the programmer - especially when you're dealing with a case where being consistent with one thing means being inconsistent with another. Overall, I think that we've done a decent job of it, but there are definitely places (e.g. static array declarations) where I think we botched it. - Jonathan M Davis
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
Okay. That seriously got munged. Let's try that again... On Tue, 27 May 2014 06:42:41 -1000 Andrei Alexandrescu via Digitalmars-d-announce wrote: > http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ > > https://news.ycombinator.com/newest (search that page, if not found > click "More" and search again) > > https://www.facebook.com/dlang.org/posts/855022447844771 > > https://twitter.com/D_Programming/status/471330026168651777 Fortunately, for the most part, I think that we've avoided the types of inconsistencies that Scott describes for C++, but we do definitely have some of our own. The ones that come to mind at the moment are: 1. The order of the dimensions of multi-dimensional static arrays is backwards in comparison to what most everyone expects. int[4][5][6] foo; is the same as int foo[6][5][4]; and has the same dimensions as auto bar = new int[][][](6, 5, 4); The reasons for it stem from the fact that the compiler reads types outward from the variable name (which is very important to understand in C because of its function pointer syntax but not so important in D). However, once we did const(int)* foo; and didn't allow (int)const* foo; I think that we threw that particular bit of consistency with C/C++ out the window, and we really should have just made static array dimensions be read from left-to-right. Unfortunately, I don't think that we can fix that at this point, because doing so would cause silent breakage (or at minimum, would be silent until RangeErrors were thrown at runtime). 2. We're inconsistent with dynamic array dimensions. auto foo = new int[5]; is the same as auto foo = new int[](5); but once you get into multi-dimensional arrays, it's just confusing, because auto foo = new int[4][5][6]; does _not_ declare a multi-dimensional dynamic array but rather a dynamic array of length 6 which contains a multi-dimensonal static array of dimensions 4 and 5. Instead, what you need to do is auto foo = new int[][][](4, 5, 6); IMHO, we should have made it illegal to have dynamic array dimensions inside of the brackets rather than the parens, but I don't know if we can change that. It wouldn't be silent breakage, but it _would_ make it so that a lot of existing code would be broken - especially because so many people put the array dimensions between the brackets for single-dimension dynamic arrays. 3. const, immutable, and inout on the left-hand side of a function declaration are unfortunately legal. This inevitably trips people up, because they think that the attribute applies to the return type, when it applies to the function itself. This is to make the function attributes consistent, because all of the others can go on either side, but the result is that it's essentially bad practice to ever put any attribute on the left-hand side which could apply to the return type, because it looks like a bug. If we just made it illegal for those attributes to go on the left, the problem would be solved, and the result would be far less confusing and bug-prone. I think that we can make that change with minimal breakage (since it's already bad practice to put them no the left-hand side), but AFAIK, Walter is against the idea. 4. There are some cases (such as with static constructors and unittest blocks) that the attributes have to go on the left for some reason. I don't remember the reasons for it, but it's an inconsistency which definitely trips up even seasoned D programmers from time to time. 5. The fact that pure is called pure is very problematic at this point as far as explaining things to folks goes. We should probably consider renaming it to something like @noglobal, but I'm not sure that that would go over very well given the amount of breakage involved. It _does_ require a lot of explaining though. 6. The situation with ranges and string is kind of ugly, with them being treated as ranges of code points. I don't know what the correct solution to this is, since treating them as ranges of code units promotes efficiency but makes code more error-prone, whereas treating them as ranges of graphemes would just cost too much. Ranges of code points is _mostly_ correct but still incorrect and _more_ efficient than graphemes but still quite a bit less efficient than code units. So, it's kind of like it's got the best and worst of both worlds. The current situation causes inconsistencies with everything else (forcing us to use isNarrowString all over the place) and definitely requires frequent explaining, but it does prevent some classes of problems. So, I don't know. I used to be in favor of the current situation, but at this point, if we could change it, I think that I'd argue in faver of just treating them as ranges of code units and then have wrappers for ranges of code points or graphemes. It seems like the current situation promotes either using ubyte[] (if you care about efficiency) or the
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 04:48:11 UTC, Jesse Phillips wrote: I did a translation of most of the code in the slides. http://dpaste.dzfl.pl/72b5cfcb72e4 I'm planning to transform it into blog post (or series). Right now it just has some scratch notes. Feel free to let me know everything I got wrong. Hoping someone can confirm or deny this thought. int x2prime = void; // (at global scope) Since x2prime is module variable, I would expect that the compiler will always initialize this to 0 since there isn't really a performance hit. Or is using void guarantee it won't get initialized (so much value in that guarantee)?
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/28/2014 6:06 PM, Brian Schott wrote:
On Thursday, 29 May 2014 at 00:58:35 UTC, Walter Bright wrote:
Off the top of my head:
static if (condition)
else :
... declarations ...
All attributes apply to either:
1. the next statement or declaration
2. { ... }
3. : ...
That case is (3), as static if is set up as an attribute.
Static if is not an attribute.
They are handled that way by the parser.
https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c#L379
Looks like there's an omission in the grammar. Thanks for pointing it out.
https://issues.dlang.org/show_bug.cgi?id=12818
ConditionalStatement:
Condition NoScopeNonEmptyStatement
Condition NoScopeNonEmptyStatement else NoScopeNonEmptyStatement
Condition:
VersionCondition
DebugCondition
StaticIfCondition
Attribute:
LinkageAttribute
AlignAttribute
DeprecatedAttribute
ProtectionAttribute
Pragma
static
extern
abstract
final
override
synchronized
auto
scope
const
immutable
inout
shared
__gshared
Property
nothrow
pure
ref
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 13:05:53 UTC, Craig Dillabaugh wrote: Whats wrong with "If you think that, you have another thing coming."? I've always understood it sort of like say your Father saying: "If you think that [i.e. you can steal your little brother's ice cream cone], then you have another thing [i.e no ice cream, but maybe the leather strap] coming." I think it depends on the context, "another thing coming" works with threats whereas "another think coming" works with civilized/intellectual disagreement. Due to the popularity of "another thing coming" I probably would avoid using "think coming" lest it be interpreted as hostility.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 00:58:35 UTC, Walter Bright wrote:
Off the top of my head:
static if (condition)
else :
... declarations ...
All attributes apply to either:
1. the next statement or declaration
2. { ... }
3. : ...
That case is (3), as static if is set up as an attribute.
Static if is not an attribute.
ConditionalStatement:
Condition NoScopeNonEmptyStatement
Condition NoScopeNonEmptyStatement else
NoScopeNonEmptyStatement
Condition:
VersionCondition
DebugCondition
StaticIfCondition
Attribute:
LinkageAttribute
AlignAttribute
DeprecatedAttribute
ProtectionAttribute
Pragma
static
extern
abstract
final
override
synchronized
auto
scope
const
immutable
inout
shared
__gshared
Property
nothrow
pure
ref
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 2014-05-28 13:05, Craig Dillabaugh via Digitalmars-d-announce wrote: On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. when they mean: I couldn't care less. and: If you think that, you have another thing coming. when they mean: If you think that, you have another think coming. Whats wrong with "If you think that, you have another thing coming."? I've always understood it sort of like say your Father saying: "If you think that [i.e. you can steal your little brother's ice cream cone], then you have another thing [i.e no ice cream, but maybe the leather strap] coming." It's an old saying, and in more modern English might be phrased "If you think that, you have another thought coming", i.e. you'll soon enough see why you're wrong. -- Simen
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/28/2014 5:35 PM, Brian Rogoff wrote:
Could you elaborate? Using some of the examples Brian gave, which ones do you
think are are mathematically consistent/human inconsistent and which the
inverse?
Off the top of my head:
static if (condition)
else :
... declarations ...
All attributes apply to either:
1. the next statement or declaration
2. { ... }
3. : ...
That case is (3), as static if is set up as an attribute.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 23:07:07 UTC, Walter Bright wrote: Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies. I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds. Could you elaborate? Using some of the examples Brian gave, which ones do you think are are mathematically consistent/human inconsistent and which the inverse?
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 22:42:03 UTC, Ali Çehreli wrote: However, those expectations are based on the inside-out syntax of C. Naturally, wanting to be consistent, especially compared to C, D should deviate from that syntax. I don't get to read the original email, but I agree with the examples you pull out. D's array declaration syntax is so nice. The support for C style syntax is unfortunate though.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies. I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 05/28/2014 03:10 PM, Jonathan M Davis via Digitalmars-d-announce wrote: > On Tue, 27 May 2014 06:42:41 -1000 > Andrei Alexandrescu via Digitalmars-d-announce > wrote: > > > > http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ > > > > https://news.ycombinator.com/newest (search that page, if not found > > click "More" and search again) > > > > https://www.facebook.com/dlang.org/posts/855022447844771 > > > > https://twitter.com/D_Programming/status/471330026168651777 > > Fortunately, for the most part, I think that we've avoided the types of > inconsistencies that Scott describes for C++, but we do definitely have some > of our own. The ones that come to mind at the moment are: > > 1. The order of the dimensions of multi-dimensional static arrays is backwards > in comparison to what most everyone expects. However, those expectations are based on the inside-out syntax of C. Naturally, wanting to be consistent, especially compared to C, D should deviate from that syntax. > int[4][5][6] foo; That is sane: It is alwasy "first the type then the size": int[1]good Animal[2] good Following from that rule (i.e. first type, then size), how would I have an array of 3 elements where each element is an array of 4 elements. Let's see... Each element is int[4]. There: int[4] Then, I want an array of 3 of those. There: int[4][3] good This is one of the commonish arguments in the D forums that I have the strongest opinion because there is no problem with D's syntax at all. It is consistent. It is consistent even when indexing. The index is for the array: int[1] a; a[0]; // the first element of a; it is an int int[2][3] b; b[0]; // the first element of b; it is an int[2] I don't see any problem at all. :) Remembering that there is no such thing as a multi-dimensional array in D (nor C), it just follows naturally: b[0][1]; // the second int of the first int[2] > is the same as > > int foo[6][5][4]; That's beyond ridiculous. I am glad that D avoided that problem for both function pointers and arrays. > and has the same dimensions as > > auto bar = new int[][][](6, 5, 4); That makes perfect sense to me, because this is a function API, not D syntax. There is no ambiguity in saying "you go deeper into the element sizes as you provide the arguments." Ali
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tue, 27 May 2014 06:42:41 -1000 Andrei Alexandrescu via Digitalmars-d-announce wrote: > http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ > > https://news.ycombinator.com/newest (search that page, if not found > click "More" and search again) > > https://www.facebook.com/dlang.org/posts/855022447844771 > > https://twitter.com/D_Programming/status/471330026168651777 Fortunately, for the most part, I think that we've avoided the types of inconsistencies that Scott describes for C++, but we do definitely have some of our own. The ones that come to mind at the moment are: 1. The order of the dimensions of multi-dimensional static arrays is backwards in comparison to what most everyone expects. int[4][5][6] foo; is the same as int foo[6][5][4]; and has the same dimensions as auto bar = new int[][][](6, 5, 4); The reasons for it stem from the fact that the compiler reads types outward from the variable name (which is very important to understand in C because of its function pointer syntax but not so important in D). However, once we did const(int)* foo; and didn't allow (int)const* foo; I think that we threw that particular bit of consistency with C/C++ out the window, and we really should have just made static array dimensions be read from left-to-right. Unfortunately, I don't think that we can fix that at this point, because doing so would cause silent breakage (or at minimum, would be silent until RangeErrors were thrown at runtime). 2. We're inconsistent with dynamic array dimensions. auto foo = new int[5]; is the same as auto foo = new int[](5); but once you get into multi-dimensional arrays, it's just confusing, because auto foo = new int[4][5][6]; does _not_ declare a multi-dimensional dynimac array but rather a dynamic array of length 6 which contains a multi-dimensonal static array of dimensions 4 and 5. Instead, what you need to do is auto foo = new int[][][](4, 5, 6); IMHO, we should have made it illegal to have dynamic array dimensions inside of the brackets rather than the parens, but I don't know if we can change that. It wouldn't be silent breakage, but it _would_ make it so that a lot of existing code would be broken - especially because so many people put the array dimensions between the brackets for single-dimension dynamic arrays. 3. const, immutable, and inout on the left-hand side of a function declaration are unfortunately legal. This inevitably trips people up, because they think that the attribute applies to the return type, when it applies to the function itself. This is to make the function attributes consistent, because all of the others can go on either side, but the result is that it's essentially bad practice to ever put any attribute on the left-hand side which could apply to the return type, because it looks like a bug. If we just made it illegal for those attributes to go on the left, the problem would be solved, and the result would be far less confusing and bug-prone. I think that we can make that change with minimal breakage (since it's already bad practice to put them no the left-hand side), but AFAIK, Walter is against the idea. 4. There are some cases (such as with static constructors and unittest blocks) that the attributes have to go on the left for some reason. I don't remember the reasons for it, but it's an inconsistency which definitely trips up even seasoned D programmers from time to time. 5. The fact that pure is called pure is very problematic at this point as far as explaining things to folks goes. We should probably consider renaming it to something like @noglobal, but I'm not sure that that would go over very well given the amount of breakage involved. It _does_ require a lot of explaining though. 6. The situation with ranges and string is kind of ugly, with them being treated as ranges of code points. I don't know what the correct solution to this is, since treating them as ranges of code units promotes efficiency but makes code more error-prone, whereas treating them as ranges of graphemes would just cost too much. Ranges of code points is _mostly_ correct but still incorrect and _more_ efficient than graphemes but still quite a bit less efficient than code units. So, it's kind of like it's got the best and worst of both worlds. The current situation causes inconsistencies with everything else (forcing us to use isNarrowString all over the place) and definitely requires frequent explaining, but it does prevent some classes of problems. So, I don't know. I used to be in favor of the current situation, but at this point, if we could change it, I think that I'd argue in faver of just treating them as ranges of code units and then have wrappers for ranges of code points or graphemes. It seems like the current situation promotes either using ubyte[] (if you care about efficiency) or the new grapheme facilities in std.uni if you care about cor
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/28/2014 2:28 AM, John Colvin wrote: On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. when they mean: I couldn't care less. and: If you think that, you have another thing coming. when they mean: If you think that, you have another think coming. http://www.youtube.com/watch?v=om7O0MFkmpw&feature=kp At least the Queen and I agree on something!
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 08:58:34 UTC, Rene Zwanenburg wrote: I just noticed someone posted a link to the talk at gamedev[0]. I don't know who the poster is but the gamedev.net community is pretty large; this should result in quite some extra views :) Out of curiosity - did anyone try to post it to slashdot? If not as a news article then maybe in the comments? Andrzej [0] http://www.gamedev.net/topic/657103-scott-meyers-the-last-thing-d-needs/
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 14:39:53 UTC, anonymous_me wrote: The first line: int x2; // (at global scope) The x2 resides in Thread Local Storage (TLS). A __gshared would put it in global scope. Still initialized to int.init which is zero. D doesn't have global scope. C++ does not do TLS but that isn't relevant to the no cost position that C++ is taking.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wed, 28 May 2014 04:48:09 +, Jesse Phillips wrote: > On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu > wrote: >> http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ >> >> https://news.ycombinator.com/newest (search that page, if not >> found click "More" and search again) >> >> https://www.facebook.com/dlang.org/posts/855022447844771 >> >> https://twitter.com/D_Programming/status/471330026168651777 >> >> >> Andrei > > I did a translation of most of the code in the slides. > > http://dpaste.dzfl.pl/72b5cfcb72e4 > > I'm planning to transform it into blog post (or series). Right > now it just has some scratch notes. Feel free to let me know > everything I got wrong. The first line: int x2; // (at global scope) The x2 resides in Thread Local Storage (TLS). A __gshared would put it in global scope. Still initialized to int.init which is zero.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. when they mean: I couldn't care less. and: If you think that, you have another thing coming. when they mean: If you think that, you have another think coming. Whats wrong with "If you think that, you have another thing coming."? I've always understood it sort of like say your Father saying: "If you think that [i.e. you can steal your little brother's ice cream cone], then you have another thing [i.e no ice cream, but maybe the leather strap] coming."
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. when they mean: I couldn't care less. and: If you think that, you have another thing coming. when they mean: If you think that, you have another think coming. http://www.youtube.com/watch?v=om7O0MFkmpw&feature=kp
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ https://news.ycombinator.com/newest (search that page, if not found click "More" and search again) https://www.facebook.com/dlang.org/posts/855022447844771 https://twitter.com/D_Programming/status/471330026168651777 Andrei I just noticed someone posted a link to the talk at gamedev[0]. I don't know who the poster is but the gamedev.net community is pretty large; this should result in quite some extra views :) [0] http://www.gamedev.net/topic/657103-scott-meyers-the-last-thing-d-needs/
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
woudl be nice to have some sort of example by example comparison or as an extension to the page http://dlang.org/cpptod.html Am 28.05.2014 07:40, schrieb Jesse Phillips: On Wednesday, 28 May 2014 at 05:30:18 UTC, Philippe Sigaud via Digitalmars-d-announce wrote: I did a translation of most of the code in the slides. http://dpaste.dzfl.pl/72b5cfcb72e4 I'm planning to transform it into blog post (or series). Right now it just has some scratch notes. Feel free to let me know everything I got wrong. That's a good idea. I think most of us did that while listening to the talk. I kept telling myself: 'oh wait, that'd simpler in D' or 'that does not exist in D'. As for the class inheritance problem, I'd also be interested in an answer. When he explained why C++ inferred a const int type as int, he tripped me up because D does drop const for value types. But D does the simple to explain thing, may not be the expected thing (seen questions about it in D.learn), but it is simple to explain.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/27/2014 10:40 PM, Jesse Phillips wrote: When he explained why C++ inferred a const int type as int, he tripped me up because D does drop const for value types. But D does the simple to explain thing, may not be the expected thing (seen questions about it in D.learn), but it is simple to explain. We have at times opted for an "easy to explain" rule rather than a semantically perfect one. For example, I've rejected several proposals to make function overloading more fine-grained on such grounds. I've rarely met anyone who could explain how C++'s function overloading rules actually work, they just try arbitrary things until it selects the function they want it to.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 05:30:18 UTC, Philippe Sigaud via Digitalmars-d-announce wrote: I did a translation of most of the code in the slides. http://dpaste.dzfl.pl/72b5cfcb72e4 I'm planning to transform it into blog post (or series). Right now it just has some scratch notes. Feel free to let me know everything I got wrong. That's a good idea. I think most of us did that while listening to the talk. I kept telling myself: 'oh wait, that'd simpler in D' or 'that does not exist in D'. As for the class inheritance problem, I'd also be interested in an answer. When he explained why C++ inferred a const int type as int, he tripped me up because D does drop const for value types. But D does the simple to explain thing, may not be the expected thing (seen questions about it in D.learn), but it is simple to explain.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
> I did a translation of most of the code in the slides. > > http://dpaste.dzfl.pl/72b5cfcb72e4 > > I'm planning to transform it into blog post (or series). Right now it just > has some scratch notes. Feel free to let me know everything I got wrong. That's a good idea. I think most of us did that while listening to the talk. I kept telling myself: 'oh wait, that'd simpler in D' or 'that does not exist in D'. As for the class inheritance problem, I'd also be interested in an answer.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ https://news.ycombinator.com/newest (search that page, if not found click "More" and search again) https://www.facebook.com/dlang.org/posts/855022447844771 https://twitter.com/D_Programming/status/471330026168651777 Andrei I did a translation of most of the code in the slides. http://dpaste.dzfl.pl/72b5cfcb72e4 I'm planning to transform it into blog post (or series). Right now it just has some scratch notes. Feel free to let me know everything I got wrong.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 22:10:02 UTC, Johannes Totz wrote: Thanks, is it possible to put it on Youtube as well? Ustream stutters every second from where I am which makes me feel sorry for the speaker… http://rg3.github.io/youtube-dl/ helps with the stutter. +1
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
Brian Schott, el 27 de May a las 20:03 me escribiste: > On Tuesday, 27 May 2014 at 19:44:01 UTC, Andrew Edwards wrote: > >Really? What I got out of it was that D doesn't need people like > >him because his job is to explain the inconsistencies of the > >language. By designing a consistent language in the first place, > >people can readily understand it in all context thereby > >eliminating the need for people like him. > > Another point is that D is still small enough that we have time to > fix things before they get out of control. > > (One of my favorite parts of this talk is when he points out that > you need parenthesis in a specific kind of lambda just because the > committee forgot to update the grammar specification.) This is very related to Don's message of last year's talk about ROI of breaking changes. https://www.youtube.com/watch?v=pmwKRYrfEyY#t=30m55s -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Y serán tiempos de vanos encuentros entre humano y humano; en que las fieras se comerán entre ellas y después del final; en que se abríran las tierras y los cielos... y en el medio de la nada Racing saldrá campeón. -- Ricardo Vaporeso
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/27/2014 6:10 PM, Johannes Totz wrote: On 27/05/2014 18:43, "Ola Fosheim Grøstad" " wrote: On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ Thanks, is it possible to put it on Youtube as well? Ustream stutters every second from where I am which makes me feel sorry for the speaker… http://rg3.github.io/youtube-dl/ helps with the stutter. Or this FF extension (which is what I normally use): http://www.downloadhelper.net/
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 27/05/2014 18:43, "Ola Fosheim Grøstad" " wrote: > On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote: >> http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ >> > > Thanks, is it possible to put it on Youtube as well? Ustream stutters > every second from where I am which makes me feel sorry for the speaker… http://rg3.github.io/youtube-dl/ helps with the stutter.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. when they mean: I couldn't care less. and: If you think that, you have another thing coming. when they mean: If you think that, you have another think coming.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 21:16:34 UTC, Chris Nicholson-Sauls wrote: On Tuesday, 27 May 2014 at 20:11:13 UTC, w0rp wrote: On Tuesday, 27 May 2014 at 19:43:57 UTC, Steven Schveighoffer wrote: On Tue, 27 May 2014 14:57:46 -0400, w0rp wrote: That was brilliant. I think Scott made two very good points. D needs people like himself to educate others I think you misunderstood that point ;) He was saying to make D so that we DON'T need specialists like himself that can make a career out of explaining the strange quirks of D, mostly by not having those quirks in the first place. -Steve Oh, I see what he's saying now. The *last* thing. That's... confusing use of English. It makes more sense with respect to his other comment, though. Sometimes I think English could use a guy like him. I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 20:11:13 UTC, w0rp wrote: On Tuesday, 27 May 2014 at 19:43:57 UTC, Steven Schveighoffer wrote: On Tue, 27 May 2014 14:57:46 -0400, w0rp wrote: That was brilliant. I think Scott made two very good points. D needs people like himself to educate others I think you misunderstood that point ;) He was saying to make D so that we DON'T need specialists like himself that can make a career out of explaining the strange quirks of D, mostly by not having those quirks in the first place. -Steve Oh, I see what he's saying now. The *last* thing. That's... confusing use of English. It makes more sense with respect to his other comment, though. Sometimes I think English could use a guy like him.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tue, 27 May 2014 16:11:12 -0400, w0rp wrote: On Tuesday, 27 May 2014 at 19:43:57 UTC, Steven Schveighoffer wrote: On Tue, 27 May 2014 14:57:46 -0400, w0rp wrote: That was brilliant. I think Scott made two very good points. D needs people like himself to educate others I think you misunderstood that point ;) He was saying to make D so that we DON'T need specialists like himself that can make a career out of explaining the strange quirks of D, mostly by not having those quirks in the first place. -Steve Oh, I see what he's saying now. The *last* thing. That's... confusing use of English. Yes, it's a common phrase. http://dictionary.cambridge.org/us/dictionary/british/the-last-thing-you-want-need-etc Basically it means something you definitely DON'T need. -Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 19:43:57 UTC, Steven Schveighoffer wrote: On Tue, 27 May 2014 14:57:46 -0400, w0rp wrote: That was brilliant. I think Scott made two very good points. D needs people like himself to educate others I think you misunderstood that point ;) He was saying to make D so that we DON'T need specialists like himself that can make a career out of explaining the strange quirks of D, mostly by not having those quirks in the first place. -Steve Oh, I see what he's saying now. The *last* thing. That's... confusing use of English. It makes more sense with respect to his other comment, though.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 19:44:01 UTC, Andrew Edwards wrote: Really? What I got out of it was that D doesn't need people like him because his job is to explain the inconsistencies of the language. By designing a consistent language in the first place, people can readily understand it in all context thereby eliminating the need for people like him. Another point is that D is still small enough that we have time to fix things before they get out of control. (One of my favorite parts of this talk is when he points out that you need parenthesis in a specific kind of lambda just because the committee forgot to update the grammar specification.)
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/27/14, 2:57 PM, w0rp wrote: That was brilliant. I think Scott made two very good points. D needs people like himself to educate others, and that D should focus on behaviour which makes sense not only in a particular context, but with respect to the other contexts. (Which is what C++ lacks greatly.) Really? What I got out of it was that D doesn't need people like him because his job is to explain the inconsistencies of the language. By designing a consistent language in the first place, people can readily understand it in all context thereby eliminating the need for people like him. At roughly 04:55 he says: "I am a professional explainer. That's my job. Who knew that you can have a job doing that? Turns out you can actually make a career of it." He gives a slew of examples of kind of things he's got to explain on a daily basis and closes out the whole thing with: "The message that I bring to the D Community, based on my experience with with C++, is that the last thing D needs is somebody like me."
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tue, 27 May 2014 14:57:46 -0400, w0rp wrote: That was brilliant. I think Scott made two very good points. D needs people like himself to educate others I think you misunderstood that point ;) He was saying to make D so that we DON'T need specialists like himself that can make a career out of explaining the strange quirks of D, mostly by not having those quirks in the first place. -Steve
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
That was brilliant. I think Scott made two very good points. D needs people like himself to educate others, and that D should focus on behaviour which makes sense not only in a particular context, but with respect to the other contexts. (Which is what C++ lacks greatly.)
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
Great, but I think this should be on youtube too, reasons for this is the possibility to change resolution and other features like subtitles for foreigners etc. Matheus.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ Thanks, is it possible to put it on Youtube as well? Ustream stutters every second from where I am which makes me feel sorry for the speaker…
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 5/27/2014 12:42 PM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/ https://news.ycombinator.com/newest (search that page, if not found click "More" and search again) https://www.facebook.com/dlang.org/posts/855022447844771 https://twitter.com/D_Programming/status/471330026168651777 Andrei What? Andrei's keynote isn't first? :( Nonetheless, this Scott Meyers talk is fantastic (and a good choice for "first released"). Only one thing could've made this better: When the MC finishes his intro, there should be some heavy rock music and laser lights while Scott comes up on stage. :) Oh well, maybe next year...Who's got the fog machine?
