Learn to program in Haskell, lesson 2
Posted: Sat Aug 04, 2007 12:33 pm
Right. I've learned a lot from lessons 1 and 1.5, or rather the feedback to them, or rather the lack of it. Mainly that if I were a less honest guy, I'd pretend they were a test all along and that only hyperintelligent people would understand them without previous education in computer science. I'm not, though, so I'll say only this: Maybe if I'd taken my time and done an incredibly good job at making them as easy to understand as possible and you had had unlimited time for studying them, then you guys would have understood them. I hurried too much, and now I'm going to make up for it by a lesson that hopefully should really be both enlightening and understandable.
It's about the nature and purpose of programming, and if it seems short, it's not because I'm not saying much, it's because you aren't reading enough into it... oh, and also because lessons 1 and 1.5 *were* too long.
So, programming. What's it for? No, actually, let's do the simpler question first: What is it? Here's the definition that we'll be using:
Programming an engineering discipline for representing ideas clearly and formally, in languages that are understandable by humans and also computers.
And... that's it. That's part 1 of this lesson. I'm sure that you know at least something about the relation between programming and software (the former makes the latter), and what stuff on your computer is software (it's the part that you can't kick). Now meditate on software, and consider what it would be like if it actually were written according to this definition.
While meditating, take note that there are several paradigms of programming and programming languages, and it's likely that most of the software on your computer was not only not written in Haskell, but not even written in a functional language at all. There's a lot of reasons for this; There's historical accident, there's misconceptions, there's concerns about performance where none should exist, and then there are also some good reasons, but not very many. If you're really interested about what I mean with functional programming languages (such as Haskell itself), as opposed to for instance imperative ones, I can explain it, but it's not really a very interesting thing to know.
Now, what's programming good for? Actually, since we're be using Haskell, let's ask: What's Haskell good for? Well, I could just show you a list, but that wouldn't be very enlightening, so let's try this instead: While Haskell is particularly good for complex things such as compilers (programs that turn things in programming languages into things in machine languages so that computers can run them), theorem provers, various kinds of deep mathematical things, they're not all that Haskell can express. Just to take a couple of examples, it can also express games, music, websites, geometric designs, financial contracts, etc..
Each of these things, when done in Haskell, is built on the same abstractions: Functions, values, types, constructors, and... well, actually, those *are* pretty much the most important abstractions that you'll need in order to express the kinds of things that I listed above. There's a whole bunch of convenience features but it all comes down to a couple of primitive features. (a "primitive" is defined basically as, well, something that it all comes down to)
While you can make some use of some of the primitives without understanding all of them, it's going to be quite limited, as they're meant to be used together. Also, merely knowing the primitives is not going to make anything terribly convenient, so there's a whole bunch of things built from those primitives that you'll have to learn to use before you can actually do anything useful. Thus, it can be overwhelming to take it all in at once...
(end part 2 of actual lesson)
... and because it might be overwhelming, I'm going to have to ask a question I didn't intend to ask at first: Are you with me? If I make the coming lessons significantly more palatable and go in smaller chunks, and combine the lessons with some chats (more on this later), will you try to at least stay with me and tell me if you don't understand something?
This question is *not* here for my sake. I already know that Erik, and maybe Neike will be following this course in any case, and I want to write these lessons in order to sharpen my own understanding. It's for your sake: I can give you power to express ideas in ways you couldn't before, but I can't just pour the knowledge into your heads, you'll have to spend a while thinking about it and find out things that you don't understand. It will take some time and some work.
On the chats: You'll find me and lambdabot, my dutiful TA who will tirelessly evaluate expressions and infer types for you, on irc.xelium.net:#jm3u. If you can't be bothered to get an IRC client but have Java set up properly, you can go to http://www.student.oulu.fi/~arirahik/pj ... pplet.html , where I've set up an applet to automatically connect to that channel. That's a good place to catch me and ask questions about Haskell - with lambdabot right there it will be easy to demonstrate simple expressions and such. If you come in at a time when I'm not likely to be asleep, you should ask if I'm there and wait a while - it might take a while for me to respond.
If I somehow manage to get a lot of people interested, I'll try to arrange for some kind of online exercises in there. We'll have to decide on times for those but, well, that's for the future to take care of...
It's about the nature and purpose of programming, and if it seems short, it's not because I'm not saying much, it's because you aren't reading enough into it... oh, and also because lessons 1 and 1.5 *were* too long.
So, programming. What's it for? No, actually, let's do the simpler question first: What is it? Here's the definition that we'll be using:
Programming an engineering discipline for representing ideas clearly and formally, in languages that are understandable by humans and also computers.
And... that's it. That's part 1 of this lesson. I'm sure that you know at least something about the relation between programming and software (the former makes the latter), and what stuff on your computer is software (it's the part that you can't kick). Now meditate on software, and consider what it would be like if it actually were written according to this definition.
While meditating, take note that there are several paradigms of programming and programming languages, and it's likely that most of the software on your computer was not only not written in Haskell, but not even written in a functional language at all. There's a lot of reasons for this; There's historical accident, there's misconceptions, there's concerns about performance where none should exist, and then there are also some good reasons, but not very many. If you're really interested about what I mean with functional programming languages (such as Haskell itself), as opposed to for instance imperative ones, I can explain it, but it's not really a very interesting thing to know.
Now, what's programming good for? Actually, since we're be using Haskell, let's ask: What's Haskell good for? Well, I could just show you a list, but that wouldn't be very enlightening, so let's try this instead: While Haskell is particularly good for complex things such as compilers (programs that turn things in programming languages into things in machine languages so that computers can run them), theorem provers, various kinds of deep mathematical things, they're not all that Haskell can express. Just to take a couple of examples, it can also express games, music, websites, geometric designs, financial contracts, etc..
Each of these things, when done in Haskell, is built on the same abstractions: Functions, values, types, constructors, and... well, actually, those *are* pretty much the most important abstractions that you'll need in order to express the kinds of things that I listed above. There's a whole bunch of convenience features but it all comes down to a couple of primitive features. (a "primitive" is defined basically as, well, something that it all comes down to)
While you can make some use of some of the primitives without understanding all of them, it's going to be quite limited, as they're meant to be used together. Also, merely knowing the primitives is not going to make anything terribly convenient, so there's a whole bunch of things built from those primitives that you'll have to learn to use before you can actually do anything useful. Thus, it can be overwhelming to take it all in at once...
(end part 2 of actual lesson)
... and because it might be overwhelming, I'm going to have to ask a question I didn't intend to ask at first: Are you with me? If I make the coming lessons significantly more palatable and go in smaller chunks, and combine the lessons with some chats (more on this later), will you try to at least stay with me and tell me if you don't understand something?
This question is *not* here for my sake. I already know that Erik, and maybe Neike will be following this course in any case, and I want to write these lessons in order to sharpen my own understanding. It's for your sake: I can give you power to express ideas in ways you couldn't before, but I can't just pour the knowledge into your heads, you'll have to spend a while thinking about it and find out things that you don't understand. It will take some time and some work.
On the chats: You'll find me and lambdabot, my dutiful TA who will tirelessly evaluate expressions and infer types for you, on irc.xelium.net:#jm3u. If you can't be bothered to get an IRC client but have Java set up properly, you can go to http://www.student.oulu.fi/~arirahik/pj ... pplet.html , where I've set up an applet to automatically connect to that channel. That's a good place to catch me and ask questions about Haskell - with lambdabot right there it will be easy to demonstrate simple expressions and such. If you come in at a time when I'm not likely to be asleep, you should ask if I'm there and wait a while - it might take a while for me to respond.
If I somehow manage to get a lot of people interested, I'll try to arrange for some kind of online exercises in there. We'll have to decide on times for those but, well, that's for the future to take care of...
This is one thing I feel wasn't highlighted enough in my studies. We were pretty much told, "Yeah, there are other paradigms... but (fortunately, or unfortunately, or neutrally) you won't need more than an understanding for procedural and object-oriented programming in practise, really." Which is true, but I still love Haskell. But then, I like Assembly, too. And Object Pascal. Mmm, Object Pascal. (I pretty much like Object Pascal for its pedantry with types - it's not quite as awesome as Haskell in that regard, but it comes fairly damn close, and I wish more languages did that.)