Entry tags:
А почему макросам не радуются?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
xeno_by написал, что макры для скалы почти вот-вот будут готовы. А люди как-то не очень радуются. Я почитал комментарии, мне что-то не понравилось такое обсуждение.Макросы - это признание поражения. "Наш язык оказался недостаточно хорошо, нам придется генерировать программы на нём, чтобы продолжать притворяться, что мы пишем на нём".
Во-первых, тут явно подразумевается, что кодогенерация является чем-то плохим и доказывает несостоятельность языка, как средства для написания программ. Из моего ежедневного: редактировать форму мне удобней в графическом дизайнере, просматривать схему базы данных и редактировать связи между таблицами опять же удобней в графическом представлении. По-моему, очевидно, что если существуют разные способы выполнить одну работу, то надо выбирать самый удобный. И либо у нас есть серебряная пуля, либо для каждой задачи существует свой самый удобный инструмент. А чтобы это все как-то между собой взаимодействовало о совмещалось, надо приводить к одному знаменателю. Например, к текстовому представлению в виде кода на определенном языке программирования. Этот способ не единственный, но, на мой взгляд, достаточно практичный и удобный.
Во-вторых, языки развиваются и видоизменяются. При этом во время компиляции многие известные мне языки сначала рассахариваются в некоторое подмножество языковых конструкцию, после чего код на этом подможестве преобразуется в AST и поехало. Специальный синтаксис для монад (linq query syntax в C#, do-нотация в Haskell), asyc/await в C#, сахар для стрелок в том же Haskell, препроцессоры OCaml и множество других примеров. Интересно, нормально ли после каждого релиза с подобными изменениями, упрекать авторов в том, что их язык оказался недостаточно хорош?
В-третьих, существуют расширения компилятора. Для Haskell'а они активно используются и даже можно встретить мнения, что часть этих расширений пора включить в стандарт. Для C# делается некий проект Roslyn, который должен позволить пилить аналогичным образом расширения для главного языка дотнетов. На мой взгляд, это свидетельсво того факта, что разные люди по-разному видят развитие инструмента и работают в соответствующем направлении. Расширение его возможностей или наоборот специализация - это нормально. Но можно, например, заявить про признание поражения.
На мой взгляд, имеет место быть "ваша пуля не серебряная", а это как-то не серьезно.
Код с макросами очень трудно отлаживать.
Этот пойт я не понял. Я пишу на Немерле, и код с использованием макросов в отладке ни чем не отличается от кода без них. Откуда могут быть проблемы? Было выражение, потом на этапе компиляции оно раскрылось в другое выражение. И итоге получается простой линейный код с нормальными именами переменных. Проблемы - это когда стираются имена аргументов, когда стейт шарится между кучей объектов, когда стектрейс растягивается на два экрана, когда куча всего вычисляется лениво и ошибки этих вычислений экранируются и игнорируются или пихаются в стейт, когда все это вычисляется в нескольких потоках наступает ад. Макросы ничего в этот список не привносят. Есть еще отладка самих макросов, но это дело скорее неудобное чем сложное, по крайней мере, применительно к Немерле.
Практически деткам в руки дали не спички, а сразу тротиловые шашки. Представляю, что на этом могут построить наши индийские братья по разуму.
Во-первых, всем всем равно, чем занимается контингент именуемый здесь "индийские братья по разуму". Сколько лет я программирую, столько лет слышу эти рассказы, иногда вижу какие-то подтверждения. Если человек склонен к превращению кода в ад, он это сделает. Они этим занимались на Lisp, занимались на Си, занимаются на Java, будут заниматься на любом другом языке. (Я считаю, что в той или иной мере мы все к этому склонны, просто не всегда рядом есть кто-то, способный увидеть сумасшествие и указать на это, как и не всегда есть желание обсуждать подобное. А вопрос как раз и состоит в постоянном развитии и совершенствовании. И приоритеты в этом развитии могут быть разными).
Во-вторых, я не вижу, чтобы слабые программисты лезли использовать мощные и сложные средства. То есть существует некий контингент постоянно стремящийся интегрировать в проекты НОВЬЕ из последнего выпуска журнала Хакер или статей на Хабре, но там либо старшие товарищи останавливают, либо все желание пропадает, пока новатор разбирается с новой игрушкой. А те программисты, которые ничем не интересуются, пишут на небольшом примитивных подмножестве языка, мирно делаю свои велосипеды и никому жизнь портить не пытаются. (Всегда забавляет эта ежемесячная статья на Хабре "Что такое атрибуты в дотнете и зачем они нужны" и куча комментариев вроде "интересно, спасибо, прочитал") А макросы в статически типизируемом языке с негомоиконичным синтаксисом - штука сложна, очень сложная. И вроде,
xeno_by говорил, мол Мартин считает, что макросы и должны быть сложными. Может по каким-то таким причинам.Скала очень сложная и без макросов.
- Ребята, я конфетки вам принес
- Не надо, у нас уже есть БАГЕТ. Очень сытный
То есть, я каким-то серьезных аргументов против макросов в Скале пока не увидел. Не хотят люди пользоваться - никто не заставляет. Не знают, какие задачи будут решаться макросами - но ведь никто и не спрашивает. Да и часто не читают про эти самые макросы, то у там С++, то сишка, то рефлексия тормозит.
no subject
господибожемой про JVM не комментирую
no subject
Может.
no subject
Ну и это немного отличается от возможностей, на которые намекает jdevelop. Если я понял, то собственно VM стеком не занимается, а стеком занимается каждая программа сама? Или имеется в виду, что стек-то развернуть можно всегда, да только без имён функций будет только куча цифр? те по содержимому стека можно выяснить, где IP адреса функций, а где аргументы, не зависимо от опций компиляции программы? У JVM именно так.
no subject
no subject
Вот с tail call бы выяснить. Поскольку после tail call на стеке не остаётся следа от caller, как можно решить вопрос трассирования пути до ошибки?
no subject
Со второй минуты начинается интересное. Три следующих кадра доклада говорят, что же они собираются делать. На 22-ой минуте демонстрация.
no subject
no subject
no subject
Со слов не понятно, что на практике означает удаление "common prefix" и повторов. Мне тяжело судить, сколько информации будет утрачено, потому что в императивных языках ничего не удаляется, т.е. с таким подходом я просто не сталкивался.