Re[14]: Бизнес-логика на Erlangе
От: FR  
Дата: 16.05.07 12:43
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

FR>>Согласен языки типа Scala или Nemerle вполне могут дать близкую к питону или руби скорость разработки.


АХ>Я думаю, что даже теоретически более быструю (хотя конечно многое зависит от самого разработчика), т.к. всякие Intellisense, рефакторинги, подсветка ошибок гораздо лучше работают в IDE для статически-типизированных языков. Ну и объем кода юнит-тестов поменьше будет.


Это да, но с другой стороны гибкость интерфейсов и обобщенность для динамики могут все это компенсировать, хотя согласен все зависит от проекта и разработчиков.
Re[4]: Бизнес-логика на Erlangе
От: Аноним  
Дата: 16.05.07 13:54
Оценка:
К>Кстати Ульф (вроде или Тоббе) говорил, что xmerl далеко не лучший парсер, у себя там они свой парсер юзают, правда публично он не доступен.

А не говорили чем он им не подходит?

ejabberd вроде по умолчанию expat использует, хотя и патч на xmerl есть
Re[9]: Бизнес-логика на Erlangе
От: Аноним  
Дата: 16.05.07 14:04
Оценка: :)
VD>а иделогия программно-изолированных процессов и общения между ними по средствам сообщений.
VD>Уверен, что подобный фрэймворк был бы кстати в любом языке и/или рантайме (например, Яве или дотнете).

Scala on Sails ? :D
Re[5]: Бизнес-логика на Erlangе
От: Курилка Россия http://kirya.narod.ru/
Дата: 16.05.07 14:14
Оценка:
Здравствуйте, Аноним, Вы писали:

К>>Кстати Ульф (вроде или Тоббе) говорил, что xmerl далеко не лучший парсер, у себя там они свой парсер юзают, правда публично он не доступен.


А>А не говорили чем он им не подходит?


Поищи на трапекзите.
Реально производительность не ахти.

А>ejabberd вроде по умолчанию expat использует, хотя и патч на xmerl есть

Про это он тоже упоминал вродь как.
Re[10]: Бизнес-логика на Erlangе
От: Аноним  
Дата: 16.05.07 14:18
Оценка: 11 (1)
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, eao197, Вы писали:


E>>Такая замена возможна не только для Хаскелля. Lazy Cjow Rhrr приводил как-то ссылку на аналогичную разработку для чистого C. Указанный тобой документ по Хасекеллю я не осилил, поэтому не могу судить, насколько там все удобно. А вот простота обновления для C и для Ruby как небо и земля.


D>Я думаю, что в C просто мало инструментов для монтирования высокоуровневых абстракций. В любом случае механизм действий один и тот же:


D>(1) ядро приложения заберает управление у старого динамического кода

D>(2) ядро приложения запоминает транзистентное состояние
D>(3) ядро приложения выгружает старый и подгружает новый динамический код
D>(4) управление и транзистентное состояние передаются новому коду в его точку входа

Не совсем так в Эрланге.

(1) ядро приложения подгружает новый динамический код. Старый тоже остается в памяти.
(2.1) Работающие функции приложения используют новые версии функций из модуля (там где можно)
(2.2) Работающие функции приложения используют старые версии функций из модуля (там где нельзя новые)

Случаи 2.1 от 2.2 должен явно отделить программист.

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

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

Сохранение данных облегчается тем что почти все данные передаются как аргументы функций.
Т.е. нет объектов, которые разрушаются, вместе с информацией в них.

Если бы понадобилось делать очередь сообщений — это был бы сервер-процесс-функция(или несколько связанных функций) и он незаметно перешел бы от старой версии себя-функции к новой.
Re[11]: Бизнес-логика на Erlangе
От: Курилка Россия http://kirya.narod.ru/
Дата: 16.05.07 14:28
Оценка:
Здравствуйте, Аноним, Вы писали:

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


По-моему (на практике не пробовал), вполне можно менять дофига раз без перезагрузки.
Суть в том, что у тебя время выполнения квантуется на периоды выполнения функций. Так вот старый модуль будет в памяти, пока функции, определённые в нём не завершатся. Вызов хвостовой рекурсии есть завершение функции (т.е. фактически получается "возвратом" из функции, правда в неё саму).
Re[12]: Бизнес-логика на Erlangе
От: gandalfgrey  
Дата: 16.05.07 14:56
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:

К>По-моему (на практике не пробовал), вполне можно менять дофига раз без перезагрузки.

