You assume it was me that opened the page on a desktop or something with a primitive keyboard. I asked my agent to summarize and provide me the list of links to see if it was there. The list did not list bun. The code it executed through my phantomjs mcp server was simply:
> If you type out somebody's work, you learn a lot about it. Amazingly it's like music. And from typing out parts of Faulkner, Hemingway, Fitzgerald - these were writers that were very big in my life and the lives of the people around me - so yea I wanted to learn from the best I guess.
> You don't get reams of wishy-washy code unless you ask for it.
I've found that they get pretty wishy-washy when you correct them. As an example, yesterday I was working on porting a function from the open-source CUE4Parse project from C# to Python (for a hobby project), and the LLM (Gemini 2.5 Pro) suggested the following translation of a C# method:
@staticmethod
def from_name(name: str) -> 'FPackageId':
# C# Encoding.Unicode is UTF-16 LE in Python
lower_name_bytes = name.lower().encode('utf-16-le')
hashed_id = CityHash64(lower_name_bytes)
return FPackageId(hashed_id)
I noted that the original used a custom ToLower() implementation:
> This custom ToLower(), does that produce the same result as .lower() in Python?
Gemini answered with a lot of text and concluded: "You should use Python's standard lower() method for your port."
I pushed back with:
> Right, but for this to work (looking up an asset by its hash as contained in global.utoc), I probably have to match the behavior of Unreal Engine...
Gemini: You are absolutely right. My apologies, your insight is spot on. For the purpose of matching hashes that are pre-calculated by Unreal Engine and stored in files like `global.utoc`, you **must** replicate the engine's behavior exactly. My previous advice to use Python's `.lower()` was incorrect in this specific context.
You need to implement a function that behaves identically to the C# `ToLower` you highlighted. The engine uses this specific, non-Unicode-aware, ASCII-only lowercasing function before hashing the path to generate the `FPackageId`. Using Python's standard `.lower()` would produce a different byte sequence for any path containing non-English characters, leading to a hash mismatch.
From my experience this is representative of the typical LLM interaction once one ventures into niche topics like Unreal Engine modding.
Yes, if they make a mistake and you point it out, they will make another mistake. In many of those cases, it's better to scrap it and start with a fresh context, try a different prompt (or provider smaller context).
Also, more importantly, they will ignore negative directives. So telling it: "don't do X" , will get ignored. You are better of using positive directives instead.
It's pretty difficult to have a useful back and forth with an LLM, because they're really heavily finetuned to be agreeable (and also they're not particularly smart, just knowledgeable, so their 'system 1' is a lot better than their 'system 2', to analogize with 'thinking fast and slow'). Generally speaking if they don't get a useful answer in one shot or with relatively simple, objective feedback, they're just going to flop around and agree with whatever you last suggested.
But, to make a comparison here with Claude Code, I was initially impressed with Geminis ability to hold a keep a conversation on track, but it rarely gets the hint when I express annoyance with its output. Claude has an uncanny ability to guess what I find wrong with its output (even when I just respond with WTF!) and will try to fix it often in actually useful ways, Gemini just keeps repeating its last output after acknowledging my annoyance.
Loved using OCaml for a compiler course at uni when I was a student. But I've always felt that the tooling side is pretty rough, especially on Windows. Opam recently added Windows support, but it involves installing MinGW, and when following the official docs https://ocaml.org/docs/installing-ocaml#install-platform-too... the process breaks down with an error when trying to install utop due to a path separator error, which one has to fix manually (at least that was the case last time I tried). By comparison, installing Python or Rust on Windows is a breeze.
Never played with OCaml, but I spent the past few days learning about F# (my understanding is that it inherits a lot from OCaml). Tooling seemed great: I used JetBrains Rider; VSCode and Visual Studio are also options. Support seemed great: good official docs; good book choices. Ecosystem seemed great: entire .Net class library.
I’m been on the JVM for 20+ years, but an opportunity came up to leverage some of my other experience to get some CLR work… and I dove in.
F# has diverged from OCaml a bit, but they're still very similar.
I mentioned in a top-level comment that F#'s "lightweight" syntax is basically what I want when I use OCaml. I know ReasonML is a thing, but if I'm writing OCaml I don't want it to look more JavaScripty - I prefer syntax like "match x with" over "switch(x)" for pattern matching, for example.
I know some people dislike the way F#'s newer syntax makes whitespace significant, and that's fair. But the older verbose syntax is there if you need or want to use it. For example, something like
let things =
let a = 1 in
let b = 2 in
let c = 3 in
doSomething a b c
Thank you! I knew this, but of course blanked on it when I came up with an Ocaml example.
There are a few other places I prefer F#'s syntax, but overall it's not the reason I'd pick F# over OCaml for a project. It's usually mostly about needing to integrate with other .NET code or wanting to leverage .NET libraries for specific use cases.
Can't lose either way - they're both a please to work with.
I used to fiddle with F#, its tooling is good, but it's interweaved with too much dotnet c# cruft and also there's the dark shadow of Microsoft. I wish it had zero cost abstractions like Rust because most things you write in F# is also slower than C#
Dune is a very powerful and good build system — it can do some very magical and useful things. The only problem is most of these useful features are very poorly documented…
Personally, I think it's a shame that JetBrains get such flack for collecting telemetry in their free products when Microsoft do the same in VS Code with hardly anyone voicing the same level of criticism for it.
