eyalroz at technion.ac.il
Wed Nov 29 17:38:23 UTC 2017
> Since either C or C++ support writing outside the bounds of arrays,
> freeing memory twice, and casting between structures of different sizes,
The thing is, in Modern C++ you have little motivation or need to do
this. We use smart pointers; we use ranged-for loops, as well as
standard library algorithms to complete avoid looping; and we don't need
reinterpretation since we have std::variant's, type erasure with
std::any, and again - we don't need to allocate void */char *.
Now, true, potentially-dangerous code will never be entirely gone, but
by now it is mostly gone with almost no effort on your part. I don't
intend to knock Rust or anything, just making the point that the
perception of C++ as a memory-unsafe language requiring external
debugging tools is somewhat outdated.
> Those cases (performance, latency) might apply in some areas of a web
> browser. But in 2017, the whole idea of embedding a complex web browser
> written in a low-level language directly in your application in such a
> way that you need to compile and maintain the web browser code yourself
> is just ... (looking for a polite word) ... ill-advised.
I'm hope I'm not restarting an older debate, but - it is most advised.
Or rather, the part about basing a mail client and other networking apps
on a web browser with extensive and complex capabilities. The TB
development community might not like to maintain a idiosyncratic
embedded browser, but the concept is just fine. It is exactly this
concept which brought me, and many others, to TB as an easily-extensible
application. If a different mail client is written then it'll be, well,
just a mail client.
Also, performance is a very important consideration - again, for the
computational work we do in extensions. Since not every single line of
code is manipulable and instrumented for extensions to use, you rely on
using "heavier" tools, often for minor tasks. So if these are not
super-optimized - our code which uses them repeatedly will be really slow.
> One alternative is to have an application be a local web server that
> talks to a web browser. Such a server can be wrapped in Electron or
> something similar if you really want to bundle a web browser with your
> application. That different relationship to the web browser is the
> architectural shift which makes most of the existing Thunderbird
> codebase obsolete (whatever it is written in). And that shift
> essentially the reason I am writing this email in Roundcube via a web
> browser on a cheap Chromebook on my couch and not Thunderbird on a big
> desktop in my office.
> But you can find others saying the same. Here is a comment from 2007(!),
> for example from Benjamin Smedberg:
> "I have a fairly high tolerance for coding pain, and I have found the
> mailnews codebase very difficult to navigate and hack effectively. There
> are multiple causes for this, that I am going to list in no particular
> order. ... 1) Poor Model-View-Controller separation. ... 2) Pervasive
> C++ ..."
> And agreement by Jean-Marc Desperrier: "I think the problem mostly is a
> huge amount of very bad C++, very verbose and inefficient. I always felt
> reading the mailnews codebase that at the start of the project it
> received all the worse coders so that they would not disturb the
> browser code. [After providing an example of such poorly written code] I
> could submit a patch for the above, but what would be the point when
> what is really needed is a full rewrite ? And in that rewrite, we could
> as well think about reducing the amount of C++ code in favor of js, but
> the basic problem is not C++, it's bad code, and it could just as well
> be bad js code than bad C++ code."
> Ok, that was ten years ago, but has that much changed?
Almost everything has changed. You wouldn't believe how much things have
changed when you put the individual feature changes over time together
into a large-scale software system design. It really feels like a
My point is that the C++ you would design and write today is not like
what bsmedberg was complaining about. Again, that's not to say there
aren't valid reasons to prefer other languages.
> And even if it has, then consider this next point on the consequences of
> having an embedded web browser written in C and C++.
> Here is one big reason why it is so hard to engage developers with the
> existing C and C++ codebase for Thunderbird:
> "The source code requires 3.6GB of free space or more and additionally
> 5GB or more for default build. ... Building can take a significant
> amount of time, depending on your system, OS, and chosen build options.
> Linux builds on a fast box may take under 15 minutes, but Windows builds
> on a slow box may take several hours. ... [After making changes] Then
> just re-run the mach command above. This will only recompile files that
> changed, but it's still a long haul."
> And nowadays I feel waiting ten seconds or more to test changes to a
> large TypeScript application is painful...
> Having to deal with this accidental complexity and testing delays from a
> legacy of embedding low-level complex code of a web browser in
> Thunderbird is all a distraction from Thunderbird developers working on
> better ways to help people communicate. It's all massive technical debt.
> That's the big challenge of Thunderbird going forward -- how to deal
> with that technical debt for each part (whether by minor maintenance,
> progressive refactoring, and/or rewriting) -- especially considering the
> need to now *unembed* a legacy Firefox web browser component from the
> Thunderbird codebase. And the use of a low-level-oriented language like
> C or C++ with poor guarantees for memory safety where it is no longer
> needed (if it ever was) in Thunderbird is another part of that technical
> debt in my opinion.
So, I think you're conflating three separate discussions:
* The choice of development language
* Whether or not a web browser is part of / central to the codebase
* The decomposability of the source code into managable parts which may
be built independently
and these are mostly orthogonal IMHO.
More information about the tb-planning