document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-03 23:40:14 +08:00
Code Issues Packages Projects Releases Wiki Activity

Translated by qhwdw

Browse Source
This commit is contained in:
qhwdw 2018-09-28 14:28:42 +08:00
parent e3ce1dac16
commit 0e1bfd595b
2 changed files with 163 additions and 155 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

155
sources/tech/20180618 What-s all the C Plus Fuss- Bjarne Stroustrup warns of dangerous future plans for his C.md
View File

@ -1,155 +0,0 @@
Translating by qhwdw
What's all the C Plus Fuss? Bjarne Stroustrup warns of dangerous future plans for his C++
======
![](https://regmedia.co.uk/2018/06/15/shutterstock_38621860.jpg?x=442&y=293&crop=1)
**Interview** Earlier this year, Bjarne Stroustrup, creator of C++, managing director in the technology division of Morgan Stanley, and a visiting professor of computer science at Columbia University in the US, wrote [a letter][1] inviting those overseeing the evolution of the programming language to “Remember the Vasa!”
Easy for a Dane to understand no doubt, but perhaps more of a stretch for those with a few gaps in their knowledge of 17th century Scandinavian history. The Vasa was a Swedish warship, commissioned by King Gustavus Adolphus. It was the most powerful warship in the Baltic Sea from its maiden voyage on the August 10, 1628, until a few minutes later when it sank.
The formidable Vasa suffered from a design flaw: it was top-heavy, so much so that it was [undone by a gust of wind][2]. By invoking the memory of the capsized ship, Stroustrup served up a cautionary tale about the risks facing C++ as more and more features get added to the language.
Quite a few such features have been suggested. Stroustrup cited 43 proposals in his letter. He contends those participating in the evolution of the ISO standard language, a group known as [WG21][3], are working to advance the language but not together.
In his letter, he wrote:
>Individually, many proposals make sense. Together they are insanity to the point of endangering the future of C++.
He makes clear that he doesn’t interpret the fate of the Vasa to mean that incremental improvements spell doom. Rather, he takes it as a lesson to build a solid foundation, to learn from experience and to test thoroughly.
With the recent conclusion of the C++ Standardization Committee Meeting in Rapperswil, Switzerland, earlier this month, Stroustrup addressed a few questions put to him by _The Register_ about what's next for the language. (The most recent version is C++17, which arrived last year; the next version C++20 is under development and expected in 2020.)
**_Register:_ In your note, Remember the Vasa!, you wrote:**
>The foundation begun in C++11 is not yet complete, and C++17 did little to make our foundation more solid, regular, and complete. Instead, it added significant surface complexity and increased the number of features people need to learn. C++ could crumble under the weight of these – mostly not quite fully-baked – proposals. We should not spend most our time creating increasingly complicated facilities for experts, such as ourselves.
**Is C++ too challenging for newcomers, and if so, what features do you believe would make the language more accessible?**
_**Stroustrup:**_ Some parts of C++ are too challenging for newcomers.
On the other hand, there are parts of C++ that makes it far more accessible to newcomers than C or 1990s C++. The difficulty is to get the larger community to focus on those parts and help beginners and casual C++ users to avoid the parts that are there to support implementers of advanced libraries.
I recommend the [C++ Core Guidelines][4] as an aide for that.
Also, my “A Tour of C++” can help people get on the right track with modern C++ without getting lost in 1990s complexities or ensnarled by modern facilities meant for expert use. The second edition of “A Tour of C++” covering C++17 and parts of C++20 is on its way to the stores.
I and others have taught C++ to 1st year university students with no previous programming experience in 3 months. It can be done as long as you don’t try to dig into every obscure corner of the language and focus on modern C++.
“Making simple things simple” is a long-term goal of mine. Consider the C++11 range-for loop:
```
for (int& x : v) ++x; // increment each element of the container v
```
where v can be just about any container. In C and C-style C++, that might look like this:
```
for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v
```
Some people complained that adding the range-for loop made C++ more complicated, and they were obviously correct because it added a feature, but it made the _use_ of C++ simpler. It also eliminated some common errors with the use of the traditional for loop.
Another example is the C++11 standard thread library. It is far simpler to use and less error-prone than using the POSIX or Windows thread C APIs directly.
**_Register:_ How would you characterize the current state of the language?**
_**Stroustrup:**_ C++11 was a major improvement of C++ and C++14 completed that work. C++17 added quite a few features without offering much support for novel techniques. C++20 looks like it might become a major improvement. The state of compilers and standard-library implementations are excellent and very close to the latest standards. C++17 is already usable. The tool support is improving steadily. There are lots of third-party libraries and many new tools. Unfortunately, those can be hard to find.
The worries I expressed in the Vasa paper relate to the standards process that combines over-enthusiasm for novel facilities with perfectionism that delays significant improvements. “The best is the enemy of the good.” There were 160 participants at the June Rapperswil meeting. It is hard to keep a consistent focus in a group that large and diverse. There is also a tendency for experts to design more for themselves than for the community at large.
**Register: Is there a desired state for the language or rather do you strive simply for a desired adaptability to what programmers require at any given time?
**Stroustrup:** Both. I’d like to see C++ supporting a guaranteed completely type-safe and resource-safe style of programming. This should not be done by restricting applicability or adding cost, but by improved expressiveness and performance. I think it can be done and that the approach of giving programmers better (and easier to use) language facilities can get us there.
That end-goal will not be met soon or just through language design alone. We need a combination of improved language features, better libraries, static analysis, and rules for effective programming. The C++ Core Guidelines is part of my broad, long-term approach to improve the quality of C++ code.
**Register: Is there an identifiable threat to C++? If so, what form does that take? (e.g. slow evolution, the attraction of emerging low-level languages, etc...your note seems to suggest it may be too many proposals.)**
**Stroustrup:** Certainly; we have had 400 papers this year already. They are not all new proposals, of course. Many relate the necessary and unglamorous work on precisely specifying the language and its standard library, but the volume is getting unmanageable. You can find all the committee papers on the WG21 website.
I wrote the “Remember the Vasa!” as a call to action. I am scared of the pressure to add language features to address immediate needs and fashions, rather than to strengthen the language foundations (e.g. improving the static type system). Adding anything new, however minor carries a cost, such as implementation, teaching, tools upgrades. Major features are those that change the way we think about programming. Those are the ones we must concentrate on.
The committee has established a “Direction Group” of experienced people with strong track records in many areas of the language, the standard library, implementation, and real-word use. I’m a member and we wrote up something on direction, design philosophy, and suggested areas of emphasis.
For C++20, we recommend to focus on:
Concepts
Modules (offering proper modularity and dramatic compile-time improvements)
Ranges (incl. some of the infinite sequence extensions)
Networking Concepts in the standard library
After the Rappwerwil meeting, the odds are reasonable, though getting modules and networking is obviously a stretch. I’m an optimist and the committee members are working very hard.
I don’t worry about other languages or new languages. I like programming languages. If a new language offers something useful that other languages don’t, it has a role and we can all learn from it. And then, of course, each language has its own problems. Many of C++’s problems relate to its very wide range of application areas, its very large and diverse user population, and overenthusiasm. Most language communities would love to have such problems.
**Register: Are there any architectural decisions about the language you've reconsidered?**
**Stroustrup:** I always consider older decisions and designs when I work on something new. For example, see my History of Programming papers 1, 2.
There are no major decisions I regret, though there is hardly any feature I wouldn’t do somewhat differently if I had to do it again.
As ever, the ability to deal directly with hardware plus zero-overhead abstraction is the guiding idea. The use of constructors and destructors to handle resources is key (RAII) and the STL is a good example of what can be done in a C++ library.
**Register: Does the three-year release cadence, adopted in 2011 it seems, still work? I ask because Java has been dealing with a desire for faster iteration.**
**Stroustrup:** I think C++20 will be delivered on time (like C++14 and C++17 were) and that the major compilers will conform to it almost instantly. I also hope that C++20 will be a major improvement over C++17.
I don’t worry too much about how other languages manage their releases. C++ is controlled by a committee working under ISO rules, rather by a corporation or a “beneficent dictator for life.” This will not change. For ISO standards, C++’s three-year cycle is a dramatic innovation. The standard is 5- or 10-year cycles.
**Register: In your note you wrote:**
We need a reasonably coherent language that can be used by 'ordinary programmers' whose main concern is to ship great applications on time.
Are changes to the language sufficient to address this or might this also involve more accessible tooling and educational support?
**Stroustrup:** I try hard to communicate my ideas of what C++ is and how it might be used and I encourage others to do the same.
In particular, I encourage presenters and authors to make useful ideas accessible to the great mass of C++ programmers, rather than demonstrating how clever they are by presenting complicated examples and techniques. My 2017 CppCon keynote was “Learning and Teaching C++” and it also pointed to the need for better tools.
I mentioned build support and package managers. Those have traditionally been areas of weakness for C++. The standards committee now has a tools Study Group and will probably soon have an Education Study group.
The C++ community has traditionally been completely disorganized, but over the last five years many more meetings and blogs have sprung up to satisfy the community’s appetite for news and support. CppCon, isocpp.org, and Meeting++ are examples.
Design in a committee is very hard. However committees are a fact of life in all large projects. I am concerned, but being concerned and facing up to the problems is necessary for success.
**Register: How would you characterize the C++ community process? Are there aspects of the communication and decision making procedure that you'd like to see change?**
**Stroustrup:** C++ doesn’t have a corporately controlled “community process”; it has an ISO standards process. We can’t significantly change the ISO rules. Ideally, we’d have a small full-time “secretariat” making the final decisions and setting directions, but that’s not going to happen. Instead, we have hundreds of people discussion on-line, about 160 people voting on technical issues, about 70 organizations and 11 nations formally voting on the resulting proposals. That’s messy, but sometimes we make it work.
**Register: Finally, what upcoming C++ features do you feel will be most beneficial for C++ users?**
**Stroustrup:**
+ Concepts to significantly simplify generic programming
+ _Parallel algorithms – there is no easier way to use the power of the concurrency features of modern hardware
+ Coroutines, if the committee can decide on those for C++20.
+ Modules to improve the way organize our source code and dramatically improve compile times. I hope we can get such modules, but it is not yet certain that we can do that for C++20.
+ A standard networking library, but it is not yet certain that we can do that for C++20.
In addition:
+ Contracts (run-time checked pre-conditions, post-conditions, and assertions) could become significant for many.
+ The date and time-zone support library will be significant for many (in industry).
**Register: Is there anything else you'd like to add?**
**Stroustrup:** If the C++ standards committee can focus on major issues to solve major problems, C++20 will be great. Until then, we have C++17 that is still far better than many people’s outdated impressions of C++. ®
--------------------------------------------------------------------------------
via: https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
作者：[Thomas Claburn][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:http://www.theregister.co.uk/Author/3190
[1]:http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
[2]:https://www.vasamuseet.se/en/vasa-history/disaster
[3]:http://open-std.org/JTC1/SC22/WG21/
[4]:https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
[5]:https://go.theregister.co.uk/tl/1755/shttps://continuouslifecycle.london/

163
translated/tech/20180618 What-s all the C Plus Fuss- Bjarne Stroustrup warns of dangerous future plans for his C.md Normal file
View File

@ -0,0 +1,163 @@
# 关于 C ++ 的所有争论？Bjarne Stroustrup 警告他的 C++ 未来的计划很危险
![](https://regmedia.co.uk/2018/06/15/shutterstock_38621860.jpg?x=442&y=293&crop=1)
今年早些时候，我们**访谈**了 Bjarne Stroustrup，他是 C++ 语言的创始人，摩根士丹利技术部门的董事总经理，美国哥伦比亚大学计算机科学的客座教授，他写了[一封信][1]邀请那些关注编程语言演进的人去“想想瓦萨号！”
毫无疑问，对于丹麦人来说，这句话很容易理解，而那些对于 17 世纪的斯堪的纳维亚历史了解不多的人，还需要展开说一下。瓦萨号是一艘瑞典军舰，由国王 Gustavus Adolphus 委托建造。它是在 1628 年 8 月 10 日首航时，当时波罗的海国家中最强大的军舰，但是它在首航几分钟之后就沉没了。
巨大的瓦萨号有一个难以解决的设计缺陷：头重脚轻，以至于它被[一阵狂风刮翻了][2]。通过这段翻船历史的回忆，Stroustrup 警示了 C++ 所面临的风险，因为现在越来越多的特性被添加到了 C++ 中。
现在已经提议了不少这样的特性。Stroustrup 在他的信中引用了 43 条提议。他认为那些参与 C++ 语言 ISO 标准演进的人（指众所周知的 [WG21][3]），正在努力地让语言更高级，但他们的努力方向却并不一致。
在他的信中，他写道：
> 分开来看，许多提议都很有道理。但将它们综合到一起，这些提议是很愚蠢的，将危害 C++ 的未来。
他明确表示，不希望 C++ 重蹈瓦萨号的覆辙，这种渐近式的改进将敲响 C++ 的丧钟。相反，应该吸取瓦萨号的教训，构建一个坚实的基础，吸取经验教训，并做彻底的测试。
在瑞士拉普斯威尔（Rapperswill）召开的 C++ 标准化委员会会议之后，本月早些时候，Stroustrup 接受了_《The Register》_ 的采访，回答了有关 C++ 语言下一步发展方向方面的几个问题。（最新版是 C++17，它去年刚发布；下一个版本是 C++20，它正在开发中，预计于 2020 年发布。）
**Register：在你的信件《想想瓦萨号！》中，你写道：**
> 在 C++11 开始基础不再完整，而 C++17 中在使基础更加稳固、规范和完整方面几乎没有改善。相反地，却增加了重要接口的复杂度，让人们需要学习的特性数量越来越多。C++ 可能在这种提议的重压之下崩溃 —— 这些提议大多数都不成熟。我们不应该花费大量的时间为专家级用户们（比如我们自己）去创建越来越复杂的东西。~~（还要考虑普通用户的学习曲线，越复杂的东西越不易普及。）~~
**对新人来说，C++ 很难吗？如果是这样，你认为怎样的特性让新人更易理解？**
**Stroustrup：**C++ 的有些东西对于新人来说确实很难。
换句话说，C++ 中有些东西对于新人来说，比起 C 或上世纪九十年代的 C++ 更容易理解了。而难点是让大型社区专注于这些部分，并且帮助新手和普通 C++ 用户去规避那些对高级库实现提供支持的部分。
我建议使用 [C++ 核心准则][4] 作为实现上述目标的一个辅助。
此外，我的 “C++ 教程” 也可以帮助人们在使用现代 C++ 时走上正确的方向，而不会迷失在自上世纪九十年代以来的复杂性中，或困惑于只有专家级的用户才能理解的东西中。第二版的 “C++ 教程” 涵盖了 C++17 和部分 C++20 的内容，这本书即将要出版了。
我和其他人给没有编程经验的大一新生教过 C++，只要你不去深挖编程语言的每个晦涩难懂的角落，把注意力集中到 C++ 中最主流的部分，在三个月内新可以学会 C++。
“让简单的东西保持简单” 是我长期追求的目标。比如 C++11 的 `range-for` 循环：
```
for (int& x : v) ++x; // increment each element of the container v
```
`v` 的位置可以是任何容器。在 C 和 C 风格的 C++ 中，它可能看到的是这样：
```
for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v
```
一些人报怨说添加了 `range-for` 循环让 C++ 变得更复杂了，很显然，他们是正确的，因为它添加了一个新特性，但它却让 C++ 用起来更简单。同时它还解决掉了传统 for 循环中出现的一些常见错误。
另外的一个例子是 C++11 的标准线程库。它比起使用 POSIX 或直接使用 Windows 的 C API 来说更简单，并且更不易出错。
**Register：你如何看待 C++ 现在的状况？**
**Stroustrup：** C++11 是 C++ 的最重大的改进版，并且在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性，但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况和标准库实现的非常好，非常接近最新的标准。C++17 已经可用。持续改进了对工具的支持。已经有了许多第三方的库和许多新工具。而不幸的是，这些东西不太好找到。
我在《想想瓦萨号！》一文中所表达的担忧与标准化过程有关，对新东西的过度热情与完美主义的组合拖延了重大的改进。“追述完美是优秀的敌人”，在六月份拉普斯威尔的会议上有 160 人参与。在这样一个数量庞大和多样化的人群中很难取得一致意见。这就导致了专家们更多地为他们自己去设计，而不是为了整个社区。
**Register： C++ 是否有一个期望的状况，或为了期望的适应性而努力简化以满足程序员们在任意时间的需要？**
**Stroustrup：** 二者都有。我很乐意看到 C++ 支持彻底保证类型安全和资源安全的编程方式。这不应该通过限制适用性或增加成本来实现，而是应该通过改进的表达能力和性能来实现。我认为可以做到这些，通过让程序员使用更好的（更易用的）语言可以实现这一点。
终极目标不会马上实现，也不会单靠语言的设计来实现。为了让编程更高效，我们需要通过改进语言特性、最好的库、静态分析、以及规则的组合来实现。C++ 核心准则是我提升 C++ 代码质量的广泛而长远的方法。
**Register：对于 C++ 是否有明显的风险？如果有，它是如何产生的？（如，改进过于缓慢，新出现的低级语言，等等，从你的信中看，似乎是提议过多。）**
**Stroustrup：**毫无疑问，今年我们已经收到了 400 个提议。当然，它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关，但是量大到难以管理。你可以在 WG21 的网站上找到所有这些文章。
我写了《想想瓦萨号！》这封信作为一个呼吁。我感受到了这种压力，为解决紧急需要和赶时髦而增加语言特性，而不是去加强语言基础（比如，改善静态类型系统）。增加的任何新东西，无论它是多小都会产生成本，比如实现、学习、工具升级。重大的特性是那些改变我们编程思想的特性。那才是我们必须关注的东西。
委员会已经设立了一个”指导小组“，这个小组由在语言、标准库、实现、以及实际使用领域中拥有极强履历的人组成。我是其中的成员之一。我们负责为重点领域写一些关于方向、设计理念和建议方面的东西。
对于 C++20，我们建议去关注：
```
概念
模块(提供适当的模块化和令人称奇的编译时改进)
Ranges（包括一些无限序列的扩展）
标准库中的网络概念
```
在拉普斯威尔会议之后，虽然带来的模块和网络化很显然只是一种延伸，但机会还是有的。我是一个乐观主义者，并且委员会的成员们都非常努力。
我并不担心其它语言或新语言会取代它。我喜欢编程语言。如果一个新的语言提供了其它编程语言没有提供的非常有用的东西，那它就是我们从中学习的榜样，当然，每个语言都有它自己的问题。许多 C++ 的问题都与它广泛的应用领域、大量的使用人群和过度的热情有关。大多数语言的社区都喜欢有这样的问题。
**Register：关于 C++ 你是否重新考虑过任何架构方面的决策？**
**Stroustrup：** 当我使用一些新的编程语言时，我经常思考 C++ 原来的决策和设计。例如，可以看我的《编程的历史》论文第 1、2 部分。
并没有让我觉得很懊悔的重大决策，如果让我重新再做一次决策，几乎不会对现有的特性做任何不同的改变。
与以前一样，能够直接处理硬件加上零开销的抽象是设计的指导思想。使用构造函数和析构函数去处理资源是关键（RAII），STL 就是在 C++ 库中能够做什么的一个很好的例子。
**Register：在 2011 年采纳的每三年发布一个标准的节奏是否仍然有效？我之所以这样问是因为 Java 为了更快地迭代，一直在解决需求。**
**Stroustrup：**我认为 C++20 将会按时发布（就像 C++14 和 C++17 那样），并且主要的编译器也会立即遵从它。我也希望 C++20 比起 C++17 能有重大的改进。
对于其它语言如何管理它们的发行版我并不焦虑。C++ 是由一个遵循 ISO 规则的委员会来管理的，并不是由一个大公司或一个”创造它的权威“来管理。这一点不会改变。关于 ISO 标准，C++ 每三年发布一次的周期是一个激动人心的创举。标准的周期是 5 或 10 年。
**Register：在你的信中你写道：**
```
我们需要一个能够被”普通程序员“使用的条理还算清楚的编程语言，他们主要关心的是能否按时高质量地交付他们的应用程序。
```
对语言的改变是否能够去解决这个问题，或者还可能涉及到更多容易获得的工具和教育支持？
**Stroustrup：**我努力去宣传我的理念 —— C++ 是什么以及如何使用它，并且我鼓励其他人也和我一样去做。
特别是，我鼓励讲师和作者们向 C++ 程序员们宣扬有用易用的理念，而不是去示范复杂的示例和技术来展示他们自己有多高明。我在 2017 年的 CppCon 大会上的演讲主题就是”学习和教学 C++“，并且也指出 C++ 需要更好的工具。
我在演讲中提到构建支持和包管理器。这些历来都是 C++ 的弱点项。标准化委员会现在有一个工具研究小组，或许不久的将来也会有一个教育研究小组。
C++ 的社区以前基本上是很乱的，但是在过去的五年里，为了满足社区对新闻和支持的需要，出现了很多会议和博客。CppCon、isocpp.org、以及 Meeting++ 就是这样的例子。
在委员会中做设计是非常困难的。但是，对于所有的大型项目来说，委员会又是必不可少的。我很关注它们，但是为了成功，关注和面对问题是必需的。
**Register：你如何看待 C++ 社区的流程？在沟通和决策方面你希望看到哪些变化？**
**Stroustrup：**C++ 并没有企业管理的”社区流程“；它有一个 ISO 标准流程。我们不能对 ISO 的角色做重大的改变。理想的情况是，我们设立一个小的全职的”秘书处“来做最终决策和方向管理，但这种理想情况是不会出现的。相反，我们有成百上千的人在线来讨论，大约有 160 人在技术问题上进行投票，大约有 70 组织和 11 个国家在结果提议上正式投票。这样是很混乱的，但是在将来某个时候我们会让它好起来。
**Register：最终你认为那些即将推出的 C++ 特性中，对 C++ 用户最有帮助的是哪些？**
**Stroustrup：**
```
大大地简化了一般编程的概念
并行算法 – 没有比使用现代化硬件的并发特性更好的方法了
协程，如果委员会能够确定在 C++20 上推出。
模块改进了组织源代码的方式，并且大幅改善了编译时间。我希望能有这样的模块，但是它还不能确定能否在 C++20 上推出。
一个标准的网络库，但是它还不能确定能否在 C++20 上推出。
```
此外：
```
Contracts（运行时检查的先决条件、后置条件、和断言）可能对许多人都非常重要。
date 和 time-zone 支持库可能对许多人（行业）非常重要。
```
**Register：最后你还有需要向读者说的话吗？**
**Stroustrup：**如果 C++ 标准化委员会能够专注于重大问题，去解决重大问题，那么 C++20 将会是非常优秀的。但是在 C++20 推出之前，我们的 C++17 仍然是非常好的，它将改变很多人关于 C++ 已经落伍的旧印象。®
------
via: https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
作者：[Thomas Claburn][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[qhwdw](https://github.com/qhwdw)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: http://www.theregister.co.uk/Author/3190
[1]: http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
[2]: https://www.vasamuseet.se/en/vasa-history/disaster
[3]: http://open-std.org/JTC1/SC22/WG21/
[4]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
[5]: https://go.theregister.co.uk/tl/1755/shttps://continuouslifecycle.london/