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

21–30 of 66 posts

Re: I Wrote a Scheme in 2025

#21

Post by skydhash »

harperlee wrote: post #12
0xcafefood wrote: post #9

Earlier quoted context omitted.

Agreed. I think Clojure strikes a pretty reasonable balance here. It's opinionated about the programming paradigm, scales back some of the pain that comes from reader macros, and solves some of the bootstrapping problems by compatibility with other JVM languages.

I love clojure but the points still stand, kind-of. - There is Calva for VS Code but the community default is emacs and cider - How many programs in apt or brew are written in clojure? I'd concede that the community is great and focused on productivity, but it's so niche that you don't see much work out there made in clojure, and there is also a vestigial lisp sentiment to prefer building your own library from scratc…

> There is Calva for VS Code but the community default is emacs and cider

Emacs isn’t required. You can always create a REPL plugin. Emacs just does a lot of heavy lifting for you due to comint, sexp navigation, and process management being included.

> building your own library from scratch instead of contributing to a standard library

Simple data structures lead to very generic function. You don’t have to write tower or massive spread of abstractions like in Java or TypeScript. A struct is nothing than a hashmap that can help a typechecker. Most lisp programs prefer primitives or functions instead of manipulating complex objects -never ‘buffer.name’ but ‘(get-buffer-name buffer)’-.

From a module, what you need are functions and an opaque state holder.

With such philosophy, you don’t need a lot of libraries, which are often designed to be complex, when you need a simple model.

> Third one you need to mutate it a little bit

You don’t. Clojure already does the optimization for you for the standard data structures, and they are the only things you need in most cases.

Re: I Wrote a Scheme in 2025

#22

Post by Pay08 »

saghm wrote: post #20
reikonomusha wrote: post #10

Earlier quoted context omitted.

This is a common reaction/belief but usually from people who have not actually managed a team of Lisp devs. Lisp devs are managed in the same way as any other: You have style guidelines, design review, code review, etc. Sometimes a new macro is good and vastly simplifies code. It's accepted as a PR and documented like anything else. Sometimes a new macro is bad, and it's promptly rejected by the team. It's a persiste…

It's hard to reconcile that with the comment they were responding to that claimed that lisp requires you to be the designer of the language a bit. I don't know enough to know who is right, but if the majority of the code is "just" regular functions and classes then I'd argue that it doesn't require custom design as a much as allow it, and the solution you're proposing is to mostly disallow it by convention. Like the…

The first rule of writing Lisp macros is to not do it if you can get away with using functions. I'd still argue that it requires custom design, but in the same way OOP does. There are established patterns that you know and sometimes iterate on.

Re: I Wrote a Scheme in 2025

#23

Post by Pay08 »

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.

Better syntax highlighting immediately comes to mind. Maybe code actions/automatic refactoring too.

Re: I Wrote a Scheme in 2025

#24

Post by skydhash »

saghm wrote: post #20
reikonomusha wrote: post #10

Earlier quoted context omitted.

This is a common reaction/belief but usually from people who have not actually managed a team of Lisp devs. Lisp devs are managed in the same way as any other: You have style guidelines, design review, code review, etc. Sometimes a new macro is good and vastly simplifies code. It's accepted as a PR and documented like anything else. Sometimes a new macro is bad, and it's promptly rejected by the team. It's a persiste…

It's hard to reconcile that with the comment they were responding to that claimed that lisp requires you to be the designer of the language a bit. I don't know enough to know who is right, but if the majority of the code is "just" regular functions and classes then I'd argue that it doesn't require custom design as a much as allow it, and the solution you're proposing is to mostly disallow it by convention. Like the…

It’s going to be used. But at a project and team level rather than at an individual level. You go from lisp, then end up with a DSL that fits the project.

Re: I Wrote a Scheme in 2025

#25

Post by codr7 »

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

Re: I Wrote a Scheme in 2025

#26

Post by skydhash »

fmbb wrote: post #14
shpongled wrote: post #4

Earlier quoted context omitted.

As someone who is "into" programming languages (and making toy implementations of them), I think some of the most important macros are along the lines of Rust/Haskells `derive/deriving` for quickly enabling serialization, printing etc. Using a language without such capability quickly becomes frustrating once you move to any kind of "real" task.

In any kind of real task, serialization is not the hard part. If you can write a meta program for it, you can execute that in CI and spit out generated code and be done with it. This is a viable approach in any programming language that can print strings to files. It’s not frustrating, but maybe it feels tacky. But then you shrug and move on to the real task at hand.

Lisp macros are more for not having to write the same type of code (all subtly different, but sharing the same general structure).

One such example is the let-alist macro in elisp

https://www.gnu.org/software/emacs/manual/html_node/elisp/As...

Dealing with nested association lists is a pain. this let you write your code with a dot notation like jq.

Macros are not only for solving a particular task (serialization, dependency injection, snippets,…) they let you write things the way it makes sense. Like having html-flavored lisps for template, sql-flavored lisp for query,… Lisp code is a tree, and most languages are trees, so you can bring easily their semantic in lisp.

Re: I Wrote a Scheme in 2025

#27

Post by skydhash »

nine_k wrote: post #11
maplant wrote: post #3

Earlier quoted context omitted.

I think people underestimate how pragmatic meta programming can be because there are some obvious downsides. Arguably one of things that made Rust so popular was its inclusion of procedural macros. But beyond that the thing I don't understand about the modern hate towards macros is that they are simply very fun.

Ruby, Python, and Typescript use metaprogramming rather heavily. They lack the homoiconic property of lisps, but they can do both higher-order functions and monkey-patching. Meta-heavy code usually offers a nice DSL, but is proportionally harder to drill down through.

Lisp code is a tree, which fits how most languages are written. So it’s easy to embed other languages in lisp. But other languages grammars are very cumbersome and can’t fit one another.

Re: I Wrote a Scheme in 2025

#28

Post by skydhash »

Pay08 wrote: post #23
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.

Better syntax highlighting immediately comes to mind. Maybe code actions/automatic refactoring too.

Lisp does not have that much syntax for highlighting to be a problem.

Lisp is also a symbolic language. Meaning the code work on symbols, not data, only at evaluation the value of the symbol is known. There’s a lot of symbols manipulation routines like macros, intern, package loading,… that prevent to statically know the code.

It’s why people use the REPL flow.

Re: I Wrote a Scheme in 2025

#29

Post by taylorallred »

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 was really interested in lisps for a couple of years, but eventually I came to the conclusions: it's just hard to read. I know they say "the parens disappear" but even if that is the case, it simply requires you to jump around the expression holding lots of context in your head. I'm a fan of code that mostly reads top-to-bottom, left-to-right.

Re: I Wrote a Scheme in 2025

#30

Post by antonvs »

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

People have played around with those exact ideas for decades. No-one has ever come close to making it work.
Post reply on HN