О состоянии дел с четвёртым томом

Опубликовано admin в Ноябрь 3, 2018 - 13:19.

Рукопись четвёртого тома с рабочим названием «Парадигмы» постепенно обретает очертания. Как водится, всё получается совсем не так, как планировалось. Изначально я хотел разделить том на четыре части: Си++, GUI, скриптинг и альтернативные парадигмы (Лисп, Пролог и иже с ними), но, пытаясь вписать старый текст по Си++ в новую канву, я столкнулся с потребностью рассказать о парадигмах до, а не после обсуждения ООП и АТД. В то же время мой опыт показывает, что рассказывать о парадигмах как о способах осмысления выполнения программ можно на примере уже известных читателю языков: Паскаля, языка ассемблера и Си вполне достаточно, чтобы проиллюстрировать разные способы мышления, пусть и не все — тут скорее важно показать сам факт наличия разных способов.

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

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

Третья (одиннадцатая) часть будет посвящена «неразрушающим» парадигмам — функциональному и логическому программированию. Здесь будет краткое введение в языки Лисп, Scheme, Пролог, Рефал (Рефал-5) и Хоуп с обсуждением того, как можно изменить собственное восприятие своих программ при работе на этих языках.

Наконец, четвёртая часть, двенадцатая в общей нумерации, под рабочим названием «Компиляция, интерпретация, скриптинг», кроме анонсированного ранее введения в Tcl и Tcl/Tk, будет содержать ещё обсуждение парадигм, связанных с избранием стратегии исполнения (полная интерпретация, частичная компиляция, полная компиляция) и их ограничений. Сделать эту часть последней, а не предпоследней, как планировалось ранее, я решил вот по какой причине. Не так давно вышла моя с двумя соавторами статья «Чистая компиляция как парадигма программирования»; идеи, которые в этой статье прозвучали, мне хочется видеть в книге, коль скоро она посвящена парадигмам, но обсуждать эти материи всерьёз можно лишь тогда, когда читатель уже знаком как с компилируемым, так и с интерпретируемым исполнением — то есть явно после главы о неразрушающих парадигмах. При этом логичнее такой параграф впишется в главу о скриптинге, для которого интерпретация кажется определяющей — например, как некий обзор ограничений скриптинга, или ответ на вопрос «почему не надо использовать командно-скриптовые языки в роли языков общего назначения».

К настоящему моменту первая часть (которая про парадигмы) почти готова, от части по Си++ есть только то, что уже было раньше, так что главы про TCP-сервер и FLTK ещё впереди, начата работа над частью про «экзотику» (написана примерно треть текста про Лисп), рукопись части про скриптинг пока пустая. В целом четвёртый том обещает быть самым толстым, но я пока надеюсь уложить его в одну физическую книгу (страниц эдак на 600).

По срокам я надеялся успеть к новому году, но, похоже, это всё-таки утопия: чтобы том успели напечатать в 2018 году, нужно рукопись дописать чуть больше чем за месяц, это нереально.

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

Большое спасибо всем, кто поддерживает проект!

Блог пользователя admin

#1Опубликовано Uriy Gerko (не проверено) в Ноябрь 4, 2019 - 11:19.

Андрей

Андрей Викторович!
Вы пишите:"....По срокам я надеялся успеть к новому году..."
А можете уточнить, какого года?

#2Опубликовано admin в Ноябрь 4, 2019 - 15:57.

Прошлого :-)

Там же в посте дата есть -- 3 ноября 2018 года, ровно год назад. Да и прямо во фразе про сроки упоминается 2018 год.

Сейчас вот год прошёл, и я уже сомневаюсь, что к этому новому году успею. То есть текст-то дописать вроде успеваю, но пока его корректор перелопатит, пока типография напечатает...

#3Опубликовано Uriy Gerko (не проверено) в Февраль 18, 2019 - 14:40.

Вопрос

Скажите, пожалуйста, когда появится четвертый том?

#4Опубликовано Gerko Yuriy (не проверено) в Апрель 17, 2019 - 07:19.

Андрей

Андрей Викторович!
Подскажите, пожалуйста, где можно посмотреть примеры практического использования FLTK?

#5Опубликовано admin в Апрель 17, 2019 - 14:48.

Увы

У меня нет ответа на ваш вопрос. Я в своё время первое впечатление составил по вот этому туториалу http://www3.telus.net/public/robark/ , а потом детали смотрел в документации здесь: https://www.fltk.org/doc-1.3/index.html
Мне хватило, так что я поиском чего-то ещё не заморачивался.

#6Опубликовано admin в Февраль 19, 2019 - 02:10.

Мне это самому интересно

