from [/unnamedcamp/functions created for big picture understanding and reuse](https://scrapbox.io/unnamedcamp/functions created for big picture understanding and reuse). image /unnamedcamp/nishio.icon My book “The Technology Behind Coding” p.25 Chapter 5 Functions - It’s not “writing in parts.” - > “Write functionally” is closer, but the problem is that it’s not a common metaphor at all - Not only was it not at all common, but it didn’t really get through to the people here, and /unnamedcamp/rashita.icon was so funny because he was so choked up! - I want to do Reverse Jenga reloading. - When a metaphor is born, it doesn’t have to be something that can be widely communicated to others, it’s better to develop it and reveal its structure first. - This type of functional concept was already used at least in EDSAC in 1949, and is a familiar concept to those who can read and write programming languages - > As a program grows, it becomes increasingly difficult to grasp the big picture. Also, you may be tempted to use often similar processes over and over again. - > Functions were created to solve this problem. By grouping semantically a piece of code together and giving it a name, it becomes easier to understand what it is doing. And by making the function usable by calling it from elsewhere, it can be reused. (Technology Supporting Coding, p. 56) - We can generalize the “program” part of this “as the program grows larger, it becomes harder to grasp the whole picture, and functions were created to solve this problem” to “described by a language”. - Functional “jump” and “back” are now possible with Scrapbox “links” and “backlink” and “Scroll to link position”.

I started writing it after titling it “Function Metaphor.”


This page is auto-translated from /nishio/全体像把握と再利用のために生まれた関数 using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. I’m very happy to spread my thought to non-Japanese readers.