Excel vs. Python: как целевой язык меняет все для неэкспертов

Таблица ссылок

Аннотация и 1 введение

2. Предыдущие концептуализации интеллектуальной помощи для программистов

3. Краткий обзор больших языковых моделей для генерации кода

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

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

6. Изузаение юзабилити и дизайна программирования A-ассистентного

7. Опыт отчетов и 7.1. Писать эффективные подсказки сложно

7.2 Активность программирования сдвигается в сторону проверки и незнакомой отладки

7.3. Эти инструменты полезны для шаблона и повторного использования кода

8. Неадекватность существующих метафор для программирования A-A-Advisted

8.1. Помощь ИИ в качестве поиска

8.2. Помощь ИИ в качестве компиляции

8.3. Помощь ИИ в качестве парного программирования

8.4. Отчетливый способ программирования

9. Проблемы с применением программирования конечного пользователя

9.1. Выпуск 1: Спецификация намерений, разложение проблемы и вычислительное мышление

9.2. Выпуск 2: Правильность кода, качество и (над) уверенность

9.3. Выпуск 3: Понимание и обслуживание кода

9.4. Выпуск 4: Последствия автоматизации в программировании конечных пользователей

9.5. Выпуск 5: Код без кода и дилемма прямого ответа

10. Заключение

A. Источники отчета о испытании

Ссылки

9.5. Выпуск 5: Код без кода и дилемма прямого ответа

Наконец, это не предрешенное вывод о том, что пользователи даже заинтересованы в коде. Как отмечает модель инвестиций в внимание Блэквелла, во многих случаях пользователь может быть контентом для выполнения действий вручную, а не инвестировать в создание многоразовой автоматизации (Blackwell, 2002a; J. Williams et al., 2020). Пользователи электронных таблиц, в частности, часто не чувствительны к уровню автоматизации или автоматизации данного рабочего процесса, используя сочетание ручных, автоматизированных и полуавтоматических методов для достижения целей (Pandita et al., 2018).

Пользователям электронных таблиц часто нуждаются в специальных преобразованиях своих данных, которые, по всей вероятности, никогда не нуждаются снова. Может случиться так, что мы можем выразить это преобразование как программу, но если пользователь заинтересован в выводе, а не в программе, важно ли или даже необходимо передать этот факт пользователю? Можно утверждать, что повышение осведомленности пользователя о гибкости и ошибке процесса предоставления предполагаемого результата (то есть, позволяя им критически оценить результаты (Sarkar et al., 2015)) может построить агентство, доверие, доверие и устойчивость. Эта проблема связана с «дилеммой прямого ответа» (Potthast et al., 2021), поднятой в ответ на повышенное явление поисковых систем, непосредственно отвечающих на запросы в дополнение к простому перечислению результатов.

Однако, если используемый язык программирования не связан с языками, знакомыми для конечного пользователя, или пользователь является полным новичком, им чрезвычайно трудно понять его, как было показано Lau et al. (2021) В своем исследовании пользователей Excel, встречающихся с кодом Python. Тем не менее, существуют социально-технологические мотивы для использования незнакомого целевого языка: долгосрочное тестирование помощи LLM показывает, что он светит в паре с API высокого уровня, которые хорошо снимают варианты использования (раздел 7). Одним из преимуществ экосистемы Python является то, что она имеет беспрецедентный набор библиотек и API для сжатия данных. Следовательно, инструмент с помощью LLM, который излучает формулы Excel, с меньшей вероятностью решает пользовательские задачи, чем операторы Python. В долгосрочной перспективе это может быть смягчено путем разработки богатого набора библиотек манипулирования данными на языке формулы Excel.