Live data from Hacker News

Racket: Lisp for Learning

lwn.net

81–90 of 154 posts

Re: Racket: Lisp for Learning

#81
post #70
post #67

Earlier quoted context omitted.

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…

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…

Agreed this is less of a concern for python and Java. Still there, though. Especially with the new streams API and general lambdas. Or python three versus two.

Is it less if a change? I guess. I do know it is a source of some bugs we've seen. Not to mention just the churn of folks not using the general style of the existing code. New or old.

Re: Racket: Lisp for Learning

#82

I really like Racket, but the potential breaking massive syntax change in Racket2 makes me really uncomfortable in using or recommending Racket to other people, at least until the situation is clarified.

What's unclear about the situation? A developer tossed out an idea at a con. That's it, and `#lang racket` is and always will be a first class citizen. If you're hesitant to recommend Racket because of a potential `#lang racket2`, it seems like you're missing the point of Racket as a workbench for creating new `#lang`s.

> A developer tossed out an idea at a con.

Uh... calling him "a developer" is like just calling Ruth Bader Ginsburg "a judge". Matthew Flatt is the #1 contributor to Racket in terms of any quantifiable metric, and he was also one of the original researchers on the project (next to Findler and Krishnamurthi, under Felleisen).

I totally agree with you that any syntax change in Racket2 will not be so big a deal as many are making it out to be, but I think it's a bit disingenuous to understate Matthew's involvement with the community to such an extent.

Re: Racket: Lisp for Learning

#83

I really like Racket, but the potential breaking massive syntax change in Racket2 makes me really uncomfortable in using or recommending Racket to other people, at least until the situation is clarified.

What?! parenthesis are a feature not a bug. Parenthesis is part of what makes lisps so nice to use. Such a stupid decision. Makes no sense at all. Maybe they are on drugs or something or just bored.

I'm gonna go out on a limb and suggest that maybe the people who originally built Racket 20+ years ago and have spent their entire careers doing research related to it know what they're doing when they say they're considering changing the syntax. I dunno, maybe that's just crazy talk...

Re: Racket: Lisp for Learning

#84
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…

The thing is (and this relates to issue of racket changing surface syntax) - s-expressions are not just about the editing experience. They are about the reading/mental parsing experience. The less time I have to wonder about operator associativity rules (let alone magical language keywords/formats) the more time I can think about the actual semantics of the program being expressed. It always amuses me when using a mixfix language that the first thing to do when debugging a tricky math expression is to get hella parenthetical to make sure things are working the way you intend.

Re: Racket: Lisp for Learning

#85
post #53

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…

Paredit works great in Windows.

Re: Racket: Lisp for Learning

#86
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…

>The main other benefit I commonly see from people using Clojure or ClojureScript is live development.

I'm still learning about Scheme/Lisp, but doesn't hot-loading have to do with the size of "compilation units?" Isn't a single s-expression treated as a compilation unit whereas in a language like Java, the compilation unit is an entire Class?

Rich Hickey touched on this in a comment here on HN (2nd paragraph): https://news.ycombinator.com/item?id=2467809

Re: Racket: Lisp for Learning

#87
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 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, Crux, garden, hiccup, honeySQL, rebl etc just straight up don't have equivalents in other languages

Your statement blows my mind, sure you don't need s-expressions to do most the above but you can just turn on parinfer and treat it like python whilst still being able to dynamically rewrite source code using data manipulation

Re: Racket: Lisp for Learning

#88
post #41

Earlier quoted context omitted.

It has always been core part of the language experience on Amiga, PC and Mac platforms. Just not on UNIX culture.

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.

Re: Racket: Lisp for Learning

#89
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

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.

Re: Racket: Lisp for Learning

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

Post reply on HN