3 ms·

Explanation why fork of clang was required (as opposed to just improving clang) would also be interesting.

by mbel 8y ago

jcelerier 8y ago
> Explanation why fork of clang was required (as opposed to just improving clang) would also be interesting. well, they wouldn't be able to sell it if they had just been pushing patches to clang.
hendzen 8y ago
I evaluated zapcc at one point. Its a fork of clang because the changes are very intrusive to clang, and probably would have had a hard time getting accepted in to trunk without a ton of debate. I believe it actually daemonizes in to a long running server process (zapccs) that then holds the instantiated templates in memory, communicating with the zapcc compiler process over IPC. I think that most clang maintainers would have found that radical of a rearchitecting kind of controversial especially from an outsider to the project.
- loup-vaillant 8y ago
  > especially from an outsider to the project. That should really not be a criterion.
  - Qwertious 8y ago
    Sure it should. It's harder to work with people you haven't worked with much before, because you haven't had-then-dealt-with as many miscommunications and such. I mean sure, it shouldn't change the validity of the technical design, but when it comes to implementation (i.e. merging the changes/redesign and modifying the roadmap and such accordingly), it has every reason to.
  - epilk 8y ago
    How else will the project know that the major changes will be maintained? Having code in a project without an owner will just lead to bugs and bit rot.
    - loup-vaillant 8y ago
      So now not only projects have to be maintained, we also have to maintain changes? I'm seriously getting sick at the notion that nothing can ever be finished. Bugs? That will be those introduced by the change, nothing more. If there is any bug left, that's only because nobody discovered them yet. Having a maintainer won't change that, only usage reveals bugs. (Unless of course the "maintainer" is instead tasked with finding bugs in the first place). Bit rot? That's only an issue when the environment around the code changes. Clang is a compiler, there's not much it cares about its environment. And if you're talking about changes within Clang that could have an effect, and those are well within the maintainer's control. We shouldn't need a maintainer for every patch. This change in particular doesn't seem to introduce any new feature. I'm guessing it only allows Clang to run faster. The new code path replaces the old, so it shouldn't require much more maintenance. --- More generally, we should do away with the notion that everything should be maintained, forever. We should be able to code correct programs. We should have environments stable enough to preserve that correctness. And we should stop believing we need so much code in the first place. Let's not kid ourselves, programs "require maintenance" (euphemism for "aren't finished"), mainly because they're so damn big. We can do better, really. http://vpri.org/work/ifnct.htm http://vpri.org/work/ifnct.htm http://www.projectoberon.com/ http://www.projectoberon.com/ https://www.youtube.com/watch?v=kZRE7HIO3vk https://www.youtube.com/watch?v=kZRE7HIO3vk

Explanation why fork of clang was required (as opposed to just improving clang) would also be interesting.

by mbel 8y ago

Explanation why fork of clang was required (as opposed to just improving clang) would also be interesting.

> Explanation why fork of clang was required (as opposed to just improving clang) would also be interesting. well, they wouldn't be able to sell it if they had just been pushing patches to clang.

hendzen 8y ago

I evaluated zapcc at one point. Its a fork of clang because the changes are very intrusive to clang, and probably would have had a hard time getting accepted in to trunk without a ton of debate. I believe it actually daemonizes in to a long running server process (zapccs) that then holds the instantiated templates in memory, communicating with the zapcc compiler process over IPC. I think that most clang maintainers would have found that radical of a rearchitecting kind of controversial especially from an outsider to the project.

loup-vaillant 8y ago
> especially from an outsider to the project. That should really not be a criterion.
- Qwertious 8y ago
  Sure it should. It's harder to work with people you haven't worked with much before, because you haven't had-then-dealt-with as many miscommunications and such. I mean sure, it shouldn't change the validity of the technical design, but when it comes to implementation (i.e. merging the changes/redesign and modifying the roadmap and such accordingly), it has every reason to.
- epilk 8y ago
  How else will the project know that the major changes will be maintained? Having code in a project without an owner will just lead to bugs and bit rot.
  - loup-vaillant 8y ago
    So now not only projects have to be maintained, we also have to maintain changes? I'm seriously getting sick at the notion that nothing can ever be finished. Bugs? That will be those introduced by the change, nothing more. If there is any bug left, that's only because nobody discovered them yet. Having a maintainer won't change that, only usage reveals bugs. (Unless of course the "maintainer" is instead tasked with finding bugs in the first place). Bit rot? That's only an issue when the environment around the code changes. Clang is a compiler, there's not much it cares about its environment. And if you're talking about changes within Clang that could have an effect, and those are well within the maintainer's control. We shouldn't need a maintainer for every patch. This change in particular doesn't seem to introduce any new feature. I'm guessing it only allows Clang to run faster. The new code path replaces the old, so it shouldn't require much more maintenance. --- More generally, we should do away with the notion that everything should be maintained, forever. We should be able to code correct programs. We should have environments stable enough to preserve that correctness. And we should stop believing we need so much code in the first place. Let's not kid ourselves, programs "require maintenance" (euphemism for "aren't finished"), mainly because they're so damn big. We can do better, really. http://vpri.org/work/ifnct.htm http://vpri.org/work/ifnct.htm http://www.projectoberon.com/ http://www.projectoberon.com/ https://www.youtube.com/watch?v=kZRE7HIO3vk https://www.youtube.com/watch?v=kZRE7HIO3vk