Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно. Упомянул он и презентацию Design Patterns in Dynamic Languages Питера Норвига.
Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

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

К>Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно. Упомянул он и презентацию Design Patterns in Dynamic Languages Питера Норвига.
К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

Паттерны, это, ИМХО, больше алфавит, достаточно удобный надо признать. А что бы каждый раз их не реализовывать — на то есть DSLи и прочие кодогенерации, на которые можно возложить самую рутинную работу.

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

DG>Паттерны, это, ИМХО, больше алфавит, достаточно удобный надо признать. А что бы каждый раз их не реализовывать — на то есть DSLи и прочие кодогенерации, на которые можно возложить самую рутинную работу.

Вопрос в том — а почему язык это не может сделать? Вот и нужны ему костыли типа кодогенераторов, или что-нибудь наподобие AspectJ.
А как бы тебе понравилось использовать описываемый паттерн "Object-oriented class"? Как раз из кодогенератора (препроцессора) и появился C++ на смену C.

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

К>Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно. Упомянул он и презентацию Design Patterns in Dynamic Languages Питера Норвига.
К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

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

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

DG>Паттерны, это, ИМХО, больше алфавит

Скорее словарик типовых фраз.

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

DG>Паттерны, это, ИМХО, больше алфавит, достаточно удобный надо признать.
А насчёт алфавита:
в рамках "слабых" языков приходится изобретать и использоватьэтот алфавит, т.к. ну нельзя выразить более высокоуровневые абстракции на этих языках (вспоминается блаб П.Грэхэма сразу ).

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

К>Здравствуйте, Dr.Gigabit, Вы писали:

DG>>Паттерны, это, ИМХО, больше алфавит, достаточно удобный надо признать.
К>А насчёт алфавита:
К>в рамках "слабых" языков приходится изобретать и использоватьэтот алфавит, т.к. ну нельзя выразить более высокоуровневые абстракции на этих языках (вспоминается блаб П.Грэхэма сразу ).

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

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

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

К>Здравствуйте, Dr.Gigabit, Вы писали:

DG>>Паттерны, это, ИМХО, больше алфавит, достаточно удобный надо признать. А что бы каждый раз их не реализовывать — на то есть DSLи и прочие кодогенерации, на которые можно возложить самую рутинную работу.

К>Вопрос в том — а почему язык это не может сделать?

Языки с развитой системой метапрограммирования, такие как Nemerle, это умеют.
зы. Никоим образом не призываю к флейму Nemerle vs all, но это факт.

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

DG>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, Dr.Gigabit, Вы писали:

DG>>>Паттерны, это, ИМХО, больше алфавит, достаточно удобный надо признать. А что бы каждый раз их не реализовывать — на то есть DSLи и прочие кодогенерации, на которые можно возложить самую рутинную работу.

К>>Вопрос в том — а почему язык это не может сделать?

DG>Языки с развитой системой метапрограммирования, такие как Nemerle, это умеют.
DG>зы. Никоим образом не призываю к флейму Nemerle vs all, но это факт.

из all много языков тоже это умеют.

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

FR>из all много языков тоже это умеют.

"много" — это очень смелая оценка.

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

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

FR>>из all много языков тоже это умеют.

VD>"много" — это очень смелая оценка.

То что даже я могу насчитать около десятка это уже много.

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

К>Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно. Упомянул он и презентацию Design Patterns in Dynamic Languages Питера Норвига.
К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

Давно уже говорилось: наличие устоявшихся паттернов, начиная от for (int i = 0; i < N; ++i) { use(a[i]) } и заканчивая паттернами проектирования, есть прямое следствие бедности языка.

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

DG>Языки с развитой системой метапрограммирования, такие как Nemerle, это умеют.
DG>зы. Никоим образом не призываю к флейму Nemerle vs all, но это факт.

Не Немерлом единым жив человек...
Но мысль верная, только вот речь о том, что проще пользоваться этим самым "алфавитом" (хотя далеко не всем), чем использовать более мощные языки, хотя развитие идёт...

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

К>Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно. Упомянул он и презентацию Design Patterns in Dynamic Languages Питера Норвига.
К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

Нет...
Когда-то и сортировки нужно было каждый раз реализовывать...
Паттерны — это просто новый уровень понимания в программировании...
Так же, как когда-то ООП было новым уровнем понимания, так сейчас и паттерны...
Погодите, дойдет эволюция — и паттерны будут в языках...
Между прочим — это и рсдну типа мысль — а не начать ли нам самим об этом думать всерьез, а не на уровне разговоров в форумах...
Каким может быть язык, в котором паттерн является конструкцией языка?
Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам...
Библиотека паттернов и сборка проги с паттернами...

Вообще-то нужно внимателоьно почитать книжку "Порождающее программирование" — там в 11-й главе о работах Микрософта оченьт интересные сведения сообщаются...

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

LVV>Здравствуйте, Курилка, Вы писали:
К>>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

LVV>Нет...
Почему нет? С чем именно ты несогласен?
LVV>Когда-то и сортировки нужно было каждый раз реализовывать...
И это не было "костылями", что нельзя было взять готовую библиотечную функцию?
LVV>Паттерны — это просто новый уровень понимания в программировании...
LVV>Так же, как когда-то ООП было новым уровнем понимания, так сейчас и паттерны...
Не соглашусь, имхо я согласен с автором статьи и объектная ориентация (там, наверное, можно разные аспекты выделить) суть набор паттернов, только вот название появилось после ООП, поэтому и обычно их не выделяют.
LVV>Погодите, дойдет эволюция — и паттерны будут в языках...
Они уже есть, см. хотябы упомянутую презентацию Норвига
LVV>Между прочим — это и рсдну типа мысль — а не начать ли нам самим об этом думать всерьез, а не на уровне разговоров в форумах...
LVV>Каким может быть язык, в котором паттерн является конструкцией языка?
LVV>Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам...
LVV>Библиотека паттернов и сборка проги с паттернами...
Речь о том, что уже есть подобные языки, но вот какой именно использовать для твоей этой "библитеки паттернов" — основание для флейма

FR>>>из all много языков тоже это умеют.

VD>>"много" — это очень смелая оценка.

FR>То что даже я могу насчитать около десятка это уже много.

В Философии у многих есть нехорошая привычка говорить лозунгами. Так вот должен отметить, что спорить с человеком, который говорит лозунгами, неовзможно по определению. Никто не сомневается в вашем профессионализме, может кто-то даже и 2 десятка насчитать сможет. Но разговор же не об этом, верно? Примеры, аргументы, обмен опытом своим/коллег оп сабжу -- ИМХО, именно за этим большинство сюда и пришло.

А лозунгами говорить вот уже как 15 лет не модно

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

К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

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

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

FR>>>>из all много языков тоже это умеют.

VD>>>"много" — это очень смелая оценка.

FR>>То что даже я могу насчитать около десятка это уже много.

DG>В Философии у многих есть нехорошая привычка говорить лозунгами. Так вот должен отметить, что спорить с человеком, который говорит лозунгами, неовзможно по определению. Никто не сомневается в вашем профессионализме, может кто-то даже и 2 десятка насчитать сможет. Но разговор же не об этом, верно? Примеры, аргументы, обмен опытом своим/коллег оп сабжу -- ИМХО, именно за этим большинство сюда и пришло.

Тебе что список нужен?
Держи:

lisp
schema
dylan
rebol
prolog
forth
smalltalk
ruby
python
erlang
ocaml
haskell
clean
scala
refal


DG>А лозунгами говорить вот уже как 15 лет не модно

Да ладно не модно, сейчас с этим еще модней, чтобы это увидеть достаточно включить телевизор

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

LVV>Каким может быть язык, в котором паттерн является конструкцией языка?
LVV>Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам...
LVV>Библиотека паттернов и сборка проги с паттернами...

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

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

LVV>Нет...
LVV>Когда-то и сортировки нужно было каждый раз реализовывать...
LVV>Паттерны — это просто новый уровень понимания в программировании...
LVV>Так же, как когда-то ООП было новым уровнем понимания, так сейчас и паттерны...
LVV>Погодите, дойдет эволюция — и паттерны будут в языках...
LVV>Между прочим — это и рсдну типа мысль — а не начать ли нам самим об этом думать всерьез, а не на уровне разговоров в форумах...
LVV>Каким может быть язык, в котором паттерн является конструкцией языка?
LVV>Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам...
LVV>Библиотека паттернов и сборка проги с паттернами...


Вот в теме интеррактивной графики, (в частности GUI) тоже есть свои паттерны. Правда в таком виде они ещё нигде (ненашёл) не появлялись.

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

Каждая такая способность встраивается в класс в нескольких точках так-же как и паттерн. Это их общее свойство.

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

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

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

_>за что минус уважаемый?
_>с чем не согласны? с тем что некоторые паттерны можно реализовать один раз а потом пользоваться?

