> absolute position of hating something such as AI and progress
Most takes I've seen are far more nuanced.
Key is that 'progress' has a positive connotation. It is different from change. Mere change - such as new inventions - may not necessarily be aligned with progress in a field, society, etc.
Change may be inevitable, but it's up to us humans to sculpt it into progress.
But I am talking about Zig and others who have the same stance. Zig has a very strict No LLM / AI contribution policy and it likely got in the way of the Bun maintainers at Anthropic. From [0]
>> No LLMs for issues.
>> No LLMs for patches / pull requests.
>> No LLMs for comments on the bug tracker, including translation.
They don't hate it. There's no antagonism that I know of there. I believe they want it to be fully human-authored and want low-hanging fruit items to be good onboarding for developers, not targeted by AI contributions. Simon Willison wrote a good blog post on it: https://simonwillison.net/2026/Apr/30/zig-anti-ai/
2% on the Linux kernel. 1% on open hardware. 4% on blockchain.
I think that says it.
They do support many other projects and seem to be stewards of the Linux ecosystem in general, but... 4% on blockchain?! I also feel many other projects should have their own funding: they're key to many businesses and that the 'Linux' foundation sponsors them is (a) good but (b) misplaced in the overall messed up system that is open source reliance and sponsorship.
Oddly, I found the bios as interesting as the behind the scenes photos (though I enjoyed the full life T-Rex on the wall!)
Jurassic Park came out before Pulp Fiction, and stars Samuel L Jackson:
> Jackson made his indelible mark on film with his portrayal of a crack addict, Gator, in Spike Lee's "Jungle Fever." For this searing characterization, Jackson received the first Best Supporting Performance award ever given out by the judges at the Cannes Film Festival. Jackson's versatile career, which includes film, television and stage work began...
Thirty years later, to me, he is indelibly associated with Pulp Fiction. Bios like this are a mark into how people were seen in the past. I's fascinating seeing what an impressive career he had (he was a stage actor, too, which I -- I'm really marking my generation with this whole comment -- only learned reading this) that has been almost erased by the subsequent career trajectory he had.
As the other commenter said, I don't think contributing it would be that useful, since QBE is a rather zen-garden project and I don't think the author would accept slop. Also he could just generate it with a prompt himself :P
It's honest. If they genuinely think it's better it's fair to say so. The article up to that point seems well written over the domain (I've solved much of the same set of problems.)
Yes - OP, you can do this via inline vars and consts:
begin
var foo : string := 'hello';
const c : integer = 5;
var bar := GetBar(); // type inference even
// and in blocks:
for var i := low(x) to high(x) do...
end;
Helpful website, but the cookie settings show hundreds of partners. Deeply unethical in general, let alone for a site that will be read by those who are worried and want information.
Symptoms section is very LLM, and that includes why it's obviously urging that critical early recognition on symptom lists that are too nonspecific to really be actionable.
Imagine the workload if people started seeking medical examinations on basis of the Week 1-2 list.
Yeah, Python and Pascal have always felt like they share similar vibes, despite being massively different languages. (Ease of writing, ease of reading, good inbuilts, etc.) Mojo feels like a clean take on similar goals... it's essentially a cleaner Python.
Mojo has both Python's def and its own fn -- two different flavors of functions. That alone isn't "cleaner". fn is there for high performance -- it's like Rust added to Python. Mojo is still missing Python functionality because it's early in development, so by that measure it's also not a "cleaner Python" ... and the parts that will never be added are because of performance, not cleanliness. Mojo has never been advertised as a cleaner Python so I don't know what vibes you're going on.
Not the OP, but I can answer with an objection to COM-style GUIDs myself. Delphi's interfaces are heavily based around COM, and so you need GUIDs, ARC, etc.
But interfaces as a concept don't require the COM backend. If you want your code to be cleanly separated, but don't want to split ownership/management models* (create/free vs ARC), and have no need for an interface and type identity to be managed outside your code and process (ie no COM), then interfaces that are not tied to ARC, and not tied to COM, give the clean code benefit without the baggage.
[*] People work around this by implementing interfaces from a base class with no-op AddRef/Release methods. But this kinda shows the problem: why is that necessary?
I work with Oxygene which is another modern Pascal -- quite a few new Pascals have popped up recently, I get the sense there's a real desire for something new! Our interfaces can be 'clean' and we support soft interfaces, too.
True! But here at least Blaise is consistent. It’s not mixing models.
My real wish for Pascal interfaces is that they are pure. Some of that is not bringing in COM stuff (including recounting) because I think memory management is or should be different to interface-based clean coding. Another: In Delphi if you define a property in an interface, you have to bring in the getter and setter too. And that makes them implicitly public / visible (even if the implementing class declares them as private.) And they must be methods, there’s no way to say “read, but I don’t care how” (where Delphi can normally read fields too.) In other words, the semantic of “I want a property with read access” causes the interface contract to define the implementation, including making public the normally private / internal backing.
Whereas what I really want is to declare “property Foo: Integer read;” and the interface requires that is satisfied, but not how. In other words, interfaces are pure - they don’t bring in extra baggage. You can do that in Oxygene.
Being restricted to COM-style interfaces, so no true properties like you say, that I totally get.
However my question was mostly with the objection against having a GUID, and how Supports() is solved without said GUID, especially since Delphi interfaces doesn't require a GUID in the first place.
I guess the language implementer needs to answer how they implement Supports :)
But within one app, ie not crossing boundaries, perhaps their object model's vtable carries references to the interfaces, so casting of any sort to/from object-interface and interface-to-interface would work, including Supports?
Most takes I've seen are far more nuanced.
Key is that 'progress' has a positive connotation. It is different from change. Mere change - such as new inventions - may not necessarily be aligned with progress in a field, society, etc.
Change may be inevitable, but it's up to us humans to sculpt it into progress.
reply