6 ms·

Scheme Reports at Fifty

66 points by djwatson24 11mo ago

tonetheman 11mo ago
I wish I saw what these guys do in scheme. I only barely know what is happening and it seems interesting. The parens are so hard for me to follow and always have. I have yet to find an editor that fixes that. Perhaps I did not try enough or am not smart enough to acutally use the editors correctly. Anyway interesting read I think
- hellcow 11mo ago
  paredit on vim is great. Working through all the exercises in "The Little Schemer" was a huge help for me when getting started. You start with a few primitives and build up all common tools from those with recursion, like how to build an addition function using just `add1` as an early example from the book.
  - fleahunter 11mo ago
    Interesting point about the difficulty of parsing all those parentheses! I remember getting pretty frustrated with it when I first picked up Scheme. It felt like trying to read a book written in a strange code. But then I stumbled onto paredit in Emacs—it totally transformed the way I interacted with the code. The structured editing made it feel more like composing music than wrestling with syntax. And you're right—working through "The Little Schemer" was a game-changer for me too. There's something about gradually building up to complex concepts that really clicks, right? I wonder if there could be a way to create more beginner-friendly editors that visually guide you through the syntax while you code. Or even some sort of interactive tutorial embedded in the editor that helps by showing expected patterns in real-time. The tension between users wanting features and implementers wanting simplicity is so prevalent in so many languages, isn't it? Makes me think about how important community feedback is in shaping a language's evolution. What do you all think would be a good compromise for Scheme—more features or a leaner report?
- neilv 11mo ago
  C-like syntax: foo(1, 2, 3); if (x) { aaa(); } else { bbb(); } Lisp-like syntax: (foo 1 2 3) (if x (aaa) (bbb)) Syntax is easy. Practical semantics is a little bit harder, but it's not hard. Editor-wise, you want an editor that does automatic indenting and some kind of matching parentheses highlighting. Emacs is one. (Once you've learned the language, you can use a fancy structural editor, but maybe don't confuse yourself with too many new things at once.)
  - mhitza 11mo ago
    For vim/neovim users out there, here's my setup https://gist.github.com/mhitza/a00d7900571e9f13bac2bbf4a203d21b https://gist.github.com/mhitza/a00d7900571e9f13bac2bbf4a203d... Not quite structural editing, minor annoyances, but pretty decent.
- bitwize 11mo ago
  The "such parens, much overwhelm, so confuse" attitude of non-Lispers always baffled me. Especially since when working in C-syntax languages, I'm cautious enough to enforce an explicit order of operations (to avoid confusion that can lead to errors) that I put nearly as many parens in my C or Java code as I do in my Lisp code. What's a few more pairs of round brackets among friends, eh? Emacs was purpose-built for working in Lisp. Out-of-the-box it really helps with paren-matching by highlighting the matched bracket (of any type) when you cursor over a bracket (also works by highlighting the open when you type the close) and providing commands for traversing and selecting whole sexps. Those alone, combined with its smart indentation, will get you pretty far. Add something like Paredit or Parinfer if you want even more assistance with sexp manipulation.
  - agumonkey 11mo ago
    I had a talk with someone very much allergic to lisp (a college trauma for him iirc). For people like him, extra distinction through syntax is a mental benefit while I assume lisp fans need the opposite, removing 90% of syntax makes things easier (sexps and fp composability being key too)
- spit2wind 11mo ago
  This is a good starter. Technically, it's Lisp and not Scheme, but once you understand one, you get the other. The benefit of Emacs Lisp is you can immediately play with it by modifying Emacs to meet your needs. https://www.gnu.org/software/emacs/manual/eintr.html https://www.gnu.org/software/emacs/manual/eintr.html
- deleted 11mo ago
  [deleted]
