| 1521 | | |
| 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]. |
| 1530 | | |
| 1531 | | === Modular vs Monolithic === |
| 1532 | | |
| 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. |
| 1538 | | |
| 1539 | | === C++ in the 21st century - THIS SECTION STILL BEING WORKED UPON === |
| 1540 | | |
| 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). |
| 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: |
| 1546 | | |
| 1547 | | 1. '''A deliberate refusal by C++ to finish becoming a better systems glue language''' |
| 1548 | | |
| 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 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. |
| 1554 | | |
| 1555 | | 2. '''A tiredness and fear of disruptive change in the C++ thought leadership''' |
| 1556 | | |
| 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 related to your qualifications despite holding multiple Masters degrees and being vastly more qualified, and sometimes more able, than the people interviewing you. This is obviously leads to a '''very''' different experience and understanding of open source software. Part of it is due to the inherant cultural differences and world view of [https://en.wikipedia.org/wiki/Millennials the Millennials] versus [https://en.wikipedia.org/wiki/Baby_boomers the Baby Boomers], but it is also due the widespread understanding that today's younger programmers will likely not retire until far beyond the present retirement age, and with very substantially fewer assets and income. That profoundly adjusts the cost benefit of serving your time and waiting your turn over the baby boomer generation, never mind working sixty plus hour weeks with two week's vacation until then. |
| 1564 | | |
| 1565 | | It's different for each of course, but for many a younger programmer including myself 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's vision before everything else in your life, including your family, and will dispose of you as a cost to be reduced as soon as they are able. 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 would exploit you, whether self employed via a startup or remote expert consulting for some solid hourly rate at which point those same earlier employers tend to suddenly value your time and inconvenience oddly enough, and don't keep creating the situations where you must constantly work overtime for no extra income. |
| 1566 | | |
| 1567 | | I suspect I am not alone in this world view. Not coincidentally most of the big and especially recent 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. |
| 1568 | | |
| 1569 | | In case you are one of those engineers of a certain age and think I'm talking out my arse 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: |
| 1570 | | |
| 1571 | | ''"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."'' |
| 1572 | | |
| 1573 | | 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. |
| 1574 | | |
| 1575 | | 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 some 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 before. 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. |
| 1576 | | |
| 1577 | | Note that if you have a job with a high status role, excellent pay 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 reaction do not of course voice it, and simply silently leave the community for somewhere more contemporary and less hostile to evolution. |
| 1578 | | |
| 1579 | | 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): |
| 1580 | | |
| 1581 | | * Supports development of Django by sponsoring sprints, meetups, gatherings and community events. |
| 1582 | | * Promote the use of Django amongst the world-wide Web development community. |
| 1583 | | * Protect the intellectual property and the framework's long-term viability (i.e. invest in blue sky new development). |
| 1584 | | * Advance the state of the art in Web development. |
| 1585 | | |
| 1586 | | 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 some of the older generation might think. |
| 1587 | | |
| 1588 | | 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 with funding, marketing and informing the community what is happening next and why instead of being cast alone into the wilderness to argue with a mailing list to build "consensus" for some idea. |
| 1589 | | |
| 1590 | | 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 each 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] and [https://www.apache.org/foundation/governance/ the full time employees they have maintaining their crucial infrastructure]. |
| 1591 | | |
| 1592 | | 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). |
| 1593 | | |
| 1594 | | 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 more promising, 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 ... |
| 1595 | | |
| 1596 | | 4. '''A pathological overemphasis on the primacy of ISO WG21 as the right place to lead out the evolution of C++''' |
| 1597 | | |
| 1598 | | 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 standard 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++ (library) 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 real world testing as was historically done]. |
| 1599 | | |
| 1600 | | 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. |
| 1601 | | |
| 1602 | | 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. |
| 1603 | | |
| 1604 | | 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: |
| 1605 | | |
| 1606 | | * Reviewing existing practice in an engineering field. |
| 1607 | | * Debating if some existing practice is ready for standardisation. |
| 1608 | | * If so, what minor trivia need fixing before standardisation. |
| 1609 | | * If not, end of discussion and next item. |
| 1610 | | |
| 1611 | | In other words, if a decision is "hard" at ISO, that means whatever it is isn't ready for standardisation. Debate -- at ISO level at least -- is concluded. |
| 1612 | | |
| 1613 | | 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: |
| 1614 | | |
| 1615 | | * Implement it in a POSIX implementation of your choice (usually Linux, sometimes FreeBSD). |
| 1616 | | * Get people using it over a period of years. |
| 1617 | | * Implement it in many POSIX implementations, or get someone else to do it for you because it was so popular in Linux. |
| 1618 | | * Get more people using it in a cross-platform way for a period of years. |
| 1619 | | * Ask the Austin Working Group to consider standardising it. |
| 1620 | | * 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). |
| 1621 | | * Profit! |
| 1622 | | |
| 1623 | | Total time is typically five to ten years, but then adjusting POSIX the standardisation of portable operating system APIs is supposed to be extremely conservative and hard and rightly so. |
| 1624 | | |
| 1625 | | It probably should be just as conservative and hard to change 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: |
| 1626 | | |
| 1627 | | * Create a strategically guided and managed proactive and modern central registry of locations of high quality C++ libraries capable of giving a good fight to the upstart systems programming languages. |
| 1628 | | * Establish and ''maintain'' the infrastructure for tooling, processes, conventions and governance for '''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. |
| 1629 | | * 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. |
| 1630 | | * Unblock WG21 so they can actually get on with standardisation instead of ceaselessly and inefficiently and negatively arguing about standardisation. |
| 1631 | | * 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 experience which led to the 2011 C++ standard. |
| 1632 | | |
| 1633 | | To conclude this rather long section, I believe that if C++ is to remain relevant and fresh in the 21st century, this is needed: |
| 1634 | | |
| 1635 | | * C++ needs to return back to basics, and finish becoming a complete superset for C for almost all users of C. |
| 1636 | | * C++ needs to become the perfect neighbour for other programming languages, and their first choice as a systems programming glue. |
| 1637 | | * Once that is achieved, a proper replacement for Microsoft COM is needed (hopefully reusing the ASIO/Networking TS event loop) as a true demonstration of all modularity and reusability can be in C++. |
| 1638 | | * After that, my personal preference would be for an "as-if everything inlined" native build system that eliminates the need for all other C++ build systems. I'll speak more on that idea below. |
| 1639 | | |
| 1640 | | * Boost's leadership or a replacement for Boost takes on the role of proactively determing what new C++ libraries are needed to solve the strategic goals set by the Foundation and by commercial sponsors, and finding contractors to design, peer review and implement such solutions. |
| 1641 | | * This work would be funded by a business orientated Boost or Boost-like open source organisation in collaboration with the Standard C++ Foundation. |
| 1642 | | |
| 1643 | | |
| 1644 | | |
| 1645 | | TODO AFTER THIS |
| 1646 | | |
| 1647 | | |
| 1648 | | |
| 1649 | | === TODO Essay about wisdom of defaulting to standalone capable modular (Boost) C++ 11/14 libraries with no external dependencies VS Essay about wisdom of dependency package managers in C++ 11/14 === |
| 1650 | | |
| 1651 | | TODO |
| 1652 | | |
| 1653 | | The obvious answer is that if a library is capable of coexisting inside multiple collections of libraries including the collection of just itself alone, that enormously increases the scope and opportunity for working around the size limit of seventy. You could, as I have often proposed, have a v1.x collection of legacy C++ 03 Boost libraries and a v2.x collection of C++ 14 Boost libraries where there is some overlap between the collections in that some C++ 03 Boost libraries are available in both collections. One therefore raises the scaling limit from about seventy to potentially one hundred and twenty or so for two collections without suffering from undermaintenance, malaise or staleness as an organisation. If your library defaults to being standalone capable and modular, that ''enormously'' improves your ability to have your library coexist in multiple collections of libraries. [https://github.com/boostcon/cppnow_presentations_2015/raw/master/files/Large-Projects-and-CMake-and-git-oh-my.pdf You therefore are writing ''social code'', not ''a-social code'']. |
| 1654 | | |
| 1655 | | However, let's assume you don't buy the hard scaling limit to a collection size and instead have some more practical use scalability problems such as: |
| 1656 | | |
| 1657 | | * I would like Boost (as a whole) to have fewer system requirements (minimum compiler versions, minimum OS support etc). This is usually really an argument in favour of better support for either legacy compilers OR embedded or games systems, but do note the substantial distinction for later. |
| 1658 | | |
| 1659 | | * I would like my favourite Boost libraries to have fewer requirements on their dependencies including other Boost libraries, especially exact version requirements (i.e. I want my favourite Boost library to detect and work with multiple versions of Boost). This is usually an argument from those who experience problems with things mildly breaking in different places in each Boost release, and they end up having to mash up their own Boost distro made up of newer and older individual Boost libraries to get the stability they need. |
| 1660 | | |
| 1661 | | * I would like my favourite Boost libraries to optionally not have the word "Boost" in their names as my [https://stackoverflow.com/questions/755439/boost-is-just-great-and-free-is-there-a-catch employer has explicitly banned all libraries with Boost in their name now and forever in perpetuity, requiring me to duplicate Boost code which passes the same Boost unit test suite as the original]. |
| 1662 | | |
| 1663 | | * I would like to download my favourite Boost libraries and only their strict dependencies within Boost without having to download or even consider during build or configuration any unnecessary other Boost libraries (i.e. the package manager argument). |
| 1664 | | |
| 1665 | | * I would like to use my favourite Boost library using the Standard C++ Library facilities that come with C++ 11 instead of being forced into using Boost near equivalents (i.e. I get annoyed dealing with mixes of `std::future` and `boost::future`). |
| 1666 | | |
| 1667 | | * I would like to drop my favourite Boost library/libraries into my project as a single giant include file with no need to worry about Boost.Build or any build system or even dealing with a Boost source control system. |
| 1668 | | |
| 1669 | | As much as these often cited user problems might seem unrelated, they are in fact all due to the lack of: |
| 1670 | | |
| 1671 | | 1. '''Modularity''' |
| 1672 | | |
| 1673 | | Your users can download your library as a self contained distribution, and get immediately to work. The ideal of this form is a single standalone include file which contains everything the library user needs. |
| 1674 | | |
| 1675 | | 2. '''Encapsulation''' |
| 1676 | | |
| 1677 | | Thinking about and specifying your dependencies properly instead of just firing in some reference to `boost::lib::foo` and dragging in a whole library just for a single routine. [http://arxiv.org/abs/1405.3323 C++ has also spectacularly failed to improve on Microsoft COM as the best available technology for fully encapsulating C++ libraries unfortunately], and as much as such work is "unsexy" the fact a proper C++ component and modularisation system doesn't have [https://isocpp.org/std/the-committee a study group at ISO WG21] is an appalling tragedy given the [https://en.wikipedia.org/wiki/Service-orientation enormous and very well understood productivity gains] you get from such a technology. |
| 1678 | | |
| 1679 | | 3. '''Low cost trial''' |
| 1680 | | |
| 1681 | | From a library user perspective, the biggest overwhelming incentive is usually to adopt "[https://en.wikipedia.org/wiki/Not_invented_here Not Invented Here]" as that best ensures continued employment at least in the medium term. So as a library author, if you want anyone to use your library you need to eliminate as many reasons for a library user to find an excuse not to use your library as possible. One of the biggest excuses users will have is simply that of the cost of trying out your library for fit to solving a problem: is installation ready for development a single action? Does including this library quadruple my build times? Does code using this library ever crash, including the compiler? Do I have to click the mouse more than three times to find something in the documentation? If the answer is yes to any of those questions, your library does not have a low cost trial curve, and could even be ''a-social coding''. |
| 1682 | | |
| 1683 | | 4. '''Forcing choices onto the library user unnecessarily''' |
| 1684 | | |
| 1685 | | When your library insists on only ever using `boost::future` and being incapable of using `std::future`, you force your library users to write boilerplate to convert between types of future because another library dependency insists on only ever using `std::future`. There is no good reason whatsoever why your library forces that choice on its users, except your laziness in not upgrading your library to make better use of the C++ 11 standard library. |
| 1686 | | |
| 1687 | | Most of the earlier problems go away if you address these four issues, but you'll note that dependency management is essentially being statically done by hand by the library maintainer due to that lack of a modern equivalent to Microsoft COM I mentioned. The wisdom of dependency package managers in C++ 11/14 is exactly what I'll write about next. |
| 1688 | | |
| 1689 | | git submodules |
| 1690 | | biicode |
| 1691 | | etc |
