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

G> Что понравилось в Ерланге :
G> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
Просьба ко всем не развязывать очередной флейм на эту тему.

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

G>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
EC>Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
EC>Просьба ко всем не развязывать очередной флейм на эту тему.

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

Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю удобным татику в хорошем языке в купе с хорошей IDE.

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

EC>>Просьба ко всем не развязывать очередной флейм на эту тему.

VD>А ты серьезно хочешь получить обоснование для этого, брошенного в реламном пылу, лозунга?
Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.

VD>Мужик просто заговорился. Со всеми бывает. Это конечно про то что касается надежных систем.
У тебя есть основания считать, что система получилась ненадёжной? или неверить ему?

VD>Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю удобным татику в хорошем языке в купе с хорошей IDE.
Именно. Мне со статической типизацией и хорошей IDE тоже как-то спокойнее и удобнее, но есть масса людей, которые делают полезные вещи другим способом. Вот мне как раз и интересно как они это делают на динамически типизированом языке.

P.S. Ты таки не удержался от флейма

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

EC>Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.

Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.

VD>>Мужик просто заговорился. Со всеми бывает. Это конечно про то что касается надежных систем.
EC>У тебя есть основания считать, что система получилась ненадёжной? или неверить ему?

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

Откровенно говоря даже не хочется обсуждать столь очевидный и столь же абсурдный вопрос.

VD>>Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю удобным татику в хорошем языке в купе с хорошей IDE.
EC>Именно. Мне со статической типизацией и хорошей IDE тоже как-то спокойнее и удобнее, но есть масса людей, которые делают полезные вещи другим способом. Вот мне как раз и интересно как они это делают на динамически типизированом языке.

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

EC>P.S. Ты таки не удержался от флейма

Где ты видишь флэйм? Бред он и есть бред. Осуждать тут нечго.

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

EC>>Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.

VD>Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.
Что фанатичного ты увидел в ней?

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

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

EC>>P.S. Ты таки не удержался от флейма

VD>Где ты видишь флэйм? Бред он и есть бред. Осуждать тут нечго.

В твоём посте нет никакой полезной информации по заданному вопросу, один ничем не аргументированный негатив.
Это даже хуже флейма.

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

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

EC>>Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.

VD>Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.

..а лечить по фото не пробовал? склонность заметна шутка.

Реклама или не реклама — это вопрос названия. Тут другое интересно. Этот эрланг оставляет у большинства исключительно положительные эмоции после практическиого применения.

VladD2 wrote:
> Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю
> удобным татику в хорошем языке в купе с хорошей IDE.
Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как
там можно жить без динамической типизации.

Хотя статические интерфейсы иногда там бы не помешали.

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

C>Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как
C>там можно жить без динамической типизации.

C>Хотя статические интерфейсы иногда там бы не помешали.

Ну по идее есть Dialyzer, который вводит некоторую долю статической проверки. А где именно ты видишь необходимость статических интерфесов?

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

G>> Что понравилось в Ерланге :
G>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
EC>Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
EC>Просьба ко всем не развязывать очередной флейм на эту тему.

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

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

Disclaimer. IIRC, 'надежность' -- это отдельное понятие, которое включает в себя много факторов. 'Доступность' является только одним из них. Поэтому вышесказанное не следует воспринимать как формулу 'надежность' == 'доступность'.

Курилка wrote:
> C>Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как
> C>там можно жить без динамической типизации.
> C>Хотя статические интерфейсы иногда там бы не помешали.
> Ну по идее есть Dialyzer
> <http://www.it.uu.se/research/group/hipe/dialyzer/&gt;, который вводит
> некоторую долю статической проверки.
Знаю, суперрулезная вещь.

> А где именно ты видишь необходимость статических интерфесов?
Как обычно — во взаимодействии с либами (внешними и внутренними). То
есть с кодом, который редко меняется и нечасто требует runtime-полиморфизма.

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

VD>>Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.
EC>Что фанатичного ты увидел в ней?

