3 ms·

I think this post is indicative of a problem that arises when a project such as firefox becomes too big. Sure, it is an open source project, so it is nice that

by kleiba 16y ago

I think this post is indicative of a problem that arises when a project such as firefox becomes too big. Sure, it is an open source project, so it is nice that you can file a bug report if you discover a shortcoming like the disappearing favicon. But the author of the blog seems to be a programmer himself. Ideally, he would not only file a bug report but - since the bug seems to bother him a lot - perhaps even come up with a patch. Instead, he writes a work-around -- and can you blame him? Compared to a two-line function, the work required to dig into a huge code base, try to understand it, come up with a patch (that doesn't break anything else), get the maintainers to integrate it, etc... seems enormous. Well, perhaps it actually isn't, who knows, but I can understand that people feel too inhibited to invest time to come up with a patch if the required effort seems so overwhelming from the start. It appears to me that this is a general problem, and the bigger the code base, the worse it gets. Yet at the same time, the overall benefit of submitting a patch rather than coming up with workarounds grows with an increasing user base, because more people are positively affected. So I wonder if there are any realistic methods to cope with this problem: how can open source projects get people to provide more patches?!

nerfhammer 16y ago
Fixing the bug may require platform and domain knowledge way beyond the skill set of the person submitting the bug
profquail 16y ago
Things like this make me wonder why anyone would want to write a huge project (like Firefox) in C/C++. I can understand wanting to re-use some legacy code, or perhaps the need for a few bits of optimized, low-level code where you really need the performance...but why not write the majority of the code in something like OCaml? I know there aren't as many good OCaml (for example) developers out there, but I'd bet that the end result would be just as fast (or faster) than the C/C++ version and have way fewer bugs (thanks to the strong type inference and succinctness of the code).
- k33n 16y ago
  If Firefox were an OCaml project, it would have likely died before hitting 1.0. Also, I've never used OCaml, so maybe I'm wrong here, but I highly doubt it's faster than C.
- _delirium 16y ago
  I'm not a C++ fan myself, but I think the complexity problem with Firefox is its various bits of internal infrastructure more than the language--- XUL, the rendering engine, custom string libraries, and a whole bunch of FooManagers and other custom interfaces intended to allow all the parts to be plugged together. The only thing I can think of offhand that a change of language might fix would be that a move to a garbage-collected language might allow for ripping out some of the FooManagers dedicated to allocating/tracking/freeing memory.

by kleiba 16y ago

nerfhammer 16y ago

Fixing the bug may require platform and domain knowledge way beyond the skill set of the person submitting the bug

profquail 16y ago

Things like this make me wonder why anyone would want to write a huge project (like Firefox) in C/C++. I can understand wanting to re-use some legacy code, or perhaps the need for a few bits of optimized, low-level code where you really need the performance...but why not write the majority of the code in something like OCaml? I know there aren't as many good OCaml (for example) developers out there, but I'd bet that the end result would be just as fast (or faster) than the C/C++ version and have way fewer bugs (thanks to the strong type inference and succinctness of the code).

k33n 16y ago
If Firefox were an OCaml project, it would have likely died before hitting 1.0. Also, I've never used OCaml, so maybe I'm wrong here, but I highly doubt it's faster than C.
_delirium 16y ago
I'm not a C++ fan myself, but I think the complexity problem with Firefox is its various bits of internal infrastructure more than the language--- XUL, the rendering engine, custom string libraries, and a whole bunch of FooManagers and other custom interfaces intended to allow all the parts to be plugged together. The only thing I can think of offhand that a change of language might fix would be that a move to a garbage-collected language might allow for ripping out some of the FooManagers dedicated to allocating/tracking/freeing memory.