"Embrace No-Paradigm Programming!" and "retpoline"

This month we are dicussing programming paradigms and security issues: The first talk, a preview of an upcoming CppEurope talk, Klaus Iglberger will raise the question what kind of programming language C++ really is. In the second talk Lukas Bergdoll will explain the Spectre security issue in detail and will talk about Google's "retpoline" solution.

----------------------------------
Title: Embrace No-Paradigm Programming!

Presenter: Klaus Iglberger is a freelancing C++ trainer and consultant. He shares his experience in popular advanced C++ courses around the world (mainly in Germany, but also the EU and US). Additionally, he is the initiator and lead designer of the Blaze C++ math library (https://bitbucket.org/blaze-lib/blaze) and one of the organizers of the Munich C++ user group (https://www.meetup.com/MUCplusplus/).

Abstract: What kind of language is C++? Is it a procedural programming language? An object-oriented programming language? A functional programming language? A generic programming language? All of those? None of those?

In this talk I’ll analyse why it is increasingly hard to answer these questions, especially since the advent of “Modern C++”. I’ll demonstrate by example that the good solutions, i.e. the solutions that promote loose coupling, ease of use, ease of maintenance, and performance, are not firmly rooted in either one of the traditional paradigms. The examples will raise doubt whether it is reasonable to try to assign C++ to any one of the paradigms. Instead, they may be an indication that we should embrace no-paradigm programming.

Link to the CppEurope talk:
https://cppeurope.com/sessions/embrace-no-paradigm-programming/

----------------------------------
Title: retpoline

Presenter: Lukas Bergdoll

Abstract: In the past decade, we've continuously been able to cram more transistors into our silicon machine brains, yet clock speeds have largely stagnated, and most programs spend the majority of their execution time waiting for memory, as latency has stagnated as well. So what did CPU manufactures do, because we've never stopped asking for more instructions per clock every year, and somehow magically they kept increasing IPC, year by year, despite plateaued clock speeds. And for the most part we developers never questioned how they did it, blindly taking the performance gains for granted, chip manufactures threw over the fence in their NDA sealed black boxes. Until 3 years ago, when people in the search of performance looked more closely how all this was achieved, realized a massive problem.

----------------------------------
Agenda:
18:30 -- Welcome with Snacks and Drinks
19:00 -- "Embrace No-Paradigm Programming!"
~20:15 -- "retpoline"
~21:30 -- Open Discussions
22:00 -- Official End

----------------------------------
Sponsor: UnternehmerTUM (www.unternehmertum.de)