DPP’s Rantifesto from November, 2024
I've come to believe that the future of computing devices is tablet devices. The programming tools for tablet devices sucks. Sure, you can write Html5 apps for tablet devices, but Html5 apps generally suck and the tools for writing Html5 apps is tragically bad. Native apps, especially iOS apps and less so Android apps, are just much, much nicer. They feel better. They work better. They are better. I think HTML has lost the race for building great apps. But the tools for writing iOS apps is super weak and the same goes for Android apps.
Sure, the tools will let folks like us write apps. The tools facilitate a whole class of development shops that charge high rates for developing iOS apps. But, there's no PowerBuilder, HyperCard, VisiCalc/1-2-3/Excel class of development tools for iOS. The tools are by developers for developers. I intend to change that.
Further, most development tools and paradigms approach the app building issues the same way they've been approached for the last 40+ years. There's precious little in today's development paradigms that make distributed computing manageable.
Well... I'm on a mission to fix all this.
I've been working on a language and a whole infrastructure to support this vision.
The language has the following attributes:
- Syntactically, it's a lot like Python and Haskell. Clean and readable.
- Semantically, it's a lot like Excel/Lotus Improv. The programmer declares the relationships among predicate and dependent computations (there are side-effect-free functions a la Haskell as well).
- The language is statically typed and has a (soon to be) solid type system. But there are two modes and the "developer mode" hides the type system from the developer where the "library author mode" exposes the type system. So, in developer mode, the developer sees what looks a whole lot like a dynamically typed language, except it’s type checked.
- Under the covers, there's a lot of Monoids and Iteratees that actually work to support the above concepts.
- I'm borrowing some of the source/sink external data concepts from Rust. This means that the relationships need not be Monadic (or perhaps they are, but without the Haskell Monad concepts), but effects are managed.
- I'm also borrowing the concept of References from Clojure. State is managed as an intersection of Refs and sources/sinks. (There’s no current syntax for these concepts.)
- Data structures are by default JSON/BSON serializable and you have to be in library author mode to design structs that cannot be serialized.
- The language is not object-oriented, but has Haskell-style open classes. I'm struggling with the whole namespace issue (OO means that the namespace is per class where in functional languages, the function/method namespace is a lot nastier.)
- Access to the program's lambda calculus representation both at compile-time (hygienic macros) and run-time (powerful information about types much like Scala's Manifests, but access to code structures as well as type information).
- Computation is lazy (it's built on Haskell, so lazy is easy)
- The language is fully type inferenced so there’s no need for type declarations.
- The language is interpreted -> compiled so writing debugging cycles are very fast... no need to wait for a recompilation (although incremental type checking does happen). But server-side execution is native code and iOS side execution is fast as well (but no native code due to iOS restrictions).
- Built-in pattern matching and something akin to Scala’s PartialFunctions so that patterns can be passed as parameters and composed.
- The development environment will be GUI-based and I’m working to make the language self-hosting so that the Smalltalk-style GUI bleed through and excellent debugging stuff should happen.
Because built-in serializability, natural transactional boundaries (Refs), and complete dependency analysis, it's easy to distribute computations across threads and whole systems without developer intervention (although it's likely that we'll need some library-level hints.) This leads to a nice cloud/semi-connected/real-time updates across a mesh of systems set of semantics. Basically, the stuff that's hard/impossible in cloud-land today becomes much easier because a lot more about the system is known at compile and run-time.
- The project will be a mix of open source (I plan to open source that language and at least parts of the cloud platform) and proprietary. Revenue generating parts of the system include:
- Charge for cloud portions of the system
- Have a app/component/data feed store that allows third parties to sell full-blown application, components of applications, and data feeds from external services that can tick into the system
But the core of the vision is to fundamentally change the programming paradigm and make it more accessible to real people. To change programming from machine focused to people focused. VisiCalc/1-2-3/Excel did this and HyperCard make programming less hard. It’s time to take the amazing swaths of computing power sitting under our swipe screens and open it up to an order of magnitude more people. All with a combination of open source so that the core language and tools are available to all and a revenue model so there's a way to fuel the development.