8 ms·

Well, I'm pretty sure this is going to go badly for me in the end, but I might as well leave this here: https://ihateracket.com https://ihateracket.com

by acbart 7y ago

acbart 7y ago
And before any says it, yes, I do love the idea of students EVENTUALLY learning a Lisp/Racket kind of language before they graduate. I would even be happy with an entire course dedicated to it. But I don't want that to be the CS1. I've just seen it go so wrong for so long now.
- snazz 7y ago
  I think this is extremely fair. It's really hard to understand why anyone might want metaprogramming until you've tried programming without it (on something larger than the average intro-to-CS assignment). Having more libraries and resources is extremely useful from teaching to working in the real world. Most of the points in the article are valid, and I especially agree that Racket or another Scheme should be taught at some point later on. Maybe even implementing a Scheme as a final course project or something like that (although that might not make sense outside a compilers class...)
- abhiyerra 7y ago
  I actually really enjoyed 61A with Scheme at Berkeley. I think the benefit of learning Scheme to start is the flexibility of learning how more complex features like OOP, can be built off a simpler language. > Pascal is for building pyramids imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms--imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place. - Structure and Interpretations of Computer Programs
- badsavage 7y ago
  I had a beautiful beginning with a lisp like programming language when I was 8 or something. Every other languages have been disappointments until I found Clojure a few years ago. I hope you will get it some day.
  - acbart 7y ago
    And I hope you will learn some empathy some day and understand the perspective of others. We all have some growing to do, it seems.
    - emptysongglass 7y ago
      The only way I was able to grok programming was through Racket. I owe my confidence and understanding to Gregor Kizcales’ How to Code, which makes clear to this art student what a dozen other language tutorials in a dozen other languages could not. I deeply love Racket and give thanks to its makers.
      - acbart 7y ago
        Great! I'm glad you found a path to computing, that is truly wonderful! And I'm not surprised that this approach worked so well for someone. Now, let's make sure we're finding ways that can generalize. It's an important problem in the world today.
madhadron 7y ago
I'm actually glad I read that. I recommend HtDP and Racket semi-regularly because 1) the incidental complexity of getting started with DrRacket is so low and 2) I don't have a better recommendation for a book that covers the same fundamentals. Do you have suggestions to recommend instead?
- acbart 7y ago
  What kind of context are you looking for? What audience? Is a book the only option? In general, people learn from presentation of material, participation to demonstrate understanding, and then receiving feedback. They need to be motivated and engaged. If you're asking how I would suggest someone self-learn something, I would suggest that they find a cool project that they're excited by, and then offer resources based on that. Ideally ones with interactive feedback and tons of examples.
  - madhadron 7y ago
    I typically recommend it for someone entirely new to programming. I don't know where else to point them for something that gets down to the meat of conditionals, repetition, and functions and applying them to data structures with as little distraction. A book isn't the only option, certainly.
