5 ms·

Why Architecture Oriented Programming Matters (2019)

62 points by mpweiher 4y ago

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
    - 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.
sshine 4y ago
I'm not sure what this article even is. Does it mainly bash John Hughes for bragging about how good FP is? Or does it mainly advertise for the author's language, Objective Smalltalk? Objective Smalltalk -- http://objective.st/ http://objective.st/ -- is a mostly unimpressive, one-man project that claims to be the first general purpose programming language, and that all other programming languages are DSLs in comparison. The few simplistic "Hello World!" front-page code examples don't solve any problems related to software architecture. I'm tempted to believe he just likes to make small languages that resemble all the other languages, like the rest of us. The article lacks perspective by measure of the lack of any references to Infrastructure as Code, first-class module systems, integration between language ecosystems and their package management and languages. I would have had more to say about how "software architecture" goes together with the lack of expressivity in most general purpose programming languages, how modern DevOps is heavy on DSLs that are executable architecture designs, and how there's both a lot of progress to be made, and a lot of noteworthy, active attempts. The author cites John Hughes (of Haskell, QuickCheck fame) for saying that structured programming lets you design programs in modular ways, and modules allow for speedy development and re-use, and that function composition is the best kind of glue for making modules. The author then links to an article [1] (Mary Shaw, 1994) which invents a word, Connectors, claims that this is great, and so Architecture Oriented Programming is great. It feels like the middle 80% part of the article that defines and connects (sic) these concepts is completely missing. Maybe I'm supposed to read the Mary Shaw article. He could have saved everyone a lot of time by just saying "Hey, I found this pretty great article. Also, I'm making a programming language that is better than yours." [1]: https://resources.sei.cmu.edu/asset_files/TechnicalReport/1994_005_001_16277.pdf https://resources.sei.cmu.edu/asset_files/TechnicalReport/19... > it turns out that [...] lazy evaluation is essentially unused, [...] So that means the number of kinds of glue that FP provides is...one. Demagoguery. Since we can apparently just make up numbers: FP actually provides -1 kinds of glue, making it a product of Satan and so entirely a cause of the coming apocalypse.
- mpweiher 4y ago
  2 - 1 = 1 Hughes claims FP provides two (2) kinds of glue: functional composition and lazy evaluation. It turns out lazy evaluation is actually not really a useful kind of glue, so subtract that one from the two initially presented: 2 - 1 = 1 > Does it mainly bash John Hughes for bragging about how good FP is? > Or does it mainly advertise for the author's language, Objective Smalltalk? Neither. It notes that John Hughes had a fantastic insight, but one that seems to not get a lot of attention: we need lots of different kinds of glue. And yes, the article somewhat assumes that you either know what a connector is, or that you would read the linked Mary Shaw article to figure it out, as it is foundational for the field of software architecture. If you don't know what a connector is and don't care to find out, the article probably won't make a lot of sense to you. And it's good for me to learn that apparently a lot of people don't know what a connector is, so I'll have to keep that in mind when communicating about this stuff. Thanks! You could start with the main Wikipedia article on Software Arcitecture: https://en.wikipedia.org/wiki/Software_architecture https://en.wikipedia.org/wiki/Software_architecture Or one of the others: https://en.wikipedia.org/wiki/Architecture_description_language https://en.wikipedia.org/wiki/Architecture_description_langu... https://en.wikipedia.org/wiki/Software_architecture_description https://en.wikipedia.org/wiki/Software_architecture_descript... They cover the basics and have lots of references. Or take a look at one of the books: https://www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572 https://www.amazon.com/Software-Architecture-Perspectives-Em... https://www.amazon.com/Software-Architecture-Foundations-Theory-Practice/dp/0470167742/ref=sr_1_1 https://www.amazon.com/Software-Architecture-Foundations-The... Here's a taxonomy of connectors, that should give you a quick overview: https://isr.uci.edu/events/wesas2000/position-papers/mehta.pdf https://isr.uci.edu/events/wesas2000/position-papers/mehta.p... And of course there is the classic from 1994, published in IEEE Software: "Architectural Mismatch: Why Reuse Is So Hard" https://www.ics.uci.edu/~taylor/ICS221/papers/ArchMismatch.pdf https://www.ics.uci.edu/~taylor/ICS221/papers/ArchMismatch.p... Turns out that one of the reasons Reuse is So Hard™ is that the connectors don't match. With the followup 14 years later: "Architectural Mismatch: Why Reuse Is Still So Hard" https://repository.upenn.edu/cgi/viewcontent.cgi?article=1074&context=library_papers https://repository.upenn.edu/cgi/viewcontent.cgi?article=107... Turns out that the connectors still don't match. Cheers.
