Racket: Lisp for Learning • Hacker News Board

Re: Racket: Lisp for Learning

#111

Post by [deleted] » Thu, Aug 08, 2019, 8:44 PM UTC

slifin wrote: post #87

sdegutis wrote: post #20

Earlier quoted context omitted.

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 can't think of a single feature of ClojureScript that's inherently better than JavaScript" Persistent data structures, multi arity functions, multi methods, transducers, data oriented design, spec, repl driven, better live reloading, meta data, protocols, core async go channels, atoms, Datoms There are breakthroughs in Clojure/Script that literally do not exist in any other language, let alone JS Datomic, Fulcro,…

[deleted]

Re: Racket: Lisp for Learning

#112

Post by acbart » Thu, Aug 08, 2019, 8:47 PM UTC

rkido wrote: post #90

acbart wrote: 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 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.

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

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

Re: Racket: Lisp for Learning

#113

Post by sdegutis » Thu, Aug 08, 2019, 8:47 PM UTC

slifin wrote: post #87

sdegutis wrote: post #20

Earlier quoted context omitted.

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 can't think of a single feature of ClojureScript that's inherently better than JavaScript" Persistent data structures, multi arity functions, multi methods, transducers, data oriented design, spec, repl driven, better live reloading, meta data, protocols, core async go channels, atoms, Datoms There are breakthroughs in Clojure/Script that literally do not exist in any other language, let alone JS Datomic, Fulcro,…

Persistent data structures: Useful but you can get that in JS too, and if you can get your whole team to agree on it, you can avoid mutable data structures. I've been able to do that 100% for years now.

Multi arity functions: That's actually a minus, not a plus. The vast majority of the usages of this are solved with options params with default values in a much clearer way.

Multi methods: In 5 years of using Clojure professionally, I think I've never seen these used once.

Transducers: This is just an optimization, and I'm pretty sure it's possible in JS too since it's an API design.

Data oriented design: This is a design practice, it can be done in JS too, and it's a questionable one too.

Spec: When Spec came out is around the time I realized the period of true Clojure innovation is over, which peaked from around 1.3 to 1.5 or so. TypeScript is by far a better version of adding type innovations to a dynamic language.

REPL driven: You can do this in any language with a REPL, even JS.

Better live reloading: This is just as good in JS. There's no language feature of ClojureScript that makes this better than in plain JS.

Meta data: The only times I've ever seen this feature used was in storing internal representations of things in DSLs, which can be done in JS by using plain objects for their representations which store an inner object.

Protocols: JS only doesn't have this because it's duck-typed and they are implicit. An explicit counterpart exists in TypeScript's interfaces for those who want it to be explicit.

Core async, Go channels: These have to do with threading, but JS mostly exists in single-threaded runtimes, so it's non-applicable.

Atoms, Datoms: These are library-level concerns which are doable in JS.

Re: Racket: Lisp for Learning

#114

Post by sdegutis » Thu, Aug 08, 2019, 8:50 PM UTC

yogthos wrote: post #110

sdegutis wrote: post #20

Earlier quoted context omitted.

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

JS tooling has come a long way, and I've had pretty much all of these benefits by using Create-React-App within the past year. I don't remember ever needing to make project-wide changes because of an upgrade.

It's also possible to avoid JSX completely, thanks to a library that uses JavaScript's template strings feature: https://www.npmjs.com/package/htm

Re: Racket: Lisp for Learning

#115

Post by ajudson » Thu, Aug 08, 2019, 8:54 PM UTC

neilv wrote: post #47

gaze wrote: 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…

which company has that internal application?

Re: Racket: Lisp for Learning

#116

Post by acbart » Thu, Aug 08, 2019, 8:55 PM UTC

taeric wrote: post #67

acbart wrote: 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

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

> How stable has racket been compared to the alternatives?

Why does the stability of Racket matter? Isn't the real question more about how easy it is to reuse, readopt, reshare, find, etc. materials? I'll point out that the CSEngageEdu site doesn't have a Racket section. If you want me to find 100 programming problems in Python, I can do so immediately (because I published more than that, and I know others who have published even more). It's a simple fact that there's more community and infrastructure around Racket. There's been some interesting arguments that we shouldn't let that stop us - what about the future? But the reality is that right now, it's harder to teach in Racket, and I don't see any compelling evidence to prop it up further.

> Is there any data about how well the students do following each language choice?

I'm sorry, I had to laugh out loud. You've asked a really reasonable question, but it's one that the CS Ed community bickers about endlessly. I wrote a paper for SIGCSE about trends in what we talk about on the SIGCSE Mailing list. Seriously, every few years we get into the argument. Actual data seems to suggest very little. Heck, it's so hard to compare with all the confounding factors and individualized components that it's probably not really meaningful to get a simple answer. Ultimately? It probably doesn't matter. If you can teach 90% of my students with Racket the way I teach 90% of my students with Python, and you have the time and energy, then that's probably fine. But the simple reality where I'm at is that that's not the case - students who were taking Racket here before I arrived were being traumatized (and I suspect it's true at more places than the Racket folks want to acknowledge). If they don't want Racket, and I can teach a good CS1 in Python or Java or JavaScript, why should I fight that? Language choice doesn't really influence pedagogy as much as we might want to think it does, per this quote from the beautiful Meta paper that came out earlier this year:

> “Given the perennial question of which language, if any, is best suited for the teaching of introductory programming, many papers describe empirical comparisons between languages, often finding no significant difference in learning outcomes, but sometimes finding differences in student satisfaction.”

> “The choice of programming language is clearly a highly subjective one and is driven by many competing factors. It is clear that the literature will continue to host publications making the case for different programming language choices — and that no paper or series of papers will ever put an end to the debate, as no programming language will ever satisfy all of the conflicting requirements of an introductory programming course.”

Re: Racket: Lisp for Learning

#117

Post by sdegutis » Thu, Aug 08, 2019, 8:58 PM UTC

bitwize wrote: post #53

sdegutis wrote: post #20

Earlier quoted context omitted.

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 evaluated Paredit while it was being developed. I thought it was a massive boon to working with Lisp. Then, one day, I turned it off. I'm not sure why. I think it's because I didn't want to get too attached to it. I reasoned that Paredit wouldn't always be in the places I was working with Lisp, so I had better remain flexible enough to not need it. And between the editor's paren matching and the way I format my Lis…

The modifier key positions are different on an Apple keyboard vs a PC keyboard, so my muscle memory is completely broken when using Windows since I got used to them on Mac.

Re: Racket: Lisp for Learning

#118

Post by chessturk » Thu, Aug 08, 2019, 9:59 PM UTC

acbart wrote: post #101

chessturk wrote: post #75

Earlier quoted context omitted.

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

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 :)

Re: Racket: Lisp for Learning

#119

Post by badsavage » Thu, Aug 08, 2019, 10:18 PM UTC

acbart wrote: post #51

acbart wrote: 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

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.

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.

Re: Racket: Lisp for Learning

#120

Post by oehtXRwMkIs » Thu, Aug 08, 2019, 10:52 PM UTC

acbart wrote: post #102

layoutIfNeeded wrote: post #73

Earlier quoted context omitted.

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?

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.