neilv 7y ago
If I understand correctly, you're making scholarly CS Education arguments relative to PbD and HtDP, correct? Like, before you, the professors behind HtDP did relative to SICP (though they chose a playful academic article title, rather than a domain name :)? On that, I'll to defer to you CSE people, to investigate and debate, in the onward progress of science. You're not, however, objecting to Racket itself, the practical programming language platform that enabled building the HtDP progessively-powerful teaching languages and their beginner IDE?
- chessturk 7y ago
  I too am curious about the author's opinions of SICP. As a self taught developer, SICP and HTDP gave me the classic "My-Eyes-Are-Open-And-Now-Can-See" experience. I didn't feel like it was something to take with me to business directly, but an explanation of how data and functions relate through show-not-tell. It's sort of saddening to me that the average CS student exposed to this stuff doesn't experience the sublime when S-expressions suddenly click, or whatever.
  - acbart 7y ago
    I love SICP, great ideas. Keep in mind I'm talking about your first real coding experience. You were a self-taught developer, right? Perhaps I'm over-inferring, but it sounds like you hit the curriculum right when you needed it. For about 80-90% of my students, that time wasn't right. The others, who were more like you, also probably got a lot of it. As I said in another part of the thread, having it later in the curriculum makes sense. I'd love to subject everyone to a Programming Languages course. At Virginia Tech, they called it Comparative Languages. Here at UD, there used to be a Junior level SICP course. I wasn't around for it, but I think it was brilliant and well-timed. A lot of the problem came with trying to move those realizations earlier when folks aren't as ready for it - plus, all the other associated problems I raised.
    - chessturk 7y ago
      I see what you're saying about placement in time of curriculum. You're right, and I came into HTDP and SICP after knowing 3-4 programming languages well enough to release production code in them, understood the differences between programming paradigms, and was coding full-time as a job. That's very different than a freshman with little or no knowledge of programming. I've wondered what my reaction would have been if I had started with something like SICP or HTDP, and wondered if it would've saved me some headache. It's interesting that your real world experiences reflect that it might not have been as enlightening as I wondered. Edit: "might NOT have been as enlightening..." Thanks for the reply :)
taeric 7y ago
The opening does leave a sour taste. You ack that there is little research, and then claim a pragmatic position. Your data section is compelling. Though, it reads close to the same arguments for why kids shouldn't learn calculus in grade school. So the questions I would have to counter this would be: * How stable has racket been compared to the alternatives? Specifically, how many texts in Java and python taught methods that are actually not good for user in industry? This is ironic, as the argument is they would be using an industry language. But they aren't, really. They are likely using an ancient dialect of an industry one. Heaven help you if you picked JavaScript. * Is there any data about how well the students do following each language choice? In particular, this should be easier to get. Do kids that skip the racket course generally do better than those that don't?
- kd0amg 7y ago
  Do kids that skip the racket course generally do better than those that don't? This is likely to have some confounding factors, considering the usual mechanics of skipping a university course.
  - taeric 7y ago
    Agreed, but that should favor the skippers. And we should see it in the data, still.
- snazz 7y ago
  What do you mean by “ancient dialect” of Java and Python? Even if they taught Java 7 and Python 2.5, it’s not a huge leap to comprehend modern language features. I’d argue that Racket is even more fast moving than either of them. I don’t think the goal is to teach “methods that are usable in industry” as much as it is to teach computer science. It’s probably easier to learn modern Python coming from old Python than it is coming from Racket anyway, but that’s completely irrelevant. I think your second question is sound, even though it might be difficult to test. I’d be interested in the answer to it (or better, the answer to the related question of whether the students taking the Python version fare better than those taking the Racket version).
layoutIfNeeded 7y ago
God, this site is awful on mobile. Why on Earth would you think that I want the title of the current paragraph take up half of my screen from the top??
- acbart 7y ago
  I used a default theme from Github, and then did my best to make it a little more mobile-friendly. However, I wanted to focus on the content and, you know, my actual job, instead of spending hours fixing CSS. Perhaps consider taking that energy and make a pull request with specific improvements to the layout?
  - oehtXRwMkIs 7y ago
    Could you use a different theme? Even on my laptop the top bar thing that follows you obstructs like 10% of the page for me. Granted it's because I'm usually zoomed in for the sake of my eyes but I think it's worth fixing.
    - acbart 7y ago
      I went in and killed the relevant CSS - hopefully that makes it a little easier to read?
      - layoutIfNeeded 7y ago
        Thanks, I no longer have complaints.
