Hello HN. There's still a long road ahead for the project, but since I've recently closed the loop on bootstrapping the language's core within itself, I thought now's as good a time as any to throw it out there and start getting other people's takes on it.
Chirp is my attempt at engineering a programing language from the ground up that packs together all my favorite bits and pieces into one tight and consistent package. It's got a bit of Rust, a bit of Zig, a LOT of TypeScript, and a lot more LISP than I initially expected.
What sets it apart is its treatment of sets as a trait, and how they are used to express constraints on variables while keeping the code as boring and straightforward as possible.
Here's a taste:
let fizz = { x:int | x % 3 == 0 };
let buzz = { x:int | x % 5 == 0 };
let fb_range = 0 ..= 100;
let eval(v: fb_range) = match v {
fizz ∩ buzz => "fizzbuzz",
fizz => "fizz",
buzz => "buzz",
`any => f"{v}"
};
for (v ∈ fb_range) `print(eval(v));
To manage expectations: Code emission isn't ready yet. As things stand, it's effectively a scripting language with an intuitive set-centric syntax and runtime constraint checking. But, especially since scripting a compiler is what it's meant to do, I think it's still enough to show around a bit.
> and to avoid the warning (error) the code is decorated with compiler pacifiers, which makes no sense!
How is that a bad thing, exactly?
Think of it this way: The pacifiers don't just prevent the warnings. They embed the warnings within the code itself in a way where they are acknowledged by the developer.
Sure, just throwing in compiler pacifiers willy-nilly to squelch the warnings is terrible.
However, making developers explicitly write in the code "Yes, this block of code triggers a warning, and yes it's what I want to do because xyz" seems not only perfectly fine, but straight up desirable. Preventing them from pushing the code to the repo before doing so by enabling warnings-as-errors is a great way to get that done.
The only place where I've seen warnings-as-errors become a huge pain is when dealing with multiple platforms and multiple compilers that have different settings. This was a big issue in Gen7 game dev because getting the PS3's gcc, the Wii's CodeWarrior and the XBox360's MSVC to align on warnings was like herding cats, and not every dev had every devkit for obvious reason. And even then, warnings as errors was still very much worth it in the long run.
It's not just a pure matter of law, and looking at it from that perspective is naive.
Legacy publishers in general (and a few big ones in particular, like der Spiegel) have been lobbying hard for legislatures to redirect big tech revenue to their failing businesses.
The focus on AI here is really just the continuation of that ongoing fight that has been raging for over a decade now. If it wasn't that, it would be some other wedge.
I'm not saying Google is squeaky-clean here, far from it. However, it's important to keep in mind that the main drive here is to get publishers paid, not to force Google to be accountable to some specific standards.
In the grand scheme of things, we've only had about a quarter century where you needed a *very* specific kind of problem where prosumer hardware wasn't adequate across computer science as a whole.
It's kind of amazing we got that at all for a while.
There's no confusion here. It's pretty easy to make the argument that the combination of auto play and short form is orders of magnitude more problematic than the sum of their parts.
There is a HUGE difference in that the combined short length with the fact that the video starts playing before you even have a chance to make a decision on whether to watch it or not leads you to a "heh! I'm here already, might as well just watch the thing".
Honestly, I don't mind the format in principle, and the process that goes from YT's homepage to watching a single one of them is not that bad to me. As long as I get to make a decision that I want to watch something, consciously go "I will click on this thing and watch it" and only then proceed to watch it, then it's _fine_.
It's the algorithmic loop that starts the moment you scroll to the next video that starts playing before you even have a chance to decide whether or not it's something that you want to watch that's abhorrent to me.
If your argument is that the guardrails only provide a false sense of security, and removing them would ultimately be a good thing because it would force people to account for that, that's an interesting conversation to have
> Have you read the literature? Do you have a background in machine learning or statistics?
Very much so. Decades.
> Being trained by predicting one token at a time is also not a criticism??! It is just a factually correct description...
Of course that's the case. The objection I've had from the very first post in this thread is that using this trivially obvious fact as evidence that LLMs are boring/uninteresting/not AI/whatever is missing the forest for the trees.
"We understand [the I/Os and components of] LLMs, and what they are is nothing special" is the topic at hand. This is reductionist naivete. There is a gulf of complexity, in the formal mathematical sense and reductionism's arch-enemy, that is being handwaved away.
People responding to that with "but they ARE predicting one token at a time" are either falling into the very mistake I'm talking about, or are talking about something else entirety.
> They do it by iteratively predicting the next token.
You don't know that. It's how the llm presents, not how it does things. That's what I mean by it being the interface.
There's ever only one word that comes out of your mouth at a time, but we don't conclude that humans only think one word at a time. Who's to say the machine doesn't plan out the full sentence and outputs just the next token?
I don't know either fwiw, and that's my main point. There's a lot to criticize about LLMs and, believe or not, I am a huge detractor of their use in most contexts. But this is a bad criticism of them. And it bugs me a lot because the really important problems with them are broadly ignored by this low-effort, ill-thought-out offhand dismissal.
For the sake of this conversation "understanding" implicitly means "understand enough about it to be unimpressed".
This is what's being challenged: That you can discount LLMs as uninteresting because they are "just" probalistic inference machines. This completely underestimates just how far you can push the concept.
Your pedantic definition of understand might be technically correct. But that's not what's being discussed.
That is, unless you assign metaphysical properties to the notion of intelligence. But the current consensus is that intelligence can be simulated, at least in principle.
Yeah, but that's their interface. That informs surprisingly little about their inner workings.
ANNs are arbitrary function approximators. The training process uses statistical methods to identify a set of parameters that approximate the function as best as possible. That doesn't necessarily mean that the end result is equivalent to a very fancy multi-stage linear regression. It's a possible outcome of the process, but it's not the only possible outcome.
Looking at a LLMs I/O structure and training process is not enough to conclude much of anything. And that's the misconception.
> I feel like LLMs are a fairly boring technology. They are stochastic black boxes. The training is essentially run-of-the-mill statistical inference. There are some more recent innovations on software/hardware-level, but these are not LLM-specific really.
This is pretty ironic, considering the subject matter of that blog post. It's a super-common misconception that's gained very wide popularity due to reactionary (and, imo, rather poor) popular science reporting.
The author parroting that with confidence in a post about Dunner-Krugering gives me a bit of a chuckle.
A choice of tech stack can never be enough to prove anything. It only establishes a lower bound on resource usage, but there is never and upper bound as long as while() and malloc() are available.
You can't have it both ways. If your test for whether something is intelligent/thinking or not isn't applicable to any known form of intelligence, then what you are testing for is not intelligence/thinking.
Ok, but how do you go about measuring whether a black-box is doing that or not?
We don't apply that criteria when evaluating animal intelligence. We sort of take it for granted that humans at large do that, but not via any test that would satisfy an alien.
Why should we be imposing white-box constraints to machine intelligence when we can't do so for any other?
Chirp is my attempt at engineering a programing language from the ground up that packs together all my favorite bits and pieces into one tight and consistent package. It's got a bit of Rust, a bit of Zig, a LOT of TypeScript, and a lot more LISP than I initially expected.
What sets it apart is its treatment of sets as a trait, and how they are used to express constraints on variables while keeping the code as boring and straightforward as possible.
Here's a taste:
To manage expectations: Code emission isn't ready yet. As things stand, it's effectively a scripting language with an intuitive set-centric syntax and runtime constraint checking. But, especially since scripting a compiler is what it's meant to do, I think it's still enough to show around a bit.