Hacker News new | past | comments | ask | show | jobs | submit login

The idea of computing as the shared stage to reflect our own intelligence is really what sticks out to me as the best way to frame what interacting with a computer means. It's not new but Alan did a great job of motivating and framing it here. Thanks for posting this great reminder that what we use as computers today are still only poor imitations of what could truly be done if we can transport our minds to be more directly players on that stage. It's interesting to reflect the other way as well. If we are the actors reflecting a computer to itself. An AGI has to imagine and reflect in a space created of our ideas. To be native the AI needs better tools, the "mouse" of it's body controlling the closed loop of it's "graphics", how do we create such a space that is more directly shared? Dynamically trading been actor and audience in an improvisational exchange? This is the human computer symbiosis I seek.



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.


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.


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


Herbert is describing a humanity amplifying phenomenon.


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.


> 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?


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


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 ...'


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


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.


> 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.


Is ambiguity ever desirable when communicating with them?


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


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.


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.


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.


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).


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.


> 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.


>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.


>The idea of computing as the shared stage to reflect our own intelligence

We tried that, and it worked briefly. But the end result is the modern web/app landscape: commercialization, tits and cats, hating, techo-feudal and government control, partisanship bs, spam, narcisism - and rare sprinkles of intelligence here and there.


That’s true, but I think the core of human communication has always been half of what you’ve listed - low intelligence, hating, spam and narcissism. It’s just more obvious and amplified online as you can see everyone engaging with it all at the same time. In pre-internet times, you’d need to be physically present and see maximum a bar-full amount of people doing that.

I’m still very hopeful we will use the tech to help up us with some non-communication related things. Maybe something that’ll even off-ramp people outside the internet world.


>In pre-internet times, you’d need to be physically present

Because of that, the very real possibility of getting a punch in the face if you went over the line also helped curb those behaviors somewhat.


A sentiment often expressed, but I find it too close to “An armed society is a polite society” for my comfort.



We tried that, and it worked briefly.

Where and when?


In the early days of the internet up to the early years of the web.


do you have any specific examples?


I feel like the LLM interface will enable that. I wonder what Alan Kay makes of the current LLM revolution (he does talk a bit about it in the question section @ around 1:35)


I am a big fan of just in time on the fly UI and LLMs seem to make that possible now with some of the fast token outputs there are a couple of experiments [1]using image for now and I expect this to be more useful in not too long.

[1] https://twitter.com/sincethestudy/status/1761099508853944383...


I'm not Alan, but I'm pretty sure he isn't too happy about it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: