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

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

Ну если честно, то тут играет ещё эрлаговая ВМ, хотя можно ли её "отцепить" от языка — вопрос очень большой. Так вот, в ней заложено, что для любого модуля у нас может быть 2 копии — актуальная и та, которая выполняется в текущий момент (естественно, они могут совпадать). Естественно "серверная" функция модуля, которая вызывается рекурсивно, не должна менять свой интерфейс, хотя можно из неё сделать "stub", который бы трансформировал параметры и передал в новую функцию. Хотя, если честно сам такого не делал, за 100% точность не ручаюсь

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

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

Не надо только про С++. А то у тебя по жизни перекосы... рекламирушь Руби на фоне С++. На его фоне многое (ну, разве, что кроме скорости того же Руби) выглядит неплохо.

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

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

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

E>А по твоему софт для телефонии, для транспорта SMS/MMS, для обслуживания финансовых транзакций, для банкоматов, для мобильных телефонов, для управления двигателями и пр. тестируются только unit-тестами? Широко применяются тестовые и имитационные стенды,

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

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

Вот недавно у нас были проблемы с NNTP-сервером. Долго мучались пока установили причину проблем. И ведь никаких проблем с горчей замено кода не было. Сервер можно тупо перезапускать хоть раз в минуту.

Здравствуйте, deniok, Вы писали:
D>Достоинство Ruby и Erlang, как я понимаю, в том, что поддержка горячей замены является частью стандартного фреймворка.
В python-е для этого используется встроенная функция reload. Для динамических языков это похоже сильно проще реализуется.

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

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

Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить".
У меня есть немалый опыт средних и крупных проектов, отчего я и считаю, что статическая типизация для достижения РАВНОЙ с динамической типизацией надежности требует в РАЗЫ, а то и на порядок, больших временных затрат. Оно, конечно, потенциально возможно — но кто будет финансировать такую разработку ? Чай, не шаттлостроением занимаемся

А вот и примеры :

%  создает новый тупль по таблице имен и заполняет его полями
fill_record_flds(Recname,Flds) when is_atom(Recname) ->

% заполняет полями существующий тупль
fill_record_flds(Rec,Flds) when is_tuple(Rec)->

Кусочек очень простой, но он позволяет не держать в мозгу 2 РАЗНЫЕ функции, которые делают практически одно и тоже

Вот посложнее :

conv_val2(id,"0") -> 0;
conv_val2(id,0) -> 0;
conv_val2(id,[]) -> 0;
conv_val2(id,null) -> 0;
conv_val2(id,"HEAD") -> head;
conv_val2(id,Id1) when is_integer(Id1)->Id1;
conv_val2(id,Str)->
    case (catch io_lib:fread("~d~d",Str)) of
        {ok,[Id1,Id2],_} ->{Id1,Id2};
        _ ->
            {ok,[Id],_} = io_lib:fread("~d",Str),Id
    end;
conv_val2(text,Str)->Str;
conv_val2(int,Str) -> 
    case io_lib:fread("~d",Str) of
        {ok,[Num],_} -> Num;
        _ -> []
    end;

conv_val2(bool,Str)-> 
    {ok,[Num],[]} = io_lib:fread("~d",Str), Num=/=0;
    
conv_val2(hbool,Str) -> void;

conv_val2({ref_enum,Refid},Str) -> conv_val2(id,Str);

conv_val2({ref_entity,Refid},Str) -> conv_val2(id,Str);

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

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

[все поскипано]

Извини Влад, но все это явный влейм и оффтоп.

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

Была просьба.

а) Пояснить, что имелось в виду
б) Была просьба узнать мнение человека, который написал это
в) Была просьба не развивать флейм

Не лождавшись ответа автора ты начал его заранее охаивать:

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

Может, стоило подождать ответа автора?

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

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

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

G>Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить".
G>У меня есть немалый опыт средних и крупных проектов, отчего я и считаю, что статическая типизация для достижения РАВНОЙ с динамической типизацией надежности требует в РАЗЫ, а то и на порядок, больших временных затрат. Оно, конечно, потенциально возможно — но кто будет финансировать такую разработку ? Чай, не шаттлостроением занимаемся

