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

[stdray]

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


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

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

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

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


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

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


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

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

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


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

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


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

Comments

[jdevelop.livejournal.com]

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

дальше можно не читать.

[stdray.livejournal.com]

Можно не читать. А в процитированном фрагменте что не устроило?

[jdevelop.livejournal.com]

у меня смутное подозрение, что вы никогда не отлаживали код на скале или там кложури

пример

с макросами такие вот трейсы отлаживать будет не то, чтобы сложно, а сложно в сотой степени двойки. Потому что у меня в исходном коде даже и строки такой не будет, на которой оно уебется в говно, и нужно будет чесать репу - a$b$c at Source.scala:110 при общем количестве строк в Source.scala в 20 - это куда смотреть?

так понятнее?

[xeno-by.livejournal.com]

Я уже упоминал, что макросы в Скале не текстовые. Соответственно, можно догадаться, что номера строк в сырцах они разрушать не будут. А еще просто можно взять, попробовать и убедиться.

[thesz.livejournal.com]

Они легко могут добавить некоторые дополнительные действия, не имеющиеся в исходном тексте. Оптимизированную программу отладчиком VS отлаживать трудно, что говорить про улучшения на коленке в виде макросов.

"Попробовать и убедиться" - увольте. Я уже неоднократно говорил, что Scala не подходит для эффективной работы, особенно в функциональном стиле. Вот начнут компилировать в нативный код, чтобы объекты занимали ровно столько, сколько нужно, тогда и посмотрим. Если смогут, конечно.

Тем не менее, идеи интересные есть, за что большое спасибо.

[xeno-by.livejournal.com]

Про действия согласен. С этим предлагается бороться вот как.

При генерации отладочной информации есть вариант оставлять все как есть, т.е. раскрытия макросов будут для дебаггера каждое схлопываться в одну строчку (соответствующую вызову макро-функции). Тогда стек трейсы будут нетронутыми, но посмотреть в дебаггере раскрытый исходник не получится. Так работает прямо сейчас.

А в будущем добавим вариант запоминать результаты раскрытия макросов и сохранять информацию о них в отладочной информации. Тогда дебаггер сможет по этой информации воссоздать исходник с раскрытыми макросами, и отладка будет вестись как будто этот исходник был вручную написан программистом.

Про "попробовать и убедиться" я предлагал уважаемому jdevelop в плане убедиться в том, что строки не разъезжаются от раскрытия макросов.

[thesz.livejournal.com]

>Тогда дебаггер сможет по этой информации воссоздать исходник с раскрытыми макросами, и отладка будет вестись как будто этот исходник был вручную написан программистом.

К TurboAssembler прилагался отличный отладчик. Он назывался td.exe. ТурбоДебаггер. А ещё был td386.exe, который позволял использовать больше памяти MS-DOS.

Это я к тому, что я не понаслышке знаком с отладкой раскрытых макросов.

[golikov konstantine (from livejournal.com)]

>вот начнут компилировать в нативный код

так уже же

есть scala под llvm, его конечно надо потыкать палочкой что бы убедится что оно живое, но как proof-of-concept вполне годится

[thesz.livejournal.com]

Этого мало самого по себе. Надо, чтобы накладные расходы на значения были в районе одного слова.

А то компилирующаяся в машинный код Scala будет иметь все минусы - и большие накладные расходы, и трудности с библиотеками.

[jdevelop.livejournal.com]

они НЕ МОГУТ не разрушать номера строк, по определению. Это привнесенные куски кода.

да что там макросы, взять для примера обычную скалу как она есть в 2.9.1

