Для того, чтобы прямо ответить на ваш вопрос, мне пришлось бы написать очень длинный текс. Поэтому я постараюсь написать короче, но через аллегорию.
Представьте, что вам необходимо объяснить человеку как получить стакан горячей воды. Вы могли бы просто рассказать ему как это сделать, реализация сказанного вами может занять много времени или вообще не сработать, если условия его быта сильно отличаются от ваших. Поэтому вы идете с человеком в его кухню и объясняете все императивно, здесь и сейчас. Вы отдаете ему команды, он их выполняет и в конце концов получает стакан горячей воды. Теперь он знает как в этой кухне, используя теже самые предметы, получить стакан воды.
Вы дали человеку алгоритм для удовлетворения определенной потребности в определенных условиях.
Теперь представьте, что вам необходимо постоянно производить подобную процедуру для большого круга людей. Вы могли бы писать книги, чтобы обучать людей принципам физики, электромеханики и др., чтобы люди могли в различных условиях находить различные способы получения стакана воды. Но подобный подход не гарантирует время выполнения процедуры и качество её результата. Поэтому вы принимаете решение производить чайники, проводить людям водопровод и раздавать брошюрки с наглядным описанием того, как при наличии водопровода, чайника и стакана можно получить стакан с горячей водой. Теперь, при условии выполнения необходимых условий, как наличие чайника, брошюрки и доступа к водопроводу, любой человек может получить стакан горячей воды.
Первое представление содержит объяснение, почему предложенные вами, в статье и вопросе, подходы не дадут ожидаемых результатов. Оба представления, при правильном построении аналогии позволят лучше понять изначальную суть принципа KISS. А форма ответа отражает форму предложенного вами метода объяснения принципов в утрированной форме.
Коаны — лучший ключ к развитию понимания. Давать абстрактное понятие без конкретных объектов, разрешающих абстракцию до привычных мыслительных цепочек то же самое, что запускать регулярный поиск на данных, которые не содержат структур, удовлетворяющих искомому паттерну. Попробуйте дать точное определение тривиальности в любом контексте, к вам придет понимание, что упрощение в контексте ваших знаний может привести к обратному результату. На Хабре уже столько подобных статей, что мем про «еще один протокол» (another one standard xkcd) никогда не перестанет быть актуальным.
Прием — обработка, в том или ном виде, заявки от клиента (опр. по контексту статьи). Например, прием звонков, прием заявлений, прием обращений и т.д.
«Бронь» — жаргонизм от бронировать. Например, сделать бронь в ресторане.
В тексте комбинация из этих понятий используется в заголовках. Под первым из них
«Прием брони на F#, попытка первая»
излагается пояснение
«В моем Pluralsight-курсе Test-Driven Development with F# (доступна сокращенная бесплатная версия: www.infoq.com/presentations/mock-fsharp-tdd) я демонстрирую, как реализовать HTTP API для онлайн-системы бронирования ресторанов, который принимает заявки на резервирование. Один из шагов при обработке запроса на резервирование — проверить, достаточна(заставляет задуматься о грамотности перевода, прим.) ли свободных мест в ресторане для приема брони.»
В переводе присутствует такая же жаргонная фраза — «бронирования ресторанов» — при прочтении текста становится очевидно, что бронируются не рестораны, а места в них.
Оригинальный текст не читал, поэтому не могу сказать, является ли сам текс безграмотным или таков лишь перевод.
Я имел ввиду, что при сравнении с другими редакторами, главное преимущество Vim — это его «эргономичность» управления при наборе вслепую. Я не встречал ни одного редактора (ни самостоятельного, ни встроенного в IDE), где это удобство сочеталось бы со всей полнотой возможностей Vim. Поэтому я его и выбираю. Если опустить вышеприведенный критерий, то Vim перестает быть уникальным и может уступать тому же Emacs, в целом, и специализированным IDE, в частности.
Элемент множества — это объект множества. И принадлежит он множеству, а не операции. Операция обладает лишь операндами — элементами множества, учавствующими в операции. Нейтральность — свойство самого элемента, проявляющееся в условиях применения операции, для которой он собственно и является нейтральным. Нейтральных элементов может быть и два, если операция некоммутативна…
Хотя о чем это я.
*MyMonoid> mconcat $ map Min []
HighInf
Я так понимаю вы хотите доказать, что минимальным элементом пустого множества является плюс бесконечность?
Не буду, как вы, переходить на личности. Я не спорю, что в алгоритме нахождения минимума брать наибольшее значение вполне логично, но только в том случае, если множество непустое (собвственно, так как «Минимум — n-арная операция, операция над n числами, возвращающая наименьшее из чисел.», то минимум от пустого множества неопределим). Я считаю, что необходимо использовать как нейтральный элемен либо неопределенность (ввиду того, что пользователь не предоставил выборку из множества типа, т.е. то самое перечисление чисел, а значит логика операции нарушена), либо минимальный элемент множества типа, тот самый minBound (для мн-ва целых чисел — минус бесконечность). Или вы считаете, что минимальным элементом множества целых чисел является плюс бесконечность?
Теперь возьмем пример поинтереснее — бинарную операцию минимума на числовом множестве. Является ли она моноидом? Операция ассоциативна, множество задано. Единственная проблема — определение нейтрального элемента. Нам нужен такой элемент в нашем множестве, который был бы не меньше любого другого элемента. Если наше множество имеет точную верхнюю грань (например, тип uint8 имеет максимальное значение 255), то мы можем взять это значение в качестве нейтрального элемента нашего моноида. Но если у нас тип неограниченных целых чисел? Решение довольно простое — мы расширяем наш тип еще одним специальным значением (условно назовем его «плюс бесконечность») и зададим операцию так, чтобы выполнялись законы
Prelude> mconcat $ map Min ['a', 'b', 'c']
Min 'a'
Prelude> mconcat $ map Min ([] :: [Char])
HighInf
Я думал, что операция определена «на числовом множестве»? Наверно тоже моя дума. Хотя нет, всё нормально, ведь
Все как и ожидалось — минимум на пустом списке дает плюс бесконечность, на непустом — минимальный элемент.
Как всем хорошо известно, моноидом называется ассоциативная бинарная операция на заданном множестве, имеющая нейтральный элемент.
Думаю, стоит поправить. Моноид — это множество, на котором задана бинарная ассоциативная операция, а не сама операция (к тому же, операция не может иметь нейтральный элемент).
Что же касается сути статьи, а именно реализации полиадической функции сравнения — могу сказать лишь одно: желание реализовать такое возникает только у «лисперов», в силу определенных тенденций.
Я конечно не математик, но вот пример с HighInf в нахождении минимума это нонсенс. Во-первых, подобные операции на пустом списке, в функциональном программировании, являются ошибкой. Во-вторых, если находить минимум на каком-то множестве чисел, то необходимо правильно учитывать структуру этого множества, в случае бесконечных в обе стороны множеств (т.е. от минус бесконечности до плюс бесконечности), минимальным значением будет минус бесконечность, а для конечных множеств это нижняя граница, как 1 для на множества натуральных чисел. Думаю, если уж вводит определение минимума для пустого списка, то это будет неопределенность.
Kay is one of the fathers of the idea of object-oriented programming, which he named, along with some colleagues at PARC and predecessors at the Norwegian Computing Center.
Думаю, при чтении, следует вдумываться в текст. Также вам следует изучить термин «канонический» и отличия терминов «каноническое определение» и «идея»
Для ООП никогда не существовало канонического определения, так как само понятие ООП распределено во множестве языков, его реализующих. И каждый, кто начинает говорить о каноническом определнии, ошибочно полагает, что он знает все его проявления, что, чаще всего, является ошибкой.
Я не знаю кто и в каком языке впервые ввел ООП, но одним из самых известных пионеров, кто начал его популяризаю, думаю, был Алан Кэй. Он утверждал, что основной задачей данной парадигмы, является уход от статической модульности, в виде поключаемых файлов, к динамическим модулям в виде объектов, реализующих как обобщенную, так и конкретную функциональность. Он никогда не говорил, что основной сутью ООП являются объекты как таковые, но именно инкапсуляция в объектах независимых частей общей системы (откуда и растут ноги многократно используемого кода) и взаимодействие данных частей. Главной задачей была именно динамичность системы: горячие обновления путем замены объектов в runtime, как, например, обновление в erlang, взаимодействие модулей, основанное прежде всего на интерфейсах, обеспечивающих гибкость и легкость изменения объектов без нарушения работоспособности системы в целом, общение объектов между собой посредством сообщений, что давало возможность общим объектам делегировать выполнение задачи более специализированным объектам и многое другое.
В целом, можно сделать вывод, что большинство сторонников ООП вообще не понимают первоначальную идею данной парадигмы, считая её неким выражением философской когнитивной модели объект-субъект (причем с отсутствием последнего). Так что ждать от современных ООП-языков соответствия первоначальным принципам не приходится, а попытки переосмыслить все «по-новому» окончательно выродились во что-то неосмысленное и привели к бесконечному потоку подобных статей.
Как раз наоборот, у меня старая видеокарта ATI и в прошлых версиях ubuntu невозможно было поставить проприетарные драйверы от производителя, из-за ограничений на версию X-сов и ядра, вследствие чего не работал opengl. В 16.04 все работает.
Представьте, что вам необходимо объяснить человеку как получить стакан горячей воды. Вы могли бы просто рассказать ему как это сделать, реализация сказанного вами может занять много времени или вообще не сработать, если условия его быта сильно отличаются от ваших. Поэтому вы идете с человеком в его кухню и объясняете все императивно, здесь и сейчас. Вы отдаете ему команды, он их выполняет и в конце концов получает стакан горячей воды. Теперь он знает как в этой кухне, используя теже самые предметы, получить стакан воды.
Вы дали человеку алгоритм для удовлетворения определенной потребности в определенных условиях.
Теперь представьте, что вам необходимо постоянно производить подобную процедуру для большого круга людей. Вы могли бы писать книги, чтобы обучать людей принципам физики, электромеханики и др., чтобы люди могли в различных условиях находить различные способы получения стакана воды. Но подобный подход не гарантирует время выполнения процедуры и качество её результата. Поэтому вы принимаете решение производить чайники, проводить людям водопровод и раздавать брошюрки с наглядным описанием того, как при наличии водопровода, чайника и стакана можно получить стакан с горячей водой. Теперь, при условии выполнения необходимых условий, как наличие чайника, брошюрки и доступа к водопроводу, любой человек может получить стакан горячей воды.
Первое представление содержит объяснение, почему предложенные вами, в статье и вопросе, подходы не дадут ожидаемых результатов. Оба представления, при правильном построении аналогии позволят лучше понять изначальную суть принципа KISS. А форма ответа отражает форму предложенного вами метода объяснения принципов в утрированной форме.
Прием — обработка, в том или ном виде, заявки от клиента (опр. по контексту статьи). Например, прием звонков, прием заявлений, прием обращений и т.д.
«Бронь» — жаргонизм от бронировать. Например, сделать бронь в ресторане.
В тексте комбинация из этих понятий используется в заголовках. Под первым из них
«Прием брони на F#, попытка первая»
излагается пояснение
«В моем Pluralsight-курсе Test-Driven Development with F# (доступна сокращенная бесплатная версия: www.infoq.com/presentations/mock-fsharp-tdd) я демонстрирую, как реализовать HTTP API для онлайн-системы бронирования ресторанов, который принимает заявки на резервирование. Один из шагов при обработке запроса на резервирование — проверить, достаточна (заставляет задуматься о грамотности перевода, прим.) ли свободных мест в ресторане для приема брони.»
В переводе присутствует такая же жаргонная фраза — «бронирования ресторанов» — при прочтении текста становится очевидно, что бронируются не рестораны, а места в них.
Оригинальный текст не читал, поэтому не могу сказать, является ли сам текс безграмотным или таков лишь перевод.
Хотя о чем это я.
Я так понимаю вы хотите доказать, что минимальным элементом пустого множества является плюс бесконечность?
Я думал, что операция определена «на числовом множестве»? Наверно тоже моя дума. Хотя нет, всё нормально, ведь
Думаю, стоит поправить. Моноид — это множество, на котором задана бинарная ассоциативная операция, а не сама операция (к тому же, операция не может иметь нейтральный элемент).
Что же касается сути статьи, а именно реализации полиадической функции сравнения — могу сказать лишь одно: желание реализовать такое возникает только у «лисперов», в силу определенных тенденций.
Думаю, при чтении, следует вдумываться в текст. Также вам следует изучить термин «канонический» и отличия терминов «каноническое определение» и «идея»
Я не знаю кто и в каком языке впервые ввел ООП, но одним из самых известных пионеров, кто начал его популяризаю, думаю, был Алан Кэй. Он утверждал, что основной задачей данной парадигмы, является уход от статической модульности, в виде поключаемых файлов, к динамическим модулям в виде объектов, реализующих как обобщенную, так и конкретную функциональность. Он никогда не говорил, что основной сутью ООП являются объекты как таковые, но именно инкапсуляция в объектах независимых частей общей системы (откуда и растут ноги многократно используемого кода) и взаимодействие данных частей. Главной задачей была именно динамичность системы: горячие обновления путем замены объектов в runtime, как, например, обновление в erlang, взаимодействие модулей, основанное прежде всего на интерфейсах, обеспечивающих гибкость и легкость изменения объектов без нарушения работоспособности системы в целом, общение объектов между собой посредством сообщений, что давало возможность общим объектам делегировать выполнение задачи более специализированным объектам и многое другое.
В целом, можно сделать вывод, что большинство сторонников ООП вообще не понимают первоначальную идею данной парадигмы, считая её неким выражением философской когнитивной модели объект-субъект (причем с отсутствием последнего). Так что ждать от современных ООП-языков соответствия первоначальным принципам не приходится, а попытки переосмыслить все «по-новому» окончательно выродились во что-то неосмысленное и привели к бесконечному потоку подобных статей.