С тем что на плюсах можно реализовать вменяемые (т.е. понятные изнутри) паттерны, которые используются в реальной жизни.

К>С тем что на плюсах можно реализовать вменяемые (т.е. понятные изнутри) паттерны, которые используются в реальной жизни.

во первых, ни кто не говорил о С++
во вторых всё относительно, в том числе понятие вменяемости

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

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

FR>Тебе что список нужен?
FR>Держи:

FR>lisp
FR>schema

Это один язык. Нет просто "lisp".

Так что 1.

FR>dylan
FR>rebol

Экзотика. Я их и не видел. Ну, да верим на слово.
3.

FR>prolog

Не поддерживает метапрограммирование. Это логическое программирование. Отдельный класс — парадигма.

FR>forth
FR>smalltalk
FR>ruby
FR>python

7.

FR>erlang
FR>ocaml
FR>haskell
FR>clean
FR>scala

Эти тоже к метапрограммированию отношения не имеют. У ocaml-а правда есть препроцессор, но он не являеется часью языка. Есть правда эксперементальная версия Mete Haskell и Mete ML (пара штук).

FR>refal

Опять же не видел, но зачтем до выяснения.

Итого 8.

На два десятка не тянет. Причем даже если зачесть те языки кторые ты не назвал.

Так что это только языком просто сделать. В мире конечно метаязыков больше чем 20. Вот только это частные решения и невероятная экзотика. А из используемых на практике метаязыков вообще еденицы.

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

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

WR>Догадываюсь, что так обстоит дело в каждой предметной области.
WR>Так что тема эта ещё более актуальна, чем это представляется на первый взгляд.


Эта тема ведёт нас к автоматизированному программированию

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

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

FR>>Тебе что список нужен?
FR>>Держи:

FR>>lisp
FR>>schema

VD>Это один язык. Нет просто "lisp".

Это разные языки, у них философии ортогональны

VD>Так что 1.

FR>>dylan
FR>>rebol

VD>Экзотика. Я их и не видел. Ну, да верим на слово.
VD>3.

У ребола полный доступ к структуре программмы также как в лиспе, так что он очень даже мета. Dylan это лисп с синтаксисом паскаля

FR>>prolog

VD>Не поддерживает метапрограммирование. Это логическое программирование. Отдельный класс — парадигма.

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

FR>>forth
FR>>smalltalk
FR>>ruby
FR>>python

VD>7.

FR>>erlang
FR>>ocaml
FR>>haskell
FR>>clean
FR>>scala

VD>Эти тоже к метапрограммированию отношения не имеют. У ocaml-а правда есть препроцессор, но он не являеется часью языка. Есть правда эксперементальная версия Mete Haskell и Mete ML (пара штук).

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

FR>>refal

VD>Опять же не видел, но зачтем до выяснения.

Посмотри, по сравнению с ним Nemerle может отдыхать

VD>Итого 8.

Удивительно что ты вообще столько насчитал.

VD>На два десятка не тянет. Причем даже если зачесть те языки кторые ты не назвал.

Кто говорил про два десятка?

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

Интенсивно используемых языков вообще немного.

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

Это как смотреть, по моему вполне достаточно. И уж точно не только наше (вернее ваше) всё

К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

ещё подумалось... а в архитектуре (ну там где дома и прочие здания проектируют ) паттерны это костылики к чему?

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

LVV>Каким может быть язык, в котором паттерн является конструкцией языка?

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

LVV>Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам...

Есть языки в которых есть возможность втроить паттерны в язык не меняя покмпилятора. И за эттим подходом будущее. А самое забавное, что возник он еще в Лиспе кторый страрше большинства участников форума.

LVV>Вообще-то нужно внимателоьно почитать книжку "Порождающее программирование" — там в 11-й главе о работах Микрософта оченьт интересные сведения сообщаются...

Мне кажется не то ты читать собрался.

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

К>Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно.

Забавно, значит не только в мою голову такие мысли лизут. А вот товарищи спорят

Автор: VladD2
Дата: 15.09.06

.

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

_>Ну не каждый... Александреску показал как можно реализовывать паттерны один раз.

И толпа ежиков до сих пор не может ножрать этот кактус.

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


FR>>prolog

VD>Не поддерживает метапрограммирование. Это логическое программирование. Отдельный класс — парадигма.

Принадлежность пролога к классу логических, не мешает ему поддерживать метапрограммирование.

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

FR>>dylan
VD>Экзотика. Я их и не видел. Ну, да верим на слово.
afaik, Dylan — попытка сделать lisp "с человеческим лицом". Разработан в Apple.

FR>>erlang
FR>>ocaml
FR>>haskell
FR>>clean
FR>>scala

VD>Эти тоже к метапрограммированию отношения не имеют. У ocaml-а правда есть препроцессор, но он не являеется часью языка. Есть правда эксперементальная версия Mete Haskell и Mete ML (пара штук).

SMERL &mdash; Simple Metaprogramming for ERLang
А именно здесь

It turns out that Erlang's dynamic typing, hot code swapping and built-in parsing and compilation tools make for some excellent runtime metaprogramming capabilities (I actually don't know of any other functional language that gives the programmer so much flexibility in the area of runtime code manipulation).

_>ещё подумалось... а в архитектуре (ну там где дома и прочие здания проектируют ) паттерны это костылики к чему?

К архитекторским CAD-ам Ну или изначально — к кульману и ватману

_>>ещё подумалось... а в архитектуре (ну там где дома и прочие здания проектируют ) паттерны это костылики к чему?

L>К архитекторским CAD-ам Ну или изначально — к кульману и ватману

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

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

_>>>ещё подумалось... а в архитектуре (ну там где дома и прочие здания проектируют ) паттерны это костылики к чему?
L>>К архитекторским CAD-ам Ну или изначально — к кульману и ватману

_>Что то я очень сомневаюсь, что если появятся инструменты без слабостей то паттерны уйдут...
_>ведь удачные решения типовых задач как были так и будут как и сами типовые задачи.

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

Например, есть типовые задача — сортировка и решение — алгоритм быстрой сортировки.

В одном языке (напр. Pascal) будет существовать паттерн быстрой сортировки, т.е. каждый раз когда надо сортировать, придется применять это типовое решение, потому что нельзя средствами языка выразить типовое решение в общем виде.

В другом языке (напр. С++) один раз реализуют функцию quick_sort, и затем используют её — таким образом, типовое решение есть, но паттерн не нужен.

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

_>>>ещё подумалось... а в архитектуре (ну там где дома и прочие здания проектируют ) паттерны это костылики к чему?

L>>К архитекторским CAD-ам Ну или изначально — к кульману и ватману

_>Что то я очень сомневаюсь, что если появятся инструменты без слабостей то паттерны уйдут...
Мы всё ещё об архитектуре говорим? Думаю, вполне реально сделать CAD (возможно, такие уже есть — не интересовался вопросом) в котором человек который умеет тыкать мышой сможет за небольшое время сделать проект дачного домика. Вот только профессиональный архитектор всё равно сделает лучше — дешевле, красивее, прочнее и т.п. Возможно, на дачном домике разница будет не очень заметна, но вот на небоскрёбе — она будет выражаться в порядках Вообщем, всё один-в один как в программировании

_>ведь удачные решения типовых задач как были так и будут как и сами типовые задачи.
В топике насколько я понимаю говорится о том что паттерны не уйдут совсем — они станут частью языка. В применении к аритектуре — будут встроены в CAD.

Кё>В одном языке (напр. Pascal) будет существовать паттерн быстрой сортировки, т.е. каждый раз когда надо сортировать, придется применять это типовое решение, потому что нельзя средствами языка выразить типовое решение в общем виде.

Кё>В другом языке (напр. С++) один раз реализуют функцию quick_sort, и затем используют её — таким образом, типовое решение есть, но паттерн не нужен.


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

_>>ведь удачные решения типовых задач как были так и будут как и сами типовые задачи.
L>В топике насколько я понимаю говорится о том что паттерны не уйдут совсем — они станут частью языка. В применении к аритектуре — будут встроены в CAD.

и появятся библиотеки паттернов как говорили выше? тогда (+1)

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

VD>>Это один язык. Нет просто "lisp".

FR>Это разные языки, у них философии ортогональны

Извините, что влезаю. А можно в 2 словах про ортогональность. Я то думал, что схема — попытка сделать более простой и стройный лисп.

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


FR>>Это разные языки, у них философии ортогональны

C>Извините, что влезаю. А можно в 2 словах про ортогональность. Я то думал, что схема — попытка сделать более простой и стройный лисп.

Если про философию, то именно простота и понятность, а один из создателей схемы пишет:

