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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чушь

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

Пожелания

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

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

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

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

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

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

А что не так с

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

Когда вас к

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

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

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

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

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

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

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

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

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

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

С чего бы это?

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

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

Haskell

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

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

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

Спасибо.

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

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

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

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

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

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

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

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

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

Нет никакого

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

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

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

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

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <pre>
  • Строки и параграфы переносятся автоматически.

Подробнее о форматировании

CAPTCHA
Проверка на бота
Image CAPTCHA
Copy the characters (respecting upper/lower case) from the image.