DonaldPShimoda 7y ago
I see your point, but I don't know that I feel you've done a good enough job defending it. (I say this as very much not an expert, but as someone who is merely very interested in the intersection of CS and education.) Racket was primarily designed for teaching and has been somewhat successful in that regard. I don't know of an empirical study, but if you attend a RacketCon or go to a Racket Summer School you will meet educators who talk about how Racket has positively affected their experience in education. But maybe part of the issue is using Racket for what it's meant to be used for. Racket is good for teaching computer science, which I'm contrasting with software engineering (often just called programming, although I don't like that). It seems like most CS programs at universities are really SWE programs in disguise. Of course, this is often what the students really want: a program to help them get jobs in industry. Racket is good for building a slightly more mathematical framework of programming than a language like Python. The functional nature of the language promotes thinking about problems in terms of data and their relations, instead of in terms of procedures and state manipulation which tends to be how imperative languages are learned. (This is not to say that imperative languages can't be used well, or can't be used in a "mathematical" way, but this tends in general not to be the case.) If the end-goal is to teach students how to approach programming mathematically, then they are more likely to learn better with Racket than Python. You will also have a problem now with students who have some prior CS knowledge disliking Racket because it doesn't aligned with their not-yet-fully-built notions of how programming languages work. The larger your classes, the more influence this factor will have. I think your survey ("Students do not like Racket") would be better if it were correlated with information like this. My gut feeling is that students with zero prior programming experience are likely to have a less extreme negative feeling of Racket than those who had previously learned a little Python, C, Java, Javascript, etc. The issue of students not using Racket later in their degree is certainly problematic. Matthew Flatt (one of the principle authors of Racket) taught Utah's intro course in Racket just twice. When I asked him why it didn't continue, he more or less indicated that he had a hard time with it because it caused problems for students with the rest of the degree program. They learned stuff fine in his class, but the subsequent semester relied on knowledge of Java, and this was no good. Schools where Racket does well are schools where the various curricula are more cohesive in this regard, such as Northeastern and Indiana. (Speaking of which, Indiana should go on your list. I'm pretty sure their intro course is taught in Racket.) You also claim that the Racket group have not published very much data, but you also are lacking the same data. For example, you say: > Despite being ten years old, there is relatively little research to demonstrate the value of “Design Recipes” as a pedagogical approach, especially one that has long term benefits. One research study by the group indicates that students may be more prepared to apply principles of Functional Decomposition through this approach than students who do not, based on studies of the Rainfall Problem. Is this unique to using Racket? It’s a reasonable hypothesis, but not a proven fact. but you don't provide evidence that it isn't the case, nor that Python is a better language for the same problem. I do believe there's value in expressing opinions without facts (or else I wouldn't be here!), but I think in this case your position would be significantly strengthened by having actual data to back up your claims. I'd suggest that maybe your issue with teaching Racket was multi-fold: (a) your students wanted industry-relevant languages (SWE vs CS) and Racket is not that (which indicates either a need for industry-relevant languages or else an explicit explanation of why Racket is a good introductory language); (b) you lacked support from other faculty so students could continue to learn in the Racket environment past their first semester; (c) you don't appear to be a proponent of the whole "Design Recipe" thing, which is kind of essential to the intended Racket teaching methodology. I also wonder about other factors, such as whether your TAs were good at helping with Racket. I want to make clear that I don't think you're wrong by necessity. It's entirely possible that Racket is actually bad for teaching computer science. But it's my opinion (as somebody who learned imperative languages first, Racket later) that your article does not really satisfy your claim, and I find that a little disappointing. As an aside, I might suggest looking more specifically at what Shriram Krishanmurthi is up to. He's the most education-focused of the original Racket group, leading initiatives like Bootstrap to great success. He's also pretty active on Twitter, so if you're feeling up to it you might post your article there and tag him in. ;) (I think he's also on HN but I've forgotten his handle.)
noelwelsh 7y ago
Two quick points on the other side: * Industry is moving towards FP. Teaching Python or Java is teaching students a way of programming that will increasingly be out of date * In my day to day programming (Scala) I lean very heavily on the concepts in the design recipes. Understand them and you can create correct code very quickly. No data here. Just something to think about.
- acbart 7y ago
  > Industry is moving towards FP. ... Citation required. My dad will be writing COBOL till the day he dies, and most of those lines of business logic in Java will bit rot before they get converted to Scala/Haskell/Something else. I thought you were going to make the more palatable argument that most modern languages refuse to stick to one paradigm. The fact that Java has lambdas now demonstrates the appeal of these other approaches. Saying that imperative programming will go out of date... Well, that's a bold claim. I vote we meet up in 20 years and whoever is wrong has to buy the other one a beer :)
  - noelwelsh 7y ago
    You misunderstand my point. OO was the dominant paradigm in the 1990s and 2000s, and legacy COBOL, C, etc. code still existed back then. Legacy code will continue to exist as the industry moves away from OO. New languages and frameworks are taking inspiration from FP: Typescript, React, Scala, Swift, and Rust are all examples. Even Java is moving in this direction. In the same way the majority of OO programs were not written in Smalltalk but instead in C++ (C with OO bolted on) or Java, FP programs won't be written in Haskell, but in languages that bridge the old and the new. The key idea of FP is static understanding of code. This drives everything else: "pure" functions, types, composition, etc. FP is not against effects and mutability. It's against uses of effects and mutability that make reasoning hard. Rust (affine types) shows you can have mutation will retaining reasoning about code.
rkido 7y ago
I would argue that some research is better than none, and that some intentionality in the design of a curriculum is better than an ad hoc curriculum. The design recipes give you an excellent foundation for transitioning to a statically-typed programming language with algebraic datatypes. If students are just going to learn Java or Python immediately afterwards, I think it's a waste.
- acbart 7y ago
  > Some research is better than none. Yes, so we should look at the relatively more massive amount of research done for languages like Java, Python, etc. SIGCSE and ICER and ITiCSE are full of them. We've learned a lot - learning is hard :) > Intentionality in the design of a curriculum is better than an ad hoc curriculum. I strongly agree. I wish I could impart to you how involved I am in Instructional Design with my work. I don't know if this will help, but here's a sample from what I was doing last year: https://acbart.github.io/python-sneks/ https://acbart.github.io/python-sneks/ > The design recipes give you an excellent foundation for transitioning to a statically-typed programming language with algebraic datatypes. I'm not clear that that's more than a theory. Even if it's true, is that necessarily the major goal in CS1? Perhaps, but you'll have to convince a few of my colleagues of that.
  - rkido 7y ago
    You wrote on ihateracket.com: > Which language should be used in a CS1? There isn’t very much research to suggest conclusively what makes the biggest difference in a classroom, and it doesn’t seem like the language debate will ever end. But now you're saying there's a massive amount of research for Java and Python — so I think we must be talking about two different things. > I'm not clear that that's more than a theory. It is less than a theory — it's my opinion based on my experience going through the edX How to Code series (closely based on HtDP and the design recipes). For example, sum types are taught as "Enumerations" [0], and the design recipe for enumerations looks suspiciously like "pattern matching in a language without pattern matching", as if to prime the student for a language that supports this more conveniently. Yet, if the student learns Java immediately after HtDP, they will have no use for this knowledge (and probably forget it), as it seems you need some convoluted boilerplate like the visitor pattern to emulate a sum type [1]. > Even if it's true, is that necessarily the major goal in CS1? Perhaps, but you'll have to convince a few of my colleagues of that. Given that the follow-up material to HtDP was called "How to Design Classes" and used Java [2], no I don't think this is a goal of (PbD's) CS1. I'm saying I think it should be to make the curriculum cohesive, and that HtDP is a wasted investment of the student's patience without related follow-up material. I really loved HtDP so I wish I could find such material. [0]: https://htdp.org/2019-02-24/part_one.html#%28part._sec~3aenums%29 https://htdp.org/2019-02-24/part_one.html#%28part._sec~3aenu... [1]: https://stackoverflow.com/questions/48143268/java-tagged-union-sum-types https://stackoverflow.com/questions/48143268/java-tagged-uni... [2]: https://programbydesign.org/materials https://programbydesign.org/materials (You can see it mentioned but it doesn't seem to exist anymore when you follow the links)