peterhil 4y ago
The bold point really resonates with me. Lately I’ve been writing a CLI application in Python to analyse and generally handle possibly megabytes of DNA data. At first I wrote the code quickly and in haste of inspiration using some Numpy constructs, some functional maps (with list) and an occasional list comprehension. It has took WAY too long to convert to code to use iterators, because the syntax and semantics are so different. In Lisp I could usually just switch the kind of map function to be lazy, iterative, or whatever I would like without changing and carefully thinking about the rest of the code. I think this is the kind of glue the article points to.
metapsj 4y ago
You have to follow Marcel Weiher's work on combinators aka connectors. The following article references his work on in-process rest, polymorphic identifiers, and storage combinators. What Alan Kay Got Wrong About Objects https://blog.metaobject.com/2019/11/what-alan-kay-got-wrong-about-objects.html https://blog.metaobject.com/2019/11/what-alan-kay-got-wrong-... Here's an ACM SIGPLAN talk he gave on storage combinators... Storage Combinators @ SPLASH'19 https://www.youtube.com/watch?v=6FFlmkFS1YY https://www.youtube.com/watch?v=6FFlmkFS1YY The ACM SIGPLAN talk is a very good starting place to get an understanding what he is talking about.
- magicalhippo 4y ago
  > The ACM SIGPLAN talk is a very good starting place to get an understanding what he is talking about. What's the big difference from just using composition like we've done for ages? I mean, his examples in that talk was very reminiscent of stuff I've been doing for many years, and I don't consider myself to be special in any way. Writing decent interfaces, write useful implementations, then compose them together. Not trying to be dismissive, I just feel like I'm clearly missing something as it's a bit underwhelming for a 2019 talk to be all about "composition is great, use it".
  - metapsj 4y ago
    imho the key concept is in-process rest as in representational state transfer as an interface. instead of an imperative interface it's more of a protocol based interface. think http middleware built around a standard interface like ruby's rack, asp.net's owin, or python's wsgi. once you have that style of abstraction it becomes pluggable and you can chain them together. here's a past discussion on in-process rest. https://news.ycombinator.com/item?id=21560626 https://news.ycombinator.com/item?id=21560626
    - magicalhippo 4y ago
      Thanks, that's a bit more specific. Think I'd have to play with it to see how it really differed from my normal composition of interfaces and implementations.
revskill 4y ago
The success of ReactJS is bold claim of FP. Architecture matters.
- edgyquant 4y ago
  React was developed as class based and functional react isn’t “functional programming” as it’s loaded with side effects by its nature.
- mpweiher 4y ago
  UIs are not pure functions of the model https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
galaxyLogic 4y ago
" each Smalltalk object is a recursion on the entire possibilities of the computer " This is true to a degree. But a Smalltalk or any OOP object makes much too many assumptions about the inputs it gets via "messages". Most fatally they make the assumption the inputs are similar objects as the recipient, programmed in same or similar programming language. Note: In Smalltalk everything is an Object. A Computer instead communicates with other physical objects by means of a very simple binary protocol of ones and zeroes. The computer then interprets the bits it gets according to some generally agreed upon convention. A Smalltalk Object does not interpret the messages it gets, it assume they are already interpreted for it. The protocol of Smalltalk objects communicating with each other has not been implemented between computers in general. That is perhaps a failure of standardization, but it nevertheless is the reality. There are two ways to fix it: a) Make every Smalltalk object more like a computer in that it communicates with other objects only via a text-based protocol. not by passing along arguments with predefined semantics like Objects or Functions or Methods. b) Make every Computer assume the same of its inputs as a Smalltalk object makes of its. I think b) is impractical but maybe there could be a Smalltalk whose Objects truly act like small Computers.
- tripleo1 4y ago
  Is this why Smalltalk never has a multithreaded vm?
  - galaxyLogic 4y ago
    Smalltalk implements its own threads which are instance of class Process. They are not OS-threads as far as I know.
  - jdougan 4y ago
    Smalltalk/MT has platform threads
    - galaxyLogic 4y ago
      Good point forgot about that one. Now that you brought it up I realize that "MT" must refer to "MultiThreading". Do you know if Smalltalk/MT is still being maintained?
