Name: Software architecture
ISBN: 9780131829572

Software architecture

Software developers have often adopted specific architectural patterns for system organization - but, for the most part, informally. In this book, authors Mary Shaw and David Garlan discuss the formalization of what, until now, has been "a substantial folklore of system design, with little consistency or precision.". With their unique perspective on the current state of software architecture and its impact on design, the authors provide useful information for several types of readers: Professional software developers will find new ideas in the discussion and evaluation of familiar patterns. Students will find useful techniques for approaching system organization from an architectural point of view, rather than following current fads or outmoded methodology. Educators will find the book helpful as a text for a software architecture course or as a supplemental text for courses in software engineering or software design. This book also includes hints for choosing a suitable architecture, the use of well-understood paradigms for designing new systems, how formal notation and models can characterize system design, and the study of actual system architectures as models for new designs.

What Hacker News says

mpweiherMay 2026

The recommendations are often very good, for example Ousterhouts A Philosophy of Software Design, but seem to be on software development in general, not actually software architecture in particular.

For that, I would recommend the classic texts, such as Software Architecture: Perspectives on an Emerging Discipline (Shaw/Garlan) and really anything you can find by Mary Shaw. Including more recent papers that explore why the field of software architecture did not go the way they foresaw, for example Myths and Mythconceptions: What Does It Mean to Be a Programming Language, Anyhow? or Revisiting Abstractions for Software Architecture and Tools to Support Them

More practically: look at why Unix pipes and filters and REST are successful, and where they fall down and why. Hexagonal architecture is also key.

And a plug for my own contribution, linking software architecture with metaobject protocols as a new foundation for programming languages and programming: Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status. An answer to Mary Shaw's Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status.

Answering the question: if procedure calls are the assembly language, what might a high level language look like? And also maybe that software architecture might have a brighter and more practical future ahead of itself.

thread

mpweiherJun 2021

"I am not seeing anything here that would differentiate this from a Turing machine"

"I am not seeing anything here that would differentiate this from x86 assembly"

¯\_(ツ)_/¯

Anyway, if you insist on mapping something new in computing onto something you already know, you will pretty much always find some way of accomplishing this. While it might seem clever, it really just reiterates Turing-completeness, and so is not particularly interesting.

The question is whether your mapping is appropriate (it's not) or straightforward (also not).

Of course, this is a problem, because to understand something, you typically first have to map it onto something you already understand, but the key is to not stop there.

As to "something new": no, software architecture is not new. Not new at all. The seminal book is from 1996: Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan.

https://www.amazon.com/Software-Architecture-Perspectives-Em...

The paper trail is much older.

There is an entire discipline behind this, and in this discipline, FP is a small corner of the small corner that is the call/return architectural style, of all the myriad of architectural styles available. You can argue that this whole discipline of computer science with conferences, many thousands of peer-reviewed articles, many books etc. is all just BS, but I think you'd have a hard time arguing that case. And it would be you who'd have to make the case, because the discipline is well-established.

All Objective-S does is to say "hey, let's take this talk of connectors and components seriously and program with them". It's also not the first language to do this, there was ArchJava. Alas, this was an extension of Java with architectural constructs such as connectors, which is the wrong way around: connectors are more general.

thread

mpweiherMay 2021

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/ (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)

"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

[1] https://dl.acm.org/doi/10.1145/3359619.3359748

[2] https://dl.acm.org/doi/10.1145/2889443.2889456?cid=813164912...

[3] https://link.springer.com/chapter/10.1007%2F978-1-4614-9299-...

[4] https://dl.acm.org/doi/10.1145/2508168.2508169?cid=813164912...

[5] https://dl.acm.org/doi/10.1145/3359591.3359729?cid=813164912...

[6] https://blog.metaobject.com/2018/04/notification-protocols.h...

thread

mpweiherMar 2023

2 - 1 = 1

Hughes claims FP provides two (2) kinds of glue: functional composition and lazy evaluation.

It turns out lazy evaluation is actually not really a useful kind of glue, so subtract that one from the two initially presented:

2 - 1 = 1

> Does it mainly bash John Hughes for bragging about how good FP is?

> Or does it mainly advertise for the author's language, Objective Smalltalk?

Neither. It notes that John Hughes had a fantastic insight, but one that seems to not get a lot of attention: we need lots of different kinds of glue.

And yes, the article somewhat assumes that you either know what a connector is, or that you would read the linked Mary Shaw article to figure it out, as it is foundational for the field of software architecture. If you don't know what a connector is and don't care to find out, the article probably won't make a lot of sense to you.

And it's good for me to learn that apparently a lot of people don't know what a connector is, so I'll have to keep that in mind when communicating about this stuff. Thanks!

You could start with the main Wikipedia article on Software Arcitecture: https://en.wikipedia.org/wiki/Software_architecture

Or one of the others: https://en.wikipedia.org/wiki/Architecture_description_langu... https://en.wikipedia.org/wiki/Software_architecture_descript...

They cover the basics and have lots of references.

Or take a look at one of the books:

https://www.amazon.com/Software-Architecture-Perspectives-Em...

https://www.amazon.com/Software-Architecture-Foundations-The...

Here's a taxonomy of connectors, that should give you a quick overview:

https://isr.uci.edu/events/wesas2000/position-papers/mehta.p...

And of course there is the classic from 1994, published in IEEE Software: "Architectural Mismatch: Why Reuse Is So Hard"

https://www.ics.uci.edu/~taylor/ICS221/papers/ArchMismatch.p...

Turns out that one of the reasons Reuse is So Hard™ is that the connectors don't match.

With the followup 14 years later: "Architectural Mismatch: Why Reuse Is Still So Hard"