[d_tr]

A first-class programming language (not an LLM) to talk to the computer's OS along with a rich library is the most important missing component IMO.

Humans communicate mainly with language and no OS provides this in a satisfactory way for the average user.

The result is users mostly clicking on signs to choose among predetermined tasks, like monkeys in a lab.

[TheOtherHobbes]

That's because computers are dumb servants. And that's a good thing, because computer solutions should be task specific. The human has agency and sometimes imagination, and the computer's job is to solve a problem as transparently as possible with as little cognitive load as possible.

Human language is optimised for human relationships, not for task-specific problem solving. It's full of subtext, context, and implication.

As soon as you try to use natural language for general open-ended problem solving you get lack of clarity and unintended consequences. At best you'll have to keep repeating the request until you get what you want, at worst you'll get a disaster you didn't consider.

[cmrdporcupine]

Yes, the machine should be a humanity-amplifier, not a humanity-replacement.

“Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.” Frank Herbert, Dune

[wwweston]

Herbert is describing a humanity amplifying phenomenon.

[cmrdporcupine]

Herbert saw machine-thinking / AI as taking away human-ness, not adding to it. Or at least his Bene Gesserit did. Many quotes throughout the series about the corrosive effects of letting humans defer their complicated choices to machines, etc.

[vasco]

> And that's a good thing, because computer solutions should be task specific

Why? I enjoyed your comment but I don't follow why this is obvious?

Why should computer solutions be task specific rather than general?

[kjkjadksj]

So that when you ask what 1+1 is you get 2 and not a general solution

[falcor84]

Why not both?

If I were making an API call, I'd want to get 2, but as an end user, I'd be delighted in "It's 2 and here's how I arrived at it ...'

[danielovichdk]

"computer solutions should be task specific". Sums it up perfectly

[AlchemistCamp]

There are things about human language that are fundamentally at odds with effective communication with a computer (or engineering in general).

One example is ambiguity. Every human language has faculties for ambiguity, which is crucial in many human interactions and relationships. The ability to make implicit requests or suggestions while maintaining plausible deniability is valuable, even in situations that are non-adversarial.

In contrast, when communicating with an OS or engineering a mechanical device, ambiguity is a negative and it's crucial to use language that is deterministic.

There is a very real degree to which people are only capable of thinking clearly about complex systems to the degree they are comfortable with tools such as mathematics and programming that can be used to unambiguously describe them.

[ssivark]

> In contrast, when communicating with an OS or engineering a mechanical device, ambiguity is a negative and it's crucial to use language that is deterministic.

Very much a historical artifact. Modern systems (LLMs, for example) can in principle handle ambiguous inputs.

[AlchemistCamp]

Is ambiguity ever desirable when communicating with them?

[carbotaniuman]

I would argue no - the entire concept of prompt engineering exists for this reason.

[pilgrim0]

I agree. I think one way to achieve that is to first acknowledge the important distinction between modes of programming and levels of abstraction. See, even in programming, we’re still restricted to a given domain. A web dev does not program to the network stack, thus needs not to known NICs and TCP frames internals. The web dev only interacts with the lower levels via high level parameters (data) through the low level APIs, which are already done and settled, not directly with code. The same goes for each layer and domain. Now, expecting users to write actual code is not realistic or sustainable. What’s more reasonable is to imagine a scenario where users needs only to give the parameters for the functions which are already done and settled. So, composing super high level functions in an environment which disposes of an extensive library of utilities seems the way to go. Users already do parameterization everyday, such as when they press buttons and fill forms. What’s missing is simply an abstraction which gives them the power to compose those functions. Regarding the paradigmatic framing for an end user language, I think stack-based programming offers a superior model, because the context window is directly visible and easy to track and reason, but more than that, stack languages offer a good avenue for learning, since it’s the easiest model to teach by analogy, even physical analogies can be made. It boils down to just pushing and popping in a coherent order. The order of operations is in fact the program. Hard to beat this simplicity and universality.

[runevault]

to my mind at least part of the issue here is human communication languages are fundamentally lossy by nature. Everything has too many meanings and requires inference. This is why when able to communicate with code it gets so much easier because it has to be exactly right or the computer fails. And at least because it is consistent we can debug and fix that communication and once that is done it will work with reasonable consistency.

[coldtea]

That describes a limitation of computers (and current interfaces to them) though.

Requiring humans to describe stuff "unambiguosly" is the easy cop out to that.

Getting computers to handle the ambiguity and resolve it as good as humans is what would be really amplifying. LLMs are a good step to that, compared to a regular programming language/interface.

[infinite8s]

It's also a limitation of human-human communication, and why nation's have ambassadors (who presumably have a shared context from which to start from when dealing with a foreign nation).

[coldtea]

I don't think diplomacy and ambassadors are there to handle ambiguity in communication.

There are there to handle conflicting interests and goals.

To that end, ambiguity in communication is something they use on purpose, not something they're there to solve.

[rbanffy]

> Humans communicate mainly with language and no OS provides this in a satisfactory way for the average user.

Most humans would have nothing to say to an OS. I am a software engineer and most of the time I function many levels of abstraction away from the OS. Most of my work doesn't even run on the same OS I work in, and when it runs, it talks to an OS that's not even running on an actual computer, but a construct that looks like a computer, but is entirely made up by a hypervisor.

[hdarshane]

>A first-class programming language (not an LLM) to talk to the computer's OS along with a rich library is the most important missing component IMO.

That "programming language" might just be ability to have generative interfaces (LLM based).

>Humans communicate mainly with language and no OS provides this in a satisfactory way for the average user. LLMs literally fix this.