<...прочитано и поскипано...>

Чесно говоря, так и не понял, что же здесь обеспечивает надежность?
Даже в очень нелюбимом многими C++, где типизация есть только на этапе компиляции, аналогичных эффектов можно достичь путем простой перегрузки функций или чуть более сложной специализации шаблонов. При этом компилятор будет брать на себя отлов ошибок типизации, которые в динамике требуют покрытия кода тестами. Так что баш на баш (по показанным примерам, по крайней мере). А если взять во внимание статически типизированные Scala и Nemerle, так там даже по синтаксическому оверхеду размер кода будет сопоставим.

Не раскрыта тема, однако

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

E>Чесно говоря, так и не понял, что же здесь обеспечивает надежность?

Пример слишком примитивный — тут я согласен.
Вот несколько более другой :

    {_,_,Flt}=get_fld_dict_ets(Recname),
    L1=mnesia:dirty_match_object(Basename,Rec),
    [X||X<-L1,Flt(X,Ctx)]

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

E>Не раскрыта тема, однако

Опасаюсь я бросать сюда большие или сложные куски — многое написано студентом, отчего код, мягко говоря, корявоват. Впрочем, попробую выскрести какие-то вразумительные обрывки.

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

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

G>Хотя — на кусках кода сложно передать причины моей убежденности в соотношении трудозатрат в написании систем с динамической и статической типизацией. Оная убежденность выросла в процессе построения и развития подобных систем ( эта — не первая, но самая сложная ). Другой пример — мои знакомые делают обвязку С++ софта тиклевыми скриптами для сложной обработки данных именно потому, что на С++ сделать это за разумные сроки совершенно нереально. Их С++ софт писался несколько лет. Обвязка на Тикле превосходит по сложности уже в несколько раз, и писалась несколько месяцев. Некая зависимость проглядывает, верно ?

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

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

PM>Пока из Ваших примеров видно, что статическая типизация С++ приносит много проблем, не обеспечивая должной надежности, с чем мало кто здесь будет спорить.

О том и речь ! Я не сравниваю со статической типизацией в Хаскеле — мне не нравится Хаскель, я на нем писал только маленькие примерчики, и не считаю себя достаточно компетентным для такового сравнения. Не сравниваю с Окамлом — найти / обучить людей ему несколько проблематично. Окамл, пожалуй, будет попроще, чем С++, но не так уж чтоб намного. Не сравниваю и с Сшарпом — ибо портабельность была и есть одним из основных требований. D ? Это просто гуманизированные ++. Жаба ? Я уже привел соотношение размеров кода — почти 2 порядка. По оценкам писателей этой системы, во многом за счет статической типизации в Жабе
Немерль ? Я пока не считаю его пригодным для промышленного использования.
Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?

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

E>>Чесно говоря, так и не понял, что же здесь обеспечивает надежность?

G>Пример слишком примитивный — тут я согласен.
G>Вот несколько более другой :
G>

G>    {_,_,Flt}=get_fld_dict_ets(Recname),
G>    L1=mnesia:dirty_match_object(Basename,Rec),
G>    [X||X<-L1,Flt(X,Ctx)]
G>

G>Лямбда Flt генерируется при старте сервера для каждого типа записей, чтоб при любом изменении внутренних структур данных и форматов записей в базе корректным образом доставать оттуда то, что заказано. Вся типизация ( динамическая, заметим) скрыта внутри. Это и есть пример достижения необходимой надежности

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

E>>Не раскрыта тема, однако

G>Опасаюсь я бросать сюда большие или сложные куски — многое написано студентом, отчего код, мягко говоря, корявоват. Впрочем, попробую выскрести какие-то вразумительные обрывки.

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

G>Хотя — на кусках кода сложно передать причины моей убежденности в соотношении трудозатрат в написании систем с динамической и статической типизацией. Оная убежденность выросла в процессе построения и развития подобных систем ( эта — не первая, но самая сложная ). Другой пример — мои знакомые делают обвязку С++ софта тиклевыми скриптами для сложной обработки данных именно потому, что на С++ сделать это за разумные сроки совершенно нереально. Их С++ софт писался несколько лет. Обвязка на Тикле превосходит по сложности уже в несколько раз, и писалась несколько месяцев. Некая зависимость проглядывает, верно ?