Well, I'm pretty sure this is going to go badly for me in the end, but I might as well leave this here: https://ihateracket.com https://ihateracket.com

by acbart 7y ago

Well, I'm pretty sure this is going to go badly for me in the end, but I might as well leave this here: https://ihateracket.com https://ihateracket.com

acbart 7y ago

And before any says it, yes, I do love the idea of students EVENTUALLY learning a Lisp/Racket kind of language before they graduate. I would even be happy with an entire course dedicated to it. But I don't want that to be the CS1. I've just seen it go so wrong for so long now.

snazz 7y ago
I think this is extremely fair. It's really hard to understand why anyone might want metaprogramming until you've tried programming without it (on something larger than the average intro-to-CS assignment). Having more libraries and resources is extremely useful from teaching to working in the real world. Most of the points in the article are valid, and I especially agree that Racket or another Scheme should be taught at some point later on. Maybe even implementing a Scheme as a final course project or something like that (although that might not make sense outside a compilers class...)
abhiyerra 7y ago
I actually really enjoyed 61A with Scheme at Berkeley. I think the benefit of learning Scheme to start is the flexibility of learning how more complex features like OOP, can be built off a simpler language. > Pascal is for building pyramids imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms--imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place. - Structure and Interpretations of Computer Programs
badsavage 7y ago
I had a beautiful beginning with a lisp like programming language when I was 8 or something. Every other languages have been disappointments until I found Clojure a few years ago. I hope you will get it some day.
- acbart 7y ago
  And I hope you will learn some empathy some day and understand the perspective of others. We all have some growing to do, it seems.
  - emptysongglass 7y ago
    The only way I was able to grok programming was through Racket. I owe my confidence and understanding to Gregor Kizcales’ How to Code, which makes clear to this art student what a dozen other language tutorials in a dozen other languages could not. I deeply love Racket and give thanks to its makers.
    - acbart 7y ago
      Great! I'm glad you found a path to computing, that is truly wonderful! And I'm not surprised that this approach worked so well for someone. Now, let's make sure we're finding ways that can generalize. It's an important problem in the world today.

madhadron 7y ago

I'm actually glad I read that. I recommend HtDP and Racket semi-regularly because 1) the incidental complexity of getting started with DrRacket is so low and 2) I don't have a better recommendation for a book that covers the same fundamentals. Do you have suggestions to recommend instead?

acbart 7y ago
What kind of context are you looking for? What audience? Is a book the only option? In general, people learn from presentation of material, participation to demonstrate understanding, and then receiving feedback. They need to be motivated and engaged. If you're asking how I would suggest someone self-learn something, I would suggest that they find a cool project that they're excited by, and then offer resources based on that. Ideally ones with interactive feedback and tons of examples.
- madhadron 7y ago
  I typically recommend it for someone entirely new to programming. I don't know where else to point them for something that gets down to the meat of conditionals, repetition, and functions and applying them to data structures with as little distraction. A book isn't the only option, certainly.

neilv 7y ago

If I understand correctly, you're making scholarly CS Education arguments relative to PbD and HtDP, correct? Like, before you, the professors behind HtDP did relative to SICP (though they chose a playful academic article title, rather than a domain name :)? On that, I'll to defer to you CSE people, to investigate and debate, in the onward progress of science. You're not, however, objecting to Racket itself, the practical programming language platform that enabled building the HtDP progessively-powerful teaching languages and their beginner IDE?

