4 ms·

> Perl wouldn't come to mind as something with a way for a user to define and refine new connectors. Anyone can add a new features to a language that users wan

> Perl wouldn't come to mind as something with a way for a user to define and refine new connectors. Anyone can add a new features to a language that users want to use. The source of the new connectors are incidental (user defined vs native syntax). That aside, operator overloading is fits the specific "user glue" you are focusing on. Perl added this in 1999. Perl pretty much had everything (Moose object system, etc).

mpweiher 5y ago
> That aside, operator overloading is fits the specific "user glue" you are focusing on I thought so as well, for a long time, but it turns out not to be the case, because you can't properly do "connection" via call/return. You can do it, but not "properly". The Problem: Architectural Mismatch ------ The crux is that all mainstream and virtually all non-mainstream languages aren’t really general purpose, though we obviously think of them and use them that way. They are DSLs for the domain of algorithms, for computing answers based on some inputs. Obviously with many variations, but the essence is the same. a := f(x). Or a := x.f(). Or a: x f. And the algorithmic mechanism we have for computing answers is also our primary linguistic mechanism for structuring our programs: the procedure/function/method. (Objects/classes/prototypes/modules are secondary mechanisms). (see also: the ALGOrithmic Language, predecessor to most of what we have, and allegedly an improvement on much of that). As long as our problems were also primarily algorithmic, this was perfectly fine. But they no longer are, they are shifting more and more away from being algorithmic. For example, if you look at how we program user interfaces today, there hasn’t really been much progress since the early 80s or 90s. Arguably things have actually taken huge leaps backwards in many areas. I found this very puzzling, and the common explanation of “kids these days” seemed a bit too facile. The problem became a bit clearer when I discovered Stéphane Chatty’s wonderful, and slightly provocatively named paper "Programs = Data + Algorithms + Architecture: consequences for interactive software engineering". https://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf https://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf He explains very well, and compellingly, how our programming languages are architecturally mismatched for writing GUIs. Once you see it, it becomes really hard to un-see, and this problem of algorithmic programming languages, or in the architectural vernacular I prefer, call/return programming languages pops up everywhere. Or how Guy Steele put it: "Another weakness of procedural and functional programming is that their viewpoint assumes a process by which "inputs" are transformed into "outputs"; there is equal concern for correctness and for termination (and proofs thereof). But as we have connected millions of computers to form the Internet and the World Wide Web, as we have caused large independent sets of state to interact–I am speaking of databases, automated sensors, mobile devices, and (most of all) people–in this highly interactive, distributed setting, the procedural and functional models have failed, another reason why objects have become the dominant model. Ongoing behavior, not completion, is now of primary interest." --- I also thought plain old metaprogramming facilities would do the trick, but in the end those are also insufficient. (For example, my HOM was entirely done via metaprogramming). Architecture Oriented Programming is a generalisation of call/return programming, not an extension. https://blog.metaobject.com/2020/04/why-any-fundamental-improvement-in.html https://blog.metaobject.com/2020/04/why-any-fundamental-impr...
- Supermancho 5y ago
  > He explains very well, and compellingly, how our programming languages are architecturally mismatched for writing GUIs. I'm not sure I agree this was the takeaway. It does highlight that handling of concurrency is percieved as anathema to an algebraic perception of realtime processing by some. Just as one might say that programming languages are architecturally mismatched for writing a biological system, GUIs are a more constrained exercise of the same concepts. I believe this is largely related to a "distributed setting" and the "ongoing behavior" that Steele refers to. (^4.3 paraphrased) GUIs are a set of small programmatic interactions that represent state manipulation. Shortly thereafter: > With interaction, state is essential in behaviors and the locality principle would require that all code that changes it is grouped. That pushed researchers to propose programming patterns based on finite state machines, Statecharts or Petri nets, but: when using a computation-oriented language, the transitions are implemented as functions or methods and the principle of locality is not met; Transitions (eg text fade-out) are not implemented as functions, as everyone knows. Transitions are performed concurrently alongside the state change. Losing control of the transition (or not being aware of it) by initiating a form of parallelism is not optimal to a developer who wants to maintain control, but is undeniably effective in performing the work. The fact that any module (say a label's fadeOut method) can behave concurrently at any time is a side-effect of information hiding, rather than a loss of main/subrouting empiricism. It does require a new set of concerns and architecture additions, rather than a full-blown teardown. P.S. What I always found most interesting about that paper is the side-criticisms about encapsulation.
  - mpweiher 5y ago
    >> our programming languages are architecturally mismatched for writing GUIs. > I'm not sure I agree this was the takeaway. Hmmm...he says so quite explicitly. For example, Section 4: "4 Understanding mismatches We now propose a few reasons why architecture patterns proposed at level 3 for interactive software display incompatibilities with those offered by most programming languages." Not sure how much more directly this could be expressed. > ...handling of concurrency... Concurrency is just one of a whole number of architectural issues. In the abstract, he writes: "Among these are the contra-variance of reuse and control, new scenarios of software reuse, the architecture-induced concurrency, and the multiplicity of hierarchies." So it's not even concurrency as a stand-alone issue. It's just an artefact of the architectural mismatch. > ... state manipulation ... Yes, which is why the idea that FP is a good match for GUI programming is...er..."special". Which is reflected in the hoops that you have to jump through to make it work at all. Not sure what you're trying to say with the bit about transitions. You obviously have to encapsulate the GUI and separate it from the Model. MVC, yay! And not group little bits of GUI+model together, that way madness lies. And bugs. The core of MVC is essentially just a set of dataflow constraints, so can be expressed compactly, elegantly and correctly using a different architectural language, one that allows that type of connectors. I had a fairly well-worked out example in my Constraints as polymorphic connectors paper: https://dl.acm.org/doi/10.1145/2889443.2889456?cid=81316491227 https://dl.acm.org/doi/10.1145/2889443.2889456?cid=813164912...

