Formal review of std.lexer

[Adam Wilson]

On Mon, 24 Feb 2014 15:36:43 -0800, Meta <jared771 at gmail.com> wrote:

> On Monday, 24 February 2014 at 23:07:07 UTC, Adam Wilson wrote:
>> Well, we keep voting down replacement candidates, which incidentally,  
>> is exactly what happened with the std.signals replacement, so I view  
>> this as an orthogonal issue to whether or not it should be included  
>> after passing a review. I don't think the fact that a module might not  
>> be perfect after review should stop us from approving a module that  
>> offers completely new functionality AND passed a review. Handling the  
>> problems after inclusion is what bugzilla is for.
>
> I guess std.signals was a bad example, as there *was* a proposed  
> replacement. However, there were real problems with the replacement that  
> made it not suitable for inclusion. If I recall, these were largely API  
> issues, which are the hardest to change. If we had've accepted the new  
> std.signals despite the issues raised, several years down the road it  
> might turn out to be as broken as the old implementation (no offense to  
> the author, this is just for the sake of argument), and we are unable to  
> replace it for fear of breaking code. There are then 2 options: support  
> the old API with its broken behaviour in the same module as the new API,  
> or introduce std.signals2 or the like, which people have shown  
> resistance to in the past. I think that it's very important to be  
> careful as to what goes into Phobos at this point, as it's going to  
> become increasingly difficult to change anything.

Ok. Then by that standpoint we have two remaining options. A) Don't ever  
change existing code because you might breaking someone else's depending  
code on accident. Even without an API change, a change in how a function  
does it's processing can result in incorrect behavior in down-stream code.  
B) Never introduce new modules because we are terrified that the API might  
not be right in five years.

It is unrealistic in the extreme to demand that a new module in Phobos  
meet some arbitrary future compatibility bar. We routinely make changes to  
Phobos that break people's code in subtle ways that don't produce compiler  
errors and we never hear about it because no sane programmer expects a  
standard library to be a static thing that will never ever ever change in  
any way what so ever so that they can expect the exact same behavior five  
years from now. No, they go fix it and move on.

"OMG! We can't add this! It might not be the right API in the future!" By  
that reasoning we should halt all work on Phobos ever. After all, we might  
break something or a new API might not be perfect in five years after a  
new language feature allows an obviously better way of implementing that  
API. As reasoning goes, the best word I am come up with to describe it is  
"naive". It is a purely fear based response based on some unspecified and  
unknown future circumstance. Newsflash, you can't predict the future,  
which incidentally, is why API's change!

The reason std.signals replacement got voted down was because it wasn't  
API compatible with the original. This is despite the fact that nobody  
stood up to say that they use the current implementation and like it.  
Anybody who did use it said that they are desperate for a replacement. No  
the current std.signals is universally reviled and almost completely  
unused but we can't change it because of the mythical silent user who  
might be out there coding under a rock with no Internet and isn't voicing  
their opinion. Well, guess what, if you don't speak-up you have no right  
to blame it on the people who did and decided to changed it. You had your  
chance, stop whining and go update your code.

We are programmers. It is our JOB to deal with changes in the API/ABI/ISA.  
We don't have the RIGHT to whine about change because dealing with change  
is what we DO. If we aren't dealing with change we're working on something  
that isn't used at all and therefore pointless. I'm all for pointless  
pursuits, but don't hamstring me and my non-pointless pursuits with them.

I wanted std.signals in the new form badly, but now I can't have it, and  
Aurora is going to suffer mightily for it. Now I get to go off and make my  
own substandard iteration of Signals, because some people whined about how  
the API wasn't backwards compatible, even though it's widely acknowledged  
that almost nobody uses it and those that do would've been happy to move  
to the new signals.

Note, I am not talking about voting down modules that are obviously poorly  
implemented, I am talking about modules that work well and can do the task  
they purport to do with as few bugs as possible. If the module can do what  
it says it can, and the API isn't horrible, then we should default to  
adding it. Griping about the API five years from now is just bikeshedding,  
write up a pull and get that reviewed, chances are high it'll get rejected  
because the changes are worse anyways.

The only difficulty with changing anything is in your head. In practice,  
programmers who actually need to get things done expect it.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator