FR>>Это разные языки, у них философии ортогональны
C>Извините, что влезаю. А можно в 2 словах про ортогональность. Я то думал, что схема — попытка сделать более простой и стройный лисп.
Если про философию, то именно простота и понятность, а один из создателей схемы пишет:
Scheme, тот диалект Лиспа, который мы используем, пытается совместить
силу и красоту Лиспа и Алгола. От Лиспа мы берем метаязыковую мощь,
которой он обязан простоте своего синтаксиса, единообразное представление
программ как объектов данных, выделение данных из кучи с последующей их
утилизацией сборщиком мусора. От Алгола мы берем лексическую область дей-
ствия и блоковую структуру, подаренные нам первопроходцами проектирования
языков программирования из комитета по Алголу.
Здравствуйте, Курилка, Вы писали:
К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.
Видимо, основная мысль статьи в том, что надо напрямую поддерживать паттерны средствами ЯП.
Наверное, частично это верно; некоторые паттерны впоследствии стали частью более развитых ЯП.
Но есть также вопросы и сомнения.
Как надо поддерживать паттерны? "Зашить" их в языке? Включить в библиотеку?
Если включать в язык, то до каких пределов допустимо усложнение языка?
Другой момент: паттерны, как правило, имеют как достоинства, так и недостатки.
Если взять книжку GoF, то там каждый паттерн сопровождается списками "за" и "против".
Включая паттерн непосредственно в язык, мы не только усложняем язык, но также "наследуем" недостатки паттерна.
Поэтому, ИМХО, поддержка паттернов средствами ЯП не такое простое уж дело.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[2]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Курилка, Вы писали:
К>>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.
AVC>Видимо, основная мысль статьи в том, что надо напрямую поддерживать паттерны средствами ЯП. AVC>Наверное, частично это верно; некоторые паттерны впоследствии стали частью более развитых ЯП. AVC>Но есть также вопросы и сомнения. AVC>Как надо поддерживать паттерны? "Зашить" их в языке? Включить в библиотеку? AVC>Если включать в язык, то до каких пределов допустимо усложнение языка?
Нет, имхо, "зашивать" да и включать в язык (что вроде бы одно и то же, или есть разница?) это тупиковый путь, можно вспомнить как "элементарно" добавляли тот же foreach в яву — до боли простая вещь вроде, но...
Думаю наиболее удобный механизм — метапрограммирование, когда использование подобных вещей не регламентируется создателем языка, а "играться" можно самому, если возникает такая потребность.
AVC>Другой момент: паттерны, как правило, имеют как достоинства, так и недостатки. AVC>Если взять книжку GoF, то там каждый паттерн сопровождается списками "за" и "против". AVC>Включая паттерн непосредственно в язык, мы не только усложняем язык, но также "наследуем" недостатки паттерна. AVC>Поэтому, ИМХО, поддержка паттернов средствами ЯП не такое простое уж дело.
Вот ПОЭТОМУ в язык включать их и не надо. Должны быть механизмы, с помощью которых язык может расширяться (e.g. макросы лиспа). А уж как это будет выглядеть — библиотеки или что-то подобное, думаю не сильно принципиально.
Ну и от защиты от "любителей пофантазировать" нужно иметь ключик в языке, который бы позволял создавать подобные вещи только тем людям, которые понимаю, что делают.
Re[6]: Паттерны суть слабости языков программирования
gid_vvp wrote:
> и появятся библиотеки паттернов как говорили выше? тогда (+1)
Не совсем понятно вообще что такое библиотека для паттерна, паттерны более абстрактная вещь, чем алгоритм. Ну ладно,
паттерн Visitor, можно это обозвать signal/slots и некоторые алгоритмамы обозвать таким паттерном, что вообще говоря не
совсем точно. Но вот как можно библиотекой представлять те же структурные паттерны. Возьмём какой-нибудь Facade — что
можно библиотекой оргаризовать? Или даже какой язык может предоставить специальную конструкцию для этого паттерна?
Паттерн — вещь абстрактная, и каждая его имплементация — конкретизация, а следовательно потеря общности.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Паттерны суть слабости языков программирования
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Курилка, Вы писали:
К>>Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно. Упомянул он и презентацию Design Patterns in Dynamic Languages Питера Норвига. К>>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.
LVV>Нет... LVV>Когда-то и сортировки нужно было каждый раз реализовывать... LVV>Паттерны — это просто новый уровень понимания в программировании... LVV>Так же, как когда-то ООП было новым уровнем понимания, так сейчас и паттерны... LVV>Погодите, дойдет эволюция — и паттерны будут в языках... LVV>Между прочим — это и рсдну типа мысль — а не начать ли нам самим об этом думать всерьез, а не на уровне разговоров в форумах... LVV>Каким может быть язык, в котором паттерн является конструкцией языка? LVV>Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам... LVV>Библиотека паттернов и сборка проги с паттернами...
Рекомендуется осмотреть BETA и MPS. только не перепутать паттерны BETA и паттены ООП
LVV>Вообще-то нужно внимателоьно почитать книжку "Порождающее программирование" — там в 11-й главе о работах Микрософта оченьт интересные сведения сообщаются...
Re[3]: Паттерны суть слабости языков программирования
Здравствуйте, Курилка, Вы писали:
К>Думаю наиболее удобный механизм — метапрограммирование, когда использование подобных вещей не регламентируется создателем языка, а "играться" можно самому, если возникает такая потребность.
Да, точно, еще метапрограммирование (забыл его упомянуть).
А читабельность важна?
AVC>>Поэтому, ИМХО, поддержка паттернов средствами ЯП не такое простое уж дело. К>Вот ПОЭТОМУ в язык включать их и не надо. Должны быть механизмы, с помощью которых язык может расширяться (e.g. макросы лиспа). А уж как это будет выглядеть — библиотеки или что-то подобное, думаю не сильно принципиально. К>Ну и от защиты от "любителей пофантазировать" нужно иметь ключик в языке, который бы позволял создавать подобные вещи только тем людям, которые понимаю, что делают.
Все-таки фантазии иногда представляют опасность.
Меня пока вполне устраивает (возможно, вследствие характера решаемых мной задач) старая схема, когда возможности языка расширяются за счет модулей (в модульных языках).
Сейчас нет под рукой источника, но помню, как в одной из статей 1970-х гг. Вирт рассуждал о том, что в язык невозможно (и не нужно) включать все потенциально полезные конструкции, но можно расширять возможности языка за счет модульности (похоже, статья была написана на основании опыта Паскаля, но до создания Модулы).
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[4]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>А читабельность важна?
Смотря что есть читабельность, вот некоторые скобки лиспа ненавидят, другие — наоборот, так что вопрос скользкий, но важный.
Естественно инструмент должен быть таким чтобы было удобно им пользоваться иначе какой в нём смысл?
AVC>Все-таки фантазии иногда представляют опасность.
Возможно, об этом и речь, тем более в крупных проектах/коммандах. AVC>Меня пока вполне устраивает (возможно, вследствие характера решаемых мной задач) старая схема, когда возможности языка расширяются за счет модулей (в модульных языках). AVC>Сейчас нет под рукой источника, но помню, как в одной из статей 1970-х гг. Вирт рассуждал о том, что в язык невозможно (и не нужно) включать все потенциально полезные конструкции, но можно расширять возможности языка за счет модульности (похоже, статья была написана на основании опыта Паскаля, но до создания Модулы).
И? То, что нельзя создать серебрянную пулю это и ежу понятно. Но вот никто не мешает приближаться к этой пуле по меньшей мере в рамках конкретной задачи, которая перед тобой стоит.
А по поводу модульности — она безусловно очень важна, но вот достаточна ли? Не знаю, нужно много думать и иметь какой-то дотстаточный опыт таких проектов и т.п.
Re[4]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Да, точно, еще метапрограммирование (забыл его упомянуть). AVC>А читабельность важна?
Конечно, правильное использование метапрограммирования ее повышает.
AVC>Все-таки фантазии иногда представляют опасность. AVC>Меня пока вполне устраивает (возможно, вследствие характера решаемых мной задач) старая схема, когда возможности языка расширяются за счет модулей (в модульных языках). AVC>Сейчас нет под рукой источника, но помню, как в одной из статей 1970-х гг. Вирт рассуждал о том, что в язык невозможно (и не нужно) включать все потенциально полезные конструкции, но можно расширять возможности языка за счет модульности (похоже, статья была написана на основании опыта Паскаля, но до создания Модулы).
Только модульность это очень мало.
Все потенциально возможные конструкции конечно не нужно включать, но и минимализм Вирта когда в язык не включены просто необходимые для современного языка конструкции и возможности тоже плохо.
Re[5]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
FR>Только модульность это очень мало. FR>Все потенциально возможные конструкции конечно не нужно включать, но и минимализм Вирта когда в язык не включены просто необходимые для современного языка конструкции и возможности тоже плохо.
О каких именно современных конструкциях идет речь?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[5]: Паттерны суть слабости языков программирования
Здравствуйте, Курилка, Вы писали:
К>И? То, что нельзя создать серебрянную пулю это и ежу понятно. Но вот никто не мешает приближаться к этой пуле по меньшей мере в рамках конкретной задачи, которая перед тобой стоит.
Наверное, так.
Но вот такая мысль: использовать к месту паттерн в отдельном проекте не так трудно, а вот "зашить" (в любом виде) тот же самый паттерн в средства разработки требует больших умственных усилий, ИМХО.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[6]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, FR, Вы писали:
FR>>Только модульность это очень мало. FR>>Все потенциально возможные конструкции конечно не нужно включать, но и минимализм Вирта когда в язык не включены просто необходимые для современного языка конструкции и возможности тоже плохо.
AVC>О каких именно современных конструкциях идет речь?
Конструкции не современные, довольно старые.
Если придерживатся максимального минимализма , то хотя бы ФВП и замыкания.
Re[7]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
FR>Конструкции не современные, довольно старые. FR>Если придерживатся максимального минимализма , то хотя бы ФВП и замыкания.
Догадываюсь, что ФВП — это "функции высшего порядка".
Т.е. речь идет исключительно о средствах языков функционального программирования?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[3]: Паттерны суть слабости языков программирования
Здравствуйте, VladD2, Вы писали:
LVV>>Каким может быть язык, в котором паттерн является конструкцией языка? LVV>>Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам... VD>Паттерны они сами относительно языка строятся. Так что язык может быть любым. Чем больше паттернов в языке тем более высокоуровневые паттеерны используются в нем как паттерны. VD>Есть языки в которых есть возможность втроить паттерны в язык не меняя покмпилятора. И за эттим подходом будущее. А самое забавное, что возник он еще в Лиспе кторый страрше большинства участников форума.
Вообще-то мне макросы немерли как-то интуитивно зацепляют в этом отношении...
Уж больно мощьные... Скорее всего, с помощью похожего механизма можно будет и паттерны как конструкции вводить... LVV>>Вообще-то нужно внимателоьно почитать книжку "Порождающее программирование" — там в 11-й главе о работах Микрософта оченьт интересные сведения сообщаются... VD>Мне кажется не то ты читать собрался.
Да я уж прочитал...
И даже не один раз... А все равно — интересные там идеи — программирование в намерениях...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Паттерны суть слабости языков программирования
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gid_vvp, Вы писали:
_>>Ну не каждый... Александреску показал как можно реализовывать паттерны один раз.
VD>И толпа ежиков до сих пор не может ножрать этот кактус.
Ну, очевидно, инструмент реализации -слабоват и не совсем адекватен...
Макросы немерли более подходящи?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[8]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, FR, Вы писали:
FR>>Конструкции не современные, довольно старые. FR>>Если придерживатся максимального минимализма , то хотя бы ФВП и замыкания.
AVC>Догадываюсь, что ФВП — это "функции высшего порядка".
угу
AVC>Т.е. речь идет исключительно о средствах языков функционального программирования?
О средствах которые в основном появились благодаря функциональному программированию, те же ФВП и все что с ними связано ничто ни мешает использовать и в императивных языках.
Re[4]: Паттерны суть слабости языков программирования
Здравствуйте, LaptevVV, Вы писали:
LVV>Вообще-то мне макросы немерли как-то интуитивно зацепляют в этом отношении... LVV>Уж больно мощьные... Скорее всего, с помощью похожего механизма можно будет и паттерны как конструкции вводить...
Что значит можно? Собственно УЖЕ в какой-то мере: здесь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
FR>О средствах которые в основном появились благодаря функциональному программированию, те же ФВП и все что с ними связано ничто ни мешает использовать и в императивных языках.
Поправка принята — я выразился неточно.
Я хотел сделать упор на слове "исключительно".
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[4]: Паттерны суть слабости языков программирования
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, gid_vvp, Вы писали:
_>>>Ну не каждый... Александреску показал как можно реализовывать паттерны один раз.
VD>>И толпа ежиков до сих пор не может ножрать этот кактус. LVV>Ну, очевидно, инструмент реализации -слабоват и не совсем адекватен... LVV>Макросы немерли более подходящи?
Более подходящи любые адекватные средства метапрограммирования, кроме того многие динамические и функциональные языки и без средств метапрограммирования позволяют реализовывать тоже самое.
Re[5]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, LaptevVV, Вы писали:
LVV>>Макросы немерли более подходящи?
FR>Более подходящи любые адекватные средства метапрограммирования, кроме того многие динамические и функциональные языки и без средств метапрограммирования позволяют реализовывать тоже самое.
Или же при помощи них можно добавить метапрограммирование в сам язык как в случае с эрлангом и smerl.
