> What you want is guarantees that correct programs typecheck quickly.

In practice there's wealth of lemmas provided to you within the inference environment in a way standard library functions are provided in conventional languages. Those act like a memoization cache for the purpose of proving your program's propositions. A compiler can also offer a flag to either proceed with ("trust me, it will infer in time") or reject the immediately undecidable stuff.

> This is the "artisanal clothing argument".

> it is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results.

Your take essentially is "let's live in a shoe box, packaging pipelines produce them cheaply en masse, who needs slow poke construction engineers and architects anymore"

Where have I said engineers/architects aren't necessary? My point is that it is easier to get AI to get better than try to improve a million developers. Isn't that a straightforward point?

What the role of an engineer in the new context - I am not speculating on.

> My point is that it is easier to get AI to get better than try to improve a million developers.

No it's not, your whole premise is invalid both in terms of financing the effort and in the AI's ability to improve beyond RNG+parroting. The AI code agents produce shoe boxes, your claim is that they can be improved to produce buildings instead. It won't happen, not until you get rid of the "temperature" (newspeak for RNG) and replace it with conceptual cognition.

> Also, the assumption that you can do ___ thing

...

3. profit

4. bro down

ABC: Always. Build on. Parser Combinators.

Python ecosystem has several options, for instance: https://parsy.readthedocs.io/en/latest/tutorial.html

Is there a list of MEPs who are just right, without the far prefix?

Just as with most parts of the EU (imo both it's strength and it's weakness) there is some complexity and bureaucracy involved with founding out the political spectrum of MEPs. You can research the EU political groups and the political alliances and the corresponding positions on these Wikipedia pages.

https://en.wikipedia.org/wiki/Political_groups_of_the_Europe... https://en.wikipedia.org/wiki/European_political_alliances

Yes. But if you look into the policies they push, they are all progressive for some reason.

Yes ?

> ASML relies on the United States for several of its components, and it’s this very reliance that has allowed the United States to use the Foreign Direct Product Rule and impose export controls on ASML products. However, there are signs of a shift. ASML has already started to reduce its dependence on American technology, aligning with the EU’s goal of strategic autonomy. Earlier this month, ASML announced a major investment in Mistral, France’s flagship AI startup. The Dutch firm invested $1.5 billion in Mistral, becoming the company’s largest shareholder. The deal was widely seen by policymakers as a move that strengthens European ‘digital sovereignty.’ In a sector dominated by American tech giants, ASML’s Mistral investment represents a growing realization from Europe: cooperation within the bloc is necessary for the EU to stay competitive in the AI race.

---

I don't follow, how exactly does the investment into a French AI startup reduce ASML's "dependence on American technology"? Is it a supply-chain dependence, or a revenue-making dependence?

> ASML

Who's the customer base of ASML? Are they predominantly based in Europe?

They are predominantly Taiwan, and South Korea.

> When you add distribution you cannot make as many assumptions

You absolutely can make all assumptions relevant to the handling/dispatching logic expressed at type-level.

> and as such you encode that into the type with a bunch of optionals.

Not necessarily, it can be `Alternative f` of non-optional compound types that define the further actions downstream.

> Once you have gotten everything into optionals, you’re effectively doing the same checks you’d be doing with a dynamic language everywhere anyway.

Not true, your business logic can be dispatched based on a single pattern comparison of the result of the `Alternative f`.

> handling dynamic messages

the dynamic messages have to have static properties to be relevant for the receiving program, the properties are known upfront, and there's no "decades-running trap of trying to solve this".

> there's no "decades-running trap of trying to solve this".

I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something. The fact that, even given a very popular alternative in that list, or super tightly integrated RPC like sending terms between BEAMs, basic questions like “should optionality/absence be encoded differently than unset default values?” and “how should we encode forward compatibility?” have so may different and unsatisfactory answers says something.

Not as an appeal to authority or a blanket endorsement, but I think Fowler put it best: https://martinfowler.com/articles/distributed-objects-micros...

It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.

> I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something.

> It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.

ASN.1 wasn't in the same problem space with CORBA/DCOM, both CORBA and DCOM/OLE were heavily invested in a general-purpose non-domain-specific object model representation that would suppot arbitrary embeddings within an open-ended range of software. I suspect this is the unsolvable problem indeed, but I also believe that's not what you meant with your comment either, since all the known large-scale BEAM deployments (the comment I originally replied to implied BEAM deployments) operate within bounded domain spaces such as telecom and messaging, where distributed properties of the systems are known upfront: there are existing formats, protocols of exchange, and the finite number of valid interactions between entities/actors of the network, the embeddings are either non-existent or limited to a finite set of media such as static images, videos, maps, contacts etc. All of these can be encoded by a compile-time specification that gets published for all parties upfront.

> basic questions like “should optionality/absence be encoded differently than unset default values?”

However you like, any monoid would work here. I would argue that [a] and [] always win over (Option a) and especially over (Option [a]).

> and “how should we encode forward compatibility?”

If you'd like to learn if there's a spec-driven typed way of achieving that, you can start your research from this sample implementation atop json: https://github.com/typeable/schematic?tab=readme-ov-file#mig...

When you say "any better than" are you referring to the runtive vs comptime difference?