Я очень надеюсь выпустить его до лета. Получится или нет — скоро увидим.

Пока там ещё писать и писать.

#7Опубликовано Uriy Gerko (не проверено) в Февраль 19, 2019 - 08:52.

о создании графических интерфейсов с помощью FLTK

Уважаемый Андрей Викторович!
Очень жду десятую часть, чтобы почитать об использовании FLTK. В настоящее время для обработки экспериментальных данных пишу программу на С, для визуализации результатов использую gnuplot. В принципе неплохо получается, однако хочу создать программу с графическим интерфейсом. Делал несколько подходов к Qt, пока не освоил из-за недостатка времени. (Я не профессиональный программист, однако очень интересуюсь). В процессе изучения Ваших работ обнаружил обнадёживающую, в смысле моих потребностей, информацию о FLTK. Если это возможно, сообщите, пожалуйста, ссылки на материалы о практическом применении этой библиотеки для создания интерактивных графических интерфейсов.(Документ FLTK 1.3.5 Programming Manual.pdf я уже имею)

#8Опубликовано фтщт (не проверено) в Ноябрь 12, 2018 - 15:49.

Еще бы найти место, где все эти знания потом радостно применять)

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

В итоге для радости приходится изучать одно, а для работы - совсем другое

P.S. Я бот, так как капчу не могу расознать

#9Опубликовано admin в Ноябрь 13, 2018 - 23:11.

Чушь

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

#10Опубликовано Aleksej (не проверено) в Февраль 16, 2019 - 13:47.

Извините что

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

#11Опубликовано admin в Февраль 20, 2019 - 22:27.

Есть-есть

Да, я знаком с программистами, пишущими за деньги, например, на Scheme и Haskell. Вроде бы на Clojure тоже кто-то писал, но я с ходу не вспомнил, кто именно из моих знакомых. Индустриальных прологеров не знаю, но в России Пролог вообще традиционно менее популярен, чем функциональные языки.

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

#12Опубликовано Alexander (не проверено) в Ноябрь 7, 2018 - 21:41.

Пожелания

Андрей Викторович, из прочитаных 3 томов, хотелось попросить добавить Хаки по Си++, как вы описывали по Си во втором томе, и еще бы интересно было, как сейчас модно говорить "паттерны проектирования", которые по вашему мнения лучше использовать.
Рассмотреть такой вопрос,как использование в Си++ библиотек и кодов из других языков программирования, если это возможно. А еще не хватает в ваших книгах упражнений для закрепления материала, чтобы на практике воспользоваться полученными знаниями. Или выпустить отдельно к 4 томам сборник типовых задача и со звездочкой по born shell, make, pascal, assembler, C, C++ ...)

#13Опубликовано admin в Ноябрь 9, 2018 - 14:23.

Про хаки не понял

Где это, собственно, я описывал хаки по Си?

Про "паттерны проектирования": их использовать не надо. Точка, всё. Люди, начитавшиеся "банды четырёх", опасны для окружающих :-)

Про "из других языков" -- возможно, разумеется, вообще всё. Вопрос в том, насколько это нужно.

Что до задачника -- такая идея уже озвучивалась. Ну вот сейчас с четвёртым томом закончу, подумаю на эту тему.

#14Опубликовано Sergei (не проверено) в Ноябрь 10, 2018 - 23:28.

А что не так с

А что не так с паттернами проектирования? У меня сложилось впечатление, что во многих случаях банальный здравый смысл приводит к конструкциям, которые по сути являются паттернами проектирования, хотя тот, кто пишет код, может и не знать о том, что они именно так называются. Например, банальная ситуация, когда у нас есть абстрактный класс и несколько его реализацией, вроде как называется паттерном "Bridge" или "Strategy" (никогда не понимал, в чём между ними разница), но для практического применения это вроде как знать не обязательно. Не могли бы вы пояснить, в чём здесь заключается проблема?
Если что, вопрос задаётся не холивару ради, а информации для. Так вышло, что книгу "банды четырёх" я не читал, хотя и слышал о ней.
Интересно, пройдёт ли этот комментарий премодерацию )

#15Опубликовано admin в Ноябрь 13, 2018 - 23:25.

Когда вас к

Когда вас к "конструкциям" приводит здравый смысл, то это уже не "паттерн", будь эта конструкция хоть двести раз "похожа". Проблема с паттернами именно в том, что их применяют без всякого здравого смысла, просто потому что вот есть же такой вот паттерн. Естественно, применяют не по делу. Самый популярный почему-то паттерн "фабрика объектов" на самом деле не нужен вообще почти никогда, но его _возможно_ (в смысле, ну вот физически есть такая возможность) применить везде, где вообще есть объекты, так каждый первый "благодарный читатель" банды четырёх считает это своим первейшим долгом. А потом ещё в довершение сделать фабрику фабрик.

