Hacker News Reader

Comment by bobbiechen | Hacker News Reader

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.

View on HN

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.

Yeah! I liked your blog post :)

We can all be 100x programmers, if we look at a broader timespan.

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 full KWIC index program specification can be found in the original 1971 paper (reference [8] in the 1972 paper): https://kilthub.cmu.edu/articles/journal_contribution/On_the...

The code therein uses the specification language described in https://dl.acm.org/doi/pdf/10.1145/355602.361309 (reference [3] in the 1972 paper). From there:

"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."

Thanks for the additional context. This is very interesting.

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.

You sort of have to go along with it if you want to estimate. The perfect plan and estimate only happens after the completion date.

There are so many unknown deps and unknown opportunities to optimise at the start of a project.

You find those out as you get in the weeds and as the ICs dream a 1am about their code and bring that idea in the next day.

... then came semantic search, and AI search, which just spits out the answer. I had not heard of KWIC either.

> 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.

> ok - "modules that hide design decisions" implies OOP

It doesn't. Implementation/design decision hiding also exists in procedural, functional and in other paradigms.

I didn't say "it demands OOP" I said "implies OOP" .. what you say is true also

> "modules that hide design decisions" implies OOP.

No; it is the other way around.

OOD/OOP implies information hiding/encapsulation.

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:

https://www.miasap.se/obnc/oberon-report.html

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.

Reply on news.ycombinator.com