Compile time iota

Thu Jan 22 13:21:39 PST 2015

On 1/22/15 5:08 AM, Dicebot wrote:
> On Thursday, 22 January 2015 at 13:06:26 UTC, Nick Treleaven wrote:
>> On 21/01/2015 19:15, zeljkog wrote:
>>> And good name staticIota, unlike TypeTuple. I always wonder what is raw
>>> tuple, TypeTuple or Tuple :)
>>
>> Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a
>> pull to do that (which goes further than the DIP), but I don't know if
>> the deprecation/disruption will be acceptable. If not, perhaps we
>> could just add a better named alias for TypeTuple (e.g. MetaTuple) but
>> keep the same module name. I don't think the status quo is really
>> acceptable.
>>
>> (In fact, I don't agree with removing deprecated symbols unless they
>> are actually buggy - this is what GTK does. If we kept them there
>> would be less friction and less cause not to deprecate things which
>> are problematic).
>
> Ah, great, now I am least sure that you and ntrel are the same person :)
> Fate of your pull and DIP in general is in Andrei hands - but, as he has
> mentioned in this thread, his mailbox queue is not easy to deal with. So
> right now can't really do anything but sit and wait.

I'm ambivalent about this; I think it could go either way without making 
a huge impact. (BTW I like GTK's idea to keep the old names around. They 
could be marginalized in the documentation but still allow older 
programs to build.)

I'm more worried about another trend though (only loosely related to 
this particular one). I might talk about that tonight.ñ

While working on the new site menus I was copying std modules by hand - 
and boy, there's just so much work to be done. Streams, json, encoding, 
mmfile, outbuffer, signals, socket, socketstream, xml, zip - all that 
stuff, maybe a third of the standard library packages, are /known/ to be 
in need of a good revamp (ranging from better documenting to refactoring 
to improving to completely rewriting) yet recently a lot of work has 
been spent on renaming, splitting, ... - shuffling the rubble in the 
garden, especially parts that are already good: container, algorithm, 
range, typecons.

Moreover, there's a ton of brand new work to be done! We don't have 
standard decent wrappers for libevent or libarchive, networking 
protocols, web servers, databases, and just a ton of other things.

I hypothesize much of it is because a small improvement to something 
that's already good is easier to push past review; what's there works, 
the new stuff is even nicer - game, set, and match. Pull merged. In 
contrast, embarking on a significant new work is likely to receive a lot 
more scrutiny and criticism.

This might be because an asymmetry: we have a high bar for reviews and a 
good process in place, but no strong enough large submissions to make it 
past it. As a consequence our current dynamics "optimizes" for small 
improvements of already working code.

In WWI, the advent of mounted machine guns created a large asymmetry 
between defense and offense: defense was much more effective than 
offense, which led to the trench stalemate. It seems to me we have an 
asymmetry between the review process and the strength of potential 
submissions. The WWI stalemate was broken by the invention of the tank. 
We apparently need an equivalent of it :o).

===

Take a look at 
https://github.com/D-Programming-Language/phobos/pull/2687/files. So we 
have a bunch of replacements like "TypeTuple" to "meta.List" and 
"allSatisfy" to "meta.all". Are the new names nicer? Arguably. I like 
them! Do they improve things? I guess. There'd be less confusion about 
TypeTuple not always containing types etc, which does matter. Will they 
have an important contribution to the adoption of D? Very, very little 
if at all, especially compared with the opportunity costs: all the good 
work that WASN'T done by the talented contributors involved while they 
were busy renaming things.

That said https://github.com/D-Programming-Language/phobos/pull/2687 
will probably get pulled. Why? Because it's sensible, and because it's 
there. It's the sensible, okay work that I'm most worried about, even 
more than bad work.

Bad work is visibly undesirable so it won't get far. The problem with 
okay work is it does get implemented and pulled, so it takes away time 
from the great work that does make a difference.

Andrei