Декларативное программирование и сеть

02 Сентября 2014 2760 ,

Как и большинство веб-разработчиков, я провожу свои дни, давая инструкции компьютерам. Эти инструкции обычно включают некоторый ввод (запрос на веб-страницу),  некоторую логику (отправление правильного содержания из базы данных), и некоторый вывод (отправление содержания в запрашивающий браузер).  Это процесс сообщения компьютеру, как выполнить задачу, такую как генерация веб-страницы, то, что мы обычно называем “программирование”, но это – только один из множества видов программирования: императивное программирование.

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

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

Скрытое в простом виде

Декларативные языки имеют тенденцию исчезать на фоне программирования, частично потому что они ближе к тому, как мы естественно взаимодействуем с людьми. Если вы говорите с другом, и вы хотите бутерброд, вы обычно не даете вашему другу постепенные инструкции о том, как сделать его. Если бы вы это делали, то это было бы программированием вашего друга. Вместо этого вы, намного более вероятно, будете говорить о результате, который вы хотите, например “Пожалуйста, сделай мне бутерброд” (или, возможно, “Sudo сделай мне бутерброд”). Если ваш друг желает и в состоянии следовать этим инструкциям, то он перевел бы фразу, “Сделай мне бутерброд” в серию шагов, таких как нахождение ломтя хлеба, применение начинок, и т.д.01-sandwich-opt

Этот тип фокусируется на результате инструкции — то, как декларативное программирование работает, оставляя логику того, как реализовать запросы  системе, которая интерпретирует язык (например, ваш друг). Когда мы хотим изображение в документе HTML, например, мы просто включаем <img> тег, и затем система, которая интерпретирует HTML (обычно, браузер) обработав все шаги, должна была бы  вывести на экран это изображение, такие как извлечение его из сервера, определение, где точно представить его, декодирование двоичных данных, масштабирование изображения и представление его на экране. Мы не должны объяснить все это, так что часто забываем, что все это происходит, и что кто-то запрограммировал это, как это происходит и как из этого сложного комплекса процессов получается простой <img>.

Другой фактор, из-за которого трудно разглядеть декларативное программирование, как программирование в сети, — то, что это “просто работает”. Много сил вложено в создание языков как HTML, CSS и SQL, способных обеспечить достаточную ясность в том, какие потребности могут быть выполнены, какие шаги требуются для достижения результат, и могут быть определены без подробной инструкции. Но большинство веб-разработчиков начали использовать эти декларативные языки, долгое время спустя, после того, как тяжелая работа их создания была завершена, таким образом, мы просто рассматриваем их как нормальную, обычную и просто естественную часть способа работы сети.

Веб-разработчики действительно занимаются декларативным программированием, прежде чем интересная работа будет сделана, это обычно при разработке API для веб-сайта. Большая часть API реализована через декларативное программирование. Вместо того, чтобы обеспечивать способ дать веб-сайту постепенные инструкции, у API обычно есть простой язык, который может использоваться, чтобы выразить желаемый результат. Когда мы хотим получить некоторые твиты от API Twitter, например, мы даем описание твитов, которые мы хотим, такие как “все из @A_single_bear”. Если бы API был обязателен, мы вместо этого описали бы определенные шаги, которые мы хотим, чтобы Twitter реализовал от нашего имени, объясняя, как загрузить, отформатировать и возвратить твиты. К счастью API скрывает всю эту логику позади простого декларативного языка, таким образом, мы только должны описать то, что мы хотим, а не, как получить это.

Два пути вперед

Как только мы понимаем, насколько широко распространены языки декларативного программирования в Интернете, трудно представить себе Интернете без них. Трудно, но не невозможно. Поскольку JavaScript вырос повсеместно, инструменты, в которых мы нуждались бы для сети только для императива, довольно просто найти.  Мы могли бы поменять HTML и CSS для рендеринга непосредственно в JavaScript. Мы могли бы поменять SQL для родной базы данных JavaScrip (или так). И мы могли бы поменять вызовы декларативных веб API, с императивным вызовом функций JavaScript, даже через разрыв между клиентом и сервером.

