www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - On the future of DIP1000

reply Dicebot <public dicebot.lv> writes:
This week I had a tele-meeting with Andrei and Walter regarding 
the fate
of DIP1000 
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
and intented way to move forward with it. This is a short summary 
of the
meeting.

Approval of DIP1000
-------------------

DIP1000 is going to be approved as the basis of the idea
but exact specification may change during implementation and as a 
result
of incorporating some ideas from feedback threads
(http://forum.dlang.org/thread/pqsiqmkxenrwxoruzaml forum.dlang.org and
http://forum.dlang.org/thread/rwxcfapvpfiqmfsuixlf forum.dlang.org).

Core principles that are sure to stay at this point:
- scope is a storage class
- scope is non-transitive
- scope is  safe only
- responsibility of implementing complicated scope-using types is 
on
developer, compiler magic is intended to be minimal

Any changes in intended DIP1000 spec will be reflected in original
document 
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md).

Implementation of DIP1000
-------------------------

Walter is currently working on implementing the support via
https://github.com/dlang/dmd/pull/5972, which will take some 
time. Once
it is more feature complete I'll contact Martin for possible
out-of-release preview compiler builds from that branch to try it 
out
easily. About that time we will start another feedback thread in 
the NG
with a more practical focus - featuring more code examples and 
design
idioms.

Life after DIP1000
------------------

It is acknowledged that DIP1000 itself does not allow to 
implemented
completely  safe reference counting, primarily because of an 
issue with
 trusted destructor and re-assignment. Intention is to follow up 
with
another proposal (not directly related) to address the issue from
another angle - but this will only become in focus after DIP1000 
is
finished.
Aug 21 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:

 - scope is  safe only


Why? I might have  system code that could still benefit from 
scope.
Aug 21 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote:

 On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:

 - scope is  safe only


 Why? I might have  system code that could still benefit from 
 scope.


I guess it would be too restrictive, but I'm just a bit 
frustrated at having to choose between lots of compiler checking 
and none at all. I wish there was a flag for the compiler that 
would give  safe violations as warnings in  system /  trusted 
code, it would be too noisy for routine use but it would be great 
to occasionally look through.
Aug 21 2016
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Sunday, August 21, 2016 21:52:59 John Colvin via Digitalmars-d-announce 
wrote:

 On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote:

 On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:

 - scope is  safe only


 Why? I might have  system code that could still benefit from
 scope.


 I guess it would be too restrictive, but I'm just a bit
 frustrated at having to choose between lots of compiler checking
 and none at all. I wish there was a flag for the compiler that
 would give  safe violations as warnings in  system /  trusted
 code, it would be too noisy for routine use but it would be great
 to occasionally look through.


Well, if you typically try and restrict your  system code to small parts of
your program and use  trusted to turn them into  safe, then the vast
majority of your program will be  safe. As I understand it, that's at least
how it was _intended_ that  system be dealt with - though plenty of folks
just don't bother with  safe, and it's certainly the case that code out
there doesn't restrict the  system portions as much as it could.

So, at least _in theory_, if you're using  safe as intended, even if you
have a fair number of code snippets which are  system, you can take
advantage of stuff like scope in most of your code. I don't know how well
that will work in practice though.

I can think of two big reasons to restrict something like this to  safe code
though. One is that implementing something like this usually means declaring
some stuff illegal that is actually safe, because the compiler can't be
perfect about it (a similar example would be how a lot of lambdas end up
allocating closures in order to be  safe when they don't actually need to;
the compiler simply isn't smart enough to figure out that it isn't necessary
and may or may not be able to with what the language allows the programmer
to do). Another reason is that sometimes in order to make certain
guarantees, the compiler has to be able to assume things that aren't
necessarily true in  system code, even if they happen to be true for most
 system code.

