There is perhaps no simpler way to compose programs than with function composition (except maybe with relations). This leads to great clarity of thought and writing, and is not to the exclusion of architecture.
Avoid taking inspiration from mathematics at your own peril.
Not "number of benefits" but "kinds of glue" and "ways [to] glue solutions together".
And I guess putting the crucial quote in bold wasn't enough. I joked about wanting to add a blink tag around it, maybe I should have done that?
"The ways in which one can divide up the original problem depend directly on the ways* in which one can glue solutions together. Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language."
This is not me, this is the direct quote from Why Functional Programming Matters.
Note: "ways* and "new kinds". Plural. New kinds. Not "a single way". Not "a single kind of glue".
He goes on: "We shall argue in the remainder of this paper that functional languages provide two new, very important kinds of glue."
Except it's really only one kind of glue (see the update).
So, deftly switching metaphors, the fact that you have the best hammer of all time doesn't help much if we have two pieces that are best held together with a screw. Or arc welded. Or vacuum welded. Or soldered. Or glued with two-component glue. Or glued with super-glue. Or glued with wood glue (and I just learned that super glue really doesn't work when you need wood glue). Or rivets. Or joined together with glue-less and fastener-less wood joins.
And the fact that all these different ways of joining together things exist and are valid and make for better end results when used appropriately does not detract from the shininess of your hammer.
The article is saying that irrespective of how good or bad function composition is, it is just one kind of connector ("glue"). And we need more than one.
For more info on connectors, see Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status by Mary Shaw.
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid...
Unicon was one of the first projects I am aware of that tried to generate code:
https://www.cs.cmu.edu/~Vit/unicon/reference-manual/Referenc...
It is also the system that made me see the connection between architectural elements (connectors/components) and the elements of a programming language, the language's meta-model.
ArchJava ist the only attempt so far to add a connector abstraction to an existing programming language:
https://www.ics.uci.edu/~andre/informatics223s2009/aldrichch...
But since "connector" is a generalisation of "procedure/function/method call", you can't really just add connectors to an existing language, you have to generalise. Which is what I am doing with Objective-S: http://objective.st
(And no, the ObjS web-site is currently not very good at all. But it is being served by ObjS and can stand up to a HN hug of death, so at least something...)
I did briefly look at Objective-S as well, but I'm not familiar with Scheme from before so will need more time to get a feel for how it works in practice.
You can get a lot of the advantages of this clear split in a regular language like C#, but I agree that a dedicated one probably can get you some synergies that are otherwise lost.
Absolutely! It's just not at all obvious and thus difficult to accomplish or do well. You need to have a very clear model of the solution in your head that you then encode very differently in your language of choice.
And once it's encoded, it's very difficult to recover that clear/simple model that only exists in your head, both for yourself and even more so for future maintainers. Meaning it will probably degrade more or less rapidly over time.
Linguistic support should make this much more straightforward, as you can just write down the model you had in your head. Or at least much more of it.
It occurs to me that operators can be considered connectors!
Your chances of having the right kind of glue increase the more different kinds of glue you have to choose from. (Which is not my point, it is the point John Hughes made, but I certainly agree with it). Of course it isn't just a numbers game, for example you could have lots of different kinds of glue that are all horrible.
But if you have only one kind of glue, the chances of it being the right kind of glue in all circumstances are pretty low, regardless of the quality of any one kind of glue.