Здравствуйте, WoldemaR, Вы писали:
WR>Здравствуйте, FDSC, Вы писали:
WR>...
FDS>>Эта тема ведёт нас к автоматизированному программированию
WR>Ещё более автоматизированному. Не зря народ в открытых проектах за это рубится.
WR>Плохо то, где американец спрашивает — "а как из этого извлечь прибыль?" WR>русский отвечает — "сам дурак!".
WR>менталитет.
И правильно делает: нечего из глупостей прибыль извлекать
Вся проблема в том, что нам, собственно, тогда нужен некий компилятор, который просто сможет запоминать и оперировать понятиями человека, а не какого-то конкретного языка. Совершенно абстрактными от кода понятиями. Есть подозрение, что это чуть-чуть невозможно
Re[11]: Паттерны суть слабости языков программирования
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>
И какое это отношение имеет к метапрограммировании в Эрлэнг?
Smerl is a library that simplifies the generation and manipulation of Erlang code in runtime.
Еще вопросы есть?
Или уж давайте тогда считать все языки поддерживающими метапрограммирование. А что? На них же можно создать проргамму? А раз так то эта программа может генерировать код.
Эдак у нас C# и Ява метапрограммирование допускают с их то Рефлексией...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Curufinwe, Вы писали:
FR>>>Это разные языки, у них философии ортогональны
C>>Извините, что влезаю. А можно в 2 словах про ортогональность. Я то думал, что схема — попытка сделать более простой и стройный лисп.
FR>Если про философию, то именно простота и понятность, а один из создателей схемы пишет: FR>[q] FR>Scheme, тот диалект Лиспа,
Мне кажется дальше можно не читать, чтобы опнять что ты не прав. Иначе ты зря остановился еще нужно было Автокадовский диалект приплести и Емаксовский.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Паттерны суть слабости языков программирования
Здравствуйте, LaptevVV, Вы писали:
LVV>Вообще-то мне макросы немерли как-то интуитивно зацепляют в этом отношении...
Забавно, что о Немерле я и не заикался.
LVV>Уж больно мощьные... Скорее всего, с помощью похожего механизма можно будет и паттерны как конструкции вводить...
Не "можно". А уже и во всю. Другое дело, что не часто они в этом языке нужны. Но Proxy с делегированием сделали.
А разные Псетители, Строители и т.п. просто не нужны. Хотя можно сделать для разнообразия. Я Посетителя на R# делал. На Nemerle это будет еще проще.
LVV>И даже не один раз... А все равно — интересные там идеи — программирование в намерениях...
Это то что называется "by contract"? Дык в том же Немерле оно тоже уже есть и традиционно реализуется на макросах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Паттерны суть слабости языков программирования
Здравствуйте, LaptevVV, Вы писали:
VD>>И толпа ежиков до сих пор не может ножрать этот кактус. LVV>Ну, очевидно, инструмент реализации -слабоват и не совсем адекватен... LVV>Макросы немерли более подходящи?
Да, но тогда нужно разумно было бы сказать, что "Лисп нам показал", а уж в разные люди поняли его пример по своему. В С++ решили взяться проктологию, а в Немерле обобщить опыт других и взять лучшее. Ведь Александреску всего лишь попытался перенести опыт Лиспа встроив его бледное подобие в С++ на базе побочных эффектов от шаблонов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Паттерны суть слабости языков программирования
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Трурль, Вы писали:
Т>>Принадлежность пролога к классу логических, не мешает ему поддерживать метапрограммирование.
VD>Какм боком?
Здравствуйте, Кодёнок, Вы писали:
Кё>Паттерны появляются когда инструмент не позволяет выразить типовое решение в виде одной сущности, которую потом можно повторно использовать.
Тут есть одна особенность. Паттерны все равно надо будет знать. Просто для того чтобы найти то что его реализует. Другое дело, что достаточно будет знать название паттерна и что он делает. А детали реализации будут скрыты.
Это тоже саоме что было с алгоритмами вроде сортировки в прошлые годы. Сначала их каждый писал сам (причем без знаний, изобретая все с нуля), потом появились умные книги и сортировку стали писать с умом, но как сейчас это происходит с паттернами ее лепили в любой проект и по нескольку раз. Ну, а потом алгоритмы легли в библоиотеки, а в книжках стали писать о том как их использвать в готовом виде.
Думаю, что это же ждет и паттерны. Знать реализацию паттернов будет так же полезно как знание алгоритмов сортировки.
Вот только будет это явно не скоро. Качественная поддержка метапрограммирования еще не вошла в мэйнстрим-яызки. И Сан с МС против этого просто таки борются.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Паттерны суть слабости языков программирования
Здравствуйте, kan, Вы писали:
kan>паттерн Visitor, можно это обозвать signal/slots и некоторые алгоритмамы обозвать таким паттерном, что вообще говоря не совсем точно.
Ага. Совсем не точно. Но тем неменее Visitor не только легко запихиваетя в библиоетеку если в языке есть метапрограммирование (МП), но и вообще может быть бессмысленным если в языке есть сопоставление с образцом (паттерн-матчинг).
kan> Но вот как можно библиотекой представлять те же структурные паттерны. Возьмём какой-нибудь Facade — что можно библиотекой оргаризовать?
Ага. Это как раз замечательный кандидат на автоматизацию. Достаточно продумать как отображать один интерфейс на другой (например, в виде атрибутов) и написать код который породит весь код Фасада по этому простому описанию.
kan> Или даже какой язык может предоставить специальную конструкцию для этого паттерна?
Nemerle! Что за несуразные вопросы, право.
kan>Паттерн — вещь абстрактная, и каждая его имплементация — конкретизация, а следовательно потеря общности.
Паттерн вещь конкретная — это детали реализации могут варьироваться. Ну, так никто не говорит, что реализация должна быть одна и она не может быть гибкой (настраивамемой). Реализаций может быть море. Как у тех же алгоритмов сортировки. А особенности так же можно описывать декларативно, а метакод будет их читать и учитывать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Но вот такая мысль: использовать к месту паттерн в отдельном проекте не так трудно, а вот "зашить" (в любом виде) тот же самый паттерн в средства разработки требует больших умственных усилий, ИМХО.
Несомненно! Но эти же слова приенимы и к алгоритмам. Причем на сегодня никто не сомневается, что алгоритмы разумно зашибвать в библиотеки, а не писать акждый раз занова.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Догадываюсь, что ФВП — это "функции высшего порядка". AVC>Т.е. речь идет исключительно о средствах языков функционального программирования?
Они как бы просто напрашиваются. Хорошие проработанные идеи. Что делать вид что их нет? Вирт не просто делает вид, что их нет. Он еще пытается их вредность доказать. Что по-моему вообще неразумно.
Вот только из ФЯ я бы в первую очередь брал бы паттерн-матчинг, замыкания и локальные функции (которые почти есть в Обероне).
Но в язык хорош было бы добавить и другие вещи вроде foreach и т.п.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
FR>О средствах которые в основном появились благодаря функциональному программированию, те же ФВП и все что с ними связано ничто ни мешает использовать и в императивных языках.
И что ты тогда споришь со мней в соседнем форуме?
ЗЫ
У меня временами создается впечатление, что есть личности которые возразить владу считают насущьной необходимостью. Причем даже если они согласны с ним.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FDSC, Вы писали:
FDS>Вся проблема в том, что нам, собственно, тогда нужен некий компилятор, который просто сможет запоминать и оперировать понятиями человека, а не какого-то конкретного языка. Совершенно абстрактными от кода понятиями. Есть подозрение, что это чуть-чуть невозможно
я бы не сказал, что паттерны понятия человека. Скорее это проекция решения некоторых задач на язык.
вся соль тут заключается в том, что паттерны касаются приложения в нескольких точках.
если все эти точки собраны в одном месте, в одной сущности, то паттерн воспринимается легко.
а если он разбросан по коду, то его и встраивать и понимать и удалять уже сложнее.
осталось дело за малым — как получать синтаксически компактные представления логики программы для конкретных паттернов.
Re[14]: Паттерны суть слабости языков программирования
FR>>Если про философию, то именно простота и понятность, а один из создателей схемы пишет: FR>>[q] FR>>Scheme, тот диалект Лиспа,
VD>Мне кажется дальше можно не читать, чтобы опнять что ты не прав. Иначе ты зря остановился еще нужно было Автокадовский диалект приплести и Емаксовский.
Не читай мне то что
Re[12]: Паттерны суть слабости языков программирования
Smerl is a library that simplifies the generation and manipulation of Erlang code in runtime.
VD>Или уж давайте тогда считать все языки поддерживающими метапрограммирование. А что? На них же можно создать проргамму? А раз так то эта программа может генерировать код. VD>Эдак у нас C# и Ява метапрограммирование допускают с их то Рефлексией...
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.
Кстати! Smerl нигде не "поганит" исходные сорцы. Все манипуляции происходят только в рантайме. То есть код он-то генерит (что от него и требовалось ), но происходит это, не затрагивая исходники. А что еще надо для щастя?
Здравствуйте, VladD2, Вы писали:
FR>>О средствах которые в основном появились благодаря функциональному программированию, те же ФВП и все что с ними связано ничто ни мешает использовать и в императивных языках.
VD>И что ты тогда споришь со мней в соседнем форуме?
Там я спорю потому что ты по моему слишком широко трактуешь понятие "синтаксический сахар"
VD>ЗЫ
VD>У меня временами создается впечатление, что есть личности которые возразить владу считают насущьной необходимостью. Причем даже если они согласны с ним.
Ну бывает, иногда
Когда согласен нет.
Re[7]: Паттерны суть слабости языков программирования
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Или же при помощи них можно добавить метапрограммирование в сам язык как в случае с эрлангом и smerl.
VD>Это не добавление МП в язык. Это фрэймворк для рантайм-кодогенерации. Эдак в любой язык можно добавить МП.
Возможно и так, только весь вопрос в том, насколько это будет просто и удобно в использовании, а также работоспособно.
Re[13]: Паттерны суть слабости языков программирования
Здравствуйте, 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>Эрланг это позволяет?
Он позволяет написать внешнюю метапрограмму. Это позволяет любой универсальный язык. Когда люди говорят о метапрограммировании в ЯП, то речь идет о средствах самого языка. Таких средств в Эрлэнг нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Паттерны суть слабости языков программирования
