functional programming from scratch ja
1.0.0
Introduction to functional programming
Functional Programming From Scratch
Explaining functional programming from scratch, easy-to-understand and practical, from a wide range of perspectives! ~ From category theory to construction of FRP
?UNIT 1? OVERVIEW
https://zenn.dev/ken_okabe/books/functional-programming-from-scratch-1/
This is the beginning of the article.
Introducing the "outside" of functional programming
What is functional programming?
A wide range of topics including trends in the latest programming community, CPU and imperative programming, types in system languages, abstractions to structured programming, introductions to functional languages, relationships between terms and mathematics of object-oriented and functional programming, and philosophical aspects of the Unreal Engine (game engine) functional language Verse, SolidJS, and FRP.
Quick start and setup for TypeScript and F# development environments
https://zenn.dev/ken_okabe/books/functional-programming-from-scratch-1
Introducing the parts that form the skeleton for functional programming
First class functions, lambda expressions, higher order functions, binomial operational connectivity, function synthesis, Monoid
Without this, functional programming will not start, so understanding is necessary
https://zenn.dev/ken_okabe/books/functional-programming-from-scratch-2
Going into the underlying theory of functional programming quite deeply
We will try to provide easy-to-approach explanations, citing well-known papers aimed at readers who are particularly interested in the category theory, which is thought to be difficult.
Uninterested readers don't have to force themselves to understand everything, and they don't mind skipping it.
https://zenn.dev/ken_okabe/books/functional-programming-from-scratch-3
Includes a summary of THEORY's content and diagrams
Introducing Pipeline/List/Option/IO/Timeline/Async Monad
Implementing Monad, writing specific code using F# and TypeScript
Ultimately, we aim to build a minimalist FRP from scratch.
https://zenn.dev/ken_okabe/books/functional-programming-from-scratch-4
Sample code
https://zenn.dev/ken_okabe/books/functional-programming-from-scratch-5
For many programmers
moreover
Because it's a body of knowledge in the realm
And it is rare that such "awareness" is explained in detail.
What is functional programming?
Combining Pure fiunction
Pure functions must not have side effects
"Variable" is immutable
There is referential transparency (let's make sure)
In general, this is how new terms are listed, along with features and specs.
All of these are rather strict rules , and they are definitely requirements that programmers have never been aware of before, and they take away the freedom of coding, making them feel like they're tied up the programmer's hands and feet.
The true nature of each terminology is "What is it really?" In fact, readers are not explained properly until the very end.
Why does that have to be the concept? Why should we not be so restricted? ? Since the word "What is that really?" is not properly processed, it is often pushed along with new code, as well as "You can write such beautiful code" or "Did you feel any benefits?"
In fact, these novel terms and concepts have simple and solid similarities , and there are fundamentally concepts that you should be aware of, and you must first thoroughly explain them.
This is a great process of "awareness", and in fact, "awareness" is an intellectual exploration and adventure , and is something very interesting.
However, because the main goal of the commentary is to cover these listed features and link each one with a compelling explanation, it is a counterproductive attitude, so this most important "recognition" can be simply touched on, or completely ignored, as a bonus.
The person who explains the story may "really don't understand" (I think this is actually a lot of cases), or for those who know it but have already mastered it, it is a hassle to explain it kindly, so it is easy to just say "I said that, right?"
Of course, I don't know all the explanations, but I think most explanations have failed for this reason.
For some people, the world is Knows | Unknowns ~ "What I know" and "What I don't know"
Of course, there are overwhelmingly more "things you don't know" in the world, and it's impossible to just use the ratio of this graph, so the size of "things you know" is quite exaggerated for explanation.
The act of gradually expanding the area of Known's "knowing things" is the acquisition of knowledge , as if gradually replacing the area of Unknowns "knowing things"
For example, if we limit ourselves to the fields of programming and IT,
I want to learn the programming language Rust !
I want to be able to master Unreal Engine 5 !
I want to know more about Docker 's practical techniques!
It'll be like that
Rust, Unreal Engine 5, Docker and others are well-known "well-known" technologies that are famous in the programming and IT world.
The famous "well-known" here does not mean that everyone is well-known, well-known, or familiar with the technology, but rather that their name is well-known, well-known, or well-known.
In other words, whether you know the contents of the technology or not, there are unknown areas that are not even generally well- known, unknown, unknown areas that are not even well-known.
The "parts" of functional programming are not technology that is already well known to the public, such as Rust and Docker.
To learn functional programming
Unkown (not realised)
Known
The process = awareness is more important than anything
However, many of the functional programming explanations that are abundant in the streets attempt to explain new concepts necessary for functional programming, which are probably unknown to readers and are not even aware of, are already well-known and well-known.
This approach doesn't work
the result,
"Functional programming has the knowledge that it is pure functions."
"Pure functions are reference transparent"
"Pure functions do not cause side effects."
This is an incredible state where a completely incomprehensible explanation is in normal mode, where an unfamiliar concept is attempted to explain something unknown with another unfamiliar concept, or that involves assembling something in the air without a foundation.
Or, in cases where you instinctively realize that it's bad, you can start up a rather unusual example, and write the sample code to try to persuade the reader.
In general, these two options are the bottom line, and the true nature of the fundamental concept, "awareness," is not mentioned, and is never explained in a way that gives the reader the awareness of the important reader.
Explain another unknown word with words you don't know ←Not for discussion
Showing sample code for a singular case, reconstructing unknown concepts in the reader's mind ← There are rarely any geniuses who can do that
There is also a "matching technique between the two."
This is a pattern where you write code for Haskell, a functional language, and call it a "introduction to functional programming or a "sectoral theory."
Explaining a new concept of functional programming with unknown language specifications for Haskell.
We show sample code for the unknown language Haskell, which reconstructs the unknown concepts of functional programming and category theory in readers' minds.
This "matching the two" is of course awkward, but there is actually a harsh current situation in the programming world, where people who have come to understand it, at least who can write Haskell's code themselves, are reproducing the same approach they have had to understand.
Unknown: "unknown" knowledge,
Knows: "What I Know"
Unknowns "Things I don't know"
There are both
To clarify this, it is only a matter of conceptual classification diagrams, but it is also possible to rewrite the graphs.
First, the lower half is usually noticed, well known, known area of Known
Again, this approach works if the target you want to learn is already a well-known technology, Rust, Unreal Engine, or Docker.
However, this approach does not work in functional programming
First of all, it is very important to reaffirm that Known Knows is "aware of what you know."
For example, everyone should be "very familiar with" "addition", "subtraction", "multiplication", and "division" that they learned in the beginning in elementary school math.
This book actually starts at this level , and is designed in a more planned manner than the above policy.
Ultimately, learning means expanding your knowledge based on things you already know well.
What you already know is actually something like this when you look at functional programming.
Unkown Knows: "I don't realize what I know"
Known Knows: "I'm aware of what I know"
This is a process of "notification" and does not require new tasks to purchase new "things" from Unknowns up until now, making it very easy and smooth.
In other words, everyone who graduates from elementary school has "knowing very well," "addition," "subtraction," "multiplication," and "division," are solid knowledge for that person, and there is no need to redo the arithmetic drill.
This is a great intellectual asset that the person has already worked hard to acquire in elementary school.
However, how does this "algebraic structure" called "fourth arithmetics" lead to functional programming and concepts called Monads? Most people don't know, they're not known
Once you have "awareness", this hard-earned intellectual property called "aggregational arithmetics" can be used entirely as it is, into the knowledge of functional programming.
Therefore, it is outrageous to notify, inform, teach, or explain this "awareness"; it is either the negligence of the explainer or simply the explanation itself, but in reality, the latter case is very common.
This book is a thorough attempt with this task in mind.
If you "don't realize" this, then it's worth reading this book on its own.
The next step will focus on Unknown Known's "I don't realize what I know" and enter the area of Unknown Unknown Unknown's "I don't realize what I don't know."
This includes, for example, the theoretical physics perspective of [flow of time]
A well-known book that introduces "time handling" in functional programming from a theoretical physics perspective is "Structure and Interpretation of Computer Programs," which is often used as the abbreviation of SICP in the original title.
Structure and Interpretation of Computer Programs Hardcover – 2000/2/1 Gerald Jay Sussman (author), Julie Sussman (author), Harold Ableson (author), & 4 more
is
As for the theoretical physics perspective of "time handling" in functional programming , at least I don't remember seeing a single commentary, with the exception of SICP, so I think it is an important theme that is neglected by the public.
This book is a thorough attempt with this task in mind.
If you "don't realize" this, then it's worth reading this book on its own.
In writing this book, I developed and used my own WYSIWYG editor (an extension of VSCode) to efficiently paste a huge number of images and write Markdown.
MarkdownNote