Мы могли соединить все это и полностью прекратить использовать декларативные языки в сети, даже прежде чем мы войдем в большее количество передовых технологий, возглавляющих наше направление, как asm.js. Мы можем, теперь, создать веб-эквивалент мэйнфреймов: большие, мощные системы, созданные не как набор несоизмеримых частей, а как связное целое. Теперь в JavaScript мы можем все. Мы попробовали это прежде с технологиями как Java и ActiveX. И некоторые организации, такие как AOL, даже имели успех, создающие менее грязный подобный сети стек. Различие на сей раз — то, что технология, доступная, чтобы создать эти “мэйнфреймы”, является частью открытого веб-стека, так, чтобы любой мог теперь сделать их собственный автономный подобный сети стек.

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

Определяя детали реализации в самом языке, декларативное программирование позволяет императивным языкам, таким как JavaScript, PHP и Ruby использовать результаты в качестве шагов в более сложных поведениях. Это имеет преимущество предоставления доступа к поведению, для множества языков, включая языки, которые еще не существуют, и это также дает нам прочную основу, на которой можно строить выше. В то время как мы могли бы строить свой ​​собственный документ рендеринга системы в JavaScript или Python, мы не должны этого делать, потому что HTML уже решил эту проблему. И мы можем снова использовать это решение в любом императивном языке, освобождая нас, чтобы решать новые, большие проблемы. JavaScript может потянуть изображение на холсте и поместить его в документ с HTML. Ваш друг может сделать вам бутерброд и свежий лимонад. Но мы доберемся до этой будущей сети только, оценивая декларативное программирование как подход, который стоит поддержать, теперь, когда это больше не единственный вариант.

Декларативный подход

Когда мы начинаем создавать инструмент в сети, мы часто переходим сразу к том, чтобы заставить сделать то, что мы хотим. В декларативном подходе сначала необходимо  определить язык, чтобы кратко описать результаты, которые мы хотим. Прежде чем мы создадим новую библиотеку JavaScript для создания бутербродов (или, конечно, другой), давайте рассмотрим, как мы могли бы описать результаты на языке декларативного программирования. Одна опция выглядела бы так {«хлеб»: «ржаной», «сыр»: «чеддер»}, в то время как другая выглядела  бы так <бутердброд><чедер /><ржаной /></бутерброд>. Есть много вариантов  при разработке декларативного языка, от высокоуровневого выбора формата (JSON? XML? YAML?) к деталям структуры данных (действительно ли сыр — атрибут бутерброда или объекта в списке начинок бутерброда?). Принятие этих решений раньше может улучшить организацию вашей более поздней обязательной реализации. И в долгосрочной перспективе, декларативный язык может оказаться более важным,  чем удивительная делающая бутерброд реализация, потому что декларативный язык может использоваться вне отдельной реализации.

02-sandwich-opt

Мы видим  некоторые преимущества декларативного подход в общедоступных проектах, который объединил оба подхода. Например, три года назад Sunlight Foundation начинала работать над проектом, который сделал бы проще связь людей с членами Конгресса США. Они начали с приложения Ruby, чтобы автоматизировать представление форм контакта, Formageddon. В этом году они сделали новое декларативное усилие к этой же цели, проекту Contact Congress, запускающемуся с декларативного языка, который описывает формы контакта.

Графики действия и временные шкалы этих двух проектов проясняют, какой подход добился успеха, но преимущества декларативного подхода идут вне прямых результатов. Файлы YAML, произведенные декларативным подходом, могут использоваться, чтобы создать приложения как Formageddon, но они могут также использоваться для других целей, даже не предназначенные их создателями. Например, вы могли бы создать приложение для анализа описания контактных форм, чтобы увидеть, какие темы члены Конгресса ожидают услышать от своих избирателей.

Успешное декларативное программирование, в некоторой степени более сложно, чем императивное. Оно требует четких описаний, но также требует достаточное знание об императивной реализации, чтобы знать, что нужно описывать. Вы не можете только сказать приложению, где форма, и ожидать допустимое представление, и при этом вы не можете сказать <greatwebsite> браузеру и получить то, что вы хотите. Но если вы готовы принять вызов, вознаграждение за декларативный подход также будет больше. Декларативные языки часто переживают свои императивные реализации.

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

По материалам: smashingmagazine.com

Подписывайтесь на обновления

Читайте RSS ленту

Комментарии

Добавить комментарий