Scheme, тот диалект Лиспа, который мы используем, пытается совместить
силу и красоту Лиспа и Алгола. От Лиспа мы берем метаязыковую мощь,
которой он обязан простоте своего синтаксиса, единообразное представление
программ как объектов данных, выделение данных из кучи с последующей их
утилизацией сборщиком мусора. От Алгола мы берем лексическую область дей-
ствия и блоковую структуру, подаренные нам первопроходцами проектирования
языков программирования из комитета по Алголу.

А так про разницу смотри тут: http://rsdn.ru/forum/Message.aspx?mid=2115003&amp;only=1

Автор: Курилка
Дата: 18.09.06

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

К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

Видимо, основная мысль статьи в том, что надо напрямую поддерживать паттерны средствами ЯП.
Наверное, частично это верно; некоторые паттерны впоследствии стали частью более развитых ЯП.
Но есть также вопросы и сомнения.
Как надо поддерживать паттерны? "Зашить" их в языке? Включить в библиотеку?
Если включать в язык, то до каких пределов допустимо усложнение языка?
Другой момент: паттерны, как правило, имеют как достоинства, так и недостатки.
Если взять книжку GoF, то там каждый паттерн сопровождается списками "за" и "против".
Включая паттерн непосредственно в язык, мы не только усложняем язык, но также "наследуем" недостатки паттерна.
Поэтому, ИМХО, поддержка паттернов средствами ЯП не такое простое уж дело.

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

AVC>Здравствуйте, Курилка, Вы писали:

К>>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

AVC>Видимо, основная мысль статьи в том, что надо напрямую поддерживать паттерны средствами ЯП.
AVC>Наверное, частично это верно; некоторые паттерны впоследствии стали частью более развитых ЯП.
AVC>Но есть также вопросы и сомнения.
AVC>Как надо поддерживать паттерны? "Зашить" их в языке? Включить в библиотеку?
AVC>Если включать в язык, то до каких пределов допустимо усложнение языка?
Нет, имхо, "зашивать" да и включать в язык (что вроде бы одно и то же, или есть разница?) это тупиковый путь, можно вспомнить как "элементарно" добавляли тот же foreach в яву — до боли простая вещь вроде, но...
Думаю наиболее удобный механизм — метапрограммирование, когда использование подобных вещей не регламентируется создателем языка, а "играться" можно самому, если возникает такая потребность.

AVC>Другой момент: паттерны, как правило, имеют как достоинства, так и недостатки.
AVC>Если взять книжку GoF, то там каждый паттерн сопровождается списками "за" и "против".
AVC>Включая паттерн непосредственно в язык, мы не только усложняем язык, но также "наследуем" недостатки паттерна.
AVC>Поэтому, ИМХО, поддержка паттернов средствами ЯП не такое простое уж дело.
Вот ПОЭТОМУ в язык включать их и не надо. Должны быть механизмы, с помощью которых язык может расширяться (e.g. макросы лиспа). А уж как это будет выглядеть — библиотеки или что-то подобное, думаю не сильно принципиально.
Ну и от защиты от "любителей пофантазировать" нужно иметь ключик в языке, который бы позволял создавать подобные вещи только тем людям, которые понимаю, что делают.

gid_vvp wrote:

> и появятся библиотеки паттернов как говорили выше? тогда (+1)
Не совсем понятно вообще что такое библиотека для паттерна, паттерны более абстрактная вещь, чем алгоритм. Ну ладно,
паттерн Visitor, можно это обозвать signal/slots и некоторые алгоритмамы обозвать таким паттерном, что вообще говоря не
совсем точно. Но вот как можно библиотекой представлять те же структурные паттерны. Возьмём какой-нибудь Facade — что
можно библиотекой оргаризовать? Или даже какой язык может предоставить специальную конструкцию для этого паттерна?
Паттерн — вещь абстрактная, и каждая его имплементация — конкретизация, а следовательно потеря общности.

Здравствуйте, 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-й главе о работах Микрософта оченьт интересные сведения сообщаются...

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

К>Думаю наиболее удобный механизм — метапрограммирование, когда использование подобных вещей не регламентируется создателем языка, а "играться" можно самому, если возникает такая потребность.

Да, точно, еще метапрограммирование (забыл его упомянуть).
А читабельность важна?

AVC>>Поэтому, ИМХО, поддержка паттернов средствами ЯП не такое простое уж дело.
К>Вот ПОЭТОМУ в язык включать их и не надо. Должны быть механизмы, с помощью которых язык может расширяться (e.g. макросы лиспа). А уж как это будет выглядеть — библиотеки или что-то подобное, думаю не сильно принципиально.
К>Ну и от защиты от "любителей пофантазировать" нужно иметь ключик в языке, который бы позволял создавать подобные вещи только тем людям, которые понимаю, что делают.

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

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

AVC>А читабельность важна?
Смотря что есть читабельность, вот некоторые скобки лиспа ненавидят, другие — наоборот, так что вопрос скользкий, но важный.
Естественно инструмент должен быть таким чтобы было удобно им пользоваться иначе какой в нём смысл?

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

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

...

FDS>Эта тема ведёт нас к автоматизированному программированию

Ещё более автоматизированному. Не зря народ в открытых проектах за это рубится.

Плохо то, где американец спрашивает — "а как из этого извлечь прибыль?"
русский отвечает — "сам дурак!".

менталитет.

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

AVC>Да, точно, еще метапрограммирование (забыл его упомянуть).
AVC>А читабельность важна?

Конечно, правильное использование метапрограммирования ее повышает.

AVC>Все-таки фантазии иногда представляют опасность.
AVC>Меня пока вполне устраивает (возможно, вследствие характера решаемых мной задач) старая схема, когда возможности языка расширяются за счет модулей (в модульных языках).
AVC>Сейчас нет под рукой источника, но помню, как в одной из статей 1970-х гг. Вирт рассуждал о том, что в язык невозможно (и не нужно) включать все потенциально полезные конструкции, но можно расширять возможности языка за счет модульности (похоже, статья была написана на основании опыта Паскаля, но до создания Модулы).

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

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

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

О каких именно современных конструкциях идет речь?

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

К>И? То, что нельзя создать серебрянную пулю это и ежу понятно. Но вот никто не мешает приближаться к этой пуле по меньшей мере в рамках конкретной задачи, которая перед тобой стоит.

Наверное, так.
Но вот такая мысль: использовать к месту паттерн в отдельном проекте не так трудно, а вот "зашить" (в любом виде) тот же самый паттерн в средства разработки требует больших умственных усилий, ИМХО.

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

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

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

AVC>О каких именно современных конструкциях идет речь?

Конструкции не современные, довольно старые.
Если придерживатся максимального минимализма , то хотя бы ФВП и замыкания.

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

FR>Конструкции не современные, довольно старые.
FR>Если придерживатся максимального минимализма , то хотя бы ФВП и замыкания.

Догадываюсь, что ФВП — это "функции высшего порядка".
Т.е. речь идет исключительно о средствах языков функционального программирования?

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

LVV>>Каким может быть язык, в котором паттерн является конструкцией языка?
LVV>>Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам...
VD>Паттерны они сами относительно языка строятся. Так что язык может быть любым. Чем больше паттернов в языке тем более высокоуровневые паттеерны используются в нем как паттерны.
VD>Есть языки в которых есть возможность втроить паттерны в язык не меняя покмпилятора. И за эттим подходом будущее. А самое забавное, что возник он еще в Лиспе кторый страрше большинства участников форума.
Вообще-то мне макросы немерли как-то интуитивно зацепляют в этом отношении...
Уж больно мощьные... Скорее всего, с помощью похожего механизма можно будет и паттерны как конструкции вводить...
LVV>>Вообще-то нужно внимателоьно почитать книжку "Порождающее программирование" — там в 11-й главе о работах Микрософта оченьт интересные сведения сообщаются...
VD>Мне кажется не то ты читать собрался.
Да я уж прочитал...
И даже не один раз... А все равно — интересные там идеи — программирование в намерениях...

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

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

_>>Ну не каждый... Александреску показал как можно реализовывать паттерны один раз.

VD>И толпа ежиков до сих пор не может ножрать этот кактус.
Ну, очевидно, инструмент реализации -слабоват и не совсем адекватен...
Макросы немерли более подходящи?

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

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

FR>>Конструкции не современные, довольно старые.
FR>>Если придерживатся максимального минимализма , то хотя бы ФВП и замыкания.

AVC>Догадываюсь, что ФВП — это "функции высшего порядка".

угу

AVC>Т.е. речь идет исключительно о средствах языков функционального программирования?

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

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

LVV>Вообще-то мне макросы немерли как-то интуитивно зацепляют в этом отношении...
LVV>Уж больно мощьные... Скорее всего, с помощью похожего механизма можно будет и паттерны как конструкции вводить...
Что значит можно? Собственно УЖЕ в какой-то мере: здесь.

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

FR>О средствах которые в основном появились благодаря функциональному программированию, те же ФВП и все что с ними связано ничто ни мешает использовать и в императивных языках.

