на Хабре появилась статья о метапрограммировании.
Все выглядит вполне убедительно, пока не оказывается, что автор, с небывало утонченным юмором, использует для этого Javascript.
а весь список используемых им(и) языков, надо полагагать, для этих целей тоже:
· C# .NET · PHP 4 and 5
· C++ .NET, C++ for Win32
(Visual C++, GCC, Borland C++ Builder) · Delpli and Pascal
(Object Pascal, Borland Delphi, Kylix, Free Pascal)
· Assembler x86,8080, Win32 · Java (J2EE, J2ME)
· JavaScript · PEARL
Радует то, что все это в куче называется Meta Systems (Украины).
Здравствуйте, _Claus_, Вы писали:
_C_>на Хабре появилась статья о метапрограммировании. _C_>Все выглядит вполне убедительно, пока не оказывается, что автор, с небывало утонченным юмором, использует для этого Javascript.
Я предупредил, что юмор утонченный, вот напр. любимый кусочек:
"Но более того, мета-модель содержит еще и интерпретируемые скрипты для выражения бизнес-логики, скрипты получают уже развернутую в памяти декларативную часть мета-модели в свое полное распоряжение и могут обращаться к библиотеками. Тут все подумали про JavaScript конечно."
Здравствуйте, _Claus_, Вы писали:
_C_>на Хабре появилась статья о метапрограммировании. _C_>Все выглядит вполне убедительно, пока не оказывается, что автор, с небывало утонченным юмором, использует для этого Javascript.
Показательный пример. Отлично демонстрирует уровень среднего хабровца.
Мало того, что сам автор не понимает о чем говорит, так из всех кто влез в обсуждение в теме только ffriend (и, возможно еще пара товарищей). Остальные демонстрируют полное не понимание и вау-эффект.
То что товарищ называет метапрограммированием и "динамическая интерпретация метамоделей" (с) по жизни является банальным интерпретатором сделанным без применения метапрограммирования как такового. Просто для товарища явилось откровением то, что ЯП могут не иметь сходства с жабаскриптом или Явой.
Определение МП, классификация и и разглагольствования про парадигмы и метаподели — вообще являются фееричным бредом.
В общем, смешного тут мало. Все это очень печально. Это показывает, что большинство программистов (или, по крайней мере посетителей хабра) просто не понимают сути метапрограммирования и ДСЛ-естроения, а стало быть не готовы к этим технологиям.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>В общем, смешного тут мало. Все это очень печально. Это показывает, что большинство программистов (или, по крайней мере посетителей хабра) просто не понимают сути метапрограммирования и ДСЛ-естроения, а стало быть не готовы к этим технологиям.
Ты упускаешь позитивные моменты. Во-первых это показательный пример того, что нельзя одновременно читать книжку по Javascript и статьи по метапрограммированию, — очень вероятна диффузия. Во-вторых, этот мужчина еще и кто-то по академической иерархии Украины, и дописав еще десяток страниц
он превратит это в докторскую диссертацию по теме примерно "Метапрограмирование как обратная сторона JavaScriptа", которую я б тоже почитал бы.
Здравствуйте, VladD2, Вы писали:
VD>Это показывает, что большинство программистов (или, по крайней мере посетителей хабра) просто не понимают сути метапрограммирования и ДСЛ-естроения, а стало быть не готовы к этим технологиям.
Я думаю, что это не совсем правильный посыл. У меня, например, всегда было так, что я начинал понимать суть того или иного подхода только основательно его поюзав.
Здравствуйте, Visor2004, Вы писали:
VD>>Это показывает, что большинство программистов (или, по крайней мере посетителей хабра) просто не понимают сути метапрограммирования и ДСЛ-естроения, а стало быть не готовы к этим технологиям.
V>Я думаю, что это не совсем правильный посыл. У меня, например, всегда было так, что я начинал понимать суть того или иного подхода только основательно его поюзав.
А в чем не верен посыл? Я констатирую факт. С тобой я тоже согласен. Пока не попробуешь, не поймешь. Но вот такие вот "статьи" только ухудшают положение, так как вносят в неподготовленные головы сумбур.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Claus_, Вы писали:
_C_>на Хабре появилась статья о метапрограммировании. _C_>Все выглядит вполне убедительно, пока не оказывается, что автор, с небывало утонченным юмором, использует для этого Javascript. _C_>а весь список используемых им(и) языков, надо полагагать, для этих целей тоже:
Да, все это забавно, кто то воздыхает о уровне развития общества в области метапрограммирования, а я наоборот вижу положительные тенденции в этом. Это говорит о том, что все больше людей находят полезным использование идей метапрограммирования, то есть естественным путем приходят к потребности в этом, чтобы оперировать кодом как данными и программам не просто выполнять некоторые функции, но и уметь переписывать себя самих. Что само общество естественным путем приходит к пользе метапрограммирования и хочет применять его в своих программах, именно так создавались все вещи на свете от простой потребности, поиска, нахождения решения. По статье видно что человек действительно серьезно занялся вопросом, влез в определения, проверил разные способы из имеющихся и копал идею, хотя это больше похоже на изобретение велосипеда, усатым дядькой, сто с лишним лет назад, уверенным что он сделал невероятное открытие и с серьезным видом глядя в объектив, но достойно уважения искренний поиск исследователя.
Общество нуждается в мощных инструментах для метапрограммирования, сколько уже всевозможных попыток: отражение, перепись IL, динамическая компиляция, интерпретаторы... Немерле предлагает свои интересные подходы для решения этих проблем, и часто позволяет решить большинство, но мне кажется еще не все. Например, не достает до полноты некоторой свободы в динамике например, то есть во время работы оперировать программой, как это делается в Рослине, но в ужасном текстовом виде, если бы совместить все возможные подходы и сделать качественные решения, чтобы программы могли себя изменять не только во время компиляции, но например переписыватся во время выполнения.
То есть в этом направление еще не даны все ответы, общество языкостроителей ищут компромисса в анализе во время компиляции и помещение информации в типы во время выполнения, то есть умных типов, зависимые типы и разные подходы, вот на все эти вопросы хорошо бы найти качественные решения.
Здравствуйте, VladD2, Вы писали:
VD>А в чем не верен посыл? Я констатирую факт. С тобой я тоже согласен. Пока не попробуешь, не поймешь. Но вот такие вот "статьи" только ухудшают положение, так как вносят в неподготовленные головы сумбур.
Черт его знает, что лучше, сумбур или вакуум. У меня лично по всем технологиям цепочка такая: вукуум — сумбур — понимание. Через сумбур ни разу не получилось проскочить.
Здравствуйте, CodingUnit, Вы писали:
CU>Например, не достает до полноты некоторой свободы в динамике например, то есть во время работы оперировать программой, как это делается в Рослине, но в ужасном текстовом виде, если бы совместить все возможные подходы и сделать качественные решения, чтобы программы могли себя изменять не только во время компиляции, но например переписыватся во время выполнения.
Поклеп и провокация.
Немерле это с рождения умеет.
Ибо Nemerle.Compiler.dll можно когда угодно запускать.
CU>То есть в этом направление еще не даны все ответы, общество языкостроителей ищут компромисса в анализе во время компиляции и помещение информации в типы во время выполнения, то есть умных типов, зависимые типы и разные подходы, вот на все эти вопросы хорошо бы найти качественные решения.
Баловство это все.
Правильный ответ это иерархия языков.
Ибо лучший способ решить задачу это ДСЛ.
Но переписывать его сразу в язык низкого уровня очень сложно.
Поэтому нужно делать иерархию языков.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Поклеп и провокация. WH>Немерле это с рождения умеет. WH>Ибо Nemerle.Compiler.dll можно когда угодно запускать.
Как результат работы Nemerle.Compiler использовать во время работы чтобы к работающей программе подкомпилировать результат, например:
class Test
{
public Method() : void {...}
public Method2() : void
{
def ty = this.GetTypeBuilder();
def mem = ty.GetMember("Method");
def check = <[if ($check) .. else .. ]>;
mem.Body = <[ $check; $(mem.Body) ]>;
}
}
// то есть тоже что dynamic но с квазицитированием и более удобно
WH>Баловство это все. WH>Правильный ответ это иерархия языков. WH>Ибо лучший способ решить задачу это ДСЛ. WH>Но переписывать его сразу в язык низкого уровня очень сложно. WH>Поэтому нужно делать иерархию языков.
Ну пожалуйста, я и сказал что нужно качественное решение встроенное в язык, что это будет за ДСЛ непонятно, пока все равно не ясно. Работа с же динамикой подобна компиляции только работает во время выполнения.
Здравствуйте, CodingUnit, Вы писали:
CU>Как результат работы Nemerle.Compiler использовать во время работы чтобы к работающей программе подкомпилировать результат, например:
Собираешь из квазицитат программу.
Компилируешь.
Получаешь сборку.
Грузишь ее в приложение.
Через Activator.CreateInctance создаешь свежесобранный класс.
Приводишь к нужному интерфейсу.
Радуешься жизни.
Есть ли удобный способ это проделать я не знаю. Мне оно не надо.
CU>Ну пожалуйста, я и сказал что нужно качественное решение встроенное в язык, что это будет за ДСЛ непонятно, пока все равно не ясно.
Ты не понял, про что я писал.
Языки общего назначения не нужны. Совсем.
CU>Работа с же динамикой подобна компиляции только работает во время выполнения.
Динамическую типизацию я вообще не рассматриваю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
CU>>Как результат работы Nemerle.Compiler использовать во время работы чтобы к работающей программе подкомпилировать результат, например: WH>Собираешь из квазицитат программу. WH>Компилируешь. WH>Получаешь сборку. WH>Грузишь ее в приложение. WH>Через Activator.CreateInctance создаешь свежесобранный класс. WH>Приводишь к нужному интерфейсу. WH>Радуешься жизни.
WH>Есть ли удобный способ это проделать я не знаю. Мне оно не надо.
Удобного — нет. Но сделать можно. Все что для этого нужно сделать — это создать экземпляр наследника ManagerClass и проинициализировать контекст. Именно это и делает Интеграция со студией.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Черт его знает, что лучше, сумбур или вакуум. У меня лично по всем технологиям цепочка такая: вукуум — сумбур — понимание. Через сумбур ни разу не получилось проскочить.
Сумбур ничего кроме сумбура родить не может.
Есть куча качественных материалов по МП. Не фига изучать что-то на основании статей тех кто сам запутался.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Черт его знает, что лучше, сумбур или вакуум. У меня лично по всем технологиям цепочка такая: вукуум — сумбур — понимание. Через сумбур ни разу не получилось проскочить.
VD>Сумбур ничего кроме сумбура родить не может.
Ессно. Но при вакууме вообще не возникает желания читать что-то по теме. Разве что по работе нужно, так это почти невероятно, что вдруг стало нужно МП, если ты про него не слышал даже.
VD>Есть куча качественных материалов по МП. Не фига изучать что-то на основании статей тех кто сам запутался.
Здравствуйте, Ziaw, Вы писали:
Z>Ессно. Но при вакууме вообще не возникает желания читать что-то по теме. Разве что по работе нужно, так это почти невероятно, что вдруг стало нужно МП, если ты про него не слышал даже.
Тогда надо по больше треша. И везде давать ссылку на нас.
Z>Поди еще и на русском? Ты про свои статьи что-ли?
