mightybyte

I think there are two ways one could look at this. One is to make each move be a move of the player's location. If you do that, then the branching factor is obviously < 8. But there's a second way you could define a "move" for the purposes of a solver. And that would be to only consider pushes. In that case, the branching factor would be < 8*num_stones.

In either case, I think when trying to assess complexity it might also be useful to consider the "narrowness" of the winning move sequence. Positions where the number of moves that win/make progress towards the goal is a small fraction of the number of available moves would arguably be harder or more complex than positions where a larger percentage of the moves win/make progress. In other words, finding a smaller needle and/or in a larger haystack makes the problem harder / more complex.

Oh, skills are absolutely useful for giving the LLM distilled knowledge of things that it doesn't just know ("off the top of its head" so to speak). For example, a company's coding style guide is something that could be very useful to express as a skill.

Haskell gives you quite a powerful set of tools for constraining and reasoning about your program's behavior. For instance, its ability to define pure functions and control side effects is a very powerful tool for preventing certain classes of bugs. Dereferencing invalid pointer locations and out of bounds array lookups are large classes of bugs in mainstream languages that Haskell basically eliminates entirely. It's not at all the same thing as what you get from the type systems in languages like Java, C++, etc. You really have to try it to appreciate it.

How much code do you think is necessary for LLMs to be good enough?

One plausible future I can see from here is that we see a shift in our relationship to code in high-level languages that is similar to what happened with code written in assembly language back when the first high level languages were introduced. Before them, software engineers operated in assembly language. They cared about the structure of assembly code. This happened before I started my professional software career, but I can imagine that a lot of the same things we are hearing from developers today were heard back then. Concern about devs producing code they didn't understand, the generated assembly not being meant to be understood by others, etc etc.

Now, however, we know how that played out in the case of assembly language. The fact of the matter is that only a very tiny fraction of software engineers give the structure of the compiled assembly code even passing thought. Our ability to generate assembly code is so great that we don't care about the end result. We only care about its properties...i.e. that it runs efficiently enough and does what we want. I could easily see the AI software development revolution ending up the same way. Does it really matter if the code generated by AI agents is DRY and has good design if we can easily recreate it from scratch in a matter of minutes/hours? As much as I love the craft and process of creating a beautiful codebase, I think we have to seriously consider and plan for a future where that approach is dramatically less efficient than other AI-enabled approaches.

Hmmm, I used OpenCode for awhile and didn't have this experience. I felt like OpenCode was the better experience.

I have been unable to use OpenCode with my Claude Max subscription. It worked for awhile, but then it seems like Anthropic started blocking it.

The thing that annoys me most of all is they block me from using OpenCode with my Claude Max plan. I find the OpenCode UI to be meaningfully better than Claude Code's, so this is really annoying.

This is why I think (at least given the current state of AI code generators) that senior engineers will benefit more from AI than less experienced engineers. I don't know exactly what the chart of experience (on the x-axis) and amount of productivity gain from AI (on the y-axis) will look like, but I'm pretty sure it will be roughly (given suitable error bars around the input) a monotonically increasing function.

No, this is not at all a given. There could be switching costs that cause people to stay on a product that is actually worse. Users also simply might be unaware of alternatives or that they are better. It's not hard to imagine any number of other reasons why in our imperfect world there is not perfectly elastic competition.

It also could happen because tech companies have optimized their products to maximize the amount of time that people spend on them, often in ways that directly result in a worse user experience (by showing ads instead of the most relevant search results, for example).

The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. I'm not aware of any broadly accepted consensus definition. Sometimes people want to use this category to talk about purity and control of side effects and use the term "functional programming" to refer to that. I would advocate the more targeted term "pure functional programming" for that definition. But in general I try to avoid the term altogether, and instead talk about specific language features / capabilities.

Was just talking with someone the other day who used to write Haskell professionally but is now using Python. He said that in his experience when there are bugs the "blast radius" is much larger in a dynamic language like Python than in a static language like Haskell. That has been my experience as well.

Something I haven't seen talked about, though, is how powerful the type system is for constraining LLMs when using them to generate code. I was recently trying to get LLMs to generate code for a pretty vague and complex task in Haskell. I wasn't having much luck until I defined a very clear set of types and organized them into a very clear and constrained interface that I asked the LLM to code to. Then the results were much better!

Sure, you can use these same techniques in less strongly typed languages like Rust, and you can probably also use a similar approach in dynamically typed languages, but Haskell's pure functions allow you to create much stronger guard rails constraining what kinds of code the LLM can write.