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

AVK>Я про другое — ПМ + discriminated unions, если отбросить исторические корни, можно с равным правом отнести кака к ООП, так и к ФП, и совершенно непонятно, почему в ФП языках он уместен, а в ООП уже лишний.

Из-за принципа подстановки Лисков. Т.е., если ввести в язык алгебраические типы ака размеченные объединения, и они будут стоять где-то сбоку от ООП-возможностей языка — то можно, если же начнется наследование по ним наследование, напр. размеченные объединения будут представлять из себя иерархию классов (как в Nemerle), то получаем потенциальное нарушение инвариантов базового класса. Крайне неприятная мина в коде.

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

V>>Для паттерн матчинга недостаточно завести одну новую конструкцию языка, для удобного его использования нужны еще конструкции, типа placeholder '_', а это не так просто в плане совместимости с имеющимся кодом

AVK>Это как раз ерунда.

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

AVK>Куда сложнее с тем, что для полноценного PM нужны discriminated unions. А это уже сильное нелокальное изменение языка. Для чего нужна глобальная маркетологическая идея. Так что, ИМХО, не в этой жизни.

Мне показалось, что предполагается сделать как в Scala — матчить по типам и св-вам, и вот относительно первого повысказывался негативно тут рядом.

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

V>IDL непригоден? JavaScript, ShellScript, XSLT, ASN.1? Свой domain-specific конфиг на JSON непригоден? Будем считать — погорячился.

В твоем мозгу полнейшая каша относительно понятия DSL и ЯПОН. В твоем списке JavaScript — это ЯПОН, а остальное DSL-ли (опять же каша между внешними и внутренними).

Пока эта каша есть спорить с тобой о чем-то просто бесполезно.

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

Есть ЯПОН-ы и есть ДСЛ-и. Их нельзя сравнивать и тем более подменять в рассуждениях друг-другом.

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

Однако чем больше ЯПОН-ов используется в проекте тем сложнее этот проект в поддержке и развитии.

Использование нескольких ЯПОН конечно может быть оправдано, например, тем требованиями к производительности или наличием обширной кодовой базы на устаревшем языке, или тем, что на клиенте доступен другой язык (как это бывает в случае с JavaScript). Но использование нескольких языков ради чистоты концепций этих самых языков — это полнейший идиотизм. Ему нет никакого разумного оправдания. Вать машу! Haskell или F# — это вам не DSL-и!

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

AVK>>Это как раз ерунда. Куда сложнее с тем, что для полноценного PM нужны discriminated unions.

VD>"discriminated unions" — это локальный для ML-я псевдоним для алгебраический типов данных.

Это просто самый популярный способ реализации алг.т.д., т.к. единственно подходящий для строго-типизированных языков, хоть и не самый удобный в использовании.

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

V>В каждой методологии есть свои практики, которые позволяют писать достаточно надежные программы. Смешение практик приведет только к ухудшению надежности, в этом плане thesz категорически прав. Или же, (а почему бы и нет?) настало время для выработки новых практик для этой сборной солянки... В любом случае должно пройти достаточное время, больше чем кажется, ибо даже пока научных работ на эту тему не видно.

