Life After Business Objects: Confessions of an OOP Veteran
summary
Team replaces mutable-heavy C# design with F# and an actor layer (Akka.NET), processing gigabytes per hour with no explicit locks in source. Claims: algebraic data types and many small record types make illegal states unrepresentable, modules control visibility of unsafe operations, option types force stricter modeling, and actor-based messaging avoids thread coordination. Notes metrics: developer half-life ~3 years and lines of code half-life ~13 years, and Amdahl-style limits on speedup when only ~40% is parallelizable.
AI-written summary · about
chapters (21)
- 0:00Intro
- 3:28Modeling a point
- 5:33Data structures in Fsharp
- 6:52OOP vs. FP
- 7:21Half-lives of software related entities
- 10:18Locks do not compose
- 11:13Amdahl's law in action
- 12:17Business objects
- 15:37Joe Armstrong on OOP
- 16:12Business objects
- 17:13Scott Wlaschin "Domain Modeling Made Functional"
- 20:54Domain modeling in Fsharp
- 21:43Algebraic data types in Fsharp
- 24:17Yaron Minsky "Make illegal state unrepresentable"
- 25:48Can't we adopt FP style in C#/Java?
- 28:57Alan Kay on objects
- 30:30Classic OOP vs real world
- 32:16Actor model as OO done right
- 33:44Impact of FP on feature development cycle
- 35:54What main advantage did we gain with FP?
- 36:54Outro
related talks
34mLife After Business Objects - Confessions of an OOP Veteran
44mLife after business objects. Confessions of an OOP veteran
35mLife After Business Objects - Confessions of an OOP Veteran
59mLife After Business Objects
52mF# in the real world
01h 00mF# in the Real World
56mFunctional Programming on .NET - The Best of Both Worlds
01h 08mWhy Every Day as a Developer Would Be Easier with F#