www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Idiotmatic D

reply "Brian Schott" <briancschott gmail.com> writes:
We all know how nice well-written idiomatic D code looks, but I 
think it's time that we try to really explore the full power of 
the language.

To further this goal, I've started the Idiotmatic D repository on 
Github. It is a place where we do not just ask, "What should we 
do?, but also ask, "What CAN we do?". I aim to create examples of 
clean-ish idiotmatic code for those new to D to follow (at their 
own peril).

The rules are simple: The code does not have to run, but it does 
have to compile.

Contributors are encouraged to do things like look at the 
Declarations page of the language reference and ask themselves 
"Does this mean that I'm allowed to _____?" where the blank is 
filled in with a really bad idea.

For instance the code:

alias double ["a" .. "whatever"] ( * foo []) [123.45f];

is both syntactically valid and banned by international war 
crimes treaties.

Does the spec let you do it but the compiler stops you? Leave it 
in, but commented out.
Does the spec let you do it and the compiler agrees? Good.
Does the spec disallow it but the compiler doesn't even issue a 
warning? Excellent.

https://github.com/Hackerpilot/Idiotmatic-D
Feb 01 2014
next sibling parent reply "qznc" <qznc web.de> writes:
On Sunday, 2 February 2014 at 01:50:50 UTC, Brian Schott wrote:

 To further this goal, I've started the Idiotmatic D repository 
 on Github. It is a place where we do not just ask, "What should 
 we do?, but also ask, "What CAN we do?". I aim to create 
 examples of clean-ish idiotmatic code for those new to D to 
 follow (at their own peril).


I think it was John Carmack who said, "whatever is syntactically 
valid will some day be in your codebase."
Feb 02 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 3 February 2014 at 07:18:39 UTC, qznc wrote:

 I think it was John Carmack who said, "whatever is 
 syntactically valid will some day be in your codebase."


One of the reasons that I want to push for decreasing the number 
of thing that are syntactically valid.

Right now we have a mess of inaccurate specs, a compiler front 
end that accepts whatever the heck it feels like, and a culture 
of rumors and legends surrounding what's (going to be) deprecated 
and what isn't.
Feb 02 2014
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 2/2/14, 11:30 PM, Brian Schott wrote:

 On Monday, 3 February 2014 at 07:18:39 UTC, qznc wrote:

 I think it was John Carmack who said, "whatever is syntactically valid
 will some day be in your codebase."


 One of the reasons that I want to push for decreasing the number of
 thing that are syntactically valid.

 Right now we have a mess of inaccurate specs, a compiler front end that
 accepts whatever the heck it feels like, and a culture of rumors and
 legends surrounding what's (going to be) deprecated and what isn't.


Hyperbole much?
Feb 02 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 3 February 2014 at 07:51:39 UTC, Brad Roberts wrote:

 Hyperbole much?


It is clear which features are going to be deprecated, and we 
know when and why.
The parser complies with the grammar specification.

Are these statements true?
Feb 03 2014
next sibling parent "fra" <a b.it> writes:
On Monday, 3 February 2014 at 08:02:45 UTC, Brian Schott wrote:

 On Monday, 3 February 2014 at 07:51:39 UTC, Brad Roberts wrote:

 Hyperbole much?


 It is clear which features are going to be deprecated, and we 
 know when and why.
 The parser complies with the grammar specification.

 Are these statements true?


No, but them being false does not make your previous ones true 
either.
Anyway, I ike the idea behind yor repo. If I happen to find 
anything interesting, I will contribute for sure!
Feb 03 2014
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 2/3/14, 12:02 AM, Brian Schott wrote:

 On Monday, 3 February 2014 at 07:51:39 UTC, Brad Roberts wrote:

 Hyperbole much?


 It is clear which features are going to be deprecated, and we know when
 and why.
 The parser complies with the grammar specification.

 Are these statements true?


Nope.  But neither was your previous one.  Which of the two is closer to 
true?  This set, by a large margin.

