rrook

There's no one true answer when it comes to the perspectivity of the mind, of which language is a part of. For some people, writing is closest to thought. For others, code is closer. Others still might find mathematics a better means of expression. YMMV with any one idea here.

That's totally fair at this point, and a bit expected. I'm still sprinting towards my definition of done for the core product surface. Hand-writing the docs (and a like, effective book) are some of the last things on the pre 1.0 list, too much churn until then.

Distributed systems and biological systems have a lot in common, the operational overlap is real!

Hah! I'm using bodily biological metaphors in a dynamic harness kinda project: https://hale-lang.org/docs/parts/organism/

I'm working on landing a similar feature in a language project, but in a general way, geared torward high level application flows. The general idea is that you can declare a "seam" between a function that returns a type set, and some other actor that exposes a method set that covers said typeset. The compiler can deal with the inbetween code, so the mainline of the app is just a set of typespace expansions/compressions. A callstack within a single thread domain can be expressed like:

bytes → (NewOrder | Cancel) → handlers → (Ack | Reject) →

https://github.com/hale-lang/hale/issues/1530#issuecomment-6...

The degree to which my statement is true depends on the degree to which a programmer's abstract model incorporates _machine realities_. If your model takes into account the process model, and what is required for those process models to communicate, you are already modeling with mechanical sympathy. Programming languages (von nuemann languages) are all opinionated expositions of the same machinery, so the cost of translating the model to the language is a real cost.

My anecdata is the opposite of yours; the people that feel like the _actually coding_ is the bottleneck tend to be the people that have the _most_ editor fluency, as they are(were?) motivated to remove the bottleneck.

> Thinking in terms of generic computing concepts is equally as easy.

This is the trapdoor in this discussion. The degree to which a concept has been thought of in terms of generic computing (or just generically; modeled abstractly), before code is written, is different for every programmer. Not only is the degree different, but the deliberation and levels of awareness vary as well.

If your mental process explicitly models in the abstract, translating and typing out to code can absolutely feel like a bottleneck, and the specific language involved matters.

it's all software, not just sass. the "application harness" is emerging, which bundles up the application, the operations of the application, and the sdlc of the application all into one deployable thing. agents/people just plug into it, and it looks _mostly_ like an org chart / task board.

i think part of this is a shortcoming of our programming languages. generally, languages allow for the expression of partial graphs, which makes the verification problem technically challenging. my take is that a language that only exposes closed-graph semantics could help bridge the gap between the model and the implementation, even if not absolute.

I think that's just extra detail on the _degree_ of human responsibility depending on the environment. Even in what you suggest, if something goes wrong, who's responsible? AI are not persons in our society; the IT-architecture/cyber security expert is ultimately responsible for the code, regardless of how it's written.

Personal responsibility will always exist at the touchpoints of software and human activity. Concentration and scope of responsibility may vary, and the degree to which that person needs to understand the code will vary as a result, but the need for a human to be able to read and understand code is going to be around for a very long while still.

Totally agree with the first part of that. The second less so. LLMs are able to maintain a cohesive idea across multiple metaphors, which is basically the same as walking abstractions.

> The tech industry has accidentally invented the initial stages a completely new kind of mind, based on completely unknown principles, using completely unknown processes that have no parallel in the biological world.

This is just false? Language emerged from biology, we've brute forced some version of that model. Knowing that this is a new kind of mind requires that we are able to differentiate these different kinds of minds in the first place.

MCP is an incomplete abstraction. It solves things in the right direction, allowing agents to interact with some given system via a controlled ingress. It's a fancy proxy, and by itself doesn't really do much to enable autonomous interactions.

Expressing complex emergent workflows is fairly straightforward given how the workflow engine recurses:

- a workflow is a series of steps

- a step is one or more tasks that can be done in parallel

- a step is complete when all of its tasks are complete

- a task can be a unit of work, or a pointer to another workflow

Narrowly, I think you're spot on. The effort required to understand the machinery around formal verification is a function of the surface area of the thing being formally verified. Specifically, formally verifying the surface area of general purpose programming languages is difficult.

My approach with Hale (shameless self plug) is that the programming language itself first offers another strata of structure to program within, a type of graph. Once the structure of the program is expressed as a graph, understanding how formal verification works is a clean encapsulation of graph activities.

I think that dissolves the "self driving" distinction, though? The mechanisms for driving the codebase must be present in the codebase itself. Otherwise its just a regular out-of-band development process.

My bet is that we'll see a second layer of harness emerge, as self-driving codebases become the target. There will be an application facing harness, orthogonal to the agent facing harness. The app harness will represent the software factory that is emergent for the specific application being developed.

Anyway, here's mine, still wip:

https://hale-lang.org/docs/dna/

https://github.com/hale-lang/hale/issues/690

I agree with you, and am all in on a solution. It has to be part of the language itself: https://hale-lang.org/docs/claims/

Thanks for that feedback, I'll try to add some more well known examples. In the meantime, maybe the docs have more of the examples you're looking for? https://hale-lang.org/docs/tutorial/job-queue/

Absolutely - it's like, the "current agreed upon version", but indeed it's a point-in-time snapshot/simplification of whatever the thing being modeled actually is.

I did RTFA, maybe YOU need to read my question again. I specifically asked about the outcome if the plaintiff didn't do all that petty stuff.

This seems like way too caustic of a reaction, OP is correct.

If you actually know what you're doing in $language, and you know how $language wants to emit the assembly or whatever, there's no huge advantage to just programming directly in assembly.

Some shameless self promo - I'm working on one!

https://hale-lang.org/proof/

Sure, the domain model isn't an artifact, but software _necessarily_ contains an artifact of the domain model.

The domain and delivery/ops context define the constraints, code that gets written ought reflect those constraints, not provide more.

I think the reality is that it has to be baked into the language. Here's my real attempt at that - if you model the system in the language, the compiler can reason about the distributed fleet: https://hale-lang.org/proof/

Does that reading intonate that had the plaintiff chosen a more benign injection, only to prove that an LLM was involved, rather than to alter the outcome, the judge would have looked at the situation differently?

Not really pursuing it at this point, but it seems so intuitive that organizational harnesses will converge on like, agent personas that are constructed just-in-time from shared knowledge graphs.

https://brained.dev/under-the-hood