chessturk 7y ago
I too am curious about the author's opinions of SICP. As a self taught developer, SICP and HTDP gave me the classic "My-Eyes-Are-Open-And-Now-Can-See" experience. I didn't feel like it was something to take with me to business directly, but an explanation of how data and functions relate through show-not-tell. It's sort of saddening to me that the average CS student exposed to this stuff doesn't experience the sublime when S-expressions suddenly click, or whatever.
- acbart 7y ago
  I love SICP, great ideas. Keep in mind I'm talking about your first real coding experience. You were a self-taught developer, right? Perhaps I'm over-inferring, but it sounds like you hit the curriculum right when you needed it. For about 80-90% of my students, that time wasn't right. The others, who were more like you, also probably got a lot of it. As I said in another part of the thread, having it later in the curriculum makes sense. I'd love to subject everyone to a Programming Languages course. At Virginia Tech, they called it Comparative Languages. Here at UD, there used to be a Junior level SICP course. I wasn't around for it, but I think it was brilliant and well-timed. A lot of the problem came with trying to move those realizations earlier when folks aren't as ready for it - plus, all the other associated problems I raised.
  - chessturk 7y ago
    I see what you're saying about placement in time of curriculum. You're right, and I came into HTDP and SICP after knowing 3-4 programming languages well enough to release production code in them, understood the differences between programming paradigms, and was coding full-time as a job. That's very different than a freshman with little or no knowledge of programming. I've wondered what my reaction would have been if I had started with something like SICP or HTDP, and wondered if it would've saved me some headache. It's interesting that your real world experiences reflect that it might not have been as enlightening as I wondered. Edit: "might NOT have been as enlightening..." Thanks for the reply :)

taeric 7y ago

The opening does leave a sour taste. You ack that there is little research, and then claim a pragmatic position. Your data section is compelling. Though, it reads close to the same arguments for why kids shouldn't learn calculus in grade school. So the questions I would have to counter this would be: * How stable has racket been compared to the alternatives? Specifically, how many texts in Java and python taught methods that are actually not good for user in industry? This is ironic, as the argument is they would be using an industry language. But they aren't, really. They are likely using an ancient dialect of an industry one. Heaven help you if you picked JavaScript. * Is there any data about how well the students do following each language choice? In particular, this should be easier to get. Do kids that skip the racket course generally do better than those that don't?

kd0amg 7y ago
Do kids that skip the racket course generally do better than those that don't? This is likely to have some confounding factors, considering the usual mechanics of skipping a university course.
- taeric 7y ago
  Agreed, but that should favor the skippers. And we should see it in the data, still.
snazz 7y ago
What do you mean by “ancient dialect” of Java and Python? Even if they taught Java 7 and Python 2.5, it’s not a huge leap to comprehend modern language features. I’d argue that Racket is even more fast moving than either of them. I don’t think the goal is to teach “methods that are usable in industry” as much as it is to teach computer science. It’s probably easier to learn modern Python coming from old Python than it is coming from Racket anyway, but that’s completely irrelevant. I think your second question is sound, even though it might be difficult to test. I’d be interested in the answer to it (or better, the answer to the related question of whether the students taking the Python version fare better than those taking the Racket version).

layoutIfNeeded 7y ago

God, this site is awful on mobile. Why on Earth would you think that I want the title of the current paragraph take up half of my screen from the top??

acbart 7y ago
I used a default theme from Github, and then did my best to make it a little more mobile-friendly. However, I wanted to focus on the content and, you know, my actual job, instead of spending hours fixing CSS. Perhaps consider taking that energy and make a pull request with specific improvements to the layout?
- oehtXRwMkIs 7y ago
  Could you use a different theme? Even on my laptop the top bar thing that follows you obstructs like 10% of the page for me. Granted it's because I'm usually zoomed in for the sake of my eyes but I think it's worth fixing.
  - acbart 7y ago
    I went in and killed the relevant CSS - hopefully that makes it a little easier to read?
    - layoutIfNeeded 7y ago
      Thanks, I no longer have complaints.

DonaldPShimoda 7y ago

