Category: литература

Category was added automatically. Read all entries about "литература".

glider

scala.meta: новая платформа для метапрограммирования Скалы

scala.reflect - наш публичный API, появившийся в Скале версии 2.10 - оказался весьма полезным на практике. Благодаря макросам, основанным на новом API, стало возможным реализовать такие библиотеки как async (DSL для упрощения работы с асинхронностью), pickling (статически генерируемые сериализаторы с отличным перфомансом), scala-blitz (ускорялка стандартных коллекций), а также улучшить ряд уже существующих решений в scalatest, Play!, parboiled и других популярных библиотеках.

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

Основываясь на нашем опыте с scala.reflect и на отзывах пользователей макросов, мы спроектировали scala.meta - новую платформу для метапрограммирования Скалы, главной целью которой является легкость в использовании и портабельность относительно существующих (Scala 2, Intellij) и планирующихся (Scala 3) реализаций языка. Первый technology preview релиз scala.meta намечен на эту осень, а пока что предлагаю посмотреть видео нашей презентации с ScalaDays и обсудить дальнейшие планы в каментах.

Слайды: Easy Metaprogramming For Everyone!
Видео: Запись презентации на parleys.com
glider

Темы для курсовых и дипломов на основе макросов в Скале

Мы уже совсем близко к финальному релизу Скалы 2.10, который вместе с другими интересными фичами будет включать в себя и макросы: http://scalamacros.org.

На текущий момент макросы весьма стабильны, ими пользуется все больше и больше народа, поэтому настал отличный момент для того, чтобы на основе макросов написать курсовую работу, диплом или даже магистерский проект. Дипломная или магистерская работа на тему популярного языка программирования, да еще и с подписью Мартина Одерского. Звучит интересно, правда?

***

Подробно предлагаемые темы описаны на сайте проекта: http://scalamacros.org/news/2012/11/05/research-projects.html, а в этом посте я вкратце прорезюмирую некоторые из них. Итак вот список:
* Optimizing collections with macros
* Using reified types for specialization
* Macro-based class system
* Macro-based continuations
* Multi-stage programming with macros
* Interpreter for abstract syntax trees

Первая тема отлично подойдет для тех, кто хочет познакомиться с идеей макросов и заодно оставить видимый след в стандартной библиотеке Скалы. Высокоуровневые методы коллекций вроде map или filter очень удобны, но компилируются в не самый быстрый код. Последние несколько лет мы с переменным успехом пытались решить эту проблему, но с помощью макросов этот вопрос можно закрыть раз и навсгеда.

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

Следующий проект (multi-stage programming with macros) использует возможности макросов для создания доменно-специфических языков. У нас в лаборатории есть интересное направление, связанное с созданием параллельных и не очень DSL с помощью LMS. Я восхищен этой технологией: контролем, который она предоставляет разработчику языков, и прозрачностью для пользователей. Но у текущей реализации есть один недостаток - количество языковой магии под капотом зашкаливает, на что часто жалуются разработчики. С помощью макросов этот недостаток можно полностью устранить.

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

***

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

Также хочу отметить, что формат сотрудничества не обязательно должен быть академическим. В основном наша лаборатория работает со студентами (магистрантами, аспирантами), это да. Но у нас есть и примеры плодотворного сотрудничества с разработчиками, для которых Скала это просто хобби.

Наконец хочу пожелать не пугаться слов "разработка новых фич для Скалы" и "сотрудничество с EPFL". С нами весело и интересно :)
glider

макросы: обзор литературы

Зачел сегодня две фундаментальные работы по макросам в Немерле: "Syntax-Extending and Type-Reflecting Macros in an Object-Oriented Language" (далее "диссер") и "Язык Немерле, часть 5" (далее "статья"), а также за эти несколько дней поговорил с Владом Чистяковым (спасибо большое, Влад, за желание помочь и детальные объяснения!). Несколько промежуточных выводов:

1) Квазицитирование крайне изящно. Всего три прозрачные языковые конструкции (цитирование, антицитирование и сплайсинг, см. раздел 8.3 диссера, если покороче, или раздел "Квази-цитирование" статьи, если развернуто) раз эдак в сто упрощают парсинг и генерацию AST. Особенно впечатлило использование антицитат и сплайсов в паттерн-матчинге. Внутренняя красота квазицитирования особенно остро воспринимается после мучений с композируемостью линка.