Exaggeration and vague statements of problems does nothing other than 
inflame and spread FUD.
Feb 03 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 3 February 2014 at 08:38:16 UTC, Brad Roberts wrote:

 Nope.  But neither was your previous one.  Which of the two is 
 closer to true?  This set, by a large margin.

 Exaggeration and vague statements of problems does nothing 
 other than inflame and spread FUD.


I've listed many specifics before, but you'll have to hunt the 
newsgroup to find them. I'm sure they're right next to the 
official plan for the "delete" keyword, the "!<>" operator, and 
imaginary number literals.

How about the "D Logo and Slogan" thread? There's still confusion 
about which of the two equivalent alias syntaxes is more correct. 
I apparently made a static analysis rule that asks users to use 
the wrong one.

The "Which tools do you miss in D?" thread: A lot of these tools 
don't exist because the process of developing D tooling is an 
incredibly painful process of looking at the spec, Phobos, DMD's 
source code, and experimentation to figure out what D is, and 
even after having done all that I'm still not sure.

The real problem is that I don't think we care. Several people 
spoke about this at DConf last year and the only thing that's 
happened since then is that I've made people annoyed.
Feb 03 2014
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 3 February 2014 at 09:43:42 UTC, Brian Schott wrote:

 I've listed many specifics before, but you'll have to hunt the 
 newsgroup to find them. I'm sure they're right next to the 
 official plan for the "delete" keyword, the "!<>" operator, and 
 imaginary number literals.


So, here? http://dlang.org/deprecate.html


 The real problem is that I don't think we care. Several people 
 spoke about this at DConf last year and the only thing that's 
 happened since then is that I've made people annoyed.


Considering that fixing these problems are tedious and
unrewarding tasks, it's not surprising that so few people step up
to do it. Considering that this task does not require as much
knowledge/experience as, e.g., hacking the compiler, IMHO the
best people to get it done is those who actually need them done.
Feb 03 2014
parent reply "Mike" <none none.com> writes:
On Monday, 3 February 2014 at 11:37:15 UTC, Vladimir Panteleev 
wrote:

 So, here? http://dlang.org/deprecate.html


That list is not complete.  I know of two that aren't on this 
list:
1) alias {newSymbol} {existingSymbol};
2) new(...) allocator.  delete is there, but new isn't



 Considering that fixing these problems are tedious and
 unrewarding tasks, it's not surprising that so few people step 
 up
 to do it.


Agreed, but...


 Considering that this task does not require as much
 knowledge/experience as, e.g., hacking the compiler, IMHO the
 best people to get it done is those who actually need them done.


IMHO the best people to get it done are the ones who implement or 
change the feature.  The job isn't finished until they've done so.

Mike
Feb 06 2014
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Friday, 7 February 2014 at 00:38:21 UTC, Mike wrote:

 IMHO the best people to get it done are the ones who implement 
 or change the feature.  The job isn't finished until they've 
 done so.

 Mike


Adding to this point: The people who need to look at the docs are 
almost by definition not qualified to write them.
Feb 06 2014
parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Friday, 7 February 2014 at 01:40:38 UTC, Brian Schott wrote:

 On Friday, 7 February 2014 at 00:38:21 UTC, Mike wrote:

 IMHO the best people to get it done are the ones who implement 
 or change the feature.  The job isn't finished until they've 
 done so.

 Mike


 Adding to this point: The people who need to look at the docs 
 are almost by definition not qualified to write them.


That is true to an extent, but I also think that in terms of 
writing documentation that is helpful to beginners, it is often 
useful to have it written by someone who is, or recently was, a 
beginner themselves. Often these individuals have a fresh memory 
of what concepts they struggled with, and what was vague in the 
documents.

It is sort of like how you can "wtre a snetecne in soem langauge 
and a procfient readr can stlil raed it, even if you psell all 
the wrods wrnog", because they almost sub-conciously correct all 
the mistakes. The same likely holds for documentation, where the 
expert can read the documentation and without even thinking fill 
in all the blanks without realizing what the blanks are.