За применение того же Singleton вообще надо с работы выгонять, и нормальный человек, понимающий (желательно на своей шкуре), почему глобальные переменные есть вселенское зло, никогда ничего подобного не сделает; но читатель банды четырёх — сделает, ведь есть же паттерн.

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

#16Опубликовано Alexander (не проверено) в Ноябрь 10, 2018 - 13:24.

Да вы правы...

Про "хаки" слово понравилось, статью параграф 4.11.4 перечитывал там был такой текст про (sentry macros) "...между тем это не более чем очередной хак, использование подвернувшегося под руку инструмента...". Правильно было сказать тонкости языка.

Ясно, как раз хотел прочитать эту книгу, теперь не буду, чтобы не быть опасным...)

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

Отлично, буду ждать выхода!

#17Опубликовано admin в Ноябрь 13, 2018 - 23:18.

ерунда какая-то

С++ не может считаться чисто компилируемым

С чего бы это?

значит может преобразовывать во время компиляции чужой код в свои код

уж такого точно в C++ отродясь не было, впрочем это и из предыдущего тезиса не следует, даже если бы он был верен

#18Опубликовано yuri (не проверено) в Ноябрь 3, 2018 - 21:10.

Haskell

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

Встретил там ваш коммент про то, что Haskell - хороший язык, но будущего вы за ним не видите.
А можете немного раскрыть, чем он хороший? После того, как меня привлёк данный язык своими необычными особенностями, я просмотрел обсуждения на различных форумах, и в основном комментарии сводятся там к тому, что он "устроен как-то не так". Связано ли это с тем, что подавляющее большинство подступаются к хаскеллю с какой-то не той стороны, или пытаются применять его к тому, для чего он не годится?
Хотелось бы услышать ваше мнение на этот счёт.

Что касается четвертого тома, выглядит он очень многообещающе. Особенно интересно будет прочитать про лисп и пролог. И кстати, раз уж речь зашла о Haskell'е, почему вы решили сведения о нём в эту книжку не включать?

Спасибо.

#19Опубликовано admin в Ноябрь 4, 2018 - 00:12.

Там оставлять

Там оставлять комментарии нельзя

Можно, почему. Просто их мало кто увидит. Я увижу в любом случае, очередь на модерацию тут одна.

Haskell
А можете немного раскрыть, чем он хороший?

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

"устроен как-то не так". Связано ли это с тем

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

почему вы решили сведения о нём в эту книжку не включать?

В части, посвящённой неразрушающим парадигмам, нет задачи научить тому или иному языку как инструменту, есть задача показать разные способы мышления. Haskell для этого не подходит из-за всё того же барьера вхождения. Если его рассказывать "по верхам", как раз того, что интересно, видно не будет, а глубоко влезть в Haskell мало кому удаётся. Хоуп (который Hope) в этом плане подходит намного лучше, он простенький, но позволяет продемонстрировать и ленивость, и вывод типов, и карринг, и успешную борьбу с побочными эффектами через ленивые последовательности. Ну а монады я бы всё равно адекватно рассказать не смог.

#20Опубликовано Maxim (не проверено) в Декабрь 29, 2018 - 21:17.

Я вообще пришёл

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

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

Какой выбор следует сделать, либо где ошибка в моей логике?

#21Опубликовано admin в Декабрь 29, 2018 - 22:16.

Ошибка?

Чтобы "ошибиться в логике", нужно для начала, чтобы логика существовала. В ваших рассуждениях логики нет вообще. Рассматривать подзадачу "я хочу заменить одну букву на другую" нельзя вне контекста, и в зависимости от того, каков объемлющий контекст — да хоть бы и от того, будет или не будет исходная строка дальше использоваться — может быть выбран тот или иной вариант. Более того, если контекст у нас из серии "мы всё равно не перетормозим пользователя" (да, такое бывает), то можно даже навертеть высокоуровневых абстракций и забить на выбор стратегии — сойдёт любая, лишь бы работало. Но в том же проекте может встретиться другой контекст: например, сначала мы модифицировали строку, которую пользователь вбил в формочку, а потом нам потребовалось модифицировать таким же точно образом строки, хранящиеся в каком-нибудь файле, в количестве полутора миллионов. И вот тут уже на эффективность забивать нельзя.

Так вот, правильный язык должен позволять любой из этих вариантов, а не навязывать какой-то один. А решать должен программист.

#22Опубликовано Anonymous (не проверено) в Декабрь 22, 2018 - 20:29.

Я вообще пришёл

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