У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации. Действительно, C++ для сложной обработки данных сольет практически любому языку по объему кода, скорости его написания и времени на тестирования. Но все это имеет косвенное отношение к надежности.

Поскольку надежность -- это способности программы выполнять свою работу в граничных условиях, при получении некорректных данных, при исчерпании ресурсов, при возникновении непредвиденных ошибок. Здесь главную роль играет наличие стратегии обнаружения сбойных ситуаций и восстановления после них. Как это буржуины говорят: detect early, fail fast. Но и наличие стратегии не дает гарантий, поскольку как сама стратегия должна быть верифицированна, так и ее реализация -- проверена. Для чего нужно тестирование. И вот здесь есть очень тонкий момент: в статически-типизированных языках компилятор гарантирует хотя бы отсутствие элементарных синтаксических ошибок или ошибок типизации во всех фрагментах кода. Даже в тех, которые обрабатывают ошибки, возникающие раз в 10 лет при определенной фазе Луны (по прикидкам разработчика). Т.е. если такая ошибка возникнет и данный код пойдет на выполнение, есть хоть какая-то уверенность, что он не порушит всю систему неожиданным TypeMismatchError.

А вот в динамике такой уверенности нет вообще. Т.е. в динамике тестами должно быть покрыто 100% кода, даже того, который, по всем законам здравого смысла, даже исполняться не должен. А это означает гораздо больший объем тестирования, чем в случае со статически типизированными языками.

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

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

G>Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?

Object Pascal
Eiffel
Scala (если оставаться в рамках "Декларативного программирования"), хотя с учетом того, сколько багов фиксятся от релиза к релизу...

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

G>>Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?

E>Object Pascal
Мне это кажется несерьезным. Начиная с некоторого порога сложности системы начинается экспоненциальный рост сложности и обьема исходников.

E>Eiffel
Тут мне опять-таки сложно что-либо сказать. Последний раз на Эйфель я смотрел лет 5-6 назад...

E>Scala (если оставаться в рамках "Декларативного программирования"), хотя с учетом того, сколько багов фиксятся от релиза к релизу
Вот именно. Стабильной версии, я считаю нет

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

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

G>Можно было бы еще упомянуть AliceML, которая может быть статически типизирована...когда она заработает.

ML и "может"?
Хотя вот о промышленных применениях чтот его не слышно.
Но по сути интересная вещь, вроде как.

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

К>ML и "может"?
К>Хотя вот о промышленных применениях чтот его не слышно.
К>Но по сути интересная вещь, вроде как.
Это я к тому, что по описанию там как бы возможна и динамическая типизация. Оно же выросло из Mozart, как я понял из доки ?
А о промышленных применениях его думать рановато, как мне кажется — совсем сырое, аж капает.

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

G>Здравствуйте, Курилка, Вы писали:

К>>ML и "может"?
G>Это я к тому, что по описанию там как бы возможна и динамическая типизация. Оно же выросло из Mozart, как я понял из доки ?
это расширение Standard ML, на моцарте были первые версии, да и моцарт тоже статически-типизированный

G>А о промышленных применениях его думать рановато, как мне кажется — совсем сырое, аж капает.
Да не знаю, давно вроде уже вижу этот язык, но чисто с теор. точки зрения вечно рассматривают.
Хотя 2002, что последнее в новостях — это не сильно много конечно, хотя всёж 5 лет

G> Тут несколько раз поднимался вопрос о возможности и оправданности написания бизнес-логики на функциональных языках. Так что могу внести свою лепту в оное обсуждение. Распределенная система на Ерланге / Тикле, кою мы ваяли последние 1.5 года, начала продаваться. Пока только избранным покупателям, ибо еще есть разного рода сырости, но в течении месяца мы ее, полагаю, высушим.

После этого можно из Гендальфа Серого превращаться в Гендальфа Белого Потому что катарсис, point of no return и так далее

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