Поправка принята — я выразился неточно.
Я хотел сделать упор на слове "исключительно".

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

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

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

_>>>Ну не каждый... Александреску показал как можно реализовывать паттерны один раз.

VD>>И толпа ежиков до сих пор не может ножрать этот кактус.
LVV>Ну, очевидно, инструмент реализации -слабоват и не совсем адекватен...
LVV>Макросы немерли более подходящи?

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

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

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

LVV>>Макросы немерли более подходящи?

FR>Более подходящи любые адекватные средства метапрограммирования, кроме того многие динамические и функциональные языки и без средств метапрограммирования позволяют реализовывать тоже самое.

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

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

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

WR>...

FDS>>Эта тема ведёт нас к автоматизированному программированию

WR>Ещё более автоматизированному. Не зря народ в открытых проектах за это рубится.

WR>Плохо то, где американец спрашивает — "а как из этого извлечь прибыль?"
WR>русский отвечает — "сам дурак!".

WR>менталитет.

И правильно делает: нечего из глупостей прибыль извлекать

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

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

M>SMERL &mdash; Simple Metaprogramming for ERLang
M>А именно здесь
M>

M>It turns out that Erlang's dynamic typing, hot code swapping and built-in parsing and compilation tools make for some excellent runtime metaprogramming capabilities (I actually don't know of any other functional language that gives the programmer so much flexibility in the area of runtime code manipulation).

M>

И какое это отношение имеет к метапрограммировании в Эрлэнг?

Идем по твоей ссылке на правильную:
http://code.google.com/p/smerl/
Читаем:

Smerl is a library that simplifies the generation and manipulation of Erlang code in runtime.

Еще вопросы есть?

Или уж давайте тогда считать все языки поддерживающими метапрограммирование. А что? На них же можно создать проргамму? А раз так то эта программа может генерировать код.
Эдак у нас C# и Ява метапрограммирование допускают с их то Рефлексией...

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

Т>Принадлежность пролога к классу логических, не мешает ему поддерживать метапрограммирование.

Какм боком?

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

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


FR>>>Это разные языки, у них философии ортогональны

C>>Извините, что влезаю. А можно в 2 словах про ортогональность. Я то думал, что схема — попытка сделать более простой и стройный лисп.

FR>Если про философию, то именно простота и понятность, а один из создателей схемы пишет:
FR>[q]
FR>Scheme, тот диалект Лиспа,

Мне кажется дальше можно не читать, чтобы опнять что ты не прав. Иначе ты зря остановился еще нужно было Автокадовский диалект приплести и Емаксовский.

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

LVV>Вообще-то мне макросы немерли как-то интуитивно зацепляют в этом отношении...

Забавно, что о Немерле я и не заикался.

LVV>Уж больно мощьные... Скорее всего, с помощью похожего механизма можно будет и паттерны как конструкции вводить...

Не "можно". А уже и во всю. Другое дело, что не часто они в этом языке нужны. Но Proxy с делегированием сделали.
А разные Псетители, Строители и т.п. просто не нужны. Хотя можно сделать для разнообразия. Я Посетителя на R# делал. На Nemerle это будет еще проще.

LVV>И даже не один раз... А все равно — интересные там идеи — программирование в намерениях...

Это то что называется "by contract"? Дык в том же Немерле оно тоже уже есть и традиционно реализуется на макросах.

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

VD>>И толпа ежиков до сих пор не может ножрать этот кактус.
LVV>Ну, очевидно, инструмент реализации -слабоват и не совсем адекватен...
LVV>Макросы немерли более подходящи?

Да, но тогда нужно разумно было бы сказать, что "Лисп нам показал", а уж в разные люди поняли его пример по своему. В С++ решили взяться проктологию, а в Немерле обобщить опыт других и взять лучшее. Ведь Александреску всего лишь попытался перенести опыт Лиспа встроив его бледное подобие в С++ на базе побочных эффектов от шаблонов.

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

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

Это не добавление МП в язык. Это фрэймворк для рантайм-кодогенерации. Эдак в любой язык можно добавить МП.

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

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

Т>>Принадлежность пролога к классу логических, не мешает ему поддерживать метапрограммирование.

VD>Какм боком?

assert, retract...
первая попавшаяся на эту тему ссылка: http://cs.wwc.edu/KU/PR/Prolog.html#meta

Здравствуйте, Кодёнок, Вы писали:

Кё>Паттерны появляются когда инструмент не позволяет выразить типовое решение в виде одной сущности, которую потом можно повторно использовать.

Тут есть одна особенность. Паттерны все равно надо будет знать. Просто для того чтобы найти то что его реализует. Другое дело, что достаточно будет знать название паттерна и что он делает. А детали реализации будут скрыты.

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

Думаю, что это же ждет и паттерны. Знать реализацию паттернов будет так же полезно как знание алгоритмов сортировки.

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

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

kan>паттерн Visitor, можно это обозвать signal/slots и некоторые алгоритмамы обозвать таким паттерном, что вообще говоря не совсем точно.

Ага. Совсем не точно. Но тем неменее Visitor не только легко запихиваетя в библиоетеку если в языке есть метапрограммирование (МП), но и вообще может быть бессмысленным если в языке есть сопоставление с образцом (паттерн-матчинг).

kan> Но вот как можно библиотекой представлять те же структурные паттерны. Возьмём какой-нибудь Facade — что можно библиотекой оргаризовать?

Ага. Это как раз замечательный кандидат на автоматизацию. Достаточно продумать как отображать один интерфейс на другой (например, в виде атрибутов) и написать код который породит весь код Фасада по этому простому описанию.

kan> Или даже какой язык может предоставить специальную конструкцию для этого паттерна?

Nemerle! Что за несуразные вопросы, право.

kan>Паттерн — вещь абстрактная, и каждая его имплементация — конкретизация, а следовательно потеря общности.

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

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

AVC>Но вот такая мысль: использовать к месту паттерн в отдельном проекте не так трудно, а вот "зашить" (в любом виде) тот же самый паттерн в средства разработки требует больших умственных усилий, ИМХО.

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

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

AVC>Догадываюсь, что ФВП — это "функции высшего порядка".
AVC>Т.е. речь идет исключительно о средствах языков функционального программирования?

Они как бы просто напрашиваются. Хорошие проработанные идеи. Что делать вид что их нет? Вирт не просто делает вид, что их нет. Он еще пытается их вредность доказать. Что по-моему вообще неразумно.

Вот только из ФЯ я бы в первую очередь брал бы паттерн-матчинг, замыкания и локальные функции (которые почти есть в Обероне).

Но в язык хорош было бы добавить и другие вещи вроде foreach и т.п.

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

FR>О средствах которые в основном появились благодаря функциональному программированию, те же ФВП и все что с ними связано ничто ни мешает использовать и в императивных языках.

И что ты тогда споришь со мней в соседнем форуме?

ЗЫ

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

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

FDS>Вся проблема в том, что нам, собственно, тогда нужен некий компилятор, который просто сможет запоминать и оперировать понятиями человека, а не какого-то конкретного языка. Совершенно абстрактными от кода понятиями. Есть подозрение, что это чуть-чуть невозможно

я бы не сказал, что паттерны понятия человека. Скорее это проекция решения некоторых задач на язык.

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

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

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


FR>>Если про философию, то именно простота и понятность, а один из создателей схемы пишет:
FR>>[q]
FR>>Scheme, тот диалект Лиспа,

VD>Мне кажется дальше можно не читать, чтобы опнять что ты не прав. Иначе ты зря остановился еще нужно было Автокадовский диалект приплести и Емаксовский.

Не читай мне то что

VD>Идем по твоей ссылке на правильную:
VD>http://code.google.com/p/smerl/
VD>Читаем:
VD>

Smerl is a library that simplifies the generation and manipulation of Erlang code in runtime.

VD>Или уж давайте тогда считать все языки поддерживающими метапрограммирование. А что? На них же можно создать проргамму? А раз так то эта программа может генерировать код.
VD>Эдак у нас C# и Ява метапрограммирование допускают с их то Рефлексией...

Ну так посмотрим:

Metaprogramming

Metaprogramming is the writing of programs that write or manipulate other programs (or themselves) as their data or that do part of the work that is otherwise done at compile time during runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually.

Эрланг это позволяет? Позволяет Значит, в нем есть метапрограммирование :

With Smerl, you can both create new modules and manipulate existing modules in runtime. You can also query whether a module has a given function by calling smerl:has_func. To start creating a new module, call smerl:new(ModuleName). Both these functions return an opaque context record for the module. To manipulate the module, use smerl:add_func and smerl:remove_func.

Ну или например:

Here's a short module I wrote, called func_recs, which generates getters and setters for all records in a given source file:

Чем не метапрограммирование? Ну и еще metacurrying:

