is davem incompetent? [was: Assistance requested with B::Utils]

On Wed, Jul 29, 2015 at 08:11:30PM +0200, Reini Urban wrote:
> 2015-07-29 14:55 GMT+02:00 Dave Mitchell <dav...@iabyn.com>:> > On Wed, Jul 29, 2015 at 02:34:04PM +0200, Reini Urban wrote:> >> I’ll have to stay with the incompetence accusation generally,> >> > Because of course your whole modus operandi on this list is to throw> > out inflammatory unevidenced assertions.> > Unevidenced? I thought you hated my evidence, so I stopped repeating> my arguments for your sake and your new policies, which disallows> being unrespectful to the maintainers.> They are still valid arguments though, even if you refuse to read them.> And I cannot blog anymore because the blog maintainers decided to> forbid criticism on destructive maintainers now, so I just fix the> issues and stopped complaining. You can pick up a tiny subset on my> github if you care.> > And it is only inflammatory if you miss the context.> For you the world is shiny and every new perl5 release is better.

You have made a serious allegation against me, and when I pointed out that
it was an unevidenced assertion, you have responded with a long list of
unevidenced assertions.

One of three things needs to happen now.

A. You need to provide detailed evidence of your assertion that I am
generally incompetent (i.e. not just another long list of unevidenced
assertions).

B. You need to withdraw the allegation and apologise.

C. If you fail to do either of those, you should be banned from the list.

Before I respond in detail to your email, you should bear in mind the
following:

* I am not and never been in charge of perl, nor have I ever claimed to
  be.
* I am not and have never been a pumpking (apart being a release pumpkin
  for a couple of maint releases).
* I have never claimed to be a language designer, nor do I participate
  much in discussions about language features: it's not an area I
  claim to have any particular expertise in.
* Since my first commit in 2003, I have been responsible for about 5% of
  perl commits. The other 95% are other peoples' fault.
* There are whole areas of the perl infrastructure (such as the build
  toolchain) that I have next to no involvement in.
* While ad-hominem attacks are discouraged on this list, we have never,
  and still do not, stifle technical discussions. Your inability to
  to distinguish between the two is the reason why you have from time to
  time received temporary bans on this list or on perl blogs (that latter
  had nothing whatsoever to to do with me, by the way - I wasn't even
  aware of your inflammatory blog post or of the temporary ban until after
  you had been banned).
  For example, in http://nntp.perl.org/group/perl.perl5.porters/219513
  I explicitly invited you to contribute to technical discussions.
  The blame for you refusing cannot be attributed to my "incompetence".

