This paper is 50+ years old and yet programmers are still making the same mistake of defining modules based on a flowchart, instead of modules that hide design decisions. I think that shows the youth (and perhaps lack of foundational training) of software engineering as a field.
But also the progress of the last 50 years: the KWIC index went from “a small system [that] could be produced by a good programmer within a week or two” to a tiny system that can be written in a couple lines using the standard library of Java (as I once saw a demo of).
Also: I recently wrote a blog post related to this paper and all of the initial test readers told me they had no idea what a KWIC index was and it needed more explanation. Instant full-text search really changes things.
Coincidentally, I reread the paper last weekend, and that side remark, about how the KWIC index would take a week or two to implement got my attention. So, I took the short specification given in the paper, and wrote it down in two dozen lines within a few minutes. I wrote it up as a blogpost just yesterday: https://holzer.online/articles/2025/03-05-kwic-quickly/
With a bit of cocktail napkin math that more than a factor of 100 faster than Parnas' estimate, just for having a higher language with a reasonable standard library at your hands.
Fred Brooks wrote in his 1986 "No silver bullet" essay that "There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity.". - but the compound effects of many years of many, many gradual improvements in developer tooling are really not bad.
The paper came out in 1972 which is the same year that C was invented. I don't think the paper mentioned what programming language was used, but since it has function calls with parameters, it's a higher level language than assembly.
"The notation is mainly ALGOL-like and requires
little explanation. To distinguish references to the
value of a function before calling the specified function
from references to its value after the call, we enclose
the old or previous value in single quotes (e.g. 'VAL').
If the value does not change, the quotes are optional.
Brackets ("[" and "]") are used to indicate the scope
of quantifiers. "=" is the relation "equals" and not
the assignment operator as in FORTRAN."
I see this mistake in project planning as well: I'm asked to scope how long it will take to complete module #1, then how long it will take to complete module #2, then module #3, etc. but in reality they all end up going hand-in-hand but depend on some common work that's "invisible" to the planners.
> defining modules based on a flowchart, instead of modules that hide design decisions
ok - "modules that hide design decisions" implies OOP. In thirty years, OOP got applied to build giant systems, some that went too far. There has been backlash against OOP for real reasons, perhaps also ignorant reasons too.
Flowchart coding is straight from "structured programming" an advance from the single line of execution ASM style that sometimes created unintuitive and needlessly-complicated execution flow. IMHO there is nothing wrong with structured programming, or actually OOP when used appropriately.
No, "modules that hide design decisions" implies modular programming. I think schools should teach modular programming before object-oriented programming. Then this confusion wouldn't arise so often. For a small modular programming language (which also supports OOP), have a look at Oberon:
As a hammer to be used on every single problem, OOP is unbearable. As a tool used when appropriate, OOP is delightful and I get very mad when languages think that they are above implementing it.
Considering the topic, I thought the PCR might be Platform Configuration Registers (it's actually polymerase chain reaction, for scientific lab machines).
I'm sympathetic - knowing something is different from putting it into practice, and sometimes other life things happen too.
I've been writing online for a few years now and for me, it comes in bursts. I recently started a new blog and publish it every two weeks - something that helped me was to write a lot when I was in the write mood, which gave me material to edit during off-weeks.
I remember reading interesting things recently about Arizona State University and the "New American University" model - https://nadia.xyz/asu is a nice summary
> If something is in memory it's under their control regardless of any magical memory encryption implementation providers claim to use.
That's not true. For example, to live-migrate Confidential VMs running on AMD SEV-SNP or Intel TDX, there is an extra step of negotiating encryption keys for live migration so that the hypervisor never sees plaintext memory pages of the guest VM. A few relevant docs:
Assuming one trusts this model and there are no implementation bugs or undocumented lawful intercept API's one would be stuck with Google Cloud or Azure. I assume AWS probably also has this. Who else?
Given it's used by the big providers one has to assume there are lawful intercept API's or some other mechanism to abide by lawful orders to monitor traffic given MitM will not work. eBPF perhaps to grab keys or intercept the HSM if not API's.
At the risk of possibly sounding crass, the practical solution is to simply never tell them of the decedent's passing.
Unless the matter of concern is a legal or financial one (eg: bank accounts, pensions, insurance, etc.), quite literally nothing and nobody else requires knowledge that the account holder passed away.
Never tell Valve that your gamer dad passed away and they will be none the wiser and noone will have any problems as you "inherit" his account and its associated games. You're not trying to defraud Social Security as a 150 year old, after all (...right?).
This might work for the first generation of steam users for now, but eventually they might require some kind of verification for old Steam accounts. Also remember that Steam is providing two things - a license for the games and a service to download them. I wouldn't expect a court to agree that a relatively low one-time fee obliges Steam to provide your or your heirs a service in perpetuity.
Why take the chance for games that you can get DRM-free and transfer independently from some live service.
Yes that is a claim they have made, but unless they show up in probate court to defend that position, they will do what the judge orders them to in a default judgement.
Hopefully your family won't have to test it for a long time then :-)
Please don't state something as a matter-of-fact if you don't know it to be true but just merely believe it to be true. Otherwise please link to an instance where a probate court has ordered it with a successful outcome.
It seems like a novel idea and I hope someone tries it and posts about it.
I agree, chat is only useful in scenarios that are 1) poorly defined, and 2) require a back-and-forth feedback loop. And even then, there might be better UX options.
But also the progress of the last 50 years: the KWIC index went from “a small system [that] could be produced by a good programmer within a week or two” to a tiny system that can be written in a couple lines using the standard library of Java (as I once saw a demo of).
Also: I recently wrote a blog post related to this paper and all of the initial test readers told me they had no idea what a KWIC index was and it needed more explanation. Instant full-text search really changes things.
reply