Здравствуйте, gid_vvp, Вы писали:
_>за что минус уважаемый? _>с чем не согласны? с тем что некоторые паттерны можно реализовать один раз а потом пользоваться?
С тем что на плюсах можно реализовать вменяемые (т.е. понятные изнутри) паттерны, которые используются в реальной жизни.
Re[3]: Паттерны суть слабости языков программирования
Эти тоже к метапрограммированию отношения не имеют. У ocaml-а правда есть препроцессор, но он не являеется часью языка. Есть правда эксперементальная версия Mete Haskell и Mete ML (пара штук).
FR>refal
Опять же не видел, но зачтем до выяснения.
Итого 8.
На два десятка не тянет. Причем даже если зачесть те языки кторые ты не назвал.
Так что это только языком просто сделать. В мире конечно метаязыков больше чем 20. Вот только это частные решения и невероятная экзотика. А из используемых на практике метаязыков вообще еденицы.
Теперь можно сравнить это количество с количеством когда-то появлявшихся языков. Думаю, это будет менее одного процента или около того. Так что назвать это дело "много" слишком смелая оценка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Паттерны суть слабости языков программирования
Здравствуйте, WoldemaR, Вы писали:
WR>Догадываюсь, что так обстоит дело в каждой предметной области. WR>Так что тема эта ещё более актуальна, чем это представляется на первый взгляд.
Эта тема ведёт нас к автоматизированному программированию
Re[10]: Паттерны суть слабости языков программирования
Здравствуйте, 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>Теперь можно сравнить это количество с количеством когда-то появлявшихся языков. Думаю, это будет менее одного процента или около того. Так что назвать это дело "много" слишком смелая оценка.
Это как смотреть, по моему вполне достаточно. И уж точно не только наше (вернее ваше) всё
Re: Паттерны суть слабости языков программирования
Здравствуйте, LaptevVV, Вы писали:
LVV>Каким может быть язык, в котором паттерн является конструкцией языка?
Паттерны они сами относительно языка строятся. Так что язык может быть любым. Чем больше паттернов в языке тем более высокоуровневые паттеерны используются в нем как паттерны.
LVV>Очевидно, язык должен уметь вводить новые паттерны аналогично функциям и классам...
Есть языки в которых есть возможность втроить паттерны в язык не меняя покмпилятора. И за эттим подходом будущее. А самое забавное, что возник он еще в Лиспе кторый страрше большинства участников форума.
LVV>Вообще-то нужно внимателоьно почитать книжку "Порождающее программирование" — там в 11-й главе о работах Микрософта оченьт интересные сведения сообщаются...
Мне кажется не то ты читать собрался.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Паттерны суть слабости языков программирования
Здравствуйте, Курилка, Вы писали:
К>Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно.
Здравствуйте, VladD2, Вы писали:
FR>>dylan VD>Экзотика. Я их и не видел. Ну, да верим на слово.
afaik, Dylan — попытка сделать lisp "с человеческим лицом". Разработан в Apple.
FR>>erlang FR>>ocaml FR>>haskell FR>>clean FR>>scala
VD>Эти тоже к метапрограммированию отношения не имеют. У ocaml-а правда есть препроцессор, но он не являеется часью языка. Есть правда эксперементальная версия Mete Haskell и Mete ML (пара штук).
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).
_>>ещё подумалось... а в архитектуре (ну там где дома и прочие здания проектируют ) паттерны это костылики к чему?
L>К архитекторским CAD-ам Ну или изначально — к кульману и ватману
Что то я очень сомневаюсь, что если появятся инструменты без слабостей то паттерны уйдут...
ведь удачные решения типовых задач как были так и будут как и сами типовые задачи.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Паттерны суть слабости языков программирования
Здравствуйте, gid_vvp, Вы писали:
_>>>ещё подумалось... а в архитектуре (ну там где дома и прочие здания проектируют ) паттерны это костылики к чему? L>>К архитекторским CAD-ам Ну или изначально — к кульману и ватману
_>Что то я очень сомневаюсь, что если появятся инструменты без слабостей то паттерны уйдут... _>ведь удачные решения типовых задач как были так и будут как и сами типовые задачи.
Паттерны появляются когда инструмент не позволяет выразить типовое решение в виде одной сущности, которую потом можно повторно использовать.
Например, есть типовые задача — сортировка и решение — алгоритм быстрой сортировки.
В одном языке (напр. Pascal) будет существовать паттерн быстрой сортировки, т.е. каждый раз когда надо сортировать, придется применять это типовое решение, потому что нельзя средствами языка выразить типовое решение в общем виде.
В другом языке (напр. С++) один раз реализуют функцию quick_sort, и затем используют её — таким образом, типовое решение есть, но паттерн не нужен.
Re[4]: Паттерны суть слабости языков программирования
Здравствуйте, gid_vvp, Вы писали:
_>>>ещё подумалось... а в архитектуре (ну там где дома и прочие здания проектируют ) паттерны это костылики к чему?
L>>К архитекторским CAD-ам Ну или изначально — к кульману и ватману
_>Что то я очень сомневаюсь, что если появятся инструменты без слабостей то паттерны уйдут...
Мы всё ещё об архитектуре говорим? Думаю, вполне реально сделать CAD (возможно, такие уже есть — не интересовался вопросом) в котором человек который умеет тыкать мышой сможет за небольшое время сделать проект дачного домика. Вот только профессиональный архитектор всё равно сделает лучше — дешевле, красивее, прочнее и т.п. Возможно, на дачном домике разница будет не очень заметна, но вот на небоскрёбе — она будет выражаться в порядках Вообщем, всё один-в один как в программировании
_>ведь удачные решения типовых задач как были так и будут как и сами типовые задачи.
В топике насколько я понимаю говорится о том что паттерны не уйдут совсем — они станут частью языка. В применении к аритектуре — будут встроены в CAD.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Паттерны суть слабости языков программирования
Кё>В одном языке (напр. Pascal) будет существовать паттерн быстрой сортировки, т.е. каждый раз когда надо сортировать, придется применять это типовое решение, потому что нельзя средствами языка выразить типовое решение в общем виде.
Кё>В другом языке (напр. С++) один раз реализуют функцию quick_sort, и затем используют её — таким образом, типовое решение есть, но паттерн не нужен.
ну что тут можно сказать
как я уже говорил на некоторых языках можно реализовывать некоторые паттерны один раз и навсегда
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Паттерны суть слабости языков программирования
_>>ведь удачные решения типовых задач как были так и будут как и сами типовые задачи. L>В топике насколько я понимаю говорится о том что паттерны не уйдут совсем — они станут частью языка. В применении к аритектуре — будут встроены в CAD.
и появятся библиотеки паттернов как говорили выше? тогда (+1)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Паттерны суть слабости языков программирования
Ну или изначально — к кульману и ватману 
