rpeden

I guess it never really occurred to me that people wouldn't immediately grok:

* Luna (Moon)

* Terra (Earth)

* Sol (Sun)

* Astra (Galaxy/Universe)

The relative sizing seems dead simple.

Everything before 8.2 is past EOL.

Is it a grey area, though? Can't negligence and recklessness already substitute for direct intent as the mens rea of a crime?

Negligence when you should have known better, and recklessness when you did know better but still did things that led to the crime occurring.

Given how long the leadership of these companies have been talking about alignment and safety and AI risk, it's hard to argue they, and the people working on the models more directly, didn't know what happened (Hugging Face, RubyGems, etc) was possible.

If more expensive and consequential incidents happen, it seems like the legal machinery to prosecute it already exists.

This gave me the shove I needed to cancel some longstanding Google subscriptions.

So...thanks, Google, I guess?

I actually think COM is an amazing bit of engineering considering its intended use case.

It still feels like a much more advanced way of sharing compiled libraries between different languages than the current default of "export a C ABI and communicate across the barrier via primitive sticks and stones."

COM isn't perfect but I still find it impressive especially since COM/OLE are 40 years old at this point.

You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0.

That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.

I don't live in this broken place you speak of and don't feel the pain you mention.

Outside of work I sometimes user LLMs to create what amounts to infinitely variable Choose Your Own Adventure books just for entertainment, and I don't think that's a problem.

I'm appalled by how dismissive and heartless many HN users seem toward non-professional users of ChatGPT.

I use the GPT models (along with Claude and Gemini) a ton for my work. And from this perspective, I appreciate GPT-5. It does a good job.

But I also used GPT-4o extensively for first-person non-fiction/adventure creation. Over time, 4o had come to be quite good at this. The force upgrade to GPT-5 has, up to this point, been a massive reduction in quality for this use case.

GPT-5 just forgets or misunderstands things or mixes up details about characters that were provided a couple of messages prior, while 4o got these details right even when they hadn't been mentioned in dozens of messages.

I'm using it for fun, yes, but not as a buddy or therapist. Just as entertainment. I'm fine with paying more for this use if I need to. And I do - right now, I'm using `chatgpt-4o-latest` via LibreChat but it's a somewhat inferior experience to the ChatGPT web UI that has access to memory and previous chats.

Not the end of the world - but a little advance notice would have been nice so I'd have had some time to prepare and test alternatives.

Is |> actually an operator in F#? I think it's just a regular function in the standard library but maybe I'm remembering incorrectly.

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.

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

should still work in F# like it would in OCaml.

I like OCaml a lot - but I think I like F# a little more. They're very similar, since F# as essentially Ocaml running on the .NET VM.

I know some people dislike the fact that F# lacks OCaml's functors, but I can see why they weren't included. Due the the way F# integrates .NET classes/objects, I can accomplish more or less the same thing that way. In some ways I prefer it - a class/type full of static methods has the same call syntax as a module full of functions, but gives me the option of overloading the method so it'll dispatch based on argument types. Having everything that's iterable unified under IEnumerable/Seq is nice, too.

Having said all that, I still enjoy OCaml a ton. One thing I wish I could have is F#'s updated lightweight syntax brought over to OCaml. I think ReasonML is great, but after using it for a while I realized that what I really want isn't OCaml that looks more like JavaScript. What I want is OCaml that looks like OCaml, but a little cleaner. F# gives me that, plus, via Fable, compilation to JS, TypeScript, Python, and Rust. And via the improved native AOT compilation in .NET 9, I can build fast and reasonably small single-file executables.

Despite all that, I still try to dive in OCaml whenever it's a decent fit for a problem for the problem I'm trying to solve. Even if it's a little quirky sometimes, it's fun.

For the tangible ones, it's often relatively easy to get financing that lets you spread the payment over the asset's useful life, which solves most of the cash flow issues you get if you pay in cash up front but have to spread the expense over many years.

It's a lot easier to get financing for a tangible asset like an oven or a delivery truck, which mitigates the cash flow issue.

Sure, you can only deduct a certain percentage of the asset's value as an expense each year, but your cash expenditures to pay for it are also spread over a multi year period.