Ни один человек не может постоянно вести себя так, как
не соответствует тому, как он себя воспринимает. (Нил Т. Андерсон «Победа над тьмой»)

7. Недостающая цепочка.

Наконец, я думаю, все сошлось.

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

Здесь я перечислю эти технологии в произвольном порядке: XML, XML-RPC, SOAP, SOA, постоянные объекты, хранилище объектов Franz LISP, JavaScript, AJAX, базы данных и файловые системы, параллельные и распределенные вычисления, вычислительная мощность бесконечной мощности, пассажиры и автомобили. Проблема… Все это выглядит красиво, но когда я приближаю это к своему сердцу, оно всегда кажется мне слишком сложным или скучным. А не делать большие проекты одним или несколькими людьми. Я подумал, что, должно быть, чего-то не хватает… Так называемая «недостающая цепочка» (или отсутствующая идея).

Некоторые проекты вроде Ruby-On-Rails и TIBCO приближаются к Проблеме, но не хватает одной важной части — естественности. Очень неестественно писать приложения в таких средах. Они объединяют все существующие части современных технологий и представляют их как полный беспорядок. Никто не может иметь полный контроль над тем, что происходит внутри этих систем. Многие вещи по-прежнему работают за кулисами, что приводит к множеству ошибок и эксплойтов. И эти системы такие тяжелые! Пытаясь хорошо рассмотреть все элементы управления пользовательского интерфейса, которые они используют, они загружают почти ВЕСЬ код JavaScript в браузер клиента во время запуска. Поскольку в их интерфейсе много сложных элементов управления, общий интерфейс становится медленным, раздутым и свиноподобным.

Тем временем мои руки занимались другой и вполне обыденной работой — программировали небольшой проект для небольшой компании. Так как я всегда стараюсь улучшать свои технологии (или даже иногда изобретать новые), я начал искать новые серверные инструменты. Существующие, которыми я часто пользуюсь (Shell+Perl+Progress СУБД), все равно не позволяют делать все так естественно, как хотелось бы. Все мои недавние проекты были веб-ориентированными, с интенсивным использованием клиентского JavaScript и взаимодействием с сервером в стиле AJAX. Я использую эту технологию с 2001 года, и тогда я не знал, что это AJAX.

Итак, что может быть более естественным иметь на сервере, если вы используете JavaScript на стороне клиента? Да! Конечно, это JavaScript! Хорошо. Я установил SpiderMonkey — автономную оболочку JavaScript [я писал эти статьи в 2007 году] — на сервер и начал возиться с ней. На первый взгляд это не дает ничего, кроме естественного повторного использования объектов с обеих сторон. Затем, приглядевшись, я понял, что это идеальный механизм для передачи объектов туда и обратно по Сети в одной и той же естественной среде: скачивание, выгрузка, выполнение… Стоп!

Вот суть всего этого! Здесь мы получаем естественный блок обработки объектов (или OPU). Да, я знаю, что существуют такие технологии, как XML-RPC, SOAP, SOA, веб-сервисы, которые, кажется, делают то же самое. Но на самом деле то, что они делают, НЕ совсем не то же самое. Что они на самом деле делают — они отвечают на поступающие данные данными (или, иногда, даже объектами), но с другой стороны, сами они являются лишь заранее запрограммированными или уже существующими объектами. Они не могут реагировать на случайные данные и обычно возвращают ошибку, если с данными что-то не так. Они ДЕЙСТВИТЕЛЬНО заботятся о данных! Чтобы понять эту разницу, позвольте мне спросить: заботятся ли обычные процессоры о коде? Заботится ли транспортное средство о водителе и/или пассажирах? Таким образом, в моей ситуации любой существующий экземпляр объекта JavaScript может быть передан вместе с внутренней логикой и данными и выполнен самостоятельно, без каких-либо сведений об этом на стороне сервера. Однако для этого требуется некоторая вспомогательная инфраструктура в виде других общих объектов на сервере. Но в нашем случае они естественным образом интегрированы в окружающую среду.

Да, я знаю, что я не первый, кто нашел эту возможность. Этот метод программирования, скорее всего, используется где-то в дикой природе, но я не слышал, чтобы его воспринимали всерьез до сих пор. И все же я не исследовал весь потенциал этого. Нужно больше экспериментов. Но смею предположить, что это и есть та самая «недостающая цепочка» в нынешнем беспорядке технологий. И это не обязательно должен быть JavaScript. Так уж получилось, что пока это единственный динамический язык, поддерживаемый браузерами. Суть в том, чтобы иметь такую ​​же природную среду. Тогда все становится намного проще и мощнее.

Представьте: клиентский браузер эмитирует кучу объектов в Интернет, часть из них может быть отправлена ​​дальше, часть может генерировать новые объекты на лету и распространять их дальше и дальше… Они могут собирать какие-то данные из разных поисковых систем, наверное с небольшим локальным объемом данных, не требующим большой мощности, но в сумме он может быть даже более всеобъемлющим, чем Google. Он может действовать так же, как сегодняшняя система DNS. Но, да, это также подразумевает более высокий уровень безопасности, потому что может быть хорошей почвой для различных вирусов. Здесь начинается параллельное и распределенное программирование. Здесь начинается Infinite Power Computing. Давайте мечтать дальше.

Я не буду упоминать какие-либо подробности об этой «недостающей части», пока полностью не изучу все последствия этого.

продолжение следует…