Действительно ли побочные эффекты являются хорошей вещью?
Вы можете сложить столбцы сверху друг друга с помощью функции bottom в пакете matplotlib.
Шаг 1: Создание фрейма данных и импорт пакетов
import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
from matplotlib import rc
d = {'male': [37,1032,1], 'female': [96,134,1]}
df = pd.DataFrame(data=d, index=['a', 'b', 'c'])
Шаг 2: Создание графика
r = [0,1,2]
bars1 = df['female']
bars2 = df['male']
plt.bar(r, bars1)
plt.bar(r, bars2,bottom=bars1, color='#557f2d')
plt.xticks(r, df.index, fontweight='bold')
plt.legend(labels = ['female', 'male'])
plt.show()
Дополнительную информацию можно найти на этой веб-странице: Ссылка
11 ответов
Время от времени я вижу вопрос о SO, который заставляет меня тратить полчаса на редактирование действительно плохой статьи в Википедии. Статья сейчас только в меру плохая. В той части, которая касается вашего вопроса, я написал следующее:
В информатике говорят, что функция или выражение имеют побочный эффект , если, помимо создания значения, оно также изменяет некоторое состояние или имеет наблюдаемое взаимодействие с вызывающими функциями или внешним миром. Например, функция может изменить глобальную или статическую переменную, изменить один из ее аргументов, вызвать исключение, записать данные в экран или файл, прочитать данные, вызвать другие побочные функции или запустить ракеты. При наличии побочных эффектов поведение программы зависит от прошлой истории; то есть порядок оценки имеет значение. Поскольку понимание эффективной программы требует обдумывания всех возможных историй, побочные эффекты часто затрудняют понимание программы.
Побочные эффекты необходимы для взаимодействия программы с внешним миром (людьми, файловыми системами, другими компьютерами в сети). Но степень использования побочных эффектов зависит от парадигмы программирования. Императивное программирование известно неконтролируемым, беспорядочным использованием побочных эффектов. В функциональном программировании побочные эффекты используются редко. Функциональные языки, такие как Standard ML и Scheme, не ограничивают побочные эффекты, но программисты обычно избегают их. Функциональный язык Haskell ограничивает побочные эффекты статической системой типов; только функция, которая выдает результат типа IO, может иметь побочные эффекты.
Pro:
- В конце концов побочные эффекты - это то, чего вы хотите достичь.
- Побочные эффекты естественны для кода, взаимодействующего с внешним миром.
- Они создают много Алгоритмы просты.
- Чтобы избежать использования побочных эффектов, вам нужно реализовать циклы с помощью рекурсии, поэтому ваша языковая реализация нуждается в оптимизации хвостового вызова.
Con:
- Чистый код легко распараллелить.
- Побочные эффекты могут усложняйте код.
- Чистый код легче доказать, что он правильный.
Например, Haskell, поначалу он кажется очень элегантным, но потом вам нужно начать играть с внешним миром, и это уже не так весело. (Haskell перемещает состояние в качестве параметра функции и скрывает его в вещи, называемые монады,
Жюри все еще отсутствует. И судебное разбирательство продолжается с самого начала компьютерных технологий, так что не ждите вердикта в ближайшее время.
Это правда, как некоторые здесь упоминают, что без побочных эффектов невозможно сделать полезное приложение. Но из этого не следует, что использование побочных эффектов неконтролируемым образом является хорошей вещью.
Рассмотрим следующую аналогию: процессор с набором команд, который не имел инструкций ветвления, был бы абсолютно бесполезным. Однако из этого не следует, что программисты должны постоянно использовать goto . Напротив, оказалось, что структурированное программирование и более поздние языки ООП, такие как Java, могут обойтись даже без оператора goto, и никто его не пропустил.
(Конечно,
Ну, во-первых, гораздо проще и интуитивно понятнее программировать с побочными эффектами. Функциональному программированию многим людям трудно сложить голову - найдите кого-то, кто преподавал / обучал класс в Окамле, и вы, вероятно, получите всевозможные истории о том, как люди не понимают этого. И что хорошего в том, чтобы красиво оформленный, чудесный функциональный код без побочных эффектов, если никто на самом деле не может им следовать? Трудно нанимать людей для выполнения ваших программ.
По крайней мере, это одна из сторон аргумента. Есть много причин, по которым многим людям придется узнавать все о функциональном стиле, коде без побочных эффектов. Многопоточность приходит на ум.
В машинах фон Неймана побочные эффекты - это то, что заставляет машину работать. По сути, независимо от того, как вы пишете свою программу, для ее работы потребуется побочный эффект (на низкоуровневом представлении).
Программирование без побочных эффектов означает абстрагирование побочных эффектов, чтобы вы могли думать о проблеме в целом - не беспокоясь о текущем состоянии машины - и уменьшать зависимости между различными модулями программы (будь то процедуры, классы или что-то еще). еще). Тем самым вы сделаете вашу программу более пригодной для повторного использования (поскольку модули не зависят от конкретного состояния для работы).
Так что да, программы без побочных эффектов - это хорошо, но побочные эффекты просто неизбежны на некотором уровне (поэтому их нельзя считать «плохими»).
Без побочных эффектов вы просто не сможете делать определенные вещи. Одним из примеров является ввод / вывод, поскольку появление сообщения на экране по определению является побочным эффектом. Вот почему целью функционального программирования является минимизация побочных эффектов, а не их полное устранение.
Если оставить в стороне, часто бывают случаи, когда минимизация побочных эффектов конфликтует с другими целями, такими как скорость или эффективность памяти. В других случаях уже существует концептуальная модель вашей проблемы, которая хорошо согласуется с идеей мутирующего состояния, и борьба с этой существующей моделью может привести к потере энергии и усилий.
Побочные эффекты необходимы для значительной части большинства применений. Чистые функции имеют много преимуществ. О них легче думать, потому что вам не нужно беспокоиться о предварительных и постусловиях. Так как они не меняют состояние, их легче распараллелить, что станет очень важно по мере увеличения числа процессоров.
Побочные эффекты неизбежны. И их следует использовать всякий раз, когда они являются лучшим выбором, чем более сложное, но чистое решение. То же самое касается чистых функций. Иногда к проблеме лучше подходить с помощью функционального решения.
Это все хорошо =) Вы должны использовать разные парадигмы в зависимости от решаемой проблемы.
Побочные эффекты - неизбежное зло , и нужно стремиться свести их к минимуму / локализовать.
Другое В комментариях к этой теме говорится, что безэффектное программирование иногда не так интуитивно , но я думаю, что то, что люди считают «интуитивным», в значительной степени является результатом их предыдущего опыта, и опыт большинства людей имеет сильный императивный уклон. Основные инструменты становятся все более функциональными с каждым днем, потому что люди обнаруживают, что бессмысленное программирование приводит к меньшему количеству ошибок (хотя по общему признанию иногда новый / другой класс ошибок) из-за меньшей возможности взаимодействия отдельных компонентов с помощью эффектов.
Почти никто не упоминал о производительности, и программирование без эффектов обычно имеет худшую производительность , чем эффективное, поскольку компьютеры - это машины фон Неймана, которые предназначены для эффективной работы с эффектами (а не для работы с лямбдами). Теперь, когда мы находимся в разгар многоядерной революции, это может изменить игру, так как люди обнаруживают, что им нужно использовать преимущества ядер, чтобы получить производительность, и в то время как распараллеливание иногда требует от ученого-ракетостроителя полного эффекта, это может быть легко сделать правильно, когда вы без эффекта.
Без побочных эффектов невозможно выполнить операции ввода-вывода; так что вы не можете сделать полезное приложение.
Побочные эффекты такие же, как и у любого другого оружия. Они, несомненно, полезны и потенциально очень опасны при неправильном обращении.
Как и у оружия, у вас есть побочные эффекты всех видов, с разной степенью летальности.
В C ++ побочные эффекты полностью не ограничены благодаря указателям. Если переменная объявлена как «частная», вы все равно можете получить к ней доступ или изменить, используя уловки с указателями. Вы даже можете изменять переменные, которые не входят в область видимости, например параметры и локальные переменные вызывающей функции. С небольшой помощью ОС (mmap) вы даже можете изменить машинный код вашей программы во время выполнения! Когда вы пишете на таком языке, как C ++, вы поднимаетесь до ранга Bit God, хозяина всей памяти в вашем процессе. Все оптимизации, которые компилятор вносит в ваш код, сделаны с предположением, что вы не злоупотребляете своими полномочиями.
В Java ваши возможности более ограничены. Все переменные в области видимости находятся под вашим контролем, включая переменные, совместно используемые разными потоками, но вы всегда должны придерживаться системы типов.Тем не менее, благодаря тому, что в вашем распоряжении находится подмножество ОС и наличие статических полей, ваш код может иметь нелокальные эффекты. Если отдельный поток каким-то образом закрывает System.out, это будет похоже на волшебство. И это будет магией: побочная магия.
В Haskell (несмотря на пропаганду чистоты) есть монада ввода-вывода, которая требует, чтобы вы регистрировали все свои побочные эффекты с помощью системы типов. Помещение вашего кода в монаду ввода-вывода похоже на трехдневный период ожидания для пистолета: вы все еще можете оторвать себе ногу, но только после того, как вы согласитесь с правительством. Также есть unsafePerformIO и ему подобные, которые являются черным рынком Haskell IO и дают вам побочные эффекты без каких-либо вопросов.
Miranda, предшественник Haskell, представляет собой чистый функциональный язык, созданный до того, как монады стали популярными. Миранда (насколько я понял ... если я ошибаюсь, замените Lambda Calculus) вообще не имеет примитивов ввода-вывода. Единственный выполняемый ввод-вывод - это компиляция программы (ввод), запуск программы и печать результата (вывода). Здесь у вас полная чистота. Порядок исполнения значения не имеет. Все «эффекты» являются локальными по отношению к функциям, которые их объявляют, что означает, что две непересекающиеся части кода никогда не могут влиять друг на друга. Это утопия (для математиков). Или, что то же самое, distpia. Это скучно. Ничего не происходит. Вы не можете написать для него сервер. На нем нельзя написать ОС. В нем нельзя написать ЗМЕЮ или Тетрис. Все просто сидят и смотрят математики.