11 ms·

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

> 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...
- Supermancho 5y ago
  I will start with a couple clarifications, in good faith. I will admit that I have made lazy errors in this discussion. Specifically in regard to terminology. Afaik, there is no term for "temporally unsynchronized" other than parallelism or concurrency, and I have misused the term concurrency at times. I have also used the term transition to mean "asynchronous state transition". This may clarify my past statements, but I will attempt to do better, going forward. So I'll visit on the material you are most familiar with so that my comments might have the most specific impact or irrelevance. For your verification, I read your paper here: https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2016_ConstraintsAsPolymorphicConnectors_AuthorsVersion.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media... To begin, I agree on the concept. If "constraining architecture" means any separation of concerns or interface. To demonstrate that I did read through the code snippets you provided and completely irrelevant to the points being discussed, I believe there was an error in the code you posted in Listing 8@p.136 - - k: degreesK { self basicC :( degreesF - 273.15. \*wat?\* ivar : ui / celsiusTextField / intValue := self c . ivar : ui / fahrenheitTextField / intValue := self f. } I also thought the implementation was a little muddled and would implement a solution similar to this^. Object subclass: #Temperatures { var c. -changedC : sender { self c: sender intValue. self updateValues: { #val : c, #type: 'Celcius' }. } -changedF : sender { self f: sender intValue. self updateValues: { #val : f, #type: 'Farenheit' }. } -changedK : sender { self k : sender intValue. self updateValues: { #val : k, #type: 'Kelvin' }. } -<void>updateValues: dict { stringValue := dict#type. intValue := dict#val. stringValue = 'Celsius' ifTrue: [self c:= intValue] ifFalse: [ stringValue = 'Farenheit' ifTrue: [self c:= ((intValue-32)*5/9)] ifFalse: [self c:= (intValue-273.15)] ]. self:updateUi. } -<void>updateUi { ivar : ui / celciusTextField / intValue := c. ivar : ui / fahrenheitTextField / intValue := c*5/9+32. ivar : ui / kelvinTextField / intValue := c+273.15. } } ^I don't have all the necessary syntax for Objective-Smalltalk, I have munged in some Smalltalk and made up some dictionary derefence syntax. I other languages, I would construct this differently, with the same overall strategy. After digesting the material, I do not think about the concept of architecture in the way you or Chatty or Backus have been presenting it. In support of this thinking, the idea of seeking the proper GUI abstractions has been sought by most programming language communities. ReactJS (uses HOM like Objective-Smalltalk) or a vanilla actor model^^^, is considered the current state-of-the-art. The MVC layers are most popular in areas where inputs are relatively static within a thread (eg web backend software). In opposition to this thinking, I believe Software Architecture emerges from a combination of mental modeling, language syntax, supported data exchange formats, and resource dependencies/components^^. To some extent, Chatty recognizes this; "We highlight a strong coupling between languages and architecture,..." Backus (https://dl.acm.org/doi/pdf/10.1145/359576.359579 https://dl.acm.org/doi/pdf/10.1145/359576.359579) proposed that FP was possibly preferable. The main problem with presenting FP as a different architecture, is that it's just a bunch of abstractions on top of VNA (you might enjoy watching https://www.youtube.com/watch?v=otAcmD6XEEE https://www.youtube.com/watch?v=otAcmD6XEEE). Chatty references Turing in 3.1.1@p.6. Ofc Lisp and Occam rely on implicit grouping, in the form of blocks (or any other lexical scope). Fundamentally, FP vs any other style is all the same implementation running on the same kind of machine. A second problem, having to do with specific purpose, is that the side effects in procedural are largely a benefit for the median developer. At each interaction with state, a developer can use a program (that is nothing more than some psuedo-algebraic transforms), into an actor via the consequences of the imperative structure. Lastly, the imperative structure is explicit; although this has started to break down across modern languages. To demonstrate, when using the FP "apply(...)" in Javascript, you can generate outputs that have no explicit inputs (eg https://www.w3schools.com/js/js_function_apply.asp https://www.w3schools.com/js/js_function_apply.asp) breaking the input/output paradigm. This is perfectly normal in FP, which (like the Java Spring Framework) makes VNA code harder to reason about by introducing composition of unrelated structures resolving at runtime. This is a step backward for maintainability, reasoning, testing and formalizing. I cannot be convinced that FP is "the future" or is a different software architecture in any meaningful sense. As an aside, Erlang and Haskell, which are the most feature rich FP languages around, aren't popular for GUI development. If there was a tangible benefit, I believe it would have been demonstrated. ^^https://resources.sei.cmu.edu/asset_files/TechnicalReport/1994_005_001_16277.pdf https://resources.sei.cmu.edu/asset_files/TechnicalReport/19... - M. Shaw's diagrams supposes that design is focused on components. This is partly incorrect. SDA Diagrams, uniformly track information flow, which necessarily involves a multiple components for information to flow between. ^^^"And not group little bits of GUI+model together, that way madness lies." - almost every game engine and GUI framework uses it. Heck, even the Objective-Smalltalk program is taking inputs from non-trivial widgets, which are precisely small GUI+model underneath.

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

Supermancho 5y ago
I will start with a couple clarifications, in good faith. I will admit that I have made lazy errors in this discussion. Specifically in regard to terminology. Afaik, there is no term for "temporally unsynchronized" other than parallelism or concurrency, and I have misused the term concurrency at times. I have also used the term transition to mean "asynchronous state transition". This may clarify my past statements, but I will attempt to do better, going forward. So I'll visit on the material you are most familiar with so that my comments might have the most specific impact or irrelevance. For your verification, I read your paper here: https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2016_ConstraintsAsPolymorphicConnectors_AuthorsVersion.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media... To begin, I agree on the concept. If "constraining architecture" means any separation of concerns or interface. To demonstrate that I did read through the code snippets you provided and completely irrelevant to the points being discussed, I believe there was an error in the code you posted in Listing 8@p.136 - - k: degreesK { self basicC :( degreesF - 273.15. \*wat?\* ivar : ui / celsiusTextField / intValue := self c . ivar : ui / fahrenheitTextField / intValue := self f. } I also thought the implementation was a little muddled and would implement a solution similar to this^. Object subclass: #Temperatures { var c. -changedC : sender { self c: sender intValue. self updateValues: { #val : c, #type: 'Celcius' }. } -changedF : sender { self f: sender intValue. self updateValues: { #val : f, #type: 'Farenheit' }. } -changedK : sender { self k : sender intValue. self updateValues: { #val : k, #type: 'Kelvin' }. } -<void>updateValues: dict { stringValue := dict#type. intValue := dict#val. stringValue = 'Celsius' ifTrue: [self c:= intValue] ifFalse: [ stringValue = 'Farenheit' ifTrue: [self c:= ((intValue-32)*5/9)] ifFalse: [self c:= (intValue-273.15)] ]. self:updateUi. } -<void>updateUi { ivar : ui / celciusTextField / intValue := c. ivar : ui / fahrenheitTextField / intValue := c*5/9+32. ivar : ui / kelvinTextField / intValue := c+273.15. } } ^I don't have all the necessary syntax for Objective-Smalltalk, I have munged in some Smalltalk and made up some dictionary derefence syntax. I other languages, I would construct this differently, with the same overall strategy. After digesting the material, I do not think about the concept of architecture in the way you or Chatty or Backus have been presenting it. In support of this thinking, the idea of seeking the proper GUI abstractions has been sought by most programming language communities. ReactJS (uses HOM like Objective-Smalltalk) or a vanilla actor model^^^, is considered the current state-of-the-art. The MVC layers are most popular in areas where inputs are relatively static within a thread (eg web backend software). In opposition to this thinking, I believe Software Architecture emerges from a combination of mental modeling, language syntax, supported data exchange formats, and resource dependencies/components^^. To some extent, Chatty recognizes this; "We highlight a strong coupling between languages and architecture,..." Backus (https://dl.acm.org/doi/pdf/10.1145/359576.359579 https://dl.acm.org/doi/pdf/10.1145/359576.359579) proposed that FP was possibly preferable. The main problem with presenting FP as a different architecture, is that it's just a bunch of abstractions on top of VNA (you might enjoy watching https://www.youtube.com/watch?v=otAcmD6XEEE https://www.youtube.com/watch?v=otAcmD6XEEE). Chatty references Turing in 3.1.1@p.6. Ofc Lisp and Occam rely on implicit grouping, in the form of blocks (or any other lexical scope). Fundamentally, FP vs any other style is all the same implementation running on the same kind of machine. A second problem, having to do with specific purpose, is that the side effects in procedural are largely a benefit for the median developer. At each interaction with state, a developer can use a program (that is nothing more than some psuedo-algebraic transforms), into an actor via the consequences of the imperative structure. Lastly, the imperative structure is explicit; although this has started to break down across modern languages. To demonstrate, when using the FP "apply(...)" in Javascript, you can generate outputs that have no explicit inputs (eg https://www.w3schools.com/js/js_function_apply.asp https://www.w3schools.com/js/js_function_apply.asp) breaking the input/output paradigm. This is perfectly normal in FP, which (like the Java Spring Framework) makes VNA code harder to reason about by introducing composition of unrelated structures resolving at runtime. This is a step backward for maintainability, reasoning, testing and formalizing. I cannot be convinced that FP is "the future" or is a different software architecture in any meaningful sense. As an aside, Erlang and Haskell, which are the most feature rich FP languages around, aren't popular for GUI development. If there was a tangible benefit, I believe it would have been demonstrated. ^^https://resources.sei.cmu.edu/asset_files/TechnicalReport/1994_005_001_16277.pdf https://resources.sei.cmu.edu/asset_files/TechnicalReport/19... - M. Shaw's diagrams supposes that design is focused on components. This is partly incorrect. SDA Diagrams, uniformly track information flow, which necessarily involves a multiple components for information to flow between. ^^^"And not group little bits of GUI+model together, that way madness lies." - almost every game engine and GUI framework uses it. Heck, even the Objective-Smalltalk program is taking inputs from non-trivial widgets, which are precisely small GUI+model underneath.