Отчет о поездке в Дагштуль: люди, программы и программные ошибки

Отчет о поездке в Дагштуль: люди, программы и программные ошибки

На протяжении многих лет мне посчастливилось быть приглашенным на многие семинары Dagstuhl. Эти мастер-классы представляют собой чудесно удаленное уединение в западной Германии в замке 19-го века, где несколько десятков исследователей вычислительной техники собираются, чтобы обсудить какую-то тему и, надеюсь, наметить будущие траектории исследований. Мой первый был, когда я был старшим докторантом в 2007 году по специальности разработка программного обеспечения для конечных пользователей; С тех пор я был на курсах практическое тестирование программного обеспечения (2010 г.), аналитика разработки программного обеспечения (2014 г.), человекоориентированная разработка программных инструментов (2015 г.), оценка обучения на вводном курсе CS (2016 г.), Продуктивность программиста (2017 г.), Разработка и оценка языков программирования (2018 г.) и Изучение и преподавание языков программирования (2019 г.). А с прошлого воскресенья по среду мне посчастливилось присоединиться к другой теме Человеческий фактор в сообщениях об ошибках программирования (2022!), организованной Бреттом А. Беккером (Университетский колледж Дублина), Полом Денни (Оклендский университет), Джанет Зигмунд ( TU Chemnitz) и Андреас Стефик (Университет Невады — Лас-Вегас).

Прелесть семинаров Dagstuhl в том, насколько они захватывающие. В замке практически нечего делать, кроме как разговаривать с другими посетителями, есть, пить и играть в игры, и поэтому они могут невероятно преобразовать зарождающиеся сообщества. У меня остались приятные воспоминания о раннем утреннем кофе с новыми друзьями, о том, как я играл в настольные игры поздно вечером, вступал в философские споры о природе программирования, коде и правильности, а также о приключениях в сельской западной Германии за едой и достопримечательностями.

Конечно, у нас все еще была глобальная пандемия, и поэтому формат был не совсем таким, как другие. Я решил не путешествовать, и поэтому, как и другие ~ 15 участников онлайн, в основном жил в Zoom, в то время как мы представляли, как другие ~ 15 участников вместе занимаются всеми забавными вещами, указанными выше. И мне также нужно было управлять часовыми поясами: семинар придерживался полного расписания по центральноевропейскому времени, с 8:30 по центральноевропейскому времени до вечерних сессий примерно до 21:00 по центральноевропейскому времени, что для меня означало полночь по тихоокеанскому времени примерно до 12:30, с половиной рабочего дня. работать после каждого рабочего дня. Мне нужно было немного поспать, поэтому я пропустил сеансы с 1:30 до 5:30 утра и несколько дней ходил на перегаре. (Не то, что я хочу делать регулярно!)

Поскольку я не присутствовал на семинаре целиком и был довольно взволнован из-за недосыпания, это будет не совсем хронологический отчет о поездке. Вместо этого я собираюсь поделиться несколькими темами, возникшими в моем смутном сознании, когда я слушал, как мои замечательные новые коллеги делятся своим опытом, идеями, теориями и идеями, и я изо всех сил пытался поделиться своими собственными поздно ночью и рано утром. . Я надеюсь, что мои коллеги узнают многие из этих идей, поскольку они представляют собой беспорядочный синтез всех наших мыслей. Прошу прощения за то, что не отдал должное каждому за их идеи — я не очень хорошо отслеживал, кто что сказал, и многие из них в любом случае представляют собой беспорядочную сборку нашего коллективного разговора. (Для коллективного зачета см. список участников). Я надеюсь, что они окажутся полезными для других участников и, что более важно, для всех, кто не был приглашен на мероприятие.

Почему сообщения об ошибках?

Первый и самый очевидный вопрос, который должен был решить семинар, заключался в том, зачем вообще говорить о сообщениях об ошибках? Возьмем, к примеру, эту ошибку Python:

в то время как True print('Hello world')
› SyntaxError: недопустимый синтаксис

Как простое утверждение, приведенное выше, может быть более важным, чем сам дизайн языка, бесчисленное множество проблем разнообразия, справедливости и включения в CS, а также грандиозные проблемы написания правильного программного обеспечения в масштабе?

Дело, которое выдвинула группа, было тонким, сплетенным воедино из многочисленных наблюдений и данных исследований об их скрытой важности:

• Сообщения об ошибках могут повлиять на самоэффективность, заставляя учащихся сдаваться.
• Сообщения об ошибках могут ввести в заблуждение, что приведет к бесплодным сеансам отладки.
• Сообщения об ошибках преимущественно на английском языке, за исключением большей части мира.
• Сообщения об ошибках часто непонятны, что снижает производительность.
• Сообщения об ошибках носят осуждающий характер, побуждая учащихся винить себя

Эти и многие другие наблюдения приводят к тому, что эти небольшие сообщения на самом деле обладают огромной силой во многих аспектах программирования, производительности, разнообразия и инклюзивности. Например, Пол Денни рассказал об исследовании, в котором студенты пробовали десятки решений ошибок, но так и не смогли скомпилировать свою программу, в конечном итоге полностью сдавшись. Другие продемонстрировали, что ошибки часто вводят в заблуждение настолько, что студенты полностью модифицируют свою программу в поисках чего-то, что устранит ошибку. А другие по-прежнему показывали исследования, в которых даже небольшие улучшения качества сообщений об ошибках значительно сокращали время отладки и общее количество ошибок.

В ходе семинара некоторые из нас предположили, что причины их силы во многом связаны с огромным авторитетом, который они имеют в формировании стратегий и действий учащихся по решению проблем, в сочетании с их плохими и вводящими в заблуждение качествами.

Что такое сообщения об ошибках?

Это может показаться очевидным — это просто текст, отображаемый при синтаксическом анализе или ошибке типа, верно? Но у группы возникло несколько вопросов об их сущности и о том, являются ли «ошибка» и «сообщение» правильными словами.

Например, само слово «ошибка» подразумевает, что человек сделал что-то не так или ошибся. Это может быть фактически верно в отношении правил языка, но нет ничего морально, этически или экзистенциально неправильного в том, что программист сделал, не соблюдая грамматику языка. Я начал понимать, как часто сообщения об ошибках являются просто газлайтингом (например, «Вы не определили это», «Но я сделал…», «Нет вы не…”). Но это далеко не человек, нарушающий какой-либо закон природы, ошибки — это просто код, несовместимый с грамматикой или недвусмысленный. Говорить об «ошибках» как о «двусмысленности» или «несоответствиях» может быть более точным и менее предвзятым.

Группа также говорила о том, что слово «сообщение» бесполезно узкое. Например, подразумевается, что «сообщения» об ошибках — это просто текст, который передается пользователю для чтения. Но реальность сообщений об ошибках такова, что они часто расположены в более богатом интерактивном контексте, например в среде IDE, которая может выделять части программы, предлагать быстрые исправления, а также может ссылаться на другие определения или документацию. Это больше, чем просто сообщения, зачастую это сложные пользовательские интерфейсы с богатым набором потенциальных взаимодействий для устранения ошибки. Говорить об «сообщениях» об ошибках как об «интерфейсах» ошибок может быть более точным. («Несоответствие интерфейсов», какой полный рот!)

Этот интерактивный аспект ошибок также был заметен в нашем анализе некоторых реальных данных студентов об ошибках на семинаре. Во многих случаях предъявление ошибки в определенное время часто полностью срывало работу студентов и, казалось, даже приводило к новым (и неверным) интерпретациям синтаксиса и семантики языка. Больше, чем просто текст, студенты, по крайней мере, рассматривают их скорее как определенное руководство, используя их содержание и возможности, чтобы полностью изменить свои стратегии программирования, вместо того, чтобы размышлять над их значением, прежде чем действовать.

Кто читает?

Одной из самых увлекательных тем семинара были наши размышления об аудитории сообщения. Некоторые из участников начали с довольно жесткого мнения о том, что все ошибки должны быть краткими, основанными на фактах, и что такая обратная связь должна быть универсальной, поскольку она основана на реальных правилах языка программирования.

Но многие участники отказались от этой упрощенной идеи. Например, одним из самых простых наблюдений было то, что не все говорят по-английски. Сообщение об ошибке на английском языке для свободно владеющего английским читателем может означать одно, но для того, кто знает английский, это может быть просто что-то, что нужно скопировать и вставить в поисковую систему, простой сигнал о том, что что-то не так, или, что еще хуже, оно может ничего не значить. .

