Tcl как обоснование ненужности поддержки компонентности в С++ - Философия программирования

Здравствуйте, VladD2, Вы писали:
VD>Ты не верно интерпретируешь понятие "паттерн".
Верно.
VD>По-моему, паттерн — это некий стандартный способ эмуляции некоего подразумеваемого поведения или свойства. Так что если в языке свойство есть, то это уже не паттерн, а часть спецификации языка. А вот если его нет и его приходится эмулировать через некий набор действий (подход) или некий эмулирующий его код, вот тогда это паттерн.
И чем это противоречит моему определению? Влад, "его нет" в большинстве мейнстримовых языков. А в тех, которых есть, оно почему-то реализовано существенно по-разному. Например, в Delphi определялось отображение свойства на независимо существующие методы и поля. В шарпе уже ничего такого нет. Что из этого является свойством? Кроме того, в Delphi есть вшитая реализация паттерна Factory. Ты, я надеюсь, не предлагаешь под этим предлогом выкинуть этот паттерн из всех учебников и заменить его ссылкой на virtual constructor?

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

VD>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.
Совершенно верно.
VD>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык.
На 100% согласен.
VD>В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.
Даже на 150%. Вообще возникает вопрос: а стоит ли встраивать в язык все известные паттерны? Не сделает ли это язык громоздким и неудобным в изучении? С одной стороны, новые паттерны появляются не так уж часто. С другой стороны, они все же появляются, и гораздо удобнее иметь язык, готовый к адаптации этих нововведений готовыми средствами. С третьей стороны, именно этим и руководствовался комитет С++

VD>Вопрос только в качестве и простоте этого изменения

1.1.4 stable rev. 510

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

S>Даже на 150%. Вообще возникает вопрос: а стоит ли встраивать в язык все известные паттерны? Не сделает ли это язык громоздким и неудобным в изучении? С одной стороны, новые паттерны появляются не так уж часто. С другой стороны, они все же появляются, и гораздо удобнее иметь язык, готовый к адаптации этих нововведений готовыми средствами. С третьей стороны, именно этим и руководствовался комитет С++

Но реализовать это смогли польские студенты.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

FR>>Для парсера на ФЯ там слишком много internal mutable

VD>И тем неменее это парсер на ФЯ в котором нет ни одного Посетителя и от этого только проще становится. Так что ход неудачный. Гейм овер.

mutable убивает ФЯ. Так что ФЯ там и не пахнет, просто императивный язык с патерн матчингом.

VD>А вообще свои догмы нужно разрушать. Чистых ФЯ практически нет. Хаскель, Схема... что там еще? Все остальные ФЯ поддерживают императивные возможности, но ФЯ от этого быть не перестают.

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

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

FR>Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

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

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

Свойством является свойство. А разница наблюдаемая тобой — это разница в синтаксисе языков. Функции ты тоже по разному описываешь в разных языках. Ты же не считашь при этом функцию паттерном?

S> Кроме того, в Delphi есть вшитая реализация паттерна Factory. Ты, я надеюсь, не предлагаешь под этим предлогом выкинуть этот паттерн из всех учебников и заменить его ссылкой на virtual constructor?

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

Или уж тогда давай говорить, что все конструкции языка — это паттрены. Паттрен if, паттерн switch, паттерн "+"... А что? Для ассемблера или, к примеру, Форта это действительно будут паттерны проектирования. Ну, а для Немерла, например, исчезает паттерн проектирования Посетитель.

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

И if, как я уже сказал, можно реализовать на Ассемблере. Но ты же не оперируешь с ним как с паттерном? И не делашь ты это только потому, что if на языке высокого уровня для небя не паттерн, а первоклассаная операция. Точно так же свойство для тебя первоклассная сущность и думаь о нем как о паттерне прото неразумно. Нет главной составляющей паттерна "repeatable solution to a commonly-occurring problem" так как нет самой проблемы. Она становится тривиальной и описывается тривиально. То етсь нет ни проблемы, ни решения. Есть просто синтаксическая конструкция.