Оно настолько явно не соответствует действительности, что сказать его мог только фанатик уже не различающий где добро, а где зло. Это вера, а не знание.

VD>>У меня есть четкие доказательства, что это утверждение ложно, потому что на базе статически-типизированных языков создано много надежных систем.
EC>И есть доказательство, что на динамически-типизированных ничего сложного создать нельзя?

Этого и не нужно. Хотя мое лично мнение как раз заключается в том, что статика очень способствует созданию комлексных приложений, но в данном случае это не важно. Важно то, что даже если на динамике можно создавать сложные приложения (т.е. я не прав в этом аспекте) — это никак не вылияет на возожность создавать сложные приложения на статике. Understand?

Вообще это азы логики. Причем не какой-то там сложной матиматической, а примитивной человеческой логики. И мне казалось, что любой вменяемый человек должен это понимать.

Нет никакого смысла пускаться в обсуждение спорного вопроса вроде "можно ли создавать на динамике большие и надежные приложения", так как утверждение уже ошибочное. Насколько я знаю есть масса надежных приложений написанных вообще на С/С++ (т.е. не только на сквозь статически типизированных, но и очень небезопасных языках). Один этот факт опровергает это утверждение.

В общем, извини, но разжевывание логики уровня детсада мне не нинтересно. Если ты тоже фанатик или просто не умешь мыслить логически, то это не ко мне. Для меня бредовость этого утверждения очевидно. И не только для меня.

VD>>Откровенно говоря даже не хочется обсуждать столь очевидный и столь же абсурдный вопрос.
EC>Так к чему ты влез вообще, если по теме сказать нечего?

Меня откровенный бред всегда веселит. А когда его начинают защищать, раздражает.

EC>В твоём посте нет никакой полезной информации по заданному вопросу, один ничем не аргументированный негатив.

Нет. В моем сообщении как раз есть полезная информация. Информация для тех, кто пока что не может быстро отличить бред и рекламщину от фактов. Дело в том, что фанатики как раз и появляются под воздействием вот такой залихватской бредятины. Поверил человек (не опытный пока), что "да и не построить надежную систему без этого (динамики)", увлечется динамикой, приуспеет в этом, и начнет нести эту чушь уже на полном серьезе и совершенно не понимая, что несет чушь. А так он подумает и даже если займется динамикой, то уже будет рассуждать несколько более трезво.

EC>Это даже хуже флейма.

У меня другое мнение по этому поводу.

ЗЫ

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

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

K>..а лечить по фото не пробовал? склонность заметна шутка.

Тут и фото не нужно.

K>Реклама или не реклама — это вопрос названия. Тут другое интересно. Этот эрланг оставляет у большинства исключительно положительные эмоции после практическиого применения.

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

Уверен, что подобный фрэймворк был бы кстати в любом языке и/или рантайме (например, Яве или дотнете).

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

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

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

>> Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю
>> удобным татику в хорошем языке в купе с хорошей IDE.
C>Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как
C>там можно жить без динамической типизации.

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

Эрлэнг спроектирован как динамический язык. Понятно, что используя именно его вряд ли можно серьзно говорить о статике. Слишком много концепций языка завязано на его динамиченсоть. Те же атомы просто немыслимы в статически-типизированном языке.

Однако самое интересно, что есть в Эрлэнге, на мой взгляд, — это программно-изолированные процессы и общение между ними по средствам сообщений. Ничего не напоминает? Правильно — Сингулярити . А Сингулярити основана на вполне статически типизированном дотнете (точнее клоне) и C# (точнее его клоне Sing#). Просто язык и рантайм расширили поддержкой нужных концепций. В итоге получилось очень похожее решение. Само по себе наличие подобной реализации говорит о том, что динамика не является обязательным ктитерием для использования подобного подхода.

C>Хотя статические интерфейсы иногда там бы не помешали.

