Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>У меня все сказанное вами оставляет впечатление, что вы говорите о большей надежности по сравнению с C++. E>Тогда более правильно вести разговор о преимуществах сильной типизации (не важно, статической ли или динамической) перед слабой типизацией.
Золотые слова. И что мы стобой спорил по этим вопросам столько времени?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tonal-, Вы писали:
T>Если потом, окажиться что выбранный тип коллекции нас не устраивает, мы становимся теред дилемой — либо добавлять в интерфейс нужный тип — и тем загрязнять его, либо менять старый тип на новый, что даже с поддержкой компилятора часто изрядно трудоёмко, как и любое нетривиальное изменение кода.
T>Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы.
На мой взгляд это приемущество раздолбайства. Типа если я живу в хлеву, то наделай я в углу и никто не расстроится. Все равно везде грязь!
На самом деле обобщенное программирование и правильное проектирование, а так же вывод типов фактически сводят такие проблемы к нул. Но если программист раздолбай и бездарность, то правильное проектирование и применение продвинутых техник программирования может быть затруднительным. Отсюда вывод — приемущество динамики обратно пропорциональны скилу программиста. Это коечно шутка, но в ней ейсть доля шутки.
T>Соответственно разработка обладает большей мобильностью.
Скажем так. Иногда, когда мы сами загнали себя в угол неправильным проектным решением, может оказться уобным вальготное манипулирование типами. Но на уровне всего проекта это чревато большими проблемами.
Самое сложное — это не написать кусок кода, а вписать его в уже имющуюся инфраструктуру. То и дело хочется произвести рефакторинг, изменить одно проектное решение на другое. И все это проще делать при наличии строгого контроля типов.
Без строгого статического контроля типов единственным способом получить надежную систему является обкладывание кода тестами. Причем такого обкладывания, чтобы ни одна мышь не проскачила. В некоторых системах это возможно, а в некоторых нет. Так что имеем еще один вывод — динамика противопоказана системам для которых по тем или иным причинам трудно создать тесты. И еще один вывод — выбирая динамику вы обязаны уделять тестированию вренмени чуть ли не больше чем основной разработке.
T>Ну и сериализация, которая для динамики делается гораздо сильно проще чем для статики.
Я бы так не сказал. Если исключить С++, то фрэймворки для сериализации (или даже встроенная сериализация) имеется для большинство статически типизированных языков. Для сериализаци нужна не динамика, а рефлексия (причем подойдет даже рефлексия времени компиляции).
T>P.S. Сейчас мы делаем проекты на Python + Qt. T>Раньше на Delphi и С++ T>Пока, для нас, выигрышь очивиден.
Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>У меня все сказанное вами оставляет впечатление, что вы говорите о большей надежности по сравнению с C++. E>>Тогда более правильно вести разговор о преимуществах сильной типизации (не важно, статической ли или динамической) перед слабой типизацией.
VD>Золотые слова. И что мы стобой спорил по этим вопросам столько времени?
Потому, что мы с тобой спорим в общей священной войне dynamic vs static, в которой много факторов и надежность отнюдь не главный. Здесь же утверждалось, что динамика способствует надежности. Будучи приверженцем динамики я, все-таки не наблюдал такой прямой зависимости между динамикой и надежностью. Поэтому и влез в этот спор, чтобы понять, может я чего не знаю еще.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Курилка, Вы писали:
E>>Проблема в другом, в том, чтобы клиенты первой версии без проблем понимали вторую. Вот пример того, как это можно обеспечить (подсмотрено в Asn.1 ).
К>Что-то вот какая-то непонятная задача, в смысле, что не видел ни одного подобного примера К>По сути получается mediation, но примеров подобного на Erlang не встречал, думаю, что ПМ тут как раз был бы к месту. В принципе в стандартной библиотеке Эрланга есть некая "идиома", когда параметр есть список опций (расширяемый), тут тоже можно сделать нечто подобное. Причём вполне нетрудно.
Подробнее о том, что такое "проблема второй версии протокола" я рассказывал здесь
T>>Вот тут и появляется выигрышь динамической типизации — решение о конкретном типе можно откладывать. А в случае, если его приходиться менять, практически не требуется менять сопредельные интерфейсы.
VD>На мой взгляд это приемущество раздолбайства. Типа если я живу в хлеву, то наделай я в углу и никто не расстроится. Все равно везде грязь!
Рефакторинг из той же песни, он тоже получается для раздолбаев.
VD>На самом деле обобщенное программирование и правильное проектирование, а так же вывод типов фактически сводят такие проблемы к нул. Но если программист раздолбай и бездарность, то правильное проектирование и применение продвинутых техник программирования может быть затруднительным. Отсюда вывод — приемущество динамики обратно пропорциональны скилу программиста. Это коечно шутка, но в ней ейсть доля шутки.
Не надо сказок про правильное проектирование, в реальном мире такое бывает разве при переписывании старых проектов и то если не добавлять новых фич
Ну а серъезно динамика дает больше перимуществ как раз более сильным программистам.
T>>Соответственно разработка обладает большей мобильностью.
VD>Скажем так. Иногда, когда мы сами загнали себя в угол неправильным проектным решением, может оказться уобным вальготное манипулирование типами. Но на уровне всего проекта это чревато большими проблемами.
VD>Самое сложное — это не написать кусок кода, а вписать его в уже имющуюся инфраструктуру. То и дело хочется произвести рефакторинг, изменить одно проектное решение на другое. И все это проще делать при наличии строгого контроля типов.
При динамике это тоже просто.
VD>Без строгого статического контроля типов единственным способом получить надежную систему является обкладывание кода тестами. Причем такого обкладывания, чтобы ни одна мышь не проскачила. В некоторых системах это возможно, а в некоторых нет. Так что имеем еще один вывод — динамика противопоказана системам для которых по тем или иным причинам трудно создать тесты. И еще один вывод — выбирая динамику вы обязаны уделять тестированию вренмени чуть ли не больше чем основной разработке.
Влад не провоцируй на разговоры про так любимого тобой Блаба
По опыту на небольших и средних проектах динамический язык (питон) требует не больше формальных тестов чем статический (хорошо написаный код на C++). Фокус в том что разработка идет практически режиме неприрывного тестирования, каждый запуск это тест. А число запусков при написании на динамике намного больше чем на статике.
VD>Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .
Думаю ява даст сильный тормоз за счет приличного увелечения объема кода. Скала вряд ли даст какое либо ускорение.
VD>>Золотые слова. И что мы стобой спорил по этим вопросам столько времени?
E>Потому, что мы с тобой спорим в общей священной войне dynamic vs static, в которой много факторов и надежность отнюдь не главный. Здесь же утверждалось, что динамика способствует надежности. Будучи приверженцем динамики я, все-таки не наблюдал такой прямой зависимости между динамикой и надежностью. Поэтому и влез в этот спор, чтобы понять, может я чего не знаю еще.
Я тоже согласен
Но обычно приверженцы статики кричат чуть ли об абсолютной ненадежности динамики. Что тоже неправда. Наверно поэтому Влад так разошелся, это же красная тряпка когда утверждают нечто абсолютно противоположное одному из его любимейших мифов
Здравствуйте, 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. динамика еще не закончен
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, VladD2, Вы писали:
VD>>Кумаю, что если вы замените Qt хотя бы на Яву, то будет еще очевиднее, что дело не в динамике. А там уже будет рукой подать до перехода на Скалу. И тогда уж станет просто кристально ясно, что дело было точно не в динамике .
FR>Думаю ява даст сильный тормоз за счет приличного увелечения объема кода. Скала вряд ли даст какое либо ускорение.
С явой согласен, разработка без поддержки IDE — это очень непростое занятие. Но вот скала? Я уже пол-года изучаю это язык и незаметно для себя обнаружил, что на скале я пишу в jedit/emacs _вообще_ без поддержки IDE (ибо нету пока толковой). Т.е. выразительность и краткость языка не идет ни в какое сравнение с java. Реально очень близко к python, только со статикой. Но гибкость скаловской системы типов и синтаксисический сахар позволяют писать как в динамике.
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) нечто, что должно подчиняться этим правилам, а на выходе — функция, генерирующая заказанные данные
. Кроме того есть J и Брэйнфак. Они то уж точно будут лидеры по запутанности.
И что мы стобой спорил по этим вопросам столько времени? 
