Материал из Linuxformat.

Что за E? штука…

Это действительно язык программирования нового образца, или просто продолжение алфавитной линии C и D? Пол Хадсон все объяснит…

Значит, вы не шутили, говоря об этом в прошлом номере?
Ничуть. В LXF93 мы рассматривали D, созданный на замену C и C++. Теперь мы говорим о E.

Язык на замену D? А я-то думал, что D – это новый язык!
Вы правы, D и в самом деле новый язык – но E совсем не предназначен для его замены. D способен заменить C потому, что похож на него лингвистически и тоже компилируется в высокоэффективный машинный код. Язык E, напротив, интерпретируемый (во всяком случае, пока), вдобавок он совершенно не похож на C по стилю программирования – фактически, это странная смесь Java и Python. Предупреждая ваши вопросы: нет, тот E, о котором мы с вами говорим, не имеет ничего общего с языком программирования E, некогда бывшим основным на Amiga. На другой напрашивающийся вопрос: да, нам бы тоже хотелось, чтобы создатели языков программирования были чуть более изобретательны в выборе названий!

Хорошо, хорошо. Но чем же E отличается от остальных языков программирования?
E предназначен для безопасного распределенного программирования, и это его козырь: единственная программа может работать на многих машинах.

А разве этого не было раньше? Пока мы тут разговариваем, мой SETI@Home занят поиском внеземных цивилизаций…
На языках Java и C++ распределенное программирование реализовывалось индивидуально каждым программистом. В E распределенное программирование – это стандарт, потому что объекты…

Опять эти объекты! Объясните мне, наконец, почему все современные языки программирования – объектно-ориентированные?
Хорошо, давайте остановимся на этом. Да, E – объектно-ориентированный язык. Фактически, он более объектно-ориентированный, чем другие языки программирования, потому что все в E подчинено OOП.

Сейчас завою…
Да ладно, это я так, про себя. Итак, E предназначен для OOП, и не напрасно: именно объекты придают ему вычислительную мощь. Например, объект 1 работает на компьютере 1, а объект 2 на компьютере 2. Если объект 1 вызывает метод объекта 2, то E автоматически формирует запрос, отправляет сообщение по сети и возвращает результат обратно. E-программист даже не обязан знать, где находятся объекты – на его машине или на чужих: E берет все это на себя.

[фырканье] Хм, еще того не легче: а как же
Создатели E позаботились об этом заранее – все сетевые сообщения шифруются и недоступны посторонним.

Ладно, объекты, может, и не столь ужасны. Зато я уверен, что обмен сетевыми сообщениями абсолютно всегда приводит к взаимным блокировкам и зависанию.
На самом деле это не так – у E нет таких проблем.

Ой ли? А вы уверены, что мы говорим об одном и том же?
Конечно, уверен: взаимная блокировка возникает, скажем, тогда, когда у меня есть LXF90, а мне нужен LXF91; у вас же, наоборот, есть LXF91, а вам нужен LXF90. Никто из нас не хочет отдавать свой номер, не получив чужого – вот вам и тупик. Ну что, на одном языке мы с вами говорим? безопасность?

Вроде да. И как E это удается?
Магия! Точнее, колдовство под названием «обещания», позволяющее мне пообещать отдать вам свой LXF90, если вы отдадите мне LXF91. Как только вы это делаете, я тут же отдаю вам LXF90, и все довольны. Теперь вообразите следующий код: someobject->doStuff(). В большинстве языков программирования (включая E) программа не будет продолжена до тех пор, пока someobject не выполнит свой метод doStuff(). В E это называется прямым вызовом функции. Но в E есть и другой способ, под названием «отложенный вызов», то есть вызов, не блокирующий работу программы.

Ого, а это еще что?
Давайте вернемся немного назад. Так вот, someobject->doStuff() исполняется немедленно, вынуждая остальную часть программы ждать. Отложенные вызовы, которые выглядят примерно так: someobject<-doStuff(), не требуют мгновенного исполнения. Фактически, вы говорите: «someobject, когда будет возможность, пожалуйста, выполните doStuff()». В результате программа, сделавшая этот вызов, беспрепятственно продолжает свою работу.

Ага! Проблема налицо: что произойдет, когда doStuff() вернет нужное значение?
Извиняюсь, создатели E тоже об этом подумали! Если вы попытаетесь воспользоваться результатом, возвращенным doStuff(), во время выполнения непрямого запроса, то фактически получите обещание, что нужное значение будет (при необходимости) вычислено. Обещание не будет выполнено до тех пор, пока doStuff() не будет реально вызвана и не возвратит нужное значение, а до тех пор у вас будет лишь его «заготовка». Но зато обещание гарантирует, что вы получите нужное значение в будущем, а пока работа программы будет продолжена так, словно оно уже известно.

Как-то в голове не укладывается.
Бесспорно, уяснить это непросто. Вспомните пример с журналом – мы просим LXF91, но, поскольку некий человек не хочет отдавать его сразу, вместо журнала мы получаем обещание. Для нас оно в перспективе равносильно LXF91, и мы смело отдаем этому человеку свой LXF90. Как только это произойдет, обещанное воплотится в реальный LXF91.

Ладно, поверю вам на слово, что все это работает. Расскажите еще что-нибудь про E – только попроще, пожалуйста!
Как вам вот это: в нем остались все средства управления, к которым вы привыкли в других языках программирования, например if, try, catch, finally, while и for. Но некоторые операторы для удобства восприятия несколько доработаны. Например, чтобы избежать путаницы между = и ==, E перенял подход Pascal и использует := для присваивания, а == для сравнения (сам по себе знак = больше не рименяется). E, в основном, обходится без переменных с типом (string, integer и т.п.), так как подразумевается автоматическое преобразование типов. Например, если добавить к строке число, то E конвертирует число в отдельную строку, а затем объединит обе строки.

А разве языки без типов не усложняют программирование?
Это распространенная точка зрения, и, во избежание проблем, E снабжает программиста «предохранителями» типов, напоминающими признаки классов в PHP. Например, если необходимо, чтобы функция обрабатывала только числа, можно указать это прямо: все входящие данные будут конвертироваться в этот формат. Если конверсия невыполнима, E выбрасывает исключение.

Если кто-нибудь – только не я – захочет попробовать E, как это можно сделать?
Лучшая версия E построена на основе Java, что имеет два основных достоинства. Во-первых, она может работать везде, где есть Java, то есть на Linux, Windows, OS X, мобильных телефонах – да где угодно. Во-вторых, вы получаете функциональность Java простым импортом библиотек. Это означает, что в E можно пользоваться Swing, если захочется – до тех пор, пока вы не поймете, что используемые вами классы Java ничего не получают от распределенной мощи E.

Но я ненавижу Java!
Не беспокойтесь: вам и вашим друзьям – Java-ненавистникам будет приятно узнать, что существует версия E на Common Lisp, которая действует примерно так же – минус поддержка Java, конечно!

Обе версии свободны?
Конечно – под Mozilla Public License.

Круто. Пару слов напоследок?
Если вы хотите узнать об этой теме подробнее, можете посетить такие сайты: www.erights.org – официальная страница, www.skyhunter.com/marcs/ewalnut.html – бесплатный онлайн-учебник по E, и www.combex.com/tech/edesk.htm – домашняя страница CapDesk, рабочей среды, полностью написанной на E, чтобы доказать высокий уровень его безопасности. Спасибо.

Итак, через месяц говорим об F?
Поживем – увидим…