Как программисты помогают думать методистам: два интересных опыта компании Макромедиa
Как вообще программисты могут помочь думать методистам? Возможно ли это? Помогает ли, например, MS Word автору в формировании текста? И да, и нет.
Да в том смысле, что Word имеет удобный понятный интерфейс, развитый набор функций форматирования, специальные возможности, наподобие автоматической верстки оглавления. Имей Гоголь подобный инструмент, ему не пришлось бы давать следующих рекомендаций по работе над текстом: « … Сделайте поправки и заметки на полях — и снова забросьте тетрадь. При новом пересмотре её новые заметки на полях, и где не хватит места — взять отдельный клочок и приклеить сбоку. …».
Нет, поскольку, наличие возможностей и удобств не избавляет от необходимости думать.
В конце прошлого века, когда еще не было понятия Web 2.0, когда еще шла ожесточенная борьба между языками программирования-разработки и еще не было ясно, что dot-синтаксис победит — было широкое поле для экспериментирования. Разработчики сред программирования вкладывали огромные деньги, чтобы первыми изобрести удобный для пользователя способ разработки приложений (в том числе учебного назначения). И одним из главнейших экспериментаторов была компания Макромедиа.
Одним из продуктов Макромедии было средство разработки учебных курсов Authorware, предназначенное для быстрой комфортной разработки курсов не программистами, а непосредственно авторами. Для обеспечения такой возможности использовался мастер построения структуры курса и графический интерфейс структуры курса в виде блок-схемы. Мастер курса в момент создания нового учебного курса задавал ряд уточняющих вопросов о том, каким должен быть курс, после чего создавался готовый для наполнения «скелет» курса. Блок-схема курса не только отражала его текущую структуру, но и представляла все необходимые возможности модификации курса, изменением собственно блок-схемы. При этом, для создания курса ни какого программирования не требовалось: все производилось на уровне мастеров, которые задавали уточняющие вопросы. Например, когда автор добавлял к блок-схеме курса очередной тест, его спрашивали: какой это будет тест, сколько вариантов ответа, и прочее. Я тестировал несколько авторских средств разработки на основе блок-схем в качестве инструментария, замещающего программирование — Authorware был самым продуманным, но и он не стал популярен. Авторские средства на основе блок схем оказались не удобны. А в качестве победителей в этой борьбе можно считать продукты со слайдовой идеологией (как у PowerPoint, например).
В качестве другого интересного опыта привожу начальную версию языка Lingo (описываемая версия использовалась в 1990-х годах). (Lingo — встроенный язык продукта Macromedia Director.) Макромедиа создала язык с синтаксисом, который почти естественным английским языком позволял автору описывать, что должна сделать программа. Например, автор мог написать (на английском, разумеется):
Установить цвет объекта "лампа" "желтый"
Если картинка объекта "диван" имеет значение "собран" то картинку объекта "диван" установить в "разобран"
Координатам объекта "человек" присвоить координаты объекта "диван"
При этом программа понимает, что ей нужно сделать. В итоге получается легко читаемый сценарий. Задумка хороша, но когда у объекта очень сложная структура, например, много степеней вложенности, «человеческим» языком становится сложно объяснить, что ты хочешь от этого объекта. В итоге, синтаксис языка Lingo был трансфрирован в dot-синтаксис:
Объект("лампа").цвет = "желтый"
Если объект("диван").картинка = "собран" то объект("диван").картинка = "разобран"
Объект("человек").координатаX = объект("диван").координатаX
Объект("человек").координатаY = объект("диван").координатаY
(В оригинале все, разумеется, на английском, но для удобства восприятия перевел на русский.)
Из этого опыта можно сделать вывод, что естественный язык хуже языка программирования, когда пытаешься подробно объяснить программе, как она должна работать (то есть даже при скриптовом, но все же программировании). А в качестве победителей в этой борьбе можно считать dot-синтаксис (как у JavaScript, например).
Да в том смысле, что Word имеет удобный понятный интерфейс, развитый набор функций форматирования, специальные возможности, наподобие автоматической верстки оглавления. Имей Гоголь подобный инструмент, ему не пришлось бы давать следующих рекомендаций по работе над текстом: « … Сделайте поправки и заметки на полях — и снова забросьте тетрадь. При новом пересмотре её новые заметки на полях, и где не хватит места — взять отдельный клочок и приклеить сбоку. …».
Нет, поскольку, наличие возможностей и удобств не избавляет от необходимости думать.
В конце прошлого века, когда еще не было понятия Web 2.0, когда еще шла ожесточенная борьба между языками программирования-разработки и еще не было ясно, что dot-синтаксис победит — было широкое поле для экспериментирования. Разработчики сред программирования вкладывали огромные деньги, чтобы первыми изобрести удобный для пользователя способ разработки приложений (в том числе учебного назначения). И одним из главнейших экспериментаторов была компания Макромедиа.
Одним из продуктов Макромедии было средство разработки учебных курсов Authorware, предназначенное для быстрой комфортной разработки курсов не программистами, а непосредственно авторами. Для обеспечения такой возможности использовался мастер построения структуры курса и графический интерфейс структуры курса в виде блок-схемы. Мастер курса в момент создания нового учебного курса задавал ряд уточняющих вопросов о том, каким должен быть курс, после чего создавался готовый для наполнения «скелет» курса. Блок-схема курса не только отражала его текущую структуру, но и представляла все необходимые возможности модификации курса, изменением собственно блок-схемы. При этом, для создания курса ни какого программирования не требовалось: все производилось на уровне мастеров, которые задавали уточняющие вопросы. Например, когда автор добавлял к блок-схеме курса очередной тест, его спрашивали: какой это будет тест, сколько вариантов ответа, и прочее. Я тестировал несколько авторских средств разработки на основе блок-схем в качестве инструментария, замещающего программирование — Authorware был самым продуманным, но и он не стал популярен. Авторские средства на основе блок схем оказались не удобны. А в качестве победителей в этой борьбе можно считать продукты со слайдовой идеологией (как у PowerPoint, например).
В качестве другого интересного опыта привожу начальную версию языка Lingo (описываемая версия использовалась в 1990-х годах). (Lingo — встроенный язык продукта Macromedia Director.) Макромедиа создала язык с синтаксисом, который почти естественным английским языком позволял автору описывать, что должна сделать программа. Например, автор мог написать (на английском, разумеется):
Установить цвет объекта "лампа" "желтый"
Если картинка объекта "диван" имеет значение "собран" то картинку объекта "диван" установить в "разобран"
Координатам объекта "человек" присвоить координаты объекта "диван"
При этом программа понимает, что ей нужно сделать. В итоге получается легко читаемый сценарий. Задумка хороша, но когда у объекта очень сложная структура, например, много степеней вложенности, «человеческим» языком становится сложно объяснить, что ты хочешь от этого объекта. В итоге, синтаксис языка Lingo был трансфрирован в dot-синтаксис:
Объект("лампа").цвет = "желтый"
Если объект("диван").картинка = "собран" то объект("диван").картинка = "разобран"
Объект("человек").координатаX = объект("диван").координатаX
Объект("человек").координатаY = объект("диван").координатаY
(В оригинале все, разумеется, на английском, но для удобства восприятия перевел на русский.)
Из этого опыта можно сделать вывод, что естественный язык хуже языка программирования, когда пытаешься подробно объяснить программе, как она должна работать (то есть даже при скриптовом, но все же программировании). А в качестве победителей в этой борьбе можно считать dot-синтаксис (как у JavaScript, например).
