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

I Wrote a Scheme in 2025

maplant.com

Post reply on HN
Print view View original

41–50 of 66 posts

Re: I Wrote a Scheme in 2025

#41

Post by reikonomusha »

nocman wrote: post #18
reikonomusha wrote: post #8

Earlier quoted context omitted.

Three thoughts (in the context of Common Lisp specifically): - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished. - There needs to be a little bit of a culture shift around Lisp to actually write programs that do things. How many programs can you download via apt or brew that are written…

> - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished. Can you give specific examples of "what a typical user expects" that are missing from Emacs-based programming environments (SLIME, and/or others)? I'm not suggesting there aren't any, I'd just like to know your list.

- Ease of setup and install. Turnkey. Good defaults.

- Non-buffer based workflows.

- Easy access to settings.

- Easy ways to change or switch my compiler.

- Integrated with typical lisp tooling for library, system, and package management. (For example, what Emacs button do I press to set or clear my ASDF compile cache?)

- Better integration of the profiler and debugger. When a Lisp error happens, yet another buffer pops up (breaking the arrangement of all your code windows you set up), this buffer may not even be the only one (but the others are hidden somewhere), and it's not clear what you can even click or expand to see more information (there's a tremendous amount, extremely non-discoverable).

- Good getting started: built in guide for structural editing, REPL workflow, etc.

...and much much more. I say all of this as someone who basically has only used and invested in Emacs for 20 years. I love sharing Emacs with people who like weird technologies and rabbit holes, the real "hacker"-type people. I hate sharing Emacs with people who want to be productive in an hour or so with a Lisp project, because I know within 5 minutes they'll be disappointed, and never get the best of the experience because it's too much uninteresting investment.

I prefer writing Lisp with Emacs+SLIME over anything else. It's extraordinarily powerful, and with enough grit, you can get it to do almost anything you want. But I'm also jealous of people who get to use, say, polished JetBrains products whose goal is to try to give you the best experience possible for your specific programming language.

Re: I Wrote a Scheme in 2025

#42

Post by reikonomusha »

Avshalom wrote: post #40
reikonomusha wrote: post #37

Earlier quoted context omitted.

Lisp code is written top to bottom, left to right. Is your grievance more to do with expression-oriented—as opposed to statement-oriented—languages? "Do this" (statement) vs "represent this" (expression)? For instance, do Haskell, OCaml, etc. also irk you in similar ways?

Lisp is written top to bottom left to right but because it's (almost) fully nested it's executed right to left bottom to top. Haskell and OCaml are, by comparison, not very nested.