VD>>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.
S>Совершенно верно.
VD>>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык.
S>На 100% согласен.

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

VD>>В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.
S>Даже на 150%. Вообще возникает вопрос: а стоит ли встраивать в язык все известные паттерны?

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

S> Не сделает ли это язык громоздким и неудобным в изучении?

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

Хотя понятие громоздкость плохо детерминировано. Возможно луче подходит термин "выразительность".

С точки зрения кривой обучения вопрос не столь очевиден. Потяно, что чем больше понятий впитал в себя язык тем сложнее его выучить. Но тут играет роль то, что для начальной стадии обучения все потятия могут оказаться не нужны. Меж тем те же приемы описанные в ГоФ являются пожалуй необходимым минимумо и хороший программист о них должен знать. И я не вижу ничего плохого если им будет придана краткая и простая форма.

S> С одной стороны, новые паттерны появляются не так уж часто. С другой стороны, они все же появляются,

Очень редко. Но другое дело что есть прикладные паттерны. Вроде тех что хотят охватить в LINQ. Вот их действительно масса и для них действительно лучше иметь расширяемый язык. Но именно расширяемый язык, а не отверстие в заднем проходе.

S> и гораздо удобнее иметь язык, готовый к адаптации этих нововведений готовыми средствами. С третьей стороны, именно этим и руководствовался комитет С++

Не, они этим отмазываются. А сам С++ имеет только одно штатное средство расширения — свои убогие макросы. Все остальное через зад. Результат соотвествующий.

Так что дух в С++ правильный, а вот реализация ни к черту.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

FR>>Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.

VD>Это пустобрехство. ОКамл ничем не отличается от Немарал и писать на нем можно как угодно. Если пимеративный вариант оказывается быстрее и/или понятнее/удобнее, то его игнорирование и демонстративное предпочтение функционального стиля является пижонством и глупостью.

Тогда не надо было про ФЯ заявления делать.

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

Только от этого паттерны и польза от них не исчезают.

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

FR>mutable убивает ФЯ. Так что ФЯ там и не пахнет, просто императивный язык с патерн матчингом.
Очередное безответственное заявление. В таком случае "неубитые" ФЯ можно буквально пересчитать по пальцам(практически всем критериям неубитости соответсвует только Haskell). На самом деле во всем мире используется такая терминология как pure functional и non-pure functional. Так вот Nemerle это non-pure functional language, так же как и OCaml.

FR>Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.
Что значит "нормальный"? Громадное количество кода на OCaml в таком случае это ненормальный код или как(включая код из стандартной библиотеки)? Я например видел парсеры на OCaml в которых было очень много императивного. С какой стати это ненормально?

На Nemerle тоже можно писать код не использующий императивные возможности, в том числе и парсеры, с неменьшим успехом чем на OCaml. Только это уже фанатизм, а Nemerle создавался не как язык для фанатов ФП.

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

FR>>Только нормальный код на ФЯ не использует императивные возможности, например я видел парсер на Ocaml, там не было ничего императивного.
VK>Что значит "нормальный"? Громадное количество кода на OCaml в таком случае это ненормальный код или как(включая код из стандартной библиотеки)? Я например видел парсеры на OCaml в которых было очень много императивного. С какой стати это ненормально?

Нормально только это уже не ФЯ а ИЯ.
Вот у меня в одном проекте на питоне процентов 60 кода функционально, но я бы не стал его приводить как пример ФЯ.

VK>На Nemerle тоже можно писать код не использующий императивные возможности, в том числе и парсеры, с неменьшим успехом чем на OCaml. Только это уже фанатизм, а Nemerle создавался не как язык для фанатов ФП.

Так я не против пишите как удобно.

Вообще разговор про ФЯ начался с того что Влад мне предложил найти хоть один паттерн посетитель в коде гипотетического парсера на ФЯ (подерживающим паттерн матчинг). Я ему предложил найти там хоть один объект (так как паттерны сильно привязаны именно к ООП). После чего был предложен код на Nemerle не имеющий никакого отношения к ФЯ. Давай теперь из этого будем раздувать ФЯ vs ИЯ, предлагаю еще добавить сюда же еше и safe vs unsafe для полного комплекта.

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

