2
$\begingroup$

Our latest question at the time of writing is What are some design errors that lead to hard-to-debug code?

It which has been closed as off topic as it is too broad. The OP seems to be asking us to create a community resource listing prior art for bad design choices to avoid.

This is indeed a little broad for a SE site but such resources are also useful reading. How might we phrase one or more questions to achieve the OPs end?

Rather than just shutting off such dicussions completely with a close vote what constructive advice could we offer?

$\endgroup$

1 Answer 1

2
$\begingroup$

I think the problem is not just that it's too broad, but also that it's likely to attract opinion-based answers. Some programmers may think a certain feature is terrible and causes difficult bugs that are hard to track down, while other programmers may have a different experience of that feature. And then the votes are more of a survey or popularity contest (I can imagine someone would get a bunch of upvotes just for dunking on PHP).

To keep the question somewhat objective, there seem to be two routes:

  1. Ask about research on the relationship between language design features and the ease of debugging; or
  2. Ask about what the designers of real languages have identified (and possibly changed) about their designs which made debugging difficult.

Option (1.) might still risk attracting opinionated answers, whereas option (2.) might still be too broad unless it focuses on a specific language. But both would be significantly better than the current question.

Either way, I think the question should emphasise that it is specifically asking about language features which make it harder to identify the causes of bugs (e.g. because the bug occurs far from the cause, because the bugs aren't easily reproducible, or because the mistake is syntactically difficult to discern), as opposed to features which make it harder to write correct code in the first place (e.g. the "billion dollar mistake" of null pointers) or harder to fix bugs once their causes are identified.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .