In contrast to, say, Java (I can't speak to the code above):
List<Things> things = thingIds.stream()
.map(model::findThing)
.filter(Objects::nonNull)
.toList();
These are streamed. This is pretty much a pipe structure, whereas the threading macros will create a lot of temporary copies of the data (I don't know if that's a universal truth). That is, if you're processing a 1000 items, say `gather` returns a 1000 items, that 1000 item list is passed to `uppercase-list` which return a new 1000 item list to feed to `sort` which returns another 1000 item list (assuming none of these are destructive).
I wish CL had something like the Java streams (maybe it does).
The version with a threading macro, will create a lazy-sequence for each step in the pipeline. It will not instantiate the entire list, so it's O(1) memory overhead in terms of peak memory, but it churns O(N) extra garbage.
(->> things
(map model/find-thing)
(filter some?))
And the version with transducers, which will not create any intermediate sequences:
This kind of DB isn't really answering this question. There's a lot more subtlety to time-span analysis than snapshotting. In particular, aligning two series is non-obvious.
Say you have one time series with CPU-core task switches:
How, in SQL, do you express the question "How many CPU cycles did each task use?"? Try to do it with more complex examples. You'll tear your hair out.
Having worked on this sort of data analysis quite a lot, I'm strongly of the opinion that SQL needs syntax, not just table-valued functions, for expressing questions about timelines.
The cool thing about Dolt is that you [eventually] get the features of the databases (MySQL, PostgreSQL, SQLite, MongoDB) they emulate, so you can have your PG 19 temporality features as well as branching and merging.
I tried to see if an LLM service provider could rewrite some legal docs where nothing was hallucinated in order to follow a consistent format to see what may be missing in the document. It could do that.
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."
Yes, the best results I've had using LLMs are for tasks where simply reading and reformatting/translating/summarizing are the goals. They are much faster and less prone to boredom doing these things than humans are. For now.
My son is in a lawsuit with his bank where they put through fraudulent charges and wouldn't charge them back then the bank sued him for the money. He is using Claude and Gemini fighting the original lawsuit and now has a counter-suit 100% using AI for everything. He puts it into different AI's to check everything against each other and to come up with more ideas. He started with ChatGPT, moved to Grok, then Claude, but now Gemini is turning out to be the strongest.
I'm about as pro-AI as anyone here. I say this with love: anyone using general-purpose, consumer-grade AI for healthcare, law, or taxes is mad. Best wishes to your son, bless his heart, but please have him consult a qualified lawyer before showing up to court with model-drafted legal documents. Among other things, those chats are not privileged information[0] and the banks could subpoena chat transcripts to see what else he might have told them.
He has had multiple hearings and the Judge has reviewed everything. The court clerk reads every submission and before the clerk puts it in the system they have a in-house lawyer review each document. This is pretty far along. The trial is scheduled for October of this year.
The bank has a lawyer, they were hoping for a default judgement because who can afford to fight the bank. The choice is fight it yourself or declare bankruptcy.
As you already know, AI companies trained on every single document they can find. Those include legal documents. The legal system is structured where you have Federal Laws, State Laws, Federal & State Regulations and Court Precedent. Because of this structure it is not difficult for a LLM to figure out.
I'm curious if you can have a judge XYZ skill where you have an ai analyze how that judge ruled for certain judgements in the past, and how similar lawsuits/arguments did in front of them. Might help to angle the ai's findings a tad, or might also not be worth the effort. Both are possible
Good luck to him. I get worried about people using AI for serious work in a field they aren't specialized in, but if it helps him achieve a good outcome, that would be interesting.
I have often felt that the legal system is divided between haves and have-nots: if you can afford to participate, you get "justice" tilted toward you. Easier participation for those without the resources for a lawyer would be good.
The second article I linked, from the MIT Technology Review, is quite interesting. It seems like judges are experiencing some version of what open source maintainers and seniors at companies are experiencing: a much larger review burden due to the cost of generating code or legal arguments dropping drastically.
I wonder what form this structural shift in output versus specialist review capacity will take in other professions. The frontier labs seem to be trying to automate more and more of the "specialist review" process. I am not sure that is feasible in the legal world, but we'll see....
> I would emphasize the importance of batching and set operations.
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.
I agree that S-expressions for defining data are pretty nice, but you don't need to actually use a Lisp to use them. You can just use them like you would XML.
I linked to an example in the comment. In that particular case, I'd say probably 10-20x faster. I do embedded, backend, web and mobile app development.
I also notice these things. Otoh i spend definitely less than 50% of my time typing in code so it is impossible that it gives more than 2x speedup. And sometimes i lose time babysitting and rewriting stuff so all in all it is kinda no productivity gain.
Wow, what an apples and aliens comparison. You add a bunch of transaction delays to your postgresql case because you can access a database over a network, but you use transaction batching for sqlite? Maybe just compare a local postgresql with/without batching to a local sqlite with/without batching to be much less misleading.
Because local postgres is a bad time unlesss it's the only thing running on the server. Even then sqlite will smoke postgres (even with unix sockets).
The point is to survive the Pareto row locking problem you need to move away from a network database (if you want to still have interactive transactions). The network part is the main point of a network database, once you drop that there's not much pointing sticking with the added complexity unless there's another feature you really need.
> What’s an example of a unionized vs non unionized group producing the same thing where unionized is better?
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.
Assuming your comment applies to Common Lisp as well, if Scheme (and Lisp) truly was, "hard to read, unfit for most purposes and that even proficient coders never seem to fully grasp," it wouldn't be the language that introduced so many features later implemented in other languages.
> 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.
https://docs.racket-lang.org/threading/introduction.html
reply