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.

Sounds like this should live in Wikipedia somewhere on https://en.wikipedia.org/wiki/Ellipse...or maybe a related but more CS focused related page.

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.

He's also won the International Obfuscated C Code Contest 3 times.

https://www.ioccc.org/authors.html#Fabrice_Bellard

One of my favorite pieces on this topic is this talk "Stop Treading Water: Learning to Learn":

https://www.youtube.com/watch?v=j0XmixCsWjs

It definitely has things in common with meetup.com. But it looks meaningfully distinct to me because the appear to specifically have some kind of strong preference against connected devices. Honestly, I've been wishing for things in this vein recently because of the feeling that our world is growing too superficial with our faces buried in phones and being fed by addictive algorithms.

That being said, I think you're right about some of the challenges that an effort like this will encounter.

Yeah, comparing to how you'd solve this in any other mainstream language is really an apples-to-oranges comparison here because this is explicitly tackling the contrived problem of solving it at the type level rather than at the much more common value level. Very few languages in existence have the ability to do this kind of type-level computation. I'd say Haskell is really the only language that could conceivably be called "viable for mainstream use" that currently supports it, and even in Haskell's case the support is new, largely experimental, in a state of active research, and not well integrated with the ergonomics of the rest of the language.

As a professional haskeller, I feel it necessary to point out for people in this thread who are less exposed to Haskell and who may be Haskell-curious...this is not what real-world commercial Haskell code looks like. To use a C analogy, I'd say it's closer to IOCCC entries than Linux kernel code.

In this same vein, Hot Ones minus Sean might be pretty entertaining as well.

I would argue that the title is misleading and overly alarmist here. This particular bug may have involved recursion and a stack overflow, but that's like saying "malloc kills" in the title of an article about a heap overflow bug. The existence of stack overflow bugs does not imply that recursion is bad any more than the existence of heap overflow bugs implies that malloc is bad. Recursion and malloc are tools that both have pretty well understood resource limitations, and one must take those limitations into account when employing those tools.

My default uninformed assumption would be that Google is paying Mozilla for making Google the default search engine for Firefox. Does anyone know if this is the case, and if so, what the likely magnitudes are? Because it seems like Google can throw quantities of money at Mozilla that would easily overwhelm whatever pressure this petition might put on them.

If you've made any kind of DNS entries involving this subdomain, then congratulations, you've notified the world of its existence. There are tools out there that leverage this information and let you get all the subdomains for a domain. Here's the first one I found in a quick search:

https://pentest-tools.com/information-gathering/find-subdoma...

There's a spectrum of efficiency/redundancy choices an organization can make. On one (theoretical) end of the spectrum the organization maximally leverages each individual's unique skills/knowledge. This is the most efficient part of the spectrum. On the other end every person is an interchangeable cog. This is the most resilient but also least efficient part of the spectrum. Small organizations usually skew much more to the efficiency end of the spectrum because they typically have significant resource constraints. As an organization grows, more people depend on its existence, and my observation has been that resilience and self preservation typically become more important than efficiency. This phenomenon is not unique to governments, it happens in all kinds of organizations.

I have a question for all the LLM and LLM-detection researchers out there. Wikipedia says that the Turing test "is a test of a machine's ability to exhibit intelligent behaviour equivalent to, or indistinguishable from, that of a human."

Three things seem to be in conflict here:

1. This definition of intelligence...i.e. "behavior indistinguishable from a human"

2. The idea that LLMs are artificial intelligence

3. The idea that we can detect if something is generated by an LLM

This feels to me like one of those trilemmas, where only two of the three can be true. Or, if we take #1 as an axiom, then it seems like the extent to which we can detect when things are generated by an LLM would imply that the LLM is not a "true" artificial intelligence. Can anyone deeply familiar with the space comment on my reasoning here? I'm particularly interested in thoughts from people actually working on LLM detection. Do you think that LLM-detection is technically feasible? If so, do you think that implies that they're not "true" AI (for whatever definition of "true" you think makes sense)?

Google search is completely broken IMO. I stopped using Google search years ago and every time I go back on the off chance that it's bigger index has something that DuckDuckGo couldn't find for me.

Image search isn't great either but it still often gives me something close and that usually satisfies my image searching needs.

I still find YouTube recommendations quite good for me, but there are occasional ones I've watched already. I still go down its fun (and educational!) rabbit holes all the time.

I think the fundamental approach being taken by this project is immensely valuable to the world. This kind of education about open standards might actually be the most powerful tool that can help us take steps in the direction away from giant opaque corporations and back towards the systems based on open standards that the internet originated from. I really hope this project continues to be updated and get more and more eyes and contributors. If you feel the same way, I'd say at least throw it a GitHub star. https://github.com/blakewatson/htmlforpeople

(Note: I have nothing to do with this project thus far and have nothing to gain from saying this.)

The Evolution of Cooperation by Robert Axelrod https://www.goodreads.com/book/show/366821.The_Evolution_of_...

See also https://ncase.me/trust/ for a really nice 30-min interactive summary of the ideas presented in the book.

My rough definition of "best" here is "most potentially impactful to humanity" (see also Andrew Breslin's Goodreads review).

> I have the sense that Youtube is net bad for the world and the monetization of Youtube has incentivized and amplified mediocrity, stupidity, and social decay.

Interesting that you say this regarding YouTube. I've been saying this regarding Twitter for awhile even though I consume quite a bit of YouTube content. However, I've curated my YouTube feed to be almost entirely stuff that is interesting, educational, and that I think I'm getting value from. I've learned tons of useful stuff from YouTube such as how to dress better and tailor my own clothes, how to fix things that break around my house, more effective training methods to accomplish specific fitness goals...I could go on and on. When I go to YouTube in incognito mode, I definitely see the bottom-of-the-barrel content that you're talking about. But it doesn't have to be that way.

> That's why, if you like the Haskell philosophy, why would you restrict yourself to Haskell? It's not bleeding edge any more.

Because it has a robust and mature ecosystem that is more viable for mainstream commercial use than any of the other "bleeding edge" languages.