I see your point, but I don't know that I feel you've done a good enough job defending it. (I say this as very much not an expert, but as someone who is merely very interested in the intersection of CS and education.) Racket was primarily designed for teaching and has been somewhat successful in that regard. I don't know of an empirical study, but if you attend a RacketCon or go to a Racket Summer School you will meet educators who talk about how Racket has positively affected their experience in education. But maybe part of the issue is using Racket for what it's meant to be used for. Racket is good for teaching computer science, which I'm contrasting with software engineering (often just called programming, although I don't like that). It seems like most CS programs at universities are really SWE programs in disguise. Of course, this is often what the students really want: a program to help them get jobs in industry. Racket is good for building a slightly more mathematical framework of programming than a language like Python. The functional nature of the language promotes thinking about problems in terms of data and their relations, instead of in terms of procedures and state manipulation which tends to be how imperative languages are learned. (This is not to say that imperative languages can't be used well, or can't be used in a "mathematical" way, but this tends in general not to be the case.) If the end-goal is to teach students how to approach programming mathematically, then they are more likely to learn better with Racket than Python. You will also have a problem now with students who have some prior CS knowledge disliking Racket because it doesn't aligned with their not-yet-fully-built notions of how programming languages work. The larger your classes, the more influence this factor will have. I think your survey ("Students do not like Racket") would be better if it were correlated with information like this. My gut feeling is that students with zero prior programming experience are likely to have a less extreme negative feeling of Racket than those who had previously learned a little Python, C, Java, Javascript, etc. The issue of students not using Racket later in their degree is certainly problematic. Matthew Flatt (one of the principle authors of Racket) taught Utah's intro course in Racket just twice. When I asked him why it didn't continue, he more or less indicated that he had a hard time with it because it caused problems for students with the rest of the degree program. They learned stuff fine in his class, but the subsequent semester relied on knowledge of Java, and this was no good. Schools where Racket does well are schools where the various curricula are more cohesive in this regard, such as Northeastern and Indiana. (Speaking of which, Indiana should go on your list. I'm pretty sure their intro course is taught in Racket.) You also claim that the Racket group have not published very much data, but you also are lacking the same data. For example, you say: > Despite being ten years old, there is relatively little research to demonstrate the value of “Design Recipes” as a pedagogical approach, especially one that has long term benefits. One research study by the group indicates that students may be more prepared to apply principles of Functional Decomposition through this approach than students who do not, based on studies of the Rainfall Problem. Is this unique to using Racket? It’s a reasonable hypothesis, but not a proven fact. but you don't provide evidence that it isn't the case, nor that Python is a better language for the same problem. I do believe there's value in expressing opinions without facts (or else I wouldn't be here!), but I think in this case your position would be significantly strengthened by having actual data to back up your claims. I'd suggest that maybe your issue with teaching Racket was multi-fold: (a) your students wanted industry-relevant languages (SWE vs CS) and Racket is not that (which indicates either a need for industry-relevant languages or else an explicit explanation of why Racket is a good introductory language); (b) you lacked support from other faculty so students could continue to learn in the Racket environment past their first semester; (c) you don't appear to be a proponent of the whole "Design Recipe" thing, which is kind of essential to the intended Racket teaching methodology. I also wonder about other factors, such as whether your TAs were good at helping with Racket. I want to make clear that I don't think you're wrong by necessity. It's entirely possible that Racket is actually bad for teaching computer science. But it's my opinion (as somebody who learned imperative languages first, Racket later) that your article does not really satisfy your claim, and I find that a little disappointing. As an aside, I might suggest looking more specifically at what Shriram Krishanmurthi is up to. He's the most education-focused of the original Racket group, leading initiatives like Bootstrap to great success. He's also pretty active on Twitter, so if you're feeling up to it you might post your article there and tag him in. ;) (I think he's also on HN but I've forgotten his handle.)

noelwelsh 7y ago

Two quick points on the other side: * Industry is moving towards FP. Teaching Python or Java is teaching students a way of programming that will increasingly be out of date * In my day to day programming (Scala) I lean very heavily on the concepts in the design recipes. Understand them and you can create correct code very quickly. No data here. Just something to think about.