charlieflowers 4y ago
It's not that the number of kinds of glue is large. It's that the one kind of glue (function composition) is particularly powerful.
- mpweiher 4y ago
  It is. As well as procedural composition. And in addition, for a long time the problems we were solving mapped well onto the kinds of decompositions we can do easily/naturally with functional/procedural (de-)composition. In fact, if I had to choose one and only kind of connector, that's the one I would choose. Dataflow expressed functionally or procedurally is pretty awful, but it has nothing on the horrors of fibonacci expressed using dataflow. Yes you can do it, but you really don't want to. AFAICT, it is exactly because the connector we have is so good that we haven't really noticed how limiting it is to have just the one. A kind of gilded cage, or as I call it: The gentle tyranny of call/return[1]. And I really do mean the "gentle" part. And for some weird reasons, whenever people proposed different connectors, they almost invariably proposed them as a single connector to replace all others. Which never turns out well. [1] https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p...
eitland 4y ago
Interestingly, if you call you glue "reflection" and "annotations" or "attributes" and not "combinators" and use them in a modern language with good editor support, it becomes a reason to deride a language. Java for example has some very interesting ways to meta program it, for example you can relatively easily dynamically select a number of classes based on different features and say for example: "apply all these to the input and count each output as a vote on an input." But except for when listening to or talking to long time users I never hear about it. Two reasons off the top of my head (but I guess there are many more): - many educators teach Java in an extremely uninspiring way. - the long and sad history of old enterprise Java (and later, Spring, although Spring was a force for good for a while) Edited to mention "attributes" as well as good editor support.
- celurian92 4y ago
  Really intrigued by your comment. Can you please elaborate on the part of meta programming in java. I am trying to learn it in java. What will you suggest to someone who is working in java for a while to dive deep into it?
  - kaba0 4y ago
    I’m not the parent poster, but what they likely meant are annotation processors. They are basically a compile time mechanism that can create new classes based on the used annotations in the program (important, they can’t modify existing classes! This is so that reasoning about the code is easier). This is mostly used by libraries and is seldom used for actual applications (I mean, annotation processors themselves, ones implemented by libs are definitely common), for example MapStruct is a really cool library that generates mapping code between two classes, one can specify which field/property maps to which and thus making a common, error-prone operation very readable and easy to maintain. With that said I disagree with the original statement that one should absolutely know/use these tools, similarly to macros in other languages these are very advanced/last resort mechanisms that are very great in that rare chance they are needed, but overuse of them can make code very hard to understand.
    - 4y ago
lincpa 4y ago
[dead]

62 points by mpweiher 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
  - 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.

sshine 4y ago

I'm not sure what this article even is. Does it mainly bash John Hughes for bragging about how good FP is? Or does it mainly advertise for the author's language, Objective Smalltalk? Objective Smalltalk -- http://objective.st/ http://objective.st/ -- is a mostly unimpressive, one-man project that claims to be the first general purpose programming language, and that all other programming languages are DSLs in comparison. The few simplistic "Hello World!" front-page code examples don't solve any problems related to software architecture. I'm tempted to believe he just likes to make small languages that resemble all the other languages, like the rest of us. The article lacks perspective by measure of the lack of any references to Infrastructure as Code, first-class module systems, integration between language ecosystems and their package management and languages. I would have had more to say about how "software architecture" goes together with the lack of expressivity in most general purpose programming languages, how modern DevOps is heavy on DSLs that are executable architecture designs, and how there's both a lot of progress to be made, and a lot of noteworthy, active attempts. The author cites John Hughes (of Haskell, QuickCheck fame) for saying that structured programming lets you design programs in modular ways, and modules allow for speedy development and re-use, and that function composition is the best kind of glue for making modules. The author then links to an article [1] (Mary Shaw, 1994) which invents a word, Connectors, claims that this is great, and so Architecture Oriented Programming is great. It feels like the middle 80% part of the article that defines and connects (sic) these concepts is completely missing. Maybe I'm supposed to read the Mary Shaw article. He could have saved everyone a lot of time by just saying "Hey, I found this pretty great article. Also, I'm making a programming language that is better than yours." [1]: https://resources.sei.cmu.edu/asset_files/TechnicalReport/1994_005_001_16277.pdf https://resources.sei.cmu.edu/asset_files/TechnicalReport/19... > it turns out that [...] lazy evaluation is essentially unused, [...] So that means the number of kinds of glue that FP provides is...one. Demagoguery. Since we can apparently just make up numbers: FP actually provides -1 kinds of glue, making it a product of Satan and so entirely a cause of the coming apocalypse.

