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

Совсем недавно, в 2002 году, бравый американец Стив Декорте понял, что ему как-то все вокруг не нравится. Ну то есть нравится, но как-то по частям. Нравится Smalltalk своей Ъ-ООП природой, нравится Lisp своей системой метапрограммирования и общей мегаизвратностью, нравится Self своими прототипами, нравится Lua, потому что маленькая и клево встраивается куда угодно. А вот что бы все и сразу — что-то не то. Погоревал бравый американец, да и наколбасил свой собственный язык программирования — Io.

Io

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

Ну что, поехали.

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

Хочу начать вести блог, посвященный метапрограммированию на Ruby.

На этот раз буду рассказывать не только про метапрограммирование, но и про Ruby, а также про алгоритмы — сегодня вспомним классику и посмотрим, как она нам явится в Ruby-строках реализации метода qsort. Блог только начинается, про настоящее метапрограммирование пока говорить рано, поэтому позволю себе отступления от основной темы.

В предыдущем посте мы затронули важнейшую концепцию — замыкание (closure).
Суть этой концепции в том, что в любой блок как бы заключается «весь окружающий мир» так, как он виден в контексте, где блок создается. Правильнее сказать, что в блок заключается не весь окружающий мир (пространство имён), а фиксируется точка зрения на окружающий мир (пространство имён).

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

Иногда возникает необходимость, запроксировать (обернуть) методы класса в свой код.

Например:

• запустить их в тредах
• навесить фильтры до и после
• померить производительность

DSL-и (domain specific languages или языки для специфичных областей) известны программистам давно. Несмотря на это, они редко используются в реальных системах. В этой статье будет рассмотрено, что такое DSL-и, и почему они не получили широкого распространения. Также будет описано, как система JetBrains MPS решает проблемы, препятствующие их широкому использованию.

Вчера на хабре я опубликовал свою статью про языко-ориентированное программирование, в которой описал, какие проблемы существуют в этой области, и как их решает систем JetBrains MPS. Сегодня я хочу показать реальные примеры того, как выглядит код в MPS, с небольшими комментариями. Мы посмотрим на язык для работы с базами данных, на язык для создания веб интерфейса, на наш javascript. Фрагменты кода взяты из приложения баг-трекера с кодовым именем Charisma, написанного на MPS.

Хочется начать посты про программирование Magic: the Gathering (M:tG), и начнем мы пожалу с самого простого – с концепции «маны». Мана – это то, чем оплачиваются все заклинания. Несмотря на то, что с виду маны всего 5 типов, на самом деле все чуть-чуть сложнее. Давайте попробуем разобраться.

Интересная вещь. Некоторые вещи лежат на виду, но почему-то их не замечаешь. Вот и сейчас. Много раз заходил на сайт jetbrains.com, но не замечал такую интересную вещь как MPS (Meta Programming System). Данная система поддерживает новый подход в программирование, так называемая ориентация на язык (Language Oriented Programming). Говоря более изящно (дословный перевод не подходит) – это мета ориентированный подход программирования. Идея данного подхода в том, чтобы расширяя существующий язык программирования создать свой собственный, заточенный под свои бизнес правила. Не знаю насколько это удобно, но данная тема точно заслуживает того чтобы обратить на нее внимание. MPS был создан Jetbrains в 2003 год, как исследовательский проект. С 2006 года компания использовала данный проект в разработке новых продуктов. MPS является бесплатным продуктом выпускаемым под лицензией Apache 2.0 license.

Краткое содержание статьи (для тех кто знаком с boost::mpl), typename опущены для ясности:

a = b;				==>		typedef b a;
f(x)				==>		f<x>::type
f(x) { return x*; }		==>		template<typename x> struct x { typedef x* type; };
f()(x)				==>		f::apply<x>::type
a[x]				==>		mpl::at<a, x>::type
(x ? y : z)			==>		mpl::if_<x, y, z>::type
switch (if_<x, y, z>)		==>		*Уфф*, общая (default) и частичные специализации
{
	case if_<bool_<false>, y, z>: return y;
	default: return z;
}

Под хабракатом есть немного пояснений :)

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

Это часть фреймворка, который я сделал для своей платформы Akshell, вот полный код решения и документация. Однако оно может пригодиться в любой Server-Side JavaScript среде, на стороне сервера удобное создание иерархий классов особенно актуально. Его можно использовать и на клиенте, если заменить работу со свойством __proto__ оператором new.

Кто изучает Ruby, знает, что в нем все сущности — объекты, но порой не догадывается насколько. Так вот, классы в Ruby это тоже объекты.

Как известно, в C++ нельзя производить сложные вычисления с плавающей точкой на стадии компиляции. Я решил попробовать избавиться от этого досадного недостатка. Цель, к которой мы будем идти, на примере вычисления корня:

typedef RATIONAL(2,0) x;
typedef sqrt<x>::type result;