acbart 7y ago
> Industry is moving towards FP. ... Citation required. My dad will be writing COBOL till the day he dies, and most of those lines of business logic in Java will bit rot before they get converted to Scala/Haskell/Something else. I thought you were going to make the more palatable argument that most modern languages refuse to stick to one paradigm. The fact that Java has lambdas now demonstrates the appeal of these other approaches. Saying that imperative programming will go out of date... Well, that's a bold claim. I vote we meet up in 20 years and whoever is wrong has to buy the other one a beer :)
- noelwelsh 7y ago
  You misunderstand my point. OO was the dominant paradigm in the 1990s and 2000s, and legacy COBOL, C, etc. code still existed back then. Legacy code will continue to exist as the industry moves away from OO. New languages and frameworks are taking inspiration from FP: Typescript, React, Scala, Swift, and Rust are all examples. Even Java is moving in this direction. In the same way the majority of OO programs were not written in Smalltalk but instead in C++ (C with OO bolted on) or Java, FP programs won't be written in Haskell, but in languages that bridge the old and the new. The key idea of FP is static understanding of code. This drives everything else: "pure" functions, types, composition, etc. FP is not against effects and mutability. It's against uses of effects and mutability that make reasoning hard. Rust (affine types) shows you can have mutation will retaining reasoning about code.

rkido 7y ago

I would argue that some research is better than none, and that some intentionality in the design of a curriculum is better than an ad hoc curriculum. The design recipes give you an excellent foundation for transitioning to a statically-typed programming language with algebraic datatypes. If students are just going to learn Java or Python immediately afterwards, I think it's a waste.

acbart 7y ago
> Some research is better than none. Yes, so we should look at the relatively more massive amount of research done for languages like Java, Python, etc. SIGCSE and ICER and ITiCSE are full of them. We've learned a lot - learning is hard :) > Intentionality in the design of a curriculum is better than an ad hoc curriculum. I strongly agree. I wish I could impart to you how involved I am in Instructional Design with my work. I don't know if this will help, but here's a sample from what I was doing last year: https://acbart.github.io/python-sneks/ https://acbart.github.io/python-sneks/ > The design recipes give you an excellent foundation for transitioning to a statically-typed programming language with algebraic datatypes. I'm not clear that that's more than a theory. Even if it's true, is that necessarily the major goal in CS1? Perhaps, but you'll have to convince a few of my colleagues of that.
- rkido 7y ago
  You wrote on ihateracket.com: > Which language should be used in a CS1? There isn’t very much research to suggest conclusively what makes the biggest difference in a classroom, and it doesn’t seem like the language debate will ever end. But now you're saying there's a massive amount of research for Java and Python — so I think we must be talking about two different things. > I'm not clear that that's more than a theory. It is less than a theory — it's my opinion based on my experience going through the edX How to Code series (closely based on HtDP and the design recipes). For example, sum types are taught as "Enumerations" [0], and the design recipe for enumerations looks suspiciously like "pattern matching in a language without pattern matching", as if to prime the student for a language that supports this more conveniently. Yet, if the student learns Java immediately after HtDP, they will have no use for this knowledge (and probably forget it), as it seems you need some convoluted boilerplate like the visitor pattern to emulate a sum type [1]. > Even if it's true, is that necessarily the major goal in CS1? Perhaps, but you'll have to convince a few of my colleagues of that. Given that the follow-up material to HtDP was called "How to Design Classes" and used Java [2], no I don't think this is a goal of (PbD's) CS1. I'm saying I think it should be to make the curriculum cohesive, and that HtDP is a wasted investment of the student's patience without related follow-up material. I really loved HtDP so I wish I could find such material. [0]: https://htdp.org/2019-02-24/part_one.html#%28part._sec~3aenums%29 https://htdp.org/2019-02-24/part_one.html#%28part._sec~3aenu... [1]: https://stackoverflow.com/questions/48143268/java-tagged-union-sum-types https://stackoverflow.com/questions/48143268/java-tagged-uni... [2]: https://programbydesign.org/materials https://programbydesign.org/materials (You can see it mentioned but it doesn't seem to exist anymore when you follow the links)