[Nix-dev] New-style Marc Weber proposal

[Tony White]

On 20 April 2010 11:05, Peter Simons <simons at cryp.to> wrote:
> Marc Weber 2
> ============
>
> If you like it, we can deprecate Marc Weber soon. Right now, both can be used.
>
> Many of you have gotten used to the version of Marc Weber that has been around
> for so long, but lets face the fact that there are problems: (a) it actually
> works and (b) I haven't written it. So I decided to do something about that.
> First, I tried to patch the existing version, but that only made things worse,
> so I re-wrote everything from scratch. This allowed me to format the entire
> source code according to my personal taste without being bothered by style
> guides or group consensus.
>
> Previously, Marc Weber had the serious disadvantage that
>
>  [       a + 3                 1                  1         ]
>  [  ---------------   - ---------------  - ---------------  ]
>  [  (a - 1) (a + 4)     (a - 1) (a + 4)    (a - 1) (a + 4)  ]
>  [                                                          ]
>  [          1               a + 3                 1         ]
>  [ - ---------------   ---------------   - ---------------  ]
>  [   (a - 1) (a + 4)   (a - 1) (a + 4)     (a - 1) (a + 4)  ]
>  [                                                          ]
>  [          1                  1               a + 3        ]
>  [ - ---------------  - ---------------   ---------------   ]
>  [   (a - 1) (a + 4)    (a - 1) (a + 4)   (a - 1) (a + 4)   ]
>
> while also being
>
>  (mmm-add-classes
>   '((literate-haskell-bird
>      :submode text-mode
>      :front "^[^>]"
>      :include-front true
>      :back "^>\\|$"
>      )))
>
> and this lead to
>
>  template<unsigned int i, typename x, typename xs>
>  struct sieve_multiples_of< i, typelist<x,xs> >
>  {
>    typedef typename ifelse
>      < x::value % i != 0u
>      , typelist<x, typename sieve_multiples_of<i, xs>::result>
>      , typename sieve_multiples_of<i, xs>::result
>      >::result result;
>  };
>
> which is really bad! In my new version, however, this all becomes:
>
>    a!#_{a]|_aa23 23 / 8ZZZZ{}````5@ a!#_{a]|_aa23 23 / 8ZZZZ{}``
>    ``5@ a!#_{a]|_aa23 23 / 8ZZZZ{}````5@ a!#_{a]|_aa23 23 /
>    8ZZZZ{}`` ``5@ a!#_{a]|_aa23 23 / 8ZZZZ{}````5@ a!#_{a]|_aa23
>    23 / 8ZZZZ{}`` ``5@ a!#_{a]|_aa23 23 / 8ZZZZ{}````5@
>    a!#_{a]|_aa23 23 / 8ZZZZ{}`` ``5@ a!#_{a]|_aa23 23 /
>    8ZZZZ{}````5@ a!#_{a]|_aa23 23 / 8ZZZZ{}`` ``5@
>
> I hope this explanation helps you understand why the re-written version is
> superior.
>
> At this point, my new code is undocumented, untested, unfinished, unreadable,
> unnecessarily complex, unmaintained, and it doesn't work, so I checked it right
> in for your convenience. If the change causes any problems for you, it's
> probably easiest if you try to fix them yourself. I may be able to assist you
> with your efforts. If it so happens that you can't fix the problems yourself,
> please just let me know! I'll make an effort to deflect all responsibility with
> flimsy excuses in the nick of time.
>
> Generally speaking, I plan to develop this project into something really major,
> like ... I dunno ... maybe a car or a moon rocket, but because of the other
> five dozen unfinished projects I'm involved in, I'm not actually going to do
> it. As always, I appreciate feedback (unless I don't like it) and I'll try to
> fix my bugs ASAP (unless they don't bother me).
>
> Have a nice day,
> Peter Simons
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>

Hi Peter,
I don't think that your comments are fair.

If someone makes a mistake or adopts an unsuitable method as a
solution to a problem, please communicate with them in a civilised
manner about it, try to reason with them and maybe even try to suggest
a better solution.
Don't just try to mock them like this. Especially not a valued
contributor to the project.

I think the productive thing to do in this situation, is to propose
that contributors work in their own separate branches in future and
send Eelco merge requests or patches when they have code ready for
review.
Instead of the current pushing of code straight into the trunk without review.
Git users are well aware of this approach because that's how
distributed development using Git works the best. That proposed method
is also feasible using SVN but it is just one simple solution that
could be considered, should rolling back to a nixpkgs backup or
reverting the last commit using svn be such a big issue for you.

Mistakes don't need to be ridiculed. They just need to be fixed.
Especially when someone has all the right intention.

Thanks,
Tony