mpweiher 5y ago

> That aside, operator overloading is fits the specific "user glue" you are focusing on I thought so as well, for a long time, but it turns out not to be the case, because you can't properly do "connection" via call/return. You can do it, but not "properly". The Problem: Architectural Mismatch ------ The crux is that all mainstream and virtually all non-mainstream languages aren’t really general purpose, though we obviously think of them and use them that way. They are DSLs for the domain of algorithms, for computing answers based on some inputs. Obviously with many variations, but the essence is the same. a := f(x). Or a := x.f(). Or a: x f. And the algorithmic mechanism we have for computing answers is also our primary linguistic mechanism for structuring our programs: the procedure/function/method. (Objects/classes/prototypes/modules are secondary mechanisms). (see also: the ALGOrithmic Language, predecessor to most of what we have, and allegedly an improvement on much of that). As long as our problems were also primarily algorithmic, this was perfectly fine. But they no longer are, they are shifting more and more away from being algorithmic. For example, if you look at how we program user interfaces today, there hasn’t really been much progress since the early 80s or 90s. Arguably things have actually taken huge leaps backwards in many areas. I found this very puzzling, and the common explanation of “kids these days” seemed a bit too facile. The problem became a bit clearer when I discovered Stéphane Chatty’s wonderful, and slightly provocatively named paper "Programs = Data + Algorithms + Architecture: consequences for interactive software engineering". https://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf https://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf He explains very well, and compellingly, how our programming languages are architecturally mismatched for writing GUIs. Once you see it, it becomes really hard to un-see, and this problem of algorithmic programming languages, or in the architectural vernacular I prefer, call/return programming languages pops up everywhere. Or how Guy Steele put it: "Another weakness of procedural and functional programming is that their viewpoint assumes a process by which "inputs" are transformed into "outputs"; there is equal concern for correctness and for termination (and proofs thereof). But as we have connected millions of computers to form the Internet and the World Wide Web, as we have caused large independent sets of state to interact–I am speaking of databases, automated sensors, mobile devices, and (most of all) people–in this highly interactive, distributed setting, the procedural and functional models have failed, another reason why objects have become the dominant model. Ongoing behavior, not completion, is now of primary interest." --- I also thought plain old metaprogramming facilities would do the trick, but in the end those are also insufficient. (For example, my HOM was entirely done via metaprogramming). Architecture Oriented Programming is a generalisation of call/return programming, not an extension. https://blog.metaobject.com/2020/04/why-any-fundamental-improvement-in.html https://blog.metaobject.com/2020/04/why-any-fundamental-impr...

Supermancho 5y ago
> He explains very well, and compellingly, how our programming languages are architecturally mismatched for writing GUIs. I'm not sure I agree this was the takeaway. It does highlight that handling of concurrency is percieved as anathema to an algebraic perception of realtime processing by some. Just as one might say that programming languages are architecturally mismatched for writing a biological system, GUIs are a more constrained exercise of the same concepts. I believe this is largely related to a "distributed setting" and the "ongoing behavior" that Steele refers to. (^4.3 paraphrased) GUIs are a set of small programmatic interactions that represent state manipulation. Shortly thereafter: > With interaction, state is essential in behaviors and the locality principle would require that all code that changes it is grouped. That pushed researchers to propose programming patterns based on finite state machines, Statecharts or Petri nets, but: when using a computation-oriented language, the transitions are implemented as functions or methods and the principle of locality is not met; Transitions (eg text fade-out) are not implemented as functions, as everyone knows. Transitions are performed concurrently alongside the state change. Losing control of the transition (or not being aware of it) by initiating a form of parallelism is not optimal to a developer who wants to maintain control, but is undeniably effective in performing the work. The fact that any module (say a label's fadeOut method) can behave concurrently at any time is a side-effect of information hiding, rather than a loss of main/subrouting empiricism. It does require a new set of concerns and architecture additions, rather than a full-blown teardown. P.S. What I always found most interesting about that paper is the side-criticisms about encapsulation.
- mpweiher 5y ago
  >> our programming languages are architecturally mismatched for writing GUIs. > I'm not sure I agree this was the takeaway. Hmmm...he says so quite explicitly. For example, Section 4: "4 Understanding mismatches We now propose a few reasons why architecture patterns proposed at level 3 for interactive software display incompatibilities with those offered by most programming languages." Not sure how much more directly this could be expressed. > ...handling of concurrency... Concurrency is just one of a whole number of architectural issues. In the abstract, he writes: "Among these are the contra-variance of reuse and control, new scenarios of software reuse, the architecture-induced concurrency, and the multiplicity of hierarchies." So it's not even concurrency as a stand-alone issue. It's just an artefact of the architectural mismatch. > ... state manipulation ... Yes, which is why the idea that FP is a good match for GUI programming is...er..."special". Which is reflected in the hoops that you have to jump through to make it work at all. Not sure what you're trying to say with the bit about transitions. You obviously have to encapsulate the GUI and separate it from the Model. MVC, yay! And not group little bits of GUI+model together, that way madness lies. And bugs. The core of MVC is essentially just a set of dataflow constraints, so can be expressed compactly, elegantly and correctly using a different architectural language, one that allows that type of connectors. I had a fairly well-worked out example in my Constraints as polymorphic connectors paper: https://dl.acm.org/doi/10.1145/2889443.2889456?cid=81316491227 https://dl.acm.org/doi/10.1145/2889443.2889456?cid=813164912...