Scheme будет разделён на два языка программирования

> многопроцесорность просасывает?

В Эрланге всё взаимодействие на message passing основано. В плане масштабируемости на процы и хосты все остальные языки сосут, не вставая на колени.

> В плане масштабируемости на процы и хосты все остальные языки сосут, не вставая на колени.

хосты -- да. но процы? эрланг -- вм и все потоки у него псевдо. как он заграбастает многопроцовость?

Почитай про Эрланг.

hint: на каждый проц свои runqueue и шедуллер.

> В Эрланге всё взаимодействие на message passing основано. В плане масштабируемости на процы и хосты все остальные языки сосут, не вставая на колени.

Ну глупость же. Ничто не мешает использовать message passing хоть в Си. А вот асинхронность эрлангового message passing - это принципиальная проблема.

> Ну глупость же. Ничто не мешает использовать message passing хоть в Си.

Да можно хоть компостером на перфокартах напробивать MP, но в Эрланге это всё равно в стотыщраз проще.

Конечно можно и на С MPI использовать и многопоточность, но я насмотрелся таких решений. Получалось так себе: race conditions, deadlocks это наше все. Конечно можно сказать, что де "писать надо лучше". Конечно надо, но где взять столько грамотных специалистов с богатым multithread бэкграундом, чтобы хорошо писалось. В Erlang есть итересные фичи, которые можно и в С поиметь, но это большая работа! Тысячи LOC'ов. А сколько багов там будет... А получится все равно что-то а ля Erlang :).

> А вот асинхронность эрлангового message passing - это принципиальная проблема.

Не вижу в этом большой проблемы. Хочешь синхронно да пожалуйста, на Erlang'e это сделать просто как мычание. Вот если бы все было синхронно это была бы большая проблема.

P.S. Да и вообще какая разница Erlang не Erlang, если это кому-то помогает зарабатывать деньги то весь этот thread > /dev/null

>>> В Эрланге всё взаимодействие на message passing основано. В плане масштабируемости на процы и хосты все остальные языки сосут, не вставая на колени.

>> Ну глупость же. Ничто не мешает использовать message passing хоть в Си.

> Да можно хоть компостером на перфокартах напробивать MP,

М прикинь, масштабироваться это будет не хуже Эрланга :D

> но в Эрланге это всё равно в стотыщраз проще.

Речь вроде о масштабируемости шла.

>> А вот асинхронность эрлангового message passing - это принципиальная проблема.

> Не вижу в этом большой проблемы. Хочешь синхронно да пожалуйста, на Erlang'e это сделать просто как мычание.

И как?

> Вот если бы все было синхронно это была бы большая проблема.

Скажи это Хоару.

> Да и вообще какая разница Erlang не Erlang, если это кому-то помогает зарабатывать деньги то весь этот thread > /dev/null

Если бы ты и правда так считал, не ответил бы.

>> но в Эрланге это всё равно в стотыщраз проще.

>Речь вроде о масштабируемости шла.

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

> Типичная стрелковская демагогия

Ты за MOP ответь %)

> инфраструктура может быть написана только постфактум

Ы. А чем тебе тот же Эрланг не инфраструктура? %) "Телекоммуникационный фреймворк со встроенным языком программирования" (с) anonymous@LOR

>> Типичная стрелковская демагогия

>Ты за MOP ответь %)

А что с MOP не так? Там все упирается в то что для статической типизации в распределенной среде весь зависимый код должен рекурсивно перекомпилироваться на всех узлах при появлении нового типа на одном из узлов. Это я уже писал раньше в каком-то динамическом сраче.

>> инфраструктура может быть написана только постфактум

>А чем тебе тот же Эрланг не инфраструктура

Наверно надо все же мыслить реалистично и стремиться к соотношению вида 80-20 или даже 90-10 между тем что обеспечивает сам язык и его библиотеки и тем чего в языке нет и должно быть написано.

> А что с MOP не так?

С MOP всё так. Ты объясни вот это:

> А чтобы гонять сериализованные формы нужен MOP. И собственно этот MOP исключает возможность сделать язык статически типированным.

...причем оба тезиса.

> для статической типизации в распределенной среде весь зависимый код должен рекурсивно перекомпилироваться на всех узлах при появлении нового типа на одном из узлов