FR>Тогда не надо было про ФЯ заявления делать.

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

Забавно, что я лично выбрасывал функциональные навороты в Немерлевом коде только потому, что они были более громоздкими и непонятными нежели императивный аналог. Например, я как-то написал код испльзующих метод Fold для фильтрации содержимого массива (выборки ненулевых элементов), а потом заменил его на foreach с if-ом так как это оказалось проще и понятнее.

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

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

FR>Только от этого паттерны и польза от них не исчезают.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

FR>>Тогда не надо было про ФЯ заявления делать.

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

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

VD>Все что я тебе тут сказал верно. Немерле это ФЯ и в основном код его компилятора тяготеет к ФС. И в его компиляторе нет ни одного Посетителя. Но ты совершенно прав в том аспекте, что нет Посетителей не потому, то немерле ФЯ, а потому что в нем есть мощьный паттерн-матчинг делающий примененение паттерна Посетитель неразумным. Вот только другие ФЯ я привел исключительно из-за того, что паттерн-матчинг есть исключительно в ФЯ. Собственно сам Немерле это ФЯ. Просто в очередной раз ты не верно понимашь терминлогию.

Ладно здесь я заспорился, но ты тоже невнятно формулировал свои мысли. Терминологию я вполне нормально понимаю, просто тебе не надо было про ФЯ говорить, сказал бы только про паттерн матчинг.

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

VD>Забавно, что я лично выбрасывал функциональные навороты в Немерлевом коде только потому, что они были более громоздкими и непонятными нежели императивный аналог. Например, я как-то написал код испльзующих метод Fold для фильтрации содержимого массива (выборки ненулевых элементов), а потом заменил его на foreach с if-ом так как это оказалось проще и понятнее.

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

VD>Так что тыкание пальцем в императивные куски и крики о нефункциональности это или фанатизм, или банальное лицимерие. В данном же случае — это неудачная попытка найти аргументы в пользу ложной позиции.

Да ладно

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

FR>>Только от этого паттерны и польза от них не исчезают.

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

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

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

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

Ненадо, я привел пример четко опровергающий теорию вездесущьности паттернов.

FR>Ладно здесь я заспорился, но ты тоже невнятно формулировал свои мысли. Терминологию я вполне нормально понимаю, просто тебе не надо было про ФЯ говорить, сказал бы только про паттерн матчинг.

Хм. Какие проблемы? Я сказал то что есть на самом деле. Я не виноват, что паттерн-матчинг родился в ФЯ. И в том что Немреле по стечению обстоятельств тоже ФЯ, хотя и не чистый (как и 90 других ФЯ).

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

Дык я и не пытаюсь этому возражать. Просто по жизни бывают разные случаи. Когда-то удобно одно, когда-то другое. А вот догмы вроде ФС форева они и есть догмы.

FR>Не единственный есть еще мультиметоды и замена посетителя на замыкания и рекурсию.

Мультиметодов практически нигде нет. Разве что в эксперементальных реализациях. Рельно они есть в Клосе, но он сам по себе основан на Лиспе и откровенно говоря стоит очень далеко от классических концепций ООП. Уж точно сильно дальше чем Смолток или Питон.

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

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

ЗЫ

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

FR>Нормально только это уже не ФЯ а ИЯ.

Рекомендую в comp.lang.functional создать тему "OCaml is not a functional programming language" и посмотреть на ответы.

FR>Вот у меня в одном проекте на питоне процентов 60 кода функционально, но я бы не стал его приводить как пример ФЯ.

