Language decisions are often made by non-technical founders, risk-averse managers, that one contractor who wrote the whole MVP in Ruby, etc. It may be true that languages like Elm, Haskell, and OCaml offer great technical advantages, but that just is not how the decisions are made. keynote 
Language decisions are often made by non-technical founders, risk-averse managers, that one contractor who wrote the whole MVP in Ruby, etc. It may be true that languages like Elm, Haskell, and OCaml offer great technical advantages, but that just is not how the decisions are made. I argue that we must revise our adoption strategy to account for the perspective of the non-technical business person: What is a "Platform Language" and how is it different from a "Productivity Language"? What are the "business characteristics" of a programming language? How do different languages show up differently on a budget? How can us non-business people cooperate more effectively to make Productivity Languages more attractive than Platform Languages? I hope that this talk will save other language authors some time, and inspire renewed cooperation between companies that love Productivity Languages.