| 1541 | | As most younger C++ programmers, or indeed non-C++ programmers will ruefully note, C++ as a language and an ecosystem has almost entirely ignored the trends of the past twenty years towards extreme reusable modularity. The last big innovation in C++ modularity was Microsoft COM back in 1993, and it formalised the C++ made available by [http://en.wikipedia.org/wiki/Cfront Cfront] because that was the most standardised implementation available in 1989 when COM was originally being proposed. To use Microsoft COM is therefore to restrict oneself to C++ as it was approximately in 1989. Despite such an enormous limitation, Microsoft COM is enormously popular, and those same limitations means you can wrap any language capable of speaking C inside a COM object whereupon it can be used by any other COM object without regard as to how it is internally implemented. |
| 1542 | | |
| 1543 | | I don't know this for sure, but I suspect much of the recent investment by the tech majors in new systems programming languages ([http://en.wikipedia.org/wiki/Swift_%28programming_language%29 Swift] by Apple, [http://en.wikipedia.org/wiki/Go_%28programming_language%29 Go] by Google, and probably the two biggest upcoming threats to C++, [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust] by Mozilla and [http://www.dotnetfoundation.org/ the conversion of .NET into a portable systems programming platform] by Microsoft) stems from the continuing abject failure of C++ to finish supplanting C as the best general purpose systems language available |
| | 1541 | As most younger C++ programmers, or indeed non-C++ programmers will ruefully note, C++ as a language and an ecosystem has almost entirely ignored the trends of the past twenty years towards extreme reusable modularity. The last big innovation in C++ modularity was Microsoft COM back in 1993, and it formalised the C++ then available by [http://en.wikipedia.org/wiki/Cfront Cfront] because that was the most standardised implementation available in 1989 when COM was originally being proposed. To use Microsoft COM is therefore to restrict oneself to C++ as it was approximately in 1989. Despite such an enormous limitation, Microsoft COM is enormously popular, and those same limitations means you can wrap any language capable of speaking C inside a COM object whereupon it can be used by any other COM object without regard as to how it is internally implemented. |
| | 1542 | |
| | 1543 | I don't know this for sure, but I suspect much of the recent investment by the tech majors in new systems programming languages ([http://en.wikipedia.org/wiki/Swift_%28programming_language%29 Swift] by Apple, [http://en.wikipedia.org/wiki/Go_%28programming_language%29 Go] by Google, and probably the two biggest upcoming threats to C++, [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust] by Mozilla and [http://www.dotnetfoundation.org/ the conversion of .NET into a portable systems programming platform] by Microsoft) stems from the continuing abject failure of C++ to finish supplanting C as the best general purpose systems language available (note that none of these work easily with C++, .NET is probably the easiest and Swift the next easiest via an Objective C++ shim, after that you're stuck with SWIG bindings). |
| 1551 | | The thing which annoys me and many others is that [http://arxiv.org/abs/1405.3323 a much enhanced replacement for Microsoft COM is not technically challenging], it just requires someone to supply the sustained funding for the necessary two or three years to make it happen. This is exactly what [https://isocpp.org/about the Standard C++ Foundation] is supposedly there to fund, but I have observed almost zero interest from the C++ community to invest in becoming a better neighbour and especially glue to other programming languages. I suspect, sadly, C++ will need to be mortally threatened by something like Rust to get its act together and get its head out of its ivory tower. |
| 1552 | | |
| 1553 | | Even that big picture stuff aside, there is a disdain within the C++ community for considering ease of use by other languages when designing standard C++ library facilities. One of my personal bugbears is the current design of `std::future<T>` which is an arse to use from C code because you can't compose waits on a future with anything else you'd wait upon in C or any other language for that matter. If `std::future<T>` had the optional ability to be waited upon along with other things inside a `select()`/`epoll()`/`kqueue()` multiplexed wait call, that would be enormously useful to anyone needing to work with C++ futures from outside C++. Hell, it would even be super useful within C++ right now, at least until the Concurrency TS `when_any()`/`when_all()` supports comes through. |
| | 1551 | The thing which annoys me and many others is that [http://arxiv.org/abs/1405.3323 a much enhanced replacement for Microsoft COM is not particularly technically challenging] (note that paper is by myself), it just requires someone to supply the sustained funding for the necessary two or three years to make it happen. This is exactly what [https://isocpp.org/about the Standard C++ Foundation] is supposedly there to fund, but I have observed almost zero interest from the C++ community to invest in becoming a better neighbour and especially glue to other programming languages. I suspect, sadly, C++ will need to be mortally threatened by something like Rust to get its act together and get its head out of its ivory tower. |
| | 1552 | |
| | 1553 | Even that big picture stuff aside, there is a disdain within the C++ community for considering ease of use by other languages when designing standard C++ library facilities. It's hardly the only example, but one of my personal bugbears is the current design of `std::future<T>` which is an arse to use from C code because you can't compose waits on a future with anything else you'd wait upon in C or any other language for that matter. If `std::future<T>` had the optional ability to be waited upon along with other things inside a `select()`/`epoll()`/`kqueue()` multiplexed wait call, that would be enormously useful to anyone needing to work with C++ futures from outside C++. Hell, it would even be super useful within C++ right now, at least until the Concurrency TS `when_any()`/`when_all()` supports comes through. |
| 1557 | | Internally C++ has undergone the wrenching change of getting the enormously delayed and overdue C++ 11 standard out of the door, and to achieve that the C++ leadership essentially had to beat up itself in a process of attrition to such an extent that quite a number of the leading lights which were so historically influential in the leadership have since left C++ altogether either due to exhaustion, bitterness or their wives suggesting that divorce would be imminent unless they stopping putting C++ before their families. What I think has happened is that it has left the C++ leadership quite tired of disruptive change, and enormously defensive of any suggestion that they are not mostly correct on any given technical choice as I have often observed personally just on the Boost Developers mailing list, let alone at C++ conferences. People I know who attend recent WG21 meetings find them overwhelmingly negative and exhausting, and more than one has observed that the only kind of person who now thrives there is at best of a sociopathic disposition (and don't get me wrong, [http://uk.businessinsider.com/linux-foundation-reigns-in-linus-torvalds-2015-3?r=US the right kind of sociopath] even psychopath can be crucial to the success of any technically challenging and complex project, but for it to work you generally want at most just one sociopath in the room at once, collecting many of them into the same room never produces a positive outcome welcomed by all). Setting aside the consequences of the brain drain of good engineers forced out by the C++ process and culture, I think this was and is a great shame given what it could be instead, and I'll elaborate a bit more in the detailed treatment of what went wrong in the section on the Boost C++ libraries below. |
| 1558 | | |
| 1559 | | 3. '''A rejection of the business side of open source''' |
| 1560 | | |
| 1561 | | Most of the C++ leadership are -- how shall I put it -- of a certain age and job security not shared by younger C++ programmers or programmers in the newer languages. Back when they were younger programmers, open source software was something you did as a hobby, a charity and as a noble and especially non-commercial pursuit outside of normal work hours as a means of achieving an excellence in your software that your employer wouldn't permit for business reasons. Employment was very secure, benefits and perks were high, and you had a strong chance of lifelong employment at the same employer if you so wished. Thanks to you working pretty much in the same field and technologies continuously, both within open source and within your employment your authority as an engineer had a good correlation with your years of experience which were many. You knew your position in the hierarchy of things, and you had worked and sacrificed to reach that position over a long career. Unsurprisingly, this generation of software engineer likes permanence, dislikes radical change, and really hates throwing away known-good code even when it is no longer fit for purpose due to bitrot and/or lack of maintenance. They also dislike the idea that one should make money from open source, and especially that one ought to ''leverage'' the dependency of firms on your free of cost open source software to extract rents (they call it blackmailing). |
| 1562 | | |
| 1563 | | The younger programmer, and increasingly the programmer not recognised as in the global engineering elite by the industry, has a very different experience and understanding of open source software. This is because all the big open source software projects invest heavily in the business side of acquiring and dispersing funding for vital work on the software, and this trend of seeing the open source software organisation as primarily one of actualising its business side instead of being just some source code repo and web presence is the most prevalent in the newest open source projects simply through them being founded more recently, and therefore adopting what they felt was the state of the art at the time. |
| 1564 | | |
| 1565 | | In case you are one of those engineers of a certain age and don't know what I'm talking about here, let me compare two open source projects: [http://www.boost.org/ the Boost C++ Libraries] and [https://www.djangoproject.com/ the Django web framework]. Django was first released in 2005, and it took just three years to establish [https://www.djangoproject.com/foundation/ the Django Software Foundation] which operates the business side of Django the open source software project, specifically as a charity which promotes, supports and advances the Django web framework by: |
| | 1557 | Internally C++ has undergone the wrenching change of getting the enormously delayed and overdue C++ 11 standard out of the door, and to achieve that the C++ leadership essentially had to eat its own young in a process of attrition to such an extent that quite a number of the leading lights which were so historically influential in the leadership have since left C++ altogether either due to exhaustion, bitterness or their wives suggesting that divorce would be imminent unless they stopping putting C++ before their families. What I think has happened is that it has left the C++ leadership quite tired of disruptive change, and enormously defensive of any suggestion that they are not mostly correct on any given technical choice as I have often observed personally just on the Boost Developers mailing list, let alone at C++ conferences. People I know who attend recent WG21 meetings find them overwhelmingly negative and exhausting, and more than one has observed that the only kind of person who now thrives there is at best of a sociopathic disposition (and don't get me wrong, [http://uk.businessinsider.com/linux-foundation-reigns-in-linus-torvalds-2015-3?r=US the right kind of sociopath] even psychopath can be crucial to the success of any technically challenging and complex project, but for it to work you generally want at most just one sociopath in the room at once, collecting many of them into the same room never produces a positive outcome welcomed by all). Setting aside the consequences of the brain drain of good engineers forced out by the C++ process and culture, I think this was and is a great shame given what it could be instead, and I'll elaborate a bit more below on what it ought to be instead. |
| | 1558 | |
| | 1559 | 3. '''A rejection of the business side of the C++ open source ecosystem''' |
| | 1560 | |
| | 1561 | Most of the C++ leadership are -- how shall I put it -- of a certain age and job security not shared by younger C++ programmers or programmers in the newer languages. Back when they were younger programmers, open source software was something you did as a hobby, a charity and as a noble and especially ''non-commercial'' pursuit outside of normal work hours as a means of achieving an excellence in your open source software that your employer wouldn't permit for business reasons. Employment was very secure, benefits and pensions were high, and you had a strong chance of lifelong employment at the same employer if you so wished. Thanks to you working pretty much in the same field and technologies continuously, both within open source and within your employment your authority as an engineer had a good correlation with your years of experience, so pay rises and seniority were automatic. You knew your position in the hierarchy of things, and you had worked and sacrificed to reach that position over a long career. Unsurprisingly, this generation of software engineer likes permanence, dislikes radical change, and really hates throwing away known-good code even when it is no longer fit for purpose due to bitrot and/or lack of maintenance. They also dislike the idea that one should make money or a living from open source, and especially that one ought to ''leverage'' the dependency of firms on your free of cost open source software to extract rents (they call it blackmailing). |
| | 1562 | |
| | 1563 | The younger programmer tends to see a career in the tech industry for what it is: a lousy industry where employees are disposable resources to be mined for all their value before disposal, pensions are probably worthless assuming you'll ever retire at a reasonable age, real estate pricing is far beyond your means and you're still saddled with enormous debts from gaining all those degrees, and the only advantage of being in tech as compared to other industries is that it's far worse in most other industries available to your age cohort -- assuming you can get a job at all despite holding multiple Masters degrees and being vastly more qualified than the people interviewing you. For many a younger programmer, contributing to open source means something far different to the older generation: ''an opportunity to escape'' the meaningless existence of writing pointless code for other people who only care about you insofar as to make you drink their Koolaid and place their company before everything else in your life, including your family. And by escape, I don't just mean merely psychologically, I mean that most have a vision that one day their open source efforts could turn into a sufficient means for living away from those who exploit you, whether self employed via a startup or remote expert consulting for some crazy hourly rate at which point those same earlier employers tend to suddenly value your time and inconvenience oddly enough. |
| | 1564 | |
| | 1565 | This is obviously a very different experience and understanding of open source software. Not coincidentally most of the big open source software projects invest heavily in the business side of acquiring and dispersing funding for vital work on the software, and this trend of seeing the open source software organisation as primarily one of actualising its business side instead of being just some central source code repo and web presence is the most prevalent in the newest open source projects simply through them being founded more recently, and therefore adopting what they felt was the state of the art at the time. |
| | 1566 | |
| | 1567 | In case you are one of those engineers of a certain age and don't know what I'm talking about here, let me compare two open source projects: [http://www.boost.org/ the Boost C++ Libraries] and [https://www.djangoproject.com/ the Django web framework]. Boost was [http://www.boost.org/users/proposal.pdf originally conceived as a proving ground for new C++ standard library ideas] making better use of the 1998 C++ ISO standard. Due to its roots as a playpen and proving ground for standard C++ libraries, Boost is unusually similar to the C++ standard library which is both good and bad: good in terms of the quality of design, algorithms, implementation and testing -- bad in terms of monolithicity, poor coupling management, and over-reliance on a single person in charge of each library (great for the library if that maintainer is active, not so great across libraries when maintainers must work together, terrible if a maintainer vanishes or departs). In particular, like many other open source projects founded in the 1990s, Boost does not believe in there being a business side to itself apart from its annual conferences which began in 2006, and [https://sites.google.com/a/boost.org/steering/ its steering committee website] has this excellent paragraph which was written after I caused a fuss about how little steering the "steering committee" does: |
| | 1568 | |
| | 1569 | ''"In the Boost community decisions have always been made by consensus and individual members have shown leadership by stepping forward to do what they felt needed to be done. Boost has not suffered from a lack of leadership or volunteer participation. It is not the role of the Steering Committee to inhibit this kind of spontaneous leadership and action, which has served Boost and the wider C++ community so well. On the contrary, it is the role of the Steering Committee to facilitate community-based leadership and decision making. The role of the Committee is to be able to commit the organization to specific action either where funds are required or where consensus cannot be reached, but a decision must be made."'' |
| | 1570 | |
| | 1571 | Firstly, I do appreciate Jon for even getting this statement put together at all -- the steering committee had managed to get four years to pass without actually stating what it felt its purpose was which was not what [https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B6eFfIvoBI5XZGVkZDc1NTgtODlkYi00MjQ0LWE2NGEtYjRmZTYwNzlmYmU1&hl=en_US&authkey=CODhyJkP the slides at BoostCon 2011 said it was going to do]. As much as this is helpful, do you notice that the "mission statement" clearly disavows taking any leadership role whatsoever unless unavoidable? This effectively means that the Boost steering committee is really a board of trustees who have very little strategic interaction with the thing they approve funding for, and that is pretty much what happens in practice: individual committee members may help you out privately on something, but publicly they have no position on anything unless someone petitions them to make a decision. Note that they make no decisions at all until someone formally asks for one, just as with a board of trustees. |
| | 1572 | |
| | 1573 | So what is the problem one may now ask? Well, you've got to understand what it is like trying to achieve anything in Boost, and indeed those BoostCon 2011 slides summed up the problem nicely. Firstly you must achieve consensus in the community, which involves persuading a majority on the Boost Developers list -- or rather, persuading a majority of those who ''respond'' on boost-dev that what you proposed is not a terrible idea, often by you investing dozens of hours of your free unpaid time into some working prototype you can show people. This part also usually involves you fending off trolls, those with chips on their shoulder, those with vested interests, those threatened by any form of change, those who simply don't like you and are trying to take you down a peg etc which most unfortunately can include members of the steering committee itself. To achieve any significant change usually involves ''years'' of campaigning, because to get a dispersed heterogeneous community with few common interests to reach consensus on some breaking change even with a proven working prototype takes a minimum of a year, and usually many years, and again you must have a skin thick enough to repel all those trolls and naysayers I mentioned. If this begins to sound as disspiriting and as exhausting as attending WG21 meetings -- except this effort is entirely unpaid -- you would be right. Anyway, if after years of unpaid effort and toil you finally reach consensus, ''then'' you can apply to the steering committee for funding to implement and deliver your change, by which stage -- to be blunt -- the funding is but a tiny fraction of the time, blood and sweat you have personally already invested. |
| | 1574 | |
| | 1575 | Note that if you have a job with a high status role and excellent job security and believe open source to be a noble non-commercial hobby, then taking years to change a community consensus is far less important to you than if you have no job security, your job is menial and you just want -- and I hate to be so blunt about this -- the open source project leadership to proactively help you rather than aloofly stand apart until you've invested years of free unpaid effort for potentially no real gain. Those unpaid hours of effort could go on actually writing new code, in an environment more welcoming, perhaps even in a community you yourself create. Most with this opinion do not of course voice it, and simply silently leave the community for somewhere more contemporary and less hostile to evolution. |
| | 1576 | |
| | 1577 | Let's look at what a modern open source project does differently: Django was first released in 2005, and it took just three years to establish [https://www.djangoproject.com/foundation/ the Django Software Foundation] which operates the business side of Django the open source software project, specifically as a charity which promotes, supports and advances the Django web framework by (from its mission statement): |
| | 1578 | |
| 1570 | | In practice that means a constant cycle of acquiring and ''maintaining'' regular donations from the firms and users who use your free of cost open source software, whether from fee paying training courses and conferences, or simply through a donate button on the website, but often through investing effort to build networks and relationships with your biggest commercial users and ''leveraging'' those networks and relationships into a regular donations stream. Concomitant with that leveraging is a ''reverse leveraging'' by those sponsors on the future strategic direction of the open source project, so when this funding process is working well you the open source org gets funds to dispose upon a future vision of the open source project previously agreed (or at least discussed) with your major sponsors. This is why leveraging your open source project for funding is '''not''' blackmail but rather funded coevolution, despite what many in the C++ leadership might think. |
| 1571 | | |
| 1572 | | Now let's compare that to Boost which is probably the leading repository of open source C++ libraries. Boost was [http://www.boost.org/users/proposal.pdf originally conceived as a proving ground for new C++ standard library ideas] making better use of the 1998 C++ ISO standard, but from [https://web.archive.org/web/20000816132250/http://www.boost.org/libs/compiler_status.htm August 2000 onwards] it also began to turn into a broken compiler workarounds portability layer which whilst initially was great for those with broken compilers, it incurred an enormous technical and especially cultural debt into the codebase which still weighs heavily upon anyone trying to change anything substantial affecting more than one library (including cultural beliefs in the importance of support of broken toolsets due to those with a vested (commercial) interest in the support of broken and legacy toolsets). Due to its roots as a playpen and proving ground for standard C++ libraries, Boost is unusually similar to the C++ standard library which is both good and bad: good in terms of the quality of design, algorithms, implementation and testing -- bad in terms of monolithicity, poor coupling management, and over-reliance on a single person in charge of each library (great for the library if that maintainer is active, not so great across libraries when maintainers must work together, terrible if a maintainer vanishes or departs). In particular, Boost does not believe in there being a business side to itself apart from its annual conferences which began in 2006, and [https://sites.google.com/a/boost.org/steering/ its steering committee website] has this wonderful paragraph which was written after I caused a fuss about how little steering the "steering committee" does: |
| 1573 | | |
| 1574 | | ''"In the Boost community decisions have always been made by consensus and individual members have shown leadership by stepping forward to do what they felt needed to be done. Boost has not suffered from a lack of leadership or volunteer participation. It is not the role of the Steering Committee to inhibit this kind of spontaneous leadership and action, which has served Boost and the wider C++ community so well. On the contrary, it is the role of the Steering Committee to facilitate community-based leadership and decision making. The role of the Committee is to be able to commit the organization to specific action either where funds are required or where consensus cannot be reached, but a decision must be made."'' |
| 1575 | | |
| 1576 | | One instantly notices the big disclaimer of taking any non-consensus strategic decisions whatsoever, unless vitally necessary. This effectively means that the Boost steering committee is really a board of trustees who have very little strategic interaction with the thing they approve funding for, and that is pretty much what happens in practice. |
| 1577 | | |
| 1578 | | "So what?" one may now ask? Well, you've got to imagine what it is like trying to achieve anything in Django versus Boost. In Django, you pitch your idea for some change, whether radical or not, to a small, contained authoritative leadership where the authority to decide and fund any initiative is clearly demarcated. They more often or not are acting really as a filter for appropriately repackaging and presenting ideas to the sponsors for funding, though they usually have some slush money around for the really radical stuff (if it is cheap). The process for enacting change is therefore extremely well specified, and moreover because a central authority will approve or disapprove an idea quickly, you don't waste time pushing ideas without a chance. |
| 1579 | | |
| 1580 | | Compare this to Boost. Firstly you must achieve consensus in the community, which involves persuading a majority on boost-dev -- or rather, persuading a majority of those who ''respond'' on boost-dev that what you proposed is not a terrible idea, often by you investing dozens of hours of your free unpaid time into some working prototype you can show people. This part also usually involves you fending off trolls, those with chips on their shoulder, those with vested interests, those threatened by any form of change, those who simply don't like you and are trying to take you down a peg etc. It also usually involves ''years'' of campaigning, because to get a dispersed heterogeneous community with few common interests to reach consensus on some breaking change even with a proven working prototype takes a minimum of a year, and usually many years. If this begins to sound as disspiriting and as exhausting as attending WG21 meetings -- except this effort is entirely unpaid -- you would be right. Anyway, if after years of unpaid effort and toil you finally reach consensus, ''then'' you can apply to the steering committee for funding to implement and deliver your change, by which stage -- to be blunt -- the funding is but a tiny fraction of the time, blood and sweat you have personally already invested. |
| 1581 | | |
| 1582 | | Back at the beginning of Boost where the improvements needed to the standard C++ standard libraries were obvious and therefore consensus was easy to obtain, plus so many vested interests in inhibiting change or challenge weren't there yet, Boost worked well and delivered an enormous contribution to the C++ TR1 (ten libraries) and C++ 11 (another ten libraries). But open source, and the world, has moved on, the current gold standard of open source practice is to run your open source project as a business. C++ has recently [https://isocpp.org/about set up a Standard C++ Foundation] which could provide less weak willed than Boost's management, but to date the only big risk that I know they've taken was [https://isocpp.org/about/financial-assistance-policy to fund Eric Niebler's work on Ranges for C++], so I think the jury is still out on whether they will rise to the standards set by the Python Foundation, the Plone Foundation, the Django Foundation or even the Linux Foundation. Which brings me to the final major problem I think there is with C++ ... |
| | 1583 | |
| | 1584 | In practice that means a constant cycle of acquiring and ''maintaining'' regular donations from the firms and users who use your free of cost open source software, whether from fee paying training courses and conferences, or simply through a donate button on the website, but mostly through investing effort to build networks and relationships with your biggest commercial users and ''leveraging'' those networks and relationships into a regular donations stream. Concomitant with that leveraging is a ''reverse leveraging'' by those sponsors on the future strategic direction of the open source project, so when this funding process is working well you the open source org gets funds to dispose upon a future vision of the open source project previously agreed (or at least discussed) with your major sponsors. This is why leveraging your open source project for funding is '''not''' blackmail but rather funded coevolution, despite what many in the C++ leadership might think. |
| | 1585 | |
| | 1586 | In Django, you pitch your idea for some change, whether radical or not, to a small, contained authoritative leadership where the authority to decide and fund any initiative is clearly demarcated. They more often or not are acting really as a filter for appropriately repackaging and presenting ideas to the sponsors for funding, though they usually have some slush money around for the really radical experimental stuff (if it is cheap). The process for enacting change is therefore extremely well specified, and moreover because a central authority will approve or disapprove an idea quickly, you don't waste time pushing ideas without a chance. If they do approve an idea, you get actual true and genuine real support from the leadership instead of being cast alone into the wilderness to argue with a mailing list to build "consensus" for some idea. |
| | 1587 | |
| | 1588 | Compare that to Boost. And Django is hardly the only business orientated open source project. [https://plone.org/foundation Plone has a well established funding pipeline for regular sprints]. [https://assoc.drupal.org/ Drupal is particularly aggressive, and indeed effectively runs a Kickstarter once per release to fund the sprint needed to make the release happen]. Some might argue that these are all products rather than an umbrella of heterogeneous libraries and are therefore fundamentally different, [https://www.apache.org/foundation/sponsorship.html if so consider the funding pipeline the Apache Software Foundation runs]. |
| | 1589 | |
| | 1590 | To sum up this point, back in the early 2000s at the beginning of Boost the improvements needed to the standard C++ standard libraries were obvious and therefore consensus was easy to obtain. This made the management processes developed back then tenable. Also, so many vested interests in inhibiting change or challenge weren't established yet, so Boost worked well and delivered an enormous contribution to the C++ TR1 (ten libraries) and C++ 11 (another ten libraries). |
| | 1591 | |
| | 1592 | But open source, and the world, has moved on, and the current gold standard of open source practice is to run your open source project as a '''business'''. C++ has recently [https://isocpp.org/about set up a Standard C++ Foundation] which could prove less weak willed and ineffective than Boost's current leadership, but to date the only big risk that I know they've taken was [https://isocpp.org/about/financial-assistance-policy to fund Eric Niebler's work on Ranges for C++], so I think the jury is still out on whether they will rise to the standards set by the Python Foundation, the Plone Foundation, the Django Foundation or even the Linux Foundation. Which brings me to the final major cause of why I think C++ is failing to become the best general purpose systems language available ... |
| 1586 | | I hate to be blunt, but as a former ISO SC22 mirror convenor for the Republic of Ireland I will categorically state this: ''The International Standards Organisation is designed to '''standardise existing practice''' not design by committee''. It has the wrong schedule, processes and organisation to develop new standard practice, however much money and resources you throw at it in funding special study groups, individuals to write feature prototypes, and people to act as champions of some feature at every meeting. |
| 1587 | | |
| 1588 | | ISO, if anything, is really where you send your company's representatives to ''stop business damaging things being standardised (by your competitors)''. It has always been this when you reduce the organisation to its fundamentals, and its configuration of one vote per country strongly favours multinational corporations who can field employees in many countries, and therefore gain power to influence standardisation decisions at a global level. And just to repeat myself, by "power to influence" I really mean "power to prevent bad ideas from being standardised" where bad ideas mean anything which could have a hard permanent effect on your profit line. This makes ISO a ''conservative enforcing'' body, and for the record that's a great thing and it's why ISO works well for the purpose of standardisation. |
| | 1596 | I don't know for sure, but I suspect that many of the problems I just outlined in the C++ ecosystem relative to its competitors and peers are recognised by some in the C++ leadership. Certainly, what's gone wrong with the Boost libraries and the refusal to lead library development as they once did has definitely come up in private conversations on multiple occasions. Perhaps as a consequence there has been a shift of moving new standard C++ development to occur under the umbrella of ISO WG21 which is the working group responsible for C++, and [http://boost.2283326.n4.nabble.com/Another-variant-type-was-peer-review-queue-tardiness-was-Cleaning-out-the-Boost-review-queue-Review--tp4674046p4674067.html a concomitant reduction in those same engineers contributing their libraries to Boost for pre-standardisation testing as was historically done]. |
| | 1597 | |
| | 1598 | I hate to be blunt, but as a former ISO SC22 mirror convenor for the Republic of Ireland I will categorically state this: ''The International Standards Organisation is designed to '''standardise existing practice''' not design new standard practice''. It has the wrong schedule, processes and organisation to develop new standard practice, however much money and resources you throw at it in funding special study groups, individuals to write feature prototypes, and people to act as champions of some feature at every meeting. |
| | 1599 | |
| | 1600 | ISO, if anything, is really where you send your company's representatives to ''stop business damaging things being standardised (by your competitors)''. It has always been this when you reduce the purpose of the organisation to its fundamentals, and its configuration of one vote per country strongly favours multinational corporations who can field employees in many countries, and therefore gain power to influence standardisation decisions at a global level. And just to repeat myself, by "power to influence" I really mean "power to prevent bad ideas from being standardised" where bad ideas mean anything which could have a hard permanent effect on your profit line. This makes ISO a ''conservative enforcing'' body, and for the record that's a great thing and it's why ISO works well for the purpose of standardisation. |
| 1610 | | * Show the way forwards for the design of new language features instead of trying to design top down and ending up with a cancer like the original C++ concepts [1]. |
| 1611 | | |
| 1612 | | [1]: During the 2007-2008 push by WG21 to reach C++ 0x, items began to be cut for the first initial draft of what would become C++ 11 for purely political reasons. The big problem was that if you proposed some library X for standardisation, someone on ISO would say "library X would look completely different once expected new language feature Y is in the language, therefore library X shouldn't enter the standard right now". The most damaging expected new language feature Y was undoubtedly original C++ concepts as that killed off entire tracts of exciting C++ library standardisation, much to the often bitterness of those who had invested months to years of their spare time developing those libraries. After all, most new language features are developed by highly paid employees where it is their day jobs, whereas of the twenty or so Boost libraries in C++ 11 were generally developed in the family time of enthusiasts who earned a fraction of the pay of those people on WG21 killing off their work, and to keep a chipper attitude whilst those who have not sacrificed shoot down often years of your work is not easy. No wonder we have seen a slow exodus of Boost old timers since the 2011 C++ standard, some leaving C++ completely for good for employment in large corporations which frown on employees having any interests outside the corporation, some disavowing Boost forever and having anything to do with Boost, and some no longer trying to get their libraries into Boost (i.e. past any form of review process) and preferring to house their C++ libraries elsewhere and specifically away from the Boost community. |
| 1613 | | |
| | 1627 | * Ideally, the Standard C++ Foundation funded implementations would be donated as-is to each of the three major standard C++ library implementations (Dinkumware, libc++, libstdc++) to save them reinventing the wheel. |
| | 1628 | * Unblock WG21 so they can actually get on with standardisation instead of ceaselessly and inefficiently and negatively arguing about standardisation. |
| | 1629 | * Show the way forwards for the design of new language features instead of trying to design top down and ending up with a cancer like the original C++ concepts. I suppose I had better explain what I mean by a cancer in this context, so here goes. During the 2007-2008 push by WG21 to reach C++ 0x, items began to be cut for the first initial draft of what would become C++ 11 for purely political reasons. The big problem was that if you proposed some library X for standardisation, someone on ISO would say "library X would look completely different once expected new language feature Y is in the language, therefore library X shouldn't enter the standard right now". The most damaging expected new language feature Y was undoubtedly original C++ concepts as that killed off entire tracts of exciting C++ library standardisation, much to the often bitterness of those who had invested months to years of their spare time developing those libraries. After all, most new language features are developed by highly paid employees where it is their day jobs, whereas of the twenty or so Boost libraries now in C++ 11 were generally developed in the family time of enthusiasts who earned a fraction of the pay of those people on WG21 killing off their work, and to keep a chipper attitude whilst those who have not sacrificed shoot down often years of your work is not easy. No wonder we have seen a slow exodus of Boost old timers since the 2011 C++ standard, some leaving C++ completely for good for employment in large corporations which frown on employees having any interests outside the corporation, some disavowing Boost forever and having anything to do with Boost, and some no longer trying to get their libraries into Boost (i.e. past any form of review process) and preferring to house their C++ libraries elsewhere and specifically away from potential standardisation. |
| | 1630 | |
| | 1631 | To conclude this rather long section, I believe that if C++ is to remain relevant and fresh in the 21st century, this is needed: |
| | 1632 | |
| | 1633 | * C++ needs to return back to basics, and finish becoming a complete superset for C for almost all users of C. |
| | 1634 | * C++ needs to become the perfect neighbour for other programming languages, and their first choice as a systems programming glue. |
| | 1635 | * Once that is achieved, a proper replacement for Microsoft COM is needed (hopefully reusing the ASIO/Networking TS event loop). |
| | 1636 | * After that, my personal preference would be for an as-if everything inlined build system that eliminates the need for all other C++ build systems. I'll speak more on that idea below. |
| | 1637 | |
| | 1638 | * Boost's leadership or a replacement for Boost takes on the role of proactively deciding what new C++ libraries are needed to solve the strategic goals set and finding contractors to design, peer review and implement such solutions. |
| | 1639 | * This work would be funded by a business orientated Boost or Boost-like open source organisation in collaboration with the Standard C++ Foundation. |
