[Axiom-developer] Fwd: A Philosophy of Software Design

[Tim Daly]

---------- Forwarded message ----------
From: Tim Daly <address@hidden>
Date: Mon, 15 Jul 2019 08:29:05 -0400
Subject: A Philosophy of Software Design
To: address@hidden, address@hidden

I'm watching your Google talk on youtube.

I've been programming for 50 years. I've done free software development
since 1996. I've written a LOT of code in over 60 languages. I have co-authored
4 commercial products. So I feel like I need to comment.

BORN or LEARN?

First, you ask if programming is something you are born with or something
you can learn. I think I could teach anyone who can follow a cooking recipe
to program. Learning to program is easy.

But programming is hard. It requires an inborn talent which is the ability to
cope with very high levels of frustration and ambiguity. I have spent a whole
week chasing a bug only to find that it is a compiler bug (4 times so far).
If you can't handle the ground-pounding frustration of failing software which
leads you to scream "WHY DOESN"T THIS WORK" and still continue then
you will never be a programmer.

I whole-heartedly agree with the value of code reviews for learning.

DEEP CLASSES

I tend to both agree and disagree with your deep class idea. I agree
that it is a useful idea for design. But I think it is a bad idea for coding.
Deep classes have a lot of complexity and are extremely specific to
the problem to be solved. Unfortunately, most of the lifetime of code
is post-development. Maintaining deep-class code is nearly impossible
because it is so task specific.

I prefer deeply layered code. See, for example, Sarker [0] where the
development is incremental and deeply layered. But the intellectual
steps are small and easily adapted. I find this form of development
easier to do, easier to teach, and easier to maintain. The most
productive programmers I know write small but working pieces of
code that makes incremental steps of improvement. Note that this
is NOT a tactical approach with ad hoc decisions, but small steps
toward the ultimate goals.

I took a course (at UCONN) where the prof gave us the spec of a
multitasking operating system. He gave us 10 weeks (in teams) to
develop it. It had to run on bare hardware (these days, an Arduino).
We had to process 100 "batch programs" to be run in minumum
time, assuming they block for I/O, etc. We developed a minimal
Read-Schedule-Process-Print loop and then enhanced it bit by bit.
You might consider that as an example project.

So while I agree that a Deep Class DESIGN is seems like a good
short term idea, I think it costs much more in the long term due to
the high maintain / modify costs.

Designers need to consider the full software lifecycle, not just the
initial implementation. You would not like an automobile that was
glued together and could not be fixed.

LOGIC and PROOF

In my later years I have watched the growth of proving
programs correct. I think designers need to write specifications
that can be proven. There is a HUGE growth in this field. See
Guy Steele [3] invited talk.

Designers need to be deeply educated in program proof and
typing. At UCONN I took a course that just gave us a pile of
research papers. We each were assigned 3 papers from the
pile. Each paper had to be presented to the class in a 20
minute talk. You were graded on your 3 presentations. We
not only learned the theory, we learned to read (and write)
research literature.

FOSS CONTRIBUTION

There is an alternative to wasting class time developing new
code to review.

You could structure a class for designers that took an
open source codebase from github for analysis. The whole
codebase would be reviewed throughout the semester and
each person who led the section could post fixes from the
code reviews to the open source site. Not only would they
see real design issues, they would learn to participate in
open source (and, incidently, how to maintain with source
code control).

LITERATE PROGRAMMING

On another track, I think you should teach literate programming.
All it takes is a simple latex macro and a trivial C[1] or Lisp[2]
program to extract code from a latex document. Future designers
out to follow the wisdom of Knuth and learn to write for humans
and, incidently, for computers.

Tim Daly
http://daly.axiom-developer.org
Carnegie Mellon University

[0] Sarker, Dipanwita and Waddell, Oscar and Dybvig, R. Kent
"A Nonpass Infrastructure for Compiler Education" (2004)
9th ACM SIGPLAN, pp 201-212

[1] http://daly.axiom-developer.org/tanglec.c

[2] http://daly.axiom-developer.org/tangle.lisp

[3] https://www.youtube.com/watch?v=dCuZkaaou0Q