2) Впрочем одна знакомая до боли проблема остается. Как лифтить (т.е. преобразовывать в AST) код из внешнего мира? Адептам стейджинга в этом плане просто (кстати, рекомендую презентацию по ссылке, первая работа Олега, которую я понял) - все функции и значения, имеющие стейджнутый тип, они лифтят (явным образом в стиле tagful или неявно через tagless - что это значит см. линк или спрашивайте у меня), а остальное игнорируют. Достигается это ценой синтаксического оверхеда на типизацию + возможными издержками на tagful представление кода (см. сюда за подробностями), но зато ведь достигается. А с макросами сложнее - в большинстве случаев без явного антицитирования они даже не пошевелятся что-то залифтить, да и, самое главное, код, скомпилированный без лифтинга, (например, внешние библиотеки) уже никогда не сможет быть залифченным. Также появляется неочевидная дилемма на тему того, разрешать ли макросам видеть значения в лексическом скоупе (см. раздел 2.3.3 диссера).

3) Также совершенно непонятно как сделать ортогональной кодогенерацию на макросах в статически типизированном ОО-языке. Во-первых, скорее всего придется выносить макросы в отдельный юнит компиляции. Во-вторых, появляется дилемма: юзать макросы до типизации и иметь возможность нагенерировать новые типы, или юзать типизированные AST, но мириться с залоченным пространством типов (лучше даже не думать, что будет, если сюда добавить тайп-инференс). В-третьих, объектность подливает масла в огонь в плане того, что появляются классы (концептуально новая сущность, которая не композируется с функциями) и наследование. В итоге получается кошмар стейтфул программирования, когда в зависимости от фазы луны операции над данными то разрешены, то запрещены. Неудивительно, что создатели F# попросту скипнули кодогенерацию, а реализовали только read-only квазицитаты.

4) В плане сообщений об ошибках и отладки сгенерированного во время раскрытия макросов кода все не так плохо, как может показаться на первый взгляд. Вместе с генерацией кода мы можем сгенерировать для него исходник (AST-то у нас есть), к которому привяжем дебажную информацию. Само собой, повреждаются оригинальные номера строк (их-то мы сможем восстановить линзами, вот только пошаговый дебаг будет прыгать туда-сюда как ненормальный) и получается фигня с стек-трейсами, но это уже хоть что-то. У сторонников стейджинга все гораздо хуже (см., например, страничку 15 слайдов про LMS).

5) Кроме того для языка с синтаксисом макросам желательно иметь контроль над парсером (см. слинкованные креативы про Немерле, а также технический репорт "Genuine, Full-power, Hygienic Macro System for a Language with Syntax"). В таком случае можно реализовывать полезные вещи вроде добавления своих атрибутов к декларациям (типа async method или method precondition) или введения кастомного синтаксиса. upd. Вообще-то, без этого можно жить: первое решается при помощи аннотаций, которые будут запускать соответствующий макрос, некоторое подмножество второй фичи уже есть в скале (например, см. каноничную реализацию цикла while).

В целом, на текущий момент концепция макросов в мейнстримных языках программирования мне представляется причудливой смесью из бабочек, единорогов, пауков и червей. На очереди Template Haskell.
glider

Про перл

С перлом меня познакомил Стив Йегги.
Потом я сел почитать книжку Learning Perl, но быстро заскучал и забил разбираться.

Спустя год после знакомства с юниксом я снова начал эксперименты.
Немного освоив bash, решил продвигаться дальше и стал разбираться с юниксовым тулчейном.
Нашел клевую штучку про awk: Idiomatic Awk, параллельно немного научился пинать sed.
Дальше - больше: Awk One-Liners Explained, Sed One-Liners Explained.
С авком еще туда-сюда, но текст про сед я не осилил и до половины.

Посмотрел на питон, почитал секретные техники шелл-скриптинга.
К счастью, вспомнил про перл.
Оказывается, он умеет эмулировать сед и авк: http://perldoc.perl.org/perlrun.html.

Зашел на stackoverflow поискать книжки по перлу.
Смотрю, все говорят про какой-то camel book.
Открываю Learning Perl, которую читал год назад - вроде бы на обложке какой-то верблюд.
Думаю: ну что они в этой книге нашли, скукотища ведь.
Присмотрелся - а там на самом деле лама.
Вот блин, оказывается тогда я читал неправильную книжку.
Правильная книжка называется Programming Perl.

Чо, сел читать правильную литературу.
Вначале был срыв мозга: http://stackoverflow.com/questions/6698041/how-do-parentheses-work-in-perl-5.
Потом перл мне показался весьма милым: http://pastie.org/2243606.
Потом снова срыв мозга: http://perldoc.perl.org/perlref.html.
А потом мне вштырило: http://perldoc.perl.org/perlobj.html.

