CppCon 2018: Juan Pedro Bolivar Puente “The Most Valuable Values”

—
—
The modern C++ community puts a strong emphasis on value semantics. We know how to build types and algorithms thinking in terms of values, their properties and relationships. However, when it gets to the big picture—the architecture—we end up growing ad-hoc webs of mutable objects that perform poorly and are hard to understand, debug and maintain.

In this talk, we'll learn what value semantics are about in a fundamental way. We'll then use values where they matter most: the architectural foundations of our system! As an example, we'll present the Unidirectional Data Flow Architecture, that is changing how people build interactive software. We'll show some patterns, examples and tools that make it easy to implement, and efficient to execute.

We will also present Lager, a library that implements such architecture and augments value-based programs with time-travel capabilities!
Links:
—
Juan Pedro Bolivar Puente, Independent (Sinusoidal Engineering)
Consultant

Juanpe is a Berlin based freelance software engineer, with a focus on interactive software, modern C++, functional programming and open source strategy. Before he worked for Ableton and he has been involved in various music technology projects. He has also developed for the GNU project and cofounded a Hacklab in Granada.
—

*-----*
*-----*

[loganpowell]

This guy needs to be on the Standards Committee

[jjurksztowicz]

Great point about the assumptions about the high and low levels of system design. I think that object semantics work best when sandwiched between layers of value semantics.

[MrAbrazildo]

15:00, friends didn't need to has pointers to persons, just persons. 15:14, even having pointers, unique_ptrs would better fit on friends, instead of people. The way it is, people data struct has an "extra issue", at least for human perception. This whole example was a mess, that proved no point. std::vector takes care of its objects lifetime. There was no need whatsoever for explicit pointers usage. Neither here (20:35) you proved a point against objects.
29:05, this model is bad only if, to get a model to work, it needs to handle all of these information. Which doesn't seems to be the case. If each "node" needs to know only the informations that "touches" it, this whole thing is humanely maintainable. Btw, this probably would not work with atomic values/f() programming, because someone would change its value by mistake, while objects don't allow it.
35:40, I think it's a good idea to have a struct, since web data structs tend to grow on time, which can avoid to have tons of refactoring work to do. And it can also easily switch to class, as soon as situation becomes dangerous, when bugs arise due to changing its variable in wrong places.
47:41, literal numbers are way more dangerous then they look. I always make a global constant for each of them.