When we demand that error messages are plaintext, there is a direct
tradeoff between how intimidating / overwhelming the error is and how
informative it is. Quite simply, the more information that the compiler
provides, the more. For example, C++ template errors will happily dump
their guts, giving you a hopelessly detailed account of what went wrong.
I think this tricky tradeoff can be greatly mitigated by making error
messages interrogatable! Take a look at this part of David Christiansen's
talk about his work on Idris's pretty-printer:
In dependently typed systems, you can check lots of properties of your
programs, but this comes with having very complicated types, and
correspondingly type errors. This makes it almost necessary for
productivity to do something better about the presentation of errors.
This is not limited to compilation errors. For example, what if your
runtime errors provided some of the program values in an interrogatable
fashion? I think that could be very handy, particularly if it is difficult
to attach a debugger to the process (e.g. debugging a rare failure in a
On Tue, Apr 5, 2016 at 9:49 PM, Linda McIver <linda.mci...@gmail.com> wrote:
> Thanks all for pointers to useful info.
> To clarify my data science unit: It will be a basic intro to data analysis
> and visualisation, with some spreadsheet work and some programming work.
> Richard: I wholeheartedly agree that incorrect (but terribly
> well-intentioned) error messages are worse than unfriendly ones! But I feel
> we could simply rewrite the existing ones to make them more intelligible
> and less intimidating. I am aware that this is far less straightforward
> than it sounds!
> I may have found my next area of research, although as I am a high school
> teacher these days, research is rather lower on my agenda than it used to
> be. I finished a PhD on introductory programming 15 years ago, and I
> confess I am a little startled at how little progress there appears to have
> been in this area. Surely I am missing something???
> On 6 April 2016 at 11:41, Richard A. O'Keefe <o...@cs.otago.ac.nz> wrote:
>> On 6/04/16 12:47 pm, Luke Church wrote:
>>> Based on observational studies, I've generally recommended to the Dart <
>>> http://www.dartlang.org/> team that the verbose errors state:
>>> - *What happened* (e.g. File 'stuff, ln 43:' class B doesn't implement
>>> method foo)
>>> - *Why it is a problem* (e.g. class B extends class A, which has an
>>> abstract method foo. This means that class B doesn't have an implementation
>>> of foo)
>>> - *What the user can do next* (e.g. consider implementing foo, or making
>>> class B abstract)
>> If I may add an anecdote, I once used a programming system
>> whose authors had put enormous effort into writing "helpful"
>> error messages. But I found them infuriating. Much of the
>> text would explain what the program thought you were trying
>> to do, but it was almost always wrong about that.
>> Take this particular example as an example: maybe the real
>> problem is that the student was trying to call food(), not
>> foo(), in which case advice to make B abstract is worse than
>> An error is detected when the system expects something and
>> something else happens. Saying clearly *where* the error
>> was is important (and I know my own programs are not very
>> good at this), as is saying what the system expected and what
>> it thinks it got.
>> In the Haskell world, one group went to the trouble of building
>> a whole new system called Helium, in part so that they could
>> provide human-friendly error messages.
>> You received this message because you are subscribed to the Google Groups
>> "PPIG Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ppig-discuss+unsubscr...@googlegroups.com.
>> To post to this group, send an email to email@example.com.
>> For more options, visit https://groups.google.com/d/optout.
> Exploring Life, Parenting and Social Justice:
> Computational Science Education: http://computeitsimple.wordpress.com/
> Dr Linda McIver
> Teacher & Freelance Writer
> Buy Fair Trade - Change the world one coffee at a time
> You received this message because you are subscribed to the Google Groups
> "PPIG Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ppig-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to firstname.lastname@example.org.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "PPIG
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.