Sergei Winitzki
Sergei Winitzki
  • Видео 100
  • Просмотров 98 372
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...
Просмотров: 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

Комментарии

  • @AndreiGeorgescu-j9p
    @AndreiGeorgescu-j9p 26 дней назад

    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

  • @AndreiGeorgescu-j9p
    @AndreiGeorgescu-j9p 26 дней назад

    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.

  • @ArduousNature
    @ArduousNature Месяц назад

    Phil Dunphy?

  • @AlexToth-x3b
    @AlexToth-x3b Месяц назад

    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.

    • @AndreiGeorgescu-j9p
      @AndreiGeorgescu-j9p 26 дней назад

      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

  • @SphereofTime
    @SphereofTime 2 месяца назад

    0:26 4:00 print

  • @bludika
    @bludika 4 месяца назад

    valiant effort

  • @sergeiwinitzki3439
    @sergeiwinitzki3439 5 месяцев назад

    Start watching at ruclips.net/video/VPgOqZNlgK0/видео.html because there were technical issues before 3rd minute.

  • @pmcgee003
    @pmcgee003 5 месяцев назад

    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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 5 месяцев назад

      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.

  • @georgecoldwell6792
    @georgecoldwell6792 8 месяцев назад

    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!

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 8 месяцев назад

      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.

    • @georgecoldwell6792
      @georgecoldwell6792 8 месяцев назад

      @@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.

    • @AndreiGeorgescu-j9p
      @AndreiGeorgescu-j9p 26 дней назад

      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

  • @simonlanglois4294
    @simonlanglois4294 8 месяцев назад

    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.

  • @DanielKRui
    @DanielKRui Год назад

    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".

  • @soltar25
    @soltar25 Год назад

    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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 Год назад

      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).

  • @leswine1582
    @leswine1582 Год назад

    RIP functional reactive programming

  • @MusicalSeriesChannel
    @MusicalSeriesChannel Год назад

    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.

  • @grawss
    @grawss Год назад

    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.

  • @rebelhype8218
    @rebelhype8218 Год назад

    Nice job

  • @SunShiNnneEee
    @SunShiNnneEee Год назад

    Very Great, detailed video! Learned a lot. Thanks!

  • @jmhimara
    @jmhimara Год назад

    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.

  • @markhathaway9456
    @markhathaway9456 Год назад

    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. 🙂

  • @allenhan8081
    @allenhan8081 Год назад

    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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 Год назад

      Thank you! Please let me know if something is unclear anywhere in my explanations.

  • @sergeiwinitzki3439
    @sergeiwinitzki3439 2 года назад

    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.

  • @sergeiwinitzki3439
    @sergeiwinitzki3439 2 года назад

    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.

  • @sergeiwinitzki3439
    @sergeiwinitzki3439 2 года назад

    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.

  • @pablobear4241
    @pablobear4241 2 года назад

    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.

  • @cinemagraphymahivara2000
    @cinemagraphymahivara2000 2 года назад

    Reflection like a dog

  • @joaoantonio7391
    @joaoantonio7391 2 года назад

    Nice video!

  • @re1konn
    @re1konn 2 года назад

    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?

    • @re1konn
      @re1konn 2 года назад

      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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 2 года назад

      @@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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 2 года назад

      @@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.

    • @re1konn
      @re1konn 2 года назад

      @@sergeiwinitzki3439 sure I will check the repl out

  • @re1konn
    @re1konn 2 года назад

    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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 2 года назад

      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]`

    • @re1konn
      @re1konn 2 года назад

      ​@@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] | }

  • @re1konn
    @re1konn 2 года назад

    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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 2 года назад

      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.

  • @re1konn
    @re1konn 2 года назад

    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?

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 2 года назад

      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.

    • @re1konn
      @re1konn 2 года назад

      @@sergeiwinitzki3439 you are the best. Thanks

    • @re1konn
      @re1konn 2 года назад

      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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 2 года назад

      @@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.

    • @re1konn
      @re1konn 2 года назад

      (1 to 1000).map(x => collatz(x).takeWhile(_ != 1).toList.size).max val res7: Int = 178 Indeed :)

  • @re1konn
    @re1konn 2 года назад

    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]?

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 2 года назад

      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.

    • @re1konn
      @re1konn 2 года назад

      @@sergeiwinitzki3439 Thanks a lot :)

  • @HPGumm
    @HPGumm 2 года назад

    This is an excellent tutorial. Thank You.

  • @ShotterManable
    @ShotterManable 2 года назад

    Thanks for sharing!! I loved your fp videos

  • @yifengliu8338
    @yifengliu8338 2 года назад

    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!

  • @gnorts_mr_alien
    @gnorts_mr_alien 2 года назад

    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.

  • @Asanqa
    @Asanqa 3 года назад

    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

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 3 года назад

      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.

  • @madhu1992blue
    @madhu1992blue 3 года назад

    Minor correction: fromDigits(non-tail-recursive implementation) in the tutorial actually creates the number in reverse.

  • @prateekgupta8861
    @prateekgupta8861 3 года назад

    Very informative video. Thanks a lot

  • @allenhan8081
    @allenhan8081 3 года назад

    Great talk. Looking forward to reading the book!

  • @yurifrl
    @yurifrl 3 года назад

    Good video

  • @HK-cq6yf
    @HK-cq6yf 3 года назад

    Thanks for this! Are you planning on doing one for what you learned writing your linear algebra book?

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 3 года назад

      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.

  • @nrrgrdn
    @nrrgrdn 3 года назад

    Thank you very much for this, as you put it, "Long and difficult, yet boring explanations given in excruciating detail."

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 3 года назад

      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.

  • @qbyteconsulting5729
    @qbyteconsulting5729 3 года назад

    Excellent, I would mention immutability.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 3 года назад

      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.

  • @frankgrey6797
    @frankgrey6797 3 года назад

    Было бы лучше показывать многопоточность сначала на callback-ах с разными задачами, например, вычислительными, потом использовать результаты в общем потоке, а уже потом обобщать на heavy-load параллелизме. Но в принципе полезное видео.

  • @zgngor
    @zgngor 4 года назад

    that's a gem. Thank you!

  • @imranfp
    @imranfp 4 года назад

    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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 4 года назад

      Thank you! Please feel free to make comments or suggestions about the book.

    • @imranfp
      @imranfp 4 года назад

      ​@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

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 4 года назад

      @@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.

    • @imranfp
      @imranfp 4 года назад

      @@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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 4 года назад

      @@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

  • @misval65
    @misval65 4 года назад

    Brilliant!

  • @abhishek-94
    @abhishek-94 4 года назад

    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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 4 года назад

      Yes, the book should be helpful. Please try reading it and let me know!

  • @PhilipSchwarzJ
    @PhilipSchwarzJ 4 года назад

    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

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 4 года назад

      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.

    • @PhilipSchwarzJ
      @PhilipSchwarzJ 4 года назад

      @@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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 4 года назад

      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.

    • @PhilipSchwarzJ
      @PhilipSchwarzJ 4 года назад

      @@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.

  • @w-mwijnja8919
    @w-mwijnja8919 4 года назад

    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.

    • @sergeiwinitzki3439
      @sergeiwinitzki3439 4 года назад

      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.

    • @w-mwijnja8919
      @w-mwijnja8919 4 года назад

      ​@@sergeiwinitzki3439 I fully agree :-).