In this respect I think even people new to the language can make 
a useful contribution.
Feb 07 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Mike"  wrote in message news:xtizbktwrvedtszcawhj forum.dlang.org...

 That list is not complete.  I know of two that aren't on this list:
 1) alias {newSymbol} {existingSymbol};


Not deprecated.


 2) new(...) allocator.  delete is there, but new isn't


It has definitely been talked about, but that != officially deprecated.


 IMHO the best people to get it done are the ones who implement or change 
 the feature.  The job isn't finished until they've done so.


I can't speak for all the other contributors, but if this was a requirement 
I would fix less bugs.  I have zero interest in writing documentation and 
interest is what drives me to generate compiler patches in my spare time.

I wrote most of the deprecated features page and by the end I wanted to blow 
my brains out.
Feb 06 2014
parent reply "Mike" <none none.com> writes:
On Friday, 7 February 2014 at 03:36:32 UTC, Daniel Murphy wrote:

 "Mike"  wrote in message 
 news:xtizbktwrvedtszcawhj forum.dlang.org...

 That list is not complete.  I know of two that aren't on this 
 list:
 1) alias {newSymbol} {existingSymbol};


 Not deprecated.


 2) new(...) allocator.  delete is there, but new isn't


 It has definitely been talked about, but that != officially 
 deprecated.


This is exactly what I'm talking about.  You claim to know what 
is and isn't deprecated, but others in this community have stated 
otherwise.  How do you know? You got the information from 
somewhere, where did you get it?

Perhaps these features are not "deprecated", but "discouraged".  
We need to know that too.

I'm in the process of modelling a 1500 page MCU datasheet in D.  
Each field in each register is modeled with an "alias" statement. 
  There will be several hundred of these when I'm done.  I already 
went down one path based on the documentation.  Then the 
community told me it was deprecated and I should go the other way.

So, I submitted a pull request to update the documentation, and 
it was merged.

I was even going to take on the task of modifying the D Runtime 
to use the supposedly "new" syntax, in an effort to be helpful.  
Now I'm not so sure I should.

I also began building a class hierarchy based on the new(...) and 
destroy(), based on the documentation.  Only to find a day or so 
ago that new(...) is discouraged/deprecated.


 I can't speak for all the other contributors, but if this was a 
 requirement I would fix less bugs.  I have zero interest in 
 writing documentation and interest is what drives me to 
 generate compiler patches in my spare time.



 I wrote most of the deprecated features page and by the end I 
 wanted to blow my brains out.


I don't really like updating the GDC wiki, migrating its bug 
reports, or submitting pull request to fix DLang.org 
documentation, but I did/do it because I care and I want these 
efforts to succeed.

Mike
Feb 06 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Mike"  wrote in message news:ncdrqamncpbgfltaqrqe forum.dlang.org...

 This is exactly what I'm talking about.  You claim to know what is and 
 isn't deprecated, but others in this community have stated otherwise.  How 
 do you know? You got the information from somewhere, where did you get it?


Reading this newsgroup, discussion on github, and bugzilla.


 Perhaps these features are not "deprecated", but "discouraged".  We need 
 to know that too.


Many many features have been proposed for deprecation.  Most of those 
discussions have gone nowhere.  Different people have different ideas about 
what should be discouraged.

eg foreach_reverse


 I'm in the process of modelling a 1500 page MCU datasheet in D.  Each 
 field in each register is modeled with an "alias" statement. There will be 
 several hundred of these when I'm done.  I already went down one path 
 based on the documentation.  Then the community told me it was deprecated 
 and I should go the other way.


The community was wrong, it is not deprecated.  The new syntax is generally 
preferred because it is easier to read etc


 So, I submitted a pull request to update the documentation, and it was 
 merged.

 I was even going to take on the task of modifying the D Runtime to use the 
 supposedly "new" syntax, in an effort to be helpful.  Now I'm not so sure 
 I should.