Читатели сообщений об ошибках также различаются по своим знаниям. Кому-то, кто хорошо знает язык, может понадобиться всего одно или два слова, чтобы определить проблему, тогда как кто-то, кто только изучает язык, может иметь очень слабое понимание синтаксиса языка и нуждаться в дополнительных инструкциях в сообщении о правилах языка. И процесс обучения от первого наблюдения ошибки к тысячному разу может потребовать различных инструкций и контекста на этом пути.

Люди, использующие программы для чтения с экрана (например, чаще всего слепые, слабовидящие или страдающие дислексией), также по-разному воспринимают сообщения. В отличие от чтения глазами, которое может быть «произвольным доступом» к содержимому сообщения, средства чтения с экрана преобразуют текст в последовательный аудиопоток. И поэтому, когда самый важный контент скрыт в середине 15-секундного аудиоклипа, это может значительно замедлить навигацию, решение проблем и утомить тех, кто внимательно слушает. Таким образом, полезное подробное сообщение для зрячего человека может оказаться мучительно медленным для слепого. Некоторые коды также недвусмысленны как текст («3», «три»), но двусмысленны в устной форме, что создает уникальные проблемы для аудиопредставления текста.

Зрячие, свободно владеющие английским языком люди с двигательными нарушениями могут не иметь проблем с чтением сообщения, но у них могут возникнуть проблемы с доступом к сообщению, если оно скрыто за всплывающей подсказкой или требует открытия какого-либо другого окна в среде IDE. Эти интерактивные свойства сообщения об ошибке могут утомить людей с двигательными нарушениями, усложнив и без того трудную задачу.

И, конечно же, все это взаимосвязано: все вышеперечисленные факторы, а также культура, возраст, грамотность и десятки других факторов взаимодействуют уникальным образом, делая любое сообщение об ошибке более или менее понятным или полезным для конкретных людей. лиц в зависимости от их личности. Это означает, что довольно сложно обобщить универсальные требования к сообщениям об ошибках: это зависит от контекста, культуры, идентичности и многого другого.

Что делает сообщение хорошим?

Несмотря на разнообразие аудиторий сообщений об ошибках, у группы было много мнений о том, что делает сообщение об ошибке хорошим. Некоторые предположили, что краткие сообщения были бы лучше; другие ценили поучительные сообщения; мы определили неотъемлемую напряженность между этими двумя принципами. Некоторые говорили о понятности как о продукте четкого письма, тщательного выбора терминологии. Мы обсудили некоторые мои работы с Майком Ли по персонификации компиляторов. Мы говорили о неприменимости оценок читабельности и их англоязычной предвзятости. Я предложил множество поверхностных качеств сообщений, включая типографскую разборчивость, количество доступных модальностей, в которых доступно сообщение, разборчивость типографской структуры сообщения и его близость к коду, к которому оно относится. Мы выявили эти и другие факторы, но не пришли к единому мнению относительно того, что имело значение. И десятилетия работы по изучению того, что имеет значение, не дали особых указаний.

Некоторые предположили, что сложность того, что делает ошибку хорошей, во многом связана с контекстом, а контекст настолько разнообразен, что трудно предсказать каким-либо совокупным или универсальным образом, что может сделать сообщение «хорошим». Возможно, это связано с описанным выше разнообразием аудитории и склонностью многих разработчиков языков программирования создавать сообщения для людей, похожих на них, а не для всех остальных. Некоторые призывали к созданию науки сообщений об ошибках, чтобы лучше организовать все эти факторы и начать теоретизировать об их взаимосвязях. Другие, казалось, сопротивлялись любой реакции на разнообразие, настаивая на том, что чисто фактические сообщения на английском языке были бы идеальными и что любая попытка персонализации только запутает и усложнит.

Должен ли у нас быть только один, и это должен быть текст?

Среди участников было много разработчиков языков программирования, поэтому основной темой было сожаление о сложности поддержки различных потребностей и аудиторий. Локализация технически проста, но на самом деле писать и поддерживать сообщения на нескольких языках далеко не просто. Языки часто создаются только для поддержки одного канонического сообщения каждого вида, а не нескольких различных уровней детализации или разных аудиторий. Даже языки, которые имеют некоторые из этих встроенных функций, такие как Pyret, ставят перед разработчиками языков трудный выбор в отношении того, как обеспечить согласованность терминологии через языковые и API-барьеры и как синхронизировать языки, сообщения, учебники и другие учебные материалы.

