7 ms·

Why learn Racket? A student's perspective

129 points by hydroxideOH- 5y ago

oltdaniel 5y ago
Comment unrelated to the article: I knew I know that blog theme from somewhere, turns out it is my own https://github.com/oltdaniel/dose https://github.com/oltdaniel/dose theme. Thanks for using it. Hope you like it. Comment related to the article: I always wanted to dive deeper into functional programming languages. Especially, because I more and more run into stuff, that is just simpler to model in a recursive pattern. Maybe I'll give it the a new try within the next weeks and see how far I come.
- hydroxideOH- 5y ago
  Thanks! I do like that theme and I only made a few tweaks to it with some of the code styling and the header. And I'd definitely recommend it, programming in FP languages has been a bit of an addiction for me.
jboynyc 5y ago
Nice writeup, keep it up!
- hydroxideOH- 5y ago
  Thank you!
- mark_l_watson 5y ago
  I agree, keep writing. I have spent a lot of my professional life using Lisp languages. Not as popular as Python, Java, etc., but Lisp (and other languages like Haskell) have a good effect on how we think about computation.
melony 5y ago
It is interesting that recursion is still considered to be so novel on blogs and forums. From what I have seen of current CS curriculums, recursion is usually taught in the first year immediately after introductory CS. It is almost impossible not to use recursion when dealing with tree structures (using an explicit stack takes a lot more code, most coding interviews don't ask for an iterative solution unless absolutely necessary).
- moron4hire 5y ago
  After 20 years of software development in a variety of languages and projects, I've come to the opinion that recursion really should be relegated to being a novelty. Few languages offer tail-call optimization. If we look at popularity of languages, then the likelihood any particular solution is going to end up in such a language is vanishingly small. For the remaining languages, fitting into the stack depth is easy to get wrong. It's easy to end up in an infinite loop that ends in an obscure error with a confusing, verbose, needle-in-hay-stack stack frame that over complicates debugging. And frankly, lots of programmers don't have a good handle on it, even the ones who studied CS in college, so asking them to maintain recursive code written by someone else usually ends pretty poorly. So when we consider that, actually, no, it's not true that using an explicit stack takes "a lot more code" (it's like, three extra lines), recursion starts to look more and more like a code smell, a smell indicating the originating programmer is more a temporarily-embarrassed mathematician than an engineer. To be clear, I have no problems conceiving of and implementing recursive solutions to problems. But every single one of my recursive solutions has eventually failed to survive contact with real life data. It might be next week when the code goes to production or it might be a year from now when the data processing needs grow, but I've eventually replaced them all. I'm not the only one with this opinion. Many safety regulations covering vehicles from cars to spacecraft explicitly ban recursion because of these issues. We need to just stop with the fetishising of math in software development.
  - dgb23 5y ago
    In web/gui programming it’s a good fit. Your data is a tree that you render on a screen, so it’s by default relatively shallow and not very big. It’s never going to blow the stack and the benefit of using recursion, closures and functional composition is you get clear, dense code and tend to make fatter data structures and more general code.
    - nonameiguess 5y ago
      Yep. Same thing with filesystems. Since they're meant for humans to traverse, finding a directory structure with deep enough nesting to blow up the process stack or hit a runtime recursion limit is sufficiently rare that you shouldn't even worry about it. I'm sure there are plenty of other examples where the practical limit you'll see in much lower than what an address space stack can fit. We had a task at an old job to create dependency and build trees of every service in the overall project and then operate on them. Even assuming a language runtime with a very small limit, say Python with its 997 or so default maximum simultaneous stack frames, we didn't have 997 individual services, so even the maximally malicious dependency tree couldn't have exceeded that limit.
ausbah 5y ago
would've put my money on this coming from a Northeastern student, nice write up either way
- MisterSandman 5y ago
  my money was on University of Waterloo (biased) or MIT.
adamddev1 5y ago
Great writing and I agree with these points. I learned Racket by working through HTDP [1] and although I've never used Racket for anything other than those exercises it was totally worth it. I think it (the language and HTDP) massively improved the way I think through, organize, and write everything else. [1]: https://htdp.org/ https://htdp.org/
srcreigh 5y ago
The point about simple evaluation models, while true for basic Racket, is actually the furthest from the truth in idiomatic Racket. The idiomatic way to solve a problem in Racket is to develop new syntax (and evaluation orders) which are suited to the problem. In fact, Racket has pythonic list comprehension syntax too: (for/list ([x '(2 4 8)]) (sqr x)) It also has lazy evaluation langs, static typecheck pre-eval step langs, DFA compilers, OOP... Basically the floodgates are open, even if the river is still a bit barren. Every confusing language feature in existence can be added to Racket. The only saving grace is that anyone, including you, can replace it with less confusing syntax / evaluation orders if they so desire. I wrote a Macro which adds identifiers to your program based on a SQLite database's column names. [0] If the database isn't found your program does not compile. How is that for confusing alternative evaluation order? If that's your nightmare, my point is made. [0]: http://tech.perpetua.io/2022/01/generating-sqlite-bindings-with-racket-macros/ http://tech.perpetua.io/2022/01/generating-sqlite-bindings-w...
- xhevahir 5y ago
  You're a lot more pessimistic here than in your blog post!
  - srcreigh 5y ago
    Not really. I'm just saying the same stuff in a different #lang-- I mean in different words :p
- srcreigh 5y ago
  Another example... this Arc code doesn't finish evaluating until a couple round trips with a web browser are finished. Absolutely cursed (defop said req (aform [w/link (pr "you said: " (arg _ "foo")) (pr "click here")] (input "foo") (submit))) (If you didn't know, Arc is implemented in Racket, and powers this site...) http://paulgraham.com/arcchallenge.html http://paulgraham.com/arcchallenge.html
- kjander79 5y ago
  One thing to note: The reason why SICP uses Scheme is not that the resulting programs are simpler. But instead, the mental model of what is happening under the hood is simpler, and easy to refine as you go along. This makes it possible to come to the end of the class, ready to create your own Scheme interpreter. I don't think that's possible with any of the alternatives, like Python. I am sure this result was rare, of course, even when it was the introductory at MIT. And as you point out, Racket has changed a lot also. I think it has been some years that Racket stopped calling itself Scheme, feeling the changes they have made have deviated too far.
scythe 5y ago
One aspect of Racket that I would expect to appeal to students, but which does not appear in this blog post, is its cross-platform (and widget-native!) GUI framework: https://docs.racket-lang.org/gui/ https://docs.racket-lang.org/gui/ The first "side-project" I ever did was a tic-tac-toe program in Java AWT during my first year of programming in high school. AWT wasn't even part of the curriculum, it was just what I gravitated towards as a 13-year-old whose experience with computers consisted entirely of graphical applications. Maybe the kids these days would be more interested in building a web app or something, but frankly I don't think it's surprising that writing code that primarily consumes and emits text at a terminal is not interesting to students who have never had any need for a terminal before.
- tonfreed 5y ago
  Can confirm, I very quickly picked up Swing when I started Java programming just because I wanted to make little games and cellular automata. Before that, we'd had Haskell forced upon us and the GUI stuff had been very difficult for a beginner to pick up.
- Bootvis 5y ago
  I tried (not very hard) to see some screenshots but failed. Do you know of a gallery with example code?
  - samth 5y ago
    https://alex-hhh.github.io/2021/09/screenshots.html https://alex-hhh.github.io/2021/09/screenshots.html is a nice gallery of one person's apps.
- steinuil 5y ago
  I love racket/gui and recently shipped a product using it for a diagnostics tool! The killer features are as you said that it uses native widgets, but also that it doesn't require any sort of dynamic linking to heavyweight C libraries (other than the ones Racket itself comes with) and that you can easily compile it in a redistributable form with basically no dependencies for all platforms. I can't recommend it enough.
axelerator 5y ago
I always say my appreciation for functional programming comes from having spent enough time in imperative hell. That being said I think learning programming in an "expressions only" environment can enable the student to deal with more complex problems earlier, merely by making certain types of errors impossible. I think the Elm programming language is the sweet spot for that. - it does have elegant (Haskell like) syntax - it has still a simple syntax because it deliberately omits certain features (namely typeclasses, do-notation) - it has a self contained build system (compiler, package manager, repl, dev server) with a rich ecosystem of libraries - it is comparatively easy to ship something tangible because it compiles to JS for the browser
dbpatterson 5y ago
So... unless Grinnell does things very differently, the author did not learn Racket, they learned (Beginning/Intermediate/Advanced) Student Language, and that's the point. Racket is a complicated language, designed primarily in order to support the easy creation of other languages: it would be as bad a choice (perhaps worse) for a first language as any other. All of the simplicity, focusing on learning to program, programming structurally based on data, that comes out of HtDP, is enabled by the restricted language. It's too bad that this naming confusion persists, as I think it hurts the effort to focus on teaching _programming_ in intro classes, vs. teaching X language (I don't want to teach people Racket any more than I want to teach them Python or Java. They can learn those on their own -- they'll probably learn at least a half dozen other languages over their career, all on their own, if they stick with it). This curriculum is about figuring out how to most effectively teach people to program: the language was created, after the fact, to support that.
- deleted 5y ago
  [deleted]
- ng12 5y ago
  Fair point although I feel like Racket deserves credit for the way it builds upon itself. By design it allows you to have the Student Languages that are each iterations upon the previous, and all are valid Racket programs. As a counter-example you can't do much of anything in Java without introducing class and public-static-void-main-string-args.
  - dbpatterson 5y ago
    I think this still, somewhat, misses the point. Sure, Racket has facilities to make implementing languages easier (that's the whole point), but that simply makes it _easier_ to implement BSL, etc. I could certainly, with more effort, implement BSL in Java or in any other language: the language that students are using really has nothing to do with the _host_ language. Things are somewhat confused by DrRacket (or, made simpler, depending on your perspective); the IDE is somewhat mixed up with everything else, but again, this functionality can and does exist in other editors: I could implement a mode for my BSL implemented in Java in, say, VS Code, with comparable features to DrRacket. Or, to take a completely different tack, implement the IDE via the web a la WeScheme or, if you want an actual concrete example of something that isn't Racket hosted, Pyret.
fuzzer37 5y ago
spdegabrielle 5y ago
Nice write up. You mention SICP, but I’m wondering if you are using HTDP http://htdp.org/ http://htdp.org/ ? I’ve always been struck by the vision the authors state in the preface; > everyone can design programs > > and > > everyone can experience the satisfaction that comes with creative design. > > Indeed, we go even further and argue that program design—but not programming—deserves the same role in a liberal-arts education as mathematics and language skills. > > A student of design who never touches a program again will still pick up universally useful problem-solving skills, experience a deeply creative activity, and learn to appreciate a new form of aesthetic. I’m not a good programmer - I’m not even a average one, but the book and learning Racket has made me better.
- hydroxideOH- 5y ago
  We actually use a collection of notes written by faculty rather than a book. But the course is much more in the style of HTDP than it is in SICP, we don't cover anything about compilers/interpreters, for instance, but the class focuses on problem solving and decomposition.
tonfreed 5y ago
I think it's important to show students how to think about languages as a set of tools. OP's post stabs at this quite well, with the "Languages are less important than you think" section, and as someone who has already jumped across 5 or 6 languages over the course of his just over 10 year pro career this definitely rings true. I think it's fine to bag on languages like Racket, but a good engineer should be able to hop across any language and at least be able to read and understand what they're doing.
acbart 5y ago
Ah, debates about programming language choice for CS1, without evidence. Gotta love the CS1 language wars. Someday some folks will actually gather evidence that really let's us know if these interesting claims about these languages hold any water. I don't think we've made much progress on that as a community. Fortunately, the people involved in these projects are doing more valuable things with their time.
- DonaldPShimoda 5y ago
  > Someday some folks will actually gather evidence that really let's us know if these interesting claims about these languages hold any water. I don't think we've made much progress on that as a community. Ironic that you should post this, having not done any due diligence on your own part. Shriram Krishnamurthi, who, incidentally, was one of the original members of the Racket team, is at the forefront of CS education research, and one thing he thinks about is how to introduce people to computer science. This, of course, includes the choice of language. He, as well as his wife and two former students, wrote and recently published the book "A Data-Centric Introduction to Computing" (DCIC) [1], which is meant to be a new kind of CS 101 textbook. In section 1.8, "Our Programming Language Choice" [2], the authors write about how Python is now a common introductory language choice that also enjoys industry use, but it can lead to frustrations for new students of computing, so they didn't want to use Python. Instead, they developed their own language, Pyret, for teaching. (Pyret is also used in another initiative of Shriram's: Bootstrap [3].) It's worth pointing out that although Pyret is very similar to Python in many regards, its spiritual heritage certainly includes Racket. Racket was designed at the outset as a language for teaching programming, and this desire to invest effort in tools for beginners has stuck with SK for the duration of his decades-spanning career. I'd suggest looking through his publications, blog posts, and Twitter feed for works/notes about CS education with regard to language choice. He's certainly not quiet about it. All this is to say: people are working on getting to a solid answer about what language is best for introductory material. We just haven't come to a definitive conclusion yet. However, I think we should leave all that aside and focus on something else: the original blog post for this HN thread is not a "debate", as you've suggested. It's one student's perspective. They are absolutely allowed to think aloud to the internet and share their resulting perspectives. They didn't claim to have all the answers. I think their post was rather well-written, exploring things that this student felt made learning programming easier. If that's not worth discussing, I'm not sure what is. [1] https://dcic-world.org https://dcic-world.org [2] https://dcic-world.org/2022-01-25/part_intro.html#%28part._.Our_.Programming_.Language_.Choice%29 https://dcic-world.org/2022-01-25/part_intro.html#%28part._.... [3] https://bootstrapworld.org https://bootstrapworld.org
awesomelvin 5y ago
I actually learned Racket in the University of Tübingen last fall too and made the exact same experience as the author. I think it's a great language to learn recursive and functional thinking and to get better at finding elegant and compact solutions for complex problems. Many students of my class were unhappy with the language choice at my university too and I really can't understand it because I had so much fun with such a different approach to programming.
wink 5y ago
I think it's a good choice if you're majoring in CS, or anything closely related where you are very likely to learn another general-purpose language anyway (or have done so), then it's an awesome way to see different paradigms. I think it's a bad choice if this is your only programming course during your studies, then it would be much more helpful to learn something that is a safer bet you'll be using in your life continuing forward. Yes, even JavaScript. If you're interested, you'll pick up another language and apply what you learned here - but if not, then I think there's a better chance you'll recall what you learned with the mainstream model and work from there. This is my unscientific opinion, but it's based on all my experience with non-programmers where you can be happy if they learned _something_ at all, they'll most often see themselves as "I learned some Python" for example, and are willing to expand from there, but they're more reluctant to transfer the knowledge to learn a new language. I don't think it's completely off, either, even drawing a parallel to learning natural languages (to a small degree, not full working proficiency).

129 points by hydroxideOH- 5y ago

Comment unrelated to the article: I knew I know that blog theme from somewhere, turns out it is my own https://github.com/oltdaniel/dose https://github.com/oltdaniel/dose theme. Thanks for using it. Hope you like it. Comment related to the article: I always wanted to dive deeper into functional programming languages. Especially, because I more and more run into stuff, that is just simpler to model in a recursive pattern. Maybe I'll give it the a new try within the next weeks and see how far I come.

hydroxideOH- 5y ago
Thanks! I do like that theme and I only made a few tweaks to it with some of the code styling and the header. And I'd definitely recommend it, programming in FP languages has been a bit of an addiction for me.

jboynyc 5y ago

Nice writeup, keep it up!

hydroxideOH- 5y ago
Thank you!
mark_l_watson 5y ago
I agree, keep writing. I have spent a lot of my professional life using Lisp languages. Not as popular as Python, Java, etc., but Lisp (and other languages like Haskell) have a good effect on how we think about computation.

melony 5y ago

It is interesting that recursion is still considered to be so novel on blogs and forums. From what I have seen of current CS curriculums, recursion is usually taught in the first year immediately after introductory CS. It is almost impossible not to use recursion when dealing with tree structures (using an explicit stack takes a lot more code, most coding interviews don't ask for an iterative solution unless absolutely necessary).

moron4hire 5y ago
After 20 years of software development in a variety of languages and projects, I've come to the opinion that recursion really should be relegated to being a novelty. Few languages offer tail-call optimization. If we look at popularity of languages, then the likelihood any particular solution is going to end up in such a language is vanishingly small. For the remaining languages, fitting into the stack depth is easy to get wrong. It's easy to end up in an infinite loop that ends in an obscure error with a confusing, verbose, needle-in-hay-stack stack frame that over complicates debugging. And frankly, lots of programmers don't have a good handle on it, even the ones who studied CS in college, so asking them to maintain recursive code written by someone else usually ends pretty poorly. So when we consider that, actually, no, it's not true that using an explicit stack takes "a lot more code" (it's like, three extra lines), recursion starts to look more and more like a code smell, a smell indicating the originating programmer is more a temporarily-embarrassed mathematician than an engineer. To be clear, I have no problems conceiving of and implementing recursive solutions to problems. But every single one of my recursive solutions has eventually failed to survive contact with real life data. It might be next week when the code goes to production or it might be a year from now when the data processing needs grow, but I've eventually replaced them all. I'm not the only one with this opinion. Many safety regulations covering vehicles from cars to spacecraft explicitly ban recursion because of these issues. We need to just stop with the fetishising of math in software development.
- dgb23 5y ago
  In web/gui programming it’s a good fit. Your data is a tree that you render on a screen, so it’s by default relatively shallow and not very big. It’s never going to blow the stack and the benefit of using recursion, closures and functional composition is you get clear, dense code and tend to make fatter data structures and more general code.
  - nonameiguess 5y ago
    Yep. Same thing with filesystems. Since they're meant for humans to traverse, finding a directory structure with deep enough nesting to blow up the process stack or hit a runtime recursion limit is sufficiently rare that you shouldn't even worry about it. I'm sure there are plenty of other examples where the practical limit you'll see in much lower than what an address space stack can fit. We had a task at an old job to create dependency and build trees of every service in the overall project and then operate on them. Even assuming a language runtime with a very small limit, say Python with its 997 or so default maximum simultaneous stack frames, we didn't have 997 individual services, so even the maximally malicious dependency tree couldn't have exceeded that limit.

ausbah 5y ago

would've put my money on this coming from a Northeastern student, nice write up either way

MisterSandman 5y ago
my money was on University of Waterloo (biased) or MIT.

adamddev1 5y ago

Great writing and I agree with these points. I learned Racket by working through HTDP [1] and although I've never used Racket for anything other than those exercises it was totally worth it. I think it (the language and HTDP) massively improved the way I think through, organize, and write everything else. [1]: https://htdp.org/ https://htdp.org/

srcreigh 5y ago

The point about simple evaluation models, while true for basic Racket, is actually the furthest from the truth in idiomatic Racket. The idiomatic way to solve a problem in Racket is to develop new syntax (and evaluation orders) which are suited to the problem. In fact, Racket has pythonic list comprehension syntax too: (for/list ([x '(2 4 8)]) (sqr x)) It also has lazy evaluation langs, static typecheck pre-eval step langs, DFA compilers, OOP... Basically the floodgates are open, even if the river is still a bit barren. Every confusing language feature in existence can be added to Racket. The only saving grace is that anyone, including you, can replace it with less confusing syntax / evaluation orders if they so desire. I wrote a Macro which adds identifiers to your program based on a SQLite database's column names. [0] If the database isn't found your program does not compile. How is that for confusing alternative evaluation order? If that's your nightmare, my point is made. [0]: http://tech.perpetua.io/2022/01/generating-sqlite-bindings-with-racket-macros/ http://tech.perpetua.io/2022/01/generating-sqlite-bindings-w...

xhevahir 5y ago
You're a lot more pessimistic here than in your blog post!
- srcreigh 5y ago
  Not really. I'm just saying the same stuff in a different #lang-- I mean in different words :p
srcreigh 5y ago
Another example... this Arc code doesn't finish evaluating until a couple round trips with a web browser are finished. Absolutely cursed (defop said req (aform [w/link (pr "you said: " (arg _ "foo")) (pr "click here")] (input "foo") (submit))) (If you didn't know, Arc is implemented in Racket, and powers this site...) http://paulgraham.com/arcchallenge.html http://paulgraham.com/arcchallenge.html
kjander79 5y ago
One thing to note: The reason why SICP uses Scheme is not that the resulting programs are simpler. But instead, the mental model of what is happening under the hood is simpler, and easy to refine as you go along. This makes it possible to come to the end of the class, ready to create your own Scheme interpreter. I don't think that's possible with any of the alternatives, like Python. I am sure this result was rare, of course, even when it was the introductory at MIT. And as you point out, Racket has changed a lot also. I think it has been some years that Racket stopped calling itself Scheme, feeling the changes they have made have deviated too far.

scythe 5y ago

One aspect of Racket that I would expect to appeal to students, but which does not appear in this blog post, is its cross-platform (and widget-native!) GUI framework: https://docs.racket-lang.org/gui/ https://docs.racket-lang.org/gui/ The first "side-project" I ever did was a tic-tac-toe program in Java AWT during my first year of programming in high school. AWT wasn't even part of the curriculum, it was just what I gravitated towards as a 13-year-old whose experience with computers consisted entirely of graphical applications. Maybe the kids these days would be more interested in building a web app or something, but frankly I don't think it's surprising that writing code that primarily consumes and emits text at a terminal is not interesting to students who have never had any need for a terminal before.

tonfreed 5y ago
Can confirm, I very quickly picked up Swing when I started Java programming just because I wanted to make little games and cellular automata. Before that, we'd had Haskell forced upon us and the GUI stuff had been very difficult for a beginner to pick up.
Bootvis 5y ago
I tried (not very hard) to see some screenshots but failed. Do you know of a gallery with example code?
- samth 5y ago
  https://alex-hhh.github.io/2021/09/screenshots.html https://alex-hhh.github.io/2021/09/screenshots.html is a nice gallery of one person's apps.
steinuil 5y ago
I love racket/gui and recently shipped a product using it for a diagnostics tool! The killer features are as you said that it uses native widgets, but also that it doesn't require any sort of dynamic linking to heavyweight C libraries (other than the ones Racket itself comes with) and that you can easily compile it in a redistributable form with basically no dependencies for all platforms. I can't recommend it enough.

axelerator 5y ago

I always say my appreciation for functional programming comes from having spent enough time in imperative hell. That being said I think learning programming in an "expressions only" environment can enable the student to deal with more complex problems earlier, merely by making certain types of errors impossible. I think the Elm programming language is the sweet spot for that. - it does have elegant (Haskell like) syntax - it has still a simple syntax because it deliberately omits certain features (namely typeclasses, do-notation) - it has a self contained build system (compiler, package manager, repl, dev server) with a rich ecosystem of libraries - it is comparatively easy to ship something tangible because it compiles to JS for the browser

dbpatterson 5y ago

So... unless Grinnell does things very differently, the author did not learn Racket, they learned (Beginning/Intermediate/Advanced) Student Language, and that's the point. Racket is a complicated language, designed primarily in order to support the easy creation of other languages: it would be as bad a choice (perhaps worse) for a first language as any other. All of the simplicity, focusing on learning to program, programming structurally based on data, that comes out of HtDP, is enabled by the restricted language. It's too bad that this naming confusion persists, as I think it hurts the effort to focus on teaching _programming_ in intro classes, vs. teaching X language (I don't want to teach people Racket any more than I want to teach them Python or Java. They can learn those on their own -- they'll probably learn at least a half dozen other languages over their career, all on their own, if they stick with it). This curriculum is about figuring out how to most effectively teach people to program: the language was created, after the fact, to support that.

deleted 5y ago
[deleted]
ng12 5y ago
Fair point although I feel like Racket deserves credit for the way it builds upon itself. By design it allows you to have the Student Languages that are each iterations upon the previous, and all are valid Racket programs. As a counter-example you can't do much of anything in Java without introducing class and public-static-void-main-string-args.
- dbpatterson 5y ago
  I think this still, somewhat, misses the point. Sure, Racket has facilities to make implementing languages easier (that's the whole point), but that simply makes it _easier_ to implement BSL, etc. I could certainly, with more effort, implement BSL in Java or in any other language: the language that students are using really has nothing to do with the _host_ language. Things are somewhat confused by DrRacket (or, made simpler, depending on your perspective); the IDE is somewhat mixed up with everything else, but again, this functionality can and does exist in other editors: I could implement a mode for my BSL implemented in Java in, say, VS Code, with comparable features to DrRacket. Or, to take a completely different tack, implement the IDE via the web a la WeScheme or, if you want an actual concrete example of something that isn't Racket hosted, Pyret.

fuzzer37 5y ago

spdegabrielle 5y ago

Nice write up. You mention SICP, but I’m wondering if you are using HTDP http://htdp.org/ http://htdp.org/ ? I’ve always been struck by the vision the authors state in the preface; > everyone can design programs > > and > > everyone can experience the satisfaction that comes with creative design. > > Indeed, we go even further and argue that program design—but not programming—deserves the same role in a liberal-arts education as mathematics and language skills. > > A student of design who never touches a program again will still pick up universally useful problem-solving skills, experience a deeply creative activity, and learn to appreciate a new form of aesthetic. I’m not a good programmer - I’m not even a average one, but the book and learning Racket has made me better.

hydroxideOH- 5y ago
We actually use a collection of notes written by faculty rather than a book. But the course is much more in the style of HTDP than it is in SICP, we don't cover anything about compilers/interpreters, for instance, but the class focuses on problem solving and decomposition.

tonfreed 5y ago

I think it's important to show students how to think about languages as a set of tools. OP's post stabs at this quite well, with the "Languages are less important than you think" section, and as someone who has already jumped across 5 or 6 languages over the course of his just over 10 year pro career this definitely rings true. I think it's fine to bag on languages like Racket, but a good engineer should be able to hop across any language and at least be able to read and understand what they're doing.

acbart 5y ago

Ah, debates about programming language choice for CS1, without evidence. Gotta love the CS1 language wars. Someday some folks will actually gather evidence that really let's us know if these interesting claims about these languages hold any water. I don't think we've made much progress on that as a community. Fortunately, the people involved in these projects are doing more valuable things with their time.

DonaldPShimoda 5y ago
> Someday some folks will actually gather evidence that really let's us know if these interesting claims about these languages hold any water. I don't think we've made much progress on that as a community. Ironic that you should post this, having not done any due diligence on your own part. Shriram Krishnamurthi, who, incidentally, was one of the original members of the Racket team, is at the forefront of CS education research, and one thing he thinks about is how to introduce people to computer science. This, of course, includes the choice of language. He, as well as his wife and two former students, wrote and recently published the book "A Data-Centric Introduction to Computing" (DCIC) [1], which is meant to be a new kind of CS 101 textbook. In section 1.8, "Our Programming Language Choice" [2], the authors write about how Python is now a common introductory language choice that also enjoys industry use, but it can lead to frustrations for new students of computing, so they didn't want to use Python. Instead, they developed their own language, Pyret, for teaching. (Pyret is also used in another initiative of Shriram's: Bootstrap [3].) It's worth pointing out that although Pyret is very similar to Python in many regards, its spiritual heritage certainly includes Racket. Racket was designed at the outset as a language for teaching programming, and this desire to invest effort in tools for beginners has stuck with SK for the duration of his decades-spanning career. I'd suggest looking through his publications, blog posts, and Twitter feed for works/notes about CS education with regard to language choice. He's certainly not quiet about it. All this is to say: people are working on getting to a solid answer about what language is best for introductory material. We just haven't come to a definitive conclusion yet. However, I think we should leave all that aside and focus on something else: the original blog post for this HN thread is not a "debate", as you've suggested. It's one student's perspective. They are absolutely allowed to think aloud to the internet and share their resulting perspectives. They didn't claim to have all the answers. I think their post was rather well-written, exploring things that this student felt made learning programming easier. If that's not worth discussing, I'm not sure what is. [1] https://dcic-world.org https://dcic-world.org [2] https://dcic-world.org/2022-01-25/part_intro.html#%28part._.Our_.Programming_.Language_.Choice%29 https://dcic-world.org/2022-01-25/part_intro.html#%28part._.... [3] https://bootstrapworld.org https://bootstrapworld.org

awesomelvin 5y ago

I actually learned Racket in the University of Tübingen last fall too and made the exact same experience as the author. I think it's a great language to learn recursive and functional thinking and to get better at finding elegant and compact solutions for complex problems. Many students of my class were unhappy with the language choice at my university too and I really can't understand it because I had so much fun with such a different approach to programming.

wink 5y ago

I think it's a good choice if you're majoring in CS, or anything closely related where you are very likely to learn another general-purpose language anyway (or have done so), then it's an awesome way to see different paradigms. I think it's a bad choice if this is your only programming course during your studies, then it would be much more helpful to learn something that is a safer bet you'll be using in your life continuing forward. Yes, even JavaScript. If you're interested, you'll pick up another language and apply what you learned here - but if not, then I think there's a better chance you'll recall what you learned with the mainstream model and work from there. This is my unscientific opinion, but it's based on all my experience with non-programmers where you can be happy if they learned _something_ at all, they'll most often see themselves as "I learned some Python" for example, and are willing to expand from there, but they're more reluctant to transfer the knowledge to learn a new language. I don't think it's completely off, either, even drawing a parallel to learning natural languages (to a small degree, not full working proficiency).