Updating the documentation to reflect best practices is always useful. 
Changing existing code is less of a sure thing, although in this case I 
doubt you'd get much opposition.  If you're worried about wasting your time 
with a pull request that gets rejected, start with one file and see if 
there's any interest from those with commit access.


 I also began building a class hierarchy based on the new(...) and 
 destroy(), based on the documentation.  Only to find a day or so ago that 
 new(...) is discouraged/deprecated.


Unlike many of the officially deprecated features, this one is pretty easy 
to ignore and doesn't seem to cause any bugs.  This makes deciding what to 
do with it rather unimportant.

So, it has an uncertain future and questionable value, and this would 
probably mean a pull request using this in phobos would not be accepted. 
You can still do whatever you like in your own code.


 I don't really like updating the GDC wiki, migrating its bug reports, or 
 submitting pull request to fix DLang.org documentation, but I did/do it 
 because I care and I want these efforts to succeed.


The great thing about being a volunteer is that you can work on the things 
you care about, and nothing else.  The situation improves by more people 
caring about the documentation, not by insisting that the people who don't 
care work on it too.

Andrei declaring we should spend effort on different areas is only binding 
for the non-volunteers, although it does help the community know that effort 
in those areas is desired.
Feb 06 2014
next sibling parent reply "Mike" <none none.com> writes:
On Friday, 7 February 2014 at 05:39:29 UTC, Daniel Murphy wrote:

 "Mike"  wrote in message

 The great thing about being a volunteer is that you can work on 
 the things you care about, and nothing else.  The situation 
 improves by more people caring about the documentation, not by 
 insisting that the people who don't care work on it too.


I'm finding too many floating turds, and so I ask, not insist, 
that people take the time to flush when they're done.
Feb 07 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/7/14, 3:10 AM, Mike wrote:

 On Friday, 7 February 2014 at 05:39:29 UTC, Daniel Murphy wrote:

 "Mike"  wrote in message

 The great thing about being a volunteer is that you can work on the
 things you care about, and nothing else.  The situation improves by
 more people caring about the documentation, not by insisting that the
 people who don't care work on it too.


 I'm finding too many floating turds, and so I ask, not insist, that
 people take the time to flush when they're done.


Now that's a good read over coffee :o).

Andrei
Feb 07 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Daniel Murphy:


 Unlike many of the officially deprecated features, this one is 
 pretty easy to ignore and doesn't seem to cause any bugs.  This 
 makes deciding what to do with it rather unimportant.

 So, it has an uncertain future and questionable value, and this 
 would probably mean a pull request using this in phobos would 
 not be accepted. You can still do whatever you like in your own 
 code.


Its recent warn/deprecation request:
http://d.puremagic.com/issues/show_bug.cgi?id=12081

Bye,
bearophile
Feb 07 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2014 10:43 AM, Brian Schott wrote:

 The real problem is that I don't think we care.


I care, but I don't believe in the official D grammar and would rather 
approach this problem by rewriting both grammar and parser completely in 
such a way that the grammar becomes legible and code that _looks_ legal 
becomes legal and code that _looks_ illegal becomes illegal.
Feb 03 2014
prev sibling parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Monday, 3 February 2014 at 07:30:45 UTC, Brian Schott wrote:

 Right now we have a mess of inaccurate specs, a compiler front 
 end that accepts whatever the heck it feels like, and a culture 
 of rumors and legends surrounding what's (going to be) 
 deprecated and what isn't.


Are you proposing to fork DMD and lead the way?
Feb 04 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 4 February 2014 at 16:06:49 UTC, Steve Teale wrote:

 Are you proposing to fork DMD and lead the way?


Why not? The license grants the original author rights to merge 
changes back in. Maybe some new ideas come about.
Feb 04 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 4 February 2014 at 17:23:06 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 4 February 2014 at 16:06:49 UTC, Steve Teale wrote:

 Are you proposing to fork DMD and lead the way?


 Why not? The license grants the original author rights to merge 
 changes back in. Maybe some new ideas come about.


The problems we have are not worth forking the language.

I volunteer to help or lead an effort to clean up the spec. 
People are going to be investigating and starting to learn D in 
larger numbers with DConf coming up, and it's not fair for them 
to try learning from documentation that is proven to be 
incomplete and inaccurate.