mpweiher 4y ago
2 - 1 = 1 Hughes claims FP provides two (2) kinds of glue: functional composition and lazy evaluation. It turns out lazy evaluation is actually not really a useful kind of glue, so subtract that one from the two initially presented: 2 - 1 = 1 > Does it mainly bash John Hughes for bragging about how good FP is? > Or does it mainly advertise for the author's language, Objective Smalltalk? Neither. It notes that John Hughes had a fantastic insight, but one that seems to not get a lot of attention: we need lots of different kinds of glue. And yes, the article somewhat assumes that you either know what a connector is, or that you would read the linked Mary Shaw article to figure it out, as it is foundational for the field of software architecture. If you don't know what a connector is and don't care to find out, the article probably won't make a lot of sense to you. And it's good for me to learn that apparently a lot of people don't know what a connector is, so I'll have to keep that in mind when communicating about this stuff. Thanks! You could start with the main Wikipedia article on Software Arcitecture: https://en.wikipedia.org/wiki/Software_architecture https://en.wikipedia.org/wiki/Software_architecture Or one of the others: https://en.wikipedia.org/wiki/Architecture_description_language https://en.wikipedia.org/wiki/Architecture_description_langu... https://en.wikipedia.org/wiki/Software_architecture_description https://en.wikipedia.org/wiki/Software_architecture_descript... They cover the basics and have lots of references. Or take a look at one of the books: https://www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572 https://www.amazon.com/Software-Architecture-Perspectives-Em... https://www.amazon.com/Software-Architecture-Foundations-Theory-Practice/dp/0470167742/ref=sr_1_1 https://www.amazon.com/Software-Architecture-Foundations-The... Here's a taxonomy of connectors, that should give you a quick overview: https://isr.uci.edu/events/wesas2000/position-papers/mehta.pdf https://isr.uci.edu/events/wesas2000/position-papers/mehta.p... And of course there is the classic from 1994, published in IEEE Software: "Architectural Mismatch: Why Reuse Is So Hard" https://www.ics.uci.edu/~taylor/ICS221/papers/ArchMismatch.pdf https://www.ics.uci.edu/~taylor/ICS221/papers/ArchMismatch.p... Turns out that one of the reasons Reuse is So Hard™ is that the connectors don't match. With the followup 14 years later: "Architectural Mismatch: Why Reuse Is Still So Hard" https://repository.upenn.edu/cgi/viewcontent.cgi?article=1074&context=library_papers https://repository.upenn.edu/cgi/viewcontent.cgi?article=107... Turns out that the connectors still don't match. Cheers.

peterhil 4y ago

The bold point really resonates with me. Lately I’ve been writing a CLI application in Python to analyse and generally handle possibly megabytes of DNA data. At first I wrote the code quickly and in haste of inspiration using some Numpy constructs, some functional maps (with list) and an occasional list comprehension. It has took WAY too long to convert to code to use iterators, because the syntax and semantics are so different. In Lisp I could usually just switch the kind of map function to be lazy, iterative, or whatever I would like without changing and carefully thinking about the rest of the code. I think this is the kind of glue the article points to.

metapsj 4y ago

You have to follow Marcel Weiher's work on combinators aka connectors. The following article references his work on in-process rest, polymorphic identifiers, and storage combinators. What Alan Kay Got Wrong About Objects https://blog.metaobject.com/2019/11/what-alan-kay-got-wrong-about-objects.html https://blog.metaobject.com/2019/11/what-alan-kay-got-wrong-... Here's an ACM SIGPLAN talk he gave on storage combinators... Storage Combinators @ SPLASH'19 https://www.youtube.com/watch?v=6FFlmkFS1YY https://www.youtube.com/watch?v=6FFlmkFS1YY The ACM SIGPLAN talk is a very good starting place to get an understanding what he is talking about.

magicalhippo 4y ago
> The ACM SIGPLAN talk is a very good starting place to get an understanding what he is talking about. What's the big difference from just using composition like we've done for ages? I mean, his examples in that talk was very reminiscent of stuff I've been doing for many years, and I don't consider myself to be special in any way. Writing decent interfaces, write useful implementations, then compose them together. Not trying to be dismissive, I just feel like I'm clearly missing something as it's a bit underwhelming for a 2019 talk to be all about "composition is great, use it".
- metapsj 4y ago
  imho the key concept is in-process rest as in representational state transfer as an interface. instead of an imperative interface it's more of a protocol based interface. think http middleware built around a standard interface like ruby's rack, asp.net's owin, or python's wsgi. once you have that style of abstraction it becomes pluggable and you can chain them together. here's a past discussion on in-process rest. https://news.ycombinator.com/item?id=21560626 https://news.ycombinator.com/item?id=21560626
  - magicalhippo 4y ago
    Thanks, that's a bit more specific. Think I'd have to play with it to see how it really differed from my normal composition of interfaces and implementations.

