Тут несколько раз поднимался вопрос о возможности и оправданности написания бизнес-логики на функциональных языках. Так что могу внести свою лепту в оное обсуждение. Распределенная система на Ерланге / Тикле, кою мы ваяли последние 1.5 года, начала продаваться. Пока только избранным покупателям, ибо еще есть разного рода сырости, но в течении месяца мы ее, полагаю, высушим.
Кратко о самой системе : ядро системы + логическая обвязка ( бизнес-правила ). Сам движок остается неизменным для всех областей применения, меняется только обвязка. Нынешняя обвязка предназначена для использования в паспортных столах любых муниципальных образований.
Пока что параметры системы таковы :
Сервер :
— чистый ерланг и Мнезия
— около 5К строк серверного кода ( движок правил, прокси и т.д ). Сгенерированный код для парсеров / лексеров правил сюда, понятно, не включается.
— около 10К строк бизнес-логики
— работает с очень даже приемлемой скоростью на гниловатом железе ( Целерон-3, 800 мгц)
Клиент :
— Тикль + чуть-чуть С++
— около 8К строк занимает фреймворк собственной выделки
— около 26К строк — формочки и бизнес-логика
— около 800 строк на С++ ( BOOST )
— может работать на Пне-2
Системы с меньшей функциональностью на жабе ( по оценкам изготовителей
этих систем ) занимают свыше 600 К строк. Сейчас с ними связался — говорят, что по функциональности сравнялись, но обьем кода вырос до 1200 К строк.
Здравствуйте, VladD2, Вы писали:
VD>С тем же бочком — это выливается в керамический клапан, меньшие допуски при изготовлении, в попловок засунутый в трубку, а стло быть не дающий перекосов и вседа движущийся в одном направлении.
VD>Вот точно так же статическая типизация и море проверок компилятора приводят к усложнению компилятора, но так как они нацелены на более раннее и более полное выявление ошибок, то они способствуют повышению качества.
Спасибо! Наконец-то для меня причинно-следсвенная связь между плохими компиляторами и унитазами очевидна!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Ну, в природе можно найти множество доказавших свою надежность систем написанных на самых разных языках. Опыт Ericsson-а в телекоме, конечно, показателен. Но далеко не всем приходится заниматься телекомом. Поэтому и интересно понять, будет ли удешевление от использования Erlang-а в других условиях. И если будет, то за счет чего.
Ну, для этого надо понять, почему есть удешевление разработки в телекоме.
По результатам анализа кода телекоммуникационных приложений и типичных ошибок в них, при разработке языка была поставлена задача:
1) Сократить объем и сложность типичного телекоммуникационного кода.
2) Убрать из языка потенциально опасные свойства, которые приводят к ошибкам в телеком-приложениях.
В результате
1) В Эрланге отсутствуют конструкции и языковые средства имеющие слабопредсказуемое время выполнения. Так как телекомовские системы должны иметь хорошую реактивность — характеристика soft-realtime. Это свойство не повредит вообще любой интерактивной системе. К примеру, в Эрланге нет ленивых вычислений.
2) Цыклов в эрланге нет, так как рекурсия на списках более надежна, чем цыклы с индексами. Минус еще один класс ошибок.
3) Нет явного управления памятью — минус еще один класс ошибок.
4) Простая и понятная модель параллелизма — телекомоские задачи содержает его много. А теперь, с переходом на многоядерные процессоры, речь идет далеко и не только о телекоме и серверах. Конструкция receive и mailbox-ы сообщений в том виде, в котором она есть в Эрланге (selective receive построенная на сопоставлении с образцом), сокращает код и делает его более понятным, так как не требуется описывать все варианты последовательностей, в которых приходят сообщения. Отсутствие разделяемых данных — устраняет класс ошибок. Легковесные процессы — устраняют архитектурные ошибки, позволяют проектировать параллельные сервисы прямолинейным образом.
5) Надежность. Это то, что в Эрланге сделано великолепно — лучше всех. Телекомоские приложения (да и не только — любые промышленные системы) должны быть устойчивы к ошибкам, которые в них содержаться. Потому, код обнаружения и корректной обработки ошибок занимает в них значительный объем, распылен по логике, и затрудняет ее понимание. Ну, типа, вы открываете файл, потом пишете в него, делаете еще некторые действия, и на каждом этапе может возникнуть ошибка, которую надо обнаружить, корректно обработать, и корректно вернуть управление наверх. Падать нельзя. Знакомая проблема? Что сделано в Эрланге:
— код обработки ошибок всегда строго отделен от кода, который выполняет логику.
— код обнаружения ошибок отсутствует вовсе. Let it crash — при ошибке должно все упасть, и чем раньше, тем лучше. Т.е. прикладная логика у вас выглядит просто и прозрачно — она не замутнена этим дурацким кодом.
— Процессы полностью изолированы — один процесс никак другому не повредит, и они умеют мониторить друг друга.
Именно это свойство дает значительную экономию по объему кода в телеком-приложениях. Обработка ошибок в Эрланге сделана не хорошо — она волшебна. А именно наличием кода обработки ошибок и реакцией на ошибки индустриальные приложения и отличаются от академических и учебных. Наши лучшие плюсовики млеют от того, насколько воздушно делается обработка ошибок на Эрланге — индустриальная разработка лишается половины своего геморроя, превращаясь в легкую прогулку (ну, почти).
6) Распределенность. Когда вы проектируете приложение — оно изначально параллельно, и требует минимум модификаций при запуске на кластере машин. Неплохо для серверов, и совершенно необходимо для обеспечения отказоустойчивости.
7) Горячие обновления кода на живой системе. Систему 24х7 останавливать нельзя, патч надо уметь накатывать на работающую систему. Это важно для серверов.
Отсюда видно, что для серверных приложений Эрланг весьма неплох. И, с появлением внятных инталляторов и графических библиотек, должен теоретически быть неплох на клиенте.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Не-а. Статически типизированный язык всего лишь позволяет такие ошибки несколько раньше обнаружить, что немного удешевляет их исправление.
VD>Более раннее выявление ошибко значительно удешевляет их исправление. Но тут речь о том, что они выявляются автоматически и в обязательном порядке. То есть весь класс выявляемых ошибок попросу устраняется.
Это так. Только ответ на вопрос — как это скажется на всем сроке разработки не так однозначен. Чтобы ответить на него, надо знать, каком процент ошибок типизации к прочим ошибкам — раз, и среднее время исправления ошибки типизации против ошибок прочих классов — два. Не собирая подробных метрик ответить на ти вопросы невозможно, это три. Но можно дать экспертные заключения.
К примеру, алгоритмические ошибки и ошибки управления ресурсами обходятся существенно дороже — они занимают примерно от 15 мин до двух часов, в среднем — около получаса на исправление. Простыми тестами они не ловятся. Ошибки типизации ловятся простейшими тестами, и их исправление (обыкновенно такие ошибки — что-то вроде опечаток) обходится в минуты. По моему опыту так. И замедление разработки от динамики в результате получается незначительное — в рамках погрешности измерения. Я его не замечаю. Однако, эти статистики очень индивидуальны.
То есть, класс ошибок-то устраняется, но это не тот класс и не тех ошибок, которые по серьезному делают погоду. От сборки мусора в том смысле толку на порядок больше — устраняется класс более геморройных и сложных в обнаружении ошибок. Я бы сказал так — динамический язык со сборкой мусора будет безопаснее и продуктивнее, чем строготипизированный С++ с ручным управлением памятью.
Подтвердить или опровергнуть все это объективно может только сбор метрик с реальных проектов, как по статике, так и по динамике. У меня есть только данные по метрикам Эрикссона — где они говорят о том, что плотность ошибок сильно-шибко пропорциональна строкам исходного кода, и не зависит от вида типизации. Они не выявили значимых отклонений в плотностях ошибок в зависимости от вида типизации. Связанно это, в частности, с относительно небольшой количественной долей и ценой исправления ошибок типизации на фоне других ошибок.
G>> И все. Это никак не влияет на объем тестов — тебе в любом случае надо обеспечить хорошее тестовое покрытие.
VD>Влияет. Я могу пологаться на более высокоуровневые тесты и на меньший их обхем.
Твои тесты должны обеспечить хотя бы то, что каждая строчка написанного тобой кода будет ими вызвана — независимо от типа типизации. Иначе это не тесты, а говно — у тебя ни разу не тестированный код в релиз попадет. Так вот, такие тесты выловят 99% ошибок типизации — эти ошибки имеют воспроизводимость 100%, хитрые сценарии для их ловли не нужны. Так что я не вполне понимаю, как именно статика позволит тебе уменьшить объем тестов.
VD>А скажем для рефакторинга мне вообще тесты не нужны будут.
Агащаз. Доказывать функциональную эквивалентность нового и старого кода (что он после твоего рефакторинга делает то же самое, что и раньше) кто будет без тестов? Пушкин?
VD>Более того его можно будет автоматизировать). Ведь мы знаем все о коде еще до его запускат. Значит мы может менять его соблядая при этом инваринт.
Если бы мы действительно знали о коде все, до того, как мы его запустим, то тогда конечно да. Только знание типов гораздо ближе к "почти ничего".
G>>Чему на самом деле пропорциональна надежность — так это G>>1) полноте тестового покрытия (никак не зависит от типизации). и G>>2) устойчивости программы к содержащимся в ней ошибкам. В целом, это тоже от типизации слабо зависит.
VD>Ну, что же. Хотя мы расходимся в частностях, но мы сходимся в главном. Утверждение о том, что только динамика может обеспечить надежность явно ложно.
Знаешь Влад, меня в последнее время больше заботит не то, что человек сказал, а то — зачем он это сказал. Человек сказал, что ему кажется, что динамика помогает ему писать надежный код. Ему так сильно это кажется, что он не представляет, как это можно вообще без динамики. Ну, сразу видно, сгоряча сказал, и наверняка сам это понял. И все заметили, и все поняли, что характерно. А ты сразу шашку наголо, и в атаку .
Вопрос — является ли сказанная им фраза абсолютной истиной — меня не волнует совершенно. Есть вещи более важные и более интересные. Мне интересно, с чем же он таким столкнулся в разработке, что пришел к настолько убежденной и нестандартной позиции. Это наверняка что-то интересное — и это не так просто объяснить. Тут бы человеку наводящими вопросами помочь, чтобы объяснил.
А ты вместо этого цепляешься к словам, и пытаешься всем доказать и так очевидные для всех вещи. Зачем? К тебе точно так же можно докопаться, и доказать, что с формальной точки зрения ты несешь чушь. Да к любому можно так докопаться — рано или поздно скажет что-нибудь неоднозначное. Думаешь, ты мало таких вещей говоришь?
G> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
Просьба ко всем не развязывать очередной флейм на эту тему.
Была просьба.
а) Пояснить, что имелось в виду
б) Была просьба узнать мнение человека, который написал это
в) Была просьба не развивать флейм
Не лождавшись ответа автора ты начал его заранее охаивать:
А ты серьезно хочешь получить обоснование для этого, брошенного в реламном пылу, лозунга?
Мужик просто заговорился. Со всеми бывает. Это конечно про то что касается надежных систем.
Здравствуйте, EvilChild, Вы писали:
G>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого EC>Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить".
У меня есть немалый опыт средних и крупных проектов, отчего я и считаю, что статическая типизация для достижения РАВНОЙ с динамической типизацией надежности требует в РАЗЫ, а то и на порядок, больших временных затрат. Оно, конечно, потенциально возможно — но кто будет финансировать такую разработку ? Чай, не шаттлостроением занимаемся
А вот и примеры :
% создает новый тупль по таблице имен и заполняет его полями
fill_record_flds(Recname,Flds) when is_atom(Recname) ->
% заполняет полями существующий тупль
fill_record_flds(Rec,Flds) when is_tuple(Rec)->
Кусочек очень простой, но он позволяет не держать в мозгу 2 РАЗНЫЕ функции, которые делают практически одно и тоже
Здравствуйте, Gaperton, Вы писали:
G>Не порадуешь дизайн-документом, описывающим общую архитектуру?
Вот бы он еще был, этот документ, в собранном виде.... Сейчас архитектура описывается кучей бумажек, каждая из которых состоит из призывов, лозунгов и запретов, и в целом похожа на речи Геббельса. Типа, "Вы сами хотели тотальной войны !" (с)
То-есть везде разбросаны мааааленькие кусочки того, как надо делать, как не надо делать, и какие принципы должны соблюдаться. Например, правила обработки ошибок для бизнес-логики :
— ежели набор входных данных формально правилен, но не соотвествует реально хранимым данным, то это обрабатывает бизнес-логика
— во всех остальных случаях запрос от клиента ДОЛЖЕН скончаться в муках, а клиентская прокся это обработает сама
Или отложенная обработка правил в соответствии с моделью :
— с каждой итерацией множество отложенных правил сужается
— не обрабатывать это специальным образом, ибо если это не так, то это ошибка предметной модели, и сервер все равно сделает лог все этого при издыхании соединения с клиентом
Собрать все в одну кучку надо....но ручонки не доходят совершенно
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, EvilChild, Вы писали:
G>>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого EC>>Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
G>Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить". G>У меня есть немалый опыт средних и крупных проектов, отчего я и считаю, что статическая типизация для достижения РАВНОЙ с динамической типизацией надежности требует в РАЗЫ, а то и на порядок, больших временных затрат. Оно, конечно, потенциально возможно — но кто будет финансировать такую разработку ? Чай, не шаттлостроением занимаемся
<...прочитано и поскипано...>
Чесно говоря, так и не понял, что же здесь обеспечивает надежность?
Даже в очень нелюбимом многими C++, где типизация есть только на этапе компиляции, аналогичных эффектов можно достичь путем простой перегрузки функций или чуть более сложной специализации шаблонов. При этом компилятор будет брать на себя отлов ошибок типизации, которые в динамике требуют покрытия кода тестами. Так что баш на баш (по показанным примерам, по крайней мере). А если взять во внимание статически типизированные Scala и Nemerle, так там даже по синтаксическому оверхеду размер кода будет сопоставим.
Не раскрыта тема, однако
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
G>Хотя — на кусках кода сложно передать причины моей убежденности в соотношении трудозатрат в написании систем с динамической и статической типизацией. Оная убежденность выросла в процессе построения и развития подобных систем ( эта — не первая, но самая сложная ). Другой пример — мои знакомые делают обвязку С++ софта тиклевыми скриптами для сложной обработки данных именно потому, что на С++ сделать это за разумные сроки совершенно нереально. Их С++ софт писался несколько лет. Обвязка на Тикле превосходит по сложности уже в несколько раз, и писалась несколько месяцев. Некая зависимость проглядывает, верно ?
Пока из Ваших примеров видно, что статическая типизация С++ приносит много проблем, не обеспечивая должной надежности, с чем мало кто здесь будет спорить.
Здравствуйте, Klapaucius, Вы писали:
K>...и все это чтобы доказать недоказуемое утверждение о том, что "чем проще — тем надежнее".
Кстати, вспомнил один пример хорошо демонстрирующий, что это утверждение не верно по крайней мере в некоторых случаях.
Между прочим этот пример есть почти у всех нас дома — это сливной бачок унитаза .
Советская консрукция механизма налива воды в бачок очень проста. Это поплавок на длинной ножке который воткнут в некий штифт. На втором его конце резиновая прокладка. При заполнении водой бачка он поднимается и пережимает наливное отверсие.
Казалось бы конструкция настолько проста, что должна быть надежна как скала.
Но вот почему-то она постоянно ломается. Средний срок "наработки на отказ" год. Через полгода — год (ну, масимум, два) она выходит из строя.
Несколько более сложная кострукция с трубой работает намного надежнее. Еще более сложные констркции работают вообще так, что например, у меня дома я вообще не заглядывал в бачок унитаза (и сантехник тоже) с тех времен как его поставили в 1995-ом году (т.е., мама дорогая, вот уже 12 лет! Самому страшо подумать ).
Я понимаю причины этого. Простота решения приводит к использованию весма ненадежных конструкционных решений. Там и шпилька из медного сплава вставленная в пласмассовое или латунное ушко которая тупо перетирается или перетирает ушко. Там и резированя прокладка которая изнашивается. Там и люфты с перекосамии усиливающие износ первых перечисленных элементов. И многое другое.
Исправить эти недостатки можно. Но любое исправление приводит к существенному усложнению конструкции.
Так что тезис "чем проще — тем надженее" явно верен далеко не всегда.
Вот с термином что "выбирать нужно самое простое решение при прочих равных" я соглашусь незадумываясь. Только вот прочие не всегда бывают равными.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, Gaperton, Вы писали:
G>>Этот переход возможен только в случае, если у тебя время обработки каждого запроса предсказуемо и постоянно. Это простой случай, тут думать практически не надо. Только жизнь сложная штука, там далеко не всегда бывает так. Например, серверу CQG приходится иметь дело с запросами, время выполнения которых непредсказуемо, и колеблется в широком биапазоне от очень быстрых до крайне медленных. Одновременно серверу приходится отвечать на множество запросов с моментальной реакцией, и прокачивать через себя кучу обновлений по открытым соединениям в реальном времени с минимальной задержкой. Периодически бывают ситуации пиковой нагрузки (ферма серверов балансирует нагрузку или отрабатывает сбой, перекидывая пользователей с сервера на сервер), при которой все должно работать так же, как обычно.
EC>А имеет смысл писать сервер аналогичный CQG'шному на erlang? Если да, то в чём будет выигрыш и проигрыш? Если можно с примерными количественными оценками.
Плюсов можно достичь таких:
1) Хорошую реактивность — с этим много неприятных багов было. В решении на Эрланге таких багов должно быть меньше.
2) Отличную масштабируемость — можно спроектировать так, чтобы решение кластеризовалось. На С++ это сделать тяжело.
3) И просто классную, небо и земля по сравнению с текущим сервером — отказоустойчивость и отработку ошибок. Шутка ли — крэш по одному из клиентов не влияет на остальных. Это означает резкое сокращение количества ошибок, вызывающих крэш и соотвественно отказ сервиса всем клиентам, и понижение приоритета таких ошибок. Мэйнтененс вздохнет свободнее.
4) Также, удалось бы сократить цикл исправления ошибок в сервере — это очень классно. Можно на живой системе отлаживаться, патчи накатывать, и смотреть, что получается — жутко удобно.
5) Динамический язык — означает легкость логгирования и анализа креш-дампов — подсистема мониторинга и логгирования будет очень удобна без особых на это затрат.
Минусы такие:
Проектировать надо совсем по другому, не так как на С++/Java — в Эрланге довольно необычный подход к проектированию, и свои грабли, которые надо знать и обходить. А сервер настолько сложен (из-за большого количества всяких обязательных к реализации мелочей и неочевидных юзкейсов), что его чрезвычайно тяжело спроектировать и на обычных ОО языках. При проектировании предстоит решить много архитектурных и алгоритмических проблем — например, временная синхронизация, или обработка временных рядов с переменной временной шкалой. Грубо говоря, я не знаю, и не могу заранее знать, с какими проблемами я столкнусь, затеяв переписывание его на Erlang (очевидно, без вставок на С++ будет не обойтись — чувствую. Однако где они будут — хоть примерно? Have no fuckin idea). Я не могу оценить трудозатраты. Для этого надо иметь очень большой опыт.
Резюмируя — я бы стартовал пилотный проект с парой людей, чтобы они пописали прототипов. И посмотрел, что получается.
Вот в институтах есть хороший классификатор проектов по степени риска, чтоли. НИР (научно исследователские работы — результат — отчеты канают), и ОКР (опытно-конструкторские работы — это обычный инженерный проект, конкретную штуковину проектируют для полезных применений), и НИОКР (это и то и то сразу — результат — прототипы, опытные образцы, но ни о каком production-качестве речь не идет).
Так вот, я бы стартовал на эту тему НИОКР. Цель которого — выявить оптимальные архитектурные подходы и свойства решений сервера на базе Erlang, результат — работающий прототип + отчет с исследованиями его свойств и выводами. А по результатам — решил, надо ли переписвать сервер или нет.
Здравствуйте, EvilChild, Вы писали:
G>> Что понравилось в Ерланге : G>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого EC>Можно об отквоченном попродробнее применительно к вашему проекту с примерами? EC>Просьба ко всем не развязывать очередной флейм на эту тему.
Не в качестве флейма, но для освещения одного из аспектов данной темы. Доступность (availability) является одним из факторов надежности. Т.е., чем проще обеспечить постоянную работу системы без запланированных/незапланированных остановок, тем лучше.
Так вот, одним из отличительных качеств таких динамически-типизированных языков, как Erlang и Ruby является горячая замена кода. Т.е. возможность не только накатить патчи для исправления багов, но и существенно модифицировать уже работающую программу без останова оной существенно повышает уровень доступности системы. А значит благоприятно сказывается на надежности системы.
Disclaimer. IIRC, 'надежность' -- это отдельное понятие, которое включает в себя много факторов. 'Доступность' является только одним из них. Поэтому вышесказанное не следует воспринимать как формулу 'надежность' == 'доступность'.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>На этот счет есть и прямо противоположное мнение. В динамическом языке любая функция — это generic-функция, она полиморфна. Что уменьшает связность системы и количество усилий по рефакторингу.
VD>Она не просто полиморфна. Она случайно полиморфна. Возможно в некоторых ситуациях этот полимпофизм будет ошибкой.
Да, он обязательно будет ошибкой в некоторых ситуациях. Точь в точь как плюсовая шаблонная функция. Но отсюда и гибкость — не надо ломать голову над иерархией интерфейсов и классов. Проще проектировать — меньше ошибок дизайна, более оббобщенный и слабосвязный код, менее хрупкий дизайн, более дешевые правки. Вот каких плюсов можно получить.
Минусы тоже понятны — легко запутаться в том, чего же именно требует полиморфная функция от своих аргументов. Таким образом — шею свернуть при такой гибкости тоже можно. По хорошему — надо бы иметь опциональную возможность указывать это в описании аргумента — либо интерфейс, либо прям имена функций. И с паттерн-матчингом совместить. Например, так (синтаксис воображаемый):
func( x : { init/1, call/2, fuck_off/4 }, y : { method1/2, method2/4 } )
Или так:
arg_requirement = { init/1, call/2, fuck_off/4 }
func( x : arg_requirement, y : { method1/2, method2/4 } , z )
Что означает — аргумент х является объектом, у которого определены методы init с одним аргументом, call с двумя, и fuck_off с четырьмя.
Типы аргументов, замечу, мы не указываем — у нас насквозь динамический язык. Только их количество является частю сигнатуры (как в Эрланге).
Смотри — язык получается объектный и динамический, однако проблема, на которую ты указал (а это реально весьма неприятная проблема) здесь остро не стоит — компилятор нам во многих проблемных случаях по рукам надает без ущерба для динамики и полиморфизма. Вот на таком объектном динамическом языке я бы пописал с удовольствием (чо не добавят такое в какой-нить популярный язык — не понимаю). Тем более, до паттерн-матчинга остался один шажок. Кажется, это называется duck typing?
Здравствуйте, gandalfgrey, Вы писали:
[cut] G> ВотЬ !
А можно какие-нибудь комментарии по поводу того — что понравилось в эрланге, на какие грабли наступали. Что использовали кроме мнезии, скажем eUnit пользовали?
Здравствуйте, eao197, Вы писали:
E>Вот gandalfgrey говорит, что с 1994 по 2002 он принимал участие в разработке серьезной системы для предприятия по переработке урана. На C++. А вы бы решились сейчас вести такую разработку на Mono? Ну т.е. прямо сейчас, даже с учетом того, что первый год-полтора будет полностью посвящен проектированию, моделированию и прототипированию.
Я, кажется, понимаю, о чем Вы. Да, должен признать, что у меня, как участника этой дискуссии, два фатальных недостатка:
1) Я не разрабатывал серьезную систему для предприятия по переработке урана на С++.
2) Я не разрабатывал систему для паспортных столов на Erlang.
Не смотря на все это, я, вслед за Марком Твеном, оставляю за собой право судить о яичнице, хотя и не снес ни одного яйца.
Впрочем, это не имеет к сути вопроса никакого отношения.
Дело вот в чем: gandalfgrey сначала утверждает, что использовать "непереносимые средства"(sic!) согласно его опыту, вообще нельзя. Это уже достаточно сильное, вплоть до абсурдности, утверждение, что характерно. Gandalfgrey вообще склонен к таким сильным утверждениям — и хотя это простительная слабость — посмеяться над ней я все равно считаю возможным. На самом деле переносимость ради переносимости не нужна и даже может оказаться вредной, потому что, и это очевидно, кроссплатформенность требует дополнительных затрат при разработке, даже если используется "переносимое средство".
Дальше gandalfgrey делает следующее утверждение о некроссплатформенности CLI, которое просто является фактически неверным. Впрочем, это может быть просто терминологический спор, потому что он, как выяснилось, разделяет средства не просто на переносимые и непереносимые (идиосинкразические?), но еще и подразделяет непереносимые на НЕПОЛНОЦЕННО переносимые и НЕНОРМАЛЬНО переносимые. Или что-то вроде того. Пока не будет внесено достаточно ясности в эту туманную классификацию, эту линию продолжать нет никакой возможности.
Вы, в свою очередь, не можете не понимать, хотя и можете притворяться, что это не так, что переводом дискуссии в плоскость ядерной энергетики только поднимаете градус абсурдности в этой теме.
На самом деле, кросплатформенность и некросплатформенность CLI никак не зависит от того, решусь ли я вести разработку на Mono системы для предприятия по переработке урана, точно также как и (не)возможность выполнить мертвую петлю на вертолете Lynx не определяется тем, решусь ли я ее выполнить (точнее попытаться ее выполнить), не так ли?
P.S. Сразу говорю, что выполнить мертвую петлю на Lynx можно, а написать hard realtime систему на Mono нельзя, но к кроссплатформенности CLI это не имеет никакого отношения.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
VD>>>Его (Моно) качество ничем не хуже нежели скажем Питона, Руби или GCC. Отдельные, редкие глюки несомненно встречаются, но пользоваться им можно без проблем. E>>На основании чего сделан такой вывод? K>А на основании чего может быть сделан обратный вывод? У Вас есть данные о бесспорном превосходстве Ruby над Mono в этом аспекте? Это было бы интересно.
Логика проста если посмотреть на конкурентов:
* Ruby/Python — основная реализация открыта и может быть портирована при необходимости, планирование фич производится авторами, все основные библиотеки открыты и теоретически чисты в плане патентов.
* Java — основная реализация стала GPL, поддерживается Sun и IBM. Открытый (с определенными оговорками) механизм внесения изменений в платформу. Официальная переносимость (правда на ограниченном кол-ве систем) всей платформы (а не только байткода), и при этом проверенная временем с кучей решений на все случаи жизни (и эти решения в подавляющем большинстве случаев разрабатываются с учетом кроссплатформенности).
Чем из этого может похвастаться mono? Переносимость между самим собой (т.е. mono рантайма) — да. Но
— фреймворк, который по сути сплошной реверсинжиниринг (для примера посмотри на wine и подумай, будешь ли ты подобное использовать в продакшене)
— фреймворк вечно догоняющий и не имеющий никакого влияния на основную ветку
— несовместим с основной веткой от MS (точнее есть нехилый зазор между поддерживаемыми фичами) и часть фич принципиально отсутсвует, например CAS
— возможные проблема с патентами
— большинство готовых решений пишутся под ОС Windows и работа их под mono абсолютно не гарантированна
— mono-develop нельзя и близко сравнить не то что с Intellij Idea / Reshaper, но и с чистым Visual Studio
Мне лично этого выше крыше хватает чтобы не рассматривать mono как серьезную платформу. Гораздо проще взять python/ruby или jvm.
Здравствуйте, eao197, Вы писали:
E>Вспоминая эту шутку и ваши данные о том, что 15Kloc Erlang + 34Kloc Tcl + 800loc C++ равны по функциональности 1.2Mloc Java я вот не могу понять: в 1.2Mloc Java можно было впихнуть свой собственный run-time Erlang-а и необходимые библиотеки для него. После чего написать те же самые 15Kloc...
Это вопрос не ко мне, а к разработчикам оной системы на Жабе, которые любезно предоставили мне данные о своем проекте. Можно было, в конце концов, просто связать Жаву и Ерланг, благо в OTP Erlang для этого есть куча жабьих классов.
E>Не оставляют меня сомнения, что дело вовсе не в языке программирования.
Не только в нем, конечно же. Но и в нем тоже. А вот процентное соотношение влияния язык / языконезависимой архитектуры — это вопрос сакральный.
E>Не хило, однако. Т.е. сама прикладная программа, используй вы только готовое системное ПО и ПО промежуточного слоя, была бы в два раза меньше и, соответственно, в два раза дешевле.
К сожалению, ничего готового, удовлетворяющего нашим требованиям, просто не было. Или же мы не нашли...
E>Если не секрет, что подвигло на написание собственной СУБД, слоя поддержки распределенности и менеджера событий? E>Казалось бы, крупнейшее в мире предприятие в своей отрасли, могло бы и раскошелиться на готовые инструменты.
Ну, они были нашими заказчиками...И их не устраивало то, что уже существовало тогда, причем по многим критериям : быстродействие, реактивность, надежность, масштабируемость и т.д. Кроме того, многое из буржуйского софта просто нельзя использовать по причинам оборонным. СУБД была обьектной ( отдавала наружу экземпляры обьектов ) и ОЧЕНЬ устойчивой к повреждениям — то-есть восстановление просто не требовалось. Распределенность организовывалась громоздким и тяжелым способом — внутри сервера, конечно. Снаружи достаточно было добавить еще один сервер в таблицу маршрутов, чтобы между ними забегали требуемые обьекты . Менеджер событий поддерживал кучу типов событий — системные, временные, скриптовые, конфигурационные и т.д.
То, что получилось, нормально работало с 30 К обьектов (не полей) в реалтайме на Первопне — требование этого тоже было. Аналогичного софта ( продаваемого за деньги ) тогда не было, да и сейчас не видно.
E>Если система была запущена в 99-м, а разрабатываться начала, как минимум, в 98-м, то альтернативы C++ в то время нужно было еще поискать. Та же Java была совсем другой, на первом пне тормозила безбожно.
Системя была запущена в 97, а начало разработки — примерно 94 год. Где-то до 2002 продолжала доводиться. Тогда уже можно было поискать что-то более другое
Здравствуйте, gandalfgrey, Вы писали:
E>>То, что Flt генерируется при старте и затем в динамике выбирается версия, подходящая для определенных типов параметов, говорит лишь об удобстве ее использования и снижения трудозатрат на ее реализацию. В том же C++ можно делать аналогичные вещи, только они будут больше по объему. А вот степень надежности того и другого -- вопрос открытый.
G>При изменении структур данных ? Мне кажется, что убогая RTTI у ++ не позволит ничего подобного. Я же говорю о динамике типов — пока что в пределах сессии сервера, но никто не мешает нам сделать это в реалтайме. Все равно описания типов данных приходят извне.
Не очень понял, что понимается под изменением структуры данных.
Что до C++, то я сам делал реализацию фабрики объектов, которая использовала тип данных параметра метода create для определения типа создаваемого объекта. Причем типы объектов автоматически регистрировались в данной фабрике вместе с нужными им типами параметра во время работы программы. Что позволяло иметь разные наборы типов в фабрике при ручной загрузке/выгрузке DLL. И все это средствами штатного RTTI.
Нужно ли говорить, что существуют языки, та же Java, в которой при помощи рефлексии можно еще и не то делать.
G>Увеличение надежности здесь проявляется в том, что мы имеем всегда актуальный код для работы с разнородными данными, о котором НЕ надо заботиться : править его, переписывать...
Давайте разговаривать серьезно, все-таки.
Нельзя передать в программу объект совершенно произвольного типа и дожным образом его обработать. В программе должен быть код, который знает, что это за тип и что с ним делать. Соответственно этот код нужно править и переписывать.
Другое дело, что динамика легко позволяет во время работы системы догружать недостающие и просто новые фрагменты кода. Об этом здесь говорили.
E>>Я не думаю, что для подтверждения вашего тезиса о большей надежности динамически-типизированных программ над статически типизированными вообще нужно приводить фрагменты кода. Имхо, проще словами перечислить те факторы, которые по вашему мнению повышают надежность.
G>Динамическая типизация подразумевает возможность обработки прихода значений левого типа, и не на уровне исключений, а в рядовой логике функций.
Опять же, если в функции есть код, который знает, что делать с левым типом, то этот тип уже не левый. А поиметь такой код вполне можно динамической загрузкой кода в статически-типизированных языках.
E>>У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации. Действительно, C++ для сложной обработки данных сольет практически любому языку по объему кода, скорости его написания и времени на тестирования. Но все это имеет косвенное отношение к надежности.
G>Это все взамосвязанные вещи. Написав одну и ту же функциональность в несколько раз быстрее, чем на С++/Жаба/что-то еще, мы можем потратить больше времени на реализацию механизмов самовосстановления, к примеру
Я же и сказал, косвенное. На скорость разработки и на освобождение времени для других целей (в том числе и повышения надежности) влияет и множество других факторов: начиная от квалификации разработчика и имеющихся в наличии инструментов, заканчивая температурой воздуха в комнате в следствие нормальной/ненормальной работы кондиционера (или отсутствия оного).
Здесь найдутся несколько человек, которые совершенно серьезно будут утверждать, что Java+IDEA или C#+ReSharper позволяют им писать на статически-типизированном языке гораздо быстрее, чем на динамически-типизированном. И нет оснований им не верить. Так же как есть несколько человек, которые не менее серьезно будут говорить, что Ruby+VIM или Erlang+Emacs позволяют им писать быстрее, чем на статически типизированном языке. Люди таки разные.
Но к надежности, имхо, это не имеет прямого отношения. Гораздо важнее, является ли используемый язык сильно-типизированным или нет. Скажем отсутствие проблемы повисших указателей или прохода по чужой памяти может сделать программу на Ruby надежнее, чем C++. Но это отнюдь не аргумент в пользу надежности из-за динамики, т.к. Java или C# являются не менее сильно-типизированными.
G>Ну, порушить всю систему у нас сможет разве что сбой питания...Все остальное обработается корректно. Максимум, что мы можем потерять — текущий запрос от одного клиента. И даже если допустить, что мы внесли грубую ошибку в код прокси запросов — мы потеряем текущую сессию с клиентом. Которая, впрочем, тут же начнет восстанавливаться ( выкачивать актуальные справочные данныые и т.д. ).
Рад, что вы настолько уверенны в своей системе.
Хотя, основываясь на своем скромном опыте, мне это кажется в большей степени рекламным слоганом, ну или попыткой самоубеждения
E>>Так вот лично меня интересует ваше мнение по поводу того, как динамическая типизация обеспечивает большую надежность (именно в смысле сохранения программой работоспособности в непредвиденных условиях)?
G>Я бы выразился в том смысле, что это экспириенс, и не только мой личный, но и кучки знакомых разработчиков, которые используют языки с динамической типизацией для повышения надежности и живучести систем. Выделить какие-то формальные факторы, которые однозначно дают положительный эффект, я просто затрудняюсь — разве что их комплекс, причем разный для разных языков : для Ерланга один набор факторов, для Тикля другой и т.д.
У меня все сказанное вами оставляет впечатление, что вы говорите о большей надежности по сравнению с C++.
Тогда более правильно вести разговор о преимуществах сильной типизации (не важно, статической ли или динамической) перед слабой типизацией.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Alex EXO, Вы писали:
AE>Здравствуйте, Mirrorer, Вы писали:
M>>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ?
AE>"Элементарно Ватсон..."
AE>Поскольку в Erlang нет глобальных переменных, то при перемиеновании переменной за пределами функции ничего искать не надо. При переименовании функции, тоже все обычно, как везде (даже проще, поскольку функции не экспортированные явно, локальны в пределах модуля).
AE>Да и нет там особой необходимости в рефакторинге переименования, именно в силу локальности имен.
На мой взгляд эта "проблема" — переименования переменных, вообще не является проблемой. У меня при разработке на переименование уходило не более половины процента времени разработки. И мне плевать, насколько хорошо подобный "рефакторинг" поддерживается тулзами. Надо будет — сделаю поиском-заменой.
Настоящий рефакторинг, как его знаю я — это глубокое изменение структуры кода без изменения функциональности, возможно — изменение дизайна, с целью подготовки старого кода к масштабному добавлению новой функциональности (или устранения "гнезда" ошибок). Здесь никакие тулзы не помогут — все равно regression-тестами надо накрывать.
Вот такой рефакторинг — головная боль и источник ошибок. А эти средсва ускорения работы машинисток, гордо называемые "рефакторинг" — детские игрушки. Смешно это в качестве плюса-минуса языка и платформы рассматривать.
Здравствуйте, gandalfgrey, Вы писали:
G> Что понравилось в Ерланге : G> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
Просьба ко всем не развязывать очередной флейм на эту тему.
до более разумных. Понятие "надежность" потихоничку подменяется понятием "скорость разработки". Делается связь между надежностью исстемы и скоростью ее разработки. Тут уже есть о чем спорить. А исходная фраз — абстурд.
Ну вот. В том-то все и дело. "Неосторожно брошенные слова".
M>>
G>>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
M>>Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
А ты серьезно хочешь получить обоснование для этого, брошенного в реламном пылу, лозунга?
Мужик просто заговорился. Со всеми бывает. Это конечно про то что касается надежных систем.
Флейм? Флейм.
А дальше головы полетели направо и налево:
EC>Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.
Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.
Причем тут фанатичность или хоть какой-то намек на логику таких осуждений (особенно в рамках просьбы к гандальфу), не понятно
И дальше топик скатился вообще непонятно куда (опять же к обсуждению статики и динамики). А казалось бы. Достаточно было дождаться ответа автора
Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить".
Все. И дальше можно обсуждать все, что угодно, применительно к проекту, создаваемому небольшим количеством человек, сложности и т.д. и т.п.
Хотя, например, не дождавшись ответа, eao197 осветил
то, что, как ему показалось, мог подразумевать gandalfgray. Причем информация там интересная. О таком аспекте я и не думал даже.
Более того, простой ответ в таком стиле:
Хм. Довольно спорное утверждение. Мой опыт показывает, что статика не только позволяет, но и помогает строить надежные системы. Быть может, автор это высказал в пылу спора или это как-то связано с его опытом в его проекте
А можно было ничего не писать Нетикет великая вещь (правда, сразу скажу, я сам не всегда ему следую)
Здравствуйте, VladD2, Вы писали:
EC>>И есть доказательство, что на динамически-типизированных ничего сложного создать нельзя?
VD>Важно то, что даже если на динамике можно создавать сложные приложения (т.е. я не прав в этом аспекте) — это никак не вылияет на возожность создавать сложные приложения на статике. Understand?
Это ты сейчас с кем споришь? Кто утверждал, что на статике создавать сложные приложения нельзя?
VD>Вообще это азы логики. Причем не какой-то там сложной матиматической, а примитивной человеческой логики. И мне казалось, что любой вменяемый человек должен это понимать.
После предыдущего пассажа это звучит особенно убедительно.
VD>В общем, извини, но разжевывание логики уровня детсада мне не нинтересно. Если ты тоже фанатик или просто не умешь мыслить логически, то это не ко мне. Для меня бредовость этого утверждения очевидно. И не только для меня.
Мощно.
Попробуй читать сообщение, на которое отвечаешь — сэкономишь кучу времени себе и другим подписчикам форума.
Я там вопрос задал максимально точно, зная любителей пофлеймить, причём человек его понял в отличие от...
ironwit wrote: >> > *Вообще-то это отход от темы и возраждение флэйма статика vs. динамика, >> > нуда выскажуст, раз уж всем так хочется снова пофлэймить .* > C>Да ну, это неинтересный флейм. Все ведь знают, что С++ — это самый > C>лучший язык > nemerle не путай )
Так ведь флейма не получится. Как же флейм без VladD2 в качестве оппонента??
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, aka50, Вы писали:
A>>>В статически типизированном языке не нужно проверять все комбинации вызовов функций f1 и f2 со всеми возможными классами C и D ... В динамике нужно. (допустим C и D это "стратегии", которые проверяются отдельно и потом могут комбинироваться в рантайме).
G>>Плюсовик завел бы шаблонну функцию и гордо заявил, что занимается generic programming, как завещал сам Степанов. В С++ компилятор поймет, что реализации init у аргумента нет, и даст по рукам. A>Заметь, в компайл тайм и без необходимости писать какие-то тесты...
Да. Но тесты тебе все равно придется писать, и эти тесты отловят тебе и ошибки типизации. Разница эффективно небольшая.
G>>Все, что надо сделать нам — это написать тест, вызывающий каждую строчку, где стоит вызов функций f1 и f2.. A>Нифига себе , а если это происходит в динамике. Каким образом будем проверять aCundDundExtensionsList.each {|i| f1(i)}? Да и получается что таки тест нужен... в С++ (и других статик языках) это будет проверено компилятором.
Что "нифига себе"? Тебя удивляет, что код надо хотя бы раз вызвать, чтобы он считался мало-мальски оттестированным? Или что?
Что именно у тебя будет проверено компилятором в статике? У тебя цикл — тебе хоть в статике, хоть в динамике для ловли функуиональных ошибок нужно для циклов минимум три теста — пустой список, список из одного элемента, список из нескольких элементов. Как ты не поймешь — тебе придется код накрыть тестами независимо от вида типизации, если твой код не наколенная поделка. Аргументы в духе "а я свой код не тестирую, мне компилятор ошибки ловит" — означает, что у тебя в коде на самом деле дофига ошибок (ошибки типизации это примерно 5-10% от всех ошибок). Можно конечно радоваться, что ошибок типизации там нет, это конечно очень круто, но дела не меняет.
A>А проблемы я могу себе создать и в Java например вызывая метод init через рефлекшн. Но я не буду "стрелять себе в ногу" а просто заведу интерфейс IFunInitAllowed и привет (в scala можно в принципе даже тип функции завести). Когда надо будет переименовать (или еще как порефакторить) — просто переименую руками и получу class should implement bla bla... в компайл тайм.
Ты их не просто "можешь создать". Ты их себе обязательно создашь, хочешь ты этого или нет. Процент ошибок типизации относительно небольшой — функциональные, алгоритмические, и ошибки дизайна более трудоемки в исправлении и их в разы больше. Их тебе компилятор не выловит. Тебе придется сделать хорошее покрытие тестами — а оно выловит тебе все ошибки типизации без всяких дополнительных затрат на тестирование. Я не понимаю, как такая простая мысль тут ни до кого не может дойти — уже в третий раз объясняю.
Ошибки типизации проблемой не являются. Проблемой являются другие ошибки. Кстати, любой даункаст и запрос интерфейса в йаве — эквивалентен динамической типизации, или, по твоему, "выстрелу в ногу". Запрос COM-интерфейса (queryinterface) — то же самое. Ничего, работают люди спокойно без истерик. Наверно потому, что не знают. что это страшная "динамическая типизация".
G>>И все. Меньшее покрытие, кстати, все равно в статике делать нельзя — у тебя нетестированный код попадет в релиз. A>Каким образом я могу оттестировать покрытие кода если используется допустим цикл с разнородными объектами? В статике я протестирую все отдельно (functionalCTest, functionalDTest возможно с использованием mock) и т.к. я статически определелил контракт — код автоматически верен. (конечно интерфейсы тут не всегда помогют, т.к. не содержат кода, а мультинаследование в java не поддерживается, но допустим если взять scala с трейтами — то можно тестировать трейты отдельно). И подсутунуть объект допустим в тот же список таких объектов требующих IFunInitAllowed будет нельзя (ну если конечно не захотеть этого специально путем насильного приведения типов)
В динамике будет ровно то же самое — тебе достаточно тестировать полиморфный код только с теми типами, с которыми он реально будет использован. Не надо тестировать полиморфный код со всеми возможными сочетаниями типов — это идиотизм. Тестировать надо только с теми сочетаниями, с которыми он реально будет вызван в твоей программе.
G>>тестирвать с хорошим покрытием надо неполиморфный вызывающий код A>Код не всегда статичен. Часто в компонентных приложениях компоненты разрабатываются независимо, т.е. разработчик библиотеки не может знать, что метод init теперь init2, а следовательно его расширение к твоему софту упадет в рантайме.
Разработчик библиотеки может и должен знать, называется метод init или init2. Его расширение к моему софту должно соответствовать моей спецификации — это раз.
Два — не по теме, но ты сам уже начал от нее отступать. Ты знаешь, как раельно резолвится указатель на функцию в dll? Так, к слову о разработке библиотек. Указатель получается специальным вызовом по имени функции. То есть, его расширение — устаревшая версия либы реально упадет в рантайме. Не смотря на очень статическую типизацию.
G>> не так как в статике, структурировать код — его можно сделать менее связным и более обобщенным, не свернув при том себе шею. A>Проблема возникает в другом — в связанности кода на уровне документации к исходникам (типа, не забываем, что у классов передаваемых в f1 должен быть метод init), против связанности на бинарном уровне в статик языках java или C# (правда С++ выпадает из этого списка ибо обладает связанностью на уровне исходников, точнее их части .h файлов)
Это небольшая "проблема", учитывая преимущество, которое я тебе описал, а ты аккуратно его скипнул. К тому же, об это "проблеме" знает каждый пользователь динамических языков, и она почему-то их мало волнует.
Кстати, та же "проблема" произойдет у тебя в яве при попытке подцепить компоненту с неправильным интерфейсом в рантайме. Полезут эксцепшены — нельзя мол к правильному типу привести. У нас же очень в моде компонентная разработка, да?
G>>Насчет изменения методов — описанная вами проблема замечательно решается конекстным поиском. А ошибки, которые не нашел компилятор, вылавливается потом простейшими regression-тестами. A>Ну собственно к чему и пришли: в динамике тесты вырастают на ровном месте, там где в статике это может проверять компилятор:
Мы к этому не пришли. Это ты просто сейчас повторяешь то, что думал с самого начала, — тебе не хотелось даже вникать в то, что я пишу.
А пришли мы к тому, что моих объяснений ты не понял — все что было по существу ты пропустил, оствил вырванные из контекста фразы. К тому, что прогрессивная общестенность не привыкла тестировать свои программы — в принципе этого никогда не делали видать, а динамика оказывается вынуждает нас писать какие-никакие тесты. К тому, что ничего нового прогрессивная общественность для себя узнать не хочет, как и вникать в суть проблемы. Ладно.
A>1. Статик язык позволяет производить рефакторинг с гарантированным результатом (проверка на выполнение контракта будет в момент компиляции)
Я тебе уже ведь писал, про то, что такое рефакторинг. Смешно. Без regression tests нормальный рефакторинг невозможен, а то, что называешь рефакторингом ты — во первых, автоматизация работы машинистки, во вторых, к статике напрямую не относится.
A>2. Поиск и замена — зло. Ибо можно поменять не то. Например у меня методы init могут встречаться налево и направо, но только 2! класса могут быть переданы в f1 и f2.
Ничего, когда я работал на maintenance сервера и клиента CQG (всего около 2,5 миллиона строк С++) — мне поиска с заменой хватало. Достаточно не забывать, что для рефакторинга нужны мозги, а не средства разработки, и проблем не будет.
A>3. Рефакторинг динамического кода приводит не только к необходимости дополнительно тестировать сам код, но так же предоставлять некий фреймворк для тестирования расширений, что в общем случае совсем не тривиально
Рефакторинг динамического кода не имеет никакого отношения к расширениям. Любой рефакторинг любой системы требует хорошего покрытия как юнит-тестами, так и системными тестами. Пришли мы к тому, что для прогрессивной общестенности вопросы тестирования незнакомы, а посему обсуждать с ней, общественностью, вопросы влияния ошибок тестирования бесполезно. Мне кажется так. Всего доброго.
Здравствуйте, aka50, Вы писали:
A>Я никогда не отрицал тестов. Но основной поинт — есть понятие "контракт" которое в случае с динамикой предлагается указывать в "спецификации", а в статическом языке типы и есть встроенная в язык спецификация.
Которая покрывает слишком мало и только слишком тривиальные случаи.
Здравствуйте, Курилка, Вы писали:
E>>Для выполнения действий над БД запускается утилита psql, которая может отработать неудачно. Поэтому в случае неудачи psql перезапускает пока не истечет необходимое количество попыток. Если убрать логирование и отбросить особенности форматирования, то получается не большая уж и разница.
К>А теперь как минимум вспоминаем разницу между процессами ОС и процессами Эрланга, плюс "встроенность" эрланговских процессов по сути в сам язык.
Да, раз уж пошли подколки, то за именование переменных вроде
{M,F,D}=dict:fetch(Pid,Dc),
не мешало бы кому-нибудь по чему-нибудь настучать
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Klapaucius, Вы писали:
VD>>>Его (Моно) качество ничем не хуже нежели скажем Питона, Руби или GCC. Отдельные, редкие глюки несомненно встречаются, но пользоваться им можно без проблем.
E>>На основании чего сделан такой вывод?
K>А на основании чего может быть сделан обратный вывод? У Вас есть данные о бесспорном превосходстве Ruby над Mono в этом аспекте? Это было бы интересно.
А где в моих словах вы нашли утверждение о "бесспорном превосходстве Ruby"?
Чтоже до стабильности (и косвенно о качестве) Mono, то достаточно посмотреть в ChangeLog:
Здравствуйте, Курилка, Вы писали:
К>А можно какие-нибудь комментарии по поводу того — что понравилось в эрланге, на какие грабли наступали. Что использовали кроме мнезии, скажем eUnit пользовали?
Ежели говорить о внешних библиотеках, то ничего, кроме leex, не использовали. Это генератор лексеров, и очень удобный. Все остальные потребности с лихвой перекрывались самой OTP. Когда-то мы использовали SOAP и, соответственно, XML — но и это все в стандартной поставке присутствует.
Что понравилось в Ерланге :
— изоляция процессов ( и захочешь, а не нагадишь )
— принцип "let it crash" ( пусть процесс помрет от несварения данных, а мы это обработаем )
— ОЧЕНЬ удобная работа с паттерн-матчингом
— сообщения ! что, в принципе, лежит рядом с изоляцией
— полиморфизм по произвольным паттернам ( функции с одним именем могут принимать и строку, и число, и тупль... но это будут разные функции )
— динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
Что НЕ понравилось :
— не возможности автоматически заставить кодописателя производить генерализацию и обобщения функций. У нас в системе сейчас поддержано около 90 типов запросов, и во многих случаях на каждый из них написана функция из 10-15 строк, которая почти не отличается от других таких же. Но это, конечно, проблема не конкретно Ерланга — он всего лишь способствует этому из-за краткости кода.
Были непонятки с Мнезией, но это было уже давно...
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
К>[cut]
G>>Это весь код, который я пишу. Библиотек я здесь не использую, ограничений на сериализуемые данные у меня нет никаких. Я могу, например, лямбда функцию спокойно сериализовать и десериализовать. Рекомендую повторить на "нормальном строготипизированном языке". Не забыв все необходимые дополнительные телодвижения, а также тот случай, когда в потоке встречается рассогласование версий форматов. Потом подумать о жизни — о том, какая это К>все-таки непростая штука.
К>Слушай, а вот как Эрланг с версионностью борется? К>Скажем апгрейдим сервер, формат сообщений расширился, т.е. под старый шаблон уже не "влезает" — придётся принудительно апгрейдить клиентов? Или в формате делать "точки расширения" (e.g. параметр как список произв. длины, я тут рядом вроде eao197 приводил подобную схема)? Не встречался с подобной задачей?
Есть на самом деле две проблемы, связанные с версионностью. Первая — десериализатор бинарного потока съезжает (из-за изменившейся длины и/или формата пакетов), и начинает работать не начала пакетов. Это кирдык. Этой проблемы у нас не будет в принципе при применении встроенной сериализации. Вторая проблема — как обрабатывать сообщения неизвестного формата. Это уже проблема прикладная. "Хорошее" поведение — пропускать пакеты неизвестного типа, и пропускать неизвестную расширенную информацию в измененных пакетах.
Но так чаще всего не делают. Лучше завести новый тип сообщения, который будет спокойно игнорироваться.
А вообще — не забывайте — у нас есть под рукой горячий апдейт кода на работающей системе и нам не страшны крэши отдельных процессов (для Эрланга крэш, в отличии от остальных языков — это штатная, рабочая ситуация, let it crash) — всю систему это не завалит. Это сильно снижает тяжесть последствий рассогласования протоколов.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, Gaperton, Вы писали:
G>>Плюсов можно достичь таких: EC>Т.е. всякие сервисы, которые слушают обновления рыночных данных, что-то пересчитывают и шлют дальше это подходящая задача?
В принципе да, с одной оговоркой. Обработка там конечно тривиальная, но как бы тормознутость Эрланга не стала проблемой. Потому, что тут важна минимальная задерка и высокая пропускная способность, а задача обработки потока котировок не так чтоб сильно хорошо параллелилась. В принципе, можно параллелить ее по т.н. коммодити (группа инструментов) и по инструментам, но это приводит к появлению большого количества несинхронизированных по времени потоков котировок. Короче — как я сказал хз, надо прототипировать. Здесь все упирается в нахождение внятного и приемлемого способа отпараллелить задачу.
Далее, надо понимать, что обработка рыночных данных — это группа разных задач.
1) "Парсеры" — преобразователи потоков котировок из одного формата в другой. Эта задача хорошо решается на Эрланге — так делают в futuresource.
2) Сервис по обработке онлайновых заявок на торговлю (электронные торги) — должен лечь на Эрланг идеально, понятно в целом как делать.
3) Сервер по обработке исторических данных и их изменениях в реальном времени — надо думать.
Сервисов возможно довольно много — это я на вскидку привел.
G>>Минусы такие: G>>Проектировать надо совсем по другому, не так как на С++/Java — в Эрланге довольно необычный подход к проектированию, и свои грабли, которые надо знать и обходить. А сервер настолько сложен (из-за большого количества всяких обязательных к реализации мелочей и неочевидных юзкейсов), что его чрезвычайно тяжело спроектировать и на обычных ОО языках. EC>Ты имеешь в виду, что опыт ОО проектирования накоплен больше чем проектирования на функциональных языках и это в данном случае проблема?
Я имею в виду, что лично я не умею проектировать большие системы конкретно на Эрланге. Проектирование Эрланг-систем имеет мало общего с проектированием на ФЯ — это почти ОО проектирование, только каждый объект работает параллельно и довольно крупный. Плюс — при проектировании надо учитывать грабли и ограничения Эрланг-системы, а для этого нужен опыт. Армстронг бы с этой задачей справился влет, я — нет.
EC>Ты часто упоминаешь временные ряды в контексте сервера CQG. Можешь привести минимальный пример задачи, чтобы понять, что имеется в виду?
Временной ряд — это упорядоченная по времени последовательность некоторых данных. Типичный для биржевой обработки пример — последовательность четверок Open, High, Low, Close по времени с интервалом, например, 60 минут. Open — Close — первая и последняя котировки за час, High Low — максимальная и минимальная за час. Эта черверка называется bar. Временные ряды могут преобразовываться, например я могу на ряд баров наложить индикатор "скользящее среднее с периодом 5", и получу другой временной ряд, из единственного числового значения MA. При этом, последнее значение OHLC 60 обновляется в реальном времени из потока котировок, должен обновляться и зависящий от него временной ряд MA. Сервер CQG умеет лениво вычислять временные ряды по запросу за период времени, логически же они бесконечны. Сервер содержит систему их кэширования, умеет отслеживать зависимости, поддерживает разные типы временных рядов и аналитической обработки.
Здравствуйте, Курилка, Вы писали:
E>>Чесно говоря, восторг от возможности передачи сложных структур данных у меня очень быстро прошел в свое время. Из-за "проблемы второй версии"
К>А конкретней? Где именно 2-я версия? Сообщений? Получателей?
Вторая версия протокола.
Наивно написанный протокол, к сожалению, не содержит возможности своего расшишения с сохранением совместимости с предыдущими версиями. Вплоть до таких детских ошибок, как отсутствие в протоколе метки его собственной версии.
M>>>Каким боком здесь динамика? А никаким К>Я думаю каким — типов сообщений у нас нет поэтому разбирать надо "на лету", поэтому можем разбирать в 2-й версии больше чем в 1-й.
Проблема в другом, в том, чтобы клиенты первой версии без проблем понимали вторую. Вот пример того, как это можно обеспечить (подсмотрено в Asn.1 ).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, kliff, Вы писали:
K>..а лечить по фото не пробовал? склонность заметна шутка.
Тут и фото не нужно.
K>Реклама или не реклама — это вопрос названия. Тут другое интересно. Этот эрланг оставляет у большинства исключительно положительные эмоции после практическиого применения.
Если ты заметил, то я к Эрлэнгу претензий не имею. Считаю его интересным продуктом. Особенно интересным конечно в нем является не динамика или фунциональная ориентация, а иделогия программно-изолированных процессов и общения между ними по средствам сообщений.
Уверен, что подобный фрэймворк был бы кстати в любом языке и/или рантайме (например, Яве или дотнете).
Но к данному заявлению это никак не относится. Более того лично для меня похвалы чего бы то нибыло вот таким образом являются антирелкамой. Собственно и хотелось бы, чтобы подобного было по меньше.
Я даже с удовольствием послушаю рассказ о том что динамика дала конкреному коллективу и т.п. Но слушать спокойно такой абстурд я не могу. Это вызвает неподдельный смех и соответственно несерьезное отношение к другим словам автора.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
M>Благодаря "Декларативному программированию" я в поисках прошел M>Lisp -> Haskell -> OCaml -> Erlang M>Дважды пытался возвращаться к Хаскелю, но не смог Довольствуюсь тем, что простенькие программы могу читать "с листа"
Тенденция, однако ! (с)
M>ЗЫ. Я еще не смотрел на Немерле
Он непортабельный. Мое wa говорит мне последние 15 лет, что затачиваться на непереносимые средства разработки — напрасная трата времени. И опыт это подтверждает.
Только не говорите мне про Mono !
Здравствуйте, Gaperton, Вы писали:
G>Кое-что есть. К студии была какая-то хреновина — Visual Assist.
Эта штукенция больше глючила чем работала, да и работала только на небольших тестовых проектах.
IT>>2. При развитии легаси системы, тем более большой, одним из основных принципов является принцип "не навреди". Следовательно, ни о каком глубоком рефакторинге речи быть не может. А для несложных случаев поиска с заменой действительно хватает.
G>Ты совершенно прав — подавляющее большинство людей не умеют вести разработку в рамках легаси, им это кажется невозможным. Это конечно очень круто, что в CQG должны быть "случаи несложные" а о "рефакторинге не может быть и речи". Только компании CQG не до подобных размышлений — ее основной продукт CQG for Windows был создан в 90 году, и с тех пор успешно развивается эволюционным образом.
Ну рефакторить то всегда можно. Только рефакторинг рефакторингу рознь. Для меня понятие глубокий рефакторинг с использованием автоматических средств — это по времени работы на день-два. А можно, конечно, рефакторить годами, успешно развиваясь эвелюционным образом. С этим я не спорю.
G>Просто люди делятся на две категории — одна из них, довольно малочисленная, умеет вести разработку в рамках легаси, при этом не вредить, и знает что такое глубокий рефакторинг (это не есть невозможно — просто для перечисленного требуется действительно высокая и специальная квалификация), а другая — нет.
Какая такая специальная квалификация? Рефакторщик 7-го разряда? Опыт нужен, голова на плечах и руки не из задницы. Впрочем, это мы уже отвлеклись.
G>Занятно. Для меня набивка и правка кода никогда не занимала настолько много времени, чтобы быть проблемой.
Ну давай к примеру возьмём переименование класса или метода. С поиском-заменой — это от несколько минут до нескольких десятков минут работы на большом проекте. При этом для динамических языков правильность результата не гарантирована. Переименование автоматическими средствами рефакторинга занимает от нескольких секунд, до нескольких десятков секунд на таком же проекте. Разница во времени на два порядка при гарантированно рабочем результате.
Это правка кода. С набивкой таже ситуация. Интелесенс не просто рулит, а рулит не по-децки. Нет необходимости помнить наизусть сигнатуры методов, количество набиваемых букв на клавиатуре сокращается в разы. Отображение ошибок уже при наборе кода позволяет писать рабочий код даже не компилируя его. И т.п.
Ещё, если мы уж заговорили о легаси, добавим ко всему этому навигацию по коду. Нам же постоянно приходится изучать старый код, написанный кем-то, правильно? Так вот изучение кода и навигация по нему превращается из проблемы в развлечение. Переход к определению метода/переменной/класса — одно нажатие кнопки, наведение мышки на идентификатор даёт подсветку всех его вхождений и т.п.
К сожалению, ничего этого нет и принципиально не может быть в динамике.
G>А отсутсвие стадии проектирования я считаю жирным минусом. Впрочем, на этапе проектирования никто не запрещает писать код.
Проектирование никуда не девается. Это понятно. Оно совмещается с тестированием идей на пилотных проекта и собственно реализацией. Фактически, результатом проектирования является рабочий код. Возможно это потому, что работа с кодом очень дёшева, примерно как потоки в Эрланге Для меня нет необходимости обдумывать всё до мелочей, можно сразу пробовать. Мелочи сами всплывут, причём абсолютно все, даже те, которые при типичном подходе к проектированию всплывают только в момент реализации. Знакомая проблема? А у меня такой нет в принципе.
Единственная область где приходится заниматься проектированием отдельно — это дизайн БД. К сожалению, пока это так и, к сожалению, ошибки при проектировании БД весьма болезнены.
IT>>Хотя трудно сказать, что отсутствует, стадия проектирования или стадия реализации того, что напроектировано, т.к. эти вещи у меня полностью совмещены. Я проектирую прямо в коде.
G>Для простого софта такого подхода действительно хватает. В сложных случаях
Простота/сложность довольно скользкая тема. Как гласит закон Мейера "Усложнять — просто, упрощать — сложно". Лично у меня разговоры о сложности и упоминание с гордостью о мегатоннах кода вызывает в лучшем случае улыбку, т.к. в 99% за сложностью скрывается запутанность и малограмотный дизайн. Поэтому, я бы предпочёл опустить эту тему.
G>такой подход слишком часто приводит к полному провалу проектов на стадии ближе к концу и потере контроля над разработкой (причина, разумеется, в том, что в голове перестает умещаться сложность системы, а не в ошибках при масштабных переименованиях функций и переменных). Что я неоднократно наблюдал.
Я не знаю что ты там наблюдал. Никаких проблем с совмещением проектирования и реализации при условии, что во время этого процесса код постоянно модифицируется и из него вылепливается наилучшее решение, нет. Давай возьмём другую аналогию. Если писать ручкой на листе бумаги, то при возникновении ошибки весь лист нужно переписывать заново. Если взять карандаш, то в некоторых случаях уже будет можно что-то исправлять по ходу, но скорее всего всё равно получится грязно. А теперь давай вместо бумаги возьмём принципиально другой материал — пластилин. По ходу с ним можно делать всё что угодно не боясь где-то ошибиться, т.к. исправление ошибки крайне дёшево.
IT>>Это возможно потому, что я не боюсь ошибится и потом кое-что переделывать. G>А я стараюсь не ошибаться и свести будущие переделки к минимуму.
Это устаревший подход. Впрочем, для динамики он единственно возможный.
G>Если ты пишешь на JScript.NET, то тебе никто не запрещает проставлять типы, если хочется. Там можно.
Нет. Обычный браузерный javascript.
G>Во-вторых — разве ты не в Visual Studio пишешь?
В студии. Но для jscript там кроме подсветки синтаксиса ничего нет. Впрочем, ребята невероятно напряглись и сделали интеллисенс для случаев, когда они могут понять тип переменной из контекста. Но случаи такие крайне редки.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Курилка, Вы писали:
К>Ну вообще это были просто "мысли вслух" К>Но, если не секрет, то интересно и почему вообще
Исключительно из соображений моды ! Ну и хотелось поначалу, чтобы все ж по какому-то стандартному протоколу шел обмен — это чтоб могли внешние системы подключаться. Но потом решили, что когда необходимость в этом ДЕЙСТВИТЕЛЬНО возникнет, приделаем уж что-нибудь
Здравствуйте, VladD2, Вы писали:
EC>>Просьба ко всем не развязывать очередной флейм на эту тему.
VD>А ты серьезно хочешь получить обоснование для этого, брошенного в реламном пылу, лозунга?
Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.
VD>Мужик просто заговорился. Со всеми бывает. Это конечно про то что касается надежных систем.
У тебя есть основания считать, что система получилась ненадёжной? или неверить ему?
VD>Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю удобным татику в хорошем языке в купе с хорошей IDE.
Именно. Мне со статической типизацией и хорошей IDE тоже как-то спокойнее и удобнее, но есть масса людей, которые делают полезные вещи другим способом. Вот мне как раз и интересно как они это делают на динамически типизированом языке.
Здравствуйте, eao197, Вы писали:
E>JSP под управлением, например, Resin-а в свое время так же позволяла менять JSP-странички на лету. Ручная загрузка-выгрузка DLL с ручным использованием GetProcAddress так же позволяет организовать горячую замену кода в C++. Только замена замене рознь. Ruby и, как я понимаю, Erlang, позволяют заменять код без потери transient-данных в ОП.
Не надо только про С++. А то у тебя по жизни перекосы... рекламирушь Руби на фоне С++. На его фоне многое (ну, разве, что кроме скорости того же Руби) выглядит неплохо.
VD>>По практие скажу, что сама по себе горячая замена кода еще не обеспечивает бесбойность работы софта. Всегда есть шанс, что заливаемый на сервер код содержит ошибки не выловленные "в лабороторных условиях".
E>Это очевидно. Однако при этом горячая замена кода дает возможность исправить и внесенные при предыдущем патче ошибки не останавливая систему.
Это уже пословие. При ошибке в залитом коде сайт с большой нагрузкой скорее всего ляжет. Прийдется откатывать изменения и запускать его занова.
E>А по твоему софт для телефонии, для транспорта SMS/MMS, для обслуживания финансовых транзакций, для банкоматов, для мобильных телефонов, для управления двигателями и пр. тестируются только unit-тестами? Широко применяются тестовые и имитационные стенды,
Незнаю как для SMS, а для серьезного сайта такие тесты создать практически невозможно. Проблемы вылезают в основном из-за непредсказуемых параллельных действий пользователя. Тут как с юнит-тестами, чтобы написать такой тест надо знать сценарий приводящий к проблеме, а возникают такие сценарии только при работе на живом сайте под нагрузкой. Так что ты даже увидить эти сценарии не всегд можешь.
От того новая фича на сайте может привести к глюкам или вообще падению сайта.
Вот недавно у нас были проблемы с NNTP-сервером. Долго мучались пока установили причину проблем. И ведь никаких проблем с горчей замено кода не было. Сервер можно тупо перезапускать хоть раз в минуту.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
E>>Чесно говоря, так и не понял, что же здесь обеспечивает надежность?
G>Пример слишком примитивный — тут я согласен. G>Вот несколько более другой : G>
G>Лямбда Flt генерируется при старте сервера для каждого типа записей, чтоб при любом изменении внутренних структур данных и форматов записей в базе корректным образом доставать оттуда то, что заказано. Вся типизация ( динамическая, заметим) скрыта внутри. Это и есть пример достижения необходимой надежности
Вынужден вновь не согласиться с вами.
То, что Flt генерируется при старте и затем в динамике выбирается версия, подходящая для определенных типов параметов, говорит лишь об удобстве ее использования и снижения трудозатрат на ее реализацию. В том же C++ можно делать аналогичные вещи, только они будут больше по объему. А вот степень надежности того и другого -- вопрос открытый.
E>>Не раскрыта тема, однако
G>Опасаюсь я бросать сюда большие или сложные куски — многое написано студентом, отчего код, мягко говоря, корявоват. Впрочем, попробую выскрести какие-то вразумительные обрывки.
Я не думаю, что для подтверждения вашего тезиса о большей надежности динамически-типизированных программ над статически типизированными вообще нужно приводить фрагменты кода. Имхо, проще словами перечислить те факторы, которые по вашему мнению повышают надежность.
G>Хотя — на кусках кода сложно передать причины моей убежденности в соотношении трудозатрат в написании систем с динамической и статической типизацией. Оная убежденность выросла в процессе построения и развития подобных систем ( эта — не первая, но самая сложная ). Другой пример — мои знакомые делают обвязку С++ софта тиклевыми скриптами для сложной обработки данных именно потому, что на С++ сделать это за разумные сроки совершенно нереально. Их С++ софт писался несколько лет. Обвязка на Тикле превосходит по сложности уже в несколько раз, и писалась несколько месяцев. Некая зависимость проглядывает, верно ?
У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации. Действительно, C++ для сложной обработки данных сольет практически любому языку по объему кода, скорости его написания и времени на тестирования. Но все это имеет косвенное отношение к надежности.
Поскольку надежность -- это способности программы выполнять свою работу в граничных условиях, при получении некорректных данных, при исчерпании ресурсов, при возникновении непредвиденных ошибок. Здесь главную роль играет наличие стратегии обнаружения сбойных ситуаций и восстановления после них. Как это буржуины говорят: detect early, fail fast. Но и наличие стратегии не дает гарантий, поскольку как сама стратегия должна быть верифицированна, так и ее реализация -- проверена. Для чего нужно тестирование. И вот здесь есть очень тонкий момент: в статически-типизированных языках компилятор гарантирует хотя бы отсутствие элементарных синтаксических ошибок или ошибок типизации во всех фрагментах кода. Даже в тех, которые обрабатывают ошибки, возникающие раз в 10 лет при определенной фазе Луны (по прикидкам разработчика). Т.е. если такая ошибка возникнет и данный код пойдет на выполнение, есть хоть какая-то уверенность, что он не порушит всю систему неожиданным TypeMismatchError.
А вот в динамике такой уверенности нет вообще. Т.е. в динамике тестами должно быть покрыто 100% кода, даже того, который, по всем законам здравого смысла, даже исполняться не должен. А это означает гораздо больший объем тестирования, чем в случае со статически типизированными языками.
Так вот лично меня интересует ваше мнение по поводу того, как динамическая типизация обеспечивает большую надежность (именно в смысле сохранения программой работоспособности в непредвиденных условиях)?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?
E>Object Pascal
Мне это кажется несерьезным. Начиная с некоторого порога сложности системы начинается экспоненциальный рост сложности и обьема исходников.
E>Eiffel
Тут мне опять-таки сложно что-либо сказать. Последний раз на Эйфель я смотрел лет 5-6 назад...
E>Scala (если оставаться в рамках "Декларативного программирования"), хотя с учетом того, сколько багов фиксятся от релиза к релизу
Вот именно. Стабильной версии, я считаю нет
Можно было бы еще упомянуть AliceML, которая может быть статически типизирована...когда она заработает.
Здравствуйте, Tonal-, Вы писали:
T>Если потом, окажиться что выбранный тип коллекции нас не устраивает, мы становимся теред дилемой — либо добавлять в интерфейс нужный тип — и тем загрязнять его, либо менять старый тип на новый, что даже с поддержкой компилятора часто изрядно трудоёмко, как и любое нетривиальное изменение кода.
T>Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы.
На мой взгляд это приемущество раздолбайства. Типа если я живу в хлеву, то наделай я в углу и никто не расстроится. Все равно везде грязь!
На самом деле обобщенное программирование и правильное проектирование, а так же вывод типов фактически сводят такие проблемы к нул. Но если программист раздолбай и бездарность, то правильное проектирование и применение продвинутых техник программирования может быть затруднительным. Отсюда вывод — приемущество динамики обратно пропорциональны скилу программиста. Это коечно шутка, но в ней ейсть доля шутки.
T>Соответственно разработка обладает большей мобильностью.
Скажем так. Иногда, когда мы сами загнали себя в угол неправильным проектным решением, может оказться уобным вальготное манипулирование типами. Но на уровне всего проекта это чревато большими проблемами.
Самое сложное — это не написать кусок кода, а вписать его в уже имющуюся инфраструктуру. То и дело хочется произвести рефакторинг, изменить одно проектное решение на другое. И все это проще делать при наличии строгого контроля типов.
Без строгого статического контроля типов единственным способом получить надежную систему является обкладывание кода тестами. Причем такого обкладывания, чтобы ни одна мышь не проскачила. В некоторых системах это возможно, а в некоторых нет. Так что имеем еще один вывод — динамика противопоказана системам для которых по тем или иным причинам трудно создать тесты. И еще один вывод — выбирая динамику вы обязаны уделять тестированию вренмени чуть ли не больше чем основной разработке.
T>Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики.
Я бы так не сказал. Если исключить С++, то фрэймворки для сериализации (или даже встроенная сериализация) имеется для большинство статически типизированных языков. Для сериализаци нужна не динамика, а рефлексия (причем подойдет даже рефлексия времени компиляции).
T>P.S. Сейчас мы делаем проекты на Python + Qt. T>Раньше на Delphi и С++ T>Пока, для нас, выигрышь очивиден.
Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>>>Вот такой рефакторинг — головная боль и источник ошибок. А эти средсва ускорения работы машинисток, гордо называемые "рефакторинг" — детские игрушки. Смешно это в качестве плюса-минуса языка и платформы рассматривать.
IT>>Это ты сейчас как менеджер или как программист говоришь?
G>Как программист. На предыдущей работе я 6 лет занимался развитием большой легаси-системы на С++, на основании этого опыта и говорю.
Понятно. Это можно прокоментировать следующим образом.
1. C++ сам по себе язык, для которого создание человеческих средств рефакторинга, да и вообще нормальной поддержки IDE, крайне затруднено и, в результате, такие средства для C++ программистов недоступны.
2. При развитии легаси системы, тем более большой, одним из основных принципов является принцип "не навреди". Следовательно, ни о каком глубоком рефакторинге речи быть не может. А для несложных случаев поиска с заменой действительно хватает.
С другой стороны, сегодня для языков для которых реализована качественная поддержка IDE, набивка кода перестаёт быть работой машинистки и превращается в роботу, скажем, гончара, когда код не просто пишется, а вылепливается. Так, например, на C# у меня сегодня стадия проектирования просто напросто отсутствует. Хотя трудно сказать, что отсутствует, стадия проектирования или стадия реализации того, что напроектировано, т.к. эти вещи у меня полностью совмещены. Я проектирую прямо в коде. Это возможно потому, что я не боюсь ошибится и потом кое-что переделывать.
При этом последнее время приходится много писать на jscript. Причём не примитивного кода из серии window.open(), а нормальную такую логику с объектами и прочей функциональщиной. С одной стороны, я сильно зауважал скрипты вообще и jscript в частности, т.к. даже не подозревал, что на нём можно делать такие вещи. С другой, при набивке кода я чувствую себя именно машинисткой, которой при наборе текста нужно всё по десять раз проверять, иначе потом придётся искать ошибку вручную, т.к. у неё нет даже элементарных средств автоматической проверки орфографии.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Немного медленнее -- это им повезло, либо они делали интеграцию Тикля с C++.
E>У меня другой опыт -- есть изрядное количество отчетов, вычисляемых на Ruby. С увеличением объемов данных и усложнением самих отчетов время их формирования на Ruby уже перестает устраивать пользователей. В то время как C++ и D выполняют расчеты гораздо быстрее. Так что на некотором этапе быстрота разработки идет в топку, поскольку ее результат не удовлетворяет пользователей.
Вообще-то Эрланг существенно быстрее Ruby, Тикля и питона. Или скажем по другому — медленнее чем Руби язык найти сложно.
Здравствуйте, eao197, Вы писали:
G>>Нет, здесь недопонимание, а не противоречие. Падение процесса в Эрланге не означает падения всего приложения — процессы полностью изолированы. Это в системах на обычных языках падать нельзя (знакомая проблема?), а в Эрланге можно и нужно.
E>Когда речь идет о процессах, из которых состоит приложение, то даже в отношении C++ падение процесса не затрагивает других процессов (если речь не об MS-DOS или каких-нибудь hard-real-time OS). На C/C++ в Unix-ах испокон веку разрабатывали сложные системы на распараллеливании именно процессов, а не нитей. Поэтому и сейчас самый, наверное, дешевый способ увеличения надежности системы -- разбиение ее на отдельные процессы, тогда и падения, и переконфигурирование обходятся гораздо дешевле. Правда, дороже обходится взаимодействие процессов.
Разумеется, я прекрасно знаю (уверен, большинство присутствующих тоже), что процессы оперсистемы дают изоляцию, и про организацию процессов в UNIX, приходилось под UNIX писать. И мне кажется, ты знаешь, что у "процессов" Эрланга общее с процессами оперсистемы только название — они гораздо легче чем даже потоки, не то что процессы, они обладают сетевой прозрачностью, и чисто практически процессы оперсистемы нельзя применять так, как применяются процессы Эрланга. В Эрланге для осуществления короткой транзакции является нормальной практикой создать десяток короткоживущих процессов — это чрезвычайно дешево (посмотрю я как у тебя будет аналогичная программа выглядеть на UNIX-процессах — читатель подумает, что автор наелся волшебных грибов, не иначе).
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, VladD2, Вы писали:
VD>>Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .
FR>Думаю ява даст сильный тормоз за счет приличного увелечения объема кода. Скала вряд ли даст какое либо ускорение.
С явой согласен, разработка без поддержки IDE — это очень непростое занятие. Но вот скала? Я уже пол-года изучаю это язык и незаметно для себя обнаружил, что на скале я пишу в jedit/emacs _вообще_ без поддержки IDE (ибо нету пока толковой). Т.е. выразительность и краткость языка не идет ни в какое сравнение с java. Реально очень близко к python, только со статикой. Но гибкость скаловской системы типов и синтаксисический сахар позволяют писать как в динамике.
Здравствуйте, Gaperton, Вы писали:
G>Не порадуешь дизайн-документом, описывающим общую архитектуру?
Вдогонку о том, что у нас есть :
1. Движок правил. Компилирует скрипты описания взаимосвязей между типами обьектов и пропертями в соответствующие им лямбды
2. Движок запросов. Компилирует структуру запросов ( они описаны во внешних файлах и часто меняются ) опять-таки в лямбды, которые разбирают запрос и вычерпывают все необходимые для него данные
3. Динамическое создание функций для работы с базой, отталкиваясь от актуальной структуры базы
4. Прокся клиентов и прокся запросов. Когда что-то падает, остальное продолжает работать. И когда у нас появляется 2 камня, параллельная работа разных клиентов ускоряется в 2 раза. Или выполнение параллельных запросов от одного клиента
5. Непрерывное соединение по TCP/IP без поддержания контекста предыдущей сессии. Думали, чесали репу, постановили — предыдущую сессию не восстанавливать
6. Движок основных скриптов обработки — задействован в малой степени. Будем переделывать сам язык скриптов, ибо синтаксис оказался неудобоваримым для продАвцев, они же установщики
Все времяемкие операции сервер делает при старте / рестарте, а потом пользуется плодами оного, обычно в виде лямбд.
Клиентам мы поставляем сервер в виде системного сервиса, дабы не прибили его случайно умные админы
Здравствуйте, 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-ки тезисов), нельзя иметь несколько версий старого кода и нельзя (или нельзя автоматически) выгрузить ненужный старый код, определив когда он более не нужен.
Поэтому нельзя менять на лету код часто (пока не отцепился полностью старый код) и, вероятно, нельзя менять больше одного раза без перезагрузки.
Сохранение данных облегчается тем что почти все данные передаются как аргументы функций.
Т.е. нет объектов, которые разрушаются, вместе с информацией в них.
Если бы понадобилось делать очередь сообщений — это был бы сервер-процесс-функция(или несколько связанных функций) и он незаметно перешел бы от старой версии себя-функции к новой.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>А вообще — не забывайте — у нас есть под рукой горячий апдейт кода на работающей системе и нам не страшны крэши отдельных процессов (для Эрланга крэш, в отличии от остальных языков — это штатная, рабочая ситуация, let it crash) — всю систему это не завалит. Это сильно снижает тяжесть последствий рассогласования протоколов.
К>Ну да, это конечно, но eao197 там вроде говорил про ситуацию когда клиенты они "внешние" по отношению к нам, хотя запускать "чужих" в эрланговую систему, где (уже внутри самой системы) по сути почти нет механизмов защиты — это жуть полная...
Тогда надо принимать/отправлять данные по сокету. Он оперирует бинарисами. Делается это примерно так:
Последняя функция предполагает, что длины binary хватает на декодирование. В реальности она будет чуть сложнее — но думаю принцип понятен.
Если клиент не Эрлаговский, мы реализуем и бинарный протокол (напугали ежа голой жопой, извините ). Тут Эрланг, разумеется, порвет ваще всех безоговорочно, но не за счет динамики, а за счет binaries.
Здравствуйте, aka50, Вы писали:
G>>Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
A>К стати интересно... Судя по заявляениям Philipp Haller и Martin Odersky http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf A>
A>Interestingly, throughput of Scala actors remains basically constant (at about 30,000 tokens
A>per second), regardless of the number of processes. In contrast, throughput of pure Java threads
A>constantly decreases as the number of processes increases. The VM is unable to create
A>a ring with 5500 threads as it runs out of heap memory. In contrast, using Scala actors
A>the ring can be operated with as many as 600,000 processes (since every queue is also
A>an actor this amounts to 1,200,000 simultaneously active actors.)
A>Вот собственно интересно было бы замутить бенчмарк...
Я такой делал
Причем, если помниться, мой ноутбук был по производительности практически такой же, как упоминался в работе Одерски. Так что 30K токенов в секунду -- это фигня А после того Remark подсказал еще несколько оптимизаций, скорость еще процентов на 7-8 выросла.
Только вот 600K агентов на своей машине я запустить не могу, после 200K агентов 512Mb RAM оказывается мало.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
G>Приведи лучше пример бесполезного теста, который просто не нужен в языках со статической типизацией — ты его выкинешь и тестовое покрытие не ухудшится. Вот тогда ты мне возразишь.
Практически любая индуктивно определенная на рекурсивном алгебраическом типе функция.
length [] = 0
length (x:xs) = 1+length xs
data E = C Double | V String | N E | R E | A E E | M E E
diff vn (V v)
| vn == v = C 1
| otherwise = C 0
diff vn (N e) = N $ diff vn e
diff vn (R e) = N $ M (diff vn e) (M e e)
diff vn (A a b) = A (diff vn a) (diff vn b)
diff vn (M a b) = M (diff vn a) b `A` M a (diff vn b)
diff vn (C c) = C 0
Здесь вообще тестировать нечего — компилятор проверит полноту разбора входных данных. Все остальное записано таблично, и, прошу прощения, в тестировании не нуждается (после выявления опечаток, как это было у меня с пропущенной переменной).
Если у нас есть сомнения в применимости какого-то куска кода, мы можем протестировать его отдельано. Например, только
test = diff "x" $ M (V "x") (V "y")
, если у меня есть сомнения насчет каких-то плохо специфицированых критериев (или вообще отданных на откуп разработчику).
Также, как ты радуешься возможности выбора применения строгой типизации не ко всему проекту, а к его части, с весом этой части в диапазоне [0..1], использующий строгую типизацию (проверки компилятора) программист радует возможности переложить на компилятор написание тестов к части проекта, с весом этой части в диапазоне [0..a], где 0 < a < 1.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
<...прочитано и поскипано...>
A>В приведенном выше коде я хочу переименовать метод C.init в C.init2. Что будет? В статике я это отловлю на уровне интерфейсов (или трейтов если это допустим scala), как я отловлю проблемы тут? Далее, как я обнаружу проблему, что класс D тоже имеет метод init и вообще-то должен быть переименован? Или не должен? (возможно есть другие функции f3 f4 но туда С не передается никогда, а D передается... и даже возможно он может передаваться и в f1 и в f2, но IDE этого знать не сможет, ибо это даже разработчик сходу может не знать )
A>В статически типизированном языке не нужно проверять все комбинации вызовов функций f1 и f2 со всеми возможными классами C и D ... В динамике нужно. (допустим C и D это "стратегии", которые проверяются отдельно и потом могут комбинироваться в рантайме).
Андрей, по-моему опыту, рефакторинги типа переименования класса/метода/атрибута в динамике (в Ruby, в частности) выполняются без проблем. Может это и занимает чуть больше времени, чем в Java+IDEA, но вовсе не так долго как может казаться. Так что Gaperton тебе правильно все говорит.
Так же Gaperton правильно говорит, что в динамике специальные тесты на проверку соответствия типов не пишутся. Пишутся нормальные функциональные тесты, в них все изрядная доля ошибок как типизации, так и очепяток в именах методов/атрибутов/переменных вылетает на ура. Так что общее время отладки что на динамике, что на статике, не сильно различается. Конечно, если брать C++, то там какой-нибудь повисший указатель может всю картину попортить и заставить дневать и ночевать за компьютером. В Java/Scala в этом смысле значительно проще.
Вообще, по моему опыту, уверенность в том, что программа работает правильно в случае статики складывается из двух составляющих -- все скомпилировалось без ошибок и пройдены основные тесты. Но, поскольку на успешную компиляцию тратится изрядная доля времени, и существует иллюзия, что компилятор выловил значительную часть ошибок, то на тестах есть соблазн съэкономить. За счет чего часть серьезных функциональных ошибок остается в коде. Поэтому лично у меня в статике нет уверенности в том, что программа работает до тех пор, пока я не прогоню достаточное количество тестов. Но вот насобирать это достаточное количество тестов... Опять возвращаемся к соблазну экономии на тестах, раз компиляция прошла.
А вот в динамике вообще единственный способ узнать что-нибудь о программе -- это протестировать. Поэтому в динамике я гораздо чаще уверен в работоспособности программы, посколько эта уверенность лежит исключительно на результатах тестов. И нет даже мысли на тестах экономить.
Вот так и получается, что для достижения одинаковой уверенности и там и там требуется одинаковое количество функциональных тестов. Которые в динамике вылавливают ошибки типизации настолько же хорошо, как компилятор в статике.
А при наличии большого количества тестов рефакторинг (переименования всякие) не так уж и сложен.
Вот какой рефакторинг действительно вызывает сложности, так это изменение структур данных. Например, где-нибудь раньше использовался объект какого-нибудь типа Description, а затем пришлось заменить его на MetaDescription, в котором Description является всего-лишь атрибутом. Вот тогда приходится полазить по исходникам с тем, чтобы определить, где и чего используется -- анотаций-то типов нет.
Но при проведении такого рефакторинга в статике все равно нужно иметь достаточное тестовое покрытие, чтобы понять, что мы ничего не запортили.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, EvilChild, Вы писали:
E>>А вот в динамике вообще единственный способ узнать что-нибудь о программе -- это протестировать. Поэтому в динамике я гораздо чаще уверен в работоспособности программы, посколько эта уверенность лежит исключительно на результатах тестов. И нет даже мысли на тестах экономить.
EC>Т.е. проблема не сугубо техническая, а заключается в человеческом факторе?
Именно.
Возможно поэтому кто-то хорошо на динамике себя чувствует, а кто-то нет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы.
VD>На мой взгляд это приемущество раздолбайства. Типа если я живу в хлеву, то наделай я в углу и никто не расстроится. Все равно везде грязь!
Рефакторинг из той же песни, он тоже получается для раздолбаев.
VD>На самом деле обобщенное программирование и правильное проектирование, а так же вывод типов фактически сводят такие проблемы к нул. Но если программист раздолбай и бездарность, то правильное проектирование и применение продвинутых техник программирования может быть затруднительным. Отсюда вывод — приемущество динамики обратно пропорциональны скилу программиста. Это коечно шутка, но в ней ейсть доля шутки.
Не надо сказок про правильное проектирование, в реальном мире такое бывает разве при переписывании старых проектов и то если не добавлять новых фич
Ну а серъезно динамика дает больше перимуществ как раз более сильным программистам.
T>>Соответственно разработка обладает большей мобильностью.
VD>Скажем так. Иногда, когда мы сами загнали себя в угол неправильным проектным решением, может оказться уобным вальготное манипулирование типами. Но на уровне всего проекта это чревато большими проблемами.
VD>Самое сложное — это не написать кусок кода, а вписать его в уже имющуюся инфраструктуру. То и дело хочется произвести рефакторинг, изменить одно проектное решение на другое. И все это проще делать при наличии строгого контроля типов.
При динамике это тоже просто.
VD>Без строгого статического контроля типов единственным способом получить надежную систему является обкладывание кода тестами. Причем такого обкладывания, чтобы ни одна мышь не проскачила. В некоторых системах это возможно, а в некоторых нет. Так что имеем еще один вывод — динамика противопоказана системам для которых по тем или иным причинам трудно создать тесты. И еще один вывод — выбирая динамику вы обязаны уделять тестированию вренмени чуть ли не больше чем основной разработке.
Влад не провоцируй на разговоры про так любимого тобой Блаба
По опыту на небольших и средних проектах динамический язык (питон) требует не больше формальных тестов чем статический (хорошо написаный код на C++). Фокус в том что разработка идет практически режиме неприрывного тестирования, каждый запуск это тест. А число запусков при написании на динамике намного больше чем на статике.
VD>Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .
Думаю ява даст сильный тормоз за счет приличного увелечения объема кода. Скала вряд ли даст какое либо ускорение.
VD>>Золотые слова. И что мы стобой спорил по этим вопросам столько времени?
E>Потому, что мы с тобой спорим в общей священной войне dynamic vs static, в которой много факторов и надежность отнюдь не главный. Здесь же утверждалось, что динамика способствует надежности. Будучи приверженцем динамики я, все-таки не наблюдал такой прямой зависимости между динамикой и надежностью. Поэтому и влез в этот спор, чтобы понять, может я чего не знаю еще.
Я тоже согласен
Но обычно приверженцы статики кричат чуть ли об абсолютной ненадежности динамики. Что тоже неправда. Наверно поэтому Влад так разошелся, это же красная тряпка когда утверждают нечто абсолютно противоположное одному из его любимейших мифов
Здравствуйте, Курилка, Вы писали:
К>По-моему (на практике не пробовал), вполне можно менять дофига раз без перезагрузки. К>Суть в том, что у тебя время выполнения квантуется на периоды выполнения функций. Так вот старый модуль будет в памяти, пока функции, определённые в нём не завершатся. Вызов хвостовой рекурсии есть завершение функции (т.е. фактически получается "возвратом" из функции, правда в неё саму).
Только хвостовой вызов должен быть нелокальным
Здравствуйте, Mirrorer, Вы писали:
M>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ? И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
А в чем проблема ? Если уж CTAGS находит то, что нужно — то переименовать можно без проблем. Не говоря уж о том, что средства получения и манипуляций AST есть в стандартной бибилиотеке Ерланга.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Курилка, Вы писали:
К>>Имя функции может быть выражением, т.к. вычисляться в рантайме (хотя реальных примеров видел такого мало).
L>Думаю, и в статических языках в подобных ситуациях (напр, рефлекшн) при рефакторинге будут аналогичные проблемы.
Ясен пень, там получается, что на самом деле в рамках статики используется динамика (правда многословно будет )
Тут Mirrorer говорит, что в 2005-й студии есть галка для замены ссылок на методы в строках.
Естественно это лишь костыль, но всёж.
Здравствуйте, gandalfgrey, Вы писали:
G>А все распределенное и требующее некоей минимальной реактивности весьма близко к телекому. Чем, например, отличается распределенный сервер сбора и обработки телеметрических данных от распределенного сервера сбора и обработки некоей бизнес-информации ?
Понятия не имею о каких телеметрических данных идет речь и о какой бизнес-информации.
E>>А то, что не статика и не динамика определяют надежность -- это факт E>>Люди по любому гораздо менее надежный фактор в этом деле. G>Верно ! Но при использовании динамики именно ЛЮДИ почему-то делают гораздо меньше ошибок. Я уже приводил пример : знакомая контора перешла при написании всяческих расчетных вещей с С++ на Тикль. Считает немного медленнее, но зато быстро делается работающий и стабильный продукт. Сокращение сроков и трудозатрат у них было просто неимоверное...
Немного медленнее -- это им повезло, либо они делали интеграцию Тикля с C++.
У меня другой опыт -- есть изрядное количество отчетов, вычисляемых на Ruby. С увеличением объемов данных и усложнением самих отчетов время их формирования на Ruby уже перестает устраивать пользователей. В то время как C++ и D выполняют расчеты гораздо быстрее. Так что на некотором этапе быстрота разработки идет в топку, поскольку ее результат не удовлетворяет пользователей.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, aka50, Вы писали:
A>Я привел отсуствие влияния в данных разговорах (типа а вон скока на ерланге написано), но это не отменяет другие мои мысли про ненадежность динамического кода. Таким образом я вполне допускаю, что будь ерланг статически типизированным — он был бы еще надежнее (хотя наличие проверки сигнатур експортируемых функций — уже фича статически типизируемых языков).
Ммм, только сигнатура в Эрланге гораздо более мягкий критерий — имя и арность, не более...
А по поводу привнесения статики я в декабре замутил дискуссию, правда свелась которая к тому, что попытки были, но вот смысла в этом особого "эрлангисты" не видят. Хотя были работы того же Вадлера и Dialyzer развивается. Хотя он по сути есть отдельная подключаемая тулза (а не встроена в компилятор).
а ты изучал тесты этого shootout? 80% из них завязаны на бибилиотеки. в tcl была лучшая regexpr библиотека для больших строк — он победил в одном из dna тестов. в haskell и erlang была лёгкая многозадачность — и они победили в многозадачном тесте
при этом разрешено использовать только бибилиотеки, поставляемые с компилятором, в результате чего например ghc резко "ускорился" когда bytestring library включили в базовую бибилиотеку. сейчас назад разделяют её на части
G> Тут несколько раз поднимался вопрос о возможности и оправданности написания бизнес-логики на функциональных языках. Так что могу внести свою лепту в оное обсуждение. Распределенная система на Ерланге / Тикле, кою мы ваяли последние 1.5 года, начала продаваться. Пока только избранным покупателям, ибо еще есть разного рода сырости, но в течении месяца мы ее, полагаю, высушим.
После этого можно из Гендальфа Серого превращаться в Гендальфа Белого Потому что катарсис, point of no return и так далее
Здравствуйте, gandalfgrey, Вы писали:
E>>Object Pascal G>Мне это кажется несерьезным. Начиная с некоторого порога сложности системы начинается экспоненциальный рост сложности и обьема исходников.
На Дельфи создана масса сложнейших систем. И они уже давно работают. Уже этот факт подтверждает, что на ней точно можно это делать.
Тут разумно говорить о сложности разработки, а не о надежности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>У меня все сказанное вами оставляет впечатление, что вы говорите о большей надежности по сравнению с C++. E>Тогда более правильно вести разговор о преимуществах сильной типизации (не важно, статической ли или динамической) перед слабой типизацией.
Золотые слова. И что мы стобой спорил по этим вопросам столько времени?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>У меня все сказанное вами оставляет впечатление, что вы говорите о большей надежности по сравнению с C++. E>>Тогда более правильно вести разговор о преимуществах сильной типизации (не важно, статической ли или динамической) перед слабой типизацией.
VD>Золотые слова. И что мы стобой спорил по этим вопросам столько времени?
Потому, что мы с тобой спорим в общей священной войне dynamic vs static, в которой много факторов и надежность отнюдь не главный. Здесь же утверждалось, что динамика способствует надежности. Будучи приверженцем динамики я, все-таки не наблюдал такой прямой зависимости между динамикой и надежностью. Поэтому и влез в этот спор, чтобы понять, может я чего не знаю еще.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
E>>>Подробнее о том, что такое "проблема второй версии протокола" я рассказывал здесь
К>>И чем тебе не нравится предложенный мной вариант? Делаем сообщение аля {msgSignature, [...extesions...], someData} К>>Промежуточному слою нахрен не нужны extensions, поэтому в бранче ПМ будет что-то типа {msgSignature, _, X}
E>Я и не говорил, что он мне не нравится. Но, если об extensions не задумываться, то весь код ПМ вида {msgSignature, X} придется переделывать в {msgSignature, _, X}, а затем в {msgSignature, _, X, _}, а затем в {msgSignature{Y,Z,_},_,X,_,_} и т.д.
Ну это просто обходится, достаточно "подумать заранее"
abstract class Msg
case class NoExt extends Msg
case class MsgSig(val a: int, val ext: Msg) extends Msg
case class MsgExt(val b: int, val ext: Msg) extends Msg
object Proto {
def doit(m: Msg) = {
System.out.print("In doit:")
m match {
case MsgSig(a, _) => System.out.println("generic simple a=" + a)
}
}
def doit2(m: Msg) = {
System.out.print("In doit2:")
m match {
case MsgSig(a, MsgExt(b, _)) => System.out.println("extended a=" + a + " b=" + b)
case MsgSig(a, _) => System.out.println("pure simple a=" + a)
}
}
def run() = {
for (i <- MsgSig(1, NoExt()) :: MsgSig(2, MsgExt(3, NoExt)) :: Nil) yield {
System.out.println("Message: " + i)
doit(i)
doit2(i)
}
}
}
scala> Proto.run
Message: MsgSig(1,NoExt())
In doit:generic simple a=1
In doit2:pure simple a=1
Message: MsgSig(2,MsgExt(3,NoExt()))
In doit:generic simple a=2
In doit2:extended a=2 b=3
unnamed6: List[Unit] = List((), ())
Менее strict, но возможно более гибкий на списках (и возможно тормознее)
abstract class Msg
case class MsgSig(val a: int) extends Msg
case class MsgExt(val b: int) extends Msg
object Proto {
def doit(m: List[Msg]) = {
System.out.print("In doit:")
m match {
case MsgSig(a) :: xs => System.out.println("generic simple a=" + a)
case Nil =>
}
}
def doit2(m: List[Msg]) = {
System.out.print("In doit2:")
m match {
case MsgSig(a) :: MsgExt(b) :: xs => System.out.println("extended a=" + a + " b=" + b)
case MsgSig(a) :: xs => System.out.println("pure simple a=" + a)
case Nil =>
}
}
def run() = {
for (i <- (MsgSig(1) :: Nil) :: (MsgSig(2) :: MsgExt(3) :: Nil) :: Nil) yield {
System.out.println("Message: " + i)
doit(i)
doit2(i)
}
}
}
scala> Proto.run
Message: List(MsgSig(1))
In doit:generic simple a=1
In doit2:pure simple a=1
Message: List(MsgSig(2), MsgExt(3))
In doit:generic simple a=2
In doit2:extended a=2 b=3
unnamed7: List[Unit] = List((), ())
Здравствуйте, aka50, Вы писали:
E>>Здравствуйте, Курилка, Вы писали: К>>>И чем тебе не нравится предложенный мной вариант? Делаем сообщение аля {msgSignature, [...extesions...], someData} К>>>Промежуточному слою нахрен не нужны extensions, поэтому в бранче ПМ будет что-то типа {msgSignature, _, X} A>Ну это просто обходится, достаточно "подумать заранее"
упсс... Курилка, это твоя идея , а я только сейчас понял что ты тоже самое предложил...
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
VD>>На Дельфи создана масса сложнейших систем. И они уже давно работают. Уже этот факт подтверждает, что на ней точно можно это делать. G>Так-таки и сложнейших ? А можно пару примеров ?
Еще в 1998-ом на выстовке SoftTool минимум треть всех систем автоматизации предприятий были на Дельфи. Названий у меня нет, но я знаю где тебе их моутт дать.
VD>>Тут разумно говорить о сложности разработки, а не о надежности. G>Одно с другим связано, причем напрямую. Ежели для достижения одного и того же функционала сложность разработки на одной платформе превышает сложность разработки на другой в разы, то не будет ли таковым ( или близким к тому ) и соотношение надежности этих разработок ?
Так еще раз.
1. Сложность разработки не имеет никакой корелляции с динамикой и статикой.
2. Объем и сложность системы не имеет прямой зависимости от ее надежности (устойчивости к сбоям). Надежность определяется проектными решениями и качеством тестирования. В том числе надежнаость увеличивается если при прочих равных использвут типобезопасный, статически-типизированный язык, так как это снижает требования по объему тестирования. Причем, заметь, применение статики не "единственно возможный шанс добиться качества", а фактор способствующий его увеличению.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Жить без рефакторинга вообще практически невозможно. В процессе работы над той или иной проблемой нам открываются новые знания (подробности о которых раньше мы не могли знать). Это приводит к корректировке планов. Без рефакторинга проект быстро превращается в ночной кошмар. А с рефакторингом развивается дальше.
Да рефакторинг хорошая вещь.
Только в динамике рефакторинг можно делать с не меньшим успехом чем в статике, отсутствие автоматического инструментария вполне компенсируется более легким изменением кода обусловленным тотальной обобщенность в динамике.
FR>>Не надо сказок про правильное проектирование,
VD>Если для тебя это сказки, то в общем-то нам больше с тобой разговаривать не о чем.
FR>> в реальном мире такое бывает разве при переписывании старых проектов и то если не добавлять новых фич
VD>Вы просто не умете ее готовить (с)
При правильном проектировании рефакторинг не нужная вещь, а ты без него жить не можешь странно да?
FR>>Ну а серъезно динамика дает больше перимуществ как раз более сильным программистам.
VD>Голословное и крайне сомнительное утверждение. Я скорее соглашусь с мнением еао197 о том, что кто к чему привык тому то и нравится. Лично мне динамика всегда мешает. Я лучше напишу пару лишних строк распознающих тип (если надо), но буду иметь полноценный контроль над тем, что делаю.
У тебя просто фобия, поэтому ты не можешь нормально пользоватся динамикой
FR>>При динамике это тоже просто.
VD>Еще одно голословное и крайне сомнительное утверждение. При динамике никакого контроля за программистом нет. И нужно опбкладываться горой тестов.
Зато есть обобщеность и легкость проскирования которая сильно облегчает правки.
FR>>Влад не провоцируй на разговоры про так любимого тобой Блаба
VD>Блаба? Я на динамических языках поработал не мало.
Извини но я не вижу что ты грокнул динамику. Без этого конечно тоже можно работать, но только на кровне блаба.
FR>>По опыту на небольших и средних проектах
VD>Я не говорю о детских игрушках которые можно наклепать одному за месяц. Это на чем угодно можно сделать.
Я думал ты знаешь общепризнаную метрику.
А "детские игрушки" (если ты про казуальные игры) это сейчас уже приличные проекты на полгода — год для одного двух программистов.
FR>> динамический язык (питон) требует не больше формальных тестов чем статический (хорошо написаный код на C++).
VD>О, опять С++. Несомненно, не типобезопасный язык может требовать тестов не меньше чем динамический. В прочем, динамика по любому требует больше тестов. Если их нет, то просто снижается качество продукта.
Читай выделенное.
FR>> Фокус в том что разработка идет практически режиме неприрывного тестирования, каждый запуск это тест. А число запусков при написании на динамике намного больше чем на статике.
VD>Более менее серьзная программа имеет тучу мелких процедур которые взываются отнюдь не постоянно. Так что даже простое изменение может бытьне протестированно "при запусках". А уж рефакторинг точно приводит к изменениям которые требуют тотального тестирования, если конечно нет статической типизации которая спасает от многих ошибок.
Да если применять не правильный способ работы с динамикой. При правильном эти мелкие функции всегда прогоняются интерактивно, REPL рулит.
Re[9]: Бизнес-логика на Erlangе
От:
Аноним
Дата:
16.05.07 14:04
Оценка:
VD>а иделогия программно-изолированных процессов и общения между ними по средствам сообщений. VD>Уверен, что подобный фрэймворк был бы кстати в любом языке и/или рантайме (например, Яве или дотнете).
Здравствуйте, IT, Вы писали:
IT>Думаю, проблема скорее всего в C++. На нём действительно дорого делать надёжные вещи. То, что вы к джаве не примерялись, скорее всего просто что-то не сложилось.
Почему не примерялись ? Пробовали, но не пошло — так как с С++ разницы большой не увидели. ( для наших задач ). А сейчас я в этом мнении укрепился — уже приводил соотношение обьемов кода для достижения одинаковой функциональности
IT>А что именно так сильно повлияло на мнение, что надёжнее уже не бывает? Должно же ведь быть какое-то объяснение.
На самом деле — выбора практически нет. Для использования в критических отраслях — с чего я начинал — никто просто не позволит использовать платформу, не ставшую промышленной и без хороших примеров применения в critical mission. И что у нас остается ? С / С++. Жаба не для таких приложений все-таки. Эйфель. Ада...и Ерланг с Тиклем. Весь список, полагаю, будет меньше 10 наименований. Дополнительные факторы : на С++ дорого. Ада ОЧЕНЬ сложна. и так далее.
После такого отсева и остается то, что имеем и применяем. И опыт — как наш, так и чужой — говорит, что это вполне разумный выбор.
А "мнение, что надёжнее уже не бывает" — это, разумеется, не так. В наших условиях, с нашими человеческими, временными и финансовыми ресурсами это просто оптимальное решение. Ежели какая-то степень надежности достигнута, то ее всегда можно превзойти, хотя бы из математических соображений. Вопрос в том, какой ценой...
Здравствуйте, gandalfgrey, Вы писали:
G>Пример одной моей системы, работающей уже более 8 лет на самом крупном в мире предприятии по очистке и обогащению урана : G>- 400 К строк, не считая сгенерированного PCCTS кода. С ним — около 1.1 М строк G>- своя реалтаймовая СУБД G>- С++ и несколько своих скриптовых языков G>- сугубо распределенная G>- работает и на ПервоПне G>В нее вбухано более 20 человеколет. Это число достаточно велико, чтобы обьяснить, почему я считаю С++ малопригодным для построения чего-то более-менее сложного — это просто ОЧЕНЬ дорого обходится.
Очень смахивает на то, что на C++ вы пытались реализовать сами то же, что входит в состав ядра Erlang-а и его инструментов и что было написано не вами, а Ericsson-ом.
Пока из ваших рассказов у меня складывается впечатление, что вы не использовали сторонних библиотек, а все низкоуровневые вещи писали сами.
Вот, например, из того, что вы перечислили выше, какой процент кода относился именно к прикладной части?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
IT>> два 'за' в пользу статики: рефакторинг и возможность качественной поддержки IDE. G>... для рефакторинга Хаскеля
С Хаскелем как раз все понятно. Статическая типизация. Можно рефакторить не опасаясь, компилятор даст по рукам если что.
G>и Ерланга. G>Для NetBean есть весьма качественная поддержка Ерланга ( плагином ). Есть и для Эклипса, и для Емакса...
А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ? И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
Здравствуйте, Mirrorer, Вы писали:
M>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ?
"Элементарно Ватсон..."
Поскольку в Erlang нет глобальных переменных, то при перемиеновании переменной за пределами функции ничего искать не надо. При переименовании функции, тоже все обычно, как везде (даже проще, поскольку функции не экспортированные явно, локальны в пределах модуля).
Да и нет там особой необходимости в рефакторинге переименования, именно в силу локальности имен.
Здравствуйте, Mirrorer, Вы писали:
M>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ? И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
Не думаю, что переименование чего-нибудь является сложной проблемой для динамики.
Гораздо интереснее изменение прототипов функций или структур. В статике все эти вещи компилятор отлавливает.
Disclaimer: ситуации, когда что-нибудь передается как void* или приведенное к типу Object не интересны.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
E>>Дело не в Erlang-е как таковом. В 1.2Mloc Java можно было бы впихнуть компилятор, run-time и отладчик какого-нибудь доморощенного DSL, на котором данная задача решается вообще в несколько тысяч строк G>Оно таки-да ! Но тут проблема психологическая. Народ не готов был к этому
Ну вот мы и выяснили что дело не в том что динамика рулит, а втом что на жабе писали...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandalfgrey, Вы писали:
WH>>Ну вот мы и выяснили что дело не в том что динамика рулит, а втом что на жабе писали... G>Дык ить ! Может, потому жаба и некошерна, что сугубо статична ? G>Люди, разрабатывавшие проект на жабе, тоже ведь не маниаки какие-то. Но чем же обьяснить такой разрыв в количестве строк ?
По отношению к Java меня этот вопрос всегда интересовал. Почему Java и вокруг нее приводит вот к такому: Execution in the Kingdom of Nouns
Хотя есть один объективный фактор: спецификация исключений в методах. Из-за чего приходится в Java коде плодить массу catch-ей с перехватом исключений, не перечисленных в собственной спецификации, и преобразования их к чему-нибудь другому.
Опять же нет делегатов, замыканий или хотя бы указателей на функции. Поэтому любой callback должен реализовываться как интерфейс с его последующей имплементацией (хотя бы и в виде анонимного класса).
IDE теже самые, думаю, свою лепту вносят -- в них так быстро мегатонны кода клепаются, что сами авторы не успевают это осознавать.
G>Как было все, связанное с программингом, искусством во времена Вирта и Хоара, так и сейчас осталось на уровне восприятия и подсознательных побуждений...Рационального обьяснения для многих парадоксов разработки просто не существует, да и не может существовать по причине полной иррациональности и субьективности этих парадоксов.
Должны существовать. Просто нужно учитывать еще и психологию, как минимум.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>А потому что это без разницы. Надежность есть надежность и не надо при ее обсуждении обсуждать скорость разработки.
Вот не надо отрывать понятие надежности от реалий и делать его некоей абстракцией. Надежность существует не сама по себе, а в тесной связи с другими свойствами проекта. И скоростью разработки, и простотой в том числе.
VD>Расскажи это создателям тех же буранов, например. К тому же ты глубого заблуждаешся думая, что Союзы просты. Они в сто раз сложнее твоих программ.
Я сравниваю Союзы не с софтом, а с аналогичными американскими поделиями. И причем здесь Бураны, которые все равно на порядок проще Шаттлов ? Они ведь не летают.
VD>Я же говорю о том, что их как раз разрабатывали без разных RAD-средств. Делали работу дого и кропотливо. В начале все считалось вообще без компьюетров. Но в итоге они летают и очень неплохо. А вот Шатлы делались с применением самой свременной техники...
Сатурн-5 делался тоже долго и кропотливо, и что получилось ? Я уж не говорю о стоимости его запуска !
В результате на всех тяжелых американских носителях стоят российские двигательные системы, ибо американские, как раз вследствие свонй чрезмерной сложности, не обеспечивают необходимой надежности.
VD>Все это я говорю к тому, что надежность достигается не только использованием удобных инструментов. Инструмент может облегчить решение задачи. Не больше не меньше.
С этим я и не спорю. Содержимое репы, правильно приложенное к проблеме, гораздо важнее
VD>Судя по твоим словам, из статических языков ты пробовал только С++. Это вообще за опыт можно не считать. На его фоне любой нормальный язык будет выглядить супер-средством.
С++ я не пробовал. Я на нем писал с момента его появления до 2003 года, да и сейчас пописываю небольшие кусочки. Пробовал я как раз всякие более другие статические языки. Некоторые мне просто не нравятся, как например Хаскель ( по причине какой-то его потусторонности ). Некоторые я считаю попросту малоэффективными — например, Жабу. Ада — люди будут упираться. Окамл — все же сложноват для большинства наших кадров.И т.д.
Здравствуйте, geniepro, Вы писали:
G>Ну тады Вам просто необходимо попробовать Оберон/Компонентный Паскаль. Достаточно эффективен, прост, привычен, статически типизирован, и т.д.
Да ну брось. Оберон ничем не лучше чем таже жаба.
G>Оберонщики Вам кучу дифирамбов напоют при случае...
Обиронщики это "неуловимые Джо".
G>(Правда, у Влада-Д2 аллергия на эту группу языков, что тоже может служить показателем его (Оберона) хорошести...) :о))
Насколько я понимаю Влада он просто считает Обероны и компинию устаревшими и безперспективными языками. И я с ним согласен.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
G>С++ я не пробовал. Я на нем писал с момента его появления до 2003 года, да и сейчас пописываю небольшие кусочки. Пробовал я как раз всякие более другие статические языки. Некоторые мне просто не нравятся, как например Хаскель ( по причине какой-то его потусторонности ).
китайцы считают, что есть можно всё. если вы что-то не способны съесть — значит просто не умеете это готовить
вот скажи мне, что поще — описать формулы вычисления данных в экселевской таблице или написать порграмму на бейсике с описанием порядка тех же вычислений? вроде порще и понятней на экселе
так же надо глядеть и на хаскел. у нас есть операции обмена с внешним миром. это скелет программы. все манипуляции, превразающие данные полученные программой в данные, которые будут отправлены наружу или управлять порядком выполнения — это просто формулы, аналогичные экселовским. и эти сложные вычисления гораздо проще проводить на FP языке. обо всё, что проихсодит помимо вызовов OS API, нужно думать не в терминах действий, а в терминах мат. зависимостей — и тогда, боюсь, сокрее императивные языки покажутся чем-то потусторонним
Здравствуйте, Аноним, Вы писали:
А>ну это уже чисто эмоциональное. clean отличается большей эффективностью, меньшим числом наворотов в типах данных, IDE и GUI библиотеками. приницпиальная основа та же
Именно что так ! Хотя насчет наворотов в типах данных я не уверен — у Клина есть свои сугубые фичи
Тем не менее — Клин для меня вполне язык, а Хаскель ну никак не идет. Жалко, что Клин такое глюкало...
Здравствуйте, Gaperton, Вы писали:
G>Настоящий рефакторинг, как его знаю я — это глубокое изменение структуры кода без изменения функциональности, возможно — изменение дизайна, с целью подготовки старого кода к масштабному добавлению новой функциональности (или устранения "гнезда" ошибок). Здесь никакие тулзы не помогут — все равно regression-тестами надо накрывать.
+1
G>Вот такой рефакторинг — головная боль и источник ошибок. А эти средсва ускорения работы машинисток, гордо называемые "рефакторинг" — детские игрушки. Смешно это в качестве плюса-минуса языка и платформы рассматривать.
Но все таки при статической типизации такая операция проходит более безболезненно чем при динамике. (правда есть минус: скорее всего код очень долго нельзя будет даже скомпилировать не говоря уже о тестировании ). Часть тестов в статичской типизации не нужна. И более того, статически типизированный язык позволяет реализовать фишки (типа изменений интерфейсов, изменений сигнатур методов, extract/convert операции для классов/интерфейсов) которые автоматизируют (типобезопасно) часть операций при таком глубоком изменении кода.
Здравствуйте, gandalfgrey, Вы писали:
G>Сатурн-5 делался тоже долго и кропотливо, и что получилось ?
Получилась РН, не имеющая, пока что, аналогов в мире по своим характеристикам и возможностям. Да, разрабатывались конфигурации РН "Энергия" аналогичные и превосходящие, но они не испытывались и не эксплуатировались.
G>Я уж не говорю о стоимости его запуска !
А какие еще претензии к Saturn V кроме большой стоимости запуска? Есть еще какие-то недостатки?
В любом случае, ракет с аналогичной грузоподъемностью, но с меньшей стоимостью запуска как не было тогда, так и сейчас нет, так что о чем весь этот разговор?
G>В результате на всех тяжелых американских носителях стоят российские двигательные системы, ибо американские, как раз вследствие свонй чрезмерной сложности, не обеспечивают необходимой надежности.
Да неужели? Какие там, в США новые средне-тяжелые ракеты? Atlas V и Delta IV. Да, в первой ступени и бустерах тяжелой конфигурации Atlas V установлен РД-180, но у Delta IV — RS-68 — не русский, а очень даже Rocketdyne. Эти же двигатели (RS-68) предполагается устанавливать и на Ares V. Что характерно, утверждение о низкой надежности (да еще и проистекающей из завышенной сложности) американских двигателей также высосано из пальца.
Зачем же обманывать читателей? Ай-ай-ай, нехорошо!
По теме спора: да, при решении определенного круга задач простое решение может превосходить сложное, но ведь очевидно, что огромное количество задач простыми средствами вообще не решаются. Именно поэтому и нужно делать просто, как только возможно, но не ПРОЩЕ.
Кроме того, на самом деле нет никакой простой зависимости сложность-надежность. С ростом сложности надежность может и уменьшаться и возрастать. Например, можно строить сложные системы из простых элементов так, что надежность всей системы будет превосходить надежность элемента, при том, что, разумеется, naive реализация системы, для которой вероятность работы без сбоя будет произведением таких вероятностей для элементов — со всеми вытекающими — является как раз самой простой.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, aka50, Вы писали:
G>>Кстати, пока никто не привел примера того теста, который ловит только ошибку типизации, но не ловит функциональных ошибок — т.е. теста, который можно выкинуть. Это мифические, неуловимые тесты, которых никто в глаза не видел, но все уверены, что их можно выкинуть.
A>
A>def f1(o)
A> o.init
A>end
A>def f2(o)
A> o.init
A>end
A>class C
A> def init
A> ...
A> end
A>end
A>class D
A> def init
A> ...
A> end
A>end
A>
A>В приведенном выше коде я хочу переименовать метод C.init в C.init2. Что будет? В статике я это отловлю на уровне интерфейсов (или трейтов если это допустим scala), как я отловлю проблемы тут? Далее, как я обнаружу проблему, что класс D тоже имеет метод init и вообще-то должен быть переименован? Или не должен? (возможно есть другие функции f3 f4 но туда С не передается никогда, а D передается... и даже возможно он может передаваться и в f1 и в f2, но IDE этого знать не сможет, ибо это даже разработчик сходу может не знать )
A>В статически типизированном языке не нужно проверять все комбинации вызовов функций f1 и f2 со всеми возможными классами C и D ... В динамике нужно. (допустим C и D это "стратегии", которые проверяются отдельно и потом могут комбинироваться в рантайме).
Что ж, давай посмотрим, что мы имеем в динамике. В динамике мы имеем две полиморфные функции f1 и f2, которые предполагают от своего аргумента наличие функции init и ничего кроме. Плюсовик завел бы шаблонну функцию и гордо заявил, что занимается generic programming, как завещал сам Степанов. Ну да это лирика. В С++ компилятор поймет, что реализации init у аргумента нет, и даст по рукам. Все, что надо сделать нам — это написать тест, вызывающий каждую строчку, где стоит вызов функций f1 и f2. Т.е. для отлова твоей ошибки у нас тот код, который вызывает f1 и f2, должен иметь адекватное покрытие. И все. Меньшее покрытие, кстати, все равно в статике делать нельзя — у тебя нетестированный код попадет в релиз.
Попытка оттестировать обобщенные функции f1 и f2 со всеми возможными вариантами типов аргументов (их бесчисленное множество — функции-то полиморфны) понятное дело — обречена на провал, так никто не делает. Делать так глупо, да и не нужно — тестирвать с хорошим покрытием надо неполиморфный вызывающий код, этого достаточно. Тот факт, что функции f1 и f2 обобщенные — это вообще то огромный плюс, а не минус — считайте, что у вас все темплейт, да еще и работающий в динамике. Это само по себе чрезвычайно мощное средство — осознание этого факта позволяет немного по другому, не так как в статике, структурировать код — его можно сделать менее связным и более обобщенным, не свернув при том себе шею.
A>>>И более того, статически типизированный язык позволяет реализовать фишки (типа изменений интерфейсов, изменений сигнатур методов, extract/convert операции для классов/интерфейсов) которые автоматизируют (типобезопасно) часть операций при таком глубоком изменении кода. G>>Сомнительно. Взять хотя бы изменение сигнатур методов. В каждом месте, где происходит вызов, придется ручками править и глазками проверять работу с новым или изменившимся аргументом. У вас правильный код для оформления измененного вызова по мановению волшебной палочки не появится. А раз так — лучше мне перед глазами этот список иметь, и делать правки руками вызывающего кода целиком, глядя, что получается, чем полагаться на слепую автозамену хрен знает где во всем коде, чтобы потом концов не собрать (если она будет "с элементами исскуственного интеллекта" — это еще хуже. Как это не парадоксально — излишне умные штуки становятся источником ошибок, когда люди начинают на этот "интеллект" полагаться). A>Ничего тут волшебного нет, в той же IDEA она требует дать еще и параметр по умолчанию и я могу указать какой-то несуществующий и получить некомпилируемый код во всех случаях где я не указал правильное входное значение. Дальше, обычно системы рефакторинга дают возможность просматривать ожидаемые изменения и править по месту (в той же IDEA). Т.е. тут все не так плохо... а вот в динамике отловить изменившийся метод уже гораздо сложнее...
Казалось бы так. Тем не менее, как показывает опыт разработчиков на динамике, эксперименты и изменения кода на динамике делаются быстрее, и циклы проектирование-реализация там существенно короче, чем на статике. Более легкое экспериментирование и более короткие циклы прототипирования являются признанным преимуществом динамики при обсуждении в usenet-овских конфах и мэйллистах, на этом люди сходятся, насколько я помню. И это при отсутствии средств "рефакторинга".
Насчет изменения методов — описанная вами проблема замечательно решается конекстным поиском. А ошибки, которые не нашел компилятор, вылавливается потом простейшими regression-тестами.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, aka50, Вы писали:
A>>Здравствуйте, Gaperton, Вы писали:
G>Что именно у тебя будет проверено компилятором в статике? У тебя цикл — тебе хоть в статике, хоть в динамике для ловли функуиональных ошибок нужно для циклов минимум три теста — пустой список, список из одного элемента, список из нескольких элементов. Как ты не поймешь — тебе придется код накрыть тестами независимо от вида типизации, если твой код не наколенная поделка. Аргументы в духе "а я свой код не тестирую, мне компилятор ошибки ловит" — означает, что у тебя в коде на самом деле дофига ошибок (ошибки типизации это примерно 5-10% от всех ошибок). Можно конечно радоваться, что ошибок типизации там нет, это конечно очень круто, но дела не меняет. G>Процент ошибок типизации относительно небольшой — функциональные, алгоритмические, и ошибки дизайна более трудоемки в исправлении и их в разы больше. Их тебе компилятор не выловит. Тебе придется сделать хорошее покрытие тестами — а оно выловит тебе все ошибки типизации без всяких дополнительных затрат на тестирование. Я не понимаю, как такая простая мысль тут ни до кого не может дойти — уже в третий раз объясняю.
Ща попробую пояснить про что я на примере кода на java:
/** listener SHOULD support init() method!!!! */class Subject {
List<Object> _listeners;
void addListener(Object o) {
_listeners.add(o)
}
void initListeners() {
for (Object o: _listeners) {
invokeMethod(o, "init")
}
}
}
Теперь в каком-то компоненте на другом конце земного шара другая команда пишет:
/** @see Subject they claims, that void init() method is mandatory */class MyObject {
void init() {
/// very important code
}
}
Subject subj = getSubjectFromSomewere()
subj.addListener(new MyObject())
Итак, как будем тестить? Сейчас я тестирую компоненты отдельно, достаточно реализовать правильный интерфейс. В случае динамики появляется еще одна дополнительная составляющая, которая обязывает меня помимо 100% функциональных тестов иметь еще и integration тесты со _100%_! покрытием (ведь этот цикл может вызваться только например при возникновении некой ошибки и очень редко).
G>>>И все. Меньшее покрытие, кстати, все равно в статике делать нельзя — у тебя нетестированный код попадет в релиз.
Не улавливаю связи. В статике я отедельно проверю цикл (допустим с 1-2 mock объектами реализующими нужный интерфейс и бросающие по заказу разные ексепшины или ведущие себя не так как надо и отдельно протестирую классы с этим методом init тоже в различных удобных мне состояниях, но тестировать это цикл со списком содержащим _все_ возможные классы мне нет необходимости, в динамике есть!
G>Разработчик библиотеки может и должен знать, называется метод init или init2. Его расширение к моему софту должно соответствовать моей спецификации — это раз.
Красота, вместо спецификации в виде жестких типов имеем спецификацию в "свободной форме".... И еще к спецификации надо не забыть приложить MySoftTestingIntegrationFramework
G>Два — не по теме, но ты сам уже начал от нее отступать. Ты знаешь, как раельно резолвится указатель на функцию в dll? Так, к слову о разработке библиотек. Указатель получается специальным вызовом по имени функции. То есть, его расширение — устаревшая версия либы реально упадет в рантайме. Не смотря на очень статическую типизацию.
Я знаю как чего резолвиться и в dll и в so. И знаю почему для расширений используется C, а не С++, я много еще чего знаю ибо наелся по уши, но к С++ это не относиться в той степени как к java/C#. С++ как я написал выше зависит от .h файлов и требует перекомпиляции в большинстве случаев. Java и C# имеет гораздо больше возможностей к гарантиям на уровне статики (ClassCastException или instanceof запросто спасет еще в момент загрузки, хотя тоже не идеально, но все же лучше чем в C++).
G>Кстати, та же "проблема" произойдет у тебя в яве при попытке подцепить компоненту с неправильным интерфейсом в рантайме. Полезут эксцепшены — нельзя мол к правильному типу привести. У нас же очень в моде компонентная разработка, да? Несовершенство рантайма не отменяет плюсов статической типизации и недостатков динамической... Рантайм можно заставить это делать (ввести версионность интерфейсов или еще чем обвесить), а вот динамику никаким костылями не вылечишь... Только глобальными интеграционными тестами (функциональных недостаточно)
G>А пришли мы к тому, что моих объяснений ты не понял — все что было по существу ты пропустил, оствил вырванные из контекста фразы. К тому, что прогрессивная общестенность не привыкла тестировать свои программы — в принципе этого никогда не делали видать, а динамика оказывается вынуждает нас писать какие-никакие тесты. К тому, что ничего нового прогрессивная общественность для себя узнать не хочет, как и вникать в суть проблемы. Ладно.
А я где-то писал, что не использую тестов со 100% покрытием? Или что они не нужны? Я писал о том, что за счет статики можно обойтись integration тестами без 100% покрытия (функциональные должны быть 100%).
Здравствуйте, eao197, Вы писали:
E>Вот какой рефакторинг действительно вызывает сложности, так это изменение структур данных. Например, где-нибудь раньше использовался объект какого-нибудь типа Description, а затем пришлось заменить его на MetaDescription, в котором Description является всего-лишь атрибутом. Вот тогда приходится полазить по исходникам с тем, чтобы определить, где и чего используется -- анотаций-то типов нет.
Не во всех динамических языках так. В Эрланге, например (тема все-таки о нем), такой рефакторинг будет проще, так как там применяется следующий подход.
1) Структуры данных, применяемые внутри модуля — делаются обычным образом, без объявлений.
2) Разделяемые структуры данных, которые используются в нескольких модулях, принято объявлять в отдельных модулях с применением конструкции record. Который устроен таким образом, что несложно отследить все места применения рекорда определенного типа (тэга). Да, при этом record — динамический тип. Т.е. record — это тэгированный атомом набор именованных полей произвольных типов.
Касательно структур данных — проблема решена.
При этом, при отсутствии вызываемой функции в модуле (module:wrong_function) компилятор выдает ошибку. При раелизации коллбэк-интерфейса за отсутствие правильных коллбэков компилятор дает по рукам. Таким образом, ситуации, когда функции не совпадают на межмодульных интерфейсах, на которых был сделан акцент в критике, нас тоже не беспокоят.
А вот все остальное — уже спокойно и неторопливо вылавливается функциональными тестами. А вообще — разговор это достаточно беспредметный. На динамических языках пишут сложные системы высокой надежности работающие в режиме 24х7. Никакого тотального ахтунга, которым тут пугают, не происходит. Точка.
И более того. Рассуждать о теоретической ненадежности динамики можно сколько угодно — только это несколько глуповато, учитывая, что практически работающий софт на динамическом Эрланге превосходит по надежности аналогичный софт писанный на статических языках и обходится в разработке дешевле. Я говорю о применениях в телекоме.
Произошло это благодаря или вопреки динамике — неважно, важно что динамика надежности не мешает, что доказано индустриальными применениями. И это объективный факт. Происходит это вопреки представлениям некоторых участников форума или нет — мне не очень интересно. Для меня убедительнее работающая железка с миллионом строк на динамике и процентом отказав в 9 девяток, чем смутные страхи и опасения уважаемых участников форума.
Здравствуйте, aka50, Вы писали:
A>Ну вот убейте меня, но не понимаю я, почему именно в динамическом языке люди совершают меньше ошибок?
Объем кода по сравнению с C++/Java не просто маленький, а очень маленький. Соответственно, проще держать его в уме, соответственно, меньше ошибок допускается.
А сравнение идет с C++/Java потому, что это промышленные и широкораспространенные платформы, которые можно брать и использовать практически для любых задач. Есть и другие хорошие языки (Eiffel, Modula-2, Ada, к примеру). Только вот не получится на них взять и так просто серьезный проект стартовать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, aka50, Вы писали:
A>>Ну вот убейте меня, но не понимаю я, почему именно в динамическом языке люди совершают меньше ошибок?
E>Объем кода по сравнению с C++/Java не просто маленький, а очень маленький. Соответственно, проще держать его в уме, соответственно, меньше ошибок допускается. E>А сравнение идет с C++/Java потому, что это промышленные и широкораспространенные платформы, которые можно брать и использовать практически для любых задач. Есть и другие хорошие языки (Eiffel, Modula-2, Ada, к примеру). Только вот не получится на них взять и так просто серьезный проект стартовать.
Тогда и надо говорить, что рулит erlang (удачно спроектирован) и smalltalk (древний), а Java (ущербно упрощена, та же scala или clean отлично демонстрируют что могло бы быть по другому) и С++(ну... сами знаете) в заднице. Но при чем тут динамика/статика — я не понимаю . Да и распространенность чего-либо не является его неоспоримым плюсом (пример: жигули vs майбах).
Здравствуйте, Курилка, Вы писали:
К>Спорно, вопрос личных предпочтений, или ты вслед за Владом пойдёшь воевать в пользу [head|tail] против [x|xs]?
На счет "вслед за Владом". Влад, как бы, не видит огромной разницы между этими вариантами если речь идет о приложении. Я говорил эти слова о примерах в книгах для начинающих. Там действительно это важно. Рассказы о i, j, k в императивных языках не катят хотя бы потому, что о этих именах сразу упоминют в тех самых книгах, а вот о x|xs — нет. Причем i, j, k используются в довольно понятном конексте, а x|xs в паттерн-матчинге который для непосвященного темный лес. Ведь переменные появляются ниоткуда и нязнамо как.
А для приложений надо бы задавать разумные имена (если это конечно не абстракные мат.алгоритмы).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, aka50, Вы писали:
A>>Тогда и надо говорить, что рулит erlang (удачно спроектирован) и smalltalk (древний), а Java (ущербно упрощена, та же scala или clean отлично демонстрируют что могло бы быть по другому) и С++(ну... сами знаете) в заднице. Но при чем тут динамика/статика — я не понимаю . Да и распространенность чего-либо не является его неоспоримым плюсом (пример: жигули vs майбах).
E>Ну так я и говорю, что на надежность влияние как статики, так и динамики, весьма косвенная.
Я привел отсуствие влияния в данных разговорах (типа а вон скока на ерланге написано), но это не отменяет другие мои мысли про ненадежность динамического кода. Таким образом я вполне допускаю, что будь ерланг статически типизированным — он был бы еще надежнее (хотя наличие проверки сигнатур експортируемых функций — уже фича статически типизируемых языков).
E>А вот распространенность играет важную роль для уменьшения рисков провала проекта: E>* при причинам отсутствия качественных библиотек/инстрементов; E>* из-за невозможности найти квалифицированных разработчиков.
По этому надо выбирать не столько язык, сколько платформу... Например если мне понадобиться в scala какая-то функциональность я без особых проблем возьму ее из мильона готовых библиотек, а вот что я буду делать, если мне нужно что-то будет для erlang-а или D? Чтобы не быть голословным: например готовая платформа типа Eclipse замечательно может использоваться как фреймворк для написания клиента, а логика уже может быть написана на scala.
Здравствуйте, IT, Вы писали:
G>>Как программист. На предыдущей работе я 6 лет занимался развитием большой легаси-системы на С++, на основании этого опыта и говорю.
IT>Понятно. Это можно прокоментировать следующим образом.
IT>1. C++ сам по себе язык, для которого создание человеческих средств рефакторинга, да и вообще нормальной поддержки IDE, крайне затруднено и, в результате, такие средства для C++ программистов недоступны.
Кое-что есть. К студии была какая-то хреновина — Visual Assist. Прикольная штукенция, но при нормальной организации и оформления кода без нее и ей подобных легко можно пережить. Хоть разные интеллектуальные переименовывалки — прикольные и полезные штуки, но от них больше фана чем реального сокращения сроков разработки.
IT>2. При развитии легаси системы, тем более большой, одним из основных принципов является принцип "не навреди". Следовательно, ни о каком глубоком рефакторинге речи быть не может. А для несложных случаев поиска с заменой действительно хватает.
Ты совершенно прав — подавляющее большинство людей не умеют вести разработку в рамках легаси, им это кажется невозможным. Это конечно очень круто, что в CQG должны быть "случаи несложные" а о "рефакторинге не может быть и речи". Только компании CQG не до подобных размышлений — ее основной продукт CQG for Windows был создан в 90 году, и с тех пор успешно развивается эволюционным образом. Просто люди делятся на две категории — одна из них, довольно малочисленная, умеет вести разработку в рамках легаси, при этом не вредить, и знает что такое глубокий рефакторинг (это не есть невозможно — просто для перечисленного требуется действительно высокая и специальная квалификация), а другая — нет.
IT>С другой стороны, сегодня для языков для которых реализована качественная поддержка IDE, набивка кода перестаёт быть работой машинистки и превращается в роботу, скажем, гончара, когда код не просто пишется, а вылепливается. Так, например, на C# у меня сегодня стадия проектирования просто напросто отсутствует.
Занятно. Для меня набивка и правка кода никогда не занимала настолько много времени, чтобы быть проблемой. А отсутсвие стадии проектирования я считаю жирным минусом. Впрочем, на этапе проектирования никто не запрещает писать код.
IT>Хотя трудно сказать, что отсутствует, стадия проектирования или стадия реализации того, что напроектировано, т.к. эти вещи у меня полностью совмещены. Я проектирую прямо в коде.
Для простого софта такого подхода действительно хватает. В сложных случаях такой подход слишком часто приводит к полному провалу проектов на стадии ближе к концу и потере контроля над разработкой (причина, разумеется, в том, что в голове перестает умещаться сложность системы, а не в ошибках при масштабных переименованиях функций и переменных). Что я неоднократно наблюдал.
IT>Это возможно потому, что я не боюсь ошибится и потом кое-что переделывать.
А я стараюсь не ошибаться и свести будущие переделки к минимуму.
IT>При этом последнее время приходится много писать на jscript. Причём не примитивного кода из серии window.open(), а нормальную такую логику с объектами и прочей функциональщиной. С одной стороны, я сильно зауважал скрипты вообще и jscript в частности, т.к. даже не подозревал, что на нём можно делать такие вещи. С другой, при набивке кода я чувствую себя именно машинисткой, которой при наборе текста нужно всё по десять раз проверять, иначе потом придётся искать ошибку вручную, т.к. у неё нет даже элементарных средств автоматической проверки орфографии.
Если ты пишешь на JScript.NET, то тебе никто не запрещает проставлять типы, если хочется. Там можно. Во-вторых — разве ты не в Visual Studio пишешь?
Ну а что касается меня — иметь хорошую IDE — безусловно удобно, что тут спорить. Но для меня это не критично — достаточно подсветки синтаксиса, нормальной работы с отступами. Видимо, у меня подход к кодированию и разработке отличается от твоего — я пишу наверняка, чтобы свести переделки к минимуму. Включая переименования идентификаторов.
Gaperton,
G>В таком языке у нас реально стирается грань между статикой и динамикой. Красиво. Жаль я не студент и не аспирант — такой дипломище бы забабахал...
И получился бы боян. В DYLAN есть опциональная статическая типизация, так что для дилановца спор "ST vs DT" абсурден по определению. Для него типизация больше напоминает отрезок [0,1] — выбирай любую точку, наиболее подходящую для твоего приложения.
E>гораздо выигрышнее оригинального варианта. Даже при том, что я лично предпочитаю [h|tail] вместо [head|tail] и to_s вместо ToString.
Ну, в данном случае переменные M,F,D локальны в пределах двух строчек. Оттого я и сократил их до инициалов. В том примере для другой посылки используются более вразумительные имена, так как там они локальны в целых 6-и строчках.
Подход к именованию у меня именно такой — где коротко, там и имена короткие.
Здравствуйте, Klapaucius, Вы писали:
K>Дело вот в чем: gandalfgrey сначала утверждает, что использовать "непереносимые средства"(sic!) согласно его опыту, вообще нельзя. Это уже достаточно сильное, вплоть до абсурдности, утверждение, что характерно.
Согласно моему опыту, использовать непереносимые средства действительно очень стремно. Так что я здесь согласен с gandlfgrey.
Что же касается Mono, то вопрос не столько в том, считать ли его существующим или подсчитывать количество реализованных в нем фич из MS .Net. Это другой вопрос. Основной же вопрос в том, если ли у вас уверенность в том, что сейчас Mono является достаточно качественной и стабильной реализацией CLI для того, чтобы ставить на него собственную зарплату и успешность собственных проектов?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, aka50, Вы писали:
A>Логика проста если посмотреть на конкурентов: A>* Ruby/Python — основная реализация открыта и может быть портирована при необходимости, планирование фич производится авторами, все основные библиотеки открыты и теоретически чисты в плане патентов.
см. ниже.
A>* Java — ...
Так, а при чем тут Java? Я про Ruby спрашивал. А это все из серии "А у меня брат — матрос, он завтра придет в школу и тебя побьет!"
Превосходство Java над Mono, по большинству параметров у меня сомнения не вызывает. Там есть, конечно, свои нюансы, но это тема для отдельного разговора.
A>Чем из этого может похвастаться mono? A>Переносимость между самим собой (т.е. mono рантайма) — да.
Собственно дальше можно и не продолжать. Весь этот спор начался с того, что утверждалось "нет" без всяких оговорок.
A>Но A>- фреймворк, который по сути сплошной реверсинжиниринг
Это безответственное утверждение. Есть стандарт.
A>— фреймворк вечно догоняющий и не имеющий никакого влияния на основную ветку
Совершенно верно.
A>— несовместим с основной веткой от MS (точнее есть нехилый зазор между поддерживаемыми фичами) и часть фич принципиально отсутсвует, например CAS
Да, это серьезный недостаток.
A>— возможные проблема с патентами
Фактически эта фраза семантически эквивалентна преведенной выше "теоретически чисты в плане патентов" — но звучит, конечно, гораздо страшнее. Да, патентный троллинг вообще серьезная угроза, но превосходство Ruby в этом плане совершенно неочевидно.
A>— большинство готовых решений пишутся под ОС Windows и работа их под mono абсолютно не гарантированна
Да.
A>— mono-develop нельзя и близко сравнить не то что с Intellij Idea / Reshaper, но и с чистым Visual Studio
Опять появляется брат-матрос. Ну расскажите, насколько альфа-плагин для Ruby и Idea круче mono-develop.
A>Мне лично этого выше крыше хватает чтобы не рассматривать mono как серьезную платформу. Гораздо проще взять python/ruby или jvm.
Тема превосходства Java над Mono раскрыта. Тема превосходства Ruby над Mono по качеству — нет. Это меня не очень устраивает потому, что спрашивал я как раз про второе.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, eao197, Вы писали:
E>Чтоже до стабильности (и косвенно о качестве) Mono, то достаточно посмотреть в ChangeLog:
E>http://www.go-mono.com/archive/1.2.2/ E>
E>Specifically, this release:
E>* 496 new methods implemented.
E>* 212 removed bogus TODOs.
E>* 65 removed NotImplementExceptions
E>Stats:
E>* 1,933 missing methods were implemented.
E>* 164 methods with pending implementations were fixed.
E>Мне как-то сомнительно, что стабильная платформа устраняет по несколько десятков не реализованных ранее методов в минорных релизах.
1) Не вижу сравнительной статистики.
2) Это имеет отношение, в основном, к повторению закрытых Майкрософтовских библиотек. А мы говорили, о качестве рантайма, нет? Даже в таком аспекте у Ruby должно быть преимущество по качеству хотя-бы потому, что naive interpreter и JIT по сложности реализации несопоставимы. Но вот только они и по функциональности несопоставимы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
G>Краткий курс "десериализации" в Эрланге. Это будет непросто, конечно не так просто, как "в нормальном строготипизированном языке", но я думаю, поднапрягшись можно что-то понять и научится этому непростому делу в динамике.
А Эрланг все же строго типизированый язык Только не статически типизированый
Здравствуйте, Аноним, Вы писали:
А>простите за глупый вопрос, а как делали связку между тиклевским клиентом и сервером? через сокеты?
Разумеется ! Система распределенная, части ее разбросаны по разным узлам, так что ничего, кроме TCP/IP, через сеть не пролезет
На тиклевой стороне использовалась сишная либа EI, которая идет вместе с OTP, и маленький переходник на плоском С в тикль. Он тоже не ручками был писан ( не весь ), а сгенерен при помощи приблуды CRITCL — она позволяет писать С код прямо внутри тикля, создает необходимые стабы и т.д.
G> Ежели говорить о внешних библиотеках, то ничего, кроме leex, не использовали. Это генератор лексеров, и очень удобный. Все остальные потребности с лихвой перекрывались самой OTP. Когда-то мы использовали SOAP и, соответственно, XML — но и это все в стандартной поставке присутствует.
эээ, xmerl знаю, а SOAP откуда в OTP появился — просвети, плизз
Кстати Ульф (вроде или Тоббе) говорил, что xmerl далеко не лучший парсер, у себя там они свой парсер юзают, правда публично он не доступен.
G> — не возможности автоматически заставить кодописателя производить генерализацию и обобщения функций. У нас в системе сейчас поддержано около 90 типов запросов, и во многих случаях на каждый из них написана функция из 10-15 строк, которая почти не отличается от других таких же. Но это, конечно,
проблема не конкретно Ерланга — он всего лишь способствует этому из-за краткости кода.
А можешь на словах пояснить, в чём суть? Почему нельзя было обобщённые функции сделать?
Здравствуйте, Курилка, Вы писали:
К>эээ, xmerl знаю, а SOAP откуда в OTP появился — просвети, плизз
Ну, XML-RPC — но это же ничем от SOAPа не отличается К>Кстати Ульф (вроде или Тоббе) говорил, что xmerl далеко не лучший парсер, у себя там они свой парсер юзают, правда публично он не доступен.
А сейчас нам это не актуально — с сервера уходит стандартное сообщение, и приходит такое же. XML все ж какой-то замороченный, да и тормознутый ( особенно на клиенте ). Отказались мы от него, и не жалеем
К>А можешь на словах пояснить, в чём суть? Почему нельзя было обобщённые функции сделать?
Можно ! Но когда функцию быстрее и проще написать по-новой, не очень хочется раздумывать над обобщениями. Это чисто психологическая проблема
Здравствуйте, gandalfgrey, Вы писали:
G>А сейчас нам это не актуально — с сервера уходит стандартное сообщение, и приходит такое же. XML все ж какой-то замороченный, да и тормознутый ( особенно на клиенте ). Отказались мы от него, и не жалеем
А что ходит тогда у вас? Обычные эрланговые сообщения? Для чего вы соап-то использовали?
Здравствуйте, Курилка, Вы писали:
К>А что ходит тогда у вас? Обычные эрланговые сообщения? Для чего вы соап-то использовали?
СОАП мы использовали раньше. И это было так замороченно, что просто беда ( особенно на клиенте ).
То-есть мы засовывали данные в XML и отдавали их клиенту — или наоборот.
Сейчас ничего этого нет. Просто сообщения. Мы получили выигрыш еще и со стороны уменьшения трафика на гнилых соединениях, типа модема. Соответственно, большая экономия времени передачи данных.
Здравствуйте, gandalfgrey, Вы писали:
G> Приветствую всех !
G> Тут несколько раз поднимался вопрос о возможности и оправданности написания бизнес-логики на функциональных языках. Так что могу внести свою лепту в оное обсуждение. Распределенная система на Ерланге / Тикле, кою мы ваяли последние 1.5 года, начала продаваться. Пока только избранным покупателям, ибо еще есть разного рода сырости, но в течении месяца мы ее, полагаю, высушим. G> Кратко о самой системе : ядро системы + логическая обвязка ( бизнес-правила ). Сам движок остается неизменным для всех областей применения, меняется только обвязка. Нынешняя обвязка предназначена для использования в паспортных столах любых муниципальных образований.
Не порадуешь дизайн-документом, описывающим общую архитектуру?
Здравствуйте, gandalfgrey, Вы писали:
G>СОАП мы использовали раньше. И это было так замороченно, что просто беда ( особенно на клиенте ). G>То-есть мы засовывали данные в XML и отдавали их клиенту — или наоборот. G>Сейчас ничего этого нет. Просто сообщения. Мы получили выигрыш еще и со стороны уменьшения трафика на гнилых соединениях, типа модема. Соответственно, большая экономия времени передачи данных.
Дак если у вас всё "родное" и на Эрланге, то резона соап юзать я не вижу, только если красивые плакатики с буковками SOA рисовать
Вот если бы были внешние системы, то уже можно было бы подумать, хотя тоже SOAP имхо только для "дырки наружу" использовать смысл имеет.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>Не порадуешь дизайн-документом, описывающим общую архитектуру? G>Вот бы он еще был, этот документ, в собранном виде.... Сейчас архитектура описывается кучей бумажек, каждая из которых состоит из призывов, лозунгов и запретов, и в целом похожа на речи Геббельса. Типа, "Вы сами хотели тотальной войны !" (с) G>То-есть везде разбросаны мааааленькие кусочки того, как надо делать, как не надо делать, и какие принципы должны соблюдаться. Например, правила обработки ошибок для бизнес-логики : G> — ежели набор входных данных формально правилен, но не соотвествует реально хранимым данным, то это обрабатывает бизнес-логика G> — во всех остальных случаях запрос от клиента ДОЛЖЕН скончаться в муках, а клиентская прокся это обработает сама
G>Или отложенная обработка правил в соответствии с моделью : G> — с каждой итерацией множество отложенных правил сужается G> — не обрабатывать это специальным образом, ибо если это не так, то это ошибка предметной модели, и сервер все равно сделает лог все этого при издыхании соединения с клиентом
G>Собрать все в одну кучку надо....но ручонки не доходят совершенно
Да лана. Просто схему процессов, и отметить отношения между ними — кто кого супервайзит, кто — листенит, кто кому мессаги шлет. Нотация UML для диаграммы классов подойдет, ассоциации подписываем стереотипами.
Здравствуйте, Курилка, Вы писали:
К>Дак если у вас всё "родное" и на Эрланге, то резона соап юзать я не вижу, только если красивые плакатики с буковками SOA рисовать К>Вот если бы были внешние системы, то уже можно было бы подумать, хотя тоже SOAP имхо только для "дырки наружу" использовать смысл имеет.
Дык ить ! Сейчас у нас СОАП и не используется. Для внешних систем есть Сишная либа, которая реализует ерланговский протокол.
Или речь о том, почему СОАП вообще стали приделывать ?
Здравствуйте, gandalfgrey, Вы писали:
G>Дык ить ! Сейчас у нас СОАП и не используется. Для внешних систем есть Сишная либа, которая реализует ерланговский протокол.
А если внешняя система на Java? Есть, конечно, jinterface, да и слишком теоретически, нет потребности — нет задачи
G>Или речь о том, почему СОАП вообще стали приделывать ?
Ну вообще это были просто "мысли вслух"
Но, если не секрет, то интересно и почему вообще
Здравствуйте, EvilChild, Вы писали:
G>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого EC>Можно об отквоченном попродробнее применительно к вашему проекту с примерами? EC>Просьба ко всем не развязывать очередной флейм на эту тему.
А ты серьезно хочешь получить обоснование для этого, брошенного в реламном пылу, лозунга?
Мужик просто заговорился. Со всеми бывает. Это конечно про то что касается надежных систем.
Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю удобным татику в хорошем языке в купе с хорошей IDE.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.
Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.
VD>>Мужик просто заговорился. Со всеми бывает. Это конечно про то что касается надежных систем. EC>У тебя есть основания считать, что система получилась ненадёжной? или неверить ему?
У меня есть четкие доказательства, что это утверждение ложно, потому что на базе статически-типизированных языков создано много надежных систем.
Откровенно говоря даже не хочется обсуждать столь очевидный и столь же абсурдный вопрос.
VD>>Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю удобным татику в хорошем языке в купе с хорошей IDE. EC>Именно. Мне со статической типизацией и хорошей IDE тоже как-то спокойнее и удобнее, но есть масса людей, которые делают полезные вещи другим способом. Вот мне как раз и интересно как они это делают на динамически типизированом языке.
Я же сказал, что этот вопрос спорный. Потому к нему у меня претензий нет. Я с ним не согласен, но это обсуждаемый вопрос.
EC>P.S. Ты таки не удержался от флейма
Где ты видишь флэйм? Бред он и есть бред. Осуждать тут нечго.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EC>>Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.
VD>Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.
Что фанатичного ты увидел в ней?
VD>У меня есть четкие доказательства, что это утверждение ложно, потому что на базе статически-типизированных языков создано много надежных систем.
И есть доказательство, что на динамически-типизированных ничего сложного создать нельзя?
VD>Откровенно говоря даже не хочется обсуждать столь очевидный и столь же абсурдный вопрос.
Так к чему ты влез вообще, если по теме сказать нечего?
EC>>P.S. Ты таки не удержался от флейма
VD>Где ты видишь флэйм? Бред он и есть бред. Осуждать тут нечго.
В твоём посте нет никакой полезной информации по заданному вопросу, один ничем не аргументированный негатив.
Это даже хуже флейма.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, EvilChild, Вы писали:
EC>>Это видимо вопрос восприятия: я не заметил в посте рекламы. Человек делится впечатлениями, полученными при применении erlang в реальном проекте.
VD>Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии.
..а лечить по фото не пробовал? склонность заметна шутка.
Реклама или не реклама — это вопрос названия. Тут другое интересно. Этот эрланг оставляет у большинства исключительно положительные эмоции после практическиого применения.
VladD2 wrote: > Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю > удобным татику в хорошем языке в купе с хорошей IDE.
Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как
там можно жить без динамической типизации.
Хотя статические интерфейсы иногда там бы не помешали.
Здравствуйте, Cyberax, Вы писали:
C>Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как C>там можно жить без динамической типизации.
C>Хотя статические интерфейсы иногда там бы не помешали.
Ну по идее есть Dialyzer, который вводит некоторую долю статической проверки. А где именно ты видишь необходимость статических интерфесов?
Курилка wrote: > C>Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как > C>там можно жить без динамической типизации. > C>Хотя статические интерфейсы иногда там бы не помешали. > Ну по идее есть Dialyzer > <http://www.it.uu.se/research/group/hipe/dialyzer/>, который вводит > некоторую долю статической проверки.
Знаю, суперрулезная вещь.
> А где именно ты видишь необходимость статических интерфесов?
Как обычно — во взаимодействии с либами (внешними и внутренними). То
есть с кодом, который редко меняется и нечасто требует runtime-полиморфизма.
Здравствуйте, EvilChild, Вы писали:
VD>>Приведенная фраза выдает явную фанатичность. Так что разбирайся в своем всоприятии. EC>Что фанатичного ты увидел в ней?
Оно настолько явно не соответствует действительности, что сказать его мог только фанатик уже не различающий где добро, а где зло. Это вера, а не знание.
VD>>У меня есть четкие доказательства, что это утверждение ложно, потому что на базе статически-типизированных языков создано много надежных систем. EC>И есть доказательство, что на динамически-типизированных ничего сложного создать нельзя?
Этого и не нужно. Хотя мое лично мнение как раз заключается в том, что статика очень способствует созданию комлексных приложений, но в данном случае это не важно. Важно то, что даже если на динамике можно создавать сложные приложения (т.е. я не прав в этом аспекте) — это никак не вылияет на возожность создавать сложные приложения на статике. Understand?
Вообще это азы логики. Причем не какой-то там сложной матиматической, а примитивной человеческой логики. И мне казалось, что любой вменяемый человек должен это понимать.
Нет никакого смысла пускаться в обсуждение спорного вопроса вроде "можно ли создавать на динамике большие и надежные приложения", так как утверждение уже ошибочное. Насколько я знаю есть масса надежных приложений написанных вообще на С/С++ (т.е. не только на сквозь статически типизированных, но и очень небезопасных языках). Один этот факт опровергает это утверждение.
В общем, извини, но разжевывание логики уровня детсада мне не нинтересно. Если ты тоже фанатик или просто не умешь мыслить логически, то это не ко мне. Для меня бредовость этого утверждения очевидно. И не только для меня.
VD>>Откровенно говоря даже не хочется обсуждать столь очевидный и столь же абсурдный вопрос. EC>Так к чему ты влез вообще, если по теме сказать нечего?
Меня откровенный бред всегда веселит. А когда его начинают защищать, раздражает.
EC>В твоём посте нет никакой полезной информации по заданному вопросу, один ничем не аргументированный негатив.
Нет. В моем сообщении как раз есть полезная информация. Информация для тех, кто пока что не может быстро отличить бред и рекламщину от фактов. Дело в том, что фанатики как раз и появляются под воздействием вот такой залихватской бредятины. Поверил человек (не опытный пока), что "да и не построить надежную систему без этого (динамики)", увлечется динамикой, приуспеет в этом, и начнет нести эту чушь уже на полном серьезе и совершенно не понимая, что несет чушь. А так он подумает и даже если займется динамикой, то уже будет рассуждать несколько более трезво.
EC>Это даже хуже флейма.
У меня другое мнение по этому поводу.
ЗЫ
Ничего не имею против Эрлэнга и расказов об опыте его успешного использования (как в прочем и расказах о любом друго средстве), но вот такие фразы (пусть даже брошенные в пылу) сразу делают для меня мнение бросившего их человека не очень серьезным. Так что если кто будет так же делиться опытом, что очень хотлось бы, чтобы было по больше фактов и цифр, и по меньше вот таких вот очевидно абсурдных заявлений.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> Что же касается "удобно", то это вообще вопрос вкусов. Лично я считаю >> удобным татику в хорошем языке в купе с хорошей IDE. C>Я немного писал на Эрланге, но честно говоря, тоже плохо представляю как C>там можно жить без динамической типизации.
Вообще-то это отход от темы и возраждение флэйма статика vs. динамика, нуда выскажуст, раз уж всем так хочется снова пофлэймить .
Эрлэнг спроектирован как динамический язык. Понятно, что используя именно его вряд ли можно серьзно говорить о статике. Слишком много концепций языка завязано на его динамиченсоть. Те же атомы просто немыслимы в статически-типизированном языке.
Однако самое интересно, что есть в Эрлэнге, на мой взгляд, — это программно-изолированные процессы и общение между ними по средствам сообщений. Ничего не напоминает? Правильно — Сингулярити . А Сингулярити основана на вполне статически типизированном дотнете (точнее клоне) и C# (точнее его клоне Sing#). Просто язык и рантайм расширили поддержкой нужных концепций. В итоге получилось очень похожее решение. Само по себе наличие подобной реализации говорит о том, что динамика не является обязательным ктитерием для использования подобного подхода.
C>Хотя статические интерфейсы иногда там бы не помешали.
Да без разницы. Это меня мало интересует. Эрлэнг не очень подходит лично для меня, так как я (как, кстати, и ты) люблю периодически заняться разными, довольно низкоуровневыми, вещами которые требуют высокой производительности от кода. Да и ошибаться по мелочи (очепятыватся) я люблю. Плюс я люблю хороший интелисенс. Так что мой путь однозначно статика. Понимаю, что есть люди которым динамика ближе. Но это не повод чтобы нести откровенную чушь. Я же не заявляю, что без статики нельзя создать надежную программу? Конечно можно. Хотя я считаю, что для больших систем хорошая статическая типизация — это отличное подспорье.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Так вот, одним из отличительных качеств таких динамически-типизированных языков, как Erlang и Ruby является горячая замена кода.
Начнем с того, что это не так. То же ASP.NET хотя и основано на статически-типизированном фрэймворке, но обеспечивает горячую замену кода.
По практие скажу, что сама по себе горячая замена кода еще не обеспечивает бесбойность работы софта. Всегда есть шанс, что заливаемый на сервер код содержит ошибки не выловленные "в лабороторных условиях".
Плюс, опять же по практике, перезапуск сервера может быть вызван банальными просчетами в дизайне. Например, для ускорения работы сервера файлы кэшируются, а нужно ты их меняешь и нужно проверить правильно ли ты их изменил. Конечо через 10 минут (к примеру) они перечитаются, но сидеть и ждать эти 10 минут нет никакого желания и проще перезапустить сервер. (пример из жизни, я так делаю когда меняю рекламные модули на сайте).
E> Т.е. возможность не только накатить патчи для исправления багов, но и существенно модифицировать уже работающую программу без останова оной существенно повышает уровень доступности системы. А значит благоприятно сказывается на надежности системы.
Не факт. Во-перых, кто определяет эту существнность? Скажем если сайт не будет виден 10 секунд, то это вряд ли кто-то даже заметит. Или если и заметит, то не придаст этому значения. А вот баг вылезший на этом сайте может остановить его работу на неопределенный промежуток времени. Ну, а пропустить баг в динамической системе все же проще. Так что тут все решают конеретные уловия.
Лично я считаю, что самый большой вред доступности лично нашего сайта приносят именно ошибки, а не что-то иное. Проблема в том, что под нагрузкой все работает совсем не так как без нее. Юнит-тестами такие проблемы не ловятся. Приходится пробовать на живом сервере. А это уже напрямую влияет на его доступности.
E>Disclaimer. IIRC, 'надежность' -- это отдельное понятие, которое включает в себя много факторов. 'Доступность' является только одним из них. Поэтому вышесказанное не следует воспринимать как формулу 'надежность' == 'доступность'.
Само собой. Кстати, самый надежный двигатель — это выключенный двигатель, обмазанный солидолом, гермитично упакованный и зартый глубого под семлю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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 за десять секунд наргузочного тестирования нагенерирует столько информации в логах и базах данных, что выявить в них тонкие аномалии вручную составляет сложную задачу.
По сравнению с объемом работы, который нужно проделать для организации нормального имитационного/нагрузочного тестирования с анализами результатов, различия в подходах к разработке на статике/динамике не так уж существенны.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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 как небо и земля.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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 ситация такая же.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Динамически-типизированный Ruby сам по себе является таким инструментом. E>Думаю, что с Erlang ситация такая же.
Ну если честно, то тут играет ещё эрлаговая ВМ, хотя можно ли её "отцепить" от языка — вопрос очень большой. Так вот, в ней заложено, что для любого модуля у нас может быть 2 копии — актуальная и та, которая выполняется в текущий момент (естественно, они могут совпадать). Естественно "серверная" функция модуля, которая вызывается рекурсивно, не должна менять свой интерфейс, хотя можно из неё сделать "stub", который бы трансформировал параметры и передал в новую функцию. Хотя, если честно сам такого не делал, за 100% точность не ручаюсь
Здравствуйте, deniok, Вы писали: D>Достоинство Ruby и Erlang, как я понимаю, в том, что поддержка горячей замены является частью стандартного фреймворка.
В python-е для этого используется встроенная функция reload. Для динамических языков это похоже сильно проще реализуется.
Лямбда Flt генерируется при старте сервера для каждого типа записей, чтоб при любом изменении внутренних структур данных и форматов записей в базе корректным образом доставать оттуда то, что заказано. Вся типизация ( динамическая, заметим) скрыта внутри. Это и есть пример достижения необходимой надежности
E>Не раскрыта тема, однако
Опасаюсь я бросать сюда большие или сложные куски — многое написано студентом, отчего код, мягко говоря, корявоват. Впрочем, попробую выскрести какие-то вразумительные обрывки.
Хотя — на кусках кода сложно передать причины моей убежденности в соотношении трудозатрат в написании систем с динамической и статической типизацией. Оная убежденность выросла в процессе построения и развития подобных систем ( эта — не первая, но самая сложная ). Другой пример — мои знакомые делают обвязку С++ софта тиклевыми скриптами для сложной обработки данных именно потому, что на С++ сделать это за разумные сроки совершенно нереально. Их С++ софт писался несколько лет. Обвязка на Тикле превосходит по сложности уже в несколько раз, и писалась несколько месяцев. Некая зависимость проглядывает, верно ?
Здравствуйте, palm mute, Вы писали:
PM>Пока из Ваших примеров видно, что статическая типизация С++ приносит много проблем, не обеспечивая должной надежности, с чем мало кто здесь будет спорить.
О том и речь ! Я не сравниваю со статической типизацией в Хаскеле — мне не нравится Хаскель, я на нем писал только маленькие примерчики, и не считаю себя достаточно компетентным для такового сравнения. Не сравниваю с Окамлом — найти / обучить людей ему несколько проблематично. Окамл, пожалуй, будет попроще, чем С++, но не так уж чтоб намного. Не сравниваю и с Сшарпом — ибо портабельность была и есть одним из основных требований. D ? Это просто гуманизированные ++. Жаба ? Я уже привел соотношение размеров кода — почти 2 порядка. По оценкам писателей этой системы, во многом за счет статической типизации в Жабе
Немерль ? Я пока не считаю его пригодным для промышленного использования.
Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?
Здравствуйте, gandalfgrey, Вы писали:
G>Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?
Object Pascal
Eiffel
Scala (если оставаться в рамках "Декларативного программирования"), хотя с учетом того, сколько багов фиксятся от релиза к релизу...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Курилка, Вы писали:
К>ML и "может"? К>Хотя вот о промышленных применениях чтот его не слышно. К>Но по сути интересная вещь, вроде как.
Это я к тому, что по описанию там как бы возможна и динамическая типизация. Оно же выросло из Mozart, как я понял из доки ?
А о промышленных применениях его думать рановато, как мне кажется — совсем сырое, аж капает.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>ML и "может"? G>Это я к тому, что по описанию там как бы возможна и динамическая типизация. Оно же выросло из Mozart, как я понял из доки ?
это расширение Standard ML, на моцарте были первые версии, да и моцарт тоже статически-типизированный
G>А о промышленных применениях его думать рановато, как мне кажется — совсем сырое, аж капает.
Да не знаю, давно вроде уже вижу этот язык, но чисто с теор. точки зрения вечно рассматривают.
Хотя 2002, что последнее в новостях — это не сильно много конечно, хотя всёж 5 лет
Здравствуйте, 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>Так вот лично меня интересует ваше мнение по поводу того, как динамическая типизация обеспечивает большую надежность (именно в смысле сохранения программой работоспособности в непредвиденных условиях)?
Я бы выразился в том смысле, что это экспириенс, и не только мой личный, но и кучки знакомых разработчиков, которые используют языки с динамической типизацией для повышения надежности и живучести систем. Выделить какие-то формальные факторы, которые однозначно дают положительный эффект, я просто затрудняюсь — разве что их комплекс, причем разный для разных языков : для Ерланга один набор факторов, для Тикля другой и т.д.
Здравствуйте, Курилка, Вы писали:
К>тьфу, тут я запарил, там 2002 — первая новость (т.е. последняя, если читать "с конца") К>Последние этого года. (3 мая новую версию выкатили)
( В раздумьях ) Пощупать, что ли, Алису за тугое вымя ? На предмет новых фич, но в основном на предмет стабильности
К>Oz — другой язык, поэтому он не может "вместе существовать", а mozart — runtime система для него.
Ну как ! Это и есть сосуществование в советском смысле этого слова
К>Вот там чтот давно ничего не появлялось — год назад последний релиз был в июне прошлого года. К>Да и активности тож какой-то не видать
Я и говорю — помалу...На этом рантайме вроде бы какие-то другие языки собирались развивать — но ничего об этом пока не слышно
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>тьфу, тут я запарил, там 2002 — первая новость (т.е. последняя, если читать "с конца") К>>Последние этого года. (3 мая новую версию выкатили) G>( В раздумьях ) Пощупать, что ли, Алису за тугое вымя ? На предмет новых фич, но в основном на предмет стабильности
Вопрос вылезет — сильно ли многословней будет статическитипизированный вариант и насколько "лёгкая" там параллелизация. Было бы круто увидеть хотя бы какое-нибудь минимальное сравнение
Здравствуйте, Курилка, Вы писали:
К>Вопрос вылезет — сильно ли многословней будет статическитипизированный вариант и насколько "лёгкая" там параллелизация. Было бы круто увидеть хотя бы какое-нибудь минимальное сравнение
О компактности кода не скажу, а процессы, как утверждают на основании отдельных тестов, вполне сравнимы с ерланговскими. ( На небольшом количестве процессов )
Здравствуйте, gandalfgrey, Вы писали:
G>О компактности кода не скажу, а процессы, как утверждают на основании отдельных тестов, вполне сравнимы с ерланговскими. ( На небольшом количестве процессов )
Ну если так, то за счёт статической типизации можно получить ускорение на алгоритмах с "числодробительной" составляющей.
А где ты читал про "утверждают"?
Хотя небольшое количество — эт как-то "неспортивно", но вопрос — сколько именно?
Здравствуйте, eao197, Вы писали: E>Я не думаю, что для подтверждения вашего тезиса о большей надежности динамически-типизированных программ над статически типизированными вообще нужно приводить фрагменты кода. Имхо, проще словами перечислить те факторы, которые по вашему мнению повышают надежность.
Есть примерно такие соображения про тип типизации:
Статическая типизация избавляет от ошибок типизации — это несомненный плюс.
Но она же заставляет согласовывать всё типы.
Т.е. Если мы в статическо-типизированном языке решили возвратить коллекцию, мы должны жестко зафиксировать тип этой коллекции. И согласовать с этим типом остальные интерфейсы.
Если потом, окажиться что выбранный тип коллекции нас не устраивает, мы становимся теред дилемой — либо добавлять в интерфейс нужный тип — и тем загрязнять его, либо менять старый тип на новый, что даже с поддержкой компилятора часто изрядно трудоёмко, как и любое нетривиальное изменение кода.
Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы.
Соответственно разработка обладает большей мобильностью.
Хотя, это вроде как призван решить вывод типов.
Насколько он это делает в том-же Haskell-е я не в курсе.
Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики.
P.S. Сейчас мы делаем проекты на Python + Qt.
Раньше на Delphi и С++
Пока, для нас, выигрышь очивиден.
Здравствуйте, Tonal-, Вы писали:
T>Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы. T>Соответственно разработка обладает большей мобильностью.
Опять же, речь не о мобильности, а о надежности.
Все же это разные вещи.
T>Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики.
Да ладно, стоит один раз нормально сделать , а потом использоваться без всяких заморочек.
T>P.S. Сейчас мы делаем проекты на Python + Qt. T>Раньше на Delphi и С++ T>Пока, для нас, выигрышь очивиден.
Я знаю об опытах перехода с Python+C++ на Java с не менее очевидным выигрышем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Mamut, Вы писали:
M>Извини Влад, но все это явный влейм и оффтоп.
Не хочется извинять.
M>
G>> — динамическая типизация. Удобно до безумия, да и не построить надежную систему без этого
M>Можно об отквоченном попродробнее применительно к вашему проекту с примерами?
M>Просьба ко всем не развязывать очередной флейм на эту тему.
M>Была просьба.
M>а) Пояснить, что имелось в виду M>б) Была просьба узнать мнение человека, который написал это M>в) Была просьба не развивать флейм
до более разумных. Понятие "надежность" потихоничку подменяется понятием "скорость разработки". Делается связь между надежностью исстемы и скоростью ее разработки. Тут уже есть о чем спорить. А исходная фраз — абстурд.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>А вот и примеры :
G>[code] G>% создает новый тупль по таблице имен и заполняет его полями G>fill_record_flds(Recname,Flds) when is_atom(Recname) -> G>... G>Кусочек очень простой, но он позволяет не держать в мозгу 2 РАЗНЫЕ функции, которые делают практически одно и тоже
Ну, а причем тут надежность то? Как ты понимашь этот термин?
Кстати, для сравки. Все тоже самое я могу делать на Nemerle с помощью макросов во время компиляции. Причем в отличии от тебя могу проконролировать надежноть произведя проверки еще во время компиляции и выдать соответствующую диагностику.
G>Варианты наращивались по мере усложнения системы, не затрагивая предыдущих случаев. То-есть ошибки привноситься в них просто НЕ могут
Ты говоришь о генерации кода. Она родимая никак не зависит от того является ли язык динамическим или нет. Я знаю людей которые генерируют C#-код из XML-описания на базе XSLT. Звучит как извращение, но по факту результат достигается такой же.
G>Есть и более сложные случаи, просто они несколько менее понятны с первого взгляда
Приводи, поглядим. Пока что ты твои примеры показвают, что ты весьма странно понимаешь термин "надежность".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>О том и речь ! Я не сравниваю со статической типизацией в Хаскеле — мне не нравится Хаскель, я на нем писал только маленькие примерчики, и не считаю себя достаточно компетентным для такового сравнения.
А не кажется ли тебе тогда, что если твоя компетенция в области статически-типизированных языков заканчивается на С++, то все же не стоит делать таких смелых заявлений по поводу надежности решений на динамических языках в сравнении с аналогами созданными на статических?
G> Жаба ? Я уже привел соотношение размеров кода — почти 2 порядка.
Ну, два порядка — это еще одно безответственное озаявление. Хотя согласен, что конечно код на динамическом языке с паттерн-мачингом по любому будет существенно меньше (если ваторы вменяемы).
Но прчем тут надежность? Больший по объему код еще не означет, что он мнее надежен. Ява — это типобезопасный язык, так что с точки зрения надежности решения будут идентичны (при одинаковом качестве рзработки и тестирования). Так что все упирается в грамотность проектирования и отладки. Соответственно все слова о приемуществе динамики не более чем заблуждения.
G> По оценкам писателей этой системы, во многом за счет статической типизации в Жабе
Эти слова уже вызвают сомнение в компетенции ваших Жабистов. Они просто не понимаю, что такое ФЯ и паттерн-мачинг, и насколько они согращают код реализации.
G>Немерль ? Я пока не считаю его пригодным для промышленного использования.
Ну, то что ты не считашь еще не значит, что это так на самом деле.
G>Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?
Скала еще. Ты конечно тоже что-то там не считашь. Это ясно.
Но вопрос то был не в том считаешь лыи ты какие-то языки зрелыми или нет. Вопрос был в заявлении о том, что якобы надежную систему можно создать только на динамике. Стало быть скажем на VB 1.0 надежную систему создать можно, а скажем на VB 9.0 или на C# 3.0 уже нельзя. Вот такие вот забавнешие выводы получаютя из твоих утверждений.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации.
Имхо, главная мощь именно Эрланга, которая, возможно, имеет/не имеет отношения к чему-либо, будь то типизация или что иное, это его тривиальная сериализуемость и (частично как следствие, частично как причина) его тривиальная работа с сетью.
Будь в любом другом языке такое же, имхо, Эрланг курил бы в стороне и, возможно, вообще бы не появился
Возможность написать:
Pid ! {Любая, [структура, данных]}
это наигениальнейшая вещь.
Я как вспомню все эти пляски с бубном вокруг решений о том, что и как запаковывать/распаковывать и передавать по сети... Бррр.
Здравствуйте, Mamut, Вы писали:
E>>У меня складывается впечатление, что вы говорите не о надежности, а о простоте и скорости реализации.
M>Имхо, главная мощь именно Эрланга, которая, возможно, имеет/не имеет отношения к чему-либо, будь то типизация или что иное, это его тривиальная сериализуемость и (частично как следствие, частично как причина) его тривиальная работа с сетью.
M>Будь в любом другом языке такое же, имхо, Эрланг курил бы в стороне и, возможно, вообще бы не появился
M>Возможность написать: M>
M>Pid ! {Любая, [структура, данных]}
M>
M>это наигениальнейшая вещь.
M>Я как вспомню все эти пляски с бубном вокруг решений о том, что и как запаковывать/распаковывать и передавать по сети... Бррр.
Чесно говоря, восторг от возможности передачи сложных структур данных у меня очень быстро прошел в свое время. Из-за "проблемы второй версии"
M>Каким боком здесь динамика? А никаким
Если мне не отшибает память, то Sun когда-то давным давно приводила в качестве достоинства и конкурентного преимущества байт-кода Java что его можно легко передавать на удаленную сторону и исполнять там. Что, собственно, Java-апплеты и продемонстрировали. Хотя может я сейчас и не о том.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Чесно говоря, восторг от возможности передачи сложных структур данных у меня очень быстро прошел в свое время. Из-за "проблемы второй версии"
А конкретней? Где именно 2-я версия? Сообщений? Получателей?
M>>Каким боком здесь динамика? А никаким
Я думаю каким — типов сообщений у нас нет поэтому разбирать надо "на лету", поэтому можем разбирать в 2-й версии больше чем в 1-й.
Здравствуйте, eao197, Вы писали:
E>Проблема в другом, в том, чтобы клиенты первой версии без проблем понимали вторую. Вот пример того, как это можно обеспечить (подсмотрено в Asn.1 ).
Что-то вот какая-то непонятная задача, в смысле, что не видел ни одного подобного примера
По сути получается mediation, но примеров подобного на Erlang не встречал, думаю, что ПМ тут как раз был бы к месту. В принципе в стандартной библиотеке Эрланга есть некая "идиома", когда параметр есть список опций (расширяемый), тут тоже можно сделать нечто подобное. Причём вполне нетрудно.
Здравствуйте, Mamut, Вы писали:
M>*только не в бан, только не в бан*
Ладно. Рассмотреим пожелание.
M>Ну вот. В том-то все и дело. "Неосторожно брошенные слова".
Дело в том, что эта рихтовка производится уже после осбуждения. А не будь замечания многие бы проглатили исходное утверждение, а то еще хуже начали бы его расространять как истину не требующую доказательства.
M>Флейм? Флейм.
А может флэймом была сама исходная фраза?
M>Причем тут фанатичность или хоть какой-то намек на логику таких осуждений (особенно в рамках просьбы к гандальфу), не понятно
А ты почитай развитие ситации. Это именно фанатичные заявления. Альтернативы не пробовал, но выводы уже устоявшиеся.
M>И дальше топик скатился вообще непонятно куда
Да, никуда он не скатился. Просто к залихватской рекламной компании добавился разумный "разбор полетов".
Конструктивного, кстати, в подобных рекламных проспектах все равно ничего нет. Каждый кулик свое болото хвалит. Этой истине сто лет в обед.
Интересны не заявления "мы с помощью ххх порвали всех...", а рассказ о том, как и что было достигнуто. Ну, по крайней мере лично мне интереснее...
M>(опять же к обсуждению статики и динамики). А казалось бы. Достаточно было дождаться ответа автора
M>Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить".
Ну, и что этот ответ дал? Он мне очень напоминает анегдот:
В курилке один из сотруднико громко заявляет:
— Наш начальник полное говно!
Вдруг входит тот самый начальник...
— Ну, в хорошем смысле этого слова .
Из его слов лично мне стало ясно, что из статически типизированных языков он пробовал использовать только С++ и на его фоне ему показалось, что надежность действительно определяется динамикой Эрлэнга. В лучшем случае — это искренее заблуждение.
M>Все. И дальше можно обсуждать все, что угодно, применительно к проекту, создаваемому небольшим количеством человек, сложности и т.д. и т.п.
Дальше можно обсуждать только опыт и компетенцию, а это п. 5 по нашим правилам.
M>Более того, простой ответ в таком стиле: M>
M>Хм. Довольно спорное утверждение. Мой опыт показывает, что статика не только позволяет, но и помогает строить надежные системы. Быть может, автор это высказал в пылу спора или это как-то связано с его опытом в его проекте
Понимаешь ли в чем дело. Есть утверждения спорные и их можно понять. А есть абсурдные. Вот это было отнюдь не спорным.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
VD>>Важно то, что даже если на динамике можно создавать сложные приложения (т.е. я не прав в этом аспекте) — это никак не вылияет на возожность создавать сложные приложения на статике. Understand? EC>Это ты сейчас с кем споришь? Кто утверждал, что на статике создавать сложные приложения нельзя?
Это я не спорю, а разясняю основы дошкольной логики тем кто в этом нуждается.
EC>Попробуй читать сообщение, на которое отвечаешь — сэкономишь кучу времени себе и другим подписчикам форума.
Пробовал. У некоторых людей они действительно содержат интересную информацию. Но это не тот случай.
EC>Я там вопрос задал максимально точно, зная любителей пофлеймить, причём человек его понял в отличие от...
А в чем смысл твоег вопроса? Сказанное было без этого не очевидно? На заявление "Земля — это треугольник" ты тоже попросишь разяснений?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Действительно, C++ для сложной обработки данных сольет практически любому языку по объему кода, скорости его написания и времени на тестирования. Но все это имеет косвенное отношение к надежности.
Ну, это уже перебор. Есть же С и Паскаль . Кроме того есть J и Брэйнфак. Они то уж точно будут лидеры по запутанности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Написав одну и ту же функциональность в несколько раз быстрее, чем на С++/Жаба/что-то еще, мы можем потратить больше времени на реализацию механизмов самовосстановления, к примеру
Значит дело все же не в динамике, и даже не в надежности, которую безусловно можно достичь на языке любого типа, а в том, что на языке Х банально проще вести разработку и оастается больше свободного времени?
Что же это разумно. Только причем тут надежность? Пояляющееся время можно потратить на создание новых, глючных фич или банально на игры в Дум 33.
Ну, и если мы говрим о времени, то наверно не лишним будет сказать, что ускорению разработки способствовают многие факторы (например, использование мощьного фрэймворка), и что есть много языков способствующих ускорению.
Главное что это то что Эрлэнг способствует ускорению разработки никак не сказывается на всем сообществе динамических языков в области надежности. Ведь VB 1.0 вряд ли ускоряет разработку серверного софта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
E>>Проблема в другом, в том, чтобы клиенты первой версии без проблем понимали вторую. Вот пример того, как это можно обеспечить (подсмотрено в Asn.1 ).
К>Что-то вот какая-то непонятная задача, в смысле, что не видел ни одного подобного примера К>По сути получается mediation, но примеров подобного на Erlang не встречал, думаю, что ПМ тут как раз был бы к месту. В принципе в стандартной библиотеке Эрланга есть некая "идиома", когда параметр есть список опций (расширяемый), тут тоже можно сделать нечто подобное. Причём вполне нетрудно.
Подробнее о том, что такое "проблема второй версии протокола" я рассказывал здесь
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>По сути получается mediation, но примеров подобного на Erlang не встречал, думаю, что ПМ тут как раз был бы к месту. В принципе в стандартной библиотеке Эрланга есть некая "идиома", когда параметр есть список опций (расширяемый), тут тоже можно сделать нечто подобное. Причём вполне нетрудно.
E>Подробнее о том, что такое "проблема второй версии протокола" я рассказывал здесь
И чем тебе не нравится предложенный мной вариант? Делаем сообщение аля {msgSignature, [...extesions...], someData}
Промежуточному слою нахрен не нужны extensions, поэтому в бранче ПМ будет что-то типа {msgSignature, _, X}
Здравствуйте, Курилка, Вы писали:
К>Ну если так, то за счёт статической типизации можно получить ускорение на алгоритмах с "числодробительной" составляющей. К>А где ты читал про "утверждают"? К>Хотя небольшое количество — эт как-то "неспортивно", но вопрос — сколько именно?
Это когда я заинтересовался АлисойМЛ ( с год назад ), прошелся поиском насчет сравнения с другими языками. Так вот, в одном из буржуинских форумов писалось именно про небольшое количество процессов и быстрый их старт. Я еще подумал тогда, а не держат ли они за пазухой пул нитей ? И как-то мне это сразу не понравилось...
Но раз у них свежий релиз, имеет смысл еще раз пошарить в сетях. "Тятя, тятя, наши сети..." (с) Некрасов
Здравствуйте, gandalfgrey, Вы писали:
G>Это когда я заинтересовался АлисойМЛ ( с год назад ), прошелся поиском насчет сравнения с другими языками. Так вот, в одном из буржуинских форумов писалось именно про небольшое количество процессов и быстрый их старт. Я еще подумал тогда, а не держат ли они за пазухой пул нитей ? И как-то мне это сразу не понравилось... G>Но раз у них свежий релиз, имеет смысл еще раз пошарить в сетях. "Тятя, тятя, наши сети..." (с) Некрасов
Ну если найдёшь — было бы ужасно интересно, с ходу нашёл только это — вроде неплохо (хотя однопроцессорный вариант), но лишь 100 муравьёв и версия компилятора 1.2.1 (2005-го года).
M>>*только не в бан, только не в бан*
VD>Ладно. Рассмотреим пожелание.
*Ффффух*
M>>Ну вот. В том-то все и дело. "Неосторожно брошенные слова". VD>Дело в том, что эта рихтовка производится уже после осбуждения. А не будь замечания многие бы проглатили исходное утверждение, а то еще хуже начали бы его расространять как истину не требующую доказательства.
"
M>>Флейм? Флейм. VD>А может флэймом была сама исходная фраза?
M>>Причем тут фанатичность или хоть какой-то намек на логику таких осуждений (особенно в рамках просьбы к гандальфу), не понятно VD>А ты почитай развитие ситации. Это именно фанатичные заявления. Альтернативы не пробовал, но выводы уже устоявшиеся.
На тот момент это не было известно
M>>И дальше топик скатился вообще непонятно куда VD>Да, никуда он не скатился. Просто к залихватской рекламной компании добавился разумный "разбор полетов".
Да, но он начался немного в другой ветке и только после ответа автора
VD>Конструктивного, кстати, в подобных рекламных проспектах все равно ничего нет. Каждый кулик свое болото хвалит. Этой истине сто лет в обед. VD>Интересны не заявления "мы с помощью ххх порвали всех...", а рассказ о том, как и что было достигнуто. Ну, по крайней мере лично мне интереснее...
Выделенное действительно интереснее
M>>(опять же к обсуждению статики и динамики). А казалось бы. Достаточно было дождаться ответа автора
M>>Прочитав тему за выходные, понял, что необходимо кое-что пояснить. Неявно подразумевалось : не построить нашими силами. То-есть целиком фраза будет звучать так : "С нашими человеческими и временными ресурсами надежную систему без динамической типизации не построить".
VD>Ну, и что этот ответ дал? Он мне очень напоминает анегдот: VD>
В курилке один из сотруднико громко заявляет:
VD>- Наш начальник полное говно!
VD>Вдруг входит тот самый начальник...
VD>- Ну, в хорошем смысле этого слова .
VD>Из его слов лично мне стало ясно, что из статически типизированных языков он пробовал использовать только С++ и на его фоне ему показалось, что надежность действительно определяется динамикой Эрлэнга. В лучшем случае — это искренее заблуждение.
Ну, эти его слова были увидены-услышаны через сутки после этой ветки
M>>Все. И дальше можно обсуждать все, что угодно, применительно к проекту, создаваемому небольшим количеством человек, сложности и т.д. и т.п. VD>Дальше можно обсуждать только опыт и компетенцию, а это п. 5 по нашим правилам.
Действительно Но
Видите ли, — сказал Фарфуркис, — чувствуется, что вы не юрист. Нет
ничего более гибкого и уступчивого, нежели юридические рамки. Их можно
указать при необходимости, но их нельзя перейти.
M>>Более того, простой ответ в таком стиле: M>>
M>>Хм. Довольно спорное утверждение. Мой опыт показывает, что статика не только позволяет, но и помогает строить надежные системы. Быть может, автор это высказал в пылу спора или это как-то связано с его опытом в его проекте
VD>Понимаешь ли в чем дело. Есть утверждения спорные и их можно понять. А есть абсурдные. Вот это было отнюдь не спорным.
Ну, не знаю Имхо, флейм статика vs. динамика еще не закончен
A>С явой согласен, разработка без поддержки IDE — это очень непростое занятие. Но вот скала? Я уже пол-года изучаю это язык и незаметно для себя обнаружил, что на скале я пишу в jedit/emacs _вообще_ без поддержки IDE (ибо нету пока толковой). Т.е. выразительность и краткость языка не идет ни в какое сравнение с java. Реально очень близко к python, только со статикой. Но гибкость скаловской системы типов и синтаксисический сахар позволяют писать как в динамике.
Согласен языки типа Scala или Nemerle вполне могут дать близкую к питону или руби скорость разработки.
Здравствуйте, eao197, Вы писали:
E>>>То, что Flt генерируется при старте и затем в динамике выбирается версия, подходящая для определенных типов параметов, говорит лишь об удобстве ее использования и снижения трудозатрат на ее реализацию. В том же C++ можно делать аналогичные вещи, только они будут больше по объему. А вот степень надежности того и другого -- вопрос открытый.
Flt генерируется по ОПИСАНИЮ структур данных, которые вовсе не являются предопределенными. Более того, они мне неизвестны заранее
E>Не очень понял, что понимается под изменением структуры данных. E>Что до C++, то я сам делал реализацию фабрики объектов, которая использовала тип данных параметра метода create для определения типа создаваемого объекта. Причем типы объектов автоматически регистрировались в данной фабрике вместе с нужными им типами параметра во время работы программы. Что позволяло иметь разные наборы типов в фабрике при ручной загрузке/выгрузке DLL. И все это средствами штатного RTTI.
Я правильно понимаю, что код для новых типов надо писать ручками ? У меня приходит заранее неизвестный тип, неизвестной структуры, но подчиняющийся определнным правилам, которые и позволяют сгенерить функции для доступа к полям.
E>Давайте разговаривать серьезно, все-таки. E>Нельзя передать в программу объект совершенно произвольного типа и дожным образом его обработать. В программе должен быть код, который знает, что это за тип и что с ним делать. Соответственно этот код нужно править и переписывать.
Типы могут быть произвольными в рамках неких правил ( которые тоже описываются на некотором уровне )
E>Другое дело, что динамика легко позволяет во время работы системы догружать недостающие и просто новые фрагменты кода. Об этом здесь говорили.
Это совершенно не та динамика, о которой говорю я
E>Опять же, если в функции есть код, который знает, что делать с левым типом, то этот тип уже не левый. А поиметь такой код вполне можно динамической загрузкой кода в статически-типизированных языках.
Достаточно иметь код, который знает, что делать с правилами, описывающими левый тип.
E>Я же и сказал, косвенное. На скорость разработки и на освобождение времени для других целей (в том числе и повышения надежности) влияет и множество других факторов: начиная от квалификации разработчика и имеющихся в наличии инструментов, заканчивая температурой воздуха в комнате в следствие нормальной/ненормальной работы кондиционера (или отсутствия оного).
Мы можем существенно упростить логику за счет динамической типизации. Это даст нам уменьшение обьемов кода, что, в свою очередь, уже прямо влияет на надежность вследствие известной закономерности : соотношение количества ошибок и строк кода есть константа ( при прочих равных условиях, разумеется )
E>Здесь найдутся несколько человек, которые совершенно серьезно будут утверждать, что Java+IDEA или C#+ReSharper позволяют им писать на статически-типизированном языке гораздо быстрее, чем на динамически-типизированном. И нет оснований им не верить. Так же как есть несколько человек, которые не менее серьезно будут говорить, что Ruby+VIM или Erlang+Emacs позволяют им писать быстрее, чем на статически типизированном языке. Люди таки разные.
Это уже другая сторона, А именно, личное восприятие и предпочтения. Вкусы действительно разные у всех : мне, к примеру, не нравится Хаскель, но нравится D. Но С++ мне все равно не нравится, хотя и приходится маленькие кусочки на нем писать ( в основном для Тикля ).
E>Но к надежности, имхо, это не имеет прямого отношения. Гораздо важнее, является ли используемый язык сильно-типизированным или нет. Скажем отсутствие проблемы повисших указателей или прохода по чужой памяти может сделать программу на Ruby надежнее, чем C++. Но это отнюдь не аргумент в пользу надежности из-за динамики, т.к. Java или C# являются не менее сильно-типизированными.
Скажем так : тот код на Ерланге, который обрабатывает сложные структуры данных, переменного, заранее неопределенного формата (то, о чем я выше писал ), вышел весьма компактным и из-за этого поддающийся легкой проверке и тестированию. Как это было бы на С++ — мне даже страшно представить, и какого бы оно выросло размера, и сколько было бы там глюков...На Окамле и то было бы существенно более громоздким, по моим предварительным прикидкам.
E>Рад, что вы настолько уверенны в своей системе. E>Хотя, основываясь на своем скромном опыте, мне это кажется в большей степени рекламным слоганом, ну или попыткой самоубеждения
Все просто — изоляция процессов спасет отцов русской демократии...А точнее, принцип "let it crash" ( в переводе — да пусть оно сдохнет ). Процессы, порожденные клиентской проксей — чисто пассивные. Их дело — обрабатывать запросы и рассылать уведомления. Если один из них загнется, никто, кроме ядра, этого не заметит. Да и ядро сделает запись в лог и забудет об этом. Процессы, порождаемые запросами от клиента, не имеют прямого доступа к ядру и уронить его не могут при всем желании. Ежели они сдохнут, то клиенту уйдет уведомление об этом. Клиентская сессия продолжится далее
E>У меня все сказанное вами оставляет впечатление, что вы говорите о большей надежности по сравнению с C++. E>Тогда более правильно вести разговор о преимуществах сильной типизации (не важно, статической ли или динамической) перед слабой типизацией.
Не только С++, но и Жабба...
Здравствуйте, VladD2, Вы писали:
VD>На Дельфи создана масса сложнейших систем. И они уже давно работают. Уже этот факт подтверждает, что на ней точно можно это делать.
Так-таки и сложнейших ? А можно пару примеров ?
VD>Тут разумно говорить о сложности разработки, а не о надежности.
Одно с другим связано, причем напрямую. Ежели для достижения одного и того же функционала сложность разработки на одной платформе превышает сложность разработки на другой в разы, то не будет ли таковым ( или близким к тому ) и соотношение надежности этих разработок ?
Re[10]: Бизнес-логика на Erlangе
От:
Аноним
Дата:
15.05.07 09:47
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandalfgrey, Вы писали:
G>>О том и речь ! Я не сравниваю со статической типизацией в Хаскеле — мне не нравится Хаскель, я на нем писал только маленькие примерчики, и не считаю себя достаточно компетентным для такового сравнения.
VD>А не кажется ли тебе тогда, что если твоя компетенция в области статически-типизированных языков заканчивается на С++, то все же не стоит делать таких смелых заявлений по поводу надежности решений на динамических языках в сравнении с аналогами созданными на статических?
G>> Жаба ? Я уже привел соотношение размеров кода — почти 2 порядка.
VD>Ну, два порядка — это еще одно безответственное озаявление. Хотя согласен, что конечно код на динамическом языке с паттерн-мачингом по любому будет существенно меньше (если ваторы вменяемы). VD>Но прчем тут надежность? Больший по объему код еще не означет, что он мнее надежен. Ява — это типобезопасный язык, так что с точки зрения надежности решения будут идентичны (при одинаковом качестве рзработки и тестирования). Так что все упирается в грамотность проектирования и отладки. Соответственно все слова о приемуществе динамики не более чем заблуждения.
G>> По оценкам писателей этой системы, во многом за счет статической типизации в Жабе
VD>Эти слова уже вызвают сомнение в компетенции ваших Жабистов. Они просто не понимаю, что такое ФЯ и паттерн-мачинг, и насколько они согращают код реализации.
G>>Немерль ? Я пока не считаю его пригодным для промышленного использования.
VD>Ну, то что ты не считашь еще не значит, что это так на самом деле.
G>>Что у нас еще есть такого, статического, с чем имеет смысл сравнивать ?
Всегда было интересно посмотреть на примеры использования Немерля в реальных проектах. Таковые есть?
Здравствуйте, VladD2, Вы писали:
VD>Значит дело все же не в динамике, и даже не в надежности, которую безусловно можно достичь на языке любого типа, а в том, что на языке Х банально проще вести разработку и оастается больше свободного времени?
Это только один из факторов, но немаловажный. Ибо при нехватке времени обычно начинается "Бери больше, бросай дальше", а к чему это ведет — все знают
VD>Ну, и если мы говрим о времени, то наверно не лишним будет сказать, что ускорению разработки способствовают многие факторы (например, использование мощьного фрэймворка), и что есть много языков способствующих ускорению.
Оно конечно... только ускорение бывает разное...
VD>Главное что это то что Эрлэнг способствует ускорению разработки никак не сказывается на всем сообществе динамических языков в области надежности. Ведь VB 1.0 вряд ли ускоряет разработку серверного софта.
Я и не говорю про все сообщество. Более того, я не выдвигаю никаких теорий по поводу того, насколько хороша динамика в целом для абстрактных проектов. У меня есть опыт средних проектов на Ерланге, но зато с требованиями повышенной надежности ( все та же родимая телеметрия и телеуправление ), и он говорит мне, что Ерланг для этого очень хорош. У меня есть опыт крупного проекта на Ерланге, и я могу его сравнивать с альтернативными реализациями, и опять-таки вижу, что Ерланг для этого очень хорош. Не только из-за динамики, но она на одном из первых мест в списке важных факторов.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>Не очень понял, что понимается под изменением структуры данных. E>>Что до C++, то я сам делал реализацию фабрики объектов, которая использовала тип данных параметра метода create для определения типа создаваемого объекта. Причем типы объектов автоматически регистрировались в данной фабрике вместе с нужными им типами параметра во время работы программы. Что позволяло иметь разные наборы типов в фабрике при ручной загрузке/выгрузке DLL. И все это средствами штатного RTTI. G>Я правильно понимаю, что код для новых типов надо писать ручками ? У меня приходит заранее неизвестный тип, неизвестной структуры, но подчиняющийся определнным правилам, которые и позволяют сгенерить функции для доступа к полям.
E>>Давайте разговаривать серьезно, все-таки. E>>Нельзя передать в программу объект совершенно произвольного типа и дожным образом его обработать. В программе должен быть код, который знает, что это за тип и что с ним делать. Соответственно этот код нужно править и переписывать. G>Типы могут быть произвольными в рамках неких правил ( которые тоже описываются на некотором уровне )
То есть задача в создании универсального акцессора, который на входе получает (1) правила (структуру которых можно описать на некотором языке метаправил, и, следовательно, типизировать ) (2) нечто, что должно подчиняться этим правилам, а на выходе — функция, генерирующая заказанные данные
Здравствуйте, deniok, Вы писали:
D>То есть задача в создании универсального акцессора, который на входе получает (1) правила (структуру которых можно описать на некотором языке метаправил, и, следовательно, типизировать ) (2) нечто, что должно подчиняться этим правилам, а на выходе — функция, генерирующая заказанные данные D>
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, deniok, Вы писали:
D>>То есть задача в создании универсального акцессора, который на входе получает (1) правила (структуру которых можно описать на некотором языке метаправил, и, следовательно, типизировать ) (2) нечто, что должно подчиняться этим правилам, а на выходе — функция, генерирующая заказанные данные D>>
G>В принципе как бы да — только функция не генерирует данные, а позволяет осуществлять к ним доступ неким унифицированным образом.
А можно увидеть на псевдокоде принцип подобного действа.
Допустим есть такой ентити:
class Person {
var name: String = _;
var position: Position = _;
}
И есть такой (допустим он даже не совместим и не наследуется от person)
class VIPerson {
var name: String = _;
var bablo: double = _;
var position: Position = _;
}
Можно хотя бы на пальцах пояснить как будут выглядеть правила для модификации name в этих объектах.
ЗЫ: хотя все таки слабо представляю код, которому все равно что это за объект он модифицирует ( в случае с иерархией и trait-ами
понимаю)
К>И чем тебе не нравится предложенный мной вариант? Делаем сообщение аля {msgSignature, [...extesions...], someData} К>Промежуточному слою нахрен не нужны extensions, поэтому в бранче ПМ будет что-то типа {msgSignature, _, X}
Я и не говорил, что он мне не нравится. Но, если об extensions не задумываться, то весь код ПМ вида {msgSignature, X} придется переделывать в {msgSignature, _, X}, а затем в {msgSignature, _, X, _}, а затем в {msgSignature{Y,Z,_},_,X,_,_} и т.д.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
<...Про структуры данных разбираются, видимо, в соседней ветке...>
E>>Но к надежности, имхо, это не имеет прямого отношения. Гораздо важнее, является ли используемый язык сильно-типизированным или нет. Скажем отсутствие проблемы повисших указателей или прохода по чужой памяти может сделать программу на Ruby надежнее, чем C++. Но это отнюдь не аргумент в пользу надежности из-за динамики, т.к. Java или C# являются не менее сильно-типизированными. G>Скажем так : тот код на Ерланге, который обрабатывает сложные структуры данных, переменного, заранее неопределенного формата (то, о чем я выше писал ), вышел весьма компактным и из-за этого поддающийся легкой проверке и тестированию. Как это было бы на С++ — мне даже страшно представить, и какого бы оно выросло размера, и сколько было бы там глюков...На Окамле и то было бы существенно более громоздким, по моим предварительным прикидкам.
Позволю себе усомниться в ваших оценках сложности и глючности C++ кода. Исходя из собственного опыта.
E>>Рад, что вы настолько уверенны в своей системе. E>>Хотя, основываясь на своем скромном опыте, мне это кажется в большей степени рекламным слоганом, ну или попыткой самоубеждения G>Все просто — изоляция процессов спасет отцов русской демократии...А точнее, принцип "let it crash" ( в переводе — да пусть оно сдохнет ). Процессы, порожденные клиентской проксей — чисто пассивные. Их дело — обрабатывать запросы и рассылать уведомления. Если один из них загнется, никто, кроме ядра, этого не заметит. Да и ядро сделает запись в лог и забудет об этом. Процессы, порождаемые запросами от клиента, не имеют прямого доступа к ядру и уронить его не могут при всем желании. Ежели они сдохнут, то клиенту уйдет уведомление об этом. Клиентская сессия продолжится далее
Ok. Но наивно слычать такие рассуждения о надежности. Может вам просто не доводилось сталкиваться с логическими ошибками, которые при одних и тех же входящих данных приводят к зависанию или падению процесса. Процесс восстанавливается, восстанавливает те же самые данные и падает опять.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Я и не говорил, что он мне не нравится. Но, если об extensions не задумываться, то весь код ПМ вида {msgSignature, X} придется переделывать в {msgSignature, _, X}, а затем в {msgSignature, _, X, _}, а затем в {msgSignature{Y,Z,_},_,X,_,_} и т.д.
Нет, у нас в данном случае 1 "точка развития", правда можно сделать опцию (которая уже находится в какой-то "точке") с точкой развития, но тут уж сам себе злобный буратино
Т.к. точка есть лист, то туда можно напихать всё, что душе угодно, забота получателя разобрать нужные опции (и игнрорировать те, что он не понимает).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandalfgrey
E>Позволю себе усомниться в ваших оценках сложности и глючности C++ кода. Исходя из собственного опыта.
Не самого кода, но исходников, написанных программерами. Вот уж тут сбываются самые мрачные прогнозы !
E>Ok. Но наивно слычать такие рассуждения о надежности. Может вам просто не доводилось сталкиваться с логическими ошибками, которые при одних и тех же входящих данных приводят к зависанию или падению процесса. Процесс восстанавливается, восстанавливает те же самые данные и падает опять.
А бывает ! Но это легко отслеживается его прародителем
Здравствуйте, FR, Вы писали:
FR>Рефакторинг из той же песни, он тоже получается для раздолбаев.
Это зависит. Но сам факт стремления к улучшению кода говорит сам за себя.
Жить без рефакторинга вообще практически невозможно. В процессе работы над той или иной проблемой нам открываются новые знания (подробности о которых раньше мы не могли знать). Это приводит к корректировке планов. Без рефакторинга проект быстро превращается в ночной кошмар. А с рефакторингом развивается дальше.
VD>>На самом деле обобщенное программирование и правильное проектирование, а так же вывод типов фактически сводят такие проблемы к нул. Но если программист раздолбай и бездарность, то правильное проектирование и применение продвинутых техник программирования может быть затруднительным. Отсюда вывод — приемущество динамики обратно пропорциональны скилу программиста. Это коечно шутка, но в ней ейсть доля шутки.
FR>Не надо сказок про правильное проектирование,
Если для тебя это сказки, то в общем-то нам больше с тобой разговаривать не о чем.
FR> в реальном мире такое бывает разве при переписывании старых проектов и то если не добавлять новых фич
Вы просто не умете ее готовить (с)
FR>Ну а серъезно динамика дает больше перимуществ как раз более сильным программистам.
Голословное и крайне сомнительное утверждение. Я скорее соглашусь с мнением еао197 о том, что кто к чему привык тому то и нравится. Лично мне динамика всегда мешает. Я лучше напишу пару лишних строк распознающих тип (если надо), но буду иметь полноценный контроль над тем, что делаю.
VD>>Самое сложное — это не написать кусок кода, а вписать его в уже имющуюся инфраструктуру. То и дело хочется произвести рефакторинг, изменить одно проектное решение на другое. И все это проще делать при наличии строгого контроля типов.
FR>При динамике это тоже просто.
Еще одно голословное и крайне сомнительное утверждение. При динамике никакого контроля за программистом нет. И нужно опбкладываться горой тестов.
VD>>Без строгого статического контроля типов единственным способом получить надежную систему является обкладывание кода тестами. Причем такого обкладывания, чтобы ни одна мышь не проскачила. В некоторых системах это возможно, а в некоторых нет. Так что имеем еще один вывод — динамика противопоказана системам для которых по тем или иным причинам трудно создать тесты. И еще один вывод — выбирая динамику вы обязаны уделять тестированию вренмени чуть ли не больше чем основной разработке.
FR>Влад не провоцируй на разговоры про так любимого тобой Блаба
Блаба? Я на динамических языках поработал не мало.
FR>По опыту на небольших и средних проектах
Я не говорю о детских игрушках которые можно наклепать одному за месяц. Это на чем угодно можно сделать.
FR> динамический язык (питон) требует не больше формальных тестов чем статический (хорошо написаный код на C++).
О, опять С++. Несомненно, не типобезопасный язык может требовать тестов не меньше чем динамический. В прочем, динамика по любому требует больше тестов. Если их нет, то просто снижается качество продукта.
FR> Фокус в том что разработка идет практически режиме неприрывного тестирования, каждый запуск это тест. А число запусков при написании на динамике намного больше чем на статике.
Более менее серьзная программа имеет тучу мелких процедур которые взываются отнюдь не постоянно. Так что даже простое изменение может бытьне протестированно "при запусках". А уж рефакторинг точно приводит к изменениям которые требуют тотального тестирования, если конечно нет статической типизации которая спасает от многих ошибок.
VD>>Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .
FR>Думаю ява даст сильный тормоз за счет приличного увелечения объема кода. Скала вряд ли даст какое либо ускорение.
Агащазблин. Ява даст увеличение объема кода по сравнению с С++ котодм на базе Qt? я плякаль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
VD>>Понимаешь ли в чем дело. Есть утверждения спорные и их можно понять. А есть абсурдные. Вот это было отнюдь не спорным.
M>Ну, не знаю Имхо, флейм статика vs. динамика еще не закончен
Дык речь, то не о нем. Речь то о надежности которую можно достичь только на динамике .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>Всегда было интересно посмотреть на примеры использования Немерля в реальных проектах. Таковые есть?
Лично я занимаюсь Интеграцией с VS 2005 и самим компилятором. Оба проекта довольно серьезные. Кмпилтор, пожалуй самый большой проект. Так же можно поглядеть на генератор парсеров который делает konsoletyper. Насколько я знаю доступны коды автоматического проверяльшика доказательств теорем который пишит один из разработчиков компилятора (точную ссылку не знаю). Есть так же ряд частных разработок, но они закрытые, так что посмотреть их код не представляется возможным.
ЗЫ
Зачем так оверквоить?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Потому, что мы с тобой спорим в общей священной войне dynamic vs static, в которой много факторов и надежность отнюдь не главный. Здесь же утверждалось, что динамика способствует надежности. Будучи приверженцем динамики я, все-таки не наблюдал такой прямой зависимости между динамикой и надежностью. Поэтому и влез в этот спор, чтобы понять, может я чего не знаю еще.
Приятно видеть объективность в довольно религиозном вопросе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Но обычно приверженцы статики кричат чуть ли об абсолютной ненадежности динамики.
Мне кажется, что тебе кажется.
Вменяемые люди понимают, что на нет одного определяющего фактора. Такие факторы как типобезпасность несомненно сильно влияют на качество ОП (здесь ведь под надежностью понимают именно это). Статическая типизация так же положительно влияет на качество ПО, так как устраняет целые классы ошибок. Но конечно же остается еще море мест где она бессильна. Так что вполне нормально когда программа на динамическом языке более надежна чем скажем на С++, так как он не типобезопасен. Да и нет ничего необычного в том, что скажем программа на Питоне окажется надежнее чем аналогичная программа на Яве. Ведь первая может быть лучше спроектирована и тщательнее оттестирована. Но так же вполне очевидно, что статическая типизация не может негативно влиять на качество ПО сама по сибе (как по сути утверждает автор высказывания).
FR> Что тоже неправда. Наверно поэтому Влад так разошелся, это же красная тряпка когда утверждают нечто абсолютно противоположное одному из его любимейших мифов
Ты меня с кем-то путашь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
FR>>Рефакторинг из той же песни, он тоже получается для раздолбаев. VD>Это зависит. Но сам факт стремления к улучшению кода говорит сам за себя. VD>Жить без рефакторинга вообще практически невозможно. В процессе работы над той или иной проблемой нам открываются новые знания (подробности о которых раньше мы не могли знать). Это приводит к корректировке планов. Без рефакторинга проект быстро превращается в ночной кошмар. А с рефакторингом развивается дальше.
+1
FR>> в реальном мире такое бывает разве при переписывании старых проектов и то если не добавлять новых фич VD>Вы просто не умете ее готовить (с)
Всегда завидовал людям, которые не работают с внешними заказчиками.
VD>>>Самое сложное — это не написать кусок кода, а вписать его в уже имющуюся инфраструктуру. То и дело хочется произвести рефакторинг, изменить одно проектное решение на другое. И все это проще делать при наличии строгого контроля типов. FR>>При динамике это тоже просто. VD>Еще одно голословное и крайне сомнительное утверждение. При динамике никакого контроля за программистом нет. И нужно опбкладываться горой тестов.
Зачем гора? Старые тесты как работали, так и остануться неизменными. Дописать придётся только для новых вариантов.
А вот в статике, придётся переписывать довольно много,.. и все старые тесты тоже,.. что требует гораздо больше усилий для подобных изменений несмотря на помощь компилятора.
VD>Блаба? Я на динамических языках поработал не мало.
У всех бывают свои личные неудачи.
VD>>>Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике . FR>>Думаю ява даст сильный тормоз за счет приличного увелечения объема кода. Скала вряд ли даст какое либо ускорение. VD>Агащазблин. Ява даст увеличение объема кода по сравнению с С++ котодм на базе Qt? я плякаль.
А где я говорил про Qt и С++?
Проекты делаються на Python + Qt. Библиотека биндинга называется PyQt. Qt Designer производит xml-ку по которой генерируется код на Python. На систему сигнал-слот просто идеально ложаться замыкания. Ни одной стрчки на С++ там нет, и пока не предвидиться.
Так что с Явой мы пока обождём.
Здравствуйте, eao197, Вы писали: T>>Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы. T>>Соответственно разработка обладает большей мобильностью.
E>Опять же, речь не о мобильности, а о надежности. E>Все же это разные вещи.
T>>Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики. E>Да ладно, стоит один раз нормально сделать , а потом использоваться без всяких заморочек.
И в плоские файлы и в базу даных одну систему сериализации? Сильно.
Здравствуйте, Tonal-, Вы писали:
T>А где я говорил про Qt и С++? T>Проекты делаються на Python + Qt. Библиотека биндинга называется PyQt. Qt Designer производит xml-ку по которой генерируется код на Python. На систему сигнал-слот просто идеально ложаться замыкания. Ни одной стрчки на С++ там нет, и пока не предвидиться. T>Так что с Явой мы пока обождём.
Ясно. Значит я тебя не так понял.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tonal-, Вы писали:
T>>>Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики. E>>Да ладно, стоит один раз нормально сделать , а потом использоваться без всяких заморочек. T>И в плоские файлы и в базу даных одну систему сериализации? Сильно.
Под "базой данных", надо полагать, понимается реляционная СУБД. В принципе, можно и туда, в varchar или blob-поля.
А еще есть объектные СУБД, там еще проще.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Согласен языки типа Scala или Nemerle вполне могут дать близкую к питону или руби скорость разработки.
Я думаю, что даже теоретически более быструю (хотя конечно многое зависит от самого разработчика), т.к. всякие Intellisense, рефакторинги, подсветка ошибок гораздо лучше работают в IDE для статически-типизированных языков. Ну и объем кода юнит-тестов поменьше будет.
Здравствуйте, Андрей Хропов, Вы писали:
FR>>Согласен языки типа Scala или Nemerle вполне могут дать близкую к питону или руби скорость разработки.
АХ>Я думаю, что даже теоретически более быструю (хотя конечно многое зависит от самого разработчика), т.к. всякие Intellisense, рефакторинги, подсветка ошибок гораздо лучше работают в IDE для статически-типизированных языков. Ну и объем кода юнит-тестов поменьше будет.
Это да, но с другой стороны гибкость интерфейсов и обобщенность для динамики могут все это компенсировать, хотя согласен все зависит от проекта и разработчиков.
Re[4]: Бизнес-логика на Erlangе
От:
Аноним
Дата:
16.05.07 13:54
Оценка:
К>Кстати Ульф (вроде или Тоббе) говорил, что xmerl далеко не лучший парсер, у себя там они свой парсер юзают, правда публично он не доступен.
А не говорили чем он им не подходит?
ejabberd вроде по умолчанию expat использует, хотя и патч на xmerl есть
Здравствуйте, Аноним, Вы писали:
К>>Кстати Ульф (вроде или Тоббе) говорил, что xmerl далеко не лучший парсер, у себя там они свой парсер юзают, правда публично он не доступен.
А>А не говорили чем он им не подходит?
Поищи на трапекзите.
Реально производительность не ахти.
А>ejabberd вроде по умолчанию expat использует, хотя и патч на xmerl есть
Про это он тоже упоминал вродь как.
Здравствуйте, Аноним, Вы писали:
А>Поэтому нельзя менять на лету код часто (пока не отцепился полностью старый код) и, вероятно, нельзя менять больше одного раза без перезагрузки.
По-моему (на практике не пробовал), вполне можно менять дофига раз без перезагрузки.
Суть в том, что у тебя время выполнения квантуется на периоды выполнения функций. Так вот старый модуль будет в памяти, пока функции, определённые в нём не завершатся. Вызов хвостовой рекурсии есть завершение функции (т.е. фактически получается "возвратом" из функции, правда в неё саму).
Re[12]: Бизнес-логика на Erlangе
От:
Аноним
Дата:
16.05.07 15:01
Оценка:
А>>Поэтому нельзя менять на лету код часто (пока не отцепился полностью старый код) и, вероятно, нельзя менять больше одного раза без перезагрузки.
К>По-моему (на практике не пробовал), вполне можно менять дофига раз без перезагрузки. К>Суть в том, что у тебя время выполнения квантуется на периоды выполнения функций. Так вот старый модуль будет в памяти, пока функции, определённые в нём не завершатся. Вызов хвостовой рекурсии есть завершение функции (т.е. фактически получается "возвратом" из функции, правда в неё саму).
Если возможно определить когда все старые хвосты отрублены и потом отгрузить старый код — тогда конечно.
Но, ЕМНИП, в тезисах писалось что такого Эрланг не умеет (впрочем писались они давно, с тех пор вполне себе мог и научиться. Мне тогда сразу показалось странным такое явное ограничение полезной возможности).
Нe говоря уже о случае когда я запущу какой-то процесс, в котором по ошибке будет только краткий вызов функции. Такой процесс не отпустит старый код никогда и если я не смогу полуавтоматически его обнаружить и убить (частичный перезапуск) — то без перезапуска второй раз код обновить не смогу.
Здравствуйте, Аноним, Вы писали:
А>Нe говоря уже о случае когда я запущу какой-то процесс, в котором по ошибке будет только краткий вызов функции. Такой процесс не отпустит старый код никогда и если я не смогу полуавтоматически его обнаружить и убить (частичный перезапуск) — то без перезапуска второй раз код обновить не смогу.
Ну, должен же код знать, что его могут подменить ? Длинный вызов и создаст обновление. Можно ведь сделать и так :
Переход на новую версию кода произойдет по сообщению 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-м пунктом).
Все-таки загрузка нового кода должна происходить до остановки старого. И только если эта загрузка успешна — можно останавливать старый.
Здравствуйте, VladD2, Вы писали:
VD>2. Объем и сложность системы не имеет прямой зависимости от ее надежности (устойчивости к сбоям). Надежность определяется проектными решениями и качеством тестирования. В том числе надежнаость увеличивается если при прочих равных использвут типобезопасный, статически-типизированный язык, так как это снижает требования по объему тестирования.
Не-а. Статически типизированный язык всего лишь позволяет такие ошибки несколько раньше обнаружить, что немного удешевляет их исправление. И все. Это никак не влияет на объем тестов — тебе в любом случае надо обеспечить хорошее тестовое покрытие. Хотя бы, чтобы весь твой код выполнялся под тестами (100% покрытия по метрике SLOC) — а это довольно слабое тестовое покрытие. При этом, даже при таком слабом покрытии — ошибки типизации такие тесты вылавливают на 99 и девять в периоде %.
Чему на самом деле пропорциональна надежность — так это
1) полноте тестового покрытия (никак не зависит от типизации). и
2) устойчивости программы к содержащимся в ней ошибкам. В целом, это тоже от типизации слабо зависит.
Здравствуйте, Gaperton, Вы писали:
G>Не-а. Статически типизированный язык всего лишь позволяет такие ошибки несколько раньше обнаружить, что немного удешевляет их исправление.
Более раннее выявление ошибко значительно удешевляет их исправление. Но тут речь о том, что они выявляются автоматически и в обязательном порядке. То есть весь класс выявляемых ошибок попросу устраняется.
G> И все. Это никак не влияет на объем тестов — тебе в любом случае надо обеспечить хорошее тестовое покрытие.
Влияет. Я могу пологаться на более высокоуровневые тесты и на меньший их обхем. А скажем для рефакторинга мне вообще тесты не нужны будут. Более того его можно будет автоматизировать). Ведь мы знаем все о коде еще до его запускат. Значит мы может менять его соблядая при этом инваринт.
G>Чему на самом деле пропорциональна надежность — так это G>1) полноте тестового покрытия (никак не зависит от типизации). и G>2) устойчивости программы к содержащимся в ней ошибкам. В целом, это тоже от типизации слабо зависит.
Ну, что же. Хотя мы расходимся в частностях, но мы сходимся в главном. Утверждение о том, что только динамика может обеспечить надежность явно ложно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Можно вопрос? А какими ещё средствами тебе приходилось пользоваться для построения надёжных систем и почему это не получалось?
Это не то чтобы не получалось, но ресурсы при этом были использованы совершенно другие. Большие системы до этого писал на С++ в смеси с Тиклем как скриптовым языком или клиентским кодом. Хаскель в свое время я принялся активно изучать, но чем дальше, тем больше у меня создавалось впечатление о нем как о языке для лабораторий, и в конце концов интерес к нему пропал. Окамл хорош, но людей для него найти весьма сложно, так как он представляет собой ( на мой взгляд ) смесь самых разнообразных концепций. Видимо, оттого народ в нем и путается.
Пример одной моей системы, работающей уже более 8 лет на самом крупном в мире предприятии по очистке и обогащению урана :
— 400 К строк, не считая сгенерированного PCCTS кода. С ним — около 1.1 М строк
— своя реалтаймовая СУБД
— С++ и несколько своих скриптовых языков
— сугубо распределенная
— работает и на ПервоПне
В нее вбухано более 20 человеколет. Это число достаточно велико, чтобы обьяснить, почему я считаю С++ малопригодным для построения чего-то более-менее сложного — это просто ОЧЕНЬ дорого обходится.
К Жабе примерялись, но существенного выигрыша тут все же нет.
Вот использование Ерланга и Тикля себя оправдало. Сейчас даже при желании от них невозможно отказаться — уж очень эффективно решаются проблемы с их помошью.
Более того, во многих других конторах, занимающихся аналогичными задачами, как-то стихийно наметился уклон в сторону языков с динамической типизацией.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote:
>> *Вообще-то это отход от темы и возраждение флэйма статика vs. динамика, >> нуда выскажуст, раз уж всем так хочется снова пофлэймить .* C>Да ну, это неинтересный флейм. Все ведь знают, что С++ — это самый C>лучший язык
nemerle не путай )
Здравствуйте, gandalfgrey, Вы писали:
IT>>Можно вопрос? А какими ещё средствами тебе приходилось пользоваться для построения надёжных систем и почему это не получалось? G>Это не то чтобы не получалось, но ресурсы при этом были использованы совершенно другие. Большие системы до этого писал на С++ в смеси с Тиклем как скриптовым языком или клиентским кодом... G>К Жабе примерялись, но существенного выигрыша тут все же нет.
Думаю, проблема скорее всего в C++. На нём действительно дорого делать надёжные вещи. То, что вы к джаве не примерялись, скорее всего просто что-то не сложилось.
G>Вот использование Ерланга и Тикля себя оправдало. Сейчас даже при желании от них невозможно отказаться — уж очень эффективно решаются проблемы с их помошью.
А что именно так сильно повлияло на мнение, что надёжнее уже не бывает? Должно же ведь быть какое-то объяснение.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandalfgrey, Вы писали:
IT>>Думаю, проблема скорее всего в C++. На нём действительно дорого делать надёжные вещи. То, что вы к джаве не примерялись, скорее всего просто что-то не сложилось. G>Почему не примерялись ? Пробовали, но не пошло — так как с С++ разницы большой не увидели. ( для наших задач ). А сейчас я в этом мнении укрепился — уже приводил соотношение обьемов кода для достижения одинаковой функциональности
Соотношения чего с чем?
IT>>А что именно так сильно повлияло на мнение, что надёжнее уже не бывает? Должно же ведь быть какое-то объяснение. G>На самом деле — выбора практически нет. Для использования в критических отраслях — с чего я начинал — никто просто не позволит использовать платформу, не ставшую промышленной и без хороших примеров применения в critical mission.
Это всё здорово, но это лишь следствие и не имеет никакого отношения к определению надёжности. Мне же интересно понять почему код на динамических языках надёжнее. Например, мне понятно почему может быть ненадёжен код на C++. Но сравнивая динамику с той же джавой или C# я просто не могу понять за счёт чего Пока что я вижу только ссылки на опыт на на "нашу специфику". Но у нас у всех есть опыт и есть специфика и многим она говорит, что, обладая определёнными проблемами, динамика в серьёзных приложениях есть суксь. Так вот мне интересно прежде всего понять за счёт чего ваши решения выигрывают у статики, почему сложилось такое мнение, и так ли это на самом деле. Вполне возможно, что у вас выигрышь не за счёт динамики, а за счёт чего-то другого.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Соотношения чего с чем?
Соотношение количества строк для проектов на Жаве и Ерланге, реализующих примерно одинаковую функциональность. Я эти числа приводил в исходном сообщении. Разница более чем на порядок ( в пользу Ерланга )
IT>Это всё здорово, но это лишь следствие и не имеет никакого отношения к определению надёжности. Мне же интересно понять почему код на динамических языках надёжнее. Например, мне понятно почему может быть ненадёжен код на C++. Но сравнивая динамику с той же джавой или C# я просто не могу понять за счёт чего Пока что я вижу только ссылки на опыт на на "нашу специфику". Но у нас у всех есть опыт и есть специфика и многим она говорит, что, обладая определёнными проблемами, динамика в серьёзных приложениях есть суксь. Так вот мне интересно прежде всего понять за счёт чего ваши решения выигрывают у статики, почему сложилось такое мнение, и так ли это на самом деле. Вполне возможно, что у вас выигрышь не за счёт динамики, а за счёт чего-то другого.
Вряд ли я могу представить исчерпывающее теоретическое обоснование такового мнения... Все, что я излагал в прочих сообщениях, является моим личным експириенсом и ИМХО. По поводу предубеждения относительно динамики могу заметить, что у меня оно тоже дооолгое время присутствовало, но помаленьку-понемножку рассеялось. Ежели попробовать обьяснить совсем уж вкратце, то статическая и динамическая типизация просто заставляют по-разному думать над кодом. Оттого и надежность кода разная. Разумеется, это всего лишь предположение...
Здравствуйте, eao197, Вы писали:
E>Очень смахивает на то, что на C++ вы пытались реализовать сами то же, что входит в состав ядра Erlang-а и его инструментов и что было написано не вами, а Ericsson-ом.
Есть старая шутка про то, что любая более-менее сложная программа включает в себя кривой и неэффективный Лисп...
E>Пока из ваших рассказов у меня складывается впечатление, что вы не использовали сторонних библиотек, а все низкоуровневые вещи писали сами.
Ну, это не так. Сторонние библиотеки обеспечивали почти половину функциональности
E>Вот, например, из того, что вы перечислили выше, какой процент кода относился именно к прикладной части?
Ориентировочно процентов 50 прикладного кода (может, и меньше). Все остальное — рантайм скриптов, СУБД, распределенщина, менеджеры событий... Безусловно, некоторое сходство с Ерлангом есть. К сожалению, тогда мы о нем и не слыхивали.
Здравствуйте, gandalfgrey, Вы писали:
G>Вряд ли я могу представить исчерпывающее теоретическое обоснование такового мнения...
Жаль. Хотелось услышать реальные причины такого вывода, а не просто эмоции.
G>Все, что я излагал в прочих сообщениях, является моим личным експириенсом и ИМХО. По поводу предубеждения относительно динамики могу заметить, что у меня оно тоже дооолгое время присутствовало, но помаленьку-понемножку рассеялось. Ежели попробовать обьяснить совсем уж вкратце, то статическая и динамическая типизация просто заставляют по-разному думать над кодом. Оттого и надежность кода разная. Разумеется, это всего лишь предположение...
У нас у всех предостаточно экспириенса. Самого разнообразного. С точки зрения моего экспириенса, например, невозможность нормального рефакторинга не позволяет применять динамические языки в больших, крупногобаритных приложениях.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>У нас у всех предостаточно экспириенса. Самого разнообразного. С точки зрения моего экспириенса, например, невозможность нормального рефакторинга не позволяет применять динамические языки в больших, крупногобаритных приложениях.
Здравствуйте, IT, Вы писали:
IT>Жаль. Хотелось услышать реальные причины такого вывода, а не просто эмоции.
Это не то чтоб эмоции, но ощущение правильности выбора. Своего рода дзен, я бы сказал.
Вообще крайне сомневаюсь, что возможны РАЦИОНАЛЬНЫЕ аргументы по поводу превосходства одного языка над другим. Разве что для очень близких языков...Возможно, таких как С++ и D ? И даже в этом случае не уверен в корректности этого сравнения
Здравствуйте, gandalfgrey, Вы писали:
E>>Очень смахивает на то, что на C++ вы пытались реализовать сами то же, что входит в состав ядра Erlang-а и его инструментов и что было написано не вами, а Ericsson-ом. G>Есть старая шутка про то, что любая более-менее сложная программа включает в себя кривой и неэффективный Лисп...
Вспоминая эту шутку и ваши данные о том, что 15Kloc Erlang + 34Kloc Tcl + 800loc C++ равны по функциональности 1.2Mloc Java я вот не могу понять: в 1.2Mloc Java можно было впихнуть свой собственный run-time Erlang-а и необходимые библиотеки для него. После чего написать те же самые 15Kloc...
Не оставляют меня сомнения, что дело вовсе не в языке программирования.
E>>Вот, например, из того, что вы перечислили выше, какой процент кода относился именно к прикладной части? G>Ориентировочно процентов 50 прикладного кода (может, и меньше). Все остальное — рантайм скриптов, СУБД, распределенщина, менеджеры событий... Безусловно, некоторое сходство с Ерлангом есть. К сожалению, тогда мы о нем и не слыхивали.
Не хило, однако. Т.е. сама прикладная программа, используй вы только готовое системное ПО и ПО промежуточного слоя, была бы в два раза меньше и, соответственно, в два раза дешевле.
Если не секрет, что подвигло на написание собственной СУБД, слоя поддержки распределенности и менеджера событий?
Казалось бы, крупнейшее в мире предприятие в своей отрасли, могло бы и раскошелиться на готовые инструменты.
Если система была запущена в 99-м, а разрабатываться начала, как минимум, в 98-м, то альтернативы C++ в то время нужно было еще поискать. Та же Java была совсем другой, на первом пне тормозила безбожно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вспоминая эту шутку и ваши данные о том, что 15Kloc Erlang + 34Kloc Tcl + 800loc C++ равны по функциональности 1.2Mloc Java я вот не могу понять: в 1.2Mloc Java можно было впихнуть свой собственный run-time Erlang-а и необходимые библиотеки для него. После чего написать те же самые 15Kloc...
Тут уже обсуждалось что на Java/.Net встают реальные проблемы по реализации эрланга, т.к. основной фокус в ВМ
А она написана на C
G>К примеру, алгоритмические ошибки и ошибки управления ресурсами обходятся существенно дороже — они занимают примерно от 15 мин до двух часов, в среднем — около получаса на исправление. Простыми тестами они не ловятся. Ошибки типизации ловятся простейшими тестами, и их исправление (обыкновенно такие ошибки — что-то вроде опечаток) обходится в минуты. По моему опыту так. И замедление разработки от динамики в результате получается незначительное — в рамках погрешности измерения. Я его не замечаю. Однако, эти статистики очень индивидуальны.
Угу и эти индивидуальные различия и есть основная причина споров "динамика vs статика", и Влад тут выступает в качестве столь горячо любимого им Блаба, ну не грокнул он динамику, и не понимает что не грокнул.
Здравствуйте, Курилка, Вы писали:
E>>Вспоминая эту шутку и ваши данные о том, что 15Kloc Erlang + 34Kloc Tcl + 800loc C++ равны по функциональности 1.2Mloc Java я вот не могу понять: в 1.2Mloc Java можно было впихнуть свой собственный run-time Erlang-а и необходимые библиотеки для него. После чего написать те же самые 15Kloc...
К>Тут уже обсуждалось что на Java/.Net встают реальные проблемы по реализации эрланга, т.к. основной фокус в ВМ
Дело не в Erlang-е как таковом. В 1.2Mloc Java можно было бы впихнуть компилятор, run-time и отладчик какого-нибудь доморощенного DSL, на котором данная задача решается вообще в несколько тысяч строк
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Дело не в Erlang-е как таковом. В 1.2Mloc Java можно было бы впихнуть компилятор, run-time и отладчик какого-нибудь доморощенного DSL, на котором данная задача решается вообще в несколько тысяч строк
Если бы да кабы...
Понимаешь, для того, чтоб сделать этот ДСЛ нужно подумать, потом надо обучить людей писать на нём и т.п.
А так легче индусов нанять которые будут копипастить
Здравствуйте, Курилка, Вы писали:
IT>>У нас у всех предостаточно экспириенса. Самого разнообразного. С точки зрения моего экспириенса, например, невозможность нормального рефакторинга не позволяет применять динамические языки в больших, крупногобаритных приложениях.
К>Нормального == автоматического?
Нормального == после изменение/удаление типа, сигнатуры метода нет возможности запуска приложения, пока все ссылки на тип, метод не будут приведены в соответствие.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Курилка, Вы писали:
E>>Дело не в Erlang-е как таковом. В 1.2Mloc Java можно было бы впихнуть компилятор, run-time и отладчик какого-нибудь доморощенного DSL, на котором данная задача решается вообще в несколько тысяч строк
К>Если бы да кабы... К>Понимаешь, для того, чтоб сделать этот ДСЛ нужно подумать, потом надо обучить людей писать на нём и т.п.
Если уж человеку ничего не стоило забабахать свою рилтаймовую СУБД в другом проекте, то уж сделать DSL
К>А так легче индусов нанять которые будут копипастить
Да, нанять индусов, способных копипастить Erlang, пока вряд ли возможно
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
IT>>Жаль. Хотелось услышать реальные причины такого вывода, а не просто эмоции. G>Это не то чтоб эмоции, но ощущение правильности выбора. Своего рода дзен, я бы сказал.
И это очень странно. Я, например, могу привести как минимум два 'за' в пользу статики: рефакторинг и возможность качественной поддержки IDE. Без всякого дзена.
G>Вообще крайне сомневаюсь, что возможны РАЦИОНАЛЬНЫЕ аргументы по поводу превосходства одного языка над другим. Разве что для очень близких языков...Возможно, таких как С++ и D ? И даже в этом случае не уверен в корректности этого сравнения
Как раз не надо сравнивать конкретные языки. Сравнивать нужно подходы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Дело не в Erlang-е как таковом. В 1.2Mloc Java можно было бы впихнуть компилятор, run-time и отладчик какого-нибудь доморощенного DSL, на котором данная задача решается вообще в несколько тысяч строк
Оно таки-да ! Но тут проблема психологическая. Народ не готов был к этому
Здравствуйте, IT, Вы писали:
IT>И это очень странно. Я, например, могу привести как минимум два 'за' в пользу статики: рефакторинг и возможность качественной поддержки IDE. Без всякого дзена.
В Британии государством спонсируется проект по разработке инструментария для рефакторинга Хаскеля и Ерланга. Кое-что они уже выложили
Для NetBean есть весьма качественная поддержка Ерланга ( плагином ). Есть и для Эклипса, и для Емакса...
IT>Как раз не надо сравнивать конкретные языки. Сравнивать нужно подходы.
Но как ? Каковы критерии ? Веса, так сказать, для сравнения
Критерии для разных подходов тоже будут разными, не так ли ?
Здравствуйте, gandalfgrey, Вы писали:
G>Кроме того, многое из буржуйского софта просто нельзя использовать по причинам оборонным.
Тогда все ясно.
E>>Если система была запущена в 99-м, а разрабатываться начала, как минимум, в 98-м, то альтернативы C++ в то время нужно было еще поискать. Та же Java была совсем другой, на первом пне тормозила безбожно. G>Системя была запущена в 97, а начало разработки — примерно 94 год. Где-то до 2002 продолжала доводиться. Тогда уже можно было поискать что-то более другое
Да уж, годы еще те.
Тем более тогда создавать подобные решения с жесткими требованиями по быстродействию и ресурсоемкости особо не на чем было. Разве что Ada, Modula-2 да Eiffel, только кто ж их тогда здесь знал.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали: G> Есть вещи более важные и более интересные. Мне интересно, с чем же он таким столкнулся в разработке, что пришел к настолько убежденной и нестандартной позиции. Это наверняка что-то интересное — и это не так просто объяснить.
Могу высказать свое IMHO ( или даже скорее "наблюдение") об одной из причин:
количество алгоритмических ошибок очень сильно зависит от того какой кусок логики (не кода!) программист может тувидеть одновременно на экране.
Здравствуйте, Mirrorer, Вы писали:
M>А вот для Эрланга. Банальный пример. Если сделать rename чего-нить. Как IDE найдет все ссылки на ту вещь, которую мы хотим переименовать ? И когда вылезет ошибка если вдруг преименовали не так? конечно есть Dyalizer, но это как бы и не компилятор, и я не уверен, что IDE вовсю пользуют его возможности.
Вопрос — что же переименовать хочешь
В голове такие варианты:
1. имя функции
2. имя переменной
3. имя атома
4. имя процесса
первые 3 варианта элементарны, 2-й самый примитивный, т.к. переменные локальны, то даж смотреть больше никуда не надо
Если у нас есть исходники всех модулей системы, то 1 и 3 тоже решаются довольно несложно.
Правда, если есть "сторонние" модули (а такое возможно т.к. статически мы прочекать всё не можем, нет монолитной системы), то возникают некоторые проблемы.
Ну и 4-й пунт как раз вот "сторонними" вызовами чреват, т.к. мы не можем отследить "внешние" вызовы, которые приходят из сети, но тут думаю играет роль тот фактор, что адресация напрямую к процессу есть архитектурно неправильное решение.
AE>Поскольку в Erlang нет глобальных переменных, то при перемиеновании переменной за пределами функции ничего искать не надо. При переименовании функции, тоже все обычно, как везде (даже проще, поскольку функции не экспортированные явно, локальны в пределах модуля).
А вот тут как раз не всё так гладко как кажется
Имя функции может быть выражением, т.к. вычисляться в рантайме (хотя реальных примеров видел такого мало).
Пример:
Здравствуйте, Alex EXO, Вы писали:
К>>Имя функции может быть выражением, AE>Согласен. Но это в любом случае уже несколько извращенный вариант (лучше уж саму функцию положить в переменную).
Не, вроде бы какие-то вменяемые варианты использования в рассылке пробегали, только уже не помню...
Думаю пример такого — использование функций из разных модулей (т.е. имя функции одно и то же, но в зависимости от фазы луны вызываем модуль1 или модуль2), хотя тоже сценарий несколько жутковатый
AE>В Java если все откастовать в Object, то рефакторинг тоже накроется. Так что абсолютной дуракоустойчивости не бывает.
Конечно, только есть языки более "чёткие" с этой точки зрения, скажем Haskell, где статическая типизация более скурпулёзна чтоли.
Здравствуйте, WolfHound, Вы писали:
WH>Ну вот мы и выяснили что дело не в том что динамика рулит, а втом что на жабе писали...
Дык ить ! Может, потому жаба и некошерна, что сугубо статична ?
Люди, разрабатывавшие проект на жабе, тоже ведь не маниаки какие-то. Но чем же обьяснить такой разрыв в количестве строк ?
Как было все, связанное с программингом, искусством во времена Вирта и Хоара, так и сейчас осталось на уровне восприятия и подсознательных побуждений...Рационального обьяснения для многих парадоксов разработки просто не существует, да и не может существовать по причине полной иррациональности и субьективности этих парадоксов.
Здравствуйте, gandalfgrey, Вы писали:
G>Как было все, связанное с программингом, искусством во времена Вирта и Хоара, так и сейчас осталось на уровне восприятия и подсознательных побуждений...Рационального обьяснения для многих парадоксов разработки просто не существует, да и не может существовать по причине полной иррациональности и субьективности этих парадоксов.
Что не отменяет естественного желания поверить алгеброй гармонию, чем мы здесь все и пытаемся заниматься
Здравствуйте, Gaperton, Вы писали:
G>Это так. Только ответ на вопрос — как это скажется на всем сроке разработки не так однозначен.
Согласен, не однозначен.
G>Чтобы ответить на него, надо знать, каком процент ошибок типизации к прочим ошибкам — раз, и среднее время исправления ошибки типизации против ошибок прочих классов — два.
Более того он может быть разным на разных задачах, у разных людей. А возможно при попытке его измерения сработает левый фактор который будет записан как основное действие.
G> Не собирая подробных метрик ответить на ти вопросы невозможно, это три. Но можно дать экспертные заключения.
Собирая тоже не просто. Тут можно только говорить об опыте. Что в общем можно назвать экспертным заключением.
G>К примеру, алгоритмические ошибки и ошибки управления ресурсами обходятся существенно дороже — они занимают примерно от 15 мин до двух часов, в среднем — около получаса на исправление.
Не соглашусь. Хотя тут важно разбить проблему.
1. Алгоритмические ошибки. Не факт, что они обходятся дороже или дешевле. Тут могут быть варианты. 99% алгоримический ошибок у меня отлавиливаются очень быстро. Но есть такие которые я ловлю днями. Или даже откладываю их поиск и справление на потом в виду сложности их обнаружения/исправления.
При этом помню ошибки на динамических языках (ЯваХрип в ASP (не .NET)) которые я искал очень долго. Было это, например, так... Все работало как часы. Потом что-то там поправил в другом месте и привет. Не пашет и все тебе. Точнее пашет, но не так как следовало бы. Искал ошибку долго. Только откатив изменения и накатывая их частями я нашел ошибку. Оказалось перекрытие перменной в виду очепятки. Все работало пока перменная не была по сути нужа, но как только появилась такая же переменная которая временами получала значения изменялась еще одна переменная и уже этот побочный эффект вылизал как-будто ошибка была в логике программы. По сути была ошибка второго порядка которые я до этого видел только в С++ при ошибках с указателями (т.е. затирание памяти и наложенка от этого). В типизированной прорамме я бы получил предупреждение компилятора о том, что а) я переопределяю переменную (в прочем это к динамике не отностися, но наблюдается во всех динамических императивных языках), б) о том, что я использую одну и ту же переменную для хранения разных типов данных (одна была строка, а вторая что-то более сложное).
2. Управление ресурсами... На самом деле эта проблема относится к типобезопасности. Просто потери памяти не так страшны. Да и в GC-языках их можно допустить:
calss Global
{
public static List<object> AddGarbageHere = List<object>();
}
А вот ошибки с указателями, использование "мертвых" объектов и т.п. — это уже все следствие слабости системы типов.
Мне, чесно говоря кажется, что без GC или подсчета ссылок (короче, без автоматического управления памятью) вообще нельзя создать типобезопасный рантайм.
Так вот, С++ попросту не типобезопасный язык. А вот подавляющее большинство скриптовых языков как раз типобезопасны. Вот только типобезопастность проявляется исключительно в рантайме.
Так что я согласен, что "скрипты безопаснее С++", но не потому, что они "скрипты", а потому что С++ не типобезопасен (вообще). Если же мы возьмем к примеру Яву, то тут все уже будет по другому. Она как раз типобезопасна, причем в огромной мере эта типобезопасность проверяется еще до компиляции.
Далее вспоминаем о приемуществе раннего обнаружения ошибок...
...и сделаем простой вывод, что при прочих равных статика обеспечивает большую надежность. Другой вопрос насколько. Вот это уже зависит от взглядов, опыта и т.п.
G> Простыми тестами они не ловятся. Ошибки типизации ловятся простейшими тестами, и их исправление (обыкновенно такие ошибки — что-то вроде опечаток) обходится в минуты.
Я еже говорил, что "это зависит". Бывают разные ошибки. Бывают ошибки типов которые хрен поймаешь (С++ тому ярчайшее подтверждение). А быват и логические которые ловятся банальным пробеганием в отладчике.
G> По моему опыту так.
А по моему — иначе.
G> И замедление разработки от динамики в результате получается незначительное — в рамках погрешности измерения. Я его не замечаю. Однако, эти статистики очень индивидуальны.
Тут не учтены еще несколько факторов. Не маловажным является поддержка IDE. Я понимаю, что есть люди которые пишут по английски вслепую, помнят все библиотеки на изусть, и программу сначала продумывают на бумажке. Но таких все же не много, да и есть у меня подозрение, то они просто решают слишком примитивные задачи. Или решают задачи слишком медленно (никто же не сравнивал "быстродействие" разных программистов?).
Для работы боьшинства сервисов IDE нужна информация о типах. Причем она нужна еще до запуска программы. Динамика это обеспечить не может. Даже интелисенс будет очень ограниченым, а уж о хинтах, навигации, автоматическом рефаторинге можно забыть. И не надо мне преводить в качестве примера Смолток. Сколько бы не вопили его фанаты, но рефаткорирг там примитивнешйий (по функционалу почти сравнимый с поиском с заменой на базе регекспов).
G>Я бы сказал так — динамический язык со сборкой мусора будет безопаснее и продуктивнее, чем строготипизированный С++ с ручным управлением памятью.
Я бы тоже так сказал, но... см. выше.
G>Подтвердить или опровергнуть все это объективно может только сбор метрик с реальных проектов, как по статике, так и по динамике. У меня есть только данные по метрикам Эрикссона
Откровенно говоря доверия к Эриксону в этом вопросе у меня нет совсем. Им нужна база для пиара своей разработки. Такие оценки должны делаться независимыми экспертами. И даже при этом такие данные будут весьма спорными.
Точно установить истину можно было бы проведя большой объем эксперементов. Но это слишком дорого. Так что этим никто заниматься не убдет.
VD>>Влияет. Я могу пологаться на более высокоуровневые тесты и на меньший их обхем. G>Твои тесты должны обеспечить хотя бы то, что каждая строчка написанного тобой кода будет ими вызвана — независимо от типа типизации.
На самом деле этого недостаточно. Программа это не примитивная фукнция. В ней меняется состояние и один и тот же код может перестать работать при некоторых условиях.
G> Иначе это не тесты, а говно — у тебя ни разу не тестированный код в релиз попадет. Так вот, такие тесты выловят 99% ошибок типизации
К сожалению не выловят. Все по той же причине. Состояние меняется и с ним меняются условия. Чем динамичнее система тем меньше толку от тестов всего лишь "покрывающих код".
Есть задачи где тесты могут что-то гарантировать, есть в которых они бессильны. Многие интерактивные системы и просто системы со сложной логикой и большой вариативностью данных приводят к тому, что тесты могут только снизить число ошибок и гарантировать отсуствие их повторения (если это пакетные тесты проганяемые переодически).
Так вот компилятор с жесткой (или жестокой) логикой контроля все же нехило помогает в контроле за структурой кода. То что у любого объекта можно взывать любой метод (послать сообщение и т.п.) приводит к тому, что могут появляться наложенные ошибки. А вот именно они то и являются самыми опасными, так как мы должны уже думать в двумерном пространстве (точнее в Х-метром).
Просто, согласен, что в С++ такие ошибки получаеются чаще чем в динамике. И согласен, что в том же Эрлэнге таких ошибок оказвается меньше чем в обычных динамических языках, так как язык функциональный (меньше состояния, меньше побочных эффектов). Но давайте признаем правду. Приемущество Эрлэнга не в динамике, а в некоторых архитектурных решениях его авторов.
VD>>А скажем для рефакторинга мне вообще тесты не нужны будут. G>Агащаз. Доказывать функциональную эквивалентность нового и старого кода (что он после твоего рефакторинга делает то же самое, что и раньше) кто будет без тестов? Пушкин?
Мне не нужно доказывать если рефакторинг автоматический. Как раз статическая типизация позволяет алгоритмизировать рефакторинг.
VD>>Более того его можно будет автоматизировать). Ведь мы знаем все о коде еще до его запускат. Значит мы может менять его соблядая при этом инваринт. G>Если бы мы действительно знали о коде все, до того, как мы его запустим, то тогда конечно да. Только знание типов гораздо ближе к "почти ничего".
Э... не надо таких приемов. Я не в филосовском смысле. Просто если мы переименовываем переменную в СТЯ (статически типизированном языке), то мы в состоянии вычислить все вхождения этой переменной в программе и не будем страдать от наличия одноименных переменных. Та же фигня с другими видами рефакторинга. Так что "знаем о коде все" не значит, что наш компилятор/IDE стали вдруг обладать интелектом. Это значит, что мы знаем, что означет какой идентификатор и можем использовать это знание для автоматизации нашей работы.
G>Знаешь Влад, меня в последнее время больше заботит не то, что человек сказал, а то — зачем он это сказал.
Красивая фараз. Чья?
G> Человек сказал, что ему кажется, что динамика помогает ему писать надежный код. Ему так сильно это кажется, что он не представляет, как это можно вообще без динамики. Ну, сразу видно, сгоряча сказал, и наверняка сам это понял.
Ага.
G>И все заметили, и все поняли, что характерно.
Да? Странно. Заметь я всего лишь слегонца постебался над товарищем. И сдела я это именно потому что "сразу видно, сгоряча сказал, и наверняка сам это понял". И сказал это просто для того, чтобы он в дальнейших своих речах был чуть аккуратнее и не заговаривался. Можно сказать, помочь ему хотил. Но нашлись несогласные
Да какой шашкой. Просто смешно ведь когда люди серьезно обсуждают исходно обсурдную фразу брошенную на радостях, в пылу писательского порыва.
G>Мне интересно, с чем же он таким столкнулся в разработке, что пришел к настолько убежденной и нестандартной позиции.
Ну, дык выяснили же. Человек путает понятие надежности и скорости разработки. При этом он делает набор ложных умозаключений:
* Эрлэнг позволяет ускорить разработку.
* Ускорение разработки может дать дполнительное время на тестирование.
* Дополнительное тестирование приводит к повышению качества.
* Эрлэнг — динамический язык.
Выоды: Значит — динамика единственный способ добиться надежности софта.
То что при этом ускорение не обязательно ведет к повышению качества, и то, что Эрлэнг обладает обладает кроме динамики рядом других достоинств (метапрограммирование и сопоставление с образцом) которые приводят к ускорению разрабтки он даже не подумал. В прочем как он вообще умудрился сделать связь с динамикой для меня вообще остаяется загадкой. В этих рассуждениях нет ни одной зацепки для этого.
С тем же успехом я могу сделать вывод, что скажем Nemerle (обладающий тем же паттерн-матчингом и поддерживающий метапрограммирование) так же ускоряет разработку (и это скорее всего верный вывод), а дальше сделать тагую же логическую ошибку и заявить, что так как Немерле статически типизированный, то стало быть статика является необходимым средством для построения надежных систем.
Бред?... Несомненно. Но логика (точнее ее отсуствие) та же.
G> Это наверняка что-то интересное — и это не так просто объяснить. Тут бы человеку наводящими вопросами помочь, чтобы объяснил.
Дык я уже под столом лежал. Мне надо было о жувоте заботиться, а не вопросы задавать .
G>А ты вместо этого цепляешься к словам, и пытаешься всем доказать и так очевидные для всех вещи. Зачем?
Как показывает практика это не "очевидные для всех вещи".
G> К тебе точно так же можно докопаться, и доказать, что с формальной точки зрения ты несешь чушь. Да к любому можно так докопаться — рано или поздно скажет что-нибудь неоднозначное. Думаешь, ты мало таких вещей говоришь?
Я думаю, что все в этой жизни ошибаются. И я, и ты и автор этих строк. И думаю, что на моее сообщение
Здравствуйте, gandalfgrey, Вы писали:
G>В нее вбухано более 20 человеколет. Это число достаточно велико, чтобы обьяснить, почему я считаю С++ малопригодным для построения чего-то более-менее сложного — это просто ОЧЕНЬ дорого обходится.
С этим спорят только оконченные фанаты С++.
G>К Жабе примерялись, но существенного выигрыша тут все же нет.
А вот это уже откровенно не верный вывод.
G>Вот использование Ерланга и Тикля себя оправдало. Сейчас даже при желании от них невозможно отказаться — уж очень эффективно решаются проблемы с их помошью. G>Более того, во многих других конторах, занимающихся аналогичными задачами, как-то стихийно наметился уклон в сторону языков с динамической типизацией.
Если бы ты сказал "Эрлэнг нам помог разрабатывать приложения быстрее" никто ничего не сказал бы. А так...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Соотношение количества строк для проектов на Жаве и Ерланге, реализующих примерно одинаковую функциональность. Я эти числа приводил в исходном сообщении. Разница более чем на порядок ( в пользу Ерланга )
Разница на порядок это такой же гон высасаный из пальца как гон о том, что только динамика обеспечивает надежность. У эрлэнга есть ряд факторов позволяющих сократить объем кода. Основны из них отсуствие декларации типов. Это не даст более 30% выигрыша. И паттерн-матчинг. Это может дать несколько раз. Но никак не порядок.
Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина.
G>Вряд ли я могу представить исчерпывающее теоретическое обоснование такового мнения... Все, что я излагал в прочих сообщениях, является моим личным експириенсом и ИМХО.
К сожалению, просто опыт мало интересен. Интересны обоснования. Вот их и не видно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Вообще крайне сомневаюсь, что возможны РАЦИОНАЛЬНЫЕ аргументы по поводу превосходства одного языка над другим. Разве что для очень близких языков...Возможно, таких как С++ и D ? И даже в этом случае не уверен в корректности этого сравнения
Мне кажется рациональным аргументом является то что язык A может все что B плюс неких z который позволяет упрощать ряд решений. Скажем если у нас есть Ява с паттерн-матчиногом, то просто Ява отдыхает. Если у нас есть Ява с миксинами, то просто ява отдыхает. В итоге сомнений в том, что Ява < Скала лично у меня нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alex EXO, Вы писали:
AE>Поскольку в Erlang нет глобальных переменных, то при перемиеновании переменной за пределами функции ничего искать не надо. При переименовании функции, тоже все обычно, как везде (даже проще, поскольку функции не экспортированные явно, локальны в пределах модуля).
Вспоминаем про программно изолированные процессы, сообщения которыми они обмениваются и про то, что в Эрлэнге есть разные хэш-таблицы хранящие состояние процесса. Как с ними?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вспоминаем про программно изолированные процессы, сообщения которыми они обмениваются и про то, что в Эрлэнге есть разные хэш-таблицы хранящие состояние процесса. Как с ними?
С ними согласен — есть сложности.
Но не в смысле "рефакторинга переименования" (о котором был вопрос). С этим видом рефакторинга как раз сложности минимальные.
Вот если бы было спрошено про рефакторинг набора параметров в сообщении — то да...
Здравствуйте, VladD2, Вы писали:
VD>Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина.
VladD2, в последних постах тут ты что-то упираешь на метапрограммирование — можно поинтересоваться, что ты имеешь в виду под этим в Эрланге? Там, конечно, есть parse transforms, но их даж рекомендуют по возможности избегать.
Здравствуйте, VladD2, Вы писали:
VD>Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина.
У Явы есть одна проблема свер прочих: слишком много халявного кода, с не очень (мягко скажем) хоршей архитектурой.
На ранних этапах проектов — это соблазн, на поздних — попадалово...
Здравствуйте, VladD2, Вы писали:
VD>Хочу поменять структуру записи которая используется для передачи сообщений в другие процессы.
VD>Что делать?
Тут есть 2 варианта — если используется именно структура, т.е. record в рамках Эрланга, то это сделать имхо вполне возможно. Считай чуток стат. типизации имеется
Но вот только эти recordы не есть повсеместно используемая вещь, т.к. для их использования необходима перекомпиляция всех модулей, а это даёт зависимости и т.п. Поэтому чаще сообщения посылают обычными туплами/списками. А тут рефакторинг — дело, по меньшей мере, тяжкое
Здравствуйте, VladD2, Вы писали:
VD>Откровенно говоря доверия к Эриксону в этом вопросе у меня нет совсем. Им нужна база для пиара своей разработки. Такие оценки должны делаться независимыми экспертами. И даже при этом такие данные будут весьма спорными.
А собственно, почему ? Они же Ерлангом не торговали. Покупателям же всякого ихнего железа без разницы, что внутри — Ерланг или Бабсик. Лишь бы обеспечивалось соответствие заявленным параметрам
VD>Э... не надо таких приемов. Я не в филосовском смысле. Просто если мы переименовываем переменную в СТЯ (статически типизированном языке), то мы в состоянии вычислить все вхождения этой переменной в программе и не будем страдать от наличия одноименных переменных. Та же фигня с другими видами рефакторинга. Так что "знаем о коде все" не значит, что наш компилятор/IDE стали вдруг обладать интелектом. Это значит, что мы знаем, что означет какой идентификатор и можем использовать это знание для автоматизации нашей работы.
Отсутствие глобальных переменных уже не раз спасало отцов русской демократии
VD>Да? Странно. Заметь я всего лишь слегонца постебался над товарищем. И сдела я это именно потому что "сразу видно, сгоряча сказал, и наверняка сам это понял". И сказал это просто для того, чтобы он в дальнейших своих речах был чуть аккуратнее и не заговаривался. Можно сказать, помочь ему хотил. Но нашлись несогласные
.
Ну как, "сгоряча" ? Заинтересованные люди спросили меня о ходе проекта, я изложил то, что думаю о причинах успеха. Ежели кому-то это показалось не очень осмысленным или вовсе бредовым — что ж, jedem das seine.
VD>Да какой шашкой. Просто смешно ведь когда люди серьезно обсуждают исходно обсурдную фразу брошенную на радостях, в пылу писательского порыва.
"Исходно абсурдную" — звучит весомо
VD>Ну, дык выяснили же. Человек путает понятие надежности и скорости разработки.
Так-таки и путаю ? Надежность в моем понимании ( для краткости обьединим это понятие с устойчивостью ) — это вероятность отработки системой своего функционала в полной мере на протяжении некоего, достаточно большого, периода. Надежность 99.9999 % означает, что время дисфункции за месяц не может превышать 2.5 секунд.
Или есть какие, более другие трактовки этого термина ?
VD>* Эрлэнг позволяет ускорить разработку.
Это верно VD>* Ускорение разработки может дать дполнительное время на тестирование.
Тоже верно, но не только ЭТО оно может дать. Вследствие брожения, происходящего в репах разработчиков, длительные процессы имеют тенденцию еще более замедляться и как бы сопровождаться дополнительными глюками. По моему глубочайшему убеждению, сокращение времени разработки само по себе способствует повышению надежности, даже без привлечения дополнительных факторов. VD>* Дополнительное тестирование приводит к повышению качества.
И это верно, но не как основной фактор. VD>* Эрлэнг — динамический язык.
Именно VD>Выоды: Значит — динамика единственный способ добиться надежности софта.
Как я уже писал в этой теме, и писал не раз — способ не единственный, но самый дешевый. И вывод этот сделан был не на основании упомянутых выше 4-х факторов, а как экспертная оценка. Надеюсь, разница заметна ?
VD>То что при этом ускорение не обязательно ведет к повышению качества, и то, что Эрлэнг обладает обладает кроме динамики рядом других достоинств (метапрограммирование и сопоставление с образцом) которые приводят к ускорению разрабтки он даже не подумал.
Опять-таки, подумал или нет — это вопрос, на который могу ответить только я. Верно ? Паттерн матчинг есть сейчас во многих языках, потому я исключил его их рассмотрения. А метапрограммирование в Ерланге — и вовсе совершенно отдельная песня.
VD> В прочем как он вообще умудрился сделать связь с динамикой для меня вообще остаяется загадкой. В этих рассуждениях нет ни одной зацепки для этого.
Как я уже НЕ РАЗ писал, это вывод из личного опыта. Причем не только моего.
Здравствуйте, VladD2, Вы писали:
G>>Более того, во многих других конторах, занимающихся аналогичными задачами, как-то стихийно наметился уклон в сторону языков с динамической типизацией.
VD>Если бы ты сказал "Эрлэнг нам помог разрабатывать приложения быстрее" никто ничего не сказал бы. А так...
В данном случае я говорю не только про Ерланг. Тикль, несмотря на свою ограниченность, тоже очень часто выигрывает у статических языков. А это уже тенденция, не правда ли ?
Кстати ! Почему все время "Эрлэнг" ? Это фамилия скандинавского мужика, и читается она как "Ерланг".
Здравствуйте, VladD2, Вы писали:
VD>Разница на порядок это такой же гон высасаный из пальца как гон о том, что только динамика обеспечивает надежность. У эрлэнга есть ряд факторов позволяющих сократить объем кода. Основны из них отсуствие декларации типов. Это не даст более 30% выигрыша. И паттерн-матчинг. Это может дать несколько раз. Но никак не порядок.
Ну что означает "гон" ? Есть данные по нашему проекту, есть данные по аналогичному проекту на Жабе, который делался достаточно квалифицированными разработчиками. И есть соотношение чисел
VD>Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина.
Метапрограммирование ? Тут какая-то ошибка. У нас динамически порождаются функции и интерфейсы к данным, но это все в рамках лямбда-исчисления
VD>К сожалению, просто опыт мало интересен. Интересны обоснования. Вот их и не видно.
Я попытался изложить некоторые догадки об обоснованиях...
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется рациональным аргументом является то что язык A может все что B плюс неких z который позволяет упрощать ряд решений. Скажем если у нас есть Ява с паттерн-матчиногом, то просто Ява отдыхает. Если у нас есть Ява с миксинами, то просто ява отдыхает. В итоге сомнений в том, что Ява < Скала лично у меня нет.
То-есть сравнение корректно ТОЛЬКО для языков, один из которых является прямым наследником другого ?
Re[12]: Бизнес-логика на Erlangе
От:
Аноним
Дата:
23.05.07 14:22
Оценка:
VD>Мне кажется рациональным аргументом является то что язык A может все что B плюс неких z
БАшня из слоновой кости
Сравниваем C и D.
Есть в D malloc/free ? есть в нём #define ? есть в нём "массив == указатель" ?
Получается, что D не больше C.
И так будет почти в любой паре языков, если специально их не подбирать.
Здравствуйте, gandalfgrey, Вы писали:
G>В данном случае я говорю не только про Ерланг. Тикль, несмотря на свою ограниченность, тоже очень часто выигрывает у статических языков. А это уже тенденция, не правда ли ?
Не правда — ли.
Вообще ты меня извини за некоторый переход на личности, но твое неумение грамотно делать логические выводы просто напрягает.
Даже если отбросить ничем не подтвержденное заявление о том что Тикель выигрывать у чего-то абстрактного на статически типизированного, то как его выигрышь можно проецировать на весь класс динамических языков. Скажем QuickBasic динамический язык, но с чего он может дать какие-то приемущества?
G>Кстати ! Почему все время "Эрлэнг" ? Это фамилия скандинавского мужика, и читается она как "Ерланг".
По правилам английской грамматики .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alex EXO, Вы писали:
AE>У Явы есть одна проблема свер прочих: слишком много халявного кода, с не очень (мягко скажем) хоршей архитектурой. AE>На ранних этапах проектов — это соблазн, на поздних — попадалово...
Да, уж. Проблема выбора — ужасная вещь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Ну что означает "гон" ? Есть данные по нашему проекту, есть данные по аналогичному проекту на Жабе, который делался достаточно квалифицированными разработчиками.
А я вот сегодня пример на Васике написал. По моим данным там 10 строк кода и ни одной ошибки. Можно на основании этого делать какие-то выводы?
Помйми, есть научные принцыпы получения достоверных сведений. Нельзя сравнивать что-то просто ради того, что у ниго схожие фукнции и потом проецировать результат этого сравнения на языки прогаммирования. Возможно в иных условиях оказалось бы, что программа на Эрлэнге распула и равалилась, а Явская блестела и сверкала. Причем просто потому, что изменился состав команд.
Сравнивать можно только есть достоверные и объективные данные. Такими данными могут быть специльные сравнения в которых гарантируется, что качество проектирования одинаково высокое. Или статистика собранная по большому количеству проектов (где высчитывается среднее качество).
Я уверен, что объм эрлэнг-кода для многих задач будет существенно меньеш явского, но меня гложут большие сомения, что тут можно говорить о порядках.
VD>>Ваша разница скорее всего является следствием не очень грамотного проектирования на Яве и более менее грамотного на Эрлэнге. Вы, как я понял, использовали метапрограммирование. Это серьезное средство для сокращения объемов кода в задачах где есть много, что можно сгенерировать по модели. На Яве я так понимаю — этого не делалось. Вот и причина. G>Метапрограммирование ? Тут какая-то ошибка. У нас динамически порождаются функции и интерфейсы к данным, но это все в рамках лямбда-исчисления
Любое программное порождение кода — это метапрограммировиние. А лямбд-исчисления вообще невозможны на современных компьютерах. Тут скорее о машине Тюринга нужно говорить. И вообще это обастракный треп. Вы берете некую модель и получаете код для обработки нужных вам данных. Это ни что иное как метапрограммирование. Конечно Ява не лучшее средства для метапрогараммирования, но тем не мнее им можно заниматься и в нем. Только по сложнее.
Так вот сравнивая решения одно из которых создано с массовым использванием МП, а другое решено методов закидывания буденовками ты можешь сделать только один вывод — задача проще решается средствами МП. Но на Яву это уже обощать нельзя.
VD>>К сожалению, просто опыт мало интересен. Интересны обоснования. Вот их и не видно. G>Я попытался изложить некоторые догадки об обоснованиях...
И даже в этом делашь море логических ошибок нивилирующих твои слва.
ЗЫ
На самом деле я очень тебя понимаю. Ты чувствуешь, что некое средство Х дает тебе приемущество перед тем, что ты использовал ранее. И ты хочешь этим поделиться. Это хорошо. Но ты не можешь найти реальную суть приемущества и ты начинашь обощать догадки. Результат получается фиговый. Тут лучше все же потратить время на анализ и попытаться докопаться до сути.
Проблема только в том, что мне кажется, что эта суть будет сильно расходиться с твоими теперешними выводами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>БАшня из слоновой кости
Тебе виднее.
А>Сравниваем C и D. А>Есть в D malloc/free ?
Есть аналоги.
А> есть в нём #define ?
Специально изведен. Вместо него даны адекватные, но не имеющие тех проблем замены.
А> есть в нём "массив == указатель" ?
В С/С++ фактически нет массива. Он там ублюдочный. В ди же есть и массивы и указатели и возможность получить указатель на массив.
А>Получается, что D не больше C.
Получаем безответсвенный гон с твоей стороны в данном случае.
Но мысль ясна. Не все языки можно разложить в некую линию где один однозначно лучше, а другой однозначно хуже. Вот только D и C точно не из этого списка.
А>И так будет почти в любой паре языков, если специально их не подбирать.
Скажем так. Любой язык программирования — это дизайнерское решение. Всегда нужно идти на компромисы выбирая между решениями. И конечно сравнение языков есть сложный и не однозначный процесс. Вот толко это никак не влияет на возможность сравнивать языки. Те же С/С++ на столько отстали от жизни, и являются настолько ублюдочными по сравнению с более молодыми, что проигрывают всегда если сравнение объективно.
Собственно единственное на чем пока держится С/С++ — это на том, что для него существуют компиляторы с офигительными оптимизаторами и то, что рантаймы этих языков минимальны. Со временем эти приемущества будут нивелироваться. Они уже и сейчас не актуальны для большинства задач.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>То-есть сравнение корректно ТОЛЬКО для языков, один из которых является прямым наследником другого ?
Скажем так. Для таких языков оно 100%-доказуемо корректно. В прочем, и тут можно найти свои "но". Скажем в C# есть unsafe-код, а в Немерле нет. Для кого-то это недостаток.
Вторая проблема сравнения — это выбор предпочтений. Скажем кто-то может настолько верить в идею, что любая анотация типов — это вселенское зло, что кроме динамики ни во что не верить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
VD>>Откровенно говоря доверия к Эриксону в этом вопросе у меня нет совсем. Им нужна база для пиара своей разработки. Такие оценки должны делаться независимыми экспертами. И даже при этом такие данные будут весьма спорными. G>А собственно, почему ? Они же Ерлангом не торговали. Покупателям же всякого ихнего железа без разницы, что внутри — Ерланг или Бабсик. Лишь бы обеспечивалось соответствие заявленным параметрам
Они Эрлэнг продвигали. Они априори предвзяты. Как бы ты отнесся к тому, что тебя разрешили судить не судье, а милиции или налоговой? А аргументировали бы так же как ты "они же не продают ничго...".
G>Отсутствие глобальных переменных уже не раз спасало отцов русской демократии
В Эрлэнге их аналоги все таки есть. Хотя наверно их меньше чем скажем в Питоне. Вот только это заслуга выбора авторами Эрлэнга функционального подхода, а не динамики. Иначе бы твои рассуждения можно было бы распространить и на Питон с Васиком.
G>Ну как, "сгоряча" ? Заинтересованные люди спросили меня о ходе проекта, я изложил то, что думаю о причинах успеха. Ежели кому-то это показалось не очень осмысленным или вовсе бредовым — что ж, jedem das seine.
То есть ты считашь утверждение "только на динамике можно добиться надежности" верным?
G>"Исходно абсурдную" — звучит весомо
Ну, что поделаешь. Если бы ты умел применять логический вывод к своим утверждениям, то понял бы, что так оно и есть.
VD>>Ну, дык выяснили же. Человек путает понятие надежности и скорости разработки. G>Так-таки и путаю ? Надежность в моем понимании ( для краткости обьединим это понятие с устойчивостью ) — это вероятность отработки системой своего функционала в полной мере на протяжении некоего, достаточно большого, периода. Надежность 99.9999 % означает, что время дисфункции за месяц не может превышать 2.5 секунд. G>Или есть какие, более другие трактовки этого термина ?
Конеретные цыфры ты сюда зря влючил. Без них определение вполне приемлемо. Но причем тут это?
В прочем, согласен. Ты не термины путашь. Ты законы логики нарушаешь. Ты из заключения о том, что из А следует Б, делаешь заключение что из Б следует В. Причем никакой видимой связи межд Б и В нет.
G>Тоже верно, но не только ЭТО оно может дать. Вследствие брожения, происходящего в репах разработчиков, длительные процессы имеют тенденцию еще более замедляться и как бы сопровождаться дополнительными глюками. По моему глубочайшему убеждению, сокращение времени разработки само по себе способствует повышению надежности, даже без привлечения дополнительных факторов.
А вот люди которые делали первые ракеты делали все крайне долго проверя все по сто раз и усложняя тем самым решение. Но в итоге на их разработках мы и сейчас в космос летаем.
VD>>* Дополнительное тестирование приводит к повышению качества. G>И это верно, но не как основной фактор.
Какой к черту факто?
VD>>* Эрлэнг — динамический язык. G>Именно
Что именно? Где связь? Где логика?
VD>>Выоды: Значит — динамика единственный способ добиться надежности софта. G>Как я уже писал в этой теме, и писал не раз — способ не единственный, но самый дешевый. И вывод этот сделан был не на основании упомянутых выше 4-х факторов, а как экспертная оценка. Надеюсь, разница заметна ?
Заметно, то что с логикой у тебя просто кранты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А я вот сегодня пример на Васике написал. По моим данным там 10 строк кода и ни одной ошибки. Можно на основании этого делать какие-то выводы?
Вот если бы этот пример обеспечивал функциональность информационной системы, то можно было. А так — нет. Мы же сравниваем характеристики проектов на разных языках, но с близким функционалом.
VD>Помйми, есть научные принцыпы получения достоверных сведений. Нельзя сравнивать что-то просто ради того, что у ниго схожие фукнции и потом проецировать результат этого сравнения на языки прогаммирования. Возможно в иных условиях оказалось бы, что программа на Эрлэнге распула и равалилась, а Явская блестела и сверкала. Причем просто потому, что изменился состав команд.
Возможно-возможно, но тем не менее это единственная РЕАЛЬНО существующая методика сравнения различных платформ.
VD>Сравнивать можно только есть достоверные и объективные данные. Такими данными могут быть специльные сравнения в которых гарантируется, что качество проектирования одинаково высокое. Или статистика собранная по большому количеству проектов (где высчитывается среднее качество).
Ну, это уже какой-то идеализм. Даже солипизм, я бы сказал ! Ведь требования совершенно нереальные
VD>Я уверен, что объм эрлэнг-кода для многих задач будет существенно меньеш явского, но меня гложут большие сомения, что тут можно говорить о порядках.
Я говорил о конкретном случае. На других задачах действительно может быть несколько иначе
VD>Любое программное порождение кода — это метапрограммировиние. А лямбд-исчисления вообще невозможны на современных компьютерах. Тут скорее о машине Тюринга нужно говорить. И вообще это обастракный треп. Вы берете некую модель и получаете код для обработки нужных вам данных. Это ни что иное как метапрограммирование. Конечно Ява не лучшее средства для метапрогараммирования, но тем не мнее им можно заниматься и в нем. Только по сложнее.
Это не является метапрограммированием ! Иначе применение пары функциональных комбинаторов тоже будет им являться
Здравствуйте, VladD2, Вы писали:
VD>Скажем так. Для таких языков оно 100%-доказуемо корректно. В прочем, и тут можно найти свои "но". Скажем в C# есть unsafe-код, а в Немерле нет. Для кого-то это недостаток.
Тогда о чем речь, ежели in vivo такие сравнения бессмысленны ?
VD>Вторая проблема сравнения — это выбор предпочтений. Скажем кто-то может настолько верить в идею, что любая анотация типов — это вселенское зло, что кроме динамики ни во что не верить.
Это не про меня. Ну, пишу же я маленькие модульки на С++ для расширения Тикля...Да и D понемногу начинаю использовать
Здравствуйте, VladD2, Вы писали:
VD>Вообще ты меня извини за некоторый переход на личности, но твое неумение грамотно делать логические выводы просто напрягает.
Mea culpa ! Confiteor ! 8))
VD>Даже если отбросить ничем не подтвержденное заявление о том что Тикель выигрывать у чего-то абстрактного на статически типизированного, то как его выигрышь можно проецировать на весь класс динамических языков. Скажем QuickBasic динамический язык, но с чего он может дать какие-то приемущества?
О ничем не подтвержденном якобы утверждении : какие подтверждения надобны, кроме примеров из РЕАЛЬНОЙ жизни ? Сражу скажу — теоретических доводов не будет.
Ну, КвикБабсик мы пропустим, полагаю
VD>По правилам английской грамматики .
Английская грамматика здесь неприменима, ибо известный математик Агнер Краруп Ерланг, так же как и создатели языка Ерланг, названного в его честь, говорили на шведском.
Здравствуйте, VladD2, Вы писали:
VD>Они Эрлэнг продвигали. Они априори предвзяты. Как бы ты отнесся к тому, что тебя разрешили судить не судье, а милиции или налоговой? А аргументировали бы так же как ты "они же не продают ничго...".
Куда это его они продвигали ? Насколько я помню, до 98-го года Ерланг был внутренним софтом. Только когда от Ериксона отпочковалась Bluetail, его открыли для посторонних.
VD>В Эрлэнге их аналоги все таки есть. Хотя наверно их меньше чем скажем в Питоне. Вот только это заслуга выбора авторами Эрлэнга функционального подхода, а не динамики. Иначе бы твои рассуждения можно было бы распространить и на Питон с Васиком.
Это не аналоги. Если я полезу в другой процесс за какими-то данными, и этот процесс понимает, чего я от него хочу — то это скорее можно назвать data retreiving или даже data mining. Поскольку для моего процесса источник данных будет независимым, примерно как СУБД.
VD>То есть ты считашь утверждение "только на динамике можно добиться надежности" верным?
А почему постоянно пропускается 2-ая половина моего утверждения : "с теми ресурсами, которыми располагает проект" ? Я ведь это повторил не раз и не два.
G>>"Исходно абсурдную" — звучит весомо VD>Ну, что поделаешь. Если бы ты умел применять логический вывод к своим утверждениям, то понял бы, что так оно и есть.
Если бы я был наделен даром членораздельной речи, я стал бы поэтом ....
VD>А вот люди которые делали первые ракеты делали все крайне долго проверя все по сто раз и усложняя тем самым решение. Но в итоге на их разработках мы и сейчас в космос летаем.
Разве ? А то, что Союзы на пару ПОРЯДКОВ проще Шаттлов, это известно ? Надежная техника не может быть сложной — это первое правило оборонки.
VD>>>Выоды: Значит — динамика единственный способ добиться надежности софта. G>>Как я уже писал в этой теме, и писал не раз — способ не единственный, но самый дешевый. И вывод этот сделан был не на основании упомянутых выше 4-х факторов, а как экспертная оценка. Надеюсь, разница заметна ? VD>Заметно, то что с логикой у тебя просто кранты.
Что поделать...Видимо, карма такая...Слишком много грешил писанием на статических языках в предыдущей жизни, не иначе
VD>>По правилам английской грамматики . G>Английская грамматика здесь неприменима, ибо известный математик Агнер Краруп Ерланг, так же как и создатели языка Ерланг, названного в его честь, говорили на шведском.
Кстати, в видео Джо Армстронг явно говорит "ланг", емнип
Здравствуйте, gandalfgrey, Вы писали:
G>Вот если бы этот пример обеспечивал функциональность информационной системы, то можно было. А так — нет. Мы же сравниваем характеристики проектов на разных языках, но с близким функционалом.
Ну, из чего следут, что функциональность и качество этих проектов идентичны?
VD>>Помйми, есть научные принцыпы получения достоверных сведений. Нельзя сравнивать что-то просто ради того, что у ниго схожие фукнции и потом проецировать результат этого сравнения на языки прогаммирования. Возможно в иных условиях оказалось бы, что программа на Эрлэнге распухла и развалилась, а Явская блестела и сверкала. Причем просто потому, что изменился состав команд. G>Возможно-возможно, но тем не менее это единственная РЕАЛЬНО существующая методика сравнения различных платформ.
Такие методики называются — профанацией.
G>Ну, это уже какой-то идеализм. Даже солипизм, я бы сказал ! Ведь требования совершенно нереальные
Требования не то, что бы реальны, а минимальные. Без них грош цена такому сравниню.
G>Это не является метапрограммированием ! Иначе применение пары функциональных комбинаторов тоже будет им являться
Интересное утверждение. Его нужно обдумать. Возможно, что так оно и есть. Тут нужно прояснить главное когда и на каких условиях происходит комбинирование. Если во время компиляции и безусловно, то это просто программа. Если после компиляции и при этом используется некий внешний источник данных, то в общем-то это и есть метапрграммирование.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
VD>>Скажем так. Для таких языков оно 100%-доказуемо корректно. В прочем, и тут можно найти свои "но". Скажем в C# есть unsafe-код, а в Немерле нет. Для кого-то это недостаток. G>Тогда о чем речь, ежели in vivo такие сравнения бессмысленны ?
Дело в том, что эти "но" интересны только пуристам. Если взять некий ценз, то на его основе языки сравниваются без каких либо проблем.
VD>>Вторая проблема сравнения — это выбор предпочтений. Скажем кто-то может настолько верить в идею, что любая анотация типов — это вселенское зло, что кроме динамики ни во что не верить. G>Это не про меня.
Этого никто и не утверждал. Я просто привел пример.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>Это не аналоги. Если я полезу в другой процесс за какими-то данными, и этот процесс понимает, чего я от него хочу — то это скорее можно назвать data retreiving или даже data mining. Поскольку для моего процесса источник данных будет независимым, примерно как СУБД.
Называй как угодно. От этого ничего не изменится. Состояние есть, проблемы тоже. Программа программой не престает быть если ее разбивают на процессы или классы.
VD>>То есть ты считашь утверждение "только на динамике можно добиться надежности" верным? G>А почему постоянно пропускается 2-ая половина моего утверждения : "с теми ресурсами, которыми располагает проект" ? Я ведь это повторил не раз и не два.
А потому что это без разницы. Надежность есть надежность и не надо при ее обсуждении обсуждать скорость разработки.
VD>>А вот люди которые делали первые ракеты делали все крайне долго проверя все по сто раз и усложняя тем самым решение. Но в итоге на их разработках мы и сейчас в космос летаем. G>Разве ? А то, что Союзы на пару ПОРЯДКОВ проще Шаттлов, это известно ? Надежная техника не может быть сложной — это первое правило оборонки.
Расскажи это создателям тех же буранов, например. К тому же ты глубого заблуждаешся думая, что Союзы просты. Они в сто раз сложнее твоих программ.
Я же говорю о том, что их как раз разрабатывали без разных RAD-средств. Делали работу дого и кропотливо. В начале все считалось вообще без компьюетров. Но в итоге они летают и очень неплохо. А вот Шатлы делались с применением самой свременной техники...
Все это я говорю к тому, что надежность достигается не только использованием удобных инструментов. Инструмент может облегчить решение задачи. Не больше не меньше.
G>Что поделать...Видимо, карма такая...Слишком много грешил писанием на статических языках в предыдущей жизни, не иначе
Судя по твоим словам, из статических языков ты пробовал только С++. Это вообще за опыт можно не считать. На его фоне любой нормальный язык будет выглядить супер-средством.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, из чего следут, что функциональность и качество этих проектов идентичны?
Как из чего ? Из того, что они делают практически одно и тоже, следует, что и функциональность их весьма близка. Вот про качество проектирования сказать ничего не могу, ибо не существует полноценных формальных методик оценки оного качества. Метрики кода за таковые я не считаю.
VD>Такие методики называются — профанацией.
Но других-то ( реально работающих ) просто нет !
VD>Требования не то, что бы реальны, а минимальные. Без них грош цена такому сравниню.
Гм. Но обеспечить эти требования будет сложновато
VD>Интересное утверждение. Его нужно обдумать. Возможно, что так оно и есть. Тут нужно прояснить главное когда и на каких условиях происходит комбинирование. Если во время компиляции и безусловно, то это просто программа. Если после компиляции и при этом используется некий внешний источник данных, то в общем-то это и есть метапрграммирование.
В рантайме, конечно же. Читаются исходный текст неких правил или описание данных, парсится, а потом начинается рекомбинация функторов, дабы получить одну толстую лямбду, которая и будет выполнять роль движка правил. И все же это далеко от метапрограммирования. В моем понимании, по крайней мере.
Здравствуйте, VladD2, Вы писали:
VD>Дело в том, что эти "но" интересны только пуристам. Если взять некий ценз, то на его основе языки сравниваются без каких либо проблем.
Чего-то я не улавливаю. А поподробнее ?
.
Re[14]: Бизнес-логика на Erlangе
От:
Аноним
Дата:
25.05.07 14:02
Оценка:
А>>Есть в D malloc/free ? VD>Есть аналоги.
А>> есть в нём #define ?
VD>Специально изведен. Вместо него...
"Есть аналоги."
А>> есть в нём "массив == указатель" ? VD>В С/С++ фактически нет массива. Он там ублюдочный. В ди же есть и массивы....
Т.е. говоря о Сишном массиве, снова "Есть аналоги."
VD>Но мысль ясна. Не все языки можно разложить в некую линию где один однозначно лучше, а другой однозначно хуже.
эк тебя... "лучше"...
Да просто больше-меньше (вложенность, в терминах множеств) уже почти никогда не случится.
Вернемся к твоим словам "язык A может все что B плюс неких z".
Если речь о принципиальных возможностях — то для всех Тьюринг-полных языков....
Если речь идет о конкретных возможностях синтаксиса/семантики, то почти нигде не будет полного повтора, а будет сплошное "Есть аналоги."
И поэтому формально сравнивать нельзя.
Точнее для того чтобы строгонаучноформальнообъективно сравнить, надо сначала иррационально неформально договориться, что мы считаем аналогами, а что нет. И все сравнение сведется к этому необъективному "тут похоже. а тут не похоже"
VD>Скажем так. Любой язык программирования — это дизайнерское решение. Всегда нужно идти на компромисы выбирая между решениями.
Тем самым делая невозможным сравнение "есть все до одного те же элементы + что то еще"
А дальше всй скипнуто, дальше тебя куда-то не в ту степь понесло.
Здравствуйте, <Аноним>, Вы писали:
VD>>Специально изведен. Вместо него...
А>"Есть аналоги."
Это вопрос?
Аналоги несомненно есть. Но не прямые. Вместо уродливого препроцессора D поддерживает менее уродливые вычисления времени компиляции (првад не сравнимые с макросами Лиспа или Немерла).
В D все константные вычисления могут быть произведены во время компиляции. Для условной компиляции есть как константый if, так и специализированные конструкции.
Вот только сам D в этом форуме — фотоп.
А>Т.е. говоря о Сишном массиве, снова "Есть аналоги."
То есть, говоря человеческим языком — фунциональность перекрывается в полной мере и качество реализации несравнимо выше.
VD>>Но мысль ясна. Не все языки можно разложить в некую линию где один однозначно лучше, а другой однозначно хуже.
А>эк тебя... "лучше"... А>Да просто больше-меньше (вложенность, в терминах множеств) уже почти никогда не случится.
Терминалогические споры вообще лучше осуществлять на www.gramota.ru.
А>Вернемся к твоим словам "язык A может все что B плюс неких z". А>Если речь о принципиальных возможностях — то для всех Тьюринг-полных языков.... А>Если речь идет о конкретных возможностях синтаксиса/семантики, то почти нигде не будет полного повтора, а будет сплошное "Есть аналоги."
Если мерить на уровне операторов — насомненно. Если смотреть по существу, то ты заллуждаешся.
А>И поэтому формально сравнивать нельзя.
Все зависит исключительно от того, что ты в кладываешь в термин "формально". Я считаю, что сранвивать можно и нужно.
А>Точнее для того чтобы строгонаучноформальнообъективно сравнить, надо сначала иррационально неформально договориться, что мы считаем аналогами, а что нет. И все сравнение сведется к этому необъективному "тут похоже. а тут не похоже"
Тут не очем дововариваться. Сравниваются не операторы, а возможности. Скажем вычисления времи компиляции. По этому критерию без проблем можно формально разложить языки где в самом хвосте будут Delphi, VB, C# и т.п. В середине C++. Чуть ближе к голове D. А у самой головы будут Lisp, Nemerle, многие скриптовые языки и несколько экзотических языков или расширений. Все будет однозначно и четко.
Точно так же можно расположить языки по любому другому выбранному критерию.
Проблема начитаетс только тогда, когда мы пытаемся разложить по одной оси языки сразу по нескольким ктиретиям. Тут начинают играть роль приоритеты.
Забавно, что приоритеты могут влиять и не на языковом уровне. Например, тот же Немерле моногие не приемлят не из-за проблем исходящих из самого языка, а из-за его рантайма — .NET.
VD>>Скажем так. Любой язык программирования — это дизайнерское решение. Всегда нужно идти на компромисы выбирая между решениями.
А>Тем самым делая невозможным сравнение "есть все до одного те же элементы + что то еще"
Отнюдь. Сравнения более чем возможны. Вот только выбор может оказаться не одназначным, так как у разных людей разные приоритеты, привычки, фобии.
А>А дальше всй скипнуто, дальше тебя куда-то не в ту степь понесло.
Или ты не понял.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
g> С++ я не пробовал. Я на нем писал с момента его появления до 2003 года, да и сейчас пописываю небольшие кусочки. Пробовал я как раз всякие более другие статические языки. Некоторые мне просто не нравятся, как например Хаскель ( по причине какой-то его потусторонности ). Некоторые я считаю попросту малоэффективными — например, Жабу. Ада — люди будут упираться. Окамл — все же сложноват для большинства наших кадров.И т.д.
Ну тады Вам просто необходимо попробовать Оберон/Компонентный Паскаль. Достаточно эффективен, прост, привычен, статически типизирован, и т.д.
Оберонщики Вам кучу дифирамбов напоют при случае...
(Правда, у Влада-Д2 аллергия на эту группу языков, что тоже может служить показателем его (Оберона) хорошести...) :о))
Здравствуйте, geniepro, Вы писали:
G>Ну тады Вам просто необходимо попробовать Оберон/Компонентный Паскаль. Достаточно эффективен, прост, привычен, статически типизирован, и т.д. G>Оберонщики Вам кучу дифирамбов напоют при случае...
А разве Оберон не помре ? Да и какой выигрыш он мне даст по сравнению с упряжкой-тройкой Ерланг, Тикль и С++/D для замазывания системных щелей ?
G>(Правда, у Влада-Д2 аллергия на эту группу языков, что тоже может служить показателем его (Оберона) хорошести...) :о))
Какой-то сомнительный аргумент...А ежели он завтра скажет, что все языки суть помет, окромя Лиспа ? Как тогда быть, куда бежать ? 8)))
Здравствуйте, Аноним, Вы писали:
А>китайцы считают, что есть можно всё. если вы что-то не способны съесть — значит просто не умеете это готовить
Все, что бегает, плавает и летает — сьедобно ?
А>так же надо глядеть и на хаскел. у нас есть операции обмена с внешним миром. это скелет программы. все манипуляции, превразающие данные полученные программой в данные, которые будут отправлены наружу или управлять порядком выполнения — это просто формулы, аналогичные экселовским. и эти сложные вычисления гораздо проще проводить на FP языке. обо всё, что проихсодит помимо вызовов OS API, нужно думать не в терминах действий, а в терминах мат. зависимостей — и тогда, боюсь, сокрее императивные языки покажутся чем-то потусторонним
Не в этом дело. У меня некая нелюбовь именно к Хаскелю, хотя Clean, сильно на него похожий, не вызывает у меня отрицательных эмоций. А Окамл так и вовсе ничего ( ежели не считать, что он чем-то напоминает кучу мусора )
Re[25]: Бизнес-логика на Erlangе
От:
Аноним
Дата:
29.05.07 06:12
Оценка:
G>Не в этом дело. У меня некая нелюбовь именно к Хаскелю, хотя Clean, сильно на него похожий, не вызывает у меня отрицательных эмоций. А Окамл так и вовсе ничего ( ежели не считать, что он чем-то напоминает кучу мусора )
ну это уже чисто эмоциональное. clean отличается большей эффективностью, меньшим числом наворотов в типах данных, IDE и GUI библиотеками. приницпиальная основа та же
Здравствуйте, Аноним, Вы писали:
G>> Не в этом дело. У меня некая нелюбовь именно к Хаскелю, хотя Clean, сильно на него похожий, не вызывает у меня отрицательных эмоций. А Окамл так и вовсе ничего ( ежели не считать, что он чем-то напоминает кучу мусора )
А> ну это уже чисто эмоциональное. clean отличается большей эффективностью, меньшим числом наворотов в типах данных, IDE и GUI библиотеками. приницпиальная основа та же
А меня в Clean обескураживает куча вариантов списков.
То ли дело в Хаскелле — всего один. Правда, в Data Parallel Haskell тоже появились ещё и параллельные списки [: :] — зачем все эти сложности — непонятно...
Библиотека Prelude (или что там в Clean'e) после Хаскелла в Clean'е — неудобная какая-то, хотя вот ObjectIO из Clean потихоньку перебирается в Хаскелл...
Да, вообще, эмоции — штука сомнительная... Как может Clean нравиться, а Хаскелл при этом вызывать отторжение?
Здравствуйте, geniepro, Вы писали:
G>Да, вообще, эмоции — штука сомнительная... Как может Clean нравиться, а Хаскелл при этом вызывать отторжение?
Да вот как-то так...Я потому и привел это сравнение, что логически обьяснить сложно. "Нутром чую !" (с)
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
А>>ну это уже чисто эмоциональное. clean отличается большей эффективностью, меньшим числом наворотов в типах данных, IDE и GUI библиотеками. приницпиальная основа та же G>Именно что так ! Хотя насчет наворотов в типах данных я не уверен — у Клина есть свои сугубые фичи G>Тем не менее — Клин для меня вполне язык, а Хаскель ну никак не идет. Жалко, что Клин такое глюкало...
Какие однако у Эрлангистов одинаковые предпочтения . У меня на 100% то же самое . Включая мнение по ОКамлу — классный, тока помойка
Здравствуйте, Gaperton, Вы писали:
G>Какие однако у Эрлангистов одинаковые предпочтения . У меня на 100% то же самое . Включая мнение по ОКамлу — классный, тока помойка
Интересно, что было вначале — Ерланг, а уже потом языковые предпочтения, или же сначала предпочтения, а потом усвоение Ерланга ?
Это могло бы многое прояснить, мне кажется...
Возможно, и с другими языками похожая ситуация
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>Какие однако у Эрлангистов одинаковые предпочтения . У меня на 100% то же самое . Включая мнение по ОКамлу — классный, тока помойка G>Интересно, что было вначале — Ерланг, а уже потом языковые предпочтения, или же сначала предпочтения, а потом усвоение Ерланга ? G>Это могло бы многое прояснить, мне кажется... G>Возможно, и с другими языками похожая ситуация
Если говорить об обсуждаемых языках
Erlang -> Haskell -> OCaml -> Clean -> Языковые предпочтения.
Здравствуйте, aka50, Вы писали:
G>>Вот такой рефакторинг — головная боль и источник ошибок. А эти средсва ускорения работы машинисток, гордо называемые "рефакторинг" — детские игрушки. Смешно это в качестве плюса-минуса языка и платформы рассматривать. A>Но все таки при статической типизации такая операция проходит более безболезненно чем при динамике.
На этот счет есть и прямо противоположное мнение. В динамическом языке любая функция — это generic-функция, она полиморфна. Что уменьшает связность системы и количество усилий по рефакторингу. Система типов Хиндли-Милнера обладает тем же свойством, впрочем, если не выписывать сигнатуры и полагаться на выведение типов.
A>(правда есть минус: скорее всего код очень долго нельзя будет даже скомпилировать не говоря уже о тестировании ).
Ну, это не минус
A>Часть тестов в статичской типизации не нужна.
Не понимаю, с чего это прогрессивной общественности взбрела в голову такая мысль. Откуда дровишки-то? Любой тест приводит к выполнению кода, и убирание этого теста уменьшает тестовое покрытие — у вас какой-то код становится тестими не покрыт. Адекватное же тестовое покрытие найдет 99,999% ошибок типизации — не нужны никакие специальные тестовые сценарии для их ловли, достаточно близкого к 100% покрытия по строкам кода . Т.е. тестовое покрытие потребуется одинаковое.
Кстати, пока никто не привел примера того теста, который ловит только ошибку типизации, но не ловит функциональных ошибок — т.е. теста, который можно выкинуть. Это мифические, неуловимые тесты, которых никто в глаза не видел, но все уверены, что их можно выкинуть.
A>И более того, статически типизированный язык позволяет реализовать фишки (типа изменений интерфейсов, изменений сигнатур методов, extract/convert операции для классов/интерфейсов) которые автоматизируют (типобезопасно) часть операций при таком глубоком изменении кода.
Сомнительно. Взять хотя бы изменение сигнатур методов. В каждом месте, где происходит вызов, придется ручками править и глазками проверять работу с новым или изменившимся аргументом. У вас правильный код для оформления измененного вызова по мановению волшебной палочки не появится. А раз так — лучше мне перед глазами этот список иметь, и делать правки руками вызывающего кода целиком, глядя, что получается, чем полагаться на слепую автозамену хрен знает где во всем коде, чтобы потом концов не собрать (если она будет "с элементами исскуственного интеллекта" — это еще хуже. Как это не парадоксально — излишне умные штуки становятся источником ошибок, когда люди начинают на этот "интеллект" полагаться).
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, aka50, Вы писали:
G>>>Вот такой рефакторинг — головная боль и источник ошибок. А эти средсва ускорения работы машинисток, гордо называемые "рефакторинг" — детские игрушки. Смешно это в качестве плюса-минуса языка и платформы рассматривать. A>>Но все таки при статической типизации такая операция проходит более безболезненно чем при динамике.
G>На этот счет есть и прямо противоположное мнение. В динамическом языке любая функция — это generic-функция, она полиморфна. Что уменьшает связность системы и количество усилий по рефакторингу.
A>>Часть тестов в статичской типизации не нужна. G>Не понимаю, с чего это прогрессивной общественности взбрела в голову такая мысль. Откуда дровишки-то? Любой тест приводит к выполнению кода, и убирание этого теста уменьшает тестовое покрытие — у вас какой-то код становится тестими не покрыт. Адекватное же тестовое покрытие найдет 99,999% ошибок типизации — не нужны никакие специальные тестовые сценарии для их ловли, достаточно близкого к 100% покрытия по строкам кода . Т.е. тестовое покрытие потребуется одинаковое.
G>Кстати, пока никто не привел примера того теста, который ловит только ошибку типизации, но не ловит функциональных ошибок — т.е. теста, который можно выкинуть. Это мифические, неуловимые тесты, которых никто в глаза не видел, но все уверены, что их можно выкинуть.
def f1(o)
o.init
end
def f2(o)
o.init
end
class C
def init
...
end
end
class D
def init
...
end
end
В приведенном выше коде я хочу переименовать метод C.init в C.init2. Что будет? В статике я это отловлю на уровне интерфейсов (или трейтов если это допустим scala), как я отловлю проблемы тут? Далее, как я обнаружу проблему, что класс D тоже имеет метод init и вообще-то должен быть переименован? Или не должен? (возможно есть другие функции f3 f4 но туда С не передается никогда, а D передается... и даже возможно он может передаваться и в f1 и в f2, но IDE этого знать не сможет, ибо это даже разработчик сходу может не знать )
В статически типизированном языке не нужно проверять все комбинации вызовов функций f1 и f2 со всеми возможными классами C и D ... В динамике нужно. (допустим C и D это "стратегии", которые проверяются отдельно и потом могут комбинироваться в рантайме).
A>>И более того, статически типизированный язык позволяет реализовать фишки (типа изменений интерфейсов, изменений сигнатур методов, extract/convert операции для классов/интерфейсов) которые автоматизируют (типобезопасно) часть операций при таком глубоком изменении кода. G>Сомнительно. Взять хотя бы изменение сигнатур методов. В каждом месте, где происходит вызов, придется ручками править и глазками проверять работу с новым или изменившимся аргументом. У вас правильный код для оформления измененного вызова по мановению волшебной палочки не появится. А раз так — лучше мне перед глазами этот список иметь, и делать правки руками вызывающего кода целиком, глядя, что получается, чем полагаться на слепую автозамену хрен знает где во всем коде, чтобы потом концов не собрать (если она будет "с элементами исскуственного интеллекта" — это еще хуже. Как это не парадоксально — излишне умные штуки становятся источником ошибок, когда люди начинают на этот "интеллект" полагаться).
Ничего тут волшебного нет, в той же IDEA она требует дать еще и параметр по умолчанию и я могу указать какой-то несуществующий и получить некомпилируемый код во всех случаях где я не указал правильное входное значение. Дальше, обычно системы рефакторинга дают возможность просматривать ожидаемые изменения и править по месту (в той же IDEA). Т.е. тут все не так плохо... а вот в динамике отловить изменившийся метод уже гораздо сложнее...
Здравствуйте, Klapaucius, Вы писали:
K>Получилась РН, не имеющая, пока что, аналогов в мире по своим характеристикам и возможностям. Да, разрабатывались конфигурации РН "Энергия" аналогичные и превосходящие, но они не испытывались и не эксплуатировались.
Это Н-1 не испытывалась, так как не была построена. А Энергия последних модификаций совсем немного уступает Сатурну-5 по массе выводимого груза, насколько я помню. ( Могу и ошибаться — куча источников и все врут по-своему )
K>А какие еще претензии к Saturn V кроме большой стоимости запуска? Есть еще какие-то недостатки?
Первые Сатурны не отличались высокой надежностью, как известно. Это только у Сатурна-5 все рабочие запуски прошли успешно.
K>В любом случае, ракет с аналогичной грузоподъемностью, но с меньшей стоимостью запуска как не было тогда, так и сейчас нет, так что о чем весь этот разговор?
В смысле, с меньшей стоимостью ? Он ТОГДА стоил около полумиллиарда баксов, а ежели привести к нынешнему курсу, то сколько это будет ? От 1.5 до 5 гигабаксов за каждый запуск ! Не слишком ли жЫрно даже для большого выводимого груза ?
K>Да неужели? Какие там, в США новые средне-тяжелые ракеты? Atlas V и Delta IV. Да, в первой ступени и бустерах тяжелой конфигурации Atlas V установлен РД-180, но у Delta IV — RS-68 — не русский, а очень даже Rocketdyne. Эти же двигатели (RS-68) предполагается устанавливать и на Ares V. Что характерно, утверждение о низкой надежности (да еще и проистекающей из завышенной сложности) американских двигателей также высосано из пальца.
Имеется в виду так называемая Тяжелая Дельта-4 с водородным двигателем, как я понимаю ? Там да, Боинговские двигатели стоят K>Зачем же обманывать читателей? Ай-ай-ай, нехорошо!
Ну что уж сразу обманывать ? Про тяжелую дельту просто не вспомнил. А на других дельтах стоят другие двигатели. Вот на Аресе будут сразу RS68 стоять
K>По теме спора: да, при решении определенного круга задач простое решение может превосходить сложное, но ведь очевидно, что огромное количество задач простыми средствами вообще не решаются. Именно поэтому и нужно делать просто, как только возможно, но не ПРОЩЕ.
БОЛЬШИНСТВО задач как раз решаются простыми, и даже очень простыми двигателями
K>Кроме того, на самом деле нет никакой простой зависимости сложность-надежность. С ростом сложности надежность может и уменьшаться и возрастать. Например, можно строить сложные системы из простых элементов так, что надежность всей системы будет превосходить надежность элемента, при том, что, разумеется, naive реализация системы, для которой вероятность работы без сбоя будет произведением таких вероятностей для элементов — со всеми вытекающими — является как раз самой простой.
Оно, конечно, так — но опять-таки соотношение стоимости разработки и надежности получится не самым лучшим.
G>>Какие однако у Эрлангистов одинаковые предпочтения . У меня на 100% то же самое . Включая мнение по ОКамлу — классный, тока помойка G>Интересно, что было вначале — Ерланг, а уже потом языковые предпочтения, или же сначала предпочтения, а потом усвоение Ерланга ? G>Это могло бы многое прояснить, мне кажется... G>Возможно, и с другими языками похожая ситуация
Благодаря "Декларативному программированию" я в поисках прошел
Lisp -> Haskell -> OCaml -> Erlang
Дважды пытался возвращаться к Хаскелю, но не смог Довольствуюсь тем, что простенькие программы могу читать "с листа"
А>>ну это уже чисто эмоциональное. clean отличается большей эффективностью, меньшим числом наворотов в типах данных, IDE и GUI библиотеками. приницпиальная основа та же G>Именно что так ! Хотя насчет наворотов в типах данных я не уверен — у Клина есть свои сугубые фичи
ну у clean их вроде всего две — strict и unique types. а хаскеловцы такие затейники, каждый год какую-нибудь гадость притащат. ты просто наверно не читал 7-ю главу доки по ghc
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, aka50, Вы писали:
A>>В статически типизированном языке не нужно проверять все комбинации вызовов функций f1 и f2 со всеми возможными классами C и D ... В динамике нужно. (допустим C и D это "стратегии", которые проверяются отдельно и потом могут комбинироваться в рантайме).
G>Плюсовик завел бы шаблонну функцию и гордо заявил, что занимается generic programming, как завещал сам Степанов. В С++ компилятор поймет, что реализации init у аргумента нет, и даст по рукам.
Заметь, в компайл тайм и без необходимости писать какие-то тесты...
G>Все, что надо сделать нам — это написать тест, вызывающий каждую строчку, где стоит вызов функций f1 и f2..
Нифига себе , а если это происходит в динамике. Каким образом будем проверять aCundDundExtensionsList.each {|i| f1(i)}? Да и получается что таки тест нужен... в С++ (и других статик языках) это будет проверено компилятором. А проблемы я могу себе создать и в Java например вызывая метод init через рефлекшн. Но я не буду "стрелять себе в ногу" а просто заведу интерфейс IFunInitAllowed и привет (в scala можно в принципе даже тип функции завести). Когда надо будет переименовать (или еще как порефакторить) — просто переименую руками и получу class should implement bla bla... в компайл тайм.
G>И все. Меньшее покрытие, кстати, все равно в статике делать нельзя — у тебя нетестированный код попадет в релиз.
Каким образом я могу оттестировать покрытие кода если используется допустим цикл с разнородными объектами? В статике я протестирую все отдельно (functionalCTest, functionalDTest возможно с использованием mock) и т.к. я статически определелил контракт — код автоматически верен. (конечно интерфейсы тут не всегда помогют, т.к. не содержат кода, а мультинаследование в java не поддерживается, но допустим если взять scala с трейтами — то можно тестировать трейты отдельно). И подсутунуть объект допустим в тот же список таких объектов требующих IFunInitAllowed будет нельзя (ну если конечно не захотеть этого специально путем насильного приведения типов)
G>тестирвать с хорошим покрытием надо неполиморфный вызывающий код
Код не всегда статичен. Часто в компонентных приложениях компоненты разрабатываются независимо, т.е. разработчик библиотеки не может знать, что метод init теперь init2, а следовательно его расширение к твоему софту упадет в рантайме.
G> не так как в статике, структурировать код — его можно сделать менее связным и более обобщенным, не свернув при том себе шею.
Проблема возникает в другом — в связанности кода на уровне документации к исходникам (типа, не забываем, что у классов передаваемых в f1 должен быть метод init), против связанности на бинарном уровне в статик языках java или C# (правда С++ выпадает из этого списка ибо обладает связанностью на уровне исходников, точнее их части .h файлов)
G>Насчет изменения методов — описанная вами проблема замечательно решается конекстным поиском. А ошибки, которые не нашел компилятор, вылавливается потом простейшими regression-тестами.
Ну собственно к чему и пришли: в динамике тесты вырастают на ровном месте, там где в статике это может проверять компилятор:
1. Статик язык позволяет производить рефакторинг с гарантированным результатом (проверка на выполнение контракта будет в момент компиляции)
2. Поиск и замена — зло. Ибо можно поменять не то. Например у меня методы init могут встречаться налево и направо, но только 2! класса могут быть переданы в f1 и f2.
3. Рефакторинг динамического кода приводит не только к необходимости дополнительно тестировать сам код, но так же предоставлять некий фреймворк для тестирования расширений, что в общем случае совсем не тривиально
Здравствуйте, gandalfgrey, Вы писали:
K>>Получилась РН, не имеющая, пока что, аналогов в мире по своим характеристикам и возможностям. Да, разрабатывались конфигурации РН "Энергия" аналогичные и превосходящие, но они не испытывались и не эксплуатировались. G>Это Н-1 не испытывалась, так как не была построена.
Похоже жизнь Вас ничему не учит. Вы снова вводите читателей в заблуждение. Н-1 была построена и испытывалась 4 раза, в два раза больше чем "Энергия". Просто все 4 испытания провалились.
G>А Энергия последних модификаций совсем немного уступает Сатурну-5 по массе выводимого груза, насколько я помню.
У "Энергии" дважды испытывалась первая модификация, она же и последняя. Да, уступает, действительно — немного. Но:
1) Все-таки уступает.
2) "Энергия" не эксплуатировалась — только испытывалась.
3) "Энергия" разработана и построена существенно позже.
Более тяжелые конфигурации "Энергии" аналогичные и превосходящие Saturn V, как я уже говорил, разрабатывались, но не испытывались.
K>>А какие еще претензии к Saturn V кроме большой стоимости запуска? Есть еще какие-то недостатки? G>Первые Сатурны не отличались высокой надежностью, как известно.
Правда чтоли? А какие запуски Saturn IB закончились неудачей? Расскажите, это очень интересно. А у Saturn I вообще "рабочих" запусков небыло.
G>Это только у Сатурна-5 все рабочие запуски прошли успешно.
Вообще-то считается, что SA-508 — не полностью выполненная миссия, хотя да, Saturn V тут не при чем, проблемы были с Apollo 13.
K>>В любом случае, ракет с аналогичной грузоподъемностью, но с меньшей стоимостью запуска как не было тогда, так и сейчас нет, так что о чем весь этот разговор? G>В смысле, с меньшей стоимостью ? Он ТОГДА стоил около полумиллиарда баксов,
Не совсем так. Saturn V обошелся в 6,5 ярдов, понятно, с учетом R&D и постройкой 15 ракет. Две просто не запускали.
G>Не слишком ли жЫрно даже для большого выводимого груза ?
Это спекулятивное рассуждение. Такой груз никакая другая ракета не выводила, так что жирно относительно чего — совершенно непонятно. А так да, ничего не запускать конечно дешевле, чем что-то запускать.
K>>Да неужели? Какие там, в США новые средне-тяжелые ракеты? Atlas V и Delta IV. Да, в первой ступени и бустерах тяжелой конфигурации Atlas V установлен РД-180, но у Delta IV — RS-68 — не русский, а очень даже Rocketdyne. Эти же двигатели (RS-68) предполагается устанавливать и на Ares V. G>Имеется в виду так называемая Тяжелая Дельта-4 с водородным двигателем, как я понимаю ?
RS-68 — это двигатель первой ступени. Т.е. он во всех конфигурациях Delta IV есть. Просто у Medium/Medium+ он один, а у Heavy — их три (+2 в бустерах).
G> Там да, Боинговские двигатели стоят
Кстати, теперь Rocketdyne уже не Boeing/Rockwell, а подразделение Pratt & Whitney, кажется.
K>>Зачем же обманывать читателей? Ай-ай-ай, нехорошо! G>Ну что уж сразу обманывать ?
НЕ кажется Вам, что между фактическим положением вещей "На Atlas V в первой ступени и бустерах используются российские двигатели" и Вашими словами "на всех тяжелых американских носителях стоят российские двигательные системы" есть существенная разница?
А после этого Вы делаете какие-то непонятные умозаключения об избыточной сложности американских двигателей (с чего вы вообще взяли что RS-68 сложнее РД-180? только потому что первый водородный, а второй керосиновый? где можно об этом почитать?) и все это чтобы доказать недоказуемое утверждение о том, что "чем проще — тем надежнее".
G>Про тяжелую дельту просто не вспомнил. А на других дельтах стоят другие двигатели.
На всех D4 — RS-68.
K>>По теме спора: да, при решении определенного круга задач простое решение может превосходить сложное, но ведь очевидно, что огромное количество задач простыми средствами вообще не решаются. Именно поэтому и нужно делать просто, как только возможно, но не ПРОЩЕ. G>БОЛЬШИНСТВО задач как раз решаются простыми, и даже очень простыми двигателями
Ну ну.
K>>Кроме того, на самом деле нет никакой простой зависимости сложность-надежность. С ростом сложности надежность может и уменьшаться и возрастать. Например, можно строить сложные системы из простых элементов так, что надежность всей системы будет превосходить надежность элемента, при том, что, разумеется, naive реализация системы, для которой вероятность работы без сбоя будет произведением таких вероятностей для элементов — со всеми вытекающими — является как раз самой простой. G>Оно, конечно, так — но опять-таки соотношение стоимости разработки и надежности получится не самым лучшим.
Это уже совсем другой вопрос. А космонавтика, мягко говоря, неподходящая область для выбора примеров дешевой разработки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
G>>Он непортабельный. <...> G>>Только не говорите мне про Mono !
K>Президентов США никогда не убивали. K>Только не говорите мне про Линкольна и JFK!
Вот gandalfgrey говорит, что с 1994 по 2002 он принимал участие в разработке серьезной системы для предприятия по переработке урана. На C++. А вы бы решились сейчас вести такую разработку на Mono? Ну т.е. прямо сейчас, даже с учетом того, что первый год-полтора будет полностью посвящен проектированию, моделированию и прототипированию.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, aka50, Вы писали:
E><...прочитано и поскипано...>
A>>В приведенном выше коде я хочу переименовать метод C.init в C.init2. Что будет? В статике я это отловлю на уровне интерфейсов (или трейтов если это допустим scala), как я отловлю проблемы тут? Далее, как я обнаружу проблему, что класс D тоже имеет метод init и вообще-то должен быть переименован? Или не должен? (возможно есть другие функции f3 f4 но туда С не передается никогда, а D передается... и даже возможно он может передаваться и в f1 и в f2, но IDE этого знать не сможет, ибо это даже разработчик сходу может не знать )
A>>В статически типизированном языке не нужно проверять все комбинации вызовов функций f1 и f2 со всеми возможными классами C и D ... В динамике нужно. (допустим C и D это "стратегии", которые проверяются отдельно и потом могут комбинироваться в рантайме).
E>Андрей, по-моему опыту, рефакторинги типа переименования класса/метода/атрибута в динамике (в Ruby, в частности) выполняются без проблем. Может это и занимает чуть больше времени, чем в Java+IDEA, но вовсе не так долго как может казаться. Так что Gaperton тебе правильно все говорит.
Вот представь, что у тебя есть интерфейс типа Runnable и Callable который используется в 1000 и 1 месте и тебе _всего лишь_ надо переименовать run в runMe только в Runnable. Т.е. семантика вызова не меняется... Я потрачу на это 3 минуты + время на подумать IDE для проекта любого размера, а в динамике я просто плюну на это дело...
E>Так же Gaperton правильно говорит, что в динамике специальные тесты на проверку соответствия типов не пишутся. Пишутся нормальные функциональные тесты, в них все изрядная доля ошибок как типизации, так и очепяток в именах методов/атрибутов/переменных вылетает на ура. Так что общее время отладки что на динамике, что на статике, не сильно различается.
Для отлова проблемы вызова метода init одного компонента из другого потребуется integration тест. функциональный тут не поможет (в тесте будет продолжать вызваться метод init и все хорошо, но когда мы попытаемся подсунуть это в некую компонентную систему — все обвалится, при чем в самый неподходящий момент, например этот объект должен послать нам сообщение об ошибки, но вместо сообщения получим здоровенный такой ексепшн)
E>Вообще, по моему опыту, уверенность в том, что программа работает правильно в случае статики складывается из двух составляющих -- все скомпилировалось без ошибок и пройдены основные тесты.
Я никогда не отрицал тестов. Но основной поинт — есть понятие "контракт" которое в случае с динамикой предлагается указывать в "спецификации", а в статическом языке типы и есть встроенная в язык спецификация. Если еще типы обвесить http://en.wikipedia.org/wiki/Design_by_contract то будет вообще красота... Помимо тестов еще и рантайм проверка...
E>Вот какой рефакторинг действительно вызывает сложности, так это изменение структур данных. Например, где-нибудь раньше использовался объект какого-нибудь типа Description, а затем пришлось заменить его на MetaDescription, в котором Description является всего-лишь атрибутом. Вот тогда приходится полазить по исходникам с тем, чтобы определить, где и чего используется -- анотаций-то типов нет.
Мое мнение, что разницы между структурами и интерфейсами (читай контрактами) по сути нет. Интерфейсы легче протестировать, но сути это не меняет: в динамике гораздо сложнее соблюдать спецификацию.
E>Но при проведении такого рефакторинга в статике все равно нужно иметь достаточное тестовое покрытие, чтобы понять, что мы ничего не запортили.
Функциональное должно быть 100%! Integration тестирование в статике требует меньше усилий и меньшее кол-во покрытия by design
Здравствуйте, Klapaucius, Вы писали:
K>Президентов США никогда не убивали. K>Только не говорите мне про Линкольна и JFK!
Гарфилд, Мак-Кинли, Гардинг ( ежели верить, что его потравили )...Это уже несколько другая статистика, верно ?
А что, Моно уже НОРМАЛЬНО и ПОЛНОЦЕННО работает хотя бы на десятке платформ ?
E>>Вообще, по моему опыту, уверенность в том, что программа работает правильно в случае статики складывается из двух составляющих -- все скомпилировалось без ошибок и пройдены основные тесты. A>Я никогда не отрицал тестов. Но основной поинт — есть понятие "контракт" которое в случае с динамикой предлагается указывать в "спецификации", а в статическом языке типы и есть встроенная в язык спецификация. Если еще типы обвесить http://en.wikipedia.org/wiki/Design_by_contract то будет вообще красота... Помимо тестов еще и рантайм проверка...
В динамике также есть понятие контракт, в том же питоне есть несколько библиотек реализующих Design_by_contract там же с помощью метаклассов можно делать и интерфейсы и валидацию при инициации класса (практически аналог compile time). Так что эти вещи применимы как в статике так и в динамике.
Здравствуйте, Klapaucius, Вы писали:
K>Похоже жизнь Вас ничему не учит. Вы снова вводите читателей в заблуждение. Н-1 была построена и испытывалась 4 раза, в два раза больше чем "Энергия". Просто все 4 испытания провалились.
Разве не прототип Н-1 проходил испытания ?
K>Более тяжелые конфигурации "Энергии" аналогичные и превосходящие Saturn V, как я уже говорил, разрабатывались, но не испытывались.
Тут я согласен
K>Не совсем так. Saturn V обошелся в 6,5 ярдов, понятно, с учетом R&D и постройкой 15 ракет. Две просто не запускали.
Я имею в виду стоимость ОДНОГО запуска. Сейчас пошарил и нашел более точную сумму 430 мегабаксов.
K>Кстати, теперь Rocketdyne уже не Boeing/Rockwell, а подразделение Pratt & Whitney, кажется.
Гм. Они купили лицензию на производство РД-180 и будут его делать сами
K>А после этого Вы делаете какие-то непонятные умозаключения об избыточной сложности американских двигателей (с чего вы вообще взяли что RS-68 сложнее РД-180? только потому что первый водородный, а второй керосиновый? где можно об этом почитать?) и все это чтобы доказать недоказуемое утверждение о том, что "чем проще — тем надежнее".
Опять гм. Это утверждает куча всяческих экспертов — что керосиновые двигатели по природе своей проще водородных.
Пошарил в сетях и вижу, что мои утверждения в предыдущих письмах ( взятые из печатных материалов ), не совсем соответствуют истине. Как ни печально это признавать, но тут я здорово заблуждался...
K>Это уже совсем другой вопрос. А космонавтика, мягко говоря, неподходящая область для выбора примеров дешевой разработки.
Здравствуйте, FR, Вы писали:
FR>В динамике также есть понятие контракт, в том же питоне есть несколько библиотек реализующих Design_by_contract там же с помощью метаклассов можно делать и интерфейсы и валидацию при инициации класса (практически аналог compile time). Так что эти вещи применимы как в статике так и в динамике.
Эмуляция статики... аналогично можно эмулировать динамику на статически типизированной платформе (groovy, jython, jruby).
Здравствуйте, FR, Вы писали:
A>>Я никогда не отрицал тестов. Но основной поинт — есть понятие "контракт" которое в случае с динамикой предлагается указывать в "спецификации", а в статическом языке типы и есть встроенная в язык спецификация.
FR>Которая покрывает слишком мало и только слишком тривиальные случаи.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>В динамике также есть понятие контракт, в том же питоне есть несколько библиотек реализующих Design_by_contract там же с помощью метаклассов можно делать и интерфейсы и валидацию при инициации класса (практически аналог compile time). Так что эти вещи применимы как в статике так и в динамике.
A>Эмуляция статики... аналогично можно эмулировать динамику на статически типизированной платформе (groovy, jython, jruby).
Ничего подобного контрактное программирование вообще ортогонально типизации.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
G> И более того. Рассуждать о теоретической ненадежности динамики можно сколько угодно — только это несколько глуповато, учитывая, что практически работающий софт на динамическом Эрланге превосходит по надежности аналогичный софт писанный на статических языках и обходится в разработке дешевле. Я говорю о применениях в телекоме.
А ничего что он функциональный? Или это так, сбоку: главное динамика?
G>Произошло это благодаря или вопреки динамике — неважно, важно что динамика надежности не мешает, что доказано индустриальными применениями. И это объективный факт. Происходит это вопреки представлениям некоторых участников форума или нет — мне не очень интересно. Для меня убедительнее работающая железка с миллионом строк на динамике и процентом отказав в 9 девяток, чем смутные страхи и опасения уважаемых участников форума.
А можно поглядеть на индустриальные решения 24x7 на нефункциональном динамическом языке? А то все всякие С/C++ да жавы в голову лезут
А случай erlang-а — это отдельная тема. Ералнг рулит за счет отсутствия состояния и удачной системы процессов (актеры). Абсолютно не факт, что будучи у ералнга статическая типизация он не был бы еще надежнее... Но опять же: 100% тестирования в функциональном языке и 100% покрытия в императивном — это две большие разницы.
Здравствуйте, FR, Вы писали:
FR>>>В динамике также есть понятие контракт, в том же питоне есть несколько библиотек реализующих Design_by_contract там же с помощью метаклассов можно делать и интерфейсы и валидацию при инициации класса (практически аналог compile time). Так что эти вещи применимы как в статике так и в динамике.
A>>Эмуляция статики... аналогично можно эмулировать динамику на статически типизированной платформе (groovy, jython, jruby).
FR>Ничего подобного контрактное программирование вообще ортогонально типизации.
Неудачно сформулировал мысль Я не про контрактное, я про выделенное...
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, FR, Вы писали:
FR>>>>В динамике также есть понятие контракт, в том же питоне есть несколько библиотек реализующих Design_by_contract там же с помощью метаклассов можно делать и интерфейсы и валидацию при инициации класса (практически аналог compile time). Так что эти вещи применимы как в статике так и в динамике.
A>>>Эмуляция статики... аналогично можно эмулировать динамику на статически типизированной платформе (groovy, jython, jruby).
FR>>Ничего подобного контрактное программирование вообще ортогонально типизации. A>Неудачно сформулировал мысль Я не про контрактное, я про выделенное...
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, aka50, Вы писали:
A>>Здравствуйте, FR, Вы писали:
FR>>>>>В динамике также есть понятие контракт, в том же питоне есть несколько библиотек реализующих Design_by_contract там же с помощью метаклассов можно делать и интерфейсы и валидацию при инициации класса (практически аналог compile time). Так что эти вещи применимы как в статике так и в динамике.
FR>Выделенное тоже не равнозначно типизации
Не равнозначно, но является эмуляцией оной.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, eao197, Вы писали:
G>> И более того. Рассуждать о теоретической ненадежности динамики можно сколько угодно — только это несколько глуповато, учитывая, что практически работающий софт на динамическом Эрланге превосходит по надежности аналогичный софт писанный на статических языках и обходится в разработке дешевле. Я говорю о применениях в телекоме. A>А ничего что он функциональный? Или это так, сбоку: главное динамика?
Ни то, ни другое не главное (кстати, Эрланг не чисто функциональный язык, там много грязи, взять хотя бы процессы). Главное то, что сказано у меня в следующем предложении: G>>Произошло это благодаря или вопреки динамике — неважно, важно что динамика надежности не мешает, что доказано индустриальными применениями.
Вот это главное. И еще: метрики Эрикссона по реальным проектам показывают отсутствие зависимости плотностей ошибок и времени разработки от вида типизации. Единственно, с чем плотность ошибок дала корелляцию — строки кода. У Эрикссона очень большая база кода для снятия метрик, много разных языков и проектов.
G>>И это объективный факт. Происходит это вопреки представлениям некоторых участников форума или нет — мне не очень интересно. Для меня убедительнее работающая железка с миллионом строк на динамике и процентом отказав в 9 девяток, чем смутные страхи и опасения уважаемых участников форума. A>А можно поглядеть на индустриальные решения 24x7 на нефункциональном динамическом языке? А то все всякие С/C++ да жавы в голову лезут
Можно. Довольно много написано на Смоллтоке — динамичнее не бывает (Эрланг похож на Smalltalk 72, кстати, там весьма схожая декомпозиция систем получается). Конкретных примеров лучше спросить у смоллтокеров — я помню что они были по флеймам, и хорошие примеры, но не помню какие. Из того что я помню — Gemstone — пример смоллтоковской платформы для 24х7. Если поискать — можно примеров найти и на других языках, я думаю.
A>А случай erlang-а — это отдельная тема.
Мы в этой теме и находимся, кстати
A>Ералнг рулит за счет отсутствия состояния и удачной системы процессов (актеры).
Да лана. Это в Эрланге-то отсутствует состояние. Там процессы применяются в качестве объектов — декомпозиция у Эрланговских систем объектная, с явным состоянием. Плюс — сам язык грязный.
A>Абсолютно не факт, что будучи у ералнга статическая типизация он не был бы еще надежнее...
Если бы от статической тиизации в Эрланге было больше пользы, чем вреда и геморроя, ее бы туда давно добавили. Эрланг — инженерно-практический язык, это не платформа для научны исследований вроде Хаскеля. Эта тема регулярно поднимается в Эрланговском мэйллисте, и закрывается каждый раз с одинаковой резолюцией — нафиг. Ну то есть неплохо бы в принципе со статикой, но и без нее все достаточно хорошо.
A>Но опять же: 100% тестирования в функциональном языке и 100% покрытия в императивном — это две большие разницы.
Во-первых, если говорить о покрытии 100% по метрике строк кода — то разницы нет никакой. Ключевое выделено — важно в какой метрике ты меряешь покрытие. Это покрытие минимально необходимо, и оно ловит практически все ошибки типизации.
Во-вторых, для чисто функционального кода тесты писать да, проще: причина в отсутствии изменяемого состояния. Только к Эрлангу это слабо относится — система на Эрланге представляет собой огромное количество маленьких параллельных процессов с изменяемым состоянием. В случае Эрланга чистотой облегчено только unit-тестирование небольших модулей.
Здравствуйте, Gaperton, Вы писали:
G>Вот такой рефакторинг — головная боль и источник ошибок. А эти средсва ускорения работы машинисток, гордо называемые "рефакторинг" — детские игрушки. Смешно это в качестве плюса-минуса языка и платформы рассматривать.
Это ты сейчас как менеджер или как программист говоришь?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, aka50, Вы писали:
A>>А случай erlang-а — это отдельная тема. G>Мы в этой теме и находимся, кстати
Ок прелагаю остаться при своих мнениях ибо erlang мне нравиться так же как и scala... (динамику не люблю, но в эрланге она какая-то особая чтоли... )
A>>Ералнг рулит за счет отсутствия состояния и удачной системы процессов (актеры). G>Да лана. Это в Эрланге-то отсутствует состояние. Там процессы применяются в качестве объектов — декомпозиция у Эрланговских систем объектная, с явным состоянием. Плюс — сам язык грязный.
Чистота — она конечно залог здоровья, но митиски обычно очень красивые
Здравствуйте, IT, Вы писали:
G>>Вот такой рефакторинг — головная боль и источник ошибок. А эти средсва ускорения работы машинисток, гордо называемые "рефакторинг" — детские игрушки. Смешно это в качестве плюса-минуса языка и платформы рассматривать.
IT>Это ты сейчас как менеджер или как программист говоришь?
Как программист. На предыдущей работе я 6 лет занимался развитием большой легаси-системы на С++, на основании этого опыта и говорю.
Здравствуйте, Gaperton, Вы писали:
E>>Вот какой рефакторинг действительно вызывает сложности, так это изменение структур данных. Например, где-нибудь раньше использовался объект какого-нибудь типа Description, а затем пришлось заменить его на MetaDescription, в котором Description является всего-лишь атрибутом. Вот тогда приходится полазить по исходникам с тем, чтобы определить, где и чего используется -- анотаций-то типов нет.
G>Не во всех динамических языках так. В Эрланге, например (тема все-таки о нем), такой рефакторинг будет проще, так как там применяется следующий подход. G>1) Структуры данных, применяемые внутри модуля — делаются обычным образом, без объявлений. G>2) Разделяемые структуры данных, которые используются в нескольких модулях, принято объявлять в отдельных модулях с применением конструкции record. Который устроен таким образом, что несложно отследить все места применения рекорда определенного типа (тэга). Да, при этом record — динамический тип. Т.е. record — это тэгированный атомом набор именованных полей произвольных типов.
G>Касательно структур данных — проблема решена.
G>При этом, при отсутствии вызываемой функции в модуле (module:wrong_function) компилятор выдает ошибку. При раелизации коллбэк-интерфейса за отсутствие правильных коллбэков компилятор дает по рукам. Таким образом, ситуации, когда функции не совпадают на межмодульных интерфейсах, на которых был сделан акцент в критике, нас тоже не беспокоят.
Это здорово. Огромный плюс за это Erlang-у.
G>А вот все остальное — уже спокойно и неторопливо вылавливается функциональными тестами. А вообще — разговор это достаточно беспредметный. На динамических языках пишут сложные системы высокой надежности работающие в режиме 24х7. Никакого тотального ахтунга, которым тут пугают, не происходит. Точка.
G> И более того. Рассуждать о теоретической ненадежности динамики можно сколько угодно — только это несколько глуповато, учитывая, что практически работающий софт на динамическом Эрланге превосходит по надежности аналогичный софт писанный на статических языках и обходится в разработке дешевле. Я говорю о применениях в телекоме.
Ну, в природе можно найти множество доказавших свою надежность систем написанных на самых разных языках. Опыт Ericsson-а в телекоме, конечно, показателен. Но далеко не всем приходится заниматься телекомом. Поэтому и интересно понять, будет ли удешевление от использования Erlang-а в других условиях. И если будет, то за счет чего.
А то, что не статика и не динамика определяют надежность -- это факт
Люди по любому гораздо менее надежный фактор в этом деле.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>В результате G>1) В Эрланге отсутствуют конструкции и языковые средства имеющие слабопредсказуемое время выполнения. Так как телекомовские системы должны иметь хорошую реактивность — характеристика soft-realtime. Это свойство не повредит вообще любой интерактивной системе. К примеру, в Эрланге нет ленивых вычислений.
Не думаю, что это имеет отношение к динамике.
G>2) Цыклов в эрланге нет, так как рекурсия на списках более надежна, чем цыклы с индексами. Минус еще один класс ошибок.
Пусть будет так, нет опыта сравнения надежности циклов vs рекурсии.
G>3) Нет явного управления памятью — минус еще один класс ошибок.
Опять же, сборка мусора не является прерогативой динамики.
G>4) Простая и понятная модель параллелизма — телекомоские задачи содержает его много. А теперь, с переходом на многоядерные процессоры, речь идет далеко и не только о телекоме и серверах. Конструкция receive и mailbox-ы сообщений в том виде, в котором она есть в Эрланге (selective receive построенная на сопоставлении с образцом), сокращает код и делает его более понятным, так как не требуется описывать все варианты последовательностей, в которых приходят сообщения. Отсутствие разделяемых данных — устраняет класс ошибок. Легковесные процессы — устраняют архитектурные ошибки, позволяют проектировать параллельные сервисы прямолинейным образом.
Мне кажется, что здесь намешано много чего под один пункт. Что явно выделяется -- паттерн-матчинг для выборки сообщений, но и он не является прерогативой динамики.
G>5) Надежность. Это то, что в Эрланге сделано великолепно — лучше всех. Телекомоские приложения (да и не только — любые промышленные системы) должны быть устойчивы к ошибкам, которые в них содержаться. Потому, код обнаружения и корректной обработки ошибок занимает в них значительный объем, распылен по логике, и затрудняет ее понимание. Ну, типа, вы открываете файл, потом пишете в него, делаете еще некторые действия, и на каждом этапе может возникнуть ошибка, которую надо обнаружить, корректно обработать, и корректно вернуть управление наверх. Падать нельзя. Знакомая проблема? Что сделано в Эрланге: G>- код обработки ошибок всегда строго отделен от кода, который выполняет логику. G>- код обнаружения ошибок отсутствует вовсе. Let it crash — при ошибке должно все упасть, и чем раньше, тем лучше. Т.е. прикладная логика у вас выглядит просто и прозрачно — она не замутнена этим дурацким кодом. G>- Процессы полностью изолированы — один процесс никак другому не повредит, и они умеют мониторить друг друга.
Здесь вообще противоречие (см. выделеное)
Подобный подход к достижению надежности используется в NonStop-приложениях (бывший Tandem), вплоть до мониторинга процессов друг другом.
G>Именно это свойство дает значительную экономию по объему кода в телеком-приложениях. Обработка ошибок в Эрланге сделана не хорошо — она волшебна. А именно наличием кода обработки ошибок и реакцией на ошибки индустриальные приложения и отличаются от академических и учебных. Наши лучшие плюсовики млеют от того, насколько воздушно делается обработка ошибок на Эрланге — индустриальная разработка лишается половины своего геморроя, превращаясь в легкую прогулку (ну, почти).
Самую крутую систему обработки проблем, про которую я слышал от очевидцев, была реализована в советской ПРО на Эльбрусах, которые могли зависать и перезагружаться раз в 15 секунд. При этом нужно было вести траекторию цели и противоракеты в жестком реальном времени. Контрольные точки и быстрое восстановление после сбоев.
Что касается волшебной обработки ошибок на Erlang-е, может ли кто-нибудь привести примеры того, насколько она отличается от таковой, скажем в C++, C# или Java.
G>6) Распределенность. Когда вы проектируете приложение — оно изначально параллельно, и требует минимум модификаций при запуске на кластере машин. Неплохо для серверов, и совершенно необходимо для обеспечения отказоустойчивости.
Опять же, здесь не столько язык влияет на окончательный результат, сколько выбранный инструментарий вообще. Системы обмена сообщениями, имхо, вне зависимости от типа языка программирования, способны существенно упростить разработку распределенных/распараллеливаемых приложений по сравнению, например, с удаленным вызовом процедур.
Т.е. из всего вышесказанного лично для меня следуюет, что Erlang, как набор архитектурных решений и инструментов сильно выигрывает у C++. Но сравнение с каким-нибудь Eiffel-ем, C# или Java будет, имхо, не настолько в пользу Erlang-а. Другое дело, что Eiffel, будучи очень интересным языком, так и не смог завоевать достаточное место под Солнцем.
G>7) Горячие обновления кода на живой системе. Систему 24х7 останавливать нельзя, патч надо уметь накатывать на работающую систему. Это важно для серверов.
Вот это да. Убийственный аргумент в пользу Erlang-а.
G>Отсюда видно, что для серверных приложений Эрланг весьма неплох. И, с появлением внятных инталляторов и графических библиотек, должен теоретически быть неплох на клиенте.
Угу.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну, в природе можно найти множество доказавших свою надежность систем написанных на самых разных языках. Опыт Ericsson-а в телекоме, конечно, показателен. Но далеко не всем приходится заниматься телекомом. Поэтому и интересно понять, будет ли удешевление от использования Erlang-а в других условиях. И если будет, то за счет чего.
А все распределенное и требующее некоей минимальной реактивности весьма близко к телекому. Чем, например, отличается распределенный сервер сбора и обработки телеметрических данных от распределенного сервера сбора и обработки некоей бизнес-информации ?
E>А то, что не статика и не динамика определяют надежность -- это факт E>Люди по любому гораздо менее надежный фактор в этом деле.
Верно ! Но при использовании динамики именно ЛЮДИ почему-то делают гораздо меньше ошибок. Я уже приводил пример : знакомая контора перешла при написании всяческих расчетных вещей с С++ на Тикль. Считает немного медленнее, но зато быстро делается работающий и стабильный продукт. Сокращение сроков и трудозатрат у них было просто неимоверное...
Здравствуйте, eao197, Вы писали:
E>Понятия не имею о каких телеметрических данных идет речь и о какой бизнес-информации.
Ну, к примеру, подача воздуха в шахту как телеметрия ( кубы в секунду, потребляемая мощность, температура воздуха, температура электромоторчиков, каждый по несколько мегаватт...) и запросы на получение данных по семье из паспортного стола.
E>Немного медленнее -- это им повезло, либо они делали интеграцию Тикля с C++.
Очень ограниченная интеграция — на ++ только запускалка целой кучи скриптов. Все вычисления — на Тикле. В некоторых случаях они получили даже ускорение обработки — а все потому, что алгоритм на Тикле оказался ГОРАЗДО более обозримым, чем на ++, и вследствие чего они смогли сделать его модификацию. Очень грубый пример : есть некая плавающая сумма за период времени, скажем за сутки. Она складывается из 1-минутных отсчетов. На С++ для этого использовался огромный массив, который суммировался при каждом приходе данных. На тикле они обошлись 2-мя операциями — вычесть из суммы самый старый отсчет, прибавить новый, и занести его в массив. Конечно же, на С++ это тоже можно было бы сделать... если бы это просто можно было увидеть...Слишком много там было разных деталей, которые мешали увидеть ситуацию.
E>У меня другой опыт -- есть изрядное количество отчетов, вычисляемых на Ruby. С увеличением объемов данных и усложнением самих отчетов время их формирования на Ruby уже перестает устраивать пользователей. В то время как C++ и D выполняют расчеты гораздо быстрее. Так что на некотором этапе быстрота разработки идет в топку, поскольку ее результат не удовлетворяет пользователей.
Я не использовал Руби в реальных приложениях, так что не могу сказать о сравнении скоростей. Но у этих моих знакомых обьемы весьма велики, но скорость устраивает диспетчеров и технологов. Так что, видимо, есть разные способы содрать с кошки шкурку
Здравствуйте, gandalfgrey, Вы писали:
E>>Понятия не имею о каких телеметрических данных идет речь и о какой бизнес-информации. G>Ну, к примеру, подача воздуха в шахту как телеметрия ( кубы в секунду, потребляемая мощность, температура воздуха, температура электромоторчиков, каждый по несколько мегаватт...) и запросы на получение данных по семье из паспортного стола.
Вопрос не столько в прикладном смысле информации, сколько в ее обработке и хранении.
G>Я не использовал Руби в реальных приложениях, так что не могу сказать о сравнении скоростей. Но у этих моих знакомых обьемы весьма велики, но скорость устраивает диспетчеров и технологов. Так что, видимо, есть разные способы содрать с кошки шкурку
Это теже знакомые, которые суммировали большие вектора?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>А то, что не статика и не динамика определяют надежность -- это факт E>>Люди по любому гораздо менее надежный фактор в этом деле. G>Верно ! Но при использовании динамики именно ЛЮДИ почему-то делают гораздо меньше ошибок. Я уже приводил пример : знакомая контора перешла при написании всяческих расчетных вещей с С++ на Тикль. Считает немного медленнее, но зато быстро делается работающий и стабильный продукт. Сокращение сроков и трудозатрат у них было просто неимоверное...
Ну вот убейте меня, но не понимаю я, почему именно в динамическом языке люди совершают меньше ошибок? Может все таки стоит сравнивать не древний C++ с его болячками, а более молодые языки? Основной посыл писателей на динамике — мы все тестируем. Но что мешает тестировать в статике? Попробую еще раз привести списочек различий при одинаковом тестовом покрытии:
c/t — compile time
r/t — runtime (т.е. тесты, и если не оттестировали — в продакшене)
Статика
Динамика
1.
Опечатки
c/t
r/t
2.
Сигнатуры
c/t
r/t (**1)
3.
Объем кода
средний/мал(**2)
мал
4.
Простой рефакторинг
c/t
r/t
5.
Функциональный рефакторинг
r/t
r/t
6.
Компонентность
c/t r/t (**3)
r/t
7.
Надежность рантайма
высокая(**4)
высокая
8.
Скорость выполнения
высокая
низкая(**5)
9.
Скорость разработки
средняя/низкая
высокая
(**1) как выяснилось в erlang признаки статики как минимум на уровне модулей, т.е. это уже как бы и не совсем динамика
(**2) scala по краткости кода не уступят питону или ruby, хоть язык еще и не production, да и D не сильно многословнее
(**3) нормально и безопасно компонентность по моему еще нигде не реализована (т.е. и на уровне c/t и на уровне r/t, везде что-то не хватает)
(**4) для статических языков работающих в vm или как минимум с gc
(**5) есть исключения, но как правило динамические языки медленее статически типизированных
Вроде ничего не забыл. И вот из этих умозаключений я ну никак не пойму неоспоримых плюсов динамики... Даже больше, я лично вижу больше минусов, чем плюсов.
Здравствуйте, eao197, Вы писали:
E>Вопрос не столько в прикладном смысле информации, сколько в ее обработке и хранении.
В общем-то, и тут разницы мало... "Люди есть люди, небо есть небо, и так везде" (с) Дзюбей Кибагами
E>Это теже знакомые, которые суммировали большие вектора?
Ну да. Я ж написал "Эти знакомые". Кстати, устраивать заказчика работа расчетных вещей стала именно после массированного перехода на Тикль. Ту , конечно, не одна причина
Здравствуйте, gandalfgrey, Вы писали:
E>>Вопрос не столько в прикладном смысле информации, сколько в ее обработке и хранении. G>В общем-то, и тут разницы мало... "Люди есть люди, небо есть небо, и так везде" (с) Дзюбей Кибагами
Мне сложно судить. Хотя, помниться, обработка телеметрической информации для оперативного реагирования (например, для управления чем-нибудь) -- это одно, а обработка с целью складирования, архивирования и последующего анализа/обработки -- совсем другое. Но может это мне так по молодости казалось, когда довелось этими темами заниматься
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Объем кода по сравнению с C++/Java не просто маленький, а очень маленький. Соответственно, проще держать его в уме, соответственно, меньше ошибок допускается.
Я про это уже писал, когда приводил пример с расчетами на С++ и на Тикле. На ++ именно обьем кода не давал увидеть, что за ним кроется.
E>А сравнение идет с C++/Java потому, что это промышленные и широкораспространенные платформы, которые можно брать и использовать практически для любых задач. Есть и другие хорошие языки (Eiffel, Modula-2, Ada, к примеру). Только вот не получится на них взять и так просто серьезный проект стартовать.
Эйфель почему-то почти нигде у нас в России не прижился. Начать проект на Аде я считаю просто нереальным — сложность самого языка требует совершенно дурных денежных вливаний в обучение и переобучение персонала. Хорошо Минобороны Штатов — у них денежек больше, чем во всем софте байтов.
А модула-2, да и 3-я тоже даст ли ощутимый выигрыш ?
Здравствуйте, eao197, Вы писали:
E>Мне сложно судить. Хотя, помниться, обработка телеметрической информации для оперативного реагирования (например, для управления чем-нибудь) -- это одно, а обработка с целью складирования, архивирования и последующего анализа/обработки -- совсем другое. Но может это мне так по молодости казалось, когда довелось этими темами заниматься
Диспетчерам мало видеть то, что происходит сейчас — они хотят знать тенденции процессов, тренды и прочую галиматью. Например, ежели за последние полчаса откачивается больше воды, чем за это же время сутки назад — это повод для тревоги, ибо грозит прорывом паводковых вод или чем еще. На самом деле, конечно, обработка намного более сложная, чем этот пример.
Здравствуйте, aka50, Вы писали:
A>Тогда и надо говорить, что рулит erlang (удачно спроектирован) и smalltalk (древний), а Java (ущербно упрощена, та же scala или clean отлично демонстрируют что могло бы быть по другому) и С++(ну... сами знаете) в заднице. Но при чем тут динамика/статика — я не понимаю . Да и распространенность чего-либо не является его неоспоримым плюсом (пример: жигули vs майбах).
Ну так я и говорю, что на надежность влияние как статики, так и динамики, весьма косвенная.
А вот распространенность играет важную роль для уменьшения рисков провала проекта:
* при причинам отсутствия качественных библиотек/инстрементов;
* из-за невозможности найти квалифицированных разработчиков.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
E>>Мне сложно судить. Хотя, помниться, обработка телеметрической информации для оперативного реагирования (например, для управления чем-нибудь) -- это одно, а обработка с целью складирования, архивирования и последующего анализа/обработки -- совсем другое. Но может это мне так по молодости казалось, когда довелось этими темами заниматься G>Диспетчерам мало видеть то, что происходит сейчас — они хотят знать тенденции процессов, тренды и прочую галиматью. Например, ежели за последние полчаса откачивается больше воды, чем за это же время сутки назад — это повод для тревоги, ибо грозит прорывом паводковых вод или чем еще. На самом деле, конечно, обработка намного более сложная, чем этот пример.
Вот об этом-то я и говорю. Как только появляются в поле зренения исторические тренды, подход к складированию данных меняется. Особенно в случаях, когда опросы идут с большим темпом (скажем близко к сотне раз в секунду).
С другой стороны, когда мы управляем двигателями или весовыми машинами, складирование не нужно и информация перестает быть важной сразу после своей обработки. Зато и обработка, как правило, сложнее. Вплоть до использования сложных и ресурсоемких расчетов на специальном оборудовании.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вот об этом-то я и говорю. Как только появляются в поле зренения исторические тренды, подход к складированию данных меняется. Особенно в случаях, когда опросы идут с большим темпом (скажем близко к сотне раз в секунду).
Точно я не скажу, но они говорили о нескольких тысяч точек с 15-секундными и 1-минутными отсчетами. Тикль как инструмент для складирования, добывания обратно и обработки данных их более чем устраивает. Все альтернативные решения, которые они пробовали, проигрывают в разы по суммарной эффективности
E>С другой стороны, когда мы управляем двигателями или весовыми машинами, складирование не нужно и информация перестает быть важной сразу после своей обработки. Зато и обработка, как правило, сложнее. Вплоть до использования сложных и ресурсоемких расчетов на специальном оборудовании.
Как я понимаю, спецжелезо они не ставят. Максимум, что есть — это Линукс-боксы ( Пень-3 и 256 мег РАМы в свистке ). К счастью, раскидать обработку по разным узлам ин несложно
Здравствуйте, eao197, Вы писали:
G>>В результате G>>1) В Эрланге отсутствуют конструкции и языковые средства имеющие слабопредсказуемое время выполнения. Так как телекомовские системы должны иметь хорошую реактивность — характеристика soft-realtime. Это свойство не повредит вообще любой интерактивной системе. К примеру, в Эрланге нет ленивых вычислений.
E>Не думаю, что это имеет отношение к динамике. E>Опять же, сборка мусора не является прерогативой динамики. E>Мне кажется, что здесь намешано много чего под один пункт. Что явно выделяется -- паттерн-матчинг для выборки сообщений, но и он не является прерогативой динамики.
"Шел ежик в каске. Не смешно? Зато про войну"
Тебе про динамику, или про то, почему Эрланг удобен для телекома? Ты уж определись. Меня ты спросил про второе. Про динамику спорь с кем-нибудь другим — я на эту тему сказал уже все что думаю.
G>>5) Надежность. Это то, что в Эрланге сделано великолепно — лучше всех. Телекомоские приложения (да и не только — любые промышленные системы) должны быть устойчивы к ошибкам, которые в них содержаться. Потому, код обнаружения и корректной обработки ошибок занимает в них значительный объем, распылен по логике, и затрудняет ее понимание. Ну, типа, вы открываете файл, потом пишете в него, делаете еще некторые действия, и на каждом этапе может возникнуть ошибка, которую надо обнаружить, корректно обработать, и корректно вернуть управление наверх. Падать нельзя. Знакомая проблема? Что сделано в Эрланге: G>>- код обработки ошибок всегда строго отделен от кода, который выполняет логику. G>>- код обнаружения ошибок отсутствует вовсе. Let it crash — при ошибке должно все упасть, и чем раньше, тем лучше. Т.е. прикладная логика у вас выглядит просто и прозрачно — она не замутнена этим дурацким кодом. G>>- Процессы полностью изолированы — один процесс никак другому не повредит, и они умеют мониторить друг друга.
E>Здесь вообще противоречие (см. выделеное)
Нет, здесь недопонимание, а не противоречие. Падение процесса в Эрланге не означает падения всего приложения — процессы полностью изолированы. Это в системах на обычных языках падать нельзя (знакомая проблема?), а в Эрланге можно и нужно.
E>Самую крутую систему обработки проблем, про которую я слышал от очевидцев, была реализована в советской ПРО на Эльбрусах, которые могли зависать и перезагружаться раз в 15 секунд. При этом нужно было вести траекторию цели и противоракеты в жестком реальном времени. Контрольные точки и быстрое восстановление после сбоев.
К сожалению, эрланг-система не зависает и не перезагружается раз в 15 секунд — она продолжает работать в штатном режиме. В том числе и при отказе железа. Но если ты предпочитаешь использовать преимущество архитектуры Эльбрус-2 с зависаниями и перезагрузками раз в 15 секунд — то пожалуйста . Главное — найти рабочий экземпляр Эльбрус-2.
E>Что касается волшебной обработки ошибок на Erlang-е, может ли кто-нибудь привести примеры того, насколько она отличается от таковой, скажем в C++, C# или Java.
Почитай диссертацию Армстронга, там есть примеры. Или попроси gandalgray.
G>>6) Распределенность. Когда вы проектируете приложение — оно изначально параллельно, и требует минимум модификаций при запуске на кластере машин. Неплохо для серверов, и совершенно необходимо для обеспечения отказоустойчивости.
E>Опять же, здесь не столько язык влияет на окончательный результат, сколько выбранный инструментарий вообще. Системы обмена сообщениями, имхо, вне зависимости от типа языка программирования, способны существенно упростить разработку распределенных/распараллеливаемых приложений по сравнению, например, с удаленным вызовом процедур.
Система обмена сообщениями и процессы является неотъемлемой частью языка Эрланг. Язык предполагает определенную философию разработки приложений, и она такова, что программа твоя изначально параллельна. Ты можешь симулировать похожий стиль на других языках, как симулируюся замыкания на функторах в С++, и континуэйшны на файберах, но к оригиналу ты не приблизишься. Эрланг имеет наиболее подходящий для этого рантайм и синтаксис.
E>Т.е. из всего вышесказанного лично для меня следуюет, что Erlang, как набор архитектурных решений и инструментов сильно выигрывает у C++. Но сравнение с каким-нибудь Eiffel-ем, C# или Java будет, имхо, не настолько в пользу Erlang-а. Другое дело, что Eiffel, будучи очень интересным языком, так и не смог завоевать достаточное место под Солнцем.
Сравнение будет настолько же в пользу Эрланга. Существенное отличие Java от С++ при данном сравнении состоит в отсутствии явного управления памятью.
G>>7) Горячие обновления кода на живой системе. Систему 24х7 останавливать нельзя, патч надо уметь накатывать на работающую систему. Это важно для серверов.
E>Вот это да. Убийственный аргумент в пользу Erlang-а.
Кстати, нет. Такое же делается на Java, хоть это и более трудоемко и опасно. А в случае, если рантайм нам таких фокусов не позволяет — просто ставятся рядом два сервера, один из которых шатдаунится для апгрейда. В большинстве случаев этого хватает, но это тоже более геморройно.
Здравствуйте, Gaperton, Вы писали:
G>"Шел ежик в каске. Не смешно? Зато про войну" G>Тебе про динамику, или про то, почему Эрланг удобен для телекома? Ты уж определись. Меня ты спросил про второе. Про динамику спорь с кем-нибудь другим — я на эту тему сказал уже все что думаю.
Упс... Действительно, занесло меня несколько. Но поскольку Erlang насквозь динамичен, то невольно переходишь на обсуждение "почему динамика удобна для телекома"
G>Нет, здесь недопонимание, а не противоречие. Падение процесса в Эрланге не означает падения всего приложения — процессы полностью изолированы. Это в системах на обычных языках падать нельзя (знакомая проблема?), а в Эрланге можно и нужно.
Когда речь идет о процессах, из которых состоит приложение, то даже в отношении C++ падение процесса не затрагивает других процессов (если речь не об MS-DOS или каких-нибудь hard-real-time OS). На C/C++ в Unix-ах испокон веку разрабатывали сложные системы на распараллеливании именно процессов, а не нитей. Поэтому и сейчас самый, наверное, дешевый способ увеличения надежности системы -- разбиение ее на отдельные процессы, тогда и падения, и переконфигурирование обходятся гораздо дешевле. Правда, дороже обходится взаимодействие процессов.
E>>Что касается волшебной обработки ошибок на Erlang-е, может ли кто-нибудь привести примеры того, насколько она отличается от таковой, скажем в C++, C# или Java.
G>Почитай диссертацию Армстронга, там есть примеры. Или попроси gandalgray.
На диссертацию гляну, а где именно там смотреть?
Может еще и gandalgray чего продемонстрирует.
G>Система обмена сообщениями и процессы является неотъемлемой частью языка Эрланг. Язык предполагает определенную философию разработки приложений, и она такова, что программа твоя изначально параллельна. Ты можешь симулировать похожий стиль на других языках, как симулируюся замыкания на функторах в С++, и континуэйшны на файберах, но к оригиналу ты не приблизишься. Эрланг имеет наиболее подходящий для этого рантайм и синтаксис.
Нудык если бы вся задача состояла только в отсылке или получении собщений, тогда да. А ведь кроме этого существует еще и основная логика. Ее далеко не всем удобно и привычно в функциональном стиле реализовывать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>На диссертацию гляну, а где именно там смотреть? E>Может еще и gandalgray чего продемонстрирует.
Запросто
client_proxy(Dc)->
receive
stop->ok;
{'EXIT',Pid,Reason}->
case analyze_err(Reason) of
restart->
{M,F,D}=dict:fetch(Pid,Dc),
Pid1=spawn_link(M,F,[D]),
client_proxy(dict:store(Pid1,{M,F,D},dict:erase(Pid,Dc)));
drop->
client_proxy(dict:erase(Pid,Dc))
end;
{start,Mod,Func,Data}->
Pid=spawn_link(Mod,Func,[Data]),
client_proxy(dict:store(Pid,{Mod,Func,Data},Dc))
end.
Это упрощенный кусок прокси клиентов. Если клиент сдыхает, то функция analyze_err ( которую я здесь не привожу ) определяет, имеет ли смысл перезапустить клиентский процесс или "доктор сказал — в морг !". В клиентском процессе производится обработка запроса, и оная обработка вполне может быть написана криво.
E>Нудык если бы вся задача состояла только в отсылке или получении собщений, тогда да. А ведь кроме этого существует еще и основная логика. Ее далеко не всем удобно и привычно в функциональном стиле реализовывать.
Привычка приходит во время работы. И достаточно быстро
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>На диссертацию гляну, а где именно там смотреть? E>>Может еще и gandalgray чего продемонстрирует. G>Запросто
G>
G>Это упрощенный кусок прокси клиентов. Если клиент сдыхает, то функция analyze_err ( которую я здесь не привожу ) определяет, имеет ли смысл перезапустить клиентский процесс или "доктор сказал — в морг !". В клиентском процессе производится обработка запроса, и оная обработка вполне может быть написана криво.
Алаверды:
void
processInterval( in StartStopInfo currentInterval )
{
int errors = 0;
while( errors < options_.retries )
{
try
{
log_.info(
sprint()(
"processing interval: {}",
currentInterval.toUtf8 ) );
auto cmdLine = makeCmdLine( currentInterval );
auto result = psql( options_, cmdLine );
return;
}
catch( NonZeroProcessStatusException x )
{
log_.warn( sprint()( "process lanching exception: {}", x ) );
foreach( line; x.stderr )
log_.warn( line );
}
catch( Exception x )
{
log_.error( sprint()( "exception caught: {}\n", x ) );
}
++errors;
}
log_.fatal( sprint()( "too many errors during processing interval: {}",
currentInterval.toUtf8 ) );
problemsRegistrator_.registerInterval( currentInterval );
}
Для выполнения действий над БД запускается утилита psql, которая может отработать неудачно. Поэтому в случае неудачи psql перезапускает пока не истечет необходимое количество попыток. Если убрать логирование и отбросить особенности форматирования, то получается не большая уж и разница.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Для выполнения действий над БД запускается утилита psql, которая может отработать неудачно. Поэтому в случае неудачи psql перезапускает пока не истечет необходимое количество попыток. Если убрать логирование и отбросить особенности форматирования, то получается не большая уж и разница.
А теперь как минимум вспоминаем разницу между процессами ОС и процессами Эрланга, плюс "встроенность" эрланговских процессов по сути в сам язык.
Здравствуйте, Курилка, Вы писали:
E>>Для выполнения действий над БД запускается утилита psql, которая может отработать неудачно. Поэтому в случае неудачи psql перезапускает пока не истечет необходимое количество попыток. Если убрать логирование и отбросить особенности форматирования, то получается не большая уж и разница.
К>А теперь как минимум вспоминаем разницу между процессами ОС и процессами Эрланга, плюс "встроенность" эрланговских процессов по сути в сам язык.
И как это все сказывается на "волшебной обработке ошибок"?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Для выполнения действий над БД запускается утилита psql, которая может отработать неудачно. Поэтому в случае неудачи psql перезапускает пока не истечет необходимое количество попыток. Если убрать логирование и отбросить особенности форматирования, то получается не большая уж и разница.
В моем примере client_proxy держит одновременно несколько сотен процессов и обрабатывает их независимо друг от друга. Как вырастет для этого случая ваш код ? Или вы запускаете для каждого процесса свой супервайзер ? А как тогда организуется взаимодействие между супервайзорами типа "перезапускать процесс func1, если запущен процесс func2 и не запущен func3" ?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>А теперь как минимум вспоминаем разницу между процессами ОС и процессами Эрланга, плюс "встроенность" эрланговских процессов по сути в сам язык.
E>И как это все сказывается на "волшебной обработке ошибок"?
Ну да, я немного не о том, но вот ты покажи — кто у тебя эксепшны генерит для отдельного процесса? В Эрланге это будет "бай дефолт", покажи свой код.
A>>Абсолютно не факт, что будучи у ералнга статическая типизация он не был бы еще надежнее... G>Если бы от статической тиизации в Эрланге было больше пользы, чем вреда и геморроя, ее бы туда давно добавили. Эрланг — инженерно-практический язык, это не платформа для научны исследований вроде Хаскеля. Эта тема регулярно поднимается в Эрланговском мэйллисте, и закрывается каждый раз с одинаковой резолюцией — нафиг. Ну то есть неплохо бы в принципе со статикой, но и без нее все достаточно хорошо.
Все еще проще. Когда-то давным давно Эрикссон даже спрашивал клиентов своих, мол, нужна ли вам статика. Все дружно отвечали: "в сад" Об этом, по-момему, Wiger или даже Armstrong в рассылке говорил
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали: К>>А теперь как минимум вспоминаем разницу между процессами ОС и процессами Эрланга, плюс "встроенность" эрланговских процессов по сути в сам язык.
E>Да, раз уж пошли подколки, то за именование переменных вроде
Никаких подколок не подразумевалось
Просто реально разница именно из-за "встроенности" и получение сообщений от "дохлых" процессов тоже оттуда E>
E>{M,F,D}=dict:fetch(Pid,Dc),
E>
E>не мешало бы кому-нибудь по чему-нибудь настучать
Спорно, вопрос личных предпочтений, или ты вслед за Владом пойдёшь воевать в пользу [head|tail] против [x|xs]?
В Эрланге функции небольшие, поэтому там не нужно держать в уме большой контектс переменных, полей и т.п. Так что краткие названия вполне нормальное едло, имхо.
Здравствуйте, gandalfgrey, Вы писали:
E>>Для выполнения действий над БД запускается утилита psql, которая может отработать неудачно. Поэтому в случае неудачи psql перезапускает пока не истечет необходимое количество попыток. Если убрать логирование и отбросить особенности форматирования, то получается не большая уж и разница. G>В моем примере client_proxy держит одновременно несколько сотен процессов и обрабатывает их независимо друг от друга. Как вырастет для этого случая ваш код ? Или вы запускаете для каждого процесса свой супервайзер ? А как тогда организуется взаимодействие между супервайзорами типа "перезапускать процесс func1, если запущен процесс func2 и не запущен func3" ?
А где все эти условия в вашем коде? В спрятанной функции analyze_err?
У меня все просто -- на каждый дочерний процесс по нити, поскольку процессов не много. Каждая нить выполняет свою работу, частью которой является запуск и контроль дочернего процесса. Если по логике работы потребуется создать что-нибудь вроде перезапуска func1 при func2 и отсутствии func3, то что сложного в том, чтобы это сделать?
Тем более, что супервайзеры, если я правильно понял, это не часть языка Erlang-а, а одна из его библиотек. Неужели вы думаете, что подобную библиотеку сложно сделать для других языков? Вон у Tandem-ов она является частью ОС.
Сотни процессов -- это типа, сильный аргумент должен быть? Ну так даже на обычном select-е в C/C++ делают обработку сотен сокетов и ничего, не так уж и сложно все получается.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А где все эти условия в вашем коде? В спрятанной функции analyze_err?
Эта функция представляет собой длинный набор паттернов ( в основном ), и только в некоторых случаях там пишется что-то еще. Что-то типа :
E>У меня все просто -- на каждый дочерний процесс по нити, поскольку процессов не много. Каждая нить выполняет свою работу, частью которой является запуск и контроль дочернего процесса. Если по логике работы потребуется создать что-нибудь вроде перезапуска func1 при func2 и отсутствии func3, то что сложного в том, чтобы это сделать?
Вопрос в том, как они контролируют состояние других нитей ?
E>Тем более, что супервайзеры, если я правильно понял, это не часть языка Erlang-а, а одна из его библиотек. Неужели вы думаете, что подобную библиотеку сложно сделать для других языков? Вон у Tandem-ов она является частью ОС.
В данном случае это и был рукописный супервайзер, а не библиотечный
E>Сотни процессов -- это типа, сильный аргумент должен быть? Ну так даже на обычном select-е в C/C++ делают обработку сотен сокетов и ничего, не так уж и сложно все получается.
Ну, когда речь пойдет о тысячах и десятках тысяч процессов, это станет сильным аргументом 8)). Но я говорил не об этом, а об обработке супервайзером НАБОРА состояний процессов.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>Для выполнения действий над БД запускается утилита psql, которая может отработать неудачно. Поэтому в случае неудачи psql перезапускает пока не истечет необходимое количество попыток. Если убрать логирование и отбросить особенности форматирования, то получается не большая уж и разница. G>В моем примере client_proxy держит одновременно несколько сотен процессов и обрабатывает их независимо друг от друга. Как вырастет для этого случая ваш код ? Или вы запускаете для каждого процесса свой супервайзер ? А как тогда организуется взаимодействие между супервайзорами типа "перезапускать процесс func1, если запущен процесс func2 и не запущен func3" ?
А почему этого не может делать библиотека? Если уж в scala http://lamp.epfl.ch/~phaller/doc/ActorsTutorial.html наваяли, то думаю не будет больших проблем использовать это из любого jvm языка? Более того, в этой скаловской либе есть точно такой-же link как и в erlang (т.е. "супервайзер" пишется так же легко и непринужденно). В ней же реализована thread-less модель актеров. При чем достаточно производительная http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf.
Так что по поводу обработки ошибок — думаю это вопрос фреймворка и типа языка (в функциональных проще делать recover) и на любом языке с vm это реализуемо.
Здравствуйте, aka50, Вы писали:
A>Так что по поводу обработки ошибок — думаю это вопрос фреймворка и типа языка (в функциональных проще делать recover) и на любом языке с vm это реализуемо.
Это всё хорошо, только вот есть некоторая разница между "реализуемо" и "реализовано". В Эрланге заметная часть использует фишки самой ВМ, на JVM же тебе придётся либо весь код как-то инструментировать, т.е. перелопачивать ВМ по сути, или же решение будет "не до конца". Хотя, конечно, это ближе к субъективному мнению, чем к исследованию такой возможности с чёткими выкладками, примерами и т.п.
Здравствуйте, eao197, Вы писали:
E>Вот gandalfgrey говорит, что с 1994 по 2002 он принимал участие в разработке серьезной системы для предприятия по переработке урана. На C++. А вы бы решились сейчас вести такую разработку на Mono? Ну т.е. прямо сейчас, даже с учетом того, что первый год-полтора будет полностью посвящен проектированию, моделированию и прототипированию.
Логика офигительная. На С++ значит решились, а на Моно нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
G>>А что, Моно уже НОРМАЛЬНО и ПОЛНОЦЕННО работает хотя бы на десятке платформ ? VD>Года эдак 3 уже как.
Ну... Насчет "нормально", "полноценно" и "десяток" платформ можно поспорить.
Здравствуйте, Gaperton, Вы писали:
G>На этот счет есть и прямо противоположное мнение. В динамическом языке любая функция — это generic-функция, она полиморфна. Что уменьшает связность системы и количество усилий по рефакторингу.
Она не просто полиморфна. Она случайно полиморфна. Возможно в некоторых ситуациях этот полимпофизм будет ошибкой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
К>>А теперь как минимум вспоминаем разницу между процессами ОС и процессами Эрланга, плюс "встроенность" эрланговских процессов по сути в сам язык.
E>И как это все сказывается на "волшебной обработке ошибок"?
Я вот тоже много слышал восхищений обработкой ошибок в Эрланге, но что-то когда я просил объяснить это, то в лучшем случае мне говорили "это тоже самое, что обработка исключений".
Конечно изолированность процессов дает дополнительное приемущество. Но это скорее приемущество подхода с программно-изолированными процессами. Такой подход реализуем и вне Эрланга. Например, он реализован в Sing#-е (клоне C#-а из Сингулярити). Причем там седано больше чем в Эрланге. Там кроме всего прочего есть еще декларативное описание протокола. Можно это реализовать и на языках с изменяющимся синтаксисом вроде Немерла и Лиспа.
Несомненно функциональная ориентация удешевляет эмуляцию параллелизма. Но пожалуй — это все. В остальном тех же возможностей можно добиться на универсальных, статически типизированных языках.
ЗЫ
Что же касается обработки ошибок, то чесно говоря я не понимаю чем тут помгут процессы в общем случае. Ведь если что-то не работает, то но не работает. Янус тоже практически никогда не выпадает в осадок. Но если какая-то важная функция глючит, то радости от невыпадения в осадок как-то не много. Да и не выпадает он естественно потому что есть обработка исключений, сам он написан в рассчете на нее и с исползованием типобезопасного языка.
Так что у меня большие сомнения в том, что будь Янус написан на Эланге, то он работал бы надежнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Между прочим этот пример есть почти у всех нас дома — это сливной бачок унитаза . VD>Советская консрукция механизма налива воды в бачок очень проста. Это поплавок на длинной ножке который воткнут в некий штифт. На втором его конце резиновая прокладка. При заполнении водой бачка он поднимается и пережимает наливное отверсие. VD>Несколько более сложная кострукция с трубой работает намного надежнее. Еще более сложные констркции работают вообще так, что например, у меня дома я вообще не заглядывал в бачок унитаза (и сантехник тоже) с тех времен как его поставили в 1995-ом году (т.е., мама дорогая, вот уже 12 лет! Самому страшо подумать ).
Согласен, но с небольшим дополнением: плохая реализация простой конструкции и плохая реализация сложной отличаются уже не в пользу последней , т.к. простая просто ломается, а сложная глючит. Как пример: у меня сливной бачек сложной конструкции производства made in Russia (типа съэкономил), дык вот через 2 месяца он начал глючить. Все мои попытки его починить приводили его в чувство от силы на месяц. ПРоблема была решена кардинально — замена на итальянскую. А совецкий всего лишь раз в год надо было просто тупо менять
Здравствуйте, VladD2, Вы писали:
G>>А что, Моно уже НОРМАЛЬНО и ПОЛНОЦЕННО работает хотя бы на десятке платформ ? VD>Года эдак 3 уже как.
А можно списочек ?
Здравствуйте, Gaperton, Вы писали:
G>Вообще-то Эрланг существенно быстрее Ruby, Тикля и питона. Или скажем по другому — медленнее чем Руби язык найти сложно.
Питон тоже существенно быстрее чем руби и тикль, вот сравнений с эрлангом что-то не видел.
Здравствуйте, Gaperton, Вы писали:
G>arg_requirement = { init/1, call/2, fuck_off/4 } G>func( x : arg_requirement, y : { method1/2, method2/4 } , z )
В принципе, такое можно сделать через список гардов when. Но это будет рыхло выглядеть
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>arg_requirement = { init/1, call/2, fuck_off/4 } G>>func( x : arg_requirement, y : { method1/2, method2/4 } , z ) G>В принципе, такое можно сделать через список гардов when. Но это будет рыхло выглядеть
Ммм, а на что ты гарды будешь вешать?
Понимаю были бы Объекты/Классы в Эрланге, а так? Единственная аналогия приходит в голову — behavior.
На процессы гарды не повесишь
Здравствуйте, Gaperton, Вы писали:
G>func( x : { init/1, call/2, fuck_off/4 }, y : { method1/2, method2/4 } )
G>Или так:
G>arg_requirement = { init/1, call/2, fuck_off/4 } G>func( x : arg_requirement, y : { method1/2, method2/4 } , z )
Интересно получается.
forward_iterator = { next/0, data }
transform( End : forward_iterator, End : forward_iterator, _, _ ) -> ok;
transform( Begin : forward_iterator, End : forward_iterator, F/1, Res : forward_iterator ) ->
Res.data <- F( Begin.data ),
transform( Begin.next(), End, F, Res.next() ).
Прикольно. Можно регулировать подробность спецификаций типов как угодно — совмещаем это с выводом типов, и компилятор может вылавливать противоречия. Разница со статической типизацией только в том, что мы не обязаны выводить полную информацию о типах — где не вывелось — там динамика. В таком языке у нас реально стирается грань между статикой и динамикой. Красиво. Жаль я не студент и не аспирант — такой дипломище бы забабахал...
log_info( Container : { begin, end }, File : { position } ) ->
transfrorm( Container.begin, Container.end, fun( X : { info } ) -> X.info end, File.position )
G>Прикольно. Можно регулировать подробность спецификаций типов как угодно — совмещаем это с выводом типов, и компилятор может вылавливать противоречия. Разница со статической типизацией только в том, что мы не обязаны выводить полную информацию о типах — где не вывелось — там динамика. В таком языке у нас реально стирается грань между статикой и динамикой. Красиво. Жаль я не студент и не аспирант — такой дипломище бы забабахал...
Может я ошибаюсь, но всё это очень напоминает то, что тут где-то FR писал по поводу планов по развития питона, где опционально появляются какие-то аннотации типа таких и получается гибкое комбинирование статики и динамики.
Здравствуйте, Курилка, Вы писали:
G>>Прикольно. Можно регулировать подробность спецификаций типов как угодно — совмещаем это с выводом типов, и компилятор может вылавливать противоречия. Разница со статической типизацией только в том, что мы не обязаны выводить полную информацию о типах — где не вывелось — там динамика. В таком языке у нас реально стирается грань между статикой и динамикой. Красиво. Жаль я не студент и не аспирант — такой дипломище бы забабахал...
К>Может я ошибаюсь, но всё это очень напоминает то, что тут где-то FR писал по поводу планов по развития питона, где опционально появляются какие-то аннотации типа таких и получается гибкое комбинирование статики и динамики.
Это хорошо, что такое появится в популярном языке. Реально нужная и полезная штука. Тока жаль Эрланговского синтаксиса там не будет, уж больно он воздушен .
Здравствуйте, aka50, Вы писали:
A>Согласен, но с небольшим дополнением: плохая реализация простой конструкции и плохая реализация сложной отличаются уже не в пользу последней ,
Сложная реализация появляется не от дури и темболее не с целью все усложнить. Она появляется для того, чтобы недопустить недостатки простой конструкции.
С тем же бочком — это выливается в керамический клапан, меньшие допуски при изготовлении, в попловок засунутый в трубку, а стло быть не дающий перекосов и вседа движущийся в одном направлении.
В общем, дизайн направлен именно на недопущение проблем в эксплуатации. Это и вызывает усложнение.
Вот точно так же статическая типизация и море проверок компилятора приводят к усложнению компилятора, но так как они нацелены на более раннее и более полное выявление ошибок, то они способствуют повышению качества.
A> т.к. простая просто ломается, а сложная глючит.
Опять заблуждение. Как раз сложные конструкции бачков обычно или работают, или нет. А наш совковый вариант именно что глючит (течет, свистит, залипает вынуждая лезть в бачек и подпихивать его пальцем).
A> Как пример: у меня сливной бачек сложной конструкции производства made in Russia
Расстрою тебя. В России вообще не делаются приличные конструкции наливных механизмов. Минимально приемлемый вариант — это Польша. Лучше если это будут швейцарцы, немыцы или японцы. Мой бачек дома как раз швейцарский.
A> (типа съэкономил), дык вот через 2 месяца он начал глючить. Все мои попытки его починить приводили его в чувство от силы на месяц.
Это как раз симптомы дешевого (простого) решения. Уверяю тебя, что починить даже Польский механизм ты будешь не в силах.
A> ПРоблема была решена кардинально — замена на итальянскую. А совецкий всего лишь раз в год надо было просто тупо менять
Вот это и есть замена простого решения на сложное.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandalfgrey, Вы писали:
G>>>А что, Моно уже НОРМАЛЬНО и ПОЛНОЦЕННО работает хотя бы на десятке платформ ? VD>>Года эдак 3 уже как. G>А можно списочек ?
Здравствуйте, FR, Вы писали:
G>>Вообще-то Эрланг существенно быстрее Ruby, Тикля и питона. Или скажем по другому — медленнее чем Руби язык найти сложно.
FR>Питон тоже существенно быстрее чем руби и тикль, вот сравнений с эрлангом что-то не видел.
Ну, так залудите альфа-блэнд на обоих языках. Посмеемся вместе .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Ммм, только сигнатура в Эрланге гораздо более мягкий критерий — имя и арность, не более... К>А по поводу привнесения статики я в декабре замутил дискуссию, правда свелась которая к тому, что попытки были, но вот смысла в этом особого "эрлангисты" не видят. Хотя были работы того же Вадлера и Dialyzer развивается. Хотя он по сути есть отдельная подключаемая тулза (а не встроена в компилятор).
МС тоже никогда не видит смысла в том, что у них не реализовано. Как только реализуют, то смысл чудесным образом появляется.
Так что не стоит слушать отмазки в стиле "а нам не надо". Это всегда больше отмазки, чем реальность.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, aka50, Вы писали:
VD>С тем же бочком — это выливается в керамический клапан, меньшие допуски при изготовлении, в попловок засунутый в трубку, а стло быть не дающий перекосов и вседа движущийся в одном направлении. VD>В общем, дизайн направлен именно на недопущение проблем в эксплуатации. Это и вызывает усложнение.
Угу, в нашем именно все это и было (т.е. это была калька с итальянского, но периодически в этой системе что-то заедало или выскакивало из креплений, при чем так, что починить можно было только достав это, разобрать и собрать назад... А совецкий можно было "пошерудив рукой" (с)Задорнов
VD>Вот точно так же статическая типизация и море проверок компилятора приводят к усложнению компилятора, но так как они нацелены на более раннее и более полное выявление ошибок, то они способствуют повышению качества.
+1
VD>Это как раз симптомы дешевого (простого) решения. Уверяю тебя, что починить даже Польский механизм ты будешь не в силах. механизм был сложный (второй двухкнопочный), но сделан у нас. Конструкция была и я его даже чинил
ЗЫ: правда зачем я его чинил, не понятно... наверное за тем же, зачем я делаю патчи к чужому софту
E>>не мешало бы кому-нибудь по чему-нибудь настучать К>Спорно, вопрос личных предпочтений, или ты вслед за Владом пойдёшь воевать в пользу [head|tail] против [x|xs]? К>В Эрланге функции небольшие, поэтому там не нужно держать в уме большой контектс переменных, полей и т.п. Так что краткие названия вполне нормальное едло, имхо.
Здравствуйте, Курилка, Вы писали:
К>Ну да, я немного не о том, но вот ты покажи — кто у тебя эксепшны генерит для отдельного процесса? В Эрланге это будет "бай дефолт", покажи свой код.
Эксепшены генерирует функция launchProcess, которую я когда-то написал для утилитки SvnParallelUpdate (попытка сделать D-шную версию Scala-примера SvnFastUpdate).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
E>>У меня все просто -- на каждый дочерний процесс по нити, поскольку процессов не много. Каждая нить выполняет свою работу, частью которой является запуск и контроль дочернего процесса. Если по логике работы потребуется создать что-нибудь вроде перезапуска func1 при func2 и отсутствии func3, то что сложного в том, чтобы это сделать? G>Вопрос в том, как они контролируют состояние других нитей ?
Нити не смогут контролировать состояния других нитей. А вот состояния других процессов можно контролировать по их статусам завершения.
E>>Сотни процессов -- это типа, сильный аргумент должен быть? Ну так даже на обычном select-е в C/C++ делают обработку сотен сокетов и ничего, не так уж и сложно все получается. G>Ну, когда речь пойдет о тысячах и десятках тысяч процессов, это станет сильным аргументом 8)).
Тысячи, десятки тысяч, сотни тысяч реактивных (т.е. реагирующих на внешние воздействия) легко решаются одной рабочей нитью и очередью заявок. А вот десятки тысяч проактивных процессов (т.е. самостоятельно инициирующих собственные операции, допустим по таймерам) доведут до деградации любую систему, хоть Erlang-овскую, хоть какую другую.
Так что я бы не стал приводить количество процессов в качестве серьезного аргумента -- всегда есть альтернативные варианты, со своими плюсами и минусами.
G>Но я говорил не об этом, а об обработке супервайзером НАБОРА состояний процессов.
Очень возможно, что я чего-то не понял. Извините, если что.
Может быть, еще представиться возможность пообщаться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Разумеется, я прекрасно знаю (уверен, большинство присутствующих тоже), что процессы оперсистемы дают изоляцию, и про организацию процессов в UNIX, приходилось под UNIX писать. И мне кажется, ты знаешь, что у "процессов" Эрланга общее с процессами оперсистемы только название — они гораздо легче чем даже потоки, не то что процессы, они обладают сетевой прозрачностью, и чисто практически процессы оперсистемы нельзя применять так, как применяются процессы Эрланга. В Эрланге для осуществления короткой транзакции является нормальной практикой создать десяток короткоживущих процессов — это чрезвычайно дешево (посмотрю я как у тебя будет аналогичная программа выглядеть на UNIX-процессах — читатель подумает, что автор наелся волшебных грибов, не иначе).
В unix-ах десятки короткоживущих процессов делаются на пуле предварительно запущенных процессов. IIRC, на таком принципе работают FastCGI процессы в Web-е.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Нити не смогут контролировать состояния других нитей. А вот состояния других процессов можно контролировать по их статусам завершения.
А если ( как это часто бывает нужно ) нам надо определить некий внутренний статус процесса ? Придется громоздить межпроцессный обмен, не так ли ?
E>Тысячи, десятки тысяч, сотни тысяч реактивных (т.е. реагирующих на внешние воздействия) легко решаются одной рабочей нитью и очередью заявок. А вот десятки тысяч проактивных процессов (т.е. самостоятельно инициирующих собственные операции, допустим по таймерам) доведут до деградации любую систему, хоть Erlang-овскую, хоть какую другую.
Совсем не так. Для Ерланговского процесса сообщение от таймера — точно такое же сообщение, как и любое другое — то есть они ВСЕГДА пассивны в полном смысле этого слова. И десятки, и сотни тысяч процессов могут жить в таком режиме совершенно безнаказанно.
E>Так что я бы не стал приводить количество процессов в качестве серьезного аргумента -- всегда есть альтернативные варианты, со своими плюсами и минусами.
Оно конечно — только сложность реализации отличается, мягко говоря.
G>>Но я говорил не об этом, а об обработке супервайзером НАБОРА состояний процессов. E>Очень возможно, что я чего-то не понял. Извините, если что.
Я имел в виду именно внутренние состояния процессов. Пример :
Пр.1 тянет издалека конфигурацию
Пр.2 производит переконфигурирование подсистемы
Пр.3 проверяет, действительно ли Пр. 1 тянет, или он застрял на таймаутах, и имеет ли смысл подсунуть в качестве рабочей закэшированную конфигурацию
Супервайзер разруливает сообщения от Пр. 1,2 и 3 в соответствии со своими правилами
Самый простой случай, но здесь именно набор состояний.
Здравствуйте, gandalfgrey, Вы писали:
G>Ну, в данном случае переменные M,F,D локальны в пределах двух строчек. Оттого я и сократил их до инициалов. В том примере для другой посылки используются более вразумительные имена, так как там они локальны в целых 6-и строчках. G>Подход к именованию у меня именно такой — где коротко, там и имена короткие.
Плохой подход. Ибо сегодня коротко, а завтра еще строк добавят. Да и читать это как?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Gaperton,
G>>В таком языке у нас реально стирается грань между статикой и динамикой. Красиво. Жаль я не студент и не аспирант — такой дипломище бы забабахал...
LCR>И получился бы боян. В DYLAN есть опциональная статическая типизация, так что для дилановца спор "ST vs DT" абсурден по определению. Для него типизация больше напоминает отрезок [0,1] — выбирай любую точку, наиболее подходящую для твоего приложения.
Так таки и боян . Впрочем, это только подтверждает, что идея стоящая .
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Gaperton, Вы писали:
G>>Вообще-то Эрланг существенно быстрее Ruby, Тикля и питона. Или скажем по другому — медленнее чем Руби язык найти сложно.
FR>Питон тоже существенно быстрее чем руби и тикль, вот сравнений с эрлангом что-то не видел.
Здравствуйте, gandalfgrey, Вы писали:
E>>Нити не смогут контролировать состояния других нитей. А вот состояния других процессов можно контролировать по их статусам завершения. G>А если ( как это часто бывает нужно ) нам надо определить некий внутренний статус процесса ? Придется громоздить межпроцессный обмен, не так ли ?
Да.
E>>Тысячи, десятки тысяч, сотни тысяч реактивных (т.е. реагирующих на внешние воздействия) легко решаются одной рабочей нитью и очередью заявок. А вот десятки тысяч проактивных процессов (т.е. самостоятельно инициирующих собственные операции, допустим по таймерам) доведут до деградации любую систему, хоть Erlang-овскую, хоть какую другую. G>Совсем не так. Для Ерланговского процесса сообщение от таймера — точно такое же сообщение, как и любое другое — то есть они ВСЕГДА пассивны в полном смысле этого слова. И десятки, и сотни тысяч процессов могут жить в таком режиме совершенно безнаказанно.
Безнаказанно и бесполезно. Представте себе, что 10K процессов должны обрабатывать таймерное сообщение раз в 10 секунд. В худшем случае это приведет к тому, что на момент времени t всем 10K процессам будет отправленно таймерное сообщение. За десять секунд эти 10K процессов обязательно должны обработать свои таймерные сообщения, поскольку в момент (t+10s) к ним в очередь станут еще 10K таймерных сообщений.
А обработка 1000 сообщений за одну секунду -- не такое уж простое дело, поскольку обработка может тянуть за собой некоторую серьезную работу, которую в 1ms не уместишь.
А если увеличить количество процессов с 10K до 100K (часто используемый аргумент в отношении Erlang-а, кстати). Или уменьшить тайм-аут с 10s до 5s?
Я ведь не спроста об этом говорю, поскольку имел неприятный опыт в организации обработки каждой транзакции в виде отдельного агента (практически полная аналогия с Erlang-овскими процессами). Проактивные схемы в этом случае оказываются слишком сложными в масштабировании и мониторинге. В отличии от схем с очередями сообщений на ограниченном числе агентов/процессов.
E>>Так что я бы не стал приводить количество процессов в качестве серьезного аргумента -- всегда есть альтернативные варианты, со своими плюсами и минусами. G>Оно конечно — только сложность реализации отличается, мягко говоря.
Сложность сильно зависит от требований. Например, если поставить в требование возможность визуального контроля за состоянием каждого из 10K процессов, то получается совсем доругая картина, чем в случае десяти процессов с очередями сообщений.
G>>>Но я говорил не об этом, а об обработке супервайзером НАБОРА состояний процессов. E>>Очень возможно, что я чего-то не понял. Извините, если что. G>Я имел в виду именно внутренние состояния процессов. Пример : G>Пр.1 тянет издалека конфигурацию G>Пр.2 производит переконфигурирование подсистемы G>Пр.3 проверяет, действительно ли Пр. 1 тянет, или он застрял на таймаутах, и имеет ли смысл подсунуть в качестве рабочей закэшированную конфигурацию G>Супервайзер разруливает сообщения от Пр. 1,2 и 3 в соответствии со своими правилами G>Самый простой случай, но здесь именно набор состояний.
Такое разделение на процессы и на взаимный контроль за ними напоминает пословицу о том, что когда в руках молоток, то все вокруг выглядит как гвозди. Например, какая выгода от решения задачи загрузки удаленной конфигурации именно таким образом?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>А обработка 1000 сообщений за одну секунду -- не такое уж простое дело, поскольку обработка может тянуть за собой некоторую серьезную работу, которую в 1ms не уместишь.
это ту не при чём. если процессора не хватает, то в любом случае ничего не получится. надо рассматривать затраты на переключение, на принятие этого сообщения — если они заметно меньше 1ms, то это и означает, что эрланг способен поддерживать 10 тысяч процессов
Здравствуйте, eao197, Вы писали:
G>>Разумеется, я прекрасно знаю (уверен, большинство присутствующих тоже), что процессы оперсистемы дают изоляцию, и про организацию процессов в UNIX, приходилось под UNIX писать. И мне кажется, ты знаешь, что у "процессов" Эрланга общее с процессами оперсистемы только название — они гораздо легче чем даже потоки, не то что процессы, они обладают сетевой прозрачностью, и чисто практически процессы оперсистемы нельзя применять так, как применяются процессы Эрланга. В Эрланге для осуществления короткой транзакции является нормальной практикой создать десяток короткоживущих процессов — это чрезвычайно дешево (посмотрю я как у тебя будет аналогичная программа выглядеть на UNIX-процессах — читатель подумает, что автор наелся волшебных грибов, не иначе).
E>В unix-ах десятки короткоживущих процессов делаются на пуле предварительно запущенных процессов. IIRC, на таком принципе работают FastCGI процессы в Web-е.
Угу, тока
1) Требуются не десятки, а десятки тысяч процессов.
2) В случае Эрланга это все вместе с шедулером живет в рамках одного физического процесса (качественно быстрее работает — меньше оверхэд на переключение), и алгоритм шедулинга процессов гонит по ним волну сообщений (UNIX-шедулер ничего не знает про сообщения). Детали работы рантайма LCR изложил в своем мегапосте в философии. Может быть, он приведет ссылку, чтобы стало понятно, в чем разница. На процессах ОС ты не добьешься даже близко такого поведения, как на процессах Эрланга. Они так же быстры, как user-lever threads, им требуется меньше памяти, по защите данных обладают свойствами потоков оперсистемы + более развитыми средствами чем в ОС, и обладают сетевой прозрачностью (все равно на какой машине "процесс" запущен) и шедулером реального времени, которыми процессы ОС не обладают. Посылка сообщений на порядок быстрее, чем скорость работы примитовов поточной синхронизации внутри процессов.
Здравствуйте, Gaperton, Вы писали:
G>2) В случае Эрланга это все вместе с шедулером живет в рамках одного физического процесса (качественно быстрее работает — меньше оверхэд на переключение), и алгоритм шедулинга процессов гонит по ним волну сообщений (UNIX-шедулер ничего не знает про сообщения). Детали работы рантайма LCR изложил в своем мегапосте в философии. Может быть, он приведет ссылку, чтобы стало понятно, в чем разница. На процессах ОС ты не добьешься даже близко такого поведения, как на процессах Эрланга. Они так же быстры, как user-lever threads, им требуется меньше памяти, по защите данных обладают свойствами потоков оперсистемы + более развитыми средствами чем в ОС, и обладают сетевой прозрачностью (все равно на какой машине "процесс" запущен) и шедулером реального времени, которыми процессы ОС не обладают. Посылка сообщений на порядок быстрее, чем скорость работы примитовов поточной синхронизации внутри процессов.
Вот насчёт выделенного в erlang-questions недавно длинная тема поднята была, что не совсем там всё ОК в шедулере, правда там больше заморочки характерные для жёсткого риалтайма вроде как. Вот здесь есть "кусок" от той темы. Поправить вроде собираются, но приоритет не очень высокий.
Здравствуйте, gandalfgrey, Вы писали:
K>>Президентов США никогда не убивали. K>>Только не говорите мне про Линкольна и JFK! G>Гарфилд, Мак-Кинли
+40
G>А что, Моно уже НОРМАЛЬНО и ПОЛНОЦЕННО работает хотя бы на десятке платформ?
Я не понимаю, что в данном случае подразумевается под словами "нормально" и "полноценно".
В чем сомнения заключаются? В полноте реализации стандарта ISO/IEC 23271 ? Или еще в чем?
Почему настоящая кроссплатформенность начинается с 10 платформ, а не с 9 или с 11-и?
Есть ли ISO стандарт для Erlang? Сколько существует реализаций?
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Я не понимаю, что в данном случае подразумевается под словами "нормально" и "полноценно".
Это означает, что написанное под Виндозный Дотнет будет работать под Моно на других платформах без переделки. И я говорю не о GUI
K>Есть ли ISO стандарт для Erlang? Сколько существует реализаций?
Про стандарт не скажу, ибо не знаю, а реализаций — под сотню, на самых экзотичных и даже эзотерических платформах
Здравствуйте, Klapaucius, Вы писали:
K>Я, кажется, понимаю, о чем Вы. Да, должен признать, что у меня, как участника этой дискуссии, два фатальных недостатка: K>1) Я не разрабатывал серьезную систему для предприятия по переработке урана на С++. K>2) Я не разрабатывал систему для паспортных столов на Erlang.
Вообще-то мы несколько не о том вели беседу. Эти два примера — всего лишь примеры, и не более того
K>Дело вот в чем: gandalfgrey сначала утверждает, что использовать "непереносимые средства"(sic!) согласно его опыту, вообще нельзя.
Не надо придавать моим словам некий абсолютный смысл ! Никто ведь не запрещает делать это под страхом расстрела на медленном огне, правда ? Другое дело, что использование непортабельных средств рано или поздно ( и скорее рано, чем поздно ) аукнется и икнется мучительным переползанием на что-то более другое. И я говорю "нельзя" именно в значении "плохо, не надо, чревато боком". Примерно как в выражении "пить стеклоочиститель нельзя !".
На самом деле переносимость ради переносимости не нужна и даже может оказаться вредной, потому что, и это очевидно, кроссплатформенность требует дополнительных затрат при разработке, даже если используется "переносимое средство".
Это не совсем так — доп. затраты ничтожны по сравнению с элиминацией рисков перехода на другую платформу. Ежели, конечно, с самого начала проектирования иметь в виду возможность оного перехода
K>P.S. Сразу говорю, что выполнить мертвую петлю на Lynx можно, а написать hard realtime систему на Mono нельзя, но к кроссплатформенности CLI это не имеет никакого отношения.
На Ерланге тоже нельзя добиться жесткого реалтайма. Разве что на под соответствующими ОС типа QNX или Vxworks
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Gaperton, Вы писали:
FR>>>Питон тоже существенно быстрее чем руби и тикль, вот сравнений с эрлангом что-то не видел.
G>>http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=hipe&lang2=python
FR>То есть эрланговский компилятор (HiPE) они уже научились запускать, а jit для питона (psyco) все еще не умеют, молодцы ребята
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Klapaucius, Вы писали:
K>>Я не понимаю, что в данном случае подразумевается под словами "нормально" и "полноценно". G>Это означает, что написанное под Виндозный Дотнет будет работать под Моно на других платформах без переделки. И я говорю не о GUI
В общем случае — нет. Кроссплатформенен CLI, а .Net — суперсет CLI, как впрочем, и Mono. Если Вы разрабатываете под .Net Вы можете использовать платформеннозависимую возможность. Если Вы попадете в пересечение .Net и Mono — тогда написанное будет работать (совместимость на уровне сборок) — не попадете — нет. Но это как и почти везде — платформеннозависимую фичу можно использовать и в C++ и в Java. Не понятно, зачем выделять GUI как особый случай — мало ли какая библиотека может быть привязана к платформе?
K>>Есть ли ISO стандарт для Erlang? Сколько существует реализаций? G>Про стандарт не скажу, ибо не знаю, а реализаций — под сотню, на самых экзотичных и даже эзотерических платформах
Я спрашивал не про количество поддерживаемых платформ, а про количество реализаций стандарта. Если есть стандарт (хотя-бы de facto) то это возможно. Есть реализация от Ericsson — а еще?
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>В общем случае — нет. Кроссплатформенен CLI, а .Net — суперсет CLI, как впрочем, и Mono. Если Вы разрабатываете под .Net Вы можете использовать платформеннозависимую возможность. Если Вы попадете в пересечение .Net и Mono — тогда написанное будет работать (совместимость на уровне сборок) — не попадете — нет. Но это как и почти везде — платформеннозависимую фичу можно использовать и в C++ и в Java. Не понятно, зачем выделять GUI как особый случай — мало ли какая библиотека может быть привязана к платформе?
Гуй является особым случаем слишком уж часто, чтобы можно было не отделять его от остального.
K>Я спрашивал не про количество поддерживаемых платформ, а про количество реализаций стандарта. Если есть стандарт (хотя-бы de facto) то это возможно. Есть реализация от Ericsson — а еще?
Open Erlang, Core Erlang, Hipe Project — основные ветки. Есть еще несколько кросс-компиляторов ( в Схему, С и пр. )
Здравствуйте, gandalfgrey, Вы писали:
G>Ну, в данном случае переменные M,F,D локальны в пределах двух строчек. Оттого я и сократил их до инициалов. В том примере для другой посылки используются более вразумительные имена, так как там они локальны в целых 6-и строчках. G>Подход к именованию у меня именно такой — где коротко, там и имена короткие.
Да какая разница локально или нет, если понять значения переменных можно тлько из документации? Это же усложняет чтение кода на порядок.
Если бы язык еще был статически типизированным и была интеграция с IDE, то можно было бы подробности в хинте подсмотреть. А для Эрланга — это развносильно шифрованию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Этим тестам у меня доверия нуль, я там уже много ошибок видел. Вот например сейчас бегло посмотрел на сравнение и sum-file на эрланге в 37 раз быстрее чем на питоне, это явный бред.
G>Кстати, Psyco вышел в продакшн? Не нем не страшно реальные системы пускать?
Вполне стабильный, правда авторы охладели к нему, так как занялись PyPy/
Здравствуйте, FR, Вы писали:
FR>Этим тестам у меня доверия нуль, я там уже много ошибок видел. Вот например сейчас бегло посмотрел на сравнение и sum-file на эрланге в 37 раз быстрее чем на питоне, это явный бред.
И к каким тестам у тебя есть доверие? Может быть, веб-сервер?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, FR, Вы писали:
FR>>Этим тестам у меня доверия нуль, я там уже много ошибок видел. Вот например сейчас бегло посмотрел на сравнение и sum-file на эрланге в 37 раз быстрее чем на питоне, это явный бред.
G>И к каким тестам у тебя есть доверие? Может быть, веб-сервер?
Слишком будет тяжело найти близкие по свойствам серверы.
Здравствуйте, eao197, Вы писали:
E>Вообще, по моему опыту, уверенность в том, что программа работает правильно в случае статики складывается из двух составляющих -- все скомпилировалось без ошибок и пройдены основные тесты. Но, поскольку на успешную компиляцию тратится изрядная доля времени, и существует иллюзия, что компилятор выловил значительную часть ошибок, то на тестах есть соблазн съэкономить. За счет чего часть серьезных функциональных ошибок остается в коде. Поэтому лично у меня в статике нет уверенности в том, что программа работает до тех пор, пока я не прогоню достаточное количество тестов. Но вот насобирать это достаточное количество тестов... Опять возвращаемся к соблазну экономии на тестах, раз компиляция прошла.
E>А вот в динамике вообще единственный способ узнать что-нибудь о программе -- это протестировать. Поэтому в динамике я гораздо чаще уверен в работоспособности программы, посколько эта уверенность лежит исключительно на результатах тестов. И нет даже мысли на тестах экономить.
Т.е. проблема не сугубо техническая, а заключается в человеческом факторе?
Здравствуйте, FR, Вы писали:
FR>>>Этим тестам у меня доверия нуль, я там уже много ошибок видел. Вот например сейчас бегло посмотрел на сравнение и sum-file на эрланге в 37 раз быстрее чем на питоне, это явный бред.
G>>И к каким тестам у тебя есть доверие? Может быть, веб-сервер?
FR>Слишком будет тяжело найти близкие по свойствам серверы.
Тогда не знаю. Предлагай микротест. Что-нибудь на работу с деревьями пойдет, на плавающую запятую, не целые числа (без массивов), на массивы (тут Эрланг запланировано сольет — хреновые у него массивы), на работу со списками, на разбор бинарных данных (порвем Питон как тузик грелку). На распределенку тесты предлагать не буду — сам понимаешь, не спортивно.
Здравствуйте, Gaperton, Вы писали:
G>Интересно получается.
G>forward_iterator = { next/0, data }
G>transform( End : forward_iterator, End : forward_iterator, _, _ ) -> ok; G>transform( Begin : forward_iterator, End : forward_iterator, F/1, Res : forward_iterator ) -> G> Res.data <- F( Begin.data ), G> transform( Begin.next(), End, F, Res.next() ).
G>Прикольно. Можно регулировать подробность спецификаций типов как угодно — совмещаем это с выводом типов, и компилятор может вылавливать противоречия. Разница со статической типизацией только в том, что мы не обязаны выводить полную информацию о типах — где не вывелось — там динамика. В таком языке у нас реально стирается грань между статикой и динамикой. Красиво. Жаль я не студент и не аспирант — такой дипломище бы забабахал...
G>log_info( Container : { begin, end }, File : { position } ) -> G> transfrorm( Container.begin, Container.end, fun( X : { info } ) -> X.info end, File.position )
VB? Конечно не в точности так, но типизация по выбору разработчика.
Здравствуйте, eao197, Вы писали:
E>Что же касается Mono, то вопрос не столько в том, считать ли его существующим или подсчитывать количество реализованных в нем фич из MS .Net. Это другой вопрос. Основной же вопрос в том, если ли у вас уверенность в том, что сейчас Mono является достаточно качественной и стабильной реализацией CLI для того, чтобы ставить на него собственную зарплату и успешность собственных проектов?
Его (Моно) качество ничем не хуже нежели скажем Питона, Руби или GCC. Отдельные, редкие глюки несомненно встречаются, но пользоваться им можно без проблем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>И к каким тестам у тебя есть доверие? Может быть, веб-сервер?
Дык в чем проблема написать свои и выствить их на форум для рецензирования?
Вот альфаблэнд на Питоне уже делали. Получилось редкостно хреново. Попробуй на Эрланге. Если он отстанет от С++ не более чем в два раза, то можно будет произвоидтельности рассуждать. Но лично мне как-то в это совсем не верится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вот альфаблэнд на Питоне уже делали. Получилось редкостно хреново. Попробуй на Эрланге. Если он отстанет от С++ не более чем в два раза, то можно будет произвоидтельности рассуждать. Но лично мне как-то в это совсем не верится.
А где можно на альфа бленд питоновский посмотреть?
Хотя это конечно дурдом на нем вообще такое делать
G>Тогда не знаю. Предлагай микротест. Что-нибудь на работу с деревьями пойдет, на плавающую запятую, не целые числа (без массивов), на массивы (тут Эрланг запланировано сольет — хреновые у него массивы), на работу со списками, на разбор бинарных данных (порвем Питон как тузик грелку). На распределенку тесты предлагать не буду — сам понимаешь, не спортивно.
У меня не пузомерное настроение
Хотя если найдешь что простенькое на питон могу переписать.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Кстати, Psyco вышел в продакшн? Не нем не страшно реальные системы пускать?
VD>Как показал альфаблэн он Питону как мертвому припарка. Один фиг Питон в глубокой заднице на сложных вычислительных тестах.
От задач зависит, с задачами хорошо ложащимися на библиотеки типа NumPy скорость вполне приличная.
Здравствуйте, VladD2, Вы писали:
G>>И к каким тестам у тебя есть доверие? Может быть, веб-сервер?
VD>Дык в чем проблема написать свои и выствить их на форум для рецензирования?
VD>Вот альфаблэнд на Питоне уже делали. Получилось редкостно хреново. Попробуй на Эрланге. Если он отстанет от С++ не более чем в два раза, то можно будет произвоидтельности рассуждать. Но лично мне как-то в это совсем не верится.
Работа с массивами — слабое место Эрланга. На эрланге это будет очень медленно, так как в той задаче вместо массива придется использовать словарь процесса (хэш-таблицу).
Здравствуйте, VladD2, Вы писали:
E>>Что же касается Mono, то вопрос не столько в том, считать ли его существующим или подсчитывать количество реализованных в нем фич из MS .Net. Это другой вопрос. Основной же вопрос в том, если ли у вас уверенность в том, что сейчас Mono является достаточно качественной и стабильной реализацией CLI для того, чтобы ставить на него собственную зарплату и успешность собственных проектов?
VD>Его (Моно) качество ничем не хуже нежели скажем Питона, Руби или GCC. Отдельные, редкие глюки несомненно встречаются, но пользоваться им можно без проблем.
На основании чего сделан такой вывод?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
K>>Дело вот в чем: gandalfgrey сначала утверждает, что использовать "непереносимые средства"(sic!) согласно его опыту, вообще нельзя. G>Не надо придавать моим словам некий абсолютный смысл ! Никто ведь не запрещает делать это под страхом расстрела на медленном огне, правда ? Другое дело, что использование непортабельных средств рано или поздно ( и скорее рано, чем поздно ) аукнется и икнется мучительным переползанием на что-то более другое. И я говорю "нельзя" именно в значении "плохо, не надо, чревато боком". Примерно как в выражении "пить стеклоочиститель нельзя !".
Вот только от поглощения стеклоотчистителя нельзя получить никаких бенефитов, а от более тесного взаимодействия с одной платформой в ущерб кроссплатформенности — можно. Поэтому все далеко не так однозначно.
K>>На самом деле переносимость ради переносимости не нужна и даже может оказаться вредной, потому что, и это очевидно, кроссплатформенность требует дополнительных затрат при разработке, даже если используется "переносимое средство". G>Это не совсем так — доп. затраты ничтожны по сравнению с элиминацией рисков перехода на другую платформу. Ежели, конечно, с самого начала проектирования иметь в виду возможность оного перехода
И тем не менее это вопрос дискуссионный.
G>На Ерланге тоже нельзя добиться жесткого реалтайма. Разве что на под соответствующими ОС типа QNX или Vxworks
Это понятно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, eao197, Вы писали:
VD>>Его (Моно) качество ничем не хуже нежели скажем Питона, Руби или GCC. Отдельные, редкие глюки несомненно встречаются, но пользоваться им можно без проблем.
E>На основании чего сделан такой вывод?
А на основании чего может быть сделан обратный вывод? У Вас есть данные о бесспорном превосходстве Ruby над Mono в этом аспекте? Это было бы интересно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, aka50, Вы писали:
A>(**1) как выяснилось в erlang признаки статики как минимум на уровне модулей, т.е. это уже как бы и не совсем динамика
Эрланг — это совершеннейшая динамика, побольше, чем у некоторых. По степени динамичности — это почти Лисп. Я могу например делать так:
dispatch_message( { MsgGroup, MsgType, Value } ) -> MsgGroup:MsgType( Value ).
Не каждый динамический язык на такое способен.
На уровне модульных интерфейсов тебе любой динамический язык по рукам даст без ущерба для динамичности — модуль это не класс. Более того, в Эрланге есть Dyalizer, который статически ловит ошибки типизации выводя типы из контекста. И при этом — это динамика. Просто твои представления о динамике, гхм, устарели, чтоли. Ну, примерно как раньше американцы были уверены, что у русских медведи по улицам ходят.
Здравствуйте, Klapaucius, Вы писали:
K>Вот только от поглощения стеклоотчистителя нельзя получить никаких бенефитов,
Как нельзя ? А бычий кайф ?! Для кого-то он очень даже приоритетен, пусть даже в ущерб здоровью.
а от более тесного взаимодействия с одной платформой в ущерб кроссплатформенности — можно. Поэтому все далеко не так однозначно.
А куда потом бежать, когда платформа кончится естественной смертью, перестанет быть поддерживаемой или просто коварно мутирует во что-нибудь неузнаваемое ?
FR>>>>Этим тестам у меня доверия нуль, я там уже много ошибок видел. Вот например сейчас бегло посмотрел на сравнение и sum-file на эрланге в 37 раз быстрее чем на питоне, это явный бред.
почему же? если на одном программа скомпилировалась и использует одну машинную инструкцию на каждый элемент, а на другом — интерепретируется или хотя бы динамически диспетчеризуется. скажем, сложение массивов double на ghc работает раз в 10-20 медленней gcc'шного просто потому, что там тупой кодегенератор
G>>>И к каким тестам у тебя есть доверие? Может быть, веб-сервер?
FR>>Слишком будет тяжело найти близкие по свойствам серверы.
G>Тогда не знаю. Предлагай микротест.
в shootout есть два или три теста, зависящих именно от качества компиляции. sum-file кстати один из них, хотя имхо для C он банально упирается в скорость памяти. в отличие в 37 раз на никзоуровневом тесте нет ничего сверхъестественного. скажем, Ruby с кго интерпретацией в 1000 раз медленнее С в подобных тестах. ghc при его строгой типизации и какой-никакой оптимизирующей компиляции медленней в 3-10 раз
Здравствуйте, eao197, Вы писали:
E>>>Сотни процессов -- это типа, сильный аргумент должен быть? Ну так даже на обычном select-е в C/C++ делают обработку сотен сокетов и ничего, не так уж и сложно все получается. G>>Ну, когда речь пойдет о тысячах и десятках тысяч процессов, это станет сильным аргументом 8)).
E>Тысячи, десятки тысяч, сотни тысяч реактивных (т.е. реагирующих на внешние воздействия) легко решаются одной рабочей нитью и очередью заявок.
Не легко. Ты затрахаешься обеспечивать хорошую реактивность системы в этом случае, если часть запросов у тебя длительные. Во-вторых, при возникновении ошибки при обработке запроса ты не сможешь гарантировать, что это не повлияет на выполнение остальных — а эрланг-система дает 100% гарантию этого.
E>А вот десятки тысяч проактивных процессов (т.е. самостоятельно инициирующих собственные операции, допустим по таймерам) доведут до деградации любую систему, хоть Erlang-овскую, хоть какую другую.
Не доведут, и не любую.
Особенность Эрланговского рантайма в том, что не происходит деградации производительности при пиковой нагрузке — пропускная способность системы остается постоянной. Это требование телеком приложений.
E>Так что я бы не стал приводить количество процессов в качестве серьезного аргумента -- всегда есть альтернативные варианты, со своими плюсами и минусами.
Возможность не думать о количестве процессов — это объективно серьезный плюс при дизайне системы. Сравнимый с преимуществом наличия сборки мусора — просто класс проблем изчезает, вроде заботы об ownership policy. Так и здесь — у меня не болит голова о пулах процессов, организации очередей сообщений, и схемах синхронизации.
Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
G>>Но я говорил не об этом, а об обработке супервайзером НАБОРА состояний процессов.
E>Очень возможно, что я чего-то не понял. Извините, если что. E>Может быть, еще представиться возможность пообщаться.
Эрланг придумали не идиоты, а чрезвычайно опытные инженеры, и не из любви к исскуству, а для того, чтобы легче выполнять работу.
Так что если ты чего-то не понял — то высока вероятность, что ты просто чего-то не понял. Хочешь разобраться — лучше не спорь, а читай диссертацию Джо. http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
В хаскеллевском компилере GHC какая-то неважнецкая работа с плавающей арифметикой двойной точности (или я пока не умею её готовить)...
Если этот тест переписать прямо:
pythags :: Double -> Int
pythags mp = pyth 2 0
where
pyth c i | c > mp = i
| otherwise = pyth (c+1) (i + (pyth' 1 0))
where
pyth' b j | b == c = j
| otherwise = let a = sqrt (c*c - b*b)
in if a == fromIntegral ((truncate a)::Int)
then pyth' (b+1) (j+1)
else pyth' (b+1) j
или так:
pythags :: Double -> Int
pythags mp = length [ () | c <- [1..mp],
b <- [1..c-1],
let a = sqrt (c*c - b*b),
a == fromIntegral ((truncate a)::Int) ]
то на Хаскелле расчёт будет примерно раз в 40 медленнее, чем на VisualC, или раз в 25 медленнее, чем на GCC:
int pyphags(double mp)
{
double c, b;
int i = 0;
double a;
for (c = 2; c <= mp; c++)
{
for (b = 1; b < c; b++)
{
a = fastDoubleSqrt(c*c - b*b);
if (trunc(a) == a) i++;
}
}
return i;
}
Но если переписать тест на целые числа:
pythags :: Int -> Int
pythags mp = length [ () | c <- [1..mp],
b <- [1..c-1],
let s = c*c - b*b
a = primIntSqrt s,
s == a*a ]
то разница между GHC и GCC будет меньше, чем между GCC и VisualC...
int pyphags(int mp)
{
int a, b, c, s, i=0;
for (c = 2; c <= mp; c++)
{
for (b = 1; b < c; b++)
{
a = c*c - b*b;
s = fastIntSqrt(a);
if (s*s == a) i++;
}
}
return i;
}
Прим. В GCC, поставляющемся с GHC 6.6 (Win32), тормозная функция double sqrt(double) из math.h, так что для GCC fastDoubleSqrt и fastIntSqrt я определил так:
Здравствуйте, Gaperton, Вы писали:
G>Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
Interestingly, throughput of Scala actors remains basically constant (at about 30,000 tokens
per second), regardless of the number of processes. In contrast, throughput of pure Java threads
constantly decreases as the number of processes increases. The VM is unable to create
a ring with 5500 threads as it runs out of heap memory. In contrast, using Scala actors
the ring can be operated with as many as 600,000 processes (since every queue is also
an actor this amounts to 1,200,000 simultaneously active actors.)
Вот собственно интересно было бы замутить бенчмарк... Интересность именно в том, что в случае scala — это jvm, но удобство использования актеров как в erlang (т.е. и link и сообщения и даже синтаксис в наличии).
Вот эта реализация сервера подойдет для пиписькомера (если аналогичную замутить на scala)?
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
A>К стати интересно... Судя по заявляениям Philipp Haller и Martin Odersky http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf A>
A>Interestingly, throughput of Scala actors remains basically constant (at about 30,000 tokens
A>per second), regardless of the number of processes. In contrast, throughput of pure Java threads
A>constantly decreases as the number of processes increases. The VM is unable to create
A>a ring with 5500 threads as it runs out of heap memory. In contrast, using Scala actors
A>the ring can be operated with as many as 600,000 processes (since every queue is also
A>an actor this amounts to 1,200,000 simultaneously active actors.)
A>Вот собственно интересно было бы замутить бенчмарк... Интересность именно в том, что в случае scala — это jvm, но удобство использования актеров как в erlang (т.е. и link и сообщения и даже синтаксис в наличии). A>Вот эта реализация сервера подойдет для пиписькомера (если аналогичную замутить на scala)?
Почему нет, можно взять и эту. Кстати, эти скаловские акторы прерываются шедулером, или он должен дождаться, когда они вернут управление?
Здравствуйте, Gaperton, Вы писали:
E>>Тысячи, десятки тысяч, сотни тысяч реактивных (т.е. реагирующих на внешние воздействия) легко решаются одной рабочей нитью и очередью заявок. G>Не легко. Ты затрахаешься обеспечивать хорошую реактивность системы в этом случае, если часть запросов у тебя длительные. Во-вторых, при возникновении ошибки при обработке запроса ты не сможешь гарантировать, что это не повлияет на выполнение остальных — а эрланг-система дает 100% гарантию этого.
Если часть запросов длительная, то и Erlang-овская система затрахается. Сильно сомневаюсь, что при наличии длительных операций ввода-вывода Erlang будет диспетчировать процессы лучше ОС.
Даже в случае отсутствия работы с переферией, когда грузится только процессор, переключение контекстов на 10K вычислительных задач будет означать, что каждый процесс будет получать порядка 10ms каждые пару минут. Реактивность здесь классная, как будто 10K черепах ползут.
G>Особенность Эрланговского рантайма в том, что не происходит деградации производительности при пиковой нагрузке — пропускная способность системы остается постоянной. Это требование телеком приложений. G>
еще бы было объяснение что это все означает.
G>Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
А ты?
Пока ты только ссылаешься на чужой опыт выдавая Erlang за серебрянную пулю, но, как я понимаю, сам не нем серьезных систем не сделав.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Кстати, эти скаловские акторы прерываются шедулером, или он должен дождаться, когда они вернут управление?
Нет по несольким причинам:
1. jvm не продставляет возможностей для управление стеком (а следовательно честные continutation реализовать очень проблематично)
2. scala все таки не чисто функциональный язык, значит прерывать выполнение грубым suspend нельзя
По этому идея такая: актер, ожидающий сообщения — суть замыкание. Когда приходит сообщение, это замыкание (внутри которого паттерн-матчинг конструкция) вызывается в контексте посылающего потока. Если актер блокируется в receive, то вместо этого бросается исключение раскручивающее стек. Если актер завершается, то происходит просто возврат как из функции. Посылающим может быть либо шелдулер в случае асинхронного вызова (и тогда это будет worker thread), либо другой поток — в случае синхронной посылки сообщения. При этом, если обнаруживается, что все рабочие потоки у шелдулера заняты, он может родить еще один поток. По этому максимум актеров, которые используют длительные операции может быть ~5.5k, при которотких операциях их может быть на прядки больше.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, aka50, Вы писали:
A>>Вот собственно интересно было бы замутить бенчмарк...
E>Причем, если помниться, мой ноутбук был по производительности практически такой же, как упоминался в работе Одерски. Так что 30K токенов в секунду -- это фигня А после того Remark подсказал еще несколько оптимизаций, скорость еще процентов на 7-8 выросла.
Подумал... знаешь, это все таки не совсем честный бенчмарк. Дело в том, что основное условие для работы актеров скалы — это короткое время выполнения... а вот 600к заблокированных в io например актеров скала (точнее jvm) уже не вытянет, т.к. максимум потоков — 5500. Т.е. блокирующие операции придется отдавать другим актерам (например пулу diskIoActor-ов) которые будут уже выполнять реальную блокирующую операцию. Т.е. все таки придется организовывать пулы, чего в случае с ерлангом делать не нужно...
G>Работа с массивами — слабое место Эрланга. На эрланге это будет очень медленно, так как в той задаче вместо массива придется использовать словарь процесса (хэш-таблицу).
Ну, дык та задача — это честная числодробилка. Понятно, что более высокоуровневые вещи будут на динамике выглядеть лучше, так как многое может лечь на библиотеки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>От задач зависит, с задачами хорошо ложащимися на библиотеки типа NumPy скорость вполне приличная.
Ежу понятно. Но это уже не совсем честное сравнение. Это уже пенисометрия библиотек, или, что еще хуже, сравнение С с С но замаскированный под Питор (обман, значичь).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>От задач зависит, с задачами хорошо ложащимися на библиотеки типа NumPy скорость вполне приличная.
VD>Ежу понятно. Но это уже не совсем честное сравнение. Это уже пенисометрия библиотек, или, что еще хуже, сравнение С с С но замаскированный под Питор (обман, значичь).
Тебе шашечки или ехать?
Это нормальное использование для glue языка.
Здравствуйте, eao197, Вы писали:
A>>Вот собственно интересно было бы замутить бенчмарк...
E>Я такой делал E>Причем, если помниться, мой ноутбук был по производительности практически такой же, как упоминался в работе Одерски. Так что 30K токенов в секунду -- это фигня А после того Remark подсказал еще несколько оптимизаций, скорость еще процентов на 7-8 выросла.
E>Только вот 600K агентов на своей машине я запустить не могу, после 200K агентов 512Mb RAM оказывается мало.
30К токенов в секунду — то вообще ерунда. Мы делали тест с кольцом сумматоров на Эрланге. По результатам измерений на настолькой машине Эрланг система прокачивает около 600К сообщений в секунду.
Здравствуйте, Gaperton, Вы писали:
G>30К токенов в секунду — то вообще ерунда. Мы делали тест с кольцом сумматоров на Эрланге. По результатам измерений на настолькой машине Эрланг система прокачивает около 600К сообщений в секунду.
Настольная система — понятие растяжимое, например у меня на столе Core2Duo с 4GB на борту . По этому и скалу смотреть надо на той же машине с аналогичным алгоритмом, да и в статье довольно древний пень использовался...
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Кстати, эти скаловские акторы прерываются шедулером, или он должен дождаться, когда они вернут управление? A>Нет по несольким причинам: A>1. jvm не продставляет возможностей для управление стеком (а следовательно честные continutation реализовать очень проблематично) A>2. scala все таки не чисто функциональный язык, значит прерывать выполнение грубым suspend нельзя
A>По этому идея такая: актер, ожидающий сообщения — суть замыкание. Когда приходит сообщение, это замыкание (внутри которого паттерн-матчинг конструкция) вызывается в контексте посылающего потока. Если актер блокируется в receive, то вместо этого бросается исключение раскручивающее стек. Если актер завершается, то происходит просто возврат как из функции. Посылающим может быть либо шелдулер в случае асинхронного вызова (и тогда это будет worker thread), либо другой поток — в случае синхронной посылки сообщения. При этом, если обнаруживается, что все рабочие потоки у шелдулера заняты, он может родить еще один поток. По этому максимум актеров, которые используют длительные операции может быть ~5.5k, при которотких операциях их может быть на прядки больше.
Так я и думал. Получается, что эрланговские процессы лучше и удобнее. У них честная вытесняющая многозадачность.
Здравствуйте, eao197, Вы писали:
E>>>Тысячи, десятки тысяч, сотни тысяч реактивных (т.е. реагирующих на внешние воздействия) легко решаются одной рабочей нитью и очередью заявок. G>>Не легко. Ты затрахаешься обеспечивать хорошую реактивность системы в этом случае, если часть запросов у тебя длительные. Во-вторых, при возникновении ошибки при обработке запроса ты не сможешь гарантировать, что это не повлияет на выполнение остальных — а эрланг-система дает 100% гарантию этого.
E>Если часть запросов длительная, то и Erlang-овская система затрахается. Сильно сомневаюсь, что при наличии длительных операций ввода-вывода Erlang будет диспетчировать процессы лучше ОС.
Эрланг-система диспетчеризует свои процессы лучше ОС. И это наглядный факт, наблюдаемый по поведению программ — можешь сомневаться, можешь нет.
E>Даже в случае отсутствия работы с переферией, когда грузится только процессор, переключение контекстов на 10K вычислительных задач будет означать, что каждый процесс будет получать порядка 10ms каждые пару минут. Реактивность здесь классная, как будто 10K черепах ползут.
Это при условии, что все 10К процессов постоянно заняты научными вычислениями — а в реальных приложениях процессы заняты как раз вводом-выводом и общением друг с другом. Эрланг даст хорошую реактивность для 9000 коротких процессов в случае, если в системе есть 1000 длительных. Вот это — факт.
G>>Особенность Эрланговского рантайма в том, что не происходит деградации производительности при пиковой нагрузке — пропускная способность системы остается постоянной. Это требование телеком приложений. G>>
E>еще бы было объяснение что это все означает. http://www.sics.se/~joe/apachevsyaws.html
G>>Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
E>А ты?
А я в CQG возглавлял группу разработки сервера, который по требованиям должен иметь хорошую реактивность и soft-realtime поведение. Собственно, CQG — это софт-рилтайм система, чем меньше время отклика и задержка прохождения котировок, тем меньше денег теряет клиент. Это добро написано на С++, и я не понаслышке знаю, как тяжело на практике в большом приложении обеспечить хорошую реактивность и отсутствие деградации производительности при нагрузке. К слову, я являюсь автором подсистемы "легких потоков", основанных на файберах со своим специализированным шедулером, которая сейчас применяется в клиенте и сервере CQG — разработаной чтобы побороть проблемы с реактивностью сервера. И могу сказать как врач — это, коллега, охрененно не просто — совсем не так, как ты тут с легкостью пишешь о пулах процессов, тредов, и очередях сообщений. Это только кажется, что все просто, пока сам не делал.
E>Пока ты только ссылаешься на чужой опыт выдавая Erlang за серебрянную пулю, но, как я понимаю, сам не нем серьезных систем не сделав.
Я сказал ровно то, что сказал. Эрланг в реальных приложениях, которые можно скачать и потестировать, дает хорошую реактивность и пропускная способность системы не падает под нагрузкой, и в этом он превосходит все существующие платформы, добиться на которых подобного можно только не по децки затрахавшись. Я не считаю Эрланг серебряной пулей — за серебряными пулями обращайся к Владу и последователям культа Немерле. У Эрланга есть минусы, есть плюсы. Я тебе пока рассказываю о плюсах.
Что до опыта — на Эрланге у нас построена система моделирования. Это достаточно серьезная система. Только тебе это все равно — вон gandalfgray серьезную промышленную систему забабахал — не чета нашей, и к его словам ты в равной степени не прислушиваешься. На опыт Джо Армстронга (который сделал несколько лучших в индустрии по характиристикам систем, превосходящих по сложности все мои проекты и проекты gandalfgray), Пера Берквиста, Ульфа Вигера, и команды Эрикссона занимавшейся AXD301, я тоже ссылаться не считаю зазорным. Опыт, который проанализирован и по которому написаны отчеты — это не форумное бла-бла-бла, понты, и детские замеры.
Здравствуйте, Gaperton, Вы писали:
E>>Если часть запросов длительная, то и Erlang-овская система затрахается. Сильно сомневаюсь, что при наличии длительных операций ввода-вывода Erlang будет диспетчировать процессы лучше ОС.
G>Эрланг-система диспетчеризует свои процессы лучше ОС. И это наглядный факт, наблюдаемый по поведению программ — можешь сомневаться, можешь нет.
Не сомневаюсь, что в случае отсуствия операций ввода-вывода так и есть. Я говорил как раз о наличии таких операций.
G>>>Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
E>>А ты? G>А я в CQG возглавлял группу разработки сервера, который по требованиям должен иметь хорошую реактивность и soft-realtime поведение. Собственно, CQG — это софт-рилтайм система, чем меньше время отклика и задержка прохождения котировок, тем меньше денег теряет клиент. Это добро написано на С++, и я не понаслышке знаю, как тяжело на практике в большом приложении обеспечить хорошую реактивность и отсутствие деградации производительности при нагрузке. К слову, я являюсь автором подсистемы "легких потоков", основанных на файберах со своим специализированным шедулером, которая сейчас применяется в клиенте и сервере CQG — разработаной чтобы побороть проблемы с реактивностью сервера. И могу сказать как врач — это, коллега, охрененно не просто — совсем не так, как ты тут с легкостью пишешь о пулах процессов, тредов, и очередях сообщений. Это только кажется, что все просто, пока сам не делал.
Мы, конечно, не CQG (кстати, может по московским меркам CQG и крутая контора, но у нас про нее никто не знает).
Но у нас так же работает в софт-реалтайме система, написанная на C++ и обеспечивающая нормальную реактивность при больших нагрузках. Так что я говорю о том, что сам делал. И десятки тысяч агентов (по аналогии с Erlang-овскими процессами), о которых я говорил, существовали в реальных приложениях. И переход от множества агентов к нескольким агентам так же был вызван опытом реальной эксплуатации со своими тебованиями не только к реактивности, но и к сопровождаемости и обозримости (в том числе и к мониторингу).
G>У Эрланга есть минусы, есть плюсы. Я тебе пока рассказываю о плюсах.
Кстати, мне показалось, что Армстронг несколько по другому оценивает плюсы Erlang-а, нежели ты.
Но я его диссер пока не дочитал, так что спорить пока не буду.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
E>>>Если часть запросов длительная, то и Erlang-овская система затрахается. Сильно сомневаюсь, что при наличии длительных операций ввода-вывода Erlang будет диспетчировать процессы лучше ОС.
G>>Эрланг-система диспетчеризует свои процессы лучше ОС. И это наглядный факт, наблюдаемый по поведению программ — можешь сомневаться, можешь нет.
E>Не сомневаюсь, что в случае отсуствия операций ввода-вывода так и есть. Я говорил как раз о наличии таких операций.
Как раз при вводе-выводе это так. Если ввода-вывода нет, то процессы шедулятся крайне тупо — по кругу раздаюшь кванты и все — это лучшая схема. Ты график пропускной способности веб-сервера вообще смотрел, что я приводил, нет? Видел, как от количества одновременных соединений throughput зависит? В веб-сервере каждый процесс занимается ввобом-выводом.
E>Мы, конечно, не CQG (кстати, может по московским меркам CQG и крутая контора, но у нас про нее никто не знает). E>Но у нас так же работает в софт-реалтайме система, написанная на C++ и обеспечивающая нормальную реактивность при больших нагрузках. Так что я говорю о том, что сам делал. И десятки тысяч агентов (по аналогии с Erlang-овскими процессами), о которых я говорил, существовали в реальных приложениях. И переход от множества агентов к нескольким агентам так же был вызван опытом реальной эксплуатации со своими тебованиями не только к реактивности, но и к сопровождаемости и обозримости (в том числе и к мониторингу).
Этот переход возможен только в случае, если у тебя время обработки каждого запроса предсказуемо и постоянно. Это простой случай, тут думать практически не надо. Только жизнь сложная штука, там далеко не всегда бывает так. Например, серверу CQG приходится иметь дело с запросами, время выполнения которых непредсказуемо, и колеблется в широком биапазоне от очень быстрых до крайне медленных. Одновременно серверу приходится отвечать на множество запросов с моментальной реакцией, и прокачивать через себя кучу обновлений по открытым соединениям в реальном времени с минимальной задержкой. Периодически бывают ситуации пиковой нагрузки (ферма серверов балансирует нагрузку или отрабатывает сбой, перекидывая пользователей с сервера на сервер), при которой все должно работать так же, как обычно.
С агентами эта задача практически не решаема за разумные сроки с разумным качеством (сдохнешь на рефакторинге — бить последовательные процессы на несколько "агентов", и вводить систему веревочек, чтобы обеспечить приоритеты) — параллельных активностей слишком много, именно для решения этих проблем и была введена легкая многозадачность с собственным планировщиком. Имея такой рантайм, каким обладает Эрланг, этих проблем попросту бы не было. Воспроизвести свойства этого рантайма на С++ невозможно даже со своими потоками — файберы (в отличии от эрланговских процессов) жрут адресное пространство со страшной силой, иметь их в системе десятки тысяч сложно, и практически невозможно, плюс — в файберах приходится помечать точки возможного прерывания шедулером руками. А агенты — вообще отстой, их применение усложняет код и время разработки в два раза по нашим метрикам (за счет того, что длительная обработка разворачивается из последовательного кода в конечный автомат, и программа становится асинхронной). В простом случае ты конечно того не заметишь, и, возможно, не поймешь, о каких проблемах я говорю, но вообще — вот так бывает, дружище.
Вообще непонятно, зачем ты споришь с очевидным. Так сложно пережить факт, что Эрланговский рантайм содержит лучшую на текущий момент поддержку параллельного программирования? Извини, люди специально старались, чтоб было именно так, что тут удивляться. Старались они потому, что считали, что это очень важно. И не идиоты люди-то — заслуженные инженеры, с опытом, понимают, что делают. Можно допустить, что тут есть какая-то полезная фишка? Или все отстой, кроме пчел?
G>>У Эрланга есть минусы, есть плюсы. Я тебе пока рассказываю о плюсах.
E>Кстати, мне показалось, что Армстронг несколько по другому оценивает плюсы Erlang-а, нежели ты.
Моя оценка плюсов и минусов не отличается от мнения эрланговского мэйллиста, могу тебя заверить. Но если тебе что-то показалось — так ты скажи, что именно. Хочешь — перенесем дискуссию в эрланг мэйллист, и ты увидишь мнение Джо.
Армстронг делает упор на Concurrency Oriented Programming (ему как Степанову с STL, кажется, что он новую парадигму изобрел), и надежность в условии присутствия программных и аппаратных ошибок. При этом, мотивация разработки Эрланга, которую я тебе привел в посте про преимущества в телекоме, ты можешь прочесть конспективно в FAQ по языку (это элементарщина — не надо за этим Джо теребить) и материалах по истории разработки Эрланга.
Здравствуйте, VladD2, Вы писали:
G>>Работа с массивами — слабое место Эрланга. На эрланге это будет очень медленно, так как в той задаче вместо массива придется использовать словарь процесса (хэш-таблицу).
VD>Ну, дык та задача — это честная числодробилка. Понятно, что более высокоуровневые вещи будут на динамике выглядеть лучше, так как многое может лечь на библиотеки.
В Эрланге просто нет массивов нормальных, и все . Плавающую запятую HIPE компилирует нормально, рекурсия там тоже быстра. Что-нить без того, чтобы лопатить вперехлест здоровый массив, как в альфабленде — это будет совсем другое дело. Хоть перемножение матриц. Здесь можно будет обогнать Питон.
Но лучше что-нить нейтральное — работа с какими-нибудь деревьями. Это достаточно низкоуровнево, библиотеки не нужны — все по честному. Можно в эти деревья плавающую запятую добавить и целые числа.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>30К токенов в секунду — то вообще ерунда. Мы делали тест с кольцом сумматоров на Эрланге. По результатам измерений на настолькой машине Эрланг система прокачивает около 600К сообщений в секунду.
A>Настольная система — понятие растяжимое, например у меня на столе Core2Duo с 4GB на борту . По этому и скалу смотреть надо на той же машине с аналогичным алгоритмом, да и в статье довольно древний пень использовался...
Одно ядро, П4, 3 гигагерца. Памяти по моему гиг — она не узкое место. Тест был — кольцо сумматоров (следующий получает мессаги от двух предыдущих).
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, aka50, Вы писали:
Я руби не защищаю, я отвечал на вопрос — почему mono — недоплатформа. Возможно надо было не тебе отвечать, а на первоначальный пост.
K>Собственно дальше можно и не продолжать. Весь этот спор начался с того, что утверждалось "нет" без всяких оговорок.
Ну я и ответил: нет обезьянам. Что ruby only — я тоже с этим не согласен , мне больше jvm + scala симпатичнее и erlang.
A>>Но A>>- фреймворк, который по сути сплошной реверсинжиниринг K>Это безответственное утверждение. Есть стандарт.
CLI — да, но это далеко не все, что есть в CLR...
The .Net Framework Class Library is a superset of the libraries defined in the CLI (including the BCL); it includes those libraries as well as several that are not standardised, such as System.Windows.Forms and System.Web.
A>>— возможные проблема с патентами K>Фактически эта фраза семантически эквивалентна преведенной выше "теоретически чисты в плане патентов" — но звучит, конечно, гораздо страшнее. Да, патентный троллинг вообще серьезная угроза, но превосходство Ruby в этом плане совершенно неочевидно.
Не эквивалентны. mono _уже_ нарушает патенты реимплементируя (см ниже цитату из FAQ) те-же winforms, в ruby — надо еще доказать... К тому же это принциально разное нарушение: в mono — прямое копирование, в ruby — возможное нарушение каких-то алгоритмов.
For people who need full compatibility with the Windows platform, Mono's strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandalfgrey, Вы писали:
G>>Ну, в данном случае переменные M,F,D локальны в пределах двух строчек. Оттого я и сократил их до инициалов. В том примере для другой посылки используются более вразумительные имена, так как там они локальны в целых 6-и строчках. G>>Подход к именованию у меня именно такой — где коротко, там и имена короткие. WH>Плохой подход. Ибо сегодня коротко, а завтра еще строк добавят.
В Эрланге сокращения M и F применяются для обозначения модуля и функции, так же традиционно, как i j k применяются для переменных циклов. Второй строкой идет spwan_link, популярная билиотечная функция, аргументы которой и предназначение знает наизусть даже новичок. Написано нормально, предельно читабельно. все gandalfgray сделал правильно. Именно так в этом случае все и пишут.
WH>Да и читать это как?
Язык учить сначала, а только потом читать и учить людей оформлению кода.
Здравствуйте, Mamut, Вы писали:
M>Имхо, главная мощь именно Эрланга, которая, возможно, имеет/не имеет отношения к чему-либо, будь то типизация или что иное, это его тривиальная сериализуемость и (частично как следствие, частично как причина) его тривиальная работа с сетью.
M>Будь в любом другом языке такое же, имхо, Эрланг курил бы в стороне и, возможно, вообще бы не появился
M>Возможность написать: M>
M>Pid ! {Любая, [структура, данных]}
M>
M>это наигениальнейшая вещь.
M>Я как вспомню все эти пляски с бубном вокруг решений о том, что и как запаковывать/распаковывать и передавать по сети... Бррр.
M>Каким боком здесь динамика? А никаким
Забавно. Слона то ты и не заметил. Да наипрямейшим образом тут динамика. Именно динамика дает тебе такую легкость сериализации и десериализации — не нужны никакие фабрики. Именно поэтому Эрланг динамический. Это довольно глубокая мысль — думая ее ты достигнешь просветления.
G>Забавно. Слона то ты и не заметил. Да наипрямейшим образом тут динамика. Именно динамика дает тебе такую легкость сериализации и десериализации — не нужны никакие фабрики.
как человек, написавший пару библиотек сериализации на хаскеле, я протестую против наглой и циничной лжи!
правда, тип для десериализации всё равно знать приходится но в языке с действительно строгой типизацией это обычно и не является проблемой
Здравствуйте, Gaperton, Вы писали:
G>Этот переход возможен только в случае, если у тебя время обработки каждого запроса предсказуемо и постоянно. Это простой случай, тут думать практически не надо. Только жизнь сложная штука, там далеко не всегда бывает так. Например, серверу CQG приходится иметь дело с запросами, время выполнения которых непредсказуемо, и колеблется в широком биапазоне от очень быстрых до крайне медленных. Одновременно серверу приходится отвечать на множество запросов с моментальной реакцией, и прокачивать через себя кучу обновлений по открытым соединениям в реальном времени с минимальной задержкой. Периодически бывают ситуации пиковой нагрузки (ферма серверов балансирует нагрузку или отрабатывает сбой, перекидывая пользователей с сервера на сервер), при которой все должно работать так же, как обычно.
А имеет смысл писать сервер аналогичный CQG'шному на erlang? Если да, то в чём будет выигрыш и проигрыш? Если можно с примерными количественными оценками.
Здравствуйте, Gaperton, Вы писали:
G>С агентами эта задача практически не решаема за разумные сроки с разумным качеством (сдохнешь на рефакторинге — бить последовательные процессы на несколько "агентов", и вводить систему веревочек, чтобы обеспечить приоритеты) — параллельных активностей слишком много, именно для решения этих проблем и была введена легкая многозадачность с собственным планировщиком. Имея такой рантайм, каким обладает Эрланг, этих проблем попросту бы не было. Воспроизвести свойства этого рантайма на С++ невозможно даже со своими потоками — файберы (в отличии от эрланговских процессов) жрут адресное пространство со страшной силой, иметь их в системе десятки тысяч сложно, и практически невозможно, плюс — в файберах приходится помечать точки возможного прерывания шедулером руками. А агенты — вообще отстой, их применение усложняет код и время разработки в два раза по нашим метрикам (за счет того, что длительная обработка разворачивается из последовательного кода в конечный автомат, и программа становится асинхронной). В простом случае ты конечно того не заметишь, и, возможно, не поймешь, о каких проблемах я говорю, но вообще — вот так бывает, дружище.
Все вышесказанное, я так понимаю, это фантазии на тему. Ведь реального использования агентов не было.
G>Вообще непонятно, зачем ты споришь с очевидным. Так сложно пережить факт, что Эрланговский рантайм содержит лучшую на текущий момент поддержку параллельного программирования? Извини, люди специально старались, чтоб было именно так, что тут удивляться. Старались они потому, что считали, что это очень важно. И не идиоты люди-то — заслуженные инженеры, с опытом, понимают, что делают. Можно допустить, что тут есть какая-то полезная фишка? Или все отстой, кроме пчел?
Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.
Очень субъективно, но по мне выделенное говорит о несколько скептическом отношении к возможным бенефитам, а если загодя считаешь вариант проигрышным, то как-то даж не знаю
Здравствуйте, Курилка, Вы писали:
E>>Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.
К>Очень субъективно, но по мне выделенное говорит о несколько скептическом отношении к возможным бенефитам, а если загодя считаешь вариант проигрышным, то как-то даж не знаю
Термин "круто" здесь был мной упомянут в самом лучшем смысле этого слова. Читая Армстронга видишь правильные вещи, и наблюдая как эти вещи находят воплощение в Erlang-е, невольно говоришь про себя: "круто".
Но вот есть у меня пока некоторое впечатление, не позволяющее разделять восторги приверженцев Erlang-а. Впечатление субъективное, но присутствует. Отсюда и некоторый скепсис.
Тем не менее, лично я нахожу в этом разговоре много полезного, в частности, когда приходится писать кому-то ответ, то в этот момент происходит некоторое переосмысление известного мне об Erlang-е. Приношу извинения тем, кому я здесь по причине постоянных споров надоел, я преследую свои личные интересы
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BulatZiganshin, Вы писали:
G>>Забавно. Слона то ты и не заметил. Да наипрямейшим образом тут динамика. Именно динамика дает тебе такую легкость сериализации и десериализации — не нужны никакие фабрики.
BZ>как человек, написавший пару библиотек сериализации на хаскеле, я протестую против наглой и циничной лжи!
В чем ложь? В том, что при динамике не нужны фабрики, а при статике нужны? Обвиняешь в "наглой и циничной лжи" — отвечай за базар. А лучше — сначала думай, потом пиши, или (на выбор) веди себя прилично, тогда и отвечать за базар не придется.
BZ>правда, тип для десериализации всё равно знать приходится
Да ты что . Неужели? А обработку версионности сообщений ты учесть не забыл — прикольная такая штука получается, когда у тебя десериализатор съезжает с бинарного формата из-за ошибки версий — никогда не втречал такого?
BZ>но в языке с действительно строгой типизацией это обычно и не является проблемой
Для меня код сериализации-десериализации проблемой не является на любом языке, в т.ч. и на plain C — слишком много раз в жизни я его писал. И что? Не, право слово, смешные вы люди — вы правда думаете, что люди, знающие Эрланг, ни на чем другом не писали никогда, да? И вы им тайну откроете, когда расскажете, как десериализация делается в других языках?
Краткий курс "десериализации" в Эрланге. Это будет непросто, конечно не так просто, как "в нормальном строготипизированном языке", но я думаю, поднапрягшись можно что-то понять и научится этому непростому делу в динамике.
Способ первый — из бинарного источника:
DeserializedData = binary_to_term( Binary ).
Способ второй — "десериализуем" принятое процессом сообщение:
DeserializedData = receive MyData -> MyData end.
Это весь код, который я пишу. Библиотек я здесь не использую, ограничений на сериализуемые данные у меня нет никаких. Я могу, например, лямбда функцию спокойно сериализовать и десериализовать. Рекомендую повторить на "нормальном строготипизированном языке". Не забыв все необходимые дополнительные телодвижения, а также тот случай, когда в потоке встречается рассогласование версий форматов. Потом подумать о жизни — о том, какая это все-таки непростая штука.
[cut]
G>Это весь код, который я пишу. Библиотек я здесь не использую, ограничений на сериализуемые данные у меня нет никаких. Я могу, например, лямбда функцию спокойно сериализовать и десериализовать. Рекомендую повторить на "нормальном строготипизированном языке". Не забыв все необходимые дополнительные телодвижения, а также тот случай, когда в потоке встречается рассогласование версий форматов. Потом подумать о жизни — о том, какая это
все-таки непростая штука.
Слушай, а вот как Эрланг с версионностью борется?
Скажем апгрейдим сервер, формат сообщений расширился, т.е. под старый шаблон уже не "влезает" — придётся принудительно апгрейдить клиентов? Или в формате делать "точки расширения" (e.g. параметр как список произв. длины, я тут рядом вроде eao197 приводил подобную схема)? Не встречался с подобной задачей?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>С агентами эта задача практически не решаема за разумные сроки с разумным качеством (сдохнешь на рефакторинге — бить последовательные процессы на несколько "агентов", и вводить систему веревочек, чтобы обеспечить приоритеты) — параллельных активностей слишком много, именно для решения этих проблем и была введена легкая многозадачность с собственным планировщиком. Имея такой рантайм, каким обладает Эрланг, этих проблем попросту бы не было. Воспроизвести свойства этого рантайма на С++ невозможно даже со своими потоками — файберы (в отличии от эрланговских процессов) жрут адресное пространство со страшной силой, иметь их в системе десятки тысяч сложно, и практически невозможно, плюс — в файберах приходится помечать точки возможного прерывания шедулером руками. А агенты — вообще отстой, их применение усложняет код и время разработки в два раза по нашим метрикам (за счет того, что длительная обработка разворачивается из последовательного кода в конечный автомат, и программа становится асинхронной). В простом случае ты конечно того не заметишь, и, возможно, не поймешь, о каких проблемах я говорю, но вообще — вот так бывает, дружище.
E>Все вышесказанное, я так понимаю, это фантазии на тему. Ведь реального использования агентов не было.
Я так понимаю, ты просто не понимаешь смысл вышесказанного, и сути озвученных проблем. И сказать тебе по существу нечего — ни по поводу агентов, ни по поводу процессов.
E>Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.
Ну так бы сразу и сказал. А я-то думал тебе какую-то работу на языках программирования делать надо, время на тебя тратил.
У Эрланга степен крутизны невелика — он не крут совсем. На чем там ты сейчас пишешь? Ruby? Вот, Ruby в сто раз круче. И этот, как его, Питон — тот круче в двести раз. Я уж молчу о немерле — этот ваще круче вареных яиц. Все?
G>У Эрланга степен крутизны невелика — он не крут совсем. На чем там ты сейчас пишешь? Ruby? Вот, Ruby в сто раз круче. И этот, как его, Питон — тот круче в двести раз. Я уж молчу о немерле — этот ваще круче вареных яиц. Все?
Ну, не стоит недооценивать степень крутизны Эрланга. Я сейчас на Google Alerts подписан по Эрлангу. Последние пару недель процентов 90 сообщений — о реализации/возможности реализации многопоточности a la Эрланг в языках типа Руби и Питон.
Всуе и не всуе Эрланг сейчас в разных конференциях (типа .declarative, .scheme, .ruby и проч.) упоминается чуть ли не чаще, чем в, собственно, .erlang-general
Призрак бродит по Инету, призрак легкой многопоточности
Здравствуйте, Gaperton, Вы писали:
G>А вообще — не забывайте — у нас есть под рукой горячий апдейт кода на работающей системе и нам не страшны крэши отдельных процессов (для Эрланга крэш, в отличии от остальных языков — это штатная, рабочая ситуация, let it crash) — всю систему это не завалит. Это сильно снижает тяжесть последствий рассогласования протоколов.
Ну да, это конечно, но eao197 там вроде говорил про ситуацию когда клиенты они "внешние" по отношению к нам, хотя запускать "чужих" в эрланговую систему, где (уже внутри самой системы) по сути почти нет механизмов защиты — это жуть полная...
Здравствуйте, Gaperton, Вы писали:
G>Плюсов можно достичь таких:
Т.е. всякие сервисы, которые слушают обновления рыночных данных, что-то пересчитывают и шлют дальше это подходящая задача?
G>Минусы такие: G>Проектировать надо совсем по другому, не так как на С++/Java — в Эрланге довольно необычный подход к проектированию, и свои грабли, которые надо знать и обходить. А сервер настолько сложен (из-за большого количества всяких обязательных к реализации мелочей и неочевидных юзкейсов), что его чрезвычайно тяжело спроектировать и на обычных ОО языках.
Ты имеешь в виду, что опыт ОО проектирования накоплен больше чем проектирования на функциональных языках и это в данном случае проблема?
Ты часто упоминаешь временные ряды в контексте сервера CQG. Можешь привести минимальный пример задачи, чтобы понять, что имеется в виду?
Здравствуйте, Gaperton, Вы писали:
G>Есть на самом деле две проблемы, связанные с версионностью. Первая — десериализатор бинарного потока съезжает (из-за изменившейся длины и/или формата пакетов), и начинает работать не начала пакетов. Это кирдык. Этой проблемы у нас не будет в принципе при применении встроенной сериализации. Вторая проблема — как обрабатывать сообщения неизвестного формата. Это уже проблема прикладная. "Хорошее" поведение — пропускать пакеты неизвестного типа, и пропускать неизвестную расширенную информацию в измененных пакетах.
Первая проблема существует только для тех encoding rules, которые не оставляют меток в сериализованном потоке, а расчитывают исключительно на порядок следования элементов. Например, ASN1 PER и различные доморощенные способы сериализации. Для таких encoding rules незапланированное расширение протокола в общем случае невозможно. Поэтому в описании сериализуемых данных требуется указывать специальные extension points. Например, в ASN1 DDL для этого предназначены специальные синтаксические правила.
При использовании encoding rules с метками (ASN1 BER, текстовые форматы XML, JSON, YAML обладают аналогичными характеристиками) проблемы расширения или сужения набора данных в пакете не существует.
Поэтому страхи по поводу кирдыка, в общем случае преувеличены
Чтоже до пропуска пакетов неизвестного типа или неизвестной расширенной информации, то и здесь не все так просто. Так что слово "хорошее" не зря было взято в кавычки. Имхо, гораздо лучше, когда расширенная информация снабжается специальным флагом mustUnderstand. Принимающая сторона имеет право пропускать или игнорировать только ту расширенную информацию, для которой флаг mustUnderstand установлен в false.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>>>С агентами эта задача практически не решаема за разумные сроки с разумным качеством (сдохнешь на рефакторинге — бить последовательные процессы на несколько "агентов", и вводить систему веревочек, чтобы обеспечить приоритеты) — параллельных активностей слишком много, именно для решения этих проблем и была введена легкая многозадачность с собственным планировщиком. Имея такой рантайм, каким обладает Эрланг, этих проблем попросту бы не было. Воспроизвести свойства этого рантайма на С++ невозможно даже со своими потоками — файберы (в отличии от эрланговских процессов) жрут адресное пространство со страшной силой, иметь их в системе десятки тысяч сложно, и практически невозможно, плюс — в файберах приходится помечать точки возможного прерывания шедулером руками. А агенты — вообще отстой, их применение усложняет код и время разработки в два раза по нашим метрикам (за счет того, что длительная обработка разворачивается из последовательного кода в конечный автомат, и программа становится асинхронной). В простом случае ты конечно того не заметишь, и, возможно, не поймешь, о каких проблемах я говорю, но вообще — вот так бывает, дружище.
E>>Все вышесказанное, я так понимаю, это фантазии на тему. Ведь реального использования агентов не было. G>Я так понимаю, ты просто не понимаешь смысл вышесказанного, и сути озвученных проблем. И сказать тебе по существу нечего — ни по поводу агентов, ни по поводу процессов.
Из сказанного тобой я вижу, что вы сделали решение на файберах (и это была эмуляция процессов Erlang-а). Но все, что ты говоришь про агентов -- это предположения. Вот я и спрашиваю: был ли у вас какой-нибудь прототип на агентах (и на каких, агентных систем-то разных много)?
E>>Нет, я в споре пытаюсь оценить степень крутизны Erlang-а.
G>Ну так бы сразу и сказал. А я-то думал тебе какую-то работу на языках программирования делать надо, время на тебя тратил.
Извини, что отнял у тебя время.
Тем не менее, интересно было выслушать мнение об Erlang-е не из работы Армстронга, а от кого-то, кто Erlang использует (кстати, использует ли?).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Сервисов возможно довольно много — это я на вскидку привел.
А всякая расчётная кухня типа интерполяции или симуляции методом Монте-Карло и прочие вещи для моделирования в финансах?
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, Gaperton, Вы писали:
G>>Сервисов возможно довольно много — это я на вскидку привел. EC>А всякая расчётная кухня типа интерполяции или симуляции методом Монте-Карло и прочие вещи для моделирования в финансах?
Этого на практике немного — по крайней мере в приложениях CQG рассчитанных не на инвестиционные банки и не на арбитраж, а на обыкновенных трейдеров. Понятное дело, числодробилки лучше писать на С++. И сложность не в них. Большинство трейдеров применяют элементарные, довольно простые рассчеты.
Здравствуйте, eao197, Вы писали:
E>При использовании encoding rules с метками (ASN1 BER, текстовые форматы XML, JSON, YAML обладают аналогичными характеристиками) проблемы расширения или сужения набора данных в пакете не существует.
E>Поэтому страхи по поводу кирдыка, в общем случае преувеличены
Это не "страхи", и они не преувеличены. При собственной реализации сериалиации-десериализации ручками ты внесешь ошибки, которые могут привести к съезжанию потока, независимо от того, какой подход к сериализации ты применяешь, и обнаружить такую ошибку а также восстановиться после нее не так просто. Для этого в поток magic-и вводят, специальные метки. Спасает от таких ошибок только автоматически генерированные сериализаторы.
Тэгированные форматы лишены многих подобных проблем — это и есть тот формат, который применяется при автоматической сериализации в динамических языках. Тебе для его реализации придется руками воспроизвести то, что динамический язык делает автоматически. И ты, кроме того что непродуктивно потратишь время, при этом двадцать раз облажаешься.
XML и текстовые языки разметки, которые казалось бы решают проблемы сериализации, и которые ты упомянул — классная штука, только его декодирование примерно в 50 раз медленнее, чем декодирование бинарных форматов, и он не по детски жрет траффик, что неприемлемо для целого ряда приложений. Зипование потока не выход — оно увеличивает и так недетский оверхэд на отправку-получение плюс привносит задержку в процесс передачи — от чего возрастает латентность — это тоже неприемлемо для приложений реального времени.
ASN.1 с применением автоматических генераторов позволяет таких ошибок избежать. К слову, в стандартной поставке Erlang/OTP поддержан ASN.1 (что неудивительно для Open Telecom Platform).
E>Чтоже до пропуска пакетов неизвестного типа или неизвестной расширенной информации, то и здесь не все так просто. Так что слово "хорошее" не зря было взято в кавычки. Имхо, гораздо лучше, когда расширенная информация снабжается специальным флагом mustUnderstand. Принимающая сторона имеет право пропускать или игнорировать только ту расширенную информацию, для которой флаг mustUnderstand установлен в false.
Здесь как раз все достаточно просто. Если ты не понимаешь расширенную информацию, тебе придется либо ее проигнорировать либо умереть при попытке ее разобрать. Флаг mustUnderstand в результате нужен только для того, чтобы убить потребителя. Есть более простые и прямолинейные способы определить, что верисии клиента-сервера несовместимы, которые все и применяют — достаточно при хендшейке обменяться версиями протоколов, и сообщить о несовместимости культурным образом.
Здравствуйте, Gaperton, Вы писали:
E>>При использовании encoding rules с метками (ASN1 BER, текстовые форматы XML, JSON, YAML обладают аналогичными характеристиками) проблемы расширения или сужения набора данных в пакете не существует.
E>>Поэтому страхи по поводу кирдыка, в общем случае преувеличены G>Это не "страхи", и они не преувеличены. При собственной реализации сериалиации-десериализации ручками ты внесешь ошибки, которые могут привести к съезжанию потока, независимо от того, какой подход к сериализации ты применяешь, и обнаружить такую ошибку а также восстановиться после нее не так просто. Для этого в поток magic-и вводят, специальные метки. Спасает от таких ошибок только автоматически генерированные сериализаторы.
Слушай, а ты не доктор в прошлом? У них манера такая -- сначала запугать до смерти, а затем принять позу, мол я попробую, но вы же сами понимаете, что я не волшебник.
Какие-то ты страшилки рассказываешь про вручную писанные сериализаторы/десериализаторы в XXI-м веке. Странно, право. Если не брать автоматически генерируемых сериализаторов, то даже простые библиотеки для организации сериализации/десериализации превращают код сериализации/десериализации в довольно декларативный. Можно вспомнить хотя бы MFC-сериалиацию или Boost-сериализацию.
G>Тэгированные форматы лишены многих подобных проблем — это и есть тот формат, который применяется при автоматической сериализации в динамических языках. Тебе для его реализации придется руками воспроизвести то, что динамический язык делает автоматически. И ты, кроме того что непродуктивно потратишь время, при этом двадцать раз облажаешься.
Лучше нужно думать о людях. Двадцать раз облажаться -- это еще суметь нужно.
Кроме того не нужно говорить о "динамических языках" во множественном числе. Результат Erlang-овского term_to_binary ты не сможешь разобрать в Python или Ruby, хоть они и динамические. Равно как и результат Ruby-нового Marshall.dump не распарсится в Erlang. Поэтому как только встанет вопрос интероперабильности с чем-нибудь, то по любому придется писать какие-то конверторы или же использовать иной способ сериализации. В том числе и расставлять теги вручную.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Зипование потока не выход — оно увеличивает и так недетский оверхэд на отправку-получение плюс привносит задержку в процесс передачи — от чего возрастает латентность — это тоже неприемлемо для приложений реального времени.
Кстати об упаковке сериализованных потоков. При работе с медленными каналами ввода/вывода (связь через dial-up к примеру) или медленными устройствами (теми же HDD) зипование даже бинарного потока может оказаться выгоднее передачи исходных данных. Т.к. время упаковки и, особенно, распаковки, оказывается гораздо меньше, чем время пропихивания всего объема исходных данных. А в случае использования специальных упаковщиков (LZO, к примеру) это время еще более сокращается. Не случайно поэтому LZO использовалась для сжатия данных на борту NASA-вских марсоходов Spirit и Opportunity.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
VD>>Ежу понятно. Но это уже не совсем честное сравнение. Это уже пенисометрия библиотек, или, что еще хуже, сравнение С с С но замаскированный под Питор (обман, значичь).
FR>Тебе шашечки или ехать?
Ехать, по этому я не хочу жить в розовых очках думая о том, что на Питоне можно написать быстрый код на том оснвании, что какой-то шулер выдал производительность Питона за производительность одной из С-шных фукнций из его библиотеки.
FR>Это нормальное использование для glue языка.
Вот пусть его и позиционируют как "glue", а не как С++ на стеройдах. А мне glue-код не нужен. Я исползуют компонентные языки и рантаймы, которые решают в том числе и проблему динамического связыания разных модулей в единое решение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>Лучше нужно думать о людях. Двадцать раз облажаться -- это еще суметь нужно. E>Кроме того не нужно говорить о "динамических языках" во множественном числе. Результат Erlang-овского term_to_binary ты не сможешь разобрать в Python или Ruby, хоть они и динамические. Равно как и результат Ruby-нового Marshall.dump не распарсится в Erlang. Поэтому как только встанет вопрос интероперабильности с чем-нибудь, то по любому придется писать какие-то конверторы или же использовать иной способ сериализации. В том числе и расставлять теги вручную.
А term_to_binary и не нужен. Достаточно реализации Эрланговского "external term format" (довольно протсого, кстати, как я понял), чтобы программа на любом языке смогла общаться с Эрлангом на языке Эрланга.
Здравствуйте, Mamut, Вы писали:
M>А term_to_binary и не нужен. Достаточно реализации Эрланговского "external term format" (довольно протсого, кстати, как я понял), чтобы программа на любом языке смогла общаться с Эрлангом на языке Эрланга.
Более того, исходники либы EI ( на С ) поставляются вместе с дистрибутивом Ерланга. Я без большого напряга прицепил ее к Тиклю, который чейчас общается с Ерланговским сервером по Ерланговскому же протоколу.
Здравствуйте, eao197, Вы писали:
G>>Зипование потока не выход — оно увеличивает и так недетский оверхэд на отправку-получение плюс привносит задержку в процесс передачи — от чего возрастает латентность — это тоже неприемлемо для приложений реального времени.
E>Кстати об упаковке сериализованных потоков. При работе с медленными каналами ввода/вывода (связь через dial-up к примеру) или медленными устройствами (теми же HDD) зипование даже бинарного потока может оказаться выгоднее передачи исходных данных. Т.к. время упаковки и, особенно, распаковки, оказывается гораздо меньше, чем время пропихивания всего объема исходных данных. А в случае использования специальных упаковщиков (LZO, к примеру) это время еще более сокращается. Не случайно поэтому LZO использовалась для сжатия данных на борту NASA-вских марсоходов Spirit и Opportunity.
Надо же блин, а я и не знал, что иногда что-то полезно сжимать . Жду еще интересной и познавательной информации — например, интересно узнать, — потоковое видео передающееся по сети тоже выгоднее сжимать? Или все-таки лучше гнать как есть — некомпрессированными кадрами? Данные-то как-никак бинарные. А если сжимать, то чем? Специальными упаковщиками — вроде MPEG2 или H.264 (пардон, вышел из роли — "слишком умное слово для такой маленькой девочки"), или все-таки лучше LZO (все-таки в NASA применяется для марсоходов)? А?
ЗЫ: Да, кстати, может тебе интересно будет. В сервере CQG практически все данные, которые пишутся на диск — жмутся. И не группой LZ, а более простой, эффективной и на несколько порядков более быстрой, специально разработанной под формат данных схемой (разность цен приведеннах к целым числам для соседних котировок жмется Хаффманом с фиксированным словарем). Это дает выигрыш в 4 раза по скорости и объему, и только потому, что обработка данных настолько тривиальна, что все затыкается в диск. Будь иначе — никакой компрессии делать бы смысла не имело. Решение о компрессии — всегда индивидуально, и для грамотно построенного бинарного формата алгоритмы группы LZ покажут эффект близкий к нулевому. Они рулят на текстовых протоколах, и на тупых бинарных в специальных условиях.
Здравствуйте, eao197, Вы писали:
E>>>При использовании encoding rules с метками (ASN1 BER, текстовые форматы XML, JSON, YAML обладают аналогичными характеристиками) проблемы расширения или сужения набора данных в пакете не существует.
E>>>Поэтому страхи по поводу кирдыка, в общем случае преувеличены G>>Это не "страхи", и они не преувеличены. При собственной реализации сериалиации-десериализации ручками ты внесешь ошибки, которые могут привести к съезжанию потока, независимо от того, какой подход к сериализации ты применяешь, и обнаружить такую ошибку а также восстановиться после нее не так просто. Для этого в поток magic-и вводят, специальные метки. Спасает от таких ошибок только автоматически генерированные сериализаторы.
E>Слушай, а ты не доктор в прошлом? У них манера такая -- сначала запугать до смерти, а затем принять позу, мол я попробую, но вы же сами понимаете, что я не волшебник.
Нет, не доктор. А ты, слушай, в прошлом не пациент?
E>Какие-то ты страшилки рассказываешь про вручную писанные сериализаторы/десериализаторы в XXI-м веке. Странно, право. Если не брать автоматически генерируемых сериализаторов, то даже простые библиотеки для организации сериализации/десериализации превращают код сериализации/десериализации в довольно декларативный. Можно вспомнить хотя бы MFC-сериалиацию или Boost-сериализацию.
Я рассказываю про типовые ошибки в сериализаторах-десериализаторах, которые имеют обыкновение проявляються при попытках вносить изменения в протокол. Эти ошибки можно выловить и исправить, потому, что вообще любые ошибки можно выловить и исправить. Ничего "странного право" я не вижу. Можно такие ошибки допустить, о которых я говорю? Можно. Чего споришь? Отловить их тоже можно, но это трата времени.
G>>Тэгированные форматы лишены многих подобных проблем — это и есть тот формат, который применяется при автоматической сериализации в динамических языках. Тебе для его реализации придется руками воспроизвести то, что динамический язык делает автоматически. И ты, кроме того что непродуктивно потратишь время, при этом двадцать раз облажаешься.
E>Лучше нужно думать о людях. Двадцать раз облажаться -- это еще суметь нужно.
Ах, как плохо я о тебе думаю, что ты оказыватеся когда кодируешь делаешь ошибки. Трагедия. Ничо — сумеешь облажаться, я в тебя верю как в себя. Все люди лажают, когда пишут код, и вносят туда ошибки. Я, ты, он, она. Все. Не ошибаются только те, кто вообще код не пишет.
E>Кроме того не нужно говорить о "динамических языках" во множественном числе. Результат Erlang-овского term_to_binary ты не сможешь разобрать в Python или Ruby, хоть они и динамические. Равно как и результат Ruby-нового Marshall.dump не распарсится в Erlang. Поэтому как только встанет вопрос интероперабильности с чем-нибудь, то по любому придется писать какие-то конверторы или же использовать иной способ сериализации. В том числе и расставлять теги вручную.
Нужно говорить о динамически языках во множественном числе. Два сервиса на твоем Руби спокойно подружатся, так же без проблем. Утверждать же, что в Эрланге проблема серилизации решена таким образом, что магически изчезают проблемы интеропа с другими языками и платформами (что ты мне приисываешь и с чем ты споришь) — настолько несусветная дурь, что я даже комментировать это не буду.
Что насчет интероперабельности —
1) Можно взять библиотеку для разбора Эрланговских термов из стандартной поставки, и прикрутить к любому языку.
2) Можно воспольваться компилятором ASN.1 из стандартной поставки.
3) Можно реализовать любой протокол ручками — на Эрланге это будет проще, чем на любом другом языке (и чем на Руби тоже) благодяря бинарисам.
4) Можно воспользоваться CORBA (стандартная поставка).
5) Можно использовать XML (стандартная поставка).
6) С Явой есть готовый биндинг (guess what? стандартная поставка).
7) С С — тоже.
Кроме того, что ты попытался постебаться что-нибудь еще ты сказал в дополненение к тому, что иногда данные полезно сжимать? По-моему, ты просто повторил мои слова, но на свой неповторимый манер.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
E>>Слушай, а ты не доктор в прошлом? У них манера такая -- сначала запугать до смерти, а затем принять позу, мол я попробую, но вы же сами понимаете, что я не волшебник.
G>Нет, не доктор. А ты, слушай, в прошлом не пациент?
И в прошлом, и в будущем.
E>>Какие-то ты страшилки рассказываешь про вручную писанные сериализаторы/десериализаторы в XXI-м веке. Странно, право. Если не брать автоматически генерируемых сериализаторов, то даже простые библиотеки для организации сериализации/десериализации превращают код сериализации/десериализации в довольно декларативный. Можно вспомнить хотя бы MFC-сериалиацию или Boost-сериализацию.
G>Я рассказываю про типовые ошибки в сериализаторах-десериализаторах, которые имеют обыкновение проявляються при попытках вносить изменения в протокол. Эти ошибки можно выловить и исправить, потому, что вообще любые ошибки можно выловить и исправить. Ничего "странного право" я не вижу. Можно такие ошибки допустить, о которых я говорю? Можно. Чего споришь? Отловить их тоже можно, но это трата времени.
Видишь ли, с такой же вероятностью ты можешь допустить ошибку в DDL-файле с описанием для автоматической тулзины для сериализации/десериализации. Даже в Erlang-е ты можешь записать:
B = term_to_binary( {A,C,B} )
вместо
B = term_to_binary( {A,B,C} )
и ничем кроме тестов ты это не выявишь.
Я же говорил о том, что наличие удобных и готовых инструментов для сериализации сводят вероятность внесения ошибок программистом практически к такому же уровню, как при использовании автоматических инструментов сериализации/десериалиазации. Поскольку необходимости в действительно ручной (когда вручную приходится байтики в буфер складывать) уже давно нет.
E>>Кроме того не нужно говорить о "динамических языках" во множественном числе. Результат Erlang-овского term_to_binary ты не сможешь разобрать в Python или Ruby, хоть они и динамические. Равно как и результат Ruby-нового Marshall.dump не распарсится в Erlang. Поэтому как только встанет вопрос интероперабильности с чем-нибудь, то по любому придется писать какие-то конверторы или же использовать иной способ сериализации. В том числе и расставлять теги вручную.
G>Нужно говорить о динамически языках во множественном числе. Два сервиса на твоем Руби спокойно подружатся, так же без проблем. Утверждать же, что в Эрланге проблема серилизации решена таким образом, что магически изчезают проблемы интеропа с другими языками и платформами (что ты мне приисываешь и с чем ты споришь) — настолько несусветная дурь, что я даже комментировать это не буду.
Теперь понятно, что ты имел ввиду, что применительно к любому динамическому языку два сервиса на этом языке будут общаться между собой без проблем. Я понял тебя иначе.
Собственно, а Java со своей встроенной сериализацией здесь как тогда выглядит?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
E><...упражнения в острословии поскипаны...>
E>Кроме того, что ты попытался постебаться что-нибудь еще ты сказал в дополненение к тому, что иногда данные полезно сжимать? По-моему, ты просто повторил мои слова, но на свой неповторимый манер.
А я и не утверждал, что сжимать данные всегда бесполезно. Я тебе сказал ровно то, что сказал — не больше: сжатие потока не решает проблем с XML — оно увеличивает и без того высокий оверхэд на десериализацию (примерно в 50 раз против бинарного протокола) + привносит задержку в протокол, что нехорошо для приложений реального времени. Т.е. я говорил не о сжатии, а об XML. Все. А ты что пишешь в ответ? Какие нахрен марсоходы? Какие модемы? Хватит делать из меня идиота.
Здравствуйте, Gaperton, Вы писали:
G>А я и не утверждал, что сжимать данные всегда бесполезно. Я тебе сказал ровно то, что сказал — не больше: сжатие потока не решает проблем с XML — оно увеличивает и без того высокий оверхэд на десериализацию (примерно в 50 раз против бинарного протокола) + привносит задержку в протокол, что нехорошо для приложений реального времени. Т.е. я говорил не о сжатии, а об XML. Все. А ты что пишешь в ответ? Какие нахрен марсоходы? Какие модемы? Хватит делать из меня идиота.
Даже для приложений реального времени, работающих на медленных каналах (даже на 10Mbit Ethernet), сжатие XML может как раз таки убрать лишние задержки из протокола. А использование XML может быть данностью, обусловленной требованиями заказчиков. Все зависит от конкретных условий.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>А я и не утверждал, что сжимать данные всегда бесполезно. Я тебе сказал ровно то, что сказал — не больше: сжатие потока не решает проблем с XML — оно увеличивает и без того высокий оверхэд на десериализацию (примерно в 50 раз против бинарного протокола) + привносит задержку в протокол, что нехорошо для приложений реального времени. Т.е. я говорил не о сжатии, а об XML. Все. А ты что пишешь в ответ? Какие нахрен марсоходы? Какие модемы? Хватит делать из меня идиота.
E>Даже для приложений реального времени, работающих на медленных каналах (даже на 10Mbit Ethernet), сжатие XML может как раз таки убрать лишние задержки из протокола.
Использовать ХМЛ для приложений реального времени критичных к траффику да еще на относительно медленных каналах — идиотизм. Сначала создать себе проблемы, потом их героически преодолевать (зипуя канал и тд). В таких случаях нормальные люди применяют бинарные протоколы (посмотри как обошлись в МПЕГ7 — там применяется BiM — это такой бинарный ХМЛ). На быстром канале зипование внесет дополнительную задержку — она связана с окном просмотра компрессоров группы ЛЗ.
E>А использование XML может быть данностью, обусловленной требованиями заказчиков. Все зависит от конкретных условий.
Случай, когда ХМЛ — это данность, не относится к нашему разговору о преимуществах и недостатках методов сериализации. Требование заказчиков могут обусловить вообще все что угодно — это не предмет обсуждения.
Да, и еще. Мне надоело переливание из пустого в порожнее.
E>>Даже для приложений реального времени, работающих на медленных каналах (даже на 10Mbit Ethernet), сжатие XML может как раз таки убрать лишние задержки из протокола. G>Использовать ХМЛ для приложений реального времени критичных к траффику да еще на относительно медленных каналах — идиотизм. Сначала создать себе проблемы, потом их героически преодолевать (зипуя канал и тд). В таких случаях нормальные люди применяют бинарные протоколы (посмотри как обошлись в МПЕГ7 — там применяется BiM — это такой бинарный ХМЛ). На быстром канале зипование внесет дополнительную задержку — она связана с окном просмотра компрессоров группы ЛЗ.
Задержкой будет обладать не любой LZ, а только LZ с блочным кодом Хафмана.
Если мы применяем LZW или LZSS с (блочно-)динамическим кодом Хафмана, никакой задержки не будет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
A>>Часть тестов в статичской типизации не нужна. G>Не понимаю, с чего это прогрессивной общественности взбрела в голову такая мысль. Откуда дровишки-то? Любой тест приводит к выполнению кода, и убирание этого теста уменьшает тестовое покрытие — у вас какой-то код становится тестими не покрыт. Адекватное же тестовое покрытие найдет 99,999% ошибок типизации — не нужны никакие специальные тестовые сценарии для их ловли, достаточно близкого к 100% покрытия по строкам кода . Т.е. тестовое покрытие потребуется одинаковое.
Тикль:
foreach t $list {
incr s $t
}
puts "Last was $t, sum $s"
Где ошибка? Один тест со 100% покрытием ее не найдет.
(тикль не присваивает t никакого значения, если список пустой. Во всех языках со статической типизацией это будет выловлено. И в некоторых с динамической — например, в Эрланге, — но уже с тестами.)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
A>>>Часть тестов в статичской типизации не нужна. G>>Не понимаю, с чего это прогрессивной общественности взбрела в голову такая мысль. Откуда дровишки-то? Любой тест приводит к выполнению кода, и убирание этого теста уменьшает тестовое покрытие — у вас какой-то код становится тестими не покрыт. Адекватное же тестовое покрытие найдет 99,999% ошибок типизации — не нужны никакие специальные тестовые сценарии для их ловли, достаточно близкого к 100% покрытия по строкам кода . Т.е. тестовое покрытие потребуется одинаковое.
T>Тикль: T>
foreach t $list {
T> incr s $t
T>}
T>puts "Last was $t, sum $s"
T>Где ошибка? Один тест со 100% покрытием ее не найдет.
Понятия не имею. Не понимаю, что означает $. Но тест со 100% покрытия ее должен найти — у тебя для 100% должен быть выполнен incr.
T>(тикль не присваивает t никакого значения, если список пустой. Во всех языках со статической типизацией это будет выловлено. И в некоторых с динамической — например, в Эрланге, — но уже с тестами.)
Приведи лучше пример бесполезного теста, который просто не нужен в языках со статической типизацией — ты его выкинешь и тестовое покрытие не ухудшится. Вот тогда ты мне возразишь.
Здравствуйте, Gaperton, Вы писали:
G>В Эрланге просто нет массивов нормальных, и все . Плавающую запятую HIPE компилирует нормально, рекурсия там тоже быстра. Что-нить без того, чтобы лопатить вперехлест здоровый массив, как в альфабленде — это будет совсем другое дело. Хоть перемножение матриц. Здесь можно будет обогнать Питон.
G>Но лучше что-нить нейтральное — работа с какими-нибудь деревьями. Это достаточно низкоуровнево, библиотеки не нужны — все по честному. Можно в эти деревья плавающую запятую добавить и целые числа.
Мне кажестя, что интересен набор тестов. Кому интересна специализированная пенисометрия? Всегда можно подтосовать набор тестов который покажет продукт с лучшей стороны. Но интересно же знать на что способен продукт в широком диапазоне применения. Вот тебе очевидно, что альфблэнд на Эрланге и Питоне — это глупость. А кто-то может думать иначе.
В общем, комплексные тесты дали бы релаьную информацию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
И что мы стобой спорил по этим вопросам столько времени? 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
и я его даже чинил 