К>Суть в том, что у тебя время выполнения квантуется на периоды выполнения функций. Так вот старый модуль будет в памяти, пока функции, определённые в нём не завершатся. Вызов хвостовой рекурсии есть завершение функции (т.е. фактически получается "возвратом" из функции, правда в неё саму).
Только хвостовой вызов должен быть нелокальным

loop(Accum)->
    receive
        Mess->
            Ac1=proceed_message(Mess,Accum),
            ?MODULE:loop(Ac1)
    end.

Как-то вот так
Re[12]: Бизнес-логика на Erlangе
От: Аноним  
Дата: 16.05.07 15:01
Оценка:
А>>Поэтому нельзя менять на лету код часто (пока не отцепился полностью старый код) и, вероятно, нельзя менять больше одного раза без перезагрузки.

К>По-моему (на практике не пробовал), вполне можно менять дофига раз без перезагрузки.

К>Суть в том, что у тебя время выполнения квантуется на периоды выполнения функций. Так вот старый модуль будет в памяти, пока функции, определённые в нём не завершатся. Вызов хвостовой рекурсии есть завершение функции (т.е. фактически получается "возвратом" из функции, правда в неё саму).

Если возможно определить когда все старые хвосты отрублены и потом отгрузить старый код — тогда конечно.
Но, ЕМНИП, в тезисах писалось что такого Эрланг не умеет (впрочем писались они давно, с тех пор вполне себе мог и научиться. Мне тогда сразу показалось странным такое явное ограничение полезной возможности).

Нe говоря уже о случае когда я запущу какой-то процесс, в котором по ошибке будет только краткий вызов функции. Такой процесс не отпустит старый код никогда и если я не смогу полуавтоматически его обнаружить и убить (частичный перезапуск) — то без перезапуска второй раз код обновить не смогу.
Re[13]: Бизнес-логика на Erlangе
От: gandalfgrey  
Дата: 17.05.07 10:10
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Нe говоря уже о случае когда я запущу какой-то процесс, в котором по ошибке будет только краткий вызов функции. Такой процесс не отпустит старый код никогда и если я не смогу полуавтоматически его обнаружить и убить (частичный перезапуск) — то без перезапуска второй раз код обновить не смогу.

Ну, должен же код знать, что его могут подменить ? Длинный вызов и создаст обновление. Можно ведь сделать и так :

loop(Data)->
    receive
        {data,Data1}->loop(proceed_data(Data,Data1));
        code_reboot->?MODULE:loop(Data)
    end.

Переход на новую версию кода произойдет по сообщению code_reboot
Можно просто прибить все устаревшие процессы ( с неактуальным кодом ) и запустить их по новой с новым кодом — в этом случае манагер, рулящий процессами, должен понимать, что надо обновить код
Re[14]: Бизнес-логика на Erlangе
От: Аноним  
Дата: 17.05.07 11:21
Оценка:
А>>Нe говоря уже о случае когда я запущу какой-то процесс, в котором по ошибке будет только краткий вызов функции. Такой процесс не отпустит старый код никогда и если я не смогу полуавтоматически его обнаружить и убить (частичный перезапуск) — то без перезапуска второй раз код обновить не смогу.
G>Ну, должен же код знать, что его могут подменить ? Длинный вызов и создаст обновление. Можно ведь сделать и так :

см. выделенное выше:

G>Можно просто прибить все устаревшие процессы ( с неактуальным кодом ) и запустить их по новой с новым кодом


Это практически невозможно сделать автоматически.
А руками — много гемора с большой вероятностью ошибки.
В общем проще будет весь сервер перегрузить
Re[10]: Бизнес-логика на Erlangе
От: Аноним  
Дата: 17.05.07 11:27
Оценка:
D>Я думаю, что в C просто мало инструментов для монтирования высокоуровневых абстракций. В любом случае механизм действий один и тот же:

D>(1) ядро приложения заберает управление у старого динамического кода

D>(2) ядро приложения запоминает транзистентное состояние
D>(3) ядро приложения выгружает старый и подгружает новый динамический код
D>(4) управление и транзистентное состояние передаются новому коду в его точку входа

Вообще говоря, мне кажется, в этой схеме типичная, азбучная ошибка.
Примерно то же самое делается в Mozilla и в Сталкере.
(а) стёрли старый файл.
(б) попытались создать и записать новый.
(в) а если не получилось — юзеру же хуже.


В вышеприведенной схеме напрашивается
(3.5) код большой, тянет кучу другого кода и грузится минут 5...
Или так:
(3.5) оказалось, что новый код загрузить невозможно.
(3.6) а если вдруг это было предусмотрено и попытались загрузить старый — тo тoже невозможно. Например файл с кодом был удалён перед обновлением (1-м пунктом).