Да без разницы. Это меня мало интересует. Эрлэнг не очень подходит лично для меня, так как я (как, кстати, и ты) люблю периодически заняться разными, довольно низкоуровневыми, вещами которые требуют высокой производительности от кода. Да и ошибаться по мелочи (очепятыватся) я люблю. Плюс я люблю хороший интелисенс. Так что мой путь однозначно статика. Понимаю, что есть люди которым динамика ближе. Но это не повод чтобы нести откровенную чушь. Я же не заявляю, что без статики нельзя создать надежную программу? Конечно можно. Хотя я считаю, что для больших систем хорошая статическая типизация — это отличное подспорье.

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

E>Так вот, одним из отличительных качеств таких динамически-типизированных языков, как Erlang и Ruby является горячая замена кода.

Начнем с того, что это не так. То же ASP.NET хотя и основано на статически-типизированном фрэймворке, но обеспечивает горячую замену кода.

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

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

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

Не факт. Во-перых, кто определяет эту существнность? Скажем если сайт не будет виден 10 секунд, то это вряд ли кто-то даже заметит. Или если и заметит, то не придаст этому значения. А вот баг вылезший на этом сайте может остановить его работу на неопределенный промежуток времени. Ну, а пропустить баг в динамической системе все же проще. Так что тут все решают конеретные уловия.

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

E>Disclaimer. IIRC, 'надежность' -- это отдельное понятие, которое включает в себя много факторов. 'Доступность' является только одним из них. Поэтому вышесказанное не следует воспринимать как формулу 'надежность' == 'доступность'.

Само собой. Кстати, самый надежный двигатель — это выключенный двигатель, обмазанный солидолом, гермитично упакованный и зартый глубого под семлю.

VladD2 wrote:
>> > Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю
>> > удобным татику в хорошем языке в купе с хорошей IDE.
> C>Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как
> C>там можно жить без динамической типизации.
> *Вообще-то это отход от темы и возраждение флэйма статика vs. динамика,
> нуда выскажуст, раз уж всем так хочется снова пофлэймить .*
Да ну, это неинтересный флейм. Все ведь знают, что С++ — это самый
лучший язык

> Эрлэнг спроектирован как динамический язык. Понятно, что используя
> именно его вряд ли можно серьзно говорить о статике. Слишком много
> концепций языка завязано на его динамиченсоть. Те же атомы просто
> немыслимы в статически-типизированном языке.
Атомы-то как раз можно представить в статике, только вот смысла от них
будет намного меньше.

> Однако самое интересно, что есть в Эрлэнге, на мой взгляд, — это
> программно-изолированные процессы и общение между ними по средствам
> сообщений. Ничего не напоминает? Правильно — Сингулярити.
В Сингулярити оно, по тому отчету, намного менее проработано. Примерно
так же можно сказать, что обмен сообщений в Эрланге напоминает оконные
очереди сообщений в WinAPI

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

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

Хотя в Эрланге есть еще интересные вещи — типа модификации кода "на
лету", их уже намного сложнее повторить в статике. Я уже прикидывал как
— получается слишком сложно для реализации. Тут у динамики явное
преимущество.

Хотя для меня динамическая замена кода (за рамками edit&continue) не так
важна.

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

E>>Так вот, одним из отличительных качеств таких динамически-типизированных языков, как Erlang и Ruby является горячая замена кода.

VD>Начнем с того, что это не так. То же ASP.NET хотя и основано на статически-типизированном фрэймворке, но обеспечивает горячую замену кода.

JSP под управлением, например, Resin-а в свое время так же позволяла менять JSP-странички на лету. Ручная загрузка-выгрузка DLL с ручным использованием GetProcAddress так же позволяет организовать горячую замену кода в C++. Только замена замене рознь. Ruby и, как я понимаю, Erlang, позволяют заменять код без потери transient-данных в ОП.

Например, у меня был случай, когда из-за ошибки в коде один из unsigned int счетчиков при декрементировании перешел через 0 и принял слишком большое значение. Из-за чего входящие запросы накапливались в очередях, но не обрабатывались, т.к. данный счетчик не давал их обрабатывать. В результате очередь распухла и запросы из нее выбрасывались при истечении тайм-аута транзакции.

