Здравствуйте, Ikemefula, Вы писали:
I>Аргумент про итерацию и блекджект ты проигнорировал ? Так держать !
Про итерацию это никакой не аргумент. Ибо вызов функции не паттрен. Иначе все есть паттерн.
А про блекждек ты ничего не сказал.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>Аргумент про итерацию и блекджект ты проигнорировал ? Так держать ! WH>Про итерацию это никакой не аргумент. Ибо вызов функции не паттрен. Иначе все есть паттерн.
Итерацию придется реализовывать одним из способов доступных в конкретном инструменте. Итерация это и есть паттерн. В конкретной реализации это может вылиться во что угодно.
WH>А про блекждек ты ничего не сказал.
Похоже ты просто заврался,цитирую себя:
"Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны."
Здравствуйте, Ikemefula, Вы писали:
I>Правильно. Потому паттерн отсюда перекочует в код на любом языке.
Твое понимание паттернов не имеет абсолютно ничего общего с тем, что под ними понимают остальные программисты.
И как следствие ты просто не понимаешь о чем вообще разговор.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>Правильно. Потому паттерн отсюда перекочует в код на любом языке. WH>Твое понимание паттернов не имеет абсолютно ничего общего с тем, что под ними понимают остальные программисты.
Я думаю тебе еще рано говорить про остальных программистов, ты, как минимум, собираешься 99% вообще выбросить из индустрии
WH>И как следствие ты просто не понимаешь о чем вообще разговор.
Ты еще не понял, что бороться нужно с лишним кодом а не с паттернами.
Здравствуйте, Ikemefula, Вы писали:
I>Итерацию придется реализовывать одним из способов доступных в конкретном инструменте. Итерация это и есть паттерн. В конкретной реализации это может вылиться во что угодно.
Те любой вызов метода это паттерн.
Я тебя правильно понял?
WH>>А про блекждек ты ничего не сказал. I>Похоже ты просто заврался,цитирую себя: I>"Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны."
Где тут паттерны проектирования?
Ты вообще про паттерны почитай да.
Есть ООП паттерны типа визитера и абстрактной фабрики.
Есть функциональные паттерны типа zipper'а и scrap your boilerplate.
В любом случае мы говорим про паттерны в коде.
А если тебе нужно распознать некий паттерн в состоянии игры, то это совсем другой паттерн. И к паттерну проектирования отношения не имеет.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Ты еще не понял, что бороться нужно с лишним кодом а не с паттернами.
Паттерны проектирования это и есть лишний код.
А ты тут пытаешься юлить и подменять общепринятое определение паттернов проектирования на отсебятину.
И на этом основании что-то доказывать.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
__>>паттерны это естественные конструкции, которые возникают по мере разработки архитектуры WH>Не правильно. WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
Упрощенчество. Скажем, паттерн "фасад" можно выделить даже тут:
class X {
public void foo(); // Фасадpublic void zoo(); // Фасадprotected void bar(); // Реализация
}
WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.
Или там, где нет необходимости вводить дополнительные конструкции в язык. Скажу крамольную вещь: подчас проще оперировать "паттернами", чем конструкциями языками, их реализующими. Связано это с тем, что "паттерн" является, в основном, мысленной конструкцией, и её можно легко адаптировать к реалиям того или иного языка. А вот языковая конструкция, реализующая паттерн — "чудище обло, огромно, стозевно и лаяй": по тем же причинам будет такой разнобой в реализациях, что мало не покажется.
WH>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен.
Как водится, лучший способ доказать неправильную посылку — свернуть на обсуждение личности.
WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
Лучший способ "бороться с паттернами" — употреблять их только в разговорной речи, а на языке программирования писать так, как он это позволяет.
WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
Ну, как всегда — будем лечить ангину простудой, обвиняя пациента в том, что он не умеет болеть. Знакомо, знакомо...
P.S.: Чую, пора уже заводить новый мем: "Количество языков в проекте растёт до тех пор, пока оно не превысит возможности программиста".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
WH>>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть. ГВ>Упрощенчество. Скажем, паттерн "фасад" можно выделить даже тут:
Как всегда. Написал, не поймешь что. И пытаешься строить далеко идущие выводы.
У тебя тут ни задачи. Без которой разговаривать не имеет смысла. Ни даже решения.
WH>>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача. ГВ>Или там, где нет необходимости вводить дополнительные конструкции в язык.
Она есть всегда, когда в языке нет возможности работать с терминами предметной области без костылей.
ГВ>Скажу крамольную вещь: подчас проще оперировать "паттернами", чем конструкциями языками, их реализующими.
А ты пробовал оперировать языковыми конструкциями, когда ты можешь их в любой момент создать и переделать как угодно?
Я пробовал.
Обратно на языки, которые это не могут, не хочу.
Шаблоны С++ по сравнению с этим детский сад. Ясельная группа.
ГВ>Связано это с тем, что "паттерн" является, в основном, мысленной конструкцией, и её можно легко адаптировать к реалиям того или иного языка.
Я предпочитаю языковые конструкции, которые могу легко адаптировать под себя.
ГВ>А вот языковая конструкция, реализующая паттерн — "чудище обло, огромно, стозевно и лаяй": по тем же причинам будет такой разнобой в реализациях, что мало не покажется.
Будет не больше чем разброд в библиотеках.
Ибо если язык позволяет вводить новые конструкции, то они автоматически становятся библиотеками.
WH>>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен. ГВ>Как водится, лучший способ доказать неправильную посылку — свернуть на обсуждение личности.
А что у тебя есть другие варианты появления копипасты кроме слабости языка и некомпетентности?
Я других вариантов не знаю.
ГВ>Лучший способ "бороться с паттернами" — употреблять их только в разговорной речи, а на языке программирования писать так, как он это позволяет.
Ага.
И получить кучу одинаковых визитеров, абстрактных фабрик итп.
Ты пойми паттерны, они возникают в коде на языке недостаточно низкого уровня сами по себе.
Ни ты и ни кто другой не будет выдумать решение заново, если они уже решали практически такую же задачу.
И как только ты повторно используешь готовый подход к решению, ты получишь паттерн.
А я еще в первый раз расширю язык и во второй раз обойдусь без копипасты.
ГВ>Ну, как всегда — будем лечить ангину простудой, обвиняя пациента в том, что он не умеет болеть. Знакомо, знакомо...
Как всегда ты не понял о чем разговор и ставишь диагнозы.
ГВ>P.S.: Чую, пора уже заводить новый мем: "Количество языков в проекте растёт до тех пор, пока оно не превысит возможности программиста".
Ну, попробуй.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ikemefula, Вы писали:
I>>Итерацию придется реализовывать одним из способов доступных в конкретном инструменте. Итерация это и есть паттерн. В конкретной реализации это может вылиться во что угодно. WH>Те любой вызов метода это паттерн. WH>Я тебя правильно понял?
Внимание !
list.ForEach(x => Print(x))
Метод ForEach — итератор при чем это не ООП. Об этом, кстати говоря, и пишется в книгах про паттерны.
I>>Похоже ты просто заврался,цитирую себя: I>>"Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны." WH>Где тут паттерны проектирования?
А паттерны это только те что в ГОФ описаны ?
WH>Ты вообще про паттерны почитай да.
Паттерны проектирования или паттерны ооп это малая часть паттернов.
WH>В любом случае мы говорим про паттерны в коде. WH>А если тебе нужно распознать некий паттерн в состоянии игры, то это совсем другой паттерн. И к паттерну проектирования отношения не имеет.
Паттерны в коде никуда не денутся. Как только люди которые начнут писать на твоем ДСЛ, решат десяток другой однотипных задач, у них на ровном месте вырастут паттерны.
По этой причине не нужно бороться с паттернами, нужно бороться за то, что бы код было легко писать, легко майнтейнить и тд и тд и тд.
Здравствуйте, WolfHound, Вы писали:
I>>Ты еще не понял, что бороться нужно с лишним кодом а не с паттернами. WH>Паттерны проектирования это и есть лишний код.
Нет, лишний код и паттерны проектирования вещи никак не связаные. В лишнем коде может быть как лишний паттерн так и например лишний ДСЛ, лишние макры и вообще все что угодно.
WH>А ты тут пытаешься юлить и подменять общепринятое определение паттернов проектирования на отсебятину. WH>И на этом основании что-то доказывать.
А паттерн "слой", как с ним быть ? Это ж тоже лишний код по твоему
Здравствуйте, Ikemefula, Вы писали:
I>Внимание ! I>
I> list.ForEach(x => Print(x))
I>
I>Метод ForEach — итератор при чем это не ООП. Об этом, кстати говоря, и пишется в книгах про паттерны.
Вызов метода паттерн! (С)Ikemefula
I>>>Похоже ты просто заврался,цитирую себя: I>>>"Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны." WH>>Где тут паттерны проектирования? I>А паттерны это только те что в ГОФ описаны ?
Паттерны в коде. И паттерны в карточной игре это разные паттерны.
И общего межу ними как между синим и апельсином.
WH>>Ты вообще про паттерны почитай да. I>Паттерны проектирования или паттерны ооп это малая часть паттернов.
Я говорю про паттерны в коде вообще.
А ты приплетаешь сюда совершенно левые паттерны типа распознавания ситуации в карточной игре.
I>Паттерны в коде никуда не денутся. Как только люди которые начнут писать на твоем ДСЛ, решат десяток другой однотипных задач, у них на ровном месте вырастут паттерны. I>По этой причине не нужно бороться с паттернами, нужно бороться за то, что бы код было легко писать, легко майнтейнить и тд и тд и тд.
Вывод не правильный.
Если у людей появились паттерны, то нужно добавить в язык конструкции которые эти паттерны устранят.
Это единственный способ радикально упростить жизнь людям.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Нет, лишний код и паттерны проектирования вещи никак не связаные. В лишнем коде может быть как лишний паттерн так и например лишний ДСЛ, лишние макры и вообще все что угодно.
То, что лишним может быть, что угодно совершенно не противоречит утверждению о том, что паттерн проектирования всегда лишний код.
I>А паттерн "слой", как с ним быть ? Это ж тоже лишний код по твоему
И где там код?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>Внимание ! I>>
I>> list.ForEach(x => Print(x))
I>>
I>>Метод ForEach — итератор при чем это не ООП. Об этом, кстати говоря, и пишется в книгах про паттерны. WH>Вызов метода паттерн! (С)Ikemefula
Враньё, эту фразу сказал ты сам и уже дважды пытаешься приписать её мне.
I>>А паттерны это только те что в ГОФ описаны ? WH>Паттерны в коде. И паттерны в карточной игре это разные паттерны. WH>И общего межу ними как между синим и апельсином.
Естественно. Это как пример что паттерны возникают не в коде, а в решении задачи.
I>>Паттерны проектирования или паттерны ооп это малая часть паттернов. WH>Я говорю про паттерны в коде вообще. WH>А ты приплетаешь сюда совершенно левые паттерны типа распознавания ситуации в карточной игре.
Паттерны появляются в решении задачи. Проявится ли это в коде — дело десятое.
Ну и ты игнорируешь паттерны вроде "слой" и тд.
I>>Паттерны в коде никуда не денутся. Как только люди которые начнут писать на твоем ДСЛ, решат десяток другой однотипных задач, у них на ровном месте вырастут паттерны. I>>По этой причине не нужно бороться с паттернами, нужно бороться за то, что бы код было легко писать, легко майнтейнить и тд и тд и тд. WH>Вывод не правильный. WH>Если у людей появились паттерны, то нужно добавить в язык конструкции которые эти паттерны устранят. WH>Это единственный способ радикально упростить жизнь людям.
Упрощать нужно только и только в том случае, если код сложно и трудно майнтейнить.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ikemefula, Вы писали:
I>>Нет, лишний код и паттерны проектирования вещи никак не связаные. В лишнем коде может быть как лишний паттерн так и например лишний ДСЛ, лишние макры и вообще все что угодно. WH>То, что лишним может быть, что угодно совершенно не противоречит утверждению о том, что паттерн проектирования всегда лишний код.
Паттерн проектирования как минимум понятен людям со стороны если у них есть определенный опыт. Мы то сейчас живем, а не через 1000 лет в другой вселенной, когда ты наконец то допилишь свой мега ДСЛ и он станет доминирующей парадигмой
I>>А паттерн "слой", как с ним быть ? Это ж тоже лишний код по твоему WH>И где там код?
Здравствуйте, Ikemefula, Вы писали:
WH>>Вызов метода паттерн! (С)Ikemefula I>Враньё, эту фразу сказал ты сам и уже дважды пытаешься приписать её мне.
Так ты уже второй раз показываешься на один вызов одной функции и говоришь что это паттерн.
Да ни в одном месте. Ибо если паттерны растянуть настолько широко, то это слово просто теряет смысл.
I>>>А паттерны это только те что в ГОФ описаны ? WH>>Паттерны в коде. И паттерны в карточной игре это разные паттерны. WH>>И общего межу ними как между синим и апельсином. I>Естественно. Это как пример что паттерны возникают не в коде, а в решении задачи.
Еще раз.
Те паттерны, что в задаче не имею никакого отношения к паттернам в коде.
Ты просто путаешь разные сущности, которые называются одинаково.
Покажи мне задачу, в которой есть паттерн визитер или абстрактная фабрика или зиппер или scrap your boilerplate или любой другой.
Именно задачу. А не решение.
I>Упрощать нужно только и только в том случае, если код сложно и трудно майнтейнить.
Любой код усложняет поддержку.
Следствие если код можно убрать он должен быть убран.
Нельзя убрать только бизнес логику. Все остальное убрать можно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Геннадий Васильев, Вы писали:
WH>>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
ГВ>Лучший способ "бороться с паттернами" — употреблять их только в разговорной речи, а на языке программирования писать так, как он это позволяет.
Не надо с ними бороться. Решаешь несколько однотипных задач и паттерны появятся сами собой, от этого никуда не уйдешь.
Например многие вещи сворачивать в функции категорически противопоказано, например если описывается какой то воркфлоу. Всем таким функциям нужно дать качественное имя а это далеко не всегда возможно, особенно если логика имеет эвристическое происхождение, а не математическое.
Нет качественного имени — пусть лучше код будет побольше, чем иметь в качестве имен непойми что или, что еще хуже, закорючки вроде [||||] .!. 0|0
В сложных случаях лучше переходить на визуальные инструменты и в этом случае в принципе почти фиолетово, как будет выглядеть код.
ГВ>P.S.: Чую, пора уже заводить новый мем: "Количество языков в проекте растёт до тех пор, пока оно не превысит возможности программиста".
Здравствуйте, Ikemefula, Вы писали:
I>Паттерн проектирования как минимум понятен людям со стороны если у них есть определенный опыт. Мы то сейчас живем, а не через 1000 лет в другой вселенной, когда ты наконец то допилишь свой мега ДСЛ и он станет доминирующей парадигмой
Так люди уже пользуются инструментами, которые это могут.
И получают серьезные преимущества.
То, что делаю я, будет позволять это делать еще проще.
WH>>И где там код? I>Везде
Понятно. Показать не можешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Не надо с ними бороться. Решаешь несколько однотипных задач и паттерны появятся сами собой, от этого никуда не уйдешь.
Я то ухожу. А ты не можешь по тому, что у тебя язык слабый.
I>Например многие вещи сворачивать в функции категорически противопоказано, например если описывается какой то воркфлоу. Всем таким функциям нужно дать качественное имя а это далеко не всегда возможно, особенно если логика имеет эвристическое происхождение, а не математическое.
Зато можно сворачивать в язык.
Давай потренируемся.
Просто напиши форкфлоу так как оно есть.
Только логику.
Без деталей реализации.
I>В сложных случаях лучше переходить на визуальные инструменты и в этом случае в принципе почти фиолетово, как будет выглядеть код.
Те графические ДСЛ для тебя приемлемы.
А текстовые, которые гораздо лучше нет. Интересная логика.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ikemefula, Вы писали:
WH>>>Вызов метода паттерн! (С)Ikemefula I>>Враньё, эту фразу сказал ты сам и уже дважды пытаешься приписать её мне. WH>Так ты уже второй раз показываешься на один вызов одной функции и говоришь что это паттерн.
Снова враньё, я написал "Метод ForEach — итератор" а ты прочел это как "вызов метода". То ли ты врёшь, то ли читать не умеешь. Выбирай, мне всё равно.
I>>Естественно. Это как пример что паттерны возникают не в коде, а в решении задачи. WH>Еще раз. WH>Те паттерны, что в задаче не имею никакого отношения к паттернам в коде.
Это не важно, природа у них одна и та же.
WH>Покажи мне задачу, в которой есть паттерн визитер или абстрактная фабрика или зиппер или scrap your boilerplate или любой другой. WH>Именно задачу. А не решение.
Цитирую себя:
"паттерны возникают ... в решении задачи." Ты точно умеешь чиатть ?
I>>Упрощать нужно только и только в том случае, если код сложно и трудно майнтейнить. WH>Любой код усложняет поддержку.
Нет, не любой. Одна операция может запросто быть похожей на другую, но это вовсе не значит, что надо общую часть обязательно выделить в функцию или взять да обеспечить языковой поддержкой. Хорошего имени может просто и не быть, что обычное дело если логика суть эвристики. Функционалисты вроде тебя заменяют такое на закорючки и прочую ересь которую мало кто станет изучать.
WH>Следствие если код можно убрать он должен быть убран.
Это слишком категорично и безосновательно. Хорошо бы увидеть некоторые замеры, скажем "после тотального устранения лишнего кода производительность программистов увеличиалсть на А%, где А рассчитано по методика Б, проверено по методике В на программистах N проектов, увеличение производительности позволило увеличить продажина K%"
Здравствуйте, WolfHound, Вы писали:
I>>Паттерн проектирования как минимум понятен людям со стороны если у них есть определенный опыт. Мы то сейчас живем, а не через 1000 лет в другой вселенной, когда ты наконец то допилишь свой мега ДСЛ и он станет доминирующей парадигмой WH>Так люди уже пользуются инструментами, которые это могут. WH>И получают серьезные преимущества.
Эти сказки я уже слышу много лет. Еще в начале лета или весны ты рассказывал басни про увеличение продуктивности в 100-1000 раз, правда так и не рассказал, как же это ты вычислил и на чем это можно проверить.
Вот посмотрим чего добьётся джетбрейнс с вашими мульками. Не дай бог продукты будут тормозить и глючить так же как и сейчас... Ну , ты понял Ожидаю, что джетбрейнс станет нумер1 в своей области. Если нет — немерле и дсл можно выкидывать в топку как академические бредни.
WH>То, что делаю я, будет позволять это делать еще проще.
Покажи свои методы на примере сайта РСДН. А то крутых специалистов хоть лопатой греби, а сайт работает все хуже и хуже. Уже дерево топика нельзя толком раскрыть, а поиск не то что по сайту, уже по треду стал проблемой.
WH>>>И где там код? I>>Везде WH>Понятно. Показать не можешь.
Тебе показать, как вычищаются обращения к UI из кода где выкачиваются данные из БД ?