Настало. И есть не только научные работы, но и аж 3 современных полнофункцональных реализации гибридных языков (Nemerle, Scala и F#) и это если не считать, что даже C# стал почти функциональным.

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

V>>Вот именно, из детерминированного и элегантного языка превращается в непонятно что.

VD>Во как? Где это тут что-то куда-то превращается?

Элегантность была в однозначности конструкций. Это ушло.


VD>Это исходный дизайн языка. Никто не виноват, что пока не пришел Ников ни не прочел стандарт языка с пристрастием и не выявил такие вот неочевидности, никто из нас не их не замечал.
VD>Скажем, проблемы перегрузки и переопределения методов — это проблемы принятых еще в C# 1.0 решений.

Нет, спецификации и правила ресолвинга сигнатур ф-ий постоянно добавляются. У нас после перехода с 2.0 на 3.5 все прекрасно скомпилировалось без ошибок, но программа стала падать, из-за этих самых изменений. И что бесит, ни варнингов, ни ошибок — ничего. Аналогичный этюд про перегрузку Ников привел примерно год спустя, до этого кому не показывал код — все тоже были поражены, насколько неочевидно, и "втихую" все происходит по новым спецификациям.

А проблема была в весьма популярном сценарии про наследников BinaryWriter, где теперь надо прилично изгаляться, чтобы правильно вызывать методы базового класса, которые по обыкновению имеют одно и то же имя, что и методы в наследниках. В общем, теперь любой код, где есть много одноименных перегрузок, как метод Write в BinaryWriter, и имеющий наследников — это потенциальная и абсолютно незаметная мина.

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

VD>>Но вот сам код лексера, парсера, типизатора и генератора кода удобнее оформить в виде тех самых классов.

V>Вот и нет:
V>- лексер удобнее всего табличный на голом С, полученный из регулярной грамматики (не та, что перловая, а та, что класс грамматик);

А ну-ка накайтай-ка мне лексер Nemerle на этом своем чудо-средтве .
А если не сможешь, то в следующий раз будь поаккуратнее в высказываниях. ОК?

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

V>- парсер комбинаторный на любом ФП с обобщенными типами и явными их инстанциированиями;

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

V>- типизатор — однозначно логический, на прологе или чем-то похожем, ибо задача из области баз знаний и поиска решений (взаимно-рекурсивные альфа/бета редукции);

Да ну? О как? А пролог мы будем из комндной строки вызвать? Вот в Немерле Пролог, точнее подсистема унификации выделена в отдельный объект (класс). Получается очень удобно.

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

Вот незадача. Но код то нужно генерировать средствами SRE. А он имеет объектный интерфейс. Облом, да?

Можно узнать сколько компиляторов ты создал описанным тобой образом?

V>А в виде классов, или глобальный ф-ий или последовательности слов — вообще непринципиально.

Ваши функции очень быстро превратяться в кашу. ООП дает то чего нет в ФП — возможность проектировать приложения на более высоком уровне абстракций, оперируя классами и взаимодействием между ними, а не отдельными функциями. Классов получается в дестяки, а то и сотни раз меньше чем функций. И это спасает от разрыва мозга.

Так что свои сказки про ФП-ДСЛ-и оставьте при себе.

VD>>И было бы крайне глупо из-за этого писать компилятор на двух ЯПОН.

V>Я пять насчитал. На двух действительно глупо.

Это что же за язык написан на пяти языках?

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

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

Меня умиляют эти доморощенные теоретики путающие ДСЛ и ЯПОН, но с высоко задранной головой советующие окружающим чем им заняться и чему научиться.

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

Ну, и за одно продолжайте нести эту чушь оправдывая применение в одном проекте 25 языков общего назначения вроде C# и F# тем, что ДСЛ-и для некоторых задач рулят. Это конечно глупо, но если глупость повторять много раз с умным выражением лица, то многие могут в нее поверят.

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

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

AVK>>Я про другое — ПМ + discriminated unions, если отбросить исторические корни, можно с равным правом отнести кака к ООП, так и к ФП, и совершенно непонятно, почему в ФП языках он уместен, а в ООП уже лишний.

V>Из-за принципа подстановки Лисков. Т.е., если ввести в язык алгебраические типы ака размеченные объединения, и они будут стоять где-то сбоку от ООП-возможностей языка — то можно, если же начнется наследование по ним наследование, напр. размеченные объединения будут представлять из себя иерархию классов (как в Nemerle), то получаем потенциальное нарушение инвариантов базового класса. Крайне неприятная мина в коде.

Все проще. Можно несколько подкорректировать принципы которые были выработаны в других условиях.

АлгТД и ПМ по духу принципам Лисковой не противоречат. По букве, да. Но букву можно и подправить.

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

VD>Эта фраза имеет смысл только если подразумевать, что этот самый универсальный язык — это язык общего назначения, а те языки что лучше — это специализированные языки (т.е. не общего назначения).

Именно.

VD>Иначе таки, нет — универсальный язык таки может быть лучше для всех задач чет другой универсальный язык.

Наверно хотел сказать "чем другой неуниверсальный"? Согласен, банальность.


VD>Единственное что еще приходит на ум — это намеренное использование более низкоуровневых языков с целью оптимизации производитльности.

VB 6.0 более низкоуровневый, чем С/С++? Однако, он генерит гораздо лучший код для работы с COM-объектами, эффективно удаляя лишние пары AddRef/Release и лишние QueryInterface (если замечено преобразование к базе, или к тому же типу), чего не могут делать люди ни вручную, ни с помощью разных com_ptr<>. Так же автоматически кеширует для типов результаты вызовов методов IDispatch при динамическом запросе DISPID и прочее, прочее, прочее. В общем, специализированный тул, он и в Африке специализированный. (Кстати, он и обычную арифметику и все внутренние вызовы тоже неплохо оптимизирует, не намного хуже С/С++, на нем еще те числобробилки делать можно, и удобнее гораздо)


V>>А как же популярность Явы?

VD>А что в Яве нет дженириков или она вообще не изменялась за время существования?
VD>Ява 1.0 действительно мало для чего серьезного пригодна.

V>>Мы когда смотрели ее спецификации в 95-м, тоже ухахатывались, за животы держались.. а оно вон как вышло, кто бы мог подумать.

VD>А ты сравни эту спецификацию со спецификацией современной.

Разбежался.
До второго дотнета там ничего в плане языка не происходило, т.е. десяток лет застоя и все её хвалили. Надо было раньше шевелиться.


VD>К тому же в лагере явы тоже не стоят на месте. Там уже есть такие языки как Clojur, Groovy и конечно же Scala!

Спустя 15 лет существования платформы что-то есть в бета-версиях. Несомненный успех.


V>>Именно, только в конце приписать надо "для каждой конкретной задачи". Чем более специализирован язык, тем он проще и тем сложнее ошибиться программисту.

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

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


VD>По твоему, скажем, F# более специализированный нежели C#? Или как понять твои слова?

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

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

V>Элегантность была в однозначности конструкций. Это ушло.

Ты высосал ее из пальца. Подобные проблемы были в шаре всегда.

V>Нет, спецификации и правила ресолвинга сигнатур ф-ий постоянно добавляются.

Ага. Но исходные проблемы идут из 1.0. Правила для params с тех пор вообще не менялись.
Правила выбора перегрузки и переопределения все родом из 1.0. Почитай этот стандарт так как это делает Ников и поймешь, что ты не прав.

V>У нас после перехода с 2.0 на 3.5 все прекрасно скомпилировалось без ошибок, но программа стала падать, из-за этих самых изменений. И что бесит, ни варнингов, ни ошибок — ничего. Аналогичный этюд про перегрузку Ников привел примерно год спустя, до этого кому не показывал код — все тоже были поражены, насколько неочевидно, и "втихую" все происходит по новым спецификациям.

Сдается мне ты выдумываешь. Да... и 2.0 и 3.5 — это ведь не версии C#, правда?

V>А проблема была в весьма популярном сценарии про наследников BinaryWriter, где теперь надо прилично изгаляться, чтобы правильно вызывать методы базового класса, которые по обыкновению имеют одно и то же имя, что и методы в наследниках. В общем, теперь любой код, где есть много одноименных перегрузок, как метод Write в BinaryWriter, и имеющий наследников — это потенциальная и абсолютно незаметная мина.

Ну, то есть проблема была в библиотеке?

Покажи что изменилсь в Шарпе, что привело к проблеме.

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

VD>>Иначе таки, нет — универсальный язык таки может быть лучше для всех задач чет другой универсальный язык.

V>Наверно хотел сказать "чем другой неуниверсальный"? Согласен, банальность.

Нет. Что хотел, то и сказал. А ты просто в софистике упражняешься.

V>Просто есть уже отработанный метод относительно безопасного получения "мощности" языка для специальных задач. Надеюсь, понятие "мощности" применимое к ЯП для всех присутствующих означает степень его выразительности, т.е. мы об одном и том же?

ОК.

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

В такой терминологии обсуждение смысла не лишено. Но, плиз, больше не упоминай ДСЛ-и. Иначе твой слив будет засчитан в автоматическом режиме. ОК?

VD>>По твоему, скажем, F# более специализированный нежели C#? Или как понять твои слова?

V>Каждый из них более специализирован относительно другого, примерно так. Но они оба разработаны как языки общего применения, поэтому пример не очень удачный.

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

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

V>Просто до сих пор все изменения зыка были не ломающими предыдущий код.

Не все. Как минимум были изменения overload resolution, которые могли потенциально старый код сломать.

V>Мне показалось, что предполагается сделать как в Scala — матчить по типам

Конструкция typeswitch возможно когда нибудь и появится.

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

V>Скажу так, нормально делать сборки "миниатюрного" размера, тогда пофиг, на чем было написано это дерево, и каким языком ты его будешь обрабатывать. Миниатюрность сборок очень хорошо ведет себя при постоянном обновлении, через тот же click-once, закачивая каждый раз лишь минимум, и не раздражая клиента при запуске.

Хм, не могу разглашать источники информации, но оптимальным размером сборки является 300Кб-3Мб.

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

V>Я пять насчитал. На двух действительно глупо.
Браво. А теперь расскажи, как ты собираешься эти пять языков друг в друга вкрячивать, чтобы получить рабочее решение, где будешь проводить границы взаимодействия и как будешь весь этот зоопарк рефакторить, перенося логику из одного языка в другой, если вдруг поначалу промазал?

Ты там выше, очень верно заметил, что не смотря на то, что лучше SQL-я для БД ничего не придумали, на лицо явная тенденция перетащить сиквельную часть в C#. Потому что удобно делать все в одном языке, а не в специализированых.

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

V>Какие глупости пишешь...
Сам ты глупости пишешь. Я как раз привел пример задачи, часть которой никак не ложится на ООП, а часть очень даже наоборот. Теперь жду решения. Только практического, а не теоретического.

V>Понимаешь, случай с AST как раз тот самый, когда соверешенно не получается породить гомоморфную иерархию, и мадам Лисков идет таким лесом, что дальше просто не куда... а значит о чистом ООП можно даже не заикаться.
То есть задачи, которые не укладываются в гомоморфную иерархию для ООП не годятся, так?
А что годится для этих задач? И что делать, когда обработка этой иерархии лучше всего получается на ООП?

V>Сам по себе матчинг по типам (!!!) противен духу ООП (а только по значениям это будет недоматчинг).
Противен он духу — или нет, отдельный вопрос. Наследование тоже противно духу ООП, так как тоже позволяет нарушить Лисковский принцип, на который ты напираешь, но никого это не смущает ни в одном месте.
Но в данном случае мне это теоретизирование совершенно пофиг. Понимаешь, я прекрасно знаю, что такое ООП и границы его применимости, проблема в том, что я хочу, чтобы мой инструмент не ограничвался рамками ООП.
И на данный момент, стереть границу между парадигмами проще в рамках одного языка, а не в рамках целой платформы на разных языках. Я вижу и знаю, как это может работать в одном языке, но у меня нет идей, как такой же гибкости получить в рамках одной платформы — у тебя есть?

V>На уроках по ООП за это ставят двойки, поэтому не все так просто и поэтому не так просто внести в чистую ООП-среду ФП заморочки.
Я примерно представляю, кто на этих уроках ставит двойки, но к счастью, мы не на уроке и решать надо не учебную задачку, по условию, в рамках ООП, а сугубо практическую, наиболее подходящим для этого инструментом.
Нет никакх проблем ввести в "типа ООП" язык ПМ или какой-нибудь его более упрощенный аналог, более того ПМ-а в шарпе мы вряд ли дождемся в обозримом будущем, но что-нибудь по проще скорее всего появится.

V>Ты хоть представляешь, что сделал бы с Хейлсбергом научный мир IT за такие фокусы? Да разорвал бы как тузик грелку, опустил бы ниже плинтуса.
Хэйсбергу покласть на научный мир. Он делает языки не для научного мира, а для прикладных разработчиков — массовые языки, понимаешь?

V>В каждой методологии есть свои практики, которые позволяют писать достаточно надежные программы. Смешение практик приведет только к ухудшению надежности, в этом плане thesz категорически прав.
По мере добавления ФП в шарп, надежности только прибавляется, так что пока это утверждение противоречит практике.

V> Или же, (а почему бы и нет?) настало время для выработки новых практик для этой сборной солянки... В любом случае должно пройти достаточное время, больше чем кажется, ибо даже пока научных работ на эту тему не видно.
Вот Nemerle, как раз и был такой научной работой.

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

Влад прав, ты валишь в одну кучу языки общего назначения заточенные под одну парадигму (ООП, ФП) и DSL-и, от этого у тебя и такая каша.

V>IDL непригоден? JavaScript, ShellScript, XSLT, ASN.1? Свой domain-specific конфиг на JSON непригоден? Будем считать — погорячился.
Это ты конкретно погорячился. JS — это язык общего назначения, довольно неплохо заточеный под скрипты и мало пригодный для всего остального, что и определяет его узкую нишу и сидит он в ней исключительно потому, что устанешь переделывать зоопарк современных браузеров подо что-нибудь другое. Остальное — это вообще ДСЛ-и, которые не имеют никакого отношения к теме ООП-ФП.
Под неуниверсальными языками я имел ввиду SmallTalk, Haskell, etc.. Да, вот это безусловно чисто ООП или ФП, только что-то массово на них никто не пишет — неудобно.

V>Скажу так, нормально делать сборки "миниатюрного" размера, тогда пофиг, на чем было написано это дерево, и каким языком ты его будешь обрабатывать. Миниатюрность сборок очень хорошо ведет себя при постоянном обновлении, через тот же click-once, закачивая каждый раз лишь минимум, и не раздражая клиента при запуске.
Блин. Какая разница как это деплоится. Меня волнует, как ты будешь код поддерживать и рефакторить таская его по разным сборкам на разных языках, когда у тебя часть логики в одном, часть в другом и неизвестно по какому принципу их разделять. Хорошо, когда у тебя есть отдельная, явно выделенная задача, которую можно независимо выделить в отдельный проект, но так бывает далеко не всегда.
Подозреваю, что как раз у тебя все ограничивается тем, что все проекты хорошо бьются на мелкие простые сборки и от этого у тебя такая радужная иллюзия отностительно проектов на нескольких языках.

V>Да ладно, до Явы и дотнета были Дельфи и VB/VBA, которые по количеству приложений на них затыкали всех за пояс (VB у них, Дельфи у нас). Это же были основные инструменты для бизнес-приложений. Эти и несколько других, долгое время тоже весьма популярных, типа FoxPro, 1С и т.д. тоже не особо ФП похвастать могут. Так что и тут ты погорячился.
Вот именно, это были не ООП-only языки, а такие же универсальные лошадки, как сейчас Ява или Шарп, так что это ты опять мимо кассы.

V> И это все равно не повысило надежность программ на C# до уровня программам на VB, FoxPro, 1C автоматически.
Ты опять путаешь языки общего назначения и DSL-и, про DSL-и отдельный разговор. И ко всему прочему ты еще не учитываешь, что сложность современных задач существенно выше того, что писалось на древнем VB и современное приложение написанное на шарпе, с такой же надежностью, ты устанешь на том VB пистать.

V>Программы на C# до сих пор сыпятся как семечки, достаточно пройтись по тому же codeproject. Видел ли ты хоть раз, чтобы так же сыпались программы на вышеупомянутой тройке? То-то...
Во-первых — нашел где ходить, а во-вторых — да, видел как сыпались и сыпались еще и не так. То-то.

V> Или может, стоит посадить специалистов в предметной области и дать им соответствующий инструментарий?
Еще раз, не путай DSL и языки заточенные под ООП-ФП парадигму. Или ты считаешь есть специалисты в ООП предметной области и ФП предметной области?

V>Мне пока очевидно, что если речь не идет об internal членах этого дерева, что разницы нет, из нашей сборки мы его вызываем, или из другой, с использованием другого языка.

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

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

V>>Из-за принципа подстановки Лисков. Т.е., если ввести в язык алгебраические типы ака размеченные объединения, и они будут стоять где-то сбоку от ООП-возможностей языка — то можно, если же начнется наследование по ним наследование, напр. размеченные объединения будут представлять из себя иерархию классов (как в Nemerle), то получаем потенциальное нарушение инвариантов базового класса. Крайне неприятная мина в коде.

VD>Все проще. Можно несколько подкорректировать принципы которые были выработаны в других условиях.

Без комментариев.


VD>АлгТД и ПМ по духу принципам Лисковой не противоречат.

Конечно не противоречит. Противоречит лишь их эмуляция на наследовании. Кстати, в Немерле типы-члены АТД запечатаны вроде, т.е. по ним нельзя далее наследоваться? Если так — то это та самая перестраховка, т.е. хотя и используется механизм наследования, в этот механизм нельзя вмешаться извне и навредить. Если же ввести паттерн-матчинг по произвольным иерархиям типов — то будет бардак.


VD>По букве, да. Но букву можно и подправить.

Ага, и Деды морозы бывают, и русский "авось" — тоже парадигма.

ИМХО, бесполезно править "букву", описанное правило подстановки и негативные эффекты не самоуничтожатся волшебным образом, как не изменятся по нашему желанию законы окружающей действительности. Любой алгоритмический if по типам добавляет лишний шанс для нарушения инвариантов, нравится тебе это или нет, подходит это для какой-то новой фичи, или нет. Конечно, не факт, что это будет причиной ошибки, это лишь дополнительное повышение ее вероятности ввиду того, что стройная иерархия типов, помощь компилятора и прочие бенефиты реализации ООП в системе строгой типизации исчезают, добавляя тебе необходимости "ручного" контроля за происходящим.

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

Мне иногда приходится искать ошибки не только в своем коде, но и в "трудных случаях" ошибок у коллег. Так вот, если отбросить всякие "семечки", типа ошибок аргументов, недописанный if и т.д. которые находятся мгновено через юнит-тесты, Debug.Assert() и просто выскакивающие эксепшены, остальная часть ошибок, из тех, что действительно добавляют хлопот и требуют времени на поиск — это поведение программы не согласно ожидаемому и полная неочевидность таких причин. Практически всегда вот эти ошибки, требующие времени для своей локализации, связаны с нарушением инвариантов, и обычно решаются лишь "небольшим" перепроектированием иерархии. Я вот когда с Wolfhound спорил по поводу зависимых типов, то исходил именно из того, что ошибки выхода за диапазон легко находятся, в отличие от более сложных ошибок, которые возникают как "наведенные эффекты". Тут просто нельзя оставлять простора для наведения этих эффектов, и принцип подстановки Лисков нам в помощь.

Тут не зря AVK (и не только) постоянно озвучивает, что наследование реализаций — зло, достаточно наследования интерфейсов. Настолько крайне я утверждать не могу, не "зло", конечно, ИМХО очень удобный, но и на столько же опасный сам по себе инструмент, требующий определенных правил при использовании.

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


V>>IDL непригоден? JavaScript, ShellScript, XSLT, ASN.1? Свой domain-specific конфиг на JSON непригоден? Будем считать — погорячился.

VD>В твоем мозгу полнейшая каша относительно понятия DSL и ЯПОН. В твоем списке JavaScript — это ЯПОН, а остальное DSL-ли (опять же каша между внешними и внутренними).

А в этой подветке речь шла о DSL??? Че-то тебя заносит малость. Речь шла об универсальных и неуниверсальных языках. Я привел пример неуниверсальных, но тоже популярных.

VD>Пока эта каша есть спорить с тобой о чем-то просто бесполезно.

А ты так не носись по веткам, и не будет в голове каши.

VD>Есть ЯПОН-ы и есть ДСЛ-и. Их нельзя сравнивать и тем более подменять в рассуждениях друг-другом.

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


VD>Использование нескольких ЯПОН конечно может быть оправдано, например, тем требованиями к производительности или наличием обширной кодовой базы на устаревшем языке, или тем, что на клиенте доступен другой язык (как это бывает в случае с JavaScript). Но использование нескольких языков ради чистоты концепций этих самых языков — это полнейший идиотизм. Ему нет никакого разумного оправдания. Вать машу! Haskell или F# — это вам не DSL-и!

Да почему ты упорно в эту сторону идешь? Да и что за косность мышления и чеканство глупых правил?
Знаешь, почему удобно автоматизировать офис именно на VB.Net, а не на C#, хотя оба они являются ЯПОН, да еще практически с идентичными характеристиками? Просто 90% кода этой автоматизации можно создать как запись макрокоманды при "живом" оперировании офисом, и затем скопировать эти макросы практически без изменений в свой код, оставив для ручной работы лишь создание/открытие/сохранения и биндинг/подстановку данных, коли они есть. Или почему используется CLI/C++, хотя он тоже не DSL, я думаю, ответ ты должен хорошо представлять и без меня.

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

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

V>Я вот когда с Wolfhound спорил по поводу зависимых типов, то исходил именно из того, что ошибки выхода за диапазон легко находятся, в отличие от более сложных ошибок, которые возникают как "наведенные эффекты".
Мы кажется уже выяснили что ты спорил со мной не понимая что такое зависимые тыпы...

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

V>>Скажу так, нормально делать сборки "миниатюрного" размера, тогда пофиг, на чем было написано это дерево, и каким языком ты его будешь обрабатывать. Миниатюрность сборок очень хорошо ведет себя при постоянном обновлении, через тот же click-once, закачивая каждый раз лишь минимум, и не раздражая клиента при запуске.

AVK>Хм, не могу разглашать источники информации, но оптимальным размером сборки является 300Кб-3Мб.

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

Я лишь упомянул из своего богатого опыта с click-once, что маленькие сборки это порой очень удобно. Конкретно у нас, основные "системные" сборки, т.е. те, что редко меняются — как раз по 200-400k, а прикладные, которые обновляются активно — по 20-50k, и это очень удобно. Тут разумный компромисс м/у временем скачивания обновлений и временем старта приложения после всех обновлений. И тут оптимальный размер сборок диктуется популярными доступными скоростями интернета, и больше ничем.