Практика функционального программирования

Отдельная куча с отдельными указателями(std::gc_ptr какой-нибудь) и возможностью нагадить руками(сейчас же это не мешает shared_ptr'ам всяким - нагадишь - ССЗБ) - и делай себе какой угодно сборщик, хоть несколько на выбор.

Tazhate, по ходу, тоже в функционанисты записался, и испытал анальную боль.

Похоже на то. Он недавно забанил чувака за то, что тот предупреждал о засильи Лишпа в новостях.

Народ, а где-нибудь еще остались очаги интересных дискуссий на разные неизбитые темы с приличным количеством участников и без злобных узколобых вахтёров?

Чтоб совсем без вахтёров — это чаны. Но русскоязычные бесперспективны. Нульчановский /c/ безнадёжно поражён лиспохачкелистами и прочими золотцами, в недодвачевский /pr/ заходит только школота со своими похапе и дельфями. Из англоязычных есть http://dis.4chan.org — тамошние, конечно, тоже замечены в низкопоклонстве перед маргинальщиной, но общий уровень собеседников на порядок выше, чем у нас. Так что маргинальщики огребают по щщам.

окей, есть ошибки, которые допускают «индусы»

В том и пойнт, что допустили эту ошибку отнюдь не «индусы».

Чаны - место для умственно слабых и больных. Нормальному человеку среди этого сброда делать нечего.

Какую ошибку? В старом стандарте по-другому и не сделать было. Как появилась move-семантика, так и сделали unique_ptr, а auto_ptr стал не нужен.

В старом стандарте по-другому и не сделать было.

Ну да, это все знают. Теперь.

Так о полноценных замыканиях, как в других языках(даже в D!), в С++ и речи быть не может.

Нормальное «замыкание» в плюсах это функциональный объект. Вроде

class inc_device {
    int internal_state;
  public:
    explicit inc_device(int initial_state) : internal_state(initial_state) {}
    int operator()(int diff) { return internal_state += diff; }
};

вместо

std::function<int(int)> inc_device(int initial_state)
{
    auto internal_state = std::make_shared<int>(initial_state);

    return [=](int diff) -> int {
        return *internal_state += diff;
    };
}

в использовании не отличается, но по сравнению с функтором std::function всё ещё библиотечный костыль - в случае функтора объект развернётся на стеке, операция уже и так «замыкание» - посредством this, этот this и единственный аргумент попадут в операцию через регистры, а учитывая explicit + inlining - на стеке будет просто int и операция будет работать непосредственно с ним по месту. А у std::function - часть на стеке, другая часть в куче, аллокации и освобождения туда-сюда, сделать std::function<int(int)> -> int(*)(int) нельзя (правда, тут у методов та же проблема, то есть передача non-static method / std/boost::function в виде callbackа в сишный код не пишется никак кроме написания std/boost::function-like обвёрток над сишным кодом), замкнуть умный указатель по ссылке - всё молча соберётся, но получится сегфолт, необходимость использовать умный указатель (может быть нужно чтобы замыкаемое лежало на стеке?) и общее неудобство в использовании. А как оно работает - вообще не понятно, это даже не лишний вызов по указателю это wc -l closure.s > 1000 вместо < 100 для класса.

Форму уже заполнил?

Главред сообщил что новому номеру быть!

Ура!

Не нужно.

ЯП это инструмент. Как молоток, или пассатижи, или микроскоп.

Это красиво выглядящая аналогия — не более того. Например сам по себе python не является ни молотком ни пассатижами ни микроскопом, пока не сделаешь нужные import.
Язык — это более широкое понятие, чем 'инструмент'(во всяком случае это относится к полноценным языкам общего назначения). Он, конечно, призван решать некую задачу, но эта задача очень абстрактна — 'объяснение компьютеру, что от него хочет человек'.
ЯП является молотком лишь отчасти. С инструментами я бы лучше сравнил ИДЕ для языка, а также всякие библиотеки и, например, инструменты автоматической генерации документации из комментированного кода. Так что если ЯП и сравнивать с инструментом, то это далеко не молоток — это какой-то такой универсальный инструмент для создания инcтрументов. Когда-нибудь видели инструментарий или какую-то обвязку для молотка, созданную при помощи молотка?

ЯП есть разные. Как и инструменты - станок с ЧПУ (или точнее станочная линия) это мегаинструмент в принципе способный самовоспроизводиться.

Я с-но хотел лишь отметить, что кричать «С++ ацтой, ЛИСП наше все» очень глупо. Можно говорить, что для каких то задач какой то ЯП лучше. Понятно что у каждого ЯП (как и у каждого инструмента) есть своя ниша. Можно обсуждать эти ниши, или применимость того или иного ЯП в той или иной нише...

И да, с помощью молотка я могу сделать кобуру для молотка;-)

банальный map filter map, а столько писанины

Разве настольно неопциональный код что-либо доказывает? Две лямбды, три функции, переводящие список в другой список - ужас. Только одна лямбда, и только один map:

(defun list-buffers-string ()
  (mapconcat (lambda (buf)
               (let ((name (buffer-name buf)))
                 (unless (string= (substring name 0 1) " ")
                   (format "%s\n" name))))
             (buffer-list) ""))

Еще больше упростил, теперь выглядит так:

(defun list-buffers-string ()
  (mapconcat 'identity
             (remove-if (apply-partially 'string-match "^ ")
                        (mapcar 'buffer-name (buffer-list)))
             "\n"))

Вот, кстати, цитата с курсеры.

Five different things
1. Syntax: How do you write language constructs?
2. Semantics: What do programs mean? (Evaluation rules)
3. Idioms: What are typical patterns for using language features to express your computation?
4. Libraries: What facilities does the language (or a well-known project) provide “standard”? (E.g., file access, data structures)
5. Tools: What do language implementations provide to make your job easier? (E.g., REPL, debugger, code formatter, …) – Not actually part of the language

These are 5 separate issues
In practice, all are essential for good programmers
Many people confuse them, but shouldn’t

This course focuses on semantics and idioms

• Syntax is usually uninteresting
– A fact to learn, like “The American Civil War ended in 1865”
– People obsess over subjective preferences

• Libraries and tools crucial, but often learn new ones “on the job”
– We are learning semantics and how to use that knowledge to understand all software and employ appropriate idioms
– By avoiding most libraries/tools, our languages may look “silly” but so would any language used this way

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

Прошло почти два месяца. Ты сам-то ещe веришь в воскрешение трупа?

Ты сам-то ещe веришь в воскрешение трупа?

да мне все равно. выпустят новый номер — почитаем, не выпустят — почитаем что-нибудь другое.