- mylifeandtimes 11mo ago
  I've never understood why people who have no problem with print(foo) get stuck at (print foo) I've always found the parenthesis comforting, we know where it starts and where it ends.
  - munificent 11mo ago
    I don't think they're fine with print(foo) and stuck at (print foo). They're fine with: if a < b + c then d * e - f And stuck at: (if (< a (+ b c)) (- (* d e))) I personally don't mind s-expr syntax, but not having any infix expressions or precedence levels means a lot more parentheses in idiomatic code.
  - bananaflag 11mo ago
    What I found weird in Lisp (and didn't even realize at first) is that foo and (foo) mean something different. I now understand it similarly to the way in set theory x and {x} are different, but one is not used to the ordinary parenthesis symbol behaving in this way.
pklausler 11mo ago
I wish so badly that there were a statically typed, pure, and lazy Scheme.
- Chinjut 11mo ago
  What would distinguish this from existing statically typed, pure, and lazy functional languages such as Haskell?
  - maplant 11mo ago
    sexpression based hygienic macros
- _zagj 11mo ago
  > lazy Why? What are the advantages, in practice, of lazy evaluation as the default?
  - endgame 11mo ago
    If you have immutable data and want code reuse, you need laziness otherwise you give up a lot of performance. In Haskell, a careful choice of implementation for `sort` means that `take 10 (sort someList)` will only do enough work to return the first ten elements. Having laziness by default means that functions compose properly by default; you don't have to worry about libraries providing an interface to your chosen incremental streaming library or whatever. I've seen friends working in strict dialects of Haskell forced to write out each combination of list functions by hand because otherwise they'd have to materialise large intermediate data structures where regular lazy Haskell simply wouldn't. Ed Kmett has a couple of great posts about the value he's realised from laziness: https://www.reddit.com/r/haskell/comments/l98v73/can_you_share_a_realworld_anecdote_of_when/glgun65/ https://www.reddit.com/r/haskell/comments/l98v73/can_you_sha... https://www.reddit.com/r/haskell/comments/5xge0v/today_i_used_laziness_for/ https://www.reddit.com/r/haskell/comments/5xge0v/today_i_use...
    - nrds 11mo ago
michaelcampbell 11mo ago
Tangent, but wow did I find the typography and font-face on that blog post pleasant to read.
- Pinus 11mo ago
  I thought "this feels like Univers" when I saw the text. A quick check, and it turned out to be URW Classic Sans, a font that I had not heard about, but which is apparently a Univers clone. (Not to be confused with URW Classico, which is more like Optima. I also wonder how it relates to U001, another URW clone of Univers... just different names? U001 comes, or used to come at least, with GhostPCL under a non-commercial licence.)
munificent 11mo ago
> Given these deep divisions over the essential nature of the Scheme language, does it even make sense that we still keep making a Scheme report? > ‘No’ is an entirely possible answer to this question. Already in the R6RS and R7RS small days, people were arguing that Scheme standardization should stop. > If we went this way then, just like Racket in its default mode no longer claims to be a Scheme report implementation, Schemes would slowly diverge into different languages. Guile Scheme would one day simply be Guile; Chicken Scheme would be Chicken, and so on. Like the many descendants of Algol 60 and 68, and the many dialects of those descendants, each of these languages would have a strongly recognizable common ancestor, but each would still be distinct and, ultimately, likely incompatible. This would doom all of those variants to irrelevance even more than they already are. To the degree that people want Scheme to be a useful language for writing programs that solve real-world problems, it needs an ecosystem. And in order to compete with other languages, that ecosystem needs to commensurate with the scale that those other languages have. Otherwise, it doesn't matter how elegant the syntax is or how powerful the macro system is. If user needs to talk to a database and there isn't a good database library, they aren't going to pick the language. The Scheme ecosystem is already tiny when you lump all languages and their packages into one. Fragment that, and you're probably below viability for all of them. Now, it is fine if the goal of Scheme is not writing programs to solve real-world problems. It may be just a teaching language. But the evidence seems to be that it's hard to motivate programming students to learn a language that they ultimately won't end up using.

66 points by djwatson24 11mo ago

I wish I saw what these guys do in scheme. I only barely know what is happening and it seems interesting. The parens are so hard for me to follow and always have. I have yet to find an editor that fixes that. Perhaps I did not try enough or am not smart enough to acutally use the editors correctly. Anyway interesting read I think

hellcow 11mo ago
paredit on vim is great. Working through all the exercises in "The Little Schemer" was a huge help for me when getting started. You start with a few primitives and build up all common tools from those with recursion, like how to build an addition function using just `add1` as an early example from the book.
- fleahunter 11mo ago
  Interesting point about the difficulty of parsing all those parentheses! I remember getting pretty frustrated with it when I first picked up Scheme. It felt like trying to read a book written in a strange code. But then I stumbled onto paredit in Emacs—it totally transformed the way I interacted with the code. The structured editing made it feel more like composing music than wrestling with syntax. And you're right—working through "The Little Schemer" was a game-changer for me too. There's something about gradually building up to complex concepts that really clicks, right? I wonder if there could be a way to create more beginner-friendly editors that visually guide you through the syntax while you code. Or even some sort of interactive tutorial embedded in the editor that helps by showing expected patterns in real-time. The tension between users wanting features and implementers wanting simplicity is so prevalent in so many languages, isn't it? Makes me think about how important community feedback is in shaping a language's evolution. What do you all think would be a good compromise for Scheme—more features or a leaner report?
neilv 11mo ago
C-like syntax: foo(1, 2, 3); if (x) { aaa(); } else { bbb(); } Lisp-like syntax: (foo 1 2 3) (if x (aaa) (bbb)) Syntax is easy. Practical semantics is a little bit harder, but it's not hard. Editor-wise, you want an editor that does automatic indenting and some kind of matching parentheses highlighting. Emacs is one. (Once you've learned the language, you can use a fancy structural editor, but maybe don't confuse yourself with too many new things at once.)
- mhitza 11mo ago
  For vim/neovim users out there, here's my setup https://gist.github.com/mhitza/a00d7900571e9f13bac2bbf4a203d21b https://gist.github.com/mhitza/a00d7900571e9f13bac2bbf4a203d... Not quite structural editing, minor annoyances, but pretty decent.
bitwize 11mo ago
The "such parens, much overwhelm, so confuse" attitude of non-Lispers always baffled me. Especially since when working in C-syntax languages, I'm cautious enough to enforce an explicit order of operations (to avoid confusion that can lead to errors) that I put nearly as many parens in my C or Java code as I do in my Lisp code. What's a few more pairs of round brackets among friends, eh? Emacs was purpose-built for working in Lisp. Out-of-the-box it really helps with paren-matching by highlighting the matched bracket (of any type) when you cursor over a bracket (also works by highlighting the open when you type the close) and providing commands for traversing and selecting whole sexps. Those alone, combined with its smart indentation, will get you pretty far. Add something like Paredit or Parinfer if you want even more assistance with sexp manipulation.
- agumonkey 11mo ago
  I had a talk with someone very much allergic to lisp (a college trauma for him iirc). For people like him, extra distinction through syntax is a mental benefit while I assume lisp fans need the opposite, removing 90% of syntax makes things easier (sexps and fp composability being key too)
spit2wind 11mo ago
This is a good starter. Technically, it's Lisp and not Scheme, but once you understand one, you get the other. The benefit of Emacs Lisp is you can immediately play with it by modifying Emacs to meet your needs. https://www.gnu.org/software/emacs/manual/eintr.html https://www.gnu.org/software/emacs/manual/eintr.html
deleted 11mo ago
[deleted]
mylifeandtimes 11mo ago
I've never understood why people who have no problem with print(foo) get stuck at (print foo) I've always found the parenthesis comforting, we know where it starts and where it ends.
- munificent 11mo ago
  I don't think they're fine with print(foo) and stuck at (print foo). They're fine with: if a < b + c then d * e - f And stuck at: (if (< a (+ b c)) (- (* d e))) I personally don't mind s-expr syntax, but not having any infix expressions or precedence levels means a lot more parentheses in idiomatic code.
- bananaflag 11mo ago
  What I found weird in Lisp (and didn't even realize at first) is that foo and (foo) mean something different. I now understand it similarly to the way in set theory x and {x} are different, but one is not used to the ordinary parenthesis symbol behaving in this way.

pklausler 11mo ago

I wish so badly that there were a statically typed, pure, and lazy Scheme.

Chinjut 11mo ago
What would distinguish this from existing statically typed, pure, and lazy functional languages such as Haskell?
- maplant 11mo ago
  sexpression based hygienic macros
_zagj 11mo ago
> lazy Why? What are the advantages, in practice, of lazy evaluation as the default?
- endgame 11mo ago
  If you have immutable data and want code reuse, you need laziness otherwise you give up a lot of performance. In Haskell, a careful choice of implementation for `sort` means that `take 10 (sort someList)` will only do enough work to return the first ten elements. Having laziness by default means that functions compose properly by default; you don't have to worry about libraries providing an interface to your chosen incremental streaming library or whatever. I've seen friends working in strict dialects of Haskell forced to write out each combination of list functions by hand because otherwise they'd have to materialise large intermediate data structures where regular lazy Haskell simply wouldn't. Ed Kmett has a couple of great posts about the value he's realised from laziness: https://www.reddit.com/r/haskell/comments/l98v73/can_you_share_a_realworld_anecdote_of_when/glgun65/ https://www.reddit.com/r/haskell/comments/l98v73/can_you_sha... https://www.reddit.com/r/haskell/comments/5xge0v/today_i_used_laziness_for/ https://www.reddit.com/r/haskell/comments/5xge0v/today_i_use...
  - nrds 11mo ago

michaelcampbell 11mo ago

Tangent, but wow did I find the typography and font-face on that blog post pleasant to read.

Pinus 11mo ago
I thought "this feels like Univers" when I saw the text. A quick check, and it turned out to be URW Classic Sans, a font that I had not heard about, but which is apparently a Univers clone. (Not to be confused with URW Classico, which is more like Optima. I also wonder how it relates to U001, another URW clone of Univers... just different names? U001 comes, or used to come at least, with GhostPCL under a non-commercial licence.)

munificent 11mo ago

> Given these deep divisions over the essential nature of the Scheme language, does it even make sense that we still keep making a Scheme report? > ‘No’ is an entirely possible answer to this question. Already in the R6RS and R7RS small days, people were arguing that Scheme standardization should stop. > If we went this way then, just like Racket in its default mode no longer claims to be a Scheme report implementation, Schemes would slowly diverge into different languages. Guile Scheme would one day simply be Guile; Chicken Scheme would be Chicken, and so on. Like the many descendants of Algol 60 and 68, and the many dialects of those descendants, each of these languages would have a strongly recognizable common ancestor, but each would still be distinct and, ultimately, likely incompatible. This would doom all of those variants to irrelevance even more than they already are. To the degree that people want Scheme to be a useful language for writing programs that solve real-world problems, it needs an ecosystem. And in order to compete with other languages, that ecosystem needs to commensurate with the scale that those other languages have. Otherwise, it doesn't matter how elegant the syntax is or how powerful the macro system is. If user needs to talk to a database and there isn't a good database library, they aren't going to pick the language. The Scheme ecosystem is already tiny when you lump all languages and their packages into one. Fragment that, and you're probably below viability for all of them. Now, it is fine if the goal of Scheme is not writing programs to solve real-world problems. It may be just a teaching language. But the evidence seems to be that it's hard to motivate programming students to learn a language that they ultimately won't end up using.