Live data from Hacker News

Racket: Lisp for Learning

lwn.net

101–110 of 154 posts

Re: Racket: Lisp for Learning

#101
post #65

Earlier quoted context omitted.

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 pract…

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 sublim…

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.

Re: Racket: Lisp for Learning

#102
post #48

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

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??

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?

Re: Racket: Lisp for Learning

#103
post #38

Racket is a mixed bag for me. I've found a little quirks in the standard library, with simple fixes, but annoying. Stuff like decimal->string (?) producing odd output. (It was a tiny fix on my end, but it's a little subjective, maybe the behavior was intended) Not a big deal, but maybe a little impediment for learners compared to python. The article mentions Scribble, which I use as a static site generator for a a pa…

DrRacket's best feature might be that it has almost zero setup or configuration. Download, choose Beginner Student Language, and you're ready to rock. If one isn't using something like Beginner Student Language but just straight Racket then I imagine they've already graduated to another editor, except for maybe, as you say, keeping DrRacket around for little tasks. That's what I love about DrRacket: for the beginning user it has the complexity of a children's pull wagon.

Re: Racket: Lisp for Learning

#104

I got into 'purely' functional programming with Racket. It's really fun to use, and you can truly understand the functional paradigm if you dig deep into it. Along with it, I would recommend reading Structure and Interpretation of Computer Programs.

SICP is an awesome book.

Re: Racket: Lisp for Learning

#105
post #47
post #33

Who are the current major users of Racket? Are there any large commercial codebases written in it?

It's mostly used in various education projects, and various commercial and research projects that are largely done by a single strong programmer (e.g., Carmack-ish people). There's at least one large-codebase complex Web-based production system in it, which incidentally accomplished a first on AWS, but you've never heard of it, since it's internal-ish. It was a happy accident of history, that grew out of a lone super…

> .. that I'd say few teams could've pulled off in a non-Lisp.

Would you mind expanding on this? (I’m not asking facetiously either)

Re: Racket: Lisp for Learning

#106
post #88

Earlier quoted context omitted.

On *nix the whole OS is your IDE.

That is an old one, except it isn't a match for the integration an IDE is capable of offering, including the graphical capabilities. Interlisp-D, Lisp Machines, Smalltalk, Mesa/Cedar, XDE, Oberon were an OS as IDE. UNIX is a poor imitation of their capabilities.

Smalltalk and Oberon especially are complete or near complete systems: they are described from top to bottom, and in some cases described in themselves.

Oberon is interesting because the 2013 book goes much further than any recent system in this regard. One of the (final?) chapters even describes how to implement the custom processor in an FPGA.

Re: Racket: Lisp for Learning

#107
post #48

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

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 mee…

First, let me say I appreciate your lengthy response and your relative neutrality on this. Sometimes, when encountering folks who disagree with my opinions on this, things get a little heated. Case in point - I am very aware of what the person you mentioned says, which is difficult because I have blocked him on social media after our interactions. I originally had a paragraph about how I believe the PL/Racket community can be too rude to interact with. This is a difficult thing to say, but I'm afraid to let it not be said. The way that they communicate their arguments and ideas is frequently inconsiderate. You can say that feelings have no place in academia, but I've seen the impact that this has on potential practitioner adopters, on grad students, on many folks.

I hear and appreciate what you are saying about evidence. First, I'll give the usual disclaimer that evidence is hard to come by in CS Education because it's hard to collect properly. Second, I'll point out that I have been involved way more heavily in a completely different sub-branch of CS Education; if you would like to hear evidence for, say, the value of data science as an introductory computing context for non-majors (CS0), then I am very happy to share what I know that is backed up by evidence. Only recently have I started getting involved in actual CS1 research in a deep way - so I can't really take much responsibility for the lack of research. I mean, I've only been a professor for two years now :)

I don't know if you were hoping that I'd be able to find evidence in other papers or generate the evidence myself. For the former, know that I tried hard to do a proper lit review on this (and I'm not even going to get a publication out of it!). I even asked some Racket people: one basically repeated Matthias Fellisen's disgusting opinion that CS Ed research is not possible, and the other just pointed to one of their papers citing theoretical arguments. At some point, I'm hoping to ask Kathi Fisler if she has a better set of citations, assuming she'll still talk to me if she finds this document :)

As for whether I should be responsible for conducting research to disprove HtDP, I have considered it. I might even do it. Certainly, I am trying to experiment with several methods that can hopefully provide contrasting information. For instance, I want to see if I can replicate the Rainfall success by teaching more explicit functional decomposition and pattern application in my CS1. Of course, I'm also trying to do a ton of other projects, and my job promotion is based on my teaching, not my research.