revskill 4y ago

The success of ReactJS is bold claim of FP. Architecture matters.

edgyquant 4y ago
React was developed as class based and functional react isn’t “functional programming” as it’s loaded with side effects by its nature.
mpweiher 4y ago
UIs are not pure functions of the model https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

galaxyLogic 4y ago

" each Smalltalk object is a recursion on the entire possibilities of the computer " This is true to a degree. But a Smalltalk or any OOP object makes much too many assumptions about the inputs it gets via "messages". Most fatally they make the assumption the inputs are similar objects as the recipient, programmed in same or similar programming language. Note: In Smalltalk everything is an Object. A Computer instead communicates with other physical objects by means of a very simple binary protocol of ones and zeroes. The computer then interprets the bits it gets according to some generally agreed upon convention. A Smalltalk Object does not interpret the messages it gets, it assume they are already interpreted for it. The protocol of Smalltalk objects communicating with each other has not been implemented between computers in general. That is perhaps a failure of standardization, but it nevertheless is the reality. There are two ways to fix it: a) Make every Smalltalk object more like a computer in that it communicates with other objects only via a text-based protocol. not by passing along arguments with predefined semantics like Objects or Functions or Methods. b) Make every Computer assume the same of its inputs as a Smalltalk object makes of its. I think b) is impractical but maybe there could be a Smalltalk whose Objects truly act like small Computers.

tripleo1 4y ago
Is this why Smalltalk never has a multithreaded vm?
- galaxyLogic 4y ago
  Smalltalk implements its own threads which are instance of class Process. They are not OS-threads as far as I know.
- jdougan 4y ago
  Smalltalk/MT has platform threads
  - galaxyLogic 4y ago
    Good point forgot about that one. Now that you brought it up I realize that "MT" must refer to "MultiThreading". Do you know if Smalltalk/MT is still being maintained?

charlieflowers 4y ago

It's not that the number of kinds of glue is large. It's that the one kind of glue (function composition) is particularly powerful.

mpweiher 4y ago
It is. As well as procedural composition. And in addition, for a long time the problems we were solving mapped well onto the kinds of decompositions we can do easily/naturally with functional/procedural (de-)composition. In fact, if I had to choose one and only kind of connector, that's the one I would choose. Dataflow expressed functionally or procedurally is pretty awful, but it has nothing on the horrors of fibonacci expressed using dataflow. Yes you can do it, but you really don't want to. AFAICT, it is exactly because the connector we have is so good that we haven't really noticed how limiting it is to have just the one. A kind of gilded cage, or as I call it: The gentle tyranny of call/return[1]. And I really do mean the "gentle" part. And for some weird reasons, whenever people proposed different connectors, they almost invariably proposed them as a single connector to replace all others. Which never turns out well. [1] https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p...

eitland 4y ago

Interestingly, if you call you glue "reflection" and "annotations" or "attributes" and not "combinators" and use them in a modern language with good editor support, it becomes a reason to deride a language. Java for example has some very interesting ways to meta program it, for example you can relatively easily dynamically select a number of classes based on different features and say for example: "apply all these to the input and count each output as a vote on an input." But except for when listening to or talking to long time users I never hear about it. Two reasons off the top of my head (but I guess there are many more): - many educators teach Java in an extremely uninspiring way. - the long and sad history of old enterprise Java (and later, Spring, although Spring was a force for good for a while) Edited to mention "attributes" as well as good editor support.

celurian92 4y ago
Really intrigued by your comment. Can you please elaborate on the part of meta programming in java. I am trying to learn it in java. What will you suggest to someone who is working in java for a while to dive deep into it?
- kaba0 4y ago
  I’m not the parent poster, but what they likely meant are annotation processors. They are basically a compile time mechanism that can create new classes based on the used annotations in the program (important, they can’t modify existing classes! This is so that reasoning about the code is easier). This is mostly used by libraries and is seldom used for actual applications (I mean, annotation processors themselves, ones implemented by libs are definitely common), for example MapStruct is a really cool library that generates mapping code between two classes, one can specify which field/property maps to which and thus making a common, error-prone operation very readable and easy to maintain. With that said I disagree with the original statement that one should absolutely know/use these tools, similarly to macros in other languages these are very advanced/last resort mechanisms that are very great in that rare chance they are needed, but overuse of them can make code very hard to understand.
  - 4y ago

lincpa 4y ago

[dead]