The get/2 and set/3 functions are mere skeletons. They are not used directly anywhere in the code. (In fact, when you compile this module, the compiler complains that these functions are unused. Little does it know... ) When we process the file person.erl, -- in runtime -- we finally have data we need to embed get/2 and set/3 with the index parameters as well as give them their final names. We achieve this in 1 line of code by calling smerl:curry/5.

Ну и так далее влоть до ErlyDB

Кстати! Smerl нигде не "поганит" исходные сорцы. Все манипуляции происходят только в рантайме. То есть код он-то генерит (что от него и требовалось ), но происходит это, не затрагивая исходники. А что еще надо для щастя?

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

FR>>О средствах которые в основном появились благодаря функциональному программированию, те же ФВП и все что с ними связано ничто ни мешает использовать и в императивных языках.

VD>И что ты тогда споришь со мней в соседнем форуме?

Там я спорю потому что ты по моему слишком широко трактуешь понятие "синтаксический сахар"

VD>ЗЫ

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

Ну бывает, иногда
Когда согласен нет.

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

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

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

VD>Это не добавление МП в язык. Это фрэймворк для рантайм-кодогенерации. Эдак в любой язык можно добавить МП.

Возможно и так, только весь вопрос в том, насколько это будет просто и удобно в использовании, а также работоспособно.

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

M>Ну так посмотрим:

M>Metaprogramming
M>

M>Metaprogramming is the writing of programs that write or manipulate other programs (or themselves) as their data or that do part of the work that is otherwise done at compile time during runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually.

M>Эрланг это позволяет?

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

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

FR>Там я спорю потому что ты по моему слишком широко трактуешь понятие "синтаксический сахар"

Такое ощущение, что ты только по этому поводу споришь.

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

WR>осталось дело за малым — как получать синтаксически компактные представления логики программы для конкретных паттернов.

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

VladD2 wrote:

> kan>паттерн Visitor, можно это обозвать signal/slots и некоторые
> алгоритмамы обозвать таким паттерном, что вообще говоря не совсем точно.
> Ага. Совсем не точно. Но тем неменее Visitor не только легко запихиваетя
> в библиоетеку если в языке есть метапрограммирование (МП), но и вообще
> может быть бессмысленным если в языке есть сопоставление с образцом
> (паттерн-матчинг).
Даже в таком языке реализация тех же банальных сингал-слотов вполне может быть оправданной в некоторых ситуациях.

> kan> Но вот как можно библиотекой представлять те же структурные
> паттерны. Возьмём какой-нибудь Facade — что можно библиотекой оргаризовать?
> Ага. Это как раз замечательный кандидат на автоматизацию. Достаточно
> продумать как отображать один интерфейс на другой (например, в виде
> атрибутов) и написать код который породит весь код Фасада по этому
> простому описанию.
Фасад как простая выборка/переименование некоторых методов — обычно не нужен, нужен тоненький слой кода, а значит уже не
простым отображением ифейса не обойтись.
Вот и тут получилось как обычно в таких ситуациях: "Совсем не точно".

> kan> Или даже какой язык может предоставить специальную конструкцию для
> этого паттерна?
> Nemerle! Что за несуразные вопросы, право.
А я думал 42.

> kan>Паттерн — вещь абстрактная, и каждая его имплементация —
> конкретизация, а следовательно потеря общности.
>
> Паттерн вещь конкретная — это детали реализации могут варьироваться. Ну,
Детали реализации и есть конкретизация в данном случае.

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

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

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

WR>>осталось дело за малым — как получать синтаксически компактные представления логики программы для конкретных паттернов.

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


Влад. Вот в этом утверждении я неуверен. чисто интуитивно.

Вот логика моих размышлений: (очень приближённая схема)

любая программа — это граф. (разрешите опустить детализацию, что это за граф такой).

подняли за одну вершину — получили дерево, потянули за другую — другое дерево.

всё что я знаю о метапрограммировании говорит мне о том, что оно позволяет наиболее эффективно создавать такие деревья.

но тут задача состоит в другом — как из одного дерева получить граф, а по нему построить другое дерево.
эта задача, насколько мне известно, немного шире метапрограммирования.

если неубедил, то попробую подыскать подходящий пример. Хотя что это я. Далеко ходить ненадо — вот к примеру задачка про двойную диспетчеризацию, она же паттерн Visitor, она же мультиметоды.

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

kan>Фасад как простая выборка/переименование некоторых методов — обычно не нужен, нужен тоненький слой кода, а значит уже не
kan>простым отображением ифейса не обойтись.
kan>Вот и тут получилось как обычно в таких ситуациях: "Совсем не точно".

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

И даже если оные будут нужны, ну что же? Можно сделать средства добавления этого кода. Все в наших руках. Это если паттерн встроен в язык, то его уже не изменить.

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


WR>если неубедил, то попробую подыскать подходящий пример. Хотя что это я. Далеко ходить ненадо — вот к примеру задачка про двойную диспетчеризацию, она же паттерн Visitor, она же мультиметоды.

И что этот пример должен показать?

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

WR>Влад. Вот в этом утверждении я неуверен. чисто интуитивно.

Зачем в таких вопросах интуиция?

WR>всё что я знаю о метапрограммировании говорит мне о том, что оно позволяет наиболее эффективно создавать такие деревья.

Вряд ли это можно назвать знанием о МП.

МП — это (если кратко) возможность написать программу которая создаст другую программу по некому алгоритму и входным данным.

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

Да и что тут обсуждать, когда есть реальные примеры реализации?
Например, вот Прокси с делегированием:
http://nemerle.org/svn/nemerle/trunk/macros/DesignPatterns.n

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

WR>>если неубедил, то попробую подыскать подходящий пример. Хотя что это я. Далеко ходить ненадо — вот к примеру задачка про двойную диспетчеризацию, она же паттерн Visitor, она же мультиметоды.

К>И что этот пример должен показать?

Видимо, то что это легко решается средствами МП.
http://rsdn.ru/projects/rsharp/article/rsharp_mag.xml#ERH
далее ищем по слову Visitor.

VladD2 wrote:

> kan>Фасад как простая выборка/переименование некоторых методов — обычно
> не нужен, нужен тоненький слой кода, а значит уже не
> kan>простым отображением ифейса не обойтись.
> kan>Вот и тут получилось как обычно в таких ситуациях: "Совсем не точно".
>
> Как показывает практика, чем более грамоно проектирование, и чем больше
> используются те самые праттерны, тем меньше нужны ручные прослойки. Так
> что очень дажа можено обойтись и без них.
А что тогда такое Facade, как не ручная прослойка?
Похоже что твой идеал — программист должен выбрать язык (ну понятно, что nemerle), а программа сама напишется; писать
код — для ламеров, настоящие программисты должны знать только единственно правильный язык, этого достаточно.

> И даже если оные будут нужны, ну что же? Можно сделать средства
> добавления этого кода. Все в наших руках. Это если паттерн встроен в
> язык, то его уже не изменить.
Вот пример кода, что там можно сделать встроенным в язык?

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

Ну так нечестно

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

FR>>Там я спорю потому что ты по моему слишком широко трактуешь понятие "синтаксический сахар"

VD>Такое ощущение, что ты только по этому поводу споришь.

В общем да
Ну кроме того я и с твоим опонентом вполне согласен в том что ФВП это сила

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

kan>А что тогда такое Facade, как не ручная прослойка?

Автоматическая прослойка созданная по некоторому правилу.

kan>Похоже что твой идеал — программист должен выбрать язык (ну понятно, что nemerle), а программа сама напишется; писать код — для ламеров, настоящие программисты должны знать только единственно правильный язык, этого достаточно.

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

kan>Вот пример кода, что там можно сделать встроенным в язык?

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

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

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


WR>>если неубедил, то попробую подыскать подходящий пример. Хотя что это я. Далеко ходить ненадо — вот к примеру задачка про двойную диспетчеризацию, она же паттерн Visitor, она же мультиметоды.

К>И что этот пример должен показать?

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

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

WR>>всё что я знаю о метапрограммировании говорит мне о том, что оно позволяет наиболее эффективно создавать такие деревья.

VD>Вряд ли это можно назвать знанием о МП.

[поскипано]

Хорошо. У меня есть любимый пример. Классика MFC! Подключаем тулбар в майнфрейму.

Есть следующие точки касания тулбара:

1. декларация объекта тулбара как члена класса.
2. загрузка объекта из ресурса при создании майнфрейма.
3. обработка CmdUI для показа/скрытия тулбара. метод + регистрация обработчика в карте сообщений.
4. кнопка/менюшка для показа/скрытия тулбара. метод + регистрация обработчика в карте сообщений

Влад, может я отстал, чем тут поможет МП?

VladD2 wrote:

> kan>А что тогда такое Facade, как не ручная прослойка?
> Автоматическая прослойка созданная по некоторому правилу.
Не получится ли это в большинстве случаев сложнее ручной?

