Улучшение программирования

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

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

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

Вот почему я работал над созданием инструментов для вычислений. Я начал работать над этим проектом в январе 2016 года, но сделал перерыв в нем с марта по ноябрь 2016 года, чтобы больше сосредоточиться на Пространстве кодирования и WoofJS. Я снова начал работу над этим проектом в декабре 2016 года. Изначально я называл этот проект Цикл, а недавно изменил название на Роза (подробнее об этом ниже).

Журнал развития

Я многому научился, читая и перечитывая блоги и журналы разработки, посвященные аналогичным усилиям, таким как Блог Incidental Complexity и Блог Unison Пола Кьюзано.

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

Это мой первый публичный пост в журнале развития Rose. Я кратко расскажу о проекте, объясню, где дела сейчас и куда я надеюсь направиться в следующие месяцы.

Версия цикла 1

Янв - фев 2016

Первая версия Cycle была сделана с помощью Google Blockly на основе проекта Dom Block. Этот эксперимент можно охарактеризовать как блоки для JQuery. (Технически код был скомпилирован на ванильный JavaScript, но он был очень похож на JQuery-стиль манипуляции с DOM.)

Это позволяло пользователям создавать элементы DOM, выбирать их по идентификаторам, изменять их свойства и реагировать на их события - и все это без ввода строчки кода. Вы просто перетаскивали блоки.

Чтобы продемонстрировать студентам, что это очень похоже на «настоящее кодирование», мы включили окно, которое обновлялось кодом JavaScript, когда вы редактировали программу блоков.

Вы можете посмотреть его вживую на cycle.thecodingspace.com.

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

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

Цикл версии 2

Декабрь 2016 - январь 2017

Вторая версия Cycle также была построена с использованием Google Blockly. Этот эксперимент можно охарактеризовать как «блоки для ReactJS». (Технически код скомпилирован для VueJS.)

Джонатан Люнг и Николь Кельнер помогли мне разработать принципы дизайна для этого этапа проекта.

Когда я начинал проект, моей целью было создать почти точную копию ToDoMVC. Мне удалось сделать это в течение месяца работы здесь (однако позже я нарушил некоторые аспекты этого в более поздних версиях Cycle, поэтому он, вероятно, больше не соответствует пикселям). Я также создал функциональность для интеграции с Firebase и выполнения запросов AJAX. .

Февраль 2017 г.

В прошлом месяце я начал призывать пользователей получать отзывы о Cycle version 2. Мы с моим соучредителем Эли Каривом начали преподавать его некоторым из наших студентов в The Coding Space. Наши студенты, казалось, были в восторге от того, что они могут создать с помощью этого инструмента, но он оказался не таким удобным, как мы надеялись. Им нужно было много наставлений от нас.

Я также выступал с докладами на трех хакатонах по Cycle, чтобы побудить студентов использовать его для создания своих проектов. Хотя семинары прошли хорошо и студенты казались заинтересованными, мне не удалось убедить ни одного ученика использовать Cycle за пределами моего семинара.

В то же время Эли обратился к потенциальным пользователям такого продукта, как Cycle, в том числе к дизайнерам, программистам, программным агентствам, учителям информатики и организаторам хакатонов. Благодаря его исследованиям я познакомился с Webflow, инструментом WYSIWYG для создания веб-сайтов, который меня очень впечатлил. Однако мы не обнаружили явных признаков того, что инструмент, который мы создавали, пользуется большим спросом.

Результаты:

  • Создавать в Cycle v2 было определенно быстрее, проще и менее утомительно, чем набирать код ReactJS или VueJS… когда это работало.
  • Когда вы сталкивались с ошибкой, это был кошмар, к решению которого не могли и близко подойти пользователи, не относящиеся к мне. Отчасти проблема в том, что VueJS часто выдает худшие, наименее полезные ошибки.
  • Он очень точно отражал декларативный шаблон ReactJS, поэтому он смог извлечь выгоду из простоты и мощи этой парадигмы.
  • Хотя это позволило мне невероятно быстро выйти за пределы ворот, Google Blockly был ограничен и его было трудно изменить. В частности, он построен на библиотеке Google Closure, и мне это не понравилось.
  • В конечном итоге худшая часть Cycle v2 - это изолированная система. По такому принципу, как он построен, невозможно ни импортировать, ни экспортировать проект. Это означает, что он должен быть настолько хорош, чтобы вы перестроили в нем свой существующий проект, и вы должны были убедиться, что он сможет удовлетворить ваши потенциальные потребности, и вы никогда не захотите экспортировать из него свой проект. В общем, чтобы заставить вас переключиться, должно быть очень-очень хорошо.

Март 2017 г.

