derdi

The compiler bothers me more. When it encounters an error it seems to give up on the rest of the file. This makes the iteration loop quite slow - write code, get an error, fix the error, rebuild. There's very little chance to fix errors in bulk, especially if you're focussed on one module.

Are there languages where this actually works, in actual practice? No compiler I have ever used in anger was reliable enough in its error recovery, no matter how hard it tried. So when working on the command line, I always scroll up to the first error and ignore the following ones. Any work the compiler puts into showing me more than the first error is wasted, from my point of view. And it wastes my time, so I view this as a net negative. Again, not the lofty idea, but the practical implementation in compilers I've used. (IDEs can be better. IntelliJ is sometimes even actually good. Not always.)

The author mentions Rust, is the Rust compiler really that good at reliably guessing the correct way to recover? Even in the face of, say, complex type errors?

These are both "tactics". The article defines tactics as "instructions that help reduce the current goal". Writing a proof consists of starting with the thing to be proved and then writing a sequence of tactics to break the problem up into progressively easier and easier problems, until everything is broken down into things that are trivially true.

"rfl" stands for "reflexivity", the mathy term for "everything is equal to itself". As the article says, "[rfl] deems two things equal if they are equal by computation". That is to say, if the current subproblem is of the form "prove x = y" where both x and y are some sort of expressions that clearly evaluate to the same value, then applying rfl will finish the proof and mark this problem as solved.

"decide" is another tactic. Not sure where you got it from, I don't see it mentioned in this article. But basically it's a more powerful "I don't want to write out all the steps of this, please try to prove it for me" command.

Very well put. I'll just add that there is one more thing one can do to document the important/insightful/interesting parts of a proof, where it makes sense: Write a comment.

What is mostly? >50%? >75%?

1. Don't ask us, ask the Codeberg people in the thread above.

2. If you're not sure you can meet Codeberg's terms of service, do what others are claiming to do: Take your repositories elsewhere.

3. I'll just hypothesize that you don't have Codeberg repositories and are only arguing here for argument's sake.

And the actual judgment: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62...

I find these are often very readable and interesting.

Yes

I don't know if they can expand, but I did last time this was posted: https://news.ycombinator.com/item?id=48884619

Fair.