Бред. Для любого типа, имеющегося в протоколе - да. И что? Это всегда так (за исключением откровенно бредовых и редких случаев, когда по сети передается исполняемый код для обработки новых типов пакетов).

>>А чем тебе тот же Эрланг не инфраструктура

>Наверно надо все же мыслить реалистично и стремиться к соотношению вида 80-20 или даже 90-10 между тем что обеспечивает сам язык и его библиотеки и тем чего в языке нет и должно быть написано.

Ичо? Где четкая разница между языком и библиотекой, и в чем она с точки зрения прикладника?

>> для статической типизации в распределенной среде весь зависимый код должен рекурсивно перекомпилироваться на всех узлах при появлении нового типа на одном из узлов

>Бред. Для любого типа, имеющегося в протоколе - да.

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

>Это всегда так

Это почти всегда не так. Я бы даже усилил это утверждение в стиле законов Мерфи: версия протокола у клиента и сервера вообще *не может* быть одинаковой. Допустим, синхронизации протоколов мешает Дъявол или энтропия Вселенной.

>Где четкая разница между языком и библиотекой, и в чем она с точки зрения прикладника?

Хорошие библиотеки обычно пишутся в наиболее естественным для языка стиле. Те которые пытаются переделать язык плохо стыкуются с имеющимся массивом кода и отсеиваются.

> вообще все типы должны являться частью протокола.

> версия протокола у клиента и сервера вообще *не может* быть одинаковой.

По этой части вопросов больше нет %)

Так что насчет MOP?

>Так что насчет MOP?

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

> Если система типов у языка статическая то при наличии параметризованных типов надо компилировать код в рантайме чтобы создать инстанс какого-то типа полученного из MOP.

Ты средствами MOP собираешься новые типы создавать? Если да, то зачем? И в чем проблема запустить компилятор в рантайме? Ява постоянно это делает :)

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

Слова вроде все понятны, а смысл - нифига.

>> Если система типов у языка статическая то при наличии параметризованных типов надо компилировать код в рантайме чтобы создать инстанс какого-то типа полученного из MOP.

>Ты средствами MOP собираешься новые типы создавать? Если да, то зачем?

Да потому что любая попытка выделить и поддерживать какую-то общую библиотеку типов для всех узлов в распределенной системе обречена на провал. Классический Dependency Hell.

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

>Слова вроде все понятны, а смысл - нифига.

Характерно для состыковки кода написанного разными программистами. Полный комплект типов вида "Account", "Address" на каждый бакэнд, и каждый надо поддерживать.

>>> Если система типов у языка статическая то при наличии параметризованных типов надо компилировать код в рантайме чтобы создать инстанс какого-то типа полученного из MOP.

>> Ты средствами MOP собираешься новые типы создавать? Если да, то зачем?

> Да потому что любая попытка выделить и поддерживать какую-то общую библиотеку типов для всех узлов в распределенной системе обречена на провал.

_Этот_ вопрос уже закрыли. Если ты хочешь использовать все типы программы в сетевых пакетах, то я тебе не доктор.

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

>>Слова вроде все понятны, а смысл - нифига.

>Характерно для состыковки кода написанного разными программистами. Полный комплект типов вида "Account", "Address" на каждый бакэнд, и каждый надо поддерживать.

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

>Если ты хочешь использовать все типы программы в сетевых пакетах, то я тебе не доктор.

А это и есть фича эрланга - любой кусок можно отколоть и повесить на отдельный хост в любой момент. Либо на несколько хостов через балансировщик нагрузки.

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

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

>> Если ты хочешь использовать все типы программы в сетевых пакетах, то я тебе не доктор.

> А это и есть фича эрланга - любой кусок можно отколоть и повесить на отдельный хост в любой момент.

Доо... и все остальные хосты, на которых он _не_ висит, тоже автоматом обучатся новому протоколу.

>Скажи это Хоару.

скажи это разработчикам, реализующим MOST

>Если бы ты и правда так считал, не ответил бы.

как считал-то? что Erlang помогает зарабатывать деньги? :)

>> Да можно хоть компостером на перфокартах напробивать MP,

>М прикинь, масштабироваться это будет не хуже Эрланга :D

Скорость обмена перфокартами будет постоянно падать к концу рабочего дня, а в обеденное время вообще прекращаться. Плюс на four nines отрицательно будут влиять больничные, декретные, ПМС, etc...