Также обсуждались противоречия между уровнем детализации и контекста в сообщении и затратами на производительность. Например, даже для небольших программ некоторые ошибки времени выполнения могут выиграть от сохранения большого объема контекста во время выполнения, но такой контекст может быть чрезмерно большим для захвата и хранения на более медленных устройствах с меньшим объемом памяти.

Привязав инструменты ко всем вышеперечисленным соображениям, мы также обсудили способы, которыми многие сообщения об ошибках пытаются предлагать предложения, но должны делать это на основании некоторого вывода о намерениях. Предсказание намерений, а также учет неверных выводов — это то, в чем никакие инструменты или языки не преуспели.

Некоторые из наиболее радикальных идей на семинаре отметили некоторые богатые интерактивные функции сообщений об ошибках в современных языках, таких как Pyret, но также представили еще более радикальные альтернативы простым текстовым сообщениям об ошибках. Например, может быть, есть смысл в том, чтобы ошибки были уникальными кодами, а затем поддерживались различные рендеринги и объяснения этих кодов в зависимости от пользователя (даже смешные, такие как мемы!). Или, возможно, есть способы объяснить сообщения об ошибках вообще без слов, с помощью анимации, физических метафор или богатого отображения возможных модификаций для устранения ошибки.

Почему сообщения до сих пор не стали лучше?

Многие на семинаре сетовали на то, что сообщения об ошибках языка программирования по-прежнему ужасны. А для некоторых языков они есть. Но другие отметили значительное улучшение качества таких языков, как Rust, Elm и Python, благодаря усилиям сообщества. Некоторые из них связаны с рыночными силами, а другие просто из-за того, что разные сообщества имеют разные ценности. Многие указывали на опасности и парадоксы капитализма и открытого исходного кода: если язык является источником дохода, как более качественные сообщения об ошибках увеличивают прибыль? А если бесплатно, то зачем что-то улучшать?

Некоторые из нас сохраняли оптимизм в отношении того, что адвокация может что-то изменить; другие были более циничны и считали, что прибыль и власть победят, как это обычно и бывает. Другие все еще задавались вопросом, могут ли исследователи и их исследования сыграть какую-либо роль во всем этом, или наше время может быть лучше потрачено на разработку новых языков с лучшими сообщениями (что бы это ни значило).

Что дальше?

На заключительных сессиях мы собрались небольшими группами и обсудили, что наше сообщество может сделать для продвижения вперед исследований и обучения сообщениям об ошибках. Появились некоторые ключевые темы:

• Существует огромное, неизведанное пространство дизайна представления сообщений об ошибках и взаимодействия. Анимации, персонализированные строительные леса и многое другое в значительной степени не изучены и не реализованы. Частично это связано с трудностями изменения существующих языков и создания новых.
• Существует множество неисследованных форм инструкций о том, как реагировать на сообщения об ошибках. Некоторые известные идеи, которые возникли, - это равное обучение, моделирование стратегии устранения ошибок. Но остается много открытых вопросов о том, какие стратегии хороши и существуют ли какие-либо универсально эффективные стратегии.
• Многие отметили отсутствие теоретических объяснений механизма, лежащего в основе ошибочного поведения учащихся, и кроличьих нор, к которым они часто приводят, а также разнообразия аудитории, читающей сообщения. В частности, группа рассматривала сообщения об ошибках как симптом путаницы «вверх по течению» в отношении языковой семантики и других когнитивных проблем. Сообществу было бы разумно инвестировать в эту аналитическую работу, создавая более прочную основу для поддержки и информирования будущих исследований и разработок.
• Хотя мы вкратце говорили о предотвращении ошибок на семинаре (например, с помощью блочных редакторов, которые предотвращают синтаксические ошибки), нужно сделать гораздо больше, чтобы изучить компромиссы статической типизации и вывода типов, которые могут предотвратить дефекты, но только путем введения еще больше сообщений об ошибках.
• Предстоит проделать большую работу, чтобы понять лонгитюдный опыт экспертов с ошибками; большинство исследований было проведено с новичками, но могут быть важные ограничения и требования для людей, которые сталкиваются с ошибками сотни или тысячи раз.

Лично я думаю, что наиболее важными, действенными и глубокими следующими шагами будут

^
Неожиданный конец файла

Зззззз