On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote:
D is probably at the edge of what I can tollerate
complexity-wise. And we’ll get to simplify a few things soon I
believe.
There is the core of the problem.
Because you want to understand it all, therefore it must be
simplifie
On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
It seems C++ is following the road of PL/I, which is growing
language way beyond the point anyone can understand or
implement all of it.
A key line from this paper
We now have about 150 cooks; that’s not a good way to get a
ta
On Tuesday, 29 May 2018 at 04:41:33 UTC, Komplex wrote:
On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
It seems C++ is following the road of PL/I, which is growing
language way beyond the point anyone can understand or
implement all of it.
but that happened to the linux ke
On Tuesday, May 29, 2018 03:43:00 TheMightWarship via Digitalmars-d wrote:
> On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
> > A cautionary tale we should all keep in mind.
> >
> > http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
> >
> > https://www.reddit.com/r/progr
On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
It seems C++ is following the road of PL/I, which is growing
language way beyond the point anyone can understand or
implement all of it.
but that happened to the linux kernel too, long ago?
and yet...it's everywhere..and incre
On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjar
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
https://news.ycombin
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
https://news.ycombin
On 5/28/2018 6:54 PM, 12345swordy wrote:
No doubt that all this complexity is partially due to having a religious like
zeal when it comes to preserving backwards compatibility.
I mean create a new official file extension, so that it can make much needed
breaking changes on it.
For all the fa
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
https://news.ycombin
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
https://news.ycombinator.com/item?id=17172057
On Monday, 28 May 2018 at 07:52:43 UTC, Adam Wilson wrote:
I understand that.
Sorry, not for nothing, but you obviously don't. For starters,
if you were familiar with the key derivation tools available
24hrs ago, you wouldn't have come up with PBKDF2 on PBKDF2. I
suggest slowing down a lit
On Monday, 28 May 2018 at 22:37:01 UTC, sarn wrote:
On Monday, 28 May 2018 at 20:13:47 UTC, 12345swordy wrote:
[...]
Code using destroy() can still use destroy(). Otherwise,
__vdtor would be callable in the same way that __dtor and
__xdtor are.
[...]
Interesting... You don't mind me ask
On Monday, 28 May 2018 at 20:13:47 UTC, 12345swordy wrote:
How is __vdtor is going to be called, via destroy or via
directly?
Code using destroy() can still use destroy(). Otherwise, __vdtor
would be callable in the same way that __dtor and __xdtor are.
The plan is to have a better, safer,
On Monday, 28 May 2018 at 04:26:02 UTC, sarn wrote:
On Sunday, 27 May 2018 at 22:27:52 UTC, sarn wrote:
I've been thinking this through a bit, and here's what I've
got so far:
Here's a tweak that should be implementable without any
language changes:
Instead of trying to detect an empty dest
On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar
wrote:
Now that D has a better C option I was wondering if it is
possible to create a small subset of D that can be used as
embedded JIT library. I would like to trim the language to a
small subset of D/C - only primitive types and po
Might be interesting to checkout to find some optimization potential:
https://github.com/dyu/ffi-overhead
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
On 28/05/2018 10:16 PM, Robert M. Münch wrote:
Might be interesting to checkout to find some optimization potential:
https://github.com/dyu/ffi-overhead
https://github.com/dyu/ffi-overhead/issues/5
On 05/28/2018 12:14 AM, sarn wrote:
On Monday, 28 May 2018 at 06:22:02 UTC, Adam Wilson wrote:
On 05/27/2018 08:52 PM, sarn wrote:
On Monday, 28 May 2018 at 02:25:20 UTC, Adam Wilson wrote:
I like it. But it does require more space. We need three salts and
three lengths in the header. One for
On Monday, 28 May 2018 at 06:22:02 UTC, Adam Wilson wrote:
On 05/27/2018 08:52 PM, sarn wrote:
On Monday, 28 May 2018 at 02:25:20 UTC, Adam Wilson wrote:
I like it. But it does require more space. We need three
salts and three lengths in the header. One for the PBKDF2
KDK, one for the MAC key,
20 matches
Mail list logo
