Здравствуйте, xeno.by, Вы писали:
VD>>Все эти извраты решают проблемы которых просто не было бы, если бы язык педоставлял бы расширяемость и метапрограммирование.
XB>Интересно, как можно при помощи макросов реализовать тайпклассы.
Они просто на фиг не нужны. Как и многие другие навороты. Они не решают никаких прикладных проблемы. Они решают проблему языка.
А если у нас есть возможность гипер-легкого создания/расширения языка под конкретную задачу, то полиморфизм просто на фиг не упал.
Любую задачу можно решить на С или Паскале (без классов, перегрузок, классов-типов и прочей мурни). Проблема только в том, что делать это тяжело. Но всегда можно придумать язык на котором конкретная задача предметной области описывается прямым и интуитивно понятным способом. Если мы можем легко описать такой язык и легко же создать преобразователь в более низкоуровневый язык, то для решения задачи нам вообще не нужны языковые навороты.
Возьми к примеру те же парсеры. Да, несомненно, их можно писать на базе функций высшего порядка, как в прочем и на основе классов. Но так же их можно писать и на базе банальных процедур, а то и вообще без них (goto и if хватит за глаза). Вот наши Nemerle.PEG и его новейшая версия основанная на собственных алгоритмах решает эту задачу используя минимум средств. Мы не используем ФВП, используем много goto и других низкоуровневых констуркций и при этом описания парсеров у нас получается в разы более декларативным нежели аналоги на Хаскеле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, xeno.by, Вы писали:
VD>>Делайте как получается. В конце концов кому надо — привыкнут.
XB>Ты пару раз сказал про то, что люди запутаются.
Запутаются. Но кому надо напрягут мозг и разберутся. Напишете пару метров лишних мануалов, раз не хотите вводить новые конструкции в язык.
XB>Можешь, пожалуйста, привести пример такой путаницы?
Примеры ты и сам приводил. Я уже устал повторять, что люди просто не будут ничего понимать. Для них это будет член класса. Причудливый и непонятный. Они будут думать, что видят перед собой класс экзепляр которого создается в рантайме. А следовательно будут думать, что и методы (в том числе и макро-методы) будут вызваться в рантайме же.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Примеры ты и сам приводил. Я уже устал повторять, что люди просто не будут ничего понимать. Для них это будет член класса. Причудливый и непонятный. Они будут думать, что видят перед собой класс экзепляр которого создается в рантайме. А следовательно будут думать, что и методы (в том числе и макро-методы) будут вызваться в рантайме же.
Действительно, это обычный класс, просто некоторые его методы (макрометоды) себя ведут по-другому. В чем подвох? Приведи пример. Я ведь без издевки спрашиваю. Почему бы не поделиться своим опытом?
Здравствуйте, VladD2, Вы писали:
VD>Они просто на фиг не нужны. Как и многие другие навороты. Они не решают никаких прикладных проблемы. Они решают проблему языка.
Если какая-то языковая фича решает достаточно большой класс проблем более выразительно, чем макросы, я голосую за эту фичу. Как бы ты на макросах выразил тот факт, что в некий метод можно передать только объекты, для которых перегружен оператор "+"?
Здравствуйте, xeno.by, Вы писали:
VD>>Они просто на фиг не нужны. Как и многие другие навороты. Они не решают никаких прикладных проблемы. Они решают проблему языка.
XB>Если какая-то языковая фича решает достаточно большой класс проблем более выразительно, чем макросы, я голосую за эту фичу. Как бы ты на макросах выразил тот факт, что в некий метод можно передать только объекты, для которых перегружен оператор "+"?
Никому не нужно передавать операторы куда бы то ни было. Людям нужно решать проблемы. Например, вычислить зарплату. Или создать парсер/компилятор.
А все эти передачи чего-то куда-то — это детали реализации.
Так вот есть возможность решать исходные проблемы не упираясь в возможности языка.
В общем, ты мыслишь стереотипами к которым ты привык. Пока ты ты не осознаешь это ты меня не поймешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, xeno.by, Вы писали:
XB>Действительно, это обычный класс, просто некоторые его методы (макрометоды) себя ведут по-другому. В чем подвох? Приведи пример. Я ведь без издевки спрашиваю. Почему бы не поделиться своим опытом?
Если я в десятый раз повторю одно и то же, вряд ли твое понимание/мнение изменится.
В общем, пробую последний раз. Не поймешь, значит будешь понимать лбом (набивая шишки самостоятельно).
Это не фига не обычный класс, так как макрос должен компилировать задолго до начала компиляции основной программы, и так как макрос крутится в другой вселенной. Макрос — это плагин к компилятору. Во время его работы классы конечной программы еще не существуют. Есть только информация о них в виде объектов компилятора.
По сему человек разрабатывающий макрос должен четко это понимать.
Делая описание типа аналогичным описанию обычного класса вы тем самым усложняете понимание вышеизложенного тем кто будет писать макросы. Они будут путать настоящие классы и эти плэйс-холдеры.
Кроме того, как я уже показал, типы используемые для описания параметров типизированных макросов по сути не являются типами, а являются эдакими заместителями как в случае с дженерик-параметрами. По сути это не тип, а констрэйны на тип который появится в рантайме.
Маскировка этих констрэнов под тип будет так же мешать восприятию сущности макросов людьми.
Плюс вы еще будет иметь синтаксические проблемы когда захотите описать более сложные констрэйны (например, что тип должен реализовывать два интерфейса).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В общем, ты мыслишь стереотипами к которым ты привык. Пока ты ты не осознаешь это ты меня не поймешь.
Звучит как-то стремно. Влад, почему ты меня заставляешь доказывать, что я не верблюд? Почему бы просто не рассказать свои идеи, а там уже будет видно, пойму я или нет. Если я что-то не так сказал, и теперь со мной неинтересно общаться — расскажи, что не так.
VD>Так вот есть возможность решать исходные проблемы не упираясь в возможности языка.
Здравствуйте, VladD2, Вы писали:
VD>Это не фига не обычный класс
Мне кажется, я плохо сумел донести идею. Прошу прощения. Я понимаю про разницу между метакодом и объектным кодом. Я хотел провалидировать несколько другой аспект предлагаемой языковой фичи. Давай я расскажу про наше видение этой штуки, а ты поделишься впечатлениями.
Пример взят из жизни, но немного упрощен, чтобы не захламлять пост. Есть обычный класс Range, который моделирует диапазон чисел. У него есть мемберы lo и hi, а также перегружен метод toString:
class Range(val lo: Integer, val hi: Integer) {
def toString = s"range: $from - $to"
}
У этого класса есть метод foreach, который делает понятно что:
class Range(val lo: Integer, val hi: Integer) {
def toString = s"range: $lo - $hi"
def foreach(action: Integer => Unit) =
for (i <- lo to hi) action(i)
}
Теперь можно писать вот так:
new Range(1, 5).foreach(println)
println(" вышел зайчик погулять")
Этот метод явно тормозит по сравнению с обычным циклом while. Юзеры негодуют. Поэтому мы напишем макрос, который уберет замыкания и вызовы функций. Для тебя это, ессно, не новость, но немного терпения:
object Macros {
def foreach(ctx: MacroContext)(range: ctx.Expr[Range])(action: ctx.Expr[Integer => Unit]) = scala"""
val i = $range.lo
while (i < $range.hi)
${substituteClosureArgumentWithReferenceToLocalVariable(action, "i")}
"""
}
А теперь заменим старую реализацию метода foreach на макрос:
В итоге: foreach воспринимается пользователями Range как обычный метод, с понятной сигнатурой, интеллисенсом, прозрачным бинарным представлением. В отличие от extension-методов для вызова этого метода ничего не надо импортировать — он с самого начала логически находится в классе. С другой стороны, девелопером класса Range макрос воспринимается как совершенно отдельная от класса Range сущность, т.е. здесь вот, на мой взгляд, путаницы не будет.
Заранее прошу прощения, если я чего-то в очередной раз не понимаю. В таком случае надеюсь, что наше следующее обсуждение будет для тебя более приятным. Спасибо за время и усилия, потраченные в этом треде.
Здравствуйте, xeno.by, Вы писали:
XB>Звучит как-то стремно. Влад, почему ты меня заставляешь доказывать, что я не верблюд?
Я ничего никого не заставляю делать. Я говорю что вижу. Уж извини, если обидно это слышать. Я человек прямой. Но обижать никого не хочу.
XB>Почему бы просто не рассказать свои идеи, а там уже будет видно, пойму я или нет. Если я что-то не так сказал, и теперь со мной неинтересно общаться — расскажи, что не так.
Дык я рассказал. Идея проста как пробка. Вместо того чтобы выписывать программы на универсальном языке, создаем специализированный язык и решаем задачу на нем.
Что тут не понятного то?
VD>>Так вот есть возможность решать исходные проблемы не упираясь в возможности языка.
XB>Расскажи, если не секрет.
Дык уже. И не раз.
Пойми, как только ты задумываешься о решении конкретной задачи, то тебе в голову сразу же приходят готовые решения на тех языках, что ты уже знаешь. Отсюда в твоих рассуждениях появляются классы типов, перегрузка операторов и прочая не относящаяся к решению конкретной задачи ерунда.
Все гипер-навороты нужны для обхода ограниченности самого языка. Зачем в ООЯ нужны еще и классы-типов? Это ведь разновидность динамического полиморфизма. В Хасклее других средств полиморфизма просто нет. По сему классы типов оправданы. А в Скале — это дублирование функциональности.
Ничего принципиально нового классы типов не дают. Возможно они немного более гибки в некоторых случаях, но эта гибкость один фин не достаточна для выражения задачи в терминах предметной области.
У нас же есть механизм позволяющий выражать задачи прямо в терминах предеметрой области и трасформировать ее реализацию во что угодно.
Если нам нужен динамический полиморфизм мы можем использовать классы, виртуальные методы, интерфейсы и ФВП.
По делу динамический полиморфизм используется очень редко. Намного чаще с его помощью решают проблему повторного использования кода. Вот и выходит, что навороты в языке нужны просто потому, что язык хилый. И чем больше наворотов, тем хуже язык. Вот такой вот парадокс. :)
По сему мое мнение очень простое. Не нужно впихивать в язык всевозможные крутые фичи. Лучше впихнуть в язык одну фичу которая позволит заменить кучу других. И такая фича — расширяемост. Она позволяет делать ДСЛ-и под копотом у которых может быть что угодно. В том числе и код который считается не качественным, если его писать руками.
Секрет же успеха тут очень прост — мы должны сделать расширяемость языка простой до предела. Дать людям удобные и (главное) простые средства расширения языка. А уже эти люди, сами, реализуют нужные им расширения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Секрет же успеха тут очень прост — мы должны сделать расширяемость языка простой до предела. Дать людям удобные и (главное) простые средства расширения языка. А уже эти люди, сами, реализуют нужные им расширения.
Получается, мы перекладываем проблему дизайна языков на этих людей. Ведь, согласись, не так уж и просто задизайнить язык программирования, чтобы он был согласован сам с собой и не раздражал в использовании. Можно глянуть какой-нибудь end-to-end кейс-стади разработки на Немерле? Например, разработки веб-приложения. PEG действительно впечатляет, согласен, но хочется увидеть что-то более объемное.
VD>Пойми, как только ты задумываешься о решении конкретной задачи, то тебе в голову сразу же приходят готовые решения на тех языках, что ты уже знаешь. Отсюда в твоих рассуждениях появляются классы типов, перегрузка операторов и прочая не относящаяся к решению конкретной задачи ерунда... У нас же есть механизм позволяющий выражать задачи прямо в терминах предеметрой области и трасформировать ее реализацию во что угодно.
Я бы очень хотел, чтобы это сработало, ибо кроме сомнений насчет удобства ад-хок языков у меня есть сомнения еще и другого сорта.
Небольшое лирическое отступление. Начиная с прошлого лета я искал замену студии, ибо с того момента я пересел на скалу и сам понимаешь. Вначале мне очень понравился емакс. Кастомизируемый мама не горюй, можно наколбасить все, что угодно. Следующие пару недель после своего открытия я подтачивал емакс под свой воркфлоу и остался доволен результатом. Потом я приехал в Лозанну и начал использование емакса в боевых условиях. С удивлением я обнаружил, что провожу значительное время, допиливая емакс напильником. Да, тул становился все более приспособленным ко мне и все более удобным, но в какой-то момент я просто забил и перелез на эклипс.
Согласен, это всего лишь аналогия, но, надеюсь, она проиллюстрирует ход моих мыслей.
