Уорд Каннингем написал такое эссе: Key Language Feature. Оно даёт ответы на вопросы, подобные вашему.
Кратко пробежимся по списку: higher order functions, lambda expressions, exception handling, resumable exceptions, closures, first-class types, causally reflective environment, introspection and reflection, modules, automatic type inference − это всё есть в Python искаропки, но в C и C++ нужно писать много кода, чтобы реализовать все эти фичи.
Мета-вопрос: почему вы этого не понимаете? Тоже есть ответ: Пол Грэм, Blub Paradox (по-русски).
Кароси − это не совсем то, но близко. Я где-то читал, что в японских университетах не бывает абсолютной успеваемости − только относительная. Оказываешься в хвосте списка по баллам − автоматически отчисляешься. Сейчас что-то не могу найти этому подтверждения. А то была бы полная аналогия.
Нормы труда определяются алгоритмом по средней производительности сотрудников.
Наиболее медленные сотрудники автоматически увольняются.
На их место принимаются новые сотрудники со, скажем так, случайной производительностью.
GOTO 1.
Таким образом, в коллективе остаётся всё больше «быстрых» сотрудников, вследствие чего нормы труда постоянно увеличиваются, пока не превратятся в гонку на выживание. И главное, каждое конкретное действие такого алгоритма можно представить как вполне обоснованное и справедливое. И никакого давления со стороны менеджмента: коллектив сам себе выбирает темп работы.
Я помню реакцию и лицо одного программиста, которому в качестве попытки уловить труднонаходимый «плавающий» дефект предложил воспользоваться профайлером встроенным в IDE: мне было указано, что это не собачье дело руководителя проекта советовать, какими средствами программист должен пользоваться в своей работе.
Профайлер, если что, предназначен для получения статистики по использованию программой памяти и процессорного времени. «Плавающий дефект» профайлером не вылечить. Или вы перепутали профайлер с отладчиком?
Ты можешь по запросу коллеги, тестировщицы, аналитика или заказчика за 3 минуты пропарсить пару сотен тысяч
Я очень сочувствую тем программистам, которые под вашим руководством превратились в мальчиков на побегушках, выполняющих «запросы» мимо таск-трекера, парсящих логи, фигачащих отчёты в Экселе. А с учётом того, что это для них −
рутинные операции, требующие многократного повторения в течение рабочего дня…
… то вы получаете ровно то, на что напрашиваетесь: наглость (потому что иначе с вами в одной команде не прожить) и некомпетентность (потому что хороший разработчик не будет терпеть такого к себе отношения).
Но за достаточно долгую уже карьеру я встречал не так много программистов, использующих комбинации КБД на клавиатуре для вызова тех или иных стандартных действий — большинство для этого используют более медленный манипулятор «мышь».
Ну, а советы типа «выучить шоткаты» и «освоить слепой десятипальцевый метод» меня с некоторых пор даже умиляют. Просто вишенка на торте. Понятно же, что скорость написания программы ограничивается только скоростью нажимания кнопок!
Женщина-оратор, по-видимому, ставила своей задачей вселить в нас бодрость, поднять наш ослабевший дух.
Мы вошли в зал, хмурясь. Сели по местам нахмуренные. А когда она заговорила, нахмурились еще больше. Вряд ли кто-нибудь слушал, что она там говорит. Женщина довольно прытко подвигалась вперед и вдруг неожиданно заявила:
– Наука говорит: когда мы улыбаемся, расходуется энергия двадцати семи мускулов лица, а когда хмуримся – почти вдвое больше: пятидесяти одного мускула. – Она сделала паузу: – Так зачем же нам хмуриться?
В этот момент Виктор Тоска открыл глаза и громко сказал:
– Чтобы делать побольше физических упражнений.
Раздался общий хохот, крики «браво!», аплодисменты, и кто-то добавил:
– Правильно! Надо как можно больше упражняться.
Ротный командир поднялся с места и заорал:
– Отставить!
И сразу все стихло.
– Кто это сострил? – спросил ротный.
Виктор Тоска хотел встать, но Доминик схватил его за плечи и толкнул обратно на стул.
Потом Доминик встал сам.
– Явитесь ко мне в канцелярию, – сказал ему ротный, и Доминик вышел из зала.
Он был оставлен на неделю без увольнения плюс наряды вне очереди каждые сутки.
Я не очень понимаю, почему кооперативную многопоточность считают «будущим» чего-либо. Для меня она тоже around since forever, взять twisted для примера, не говоря уже о том, чтобы выйти за пределы Python-экосистемы. Она действительно даёт возможность ускорить обработку запросов, иногда просто драматически. Но зато она сложна для понимания человеком, и ни промисы, ни async/await тут не помогут. И сто́ит чуть-чуть оступиться − и у тебя в проекте блокировка, которую ты не знаешь, как отладить.
Как по мне, так ASGI и Channels − это не тупик, а как раз шаг в правильном направлении, к компромису между производительностью программиста и машины.
Построение абстракций ООП на основе сущностей реального мира — одно из самых частых заблуждений в ООП
Почему это − заблуждение, кто ещё приходил к этому выводу, что можно почитать на эту тему?
Я, например, ни разу не видел учебника, который не использовал бы метафор из реального мира, чтобы объяснить принципы ООП. Википедия говорит о “things found in the real world”. В общем, если это и заблуждение, то оно слишком распространено, чтобы отметать его так запросто, вы не думаете?
Как я понял предмет, монада − это такой способ объединения функций в цепочку, когда мы их входной и выходной типы данных продвигаем до такого типа, который будет обратно совместим с ними обоими. Для этого, естественно, нам нужны две дополнительные функции.
И правильно понимаю, что в первых двух примерах достаточно расширить структуру входных параметров
Тогда мы не сможем переиспользовать код f1, f2 и f3, а ведь это было нашей главной задачей.
Я ничего не имею против математического языка, но на Хабр захожу, чтобы получить объяснение чего-то обычным языком, in layman's terms. Видимо, я не одинок.
Кратко пробежимся по списку: higher order functions, lambda expressions, exception handling, resumable exceptions, closures, first-class types, causally reflective environment, introspection and reflection, modules, automatic type inference − это всё есть в Python искаропки, но в C и C++ нужно писать много кода, чтобы реализовать все эти фичи.
Мета-вопрос: почему вы этого не понимаете? Тоже есть ответ: Пол Грэм, Blub Paradox (по-русски).
Таким образом, в коллективе остаётся всё больше «быстрых» сотрудников, вследствие чего нормы труда постоянно увеличиваются, пока не превратятся в гонку на выживание. И главное, каждое конкретное действие такого алгоритма можно представить как вполне обоснованное и справедливое. И никакого давления со стороны менеджмента: коллектив сам себе выбирает темп работы.
Я очень сочувствую тем программистам, которые под вашим руководством превратились в мальчиков на побегушках, выполняющих «запросы» мимо таск-трекера, парсящих логи, фигачащих отчёты в Экселе. А с учётом того, что это для них −
… то вы получаете ровно то, на что напрашиваетесь: наглость (потому что иначе с вами в одной команде не прожить) и некомпетентность (потому что хороший разработчик не будет терпеть такого к себе отношения).
Ну, а советы типа «выучить шоткаты» и «освоить слепой десятипальцевый метод» меня с некоторых пор даже умиляют. Просто вишенка на торте. Понятно же, что скорость написания программы ограничивается только скоростью нажимания кнопок!
(У. Сароян. «Приключения Весли Джексона»)
make && make install:manpages.ubuntu.com/manpages/xenial/en/man8/checkinstall.8.html
Как по мне, так ASGI и Channels − это не тупик, а как раз шаг в правильном направлении, к компромису между производительностью программиста и машины.
Почему это − заблуждение, кто ещё приходил к этому выводу, что можно почитать на эту тему?
Я, например, ни разу не видел учебника, который не использовал бы метафор из реального мира, чтобы объяснить принципы ООП. Википедия говорит о “things found in the real world”. В общем, если это и заблуждение, то оно слишком распространено, чтобы отметать его так запросто, вы не думаете?
Тогда мы не сможем переиспользовать код f1, f2 и f3, а ведь это было нашей главной задачей.