Всем более-менее опытным программистам, работавшим с энтерпрайзом, четко известен следующий эмпирический закон:

Девятое Правило Гринспуна, о котором он сознательно предпочел умолчать

Любая более-менее крупная программа на Java или C# является программой на XML

Вобщем, в один прекрасный день, работая на C#, я написал на XML-конфиг некоторых приблуд для UI. Это смотрелось настолько элегантно и красиво, и кастомизировалось настолько проще, по сравнению с обычным хардкодом, что я долго лелеял идею о том чтобы воткнуть подобное еще куда-либо в проект.

Не так давно, такой шанс появился, и я перевел в декларативное описание на XML воркфлоу основных бизнес-процессов системы.

Получилось опять же крайне неплохо, но потом я посидел и подумал.

А что если эти два конфига объединить в один XML?

Ой, стойте, но тогда ведь получается, что туда же можно перенести и разнообразные простые валидаторы и предикаты действий по бизнес-логике? Описание геттеров/сеттеров и простой арифметики - не такое уж сложное занятие, тем более проект и так в System.Reflection по уши.

Черт! Но вообще-то ведь и сложные тоже не проблема - ведь они явлются в 99% случаев не более чем SQL/HQL-запросами, которые никто не мешает хранить в конфигах.

Ух, а ведь если подумать еще - то туда же можно перенести и сами действия по бизнес-логике, не так ли?

Но ведь можно пойти и дальше. Из XML можно вообще-то говоря даже и генерировать модель данных для всей логики системы! И ведь это не просто бредовая идея - такое отчасти давно уже делается стандартными средствами .Net-платформы, например тем же Entity Framework.

И тут я задался вопросом - а зачем нам тогда вообще большая часть кода на C#? Сторонние библиотеки мы ведь точно так же можем вызывать из интерпретатора XML.

Вон оно как все отлично то выходит.

Хм, правда что-то эта модель несколько, скажем так, раздулась.

Вот бы, конечно, написать более высокоуровневый интерпретатор XML чтобы он нам генирировал наш XML из декларативного описания другим XML?

И тут меня осенило. Где-то я это уже видел. Может быть в одной книжке, давно забытой на полке? Или в старой статье семьдесят мохнатого года?

Вспомнив окончательно, я просто расплакался.

Итак:

Вторая Теорема Лавсана

Каждый XML-программист (то есть любой продвинутый java/c#-программист) в конечном итоге доходит до лиспа, просветляется и плачет.

Дискач.

В Петербурге, 28го ноября, пройдет очередной IT Global Meetup. http://piter-united.ru/itgm/itgm.html

В числе участников - лисперы, во главе со мной и Мишей Глуховым(rigidus)

Мы двое, соотвественно, точно будем выступать и представим доклады.

Хотелось бы узнать, желает ли кто-нибудь еще вместе с нами подготовить какой-либо доклад на тему лиспа? Уже требуется подтвердить программу, так что дайте знать как можно скорее.

Значит, я с бодуна вот что придумал.

Универсальный Критерий Угребищности Систем Общего Назначения. (Теорема лавсана)

Система Общего Назначения является Угребищной тогда и только тогда когда она не является Метациклическим Интерпретатором.

Другими словами: Система, не способная к построению Метасистемы в рамках самой себя, то есть не способная к описанию и изменению самой себя в своих же терминах, и при этом являющаяся Системой Общего Назначения(в какой-либо области), Угребищна.

Обратное, естественно, неверно. Если Метасистему Системы Общего Назначения можно описать другой системой, это совершенно не значит что она Угребищна, и более того, в таком случае не существовало бы концепции бутстрапа, а значит и Метациклических Интерпретаторов вообще.

Чем, в контексте языков программирования, это отличается от просто тьюринг-полноты?

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

Альтернативно, мы можем такую метасистему использовать как стороннее средство, связанное через стороннюю систему(скажем генерировать код и вызывать компилятор через создание процесса операционной системы в которой запускается программа на нашем тьюринг-полном языке), подтверждая тем самым десятое правило Гринспуна, и собственно тезис теоремы.

Примеры, сначала метациклических интерпретаторов:

• Универсальная машина Тьюринга
• RASP-машина
• Реляционная модель данных
• Лисп

А вот скажем примеры систем, соответствующих критерию:

• Среднестатистический современный регистровый процессор
• Большинство языков программирования, особенно со статической типизацией.
• Большинство NoSQL моделей данных или скажем иерархических моделей данных, вроде файловых систем

В частности, давайте посмотрим на C#. C# не является метациклическим интерпретатором, т.к. термины языка не являются его же объектами.

Отчасти, это компенсируется платформой .Net, для которой термины C#(но не все) объектами таки являются(System.Reflection, грядущий Roslyn и т.д.), отчасти, в самой малой степени, фичей nameof() из C# 6, но это все только отчасти.

Сама же платформа .Net критерию тоже соответствует, но, в теории из нее можно было бы сделать метациклический интерпретатор, лисп-машину, внеся лишь достаточно небольшие изменения.

Дискач.

UPD. Собственно, отличнейшую статью нашел на эту тему: http://weblog.raganwald.com/2006/11/significance-of-meta-circular_22.html

Почему бы не добавить в лоркод картинки? Что-то типа img тега. Наверное круто было бы, не?

Народ! Reksoft, а конкретнее, американцы, на которых наше подразделение работает, то есть AlertLogic - набирают Erlang разработчиков.

Если нет знаний/опыта Erlang - это не проблема, научим. В таком случае, нужны навыки и опыт Си и C++. Желательно, конечно, иметь представление о функциональных языках вообще, таких как Лиспы, Scala, Хаскель и т.п.

Нужны знания и навыки по многопоточности, распределенным системам, системным API(linux, windows), веб-сервисам, сетевым протоколам; также пригодятся знания по парсерам, различным базам данных(как SQL так и NoSQL), и конечно, алгоритмика.

Естественно, нужен минимально необходимый для общения уровень английского языка. Разговорный - огромный плюс.

Вакансии на hh:
http://spb.hh.ru/vacancy/9743415
http://spb.hh.ru/vacancy/9743307

И да, город - Санкт-Петербург, но при необходимости - с релокацией помогут.

Народ, я тут устроился эрлангистом, буквально сегодня был первый рабочий день.

Возник такой вопрос - какие книжки порекомендуете почитать? Ну и вообще, статьи, другую литературу, howto, etc.

Btw: исключая видеокурс Царёва( http://erlang-mnesia-video.ru/ ), ессно, это я уже освоил в полной мере

Мы тут в одном широко известном в узких кругах чятике придумали отличную идею для стартапа. И заодно, для повышения популярности лиспа.

Надо написать на CL хреновину, которая занимает много кода, но нихрена не делает кроме пробрасывания вызовов одних функций в другие.

Придумать солидное название.

И главное, обозвать Enterprise Application Server. А лучше, Dynamic Enterprise Application Server. Или даже Cloud Dynamic Enterprise Application Server. И продать Ораклу. Думаю, это неплохая идея для стартапа.

Есть даже некоторые наброски исходников(это вторая версия кода, в первой были недостаточно длинные идентификаторы):

(let ((core (dserver.application.core.runtime:retrieve-instance
             'dserver.application.core:application-core)))
  (dserver.application.core.runtime:initialize-core
      core
     'dserver.application.core.runtime:application-runtime
     :multiple-use))

Достаточно ли солидно смотрится, как думаете?

При продаже Ораклу можно давить на то что у них совершенно устаревшие технологии, а у нас Dynamic Application Server, а не просто Application Server, которые уже не модны.