| 1519 | | == 18. COUPLING/SOAPBOX: Essay about wisdom of defaulting to standalone capable modular (Boost) C++ 11/14 libraries with no external dependencies == |
| 1520 | | |
| 1521 | | If the last section was somewhat speculative due to the present uncertainties about the future developments in C++, these remaining two sections are almost entirely discussion pieces as they have no known good answers. Moreover, this section and the next section are both essays arguing the opposite from one another on the basis of plenty sound good reasons, so the intent is really to make you ''think'' and ''reflect'' before you design your (C++) library. |
| 1522 | | |
| 1523 | | Consider them therefore more as food for thought rather than recommendations, and they are obviously my (Niall Douglas) personal perspective and interpretation on things. I'll make the following discussion quite Boost-centric as contractual NDAs prevent me discussing problems in commercial code bases I have worked upon, but lots of corporations out there (Google is the most famous example) have truly enormous monolithic C++ codebases where this discussion equally applies if not far more so, so please consider find and replacing all mentions of Boost with ''<insert your large C++ code base here>''. |
| 1524 | | |
| 1525 | | And finally, this section is going to look quite eccentric to most engineers as I will use arguments unfamiliar to most in software. Part of this is because I am equally trained (in terms of degrees) in Economics and Management as I am in Software, plus I am an affiliate researcher with the [http://www.wici.ca Waterloo Institute for Complexity and Innovation] Research Institute so this analysis considers software, and the human systems surrounding it, as the one and same [http://en.wikipedia.org/wiki/Complex_system complex system]. |
| | 1522 | |
| | 1523 | == 18. COUPLING/SOAPBOX: Essays on non-technical best practices within the C++ ecosystem == |
| | 1524 | |
| | 1525 | If the last technical section on C++ coroutines was somewhat speculative due to the present uncertainties about the future developments in C++, this entire section of essays is almost entirely discussion pieces as they have no known good answers. I will write as if more certain than I actually am for the purposes of clarity and brevity. Moreover, two of the later essays argue the opposite from one another on the basis of plenty sound good reasons, so the intent is really to make you ''think'' and ''reflect'' about "the big picture" before you design your (C++) library whether or not you agree with anything I write below. |
| | 1526 | |
| | 1527 | Consider them therefore more as food for thought rather than recommendations, and they are obviously my (Niall Douglas) personal perspective and interpretation on things. I'll make any discussion of the problem of how to deal with large legacy C++ code bases Boost-centric as contractual NDAs prevent me discussing problems in commercial code bases I have worked upon, but lots of corporations out there (Google is the most famous example) have truly enormous monolithic C++ codebases where this discussion equally applies if not far more so, so please consider find and replacing all mentions of Boost with ''<insert your large C++ code base here>''. |
| | 1528 | |
| | 1529 | And finally, this section is going to look quite eccentric to most C++ engineers as I will use arguments unfamiliar to most in software. Part of this is because I am equally trained (in terms of degrees) in Economics and Management as I am in Software, plus I am an affiliate researcher with the [http://www.wici.ca Waterloo Institute for Complexity and Innovation] Research Institute so this analysis considers software, and the human systems surrounding it, as the one and same [http://en.wikipedia.org/wiki/Complex_system complex system]. |
| 1529 | | As we all know after a few years of experience, there is a constant tension in large scale software development between '''MODULARITY''' (tightly specified at points of coupling between structures) and '''MONOLITHICITY''' (loose or unspecified at points of coupling between structures) where structures include the human organisations which do the programming. This tradeoff is fundamental to the universe and appears throughout mathematics and physics because of how ''rigidity'' works: the choice between instability and rigidity is always a zero sum tradeoff, so you get to choose which parts of a system you would like to make flexible only by making other parts of the same system inflexible. |
| 1530 | | |
| 1531 | | Modular software has very strongly defined interface contracts between modules. This allows teams working within that module to change the module with any change ripples hopefully never propagating outside the module boundary, and therefore what one team does should not accidentally affect the work of another team if a module boundary is between them. As [http://en.wikipedia.org/wiki/Putnam_model effort required to modify software approximates its size cubed], for very large organisations this is an '''enormous''' productivity gain because it enables your development to occur as if you were working on a much smaller codebase, and [http://en.wikipedia.org/wiki/Component_Object_Model the most popular and successful modularity framework for C++ by far is Microsoft COM] (the latest iteration of which is called [http://en.wikipedia.org/wiki/Windows_Runtime Windows Runtime]). Unfortunately, very strictly defining coupling between modules has an enormous cost in what is allowed to traverse between modules, and even to this day nothing may pass through Microsoft COM/WinRT which cannot be perfectly represented in C, so no C++ feature not perfectly representable in C can traverse a COM boundary. |
| 1532 | | |
| 1533 | | Monolithic software has loose or unspecified (anything goes) interface contracts between parts. This lets programmers do what they want when they want, and that usually means a much more enjoyable experience for the programmer because of the feeling of power and control they get over the code (even if experience and self discipline mean they rarely exercise it). This approach encourages experimentation, fun, prototyping and more often than not is how volunteer-led open source software ends up being organised at a code level, partially because as a hobby you don't want to bother with all the boring compliance and worrying about other teams stuff you have to do at work. However just because an open source codebase may be monolithic internally doesn't mean that open source software is monolithic ''between'' codebase, if anything the extreme modularisation of cloud and web services into individual single purpose solutions supplied at a network socket which others mash together has been the truly defining innovation of the past twenty years of software. |
| | 1533 | As we all know after a few years of experience, there is a constant tension in large scale software development between '''MODULARITY''' (tightly specified at points of coupling between structures) and '''MONOLITHICITY''' (loose or unspecified at points of coupling between structures) where structures include the human organisations which do the programming. This tradeoff is fundamental to the universe and appears throughout mathematics and physics because of how ''rigidity'' works: the choice between unpredictability and rigidity is always a zero sum tradeoff, so you get to choose which parts of a system you would like to make flexible only by making other parts of the same system inflexible. |
| | 1534 | |
| | 1535 | Modular software has very strongly defined interface contracts between modules. This allows teams working within that module to change the module with any change ripples hopefully never propagating outside the module boundary, and therefore what one team does should not accidentally affect the work of another team if a module boundary is between them. As [http://en.wikipedia.org/wiki/Putnam_model effort required to modify software approximates its size cubed], for very large organisations this is an '''enormous''' productivity gain because it enables your development to occur as if you were working on a much smaller codebase, and [http://en.wikipedia.org/wiki/Component_Object_Model the most popular and successful modularity framework for C++ by far is Microsoft COM] (the latest iteration of which is called [http://en.wikipedia.org/wiki/Windows_Runtime Windows Runtime]) which consists of a well specified event handling loop and framework and a well specified method of inspecting and calling functions provided by a COM component. Unfortunately, very strictly defining coupling between modules has an enormous cost in what is allowed to traverse between modules due to needing to prevent ripple traversal, and even to this day nothing may pass through Microsoft COM/WinRT which cannot be perfectly represented in C, so no C++ feature not perfectly representable in C can traverse a COM boundary. |
| | 1536 | |
| | 1537 | Monolithic software has loose or unspecified (anything goes) interface contracts between parts. This lets programmers do what they want when they want, and that usually means a much more enjoyable experience for the programmer because of the feeling of power and control they get over the code (even if experience and self discipline mean they rarely exercise it). This approach encourages experimentation, fun, prototyping and more often than not is how volunteer-led open source software ends up being organised at a code level, partially because as a hobby you don't want to bother with all the boring compliance and worrying about other teams stuff you have to do at work. However just because an open source codebase may be monolithic internally doesn't mean that open source software is monolithic ''between'' codebases, if anything the extreme reusable modularisation of cloud and web services into individual single purpose solutions supplied at a network socket which the internet public mash together has been the truly defining innovation of the past twenty years of software. |
| 1537 | | 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 modularity. The last big innovation in 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. |
| 1538 | | |
| 1539 | | 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 biggest upcoming threat to C++, [http://en.wikipedia.org/wiki/Rust_%28programming_language%29 Rust] by Mozilla) stems from the continuing abject failure of C++ to finish supplanting C as the best general purpose systems language around. |
| 1540 | | |
| 1541 | | A lot of that continuing abject failure to finish supplanting C |
| | 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. |
| | 1544 | |
| | 1545 | A lot of that continuing abject failure to finish supplanting C and become the best general purpose systems language available stems in my opinion from the followings causes: |
| 1545 | | Investing in the development of a real modular component framework substantially improving on Microsoft COM (C++ 1z Modules is actually a build performance feature and has little to nothing to do with actual modularisation - this occurred due to repeated watering downs of the Modules proposal), standardising the C++ ABI, or even providing a C reflection library allowing C code to inspect some unknown C++ binary in a useful way, would go a long way to helping persuade language runtimes such as Python and the other new languages to use the C++ instead of C ABI. Indeed, such is the continuing failure of C++ as a community here that increasingly [http://llvm.org/docs/ExceptionHandling.html LLVM is becoming the next generation "better than C with just enough C++-esque support" ABI]. |
| 1546 | | |
| 1547 | | 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 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. |
| | 1549 | Investing in the development of a real modular component framework substantially improving on Microsoft COM ([http://clang.llvm.org/docs/Modules.html C++ 1z Modules] is actually a build performance feature and has little to nothing to do with actual modularisation -- this occurred due to repeated watering downs of the Modules proposal), standardising the C++ ABI, or even providing a C reflection library allowing C code to inspect some unknown C++ binary in a useful way, would go a long way to helping persuade language runtimes such as Python and the other new languages to use the C++ instead of C ABI. Indeed, such is the continuing failure of C++ as a community here that increasingly [http://llvm.org/docs/ExceptionHandling.html LLVM is becoming the next generation "better than C with just enough C++ stuff support" ABI], so the new systems languages such as Rust target LLVM, indeed the recent conversion of .NET into a portable systems programming platform was also to LLVM. |
| | 1550 | |
| | 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. |
| 1555 | | 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 pursuit outside of normal work hours 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. 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). |
| 1556 | | |
| 1557 | | 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 central repo and web presence is the most prevalent in the newest open source projects simply through them being newer than older projects, and therefore adopting what they felt was the state of the art at the time. |
| | 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 | | 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 on 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, despite what many in the C++ leadership might think. |
| 1565 | | |
| 1566 | | 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 layer which whilst initially was great for those with broken compilers, it incurred an enormous technical 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 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, 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). 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: |
| | 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: |
| 1570 | | One instantly notices the big disclaimer of taking any strategic decisions whatsoever, unless vitally necessary, and the ability to approve funding for unsolicited proposals by the community. This effectively means that the Boost steering committee is really a board of trustees who have very little direct interaction with the thing they approve funding for, and that is pretty much what happens in practice. |
| 1571 | | |
| 1572 | | 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 power to decide and fund an 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, it actually happens. |
| 1573 | | |
| 1574 | | 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 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 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 dis-spiriting 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. |
| | 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 | 4. '''A pathological overemphasis on the primacy of ISO WG21 as the right place to lead out the evolution of C++''' |
| | 1585 | |
| | 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. |
| | 1589 | |
| | 1590 | It also makes it a lousy place to invent new stuff. I mentioned earlier that attending WG21 has of late become particularly negative and exhausting, and a lot of that is because too many contentious decisions are being squeezed into a place ill suited to take contentious decisions. ISO meetings are supposed to be about: |
| | 1591 | * Reviewing existing practice in an engineering field. |
| | 1592 | * Debating if some existing practice is ready for standardisation. |
| | 1593 | * If so, what minor trivia need fixing before standardisation. |
| | 1594 | * If not, end of discussion and meeting over. |
| | 1595 | In other words, if a decision is "hard" at ISO, that means whatever it is isn't ready for standardisation. Debate -- at WG21 at least -- is concluded. |
| | 1596 | |
| | 1597 | The problem of ill fit for anything innovative at ISO is exactly why ISO WG15 (POSIX) decided to relocate its decision making to the Austin Working Group. And even then the AWG almost exclusively reviews existing practice in POSIX implementations, debates if it's ready for standardisation, and if so formalises a regular report to send to ISO WG15 for country-level debate and standardisation. If you want a new item into POSIX the process is straightforward and uncontroversial: |
| | 1598 | * Implement it in a POSIX implementation of your choice (usually Linux, sometimes FreeBSD). |
| | 1599 | * Get people using it over a period of years. |
| | 1600 | * Implement it in many POSIX implementations, or get someone else to do it for you. |
| | 1601 | * Get more people using it in a cross-platform way for a period of years. |
| | 1602 | * Ask the Austin Working Group to consider standardising it. |
| | 1603 | * Spend another few years fine tuning the standard text and getting it signed off by the major POSIX implementations (this part is easy if they already have an implementation). |
| | 1604 | * Profit! |
| | 1605 | Total time is typically five to ten years, but then adjusting POSIX is supposed to be extremely conservative and hard. |
| | 1606 | |
| | 1607 | As it probably should be for C++ language features, but I don't think it should be so for C++ standard libraries. If instead of throwing money inefficiently at trying to make WG21 dance other to its nature the Standard C++ Foundation instead funded the strategic directed evolution of quality C++ libraries just as the Python Foundation does for Python or the Plone Foundation does for Plone they would: |
| | 1608 | * Replace Boost with something far more proactive, modern and capable of giving a good fight to the upstart systems programming languages. |
| | 1609 | * Establish and ''maintain'' '''best practice''' for C++ library development with a funded model which can then be easily standardised by WG21 after a library becomes the established standard practice. |
| | 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 | |
| | 1614 | |
