Функциональное программирование снова в моде. В зависимости от того, предпочитаете ли вы классику или хардкор, страдаете от навязанных промышленных стандартов или вы просто хипстер, вашим любимым предпочтением может быть Scala, Haskell, F# или даже старый добрый Lisp. Такие сочетания слов, как функция высшего порядка, отсутствие побочных эффектов, и даже монады, ласкают слух всех «неокрепших юных умов», будь-то ребят из JetBrains или студента, впервые увидевшего SICP.

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

Так получилось, что тесть и теща у меня доктора педагогических наук. Что приводит к тому, что волей-неволей начинаешь постигать различные полезные методики :)

Однажды, после какого-то ученого совета за виски чаем на кухне тесть говорит: Саш, а вот как ты считаешь, почему люди чего-то не делают?

Честно сказать, вопрос поставил меня в тупик. Я начал фантазировать: ну, обстоятельства мешают, черты характера, недостаток опыта…

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

• Почему менеджеров проектов надо пересаживать в отдельное здание
• Что делать, когда ваш заказчик не пользуется вашей системой отчетов
• Как раскачать low-performer’а

Какое-то время назад я писал о том, что «ссылки» — это не «адреса», когда речь идёт о C# и размещении его объектов в памяти. Хотя это действительно так, но это всего лишь деталь реализации, но не смысл «ссылки». Другая деталь реализации, которую часто путают с сутью — это то, что «память под значимые типы (value types) выделяется на стеке». Я часто это вижу, потому что именно так написано в нашей документации.

Практически каждая статья, которую я вижу, подробно описывает (часто неверно) что такое стек и что основное различие между значимыми и ссылочными типами — это то, что значимые типы располагаются на стеке. Я уверен Вы можете найти множество примеров таких статей в сети.

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

Если коротко, то «потому что могут». И т.к. стек «дёшев» мы располагаем их на стеке, когда только это возможно.

Длинный ответ он … длинный.

В этой статье я даю краткий обзор того, как применять библиотеку lock-free структур данных libcds. В реализацию я углубляться здесь не буду, — это просто взгляд извне, взгляд со стороны пользователя библиотеки.

Библиотека libcds имеет свою точку зрения на многие известные структуры данных. Отчасти это объясняется целевой областью – lock-free структуры данных довольно минималистичны по набору предоставляемых методов, — отчасти желанием выйти за ограничения и решения стандартной библиотеки STL. Что из этого получилось – решать пользователям libcds.

Кому интересно – добро пожаловать под кат

Построение lock-free структур данных зиждется на двух китах – атомарных операциях и способах упорядочения доступа к памяти. В этой статье речь пойдет об атомарности и атомарных примитивах.

Анонс. Спасибо за теплый прием Начал! Вижу, что тема lock-free интересна хабрасообществу, это меня радует. Я планировал построить цикл по академическому принципу, плавно переходя от основ к алгоритмам, попутно иллюстрируя текст кодом из libcds. Но часть читателей требует зрелищ не мешкая показать, как пользоваться библиотекой, особо не рассусоливая. Я согласен, в этом есть свой резон. В конечном счете, и мне не так интересно, что там внутри boost, — опишите, как его применять! Поэтому свой эпический цикл я разделю на три части: Основы, Внутри и Извне. Каждая статья эпопеи будет относится к одной из частей. В Основах будет рассказываться о низкоуровневых вещах, вплоть до строения современных процессоров; это часть для почемучек вроде меня. Внутри будет освещать интересные алгоритмы и подходы в мире lock-free, — это скорее теория о том, как реализовать lock-free структуру данных, libcds будет неисчерпаемым источником C++ кода. В Извне будут статьи о практике применения libcds, — программные решения, советы и FAQ. Извне будет питаться вашими вопросами/замечаниями/предложениями, дорогие хабражители.

А пока я судорожно готовлю начало Извне, — первая часть Основ. Статья во многом не о C++ (хотя и о нем тоже) и даже не о lock-free (хотя без atomic lock-free алгоритмы неработоспособны), а о реализации атомарных примитивов в современных процессорах и о базовых проблемах, возникающих при использовании таких примитивов.
Атомарность — это первый круг ада низкий уровень из двух.

Как вы, наверное, догадались, эта статья посвящена lock-free очередям.

Очереди бывают разные. Они могут различаться по числу писателей (producer) и читателей (consumer) – single/multi producer — single/multi consumer, 4 варианта, — они могут быть ограниченными (bounded, на основе предраспределенного буфера) и неограниченными, на основе списка (unbounded), с поддержкой приоритетов или без, lock-free, wait-free или lock-based, со строгим соблюдением FIFO (fair) и не очень (unfair) и т.д. Подробно типы очередей описаны в этой и этой статьях Дмитрия Вьюкова. Чем более специализированы требования к очереди, тем, как правило, более эффективным оказывается её алгоритм. В данной статье я рассмотрю самый общий вариант очередей — multi-producer/multi-consumer unbounded concurrent queue без поддержки приоритетов.

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

struct deferred;
struct deadline;
struct disable;

template<class T, class Deferred = disable, class Deadline = disable>
struct some_container

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

