3 ms·

> “By allowing general architectures, Objective-S is the first general purpose programming language. What we currently call general purpose languages are actua

by User23 5y ago

> “By allowing general architectures, Objective-S is the first general purpose programming language. What we currently call general purpose languages are actually domain specific languages for the domain of algorithms.“ What is this supposed to mean? Perhaps I’m being dense, but it looks like nonsense to me.

mpweiher 5y ago
I would expect it to look like nonsense to many if not most practitioners. It would have seemed like nonsense to me a year or two ago. The issue is incommensurability (https://en.wikipedia.org/wiki/Paradigm_shift#Incommensurability https://en.wikipedia.org/wiki/Paradigm_shift#Incommensurabil... ), though I find the idea that communication or translation is impossible a bit too strong. But it definitely is very difficult. As a start, think of what ALGOL stands for: ALGOrithimic Language ( https://en.wikipedia.org/wiki/ALGOL https://en.wikipedia.org/wiki/ALGOL ). Now think which current mainstream language is not derived from ALGOL. There are some variations, but they are fairly minor. OO languages attach the procedures to the data structures, and call the result methods and object respectively. FP languages insist procedures must not have side-effects and call them functions. And so on. (And once I remembered what ALGOL stood for, I thought that what I had thought of as a deep insight was so trivial that obviously everyone already knew it. I guess not :) ). Anyway, my first semi-coherent written account of this is here: 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... In short: the first thing we used our computers for was computing answers. For this functions/procedures are well suited, and so we also used procedures (sub-routines) as our structuring mechanism. The problems we are solving with our computers have changed dramatically, but our structuring mechanism has remained essentially the same. Another short: software architecture defines many different kinds of connectors and components. The procedure/function call is just one of them, but that's the one that is directly supported by the majority of our programming languages. So if we need a different architectural style, we have to cobble it together out of procedure calls.
- ghusbands 5y ago
  Have you looked at Oz? There are many multi-paradigm languages out there. Don't they undermine the claim that "Objective-S is the first general purpose programming language"? Also, Curry and some mini/microkanren embeddings support interesting architectural styles.
  - mpweiher 5y ago
    Yes, "Concepts, Techniques, and Models of Computer Programming" has been a definite inspiration. However, to me their approach is still very call/return centric, thus not allowing the full freedom of defining your own connectors.
- slver 5y ago
  This implies there's something else that's not "procedures/calls" out there, i.e. subroutines. What else is there, can we name one of them? Subdividing a big problem into a set of smaller problems is not just some specific way of programming, it's not even a specific way of factoring a system. It's universal, as in the entire Universe essentially is factored this way. We have areas of "widening" cohesion and coupling (implementation) and areas of "narrowing" cohesion and coupling (interfaces, incl. argument/return types). These occur both horizontally and vertically as we move towards smaller and smaller problems to solve. Your actual CPU works this way, itself. So I'm very curious what we're talking about and why the dismissive attitude towards procedures i.e. "cobble it together out of procedure calls". In these conversations usually people just bring up something else that's also a procedure, but we call it something else, like "message passing to object methods". That's a useful metaphor at a higher level for sure. But let's not forget a method is just a procedure that runs and does things like any other procedure.
  - mpweiher 5y ago
    This implies there's something else that's not "procedures/calls" out there, i.e. subroutines. What else is there, can we name one of them? Subdividing a big problem into a set of smaller problems is not just some specific way of programming, it's not even a specific way of factoring a system. It's universal, as in the entire Universe essentially is factored this way. We have areas of "widening" cohesion and coupling (implementation) and areas of "narrowing" cohesion and coupling (interfaces, incl. argument/return types). These occur both horizontally and vertically as we move towards smaller and smaller problems to solve. Your actual CPU works this way, itself. So I'm very curious what we're talking about and why the dismissive attitude towards procedures i.e. "cobble it together out of procedure calls". In these conversations usually people just bring up something else that's also a procedure, but we call it something else, like "message passing to object methods". That's a useful metaphor at a higher level for sure. But let's not forget a method is just a procedure that runs and does things like any other procedure. ----------- Thanks for the great questions! I am particularly delighted by the slight incredulity expressed as to whether it's actually possible for there to be anything else. This has been my thesis for a while, that the call/return style has become so incredibly dominant that it is now largely synonymous with programming itself and thus something that is programming but "not call/return" seems self-contradictory and non-sensical, because if programming = call/return, then that would become "programming but not programming". Clearly illogical. However, there are actually quite a few other connectors, and call/return is really just a small but important corner of the "connector space". See for example Towards a Taxonomy of Software Connectors: https://dl.acm.org/doi/10.1145/337180.337201 https://www.ics.uci.edu/~andre/ics223w2006/mehtamedvidovicphadke.pdf But any book on software architecture will do, for example Software Architecture, Perspectives on an Emerging Discipline by Garlan and Shaw: https://www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572 Objective-S concentrates on 3 architectural styles and their corresponding connectors, in addition to broadening call/return to full-bore messaging: 1. Dataflow: (Unix) Pipes and Filters[1], dataflow constraints[2] 2. Data access: (In-Process) REST[3], Polymorphic Identifiers[4], Storage Combinators[4] 3. Implicit invocation: Notification Protocols[6] Most of these papers can be accessed despite the paywall from the the Objective-S publications page: http://objective.st/Publications/ http://objective.st/Publications/ (that's an exception allowed by the ACM). > let's not forget a method is just a procedure Exactly! I had a good laugh when I saw Rust described as a "multi-paradigm"vprogramming language in an official Mozilla presentation, because it supports "imperative, functional and object-oriented" programming. These are all (very) slight variations of call/return. > Subdividing a big problem into a set of smaller problems is ... universal Absolutely! Recursive decomposition is fairly universal (and powerful). However procedural recursive decomposition is not. Except in programming, where we are only allowed to abstract using procedures. Which is both extremely weird, once you think about it, but at the same time so universal that it is extremely hard to notice it as a limitation, and even harder to think of alternatives. The first time I really noticed this was when looking at the OCaml Lwt user-level threading library (for I/O), which had an innocuous looking passage describing CPU-bound threads as a special case. Really? I mean, yes, but no. Anyway, I tried writing this up here, but it's just way too long, so I'll just write another blog post. Once you become aware of this issue of using call/return where it isn't really appropriate, you find it everywhere, and you notice that a LOT of the "accidental" complexity we currently suffer in development appears to be attributable to this issue. "Code seems "large" and "complicated" for what it does" -- Alan Kay (https://youtu.be/ubaX1Smg6pY?t=113 https://youtu.be/ubaX1Smg6pY?t=113) "One of the complaints I have is that the teams doing products that you see are far larger than they should be. And that's a failure of architecture" -- Eric Schmidt https://youtu.be/hcRxFRgNpns?t=3591 https://youtu.be/hcRxFRgNpns?t=3591 [1] https://dl.acm.org/doi/10.1145/3359619.3359748 https://dl.acm.org/doi/10.1145/3359619.3359748 [2] https://dl.acm.org/doi/10.1145/2889443.2889456?cid=81316491227 https://dl.acm.org/doi/10.1145/2889443.2889456?cid=813164912... [3] https://link.springer.com/chapter/10.1007%2F978-1-4614-9299-3_11 https://link.springer.com/chapter/10.1007%2F978-1-4614-9299-... [4] https://dl.acm.org/doi/10.1145/2508168.2508169?cid=81316491227 https://dl.acm.org/doi/10.1145/2508168.2508169?cid=813164912... [5] https://dl.acm.org/doi/10.1145/3359591.3359729?cid=81316491227 https://dl.acm.org/doi/10.1145/3359591.3359729?cid=813164912... [6] https://blog.metaobject.com/2018/04/notification-protocols.html https://blog.metaobject.com/2018/04/notification-protocols.h...

by User23 5y ago

mpweiher 5y ago

I would expect it to look like nonsense to many if not most practitioners. It would have seemed like nonsense to me a year or two ago. The issue is incommensurability (https://en.wikipedia.org/wiki/Paradigm_shift#Incommensurability https://en.wikipedia.org/wiki/Paradigm_shift#Incommensurabil... ), though I find the idea that communication or translation is impossible a bit too strong. But it definitely is very difficult. As a start, think of what ALGOL stands for: ALGOrithimic Language ( https://en.wikipedia.org/wiki/ALGOL https://en.wikipedia.org/wiki/ALGOL ). Now think which current mainstream language is not derived from ALGOL. There are some variations, but they are fairly minor. OO languages attach the procedures to the data structures, and call the result methods and object respectively. FP languages insist procedures must not have side-effects and call them functions. And so on. (And once I remembered what ALGOL stood for, I thought that what I had thought of as a deep insight was so trivial that obviously everyone already knew it. I guess not :) ). Anyway, my first semi-coherent written account of this is here: 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... In short: the first thing we used our computers for was computing answers. For this functions/procedures are well suited, and so we also used procedures (sub-routines) as our structuring mechanism. The problems we are solving with our computers have changed dramatically, but our structuring mechanism has remained essentially the same. Another short: software architecture defines many different kinds of connectors and components. The procedure/function call is just one of them, but that's the one that is directly supported by the majority of our programming languages. So if we need a different architectural style, we have to cobble it together out of procedure calls.

ghusbands 5y ago
Have you looked at Oz? There are many multi-paradigm languages out there. Don't they undermine the claim that "Objective-S is the first general purpose programming language"? Also, Curry and some mini/microkanren embeddings support interesting architectural styles.
- mpweiher 5y ago
  Yes, "Concepts, Techniques, and Models of Computer Programming" has been a definite inspiration. However, to me their approach is still very call/return centric, thus not allowing the full freedom of defining your own connectors.
slver 5y ago
This implies there's something else that's not "procedures/calls" out there, i.e. subroutines. What else is there, can we name one of them? Subdividing a big problem into a set of smaller problems is not just some specific way of programming, it's not even a specific way of factoring a system. It's universal, as in the entire Universe essentially is factored this way. We have areas of "widening" cohesion and coupling (implementation) and areas of "narrowing" cohesion and coupling (interfaces, incl. argument/return types). These occur both horizontally and vertically as we move towards smaller and smaller problems to solve. Your actual CPU works this way, itself. So I'm very curious what we're talking about and why the dismissive attitude towards procedures i.e. "cobble it together out of procedure calls". In these conversations usually people just bring up something else that's also a procedure, but we call it something else, like "message passing to object methods". That's a useful metaphor at a higher level for sure. But let's not forget a method is just a procedure that runs and does things like any other procedure.
- mpweiher 5y ago
  This implies there's something else that's not "procedures/calls" out there, i.e. subroutines. What else is there, can we name one of them? Subdividing a big problem into a set of smaller problems is not just some specific way of programming, it's not even a specific way of factoring a system. It's universal, as in the entire Universe essentially is factored this way. We have areas of "widening" cohesion and coupling (implementation) and areas of "narrowing" cohesion and coupling (interfaces, incl. argument/return types). These occur both horizontally and vertically as we move towards smaller and smaller problems to solve. Your actual CPU works this way, itself. So I'm very curious what we're talking about and why the dismissive attitude towards procedures i.e. "cobble it together out of procedure calls". In these conversations usually people just bring up something else that's also a procedure, but we call it something else, like "message passing to object methods". That's a useful metaphor at a higher level for sure. But let's not forget a method is just a procedure that runs and does things like any other procedure. ----------- Thanks for the great questions! I am particularly delighted by the slight incredulity expressed as to whether it's actually possible for there to be anything else. This has been my thesis for a while, that the call/return style has become so incredibly dominant that it is now largely synonymous with programming itself and thus something that is programming but "not call/return" seems self-contradictory and non-sensical, because if programming = call/return, then that would become "programming but not programming". Clearly illogical. However, there are actually quite a few other connectors, and call/return is really just a small but important corner of the "connector space". See for example Towards a Taxonomy of Software Connectors: https://dl.acm.org/doi/10.1145/337180.337201 https://www.ics.uci.edu/~andre/ics223w2006/mehtamedvidovicphadke.pdf But any book on software architecture will do, for example Software Architecture, Perspectives on an Emerging Discipline by Garlan and Shaw: https://www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572 Objective-S concentrates on 3 architectural styles and their corresponding connectors, in addition to broadening call/return to full-bore messaging: 1. Dataflow: (Unix) Pipes and Filters[1], dataflow constraints[2] 2. Data access: (In-Process) REST[3], Polymorphic Identifiers[4], Storage Combinators[4] 3. Implicit invocation: Notification Protocols[6] Most of these papers can be accessed despite the paywall from the the Objective-S publications page: http://objective.st/Publications/ http://objective.st/Publications/ (that's an exception allowed by the ACM). > let's not forget a method is just a procedure Exactly! I had a good laugh when I saw Rust described as a "multi-paradigm"vprogramming language in an official Mozilla presentation, because it supports "imperative, functional and object-oriented" programming. These are all (very) slight variations of call/return. > Subdividing a big problem into a set of smaller problems is ... universal Absolutely! Recursive decomposition is fairly universal (and powerful). However procedural recursive decomposition is not. Except in programming, where we are only allowed to abstract using procedures. Which is both extremely weird, once you think about it, but at the same time so universal that it is extremely hard to notice it as a limitation, and even harder to think of alternatives. The first time I really noticed this was when looking at the OCaml Lwt user-level threading library (for I/O), which had an innocuous looking passage describing CPU-bound threads as a special case. Really? I mean, yes, but no. Anyway, I tried writing this up here, but it's just way too long, so I'll just write another blog post. Once you become aware of this issue of using call/return where it isn't really appropriate, you find it everywhere, and you notice that a LOT of the "accidental" complexity we currently suffer in development appears to be attributable to this issue. "Code seems "large" and "complicated" for what it does" -- Alan Kay (https://youtu.be/ubaX1Smg6pY?t=113 https://youtu.be/ubaX1Smg6pY?t=113) "One of the complaints I have is that the teams doing products that you see are far larger than they should be. And that's a failure of architecture" -- Eric Schmidt https://youtu.be/hcRxFRgNpns?t=3591 https://youtu.be/hcRxFRgNpns?t=3591 [1] https://dl.acm.org/doi/10.1145/3359619.3359748 https://dl.acm.org/doi/10.1145/3359619.3359748 [2] https://dl.acm.org/doi/10.1145/2889443.2889456?cid=81316491227 https://dl.acm.org/doi/10.1145/2889443.2889456?cid=813164912... [3] https://link.springer.com/chapter/10.1007%2F978-1-4614-9299-3_11 https://link.springer.com/chapter/10.1007%2F978-1-4614-9299-... [4] https://dl.acm.org/doi/10.1145/2508168.2508169?cid=81316491227 https://dl.acm.org/doi/10.1145/2508168.2508169?cid=813164912... [5] https://dl.acm.org/doi/10.1145/3359591.3359729?cid=81316491227 https://dl.acm.org/doi/10.1145/3359591.3359729?cid=813164912... [6] https://blog.metaobject.com/2018/04/notification-protocols.html https://blog.metaobject.com/2018/04/notification-protocols.h...