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

Crossposts: http://stdray.livejournal.com/75842.html

Entry tags:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Flat | Top-Level Comments Only

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

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

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

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

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

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

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

Про "попробовать и убедиться" я предлагал уважаемому

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

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

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

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

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

так уже же

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

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

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

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

Ленивые значения в Хаскеле как считать - одно значение в районе одного слова или это thunk в районе одного слова+одно значение?

Вот пример (я его уже неоднократно приводил).

http://hackage.haskell.org/packages/archive/containers/0.1.0.1/doc/html/src/Data-IntSet.html#IntSet

Значение с конструктором Tip займет два слова. Значение с конструктором Bin займёт 5 слов. Bin, как легко понять, вдвое меньше, чем Tip. В среднем, получится 3.5 слов на значение. В Java не получится лучше, чем 4,5 слов на значение.

Сколько слов займут эти два конструктора в Скале?

А как вы расчитываете количество слов на значение в джаве?

Не вижу, почему бы скале быть в этом случае хуже, чем в джаве.

  case class IntSet;
  case class Nil extends IntSet;
  case class Tip(v:Int) extends IntSet;
  case class Bin(prefix:Int, mask:Int, left:IntSet, right:IntSet) extends IntSet;

генерирует ничего особенного:

Compiled from "a.scala"
public class a$Bin extends a$IntSet implements scala.ScalaObject,scala.Product,scala.Serializable {
  private final int prefix;

  private final int mask;

  private final a$IntSet left;

  private final a$IntSet right;
...(больше никаких полей не объявлено)
Compiled from "a.scala"
public class a$Tip extends a$IntSet implements scala.ScalaObject,scala.Product,scala.Serializable {
  private final int v;
...(больше никаких полей не объявлено)

http://www.javamex.com/tutorials/memory/object_memory_usage.shtml

8 байтов накладных расходов.

http://stackoverflow.com/questions/7060141/what-determines-java-object-size

И это ещё в лучшем случае!

Кстати, я неправильно посчитал расход памяти для Java для полноценного дерева. В случае Java будет 1 дополнительное слово для Bin и два дополнительных слова для Tip. Это приведёт к дополнительным расходам в 1,5 слова на значение. То есть, 5 слов супротив 3,5 на Хаскеле.

ну, так дело не пойдёт :)

в джаве расход на object header и паддинг полей является implementation specific: IBM JVM на хедер тратит 4 байта, а хотспот 8. В количество памяти на объект также нужно учесть фрагментацию памяти, а это вообще архитектурно-зависимо. В том же хотспоте размер объекта нужно округлить вверх до кратного 8 байтам. При наследовании хотспот поля каждого уровня наследования тоже паддит. Примитивные значения сгруппированы отдельно от указателей. volatile поля выровнены до границы машинного слова. На 64-битных машинах указатели часто 32-битные, зато тратится лишние 2% ЦПУ на конвертацию обратно в 64-битные. Это всё не из-за того, что не могли сделать по-другому в принципе, а потому, что такие design decisions позволяют выиграть какие-то проценты на производительности кэша и GC.

Я думаю, гораздо более интересным сравнением будет глубина применения каких-нибудь unwrap . wrap = id оптимизаций, умение обращаться с мелкими transient объектами. Вот тут Джава может облажаться из-за трудностей escape analysis; до какой-то степени делается, но есть свои но.

Что это всё означает? Это означает, что в лучшем случае вы сможете получить такой же расход по памяти, как и Хаскель.

И да, pragma RULES в Скале невозможна.

гм. я думал, это всё означает, что когда расход памяти такой же, как у Хаскеля, то это ещё не означает, что это лучший вариант даже у Хаскеля.

А ещё, я думал, это всё означает также, что расход памяти на один объект - это не так важно, как важен расход памяти на единицу бизнес логики. Как один простой пример, если уметь выбросить не нужные unwrap . wrap, которые присутствуют в коде, вы избавитесь от объектов. Второй пример - если суметь reuse место от immutable объектов до GC, опять, избавитесь от объектов.

Например, будет ясно, что тупли Скалы будут соответствовать объектам, которые Джава не сможет распаковать и потому не сможет пользоваться чисто unboxed значениями. Вот если в силу особенностей построения программы на Хаскеле компилятор может делать более глубокий анализ таких паттернов и создавать меньше объектов, чем java, это будет гораздо более ощутимой выгодой, потому что оптимизация создания одного лишнего объекта перекрывает оверхеды от разницы в размерах сразу нескольких объектов меджу этими платформами. Тем более, что чем крупнее объект, тем меньше % эта самая разница, верно?

(no subject)

thesz.livejournal.com - 2012-11-08 14:46 (UTC) - Expand

(no subject)

sassa-nf.livejournal.com - 2012-11-08 14:58 (UTC) - Expand

(no subject)

thesz.livejournal.com - 2012-11-08 15:03 (UTC) - Expand

(no subject)

sassa-nf.livejournal.com - 2012-11-08 15:23 (UTC) - Expand

(no subject)

thesz.livejournal.com - 2012-11-08 16:00 (UTC) - Expand

(no subject)

sassa-nf.livejournal.com - 2012-11-08 16:10 (UTC) - Expand

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

да что там макросы, взять для примера обычную скалу как она есть в 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:    }
  }

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

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

Edited 2012-11-07 21:17 (UTC)

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

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

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

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

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

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

Может.

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

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

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

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

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

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

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

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

(no subject)

thesz.livejournal.com - 2012-11-08 11:50 (UTC) - Expand

(no subject)

sassa-nf.livejournal.com - 2012-11-08 12:51 (UTC) - Expand

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

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

Flat | Top-Level Comments Only