typedef some_container<int, disable, deadline> deadline_container;
<source>
А хотелось бы 

<source lang=cpp>
typedef some_container<int, deadline> deadline_container;

А ещё лучше, что бы даже порядок задания не имел значение и следующие два, были бы эквивалентны

typedef some_container<int, deferred, deadline> full_container1;
typedef some_container<int, deadline, deferred> full_container1;

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

Несколько дней назад мной была написана статья о реализации автоматического обновления программного обеспечения на языке C#.

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

• Автоматическая проверка, скачивание и установка обновлений;
• Предоставление пользователю возможности выбора момента обновления (новое);
• Улучшен механизм проверки версии файла;
• Проверка целостности файла обновления (новое)

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

Несколько лет назад, программируя еще на Delphi, лично для себя соорудил некий код автоматического обновления, который в последствии стал незаменимым при разработке любой программы, где есть обновление. В настоящий момент этот код полностью переписан на c# и я хочу с Вами им поделиться.

Вначале определим цели этой реализации:

1. При обнаружении новой версии обновление должно происходить автоматически;
2. После обновления программа должна автоматически перезапускаться;
3. После обновления имя программы должно остаться прежним.

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

Программируя на Си многие сталкивались с такими функциями как memcpy() и memmove(), по сути, функции делают одно и тоже, но вторая корректно отрабатывает ситуацию, когда области памяти перекрываются (на что появляются дополнительные накладные расходы).

В мире С++ никто не запрещает пользоваться этими функциями (часто эти функции используют различные механизмы оптимизации и могут статься быстрее своих собратьев из мира C++), но есть и более родное средство, работающее через итераторы: std::copy. Это средство применимо не только к POD типам, а к любым сущностям, поддерживающим итераторы. О деталях реализации в стандарте ничего не сказано, но можно предположить, что разработчики библиотеки не настолько глупы, что бы не использовать, оптимизированные memcpy()/memmove() когда это возможно.

Видео про 8 способов противостояния формуле нужды оказалось неожиданно популярным, набрав 8,000 просмотров за два дня. Мы решили продолжить тему.

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

Мы отобрали 10 самых любопытных, на наш взгляд, вопросов в этой теме и снова заперли в студии Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП и нашего хорошего друга, чтобы он рассказал, что конкретно делать:



10 реальных ситуаций, которые удалось осветить — под катом:

Hикто не хочет конфликтовать. Когда конфликты становятся частыми, человек мучительно ищет выход. Кто-то пытается избежать общения, кто-то идет на прямой конфликт, кто-то ищет приемы и методы как правильно вести себя. Последним и посвящен данный пост, идея появления которого родилась после просмотра видео следующего топика «Как поставить человека на место: 10 реальных вопросов про давление в переговорах». Советы интересные и без сомнения при умелом использовании действенные, но есть еще один занятный метод ухода от конфликта под названием «психологическое айкидо», разработанный Литваком Михаилом Ефимовичем (психолог, психотерапевт, кандидат медицинских наук). Когда-то этот прием неплохо помог мне в общении с одним очень темпераментным начальником. Но все по порядку.

Раз уже тема переговоров с заказчиками и коллегами оказалась интересна хабровчанам (48,000 просмотров видео за неделю), мы решили продолжить эту тему.

Предыдущие материалы:

• Управленческие инструменты: Формула нужды или Каким образом нас отжимают?
• [видео] 8 способов противостояния формуле нужды
• [видео] Как поставить человека на место: 10 реальных вопросов про давление в переговорах
• Как стать переговорщиком — интервью с Дмитрием Коткиным

На этот раз мы попросили Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП разобрать ситуации более подробно. Правда, и ситуации не такие простые. Более конкретные, про проектную работу в ИТ, с непростыми заказчиками и коллегами.

Надеемся, что это окажется вам полезным. Видео-разборы 7 реальных ситуация — под катом:

• “На свободу — с готовой отчетностью!”
• “4 часа, чтобы сделать клиенту чушь”
• “Миссия невыполнима (с данным оборудованием)”
• “Начинайте работы, через 14 часов открытие магазина”
• “Наш бюджет в 3 раза меньше”
• “Незапланированный откат”
• “Если у вас в руках молоток, то все вокруг кажется гвоздем”

Сегодня столкнулся с прекращением работы антивируса Microsoft Security Essentials на Windows XP. Как известно, 8 апреля 2014 года закончилась поддержка Windows XP, поэтому в Microsoft решили отключить и антивирус для этой системы. Сообщения о том, что MSE будет работать ещё год для этой системы, не оправдались — доступная в виде дистрибутива версия 4.4.304.0 работает, однако новая версия 4.5.216.0, которая автоматически устанавливается с обновлениями безопасности, выключает антивирус и предупреждает пользователя о том, что ОС устарела и от неё пора бы избавиться. Но слишком много людей пользуются этой системой и этим удобным антивирусом, поэтому я нашёл решение, которое позволяет антивирусу работать дальше.

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

Первая часть дала нам теоретическое представление о том, что есть лямбда-исчисление. В этой статье мы последуем неофициальной його-заповеди «Practice-practice-practice» и увидим его в действии.

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

