One of the things that the Haskell language should really get kudos for is its community. I've learned many different languages, and participated in many different communities around them, but the Haskell community is on a whole other level. I often felt bad about how far the people in the Haskell community would go to make sure I understood things. I would ask a question and I would always find someone willing to work with me for HOURS if necessary, writing all kinds of example code to show me things, walking me through difficult concepts, etc. Many languages have helpful communities, but the Haskell community is simply the best I've ever seen. Top notch folks all.
Dustin Rodriguez Heh, if you think the community of Haskell is great, just wait until you experience that of Rust's! (another [predominantly] functional language, but which is compiled to fully native code, no VM or GC) I often wonder what, if any, beliefs and values are responsible for for this apparent trend - essentially, what sorts of people use languages like this, why do they want to use them, and do those reasons likely have a strong effect on the community as a whole? Perhaps a shared desire to get things _right_ ... not just to "work"..?
Matthew Ducker: Hmm. I think that could be it, yes! People in the functional communities tends to be people who are Very passionate about programming; it's more than "just a job" or about "making it work" - they spend a lot of time thinking about the most perfect way to do something - and they probably want to share that with others...
He had an adrenalin shot I guess. That was seriously out of character (well, as far as character building goes in one vid). I seriously just stopped and was like "WTF?"
How wonderful to see my first, and very best, programming professor again! I took functional programming courses for prof Hughes in 2004. Very great memories from that time :-)
After three years' CS studies at Chalmers, I always name Functional Programming (the very first course we took, and in which John played a major role) as the most valuable course - the one I would pick if I could choose only one single course to have taken. Not only are functional languages absolutely fantastic to work with; one can also use many of the important concepts of FP in imperative languages like Java to write monumentally superior code.
I was at one of his lectures at my university. Talked about the benefits of functional programming over imperative, as well as the powers of QuickCheck. Kind of like really nice propaganda from the man himself.
I wish they had some concrete examples. A lot of these summaries of programming paradigms fail to show what problem solving looks like and how it differs from other paradigms.
That's because pretty much any programming language can do simple things very easily and it's difficult to showcase important differences and what their impact is without experience and complicated examples.
Here are a few very simple examples of what functional programming can look like if run interactively in GHCi, where the user types an expression and GHCi returns its value. ">" indicates user input and this is not what an actual functional program looks like, just some standalone example expressions: >5+3 8 > > let someNumbers = [1..10] > someNumbers [1,2,3,4,5,6,7,8,9,10] > > let otherNumbers = map (+ 5) someNumbers > otherNumbers [6,7,8,9,10,11,12,13,14,15] > > all (> 5) someNumbers False > > all (> 5) otherNumbers True > > let square x = x * x > take 6 (map square [1..]) [1,4,9,16,25,36] Functional programming is all about pure expressions (most of the time). There is no such thing as mutable variables that you can assign some value to and then overwrite with something else. "=" in FP is a lot like equality in mathematics and not at all like assignment in imperative programming.
Ok, you asked for some concrete Haskell code: filterM (const [True,False]) [1,2,3] produces [[1,2,3],[1,2],[1,3],[1],[2,3],[2],[3],[]] which is the power set of [1,2,3]. explanation: we filter the list by both keeping and dropping every element in the list, using the list monad. [(2*),(3+),(1-)] [1,2,3] produces [2,4,6,4,5,6,0,-1,-2] which is every function in the first list APPLIED to every element in the second list. explanation: the list type [] is a member of the applicative class, enabling us to do such cool stuff.
But you can define those as const type * to prevent it. You're explicitly passing those pointers to be changeable, and of course there are ways around it if you're trying to blow your own foot off.
Wow he must be an excellent teacher. You can tell he has a firm grasp on functional programming concepts because he can explain things in layman terms.
He was my professor in parallel functional programming, he's fantastic! Koen Claessen who also teaches Haskell at Chalmers is also incredible and was the reason why I got interested in functional programming.
I was a core Object Oriented programmer but over the past few months have shifted to using Clojure which is another Functional Language very similar to Haskell and OMG does Functional Programming make so much more sense than OOP! Pure Functions means less bugs and the syntax of the language helps you write beautiful code that one can read so much more naturally. People who are getting into programming, give it a shot, you'll like it much more than OOP
Nothing makes me more happier than seeing functional programming rescuing fellow programmers from the terror of OOP, the dragon that has dominated the industry way too long.
OOP and FP are no contradiction. OCaml and O'Haskell are object oriented functional languages. OOP is a type system feature, FP is a control flow feature.
@@amigalemming How is it not a contradiction? In object orientation you have getters and setters, which by definition have side effects: Setters modify the state of an object, and the output of getters does depend on the state of an object. For example car.getSpeed() and car.setSpeed(50). From the OOP perspective having these side effects isn't even a bug but intended behavior. (Of course you could "de-OOP" everything by instead only allowing getCarSpeed(car) and setCarSpeed(car, 50), but then you don't have OOP anymore: All functions are global and no longer encapsulated in their classes as methods.)
This really made my day! I like Computerphile, I like Haskell and functional programming and I like John Hughes! He was such a great lecturer to have on my first course on university, and he left a good enough impression that three years after the course it still makes me excited to see him in a video!
Having no side effects, now this is genius! I was so impressed with functional programming that I spent last 5 years of my life coming up with an algorithm that can tell if a function is going to halt or not in O(1) time even. I'd would like to share the code with you all but unfortunately that would be a side-effect so I can't.
Few clarifications: Functional programming in at of itself doesn't mean you don't have side-effects. Functions that doesn't mutate and always provides the same output with the same input are called pure functions, which are part of the functional programming paradigm. Side effects are inevitable if you work with I/O such as networking, threads/multiple processes. You can still use functional programming languages (like Haskell) to write functions that handles side-effect, but it's usually done by separating them out from other business logic. Scala is also not _really_ a functional programming language by itself. It is mix between functonal and object-oriented, similar to JavaScript.
I'd like to see a video on dependent types, and type systems in general, in the future. Types are extremely important to properly using languages like Haskell, and they have a rich history of interactions with the foundations of mathematics.
I was taught Miranda in my first year of university, 1989. Twenty years later into my career spent mostly with C and Java and I was surprised to find it making comeback! (in the form of Haskell, Scala, etc).
I was lucky enough to take multiple Haskell courses with Dr. Jon Peterson, a contributor to much of the Haskell98 documentation during his tenure @ Stanford, as well as a co-author of the Arrow ( -> ) Prelude extension class. He sadly passed near the end of my graduating semester - It was a privilege to learn from him.
This was awesome! Very nicely explained. Computerphile needs to do a video on Lisp next- something on the history, or more modern dialects like Clojure. That would be really cool!
The most important thing is to pick the language and paradigm that works best for you and the project. It is nice to be able to use functional styles when the language and problem fits it. I tend to fluctuate between Functional and Imperative styles in the same project often. Sometimes that implicitly bound functional environment is nice to have other times a state modifying loop is handy. I tend to try and stay with what the language designers expect though. A lot of functional style recursion will blow the stack if implemented carelessly in many imperative languages. I tend to write in Common Lisp which allows for both but I can respect people who prefer one paradigm if it feels more "pure" to them.
Stefán Örvar Sigmundsson not necessarily. It could just be compiled into another language which can then compile to machine code. It's more the theory behind the syntax and how the raw text can be processed into a data structure that is of use to a compiler.
7 ปีที่แล้ว +1
James Coyle Compiling into another language is called source-to-source compiling or transcompiling, sure that's a lot easier.
+James Coyle If you google "g53cmp" that will take you to a course page for a Compilers module taught at the University of Nottingham which is implemented in Haskell if you are interested.
Functional is the future. I truly believe it. Haskell is my favourite functional language. Used Haskell at IMVU for many things.
7 ปีที่แล้ว +11
The world has been moving away from functional so it would have to make a comeback which it doesn't really seem to be doing. In functional programming everything feels like an algorithm. There are things like GUI programming that don't lend themselves well to this way of thinking.
Need to mention Nim as a Python-style alternative to Rust. :) You can get the best of both worlds, but I would rather see functional if there had to be one. In any given program, design 99% of the functions/methods to have no side affects (what constitutes a side affect depends on the situation). Do not give in to temptation to make quick fixes which break this rule. As a benefit, you get automatic thread safety and re-entrancy.
I love the idea of func programming, but I constantly run into problems with efficiency. A lot of my code does large scale data processing. I end up doing a lot of caching/checkpointing on the filesystem. My code ends up being very confusing an error prone, but I just can’t do it any other way.
I only see spam when I click on one of the trending news stories, and see a load of identical statuses posted by completely different people. I've never seen spam in my news feed, unless you count advertising, and posts from pages like by your friends, but facebook puts those there deliberately, so its not really the same.
One thing he doesn't mention is the fact that functional programming languages are used only very, very rarely. Probably less than 1% of all produced code today is written in a purely functional language like Haskell. Almost all other languages are imperative with a few functional ideas mixed in, or (more rarely) hybrids of sort, like Scala. Even scientists, which are usually much more math-savvy than usual business programmers, rarely use Haskell. So why are functional languages so unpopular, despite all their advantages? My theory is that one problem is their inability to handle loops. As far as I understand, in functional languages you always have to use recursive functions instead of loops. Which has two problems: - Recursive functions are usually significantly harder to understand than loops, which makes writing and reading code more difficult, and increases the chance of making mistakes or not understanding someone's elses code. If programmers have the freedom to use either of them, they, in by far the most cases, use loops instead of recursive functions. - It is much easier to write inefficient code with recursive functions than with loops. E.g. if you write a loop inside a loop, you usually end up with a time complexity of about O(n^2), which can in most cases still be computed very quickly. However, if you write two recursive calls in your recursive function, you typically get something like O(2^n)! Computing this can get _extremely_ slow even for what you might consider medium sized inputs. (Also, if you want to make a recursive function really as efficient as a typical loop, you often have to make sure that your function is "tail-recursive", which is even harder to write and understand than usual recursion.)
Got an error on my calculator trying to calculate 2^1024 )) My take on the reason why they aren't popular - they feel extremely... Elitist? In a sense that most languages use pretty familiar or understandable concepts like array, loop, variable, pointer etc. But «monad is a monoid in a category of endofunctors»... Is it just a meme?
Generally, whether you prefer OO or functional, your functions should be stateless and without side-effects unless they need to have state. Also unidirectional data flow is much easier to work with.
Really enjoyable video, for a while I've been wondering what makes functional programming different. What I do find strange though, coming from a language which separates functions (return a value) and subroutines (no value return) is that it seems obvious to me that a function wouldn't do anything else than return a value - you could implement that paradigm just with a change of programming style
I think one of the nicest parts about functional programming is the focus on composability. You can have functions that take functions and returns functions, which you can then run (btw, you can also do that in many mixed paradigm languages that are not pure functional).
Really like the way he explains the concepts at hand. Perhaps it is just suited to my learning style, but I understood everything he said and its implications, and I'm by no means an expert.
You really really need to do a video on monads. One of the functional programming topics that many of us have a lot of trouble getting our heads around.
I've never looked into functional programming that much. It's so very different from other types of programming that it pretty much requires going back to square one.
You can do functional style programming in most procedural languages. But it would be on the programmer to avoid side effects. It's advisable in many cases for subprograms to avoid or restrain side effects even in procedural programming.
I'll certainly get around to it one day. I don't have the time to learn functional programming at the moment. It's certainly interesting. When I have looked at it before it seemed to be harder to read and comprehend than imperative programming, as imperative programming makes it easy to follow the flow of the program, but a large part of that might be that I'm not used to functional programming. If I learned it, I should find it more intuitive over time.
You're right, but I highly recommend taking the time to do so. You'll be greatly rewarded even if you don't wind up using Haskell it will give you new abstractions to make your programming in other languages much better.
going from Java to Haskell is much more difficult than going from Java to C++. It's a different way of thinking not just a new syntax, but it's very much worth the effort.
Then this video must not for category theorists. I hope functional programming will share the fate of OOP: in the beginning everyone thought, so I heard, that OOP was super difficult and only geniuses could do it, but nowadays OOP languages like Java and C# are considered not requiring too much technical expertise.
Вася Бубликов And now we are moving away from OOP towards even better paradigms. It all depends on the existing availability of tools, the more stuff is already written that enables you to write code in a particular way quicker and easier, the more people will adopt it.
Haskell has one awesome feature I've never seen anywhere else (but that's probably just my ignorance): partial application. If you define a function that takes three parameters, you can call it with just one parameter, and the result is a new function that takes the remaining two parameters, with the value you passed bound to the original first parameter. And this works for ANY function. When I write a function in Haskell, I tend to order the parameters according to how likely I am to want to bind each one like that.
You can find partial application in all sorts of computer languages. I use a lot of partial application with Javascript, believe it or not; I have also seen it in Python. I truly love this feature.
***** If you call a Javascript function with fewer parameters than it's defined to take, the left over parameters are just set to 'undefined' and the function is executed as normal. I guess you're talking about writing a special function that returns a function? Haskell makes it SO much easier.
Technically, all Haskell functions take one parameter only, and may, as result, return functions returning functions, and so on ... There's nothing special about functions compared to data. Functions ARE data.
For perfomance we theoretically could take the Rust's memory management model which allows us not to use Garbage Collector and at the compile time automatically create the instructions for freeing the unused memory.
I love the amount of passion this guy has about what he does. Very interesting stuff. Had no idea Haskell is used in so many ways. Good interview, and love the samurai remake =)
You were at Chalmers? If so, I hope you liked our university! I'm not a CS student, but I've heard about John through friends who are. Very interesting to hear from someone who helped pioneer the field.
I learned haskell in my first semester programming course at uni. I absolutely hated it at first for its lack of global variables and pickyness with types, but once I understood the basics it was very nice to use and programming with it felt like a fun challenge.
At my work we were mixing and matching F# and C# for a while but ended up just ditching it in favour of using a single language (C#) for maintainability and performance, among other reasons, and using the ideas behind functional languages like immutability and avoiding side effects (e.g. using a [Pure] attribute and static code analysis) without the burden of the unintelligible syntax. I've yet to see anything in functional languages that you can't do in imperative languages, it's just a bit stricter.
Do tasks like reading input and displaying output count as side effects? Is the idea for the program to have core functionality that is solely functional, called by a user interface written without the functional restrictions? Is functional programming better for particular kinds of programming tasks than others? If so, what kinds of projects does functional programming work best with and worst with?
+Marcos Martinelli answer isn't incorrect but IMHO is not the core of the question. (Marcos, these are implementation details). +Viktor Strate, the general idea is total functions. Every input produces the same output and always the same output for the same input. Actually, that's exactly what "without all of the under the hood" Marcos pointed to.
Would be nice to have a little deeper discussion about functional programming. How to overcome its limitations for example. Not being able to easily use mutable variables is so foreign to a "normal" programmer that people get frustrated very fast when trying functional. I tried once and wasn't convinced that the benefits are worth the limitations. Later i met an earlier colleague and he was very enthusiastic about haskell. For a "normal" programmer functional programming is pretty hard at the beginning.
Bah. You are thinking about variables the wrong way. Typically, C style programmers think of variables as bins in which to put values. What you should think of variables as is aliases for values. This way you won't need mutable variables, and come to see them as the abhorrence they are. The compiler should make the code use the available registers optimally, not the programmer. This isn't the 20th century anymore. Nary a programmer even knows how the registers will be used with dynamic superpipelined out-of-order execution on a multi-core processor with parallel arithmetic and logic units and with branch prediction in speculative execution pipelines and multi-layer caches anyway.
not sure if you guys will read this, but the English subtitles seem auto-generated (even though they were seemingly manually uploaded), they're full of errors and strange notation with square brackets.
I don't know the right words for talking about programming languages, but I have a question, so I'll just try my best… Regarding higher level programming languages, such as the one this video's about… Do the things that make it up, have a direct equivalent in a lower level language that's not machine code? Because one way I'm imagining how it works, is that someone decided on a list of things that it ought to be able to do, and then built those things with a lower level language, by going over them with a fine tooth comb to find bugs, spending a lot of time to make sure each one does what they mean it to. Then you use those things to build your program, like building a machine out of off the shelf assemblies of parts, like a motherboard is assembled from lots of little electronics, such as capacitors, resistors, chips, etc., and the parts can be equated to a low level language, and manufacturing process to make all of those individual parts is the equivalent of machine code.
It is true that plenty of languages are built on lower level languages. I only really see examples where the compiler is written in C(++). Beyond that though, there's assembly which is a little higher level than machine code but not by much. With the introduction of intermediary languages like webassembly, you can often compile to something that is completely detached from the computer's hardware implementation
I have been studying Haskell for some years. I keep getting stuck on understanding monads. The term comes from Leibniz and I pretty well know what he meant with it. But what it has to do with Haskell I just can’t figure out. A video that explains what a monad is and how it is used would be very welcome.
Additionally, part of why local variables aren't side effects aside from how they are allocated on the stack is the same as the constant of integration.
Does a functional programming language actually DO something that a language like C, C++, or C# can't do, or is it more that it reduces what can be done in order to enforce an opinionated design style that reduces the probability of bugs?
CybeargPlays You're referring to a thing called the Church-Turing thesis. I suggest you spend some time on Wikipedia looking at it. There are some extremely deep rabbit holes to get lost in if you want. Lambda calculus and Turing machines are exactly identical. They have exactly equal capabilities because anything that can be defined as a list of instructions in a Turing machine can be defined recursively with lambda calculus, and vice versa.
CybeargPlays It allows for a level of implicit parallelism. In other words, you can write code a program without worrying about parallelism at all, and still have it run in parallel. Sure, that might not be too big of a deal if you're only working with a few cores, but when you're working with systems with tens to hundreds, perhaps even thousands of CPU cores, all of which need to be running very complex logic (so not like GPU programming), it makes programming a hell of a lot easier. Basically, the restraints put in place still allow you to do everything you normally could, you just have to do it in a slightly different way. The restraints make it easier for the compiler to reason about you code, and do very powerful optimizations that otherwise would be very difficult and tedious if done by the programmer. The age of their massively parallel CPUs is coming. Just look at Adapteva's Epiphany V, coming out next year. How would you program a 1024 core CPU?
You can do functional programing in C, C++ or C#, but they are not designed for this in mind, so it won't be as nice as in F#, Haskell or OCaml for example. It's not so much a reduction of what can be done than a different approach. Haskell can manipulate things like infinite list easily thanks to it's laziness, which would be harder to do in C... Same thing for parallelism, type inference, etc. But if you are writing a low level driver for example, C would be a better fit, because you don't need these features but you need the raw access to the memory and knowledge of the exact sequence of instructions realized by the computer. If you are taking in a lot of messages and trying to work out if they are spam or not at Facebook scale, you want the massive parallelism that functional programming gives you. But yeah, in terms of "What computations can you do", most programming languages are completely equivalent (keyword: Turing completeness)
To answer OP's question: No... and Yes. No: In terms of what they are able to compute. For example, Haskell and C are equivalent. Yes: There are features in many languages that have absolutely no equivalent C-ish languages. To make things concrete, let's do Haskell and C* (pick your poison). Haskell's type system can actually *enforce* what API callbacks are able to accept at quite a granular level. This was alluded to in the video with the "no leaking" library. Unlike C*, Haskell has return-type polymorphism. So next time you read that article that claims C# has monads, just remember their API's can never be generic. What a drag :)
But what can you actually DO with functional programming? If there can be no side effects, it seems to me that your programs couldn't actually do anything, other than have your main() function return some value at the end. Where is the action?
Consider the high-level minimum number of inputs and outputs you need in a program. Usually, even in a very complex one it boils down to very few. In a 3D game there are the controls as input which output to set of changes to be applied to internal world representation. Then that representation is input to an audio/video output.
That was a better explanation than we ever got at university... That said, I find find the premise of it a bit odd. I *want* functions to be able to have side effects, encapsulation is one of the major foundations of object orientated programming... call a member function, have it update something, and (optionally) return another value... the same in C operating on global variables... I would argue it is more reliable to have well defined side effects than to go without them at all. A compiler could also easily tell you if a function referenced anything external to itself, as when compiled in isolation anything external would be unlinkable.
I think of functional programming and side effects like this: A = B, where B is a function or operation. While we do this implicitly in math, we specify to computers the Boolean operators ==, and ===. Ultimately, A can be represented by whatever by is on the right so long as A == B is true. However A === B is false in a pure function. While A and B may have equal values, what happens to B is not directly happening to A. Take 7=4+3. 7 is 7, 4+3 is 4+3. In programming = would be an assignment, but in math it's a == in programming syntax. 7 can be represented by really any infinite combination of operations. In 7=4+3, 7 is never being directly changed or manipulated. A pure function's output is constant given the same inputs
I notice he completely ignored the dependency hell of Haskell. I tried getting into it... but the constant need to add newer/older versions of libraries to make other bits work properly was incredibly frustrating.
If i want to learn much of functional programming and related concepts which two should i choose out of haskell, clojure, racket, scala. can anyone give me a detailed explanation.
If you don't specify all or correct requirements to the quickcheck there still will be gaps in the tests, so what does quickcheck solve? Is it trying to bring easier syntax (implementation) to describe a unit test?
coolluckyme2007 Pretty much, it's a really handy way of checking that a property holds true for a lot of inputs (not just the ones that we worked out by hand). You should test static data (e.g. data that has broken the code before) and also dynamic tests which quick check does. Its a really amazing tool that I have been saved by a few times
Quick check can't solve core issue with testing correctness of programs. Writing a test that checks that function does what it's supposed to? How do you know the results? By writing the function again in the test? And then test the test's test's tests.... It can only be used to check simple properties, like the length of the output. And to get any decent coverage you have to still write all these property-checks.. and on top of that you have to write a generator for valid inputs. Many functions have very complex scenarios where they don't throw an exception, so writing a generator that randoly manages to generate valid inputs is harder than writing the test itself. Nothing about this is automatically generated (and it can't ever be).
If you already know some non-functional programming, be prepared to forget everything you've learned. Functional programming is fundamentally different. It's not harder, really, and if you learn it as your first language many people find it easier than imperative programming (what most languages are). But the more you are used to imperative programming, the weirder functional programming tends to seem. Being able to think in the ways both require, though, is tremendously beneficial.
Bradley Bauer Absolutely that will help! Functions in functional programming are much more like mathematical functions than the procedures in imperative languages that get called 'functions'.
One thing I don't catch is what he said at 6:20 - I mean you can have the same safe parallelism if you do a pass by value and spin-off two threads in a conventional program no?
One of the things that the Haskell language should really get kudos for is its community. I've learned many different languages, and participated in many different communities around them, but the Haskell community is on a whole other level. I often felt bad about how far the people in the Haskell community would go to make sure I understood things. I would ask a question and I would always find someone willing to work with me for HOURS if necessary, writing all kinds of example code to show me things, walking me through difficult concepts, etc. Many languages have helpful communities, but the Haskell community is simply the best I've ever seen. Top notch folks all.
Dustin Rodriguez Heh, if you think the community of Haskell is great, just wait until you experience that of Rust's! (another [predominantly] functional language, but which is compiled to fully native code, no VM or GC)
I often wonder what, if any, beliefs and values are responsible for for this apparent trend - essentially, what sorts of people use languages like this, why do they want to use them, and do those reasons likely have a strong effect on the community as a whole? Perhaps a shared desire to get things _right_ ... not just to "work"..?
I think it's because FP is so much fun to teach. Why it's so much fun to teach is something I'll have to think about more.
Matthew Ducker: Hmm. I think that could be it, yes! People in the functional communities tends to be people who are Very passionate about programming; it's more than "just a job" or about "making it work" - they spend a lot of time thinking about the most perfect way to do something - and they probably want to share that with others...
wholesome :)
Can you guys share any books or resources to start with for a java developer ?
Cheers
My dad is an expert dragon slayer.
"eeer but I don't see any dragons around... "
You're welcome.
your dad is great at his job!!! thank him for his service to humanity!! :)
Flash Man reported to PETA
unless only an expert recognizes a dragon.
what am i missing here?
@@amitdawar6411 It's a joke referring what was said in the video about: "there is no spam on facebook"
6:35 John Hughes goes full code ninja mode. God help any computer that tries to modify his data.
I HAVE BEEN JUMPSCARED
He had an adrenalin shot I guess. That was seriously out of character (well, as far as character building goes in one vid). I seriously just stopped and was like "WTF?"
hahahaha
That clearly deserves a GIF.
That was awesome. It totally showed how he feels about that mutable state. ITS CRAZY, ALL OVER, AND FAST!! Sooooo Awesome!!
Watching this in 2024, it's amazing to hear there was a time when there was no spam on facebook.
How wonderful to see my first, and very best, programming professor again!
I took functional programming courses for prof Hughes in 2004. Very great memories from that time :-)
After three years' CS studies at Chalmers, I always name Functional Programming (the very first course we took, and in which John played a major role) as the most valuable course - the one I would pick if I could choose only one single course to have taken.
Not only are functional languages absolutely fantastic to work with; one can also use many of the important concepts of FP in imperative languages like Java to write monumentally superior code.
Charmers in Gothenburg?
@@grhaonan I might be a member of that set, yes - having studied at Chalmers and all! ^^
@@simonalling nice, I studied at Chalmers 10 years ago:)
Holy... that was very well explained. If you can get John back on camera that would be appreciated.
On of the best professors I have had!
I was at one of his lectures at my university. Talked about the benefits of functional programming over imperative, as well as the powers of QuickCheck. Kind of like really nice propaganda from the man himself.
Pixelmaniac Did you just watch that DNews Plus video...
He pretty much did not explain anything? The video had like no analytical content.
Yes, please
I wish they had some concrete examples. A lot of these summaries of programming paradigms fail to show what problem solving looks like and how it differs from other paradigms.
That's because pretty much any programming language can do simple things very easily and it's difficult to showcase important differences and what their impact is without experience and complicated examples.
Here are a few very simple examples of what functional programming can look like if run interactively in GHCi, where the user types an expression and GHCi returns its value. ">" indicates user input and this is not what an actual functional program looks like, just some standalone example expressions:
>5+3
8
>
> let someNumbers = [1..10]
> someNumbers
[1,2,3,4,5,6,7,8,9,10]
>
> let otherNumbers = map (+ 5) someNumbers
> otherNumbers
[6,7,8,9,10,11,12,13,14,15]
>
> all (> 5) someNumbers
False
>
> all (> 5) otherNumbers
True
>
> let square x = x * x
> take 6 (map square [1..])
[1,4,9,16,25,36]
Functional programming is all about pure expressions (most of the time). There is no such thing as mutable variables that you can assign some value to and then overwrite with something else. "=" in FP is a lot like equality in mathematics and not at all like assignment in imperative programming.
Ok, you asked for some concrete Haskell code:
filterM (const [True,False]) [1,2,3]
produces
[[1,2,3],[1,2],[1,3],[1],[2,3],[2],[3],[]]
which is the power set of [1,2,3].
explanation: we filter the list by both keeping and dropping every element in the list, using the list monad.
[(2*),(3+),(1-)] [1,2,3]
produces
[2,4,6,4,5,6,0,-1,-2]
which is every function in the first list APPLIED to every element in the second list.
explanation: the list type [] is a member of the applicative class, enabling us to do such cool stuff.
You can join Project Euler and see many examples.
Here is a two-line quicksort in Haskell.
qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
6:34 sudden rage-mode
I was not ready.
Even the camera gets scared.
Not to mention being completely wrong.
Mark Randall
No, he has a point. Some imparative languages such as C may force one to use pointers as function arguments.
But you can define those as const type * to prevent it. You're explicitly passing those pointers to be changeable, and of course there are ways around it if you're trying to blow your own foot off.
Wow he must be an excellent teacher. You can tell he has a firm grasp on functional programming concepts because he can explain things in layman terms.
he is ... easily one of the best professors I have had.
He is one of the guys who made Haskal 🤣
He was my professor in parallel functional programming, he's fantastic! Koen Claessen who also teaches Haskell at Chalmers is also incredible and was the reason why I got interested in functional programming.
I was a core Object Oriented programmer but over the past few months have shifted to using Clojure which is another Functional Language very similar to Haskell and OMG does Functional Programming make so much more sense than OOP!
Pure Functions means less bugs and the syntax of the language helps you write beautiful code that one can read so much more naturally. People who are getting into programming, give it a shot, you'll like it much more than OOP
That makes me happy I started computer science in the summer, so our first language will be Haskell rather than Java.
Nothing makes me more happier than seeing functional programming rescuing fellow programmers from the terror of OOP, the dragon that has dominated the industry way too long.
OOP and FP are no contradiction. OCaml and O'Haskell are object oriented functional languages. OOP is a type system feature, FP is a control flow feature.
If you work with databases objects it’s a must .
@@amigalemming How is it not a contradiction? In object orientation you have getters and setters, which by definition have side effects: Setters modify the state of an object, and the output of getters does depend on the state of an object. For example car.getSpeed() and car.setSpeed(50). From the OOP perspective having these side effects isn't even a bug but intended behavior.
(Of course you could "de-OOP" everything by instead only allowing getCarSpeed(car) and setCarSpeed(car, 50), but then you don't have OOP anymore: All functions are global and no longer encapsulated in their classes as methods.)
This really made my day! I like Computerphile, I like Haskell and functional programming and I like John Hughes! He was such a great lecturer to have on my first course on university, and he left a good enough impression that three years after the course it still makes me excited to see him in a video!
I'm a javascript developer and I started programing funtionally and it makes so much sense I've never looked back
So proud! He was my teacher ^^
I would assume you did graduated, congrats!
I had subtitles on, so naturally I was suprised when it mentioned the airline programming language.
So far I was not aware that Ericsson was concerned with aviation. :-)
Having no side effects, now this is genius!
I was so impressed with functional programming that I spent last 5 years of my life coming up with an algorithm that can tell if a function is going to halt or not in O(1) time even.
I'd would like to share the code with you all but unfortunately that would be a side-effect so I can't.
Nonsense
@@atlantic_love I'm pretty sure this comment was a joke
curse these side effect rules, curse them!
He wrote QuickCheck? I used it during a Functional Programming course in uni. Very useful to make sure you got a function right fast.
Few clarifications: Functional programming in at of itself doesn't mean you don't have side-effects. Functions that doesn't mutate and always provides the same output with the same input are called pure functions, which are part of the functional programming paradigm. Side effects are inevitable if you work with I/O such as networking, threads/multiple processes. You can still use functional programming languages (like Haskell) to write functions that handles side-effect, but it's usually done by separating them out from other business logic.
Scala is also not _really_ a functional programming language by itself. It is mix between functonal and object-oriented, similar to JavaScript.
I'd like to see a video on dependent types, and type systems in general, in the future. Types are extremely important to properly using languages like Haskell, and they have a rich history of interactions with the foundations of mathematics.
I find this dude's enthousiasm very communicative. I would love to attend one of his classes. His students are lucky.
I was taught Miranda in my first year of university, 1989. Twenty years later into my career spent mostly with C and Java and I was surprised to find it making comeback! (in the form of Haskell, Scala, etc).
I was lucky enough to take multiple Haskell courses with Dr. Jon Peterson, a contributor to much of the Haskell98 documentation during his tenure @ Stanford, as well as a co-author of the Arrow ( -> ) Prelude extension class. He sadly passed near the end of my graduating semester - It was a privilege to learn from him.
This was awesome! Very nicely explained.
Computerphile needs to do a video on Lisp next- something on the history, or more modern dialects like Clojure. That would be really cool!
nah, lambda calculi
Can we get more videos about Functional Programming / Lambda Calculus and how to solve simple problems with this way of programming?
John Hughes is an incredibly nice man. Had the fortune to have met him twice so far.
I have read some of Hughes' papers and listened to him on TH-cam and just wow... He is just so elaborate without confusing people.
The most important thing is to pick the language and paradigm that works best for you and the project. It is nice to be able to use functional styles when the language and problem fits it. I tend to fluctuate between Functional and Imperative styles in the same project often. Sometimes that implicitly bound functional environment is nice to have other times a state modifying loop is handy. I tend to try and stay with what the language designers expect though. A lot of functional style recursion will blow the stack if implemented carelessly in many imperative languages. I tend to write in Common Lisp which allows for both but I can respect people who prefer one paradigm if it feels more "pure" to them.
Would there be any possibility of actually covering the process of creating a language definition and writing a compiler and/or interpreter for it?
The would require an entire series of videos. Creating a language is easy but writing a compiler requires a lot of low level assembly understanding.
Stefán Örvar Sigmundsson not necessarily. It could just be compiled into another language which can then compile to machine code. It's more the theory behind the syntax and how the raw text can be processed into a data structure that is of use to a compiler.
James Coyle Compiling into another language is called source-to-source compiling or transcompiling, sure that's a lot easier.
You don't know what you're talking about
+James Coyle If you google "g53cmp" that will take you to a course page for a Compilers module taught at the University of Nottingham which is implemented in Haskell if you are interested.
Functional is the future. I truly believe it. Haskell is my favourite functional language. Used Haskell at IMVU for many things.
The world has been moving away from functional so it would have to make a comeback which it doesn't really seem to be doing. In functional programming everything feels like an algorithm. There are things like GUI programming that don't lend themselves well to this way of thinking.
Note Purescript, Elm, GHCJS, and various FRP Haskell flavors, this is UI mostly, for everything else notice companies using Haskell, Scala and OCaml.
Companies using Haskell? You got to be joking...
Need to mention Nim as a Python-style alternative to Rust. :)
You can get the best of both worlds, but I would rather see functional if there had to be one. In any given program, design 99% of the functions/methods to have no side affects (what constitutes a side affect depends on the situation). Do not give in to temptation to make quick fixes which break this rule. As a benefit, you get automatic thread safety and re-entrancy.
Lazic B. It's a lot faster than PHP?
I love the idea of func programming, but I constantly run into problems with efficiency. A lot of my code does large scale data processing. I end up doing a lot of caching/checkpointing on the filesystem. My code ends up being very confusing an error prone, but I just can’t do it any other way.
Subtitles incorrectly say 'airline' instead of 'erlang' :-)
Thnx for clarifying.
6:35 Those Karate lessons really are starting to pay off
Bruce Lee would have been a great functional programmer
You should do a video on lambda calculus!
'I didn't think there was spam on facebook!'
What...?
Facebook is pure spam
I think it was 'a little bit' of sarcasm :D
Spambots with 10000+ friends and posts all fake don't really exist anymore.
Never had any spam myself or heard of anyone who gets spam. Twitter on the other hand oh wow what a world of spam that is lol
I only see spam when I click on one of the trending news stories, and see a load of identical statuses posted by completely different people. I've never seen spam in my news feed, unless you count advertising, and posts from pages like by your friends, but facebook puts those there deliberately, so its not really the same.
One thing he doesn't mention is the fact that functional programming languages are used only very, very rarely. Probably less than 1% of all produced code today is written in a purely functional language like Haskell. Almost all other languages are imperative with a few functional ideas mixed in, or (more rarely) hybrids of sort, like Scala. Even scientists, which are usually much more math-savvy than usual business programmers, rarely use Haskell.
So why are functional languages so unpopular, despite all their advantages?
My theory is that one problem is their inability to handle loops. As far as I understand, in functional languages you always have to use recursive functions instead of loops. Which has two problems:
- Recursive functions are usually significantly harder to understand than loops, which makes writing and reading code more difficult, and increases the chance of making mistakes or not understanding someone's elses code. If programmers have the freedom to use either of them, they, in by far the most cases, use loops instead of recursive functions.
- It is much easier to write inefficient code with recursive functions than with loops. E.g. if you write a loop inside a loop, you usually end up with a time complexity of about O(n^2), which can in most cases still be computed very quickly. However, if you write two recursive calls in your recursive function, you typically get something like O(2^n)! Computing this can get _extremely_ slow even for what you might consider medium sized inputs.
(Also, if you want to make a recursive function really as efficient as a typical loop, you often have to make sure that your function is "tail-recursive", which is even harder to write and understand than usual recursion.)
Got an error on my calculator trying to calculate 2^1024 ))
My take on the reason why they aren't popular - they feel extremely... Elitist?
In a sense that most languages use pretty familiar or understandable concepts like array, loop, variable, pointer etc.
But «monad is a monoid in a category of endofunctors»... Is it just a meme?
Generally, whether you prefer OO or functional, your functions should be stateless and without side-effects unless they need to have state. Also unidirectional data flow is much easier to work with.
Really enjoyable video, for a while I've been wondering what makes functional programming different. What I do find strange though, coming from a language which separates functions (return a value) and subroutines (no value return) is that it seems obvious to me that a function wouldn't do anything else than return a value - you could implement that paradigm just with a change of programming style
I think one of the nicest parts about functional programming is the focus on composability. You can have functions that take functions and returns functions, which you can then run (btw, you can also do that in many mixed paradigm languages that are not pure functional).
Really like the way he explains the concepts at hand. Perhaps it is just suited to my learning style, but I understood everything he said and its implications, and I'm by no means an expert.
You really really need to do a video on monads. One of the functional programming topics that many of us have a lot of trouble getting our heads around.
They did one. Still doesn’t make any sense though.
I've never looked into functional programming that much. It's so very different from other types of programming that it pretty much requires going back to square one.
Most languages do that (spoken and programmed).
You can do functional style programming in most procedural languages. But it would be on the programmer to avoid side effects. It's advisable in many cases for subprograms to avoid or restrain side effects even in procedural programming.
I'll certainly get around to it one day. I don't have the time to learn functional programming at the moment. It's certainly interesting. When I have looked at it before it seemed to be harder to read and comprehend than imperative programming, as imperative programming makes it easy to follow the flow of the program, but a large part of that might be that I'm not used to functional programming. If I learned it, I should find it more intuitive over time.
You're right, but I highly recommend taking the time to do so. You'll be greatly rewarded even if you don't wind up using Haskell it will give you new abstractions to make your programming in other languages much better.
going from Java to Haskell is much more difficult than going from Java to C++. It's a different way of thinking not just a new syntax, but it's very much worth the effort.
As a category theorist in training... I was waiting for the words like "Haskell enable composable side effects" which never came.
I expect there to be something about monads and burritos in the next video! (And monoids in the category of endofunctors!)
Then this video must not for category theorists. I hope functional programming will share the fate of OOP: in the beginning everyone thought, so I heard, that OOP was super difficult and only geniuses could do it, but nowadays OOP languages like Java and C# are considered not requiring too much technical expertise.
Вася Бубликов And now we are moving away from OOP towards even better paradigms. It all depends on the existing availability of tools, the more stuff is already written that enables you to write code in a particular way quicker and easier, the more people will adopt it.
It should have been longer, very interesting theme and guy!
Haskell has one awesome feature I've never seen anywhere else (but that's probably just my ignorance): partial application. If you define a function that takes three parameters, you can call it with just one parameter, and the result is a new function that takes the remaining two parameters, with the value you passed bound to the original first parameter. And this works for ANY function. When I write a function in Haskell, I tend to order the parameters according to how likely I am to want to bind each one like that.
You can find partial application in all sorts of computer languages. I use a lot of partial application with Javascript, believe it or not; I have also seen it in Python. I truly love this feature.
***** If you call a Javascript function with fewer parameters than it's defined to take, the left over parameters are just set to 'undefined' and the function is executed as normal. I guess you're talking about writing a special function that returns a function? Haskell makes it SO much easier.
You are right.
HebaruSan lool. Thats functionception and is in every prg lang that supports closures
Technically, all Haskell functions take one parameter only, and may, as result, return functions returning functions, and so on ...
There's nothing special about functions compared to data. Functions ARE data.
Now Mr Hughes is a professor I'd love to have at my faculty.
Hughes! This brings back memories from my first fp course at Chalmers way back. :D
2:08
i like his „Oh“
6:36 It awakes the deepest part of my soul
Follow up please! Higher-order functions and type declarations :3
very cool! had a module on Haskell last year which I really enjoyed; the teacher was super enthusiastic about it haha
What kind of programming language would you recommend for firing the missiles? Thanks
Rocky Horror and functional programming in one video? Great stuff.
For perfomance we theoretically could take the Rust's memory management model which allows us not to use Garbage Collector and at the compile time automatically create the instructions for freeing the unused memory.
I love the amount of passion this guy has about what he does. Very interesting stuff. Had no idea Haskell is used in so many ways. Good interview, and love the samurai remake =)
Just did a module in a Java course that was about the functional programming implementation in Java. This is adds a neat perspective.
Haskell and Erlang are both really nice languages to work in. I prefer it so so much over C/ C++.
I love haskell! : D Thanks for covering it.
Yes! Thank you Computerphile, great great intro to some huge ideas!
Hughes ideas too!
You were at Chalmers? If so, I hope you liked our university! I'm not a CS student, but I've heard about John through friends who are. Very interesting to hear from someone who helped pioneer the field.
He's still definitely about. He holds guest lectures at the campus every now and then.
John Hughes teaches Parallel Functional Programming in the Master's level at Chalmers.
I learned haskell in my first semester programming course at uni. I absolutely hated it at first for its lack of global variables and pickyness with types, but once I understood the basics it was very nice to use and programming with it felt like a fun challenge.
Do you still use it?
At my work we were mixing and matching F# and C# for a while but ended up just ditching it in favour of using a single language (C#) for maintainability and performance, among other reasons, and using the ideas behind functional languages like immutability and avoiding side effects (e.g. using a [Pure] attribute and static code analysis) without the burden of the unintelligible syntax. I've yet to see anything in functional languages that you can't do in imperative languages, it's just a bit stricter.
YES. More of this! Love where this channel is going.
Do tasks like reading input and displaying output count as side effects? Is the idea for the program to have core functionality that is solely functional, called by a user interface written without the functional restrictions? Is functional programming better for particular kinds of programming tasks than others? If so, what kinds of projects does functional programming work best with and worst with?
Please make a video, describing the general idea of functional programming
+Marcos Martinelli answer isn't incorrect but IMHO is not the core of the question. (Marcos, these are implementation details).
+Viktor Strate, the general idea is total functions. Every input produces the same output and always the same output for the same input. Actually, that's exactly what "without all of the under the hood" Marcos pointed to.
I'd recommend watching some of Venkat Subramaniam's talks on functional programming for any developers watching this video
Would be nice to have a little deeper discussion about functional programming. How to overcome its limitations for example. Not being able to easily use mutable variables is so foreign to a "normal" programmer that people get frustrated very fast when trying functional. I tried once and wasn't convinced that the benefits are worth the limitations. Later i met an earlier colleague and he was very enthusiastic about haskell. For a "normal" programmer functional programming is pretty hard at the beginning.
Bah. You are thinking about variables the wrong way.
Typically, C style programmers think of variables as bins in which to put values.
What you should think of variables as is aliases for values.
This way you won't need mutable variables, and come to see them as the abhorrence they are.
The compiler should make the code use the available registers optimally, not the programmer. This isn't the 20th century anymore. Nary a programmer even knows how the registers will be used with dynamic superpipelined out-of-order execution on a multi-core processor with parallel arithmetic and logic units and with branch prediction in speculative execution pipelines and multi-layer caches anyway.
So glad you put this out, I was just starting to teach myself Haskell
6:35
When the java intro teacher sees students checking if 2 strings are the same with str1 == str2
It's been years since I used Erlang. It was actually fun to build a prototype for my last project during my internship.
not sure if you guys will read this, but the English subtitles seem auto-generated (even though they were seemingly manually uploaded), they're full of errors and strange notation with square brackets.
I don't know the right words for talking about programming languages, but I have a question, so I'll just try my best…
Regarding higher level programming languages, such as the one this video's about… Do the things that make it up, have a direct equivalent in a lower level language that's not machine code? Because one way I'm imagining how it works, is that someone decided on a list of things that it ought to be able to do, and then built those things with a lower level language, by going over them with a fine tooth comb to find bugs, spending a lot of time to make sure each one does what they mean it to. Then you use those things to build your program, like building a machine out of off the shelf assemblies of parts, like a motherboard is assembled from lots of little electronics, such as capacitors, resistors, chips, etc., and the parts can be equated to a low level language, and manufacturing process to make all of those individual parts is the equivalent of machine code.
It is true that plenty of languages are built on lower level languages. I only really see examples where the compiler is written in C(++). Beyond that though, there's assembly which is a little higher level than machine code but not by much. With the introduction of intermediary languages like webassembly, you can often compile to something that is completely detached from the computer's hardware implementation
Daniel Vasquez,
Thanks!
I have been studying Haskell for some years. I keep getting stuck on understanding monads. The term comes from Leibniz and I pretty well know what he meant with it.
But what it has to do with Haskell I just can’t figure out. A video that explains what a monad is and how it is used would be very welcome.
Additionally, part of why local variables aren't side effects aside from how they are allocated on the stack is the same as the constant of integration.
Does a functional programming language actually DO something that a language like C, C++, or C# can't do, or is it more that it reduces what can be done in order to enforce an opinionated design style that reduces the probability of bugs?
CybeargPlays You're referring to a thing called the Church-Turing thesis. I suggest you spend some time on Wikipedia looking at it. There are some extremely deep rabbit holes to get lost in if you want. Lambda calculus and Turing machines are exactly identical. They have exactly equal capabilities because anything that can be defined as a list of instructions in a Turing machine can be defined recursively with lambda calculus, and vice versa.
CybeargPlays
It allows for a level of implicit parallelism. In other words, you can write code a program without worrying about parallelism at all, and still have it run in parallel. Sure, that might not be too big of a deal if you're only working with a few cores, but when you're working with systems with tens to hundreds, perhaps even thousands of CPU cores, all of which need to be running very complex logic (so not like GPU programming), it makes programming a hell of a lot easier.
Basically, the restraints put in place still allow you to do everything you normally could, you just have to do it in a slightly different way. The restraints make it easier for the compiler to reason about you code, and do very powerful optimizations that otherwise would be very difficult and tedious if done by the programmer.
The age of their massively parallel CPUs is coming. Just look at Adapteva's Epiphany V, coming out next year. How would you program a 1024 core CPU?
You can do functional programing in C, C++ or C#, but they are not designed for this in mind, so it won't be as nice as in F#, Haskell or OCaml for example.
It's not so much a reduction of what can be done than a different approach. Haskell can manipulate things like infinite list easily thanks to it's laziness, which would be harder to do in C... Same thing for parallelism, type inference, etc. But if you are writing a low level driver for example, C would be a better fit, because you don't need these features but you need the raw access to the memory and knowledge of the exact sequence of instructions realized by the computer. If you are taking in a lot of messages and trying to work out if they are spam or not at Facebook scale, you want the massive parallelism that functional programming gives you.
But yeah, in terms of "What computations can you do", most programming languages are completely equivalent (keyword: Turing completeness)
To answer OP's question: No... and Yes.
No: In terms of what they are able to compute. For example, Haskell and C are equivalent.
Yes: There are features in many languages that have absolutely no equivalent C-ish languages. To make things concrete, let's do Haskell and C* (pick your poison). Haskell's type system can actually *enforce* what API callbacks are able to accept at quite a granular level. This was alluded to in the video with the "no leaking" library. Unlike C*, Haskell has return-type polymorphism. So next time you read that article that claims C# has monads, just remember their API's can never be generic. What a drag :)
6:36-6:38 startled me. :)
Out of curiosity, does anyone know what laptop brand he's got there?
This man represents perfectly the meaning of passion, easy to tell :)
But what can you actually DO with functional programming? If there can be no side effects, it seems to me that your programs couldn't actually do anything, other than have your main() function return some value at the end. Where is the action?
I'm not sure about other functional programming languages, but Haskell solves this problem via monads.
Consider the high-level minimum number of inputs and outputs you need in a program. Usually, even in a very complex one it boils down to very few. In a 3D game there are the controls as input which output to set of changes to be applied to internal world representation. Then that representation is input to an audio/video output.
"I didn't think there was spam on facebook!" man that's aged like milk.
6:31 I have to say, I didn't see this coming. He surprised me.
That was a better explanation than we ever got at university...
That said, I find find the premise of it a bit odd. I *want* functions to be able to have side effects, encapsulation is one of the major foundations of object orientated programming... call a member function, have it update something, and (optionally) return another value... the same in C operating on global variables...
I would argue it is more reliable to have well defined side effects than to go without them at all. A compiler could also easily tell you if a function referenced anything external to itself, as when compiled in isolation anything external would be unlinkable.
You can still have side effects in functional programming languages. You can take a look at the IO monad of haskell.
Does this mean we'll get Simon Peyton Jones too? (All these sorts of Haskell guys are awesome.)
Yeah! Yeah! And Phil Wadler and Simon Marlow!
Phil Wadler would be amazing. I might resubscribe then! :D
Wonder if the guys of ***** are reading these. Another great one would be Simon Peyton Jones
He make it sound like functional programming is something new. I thought it predated most "conventional" programming languages (like LISP from '58).
I think of functional programming and side effects like this:
A = B, where B is a function or operation. While we do this implicitly in math, we specify to computers the Boolean operators ==, and ===.
Ultimately, A can be represented by whatever by is on the right so long as A == B is true. However A === B is false in a pure function. While A and B may have equal values, what happens to B is not directly happening to A.
Take 7=4+3. 7 is 7, 4+3 is 4+3. In programming = would be an assignment, but in math it's a == in programming syntax. 7 can be represented by really any infinite combination of operations. In 7=4+3, 7 is never being directly changed or manipulated.
A pure function's output is constant given the same inputs
A pure function is useless.
I notice he completely ignored the dependency hell of Haskell. I tried getting into it... but the constant need to add newer/older versions of libraries to make other bits work properly was incredibly frustrating.
Could be nice if you made a video on Kaspersky Lab's new secure operating system.
I love this guy's voice
More of John Hughes please!
I love using Haskell, thanks for the video!
4:10 The creators of Haskell and I will obviously never be friends.
If i want to learn much of functional programming and related concepts which two should i choose out of haskell, clojure, racket, scala. can anyone give me a detailed explanation.
You shouldn't chose to lean functional programming, in the first place. It's useless.
Go Haskell or ask chatgpt
to all nerds, its not airline its erlang
Fantastically explained, thank you very much sir!
If you don't specify all or correct requirements to the quickcheck there still will be gaps in the tests, so what does quickcheck solve? Is it trying to bring easier syntax (implementation) to describe a unit test?
coolluckyme2007 Pretty much, it's a really handy way of checking that a property holds true for a lot of inputs (not just the ones that we worked out by hand). You should test static data (e.g. data that has broken the code before) and also dynamic tests which quick check does. Its a really amazing tool that I have been saved by a few times
it sounds similar to "behavior-driven development" or even test-driven development
BDD and TDD are methodologies-write tests first, then implement to fulfill those tests-whereas QuickCheck is a program to empower those methodlogies.
Quick check can't solve core issue with testing correctness of programs. Writing a test that checks that function does what it's supposed to? How do you know the results? By writing the function again in the test? And then test the test's test's tests.... It can only be used to check simple properties, like the length of the output. And to get any decent coverage you have to still write all these property-checks.. and on top of that you have to write a generator for valid inputs. Many functions have very complex scenarios where they don't throw an exception, so writing a generator that randoly manages to generate valid inputs is harder than writing the test itself. Nothing about this is automatically generated (and it can't ever be).
was falling asleep as this was playing, at 6:35 I became filled with panic and fear
cool. maybe I'll check out some functional coding.
If you already know some non-functional programming, be prepared to forget everything you've learned. Functional programming is fundamentally different. It's not harder, really, and if you learn it as your first language many people find it easier than imperative programming (what most languages are). But the more you are used to imperative programming, the weirder functional programming tends to seem. Being able to think in the ways both require, though, is tremendously beneficial.
Dustin Rodriguez I like math a lot, will that help?
Bradley Bauer Absolutely that will help! Functions in functional programming are much more like mathematical functions than the procedures in imperative languages that get called 'functions'.
I love Scala; it was the subject of my 1-year independent study project.
One thing I don't catch is what he said at 6:20 - I mean you can have the same safe parallelism if you do a pass by value and spin-off two threads in a conventional program no?
I rly liked when he explainend the "MODIFYING DATA SOMEWHERE ELSE!!" part 🤣