On 15.07.2016 22:29, Walter Bright wrote:
On 7/15/2016 12:55 PM, Jack Stouffer wrote:
On Friday, 15 July 2016 at 19:06:15 UTC, Walter Bright wrote:
4. making use of asserts to provide information to the optimizer
Do dmd/ldc/gdc actually do this?
dmd doesn't. I don't know about other
On Monday, 11 July 2016 at 18:57:51 UTC, deadalnix wrote:
Alright, but keep in mind that is an example, not the actual
problem I'm talking about. There are many reasonable way to
make the example above safe: disallow dereferencing pointers
from unknown source, do a bound check on .ptr,
On Thursday, 21 July 2016 at 16:39:18 UTC, Andrew Godfrey wrote:
You seem to be assuming that everyone already agrees on which
set of changes should be made to the language. (Otherwise, how
could you expect anyone to "officially back" a side project?)
But agreeing on which changes to make
On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote:
You can lower D to Assembler and analyze that. Assembler is
simple, isn't it?
You can, and that is what C++ is mostly limited to, but you then
you most likely get false positives and cannot use the analysis
as part of the type-system.
On Thursday, 21 July 2016 at 16:21:17 UTC, Andrew Godfrey wrote:
You can lower D to Assembler and analyze that. Assembler is
simple, isn't it?
Are you trolling? Lowering discards information.
AFAIK, that's what static analysis is built for: to infer
high-level properties of the code that
On Thursday, 21 July 2016 at 08:40:03 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote:
ideas that would require a major version change. The thing
about that is that it can't be done incrementally; it's the
rare kind of thing that would need to be
On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote:
On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad
wrote:
Not sure what you mean.
1. It is more time consuming to write an analysis engine that
can cover convoluted machinery than simple machinery.
2. It it more difficult
On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad
wrote:
Not sure what you mean.
1. It is more time consuming to write an analysis engine that
can cover convoluted machinery than simple machinery.
2. It it more difficult to extend complex machinery than simple
machinery.
3.
On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote:
ideas that would require a major version change. The thing
about that is that it can't be done incrementally; it's the
rare kind of thing that would need to be planned long in
advance, and would have to amount to a huge
That's an interesting outcome that backward compatibility matters
for hobby users more than for commercial users :)
On Wednesday, 20 July 2016 at 20:12:14 UTC, Jack Stouffer wrote:
On Tuesday, 19 July 2016 at 15:22:19 UTC, Andrew Godfrey wrote:
[...]
Something being dfix-able is not enough for the simple reason
that legacy code in D is already becoming a thing, despite D2
only existing for nine years. A
On Tuesday, 19 July 2016 at 15:22:19 UTC, Andrew Godfrey wrote:
Just like earlier in this thread, where I mentined dfixable
breaking changes and Walter implied that even though a would
cause people to have to manually rewrite.
Something being dfix-able is not enough for the simple reason
On Tuesday, 19 July 2016 at 09:49:50 UTC, Chris wrote:
On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote:
2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d <
digitalmars-d@puremagic.com>:
I've never seen a definitive "No" to breaking changes.
We do breaking changes
On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote:
2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d <
digitalmars-d@puremagic.com>:
I've never seen a definitive "No" to breaking changes.
We do breaking changes all the time. Did everyone already
forget what the
On 7/18/2016 5:06 AM, Kagamin wrote:
On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote:
I've seen SAL before, but have not studied it. My impression is it is much
more complex than necessary. For example,
https://msdn.microsoft.com/en-us/library/hh916383.aspx
describes
On 7/18/2016 9:08 AM, Andrew Godfrey wrote:
On Thursday, 14 July 2016 at 20:01:54 UTC, Walter Bright wrote:
On 7/14/2016 11:49 AM, Steven Schveighoffer wrote:
In C++, the compiler has to reload x, because it may have changed.
That's right. I learned that the hard way, when the original
On 7/18/2016 6:48 AM, Andrew Godfrey wrote:
We risk scaring away potential community members, and alienating existing ones,
by the way we say "no" to proposals for breaking changes. We could improve how
we say "no", by having a place to point people to. Potential topics:
Anything we do will
2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d <
digitalmars-d@puremagic.com>:
>
> We risk scaring away potential community members, and alienating existing
> ones, by the way we say "no" to proposals for breaking changes. We could
> improve how we say "no", by having a place to
On Thursday, 14 July 2016 at 20:01:54 UTC, Walter Bright wrote:
On 7/14/2016 11:49 AM, Steven Schveighoffer wrote:
In C++, the compiler has to reload x, because it may have
changed.
That's right. I learned that the hard way, when the original
optimizer would assume that x hadn't changed. It
On Monday, 18 July 2016 at 13:48:16 UTC, Andrew Godfrey wrote:
1) As you say, a vision for D3. Maybe just a summary of the
things that are now agreed upon, e.g. autodecoding (though even
there, I think the details of where to move to, are still
contentious. E.g. I personally dislike the
On Monday, 18 July 2016 at 09:45:39 UTC, Chris wrote:
On Sunday, 17 July 2016 at 02:17:52 UTC, Andrew Godfrey wrote:
On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote:
On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
Walter called Prolog "singularly useless". You have been
referring
On Sunday, 17 July 2016 at 02:59:42 UTC, Nobody wrote:
Perl 6.
Inequality operator :)
On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote:
I've seen SAL before, but have not studied it. My impression is
it is much more complex than necessary. For example,
https://msdn.microsoft.com/en-us/library/hh916383.aspx
describes annotations to memcpy(). I believe these are
On Monday, 18 July 2016 at 11:05:34 UTC, Bill Hicks wrote:
On Sunday, 17 July 2016 at 05:50:31 UTC, H. S. Teoh wrote:
On Sun, Jul 17, 2016 at 02:59:42AM +, Nobody via
Digitalmars-d wrote:
Perl 6.
Are you serious? Perl is the *prime* example of "unprincipled
and complex". Larry Wall
On Sunday, 17 July 2016 at 05:50:31 UTC, H. S. Teoh wrote:
On Sun, Jul 17, 2016 at 02:59:42AM +, Nobody via
Digitalmars-d wrote:
Perl 6.
Are you serious? Perl is the *prime* example of "unprincipled
and complex". Larry Wall himself said (in print, no less):
English is useful
On Sunday, 17 July 2016 at 02:17:52 UTC, Andrew Godfrey wrote:
On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote:
On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
Walter called Prolog "singularly useless". You have been
referring to changes
that would amount to a new major version of D
On Sunday, 17 July 2016 at 12:38:46 UTC, Andrei Alexandrescu
wrote:
On 7/15/16 10:43 AM, Andrew Godfrey wrote:
On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter
wrote:
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh
wrote:
I think the one that hurts the most is fixing "C++
On 2016-07-17 05:35, Andrew Godfrey wrote:
No it's not the same - void initialization leaves the variable
uninitialized. I'm saying, something that still initialized, but marks
that initial value as not to be used. Anyway... given the existence of
void initialization (which I'd forgotten
On 7/15/16 10:43 AM, Andrew Godfrey wrote:
On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote:
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote:
I think the one that hurts the most is fixing "C++ fault" #3. It
means there are many scenarios in which I could put
On Sun, Jul 17, 2016 at 02:59:42AM +, Nobody via Digitalmars-d wrote:
> On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote:
> > On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote:
> > > On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
> > > > On 7/7/2016 5:56 PM, deadalnix
On Sunday, 17 July 2016 at 05:14:57 UTC, Walter Bright wrote:
On 7/16/2016 7:17 PM, Andrew Godfrey wrote:
I'm more interested in engaging on "in how many years will the
D leadership be
interested in engaging on the topic of D3?" I feel this is a
significant
omission from the vision doc, and
On 7/16/2016 7:17 PM, Andrew Godfrey wrote:
I'm more interested in engaging on "in how many years will the D leadership be
interested in engaging on the topic of D3?" I feel this is a significant
omission from the vision doc, and that omission inflames a lot of the recurring
animosity I see on
On Sunday, 17 July 2016 at 02:07:19 UTC, pineapple wrote:
On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote:
2) I wonder if an "uninitialized" feature would be worthwhile.
That is, a value you can initialize a variable to, equal to
'init', but that static analyzers know you don't
On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote:
On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote:
On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
On 7/7/2016 5:56 PM, deadalnix wrote:
While this very true, it is clear that most D's complexity
doesn't come from
there.
On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote:
On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
Walter called Prolog "singularly useless". You have been
referring to changes
that would amount to a new major version of D as "a cleanup".
From the forums,
my sense is that there IS a
On 7/16/2016 7:03 PM, Andrew Godfrey wrote:
I'm thinking:
1) Static analysis tools still have relevance even in D code.
I agree, but their utility is greatly reduced, meaning the payback for the
effort makes for a small benefit/cost ratio.
2) I wonder if an "uninitialized" feature would
On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote:
2) I wonder if an "uninitialized" feature would be worthwhile.
That is, a value you can initialize a variable to, equal to
'init', but that static analyzers know you don't mean to ever
use.
Don't we already have this in the form
On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote:
On 7/16/2016 5:32 AM, Andrew Godfrey wrote:
[...]
Thanks for taking the time to post about your experience with
it. Comparing D with SAL is a worthwhile exercise.
[...]
I've seen SAL before, but have not studied it. My
On 7/16/2016 5:32 AM, Andrew Godfrey wrote:
On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote:
But in C++, everything is @system. I'm not sure how people successfully create
enormous programs with it.
I work on Microsoft Word. I'm not sure how much I can share about internal
On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
Walter called Prolog "singularly useless". You have been referring to changes
that would amount to a new major version of D as "a cleanup". From the forums,
my sense is that there IS a groundswell of opinion, that D2 has some major
mistakes in it that
On Saturday, 16 July 2016 at 07:14:03 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote:
On 7/14/2016 6:26 AM, Chris wrote:
Now, now. Where's your sense of humor?
The thing is, he's just here to troll us. His posts all follow
the same pattern of
On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote:
But in C++, everything is @system. I'm not sure how people
successfully create enormous programs with it.
I work on Microsoft Word. I'm not sure how much I can share about
internal verification tools, but I can say: We do have
On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote:
On 7/14/2016 6:26 AM, Chris wrote:
Now, now. Where's your sense of humor?
The thing is, he's just here to troll us. His posts all follow
the same pattern of relentlessly finding nothing good
whatsoever in D, and we're all
On 7/15/2016 11:28 PM, Shachar Shemesh wrote:
First of all, it sounds like you envision that everyone will solely be using the
D supplied allocators, and no one will be writing their own.
There won't be anything stopping anyone from writing their own allocators, just
like there's nothing
On 7/15/2016 11:12 PM, Shachar Shemesh wrote:
So, would you say you shouldn't use D unless all of your code is @safe? Most?
Some? None?
The idea is to minimize the use of @system.
If you've got a large team and large codebase, the use of @system should merit
special attention in code
On 7/15/2016 11:04 PM, Andrew Godfrey wrote:
Ok. Well, when you and Shachar were arguing, it still doesn't seem like Shachar
was talking about @safe code specifically. I can't wrap my mind around wanting a
"logical const" feature usable in @safe context; you could already use @system
for those
On Friday, 15 July 2016 at 09:29:27 UTC, Kagamin wrote:
On Thursday, 14 July 2016 at 20:12:13 UTC, Ola Fosheim Grøstad
wrote:
And please note that this horrible excuse is propagate in the
C++ community too. Time and time again people claim that C++
is complex, but it has to be like that in
On 16/07/16 02:04, Walter Bright wrote:
On 7/15/2016 1:58 PM, Shachar Shemesh wrote:
Do enlighten me how to use intrusive reference counting in D. I am quite
interested in the answer.
Andrei and I are working on it. As he's expressed elsewhere, the idea is
to maintain the reference count in
On 16/07/16 07:24, Walter Bright wrote:
Since casting away immutable/const is allowed in @system code, yes, I am
referring to @safe code here.
That is something without which none of your arguments made sense to me.
Thank you for your clarification.
So, would you say you shouldn't use D
On Saturday, 16 July 2016 at 04:24:39 UTC, Walter Bright wrote:
On 7/15/2016 8:25 PM, Andrew Godfrey wrote:
I agree and I like mechanically checkable things. But I also
like compiler
features that mix mechanical checking with the ability to
attest to something
that can't be mechanically
On 7/15/2016 8:25 PM, Andrew Godfrey wrote:
I agree and I like mechanically checkable things. But I also like compiler
features that mix mechanical checking with the ability to attest to something
that can't be mechanically checked. Like the @system attribute. So this line of
reasoning feels
On Friday, 15 July 2016 at 23:00:45 UTC, Walter Bright wrote:
On 7/15/2016 1:48 PM, Shachar Shemesh wrote:
On 15/07/16 22:50, Walter Bright wrote:
You can do logical const in D just like in C++, and get those
performance gains. You just can't call it "const". But you
can call it
On 7/15/2016 1:58 PM, Shachar Shemesh wrote:
Do enlighten me how to use intrusive reference counting in D. I am quite
interested in the answer.
Andrei and I are working on it. As he's expressed elsewhere, the idea is to
maintain the reference count in memory that is outside the type system.
On 7/15/2016 1:58 PM, Shachar Shemesh wrote:
I think your argument there is completely destroyed :-)
I do not understand the joy both you and Andrei express when you think you have
"won" an "argument". This gives me the feeling that I'm not part of a process
designed to make the language
On 7/15/2016 1:48 PM, Shachar Shemesh wrote:
On 15/07/16 22:50, Walter Bright wrote:
You can do logical const in D just like in C++, and get those
performance gains. You just can't call it "const". But you can call it
/*logical_const*/ and get the same result.
No, you can't. The fact that
On Friday, 15 July 2016 at 21:24:12 UTC, Andrei Alexandrescu
wrote:
On 07/15/2016 04:58 PM, Shachar Shemesh wrote:
I do not understand the joy both you and Andrei express when
you think
you have "won" an "argument". This gives me the feeling that
I'm not
part of a process designed to make the
On 07/15/2016 04:58 PM, Shachar Shemesh wrote:
I do not understand the joy both you and Andrei express when you think
you have "won" an "argument". This gives me the feeling that I'm not
part of a process designed to make the language better, but rather part
of an argument meant to prove to me
On 15/07/16 22:06, Walter Bright wrote:
2. memory allocation - D programmers can use any of C++'s allocation
methods
Do enlighten me how to use intrusive reference counting in D. I am quite
interested in the answer. Or, for that matter, tracking lifetime through
an external linked list with
On 15/07/16 22:50, Walter Bright wrote:
You can do logical const in D just like in C++, and get those
performance gains. You just can't call it "const". But you can call it
/*logical_const*/ and get the same result.
No, you can't. The fact that the compiler enforces the no const to
mutable
On 7/15/2016 12:55 PM, Jack Stouffer wrote:
On Friday, 15 July 2016 at 19:06:15 UTC, Walter Bright wrote:
4. making use of asserts to provide information to the optimizer
Do dmd/ldc/gdc actually do this?
dmd doesn't. I don't know about other compilers.
The point is it's possible because
On Friday, 15 July 2016 at 18:01:43 UTC, Andrei Alexandrescu
wrote:
Read or write.
For const(T) , same thing, but limited to write.
Thanks. Reworked:
"During and after mutating a memory location typed as
(unqualified) type T, no thread in the program (including the
current thread) is
On Friday, 15 July 2016 at 19:06:15 UTC, Walter Bright wrote:
4. making use of asserts to provide information to the optimizer
Do dmd/ldc/gdc actually do this?
On 7/15/2016 7:43 AM, Andrew Godfrey wrote:
One example is if you make a class that has an internal cache of something.
Updating or invalidating that cache has no logical effect on the
externally-observable state of the class. So you should be able to modify the
cache even on a 'const' object.
On 7/15/2016 3:25 AM, Shachar Shemesh wrote:
On 15/07/16 13:13, Walter Bright wrote:
1. no protection against casting away const and changing it anyway
2. no protection against adding 'mutable' members and changing it anyway
3. only good for one level, no way to specify a data structure of
On 07/15/2016 01:27 PM, deadalnix wrote:
On Friday, 15 July 2016 at 14:45:41 UTC, Andrei Alexandrescu wrote:
On 07/14/2016 12:17 PM, Jesse Phillips wrote:
On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh wrote:
C++ fully defines when it is okay to cast away constness, gives you
aids
On Friday, 15 July 2016 at 14:43:35 UTC, Andrew Godfrey wrote:
On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote:
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote:
I think the one that hurts the most is fixing "C++ fault" #3.
It means there are many scenarios in
On Friday, 15 July 2016 at 14:45:41 UTC, Andrei Alexandrescu
wrote:
On 07/14/2016 12:17 PM, Jesse Phillips wrote:
On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh
wrote:
C++ fully defines when it is okay to cast away constness,
gives you
aids so that you know that that's what you are
On Friday, 15 July 2016 at 15:35:37 UTC, Dicebot wrote:
One example is if you make a class that has an internal cache
of something. Updating or invalidating that cache has no
logical effect on the externally-observable state of the
class. So you should be able to modify the cache even on a
On 07/15/2016 05:43 PM, Andrew Godfrey wrote:
> On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote:
>> On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote:
>>>
>>> I think the one that hurts the most is fixing "C++ fault" #3. It
>>> means there are many scenarios in which I
On 07/14/2016 12:17 PM, Jesse Phillips wrote:
On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh wrote:
C++ fully defines when it is okay to cast away constness, gives you
aids so that you know that that's what you are doing, and nothing
else, and gives you a method by which you can do
On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote:
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote:
I think the one that hurts the most is fixing "C++ fault" #3.
It means there are many scenarios in which I could put const
in C++, and I simply can't in D, because
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote:
I think the one that hurts the most is fixing "C++ fault" #3.
It means there are many scenarios in which I could put const in
C++, and I simply can't in D, because something somewhere needs
to be mutable.
Then it is not const
On 15/07/16 13:13, Walter Bright wrote:
1. no protection against casting away const and changing it anyway
2. no protection against adding 'mutable' members and changing it anyway
3. only good for one level, no way to specify a data structure of
generic type T as const
(and, sadly, not
On 7/15/2016 2:34 AM, Shachar Shemesh wrote:
Const is very far from meaningless in C++. It is an extremely valuable tool in
turning bugs into compile time errors. That is not something to think lightly of
Unfortunately, C++ const is little more than advisory:
1. no protection against casting
On Thursday, 14 July 2016 at 13:24:51 UTC, Ola Fosheim Grøstad
wrote:
You mean your process describes building prototypes only?
Yes?
You cannot easily iterate over the design of the core language
without creating a mess. You can iterate the design of
libraries and to some extent syntactical
On 15/07/16 02:06, Jesse Phillips wrote:
On Thursday, 14 July 2016 at 18:49:36 UTC, Steven Schveighoffer wrote:
If what you wrote is UB (as it is in D), then the compiler can go
ahead and assign 5 to y.
In C++, the compiler has to reload x, because it may have changed.
Someone explained this
On Thursday, 14 July 2016 at 14:46:50 UTC, Ola Fosheim Grøstad
wrote:
The JVM is also a decent example of a core language that is
fairly stable. It as based on the StrongTalk VM.
AFAIK JVM has a design bug: can't reliably differentiate between
methods to invoke the right one.
On Thursday, 14 July 2016 at 20:12:13 UTC, Ola Fosheim Grøstad
wrote:
And please note that this horrible excuse is propagate in the
C++ community too. Time and time again people claim that C++ is
complex, but it has to be like that in order to provide the
features it provides.
Not true for
On 7/14/2016 6:26 AM, Chris wrote:
Now, now. Where's your sense of humor?
The thing is, he's just here to troll us. His posts all follow the same pattern
of relentlessly finding nothing good whatsoever in D, and we're all idiots.
There's no evidence he's ever written a line of D, his
On Thursday, 14 July 2016 at 18:49:36 UTC, Steven Schveighoffer
wrote:
If what you wrote is UB (as it is in D), then the compiler can
go ahead and assign 5 to y.
In C++, the compiler has to reload x, because it may have
changed.
Someone explained this to me recently on the NG.
-Steve
On Thursday, 14 July 2016 at 20:09:26 UTC, Ola Fosheim Grøstad
wrote:
Excuses such as «system programming is complex therefore D must
be this complex» is not a position that should be accepted.
And please note that this horrible excuse is propagate in the C++
community too. Time and time
On Thursday, 14 July 2016 at 19:17:06 UTC, Chris wrote:
I certainly don't impose my view on others. The only reason I
was going ad hominem was to get you on board in a more
substantial manner than engaging in random discussions on the
forum.
That won't change anything. It's not a man-hour
On 7/14/2016 11:49 AM, Steven Schveighoffer wrote:
In C++, the compiler has to reload x, because it may have changed.
That's right. I learned that the hard way, when the original optimizer would
assume that x hadn't changed. It broke a surprising amount of code.
It also means that the
On 7/13/2016 4:48 AM, John Colvin wrote:
Pointer arithmetic in objects is really quite dangerous w.r.t.
immutability/const.
Right, and one reason why pointer arithmetic isn't allowed in @safe code.
On Thursday, 14 July 2016 at 18:36:26 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 18:23:54 UTC, Chris wrote:
On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad
wrote:
You were going ad hominem for no good reason. Here is a pretty
good rule: if you don't think
On 7/14/16 1:46 PM, Jesse Phillips wrote:
On Thursday, 14 July 2016 at 16:47:20 UTC, Ola Fosheim Grøstad wrote:
On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote:
I still haven't found someone who can explain how C++ can define the
behavior of modifying a variable after casting
On Thursday, 14 July 2016 at 18:23:54 UTC, Chris wrote:
On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad
wrote:
Please don't try to make yourself look like a martyr.
Huh? Where is that coming from all of a sudden? Sorry, I don't
see the point of this comment.
You were going
On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad
wrote:
Please don't try to make yourself look like a martyr.
Huh? Where is that coming from all of a sudden? Sorry, I don't
see the point of this comment. A martyr for what? Martyrs are
stupid people, they should have stayed at
On Thursday, 14 July 2016 at 17:36:59 UTC, Chris wrote:
On Thursday, 14 July 2016 at 15:59:30 UTC, Ola Fosheim Grøstad
wrote:
Not sure what you mean by calling D multi-paradigm.
As opposed to Java that is 100% OOP (well 99%).
Which programming model is it that D supports that Java doesn't?
On Thursday, 14 July 2016 at 16:47:20 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote:
I still haven't found someone who can explain how C++ can
define the behavior of modifying a variable after casting away
const.
C++ is locked down in a
On Thursday, 14 July 2016 at 15:59:30 UTC, Ola Fosheim Grøstad
wrote:
It wasn't pure OOP, not sure what you mean by that either.
Not sure what you mean by calling D multi-paradigm.
As opposed to Java that is 100% OOP (well 99%).
I still don't get the comparison. I don't buy a new
On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote:
I still haven't found someone who can explain how C++ can
define the behavior of modifying a variable after casting away
const.
C++ is locked down in a mine-field of backward compatibility
issues and a need to interface with C
On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh wrote:
C++ fully defines when it is okay to cast away constness, gives
you aids so that you know that that's what you are doing, and
nothing else, and gives you a method by which you can do it
without a cast if the circumstances support
On Thursday, 14 July 2016 at 15:28:45 UTC, Chris wrote:
I don't know much about Simula (your patriotic choice :), but
it's pure OOP and as such cannot be compared to D either (which
is multi-paradigm).
It wasn't pure OOP, not sure what you mean by that either.
Not sure what you mean by
On Thursday, 14 July 2016 at 14:46:50 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 14:11:25 UTC, Chris wrote:
On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
Such a language will never see the light
On Thursday, 14 July 2016 at 14:11:25 UTC, Chris wrote:
On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
Such a language will never see the light of day.
Many such languages exist.
Didn't I say that I don't have
On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
Such a language will never see the light of day.
Many such languages exist.
Like? I mean languages that can be used in the real world.
Certainly not Nim. It's not
On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
Such a language will never see the light of day.
Many such languages exist.
What makes a language attractive is that you can actually use
it - here and now.
What makes a language attractive is that it has system support
and provides
On Thursday, 14 July 2016 at 12:12:34 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 11:38:59 UTC, Chris wrote:
On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote:
Software design is an iterative process because one can't
sort everything at once.
Not true. Ola can. :)
On Thursday, 14 July 2016 at 13:11:36 UTC, Kagamin wrote:
On Thursday, 14 July 2016 at 12:57:06 UTC, Ola Fosheim Grøstad
wrote:
Huh? I need to explain the purpose of building prototypes?
You mean your process describes building prototypes only?
Yes?
You cannot easily iterate over the
1 - 100 of 246 matches
Mail list logo