Yes. I don't like phrasing this as being prospective for the World Cup as a whole. It's for the knockout stage. (Which the abstract says! But the title doesn't.)

Applied prospectively to the in-progress 2026 World Cup from the Round of 32, the model identifies Argentina (28.0%) and Spain (21.1%) as the leading championship candidates.

Seems weird to wait to run the "prospective" simulation until the World Cup is already in progress. Although it seems that the model also needs to use "the actual bracket and group-stage performance". So it's not prospective?

dark late into the morning, but it also makes it unsafe for kids going to school.

This is such bullshit.

What is unsafe for kids is human drivers driving their death machines into kids. The solution is not messing with clocks. The solution is convincing human drivers that they should not drive their death machines into kids.

You are presumably based in some location where "standard time" has year-round daylight around the time school starts. Guess what, many people live in locations closer to the poles where this is not the case. What do you do in a location where winter daylight hours are only between (say) 10:00 and 15:00? Have school start later and later, and have school days be shorter and shorter? Do such locations have the sides of their roads littered with child corpses, or do such locations enforce better driving?

Also, even in locations with longer days but all-day school, it's often dark when kids get out of school, especially after any extracurricular activities. At that point it's dark, and the kids are tired after a long school day, and the drivers are also tired after a long day at work. If anything, that would make them even more dangerous. The fact is, for many locations it's simply impossible to enforce that kids only go to and from school in broad daylight. Any problems arising in the dark (not from the dark!) must be solved in other ways than magically wishing for the sun to shine when it simply doesn't.

Once, during an especially tedious review session, I told my agent something like "comments are not meant to demonstrate how well you understand the system, they are meant to help others understand the system". It felt like that helped.

Just in case the above is not considered constructive enough, how about this: In my experience, with some prompting and iterations, AIs do reasonably well at writing solid, "boring" code. They do really badly at writing useful documentation, and this is a major pain point when reviewing their output. A system that claims to be oriented towards human review must address this somehow. It must talk about how it addresses it, and it must demonstrate that its own documentation is significantly better than unfiltered LLM output.

This system does not demonstrate this. It needs clear guidelines: Start with the big picture. Show an example. Show comments in that example. Don't get bogged down in the details of the internal workings of the compiler. Don't use jargon like "kernel" to mean "lowered intermediate representation". Don't use "carrier" when you mean "file". It's just a file, FFS. But again, don't tell me at all about the fact that there is an intermediate representation; that's not "big picture", and anyone who cares about compiler internals will already have guessed that you have an intermediate representation. Do tell me about the effect system in the first two paragraphs! That seems to be what sets this language apart. Do give me a brief argument why an effect system is a good match for a system where humans don't have to type everything by hand. And so on and so forth.

a C-emitting native AOT backend that currently compiles the kernel .jqd carrier

This human reviewer gave up at line 4 of the Readme. What is the kernel? What does the carrier carry? Why does it need to be carried? Where does the .jqd come from?

Also, for whatever reason, from the submission here:

I had AI analyze the ASTs of several mainstream languages plus a few of the conceptually groundbreaking but esoteric ones (listed in the README)

No, they are not listed in the Readme. Why lie to us right off the bat?

I like the general idea, but the human responsible for this seems to demonstrate no interest in actually reviewing their system's output. Which does not bode well.

OK, I see your point. I think there are (at least!) two categories of content creators here: On the one hand, those that consciously want to generate content spam. On the other hand, those that actually want to do "cool technical stuff" that was previously impossible for most people working alone with limited time on their hands (develop your own programming language etc.). As I argue at https://news.ycombinator.com/item?id=48892642, I think there is really a part of the latter group that are simply unable to recognize LLM-speak as bad style. It's how the LLM speaks to them, it doesn't bother them; since the all-knowing LLM does it, it must be fine. I don't know. I don't understand these people, but I believe they exist.

For example, consider this project where I also complained about atrocious writing: https://news.ycombinator.com/item?id=48876506. I think this is really just someone who wanted to "create" something, I don't think this is in the same category as recipe/blog spam. I don't think the person who put this online thinks that this landing page is worse than any other programming language website.

A little detail to your extra detail :-) I agree that there's a general "it'll do", motivated by just pushing something, anything, out there. But I think that's party because they don't know better. The people who generate the articles that reach the HN front page surely interact a lot with their agents. Their agents will certainly talk to them in "AI-shaped", "LLM-marker-bearing" bot-speak, but they apparently don't mind, because they can't tell that this is bad writing. If they did, if this annoyed them as much as it annoys many of us, they would surely adopt some style guidelines for their agents. And those should apply to their blog posts too.

As for the rating system, we already have many people who first check the comments for things like "AI, don't bother". I think that's OK; it could be better by quoting two or three sample sentences so that others could quickly judge how bad it is. I don't think it needs to be more formal than this.

I don't know, I wasn't saying that there was an upside. Sorry if my post was unclear. My "I don't think this is true" was in response to the assertion that people who use AI would be afraid of losing credibility from labeling.

Nobody wants to label their stuff as AI generated because they removed credibility.

I don't think this is true. I think most of the people who post LLM content without editing and without even style guidelines are simply of the opinion that the resulting text is genuinely of an acceptable quality.

Agreed with the rest of your post. We should think of this in terms of quality of the result, not the process.

The docs could use some cleanup, by which I mean "throw away all the stupid jargon". How does one publish this homepage with the term "width-bearing" on it? This is not a term of the trade. It's not even "little known" or "niche", it has literally zero Google hits outside this project's documentation. (This post will be the first one.) "Fixed-width type" is right there.

The term "extensions" is also weird. It seems to be used for two things: One, "libraries" (any standard types and functions they wanted to include but don't inherit directly from the CLR's library). Two, a "Go-shaped" (*sigh*) "extension" that is both a "library" (some trivial functions like `len`) and also changes the language by adding channels and some new syntax! Wow, syntax can be imported with an import statement! But only this specific syntax, with this specific import!

And this is "opt-in", and an extension. But... it's right there. It ships with the language. It is in the language. That's not what an extension is to normal humans. And opt-in, sure. I guess I wouldn't have to use it. Just like every other language feature I don't feel like using?