По мере того, как я уходил от версии цикла 2 и выбирал новый путь для этого проекта, мне казалось, что мне нужно было ответить на вопрос…

Должно ли программирование быть языком?

С тех пор, как я влюбился в язык программирования Scratch Массачусетского технологического института, я был уверен, что будущее программирования определенно не в том, чтобы вводить символы в текстовом редакторе. Я не уверен, будет ли это перетаскивание блоков, как в Scratch, но я твердо уверен, что компьютерные программы для редактирования текста просто вышли из своего расцвета. Ради бога, наступил 2017 год!

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

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

Тогда для меня возник вопрос: когда ситуация требует языка, а когда требует графического интерфейса? Это основано на количестве возможных вещей, которые вы хотите сделать? Это основано на технических ноу-хау создателя? Он основан на способности к синтаксическому анализу объекта вашего общения (т.е. человека или компьютера)?

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

Я не лингвист, так что это может быть на 100% неверным, но похоже, что мы все еще не знаем, как полностью смоделировать английский язык. Например, хотя мы много знаем о том, как работают предложения, Siri и Alexa по-прежнему не могут ответить даже на простые вопросы. Я чувствую, что это единственная причина, по которой он может ответить на вопрос: «Какая сегодня погода?» в том, что он способен понимать одно слово «погода». Таким образом, если вы создаете интерфейс для создания предложений на английском языке, ни один редактор графического интерфейса не может содержать какой-либо способ, которым вы хотите что-то выразить, потому что существует чертовски много способов выразить вещи, а мы все еще не знаем, как модели их всех.

Отличие программирования в том, что у нас уже есть модель всего, что вы когда-либо хотели бы сказать на языке программирования. Этот язык называется абстрактным синтаксическим деревом (AST). Чтобы сделать шаг назад, позвольте мне объяснить, что такое AST. Когда вы говорите своему компьютеру запустить программу, он сначала должен преобразовать текст программы в AST. Затем он использует AST для оценки вашей программы и выполнения ваших инструкций. Поэтому, если вы хотите изменить то, что делает компьютер, вам нужно изменить AST. Однако в настоящее время единственный способ изменить AST - это изменить текстовую программу и заставить компьютер заново преобразовать ее в дерево.

Это кажется безумием! Почему бы нам не редактировать дерево напрямую? Учитывая, что мы знаем все возможные способы создания программы, кажется, что создание графического интерфейса, который позволяет вам редактировать AST, - это всего лишь вопрос дизайна интерфейса.

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

Классики

В начале этого месяца (март 2017 г.) я встретился с Самантой Джон из Hopscotch, чтобы получить совет по созданию редактора кода с «контекстом в курсоре». В отличие от Scratch и Blockly, где у вас есть меню блоков, которые можно перетащить в свою программу, приложение Hopscotch для iPhone позволяет вам выбрать часть вашей программы для редактирования, а затем позволяет вам выбирать из набора блоков, которые логически могут туда попасть. Например, если вы нажмете на число, это позволит вам заменить его другим числом или арифметической функцией. Мне очень понравился этот подход, и я начал обдумывать способы применения его в качестве основы для моего редактора, частично как способ наконец-то выйти из Google Blockly.

Чирру

В тот же день, когда я встретился с Сэмом, Алекс Рэттрей прислал мне ссылку на пост Hacker News о Цирру, редакторе AST, в котором он поделился многими идеями, над которыми я размышлял.

Более того, сообщения HN связаны с десятками подобных проектов, о которых я никогда не слышал! Остаток дня, более 5 часов, я провел, просматривая все эти сообщения. В частности, меня поразили Unison и Prune.

Унисон

У Пола Кьюзано грандиозное видение будущего вычислительной техники. Мое видение сделать программирование не таким уж отстойным - это лишь малая часть того, на что надеется его проект Unison. Он начал свой проект с создания структурированного редактора для языка с высокой степенью типизации, похожего на Haskell. Как ни странно, это одно из направлений, в котором я серьезно подумывал о реализации своего проекта, поэтому было удивительно видеть здесь чьи-то мысли и работу, прежде чем я зря потратил свое время на изобретение велосипеда. (Это частично объясняет, почему я начинаю этот журнал общественного развития.)

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

Чернослив

А пока я решил спуститься в другую кроличью нору. Пока Пол создает что-то на основе совершенно нового языка (с надеждой на более прочную основу), сейчас я работаю с целью сделать его на 100% импортируемым и экспортируемым в JavaScript в любое время.

Идея этого проекта также исходила от Алекса Рэттрея. Он создает LightScript, язык преобразования в JS, который очень похож на JS с некоторыми тонкостями. Он предложил мне создать способ визуализации каждого типа узла в анализаторе Babel, а затем построить свой интерфейс поверх этого.

