Tangible Functional Programming
Paper by Conal Elliott (2007)
1 Like
Brian Hempel’s work is inspired by Conal’s.
Thanks for adding this, a great submission indeed. 
We had a few other links stored in a old issue, so I’ll fold those in.
1 Like
Great! Let me point 3 key arguments here.
Malleability is a derived property of Composition and Abstraction.
And Abstractions need to be meaningful.
( Also, eros in Greek means love. 
)
1 Like
I didn’t quite follow how you pointed out 3 arguments in those 3 sentences Could you elaborate?
In order for users to be able to change their software, they need to compose simple things they can understand into something new. This new thing needs to remain simple for people to understand , thus it needs to be an abstraction of the parts it is made of.
And it would be better if the abstraction had denotational meaning, which means that the abstraction represents something with which the users are familiar with. This way users only need to think in terms of the meaning of the abstractions, not the abstractions themselves.
For the last part, Conal is famous about this method. And it has been an inspiration for me as well.
There is a tutorial on denotational design here
1 Like
This was a tantalizing definition of “denotational”, but it was sadly not borne out for me by the first 5 minutes of the tutorial. Most people are not familiar with Monoids.
1 Like
A monoid is a fancy way of saying that some elements have no invertible counterparts with regards to an operator. For example, Integers is a monoid with regards to multiplication because 4 * 1/4 = 1 and 1/4 is not an integer.
Simplifying things might require one to be an expert in the subject.
It is indeed a problem that needs to be solved. In my opinion, eventually, we will require both experts whose job is to simplify things, and users that will use the simple tools by the experts.
In that sense, one could criticize the Free Software moment. Even though, everyone has the right to change the software, very few people can. And those that can are hired by companies and not the users of the software.
I doubt we can get rid of the experts, thus the malleability of software is not just a technical problem but also a social one. We need social organizations that provide those experts to the users.
I have written something back in 2018 on this : Freedom and Democracy as a Welfare Service
The gist is that Democracy and Freedom necessitate that experts provide help to the people in a direct way.
2 Likes
By coincidence, I had just watched Brian Hempel’s PhD defense yesterday. Maniposynth is really great stuff. The fluid live interface coupled with the opportunity to more easily integrate program synthesis and testing/assertions into the environment seems important. I definitely get the impression that these systems are easier to reason about in a “pure” environment absent of side effects. Figuring out how and if those are necessary will be an interesting challenge. It’s possible Elliot’s FRP helps there but I’m not sure if it’s the full solution.
I’m also interested in the idea of using fully polymorphic values to provide some level of abstract interpretation of expressions rather than just using program synthesis with concrete values.
3 Likes
My belief is that Functional Reactive Programming allows for deterministic concurrency. Thus it cannot be an abstraction model for all types of programming. We need an abstraction model for non-deterministic concurrency, that allows abstractions and composability , thus malleability.
Writing any kind of software requires expertise in the application domain. What I see as the key to malleable software is to ensure that as little as possible additional expertise is required. In particular, as little as possible technical expertise concerning the development environment, but also as little as possible expertise in design methodology, formal logic, mathematics, etc.
Mathematics-heavy approaches such as denotational design (which I have no direct experience with) are great for domains that are already strongly formalized, meaning that domain experts already have the required mathematical background. The challenge that is, as far as I know, still open is to design and develop support tools for denotational design that reduces the required technical expertise.
There are at least three situations in which I’d consider denotational design inappropriate for malleable systems:
- Poorly understood application domains, where computation is used for exploration.
- Application domains that are simpler than the methodological overhead of denotational design.
- Tasks that are essentially gluing together existing weakly specified APIs.
2 Likes
I’m not sure how true I am to denotational design but I mostly think about it as modeling your programs in terms of the domain and not the “how” of the computer. So you’re representing the application domain rather than the operational semantics of a specific program.
I would imagine it’s still helpful in figuring out and exploring an application domain. I agree that the biggest barrier is interoperating with existing programs under a very specific computational context.
2 Likes
Denotational design is a methodology that experts use to reduce the complexity for the users.
So it is the methodology with which you can achieve what you describe, Konrad.
1 Like