Андрей, так всё-таки, как вы определяете эту "дальность" от машины? Я уже оставлял тут этот вопрос пару-тройку недель назад, но он то ли затерялся, то ли не прошёл модерацию. На всякий случай уточню, что я тут не собираюсь никого троллить или разговаривать сам с собой. Меня действительно интересует ваше мнение, поскольку вопрос этот регулярно у меня самого в голове всплывает.

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

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

Если из оставшихся императивных языков вычеркнуть те, что со сборкой мусора (в силу их бессмысленности), то среди кандидатов на "хорошие" языки останется всего ничего: си, си с крестами, фортран, паскаль, раст, ада, форт... Больше с живыми компиляторами/интерпретаторами ничего сходу не вспоминается. Ну, разве что, бейсик.

#23Опубликовано admin в Декабрь 25, 2018 - 00:00.

Какой форт, какой бейсик...

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

Форт стековый, а мы пока ещё программируем на машине фон Неймана, которая отродясь стековой не была. Бейсик хоть и императивный, но машины сквозь него не видно вообще от слова совсем.

Теперь вот эти три. Си++ фактически уничтожен стандартизаторами. Паскаль... э... последняя поддерживаемая реализация -- Free Pascal, и там упорно не хотят фиксить элементарную, в сущности, ошибку в SeekEof. Я даже хотел сам пофиксить, полез в исходники, и у меня волосы встали дыбом. Понятно, почему фиксить не хотят, там write only code. В общем, сдох Паскаль, если называть вещи своими именами. Остаётся Си, но в нём напряжёнка со средствами абстрагирования, так что программирование на Си отличается просто-таки нелепым уровнем бессмысленной трудоёмкости.

Мораль? А нету хорошего языка. Ни одного. И моё утверждение о хорошем языке касается скорее того, что вроде бы должно появиться, но всё никак не появится.

#24Опубликовано Anonymous (не проверено) в Декабрь 25, 2018 - 20:48.

ну бейсик-то я в шутку упомянул, конечно

Форт стековый, а мы пока ещё программируем на машине фон Неймана, которая отродясь стековой не была.

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

А что насчёт раста? Вы как-то грозились посмотреть, не годится ли он на замену си, как язык без сборки мусора. Сам я, признаться, про раст имею только два впечатления: преувеличенный хайп вокруг него, явно маркетинговой природы, и отталкивающий (меня, по крайней мере) своей криптографичностью синтаксис.

А нету хорошего языка.

Ну вон оберонщики в своей секте таки нашли себе идеальный язык.

А мог бы быть "хорошим языком" си++? Если бы оставался си с классами? Или к нему тоже есть претензии?

Ну и ещё один волнующий меня вопрос: в каких случаях лисп/схема или хаскелл будут всё-таки наилучшим выбором (наименьшим, так сказать, злом), как вы думаете?

#25Опубликовано admin в Декабрь 26, 2018 - 20:19.

> стековую

стековую машину можно весьма прозрачно эмулировать

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

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

А что насчёт раста?

Увы, я по-прежнему не готов его обсуждать. Его для этого надо знать, я его всё ещё не знаю.

Ну вон оберонщики

Ну а рефалисты всерьёз утверждали, что всё надо писать на Рефале (там даже чисел с плавающей точкой отродясь не было, но их это не смущало). Вполне нормальное явление, "наш язык ueber alles".

А мог бы быть "хорошим языком" си++? Если бы оставался си с классами?

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

Претензии, впрочем, конечно есть. Например, this должен был бы быть ссылкой, а не указателем; см. вот это обсуждение. Более того, виртуальность следовало бы вытеснить в библиотеку. Да и new/delete тоже как-то надо было туда же, дал слабину Страуструп. И про шаблоны не надо было делать вид, что они якобы не макросы — получилось бы лучше. Больше того, символы инфиксных операций следовало бы перегружать макросами, а не функциями, и тогда бы не потребовалось делать перегрузку функций, которая тянет за собой манглинг (одно из самых уродливых явлений в Си++). Но на общем фоне это всё, откровенно говоря, ерунда.

в каких случаях лисп/схема или хаскелл будут всё-таки наилучшим выбором

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

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

Софт массового использования на таких языках писать нельзя.

#26Опубликовано jamesjames7 (не проверено) в Ноябрь 3, 2018 - 15:37.

Нет никакого

Нет никакого сомнения, ёмкостная и грамотная подготовка 4-го тома.
«четвёртый том обещает быть самым толстым» — а юмор там будет? :)
Спасибо вам за труды!

#27Опубликовано admin в Ноябрь 3, 2018 - 17:28.

Гм, быстро :-)

Не ожидал такой молниеносной реакции.

Юмор — будет, я без него не умею.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".