Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chat is a bad UI pattern for development tools

danieldelaney.net

Post reply on HN
Print view View original

381–390 of 432 posts

Re: Chat is a bad UI pattern for development tools

#381

Post by foobiekr »

empath75 wrote: post #14
croes wrote: post #5

Natural language isn’t made to be precise that’s why we use a subset in programming languages. So you either need lots of extra text to remove the ambiguity of natural language if you use AI or you need a special precise subset to communicate with AI and that’s just programming with extra steps.

AIs actually are very good at this. They wouldn't be able to write code at all otherwise. If you're careful in your prompting, they'll make fewer assumptions and ask clarifying questions before going ahead and writing code.

I don’t think I’ve ever seen an llm in any context ask for clarification. Is that a real thing?

Re: Chat is a bad UI pattern for development tools

#383

Post by taeric »

esafak wrote: post #371
taeric wrote: post #166

Earlier quoted context omitted.

Agreed if it is correspondence that we are talking about. So, agreed I'm probably too strong that anything needing filtering and such is bad. I'm thinking of things that are assembled. The correspondence that went into the assembly is largely of historical interest, but not necessarily one of current use.

So you mean like collaborating on a document? Modern word processors are versioned, or you can use text and your own VCS, same as with your code. Is your issue that you want to discuss the thing you are collaborating on outside of the tool you are creating it in?

This feels inline with my point? Versioning of documents is better done using other tools. Correspondence is fine over email.

We have some tools integrated with email to help version control things. But the actual version control is, strictly, not the emails.

Re: Chat is a bad UI pattern for development tools

#384

Post by kmoser »

9rx wrote: post #304
kmoser wrote: post #206

Earlier quoted context omitted.

Even lawyers agree that legalese is no more accurate than plain English if used properly: https://www.scientificamerican.com/article/even-lawyers-dont... In other word, complex applications can still be fully specified in plain English, even if it might take more words.

> complex applications can still be fully specified in plain English In plain English, of course, but not in natural English. When using language naturally one will leave out details, relying on other inputs, such as shared assumptions, to fill in the gaps. Programming makes those explicit.

Programming only needs to make things as explicit as necessary based on the developer's desires and the system's assumptions. Where more detail is necessary, the programmer can add more code. For example, there's no need to tell a browser explicit rules for how users should be able to interact with an input field, since that's the browser's default behavior; you only need to specify different behavior when you want it to differ from the default.

Likewise for English: one can use natural English to add as many details as necessary, depending on who you're talking to, e.g. "Make an outline around the input field, and color the outline #ff0000." You can then add, if necessary, "Make the corners of the outline rounded with a 5 pixel radius."

In this respect, complex applications can be fully specified in English; we usually call those documents "formal specifications." You can write it terse, non-natural language with consistent, defined terminology to save room (as most specs are), or colloquial (natural) language if you really want. I wouldn't recommend the latter, but it's definitely useful when presenting specs to a less technically informed audience.

Re: Chat is a bad UI pattern for development tools

#385

Post by bze12 »

ygouzerh wrote: post #169
stitched2gethr wrote: post #136

Earlier quoted context omitted.

I think this misses the point. It seems like the author is saying we should move from imperative instructions to a declarative document that describes what the software should do. Imperative: - write a HTTP server that serves jokes - add a healthcheck endpoint - add TLS and change the serving port to 443 Declarative: - a HTTP server that serves jokes - contains a healthcheck endpoint - supports TLS on port 443 The di…

Good explanation! As an open-reflexion: will a declarative document be as detailed as the imperative version? Often between the specs that the product team is providing (that we can consider as the "descriptive" document) and the implementation, many sub specs have been created by the tech team that uncovered some important implementation details. It's like a Rabbit Hole. For example, for a signup page, we could have…

I could imagine a hybrid where declarative statements drive the high-level, and lower-level details branch off and are hashed out imperatively (in chat). Maybe those detail decisions then revise the declarative statements.

The source of truth would still be the code though, otherwise the declarative statements would get so verbose that they wouldn't be any more useful than writing the code itself.