This is not true.

    (defun f (x)
      (let ((y x))
        (setf y (* y x))
        (block foo
          (if (minusp y)
              (return-from foo y))
          (loop :for i :from 1 :to 10 :do
            ...
This is absolutely typical bog-standard left-to-right top-to-bottom structured programming type code. It also must be executed like so:

  - Define the function 
  - Bind the variable 
  - Mutate the variable
  - Set up a named block
  - Do a conditional return
  - Run a loop
  - ...
The order of execution literally matches the order it's written. But not unlike almost all other languages on the planet, expressions are evaluated inside-out.

Haskell's whole raison d'etre is to allow arbitrary nesting and substitution of terms, and all or none of these terms may or may not be evaluated depending on need. De-nesting happens with a copious number of syntax to bind names to values, sometimes before the expression (via let), sometimes after the expression (via where), and sometimes in the middle of an expression (via do).

Re: I Wrote a Scheme in 2025

#43

Post by shakna »

codr7 wrote: post #25
0xcafefood wrote: post #2

I really wish lisps were more popular (or, really, popular again). Most people can't make it past the non-Algol syntax, which is silly IMO. But they do also demand more of the user than a typical language. Their use of metaprogramming doesn't just allow you to extend the language, it really expects that of the programmer. Which means you have to assume the role of language designer to some extent. Learning how to do…

I've been playing around with dropping most of the parens, but keeping the rest. https://gitlab.com/codr7/shik

Any thoughts on SRFI-119's syntax?

https://srfi.schemers.org/srfi-119/srfi-119.html

Re: I Wrote a Scheme in 2025

#44

Post by Joker_vD »

tmtvl wrote: post #38
Joker_vD wrote: post #35

Earlier quoted context omitted.

Which actually supports the OP's original argument that even with training and getting used to, this syntax reads harder than let a, b, c = 0, 1, 0 fb_start: writen(a) b +:= 1 a := b - a if c

Leaving aside the fact that you have at least 4 (EDIT: 5) mistakes in that code, I find it less readable than the Lisp equivalent. The brackets reinforce the structure imposed by the indentation and help me keep track of order of execution. But that's how my brain works and that's why syntax is subjective.

My apologies, it should've been (if you insist on indentation)

        let a, b, c = 0, 1, 0
    fb_start:
        writen(a)
        b +:= a
        a :=
          b - a
        c +:= 1
        if c
Would you care to elaborate about brackets helping with tracking the order of execution? I'm really curious about that part.

Re: I Wrote a Scheme in 2025

#45

Post by maplant »

antonvs wrote: post #31
nxobject wrote: post #15

Another reason this is interesting beyond "Lispiness" instead: implementing a (compliant) Scheme takes on some interesting problems that other languages punt - proper tail recursion, delimited continuations (off the top of my head, I don't know other methods apart from CPS), and hygienic macros.

Last I checked no compliant Scheme required delimited continuations. Unless something like that was added in R7RS or later.

They don't. They will probably get added in R7RS large. They're available in scheme-rs regardless: https://scheme.rs/Standard%20Libraries/prompts/

Re: I Wrote a Scheme in 2025

#46

Post by vindarel »

reikonomusha wrote: post #41
nocman wrote: post #18

Earlier quoted context omitted.

> - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished. Can you give specific examples of "what a typical user expects" that are missing from Emacs-based programming environments (SLIME, and/or others)? I'm not suggesting there aren't any, I'd just like to know your list.

- Ease of setup and install. Turnkey. Good defaults. - Non-buffer based workflows. - Easy access to settings. - Easy ways to change or switch my compiler. - Integrated with typical lisp tooling for library, system, and package management. (For example, what Emacs button do I press to set or clear my ASDF compile cache?) - Better integration of the profiler and debugger. When a Lisp error happens, yet another buffer p…

JetBrains IDE plugin for Common Lisp: https://github.com/Enerccio/SLT (I'm sure you saw it before and I don't know how polish it is, and I'm pretty sure it has less features than Emacs&SLIME, yet, but I must link it for reference. Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.)

Re: I Wrote a Scheme in 2025

#47

Post by reikonomusha »

vindarel wrote: post #46
reikonomusha wrote: post #41

Earlier quoted context omitted.

- Ease of setup and install. Turnkey. Good defaults. - Non-buffer based workflows. - Easy access to settings. - Easy ways to change or switch my compiler. - Integrated with typical lisp tooling for library, system, and package management. (For example, what Emacs button do I press to set or clear my ASDF compile cache?) - Better integration of the profiler and debugger. When a Lisp error happens, yet another buffer p…

JetBrains IDE plugin for Common Lisp: https://github.com/Enerccio/SLT (I'm sure you saw it before and I don't know how polish it is, and I'm pretty sure it has less features than Emacs&SLIME, yet, but I must link it for reference. Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.)

I mean the following with all due respect—and I have a lot of respect for your many efforts and contributions—but it will sound a little blunt, especially as a written comment.

"We have one," no, this is a consistent problem with people who evangelize Lisp. We have had "IDEs" for decades. Most of them, except the couple commercially supported ones, were "experimental", "incomplete", "buggy", etc. This includes the one you link here.

Are these projects valuable as a starting point for other hackers to join in and help? Sure, maybe. Are they helpful for a new programmer? Almost always the answer has been "no". I have first-hand experience subjecting a programmer to one of these tools, and I myself getting incredibly frustrated at how broken it is. Imagine somebody completely new.

You in particular love to advertise these different projects as a form of Lisp evangelism. Advertising the projects is great—I hope they attract helpers—but I think your language around them is deceiving.

> Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.

"We have one" in the absolutely most rudimentary interpretation of that phrase. What we don't have is a working JetBrains Common Lisp IDE suitable for production use.

In order to try to promote a realistic view as to why Lisp doesn't attract more programmers in 2026, I myself will continue to point out Lisp's highly substandard tooling offering until there's an actual product that works. Any Joe can spend a weekend making a 1/2 baked, proof of concept IDE. Even more so now with all the AI vibecoding tools we have at our disposal. It takes much more to make something that checks all the boxes.

Re: I Wrote a Scheme in 2025

#48

Post by kazinator »

Joker_vD wrote: post #44
tmtvl wrote: post #38

Earlier quoted context omitted.

Leaving aside the fact that you have at least 4 (EDIT: 5) mistakes in that code, I find it less readable than the Lisp equivalent. The brackets reinforce the structure imposed by the indentation and help me keep track of order of execution. But that's how my brain works and that's why syntax is subjective.

My apologies, it should've been (if you insist on indentation) let a, b, c = 0, 1, 0 fb_start: writen(a) b +:= a a := b - a c +:= 1 if c Would you care to elaborate about brackets helping with tracking the order of execution? I'm really curious about that part.

TXR Lisp, with infix via ifx macro:

  (ifx
    (let ((a 0) (b 1) (c 0))
      (tagbody
       fb-start
        (prinl a)
        (b += a)
        (a := b - a)
        (c += 1)
        (if (c

Re: I Wrote a Scheme in 2025

#49

Post by kazinator »

Joker_vD wrote: post #35
tmtvl wrote: post #5

Earlier quoted context omitted.

Lisp is versatile as all get-out, so you can program however you want. For example, we can roll like it's 1969: (prog ((a 0) (b 1) (c 0)) (declare (type Fixnum a b c)) :fb-start (print a) (incf b a) (setf a (- b a)) (incf c) (when (

Which actually supports the OP's original argument that even with training and getting used to, this syntax reads harder than let a, b, c = 0, 1, 0 fb_start: writen(a) b +:= 1 a := b - a if c

> let a, b, c = 0, 1, 0

That's atrocious; = should never have a lower precedence than comma.

Re: I Wrote a Scheme in 2025

#50

Post by Joker_vD »

kazinator wrote: post #49
Joker_vD wrote: post #35

Earlier quoted context omitted.

Which actually supports the OP's original argument that even with training and getting used to, this syntax reads harder than let a, b, c = 0, 1, 0 fb_start: writen(a) b +:= 1 a := b - a if c

> let a, b, c = 0, 1, 0 That's atrocious; = should never have a lower precedence than comma.

Please forward your complaints to Martin Richards @ https://www.cl.cam.ac.uk/~mr10/ for making this decision.

Also, why?

Post reply on HN