UPD: в текст внесены некоторые изменения с целью сделать его более понятным. Смысловая составляющая осталась прежней.

Вступление

Возможно, у этой системы найдутся приложения не только
в роли логического исчисления. (Алонзо Чёрч, 1932)

Вообще говоря, лямбда-исчисление не относится к предметам, которые «должен знать каждый уважающий себя программист». Это такая теоретическая штука, изучение которой необходимо, когда вы собираетесь заняться исследованием систем типов или хотите создать свой функциональный язык программирования. Тем не менее, если у вас есть желание разобраться в том, что лежит в основе Haskell, ML и им подобных, «сдвинуть точку сборки» на написание кода или просто расширить свой кругозор, то прошу под кат.

Статья не о том, чем заняться, пока собирается проект.

Фраза «Шаблоны — полноценный, тьюринг-полный, язык» часто воспринимается с недоверием. Это же просто обобщающая возможность современных языков программирования, откуда там вычислительные возможности? Так думал и я. Теперь хочу переубедить остальных, попутно объясняя принципы работы шаблонов для начинающих, вроде меня.

Мое понимание шаблонов впервые пошатнулось после прочтения главы «Метапрограммирование» из книги о С++ от создателя С++ — показалось, что они действительно могут быть полноценным языком программирования внутри языка программирования. Во всяком случае, там точно есть рекурсия. Но лучший способ доказать себе что-то — попытаться сделать, что мы и сделаем.

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

На Хабре недавно проскочила ещё одна статья про вычисления на шаблонах C++ от HurrTheDurr. В комментариях к ней лично я увидел вызов:

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

А так ли сложно будет написать универсальный вычислитель на типах, более удобный для программирования, чем клеточный автомат? Как оказалось, несложно; я в 30 раз больше времени потратил на эту статью, чем на написание и отладку собственно кода вычислителя.

Чуть раньше AveNat опубликовала введение в лямбда-исчисление в двух частях, так что вдохновение пришло мгновенно. Хотелось, чтобы можно было (образно) писать так:

#include <iostream>

#include <LC/kernel.h>
#include <LC/church_numerals.h>

int main()
{
    // Представление натуральных чисел в виде лямбда-абстракций
    typedef ChurchEncode<2> Two;    // 2 = λfx.f (f x)
    typedef ChurchEncode<3> Three;  // 3 = λfx.f (f (f x))

    // * = λab.λf.a (b f)
    typedef Lambda<'a', Lambda<'b', Lambda<'f',
                Apply<Var<'a'>, Apply<Var<'b'>, Var<'f'> > >
        > > > Multiply;

    // Вычисление (* 2 3)
    typedef Eval<Apply<Apply<Multiply, Two>, Three>> Output;

    // Переход обратно от лямбда-абстракций к натуральным числам
    typedef ChurchDecode<Output> Result;

    std::cout << Result::value;
}

А на выходе получать такое:

ilammy@ferocity ~ $ gcc cpp.cpp
ilammy@ferocity ~ $ ./a.out
6

Статья получилась несколько великоватой, так как мне хотелось рассказать обо всех интересных штуках, которые здесь используются. И ещё она требует базового набора знаний о лямбда-исчислении. Приведённых выше обзоров, среднего знания C++ (с шаблонами), и здравого смысла должно быть достаточно для понимания содержимого.

Под катом находится очередное прокомментированное конструктивное доказательство Тьюринг-полноты шаблонов C++ в виде compile-time интерпретатора бестипового лямбда-исчисления (плюс печеньки в виде макросов и рекурсии).

В контексте последних законов, событий и тенденций как никогда очевидна ценность рутрекера как базы данных различного контента, а не как конкретного ресурса. К сожалению все мои призывы к администрации рутрекера предоставить общедоступный, полный, удобный дамп их базы наткнулся на полное непонимание с их стороны. Выкладывать нечто, что они называют зашифрованной «базой» — я не считаю решением проблемы по причинам, изложенным в вышеприведенных ветках обсуждения и продублированным ниже.

К сожалению, решить проблему своими силами у меня не хватило ни времени, ни, будем откровенны, знаний. Но, к счастью, мои слова возымели действие на людей, которые и тем и другим обладают. В итоге эти люди организовались и сообща сделали то, о чём так долго говорили большевики о чем я писал, а именно с помощью скриптов обошли рутрекер, сдампили все описания раздач с хешами, распарсили их и скомпоновали в удобную для употребления базу. В дополнение к этому так же была написана «морда»: программа для удобной работы с базой конечных пользователей, не знающих с какого конца держат grep. К сожалению, аккаунта на хабре никто из этой команды не имеет (если не считать read-only), в песочнице статья могла бы потеряться, поэтому меня выбрали как рупор для данной площадки. Я, честно говоря, раздумывал совсем недолго и только над тем, как правильнее все сделать. Если будут какие-то вопросы — задавайте мне в комментах, я либо отвечу сам, либо переадресую разработчикам. Технические тексты от первого лица, но я имею к ним косвенное отношение, они оставлены в таком виде для простоты восприятия.

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