Can programming be liberated from the von Neumann style?

task of a program is to change the contents of the store in some major way; when one considers that this task must be accomplished entirely by pumping single words back and forth through the von Neumann bottleneck, the reason for its name becomes clear. IMHO IBM is invoking John Backus' work to sell what may be an absolutely great product but are really just ASICs and don't relate to his machine or programming language limits. [0] https://dl.acm.org/doi/pdf/10.1145/359576.359579

this large group absolutely does bring the largest gains and impact to industry. There have been many programming languages created decades before TypeScript that have realized the promise of strong typing. Unfortunately, I think this road took too long. Collectively, people have known about these ideas since John Backus's 1977 Turing Award Lecture [1] -- "Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs" Anyways, I digress. Hopefully this was insightful! Have a great day :) [1] https://dl.acm.org/doi/pdf/10.1145/359576.359579

significant complexity with non-obvious trade-offs once the requirements of an interactive version of that application are taken into account." The fact that you need to create these centralised updater methods is non-obvious, and leads to a bunch of related non-local changes. Also a muddle. "This complexity is not the result of a complicated domain model, but rather of the architectural embellishments required to move data from location to location in order to keep the different parts of the application (model, user interface, persistence) synchronized. In the next section, we will look at a mechanism for simplifying this kind of overhead." > ReactJS (uses HOM like Objective-Smalltalk) ReactJS uses Higher Order Messaging? Where? > Chatty: "We highlight a strong coupling between languages and architecture,..." Which was my point, yes, thank you! We are limited in what languages let us express cleanly. React/SwiftUI etc. are workarounds for this issue: they try to re-cast the GUI "problem" as a simple function/procedure. "The UI is a pure function of the model". If it were true, that would make things very simple. Alas, it isn't true: https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... But even without being true, it makes things very convenient, particularly for simple cases. > Backus (https://dl.acm.org/doi/pdf/10.1145/359576.359579) proposed that FP was possibly preferable. Yep, but he later said that FP was a mistake (Interview with Grady Booch). https://www.youtube.com/watch?t=3896&v=dDsWTyLEgbk&feature=y... > The main problem with presenting FP as a different architecture, is that it's just a bunch of abstractions on top of VNA That is also one of my contentions: FP, procedural and OO are just variants of the call/return architectural style. https://dl.acm.org/doi/10.1145/3397537.3397546 Which is why they are insufficient for today's systems. What's VNA? > you might enjoy watching https://www.youtube.com/watch?v=otAcmD6XEEE Yes, already seen it. Was good. > feature rich FP languages around, aren't popular for GUI development. If there was a tangible benefit, I believe it would have been demonstrated. Yes. There isn't. If you look at the papers, you will see that the benefit isn't so much claimed as assumed: "now we can get the wonders of FP for nasty GUI development". > "And not group little bits of GUI+model together, that way madness lies." - almost every game engine and GUI framework uses it. Yep, and that's why they all share the same problems (roughly "Massive View Controller"). It's not a trivial issue, because reusable widgets definitely make sense, but they lead you down a nasty path. https://blog.metaobject.com/2015/04/model-widget-controller-... You need to treat those widgets as easy-to-use Views, and interact with them largely as if they were just views.

here: 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) 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). 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) 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/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.