Корень числа вычислится на этапе компиляции. Представление числа хранится как отношение двух целых чисел, поэтому чтобы получить значение, нужно обращаться через метод get();

std::cout << result::get() << std::endl;

1.41421356

О грустном

Сидел я вчера на очередном интервью, грустил, что javax в меня какашками кидается, и слушал печальную историю соискателя о том, как он мучался пытаясь прикрутить сериализацию в JSON к модели на Java не имея ее исходников. От вида его попыток настроение мое не улучшилось.
Мы попробуем лучше, потому что, в отличие от него, мы знаем про Groovy.
Этот пост является более-менее продолжением вчерашнего. Им хотелось бы убить мешок зайцев:

1. Показать реальный пример мета-программирования на Groovy
2. Показать немного более навороченный способ работы с мета-классами
3. Показать работу с json-lib в Groovy
4. Рассказать про dependency management для бедных

Подкаст

http://ruby.rpod.ru/282270.html

Новости

• Стриминг в новой рельсе
• mortal-token
• travis-api
• Ransak
• Metaprogramming in Ruby
• BinUtils from funny-falcon
• bit.ly on Ruby
• Yet another JSON parser and discussion on reddit
• SublimeText package for generating Yardoc
• Narihiro Nakamura: Ruby’s GC Innovator
• Unexpected Ruby Behaviour
• Ruboto 0.8.0

Иногда мы делаем вещи, ценность которых является весьма сомнительной. Это как раз тот самый случай.

Код лучше тысячи слов

Не буду тянуть кота за хвост, а перейду сразу к делу. Обычно мы используем CRTP примерно так:

template<typename type, typename tag>
struct Base
{};
 
template<typename type, typename tag>
void f(const Base<type, tag>&)
{}
 
struct Foo : Base<Foo, void>
{};
 
int main()
{
  Foo foo;
  f(foo); 
}

Функции f() на самом деле всё равно, какой тэг у её аргумента, и она принимает объект любого типа, унаследованого от Base. Но не будет ли более удобным, если мы просто опустим не интересующий нас тэг? Зацените:

template<typename t>
struct base_tag { typedef decltype(get_tag((t*)42)) type; };
 
template<typename type,
         typename tag = typename base_tag<type>::type>
struct Base
{
  friend tag get_tag(type*);  //never defined
};
 
template<typename type>
void f(const Base<type>&)
{}
 
struct Foo : Base<Foo, void>
{};
 
int main()
{
  Foo foo;
  f(foo);
}

Инфраструктура .Net содержит встроенные средства генерирования кода (On-the-Fly Code Generation). Это позволяет .Net-программе в момент своего исполнения самостоятельно (без участия программиста) скомпилировать текст, написанный на каком-либо языке программирования и исполнить получившийся код. Логично было бы ожидать, что для осуществления этих действий в стандартной .Net-библиотеке предусмотрен простейший метод соответствующего класса. Но к сожалению это не так. Microsoft, проделав огромный путь по встраиванию в среду .Net средств генерирования кода, не сделала самый последний шаг навстречу простейшим потребностям программистов. Значит, придётся сделать этот шаг самостоятельно.

Самое простое средство предлагаемое Microsoft для решения описанной задачи — это класс CSharpCodeProvider, который входит в стандартную библиотеку .Net. Использование этого класса — не очень сложная задача, но тем не менее было бы полезно иметь инструмент, превращающий использование сгенерированного на лету кода в задачу тривиальную.

Захотелось, наконец-то(!), попробовать variadic templates, так как до сих пор привязан к 10й студии, где ничего этого нету. А чтобы долго не думать, где же можно бесполезно использовать variadic templates, пришла идея попробовать, как будет выглядеть Typelist. Для тех, кто ещё не знает, что это такое, я постараюсь объяснять по ходу дела, а тем, кому это скучно — может сразу пролистать вниз — попробуем написать подобие крестиков-ноликов с использованием Typelist.
Итак, TypeList:

Предлагаю вашему вниманию перевод фрагмента книги Metaprogramming Ruby 2 за авторством Паоло Перротта (Paolo Perrotta).

Что такое method_missing?

В Руби мы можем вызывать методы которые не существуют, но это будет возвращать нам ошибку. Для примера:

class Lawyer; end
nick = Lawyer.new
nick.talk_simple

NoMethodError: undefined method 'talk_simple' for #<Lawyer:0x007f801aa81938>

Помните ли вы как работает поиск методов? Когда вы вызываете метод talk_simple, Ruby идет в класс объекта nick, и перебирает там методы. Если он не может найти метод там, он ищет его в родителей данного класса, потом в Object и наконец в BasicObject. Ну и поскольку Ruby не может нигде найти метод talk_simple, он запускает метод method_missing для nick’a. Ruby знает что этот метод есть, потому, что это приватный метод BasicObject от которого наследуются все объекты.