- Jonathan M Davis
Aug 21 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/21/2016 7:01 PM, Jonathan M Davis via Digitalmars-d-announce wrote:

 Well, if you typically try and restrict your  system code to small parts of
 your program and use  trusted to turn them into  safe, then the vast
 majority of your program will be  safe. As I understand it, that's at least
 how it was _intended_ that  system be dealt with - though plenty of folks
 just don't bother with  safe, and it's certainly the case that code out
 there doesn't restrict the  system portions as much as it could.

 So, at least _in theory_, if you're using  safe as intended, even if you
 have a fair number of code snippets which are  system, you can take
 advantage of stuff like scope in most of your code. I don't know how well
 that will work in practice though.

 I can think of two big reasons to restrict something like this to  safe code
 though. One is that implementing something like this usually means declaring
 some stuff illegal that is actually safe, because the compiler can't be
 perfect about it (a similar example would be how a lot of lambdas end up
 allocating closures in order to be  safe when they don't actually need to;
 the compiler simply isn't smart enough to figure out that it isn't necessary
 and may or may not be able to with what the language allows the programmer
 to do). Another reason is that sometimes in order to make certain
 guarantees, the compiler has to be able to assume things that aren't
 necessarily true in  system code, even if they happen to be true for most
  system code.


I agree. If there's a lot of  system code in a program, something has gone awry 
in its design. I understand the desire to be able to turn each individual
safety 
feature on and off, but don't think the code really will be better off that way.
Aug 21 2016
prev sibling parent Dicebot <public dicebot.lv> writes:
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: On the future of DIP1000
References: <taqkzwiezkfylxjinozg forum.dlang.org>
 <ldbntemezuyrakuiacan forum.dlang.org>
In-Reply-To: <ldbntemezuyrakuiacan forum.dlang.org>

--gGoTIpdq2HHXA23HCRbrNRXQk1TSknD5O
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 08/22/2016 12:46 AM, John Colvin wrote:

 On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:

 - scope is  safe only


=20
 Why? I might have  system code that could still benefit from scope.


Because it can't provide expected guarantees within feature set allowed
by  system - it is too permissive for such simple system. Probably
actual scope semantics will remain in  system but it won't guarantee
anything.


