Перевод статьи Джастина Этеридж (Justin Etheredge), в которой автор объясняет тонкую разницу между детерминированными и чистыми функциями.

Вчера я читал блог Мэтта Подвизоки (Matt Podwysocki) (этот блог, кстати, потрясающий, идите и подпишитесь), и у него есть пост «Recursing into Recursion – Memoization». Отличный пост, если вы хотите познакомиться с мемоизацией. У меня уже был пост об обобщенной функции мемоизации некоторое время назад, поэтому мы будем говорить не о мемоизации. То, что возбудило во мне интерес, было в конце статьи Мэтта:

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

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

Перевод статьи Джона Скита, известного гуру языка C#, автора книги C# In Depth, сотрудника Google, человека #1 по репутации на stackoverflow.com и наконец героя Jon Skeet Facts. В этой статье Джон доступно объясняет, что представляют из себя карринг и частичное применение функции, концепции, пришедшие из мира функционального программирования. Кроме того, он подробно поясняет в чём их различие. Признаюсь, что я и сам их путал до прочтения этой статьи, поэтому мне показалось полезным сделать перевод.


Это немного странный пост, и прежде чем читать его вам, пожалуй, следует отнести себя к одной из этих групп:

• Те, кто не интересуются функциональным программированием и находят функции высшего порядка запутанными: вы можете пропустить эту статью полностью.
• Те, кто знают всё о функциональном программировании и хорошо понимают разницу между каррингом (currying) и частичным применением функции (partial function application): пожалуйста, внимательно прочтите этот пост и отпишитесь в комментариях, если найдете неточности.
• Те, кто частично знаком с функциональным программированием, и заинтересован узнать больше: отнеситесь к этому посту скептически и внимательно прочтите комментарии. Прочитайте другие статьи более опытных разработчиков для получения дополнительной информации.

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

Перевод статьи Николаса Блумхардта, известного .NET разработчика, автора IoC/DI контейнера Autofac. В этой статье Николас показывает на реальном примере как с наименьшими усилиями написать парсер предметно-ориентированного языка программирования с помощью Sprache, библиотеки парсер-комбинаторов.


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

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

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

Перевод статьи "(How to Write a (Lisp) Interpreter (in Python))" Питера Норвига. В данной статье Питер довольно кратко, но емко описывает принцип работы интерпретаторов и показывает как можно написать совсем крошечный (всего 90 строк на Python) интерпретатор подмножества языка Scheme. Перевод публикуется с разрешения автора.

Питер Норвиг (англ. Peter Norvig) — американский ученый в области вычислительной техники. В данный момент работает директором по исследованиям (ранее — директор по качеству поиска) в корпорации Google. Ранее являлся главой Подразделения вычислительной техники в исследовательском центре Амес NASA, где он руководил штатом из двухсот ученых, занимающихся разработками NASA в областях анатомии и робототехники, автоматизированной разработке ПО и анализа данных, нейроинженерии, разработки коллективных систем, и принятия решений, основанном на симуляции.

Комментатор AnotherMatt удивляется, почему консольные Win32 приложения доставляют сообщения в другой поток. Почему они не посылают их главному потоку?

На самом деле, у меня обратный вопрос. Почему в UNIX сигнал посылается главному потоку? Это делает практически невозможным сделать что-нибудь важное внутри обработчика сигнала. Главный поток может быть внутри менеджера кучи (удерживать критическую секцию) во время приёма сигнала. Если обработчик сигнала попытается получить доступ к куче, то произойдет взаимная блокировка с самим собой, если вам повезёт. В худшем варианте повредится куча.

Время от времени я вижу вариации на этот вопрос. «Почему моя низкоприоритетная нить съедает 100% CPU?»

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

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

UPD: всем спасибо за карму. перенес в специализированный блог.