Лютый апгрейд подхода к обучению программированию
Вы наверняка уже знаете, что известнейшая Khan Academy, являющаяся пионером по онлайн-образованию школьников, совсем недавно выпустила интерактивные курсы по программированию. В качестве платформы используется JavaScript и библиотека Processing. Вполне логичный и достойный выбор, всячески поддерживаем и одобряем. JavaScript очень даже неплох в качестве первого языка программирования, да и потом в жизни почти каждого инженера он тем или иным образом пригодится. В нашей компании JavaScript вообще является основой бизнеса, ибо «Продукт есть интерфейс».
Брет Виктор - исследователь и визионарий новых интерфейсов человеко-машинного взаимодействия. Я уже писал о нём в моей заметке « Интерфейсы и инструменты»:Программистам и дизайнерам интерфейсов посвящается. Настолько мощная презентация от изобретателя новых концепций пользовательского интерфейса в Apple, что одним ретвитом @stevebest не обойдёшься.
Так вот, этот самый Брет Виктор сказал, что этот Хан-Академийский интерфейс для обучения программированию - фуфло и туфта.
А так как Брет человек дела, а не только слова, то он написал не просто аргументированную критику связки JS+Processing, использующуюся в курсах Khan Academy, но и потрудился тщательнейшим образом реконструировать возможный интерфейс правильной системы для обучения. Эта работа Брета показалась мне настолько увлекательной, что в голове постоянно крутятся слова seminal paper в применении к данной работе. Это действительно работа мастера. Всем программистам и дизайнерам интерфейсов читать полностью, без вариантов и отмазок.
Читаем: Learnable Programming
В своей работе Брет постепенно, подход за подходом, прилагает очередную мощную идею из своего списка идей и ценностей проектирования интерфейса, и доходит до захватывающих результатов. При этом, его примеры - это не просто картинки, а живые видео-иллюстрации. Это нужно видеть!
Ближе к концу Брет отвлекается от проектирования надстройки над JavaScript, и делится видением по поводу метафор, стоящих за языками программирования.
Каждый язык программирования наполнен метафорами, но некоторые ложатся на мозг лучше, чем другие. Стандартный императивный подход использует метафору «присвоение переменным» - перемещение битов между маленькими коробочками. В отличие от черепашки Logo, эта метафора не была спроектирована для того, чтобы соответствовать тому, как люди учатся и понимают; она просто эволюционировала как тонкий слой над метафорами, использующимися в архитектуре низлежащей машины, такими как «сохранение в памяти».*
* Алан Кей в «The Early History of Smalltalk»: «Операторы присваивания - даже абстрактные - выражают очень низкоуровневые цели... Люди-программисты не являются машинами Тьюринга, и чем меньше их программные системы требуют техники от Тьюринг-машин, тем лучше.»
Интересно, что то же самое высказывание проливает свет немного под другим углом на вопрос о том, является ли императивное программирование интуитивным, в отличие от функционального. Из высказывания видно, что метафора машины Тюринга с переносом состояния из ячейки в ячейку не является сколько либо интуитивной, и появилась она лишь как трансляция особенностей аппарата по интерпретации этих программ, который продолжает оставаться основой большинства современных архитектур.
Из дальнейшего рассмотрения метафор, на которых построены некоторые другие языки программирования, мы видим, что Smalltalk (или тот же Erlang, если читать между строк) предоставляют очень вкусную метафору посылки сообщений между объектами. «Эта очень мощная метафора, потому что ролевые игры и разговоры являются мощными встроенными человеческими свойствами.»
Далее Брет Виктор цитирует одного из авторов языка Haskell:
Когда программист пишет модульную программу для решения задачи, он сначала разбивает задачу на подзадачи, затем решает подзадачи, и в конце концов объединяет решения. Способы, которыми программист может разбить оригинальную проблему, напрямую зависят от способов, которыми он сможет затем склеить решения вместе. Следовательно, для увеличения чьей-то способности модуляризировать задачи в принципе, нужно обеспечить новые типы клея в языках программирования.
Функциональные языки обеспечивают два новых, очень важных типа клея... Это ключевая вещь, обеспечивающая мощность функционального программирования - оно позволяет улучшенную модуляризацию.
Что касается среды Processing (изначально это библиотека для облегчения программирования графики для Java, но теперь доступна и на JavaScript, именно её использует Khan Academy):
Недостатки модульности среды Processing являются серьёзными барьерами для рекомпозиции. Программист не может просто взять у друга модель прыгающего мячика и положить рядом его собственного прыгающего мячика. Переменные должны быть переименованы или инкапсулированы вручную, соответствующие функции "draw" и работа с мышью должны быть переплетены друг с другом, и так далее. Можно легко начать работать с существующей программой Processing и изменять её, но язык не поощряет комбинирование двух программ.
Что ещё хуже, зависимость Processing'а от глобального состояния (там хранится графический контекст, например, матрицы трансформаций - lionet) убивает даже простейшие формы рекомпозиции.
Кстати, приводится непрямой аргумент в защиту Objective-C, который я люблю защищать именно из за этого свойства readability для новичков. В цитате ниже мысленно подставьте Objective-C вместо Smalltalk, синтаксис похожий там.
Smalltalk:canvas drawEllipseCenteredAtX:50 y:50 width:100 height:100.
Processing:ellipse(50,50,100,100);
x86 assembly:push 100; push 100; push 50; push 50; call _ellipse
В Smalltalk аргументы дают контекст. В Processing функция "ellipse" точно такая же таинственная, как и в языке ассемблера. Читатель должен подсмотреть или запомнить каждый аргумент - существенный барьер для чтения.
Для того, чтобы освободить меня от необходимости переводить и цитировать - идите и читайте сами :)
http://worrydream.com/LearnableProgramming/
Если из моих слов выше ещё не вполне понятно, то поясню: я считаю, что Брет Виктор написал очень крутую вещь. Последняя цитата:
Частый вопрос по поводу техник, которые описаны здесь: «Как это масштабируется до реального программирования?» Это очень хороший вопрос, но это примерно как спрашивать, как двигатель внутреннего сгорания сможет помочь лошадям. Вопрос подразумевает трансформацию не того рода.
P.S. Мы в Echo (aboutecho.com, echorussia.ru) очень сильно хайрим JavaScript-программистов в Ульяновск и Новосибирск. jobs@aboutecho.com
Брет Виктор - исследователь и визионарий новых интерфейсов человеко-машинного взаимодействия. Я уже писал о нём в моей заметке « Интерфейсы и инструменты»:Программистам и дизайнерам интерфейсов посвящается. Настолько мощная презентация от изобретателя новых концепций пользовательского интерфейса в Apple, что одним ретвитом @stevebest не обойдёшься.
Так вот, этот самый Брет Виктор сказал, что этот Хан-Академийский интерфейс для обучения программированию - фуфло и туфта.
А так как Брет человек дела, а не только слова, то он написал не просто аргументированную критику связки JS+Processing, использующуюся в курсах Khan Academy, но и потрудился тщательнейшим образом реконструировать возможный интерфейс правильной системы для обучения. Эта работа Брета показалась мне настолько увлекательной, что в голове постоянно крутятся слова seminal paper в применении к данной работе. Это действительно работа мастера. Всем программистам и дизайнерам интерфейсов читать полностью, без вариантов и отмазок.
Читаем: Learnable Programming
В своей работе Брет постепенно, подход за подходом, прилагает очередную мощную идею из своего списка идей и ценностей проектирования интерфейса, и доходит до захватывающих результатов. При этом, его примеры - это не просто картинки, а живые видео-иллюстрации. Это нужно видеть!
Ближе к концу Брет отвлекается от проектирования надстройки над JavaScript, и делится видением по поводу метафор, стоящих за языками программирования.
Каждый язык программирования наполнен метафорами, но некоторые ложатся на мозг лучше, чем другие. Стандартный императивный подход использует метафору «присвоение переменным» - перемещение битов между маленькими коробочками. В отличие от черепашки Logo, эта метафора не была спроектирована для того, чтобы соответствовать тому, как люди учатся и понимают; она просто эволюционировала как тонкий слой над метафорами, использующимися в архитектуре низлежащей машины, такими как «сохранение в памяти».*
* Алан Кей в «The Early History of Smalltalk»: «Операторы присваивания - даже абстрактные - выражают очень низкоуровневые цели... Люди-программисты не являются машинами Тьюринга, и чем меньше их программные системы требуют техники от Тьюринг-машин, тем лучше.»
Интересно, что то же самое высказывание проливает свет немного под другим углом на вопрос о том, является ли императивное программирование интуитивным, в отличие от функционального. Из высказывания видно, что метафора машины Тюринга с переносом состояния из ячейки в ячейку не является сколько либо интуитивной, и появилась она лишь как трансляция особенностей аппарата по интерпретации этих программ, который продолжает оставаться основой большинства современных архитектур.
Из дальнейшего рассмотрения метафор, на которых построены некоторые другие языки программирования, мы видим, что Smalltalk (или тот же Erlang, если читать между строк) предоставляют очень вкусную метафору посылки сообщений между объектами. «Эта очень мощная метафора, потому что ролевые игры и разговоры являются мощными встроенными человеческими свойствами.»
Далее Брет Виктор цитирует одного из авторов языка Haskell:
Когда программист пишет модульную программу для решения задачи, он сначала разбивает задачу на подзадачи, затем решает подзадачи, и в конце концов объединяет решения. Способы, которыми программист может разбить оригинальную проблему, напрямую зависят от способов, которыми он сможет затем склеить решения вместе. Следовательно, для увеличения чьей-то способности модуляризировать задачи в принципе, нужно обеспечить новые типы клея в языках программирования.
Функциональные языки обеспечивают два новых, очень важных типа клея... Это ключевая вещь, обеспечивающая мощность функционального программирования - оно позволяет улучшенную модуляризацию.
Что касается среды Processing (изначально это библиотека для облегчения программирования графики для Java, но теперь доступна и на JavaScript, именно её использует Khan Academy):
Недостатки модульности среды Processing являются серьёзными барьерами для рекомпозиции. Программист не может просто взять у друга модель прыгающего мячика и положить рядом его собственного прыгающего мячика. Переменные должны быть переименованы или инкапсулированы вручную, соответствующие функции "draw" и работа с мышью должны быть переплетены друг с другом, и так далее. Можно легко начать работать с существующей программой Processing и изменять её, но язык не поощряет комбинирование двух программ.
Что ещё хуже, зависимость Processing'а от глобального состояния (там хранится графический контекст, например, матрицы трансформаций - lionet) убивает даже простейшие формы рекомпозиции.
Кстати, приводится непрямой аргумент в защиту Objective-C, который я люблю защищать именно из за этого свойства readability для новичков. В цитате ниже мысленно подставьте Objective-C вместо Smalltalk, синтаксис похожий там.
Smalltalk:canvas drawEllipseCenteredAtX:50 y:50 width:100 height:100.
Processing:ellipse(50,50,100,100);
x86 assembly:push 100; push 100; push 50; push 50; call _ellipse
В Smalltalk аргументы дают контекст. В Processing функция "ellipse" точно такая же таинственная, как и в языке ассемблера. Читатель должен подсмотреть или запомнить каждый аргумент - существенный барьер для чтения.
Для того, чтобы освободить меня от необходимости переводить и цитировать - идите и читайте сами :)
http://worrydream.com/LearnableProgramming/
Если из моих слов выше ещё не вполне понятно, то поясню: я считаю, что Брет Виктор написал очень крутую вещь. Последняя цитата:
Частый вопрос по поводу техник, которые описаны здесь: «Как это масштабируется до реального программирования?» Это очень хороший вопрос, но это примерно как спрашивать, как двигатель внутреннего сгорания сможет помочь лошадям. Вопрос подразумевает трансформацию не того рода.
P.S. Мы в Echo (aboutecho.com, echorussia.ru) очень сильно хайрим JavaScript-программистов в Ульяновск и Новосибирск. jobs@aboutecho.com