Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Racket: Lisp for Learning

lwn.net

Post reply on HN
Print view View original

21–30 of 154 posts

Re: Racket: Lisp for Learning

#21

Post by GavinMcG »

AlexeyBrin wrote: post #5

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.

Re: Racket: Lisp for Learning

#22

Post by nudpiedo »

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

Any evidence about any oculus exec (CEO? CFO? GTO?) trying to change the most famous CTO of the company switch an implementation detail.

(The comment about the wife spoiling him to use java seemed more credible)

Re: Racket: Lisp for Learning

#23

Post by JoelMcCracken »

tombert wrote: post #9

Does Racket support "real" multithreading yet? I remember looking at their documentation a few years ago and it only had support for a green-threading thing, which (along with the first-class hashmaps) steered me towards Clojure.

Yes and no. Its not that great. A big part of the motivation to rewrite atop Chez was to be able to expose more parallelism.

Re: Racket: Lisp for Learning

#24

Post by neilv »

tombert wrote: post #18
samth wrote: post #15

Earlier quoted context omitted.

Yes, Racket support using multiple cores/OS threads. There are two mechanisms -- shared memory parallelism that is limited in what operations the threads can execute in parallel (called futures in Racket) and shared-nothing parallelism with message passing, more like Erlang (called places in Racket). Most real work using parallelism in Racket uses places.

I guess I was confused by this [1], specifically: Racket supports multiple threads of evaluation. Threads run concurrently, in the sense that one thread can preempt another without its cooperation, but threads currently all run on the same processor (i.e., the same underlying operating system process and thread). Is this documentation out of date or am I looking in the wrong place? [1] https://docs.racket-lang.org/re…

Here's two places to start, for the various options (sorry it's two separate manuals):

https://docs.racket-lang.org/guide/parallelism.html

https://docs.racket-lang.org/reference/concurrency.html

Of course, you can also do it the old-fashioned way, with multiple Racket processes running services, being workers behind a proxy/frontend, possibly on multiple hosts, etc.

Re: Racket: Lisp for Learning

#25

Post by traderjane »

JoelMcCracken wrote: post #19
AlexeyBrin wrote: post #4

Earlier quoted context omitted.

Given the Racket2 possible massive syntax changes it seems that using JavaScript was a better choice for a commercial project. That being said I very much prefer Racket to JavaScript for personal/hobby projects.

Very much an overreaction. The whole point of Racket is to support multiple syntaxes. The idea that a future Racket would NOT support the current syntax seems absurd. But really there are lots of other, better reasons to use JS over Racket for a major commercial project, which may or may not be actually a good call, but a new proposed syntax is not one of them.

But where will the culture of Racket go? How will the educational texts, documentation, and general conversations go?

Re: Racket: Lisp for Learning

#26

Post by jkxxkxjkjx »

AlexeyBrin wrote: post #5

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.

Re: Racket: Lisp for Learning

#27

Post by nudpiedo »

sdegutis wrote: post #20
jimbob45 wrote: 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 UI of an S-Expeession and a compiler transformation parse time transformation is just out of any comparison.

Most of projects wouldn’t even consider writing a loader for a compiler or using a syntax parser. Yet to add which method is more prone to errors.

Re: Racket: Lisp for Learning

#28

Post by dmix »

traderjane wrote: post #25
JoelMcCracken wrote: post #19

Earlier quoted context omitted.

Very much an overreaction. The whole point of Racket is to support multiple syntaxes. The idea that a future Racket would NOT support the current syntax seems absurd. But really there are lots of other, better reasons to use JS over Racket for a major commercial project, which may or may not be actually a good call, but a new proposed syntax is not one of them.

But where will the culture of Racket go? How will the educational texts, documentation, and general conversations go?

They could do an Elixir style fork instead? Although a pure syntax change isn’t as significant as what Elixir changed.

Re: Racket: Lisp for Learning

#29

Post by neilv »

sdegutis wrote: post #20
jimbob45 wrote: 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…

> Editing s-expressions is a nightmare without some kind of automatic help.

I used to write C and C++ code in (non-vim) vi, with only autoindent, and it was fine. I could also type the spaces, if I had to.

For s-expressions, like in a Lisp, you want autoindent a bit more, and some kind of of paren-matching/highlighting is also important.

Fortunately, editors have been doing autoindent and paren-matching for decades. And once your editor is formatting your code correctly, it's pretty visual, not textual.

And few people write any code in something like non-vim vi or notepad.exe anymore, so I see no reason to think less of a language for wanting an editor/IDE developed in the last couple decades.

There's no need for paredit, AFAIK, but paredit is another thing for which s-expressions are especially well-suited, relative to most other syntaxes. (You can also do paredit-like structural-based navigation and editing of JS, for example, but you have to have a clear model of the syntax structure, not only in the tool, but also in the programmer's head.)

Re: Racket: Lisp for Learning

#30

Post by JoelMcCracken »

traderjane wrote: post #25
JoelMcCracken wrote: post #19

Earlier quoted context omitted.

Very much an overreaction. The whole point of Racket is to support multiple syntaxes. The idea that a future Racket would NOT support the current syntax seems absurd. But really there are lots of other, better reasons to use JS over Racket for a major commercial project, which may or may not be actually a good call, but a new proposed syntax is not one of them.

But where will the culture of Racket go? How will the educational texts, documentation, and general conversations go?

Why does the same conversation not come up when discussing typed racket? Is the introduction of a static type system really less culture-shaking than surface syntax?
Post reply on HN