Nemerle к сожалению(к моему) как и OCaml пропагандирует именно ФП. Предпочтение отдаваемое неизменяемым значения, неизменяемым полям объектов по умолчанию(и как следствие объектам без состояния), отсутствию циклов как таковых(имеется в виду core language, без стандартных макросов), отсутствию return, неизменяемым односвязным спискам как доминирующей структуре данных говорит именно об этом. С Питоном ситуация совершенно противоположная. В Nemerle императивное программирование это всего лишь опциональная возможность. Была бы моя воля я бы внес в язык послабления для императивного программирования(например поменял бы ключевое слово mutable на var, перенес бы макросы return, continue и break из пространства имен Nemerle.Imperative в глобальный контекст, сделал паттерн-мэтчинг для любых коллекций, задвинул односвязные списки на задний план и подумал бы о частичной(или полной) замене их в коде компилятора на что-то еще, сделал бы кортежи опционально изменямыми и так далее)

А в данный момент Nemerle не нравится и большинству фанатов ФП, и большинству законченных мэйнстримщиков, которые дальше Java, C# и C++ ничего не видят. Я думаю не в последнюю очередь из-за такой немотивированной любви разработчиков к функциональному программированию. Меньше нужно было делать реверансов в сторону ФП, все равно фанатов ФП меньшинство и у Nemerle все равно нет шансов в этой нездоровой, в основном академической среде. Т.е. вся функциональные возможности которые есть в Nemerle должны там быть, но дизайн и особенно синтаксис языка не должен навязывать функциональное программирование в той степени, как это сделано сейчас. Но сейчас я думаю это уже невозможно изменить, так как дизайн самого языка теперь более менее стабилизировался и развивается в основном только компилятор.

Поэтому я думаю первыми гибридными мэйнстрим языками возможно будут Fortress и C# 4.0(если он вообще будет; в последнее время я даже сомневаюсь в судьбе C# 3.0), и будет это очень не скоро. У Nemerle мало шансов стать мэйнстрим языком. Зато вероятен переход разработчиков языка на работу в Microsoft Research, может быть они будут работать и над C# 4.0, или косвенно на него повлияют.

FR>Я ему предложил найти там хоть один объект (так как паттерны сильно привязаны именно к ООП).

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

FR> После чего был предложен код на Nemerle не имеющий никакого отношения к ФЯ.

Мне кажется ты путаешь ФЯ и ФП. Согласен, к функциональному программированию предложенный фрагмент кода имеет мало отношения. Компилятор Nemerle вообще написан в очень смешанном стиле, но однозначно сказать чего там больше нельзя. Там очень много такой хардкорной функциональщины, которая ни в каком императивном языке просто невозможна. Если бы разработчики как раз придерживались принципов ООП, возможно код был бы и лучше и чище.

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

VD>Все равно как ассемблерщик пересевший на С и видящий за кадой командой С набор ассемблерных инструкций.

Ассемблершик? Ха! Я по образованию — радиоинженер, и компрьютеры начиал изучать с распиленных попалам микросхем. Так что мне не чужды не только ассемблерные инструкции, но и то, как они бегают по шине и считаются во всяких АЛУ. И тот же твой паттерн-матчинг, что бы его начать эффективно использовать, придётся сначала разобрать на запчасти, подуть внутрь, понять физику процесса и собрать обратно. По другому никак

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

ГВ>>Не уходи от ответа. Ну так что, обоюдно укорачиваем языки? Ты — на "фобии", "фанатизм" и прочее подобное, я — на ответные обвинения в паталогической неспособности к C++ (сиречь — необоснованные обвинения в некомпетености)? Ы?

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

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

VD>А что до фобий. Что вижу о том и говорю. Если вижу ничем не оправданные домыслы и паталогическую боязнь чего-то то и говорю — фобии.

...рассуждая сугубо логически, легко прийти к выводу, что ты, VladD2, сам полон фобий и фанатизма. Отсюда следует, что нельзя доверять субъектным характеристикам (всему спектру: от "боязни" до "МДП"), даваемым тобой, например, мне.

Рассуждение очень простое.

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

