5 ms·

I don't really understand the author's point. It seems like the author is making a judgment based on the "number of benefits" provided, without considering the

by epgui 4y ago

I don't really understand the author's point. It seems like the author is making a judgment based on the "number of benefits" provided, without considering the magnitude of the benefits. 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.

phkahler 4y ago
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.
- bakul 4y ago
  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).
  - epgui 4y ago
    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.
    - bakul 4y ago
      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!
      - epgui 4y ago
        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:
        mpweiher 4y ago
        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=12137 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid...
        magicalhippo 4y ago
        Are there some languages that implement connectors like in the paper?
        bakul 4y ago
        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 https://ieeexplore.ieee.org/document/1695470
        mpweiher 4y ago
  - CyberDildonics 4y ago
    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.
- mpweiher 4y ago
  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.
mpweiher 4y ago
> the author is making a judgment based on the "number of benefits" provided 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.

by epgui 4y ago

phkahler 4y ago

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.

bakul 4y ago
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).
- epgui 4y ago
  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.
  - bakul 4y ago
    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!
    - epgui 4y ago
      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:
      - mpweiher 4y ago
        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=12137 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid...
        magicalhippo 4y ago
        Are there some languages that implement connectors like in the paper?
        bakul 4y ago
        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 https://ieeexplore.ieee.org/document/1695470
        mpweiher 4y ago
- CyberDildonics 4y ago
  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.
mpweiher 4y ago
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.

mpweiher 4y ago

> the author is making a judgment based on the "number of benefits" provided 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.