Eric Normand - Grokking Simplicity: Taming complex software with functional thinking

Taming complex software with functional thinking

Eric Normand

Foreword by Guy Steele and Jessica Kerr

To comment go to liveBook

Manning

Shelter Island

For more information on this and other Manning titles go to

www.manning.com

For online information and ordering of these and other Manning books, please visit www.manning.com. The publisher offers discounts on these books when ordered in quantity.

For more information, please contact

Special Sales Department

Manning Publications Co.

20 Baldwin Road

PO Box 761

Shelter Island, NY 11964

Email: orders@manning.com

2021 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Mannings policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

ISBN: 9781617296208

Ive been writing programs for over 52 years now. I still find it exciting, because there are always new problems to tackle and new things to learn. My programming style has changed quite a bit over the decades, as I learn new algorithms, new programming languages, and new techniques for organizing my code.

When I first learned to program, in the 1960s, a well-accepted methodology was to draw a flowchart for the program before writing actual code. Every computation was represented by a rectangular box, every decision by a diamond, and every input/output operation by some other shape. The boxes were connected by arrows representing the flow of control from one box to another. Then writing the program was just a matter of writing code for the contents of each box in some order, and whenever an arrow pointed anywhere but the next box you were about to code, you would write a goto statement to indicate the necessary transfer of control. The problem was that flowcharts were two-dimensional but code was one-dimensional, so even if the structure of a flowchart looked nice and neat on paper, it could be hard to understand when written out as code. If you drew arrows on your code from each goto statement to its destination, the result often resembled a mound of spaghetti, and in those days we indeed talked about the difficulties of understanding and maintaining spaghetti code.

The first big influence on my programming style was the structured programming movement of the early 1970s. Looking back, I see two big ideas that came out of that community-wide discussion. Both of them are techniques for organizing control flow. The idea, which became famous, was that most control flow could be expressed in terms of a few simple patterns: sequential execution, multiway decisions such as if-then else and switch statements, and repetitive execution such as while loops and for loops. This was sometimes oversimplified into the slogan No goto statements!but the important thing was the patterns, and if you used the patterns consistently you found that you rarely needed to use an actual goto statement. The second idea, less famous but no less important, was that sequential statements could be grouped into blocks that should be properly nested, and that a non-local transfer of control may jump to the end of a block or out of a block (think of break and continue) but should not jump into a block from outside.

When I first learned the ideas of structured programming, I did not have access to a structured programming language. But I found myself writing my Fortran code a little more carefully, organizing it according to the principles of structured programming. I even found myself writing low-level assembly language code as if I were a compiler translating from a structured programming language into machine instructions. I found that this discipline made my programs easier to write and to maintain. Yes, I was still writing goto statements or branch instructions, but almost always according to one of the standard patterns, and that made it much easier to see what was going on.

In the bad old days when I wrote Fortran code, all the variables needed in a program were declared right up front, all together in one place, followed by the executable code. (The COBOL language rigidly formalized this specific organization; variables were declared in the data division of a program, which began with the actual words DATA DIVISION. This was then followed by the code, which always began with the actual words PROCEDURE DIVISION.) Every variable could be referred to from any point in the code. That made it hard to figure out, for any specific variable, exactly how it might be accessed and modified.

The second big influence that changed my programming style was object-oriented programming, which for me encompasses a combination and culmination of early ideas about objects, classes, information hiding, and abstract data types. Again, looking back I see two big ideas that came out of this grand synthesis, and both have to do with organizing access to data. The first idea is that variables should be encapsulated or contained in some way, to make it easier to see that only certain parts of the code can read or write them. This can be as simple as declaring local variables within a block rather than at the top of the program, or as elaborate as declaring variables within a class (or module) so that only methods of that class (or procedures within the module) can access them. Classes or modules can be used to guarantee that sets of variables obey certain consistency properties, because methods or procedures can be coded to ensure that if one variable is updated, then related variables are also appropriately updated. The second idea is inheritance, meaning that one can define a more complicated object by extending simpler ones, adding new variables and methods, and perhaps overriding existing methods. This second idea is made possible because of the first one.