А почему макросам не радуются?

[stdray]

xeno_by написал, что макры для скалы почти вот-вот будут готовы. А люди как-то не очень радуются. Я почитал комментарии, мне что-то не понравилось такое обсуждение.


Макросы - это признание поражения. "Наш язык оказался недостаточно хорошо, нам придется генерировать программы на нём, чтобы продолжать притворяться, что мы пишем на нём".

Во-первых, тут явно подразумевается, что кодогенерация является чем-то плохим и доказывает несостоятельность языка, как средства для написания программ. Из моего ежедневного: редактировать форму мне удобней в графическом дизайнере, просматривать схему базы данных и редактировать связи между таблицами опять же удобней в графическом представлении. По-моему, очевидно, что если существуют разные способы выполнить одну работу, то надо выбирать самый удобный. И либо у нас есть серебряная пуля, либо для каждой задачи существует свой самый удобный инструмент. А чтобы это все как-то между собой взаимодействовало о совмещалось, надо приводить к одному знаменателю. Например, к текстовому представлению в виде кода на определенном языке программирования. Этот способ не единственный, но, на мой взгляд, достаточно практичный и удобный.
Во-вторых, языки развиваются и видоизменяются. При этом во время компиляции многие известные мне языки сначала рассахариваются в некоторое подмножество языковых конструкцию, после чего код на этом подможестве преобразуется в AST и поехало. Специальный синтаксис для монад (linq query syntax в C#, do-нотация в Haskell), asyc/await в C#, сахар для стрелок в том же Haskell, препроцессоры OCaml и множество других примеров. Интересно, нормально ли после каждого релиза с подобными изменениями, упрекать авторов в том, что их язык оказался недостаточно хорош?

В-третьих, существуют расширения компилятора. Для Haskell'а они активно используются и даже можно встретить мнения, что часть этих расширений пора включить в стандарт. Для C# делается некий проект Roslyn, который должен позволить пилить аналогичным образом расширения для главного языка дотнетов. На мой взгляд, это свидетельсво того факта, что разные люди по-разному видят развитие инструмента и работают в соответствующем направлении. Расширение его возможностей или наоборот специализация - это нормально. Но можно, например, заявить про признание поражения.

На мой взгляд, имеет место быть "ваша пуля не серебряная", а это как-то не серьезно.


Код с макросами очень трудно отлаживать.

Этот пойт я не понял. Я пишу на Немерле, и код с использованием макросов в отладке ни чем не отличается от кода без них. Откуда могут быть проблемы? Было выражение, потом на этапе компиляции оно раскрылось в другое выражение. И итоге получается простой линейный код с нормальными именами переменных. Проблемы - это когда стираются имена аргументов, когда стейт шарится между кучей объектов, когда стектрейс растягивается на два экрана, когда куча всего вычисляется лениво и ошибки этих вычислений экранируются и игнорируются или пихаются в стейт, когда все это вычисляется в нескольких потоках наступает ад. Макросы ничего в этот список не привносят. Есть еще отладка самих макросов, но это дело скорее неудобное чем сложное, по крайней мере, применительно к Немерле.


Практически деткам в руки дали не спички, а сразу тротиловые шашки. Представляю, что на этом могут построить наши индийские братья по разуму.

Во-первых, всем всем равно, чем занимается контингент именуемый здесь "индийские братья по разуму". Сколько лет я программирую, столько лет слышу эти рассказы, иногда вижу какие-то подтверждения. Если человек склонен к превращению кода в ад, он это сделает. Они этим занимались на Lisp, занимались на Си, занимаются на Java, будут заниматься на любом другом языке. (Я считаю, что в той или иной мере мы все к этому склонны, просто не всегда рядом есть кто-то, способный увидеть сумасшествие и указать на это, как и не всегда есть желание обсуждать подобное. А вопрос как раз и состоит в постоянном развитии и совершенствовании. И приоритеты в этом развитии могут быть разными).

Во-вторых, я не вижу, чтобы слабые программисты лезли использовать мощные и сложные средства. То есть существует некий контингент постоянно стремящийся интегрировать в проекты НОВЬЕ из последнего выпуска журнала Хакер или статей на Хабре, но там либо старшие товарищи останавливают, либо все желание пропадает, пока новатор разбирается с новой игрушкой. А те программисты, которые ничем не интересуются, пишут на небольшом примитивных подмножестве языка, мирно делаю свои велосипеды и никому жизнь портить не пытаются. (Всегда забавляет эта ежемесячная статья на Хабре "Что такое атрибуты в дотнете и зачем они нужны" и куча комментариев вроде "интересно, спасибо, прочитал") А макросы в статически типизируемом языке с негомоиконичным синтаксисом - штука сложна, очень сложная. И вроде, xeno_by говорил, мол Мартин считает, что макросы и должны быть сложными. Может по каким-то таким причинам.


Скала очень сложная и без макросов.

- Ребята, я конфетки вам принес
- Не надо, у нас уже есть БАГЕТ. Очень сытный


То есть, я каким-то серьезных аргументов против макросов в Скале пока не увидел. Не хотят люди пользоваться - никто не заставляет. Не знают, какие задачи будут решаться макросами - но ведь никто и не спрашивает. Да и часто не читают про эти самые макросы, то у там С++, то сишка, то рефлексия тормозит.

Comments

[sassa-nf.livejournal.com]

совершенно согласен. Здесь мы имеем дело с идентичной проблемой: скала нагенерировала туеву хучу кода, который я не писал, и узнать взаимодействие кучи пронумерованных $$anonfunction$$ невозможно.

[jdevelop.livejournal.com]

это проблема натягивания совы на глобус - перекладывание функционального программирования на не приспособленную для него никак вообще JVM

scala была бы ок, если бы собиралась в нативный код, или если бы у неё была своя VM, как у хаскеля.

[sassa-nf.livejournal.com]

хаскель стек трейсы печатает?

господибожемой про JVM не комментирую

[thesz.livejournal.com]

http://www.haskell.org/haskellwiki/Debugging#Other_tricks

Может.

[sassa-nf.livejournal.com]

Классно. Интересно, как там tail call отображается.

Ну и это немного отличается от возможностей, на которые намекает jdevelop. Если я понял, то собственно VM стеком не занимается, а стеком занимается каждая программа сама? Или имеется в виду, что стек-то развернуть можно всегда, да только без имён функций будет только куча цифр? те по содержимому стека можно выяснить, где IP адреса функций, а где аргументы, не зависимо от опций компиляции программы? У JVM именно так.

[thesz.livejournal.com]

Как я понимаю, стек вызовов создается по кратчайшему пути до ошибки. Боролись с ленью, что интересно. Как я понимаю, показывают строки кода и определения.

[sassa-nf.livejournal.com]

А что такое "кратчайший путь до ошибки"? Минимальное количество шагов, опуская невыполненные ленивые вычисления?

Вот с tail call бы выяснить. Поскольку после tail call на стеке не остаётся следа от caller, как можно решить вопрос трассирования пути до ошибки?

[thesz.livejournal.com]

http://www.youtube.com/watch?v=J0c4L-AURDQ

Со второй минуты начинается интересное. Три следующих кадра доклада говорят, что же они собираются делать. На 22-ой минуте демонстрация.

[sassa-nf.livejournal.com]

Так а как же с tail call быть? Дядя на видео говорит, что всё равно решено, ибо always push. Но это же создаёт проблему, разве нет? Если у меня, допустим, функция лениво генерирует список, то какой-нибудь any должен сгенерировать длиннющий стек, т.е. засоряет память, в то время как без трассировки any выбрасывает весь префикс списка, а потому может работать со списком любой длины.

[thesz.livejournal.com]

Там у него правила преобразования даны. Вас не затруднит показать вашу проблему с применением этих правил?

[sassa-nf.livejournal.com]

Ну, списка правил не вижу. Вижу push и call. Первый способ - если я правильно понял, что обсуждается два подхода - всегда добавляет элемент в стек; здесь будет рост стека при рекурсивных вызовах; то, что не является проблемой из-за TCO, становится проблемой из-за роста стека. Второй способ добавляет логику, которая призвана бороться с таким вот ростом стека.

Со слов не понятно, что на практике означает удаление "common prefix" и повторов. Мне тяжело судить, сколько информации будет утрачено, потому что в императивных языках ничего не удаляется, т.е. с таким подходом я просто не сталкивался.