The grammar that I'd be basing this rewrite off of is located 
here:
https://rawgithub.com/Hackerpilot/DGrammar/master/grammar.html
Feb 04 2014
parent "Mike" <none none.com> writes:
On Tuesday, 4 February 2014 at 23:02:54 UTC, Brian Schott wrote:

 People are going to be investigating and starting to learn D in 
 larger numbers with DConf coming up, and it's not fair for them 
 to try learning from documentation that is proven to be 
 incomplete and inaccurate.


Amen!

I'm one of those.  Much of my time in the past few weeks has been 
spent stumbling through some of the documentation, and making 
mistakes as a result of it.  I've submitted a couple pull 
requests to DLang.org, and I hope I can do more, but I need 
clarification to my questions on Learn, first.

Overall, the documentation is ok, but I'm coming away 
disappointed, especially given Andre's inspirational talk about 
operational professionalism.

Mike
Feb 06 2014
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/2/14, Brian Schott <briancschott gmail.com> wrote:

 We all know how nice well-written idiomatic D code looks, but I
 think it's time that we try to really explore the full power of
 the language.


D is the tersest language around, just observe how I can make
functions returning functions with ease:

void main()
{
    (() => (){})()();
}
Feb 04 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 4 February 2014 at 22:53:30 UTC, Andrej Mitrovic 
wrote:

 D is the tersest language around, just observe how I can make
 functions returning functions with ease:

 void main()
 {
     (() => (){})()();
 }


Nice. Can you create a pull request for that?
Feb 04 2014
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 4 February 2014 at 22:53:30 UTC, Andrej Mitrovic 
wrote:

 On 2/2/14, Brian Schott <briancschott gmail.com> wrote:

 We all know how nice well-written idiomatic D code looks, but I
 think it's time that we try to really explore the full power of
 the language.


 D is the tersest language around, just observe how I can make
 functions returning functions with ease:

 void main()
 {
     (() => (){})()();
 }


I call this one the Programmer's Hairbrush:

void main()
{
	(()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 ()=>
	 (){}
	 )
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	()
	;
}

http://dpaste.dzfl.pl/490d5e6707f8
Feb 04 2014
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/5/14, Meta <jared771 gmail.com> wrote:

 I call this one the Programmer's Hairbrush.


Lol, nice.
Feb 05 2014
prev sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 4 February 2014 at 23:05:40 UTC, Meta wrote:

 On Tuesday, 4 February 2014 at 22:53:30 UTC, Andrej Mitrovic 
 wrote:

 On 2/2/14, Brian Schott <briancschott gmail.com> wrote:

 We all know how nice well-written idiomatic D code looks, but 
 I
 think it's time that we try to really explore the full power 
 of
 the language.


 D is the tersest language around, just observe how I can make
 functions returning functions with ease:

 void main()
 {
    (() => (){})()();
 }


 I call this one the Programmer's Hairbrush:

 void main()
 {
 	(()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 ()=>
 	 (){}
 	 )
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	()
 	;
 }

 http://dpaste.dzfl.pl/490d5e6707f8


Hey, you can use this pattern to generate all sort of compilable 
D-art (Sorry, I am kind of busy with work, or I would have come 
up with something a bit nicer, but it does compile!

void main()
{
          (()        =>()     =>()=>      ()=>()=>()
          =>       ()=> ()=>()=>  ()=>    ()        =>
          ()      =>                ()    =>        ()=>
          ()      =>                ()    =>         ()=>
          ()        =>             ()     =>         ()
          {}          )            ()     ()         ()
          ()           ()        ()       ()         ()
          ()             ()     ()        ()        ()
          ()               () ()          ()( )( );
}
Feb 06 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2014 11:52 PM, Andrej Mitrovic wrote:

 D is the tersest language around, just observe how I can make
 functions returning functions with ease:

 void main()
 {
      (() => (){})()();
 }


void main(){
     (()=>{})()();
}
Feb 06 2014