Scala Functional Design & Programming - Chapter 1 (1)
Table of Contents
I bought "Scala Functional Design & Programming - A Comprehensive Guide to Functional Programming by Scalaz Contributors". I'll read it gradually and summarize the contents of each chapter.
This time, I'll cover Chapter 1.
The chapter introduces the purpose of the book and functional programming.
Foreword
In the foreword written by Mr. Odersky, the purpose of this book is explained.
- How to treat Scala as a purely functional programming language, which leads to beautiful code and understanding the essence of computation
- This book is not about Scala, but an introduction to functional programming
- The target audience is those who have some programming experience
- It's necessary to forget what you've learned so far and start from scratch
- Functional programming is not just about what you've done so far, but about separating responsibilities and making things immutable
The structure of the book seems to gradually increase in abstraction. There are also exercise problems, and the answers are available on Github.
Impressions
I thought it was a good point to consider functional programming as "what you've done so far". The explanation that "universal ideas that can be applied even without functional programming are more easily expressed with functional programming" is simple yet powerful.
Chapter 1
Chapter 1 provides an overview of functional programming, assuming pure functional programming.
The chapter uses the example of buying coffee with a credit card to demonstrate the benefits of pure functions by rewriting a program with side effects. The benefits mentioned are:
- Easy to test
- High modularity
By following the (sometimes strict) rules of functional programming, the structure of the program changes, and good code is produced. It's all about constraints and promises, or rather, the ability to think.
Next, the chapter explains pure functions.
- Input and output are 1:1 corresponding
- Referential transparency (an expression can always be replaced with its result)
As a result, it becomes easier to separate functions by concern, and the program becomes more modular.
Impressions
Constraints are extremely important in programming. Therefore, various methods have been tried to impose constraints. For example, Python's indentation, design by contract, static typing, and languages where everything is an object. Language designers are struggling to balance constraints and freedom. One proposal is purely functional languages, which impose a rather strict constraint of limiting side effects. This leads to various differences even when trying to achieve the same functionality. I'd like to master the benefits and drawbacks of this approach.
Continued: