---------- Forwarded message ---------- From: Tim Daly <axiom...@gmail.com> Date: Mon, 15 Jul 2019 08:29:05 -0400 Subject: A Philosophy of Software Design To: software-design-b...@googlegroups.com, axiom...@gmail.com
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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org https://lists.nongnu.org/mailman/listinfo/axiom-developer