An LLVM backend for Sparse
An LLVM backend for Sparse
Posted Aug 30, 2011 22:00 UTC (Tue) by daglwn (guest, #65432)In reply to: An LLVM backend for Sparse by penberg
Parent article: An LLVM backend for Sparse
Actually, it is. You're attacking the messenger, not the message.
> You affiliation with LLVM is very relevant for the issue at hand.
What "affiliation?" I in no way get paid by, represent or otherwise am officially connected to the LLVM development leadership in any way. I contribute code when I can. I just happen to see it and clang as a good platform for something like Sparse as they tackle the same set of problems.
But in any case, this is moot.
> That said, I'm not claiming malicious intent on your part but it does
> undermine the credibility of your "NIH" and "duplication" arguments.
> Surely you can see that too?
No, I can't. I made the exact same argument when the Apple guys started up libc++. I try to be at least somewhat fair in my critiques. :)
It turns out that the Apple guys had some compelling reasons to do libc++. I didn't agree with all of them but I understood them. The same is true for Sparse. If the Sparse people don't see a benefit to doing the clang thing, that's perfectly fine. It's probably a loss for the rest of us but if clang people really want the functionality they can code it up themselves.
Posted Aug 31, 2011 6:10 UTC (Wed)
by penberg (guest, #30234)
[Link] (1 responses)
> What "affiliation?" I in no way get paid by, represent or otherwise am
I don't get paid to hack on Linux or Sparse either. That doesn't make me
Imagine that the Haiku kernel developers were adding, say, NTFS support to
Now imagine me doing all that without actually telling them I'm a Linux kernel
See the difference?
Posted Aug 31, 2011 10:33 UTC (Wed)
by pboddie (guest, #50784)
[Link]
Personally, I think it can be bad enough even if you do know where someone is coming from. I'm all for people learning from and reusing the work that's already out there, but I've also seen people encouraging others to join their own projects, initially for reasons of sensible collaboration ("you're working on this too, so maybe we should pool our efforts"), and then becoming more aggressive towards their supposed competitors ("that other project is obsolete, use ours!"), frequently springing from the belief that there's only one way that things should be done in a particular domain and that way is their way. Discouragement of independent work that may overlap with more well-known projects might seem like it helps all parties, but as everyone should know by now, people aren't always motivated primarily by how useful they are to some larger project or how productive they are at making things for the wider community. Moreover, when heavily-promoted projects that have grown at the expense of other efforts eventually fail or fall into decline, as some do, it's best to have people doing similar things in different ways. Communities shouldn't put all their eggs in one basket, and they generally don't want to anyway.
An LLVM backend for Sparse
issue. ]
> officially connected to the LLVM development leadership in any way. I
> contribute code when I can. I just happen to see it and clang as a good
> platform for something like Sparse as they tackle the same set of problems
any less biased compared to the other developers that are getting paid. Look, I
don't have any problem with people being biased toward the projects they work
on. That's pretty much natural. You failed to disclose that early on which
weakens your argument.
their kernel. Then imagine me as Linux kernel developer accusing them of "NIH"
and "duplication" and asking them why they don't work on Linux instead. Imagine
me telling them that "we in the open source world" are at the point where
there's very few reasons to implement their own kernel.
developer.
An LLVM backend for Sparse
Now imagine me doing all that without actually telling them I'm a Linux kernel developer.