Поэтому экономичнее пойти слегка некорректным, но по-житейски логичным путём: перенести такие субъектные характеристики на того, кто их употребляет. Раз кто-то говорит "фобия!", значит, его "диагноз" является следствием того, что он сам этих фобий полон. Раз бросает в чей-то адрес "фанатик", значит сам является фанатиком. Ведь действительно, что-то же не даёт спорщику сосредоточиться на ratio, которое предъявляют оппоненты и продолжать извергать потоки домыслов? Исходя из принципа исключения лишних сущностей ответное рассуждение ограничивается характеристиками, явно сформулированными атакующим. В твоём случае это "фобии", "фанатизм", "боязнь". Здесь, кстати, важно не вносить дополнительных характеристик и не пускаться в квазипсихологию, дабы не уподобиться. Поэтому — бритва Оккама.

Смягчения ради можно допустить, что ты просто ругаешься. Кстати, как правило, твои оппоненты реагируют на твои высказывания так, как принято реагировать на ругань, если нет желания обострить конфликт: с той или иной степенью иронии. Но судя по всему, называть это просто руганью не правильно. Если бы ты просто ругался, то не стал бы настаивать на том, что: "вижу... паталогическую боязнь чего-то...", не стал бы подводить основания под свои диагнозы. Ergo — см. выше.

Короче, есть некая мудрость в этом стишке:

Строг закон самурая:
Кто произносит обидное слово,
Сам называется так.

(c) не-помню-чей.

P.S.: Но это всё не относится к сугубо объектным и объективным рассуждениям: замерам скорости, сравнениям языков и т.п. Ключевое слово: "субъект".

<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>

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

VD>"В большинстве" это явное преувеличение.
Увы.
VD> Но это по сути не важно. Главное, что есть языки (пофигу мэйн-они-стрим или еще что) в которых свойство это первоклассная сущьность. И применять некий паттерн для их реализации нет смысла.
Нет, Влад. Как раз главное — то, что есть языки, в которых свойства НЕТ.
S>> А в тех, которых есть, оно почему-то реализовано существенно по-разному. Например, в Delphi определялось отображение свойства на независимо существующие методы и поля. В шарпе уже ничего такого нет. Что из этого является свойством?

VD>Свойством является свойство. А разница наблюдаемая тобой — это разница в синтаксисе языков.
Хрен там. Еще и семантика отличается. К примеру, в шарпе нельзя замапить свойство напрямую на поле, а в Delphi — можно. И у него еще и адрес можно будет взять!
VD>Функции ты тоже по разному описываешь в разных языках. Ты же не считашь при этом функцию паттерном?
Ну конечно же считаю! Просто сейчас это настольно популярный паттерн, что тяжело найти язык без функций. Впрочем, есть и пример: bat-файлы. В них функции не встроены, и приходится их эмулировать при помощи определенной последовательности действий. Т.е. имеем паттерн.
S>> Кроме того, в Delphi есть вшитая реализация паттерна Factory. Ты, я надеюсь, не предлагаешь под этим предлогом выкинуть этот паттерн из всех учебников и заменить его ссылкой на virtual constructor?

VD>А причем тут учебники? Для дельфи существует понятие метакласса и говоря в терминах дельфи смысла в использовании паттерна фабрика действительно нет.
Влад, я тебя разочарую: в Delphi паттерн "фабрика" используют чаще, чем где бы то ни было (кроме, разве что, COM). Просто Delphi делает его применение а)простым б)удобным и в) контролируемым компилятором. Но паттерн никуда не девается.
VD>Ты конечно можешь оперировать паттерном фабрика просто ради того, что бы определить дизайн приложения в срассчете на самый убогий язык из некоторого списка.

VD>Или уж тогда давай говорить, что все конструкции языка — это паттрены.
Совершенно верно. Ну, не все...
VD>Паттрен if, паттерн switch,
Ветвление как ращ уж очень фундаментальная конструкция для программирования, ее сложно объявить паттерном.
VD>паттерн "+"... А что? Для ассемблера или, к примеру, Форта это действительно будут паттерны проектирования.
А ты, кстати, навскидку нарисуешь полный сумматор на логических элементах? Я вот полусумматор помню.
VD>Ну, а для Немерла, например, исчезает паттерн проектирования Посетитель.
S>>Так что ключевое слово property или определенный синтаксис являются реализацией паттерна. А сам паттерн существует совершенно независимо от языка. Свойство можно реализовать даже на ассемблере.