Part of my issue is that I should not be responsible for proving that their ideas work. They thought up a bunch of arguments, and then claimed that This Is the One True Way to Teach. If I made the claim that teaching works better when I punch students at random intervals, and you disagreed, you wouldn't feel that the burden of proof was on your end, right? I should need to prove my Punching Method, to some extent - perhaps at least some pilot studies? The Racket folks made up a lot of claims, and then didn't really prove what they said. That was over 10 years ago! I've been busy getting my doctorate, what is their excuse?

Separately, you provide some very valid hypotheses for why my students didn't resonate with Racket. In general, I think you have some good points about SWE vs. CS, but I have a different perspective. There's some mental model here, common in certain communities, that learning happens in a very direct way - if you just arrange concepts in the right way, things will click. I think that learning is a lot more messy and chaotic and driven by a lot of human issues and tough to work with. Transfer is hard. You can't teach CS divorced from programming and this messiness, it's just not realistic. Perhaps a small percentage of my students who are destined to be brilliant Theoretical Computer Scientists and professors will find all the learning to be orderly. But CS is a broad umbrella nowadays, and motivations are complex. I'm not really doing my points justice here, but read some of what Andy Ko and Mark Guzdial have been writing about - I think they're more my kind of CS Education folks :)

Finally, I feel like I should at least address your hypotheses: (a) Yes, my students want industry-relevant languages. They all said this to me explicitly, once or twice during class :) I really tried my damndest to give them a good justification for why Racket is a good intro language. I really tried to sell it. I failed - either the arguments weren't delivered well, or they weren't received well. I will point out that some students told me last spring that they earnestly thought I was in favor of Racket for CS1, so anecdotal evidence that I at least tried! (b) Yes, most other faculty don't know why this is being taught this way, and they don't conform their courses to the vision. Should they? What's wrong with their courses that they need to be "Racketified"? What would fixing my junior-level Algorithms course to be more Rackety? Perhaps the Racket folks should offer some explanations. Or, here's an alternative - the PbD curriculum is not solving general purpose problems, and the approaches they teach are not generalizable to other parts of the curriculum. All CS1 courses are full of useful lies - the PbD curriculum's shouldn't be propogated downstream, they should just be tossed out in favor of lies that at least align with the next courses'. (c) I taught the Design Recipe and pretended it was effective. I told my TAs to grade on it, same as the other instructors have done in previous semesters (reusing rubrics helps a lot). Perhaps I'm not a good actor, but I really tried my best to sell it. Maybe my TAs weren't good, but I doubt that. They were all excellent students who excelled at the course when they took it. If they're not good at it, well I don't think we'd have been able to get better ones, so you have to take that as a limitation of the system.

I understand why you are disappointed by my article. I am disappointed in the entire HtDP community. I think that this is a bad situation, and I'm not clear that I can make it better by writing an article. However, my goal wasn't to persuade you that Python was better than Racket for CS1. It's to make the points that right now, in my context, I should be teaching Python instead of Racket. Also that the HtDP community should be ashamed of the awful job they've done proving their points, and they should stop being so mean to everyone.

Re: Racket: Lisp for Learning

#108
post #2

Carmack is a huge fan of Racket. He was going to use it as the scripting language for VR until the Oculus execs made him use JavaScript instead (boooooo) https://twitter.com/id_aa_carmack/status/807797812700348416

Good news is that we'll be able to do VR with ClojureScript though.

Re: Racket: Lisp for Learning

#109
post #48

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

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?

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.

Re: Racket: Lisp for Learning

#110
post #2

Carmack is a huge fan of Racket. He was going to use it as the scripting language for VR until the Oculus execs made him use JavaScript instead (boooooo) https://twitter.com/id_aa_carmack/status/807797812700348416

Last week I tried writing a new Love2d mode for Emacs in Emacs Lisp, but it was on Windows so my muscle memory for Paredit wasn't helpful. Editing s-expressions is a nightmare without some kind of automatic help. Last night I wrote the same plugin for VS Code which used JavaScript, and naturally it was effortless. It got me thinking about how s-expressions are inherently hostile to non-customized setups, whereas Java…

I consider stability, consistency, and simplicity to be very important features for writing production code. While it's true that you can do a lot of the same things you can do with ClojureScript in Js, the language and the ecosystem are vastly more quirky and volatile. I wrote regarding this in a bit more detail here [1].

As an example, my team has been using Reagent on the front-end for around 5 years now. We've never had to go back and change code to accommodate changes in ClojureScript or Reagent in that time. And we don't have to deal with stuff like JSX because HTML can be expressed using regular data structures. Things just work. Meanwhile, React itself has had many changes, and some of those are breaking.

I also find that tooling for ClojureScript is strictly superior. You get REPL driven development, reliable hot loading, minification, code pruning, and code splitting out of the box. All these things are difficult to do with Js, and don't work reliably with many NPM modules.

1. https://yogthos.net/posts/2013-08-18-Why-I-m-Productive-in-C...

Post reply on HN