Reflection 14: /about

If you haven’t been following my research journey, this episode is a great place to join! I recap of who I am, where I come from, what I’m trying to accomplish, and how I hope to accomplish it. The mission of this project is, broadly, to “democratize” programming. My new phrase is: Enable all people to modify they software they use in the course of using it. This mission would cause the following changes, in order of increasing importance: All software will be co-created by decentralized communities, rather than centralized groups or companies. Through the power of crowd-sourcing, the quality of all software will become much higher than existing software. All software will be much more composible, interoperable with other pieces of software. All software will be arbitrarily customizable, allowing for bespoke, tailored experiences. Learning to communicate with computers teaches one how to think more clearly, precisely, mathmatically, and powerfully. If one can manipulate the software one uses, if only one learns how to organize one’s thoughts, many people will self-teach themselvse to do just that. As the fabric of the world is eaten by software, the ability to fully manipulate that software one uses is an essential freedom. This vision is not new nor creative: it’s obvious that people would change things if they could. Yet this problem has proven stubborn over the decades and most have given it up as insoluble. We have all but forgotten the essential characteristic of computers: their malleability. In order to accomplish this vision, I believe there are three large categories of problems that need to be addressed: Rid ourselves of the IO Monad, replacing it with better abstractions for whole systems. Create a better programming experience for the complex abstractions we create to avoid IO. Reimagine version control for a world where software looks very different than it does today, with many more forks, at many more levels than just one-deep off of master My recent work was on ridding ourselves of the IO Monad from user interfaces, which is building on Conal Elliot’s FRP work. My paper and talk at REBLS last month argues that Elm Architecture makes software take longer to understand (which is untenable if we want people to be able to modify the software they use in the course of using it) as compared to the higher-order and cyclic streams of Conal’s original FRP. My future work will be improving the programming experience of “original FRP”, potentially with a Haskell-inspired structured editor. I will also extend Conal’s FRP work to also removing the IO Monad from the “backend”. In the episode I add a lot more color to these points, as well as discuss my personal background, the past and future of Future of Coding meetups, my experience at SPLASH last month, and other whacky ideas! You can see the transcript for this episode at https://futureofcoding.org/episodes/33. Support us on Patreon: https://www.patreon.com/feelingofcomputingSee omnystudio.com/listener for privacy information.