I keep bouncing off the Scheme language
sicpers.info
sicpers.info
In much that same way that many people do the daily wordle or crossword, I do the daily leetcode.
I flip a coin and solve it first in either C++ or Python, then re-write my solution in the other one.
Usually it takes me around 20 minutes to solve it in either language, and 5 minutes to re-solve it in either language.
Recently I decided to start learning emacs lisp. This is an imperative lisp dialect that’s pretty different from scheme, but I think that the particular language doesn’t matter much for this process. I could a bit biased because I do have prior experience with SML and scheme.
I started re-solving the problems a third time in emacs lisp. And I’m still learning but I’ve felt my comfort with the language increase over time, and I expect that if I continue doing this then I will eventually reach parity with C++ and Python.
Currently it takes me about 20 minutes to re-solve a problem in emacs lisp, because I usually have to read documentation and/or look up something new.
Technical interviews are different enough from day-to-day work that I still find it valuable to practice in them.
You're probably under-weighing this factor.
The average programmer looks at SML syntax and cannot make, pardon the expression if you will, heads or tails of it.
Indeed, I'd argue the average programmer still considers recursion an advanced topic.
But isn't Python object-oriented? I mean, it's arguably more object-oriented than Java, since unlike Java, everything in Python is an object and it supports multiple inheritance. It's totally fair to not like Java, but if you like Python, then I doubt that OOP itself is what made you dislike Java.
You can view the daily problem without logging in or creating an account.
Fair warning: today's daily problem is a "hard" difficulty and it is often worth skipping those or peeking at the solution. They can take a while to solve (often at least an hour) and/or rely on unusual tricks or data structures. I haven't solved this one yet so idk exactly what its deal is.
LeetCode does have an "unofficial" API to get the problem of the day. Should work for previous days as well. This code worked last I tried [2].
[1] https://github.com/ebanner/daily-coding-challenges#leetcode
[2] https://github.com/ebanner/get-daily-leetcode-problem/blob/m...
Bonus - Racket is an accepted language on leetcode ;-)
I usually look at the editorial after the first solve to see if I missed any tricks or other approaches, and sometimes I’ll write the second solution differently if there was something interesting that I missed.
I do wonder what a language with the same “taste” and minimalism as Scheme but embracing the actor model would look like. Erlang?
Even better if someone could figure out how to harmonize them in the same language: “There are exactly two ways to do it, and they’re interchangeable.”
There is Spritely Goblins: https://spritely.institute/goblins/
Functional or declarative programming styles appeal to me, and I love what I've learned of Erlang but never really had a job where I could use it. Used SQL a lot and quite like it as well.
A few chapters in I belly laughed when it dawned on me that it's going to be recursion until the cows come home. The authors insistence on working through the steps is endearing and comical. Great book to come back to every once in a while.
Personally I find it easiest do design data flows: think about what we need in order to compute the result. The less I have to think about state the better. Functional patterns fall out and it feels simple and easy to me, so I do it. I'm way over the phase I thought that's somehow cooler than the OOP folks, however.
Best of all, is that the syntax grammar is so simple, that a simple CLAUDE.md + a few review agents lets me move super fast using AI. I spend most of my time anchoring on the design/plan and let AI write the implementation for most of the code.
(import scheme)
(import (srfi 203))
(import (srfi 216))
Official docs: https://docs.racket-lang.org/rhombus/index.html
Collection of small examples: https://github.com/racket/rhombus/blob/master/demo.rhm
Anyway, making Rhombus forced a few general enhancements in the Racket ecosystem, like more support for not-s-expression languages in the editor, filters in docs for languages families, and some new "backported" libraries like Treelist that behaves closer to a list in Python.
My main concern was how to make good macros without s-expressions. There is a nice video by Matthew Flatt in RacketCon 2023. The first 6 minutes and 20 seconds are internal stuff, so skip to the 380s that I added in the link: https://www.youtube.com/watch?v=OLgEL4esYU0&t=380s He takes like another 6 minutes to explain the general idea and make some wishes, and then at the 12m mark he defines macros and makes the wish real in just 2m (with some enhancements later).
stack traces are esoteric and error messages entirely unhelpful,
documentation masquerades as deep but is indeed inconsistent and prosaic, mixing styles of reference, explanation, and how-to willy-nilly, (compare with Dybvig’s The Scheme Programming Language, which is focused and consistent, and it takes no time to get your answers; there’s just no method to guile and guix manuals), i hate it big time,
there’s big gaps in documentation (especially with Guix – there’s literally zero information about `define-record-type*` which is used everywhere in its codebase; admittedly, not scheme related, but still),
the cli requires too much memorization,
most modules are not named, but numbered, ie, instead of something like `(base list)`, you get `(srfi srfi-1)`, so you need to either memorize, or go through the info pages for each procedure you need to import, which means you also need to know the exact names for the procedures you need beforehand,
there’s like 4 ways to define a record, each with a different feature set and incompatibilities,
etc.
these are the reasons i find it hard to use.
to respond to the content of the article, the different neurotype idea is off, because scheme allows you very well to express sequences of operations; the ecosystem of APIs may not cater to this tho. although if it was rephrased into “scheme emphasizes symbolic manipulations, as opposed to operating a machine”, i would agree
All the Lisp implementations seem to have pretty cryptic seeming errors, but it also seems to be very informative to those who know how to parse the call stack and how to expand/dig down in the built in debuggers. This is likely because of the same idea as those record-types, much of the language is built in the same lisp you’re running - so the error messages go a few levels lower level than you would expect. It’s not just a C syntax error type explanation, but rather you get some error about a bad call to a function you’ve never heard of running below that feature we normally associate with being a core function
Probably the one bit that isn't strictly fracturing's fault is stacktraces -- scheme has TCO, which is nice for alot of things but it absolutely destroys dx as it relates to stacktraces. Other languages with TCO are similarly awful in that regard, including haskell (ghc has `HasCallStack` to try help it, but it's still awful to use).
However, like “If you give a mouse a cookie”, I realized that once I had my traits that I also wanted compile-time attributes à la Rust/C# and there’s no clean way to add those to Lisp’s syntax without seriously cluttering it up (note: yes, function-level attributes would look fine but C# allows attributes on locals, iterators, and usings which just don’t mesh with Lisp’s syntax).
I gave up. Lisp is neat but it just doesn’t fit in the future of programming that Rust and C# have shown us.
They do in Racket? You look at the "List" documentation and you find all of the functions for lists. Likewise with hash tables, numbers, strings, sequences, files, etc.
> The only way to know strcat, puts, and strlen exist is…
... to look at the documentation on docs.racket-lang.org. The powerful search includes results not only for the standard ("batteries included") library reference, but also the standard guide and 3rd party libraries.
> once I had my traits that I also wanted compile-time attributes à la Rust/C# and there’s no clean way to add those to Lisp’s syntax
I mean, why are you not able to do (trait whatever) before (define whatever) or (for-each whatever) or (let whatever)?
> Lisp is neat but it just doesn’t fit in the future of programming that Rust and C#
Have you tried it or did you just try to figure out why you don't think you like it from an LLM?
Also, doesn't inheritance interfere a bit with your "functions aren't tied concretely together to types" observation? You can examine a source file for ArrayList, but if it extends List, you may not see everything you expect to see, and would just defer to the docs to help you out (or click through more source files).
I assume Racket contracts can handle your concern about relating functions and types. An IDE or static analysis tool can help you find all of the functions that operate on a `dict` type if you don't want to rely on conventions where you just seek out a dict.rkt file.
For what it's worth, coming from lots of Java experience, as a Racket novice, I poked around the Racket internals and added Candlesticks to its `plot` library [0] and removed a call to a deprecated gdk function that was causing overhead when drawing text [1]. It never felt like an insurmountable task just because methods aren't defined within types.
By finding problems with Lisp, you are finding problems with s-expressions, which, to me, are so plainly superior to XML and JSON for defining data that I wish more languages would at least consider adopting them for data definitions.
[0] https://github.com/racket/plot/commit/7f38feaf6e28a1decec93d...
contracts are not real types enforced by the compiler/runtime. that means you need to keep them in sync manually and you dont get performance benefits from typed vm instructions. you also lose a big safety net that makes sure you always call a function that can handle the values you pass in. the whole industry has been moving towards ml style strong types for the last 10 years and its for a good reason
Yes, and the only way to know that Vector and Hashtable exist is... to know that they exist.
> I also wanted compile-time attributes à la Rust/C# and there’s no clean way to add those to Lisp’s syntax without seriously cluttering it up
That's what declarations are for, a Lisp could have something like:
(declare (type Foo bar)
(derive Clone bar))
(define bar
(bar:from-string "Hello, World!"))
(db:with-connection (con (db:get-connection my-database))
(declare (db:read-only con))
(db:query con
:table "students"
:where (> "score" 80)
:sort-by "name"))
C♯ and Rust are dead languages, you make a change and you have to recompile the entire program and restart it from scratch. You can't ask a running program things like 'how many users are connected at the moment?'. That isn't a future I would like to see.
these days i'm seriously considering switching to zed tho
You might want to read Zed's EULA.
I do not use Zed's online services, only the editor itself which is GPLv3. If I need AI I wire in a third-party ACP provider, which is easy enough to configure.
I strongly recommend anyone interested use a Lisp as their prototyping language in their workplace. Another idea is to rewrite a complex component of the software you're working on and rewrite it in Lisp. More importantly ask the questions on Lisp forums especially about using the live editing workflow.
You’re almost there. Just stop thinking about the sequence of instructions. Focus on the information half (the values) that you need to produce.
There's your problem, right there. Vibe-coding is sabotaging learning before you even start.
You can learn some things by reading good code, but there's no substitute for the exercise of thinking through problems yourself. (Also, an LLM won't necessarily give you good code.)
First learn paint fence, Daniel-san. Not watch third-hand videos spliced together of other people painting the fence, and thinking you'll understand much of anything about it.
> I have the ALGOL neurotype.
Good news! Scheme started as a block-structured imperative "algorithmic" language in the spirit of ALGOL. Just with more parentheses.
Write as if in ALGOL, but using Scheme's comparable syntax and language features. And lots of parentheses.
Don't get confused by CS professors showing you pure-functional features, the metacircular evaluator, recursive programming, syntax extension and language-oriented programming, etc. You can come back to that.
Just start coding ALGOL-style in Scheme. You'll accomplish something in an hour.
Once you see it's easy, and are comfortable with that part, then the next thing you do, to get more idiomatic is one of the following, then do the other one:
* Try to get more functional, by eliminating some of the mutations of variables in your code. For example, if you're using `set!` a lot, can you eliminate them by, for example, making them arguments in a named-`let` recursion. (Or, instead of named-`let`, spell out the recursive functions, like some intro CS professors will want you to do, but that can obscure things that are obvious once you see the named-`let` lexical structure.)
* Try to get more language-oriented, by making a little domain-specific language, maybe with `syntax-rules`, `syntax-case`, or `syntax-parse`.
One more tip, for anyone coming from C, C++, Rust, etc., who may like trying to know the cost of everything: If you get hung up on high-level language features like GC, and not knowing which of a number of ways of doing something, is the right (performant) way, try not to. But if you want an intuition (that might be a lie), imagine that needless mutations or allocations may be more expensive than finding a different way to do it. And each FFI call has very expensive overhead. At one point that I had to make highly performant code, I made a little tool, to help confirm my intuitions: https://www.neilvandyke.org/racket/shootout/ There's also a statistical profiler in Racket now, and you can even (with work) rig it up in production systems, for measuring real-world workloads, which I used to guide optimizing performance of a large and complicated system.
The biggest advice I would give to the author is "If you're doing general programming instead of compiler construction, get off the goddamn lists, ignore recursion and use vectors and loops like somebody civilized. Don't write a macro until you have a gun to your head." Everybody I know who "bounces off" of Scheme/Lisps does so because of the idiotic "List Pedagogy" when the expert programmers almost invariably use vectors everywhere.
However, in this day and age, the lack of strong typing is a lot more of an issue. I've been more directing people toward OCaml rather than Scheme/Lisp nowadays--especially since they added multicore. However, similar advice attends: "Ignore the functional crap and type inference. Use vectors and put type signatures on all the things, you savage. OCaml works just fine as an "imperative" language."
> Lisp pioneered many ideas in computer science, including tree data structures, automatic storage management, dynamic typing, conditionals, higher-order functions, recursion, the self-hosting compiler, and the read–eval–print loop.
So many proficient coders were able to grasp features of Lisp, find the fitness of those features, and implement them in their own languages.
It's not a question of being smart or stupid. It's whether the tool fits the task it's applied to and the affordances it gives the user.
Scheme is intended more as a teaching tool than an actual language. Its simplicity is perfect for reasoning about programs. It's less well suited to practical tasks.
About the only really difficult lesson of Scheme is if you use it as a purely declarative language. Imperative features are a natural affordance of the human brain. Working with them is beautiful and alien.
I think it's refreshing change of perspective, and certainly worth pursuing if you're interested at all in in building programming structures rather than just using them. but if its not at all to your taste I wouldn't beat yourself up about it.