403 did not equal 404
org.scalatest.exceptions.TestFailedException: 403 did not equal 404
	at org.scalatest.Assertions$class.newAssertionFailedException(Assertions.scala:320)
	at animatron.restful.service.AuthenticationSvcTest.newAssertionFailedException(AuthenticationSvcTest.scala:34)
	at org.scalatest.Assertions$class.assert(Assertions.scala:411)
	at animatron.restful.service.AuthenticationSvcTest.assert(AuthenticationSvcTest.scala:34)
	at animatron.restful.service.AuthenticationSvcTest$$anonfun$7$$anonfun$apply$mcV$sp$5.apply$mcV$sp(AuthenticationSvcTest.scala:140)
	at animatron.restful.service.AuthenticationSvcTest$$anonfun$7$$anonfun$apply$mcV$sp$5.apply(AuthenticationSvcTest.scala:140)
	at animatron.restful.service.AuthenticationSvcTest$$anonfun$7$$anonfun$apply$mcV$sp$5.apply(AuthenticationSvcTest.scala:140)
	at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57)
	at spray.testkit.RouteTest$$anonfun$check$1.apply(RouteTest.scala:44)
	at spray.testkit.RouteTest$$anonfun$check$1.apply(RouteTest.scala:44)
	at spray.testkit.RouteResultComponent$RouteResult.$tilde$greater(RouteResultComponent.scala:109)
	at animatron.restful.service.AuthenticationSvcTest$$anonfun$7.apply$mcV$sp(AuthenticationSvcTest.scala:139)
	at animatron.restful.service.AuthenticationSvcTest$$anonfun$7.apply(AuthenticationSvcTest.scala:133)
	at animatron.restful.service.AuthenticationSvcTest$$anonfun$7.apply(AuthenticationSvcTest.scala:133)
	at org.scalatest.FlatSpec$$anon$1.apply(FlatSpec.scala:2987)
	at org.scalatest.Suite$class.withFixture(Suite.scala:1994)
	at animatron.restful.service.AuthenticationSvcTest.withFixture(AuthenticationSvcTest.scala:34)
	at org.scalatest.FlatSpec$class.invokeWithFixture$1(FlatSpec.scala:2984)
	at org.scalatest.FlatSpec$$anonfun$runTest$1.apply(FlatSpec.scala:2993)
	at org.scalatest.FlatSpec$$anonfun$runTest$1.apply(FlatSpec.scala:2993)
	at org.scalatest.SuperEngine.runTestImpl(Engine.scala:228)
	at org.scalatest.FlatSpec$class.runTest(FlatSpec.scala:2993)
[100500 lines skipped]

почему-то оно сначала уебалось на строке с декларацией класса, потом уже в нужном месте

тестовый код при это выглядит как:

133:  "AuthenticationService" should "fail on wrong password" in {
134:    val user = route.signup.createAccount(
135:      new EmailPasswordCredentials("123@123.com", "password"),
136:      "Jane Fox",
137:      "http://google.com")
138:    val content = new EmailPasswordCredentials("123@123.com", "passwordd")
139:    Post("/authenticate", content) ~> route.authenticate ~> check {
140:      assert(status.value === 404)
141:    }
  }

и никаких макросов, но ПЕРВЫМИ строчками в трейсе идет какой-то аццкий буллшит. При Сталине Гослинге такого не было. Я читаю эти имена функций в трейсе и мне натурально становится жалко тех людей, которым не дай бог придется это поддерживать

Теперь взять эти макросы - они сделают все только хуже и еще более нечитабельнее в плане трейсов.

[sassa-nf.livejournal.com]

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

[jdevelop.livejournal.com]

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

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

[golikov konstantine (from livejournal.com)]

specs2 кстати вроде бы таким не страдает, хотя могу ошибаться

[metaclass.livejournal.com]

Кстати, насчет номеров строк ты не совсем прав. Их можно сохранить в отладочную информацию до раскрытия макросов и так и оставить.
В C# и С++ для этого #line есть или как там его, в жабе не знаю.
Если по хорошему - то надо указывать два номера строки - до раскрытия и после раскрытия, вплоть до вкручивания оригинальных номеров внутрь манглинга имен. :)

