3 ms·

I did a cursory ctl-f check for "Shaw" in those links and turned up nil. In their 'About' page, they say: "The theoretical foundation for Objective-S is Mary S

I did a cursory ctl-f check for "Shaw" in those links and turned up nil. In their 'About' page, they say: "The theoretical foundation for Objective-S is Mary Shaw's Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status." https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=12137 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid... So I skimmed M. Shaw's (1994) paper [1] and it is very much a dated concern. The main thrust of her critique is valid only in the context of monolithical systems depending on a linker to assemble a composite system ("architecture"). She is basically arguing for language semantics capable of expressing connecting diverse libraries in an e.g. Unix Pipes fashion. For example, one of her criticisms of existing languages (and linkers) is namespace collisions. The other is asymmetry of connecting modules. And finally (and she's entirely right about this too) that the definition of the final [monolith] system's "structure" is dispersed in various "import" directives in constituent modules. But again, this seems to be an entirely dated concern and a completely mute point in the current regiment of networked processes. So, to this thread's raised eyebrows regarding "general purpose language" and the language website's (actually pedantically correct) notion of "domain specific languages for the domain of algorithms", hopefully above will make the matter more clear. The "[DSL] of algorithms" is what you write your e.g. "microservice". Arguably, these are, in fact, purely algorithmic constructs. And something along the lines of M. Shaw's ideas (but certainly not Objective-S as I skimmed it) would express the total system architecture. [1]: it's just 12 pages so won't take too much time.

cloogshicer 5y ago
I'm surprised to hear that you think her paper addresses a dated concern. I felt it's more relevant than ever. While I agree that naming collisions are not such a big problem, all the other issues she mentions are still present, and have even gotten worse.
- eternalban 5y ago
  This would require a fairly lengthy discussion and a level of frankness required in terms of discussing the realities of software profession that imho will not be well received in this forum. I didn't say her thoughts were incorrect. Simply this: it reflects the appraisals and realities of an earlier time in this profession.
  - cloogshicer 5y ago
    Would love to discuss it and further understand your viewpoint. Feel free to be as frank as you need to be, would love to hear a radical new opinion on this. From my experience, what she said is still highly relevant. Maybe I can share my own viewpoint first: Imagine you want to use a third party dependency from GitHub. The first thing you will do is read the readme, which contains an architectural overview (if the project is documented well). This overview is very similar to what she describes in the paper - it's mostly prose and a few (non-formal) diagrams. Often, it's very hard to understand how the code fits into the bigger picture of the system. Also, a lot of info is implicit or only contained in prose (for example, which function do I call first?). Wouldn't it be great if all this were standardized/codified in some way, and not just part of the documentation?
    - eternalban 5y ago
      > Feel free to be as frank as you need to be I'll try being tactful instead. And you on your part can try and read between the lines. (I have no desire to offend and my concern is not you.) https://www.isri.cmu.edu/people/core-faculty/shaw-mary.html https://www.isri.cmu.edu/people/core-faculty/shaw-mary.html She appears to be a highly accomplished academic. > Often, it's very hard to understand how the code fits into the bigger picture of the system. Progressively and now quite frequently in the field, usage of 3rd party code is formulaic. Progressively, as demand for software has increased, an equally downward pressure is brought to bear on value placed on contemplation. > Wouldn't it be great if all this were standardized/codified in some way, and not just part of the documentation? Yes. This is a thoughtful approach and would reduce the burden for the thoughtful programmer.
      - mpweiher 5y ago
        Right now, documenting your architecture is extra work. As is actually having a decent architecture, something other than a Big Ball of Mud. What if having a reasonably well-defined (maybe even "good") architecture were not more work, but less work? And the "code" would be the architecture documentation, because you can actually just write down your architecture.

cloogshicer 5y ago

I'm surprised to hear that you think her paper addresses a dated concern. I felt it's more relevant than ever. While I agree that naming collisions are not such a big problem, all the other issues she mentions are still present, and have even gotten worse.

eternalban 5y ago
This would require a fairly lengthy discussion and a level of frankness required in terms of discussing the realities of software profession that imho will not be well received in this forum. I didn't say her thoughts were incorrect. Simply this: it reflects the appraisals and realities of an earlier time in this profession.
- cloogshicer 5y ago
  Would love to discuss it and further understand your viewpoint. Feel free to be as frank as you need to be, would love to hear a radical new opinion on this. From my experience, what she said is still highly relevant. Maybe I can share my own viewpoint first: Imagine you want to use a third party dependency from GitHub. The first thing you will do is read the readme, which contains an architectural overview (if the project is documented well). This overview is very similar to what she describes in the paper - it's mostly prose and a few (non-formal) diagrams. Often, it's very hard to understand how the code fits into the bigger picture of the system. Also, a lot of info is implicit or only contained in prose (for example, which function do I call first?). Wouldn't it be great if all this were standardized/codified in some way, and not just part of the documentation?
  - eternalban 5y ago
    > Feel free to be as frank as you need to be I'll try being tactful instead. And you on your part can try and read between the lines. (I have no desire to offend and my concern is not you.) https://www.isri.cmu.edu/people/core-faculty/shaw-mary.html https://www.isri.cmu.edu/people/core-faculty/shaw-mary.html She appears to be a highly accomplished academic. > Often, it's very hard to understand how the code fits into the bigger picture of the system. Progressively and now quite frequently in the field, usage of 3rd party code is formulaic. Progressively, as demand for software has increased, an equally downward pressure is brought to bear on value placed on contemplation. > Wouldn't it be great if all this were standardized/codified in some way, and not just part of the documentation? Yes. This is a thoughtful approach and would reduce the burden for the thoughtful programmer.
    - mpweiher 5y ago
      Right now, documenting your architecture is extra work. As is actually having a decent architecture, something other than a Big Ball of Mud. What if having a reasonably well-defined (maybe even "good") architecture were not more work, but less work? And the "code" would be the architecture documentation, because you can actually just write down your architecture.