Gemma 4 works perfectly well offline on limited hardware (I have an 8GB video card) and can handle extracting text from image-based PDFs just fine.

Take a PDF -> run it through MarkItDown [1], using the OCR plugin if you need (point it to Gemma 4) -> now you can ask Gemma 4 questions about the (markdown) document.

I am sure Gemma 4 could even create a GUI to make this process very simple for a non technical user.

[1] https://github.com/microsoft/markitdown

If you want to change your vector to a linked list, in Lisp, you can change from `(vector 1 2 3)` to `(list 1 2 3)`. If you have some array `[1, 2, 3]` and you want to change to a linked list for whatever performance concern, you'd have to replace `[1, 2, 3]` with..

    var list = new List();
    l.insert(1);
    l.insert(2);
    l.insert(3);

`(date 2026 6 1)` is better than "2026-06-01" because the latter isn't a date, it's a date string. `(date 2026 6 1)` is better than `new Date(2026, 6, 1);` because the former is how it is serialized and can be deserialized.

> there's also the crazy bracket matching

At least with reading code, there is almost no reason to try to match brackets at all. It's like complaining about having to read semi-colons in languages that use them to signify the end of a statement. When writing code, Lisp is just another language like all the rest that benefit from an IDE that is syntax-aware. Having highlights for the starting paren and ending paren for an expression and being able to just select a particular expression make bracket matching fairly effortless.

It's clearly worse just because it moved from infix to prefix and is wrapped by parens? Is `(* (+ a b) (+ c d))` clearly worse than `(a + b) * (c + d);`? Both have a bunch of parens, and one even has a semi colon.

This works both ways. `(list 1 2 3)` is clearly better than:

        var l = new List();
        l.add(1);
        l.add(2);
        l.add(3);

How often are you trying to make sense of a bunch of infix arithmetic operations when you're programming? Separately, how often are you creating data structures, navigating data structures, handling data in the form of JSON or XML, parsing that data into your language's native data structures, etc.?

Reading arithmetic in prefix instead of infix is easy, even if it is counter to how you were taught in elementary school. Working with s-expressions for code and data is clearly better than whatever syntax your language uses for code and either directly instantiating data or reaching for JSON or XML.

> justify its lack of static typing

Racket has both Typed/Racket as well as contracts.

https://docs.racket-lang.org/reference/streams.html

https://docs.racket-lang.org/threading/introduction.html

This question has been answerable in Dolt for years now.

Next, I wanted to see if this could be done with a local LLM. Gemma-4 handles this fine with an 8GB video card and a large context (128k).

Next, I wanted to see if the model could also OCR these docs and translate them. The same model can handle that quite well.

This was when I realized LLMs should be great for handling work where:

- I already know what I want to do

- I already know how to do it

- I don't think this task will help develop skills I find to be valuable

- If I have to do it manually myself, I will probably cut corners

So now I view LLMs through the lens of, "what work can I send to an LLM that I otherwise would not really care about doing."

Please, preach your gospel more loudly and frequently. It always feels like people complain about RDBMSs being slow because they run insert queries one at a time.

Here's a layup: art. Remember the writer's union strike in 2007-2008? All of the shows whose writers were on strike that still went on were terrible.

Edit: also, the purpose of a union is not to "produce something better". The purpose of a union is to protect workers' rights. They generally serve their purpose very well.

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...

[1] https://github.com/racket/gui/pull/95

> 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.