> kan>Похоже что твой идеал — программист должен выбрать язык (ну понятно,
> что nemerle), а программа сама напишется; писать код — для ламеров,
> настоящие программисты должны знать только единственно правильный язык,
> этого достаточно.
> Умные люди не пишут код который можно сгенерировать. Точнее делают это
> один раз, задалбываются и в следующий раз ищут средства автоматизации.
> МП это как раз такое средство.
На такие разовые случаи обычно продвинутого текстового редактора хватит, или, в конце концов, что-то типа awk или perl —
по вкусу.

> kan>Вот пример кода <http://en.wikipedia.org/wiki/Fa%C3%A7ade_pattern&gt;,
> что там можно сделать встроенным в язык?
> Там описан примитивный случай. Тут и автоматизировать нечего. А бывает,
> так что ты долбишь море похожего кода вместо того чтобы описать одир наз
> то как он должен создаваться сам.
Ок, но мне всё-таки хочется понять, что же в данном (или подобном) случае можно придумать "встроенное в язык"?

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

kan>VladD2 wrote:

>> kan>А что тогда такое Facade, как не ручная прослойка?
>> Автоматическая прослойка созданная по некоторому правилу.
kan>Не получится ли это в большинстве случаев сложнее ручной?

Автоматизировать нужно только то что можно автоматизирвоать. В прочем принцип разумности он везде будет не лишним.

kan>На такие разовые случаи обычно продвинутого текстового редактора хватит, или, в конце концов, что-то типа awk или perl —
kan> по вкусу.

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

kan>Ок, но мне всё-таки хочется понять, что же в данном (или подобном) случае можно придумать "встроенное в язык"?

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

Я под фасадом все же понимаю преобразование одного интерфейса другим. Вот тут уже можно сделать очень многое.

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

WR>Хорошо. У меня есть любимый пример. Классика MFC! Подключаем тулбар в майнфрейму.

WR>Есть следующие точки касания тулбара:

WR>1. декларация объекта тулбара как члена класса.
WR>2. загрузка объекта из ресурса при создании майнфрейма.
WR>3. обработка CmdUI для показа/скрытия тулбара. метод + регистрация обработчика в карте сообщений.
WR>4. кнопка/менюшка для показа/скрытия тулбара. метод + регистрация обработчика в карте сообщений

WR>Влад, может я отстал, чем тут поможет МП?

В С++ и МФЦ кроме траха ничего. В других языках это можно было бы легко автоматизировать. Но в других языках (в том же C#) перечисленные действия можно было бы устранить сделав добавление новой команды декларируемым в неком XML-файле. Другими словами решить не за счет метапрограммирования, а за счет компонентной парадигмы. Так что это не очень хороший пример.

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

[Nemerle.MacroUsage (Nemerle.MacroPhase.WithTypedMembers,
                     Nemerle.MacroTargets.Class,
                     Inherited = false, AllowMultiple = false)]
macro StructuralHashCode (t : TypeBuilder) {
  def flds = t.GetFields (BindingFlags.Public %| BindingFlags.NonPublic %|          
                          BindingFlags.Instance %| BindingFlags.DeclaredOnly);

  def body = 
    List.FoldLeft (flds, <[ 0 ]>, fun (x : IField, acc) {
      <[ $acc %^ $(x.Name : usesite).GetHashCode () ]>
    });
  t.Define (<[ decl:
    public override GetHashCode () : int {
      $body
    }
  ]>);
}

Макрос добавляющий к классу функцию сравения:

[Nemerle.MacroUsage (Nemerle.MacroPhase.WithTypedMembers,
                     Nemerle.MacroTargets.Class,
                     Inherited = false, AllowMultiple = false)]
macro LexicographicCompareTo (t : TypeBuilder) {
  def tname = t.ParsedName;
  def flds = t.GetFields (BindingFlags.Public %| BindingFlags.NonPublic %|
                          BindingFlags.Instance %| BindingFlags.DeclaredOnly);
  def compareField (fld : IField)
  {
      def nm = Macros.UseSiteSymbol (fld.Name);
      def hasLess = match (fld.GetMemType ()) {
          | MType.Class (ti, _) =>
            def name = ti.FullName;
            match (name) {
                | "Nemerle.Core.string"
                | "System.String"
                | "Nemerle.Core.int"
                | "System.Int32"
                | "System.UInt32"
                | "Nemerle.Core.float"
                | "System.Single"
                | "Nemerle.Core.double"
                | "System.Double"
                | "Nemerle.Core.char"
                | "System.Char" =>
                  true
                | _ =>
                  false
            }
          | _ => 
            false
      }
      if (hasLess)
      {
          <[ 
            if (this.$(nm : name) < other.$(nm : name)) 
            {
                -1
            }
            else if (this.$(nm : name) > other.$(nm : name)) 
            {
                1
            }
            else
            {
                0
            }
         ]>
     }
     else
     {
         <[ this.$(nm : name).CompareTo (other.$(nm : name)); ]>
     }
  }
  def body = 
    List.FoldRight (flds, <[ 0 ]>, fun (x : IField, acc) { 
      <[ 
         def cmp = $(compareField (x));
         if (cmp == 0) 
         {
             $(acc)
         }
         else
         {
             cmp
         }
      ]>
    });
  def full = if (t.IsValueType) 
  {
      body 
  }
  else
  {
      <[ 
         if (object.ReferenceEquals (this, other)) 
         {
             0
         }
         else if (object.ReferenceEquals (other, null))
         {
             1
         }
         else
         {
             $(body)
         }
      ]>
  }

  t.Define (<[ decl:
    public CompareTo (other : $(tname : name)) : int { $full }
  ]>);
  t.Define (<[ decl:
    public CompareTo (Oother : object) : int 
    { 
      try 
      {
        def other = Oother :> $(tname : name);
        this.CompareTo (other)
      } 
      catch 
      {
        | _ is System.InvalidCastException => throw System.ArgumentException ()
      }
    }
  ]>);
}

Далее если нам понадобится добавить к классу функции сравнения или вычисления хэш-значения, то нам останется только пометить класс атрибутами LexicographicCompareTo и StructuralHashCode соотвественно.

И конечно, если мы сталкнемся с более сложными случаями, мы всегда можем реализовать эти функции врнучную.

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

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

DG>Паттерны, это, ИМХО, больше алфавит, достаточно удобный надо признать.

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


DG>А что бы каждый раз их не реализовывать — на то есть DSLи и прочие кодогенерации, на которые можно возложить самую рутинную работу.

Кодогенератор — тоже костыль.

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

Минус за сравнение Схемы с Лиспом и заявлением об отсутствии метапрограмирования в Прологе. В прологе сразу несколько способов метапрограммирования... У него программа — как данные, и в классическом виде это интерпретатор На нем довольно легко свои DSL вводить или обогащать семантику стандартного "решателя".

Because it is possible to directly access program code in Prolog, it is easy to write interpreter of Prolog in Prolog. Such interpreter is called a meta-interpreter. Meta-interpreters are usually used to add some extra features to Prolog ...

...Meta-programming is easy and elegant in Prolog because the term syntax is identical with the clause syntax ...

... so we can use terms (data) to name clauses (programs)

“Meta-programming in Prolog”, CIS335: Logic Programming,
Goldsmiths’ College, University of London 2

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

AVC>>Догадываюсь, что ФВП — это "функции высшего порядка".
AVC>>Т.е. речь идет исключительно о средствах языков функционального программирования?

VD>Они как бы просто напрашиваются. Хорошие проработанные идеи. Что делать вид что их нет? Вирт не просто делает вид, что их нет. Он еще пытается их вредность доказать. Что по-моему вообще неразумно.

Видимо, имеются в виду заявления Вирта, вроде тех, что сделаны им в
http://www.rsdn.ru/article/philosophy/virt.xml

Автор(ы): Никлаус Вирт
Дата: 23.05.2006
Уважаемые читатели! Один из наиболее известных, авторитетных и заслуженных деятелей в области программирования профессор Никлаус Вирт опубликовал в январском номере журнал Computer очень интересную, по моему мнению, статью. Я не мог отказать себе в удовольствии пересказать ее, чтобы предложить получившийся текст вашему вниманию.

как по поводу функционального программирования, так и по другим поводам.
Например,

Фантазии компьютерных ученых в 1960-е гг. не знали границ. Вдохновленные успехом в направлениях автоматического синтаксического анализа и генерации анализаторов, некоторые исследователи предложили идею гибких или, по крайней мере, расширяемых языков, представляя, что программе будут предшествовать синтаксические правила, которыми будет руководствоваться общий синтаксический анализатор при ее анализе. Более того, синтаксические правила можно было рассыпать повсюду в тексте. Например, можно было бы использовать какую-нибудь причудливую форму оператора for, специфицируя даже разные варианты одного и того же понятия в разных частях одной программы.

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

Вместе с тем, ИМХО, Вирт высказал вполне разумную мысль.
Причем у меня возникает впечатление, что между "современными" методами расширения языков (например, макросами Немерле) и "классическими" ( =упомянутыми Виртом ) есть существенное сходство.

VD>Вот только из ФЯ я бы в первую очередь брал бы паттерн-матчинг, замыкания и локальные функции (которые почти есть в Обероне).

Локальные (вложенные?) процедуры (в т.ч., конечно, процедуры-функции) в Обероне есть (как, кажется, и во всех потомках Паскаля).
Вместе с тем, существует запрет на присвоение локальных процедур процедурным переменным.
Возможная причина — при вызове локальной процедуры должна передаваться некая дополнительная информация (дисплеи и т.п.), корректность которой компилятор может обеспечить только при "правильной" последовательности вызовов.

VD>Но в язык хорош было бы добавить и другие вещи вроде foreach и т.п.

Здесь есть опасность вкусовщины.
К примеру, FR, при принципиальном, как мне кажется, согласии с тобой, foreach все же недолюбливает...
Какой критерий включения/невключения новой конструкции в язык можно было бы предложить?

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

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

V>Минус за сравнение Схемы с Лиспом и заявлением об отсутствии метапрограмирования в Прологе.

С Прологом я правда могу ошибаться, а то что Схема — это клон Лиспа — это 100%. Так что зайди из под анонима и поставь себе минус сам.

V> В прологе сразу несколько способов метапрограммирования... У него программа — как данные, и в классическом виде это интерпретатор На нем довольно легко свои DSL вводить или обогащать семантику стандартного "решателя".

Ну, и как там реализовать скажем встроенную поддержку ХМЛ?

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

AVC>Вместе с тем, ИМХО, Вирт высказал вполне разумную мысль.

Догмы он свои высказвает. Не более того.

AVC>Локальные (вложенные?) процедуры (в т.ч., конечно, процедуры-функции) в Обероне есть (как, кажется, и во всех потомках Паскаля).

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

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

AVC>Вместе с тем, существует запрет на присвоение локальных процедур процедурным переменным.

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

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

Это поток сознания, а не причина. Передавать локальные функции может даже C# 2.0. А языки вроде Лиспа делали это 25 лет назад. Все что нужно для корректной передачи ссылок на функции — это наличие GC. Он в Обероне есть. Так что единственная причина — это то что Вирт за столько лет не смог вникнуть в то что делали параллельно его конкуренты. Иными словами в чужой опыт.

VD>>Но в язык хорош было бы добавить и другие вещи вроде foreach и т.п.

AVC>Здесь есть опасность вкусовщины.

Здесь есть опасность трепавщины. Я не видел ни одного человека пользовавшегося языками с аналогами foreach, которые бы простестовали бы против этого оператора.

AVC>К примеру, FR, при принципиальном, как мне кажется, согласии с тобой, foreach все же недолюбливает...

Серьезно? Жаль он этого не знает.
На самом деле FR поклонник Питона где foreach называется for-ом, а конструкции аналогичной for-у из С/С++ попросту нет. Так что он не то чтобы не недолюбливает. Он только им и пользуется.

AVC>Какой критерий включения/невключения новой конструкции в язык можно было бы предложить?

Критерия два 1) удобство, 2) осуствие проблем. Уж что, что, а с этим у foreach-а проблем нет. Другое дело, что я согласен с Курилкой, что лучше иметь универсальные средства расширения языка. И согласен с тобой, Виртом и представителями МС с Саном, что как раз этот вопрос довольно спорен. Вот только я лично считаю, что спорен он в основном потому, что те кто о нем спорят сами не пробывали использовать расширяемые языки.

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


