Capt. Grace Hopper on Future Possibilities: Data, Hardware, Software, and People, 1982
I include links to a recently released lecture by Capt. Grace Hopper.
I include short notes on some of the points that jumped out at me.
Issues
Below is a brief list of issues vs. locations in the videos, that piqued my interest:
Part 1
20:58 - We’ve Always Done It This Way
47:10 - Systems Of Computers, Not Bigger Computers
48:00 - Get Out Of The Plane Of Paper
Part 2
0:00 - Security
8:42 - Bloatware
9:57 - 2FA
12:12 - Specialized Machines Are Faster Than General Purpose Machines
12:59 -We Have To Overcome The Concept Of Only One Computer
14:58 - Dependency Analysis
18:53 - Use independent modules
22:15 - Advocate the use of standard high level languages
27:19 - Buying Computer Time
34:49 - Management vs. Leadership
20:58 - We’ve Always Done It This Way
Don’t ever think, nor, say this.
I believe that we stick to using and designing “programming languages” due only to the fact that that’s the way IDEs were built in the 1950s1.
47:10 - Systems Of Computers, Not Bigger Computers
I, also, believe that we must think in terms of networks of computers
I believe that all of our current programming languages are designed for single computers.
I believe that all of our current programming languages are designed for single-threading, in spite of the fact that we supposedly have threading libraries, processes, etc. Programming languages are basically designed within the single-threaded paradigm. Augmenting these basic designs with band-aids like thread libraries is insufficient for the expression of truly asynchronous systems like GUIs, internet, robotics, gaming NPCs, blockchain, IoT, etc.
48:00 - Get Out Of The Plane Of Paper
Computers are a new medium. Computers are not just “better paper”.
We need to think in terms of layering.
0:00 - Security
Hopper was talking about security in 1982.
8:42 - Bloatware
Hopper was talking about bloatware in 1982.
In her mind, 160K constituted enormous overhead (bloatware). Today, though, we blithely speak about megabytes and terabytes (M and T, respectively).
Yes, images and other data need to be bigger, but, we have allowed ourselves the decadence of making shipped software be disproportionally bigger for no good reason.
We might use more software tools during development, which eat up more software memory, but, we don’t need to ship these bloatful methodologies and tools to end-users.
9:57 - 2FA
Hopper described Two Factor Authentication in 1982.
Hopper didn’t use the name 2FA. She called it something else.
12:12 - Specialized Machines Are Faster Than General Purpose Machines
One of the factors that causes bloat and inefficiency is over-generalization.
We need specialized languages and machines instead of general purpose languages.
OhmJS makes it possible to imagine building - quickly, cheaply - specialized languages.
12:59 -We Have To Overcome The Concept Of Only One Computer
Networks of many smaller machines, instead of bigger, faster machines.
Arduinos, rPis, etc.
Deprecate the concept of time-sharing (by default).
Deprecate the concept of memory-sharing (by default).
Multi-core is not the answer, we need to deal with truly distributed machines.
Robotics, internet, IoT, etc.
14:58 - Dependency Analysis
Hopper presents a mathematical analysis of the issue of dependencies.
The elephant in the room is dependency.
Half-measures like dependency-injection, DLLs, etc. are not enough. We need to examine and fundamentally re-think why our current methodologies produce dependencies, especially hidden dependencies.
I count at least three ways in which function-based programming languages (from C to Haskell and beyond) cause hidden dependencies2.
18:53 - Use independent modules
No module must ever access the interior of any other module.
N.B. that means that a function must not call another function in some other module.
Hopper talks about APIs, I favour asynchronous message-passing3.
22:15 - Advocate the use of standard high level languages
I advocate the use of many solution-specific notations. SCNs4.
On the surface, SCNs look like languages, like little nano-DSLs. This seems to oppose what Hopper says — if you think that SCNs are just little languages that are not very standardized.
Programmers have to spend brain-power and time, anyway, to understand (aka “reverse engineer”) how a solution is built, regardless of language used. Using an SCN should allow architects to express Design Intent (DI) in a way that should allow readers to traverse the learning curve more quickly.
Standardization is good. The best kind of standardization is normalization in aid of machine-readability/writability instead of human-readability.
In my mind, SCNs are something different from little, unstandardized languages. They are descriptions of DI (Design Intent) - something which currently requires reverse-engineering by maintainers and readers of the codebase. SCNs are a way to reduce the cost of such reverse-engineering.
I advocate that programmers write programs that write programs, using standardized programming languages as targets. Use existing programming languages as assembly languages5.
27:19 - Buying Computer Time
Computers are so cheap these days that we might forget that a single organization couldn’t afford to actually own a computer in the 1950s.
Organizations (companies, universities, students) had to buy computer time on a budget.
This mindset caused the invention of time-sharing. We no longer need time-sharing because of the economies of scale.
This mindset caused the over-emphasis on so-called “efficiency”, like inserting memory sharing into every program by default. We no longer need to emphasize such efficiencies because of the economies of scale. We might re-balance our goals to include development turn-around time. This raises a completely different set of considerations about “efficiencies”.
34:49 - Management vs. Leadership
Over-optimization of one factor over another led to an unbalanced emphasis on management whilst ignoring leadership.
By “1950” I mean “early computing” regardless of the actual dates.
TBD - discussion of these issues is currently spread throughout my blog. Consolidation of these issues into a single essay is under way.
Async message-passing is fundamentally different from the kind of synchronous message passing used in Smalltalk. Smalltalk performs (synchronous) method-calling, and does not perform (asynchronous) message-passing.
Solution Centric Notation
See, also, what Alan Kay says at around 31:50 of