Перл все-таки прикольный. "0+" - отличное название для оператора каста к числу.
И книжка Programming Perl очень хорошая. Если бы не она, навряд ли бы меня так затянуло.
glider

ищу книжку про юникс/линукс

Уважаемые читатели, посоветуйте, пожалуйста, хорошую книжку про юникс, где было бы рассказано про фундамент для тех, кто уже имеет кое-какой hands-on опыт + экспириенс вообще в программировании.

В идеале из такой книги я бы хотел получить обзорные знания о возможностях, которые есть в юниксе, и о идиоматических способах использования этих возможностей. Например, чтобы не совершать глупостей вроде той, на которую указал уважаемый legolegs: Не пристало доброму мужу... копировать файлы с линукса на линукс по SMB.

Пока что практически все, что я нагуглил, делится на две категории: 1) чисто прикладные произведения, где исчерпывающе рассказывается, к примеру, про кучу команд и их ключи, 2) хардкор о программировании кернела. Первое читать скучновато и в голове мало чего остается. Второе совсем непонятно.

Большой удачей мне было наткнуться на книжку The UNIX-HATERS Handbook. Там много негатива, но прочитал я ее залпом. Исторические экскурсы, тривия - все это было увлекательно на уровне хорошего триллера и очень полезно. Если бы найти что-то похожее, но посовременнее (хейтерсам уже 17 лет) и на позитиве - было бы просто супер!

upd. Также очень понравилась статья Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems. Рассматривая проблемы с разрешенными символами в именах файлов, автор попутно затрагивает очень много конвенций и идиосинкразий юниксовой экосистемы. Маст рид.

upd. Весьма просветила статейка Мигеля де Икасы Learning Unix. Благодаря ней я, наконец, понял, что тотал коммандер не нужен. Подробности в посте про файловые менеджеры.
glider

Интересное за полгода

Всем привет! Последний раз мы виделись за обсуждением прогресса по Конфлаксу, а это весьма давно. Пришло время рассказать о самых интересных штуках, произошедших со мной за последнее время. Кое-какие вещи я писал в стол и сейчас их запостил в режиме "Date out of order" (кому интересно - пролистайте бложек вниз), а об остальном коротко расскажу прямо здесь.

Все эти месяцы прошли в режиме усиленного поиска смысла жизни. Так получилось, что Конфлакс слишком долго был в роли не более, чем перспективной идеи, и это неслабо подкосило мотивацию. В итоге, за прошедшее время я больше читал, наблюдал и думал, чем писал потсы и код. Хорошей поддержкой мне стал блог Олега (zamotivator) - я на себе прочувствовал эффективность выхода из творческого кризиса посредством умеренной социализации, поэтому было очень интересно читать о похожем опыте. На обострившееся желание чувствовать происходящее вокруг очень здорово легли восточно-азиатские сериалы. Вещи вроде Orange Days поражают человечностью, социальностью и глубиной раскрытия основополагающих тем вроде семьи, работы, дружбы и любви. Ессно, у японских и корейских сериалов есть свои слабые места, но, в целом, эти креативы стали для меня откровением после голливудских сериалов вроде Хауса.

Очень понравилось читать художественную литературу. Как я недавно упоминал в каментах, киндл не оправдал возложенного на него доверия (не помещается в руку, фиг достанешь в транспорте, нет подсветки, нет дропбокса), и вместо него я для чтения юзаю телефон (на удивление, 3.7" lcd экран не напрягает глаза даже при длительном чтении). Впрочем, я отвлекся как в том анекдоте про "какой у тебя компьютер". Наибольшее впечатление на меня произвела "Анна Каренина", а также последующее прочтение рецензии Натальи Воронцовой-Юрьевой (внимание! там очень много букав). Могу сказать, что чтение и обдумывание сабжевой книжки позволили мне свести воедино многие разрозненные куски знаний и опыта касательно отношений и семьи. С небольшим отрывом второе место занял "Шантарам". Не знаю, насколько эта книга биографична, но описанный взгляд на жизнь - это что-то новенькое. Особенно запомнилась сцена первой посадки главного героя в переполненный поезд в Бомбее вместе с последующей поездкой в этом поезде. Также хотел бы еще упомянуть Довлатова - когда было хреново, для меня было лучшим лекарством сидеть и читать его часами.

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

Также, я проникся идеей курсов - регулярного и детерминированного выделения небольших кусочков времени под какое-то полезное дело (например, по 2 часа пн/ср/пт). Родилась эта идея в результате посещения месячного курса подготовки к TOEFL (если кому интересно, я отпостился о впечатлениях сдачи тоефла и могу в каментах рассказать о том, как готовился - в целом, все просто и без шизы, но нужна системная подготовка). Смысл очень простой - даже если все неделя-две скатываются в полный трэш вследствие депрессняка, все равно в сухом остатке будет что-то полезное, ибо за 2 часа не успеваешь устать + маленькие кусочки новой инфы хорошо загружают подсознание. Сейчас разбираюсь с лямбда-исчислением по лекциям Дениса Москвина (deni_ok) - прогнал всего лишь четыре лекции, но узнал много концептуально нового + теперь неслабо тянет программировать на Хаскелле =)

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

