6 ms·

Author of this blogpost here. I think the post is good, though it's mostly aimed at the perspective of "Racket is a very practical Lisp, for getting things don

Author of this blogpost here. I think the post is good, though it's mostly aimed at the perspective of "Racket is a very practical Lisp, for getting things done, akin to how Python is a very practical lisp" and also "DrRacket gives an accessible entry-point for Lisp for newcomers." Unfortunately I don't think Racket quite took this to be the rallying cry I hoped them to, to embrace Racket's lispiness as "The Python of Lisps" (which was the other alternate title I was debating between when I wrote it). But in the comments here and as with most articles about Lisp, the conversation moves to... can newcomers understand Lisp's syntax? My spouse and I gave a talk about this very topic: "Lisp but Beautiful; Lisp for Everyone". https://fosdem.org/2022/schedule/event/lispforeveryone/ https://fosdem.org/2022/schedule/event/lispforeveryone/ There's a lot in there (including demonstrations of representations of lisp which don't have parentheses at all). But the biggest point in the talk is that lisp isn't scary for new programmers... it's scary for experienced programmers. As we talk about in the video, my spouse and I co-ran introductions to programming using Racket aimed at humanities students with no required prior programming experience whatsoever. What we found was that the students who had no prior programming experience, after just a few minutes, had no problem with the syntax (and DrRacket made it easy enough to pick up the language). But we did have complaints in the class about lisp's syntax... from those who already knew how to program. They already had a frame, and within that frame, lisp's syntax looked alien. Without a frame, students just accepted it and did fine with the syntax... great, even. (Many of them praised its clarity; like any decent lisp editor, DrRacket helps identify the kinds of parentheses-oriented errors that users think they're going to encounter.) Anyway, I do more work in Guile these days than Racket, but both are really great systems with great communities. The thing I miss most about Racket though is that DrRacket gave an easy entry point for students which wasn't "and now start learning Emacs". (Guix is pretty great, however.)

mark_l_watson 4y ago
I read your article when it was first published and agree with the sentiment. Off topic (sorry) but one thing Racket is missing is great Python interop to mix in deep learning and other libraries. Common Lisp and Clojure have this support. Years ago I tried saving trained Keras weights and using them in Racket with the Matrix support: it works, but not very fun to use.
- soegaard 4y ago
  Would something like `flomat` have helped? https://docs.racket-lang.org/manual-flomat/index.html https://docs.racket-lang.org/manual-flomat/index.html
  - mark_l_watson 4y ago
    Thanks, it would have. I see you are the author, what types of applications do you use flomat for?
jimbob45 4y ago
Lisp syntax is pretty rough if you want to prioritize maintainability. I can look at blurry C code and know generally what things are and what’s going on without a single character being legible. Lisps don’t typically have the same convenience. Given that code maintenance is usually about poring through thousands of lines of code quickly, I’d say this is a significant advantage for C. However, Lisps have unparalleled macro flexibility. It’s a clear trade-off that Lispers often have trouble admitting is a trade-off.
- deleted 4y ago
  [deleted]
- xscott 4y ago
  > I can look at blurry C code [...] I'm kind of curious how much of this is the problem with parens, and how much of this is the conventions that Lisp programmers seem to mostly adopt. For instance, here's the concise 99-bottles from Rosetta Code for Racket: (define (sing bottles) (define (plural n) (~a n " bottle" (if (= n 1) "" "s"))) (printf "~a of beer on the wall\n~a of beer\n~ Take one down, pass it around\n~a of beer on the wall\n\n" (plural bottles) (plural bottles) (plural (sub1 bottles))) (unless (= 1 bottles) (sing (sub1 bottles)))) (sing 99) And even with a snippet this short, it's not quick for me to scan. Lispers generally like hanging parens, the indentation varies depending on what construct you're in, and that example uses recursion instead of a for-loop [0]. Ok, so let's turn the concise Python one into a hypothetical Lisp: (for i in (range 99 0 -1) (let b = "bottles of beer") (let w = "{b} on the wall") (print "{i} {w}, {i} {b}\n") (print "Take one down and pass it around, {(- i 1)} {w}.\n") ) I think you could "know generally what things are" with that version even if it was blurry. And of course, this "hypothetical lisp" is legal Racket/Scheme after implementing a few macros. [0] I know Racket has for loops, but they didn't choose to use them in that example. Which is my point.
  - deleted 4y ago
    [deleted]
  - kazinator 4y ago
rendaw 4y ago
Couldn't this go the other way too? People who have no experience with programming languages have no basis for evaluating the comprehensibility of a language's syntax. I didn't have any complaints about BASIC until I tried Pascal, etc.

mark_l_watson 4y ago

I read your article when it was first published and agree with the sentiment. Off topic (sorry) but one thing Racket is missing is great Python interop to mix in deep learning and other libraries. Common Lisp and Clojure have this support. Years ago I tried saving trained Keras weights and using them in Racket with the Matrix support: it works, but not very fun to use.

soegaard 4y ago
Would something like `flomat` have helped? https://docs.racket-lang.org/manual-flomat/index.html https://docs.racket-lang.org/manual-flomat/index.html
- mark_l_watson 4y ago
  Thanks, it would have. I see you are the author, what types of applications do you use flomat for?

jimbob45 4y ago

Lisp syntax is pretty rough if you want to prioritize maintainability. I can look at blurry C code and know generally what things are and what’s going on without a single character being legible. Lisps don’t typically have the same convenience. Given that code maintenance is usually about poring through thousands of lines of code quickly, I’d say this is a significant advantage for C. However, Lisps have unparalleled macro flexibility. It’s a clear trade-off that Lispers often have trouble admitting is a trade-off.

deleted 4y ago
[deleted]
xscott 4y ago
> I can look at blurry C code [...] I'm kind of curious how much of this is the problem with parens, and how much of this is the conventions that Lisp programmers seem to mostly adopt. For instance, here's the concise 99-bottles from Rosetta Code for Racket: (define (sing bottles) (define (plural n) (~a n " bottle" (if (= n 1) "" "s"))) (printf "~a of beer on the wall\n~a of beer\n~ Take one down, pass it around\n~a of beer on the wall\n\n" (plural bottles) (plural bottles) (plural (sub1 bottles))) (unless (= 1 bottles) (sing (sub1 bottles)))) (sing 99) And even with a snippet this short, it's not quick for me to scan. Lispers generally like hanging parens, the indentation varies depending on what construct you're in, and that example uses recursion instead of a for-loop [0]. Ok, so let's turn the concise Python one into a hypothetical Lisp: (for i in (range 99 0 -1) (let b = "bottles of beer") (let w = "{b} on the wall") (print "{i} {w}, {i} {b}\n") (print "Take one down and pass it around, {(- i 1)} {w}.\n") ) I think you could "know generally what things are" with that version even if it was blurry. And of course, this "hypothetical lisp" is legal Racket/Scheme after implementing a few macros. [0] I know Racket has for loops, but they didn't choose to use them in that example. Which is my point.
- deleted 4y ago
  [deleted]
- kazinator 4y ago

rendaw 4y ago

Couldn't this go the other way too? People who have no experience with programming languages have no basis for evaluating the comprehensibility of a language's syntax. I didn't have any complaints about BASIC until I tried Pascal, etc.