[stdray.livejournal.com]

>с макросами такие вот трейсы отлаживать будет не то, чтобы сложно, а сложно в сотой степени двойки.

Сам по себе макрос ни строчки в стэктрейс не добавляет, его формируют вызовы функцию.
Куда и как смотреть зависит от особенностей отладчика и от правильно протаскиваемых Location через все уровни преобразования.

Игрушечный пример.

Макрос for

for(mutable i=0; i< 100; i++) {
      WriteLine(i);
}

раскрывается вот в такое представление (показан уже типизированный код)

{
  mutable i = 0;
  ((_N_break :
  {
    def loop ()   : void
    {
      match ((i < 100 : bool))
            {
        | true =>
          (
          {
            ((_N_continue :
            {

              {
                WriteLine(i)
              }
            }) : void );

            {
              [[Cache:i]]
              ;
              [[CacheRef:i]] = _N_op_Increment([[CacheRef:i]])
            };
            loop()
          } : void )
        | _  =>
          ()
      }
    };
    loop()
  }) : void )
}

Отлаживается оно самым обычным привычным образом и со строчками никакой неразберихи нет.
(http://img528.imageshack.us/img528/6129/debugmacro.png)

[jdevelop.livejournal.com]

ок, еще раз

20:    for(mutable i=0; i< 100; i++) {
21:        WriteLine(i);
22:    }

дальше по развернутому коду оно скажем упарывается в строке 45, хотя по факту упоролось в строке 21.

как я об этом догадаюсь?

примеры того, что происходит в Scala/Clojure я уже привел, номера строчек там часто вообще ничего не значат, так как могут указывать на сигнатуру класса в том числе.

[sassa-nf.livejournal.com]

совершенно справедливо. в таких случаях необходимо, чтобы top-level exception указывал 21, а caused by настоящий стектрейс развёрнутого макроса.

[proofit404.livejournal.com]

Не, ну я соглашусь с тем, что использование средства А у языка Б в неподходящем месте вызывает проблемы в неподходящее время.

Но по факту-то действительно странно такое отношение. Не нравиться не ешь. Но всем что-то пох...

[hls-1141.livejournal.com]

погроммистам только дай что-нибудь похаять, будь то макросы, ооп, динамическая типизация, etc. Хлебом не корми.

[stdray.livejournal.com]

>поняша

Что может быть хуже...

[hls-1141.livejournal.com]

макросы в скале? )

[stdray.livejournal.com]

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

[hls-1141.livejournal.com]

у него дружелюбная типизация и магическая семантика!

[udpn.livejournal.com]

Наличие макросов в языке это признание того факта, что абстракции, на которых построен язык, и которых должно хватать для всех возможных приложений, не образуют полной системы, и мы пытаемся макросами их прикрыть. В этом нет ничего плохого, это просто признак сырости языка, и, я думаю, никто не станет спорить, что Scala очень сырая. Когда появятся макросы и ребята вроде Куклева, Темерева и Бурмако начнут исследовать их применение в языке, довольно скоро появятся библиотеки, которые позволят увидеть дополнительные абстракции в языке. Перебирая наборы абстракций, рано или поздно удастся получить консистентный и универсальный, и удалить макросы из языка. Я считаю, что ребята делают всё совершенно правильно. А для того, чтобы не популяризовать макросы и не бояться за появление legacy фичи, без которой не работает совершенно ничего, Мартин как раз и не хочет, чтобы они были простыми и легкодоступными.

[stdray.livejournal.com]

Для всех возможных приложений хватает полноты по Тьюрингу, а вот с понятием консистентности применительно к языку программирования я не знаком. Я думаю, что перебирая наборы абстракций, рано или поздно можно получить язык удобный для решения более-менее определенного (пусть даже весьма широкого) круга задач. А это какая-никакая специализация. Или надо прямо сказать, мол верим в существование серебреной пули и ждем ее пришествия.