Hacker News Reader

Comment by phkahler | Hacker News Reader

Yeah, I never saw an answer to the headline question. Lots of drivel about glue. My opinion on glue is that too much glue means you've got a suboptimal data representation. But I saw no insights even that basic. I didn't get the point.

View on HN

I think the author is saying that in order to build larger structures out of modular structures you connectors (you can think of glue as one kind). As an example think of the many different connectors that Lego Technic provides. Unix pipes can be considered connectors as well. So can tcp/ip connections (for the largest distributed system in the world, the Internet).

What is it about functional programming that rules out unix pipes, tcp/ip connections, etc? There's no basis for those to be excluded or any more difficult in that paradigm IMO.

I don't think the author is necessarily excluding FP as much as saying intrinsically it doesn't provide anything more than functional composition for what the author calls "architecture oriented programming". That is, while "structured programming" mainly focused on on modularity, how these components are connected (and communicate) is equally important. At least that is what I got from the article!

Well that's kind of what I think I took from the article as well, but I'm not sure I see the sense in that. It sounds to me a bit like saying "functional programming is not that great because it doesn't make thinking and planning obsolete"... It sounds to me like a category error, or unreasonable expectations. :shrug:

The article isn't saying anything about the quality or lack of quality of functional programming (except for disputing the unfounded 10x better claim with actual data).

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...

Are there some languages that implement connectors like in the paper?

There are the Architecture Description Languages, but they only describe, so you have to do the additional work of describing the architecture, and then program it conventionally. Not very appealing and they never really took off.

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...)

Thanks, UniCon certainly looks interesting.

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.

> You can get a lot of the advantages of this clear split in a regular language like C#

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.

Recently I became aware of “FAC: A Functional APL Language” a 1986 paper by Hai-Chen Tu and Alan Perlis[1]. Unlike traditional APLs it allows you to define your own “operators” (second order functions), such as “x (F SWAP) y: y F x”, where x and y can be congruent arrays. It even allows infinite arrays, which can be evaluated lazily and provides a powerful operator on them (let’s call it “$”) such that “1 (+ $) 1” is the Fibonacci sequence! Since FAC functions are pure, in principle you can evaluate things in parallel.

It occurs to me that operators can be considered connectors!

[1] https://ieeexplore.ieee.org/document/1695470

It's always going to be compatible data that really enables different transforms or systems to communicate. Sending and receiving it is a directly solvable problem.

The point is that if you have to write a lot of glue code, chances are you have the wrong kind of glue.

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.

Reply on news.ycombinator.com