From Irrational Configuration System to Functional Data Store

We started with 42 Oracle tables, 5200+ configuration values, no default values or templates, logical inconsistencies and circular dependencies, on-boarding times running as long as 10 months, a 1.5 million lines of legacy code, and advice that anyone who tries to redesign our configuration system will be gone within six months. Our solution is a custom-built functional data store with inheritance, flexible projections, backward compatibility with the legacy code, and a Lego™-like framework for building tools. Plus, I still work there. Come learn how we did it.

Talk objectives:

- I'd like to share how we replaced a complex, "organically-designed" configuration system that we couldn't reason about with a immutable, accretive, functional, time-variant data store based on event sources and command query responsibility segration. We're particularly happy with our choices to project views into Oracle and to treat Oracle as an event source (which gives us backward compatibility with our legacy code), and to allow queries that compile data from multiple documents (which gives us reusable configuration templates).

Target audience:

- Programmers and managers interested in applying functional programming concepts to data stores.

Tutorial: Concatenative Programming

Will Byrd and Rob Martin guide the tutorial participants through concatentive programming - in some ways, the most functional of functional programming languages. Made up of only functions and compositions, concatenative languages are "point free" - no variables or named state needed. And we already use them every day. Forth, Postscript, even CPython and the JVM are based on concatenative principles of function composition and a stack. Imperative, highly efficient, easily optimized - concatenative languages are almost trivial. This tutorial works with a simplified language called Puppy, and is hands-on: participants will be both programmer and computer.