---------- Forwarded message ---------- From: John Ousterhout <ous...@cs.stanford.edu> Date: Mon, 15 Jul 2019 10:52:23 -0700 Subject: Re: [software-design-book] A Philosophy of Software Design To: Tim Daly <axiom...@gmail.com> Cc: software-design-book <software-design-b...@googlegroups.com>
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 <axiom...@gmail.com> 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 software-design-book+unsubscr...@googlegroups.com. > To post to this group, send email to software-design-b...@googlegroups.com > . > 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. > _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org https://lists.nongnu.org/mailman/listinfo/axiom-developer