Neither use as an implementation language nor syntactic similarities make one language a dialect of another. Consider that Java is commonly implemented in C++, and its syntax was designed to be easy to learn for C++ users. Yet nobody calls it a dialect of C++, not even when squinting really hard.

Erlang's computation model is functional, like Lisp, unlike Prolog.

They might want to make their docs less confusing. https://query.mt/showcase/gpu-sharing/ says "no API key needed", and talks about running llama.cpp on a friend's GPU. No API keys are needed for this. But then the page goes on about who "holds" API keys, and where API keys "stay", where API keys are "locked", etc.

Sometimes, for instance, you might not even have access to the whole state because some of it resides on a remote server.

Not sure what you mean. The system I outlined is one where some "state" resides outside the process in a separate server. You don't need to serialize that, you just need to serialize the information to need to reconnect.

And my first point is even more relevant the more complex/distributed/brittle you make the whole thing: The more important it is for some specific process to stay alive no matter what, the less you want to live-slop code into it.

(Edit: Yes I'm aware of the live-patched space probe story. Human live-patching is not the same as letting an LLM try to one-shot the correct patch.)

There is no good reason for running this in-process. The maximally inefficient Fibonacci function in the article is a good demonstration why: Call it with a slightly larger number, and your agent slows to a crawl, with no way to enforce a timeout. Call it with a slightly larger number yet, and you might bring your agent down entirely, with no way to recover.

There is a case to be made for a dynamically evolving "tool server", but it should be a separate process. That would be more flexible for other use cases too. For example, multiple independent agent processes could talk to one shared tool server. Like a blackboard system, more classic AI!

And if you really do want to evolve the agent itself: As the article observes, its entire state can be serialized. Nothing is gained from hanging on to one particular agent process. Serialize its state, ask the tool server to kill it, rewrite its code, then start the new version and replay the state.

It doesn't matter if a human or a machine wrote it, it's just unpleasant to read. I don't know what the OP's motivation for their post was, but I think it's reasonable to point out that something is harder to read than it should be.

What's the fuzzing story? If this is meant to be a product, hopefully it's being fuzzed 24/7, using multiple state-of-the-art JavaScript fuzzers, against multiple state-of-the-art JavaScript engines?

Is "loop" a common term for... whatever it's used for here?

Anyway, this looks like it might be a fun way to gamify TODO lists. Would be interesting to see some output after some goals have been achieved. Screenshots of the web UI maybe?

This is a good list. Other reasons are that the JIT has more information about the program. The Java-to-bytecode compiler never sees the whole application, and it knows nothing about which program paths are actually executed in practice. The JIT compiler, in contrast, knows about the loaded class hierarchy, and it has access to type and branch profile information. This enables the JIT to do aggressive inlining of method calls and pruning of branches that are never executed. These are probably the most important transformations that lead to the discovery of opportunities for these mask optimizations. The source code that javac sees will contain very few relevant cases.

Again, I'm not criticizing that person specifically. They repeated a word that appears in all the articles.

There are two points I was trying to make:

1. At the relevant time, there were no separate Eastern and Western empires, so this city was just Roman, without qualification.

2. Even later, it could just be called Eastern Roman. Calling it Byzantine instead may be a conscious choice to make the Roman-ness disappear. More likely it's just deeply implanted, based on an education that was based on making the Roman-ness disappear. Again, I'm speaking about the general use of the term in all the articles, not by the OP.

Anyway. Even the person in this thread arguing most vehemently for the use of the term Byzantine says it applies to the "latter eastern Roman empire". So it shouldn't be used for this city, since it's neither form the Eastern empire (which, again, did not exist yet) and especially not from its latter period.

So I shouldn't call them Romans, since that is an English translation of what they called themselves, and thus foreign to them.

But you can call them Byzantines, an English term invented in the 19th century, because... you say so? Thank you, I have been enlightened.

"Constantine split the empire" is just incorrect. There were co-emperors with regional responsibilities both before and after him. They were co-emperors of one empire. If you want a firm split, 395 (death of Theodosius) is the more common date AFAIK.

I'm not denying that gradually, over well more than a thousand years, the empire (only surviving in the East) changed character in many ways. I am denying that a unique Eastern character sprang up (and immediately applied to Egypt) the moment that Constantinople was founded.