Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
Stub a page for what has been called “the most important law”, “the only unbreakable law”, and a generalization of both Amdahl’s and Brooks’ laws. While this is important to software engineering, it’s applicable to any engineered system, and Conway 1968 uses all sorts of infrastructure to make their point alongside software-specific examples.
I have added a link to the Wikipedia page as evidence that this “law” is something people take seriously.
Also adjusted the wording in the anecdote/example, changing “passes” to “phases”, because: (1.) that’s what M. Conway actually wrote, and (2.) since with “passes” the example makes even less sense than with “phases”.
But this entry remains borderline off-topic here on the nlab, since this is not mathematics (nor philosophy, nor physics). Maybe it’s “business jargon”.
WP’s entry, like most coverage of Conway’s paper, is depressingly informal. Conway himself was very clear that his argument is supposed to bridge our informal experiences about distributed systems with formal constraints on the underlying graphs of components and designers. I’m not saying this to complain to Urs, but for anybody who wants to go edit WP to make their page better. I no longer edit WP but somebody else should do it because so much of the page is wrong or vague; every quoted variation is incorrect aside from the joke, every interpretation given is not-even-wrong, and it’s overall just a disappointing example of how papers fail to get read.
That said, I think that this is an example of applied category theory! It’s old, it uses graphs instead of categories, and it’s a short emotive paper; but it’s clearly in our wheelhouse. I think some community ought to recognize that there’s a homomorphism there, and sadly this recognition will not come from the software-engineering world as long as they aggressively reject maths. (Most software-engineering citations available to me are so unrigorous or wrong in their phrasing of the law that they are not suitable for encyclopedias.) Conway’s law makes a fine edge for topicality in the direction of systems theory, another page we really should have.
I apologize for using “passes” instead of “phases”. I misread the paper. When we finally get a page for compiler, we can explain that a pass/phase is a mini-compiler which is intended to be composed with other mini-compilers to form a production-ready compiler pipeline. (From now-deleted conversation with Andrej Bauer on (Theoretical?) Computer Science Stack Exchange, we lack a suitable category-theoretic definition of compiler, but they’re probably fancy functors.) For now, I would gladly add any desired examples of Conway’s law to the page; these software-engineering examples were merely at hand without writing another citation.
…I might as well add a fourth paragraph while I’m here. Let me work ES Raymond’s example claim, originally made in his dictionary and quoted on WP, to show why it’s wrong. He says that four groups of people will produce a four-pass compiler: four functors composed in sequence. But what Conway actually says is that they will produce a compiler whose composite behaviors are homomorphic to conversations between the groups. Raymond was imagining a linear pipeline, but there are many other possibilities; in particular, it’s quite common for a compiler to actually be a family of functors (a “compiler collection” with multiple “targets”), so that four groups of people could produce a four-target compiler. Compiler collections with multiple sources (multiple “input languages”) are also possible.
<p>Page numbers, punctuation, and an explanation of the chosen example including historical context and a link to WP. In 1968, a multi-phase compiler would have been the only natural possibility, but starting in the 1980s, a compiler could be much more flexible; see my rant above.</p>
<p>I need to take a break because my wires are crossed; I very much want to put the olog [a system] <-is part of- [a component] -is designed by-> [a person] at the top.</p>
<p><a href="https://ncatlab.org/nlab/revision/diff/Conway%27s+law/3">diff</a>, <a href="https://ncatlab.org/nlab/revision/Conway%27s+law/3">v3</a>, <a href="https://ncatlab.org/nlab/show/Conway%27s+law">current</a></p>
In 1968, a compiler phase would have been represented physically by a deck of punched cards; a five-phase compiler would be implemented as five decks of cards which could be concatenated into a single deck and run through a computer.
That explanation seems badly confused
Corbin, this is not about fixing some details or about bringing in “ologs”; I’d discourage you from pursuing this further on the nLab, this here is not the place for it.
What you have been doing (also in the entry “biology”, where I complained, too) is what I would liken to counting clouds:
You consider recognizing rigid mathematical structures – like graphs or graph homomorphisms (let alone functors) — in complex dynamical systems, where what one sees depends on when one looks, from which perspective, how one squints and what substances one took. It’s like seeing patterns in clouds.
Maybe that’s useful for somebody somewhere, but this is not content suitable for the nLab.
If you are unsure, one rule of thumb is: If the examples for an idea come in the form of anecdotes, then it’s not suitable material for the nLab.
1 to 6 of 6