Параллелизм мозга

Из литературы или из ad-hoc опыта широко известен факт о том, что human task switches are considered harmful. В моем понимании он является следствием двух вещей: 1) сознание не способно сконцентрироваться на более, чем одной задаче одновременно, 2) переключение сознания между задачами до уровня хорошей эффективности занимает значительное время - у меня на это уходит полчаса или даже больше.

Но опять же из опыта следует то, что если долгое время (неделя и больше) углубленно заниматься одной и той же таской, но суммарный результат получится хуже, чем если то же время разбить на достаточно большие части и посвящать каждую из частей разным таскам. Например, писать основной проект + читать книжки + следить за новостями почти наверняка будет большим продвижением на пути к Мировому Разуму, нежели просто все время сидеть и лабать проект.

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

***

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

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

2. Зачастую текущий таск настолько сильно захватывает, что переключать его очень не хочется. Например, мне тупо нравится программирование как возможность заставить комп делать то, что ты хочешь, и потом наслаждаться созерцанием результатов - поэтому я могу часами заниматься хакингом here and there. Та же фигня и с книжками - сидишь, читаешь и совсем не можешь оторваться.

3. Нежелание что-то делать из-за блокера. Время от времени так случается, что никаких активных тасков нет, но делать все равно ничего не хочется. Дело может быть в банальной усталости (пункт 1) или в том, что переключение на какую-то таску ассоциируется с серьезным психологическим барьером. "То, что надо, не делаю потому, что очень сильно не хочется, а то, что хочется, не делаю потому, что надо делать, то, что надо" - это как раз про такую ситуацию.

***

С трудностями я собираюсь справляться следующим образом - пока что я пробовал только мелкую гранулярность таймфреймов, отводимых на таски, т.е. пытался делить день на 2-3 части. Но, как я помню себя раньше (т.е. до того, как я начал сознательно управлять своими тасками), естественным образом у меня получается работать, разделив неделю на отдельные дни - так собственно и сделаю: 1 день = (в идеале) 1 таска.

С таким подходом проблема из пункта 1 решается следующим образом: в результате сна контекст предыдущей таски полностью очищается, и, к тому же, утром мозг обычно работает совсе неплохо, т.е. его легко переключить на новый таск + пока я еду на работу можно морально подготовиться к переключению. С пунктом 2 также не возникает вопросов, ибо творческий угар естественным образом сбрасывается во время сна, поэтому он не будет мешать переключению тасков.

Наконец, для пункта 3 требуется особый подход - здесь все очень субъективно и зависит от конкретного блокера. Например, омерзение к конкретной задаче по программированию, можно побороть уклонением от нее, а кое-где просто надо включить силу воли. Еще в эту степь мне очень нравится trickle list, идея которого заключается в том, что выделяется список малюсеньких тасков, которые настолько маленькие и простые, что их никогда не будет проблематично сделать. Например - поболтать с народом вокруг, чтобы собрать слухи и интересные факты, сожрать витаминку или на один маленький шажок улучшить дизайн своего сайта.

***

Следующий шаг - подогнать делимую единицу времени к циклу биоритмов, но тут фиг знает, с какой стороны подступиться - надо просто пробовать и все. Читать и писать о таких вещах все равно, что читать/писать о том, как научиться ездить на велосипеде - вроде бы и полезно, но, пока самостоятельно не прочувствуешь, все равно никакого толку не будет.

Дополнительные проблемы - 1) как в список интересных тасков включить бытовуху, а также возможные неприятные вещи типо необходимости общения с кастомером на работе, 2) как оценивать свой прогресс, 3) как анализировать и корректировать общее направление движения. Но об этом я подумаю уже потом - всего понемножку.