VD>И if, как я уже сказал, можно реализовать на Ассемблере. Но ты же не оперируешь с ним как с паттерном? И не делашь ты это только потому, что if на языке высокого уровня для небя не паттерн, а первоклассаная операция. Точно так же свойство для тебя первоклассная сущность и думаь о нем как о паттерне прото неразумно.
VD>Нет главной составляющей паттерна "repeatable solution to a commonly-occurring problem" так как нет самой проблемы.
Есть, Влад, есть. Просто если ты замыкаешься на 1 языке, то нихрена кроме него не видишь. Ни паттернов, ни иных конструкций.
VD>Она становится тривиальной и описывается тривиально. То етсь нет ни проблемы, ни решения.
Влад, ну это же бред! Как это нет проблемы? Вот есть у нас например проблема: порождать объекты различных классов в зависимости от чего-то. Типичная проблема ООП. Есть и решение: паттерн Фабрика.
VD> Есть просто синтаксическая конструкция.
А она, Влад, для чего? Правильно, для решения некой проблемы. Тебя послушать, так всякие синтаксические конструкции существуют эдак сами для себя, как каприз создателей языка. Первичны именно паттерны. Самые удачные и востребованные из них оказывают влияние на синтаксис разрабатываемых языков. И мы по-прежнему можем видеть за синтаксисом паттерн, и говорить об удачной или неудачной реализации данного паттерна в том или ином языке.

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

VD>Хотя понятие громоздкость плохо детерминировано. Возможно луче подходит термин "выразительность".

VD>С точки зрения кривой обучения вопрос не столь очевиден. Потяно, что чем больше понятий впитал в себя язык тем сложнее его выучить. Но тут играет роль то, что для начальной стадии обучения все потятия могут оказаться не нужны. Меж тем те же приемы описанные в ГоФ являются пожалуй необходимым минимумо и хороший программист о них должен знать. И я не вижу ничего плохого если им будет придана краткая и простая форма.

S>> С одной стороны, новые паттерны появляются не так уж часто. С другой стороны, они все же появляются,

VD>Очень редко. Но другое дело что есть прикладные паттерны. Вроде тех что хотят охватить в LINQ. Вот их действительно масса и для них действительно лучше иметь расширяемый язык. Но именно расширяемый язык, а не отверстие в заднем проходе.

S>> и гораздо удобнее иметь язык, готовый к адаптации этих нововведений готовыми средствами. С третьей стороны, именно этим и руководствовался комитет С++

VD>Не, они этим отмазываются. А сам С++ имеет только одно штатное средство расширения — свои убогие макросы. Все остальное через зад. Результат соотвествующий.

VD>Так что дух в С++ правильный, а вот реализация ни к черту.

1.1.4 stable rev. 510

От:	Sinclair	https://github.com/evilguest/
Дата:	10.07.06 03:36
Оценка:	+3

	От:	WolfHound
	Дата:	10.07.06 06:20
	Оценка:	+1

	От:	FR
	Дата:	10.07.06 06:33
	Оценка:	-2

От:	VladD2	www.nemerle.org
Дата:	10.07.06 18:09
Оценка:

От:	VladD2	www.nemerle.org
Дата:	10.07.06 18:09
Оценка:

	От:	Vermicious Knid
	Дата:	10.07.06 18:23
	Оценка:	31 (1) +1

От:	IT	linq2db.com
Дата:	11.07.06 00:10
Оценка:	10 (2) +4

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	11.07.06 01:32
Оценка:	+1 -1

От:	eao197	http://eao197.blogspot.com
Дата:	14.09.06 07:53
Оценка:	+2