3 ms·

> Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language. > He just made the

> Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language. > He just made the important point that "one must provide new kinds of glue" and then the amount of "new kinds of glue" is the smallest number that actually justifies using the plural. The real issue is the appeal to authority. John Huges didn't make a point; he made a claim. Specifically "new kinds of glue" is a troubling phrase, that has likely been misused more than just this blogpost. The statement implies there are more than was common at the time of writing (maybe?). It doesn't specifically mean there need be more than lambdas, closures, and mixins or more implementations of the same in different ways (runtime composition via aspects, copy-paste composition via traits, etc). I would think this needs more study, as it's more of a casual observation than a strong claim. Was Perl the most modular? Maybe so. I don't think that made it the most useful, implying an upper boundary, as Marcel noted.

mpweiher 5y ago
> The real issue is the appeal to authority. No appeal to authority here as I don't claim this as true, just interesting. > John Huges didn't make a point; he made a claim. Actually, he did make a point, as he provided reasoning for his claim. > The statement implies there are more than was common at the time of writing (maybe?) There are. Towards a Taxonomy of Software Connectors https://dl.acm.org/doi/10.1145/337180.337201 https://dl.acm.org/doi/10.1145/337180.337201 / https://csis.pace.edu/~marchese/CS865/Papers/p178-mehta.pdf https://csis.pace.edu/~marchese/CS865/Papers/p178-mehta.pdf I count > 100 leaf nodes in their classification tree. Not sure I agree with all of them, and there are probably others they missed. But more than 2 is trivially fulfilled. > Was Perl the most modular? Hmm...Perl wouldn't come to mind as something with a way for a user to define and refine new connectors.
- Supermancho 5y ago
  > 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...

mpweiher 5y ago

> The real issue is the appeal to authority. No appeal to authority here as I don't claim this as true, just interesting. > John Huges didn't make a point; he made a claim. Actually, he did make a point, as he provided reasoning for his claim. > The statement implies there are more than was common at the time of writing (maybe?) There are. Towards a Taxonomy of Software Connectors https://dl.acm.org/doi/10.1145/337180.337201 https://dl.acm.org/doi/10.1145/337180.337201 / https://csis.pace.edu/~marchese/CS865/Papers/p178-mehta.pdf https://csis.pace.edu/~marchese/CS865/Papers/p178-mehta.pdf I count > 100 leaf nodes in their classification tree. Not sure I agree with all of them, and there are probably others they missed. But more than 2 is trivially fulfilled. > Was Perl the most modular? Hmm...Perl wouldn't come to mind as something with a way for a user to define and refine new connectors.

Supermancho 5y ago
> 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...