M>После этого можно из Гендальфа Серого превращаться в Гендальфа Белого Потому что катарсис, point of no return и так далее
Это не первая моя система на Ерланге, и далеко не первая распределенная. Просто раньше приходилось слишком много писать ручками из того, что Ерланг делает за меня.
Да и по сложности — бизнес-системы, пожалуй что, превосходят системы промышленной телеметрии...
Так что — рановато будет мутировать в другое состояние !

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

К>Да не знаю, давно вроде уже вижу этот язык, но чисто с теор. точки зрения вечно рассматривают.
К>Хотя 2002, что последнее в новостях — это не сильно много конечно, хотя всёж 5 лет
Гм. А вот на дату последней правки внимания просто не обратил...Уж не сдох ли проект ? Как я понимаю, Mozart и Oz существуют отдельно от Алисы до сих пор и помалу развиваются ?

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

G>Здравствуйте, Курилка, Вы писали:

К>>Да не знаю, давно вроде уже вижу этот язык, но чисто с теор. точки зрения вечно рассматривают.
К>>Хотя 2002, что последнее в новостях — это не сильно много конечно, хотя всёж 5 лет
G>Гм. А вот на дату последней правки внимания просто не обратил...Уж не сдох ли проект ? Как я понимаю, Mozart и Oz существуют отдельно от Алисы до сих пор и помалу развиваются ?
тьфу, тут я запарил, там 2002 — первая новость (т.е. последняя, если читать "с конца")
Последние этого года. (3 мая новую версию выкатили)
Oz — другой язык, поэтому он не может "вместе существовать", а mozart — runtime система для него.
Вот там чтот давно ничего не появлялось — год назад последний релиз был в июне прошлого года.
Да и активности тож какой-то не видать

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

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

При изменении структур данных ? Мне кажется, что убогая RTTI у ++ не позволит ничего подобного. Я же говорю о динамике типов — пока что в пределах сессии сервера, но никто не мешает нам сделать это в реалтайме. Все равно описания типов данных приходят извне.
Увеличение надежности здесь проявляется в том, что мы имеем всегда актуальный код для работы с разнородными данными, о котором НЕ надо заботиться : править его, переписывать...

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

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

E>У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации. Действительно, C++ для сложной обработки данных сольет практически любому языку по объему кода, скорости его написания и времени на тестирования. Но все это имеет косвенное отношение к надежности.

Это все взамосвязанные вещи. Написав одну и ту же функциональность в несколько раз быстрее, чем на С++/Жаба/что-то еще, мы можем потратить больше времени на реализацию механизмов самовосстановления, к примеру

E>Поскольку надежность -- это способности программы выполнять свою работу в граничных условиях, при получении некорректных данных, при исчерпании ресурсов, при возникновении непредвиденных ошибок. Здесь главную роль играет наличие стратегии обнаружения сбойных ситуаций и восстановления после них. Как это буржуины говорят: detect early, fail fast. Но и наличие стратегии не дает гарантий, поскольку как сама стратегия должна быть верифицированна, так и ее реализация -- проверена. Для чего нужно тестирование. И вот здесь есть очень тонкий момент: в статически-типизированных языках компилятор гарантирует хотя бы отсутствие элементарных синтаксических ошибок или ошибок типизации во всех фрагментах кода. Даже в тех, которые обрабатывают ошибки, возникающие раз в 10 лет при определенной фазе Луны (по прикидкам разработчика). Т.е. если такая ошибка возникнет и данный код пойдет на выполнение, есть хоть какая-то уверенность, что он не порушит всю систему неожиданным TypeMismatchError.

Ну, порушить всю систему у нас сможет разве что сбой питания...Все остальное обработается корректно. Максимум, что мы можем потерять — текущий запрос от одного клиента. И даже если допустить, что мы внесли грубую ошибку в код прокси запросов — мы потеряем текущую сессию с клиентом. Которая, впрочем, тут же начнет восстанавливаться ( выкачивать актуальные справочные данныые и т.д. ).

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

Этого совершенно не нужно ! Хорошо было бы иметь код, свободный от ошибок...Но я в это не верю, и к этому мы не стремимся. Нам нужен не безупречный код, а надежная работа сервера. А ведь это совсем разные вещи...Есть известный мануал "Построение надежных программных систем при наличии программных ошибок", в котором описываются многие принципы такого подхода.

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

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