The future of programming

Reference: The future of programming

Paul Chiusano:

In the functional programming world, there is insane amounts of code reuse happening, but along with this comes a fair bit of plumbing.

The plumbing Chiusano is referring to is incidental complexity imposed by current static type systems without a good set of "universal" types. Dynamically typed languages often do not have the same plumbing problem because of the extra information available at runtime to do dynamic dispatching and the use of overloading. This incidental complexity is a huge hurdle to languages like Haskell, where half of the code is about converting from one type to another.

This could be the fault of the codebase/libraries I am working with. In my practical Haskell experience, I have failed to find the zen of type/domain fit that static-typing enthusiasts talk about. Chiusano, however, hints that this problem is universal.

It makes it clear that types are effective not just at preventing many software errors, but also in guiding development.

I would love to see the adoption of standard type classes recognized by the Haskell compiler that could automatically handle the most common coercions safely. For instance, the compiler could "upgrade" function application to Functor application when the types match. It is beyond me whether this can be done "safely". I suspect that it cannot.

The second is to have more normalized types and type systems so that there is no incidental structure for code to broker between in the first place. To support this we'll see things like row types, unordered tuples, type sets, and so on, and any related type system machinery needed to make all this feasible and convenient.

If modules were programmed to a small, standard set of types (and type classes), they would be more universally applicable. The compiler could "overload" functions automatically. The trick is to keep it safe. At the very least, the "universal" types would help programmers do it manually. We may already be seeing such a convergence.

Not coincidentally, the built in Clojure data structures are usually all I need. Others appear to think the same. The Clojure ecosystem thrives from the consensus on a small, universal set. There is a lot of reuse and little boilerplate.

See Ring as an example of a universal datatype facilitating a flourishing community. It allows the problem domain (web programming) to be broken up into subproblems with little-to-no coordination between the groups. Clojure has a number of web frameworks and libraries that are all inter-compatible. I think this is unique among languages.

The editor will search for a program to make the types align, show me the program for confirmation if I request it, and then not show this subexpression in the main editor view . . .

Please give me this editor. It is technically feasible. Hoogle can already do a pretty decent search based on the types of functions. All you need is a planner to find a path from one type to another.

You could even help the search by defining a type class Convertible like this:

class Convertible a b where
    convert :: a -> b

All of the instances of Convertible would form graphs which could be searched for all paths between any two types. The editor could show a list of those paths and let you choose one.