Горячая замена кода в C++ (через загрузку/выгрузку DLL) привела к полной потере заявок из очереди, т.к. сама очередь перестала существовать. А вот горячая замена кода в Ruby просто изменила бы значение счетчика и фрагмент кода, который к этой ситуации привел. Вся очередь заявок при этом бы никуда не исчезла.

VD>По практие скажу, что сама по себе горячая замена кода еще не обеспечивает бесбойность работы софта. Всегда есть шанс, что заливаемый на сервер код содержит ошибки не выловленные "в лабороторных условиях".

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

VD>Лично я считаю, что самый большой вред доступности лично нашего сайта приносят именно ошибки, а не что-то иное. Проблема в том, что под нагрузкой все работает совсем не так как без нее. Юнит-тестами такие проблемы не ловятся. Приходится пробовать на живом сервере. А это уже напрямую влияет на его доступности.

А по твоему софт для телефонии, для транспорта SMS/MMS, для обслуживания финансовых транзакций, для банкоматов, для мобильных телефонов, для управления двигателями и пр. тестируются только unit-тестами? Широко применяются тестовые и имитационные стенды, на которых системы подвергают гораздо большим нагрузкам, чем они испытывают в реальной эксплуатации. Иногда объемы кода для этих стендов сравниваются по объему, если не превышают, объемы кода самой проверяемой системы. При тестировании систем массового обслуживания, например, SMS шлюза, возникает отдельная задача анализа корректности полученных в результате тестовых прогонов результатов. Скажем, трафик в 200 sms/s за десять секунд наргузочного тестирования нагенерирует столько информации в логах и базах данных, что выявить в них тонкие аномалии вручную составляет сложную задачу.

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

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

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

E>>>Так вот, одним из отличительных качеств таких динамически-типизированных языков, как Erlang и Ruby является горячая замена кода.

VD>>Начнем с того, что это не так. То же ASP.NET хотя и основано на статически-типизированном фрэймворке, но обеспечивает горячую замену кода.

E>JSP под управлением, например, Resin-а в свое время так же позволяла менять JSP-странички на лету. Ручная загрузка-выгрузка DLL с ручным использованием GetProcAddress так же позволяет организовать горячую замену кода в C++. Только замена замене рознь. Ruby и, как я понимаю, Erlang, позволяют заменять код без потери transient-данных в ОП.

Я вот только не понимаю — почему утверждается, что без динамической типизации замена без потери транзистентных данных невозможна. Для Хаскелла, например, поддержка такой модели реализована, см. Dynamic Applications From the Ground Up. Достоинство Ruby и Erlang, как я понимаю, в том, что поддержка горячей замены является частью стандартного фреймворка.

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

E>>JSP под управлением, например, Resin-а в свое время так же позволяла менять JSP-странички на лету. Ручная загрузка-выгрузка DLL с ручным использованием GetProcAddress так же позволяет организовать горячую замену кода в C++. Только замена замене рознь. Ruby и, как я понимаю, Erlang, позволяют заменять код без потери transient-данных в ОП.

D>Я вот только не понимаю — почему утверждается, что без динамической типизации замена без потери транзистентных данных невозможна. Для Хаскелла, например, поддержка такой модели реализована, см. Dynamic Applications From the Ground Up. Достоинство Ruby и Erlang, как я понимаю, в том, что поддержка горячей замены является частью стандартного фреймворка.

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

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

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

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

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

Ясно, что динамически подключаемый код должен уметь развёртываться и начинать работать над любым валидным транзистентным состоянием. В случае Хаскелла это уже скомпилированая динамическая библиотека, точка входа которой умеет принимать это состояние.

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

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

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

Вот-вот, все это нужно предусматривать в ядре приложения. Или пользоваться специальными инстументами, которые делают это за программиста.

Динамически-типизированный Ruby сам по себе является таким инструментом.
Думаю, что с Erlang ситация такая же.