Re: Chat is a bad UI pattern for development tools

#386

Post by parasubvert »

mrweasel wrote: post #158
taeric wrote: post #82

Earlier quoted context omitted.

Discord and slack baffle me. I liked them specifically because they were more ephemeral than other options. Which, seems at odds with how people want them to be? Why?

I really don't get why people are so happy about Slack (never used Discord). The interface is awful, it barely functions as a chat client, yet people adds bots, automation and use it as a repository for documentation. Honestly it would be better if history was deleted weekly or something, just to prevent people from storing things in Slack.

It's the opposite in my experience, it's the best parts of IRC and the history is gold. Storing things in Slack is one of the most useful bits of it. I've seen several multi-billion dollar companies built most of their collaboration across offices around Slack.

Re: Chat is a bad UI pattern for development tools

#387

Post by parasubvert »

jerjerjer wrote: post #228
65 wrote: post #127

Earlier quoted context omitted.

Oh, how nice it must be to complain about Slack. Try using Teams and you will never want to complain about Slack again.

Slack is way worse than Teams. I honestly rather dislike both and rather use email only, but will pick Teams over Slack any time.

This is, to put it mildly, a minority opinion. I don't hate Teams as much as most people do but my old (big and small) companies had both Slack and Teams and about 40% of employees had Teams statuses of "ping me on Slack I refuse to use Teams".

Re: Chat is a bad UI pattern for development tools

#388

Post by notatoad »

i like chat. all the more dedicated ai development tools try to force the author's (or somebody's) specific workflow, and fall into an uncanny valley sort of situation for my workflow, where it highlights all the bits of my workflow that don't match the tool's desired workflow.

chat is so drastically far away from my workflow that it doesn't feel like my workflow is wrong.

Re: Chat is a bad UI pattern for development tools

#389

Post by 9rx »

kmoser wrote: post #384
9rx wrote: post #304

Earlier quoted context omitted.

> complex applications can still be fully specified in plain English In plain English, of course, but not in natural English. When using language naturally one will leave out details, relying on other inputs, such as shared assumptions, to fill in the gaps. Programming makes those explicit.

Programming only needs to make things as explicit as necessary based on the developer's desires and the system's assumptions. Where more detail is necessary, the programmer can add more code. For example, there's no need to tell a browser explicit rules for how users should be able to interact with an input field, since that's the browser's default behavior; you only need to specify different behavior when you want i…

> complex applications can be fully specified in English

Of course. We established that at the beginning. The entire discussion is about exactly that. It was confirmed again in the previous comment. However, that is not natural. I expect most native English speakers would be entirely incapable of fully specifying a complex application or anything else of similar complexity. That is not natural use.

While the words, basic syntax, etc. may mirror that found in natural language, a specification is really a language of its own. It is nothing like the language you will find people speaking at the bar or when writing pointless comments on Reddit. And that's because it is a programming language.

Re: Chat is a bad UI pattern for development tools

#390

Post by skue »

yarekt wrote: post #277
ryandrake wrote: post #210

Earlier quoted context omitted.

I guess the things I don't like about Chat are the same things I don't like about pair (or team) programming. I've always thought of programming as a solitary activity. You visualize the data structures, algorithms, data paths, calling flow and stack, and so on, in your mind, with very high throughput "discussions" happening entirely in your brain. Your brain is high bandwidth, low latency. Effortlessly and instantly…

That's such a mechanical way of describing pair programming. I'm guessing you don't do it often (understandable if its not working for you). For me pair programming accelerates development to much more than 2x. Over time the two of you figure out how to use each other's strengths, and as both of you immerse yourself in the same context you begin to understand what's needed without speaking every bit of syntax between…

> I'm guessing you don't do it often (understandable if its not working for you). For me pair programming accelerates development to much more than 2x.

The value of pair programming is inversely proportional to the expertise of the participant. Junior devs who pair with senior devs get a lot out of it, senior devs not so much.

GP is probably a more experienced dev, whereas you are the type of dev who says things like “I’m guessing that you…”.

Post reply on HN