- Видео 100
- Просмотров 98 372
Sergei Winitzki
Германия
Добавлен 8 окт 2011
Advanced technical presentations about software engineering, in particular functional programming in Scala.
The Dhall language from the point of view of functional programming
The Dhall language is a templating language for producing YAML and JSON. However, for me Dhall is a good vehicle for learning advanced idioms of functional programming. Despite its simplicity, Dhall is designed as a purely functional language with a very powerful type system.
In this tutorial:
- Overview of Dhall's type system
- Examples of using types and values in the same way
- Product and co-product types, structural typing
- Loops with guaranteed termination
- Leibniz equality and "assert": a foundation of dependently-typed proof assistants
- How Dhall makes the hierarchy of type universes finite
- The difference between the "forall" and "lambda" symbols
Links:
Dhall language documentation dha...
In this tutorial:
- Overview of Dhall's type system
- Examples of using types and values in the same way
- Product and co-product types, structural typing
- Loops with guaranteed termination
- Leibniz equality and "assert": a foundation of dependently-typed proof assistants
- How Dhall makes the hierarchy of type universes finite
- The difference between the "forall" and "lambda" symbols
Links:
Dhall language documentation dha...
Просмотров: 63
Видео
Covariance, contravariance, and subtyping in functional programming
Просмотров 1295 месяцев назад
A tutorial about covariance, contravariance, and subtyping as used in functional programming (FP). - Subtyping in FP can be defined via conversion functions. P is a subtype of Q if there is a conversion function of type P → Q. (The compiler will insert the conversion function automatically.) - In FP there are 3 constructions of subtyping: co-product subtyping, product subtyping, and function su...
Functional programming and declarative programming
Просмотров 6188 месяцев назад
My thoughts about what "declarative programming" really is, and where functional programming stands in relation to declarative programming. Talk slides: github.com/winitzki/sofp/blob/master/talk_slides/fp_and_declarative.pdf Outline: Functional programming is interesting, but in a weird way - FP is (almost) engineering - Other programming paradigms are (almost) artisanship A definition of decla...
The Elm architecture from the functional programmer's point of view
Просмотров 323Год назад
The Elm architecture is a popular design pattern for GUI construction. I summarize the Elm architecture from the point of view of type theory and functional programming. I propose some type-motivated ways of making the Elm architecture modular via "combinators" for the GUI components. Disclaimer: This video is an improvised and not very polished presentation of some ideas I've been playing with...
Relational parametricity. Why the paper "Theorems for Free" is hard to understand
Просмотров 240Год назад
P. Wadler's 1991 paper "Theorems for free" (TFF) is the most often cited source on the applications of relational parametricity in functional programming. Yet, newcomers to this subject will find it difficult or impossible to understand the TFF paper in detail and to learn how to apply relational parametricity to practical examples. For illustration, here is a Stackoverflow question stackoverfl...
Relational parametricity. Lecture 7. Advanced applications (last lecture)
Просмотров 62Год назад
Proving "theorems for free" via relational parametricity. A tutorial using the syntax of Scala code, for advanced functional programmers. Complete proofs with no jargon and no unnecessary abstractions (e.g., no category theory). All new definitions are motivated and illustrated by examples. Long and difficult, yet boring explanations given in excruciating detail. Lecture 7 Some advanced applica...
Relational parametricity. Lecture 6. The wedge law and the naturality laws
Просмотров 22Год назад
Proving "theorems for free" via relational parametricity. A tutorial using the syntax of Scala code, for advanced functional programmers. Complete proofs with no jargon and no unnecessary abstractions (e.g., no category theory). All new definitions are motivated and illustrated by examples. Long and difficult, yet boring explanations given in excruciating detail. Lecture 6 The wedge law is a ge...
Relational parametricity. Lecture 5. Proof of the relational parametricity law
Просмотров 36Год назад
Proving "theorems for free" via relational parametricity. A tutorial using the syntax of Scala code, for advanced functional programmers. Complete proofs with no jargon and no unnecessary abstractions (e.g., no category theory). All new definitions are motivated and illustrated by examples. Long and difficult, yet boring explanations given in excruciating detail. Lecture 5 Formulating the relat...
Relational parametricity. Lecture 3. Motivation and definition for relations. Relation combinators
Просмотров 23Год назад
Proving "theorems for free" via relational parametricity. A tutorial using the syntax of Scala code, for advanced functional programmers. Complete proofs with no jargon and no unnecessary abstractions (e.g., no category theory). All new definitions are motivated and illustrated by examples. Long and difficult, yet boring explanations given in excruciating detail. Lecture 3 Motivating the relati...
Relational parametricity. Lecture 2, part 1. Defining fmap and cmap
Просмотров 76Год назад
Proving "theorems for free" via relational parametricity. A tutorial using the syntax of Scala code, for advanced functional programmers. Complete proofs with no jargon and no unnecessary abstractions (e.g., no category theory). All new definitions are motivated and illustrated by examples. Long and difficult, yet boring explanations given in excruciating detail. Lecture 2, part 1 How to define...
Relational parametricity. Lecture 2, part 2. Proofs of functor laws
Просмотров 32Год назад
Proving "theorems for free" via relational parametricity. A tutorial using the syntax of Scala code, for advanced functional programmers. Complete proofs with no jargon and no unnecessary abstractions (e.g., no category theory). All new definitions are motivated and illustrated by examples. Long and difficult, yet boring explanations given in excruciating detail. Lecture 2, part 2 How to prove ...
Relational parametricity. Lecture 1. Motivation and applications. Yoneda identities
Просмотров 326Год назад
Proving "theorems for free" via relational parametricity. A tutorial using the syntax of Scala code, for advanced functional programmers. Complete proofs with no jargon and no unnecessary abstractions (e.g., no category theory). All new definitions are motivated and illustrated by examples. Long and difficult, yet boring explanations given in excruciating detail. Lecture 1 An overview of practi...
Relational parametricity. Lecture 4. Relational lifting operations
Просмотров 33Год назад
Proving "theorems for free" via relational parametricity. A tutorial using the syntax of Scala code, for advanced functional programmers. Complete proofs with no jargon and no unnecessary abstractions (e.g., no category theory). All new definitions are motivated and illustrated by examples. Long and difficult, yet boring explanations given in excruciating detail. Lecture 4 What I call "relation...
Editing my book using LyX
Просмотров 1,6 тыс.2 года назад
This is a short video showing how I use the LyX editor for my book "The Science of Functional Programming". LyX has been in development as free software since 1995 and produces documents via LaTeX and can support equations, tables, diagrams, figures, and code snippets, as well as navigation, table of contents, index, hyperlinks and much more. See www.lyx.org for more information about LyX. My b...
"Science of Functional Programming", Chapter 14. Monad transformers. Part 2 of 2
Просмотров 2153 года назад
Functional programming in the mathematical spirit. Long and difficult, yet boring explanations given in excruciating detail. This is an overview of Chapter 14 of the book "Science of Functional Programming". Chapter 14 covers monad transformers. The book is in progress. Its full text is available at github.com/winitzki/sofp
"Science of Functional Programming", chapter 14. Monad transformers. Part 1 of 2
Просмотров 1993 года назад
"Science of Functional Programming", chapter 14. Monad transformers. Part 1 of 2
Relational parametricity explained. The science behind "theorems for free" (obsolete)
Просмотров 3303 года назад
Relational parametricity explained. The science behind "theorems for free" (obsolete)
What I learned about functional programming while writing a book about it (extended version)
Просмотров 1,4 тыс.3 года назад
What I learned about functional programming while writing a book about it (extended version)
Functional programming, hors série. Equivalence of typeclass methods under laws
Просмотров 1653 года назад
Functional programming, hors série. Equivalence of typeclass methods under laws
Explaining "theorems for free" and parametricity, for practicing programmers. With code in Scala
Просмотров 1,8 тыс.4 года назад
Explaining "theorems for free" and parametricity, for practicing programmers. With code in Scala
Explaining the Curry-Howard correspondence for practical programmers. With code examples in Scala
Просмотров 1,3 тыс.4 года назад
Explaining the Curry-Howard correspondence for practical programmers. With code examples in Scala
What did functional programming ever do for us (software engineers)? A tutorial with code in Scala
Просмотров 1,1 тыс.4 года назад
What did functional programming ever do for us (software engineers)? A tutorial with code in Scala
Properties of natural transformations (Science of functional programming, hors série)
Просмотров 2674 года назад
Properties of natural transformations (Science of functional programming, hors série)
Parametricity properties of purely functional code (Science of Functional Programming, Appendix D)
Просмотров 3344 года назад
Parametricity properties of purely functional code (Science of Functional Programming, Appendix D)
What did category theory ever do for us (functional programmers)?
Просмотров 3,3 тыс.5 лет назад
What did category theory ever do for us (functional programmers)?
Reasoning about types and code: Talk at SF Scala - October 17, 2019
Просмотров 2575 лет назад
Reasoning about types and code: Talk at SF Scala - October 17, 2019
Functional programming. Reasoning about types and code (hors série)
Просмотров 8835 лет назад
Functional programming. Reasoning about types and code (hors série)
Functional programming, chapter 11. Monad transformers (slides 1 to 11 only)
Просмотров 5485 лет назад
Functional programming, chapter 11. Monad transformers (slides 1 to 11 only)
Summary for: Functional programming, Chapter 10
Просмотров 736 лет назад
Summary for: Functional programming, Chapter 10
(Part 4 of 4) Functional programming, chapter 10. Free type constructions
Просмотров 1066 лет назад
(Part 4 of 4) Functional programming, chapter 10. Free type constructions
Your definition of declarative is really just saying "being at the right level of abstraction for the problem at hand". Which I agree is the most important thing in programming but declarative isn't exactly the same thing... You're describing a DSL which isn't always worth the trouble
I couldn't agree more. The disdain software "engineers" have for math is unreal. And as you said, they like to say everything is just opinion. This industry needs to change.
Phil Dunphy?
I like your work. You provide a unique point of view and you dig into details. Yet on the second example of slide 8 at about 25:00 I disagree. I would read 10 and 20 as labels (I was not trained on Fortran). Also regarding zero I guess it is 1 as in the formula minus one.
That's the point though, you have to do mental translations and get through cruft. All translations should be done by the computer, not you
0:26 4:00 print
valiant effort
Start watching at ruclips.net/video/VPgOqZNlgK0/видео.html because there were technical issues before 3rd minute.
I don't know if it gets a mention, but I was kind of intrigued to realise that in Rust, lifetimes have a subtyping relationship.
I was under impression that Rust lifetimes are not really first-class values. You cannot assign them to variables or store in arrays, can you? But they can of course have something like a subtyping relationship, if you are able to apply a function to a variable with a different lifetime than declared in the function's type signature.
This was a very informative talk. I really like that it gave a clear definition of the term "declarative", that I find is often defined so abstractly, that it loses any meaning. "you tell the computer what you want done, not how to do it" is nice, but almost meaningless to someone new to programming. Kudos for that! One slight mistake I'd like to point out it's that at 45:50, in JavaScript, much like in Java, functions can't really return references, at least not overwritable ones. f() would always produce a 0, regardless of what other modules do. I like to think about the `=` operator as "rebinding". `x = y` binds a different object to the name `x`, not modifying the previous one. `x.y = z` binds whatever's in `x`'s property `y` to an object `z`, effectively modifying `x`, but once again leaving whatever `x`'s `y` was before untouched. The example is good enough for the demonstration of a principle, just this particular case is not true and some might dismiss the whole idea because of that. Thanks for a very interesting point of view!
Thank you. Maybe modern JavaScript has fixed this issue. But I have spent about half an hour together with a colleague at my previous job (this was back in 2014) chasing a bug that consisted in `x` being modified by 3rd party library code in exactly the way I demonstrated.
@@sergeiwinitzki3439 hmm, I believe JavaScript has always had these semantics, but I might have not explained myself properly. `x = f(); x.y = 5` *will* modify `x`, and therefore the result of all subsequent calls of `f`, but it needs to be a property of `x`, not the object itself.
A better definition of declarative is "you say what things are". x := 3 means that x IS 3, just like the decade of math everybody has to learn but then somehow forgets about once they learn to program
Nice talk! I have some thoughts... Under the functional paradigm, programs are made of declarations (x :: type) and definitions (x = term). Declarative programming, in my mind, is "executable specification" where you only have to write the required type, and the machine automatically checks the proposition (i.e. Propositions as Types), implements an algorithm, finds an element of a set, etc. A DSL can offer 100% automation over its domain of specifications. Implementing a spec in general is on a best-effort basis. When I was investigating Category Theory, I found that 90% of the code I wrote was at the level of types. Usually, an implementation was constrained to be unique, so that code (that I wrote manually) could be safely ignored once it compiled; all the relevant information was in the declaration. In my day job, things are rarely so clean, but the principle is still useful. And I can put that extra effort where it matters, for reliability, etc.
In this blog post blog.sigfpe.com/2006/11/yoneda-lemma.html?m=1 there is the polymorphic function type "forall b . (a -> b) -> b". The point of the blogpost was to conclude that the only parametric program with that type would be to have some element a0 of type 'a' inside the program that the program will feed into any function a->b given to it (to produce an output of type b). Would the hardcoded type 'a' element a0 be a bound variable, number 2 in the 9 allowed constructions you discuss @30:48? Seems a bit counter to the point you make @29:40, with "no hard-coded values of specific types".
Great material but I have a question. Have you done any more general talk on CPS, usage scenarios, why it is gaining popularity, etc. Would be good to get to know the roots, if you know what I mean. Thanks again for the video.
No, I have no other talks specifically about CPS. In my view, CPS is a trick with narrow applicability. Some compilers use CPS but it is not easy; one example where CPS does not work well is Groovy (a not very well polished language and its usability is not great, you get errors about CPS but it is not about your code).
RIP functional reactive programming
Computer science has made HUGE progress. I have a not-so-recent video in my channel of Rachmaninoff singing dame da ne and it's not the same in terms of quality of processing of facial expressions.
Disjunctive type in Python: dictionary = { 'val': function, num: function_num, 'val2': lambda c: function_or_whatever } x = dictionary.get(v)(c) def function(c): return stuff(c) Use map to run every function in the dict if there's a key. 🤣😂 Great video by the way. The comment below is much appreciated too where immutability isn't the goal. Immutability is lacking due to functional programmers being lacking, and the more functional programmers we see programming, the better tools we get for those purposes. Python dicts used to be garbage, but now they're pretty amazing because so many people were using them and the demand was there.
Nice job
Very Great, detailed video! Learned a lot. Thanks!
I've tried LyX, but every time I do it feels as though something is missing. Plus the documentation is not very clear (last time I checked). Another good option might be TeXmacs. Like LyX, it's a frontend WYSIWYG editor, but it does not use LaTeX as a backend. It's written entirely from scratch. Haven't spent that much time with it, but it looks promising.
This is very different from other YT videos on Category Theory. I appreciate the viewpoint. Today the book is on chapter 13 (last). Now off to watch the other video for software engineers. 🙂
Thanks for this series of videos and for your work on the book. I watched everything and was able to follow it at a high level. Looking forward to when the book will be complete.
Thank you! Please let me know if something is unclear anywhere in my explanations.
This video is correct except that it creates an impression that dinaturality is the most general form of laws that follow from parametricity. But this is not true. There are some complicated cases where parametricity gives a stronger law than dinaturality. But those cases are rare.
This video is correct except for the last part - "Proof outline for parametricity theorem via dinatural transformations (without relations)". The parametricity theorem cannot be proved via dinatural transformations because the parametricity theorem gives a law that is (in some cases) stronger than dinaturality. Although dinaturality is sufficient in most cases in practice, there are a few cases where dinaturality does not give enough information to prove the parametricity properties. One prominent case is the Church encoding of recursive types.
This video is obsolete. Some of the details of the proof are incorrect. In particular, it is not possible to use relational composition for defining rmap in inductive steps 6 and 7. A correct proof does not use relational composition.
I'm learning programming, and am interested in curry howard theorem and found your video. Checked out your channel and loved this video, Scriabin is my favorite composer ever and this video makes him feel even closer to me.
Reflection like a dog
Nice video!
In an exercise in sofp to infer types for p → q → p(t → t(q)), I wrote the below: def func[Q,A,B](p: ((Q => A) => A) => B)(q: Q): B = p((t: Q => A) => t(q)) Another way, def func[Q,A,B]: (((Q => A) => A) => B) => Q => B = p => q => p((t: Q => A) => t(q)) Both compile but how can I know that it is correct?
Was also able to write for this other one. Very challenging indeed but love it. p → q → q(x → x(p(q))) def func2[A,B,T](p: (((A => B) => B) => T) => A)(q: ((A => B) => B) => T): T = q((x: A => B) => x(p(q))) But the question remains on how to test it? Love your work.
@@re1konn Good job! The Scala compiler can verify that your types are correct, and this is already most of the answer to your question. But there is no way of checking with Scala whether your answer actually gives the most general possible type signature, because the Scala compiler does not perform full type inference. But the Haskell and OCaml compilers do. Here is an example in Haskell. The syntax is a bit different but it's exactly the same type signature. You can sign up at repl.it to get a Haskell REPL and try it out.
@@re1konn In the Haskell REPL: let func = \p -> \q -> p( \t -> t(q)) :t func func :: (((t1 -> t2) -> t2) -> t3) -> t1 -> t3 let func2 = \p -> \q -> q( \x -> x(p(q))) :t func2 func2 :: ((((t1 -> t2) -> t2) -> t3) -> t1) -> (((t1 -> t2) -> t2) -> t3) -> t3 The Haskell compiler has the full inference algorithm for functions of this sort. It automatically introduces type variables t1, t2, t3, etc. as necessary.
@@sergeiwinitzki3439 sure I will check the repl out
At 2:49:01 , I was trying question 4. I was able to write these three things (regarding OptEither and map, fmap signatures)- 1. type OptEither[A, B] = Unit | A | B 2. map: OptEither[A, B] => (B => C) => OptEither[A, C] 2. flatMap: OptEither[A, B] => (B => OptEither[A, C]) => OptEither[A, C] But, I was having trouble implementing it. This is what I am trying to do - sealed trait OptEither[A, B] final case class Aclass(a: A) extends OptEither[A, B] final case class Bclass(b: B) extends OptEither[A, B] final case object U extends OptEither[A, B] the above doesn't even compile. What is wrong with this? P.S. - Thanks a lot :D I am enjoying these lectures.
You cannot write `case object U extends OptEither[A, B]` because `U` has no type parameters. The easiest fix is to write `case class U[A, B]() extends OptEither[A, B]`
@@sergeiwinitzki3439 After reading the disjunctive part in sofp, I came up with this and now it compiles. I should have used "Nothing". { | sealed trait OptEither[A,B] | final case class AClass[A](a: A) extends OptEither[A, Nothing] | final case class BClass[B](b: B) extends OptEither[Nothing, B] | case object MyUnit extends OptEither[Nothing, Nothing] | }
Hi Sergei. I just got the pdf version of the book. On a quick glance of the chapters, I could find notations that seemed very new. I am presuming that they are introduced as I go. I am really excited for this book, anyways.
Yes, the book introduces new notations, compared with the videos. They are completely analogous to old notations, but I found the new notations easier to use.
For question 2 at 6:02, I found that the sequence never reaches 1 since takeWhile was taking a lot of time. Is the observation correct?
Maybe. You can use the function that determines whether the sequence repeats itself. (Example 7 at ruclips.net/video/qrvmxdBletE/видео.html ) Then you can stop the sequence at the point where it repeats itself. If you don't see 1 by that time, you will certainly never see 1.
@@sergeiwinitzki3439 you are the best. Thanks
def collatz(n: Int): LazyList[Int] = LazyList.iterate(n){ x => if x % 2 == 0 then x / 2 else 3 * x + 1} (1 to 1000).map(x => collatz(x).takeWhile(_ != 1).toList) It will always terminate, that is the Collatz conjecture and in sofp, it's mentioned in the footnotes. Maybe I hadn't implemented it correct that time around. It terminated quickly for all numbers from 1 to 1000.
@@re1konn I think you computed the right thing. Your code computes the Collatz sequence starting with n. It computes only one sequence. Then you repeat this for the first 1000 numbers. It always terminates. If you want to see the behavior of the sequences, you can modify the code so that it computes the total number of elements before the sequence reaches 1. Maybe then you will see that sometimes the Collatz sequence can become long.
(1 to 1000).map(x => collatz(x).takeWhile(_ != 1).toList.size).max val res7: Int = 178 Indeed :)
even after using .toMap at 19:26 at line 7, why did Scala not recognize that it is a map and we had to explicitly put in the type Map[Int, Boolean]?
Actually, at least with Scala 2.13, it is not necessary to write the type there. You can write `val m = s.zip(t).toMap` and it works correctly. In some cases .toMap does not know what types to use and we need to write a type annotation, but in most cases it works without type annotations.
@@sergeiwinitzki3439 Thanks a lot :)
This is an excellent tutorial. Thank You.
Thanks for sharing!! I loved your fp videos
This is not a nice tutorial, this is a GREAT sbt introduction with a ground-up and deep-dive approach and truth-telling information. Compared to tons of sbt tutorials out there which spent a great deal focus on glorifying sbt, your session is the fastest path for a sbt beginner to become a sbt pro, a bit exaggerated :), but thanks a lot!
Thank you!
Now I know how annoying I am with my mechanical keyboard. Sorry everyone! - Joking aside, thanks for the presentation. There is very little out there for Mercury lang.
Hello I am currently reading Functional Programming in Scala, After which i think i am going to pick this book up. Could you tell me how difficult is the meterial in here compared to the above mentioned book. And what practical benifits you can expect as a everyday average developer to gain after rading this book
My book will be more difficult than "Functional programming in Scala", except for the first few chapters that are easier in my book. The book "Functional programming in Scala" explains some of the same material as my book (functors, monads, applicative functors, etc.). But "Functional programming in Scala" explains it at a simpler level and does not give any mathematical background. For example, "Functional programming in Scala" describes the laws of monads and proves one of the laws only for one, very simple monad ("Option"). For example, they do not prove that the State monad is correct. My book proves the monad laws for all known monads and also enumerates the ways of constructing all possible monads. To do this, my book develops certain mathematical techniques and also shows that the laws can be simplified in various ways. This makes the proofs easier - but the proofs are still quite long. If you are not interested in the mathematical justification and proof of why the monads such as the State monad is correct, you do not need to read those sections in my book. You will benefit from reading my book if you want to understand in more depth why functional programming is the way it is. The reason is that there is a mathematical theory showing that there must be functors, monads, applicatives and so on, with certain specific properties and laws. If you want to design or use more complicated libraries, like cats, if you need to use applicative functors, monads and monad transformers in your code, if you want to know how to implement correctly the functions map, flatMap, filter, zip for your own data structures - then you will benefit from reading my book. Another example is that "Functional programming in Scala" shows in Chapter 2 how you can implement a function they call "partial1". They say: "How would we go about implementing this higher-order function? It turns out that there’s only one implementation that compiles, and it follows logically from the type signature. It’s like a fun little logic puzzle." But they do not explain why there is only one implementation and how to solve that puzzle. My book shows the mathematical theory that solves this kind of puzzles and gives an algorithm for solving them. I implemented a library based on that algorithm. If you are interested how this works, you will benefit from reading my book.
Minor correction: fromDigits(non-tail-recursive implementation) in the tutorial actually creates the number in reverse.
Very informative video. Thanks a lot
Great talk. Looking forward to reading the book!
Good video
Thanks for this! Are you planning on doing one for what you learned writing your linear algebra book?
Thank you. I already forgot most of what I was reading while I was writing the linear algebra book. Not sure I will have any time to go back to that material. If I were to write that book now, it would have been quite a bit different - using a less academic language and more examples of computation. But I have no time now.
Thank you very much for this, as you put it, "Long and difficult, yet boring explanations given in excruciating detail."
I am writing this up as a book. github.com/winitzki/sofp The book is going to be long and difficult, yet boring to read. There will be lots of details.
Excellent, I would mention immutability.
Yes, funny how this never came up. Perhaps, I don't actually feel that immutability is more important than other FP features. Most FP languages in use today will have mutability in the code bases (at least in a few places) and yet programmers can reap almost all the benefits of FP. I think once programmers start using features such as iteration without loops or disjunctive types, immutability will just become natural in more contexts than before.
Было бы лучше показывать многопоточность сначала на callback-ах с разными задачами, например, вычислительными, потом использовать результаты в общем потоке, а уже потом обобщать на heavy-load параллелизме. Но в принципе полезное видео.
that's a gem. Thank you!
Studied partially the book and excellent explanation about functional programming concepts using Maths. How beautifully math expressions were mapped with Scala syntax, that absolutely makes sense.
Thank you! Please feel free to make comments or suggestions about the book.
@Sergei Winitzki There are 2 request about the book: 1. I have finished first chapter, and I found lot of important points hidden inside the text. e.g; For each bound variable, we need to create a nameless function whose argument is that variable, e.g., k=>p(k) or k=>f(k) for the examples just shown. Also there are many !!! What if all these important notes or rules are mentioned in separate box with each section under discussion. 2. Also use of images or graph, explains/recalls a big concept in a birds eye view, just for the sake of reference "Grokking Functional Programming" has used flow diagrams for map, flatMap, for comprehension, zip etc. Rest of it, it is masterpiece Thanks !!! www.manning.com/books/grokking-functional-programming?query=Grokking%20Functional
@@imranfp To 1. It's not easy for me to decide what should be in a separate box. There is too much material even for a "summary". Maybe you would like to write a summary for each chapter where you can say what were the most important points? Feel free to make a github issue and post the text. To 2. I show many "type diagrams" later on in the book. But I don't find it very useful to have diagrams such as those in "Grokking FP". A programmer knows that a function takes arguments and returns values. There are lots of books that explain in a very simple way how to use Scala for practical tasks; my book focuses on a more theoretical view.
@@sergeiwinitzki3439 would you be kind to tell, is there any git repository with source code of examples mentioned in book. github.com/winitzki/sofp It only contains pdf source code.
@@imranfp There is a git repository with some source code, but I have not yet made a full collection of examples from the book into a consistent repository with passing tests. For now, you can take a look at this: github.com/winitzki/scala-examples
Brilliant!
Hi, I am a Software Developer using Scala primarily in my job. But I want to learn Functional Programming from the basics, understanding why and how. I understand things on a surface level (using Options instead of null because of better semantics, avoiding NPE, etc.) but feel like I lack proper understanding. How do you suggest one to start the journey of learn FP? Is the book already released? If not, what are some reading/video materials once can go through to understand FP from the basics.
Yes, the book should be helpful. Please try reading it and let me know!
Sublimely thorough, as usual. I can't wait for the book to come out and I hope there will be a hard cover edition because I will be spending so much time poring over it. I am so glad that someone with your curiosity, vision, courage, ambition, rigour, stamina and relentlessness took on the subject of functional programming, doing so much hard work that will ease the burden of the hopefully many developers who want to know what there is to be known about functional programming, and for the practically minded, which topics are more profitable than others. I hope you don't mind if I take the liberty to attempt my own small contribution towards helping viewers understand natural transformations, by linking to the following short slide deck that I made on the subject: www.slideshare.net/pjschwarz/natural-transformations
Thank you. Please feel free to use any material from the book or any of my slides as well. All of that is released under an open-source license. Also please let me know if you have any further comments or suggestions for the book.
@@sergeiwinitzki3439 that is very kind of you and releasing all that under an open-source license is innovative and philanthropic. I don't have any further comments and suggestions right now, but I will let you know if and when I do. By the way, is trampolining actually covered in the book. I ask because in github.com/winitzki/sofp/blob/d841d65f92f384bd5c01e1cf0d322acb16ac463d/sofp-src/sofp-induction.tex#L2653-L2655 it says they are out of scope for that particular chapter.
Actually I don't think that I will cover trampolines in the current version of the book. Trampolines are already adequately explained in other places, e.g. in the "red book" (Chuisano & Bjarnason) and online tutorials. At the same time I feel that trampolines are just a narrowly-used trick that does not have enough mathematical depth; there is nothing we can prove rigorously or derive about trampolines (laws, equations, general properties). Maybe I'm mistaken? If time permits I'll take a look at trampolines again, but right now that's what I think.
@@sergeiwinitzki3439 That all makes perfect sense - I asked only because I have been working on some slide decks that cover trampolining (e.g. www.slideshare.net/pjschwarz/game-of-life-polyglot-fp-haskell-scala-unison-part-3) and every time I remembered that passage in your book I thought I ought to find out if the subject was actually covered in it. Thanks.
Very good presentation! One pragmatic technique I'd like to mention for people who are implementing an instance of one of these patterns and want to see whether the laws hold for their datatype, is to use property-checking. It will not prove 100% correctness but it will give you the next best thing which is pragmatically speaking arguably a better use of your time/effort.
Property checking is of course a good test, and modern libraries can provide easy-to-use property checkers for functor, monad, etc. laws. However, there are two significant reasons why I believe it is useful to learn the techniques of symbolic proof for the laws. First, you need to be able to implement the typeclasses somehow; the property checker will not help you until your code is ready to be checked. To write the correct implementation, you need to study the structure of types and the available constructions, knowing how to use them so that the laws are satisfied. Second, programmers need intuition about why the law holds, and that intuition can only come from knowing how to prove the law symbolically by hand. Suppose you implemented your code and ran your property checker but got a test failure. So, you know that there is some kind of error in your code; but where is it and how to fix it? You can write correct code only if you understand the laws and can interpret failure to satisfy a law.
@@sergeiwinitzki3439 I fully agree :-).