Re: [OT] Teaching Haskell in High School
Michael Sperber writes: This seems like a backwards way of approaching teaching the intro course. I like to look at it as a a track. (Besides, is this really suitable material for beginners, let alone high school students?) Ah, there's the catch. They are not beginners; they are CS students who already learned about Java. When it comes to other disciplines and high school students you're right that TeachScheme is ahead of us and we know we have a long way to go. Cheers, Arjan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
Arjan == Arjan van IJzendoorn [EMAIL PROTECTED] writes: Arjan Good point, but there are fundamental differences between Arjan Scheme and Haskell and our whole teaching here in Utrecht is Arjan heavily geared towards Haskell: we really need laziness to Arjan write our parsers and our attribute grammars, This seems like a backwards way of approaching teaching the intro course. (Besides, is this really suitable material for beginners, let alone high school students?) It's the common method to specify We must do this, that, and this in the intro course and work backwards towards the didactics. I once was a strong proponent of the same method, but I came to realize that it's necessary to abandon stuff that I don't know how to teach well to beginners. I now have a poster in my apartment saying Kill your darlings. (A Faulkner quote, for those who must know.) This is what differentiates HtDP from all other intro curriculi I've seen: it *really* isn't about Scheme, and *nothing* is heavily geared towards Scheme. It's about programming and problem solving, and it prepares you for learning the language you need to know to produce software. (In fact, even if you want to produce actual software in Scheme, you'd be expected to take another course after HtDP.) Arjan we believe that static typing is the way to go for more robust Arjan software, we think that algebraic data types are a great way to Arjan model data and so on. Sure. But you'll notice that HtDP *does* use a completely type-centric approach to teaching, along with algebraic data types. And the fact that you would like to apply Haskell to professional software engineering and believe static types are the way to go there says nothing about the suitability of Haskell for intro teaching. Teach them Haskell, by all means. Helium seems to be a great effort directed at that, and I'm glad *someone* in the community finally caught on to the problems you're solving. But if you want Haskell to be as broadly applicable to intro teaching for non-CS majors as HtDP/TeachScheme!, you have a long way to go. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
Paul == Paul Hudak [EMAIL PROTECTED] writes: Paul I can't resist jumping in on this one: Sure :-) Haskell just has some terrible properties when it comes to teaching beginners. Among them are the complex and easy-to-get-wrong syntax, the available programming environments which are OK for developers but awful for beginners. There's also a dearth of good textbooks at the level you need. Haskell is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Scheme. Paul I have spent many years teaching both Scheme and Haskell to beginners, Paul and I would have to say that Haskell syntax has never been a serious Paul problem, certainly no more than Scheme's parentheses. It is true that Paul there is a lack of good programming environments, although Hugs is Paul pretty easy to use, and things like Helium should be even better. (I Paul won't say much about textbooks since I wrote one that I think is pretty Paul good for beginners :-) Finally, aside from extraneous type error Paul messages (which Helium should do much better at), I claim that Haskell's Paul type system is BETTER for beginners compared to having no type system at Paul all. As for the last point above, I could just as easily say that Paul Scheme is very easy to learn (and an excellent choice for a 2nd or 3rd Paul language) when you know Haskell. Here are some observations I've made when teaching Haskell for the first time which are relevant when you're trying them out on beginners: - With the programming environment, it isn't just a question of being easier to use: in my experience, environments like Hugs (or any Scheme environment other than DrScheme) work for some, but frustrate many beginners because they don't enable them to fix trivial mistakes which they're bound to make in the first couple of weeks. These are *crucial* to the overall success of an intro course. The TeachScheme! folks had to work a long time on getting DrScheme to provide the feedback needed to alleviate this problem. Haskell systems just don't have this kind of investment. (I'm glad Helium showed up, and I'm sure to try it out soon.) - In theory, static typing is good because it helps spot bugs in your program early. However, the current state of the art is such that the type error messages in Haskell systems are not sufficiently helpful (in fact, often misleading) when it comes to finding the actual source of the problem. You're saying aside from extraneous type error messages---but these are *exactly* the problem. Certainly, the messages from Hugs and GHC often frustrate beginners (and not just beginners in programming---I've seen quite a few students who were learning Haskell as a 3rd or 4th language give up because of this). Again, Helium may be an improvement, but I suspect that the underlying problem is deeply rooted. - I've written between 1 and 10 lines of code in Haskell, and I still do things like: - look up syntax in a book - getting the alignment wrong - using a name twice in a recursive let, leading to infinite recursion Scheme syntax is just *way* smaller than Haskell syntax, and, while it may not constitute a serious problem in any given course, it certainly eats up less space when you explain it. Here are some other aspects of Haskell syntax which---in my experience---are confusing for beginners: - The syntax for ordinary variables and type variables are the same. In fact, many examples by Great Haskell Programmers use a variable s (for instance) to denote a value of type s. Beginners often have trouble understanding and distinguishing the concepts of variables and type variables, and this makes it worse. - The same holds generally for the type syntax which is analogous to the value syntax. - I don't know what kind of beginners you're talking about exactly. The original poster was asking about high school. With *CS* beginners (or beginners in some related field) different rules apply than for the average population. If these kids have problems early on, they're just bound to leave programming and never come back (or much later). I'm sure some of you have didactic concepts to get around these problems---but, as you mention, they sure aren't published anywhere, much less in a comprehensive form as HtDP, and the tools don't exist with the same quality as DrScheme. There's much more to say---about things like motivating examples with GUIs and web servers---which DrScheme has in a form accessible to beginners, but you can all read up on that in the TeachScheme! material. Haskell has great potential to be a wonderful and useful language for software development and research. It often pains me to see the efforts of the functional programming community (which is small enough as it is) fragmented by the My language is the best for *everything* attitude. For intro teaching, the TeachScheme! have
Re: [OT] Teaching Haskell in High School
Hello all, Michael Sperber wrote: I really recommend looking at the TeachScheme! curriculum and the How to Design Programs curriculum. Here are two URLs: I believe that the environment students work in is very important and can help them learn languages quicker. And so the TeachScheme programming environment is something I'm jealous of and my compliments to the people who made it. Here in Utrecht we will try to do the same for Haskell with Helium: a cool programming environment and the best compiler messages ever (we still have some tricks up our sleeve for the near future). http://www.teach-scheme.org/ I've looked at the PPT presentation and it looks like a fine commercial for functional programming. It could easily be adapted to Haskell and the syntax would be even closer to their mathematical definitions. But I don't want to argue about syntax, because that will not get us anywhere. Let the people who love Haskell try and make an environment (and by that I also include books, presentations and what not) that will make functional programming nice to learn, maybe even in high school. We will do our bit here with Helium so that the Haskell textbooks can be used with Helium. Yes, that does mean adding type classes, but not the whole machinery. If we support Eq, Ord, Show and Num with a limited number of instances, chapters 1 to 11 of Hudak's book can be used without modification. And importantly, the type errors can still be clear! No Cannot find Num instance of Char for the expression 1+'a' but The character 'a' is not a number and + expects one (or something along that line). Oh yes, we'll need SOEGraphics, too, but who knows... If we think Haskell is good for high schools and for using in other courses (like logic and so on), let's try and prove it! Kind regards, Arjan van IJzendoorn PS: What does [OT] stand for? Off topic? I don't think this is off topic. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
On Friday, 2003-02-07, 12:31, CET, Arjan van IJzendoorn wrote: [...] Yes, that does mean adding type classes, but not the whole machinery. If we support Eq, Ord, Show and Num with a limited number of instances, chapters 1 to 11 of Hudak's book can be used without modification. I just have had a look at Helium and think that at least a deriving mechanism is absolutely needed. The need to write down obvious implementations for equality is very disturbing, IMHO. Furthermore, I think, the need to state equality functions explicitely as paramters of certain functions makes learning harder and not easier. But it's an interesting project. Keep going on it. [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
Hello all, Michael Sperber wrote: - With the programming environment, it isn't just a question of being easier to use: in my experience, environments like Hugs (or any Scheme environment other than DrScheme) work for some, but frustrate many beginners because they don't enable them to fix trivial mistakes which they're bound to make in the first couple of weeks. I completely agree. I've downloaded and installed DrScheme and I must say the environment is really nice: it looks good, helps you to layout your program, matches parentheses and so on. The quality of the messages, however, is not as good as I would have expected. I am a beginning Scheme programmer and here's something I encountered: (define (length2 xs) (cond [(empty? xs) 0] [else (+1 (length2 (rest xs)))])) (length2 (cons 3 (cons 7 empty))) procedure application: expected procedure, given: 1; arguments were: 1 The definition is accepted but when use it I get an error I don't understand. I should note that the environment neatly indicates that (+1 (length2 (rest xs))) is the problem. I've browsed the documentation, found a definition of length and saw that the only difference was a space character between + and 1. That couldn't be it, could it? But it was. Apparently Scheme supports a unary plus, but still the message was wrong and should have read: procedure application: expected procedure, given: +1; arguments were: 1 I think it is important that error messages show exactly what was entered by the user (+1 and not 1) and that's why in Helium we remember each little detail in the abstract syntax tree. I still don't know what arguments were: 1 means. Does it refer to the number of arguments? The TeachScheme! folks had to work a long time on getting DrScheme to provide the feedback needed to alleviate this problem. That's a really good point. We should look at the errors students actually make and not at the errors we make or just make an educated guess. For that reason, Helium has a logging facility built in which sends a server the programs containing errors. This wealth of information can now be used to give hints for type errors that occur often and to improve other kinds of errors. [Don't worry, the version distributed via the web does not contain the logging facility; only the version in our labs has that piece of code compiled in]. - In theory, static typing is good because it helps spot bugs in your program early. However, the current state of the art is such that the type error messages in Haskell systems are not sufficiently helpful (in fact, often misleading) when it comes to finding the actual source of the problem. True. I've also seen people being disappointed in the language Haskell because of the message of the compiler/interpreter. But then I wondered: how can dynamic typing improve on this? So I made a type error in my length2 example: (define (length2 xs) (cond [(empty? xs) 0] [else (+ 1 (rest xs))])) (length2 (cons 2 empty)) +: expects type number as 2nd argument, given: empty; other arguments were: 1 Perfect. I know immediately what the problem is and I can fix it. [The fact that a type error only shows up when you actually reach to code is a pity, because you may submit a lab assignment that still somewhere tries to add a number to a list.] But how is this different from the Helium message: (2,20): Type error in infix application *** Expression : 1 + xs *** Term : xs *** Type : [a] *** Does not match : Int It contains exactly the same information; invisible to the user for now is that we also now where the expresion ends so that we can do highlighting in the future. Maybe Michael is referring to what Hugs says about this program: ERROR C:\docs\Bla.hs:1 - Illegal Haskell 98 class constraint in inferred type *** Expression : mylength2 *** Type : Num [a] = [a] - [a] Wrong line number and a very confusing message. We must keep in mind though that no Haskell compiler so far was designed primarily with helpful messages in mind. Again, Helium may be an improvement, but I suspect that the underlying problem is deeply rooted. The underlying problem may be the inference algorithm used in most compilers. We use a radically different approach which allows us to determine much more information and point at different origins of the error when compared to Hindley Milner based inferencing. If there are three uses of a variable as a Bool and one as an Int we can say that probably the Int usage is wrong. - The syntax for ordinary variables and type variables are the same. That's just how you teach it. You can 'raise' hords of students believing that type variables are always called a, b and c and normal variables use longer, more informative names. As Larry Wall put it: you can write assembly in any language. - The same holds generally for the type syntax which is analogous to the value syntax. I use different
Re: [OT] Teaching Haskell in High School
On Friday, 2003-02-07, 14:41, CET, Arjan van IJzendoorn wrote: [...] For that reason, Helium has a logging facility built in which sends a server the programs containing errors. Do you tell your students about the existence of this facility? [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [OT] Teaching Haskell in High School
On Friday, February 07, 2003 7:41 AM, Arjan van IJzendoorn
[SMTP:[EMAIL PROTECTED]] wrote:
The quality of the messages, however, is not as good as I would have
expected. I am a beginning Scheme programmer ...
Then you should have set the language to Beginning Student or
Beginning Student with List Abbreviations.
Seriously.
A nice thing about the DrScheme environment is that it allows
languages to be layered. Instructors don't have to wave their arms
ands say pay no attention to 'public static void' and 'String[] args'
and 'class TestExp {' just to begin writing simple programs.
The DrScheme languages are restricted subsets of Scheme. The same
could certainly be done in a learning environment for Haskell, but is
more difficult in Java or C++. Even if the student is told to ignore
some things for now, many of the problems they have are often caused by
not understanding the things they're supposed to be ignoring--which can
be incredibly frustrating.
If you had set the DrScheme language to one of the two Beginning
Student levels, you would have seen:
function call: expected a defined name or a primitive operation
name after an open parenthesis, but found a number
And +1 would have been highlighted. This would have been reported
when you entered the *definition* for length2, not when you applied it.
Switch to Intermediate Student, and you get:
function call: expected a name after an open parenthesis, but
found a number
With +1 highlighted, at definition of length2.
Switch to Intermediate Student with lambda or Advanced Student,
and the definition is accepted, but the application (to a non-empty
list) reports:
procedure application: expected procedure, given: 1; arguments
were: 0
I think it is important that error messages show exactly what was
entered by the user (+1 and not 1) and that's why in Helium we
remember each little detail in the abstract syntax tree.
Excellent idea.
I still don't know what arguments were: 1 means. Does it refer to
the number of arguments?
Are you sure you it said that? Mine doesn't ;). I expect arguments
were: 0. It was complaining about trying to apply 1 to the
argument that is the value of (length2 empty), which should be zero,
no?
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
Hello again, Kevin suggested: Then you should have set the language to Beginning Student or Beginning Student with List Abbreviations. You're right. That makes the messages much better. I switched to 'Advanced' level because I thought that something was possibly not accepted because it was too difficult. My fault. Wolfgang asked: [...logging facility in Helium...] Do you tell your students about the existence of this facility? We certainly do. They don't seem to mind; I even feel that they think it's nice to help research. I just have had a look at Helium and think that at least a deriving mechanism is absolutely needed. There is 'show' function for each data type you write down. Eq and Ord are not generated but we will do that; we will need it anyway for our simple class system. Furthermore, I think, the need to state equality functions explicitely as paramters of certain functions makes learning harder and not easier. I don't know. Could be. We'll probably provide two different Preludes, one with and one without overloading. This would compare to the language levels in DrScheme. A lot is possible in this area. But it's an interesting project. Keep going on it. Don't worry. We just started... Cheers, Arjan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
Hal == Hal Daume, Hal writes: Hal Hi all, Hal Before getting in to this, let me preface my question(s) with a note that Hal I have checked through the Haskell in Education web page and have found Hal various links off there of interest (and I've googled, etc. In Hal short: I've done my homework). Hal That said, I've been in rather close correspondence with my math/computer Hal science teacher from high school. When I first took CS there, they taught Hal Pascal (a year early they had been teaching Scheme). They switched over Hal to VB (alas) recently and have been teaching that for a few years now. Hal The teacher really wants to get away from VB, but is having a somewhat Hal difficult time deciding what to go to. The two most promising options are Hal Haskell and Java. I really recommend looking at the TeachScheme! curriculum and the How to Design Programs curriculum. Here are two URLs: http://www.teach-scheme.org/ http://www.htdp.org/ This works exceptionally well at the High School level (I know that earlier attempts to do this with Scheme failed---this one is very different), and has been extensively applied with great success---also and especially in conjunction with the AP curriculum and/or a course on Java based on the same methodology. There's a wealth of software and material, and the TeachScheme! program offers (mostly free) workshops on this. Haskell just has some terrible properties when it comes to teaching beginners. Among them are the complex and easy-to-get-wrong syntax, the available programming environments which are OK for developers but awful for beginners. There's also a dearth of good textbooks at the level you need. Haskell is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Scheme. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
I can't resist jumping in on this one: Haskell just has some terrible properties when it comes to teaching beginners. Among them are the complex and easy-to-get-wrong syntax, the available programming environments which are OK for developers but awful for beginners. There's also a dearth of good textbooks at the level you need. Haskell is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Scheme. I have spent many years teaching both Scheme and Haskell to beginners, and I would have to say that Haskell syntax has never been a serious problem, certainly no more than Scheme's parentheses. It is true that there is a lack of good programming environments, although Hugs is pretty easy to use, and things like Helium should be even better. (I won't say much about textbooks since I wrote one that I think is pretty good for beginners :-) Finally, aside from extraneous type error messages (which Helium should do much better at), I claim that Haskell's type system is BETTER for beginners compared to having no type system at all. As for the last point above, I could just as easily say that Scheme is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Haskell. Now, having said all this, I will add that I have the greatest respect for the TeachScheme project, and I wish that we had something as well developed for Haskell! -Paul ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [OT] Teaching Haskell in High School
Don't forget Helium (recently announced) http://www.cs.uu.nl/~afie/helium/index.html Also Manuel Chakravarty teaches Haskell to hordes. Simon | -Original Message- | From: Hal Daume III [mailto:[EMAIL PROTECTED]] | Sent: 04 February 2003 00:02 | To: Haskell Mailing List | Subject: [OT] Teaching Haskell in High School | | Hi all, | | Before getting in to this, let me preface my question(s) with a note that | I have checked through the Haskell in Education web page and have found | various links off there of interest (and I've googled, etc. In | short: I've done my homework). | | That said, I've been in rather close correspondence with my math/computer | science teacher from high school. When I first took CS there, they taught | Pascal (a year early they had been teaching Scheme). They switched over | to VB (alas) recently and have been teaching that for a few years now. | | The teacher really wants to get away from VB, but is having a somewhat | difficult time deciding what to go to. The two most promising options are | Haskell and Java. | | Aside from hype, etc., the primary advantage to Java is that the Advanced | Placement (AP) tests are in Java. For those of you unfamiliar with these, | high school students can take AP tests and then (typically) skip out of | first semester college courses. They're essentially proficiency exams. | | The way the computer science curriculum is set up at my old school is | essentially as either (a) an elective or (b) a replacement for senior year | math. The students in the course are usually about 2/3 juniors (16 year | olds) taking it as an elective and 1/3 seniors who want to get our of | senior year math :). Either way, they've both taken differential | calculus, algebra, etc. Note, however, that high school math in the | states is very rudimentary when it comes to things like induction and | proofs and things of this sort. | | Due to the fact that CS is essentially an alternative math course, I think | it would be interesting to teach Haskell. It would enable the instruction | of things the students wouldn't have come across in their ordinary math | studies, etc. | | However, I'm also well aware that Haskell is very difficult to learn (and, | I'd imagine, to teach). Given that this would in large part be a first | language for them and that they won't have a college-level math | background, do you think it would be too much to attempt to teach Haskell | at this level, and stick with Java? | | I'm really interested in any comments/experience/etc. that people have | that might assist the teacher (and, to some extent, me) make this | decision. | | Thanks in advance! | | - Hal | | | ___ | Haskell mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
John Peterson wrote: The downside of Haskell is that none of the regular implementations (ghc, hugs) are really right for this level of student. Type inference is an especially nasty problem. There also a number of gotcha's lurking in the language that cause problems. For exactly these reasons we have implemented Helium; not for replacing Haskell (we're very happy with Haskell), but for *learning* Haskell. There is no overloading, so types and type errors are easier to understand. The Helium compiler produces warnings for situations that are probably incorrect. I've found myself look at a program with a comparable problem as the one below for fifteen minutes until I saw what was happening (please look at the program with a non-proportional font like Courier for optimal confusion): filterr :: (a - Bool) - [a] - [a] filterr p [] = [] fi1terr p (x:xs) = if p x then x : filterr p xs else filterr p xs Hugs, which we used for teaching, doesn't say a word. GHC does if you helpful warnings if you pass the -Wall flag. Helium says: (2,9): Variable p is not used (3,1): Missing type signature: fi1terr :: (a - Bool) - [a] - [a] (3,1): Suspicious adjacent functions fi1terr and filterr I'm curious what the other gotcha's are that John refers to because it might give us inspiration for more warnings/language design decisions. Arjan http://www.cs.uu.nl/~afie/helium/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
John Peterson wrote: The downside of Haskell is that none of the regular implementations (ghc, hugs) are really right for this level of student. Type inference is an especially nasty problem. There also a number of gotcha's lurking in the language that cause problems. For exactly these reasons we have implemented Helium; not for replacing Haskell (we're very happy with Haskell), but for *learning* Haskell. There is no overloading, so types and type errors are easier to understand. The Helium compiler produces warnings for situations that are probably incorrect. I've found myself look at a program with a comparable problem as the one below for fifteen minutes until I saw what was happening (please look at the program with a non-proportional font like Courier for optimal confusion): filterr :: (a - Bool) - [a] - [a] filterr p [] = [] fi1terr p (x:xs) = if p x then x : filterr p xs else filterr p xs Hugs, which we used for teaching, doesn't say a word. GHC does give helpful warnings if you pass the -Wall flag. Helium says: (2,9): Variable p is not used (3,1): Missing type signature: fi1terr :: (a - Bool) - [a] - [a] (3,1): Suspicious adjacent functions fi1terr and filterr I'm curious what the other gotcha's are that John refers to because it might give us inspiration for more warnings/language design decisions. Arjan http://www.cs.uu.nl/~afie/helium/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School (fwd)
On Mon, 3 Feb 2003, Rex Page wrote: This matches my experience, too. When I've taught Haskell to first year college students, there have always been some hard core hackers who've been at it in C or VB or Perl or something like that for years, and they rarely take kindly to Haskell. The ones without any programming background do better. I think Haskell would be great for a high school math class. They could learn some logic and induction along with it, and get a few proofs back into the high school math curriculum. Rex Page Actually, this doesn't match my experience. I teach first years too, and I always have some hard core hackers. In my experience, they have the advantage that they already understand notions such as a formal syntax and an algorithm, as opposed to expecting that the computer will somehow know what they mean. They also have something concrete to compare Haskell against ... which often leads them to become real Haskell enthusiasts! But then again, my course emphasises real programming and real-world problem solving, at the expense of logic and induction. John Hughes ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
For exactly these reasons we have implemented Helium; not for replacing Haskell (we're very happy with Haskell), but for *learning* Haskell. There is no overloading, so types and type errors are easier to understand. The Helium compiler produces warnings for situations that are probably incorrect. I'm curious what the other gotcha's are that John refers to because it might give us inspiration for more warnings/language design decisions. I've been negligent in not playing with Helium yet - I'm sure that this sort of system is going to be a significant improvement for this sort of audience. I'm also hoping that Helium can be adapted into other problem domains which use typed functional languages. As far as language gotchas, the issue is much more in the way the programming environment responds to a problem than in the language design. If a system can generate a sensible response / suggestion when a student makes an error then I don't think there's any particular problem. Another issue is in how the material is presented - I think this makes a big difference in what errors a student is likely to encounter. When you teach in a slow, constructive manner I think you're less likely to encounter problems than in my case, where I was teaching from a mathematics perspective and asking students to transcribe their mathematical ideas directly into Haskell and hope that they work. Notationally, there were three problems that hit students hard and generated error messages that had nothing to do with their mistake. The numeric syntax requires digits on both sides of a decimal. Mistakes like a = .2 were extremely common. Unary minus was also a big problem - I solved this by requiring all negative number to be wrapped in parens. The varid / conid stuff also was a problem - it was hard to explain why a = 1 is OK and A = 1 isn't. This definitely was a problem with going straight into programming from math. There were a lot of problems with type errors. The numeric type classes pop up unexpectedly in error messages, rendering them cryptic. Monomorphism also caused some problems but as I recall it was the old Hugs that didn't handle monomorphism quite right anyway. Debugging was a serious problem - we basicly gave up on that. Since the programs were fairly short I could usually spot bugs fairly easily but I couldn't get students to do this on their own. Sorry if this isn't very precise - it's been a while. John ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [OT] Teaching Haskell in High School (fwd)
On Tue, 4 Feb 2003, David Bergman wrote: Rex wrote: This matches my experience, too. When I've taught Haskell to first year college students, there have always been some hard core hackers who've been at it in C or VB or Perl or something like that for years, and they rarely take kindly to Haskell. The ones without any programming background do better. I think Haskell would be great for a high school math class. They could learn some logic and induction along with it, and get a few proofs back into the high school math curriculum. Rex Page I have always had that same experience with any (more or less) declarative language. BUT, as soon as the hackers (well, maybe not VB programmers, they are kind of doomed...) have passed the initial frustration, and acquired the new way of thinking, they actually perform much better than the real beginners. /David Yes, I've seen the same thing with some of the people who come in with experience. Some are lost, but a few of them really embrace the expressiveness of a language like Haskell. Rex -- Forwarded message -- Date: Tue, 04 Feb 2003 03:03:03 +0100 From: Wolfgang Jeltsch [EMAIL PROTECTED] To: The Haskell Mailing List [EMAIL PROTECTED] Subject: Re: [OT] Teaching Haskell in High School On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote: [...] However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Hi, I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell. Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: No. [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote: [...] However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Hi, I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell. Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: No. [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School (fwd)
This matches my experience, too. When I've taught Haskell to first year college students, there have always been some hard core hackers who've been at it in C or VB or Perl or something like that for years, and they rarely take kindly to Haskell. The ones without any programming background do better. I think Haskell would be great for a high school math class. They could learn some logic and induction along with it, and get a few proofs back into the high school math curriculum. Rex Page -- Forwarded message -- Date: Tue, 04 Feb 2003 03:03:03 +0100 From: Wolfgang Jeltsch [EMAIL PROTECTED] To: The Haskell Mailing List [EMAIL PROTECTED] Subject: Re: [OT] Teaching Haskell in High School On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote: [...] However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Hi, I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell. Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: No. [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
I had the good fortune to teach Haskell to some thousand freshmen a few years ago, and noticed that some who did especially well had no previous programming experience. This supports Wolfgang Jeltsch's claim that Haskell is not inherently difficult to learn. I've taught similar numbers of students C++, and I find Haskell considerably easier to teach (and much easier on the conscience!). Freshmen innocent of programming experience are increasingly rare, however, so we have to deal mainly with students who've been trained to think not only imperatively but operationally. Their weak program-design skills, and their meager understanding of the excessively complicated languages they're using (C++, Java, ...), result in marathon debugging sessions, which they're been trained to accept as a normal part of software development. How such students respond to Haskell depends heavily on their attitude. Some feel lost without a debugger, and resist any nudge away from their operational thinking. The more open-minded students, on the other hand, recognize in Haskell a means of expressing computational ideas with far more economy than they are used to, and report that learning Haskell has improved their thinking about programming even if they never use Haskell again. Whether Haskell would be a good language for a high-school programming class (this thread's original question) depends on the class's goals. If it's intended as vocational training, i.e., direct preparation for employment, then some language more fashionable in industry would probably be appropriate. On the other hand, if it's intended as training in precise thinking, then Haskell can't be beat. Best, --Ham At 3:03 AM +0100 2/4/03, Wolfgang Jeltsch wrote: On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote: [...] However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Hi, I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell. Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: No. [...] Wolfgang -- -- Hamilton RichardsDepartment of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138Austin, Texas 78712-1188 [EMAIL PROTECTED][EMAIL PROTECTED] -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
I've also been working high school students a bit and functional programming is a great way to teach the principals of computation. The best results come when FP is applied to domains that get kids excited. I've had very good luck with Haskore as an excellent way to bring computation to a general audience. I'm also working on a student friendly version of Pan that should be releasable in a few more weeks. The downside of Haskell is that none of the regular implementations (ghc, hugs) are really right for this level of student. Type inference is an especially nasty problem. There also a number of gotcha's lurking in the language that cause problems. But even so with a little supervision everything works quite well. I think fundamentals of computing as found in Haskell are good for a general mathematics class as opposed to a computer class where you have to deal with curriculum defined by the AP test or intertwined with some specific software environment. John ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
