←back to thread

279 points nnx | 1 comments | | HN request time: 0s | source
Show context
PeterStuer ◴[] No.43543777[source]
Here's where the article goes wrong:

1. "Natural language is a data transfer mechanism"

2. "Data transfer mechanisms have two critical factors: speed and lossiness"

3. "Natural language has neither"

While a conversational interface does transfer information, its main qualities are what I always refer to as "blissfull ignorance" and "intelligent interpretation".

Blisfull ignorance allows the requester to state an objective while not being required to know or even be right in how to achieve it. It is the opposite of operational command. Do as I mean, not as I say.

"Intelligent Interpretation" allows the receiver the freedom to infer an intention in the communication rather than a command. It also allows for contextual interactions such as goal oriented partial clarification and elaboration.

The more capable of intelligent interpretation the request execution system is, the more appropriate a conversational interface will be.

Think of it as managing a team. If they are junior, inexperienced and not very bright, you will probably tend towards handholding, microtasking and micromanagement to get things done. If you have a team of senior, experienced and bright engineers, you can with a few words point out a desire and, trust them to ask for information when there is relevant ambiguity, and expect a good outcome without having to detail manage every minute of their days.

replies(2): >>43543792 #>>43543949 #
throwaway290 ◴[] No.43543949[source]
> If you have a team of senior, experienced and bright engineers, you can with a few words point out a desire and, trust them to ask for information when there is relevant ambiguity, and expect a good outcome

It's such a fallacy. First thing an experienced and bright engineer will tell you is to leave the premises with your "few words about a desire" and not return without actual specs and requirements formalized in some way. If you do not understand what you want yourself, it means hours/days/weeks/months/literally years of back and forths and broken solutions and wasted time, because natural language is slow and lossy af (the article hits the nail on the head on this one).

Re "ask for information", my favorite example is when you say one thing if I ask you today and then you reply something else (maybe the opposite, it happened) if I ask you a week later because you forgot or just changed your mind. I bet a conversational interface will deal with this just fine /s

replies(3): >>43544573 #>>43544963 #>>43546171 #
Hauthorn ◴[] No.43544573[source]
I think you work in different domains.

Expecting a good outcome is different from expecting to get exactly what you intended.

Formal specifications are useful in some lines of work and for some projects, less so for others.

Wicked problems would be one example where formal specs are impossible by definition.

replies(2): >>43545258 #>>43545274 #
johnnyanmac ◴[] No.43545274{3}[source]
>Anyway, the disabled are pretty much always allowed to be collateral damage by society, so this will just be senseless pain.

For games, you don't really need nor desire formal specs. But it also can really show how sometimes a director has a low tolerance for interpretation despite their communication being very loose. This leads to situations where it feels like the director is shifting designs on a dome, which is a lose-lose situation for everyone involved.

If nothing else, formal specification is for CYA. You get what you ask for, and any deviation should go in the next task order or have been addressed beforehand.

replies(1): >>43555648 #
1. throwaway290 ◴[] No.43555648{4}[source]
> For games, you don't really need nor desire formal specs.

Whoah is this wrong. Maybe when you hear "formal specs" you have something specific in your mind...

Formal spec can mean almost literally anything better than natural language vibes in a "few words about a desire", which is what I replied to because I was triggered by it