Все-таки загрузка нового кода должна происходить до остановки старого. И только если эта загрузка успешна — можно останавливать старый.
Re[14]: Бизнес-логика на Erlangе
От: Gaperton http://gaperton.livejournal.com
Дата: 17.05.07 11:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>2. Объем и сложность системы не имеет прямой зависимости от ее надежности (устойчивости к сбоям). Надежность определяется проектными решениями и качеством тестирования. В том числе надежнаость увеличивается если при прочих равных использвут типобезопасный, статически-типизированный язык, так как это снижает требования по объему тестирования.


Не-а. Статически типизированный язык всего лишь позволяет такие ошибки несколько раньше обнаружить, что немного удешевляет их исправление. И все. Это никак не влияет на объем тестов — тебе в любом случае надо обеспечить хорошее тестовое покрытие. Хотя бы, чтобы весь твой код выполнялся под тестами (100% покрытия по метрике SLOC) — а это довольно слабое тестовое покрытие. При этом, даже при таком слабом покрытии — ошибки типизации такие тесты вылавливают на 99 и девять в периоде %.

Чему на самом деле пропорциональна надежность — так это
1) полноте тестового покрытия (никак не зависит от типизации). и
2) устойчивости программы к содержащимся в ней ошибкам. В целом, это тоже от типизации слабо зависит.
Re[15]: Бизнес-логика на Erlangе
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.05.07 15:06
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


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

G> И все. Это никак не влияет на объем тестов — тебе в любом случае надо обеспечить хорошее тестовое покрытие.


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

G>Чему на самом деле пропорциональна надежность — так это

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

Ну, что же. Хотя мы расходимся в частностях, но мы сходимся в главном. Утверждение о том, что только динамика может обеспечить надежность явно ложно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Бизнес-логика на Erlangе
От: IT Россия linq2db.com
Дата: 17.05.07 18:01
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого


Можно вопрос? А какими ещё средствами тебе приходилось пользоваться для построения надёжных систем и почему это не получалось?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Бизнес-логика на Erlangе
От: gandalfgrey  
Дата: 18.05.07 06:18
Оценка:
Здравствуйте, IT, Вы писали:

IT>Можно вопрос? А какими ещё средствами тебе приходилось пользоваться для построения надёжных систем и почему это не получалось?

Это не то чтобы не получалось, но ресурсы при этом были использованы совершенно другие. Большие системы до этого писал на С++ в смеси с Тиклем как скриптовым языком или клиентским кодом. Хаскель в свое время я принялся активно изучать, но чем дальше, тем больше у меня создавалось впечатление о нем как о языке для лабораторий, и в конце концов интерес к нему пропал. Окамл хорош, но людей для него найти весьма сложно, так как он представляет собой ( на мой взгляд ) смесь самых разнообразных концепций. Видимо, оттого народ в нем и путается.

Пример одной моей системы, работающей уже более 8 лет на самом крупном в мире предприятии по очистке и обогащению урана :
— 400 К строк, не считая сгенерированного PCCTS кода. С ним — около 1.1 М строк
— своя реалтаймовая СУБД
— С++ и несколько своих скриптовых языков
— сугубо распределенная
— работает и на ПервоПне
В нее вбухано более 20 человеколет. Это число достаточно велико, чтобы обьяснить, почему я считаю С++ малопригодным для построения чего-то более-менее сложного — это просто ОЧЕНЬ дорого обходится.

К Жабе примерялись, но существенного выигрыша тут все же нет.
Вот использование Ерланга и Тикля себя оправдало. Сейчас даже при желании от них невозможно отказаться — уж очень эффективно решаются проблемы с их помошью.
Более того, во многих других конторах, занимающихся аналогичными задачами, как-то стихийно наметился уклон в сторону языков с динамической типизацией.
Re[8]: Бизнес-логика на Erlangе
От: ironwit Украина  
Дата: 18.05.07 10:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>VladD2 wrote:


>> *Вообще-то это отход от темы и возраждение флэйма статика vs. динамика,

>> нуда выскажуст, раз уж всем так хочется снова пофлэймить .*
C>Да ну, это неинтересный флейм. Все ведь знают, что С++ — это самый
C>лучший язык
nemerle не путай )
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[9]: Бизнес-логика на Erlangе
От: Cyberax Марс  
Дата: 18.05.07 11:17
Оценка: :)))
ironwit wrote:
>> > *Вообще-то это отход от темы и возраждение флэйма статика vs. динамика,
>> > нуда выскажуст, раз уж всем так хочется снова пофлэймить .*
> C>Да ну, это неинтересный флейм. Все ведь знают, что С++ — это самый
> C>лучший язык
> nemerle не путай )
Так ведь флейма не получится. Как же флейм без VladD2 в качестве оппонента??
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[5]: Бизнес-логика на Erlangе
От: IT Россия linq2db.com
Дата: 18.05.07 13:15
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

IT>>Можно вопрос? А какими ещё средствами тебе приходилось пользоваться для построения надёжных систем и почему это не получалось?

G>Это не то чтобы не получалось, но ресурсы при этом были использованы совершенно другие. Большие системы до этого писал на С++ в смеси с Тиклем как скриптовым языком или клиентским кодом...
G>К Жабе примерялись, но существенного выигрыша тут все же нет.

Думаю, проблема скорее всего в C++. На нём действительно дорого делать надёжные вещи. То, что вы к джаве не примерялись, скорее всего просто что-то не сложилось.

G>Вот использование Ерланга и Тикля себя оправдало. Сейчас даже при желании от них невозможно отказаться — уж очень эффективно решаются проблемы с их помошью.


А что именно так сильно повлияло на мнение, что надёжнее уже не бывает? Должно же ведь быть какое-то объяснение.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Бизнес-логика на Erlangе
От: gandalfgrey  
Дата: 18.05.07 14:06
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Думаю, проблема скорее всего в C++. На нём действительно дорого делать надёжные вещи. То, что вы к джаве не примерялись, скорее всего просто что-то не сложилось.

Почему не примерялись ? Пробовали, но не пошло — так как с С++ разницы большой не увидели. ( для наших задач ). А сейчас я в этом мнении укрепился — уже приводил соотношение обьемов кода для достижения одинаковой функциональности

IT>А что именно так сильно повлияло на мнение, что надёжнее уже не бывает? Должно же ведь быть какое-то объяснение.

На самом деле — выбора практически нет. Для использования в критических отраслях — с чего я начинал — никто просто не позволит использовать платформу, не ставшую промышленной и без хороших примеров применения в critical mission. И что у нас остается ? С / С++. Жаба не для таких приложений все-таки. Эйфель. Ада...и Ерланг с Тиклем. Весь список, полагаю, будет меньше 10 наименований. Дополнительные факторы : на С++ дорого. Ада ОЧЕНЬ сложна. и так далее.
После такого отсева и остается то, что имеем и применяем. И опыт — как наш, так и чужой — говорит, что это вполне разумный выбор.

А "мнение, что надёжнее уже не бывает" — это, разумеется, не так. В наших условиях, с нашими человеческими, временными и финансовыми ресурсами это просто оптимальное решение. Ежели какая-то степень надежности достигнута, то ее всегда можно превзойти, хотя бы из математических соображений. Вопрос в том, какой ценой...
Re[7]: Бизнес-логика на Erlangе
От: IT Россия linq2db.com
Дата: 18.05.07 15:06
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

IT>>Думаю, проблема скорее всего в C++. На нём действительно дорого делать надёжные вещи. То, что вы к джаве не примерялись, скорее всего просто что-то не сложилось.

G>Почему не примерялись ? Пробовали, но не пошло — так как с С++ разницы большой не увидели. ( для наших задач ). А сейчас я в этом мнении укрепился — уже приводил соотношение обьемов кода для достижения одинаковой функциональности

Соотношения чего с чем?

IT>>А что именно так сильно повлияло на мнение, что надёжнее уже не бывает? Должно же ведь быть какое-то объяснение.

G>На самом деле — выбора практически нет. Для использования в критических отраслях — с чего я начинал — никто просто не позволит использовать платформу, не ставшую промышленной и без хороших примеров применения в critical mission.

Это всё здорово, но это лишь следствие и не имеет никакого отношения к определению надёжности. Мне же интересно понять почему код на динамических языках надёжнее. Например, мне понятно почему может быть ненадёжен код на C++. Но сравнивая динамику с той же джавой или C# я просто не могу понять за счёт чего Пока что я вижу только ссылки на опыт на на "нашу специфику". Но у нас у всех есть опыт и есть специфика и многим она говорит, что, обладая определёнными проблемами, динамика в серьёзных приложениях есть суксь. Так вот мне интересно прежде всего понять за счёт чего ваши решения выигрывают у статики, почему сложилось такое мнение, и так ли это на самом деле. Вполне возможно, что у вас выигрышь не за счёт динамики, а за счёт чего-то другого.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.