In summary, you can't just attribute all the real or percieved past and
current failings of perl as being due to my (or my and Nicholas's)
"incompetence".

> >From the outside perl5 is losing, development stalled, and devs are> infighting. Not a single new feature implemented in the last 13 years> was successful, besides //=.  (I take out Oleg here, but he is no> maintainer.)

Most of the devs get along very well, and there is very little infighting.
Of course, since p5p is an open access mailing list (we only ban people in
extreme circumstances), anyone, committer or not, experienced or not,
can add their informed or uniformed opinion to any particular thread.
That's not the same as infighting.

> Every new perl release makes it worse, adds no new worthwhile> features, adds more risc, adds more memory bloat, adds more new bugs> than fixed bugs, changes policies and is extremely defensive.

Lots of unevidenced assertions. Many having nothing to do with me,

> For good> reasons. (use experimental, no core changes from outside, ...)> Still no object system, no optional type system, no optimizations, no> compiler support, no method inlining, no signature-based method> dispatch, no macros, no parser hooks,

As I keep saying, you know where to find perl6 is you want it.

> a slow and horrible regex engine,

It was slow and horrible before I started having any involvement with it.
Most of my work on it since then has been to make it less slow and less
horrible.

> Hell, 5.6.2 is still the best and fastest version out there. How can that be?

Because it's full of bugs and has broken unicode?

> Even if experts from the outside speak up, they are ridiculed by p5p> nobs. It's not funny from outside, it's rather dramatic.

Unevidenced assertion.

> Many CPAN modules are being unmaintained, dev tools like the toolchain> is being seriously harmed by silly demands.> E.g. no 5.6 because we need the LICENSE meta tag, better packager> support and it's OLD and buggy - Ha. It was still good in the golden> times than compared to now.

This of course has nothing whatsoever to do with me. I have no involvement
with the build toolchain, and am not responsible for any CPAN modules not
being maintained.

> perl 5.18 has certainly more bugs than 5.6.2 and 5.14.4,

Unevidenced assertion. Also in case you hadn't noticed, we're at 5.22 now.

> Devel::PPPort for XS devs is unmaintained since years.

Again, nothing to do with me.

> Module::Build and other harmful experiments are thanksfully over, but> the new folks started with even worse tools, which require half of> CPAN to maintain a module. No thanks. I do better with EUMM still.

Again, nothing to do with me.

> At least perl has not the silly name culture as ruby, and not the even> more incompetent devs as in python. But they have at least proper> management going on. Even php does so now.

Again, nothing to do with me.

> >From the inside:> The folks who are being paid to advance perl are doing simple> maintenance work

No, the folks (Tony and I) are being paid by the TPF *specifically*
to maintain perl. I am in addition being funded by Booking to do some
specific optimisations that should benefit perl generally.

> and make the horrible codebase even more unmaintainable, which could be> done by anybody.

You obviously don't look at the sorts of things I do. I go out my way
where possible to simplify and rationalise the bits of code I work on. For
example the refactoring of the regex runtime so that all the different
ad-hoc backtrack save mechanisms were collected into a single unified
backtrack state stack, which also meant that the engine no longer recursed
and so wouldn't crash when more than about 10K backtrack states needed to
be saved.  Or my work on the regex engine run-time optimiser
(intuit_start), which reduced the code size of that function by about 20%,
and reduced the number of labels from 13 to 6. But most importantly, fixed
a shed load of bugs, especially many ones where utf8 strings would go
quadratic on length. (it still needs some more work, but it's now a hell
of a lot more maintainable than it used to be).

> Capable devs as you> see on their CPAN development are being kept out.

Unevidenced assertion.

> Features that I need to advance perl5 are being kept out,

Unevidenced assertion.

> bugs not fixed,

Unevidenced assertion.

> improvements blocked on purpose,

Unevidenced assertion.

> modules badmouthed.

Unevidenced assertion.

> Horrible implementations are being added all the time.

Unevidenced assertion.

> Horrible policies are being invented, which explicitly go against> common sense and the old policies.

Unevidenced assertion.

> Normal technical discussions are not possible.

Unevidenced assertion.

> So any feature which> should have been discussed is just added silently. By the powerful. To> avoid that. That's not healthy.

Unevidenced assertion.

> Harmful changes are being politically spinned after the fact.> * E.g. the addition of binary name support was labeled "Unicode Symbol> Names". In fact unicode names were supported since 5.8.4, with> negative lengths in the HEK. Nobody needs to add a new len arg just to> support utf8. How did did your argue for that? Not a single word in> the delta. `g grep -i binary pod/perl5160delta.pod` vs "Unicode Symbol> Names" and a *$foo bug, which lost the utf8 flag.

Since I don't know what you're referring to here, I can't really comment.
But I don't think it has anything to so with me.

> Not many modules support binary names still since PPPort didn't care,> so potential attackers are very happy. I'm not talking about silly> hash ddos games here.

You have on many occasions asserted that allowing nulls in symbol table
names is insecure, yet you have always refused to provide any evidence,
despite repeated requests to do so, e.g.

    http://nntp.perl.org/group/perl.perl5.porters/204204

> * B::Generate is being told it cannot work, because one developer> decided with his powers that it should not work anymore.

I would need more context to know what you're referring to.

> Harmful political games on the back of the user-base.

I always avoid political games.


> But all went on> unpunished. By people who were not even able to maintain it.> * B for the Bytecode compiler is kept being broken on purpose for how> long now? 4 years? Because this dev "does not understand it and does> not want to revert the breakage"? The a***le rule obviously doesn't> apply to a committer.

Again, I can't comment because its not clear to me what you're referring
to.

> * The wonderful new double readonly system which took away the last> free sv bit, where still the main one readonly flag is not even used> yet, and I used the free bit.

Again, nothing to do with me. And if you needed the perl core to reserve
one free bit for your non-core usage, you should have requested and
negotiated such a reservation.

> * The wonderful new discussion which new strict flags people want,> when they do not know that they have no free bit. I earned 2 bits but> I don't give them to you, because you cannot be trusted with them.

Again, nothing to do with me.

> Harmful and destructive devs are being rewarded, and stick together.

Unevidenced assertion.

> The new code of conduct policies would be a good fit for the people> here, but are not used on them, rather on the critics on these> practices.

Unevidenced assertion.

> Devs who fix and improve issues and care for better code are being> ignored,

Unevidenced assertion.

> do not care to speak up, or are being badmouthed.

Unevidenced assertion. And this coming from the man who repeatedly
badmouths everyone around him.

> Maybe a word about your op_signatures branch:> Coding a parse into the lexer (toke.c) led to spaghetti. The whole> patch is spaghetti. It doesn't only look horrible, it does the wrong> thing and is also unmaintainable. When I added alias support and using> the stack directly to skip @_ I had to rewrite most of it. Just the> action compression PV is nice. Supporting sigs and protos together is> a parser job, not for a smart lexer generating a single token. A> parser is there to parse, the lexer should be used only for the crazy> dynamic parts. sigs and protos are both static. Besides the types, but> this is a seperate token.> A lexer doesn't know how to reset state to the previous parse.> My signature code is 2x faster, has more features, and is readable and> maintainable.

my op_signatures branch is still WIP. You have had full opportunity
to engage in discussions about it, but have chosen not to. I still
invite you, should you wish, to start a new thread where you can raise
those issues in more depth.

> COW is such a mess it hurts my eyes. ~20 unmaintainable spaghetti> rules by a different developer. For a cow refcount which is in the> read-write section?

Again, nothing to do with me,

> I could only barely fix that. Fixing that I wished nick was back who> could at least write readable code, even if he should be suspended for> life in this new fancy coc of yours.

U wot?

> Anybody heard how expensive branches are? And that's why we still have> 4 tests in the inner hash loop, instead of one or a second for utf8> unstrictness.

Again, nothing to do with me.

> There's much more evidence I brought up,

You haven't brought up any evidence so far.

> which you like to ignore but> eventually have to react. In rather mysterious ways not to loose your> face.> sv_grow?

I have never claimed that sv_grow() is good. I have ideas on how to fix
it, but haven't had time yet. Those ideas are not based on input from you.

> asan support?

What are you on about? When ASAN became easily usable on my development
plaform, I started using it. Show me anywhere where I said that using ASAN
was a bad idea or should be discouraged.

> safesyscalls?

Are you referring to croaking on making system calls where pathnames etc
have embedded nulls? Show me any evidence that I was ever opposed to this?

> And the still unresolved mess with hash functions and hash tables,

Again, nothing to do with me.

> cow, sigs, types, lexical warnings, dispatch, inlining, ...

All nothing to do with me, apart partially for sigs (I didn't implement
them, I just have some WIP in code to make them less slow).

> Do something against it. Start listening. Stop being ***. Attract> people who do have an idea what they are doing.

I know for a fact that competent developers have been driven way
by *your* unpleasant behaviour on this list over the years.

-- 
The Enterprise is involved in a bizarre time-warp experience which is in
some way unconnected with the Late 20th Century.
    -- Things That Never Happen in "Star Trek" #14