Email or username:

Password:

Forgot your password?
Top-level
LisPi

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

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

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

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.

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.

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.

Go Up