Odin Holmes

speaker

Odin was allocated from a pool of hippies in the middle of the forest. He spent most of his career designing electronic circuits and programming micro controllers in assembler. One day after having shot himself in the foot particularly badly a friend introduced him to C++, a seriously powerful and ongoing addiction followed. Odin has authored many proof of concept libraries in the embedded field and is trying to revolutionize this domain. Odin co-authored the kvasir::mpl library, co-founded the embo.io conference and was a heavy contributor to the brigand library. In his day job, he teaches people how to shoot themselves in the foot less and get more from their compiler, both with his in-house team as well as in a training and consulting role.

 

Presentations

boost.tmp: Your DSL for Metaprogramming - Part 1 of 2 (2018)


At last years code::dive I presented new ways to write algorithms in template metaprogramming with the kvasir::mpl library. In this talk, after a brief review of last years material, I would like to show how my latest creation: the boost.tmp library (not yet submitted to boost) offers a relatively feature complete DSL with which one can meet the vast majority of metaprogramming needs with no disambiguators and odd keywords. We can even benefit from the added clarity of a DSL without increasing compilation time.

We will also explore other strategies of SFINAE use, more efficient use of type_traits as well as a teaser of my vision of what fusion style metaprogramming should look like.

 

boost.tmp: Your DSL for Metaprogramming - Part 2 of 2 (2018)


At last years code::dive I presented new ways to write algorithms in template metaprogramming with the kvasir::mpl library. In this talk, after a brief review of last years material, I would like to show how my latest creation: the boost.tmp library (not yet submitted to boost) offers a relatively feature complete DSL with which one can meet the vast majority of metaprogramming needs with no disambiguators and odd keywords. We can even benefit from the added clarity of a DSL without increasing compilation time.

We will also explore other strategies of SFINAE use, more efficient use of type_traits as well as a teaser of my vision of what fusion style metaprogramming should look like.

 

What I Wish They Told Me - Part 1 of 2 (2018)


Coming into software from an electronic engineering background I found that an overarching grand theory is missing in this domain. In EE we have the Maxwell equations as well as a few other fundamentals which everything builds on. Although to this day I do not claim to fully understand these equations, and my impression is that essentially no one understands their implications fully, they serve as a structure with which one can organize all the knowledge which one gains along the way.

In software, I felt more like I was presented with a giant grab bag of piecemeal knowledge and experience, much of which contradicts each other and most of which is outdated in some way. This often led me to question what "good" code is and if my code was "good" while lacking the tools to reason about it in a first principal manor. How should a beginner critique a piece of code which functions as expected? Surely there is still room for improvement.

Although I am no Maxwell or Faraday and cannot produce an overarching theory myself I would like to share with you the observation which I have made over my career which helps me categorize and reason about the quality and applicability of the giant grab bag of information which we call software engineering practices. From reasoning about the performance of code to patterns which increase the probability of correctness as well as questions like "what is architecture really?". I will do my best to efficiently dump my brain onto slides and hope to provide structure in the minds of beginner and intermediate programmers.

 

What I Wish They Told Me - Part 2 of 2 (2018)


Coming into software from an electronic engineering background I found that an overarching grand theory is missing in this domain. In EE we have the Maxwell equations as well as a few other fundamentals which everything builds on. Although to this day I do not claim to fully understand these equations, and my impression is that essentially no one understands their implications fully, they serve as a structure with which one can organize all the knowledge which one gains along the way.

In software, I felt more like I was presented with a giant grab bag of piecemeal knowledge and experience, much of which contradicts each other and most of which is outdated in some way. This often led me to question what "good" code is and if my code was "good" while lacking the tools to reason about it in a first principal manor. How should a beginner critique a piece of code which functions as expected? Surely there is still room for improvement.

Although I am no Maxwell or Faraday and cannot produce an overarching theory myself I would like to share with you the observation which I have made over my career which helps me categorize and reason about the quality and applicability of the giant grab bag of information which we call software engineering practices. From reasoning about the performance of code to patterns which increase the probability of correctness as well as questions like "what is architecture really?". I will do my best to efficiently dump my brain onto slides and hope to provide structure in the minds of beginner and intermediate programmers.