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

[Tim Daly]

---------- Forwarded message ----------
From: John Ousterhout <address@hidden>
Date: Mon, 15 Jul 2019 10:52:23 -0700
Subject: Re: [software-design-book] A Philosophy of Software Design
To: Tim Daly <address@hidden>
Cc: software-design-book <address@hidden>

Hi Tim,

Thanks for the comments. Here are a few overall followups.

* You expressed a concern that deep classes might be harder to maintain and
modify. If this were the case, then deep classes would be a bad idea.
However, my experience is that deep classes make it *easier* to maintain
and modify software. Deep classes don't have to be more complicated than
shallow ones, and well-designed deep code is mostly non-task-specific (see
Chapter 6 of APOSD).

* You argued for proving correctness. I'm not opposed to this, but as of
today I believe it is too difficult and time-intensive to be practical in
most environments. In other words, if you're looking for the lowest-cost
way to achieve a given level of functionality, reliability, etc., you can
probably get there more cheaply using the more intuitive design approaches
I advocate than using formal verification. It feels like verification is
making gradual progress, so perhaps this situation will change in the
future. Also, for systems that require extremely high levels of
reliability, it may be that formal verification is the only way to get
there today.

* You suggested analyzing existing open source projects rather than writing
new code. There is certainly value in analyzing existing code, but in terms
of students learning how to design, it's crucial that they write code
themselves and get feedback on it. I would draw an analogy with writing.
Reading great books can be helpful in learning to write, but it is nowhere
near sufficient: you have to write stuff yourself, make mistakes, get
feedback, and fix the mistakes.

-John-

On Mon, Jul 15, 2019 at 5:29 AM Tim Daly <address@hidden> wrote:

> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "software-design-book" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address@hidden.
> To post to this group, send email to address@hidden
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/software-design-book/CAJn5L%3DKzPb4vHKfJFCfJjmNbtSjEJmnmFNUHB_JLx2iPKGxgUQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>