VD>С Прологом я правда могу ошибаться, а то что Схема — это клон Лиспа — это 100%.

Ну блин, тогда C# — это клон С, потому что скобочки одинаковые и операторы while, for и прочие очень похожи. Вот примерно так же сопоставимы Лисп и Схема.


V>> В прологе сразу несколько способов метапрограммирования... У него программа — как данные, и в классическом виде это интерпретатор На нем довольно легко свои DSL вводить или обогащать семантику стандартного "решателя".

VD>Ну, и как там реализовать скажем встроенную поддержку ХМЛ?

Так же как и везде — через разработку XML-ридеров и вообще XML-либы. Уверен, что этого добра уже есть тонны. Вот вариантик: http://www.zen37763.zen.co.uk/xml_download.html
Довольно-таки миниатюрный исходник для XML-либы. В нем сама логика занимает где-то четверть, а остальное — база данных преобразований для именованных юникодных и всяких управляющих символов, CDATA и т.д. Валидные XML-структуры хоть и записаны в виде программы, но выглядят как простое перечисление оных... В общем, в сравнении с исходниками XML-либы на C# — небо и земля.

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

Кстати, интерпретаторы на Прологе записываются в форме, очень похожей на нормальную Бэкуса-Наура. Потому на нем удобно прототипировать грамматики (всякие DSL, например ).

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

VD>Думаю, что это же ждет и паттерны. Знать реализацию паттернов будет так же полезно как знание алгоритмов сортировки.

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

Согласен.

Но главное что я хотел показать, это что паттерны вокруг которых все хороводы пляшут, это не что-то новое, изобретенное недавно. Паттерны, например из книги большой четверки — это такой же Copy-Paste вылизанных типовых решений, как и Copy-Paste кода. Поэтому мне нелепо читать про "новые языки программирования, которые будут поддерживать паттеры, и программирование паттернами", и т.п.

New features in Visual C++ 2025:
...
— Now you can copy-and-paste your code thus reusing good solution rather than reinventing it!
...

VladD2,

M>>Эрланг это позволяет?

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

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

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

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

M>Ну так нечестно

Нечестно использовать апелляции к мифическим людям, которые "говорят о метапрограммировании в ЯП".

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

VD>С Прологом я правда могу ошибаться, а то что Схема — это клон Лиспа — это 100%. Так что зайди из под анонима и поставь себе минус сам.

Возьми clisp м запусти вот эту простейшую программу на схеме:

(define (fib x)
  (if (< x 2) 1 (+ (fib (- x 1)) (fib (- x 2)) ))
)

(display (fib 16))
(display "\n")

Читай сообщения об ошибках, думай

Здравствуйте, Кодёнок, Вы писали:


Кё>Но главное что я хотел показать, это что паттерны вокруг которых все хороводы пляшут, это не что-то новое, изобретенное недавно. Паттерны, например из книги большой четверки — это такой же Copy-Paste вылизанных типовых решений, как и Copy-Paste кода. Поэтому мне нелепо читать про "новые языки программирования, которые будут поддерживать паттеры, и программирование паттернами", и т.п.

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

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

AVC>Вместе с тем, ИМХО, Вирт высказал вполне разумную мысль.
AVC>Причем у меня возникает впечатление, что между "современными" методами расширения языков (например, макросами Немерле) и "классическими" ( =упомянутыми Виртом ) есть существенное сходство.

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

VD>>Вот только из ФЯ я бы в первую очередь брал бы паттерн-матчинг, замыкания и локальные функции (которые почти есть в Обероне).

AVC>Локальные (вложенные?) процедуры (в т.ч., конечно, процедуры-функции) в Обероне есть (как, кажется, и во всех потомках Паскаля).
AVC>Вместе с тем, существует запрет на присвоение локальных процедур процедурным переменным.
AVC>Возможная причина — при вызове локальной процедуры должна передаваться некая дополнительная информация (дисплеи и т.п.), корректность которой компилятор может обеспечить только при "правильной" последовательности вызовов.

Просто нужно реализовать нормальное замыкание, Вирт сказал А но не сказал B. Реально для такого примитивного (извини ) языка как оберон просто нормальные замыкания и фвп (включая лямбду) дало бы очень много. Хотя конечно еще нужна полиморфность функций. Притом синтаксическм Оберон практически при этом не усложнится (можно сравнить с тем же питоном, сложность грамматик вполне сопоставима, а мощность нет).

VD>>Но в язык хорош было бы добавить и другие вещи вроде foreach и т.п.

AVC>Здесь есть опасность вкусовщины.
AVC>К примеру, FR, при принципиальном, как мне кажется, согласии с тобой, foreach все же недолюбливает...

Ну Влад уже сказал про питоновский for
Хотя в этом я вполне могу принять минимализм, не нужно кучу for'ов, хватит и одного достаточно мощного. Гораздо важнее включить те конструкции про которые я писал выше.

AVC>Какой критерий включения/невключения новой конструкции в язык можно было бы предложить?

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

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

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

M>Ну так нечестно

Мне так вот помнится, что в ерланге есть такая полезная штука, как parse transform. Через нее сделана MNEMOSYNE

-------------------------------------
{parse_transform,Module}