Оказывается, у кого-то была эта идея: Prune появился из ежемесячных проектов Кента Бека и Тьяго Хираи в Facebook. Хотя они не выпустили никаких демонстраций или исходного кода, их постмортальный пост невероятно помог мне начать работу. Было бы правильно сказать, что я пытаюсь продолжить их проект с того места, где они остановились.

Роза

С тех пор, как один из моих любимых программистов выпустил CycleJS, я знал, что мне придется сменить имя с Cycle. Я хотел назвать этот проект в честь моего отца Роджера, но решил, что мужское название языка программирования не имеет смысла. Итак, мы выбрали Роуз, бабушку моего отца, в честь которой его назвали.

Вы можете найти главную ссылку на Rose здесь. В настоящее время он ссылается на:

  • демонстрация того, как Rose может генерировать JS и как JS может генерировать пользовательский интерфейс Rose
  • демонстрация использования Rose для создания программы WoofJS

На момент публикации Роуз очень глючит. В настоящее время он может:

  • Изменить номера и идентификаторы
  • Добавить новые переменные, функции, параметры и т. Д.
  • Перетащите код, чтобы скопировать и заменить. (Супер багги!)
  • Удалить вещи

Мои текущие цели для Rose:

  1. Bootstrap Rose, чтобы я мог добавлять в Rose дополнительные функции с помощью Rose. Это то, что сделала и команда Prune.
  2. Интегрируйте Rose в woofjs.com, чтобы помочь студентам перейти от блочного кодирования к текстовому. В этом смысле Роза была бы очень похожа на Pencil Code. (Изначально я пытался интегрировать Pencil Code с WoofJS, но это оказалось довольно сложно.)

В настоящее время способ работы Rose: Код Javascript - ›Babel AST -› HTML-элементы VueJS - ›События HTML -› Babel AST. (В любой момент вы можете превратить Babel AST в код JS для просмотра или оценки.)

Мои текущие проблемы с Роуз:

  1. VueJS содержит небольшие ошибки и содержит ошибки. Я подумываю о переходе на ReactJS.
  2. Узел TBD. В настоящее время, когда вы добавляете новый узел в Rose, он добавляет значения по умолчанию (обычно нулевые) там, где они нужны, и позволяет вам изменить их позже. Однако не очень хорошо, если в вашем коде полно нулей, поэтому я подумываю взять страницу из Prune и скопировать их понятие узла-заполнителя.
  3. Моделирование всевозможных трансформаций. То, как я моделирую все «вещи, которые вы можете делать на каждом узле» в настоящее время, очень важно и подвержено ошибкам. Я пытаюсь придумать способы сделать это более декларативно, как предлагает Прун. Какая основная структура данных может содержать все возможные преобразования для каждого типа узла?

Другие проблемы, о которых я думаю:

  • Отображение всех возможных преобразований. Одной из основных задач этого проекта является создание пользовательского интерфейса, позволяющего пользователям просматривать, обнаруживать, выбирать и отменять преобразования дерева. В настоящее время у меня есть список преобразований, которые вы можете просмотреть. Это не масштабируется. И Unison, и Prune используют поле для предложений типа «напечатайте голову», чтобы помочь пользователям найти то, что они ищут. Я также открыт для других дизайнов, таких как меню Scratch или даже вложенные папки.
  • Предложения с учетом контекста. Когда я интегрирую Rose в woofjs.com, чтобы студенты могли писать программы WoofJS, мне понадобится способ «настроить» Rose для WoofJS таким же образом, как я настроил предложения CodeMirror по типу головы, чтобы включить функции WoofJS. . Наиболее обобщенным решением этой проблемы были бы сильные объявленные типы. Таким образом, мы могли знать, что и куда может пойти в любое время. В краткосрочной перспективе я открыт для более жестких решений.
  • Текст в виде буквы G в графическом интерфейсе. Один из возможных способов ускорить разработку - отказаться от HTML-представления Rose на VueJS и просто предоставить для просмотра стандартный текст JavaScript. Конечно, мы используем текст только как способ просмотра и навигации по коду - мы не позволим пользователю редактировать JavaScript, вводя или удаляя буквы. Мы бы предоставили список преобразований семантического дерева, из которых они могут выбирать, в зависимости от того, где находится их курсор в коде. Это позволило бы мне обойти проблему рендеринга и выбора узла и сосредоточиться на основных проблемах моделирования и отображения всех потенциальных преобразований дерева.

Сотрудничество

Одна из основных причин, по которой я пишу это, - это сотрудничество с более широким сообществом. Поэтому, если у вас есть совет, предложения или вы хотите поработать вместе, напишите нам на steveykrouse на gmail.com.

Я надеюсь публиковать здесь ежемесячно. Увидимся в конце апреля!