Email or username:

Password:

Forgot your password?
All posts mhoye's posts Post Back to profile
Top-level
Dana Fried

@publius @mhoye if you use your own thing, and you hire or work with people who are not as familiar with the thing as you are, or you just occasionally read the top Stack Overflow questions about your thing, it becomes fairly obvious where the documentation and/or error messages need to be improved.

"For experts by experts" isn't a way to make software for anyone but yourself.

1 Nov 2023 at 21:41 | Wall-to-wall | Open on mastodon.social
8 comments
mhoye

@tess @publius yeah, the big winners from this AI in everything push aren’t going to be the people getting the answers, it’s going to be the people hoarding the questions.

1 Nov 2023 at 21:53 | Open on mastodon.social
LisPi

@tess @publius @mhoye That certainly does seem like a decent heuristic in absence of bug reports or contributions to the documentation.

1 Nov 2023 at 23:32 | Open on mastodon.top
wakame

@lispi314 @tess @publius @mhoye

A little more complicated, more a thought experiment:

Every time a compiler (anywhere in the world) stumbles and falls over a line, log that somewhere centrally.

If compiling succeeds later, log also if and how the offending line has been changed.

Then, combine the most common(?) or most unsimilar looking(hello Levenshtein) lines and solutions and show some of them to the user (in case a compile fails).

For a project, it might also be helpful if e.g. a common method is invoked with false parameters a lot, since this could hint at inconsistencies or missing documentation.

@lispi314 @tess @publius @mhoye

A little more complicated, more a thought experiment:

Every time a compiler (anywhere in the world) stumbles and falls over a line, log that somewhere centrally.

If compiling succeeds later, log also if and how the offending line has been changed.

Then, combine the most common(?) or most unsimilar looking(hello Levenshtein) lines and solutions and show some of them to the user (in case a compile fails).

1 Nov 2023 at 23:43 | Open on tech.lgbt
LisPi

@wakame @tess @publius @mhoye That sounds like a very dangerous experiment with significant privacy issues.

In highly expressive and/or dynamic languages, it could also be of very limited use.

(But then such dynamic languages usually also have dynamic checks that can tell you *why* the type of something is wrong.)

1 Nov 2023 at 23:46 | Open on mastodon.top
wakame

@lispi314 @tess @publius @mhoye

That's why I introduced it as a thought experiment.

From a usability (or generally practical) perspective:

Of course expressive error messages are (likely) the best solution. With common, handwritten examples perhaps.

And if your interpreter/compiler understands what you are writing, that is always a plus.

But generally it feels as if especially software development is kind of resistant to invent and introduce new tools to make our work easier.

(This post is in danger to walking into "better UI development tools" territory, so I better stop writing now. :blobcatgiggle:​)

@lispi314 @tess @publius @mhoye

That's why I introduced it as a thought experiment.

From a usability (or generally practical) perspective:

Of course expressive error messages are (likely) the best solution. With common, handwritten examples perhaps.

And if your interpreter/compiler understands what you are writing, that is always a plus.

1 Nov 2023 at 23:57 | Open on tech.lgbt
LisPi

@wakame @tess @publius @mhoye Anything too reminiscent of Lisp (Machines) causes fear and rejection in its detractors, which is a significant part of what I blame for the resistance.

2 Nov 2023 at 0:13 | Open on mastodon.top
wakame replied to LisPi

@lispi314 @tess @publius @mhoye

That makes a lot of sense.
Even if I don't understand what all the resistance is about.

2 Nov 2023 at 10:37 | Open on tech.lgbt
Go Up