Causes the parse transformation function Module:parse_transform/2 to be applied to the parsed code before the code is checked for errors.
-------------------------------------
То-есть на этапе компиляции вызывается произвольный внешний модуль, который и трансформирует отпарсенные формы во что-то другое

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

FR>>Только модульность это очень мало.
FR>>Все потенциально возможные конструкции конечно не нужно включать, но и минимализм Вирта когда в язык не включены просто необходимые для современного языка конструкции и возможности тоже плохо.
AVC>О каких именно современных конструкциях идет речь?

Параметрические типы.
Функции как fco, ну и, соответственно, полноценные лексические замыкания и лямбды.
Алгебраические типы, кортежи, pattern matching.

Да чего там говорить? В Обероне, кажется, даже интерфейса как языковой сущности не существует. И множественной реализации нет, так ведь?

Можно еще и traits/mixins, кстати, но это на любителя.

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


AVC>>Локальные (вложенные?) процедуры (в т.ч., конечно, процедуры-функции) в Обероне есть (как, кажется, и во всех потомках Паскаля).

VD>Нет их там. Там именно как в Паскле можно обявить локальную функцию между сигнатурой метода и начало его тела.

Со времен Алгола-60 именно это и называется локальными функциями.

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

Удобная позиция: "Если кто-то несогласен со мной, то это исключительно от незнания и скудоумия".
Но у Вирта была возможность поучиться и на собственном опыте. Его первый язык был очень похож на синтаксически подслащенный Лисп.

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

AVC>>О каких именно современных конструкциях идет речь?

K>Параметрические типы.
K>Функции как fco, ну и, соответственно, полноценные лексические замыкания и лямбды.
K>Алгебраические типы, кортежи, pattern matching.

Какие же это это современные конструкции? Наследие 70-х.

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

WR>Этот пример показывает. как меняется решение (и даже формулировка) одной и той же задачи в зависимости от точки зрения. А исторически сформировавшихся точек зрения (языки) уже очень много.
WR>В сложившейся ситуации очень наивно полагать, что некоторый язык программирования займёт верх и заткнёт все остальные куда следует. (слишком много людей придётся переучивать).
WR>Можно ожидать появления такой технологии работы с кодом, которая будет обходить эти различия, равно как и точки зрения на задачу.

Мне думается, что ты копаешь уже совсем в другую сторону
Вопрос в паттернах в том, чтобы сделать это всё автоматизированным, т.е. использовать библиотечный макрос или что-то подобное.
Какой конкретно для конкретной задачи — решает программист/архитектор.
Зачем смотреть на паттерн сразу с разных т.зр. я не совсем понимаю, хотя может кому-то это и нужно

> Автоматизировать нужно только то что можно автоматизирвоать. В прочем
> принцип разумности он везде будет не лишним.
Ок.

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

> kan>Ок, но мне всё-таки хочется понять, что же в данном (или подобном)
> случае можно придумать "встроенное в язык"?
> В данном ничего. Но это лишь потому, что по сути паттерна тут и нет. Это
> пример банальной инкапсуляции. С тем же успехом можно было бы добавить
> одну функцию.
Тут алгоритма нет, т.е. того, что можно записать на формальном языке. Но вот это и есть суть паттерна!
hint: инкапсуляция — тоже паттерн! Да, он слишком очевиден для ООП-языка, но может быть применён, скажем, в процедурном
языке.

> Я под фасадом все же понимаю преобразование одного интерфейса другим.
> Вот тут уже можно сделать очень многое.
Если преобразование тривиально (что обычно и значит возможность автоматизации), то оно вряд ли может быть ценным (по
крайней мере явно не во всех случаях).


В общем, мой тезис я внёс в сабж, нарушив принцип "фидошники сабжей не меняют".

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

K>Параметрические типы.
K>Функции как fco, ну и, соответственно, полноценные лексические замыкания и лямбды.
K>Алгебраические типы, кортежи, pattern matching.

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

K>Да чего там говорить? В Обероне, кажется, даже интерфейса как языковой сущности не существует. И множественной реализации нет, так ведь?

Возможно, имя "Оберон" слишком много означает, что вызывает некоторую путаницу.
Оберон (кроме, разумеется, литературных и астрономических ассоциаций) — это:
1) операционная система (теперь, пожалуй, даже целое их семейство);
2) язык программирования, использованный для создания этой операционки;
3) семейство языков — "дериватов" Оберона (Оберон-2, Активный Оберон, Зоннон; на самом деле таких языков гораздо больше).
В первоначальном Обероне-языке не было (множественных) интерфейсов, но в Активном Обероне и Зонноне есть их аналог — definition. (Т.е. не все "оберонщики" такие же минималисты, как Вирт. )

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

К>Мне думается, что ты копаешь уже совсем в другую сторону
К>Вопрос в паттернах в том, чтобы сделать это всё автоматизированным, т.е. использовать библиотечный макрос или что-то подобное.
К>Какой конкретно для конкретной задачи — решает программист/архитектор.
К>Зачем смотреть на паттерн сразу с разных т.зр. я не совсем понимаю, хотя может кому-то это и нужно


я понял. сейчас всем будет счастье.

надо чтобы среда (ИДЕ) показывала сгенерённый код выделенным шрифтом и недавала его редактировать (типо как асм).

Интересно. хоть какая-то среда так делает?

Отсюда приходим к выводу, что для Nemerle нужна своя ИДЕ.

Или я неправ?

kan wrote:

> В общем, мой тезис я внёс в сабж, нарушив принцип "фидошники сабжей не
> меняют".
Ай-яй-яй... Порезался сабж однако... было:

Сабжи типа "Паттерны суть слабости языков программирования" суть слабости понимания понятия "паттерн"

В общем ни к чему хорошему нарушение принципа не привело

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

VD>Это поток сознания, а не причина. Передавать локальные функции может даже C# 2.0. А языки вроде Лиспа делали это 25 лет назад. Все что нужно для корректной передачи ссылок на функции — это наличие GC. Он в Обероне есть. Так что единственная причина — это то что Вирт за столько лет не смог вникнуть в то что делали параллельно его конкуренты. Иными словами в чужой опыт.

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

procedure p(n: integer);
  procedure fn;
  begin
    do_something(n)
  end;
begin
  callback(@fn)
end;

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

AVC>В принципе, многие реализации Паскаля позволяли (и позволяют) делать замыкания, именно благодаря вложенным процедурам и функциям.
AVC>Простейший пример (кстати, из книжки Элджера по... Си++, где он горько сетует, что в Си нет вложенных процедур):
<skipped/>

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

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

AVC>>В принципе, многие реализации Паскаля позволяли (и позволяют) делать замыкания, именно благодаря вложенным процедурам и функциям.
AVC>>Простейший пример (кстати, из книжки Элджера по... Си++, где он горько сетует, что в Си нет вложенных процедур):

К>Тут FR уже приводил факт — ну не замыкания это, т.к. контекст с ними не передаётся и действует только внутри функции. Хотя частично похоже

Давай разберемся; может, я неправильно понимаю.
Как это "контекст не передается"?
callback — какая-то внешняя процедура, мы передаем туда fn, callback вызывает fn, fn использует значение n из своего контекста (откуда же еще?).

Привет Курилка.
Ну и с чем ты несогласен? Нафига минус поставил?

Если кто-то думает, что автоматизация программирования произойдёт от лингвистических фокусов, тот жестоко ошибается. Поговорите со старшими товарищами, они раскажут вам легенды про компиляторы компиляторов и прочих выкрутасов.

Рекомендую повторять как мантру:
автоматизация программирования произойдёт через развитие среды разработки.

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

AVC>Давай разберемся; может, я неправильно понимаю.
AVC>Как это "контекст не передается"?
AVC>callback — какая-то внешняя процедура, мы передаем туда fn, callback вызывает fn, fn использует значение n из своего контекста (откуда же еще?).

Смотри тут Re[4]: Почему у Nemerle нет будущего

Автор: FR
Дата: 05.08.06

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

AVC>Давай разберемся; может, я неправильно понимаю.
AVC>Как это "контекст не передается"?
AVC>callback — какая-то внешняя процедура, мы передаем туда fn, callback вызывает fn, fn использует значение n из своего контекста (откуда же еще?).

В том и дело, что не процедура
Хотя это лирика...
А смысл в том, что у тебя есть только контекст вызова, а для замыкания нужен ещё конктекст создания замыкания (может есть другие определения, я из головы придумал ) Получается, что в одном месте ты создаёшь замыкание, в котором участвуют переменные, которые определены в данный момент, потом это замыкание передаётся куда-либо (вот это будет проблемой для паскаля/оберона, т.к. локальные переменные уже могут быть не видны в той точке куда мы попадём) и т.к. это функция, то туда передаются ещё параметры для вызова (0 параметров как один из вариантов). Примерно так.
У тебя же внутри происходи вызов и никуда замыкание "уйти" не может...