“How do you write loops in Clojure? You don’t (mostly).”
What did we read about?
This is our second week reading Functional Programming for the Object Orientated Programmer.
Finish Chapter 1 – from 1.11 Vectors
After discussing vectors and how they differ to lists we finally discuss what we might consider the basic elements of a programming language: loops, conditionals and different methods for passing parameters. The chapter concludes with four pages of exercises.
In a language like Java we are usually introduced to the control flow first and the data structures come later. Here the reverse approach is taken: with a discussion on data structures coming first and the control flow following. The chapter is then disparaging about both conditionals and loops.
What stood out?
- In structured programming there are three basic constructs: sequence, selection and repetition. In functional programming sequence is achieved using lists. Conditionals are introduced with a reference to the Anti-IF Campaign and regarding repetition we are told that we dont write loops (mostly). This book is forcing us to think about programming in a new way.
- Rather than walking through the common functions the reader is given an exercise (5) with a list and told to think of a problem it could solve and then solve it. The reader is not being spoon fed.
If you read nothing else this week…
- Work through the exercises in section 1.18.
- If you’re new to Clojure then I would strongly recommend Clojure Made Simple. It will provide you with many essential tips that will help you stay sane. In section 2.8, for example, you’ll find out how to access the built in docs are referred to in exercise 5. Type “(doc take)” at the REPL and you’ll quickly discover that it “returns a lazy sequence of the first n items in coll,” That will definitely help you keep your sanity.
- Take a look at the Anti-IF Campaign.
- The classic book Thinking Forth has an excellent chapter on “Minimizing Control Structures:” “The use of control structures adds complexity to your code. The more complex your code is the harder it will be for you to read and maintain. The more parts a machine has, the greater are its chances of breaking down. And the harder it is for someone to fix.” The principles explained are good for any language.