--gGoTIpdq2HHXA23HCRbrNRXQk1TSknD5O--
Aug 23 2016
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-08-21 22:01, Dicebot wrote:

 This week I had a tele-meeting with Andrei and Walter regarding the fate
 of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
 and intented way to move forward with it. This is a short summary of the
 meeting.

 Approval of DIP1000
 -------------------

 DIP1000 is going to be approved as the basis of the idea
 but exact specification may change during implementation and as a result
 of incorporating some ideas from feedback threads
 (http://forum.dlang.org/thread/pqsiqmkxenrwxoruzaml forum.dlang.org and
 http://forum.dlang.org/thread/rwxcfapvpfiqmfsuixlf forum.dlang.org).

 Core principles that are sure to stay at this point:
 - scope is a storage class
 - scope is non-transitive
 - scope is  safe only
 - responsibility of implementing complicated scope-using types is on
 developer, compiler magic is intended to be minimal

 Any changes in intended DIP1000 spec will be reflected in original
 document (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md).

 Implementation of DIP1000
 -------------------------

 Walter is currently working on implementing the support via
 https://github.com/dlang/dmd/pull/5972, which will take some time. Once
 it is more feature complete I'll contact Martin for possible
 out-of-release preview compiler builds from that branch to try it out
 easily. About that time we will start another feedback thread in the NG
 with a more practical focus - featuring more code examples and design
 idioms.

 Life after DIP1000
 ------------------

 It is acknowledged that DIP1000 itself does not allow to implemented
 completely  safe reference counting, primarily because of an issue with
  trusted destructor and re-assignment. Intention is to follow up with
 another proposal (not directly related) to address the issue from
 another angle - but this will only become in focus after DIP1000 is
 finished.


It would be nice to have the whole picture now, before implementing 
DIP1000. Then it's possible to review them together, making sure the end 
goal is actual possible to achieve. Now we just have to trust Andrei and 
Walter that all features will come together making the end goal 
possible. We've already seen in the past that some features don't play 
well together.

It's also not possible/harder to come up with alternatives, that might 
work better, if we don't have the whole picture.

I'm also not a big fan that the DIP is approved right from the start. 
Then it's not a DIP, it's more of a FYI. It makes the whole process kind 
of pointless since Andrei and Walter can choose to ignore the feedback.

-- 
/Jacob Carlborg
Aug 21 2016
next sibling parent Robert burner Schadek <rburners gmail.com> writes:
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote:

 It would be nice to have the whole picture now, before 
 implementing DIP1000. Then it's possible to review them 
 together, making sure the end goal is actual possible to 
 achieve. Now we just have to trust Andrei and Walter that all 
 features will come together making the end goal possible. We've 
 already seen in the past that some features don't play well 
 together.

 It's also not possible/harder to come up with alternatives, 
 that might work better, if we don't have the whole picture.

 I'm also not a big fan that the DIP is approved right from the 
 start. Then it's not a DIP, it's more of a FYI. It makes the 
 whole process kind of pointless since Andrei and Walter can 
 choose to ignore the feedback.


What he said !
Aug 21 2016
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote:

 It would be nice to have the whole picture now, before 
 implementing DIP1000.


It can be reviewed after the spec is inferred from 
implementation. But yes, it can be unclear how the implementation 
can affect the review process.
Do you have an alternative design for scope?
Aug 22 2016
prev sibling parent reply Dicebot <public dicebot.lv> writes:
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: On the future of DIP1000
References: <taqkzwiezkfylxjinozg forum.dlang.org>
 <npe6vr$1ud3$1 digitalmars.com>
In-Reply-To: <npe6vr$1ud3$1 digitalmars.com>

--q3A9ffMdisRAfwf5XJnqpPVofiUMHrGij
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 08/22/2016 09:44 AM, Jacob Carlborg wrote:

 It would be nice to have the whole picture now, before implementing
 DIP1000. Then it's possible to review them together, making sure the en=


d

 goal is actual possible to achieve. Now we just have to trust Andrei an=


d

 Walter that all features will come together making the end goal
 possible. We've already seen in the past that some features don't play
 well together.


My understanding is that those are not supposed to be related in any
direct way and danger of  trusted destructor is inherent to DIP1000
design (it should be better clarified in document itself though, see
https://github.com/dlang/DIPs/pull/35)


 I'm also not a big fan that the DIP is approved right from the start.
 Then it's not a DIP, it's more of a FYI. It makes the whole process kin=


d

 of pointless since Andrei and Walter can choose to ignore the feedback.=



By its design definition DIP process is for approving communitty
proposals by Walter/Andrei thus there is no point in pretending they
can't ignore the feedback. Only reason it is even processed in the same
queue is so that developers can track all major proposed changes in one
place.

I would personally prefer to see more of a commitee approach for
validating such changes but that concept is far beyond available
resources and community engagement. If both language authors agree that
certain issue is urgent to solve than, in absence of formally written
counter-proposals, there is no other way but to move ahead.

Again, the DIP process is not for Walter or Andrei - it is for everyone
else wanting to get their attention and submit good quality technical
proposal. I hope authors of already submitted DIPs will improve them to
required content bar and we will see how the process actually work but
that is still to come.

Note that during the meeting I did go through the list of all comments
submitted through the community feedback to ensure that nothing was
simply missed or forgotten and every issue is acknowledged. But all the
decision making is 100% for Andrei/Walter in the end and I don't see how
it can be different with existing state of affairs.


--q3A9ffMdisRAfwf5XJnqpPVofiUMHrGij--
Aug 23 2016
parent reply Martin Nowak <code dawg.eu> writes:
On Tuesday, 23 August 2016 at 18:37:46 UTC, Dicebot wrote:

 By its design definition DIP process is for approving 
 communitty proposals by Walter/Andrei thus there is no point in 
 pretending they can't ignore the feedback. Only reason it is 
 even processed in the same queue is so that developers can 
 track all major proposed changes in one place.


Well the fact that we have a public review and can criticize the 
proposal is as much as you can get from a peer reviewed process. 
If you have valid and important arguments they won't just get 
ignored.
In fact [DIP74](http://wiki.dlang.org/DIP74) faced a lot of 
criticism for not properly addressing escape checking first, 
that's one of the main reasons why we have DIP1000 now.
The overall goal is also clear and has been stated 
([Vision/2016H2 - D 
Wiki](https://wiki.dlang.org/Vision/2016H2#H2_2016_Priorities)), 
we want memory safe code w/o the GC.

-Martin
Aug 24 2016
parent reply Bill Hicks <billhicks gmail.com> writes:
On Wednesday, 24 August 2016 at 15:30:34 UTC, Martin Nowak wrote:

  we want memory safe code w/o the GC.

 -Martin


Rust has had that since day one.  Funny how not too long ago D 
core was mocking Rust, but now they're trying to be more like it. 
  I bet in a few years we'll see hygienic macro system in D.
Aug 26 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2016 9:53 PM, Bill Hicks wrote:

 On Wednesday, 24 August 2016 at 15:30:34 UTC, Martin Nowak wrote:

  we want memory safe code w/o the GC.

 -Martin


 Rust has had that since day one.  Funny how not too long ago D core was mocking
 Rust,


We've never mocked Rust's safety features, although I have posted that they are 
too complex for D and desire a simpler system.



 but now they're trying to be more like it.


We've had proposals for more safety annotation in D for at least 10 years (from 
Bartosz Milewski), but they've always been more complex than I wanted. DIP1000 
is a much simpler scheme.



 I bet in a few years we'll see hygienic macro system in D.


I seriously doubt it (they've been proposed many times). I haven't studied 
Rust's macro system, but others I've seen (expression templates, user defined 
syntax, CPP, macro assemblers, etc.) are very powerful, but ultimately 
off-putting because it makes code very hard to understand.

For example, Microsoft put a very powerful macro system in their assembler, 
MASM. Programmers went to town with it, each programmer essentially inventing 
their own language that was undocumented and unreadable to anyone else. A 
Microsoft programmer related to me that once he was given the job of updating a 
large assembler program that someone no longer there had written in their own 
invented macro language.

He got it updated and fixed in short order. Surprised, his manager asked him
how 
he figured out how it worked, as everyone else who tried had failed.
My friend said he didn't even attempt to figure it out. He assembled it, and
ran 
the result through a disassembler (our very own OBJ2ASM) which made it nice, 
readable, and fixable.

An earlier incarnation of myself had also succumbed to the siren song of 
inventing my own assembler language via macros. Over time, I gradually stopped 
using it and reverted to writing vanilla, understandable assembler.

I've seen the story repeated with CPP macros and expression templates, and I've 
heard similar accounts about other macro systems.

Making macros hygienic doesn't fix it.

P.S. I still from time to time use OBJ2ASM to figure out what someone's
wretched 
ASM file is doing, like I'll run CPP by itself to see what some miserable CPP 
abuse is actually generating. I've also been gradually removing all CPP use
from 
my own C++ code (the dmd back end).

A macro system is like putting a 2000 HP motor in a car. It's sure exciting,
but 
ultimately you just don't want it in a daily driver, or anyplace other than the 
track, because it'll kill you.
Aug 26 2016
parent reply Bill Hicks <billhicks gmail.com> writes:
On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright wrote:

 We've never mocked Rust's safety features, although I have 
 posted that they are too complex for D and desire a simpler 
 system.


"A disharmonic personality. Reading any amount of Rust code 
evokes the joke 'friends don't let friends skip leg day' and the 
comic imagery 
(https://www.google.com/search?q=friends+don%27t+let+friends+skip+leg+day&safe=off&tbm=isch&tbo=u&source=univ&sa=X&ved=0CB0QsARqFQoTCM_ViveKhMkCFUfZPgodVsgLs
&biw=1582&bih=1352) of men with hulky torsos resting on skinny legs".  --Andrei

If that's not mockery, then how would you describe it?


 but now they're trying to be more like it.


 We've had proposals for more safety annotation in D for at 
 least 10 years (from Bartosz Milewski), but they've always been 
 more complex than I wanted. DIP1000 is a much simpler scheme.


And he continues:

"Unfortunately, that's seldom the problem domain, which means a 
large fraction of the thinking and coding are dedicated to 
essentially a clerical job (which GC languages actually automate 
out of sight). Safe, deterministic memory reclamation is a hard 
problem, but is not the only problem or even the most important 
problem in a program". --Andrei

It should be quiet obvious that a non-optional GC does not belong 
in a language that claims to be a system programming language.  
Not only that, but for all these years D has had a rather poor 
GC.  At last we've witnessed the removal of GC usage from Phobos, 
and, if my understanding is correct, y'all trying to change the 
role GC plays in the language.  So maybe the Rust folks know 
something Dr. Andrei doesn't?  And why criticize Rust just 
because they've taken a potentially better approach to memory 
management while 'D has had the downsides of GC but hasn't 
enjoyed its benefits'?  Besides, if you can't please the 
Linux-kernel-developer type, then you ain't got a system 
programming language.  And if we are honest, I don't think D fits 
anywhere.


 I bet in a few years we'll see hygienic macro system in D.


 I seriously doubt it (they've been proposed many times). I 
 haven't studied Rust's macro system, but others I've seen 
 (expression templates, user defined syntax, CPP, macro 
 assemblers, etc.) are very powerful, but ultimately off-putting 
 because it makes code very hard to understand.

  ...

 A macro system is like putting a 2000 HP motor in a car. It's 
 sure exciting, but ultimately you just don't want it in a daily 
 driver, or anyplace other than the track, because it'll kill 
 you.


I'm not a big fan of macros either, but should we ban chainsaws 
too because they have the potential to cause serious injuries?  
The problem with misuse of features like macros is lack of proper 
training and education, not so much the features themselves.  
Large percentage of professional developers don't even have a 
degree in CS/SE, and they lack proper training.  Most of them 
become developers because of the money, and many of them get 
hired for the wrong reasons (just look at the interview process), 
and these are the kinds of developers responsible for large 
percentage of the garbage code that's out there.  Corporations 
that hire them care mostly about producing the largest amount of 
code in the shortest amount of time to increase earnings and 
profits.  Many helper tools and dumbed-down languages have 
already been created particularly for these kinds of crowds.

Unfortunately, we see a similar pattern in other areas.  The 
dumbing down of society and the deteriorating education system is 
not an accident.  Just compare the writing skills of the average 
person from, say, the 1930s to what we have today, not to mention 
their level of intellect.  And today we have spell checkers and 
software to check grammar, how amusing.  Should we make changes 
to the English language to help these people make fewer mistakes?
Aug 27 2016
next sibling parent reply Anonymouse <asdf asdf.net> writes:
On Saturday, 27 August 2016 at 15:19:40 UTC, Bill Hicks wrote:

 On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright 
 wrote:

 We've never mocked Rust's safety features, although I have 
 posted that they are too complex for D and desire a simpler 
 system.


 "A disharmonic personality. Reading any amount of Rust code 
 evokes the joke 'friends don't let friends skip leg day' and 
 the comic imagery 
 (https://www.google.com/search?q=friends+don%27t+let+friends+skip+leg+day&safe=off&tbm=isch&tbo=u&source=univ&sa=X&ved=0CB0QsARqFQoTCM_ViveKhMkCFUfZPgodVsgLs
&biw=1582&bih=1352) of men with hulky torsos resting on skinny legs".  --Andrei

 If that's not mockery, then how would you describe it?


On my phone so can only speak from memory, but if it serves then 
he went on to equally criticise D for its warts and blemishes. It 
would be cherry-picking to ignore context and just say that he 
threw mockery at rust.
Aug 27 2016
parent reply Dicebot <public dicebot.lv> writes:
On Saturday, 27 August 2016 at 15:34:04 UTC, Anonymouse wrote:

 ...


Please never reply to that person unless you are his other 
account. Not in an announce threads at least.
Aug 27 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2016 9:04 AM, Dicebot wrote:

 Please never reply to that person unless you are his other account. Not in an
 announce threads at least.


If the post is reasonably professional, it's ok to. Abusive posts just get
deleted.
Aug 27 2016
parent reply Dicebot <public dicebot.lv> writes:
On Saturday, 27 August 2016 at 20:54:02 UTC, Walter Bright wrote:

 On 8/27/2016 9:04 AM, Dicebot wrote:

 Please never reply to that person unless you are his other 
 account. Not in an
 announce threads at least.


 If the post is reasonably professional, it's ok to. Abusive 
 posts just get deleted.


There have never been a single professional or at least 
constructively fashioned post from that account and tolerating 
that harms D public image. I have learned not to argue about this 
but I am very unhappy that you not only allow but encourage both 
off-topic and flamebait derailing of _announcement_ threads.
Aug 28 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/28/2016 3:39 AM, Dicebot wrote:

 There have never been a single professional or at least constructively
fashioned
 post from that account and tolerating that harms D public image. I have learned
 not to argue about this but I am very unhappy that you not only allow but
 encourage both off-topic and flamebait derailing of _announcement_ threads.


Off-topic always happens anyway, but it's fair I should have suggested starting 
a new thread. But I thought the discussion of macros was reasonable. Criticism 
of D is ok. His abusive posts were deleted, though it's not possible to delete 
things from the mail interface, and sometimes it takes a while for the dforum 
software to sync.

It isn't really practical to ban individuals, because an account is not 
necessary to post. We can only delete posts. I also like to believe people are 
redeemable and will give anyone a second chance if they'll comport themselves 
appropriately.

I also try to err on the side of being permissive, though nearly all of his 
posts were so far over the line there was no head scratching to be done.
Aug 28 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2016 8:19 AM, Bill Hicks wrote:

I believe Andrei's point was that Rust had focused on one problem to the 
relative exclusion of others, not that memory safety was unimportant. Rust, to 
its credit, has changed the perception of the importance of memory safety.



 I bet in a few years we'll see hygienic macro system in D.


 I seriously doubt it (they've been proposed many times). I haven't studied
 Rust's macro system, but others I've seen (expression templates, user defined
 syntax, CPP, macro assemblers, etc.) are very powerful, but ultimately
 off-putting because it makes code very hard to understand.


 I'm not a big fan of macros either, but should we ban chainsaws too because
they
 have the potential to cause serious injuries?


Every language bans certain things because they are too powerful and too 
error-prone. For example, monkey-patching in Ruby - it is undeniably powerful, 
but people are moving away from Ruby because it just isn't worth it.



 The problem with misuse of
 features like macros is lack of proper training and education, not so much the
 features themselves.


This argument is often put forward as the solution, but it just does not scale. 
This is why so, so much code has security bugs in it. Heck, the whole reason 
people move from C to Rust is because education and training have proved 
inadequate to get safe code written in C, despite decades of trying.



 Large percentage of professional developers don't even
 have a degree in CS/SE, and they lack proper training.  Most of them become
 developers because of the money, and many of them get hired for the wrong
 reasons (just look at the interview process), and these are the kinds of
 developers responsible for large percentage of the garbage code that's out
 there.  Corporations that hire them care mostly about producing the largest
 amount of code in the shortest amount of time to increase earnings and profits.
 Many helper tools and dumbed-down languages have already been created
 particularly for these kinds of crowds.


Abuse of macros is hardly confined to poorly trained developers. I've seen
paper 
after paper with complex macro abuse presented at conferences by top 
professionals, even PhDs.

(I'm also sure that in their opinion these are legitimate uses of macros. My 
opinion on macros is hardly universal.)



 Unfortunately, we see a similar pattern in other areas.  The dumbing down of
 society and the deteriorating education system is not an accident.  Just
compare
 the writing skills of the average person from, say, the 1930s to what we have
 today, not to mention their level of intellect.  And today we have spell
 checkers and software to check grammar, how amusing.  Should we make changes to
 the English language to help these people make fewer mistakes?


There are a lot of specialized variants of English that attempt to remove 
mistakes, ambiguities, and nail down meanings.

BTW, I don't agree there ever was a golden age of education in America.
Aug 27 2016
next sibling parent Meta <jared771 gmail.com> writes:
Best to add him to your killfile instead of responding.
Aug 27 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2016 11:58 PM, Bill Hicks wrote:

 white men


There are plenty of other forums for politics. Not this one.

You've had a couple of worthwhile posts, you're welcome to stay and continue in 
that vein. Posts with unprofessional behavior, politics, etc., will be simply 
deleted.
Aug 28 2016
parent Bill Hicks <billhicks gmail.com> writes:
On Sunday, 28 August 2016 at 07:43:47 UTC, Walter Bright wrote:

 You've had a couple of worthwhile posts, you're welcome to stay 
 and continue in that vein. Posts with unprofessional behavior, 
 politics, etc., will be simply deleted.


D deserved someone better than a person like Andrei, but it 
doesn't matter anymore.

Goodbye Mr. Bright, and good luck to D.
Aug 28 2016
prev sibling parent reply Andrej Mitrovic via Digitalmars-d-announce writes:
On 8/21/16, Dicebot via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 This week I had a tele-meeting with Andrei and Walter regarding
 the fate
 of DIP1000
 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)


Trivia question: why is it named DIP 1000? We've had less than 100
DIPs before https://github.com/dlang/DIPs was opened, the jump seems
very arbitrary to me (and it makes it appear as if we had a thousand
DIPs already to the outsiders)
Aug 26 2016
parent Dicebot <public dicebot.lv> writes:
On Saturday, 27 August 2016 at 06:37:58 UTC, Andrej Mitrovic 
wrote:

 On 8/21/16, Dicebot via Digitalmars-d-announce 
 <digitalmars-d-announce puremagic.com> wrote:

 This week I had a tele-meeting with Andrei and Walter regarding
 the fate
 of DIP1000
 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)


 Trivia question: why is it named DIP 1000? We've had less than 
 100 DIPs before https://github.com/dlang/DIPs was opened, the 
 jump seems very arbitrary to me (and it makes it appear as if 
 we had a thousand DIPs already to the outsiders)


To clearly disambugate all new DIPs from all old ones by the 
number only.
Aug 27 2016