Здравствуйте, Mystic, Вы писали:
M>Я постарался поиграться с макросами, то, что мне хотелось, заимплементить не сумел и забросил это занятие. Так что или макросы сложные, или моих мозгов не хватило.
M>А там, где Nemerle прост, там есть и другие языки
Вобщем да. Такая проблема есть. Вход в макросы осложняется неполнотой и разбросанностью документации. Плюс разношерстным дизайном внутри компилятора. Это обусловлено историческими причинами, надеюсь с N2 все будет получше.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mystic, Вы писали:
M>>Я постарался поиграться с макросами, то, что мне хотелось, заимплементить не сумел и забросил это занятие.
VD>А спросить на форуме религия не позволила?
Вроде заходил разговор, речь шла про реализацию адского синтаксиса. Конкретно про конструкцию типа
[Label: Block_Name]
[declare Arg1: Type1; [Arg2: Type2 ... ]]
begin
-- Some code ...
exit [Block_Name] [when Condition];
end;
Ясного ответа/подсказки не было, был только тонкий намек, типа это нафиг надо
Здравствуйте, Ikemefula, Вы писали:
I>>>Изучение синтаксиса сложнее изучения имеющегося фреймворка Потому что, как правило, необходимо быть в курсе всех трансляций макроса в конкретные конструкции фреймворка.
VD>>Снова несешь высасанную из пальца чушь.
I>Весомый аргумент.
Аргументы должен высказывать тот кто делает утверждения. Опровергать чужую чушь — это очень не продуктивное занятие. Ее можно на генерировать очень много.
Отрицательный опыт, кстати, тоже ни разу не может являться аргументом. Например, в девятнадцатом веке было множество попыток построить аппарат тяжелее воздуха и поднять его в воздух. Все они, до определенного момента, заканчивались неудачами. Но доказывает ли это невозможность решения поставленной задачи? Конечно нет. Точно так же и твой отрицательный опыт ровным счетом ничего не стоит.
I>>>Взять вот Linq тот же — вроде просто, а все равно надо изучить возможные трансляции.
VD>>Зачем? Надо понимать, что делают его конструкции.
I>Затем что бы понимать что делают его конструкции. Вот после того, как Linq освоишь, про это можно и забыть.
Я вообще с трудом понимаю как ты занимаешься разработкой софта с такими жизненными позициями. Ты уверен, что правильно понимаешь процессы которые происходят в контроллерах и устройствах хранения информации в тот момент как ты обращаешься к фалу? А как можно быть уверенным в том что будет делать процессор, если твоя программа компилируется даже не в машинный код, а в байткод?
Чтобы понимать что делает код нужно всего лишь понимать его семантику, что знает — понимать, что делает код. Вот такая вот простая рекурсивная логика. Знать что "под капотом" несомненно полезно для общего развития, для использования некоторого языка (в том числе и ДСЛ-я) нужно всего лишь знать его семантику, и возможно, иметь некоторую практику.
Скажем, во что переписывается SQL современным SQL-сервером не может сказать никто включая многих его авторов, так как это очень сложный процесс. Не отказываться же по этому поводу от SQL-я?
Потом как раз в случае с макросами, в отличии от вмонтированных в язык конструкций, ты как раз можешь изучить их устройство и наблюдать во что они раскрываются. Так что если бы твой аргумент был бы верен, то он был бы за макросы, а не против них.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mystic, Вы писали:
M>Вроде заходил разговор, речь шла про реализацию адского синтаксиса. Конкретно про конструкцию типа
M>
M>begin
M> -- Some code ...
M>end;
M>
M>Ясного ответа/подсказки не было, был только тонкий намек, типа это нафиг надо
В общем — да. Ты зачем-то занялся изобретением нового языка, а не освоением макросов. Эдак можно почти любой предмет признать бесполезным на том лишь основании, что он не подходит для забивания им гвоздей.
Ты конечно можешь сделать свой синтаксис, но для этого на сегодня нужно сделать парсер языка. Такой пример есть — прасер C# 4. Подключить свой парсер к Nemerle не трудно. Вот только это совсем не то для чего нужны макросы, и изучать на базе этого макросы точно является ошибкой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты конечно можешь сделать свой синтаксис, но для этого на сегодня нужно сделать парсер языка. Такой пример есть — прасер C# 4. Подключить свой парсер к Nemerle не трудно. Вот только это совсем не то для чего нужны макросы, и изучать на базе этого макросы точно является ошибкой.
Хотелось добавить строгость и академичность Ады и посмотреть, что получится. Расширить императивный мир. Ну хорошо, упростим до такой конструкции
Block_Name>> {
if (Something) exit Block_Name;
exit Block_Name when Something;
} <<Block_Name
Вроде как все понятно. Вроде даже полезная конструкция, некоторый именованный блок, расширяющий возможность императивного программирования. Для строгости, имя дублируется также и в конце блока (раньше ловим ошибки неправильной вложенности, более информативное сообщение). Есть также инструкции выхода из блока. Конечно, есть нюанс в том, что вся эта академичность конструкций не очень ложится на синтаксис...
Здравствуйте, VladD2, Вы писали:
I>>Затем что бы понимать что делают его конструкции. Вот после того, как Linq освоишь, про это можно и забыть.
VD>Чтобы понимать что делает код нужно всего лишь понимать его семантику, что знает — понимать, что делает код. Вот такая вот простая рекурсивная логика.
Эту рекурсивную логику уже давно забраковали в Мит и в Стенфорде, она не годится ни для обучения ни для повышения квалификации.
Естественно, все не нужно изучать в подробностях. Для того, что бы понять, как работает современный процессор вовсе не нужно быть его проектировщиком, вполне хватит знаний про любой из процессоров общего назначения которые производились последние 20 лет.
VD>Скажем, во что переписывается SQL современным SQL-сервером не может сказать никто включая многих его авторов, так как это очень сложный процесс. Не отказываться же по этому поводу от SQL-я?
Представлять и понимать план выполнения SQL — в обязательном порядке. С Linq точно так же — знать до уровня байткода не нужно, а вот в какие вызовы функций транслируется запрос необходимо в обязательном порядке.
VD>Потом как раз в случае с макросами, в отличии от вмонтированных в язык конструкций, ты как раз можешь изучить их устройство и наблюдать во что они раскрываются. Так что если бы твой аргумент был бы верен, то он был бы за макросы, а не против них.
Ты, похоже, плохо умеешь читать. Макросы лично меня устраивают. Меня не устраивает кривая вхождения макросов и языка немерле, открытые вопросы с легаси кодом, т.е. тупо — где брать девелоперов, если по объявлениям приходят люди, которые даже рекурсию не могут
Если бы ты хотя бы иногда забрало приподымал, глядишь, прочел бы много интересного в уже прочтённых сообщениях
Здравствуйте, Mystic, Вы писали:
M>Хотелось добавить строгость и академичность Ады и посмотреть, что получится. Расширить императивный мир. Ну хорошо, упростим до такой конструкции
M>
M>Block_Name>> {
M> if (Something) exit Block_Name;
M> exit Block_Name when Something;
M>} <<Block_Name
M>
Такая конструкция уже есть. Только синтаксис немного другой:
Block_Name :
{
when (Something)
Block_Name();
}
Разве что имени в конце блока нет, так как не нужно (со скобками разбирается сам компилятор и интеграция), и не в духе языка.
M>Вроде как все понятно. Вроде даже полезная конструкция, некоторый именованный блок, расширяющий возможность императивного программирования. Для строгости, имя дублируется также и в конце блока (раньше ловим ошибки неправильной вложенности, более информативное сообщение). Есть также инструкции выхода из блока. Конечно, есть нюанс в том, что вся эта академичность конструкций не очень ложится на синтаксис...
Ага. Совсем не ложится. И не академичность, а синтаксис.
Еще она синтаксически неоднозначна.
Но главное, что это какое-то странное занятие переписыванием языка. Мне кажется, что для обучения нужно было бы взять что-то с одной стороны по проще, а с другой по практичнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Такая конструкция уже есть. Только синтаксис немного другой: VD>
VD>Block_Name :
VD>{
VD> when (Something)
VD> Block_Name();
VD>}
VD>
VD>Разве что имени в конце блока нет, так как не нужно (со скобками разбирается сам компилятор и интеграция), и не в духе языка.
Со скобками разбирается обычно программист. Компилятор говорит: пропущено. В том месте, где смог определить. Интеграция подсвечивает скобки, но часто они не попадают на один экран.
А конструкция when (Something) Block_Name(); как по мне дико неочевидная. Еще парочка таких макросов, и можно будет повеситься.
Здравствуйте, VladD2, Вы писали:
VD>Ты конечно можешь сделать свой синтаксис, но для этого на сегодня нужно сделать парсер языка. Такой пример есть — прасер C# 4. Подключить свой парсер к Nemerle не трудно. Вот только это совсем не то для чего нужны макросы, и изучать на базе этого макросы точно является ошибкой.
Ну так написали бы хороший язык, ну хоть для юнит-тестирования, всех делов то А то или калькуляторы или C#.
Здравствуйте, Ikemefula, Вы писали:
I>Ну так написали бы хороший язык, ну хоть для юнит-тестирования, всех делов то А то или калькуляторы или C#.
Кому надо описали свои языки. Например, вот здесь человек описал парсер Теха. А здесь можно увидеть макрос Nemerle.Xml использующий Nemerle.Peg для разбора XML-подобного ДСЛ (вот тесты).
и сделать все как там написано (а делать там надо не много).
Уверяю тебя, что за вечер ты спокойно освоишь Nemerle.Peg (если, конечно знаком с C#).
Что касается использования проекта из под VS 2010, то думаю, это можно сделать если создать C#-проект и в его теле, за импортом шапового targets-а вставить строчку:
Здравствуйте, Ikemefula, Вы писали:
I>Эту рекурсивную логику уже давно забраковали в Мит и в Стенфорде, она не годится ни для обучения ни для повышения квалификации.
Пруф линк в студию.
I>Естественно, все не нужно изучать в подробностях. Для того, что бы понять, как работает современный процессор вовсе не нужно быть его проектировщиком, вполне хватит знаний про любой из процессоров общего назначения которые производились последние 20 лет.
Ну, вот и для того чтобы понять как работает простенький ДСЛ не нужно изучать его устройство. Вполне хватит знаний про любой из ДСЛ-ей.
VD>>Скажем, во что переписывается SQL современным SQL-сервером не может сказать никто включая многих его авторов, так как это очень сложный процесс. Не отказываться же по этому поводу от SQL-я?
I>Представлять и понимать план выполнения SQL — в обязательном порядке. С Linq точно так же — знать до уровня байткода не нужно, а вот в какие вызовы функций транслируется запрос необходимо в обязательном порядке.
Это очередная ошибка. Транслируют провайдыер. Так что во что они там странслируют в общем случае неизвестно. А посмотреть на реальный SQL реального запроса или оценить его эффективность можно обычным профайлером.
VD>>Потом как раз в случае с макросами, в отличии от вмонтированных в язык конструкций, ты как раз можешь изучить их устройство и наблюдать во что они раскрываются. Так что если бы твой аргумент был бы верен, то он был бы за макросы, а не против них.
I>Ты, похоже, плохо умеешь читать.
А, ну, да.
I> Макросы лично меня устраивают. Меня не устраивает кривая вхождения макросов и языка немерле, открытые вопросы с легаси кодом, т.е. тупо — где брать девелоперов, если по объявлениям приходят люди, которые даже рекурсию не могут
Ты опять что-то выдумываешь. Я только не пойму, — зачем?
Нет никаких проблем ни с вхождением, ни темболее с легаси. Девеловперов только позови. К тебе тут же предложения последуют. Да и не проблема это вовсе. Любой кто освоил C# освоит Nemerle на уровне дстаточном для написания программ где-то за 2-3 недели. Применение макросов тоже не требует никаких особых знаний. Вот их разработка — это другое дело. Как и в любом серьезном деле это дело должны делать люди с головой и руками.
I>Если бы ты хотя бы иногда забрало приподымал, глядишь, прочел бы много интересного в уже прочтённых сообщениях
Я вижу только один отмазки в твоих сообщениях. Те кто вместо того чтобы искать отмазки взял и попробовал сам обычно резко меняют свое мнение. От Ziaw один из них. Не так давно он так же излагал свои предположения по поводу гипотетических проблем. Но потом попробовал и оказалось, что на практике все довольно просто, а страшилки оказываются не более чем мифами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Вобщем да. Такая проблема есть. Вход в макросы осложняется неполнотой и разбросанностью документации. Плюс разношерстным дизайном внутри компилятора. Это обусловлено историческими причинами, надеюсь с N2 все будет получше.
Да, уж. Постараемся сделать так, чтобы Н2 не подкачал ни в этом, ни в каком-либо другом плане.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mystic, Вы писали:
M>Со скобками разбирается обычно программист. Компилятор говорит: пропущено. В том месте, где смог определить. Интеграция подсвечивает скобки, но часто они не попадают на один экран.
Ну, зачем рассуждать о каких-то там гипотетических проблемах? Есть же практика большого количества людей. Если бы скобки были бы проблемой, то хоть кто-то эту проблему озвучил бы. Мы же не в 20-ом веке живет?
M>А конструкция when (Something) Block_Name(); как по мне дико неочевидная. Еще парочка таких макросов, и можно будет повеситься.
Вообще-то это не макрос. И что в нем не очевидного я не знаю. Она кроме всего прочего позволяет вернуть значение.
def result = Block_Name : {
when (Something)
Block_Name(42);
12
};
На практике блоки используют редко. Но они являются строительными блоками для макросов: return, breack, continue и т.п.
Ну, и позволяют обойти некоторые ограничения Си-подобных языков, вроде выхода из нескольких вложенных циклов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 4UBAKA, Вы писали:
UBA>Я о готовых продуктах, а не о языке.
А тебе не кажется что их такие как ты должны писать? Не могут же те кто работает по 8 часов на работе, а потом еще по 4 над компилятором и интеграцией еще и какой-то другой софт писать?
А вот такие как ты сидят дружной кучей и ждут когда-то сделает что-то и заработает на этом денег. Причем так-как каждый из них смотрит на других, то все вместе ничего не делают.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
VD>>Так вот не надо обезьян сажать интерфейсы делать. Лучше посадить одного хорошего дизайнера который быстро оформит интерфейсы как надо. А код форм сгенерировать автоматом по описанию на ДСЛ-е или еще как-то.
I>Пока что такой ДСЛ не родили
Ну так роди. Не я же за тебя это делать буду?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
KV>>Я вообще не понимаю, о чем спор. Я — не выпускник бауманки. Я учился на эксплуатацию систем, а не на их разработку. Из всего программирования у нас был паскаль и ассемблер, когда учились промышленных роботов программировать
I>Вообще говоря это уже _очень_ и _очень_ не слабо.
I>Итого — кое какой опыт с использованием трех языков. А люди идут в программинг хорошо если один с грехом пополам освоят — чисто из за денег.
Как вы вообще что-то писать умудряетесь? Вы же похоже вообще каких то бомжей на работу дебете.
Сколько у вас зарплата для рядового программиста?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
UBA>>Я о готовых продуктах, а не о языке.
VD>А тебе не кажется что их такие как ты должны писать?
Нет, я ж не программист.
VD>Не могут же те кто работает по 8 часов на работе, а потом еще по 4 над компилятором и интеграцией еще и какой-то другой софт писать?
Ну не могут же большие компании просто так поверить VladD2 и впрячься деньгами и т.п., нужно как-то заинтересовать/убедить.
Только, я так понял, для души?
Так и не надо лезть другими в неё.
VD>А вот такие как ты сидят дружной кучей и ждут когда-то сделает что-то и заработает на этом денег. Причем так-как каждый из них смотрит на других, то все вместе ничего не делают.
Здравствуйте, 4UBAKA, Вы писали:
VD>>А вот такие как ты сидят дружной кучей и ждут когда-то сделает что-то и заработает на этом денег. Причем так-как каждый из них смотрит на других, то все вместе ничего не делают.
UBA>И снова мимо.
Что мимо-то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>А вот такие как ты сидят дружной кучей и ждут когда-то сделает что-то и заработает на этом денег. Причем так-как каждый из них смотрит на других, то все вместе ничего не делают.
UBA>>И снова мимо.
VD>Что мимо-то?
Всё.
Я ни чего не жду, а занимаюсь, тем, чем занимаюсь, а кто-то мечтает:
На самом деле будь за плечами Немерла большая контора и ее пиар, он бы проник в массы со скоростью которая и не снилась никому.
