Есть спецификация языка. В случае Си — это стандарт ISO/IEC 9899. Все, что не входит в эту спецификацию частью языка не является. Компилятор (и уж тем более его конкретная реализация) туда не входит. Стандартная библиотека входит, но её реализация — не входит.
Еще раз. Тот факт, что вызов printf в данном случае транслируется в вызов puts вызван не языком С, а компилятором gcc (конкретной версии, использованной автором) и glibc версии 2.17. Когда Ричи с Керниганом работали над Си и хеллоуворлдом для него — ни gcc, ни glibc еще и в помине не было.
Нет. В качестве примера первой «самой простой» программы Керниган взял программу, которая выводит одну строку и завершается. Именно это написано в тексте программы и именно это делает программа после компиляции и выполнения. И делает это вполне просто и однозначно с точки зрения программиста, пишущего Hello World.
А то, каким образом она это делает под капотом — к Си как к языку никоим образом не относится. Это детали реализации компилятора, стандартной библиотеки и операционной системы.
А если так сильно хочется попричитать по поводу "слишком сложного и неоднозначного" hello world, то вы идите дальше — жалуйтесь на то, как неоднозначно выполняется код на разных архитектурах процессоров. А какие сложные квантовые эффекты в чипе процессора этот якобы "простой" код вызывает! Жуть! Ужасный пример Керниган взял, слишком уж всё сложно и неоднозначно.
Картинка с его сайта не соответствует его текущей реализации. Сейчас у него глубина воронки 1. Т.е. пристроить текущий элемент пробуем только к одному списку. Если не получилось, то этот список отправляем в буфер и больше не трогаем. А элемент заносим в новый пустой список и работаем дальше с ним.
От воронок осталось одно название. На деле входной поток просто разбивается на отсортированные подпоследовательности, которые потом сливаются мердж-сортом.
Не совсем. Сравнение только с одним текущим бакетом, а не со всеми. Если к нему пристроить не получается, то текущий отправляется в "буфер", а очередной элемент добавляется в новый пустой бакет.
Изначально — да, гениальная задумка автора была похожей — завести несколько бакетов (не динамически добавлять новые, а статически задавать "глубину воронки") и по ходу чтения пристраивать очередной элемент к концу одного из бакетов. Если ни к одному пристроить не получилось — сливаем 2 самых маленьких и пихаем наш элемент в образовавшийся пустой бакет.
Но в итоге он осознал, что это работает плохо, поэтому в своем сортире реализовал вариант с одним бакетом. Читаем данные, по ходу пристраиваем их к бакету. Если пристроить не вышло — откладываем текущий бакет в "буфер", как он это назвал и продолжаем читать дальше в новый бакет. В конце в "буфере" будет набор отсортированных бакетов, которые он сливает MergeSort-ом.
В конечном варианте, асимптотика аналогична асимптотике MergeSort-а.
Чтение за O(N) т.к. всего у нас N элементов и каждый из них пристраивается за O(1): пристройка к существующему бакету — очевидно, константа (если бакет реализован связным списком как у него). Перенос бакета в "буфер" — тоже константа.
А после этого мы просто оказываемся в ситуации "MergeSort посреди выполнения". Для хороших данных — ближе к концу выполнения. Для плохих — ближе к началу. Но в общем случае для завершения сортировки MergeSort-у потребуется O(N * Log N) времени. Не О(n^2).
Изначально у нас К бакетов. Мы можем их попарно слить друг с другом за О(n). После этого шага у нас количество бакетов уменьшится в 2 раза. Соответственно, всего на слияние всех бакетов в один потребуется Log2 K шагов. Т.е. общая асимптотика слияния будет O(N * Log К), а учитывая, что в худшем случае К = O(N), получаем асимптотику O(N * Log N)
В общем, алгоритм не ужасен. Он правда работает. Местами как MergeSort, местами даже лучше. Ужасен автор) Ну и сам алгоритм, хоть и не ужасен, но и явно не дотягивает до общепринятых на сегодняшний день. А потому применение его не оправдано практически нигде.
Ну не read-only, а 1 коммент в день. Даже с кармой -100 он сможет писать. Но лишь раз в неделю.
Но в любом случае, оно и к лучшему. Кроме агрессивного невежества комментарии автора ничего не содержали (и его заметка на сайте — не исключение). По существу с ним общаться невозможно.
П.С. А кодом он с вами поделился с условием неразглашения? Если нет, то может вы его опубликуете, чтобы была возможность у желающих все таки провести адекватные бенчмарки?
А чего так скромно-то? Давайте сразу на сто. А лучше на тысячу. Главное продолжайте всеми силами избегать замеров времени работы своего сортира и других сортировок в равных условиях. А там уж для "уравнивания" условий можно брать любой коэффициент. Хоть 3, хоть 4, хоть 100500. Предел — лишь ваше воображение!
Меня эта хрень вообще не интересует.
…
Мне НАСРАТЬ… я открытым текстом в заметке об этом написал.
Это уже все поняли :)
Да неужели? Счётчики сравнений во второй группе посмотрите! По крайней мере, первый и последний. ;)
Вторая группа в плане оценки асимптотики среднего случая совершенно бесполезна и не показательна. Но вам (как практику) это понимать не обязательно, так что не берите в голову.
Вы бредите?
Нет. А вы?
У меня НА ВСЕХ тестах воронка глубиной 1!… о чём всё описано в первой заметке.
Да, именно это я и написал. В первой заметке вы поняли, что на практике ваша концепция воронок оказалась бесполезной и потому остановились на банальном разбиении входного потока на отсортированные подпоследовательности и дальнейшем слиянии этих подпоследовательностей как в merge sort.
И полученный вариант в плане асимптотики абсолютно аналогичен сортировке слиянием. Такие дела. На практике — да, может быть немного быстрее MergeSort-а для "реальных" данных. На некоторых очень специфичных данных (полностью отсортированный массив) — заметно быстрее. Но в целом по-прежнему хуже общепринятых алгоритмов сортировки, вроде того-же TimSort.
Доказать, что воронка идеальна, уж простите, у вас не получилась. Если сравнить ваши числа с числами из первой статьи (хоть их и нельзя сравнивать, об этом дальше), то окажется, что на случайных данных воронка мощно всасывает по сравнению со всеми алгоритмами из первой статьи, за исключением SmoothSort. На частично отсортированных данных дела получше, но воронка по-прежнему и близко не подходит к тому-же TimSort-у на всех без исключения "степенях" частичной отсортированности. А в отдельных случаях работает медленнее шелла.
Но на самом деле, даже этих выводов сделать из статьи нельзя. Причин много, выбирайте любую:
Вы сами пишете, что железо у вас лучше, чем было использовано автором той статьи. То есть получается, что цифры воронки будут еще хуже.
В отличие от той статьи, у вас помимо времени собственно сортировки зачем-то замерялось еще время ввода-вывода. Выяснить, в какой степени проведенные манипуляции являются бенчмарком алгоритма, а в какой — бенчмарком вашего накопителя, не представляется возможным.
Мало того, что у вас в принципе очень отличается и железо и программная среда от использованной в первой статье, так вы еще и внятно не описали, какое вообще у вас железо. Вы тут во все стороны в истерике развешиваете ярлыки "люмпенов" и "не-программистов". Скажите пожалуйста сами, как стоит назвать человека, считающего, что "двухъядерник 2.8ГГц" — это исчерпывающее описание характеристик процессора. Или по-вашему, Atom C2550 и Core i5 7400T — это одинаковые "четырехъядерники 2.4ГГц"? Автор исходной статьи оставил конкретную модель своего ноутбука, а не абстрактный набор букв, не говорящий вообще ни о чем.
Все содержание заметки сводится к тому, что воронка сортирует непонятно какие данные на непонятно каком железе за 195 секунд. А какие-то другие — за 57. А третьи — за 3210.
Как на этом железе работают другие алгоритмы? Неизвестно — автор не удосужился измерить. Как воронка работает на другом железе? Тоже неизвестно — автор не удосужился предоставить референсную реализацию алгоритма или хотя-бы вменяемый исполнительный файл, который можно запустить на какой-либо современной платформе, а не только на музейном экспонате.
Единственное, что можно вынести из статьи — это то, что поведение воронки и правда похоже на O(n * log n). Ну круто, че. Только вот ни разу не удивительно, учитывая, что самым производительным у вас оказался вариант с воронкой глубины 1, который от обычной сортировки слиянием отличается деталями, не влияющими на асимптотику.
Южному полушарию, вроде бы, это ни капельки не мешает…
Да. Потому что мешает не тот факт, что новый год летом, а тот факт, что он будет постепенно "плыть" от зимы к лету.
Но с другой стороны, есть же расписание рассветов и закатов на много лет вперёд. Вот так же будет расписание начала весны, осени и тд.
С этим есть одно большое различие и 2 проблемы.
Различие (которое является причиной первой проблемы). Время рассвета и заката меняется по синусоиде. Оно остается в неких рамках. А с отменой високосных годов — времена года будут постоянно ползти в одну сторону. Никаких рамок не будет.
И проблемы:
1) Кто пользуется расписанием закатов и рассветов? Какому проценту населения вообще интересна информация о точном времени рассвета или заката? Единицам. Остальным более чем достаточно общих рамок, о которых я писал выше. А вот постоянная смена графика времен года в той или иной мере заденет всех людей без исключения.
2) Насколько удобно лично вам было бы каждый вечер сверяться с расписанием рассветов прежде, чем завести будильник на утро? Зачем делать так же неудобно и с временами года?
я бы хотел день своего рождения справлять ровно через год,
У вас 29 февраля день рождения? Если нет, то не понимаю, как у вас может получаться справлять день рождения не ровно через год. И главное — зачем.
А в чем проблема?
В том, что это дико неудобно. Например, придется постоянно корректировать графики огромной кучи различных сезонных мероприятий. Это и даты запуска/отключения централизованного отопления. И графики проведения ремонтных/профилактических работ в системах водоснабжения. Графики ремонта дорог. Графики проведения абсолютно всех аграрных работ. И еще куча всего. Что заденет всех людей без исключения, а не только 0,07% тех, кто родился 29 февраля и других бедолаг, которые хотели бы что-то справлять ровно, а не криво.
Если отменить високосный год, то всего за 120 лет все времена года съедут на целый месяц. А через 500 лет новый год станут отмечать с шашлыками на природе, отмахиваясь от комаров.
при выходе из строя одного все данные потеряются, но ведь и при выходе одного большого ssd будет аналогично
В такой формулировке (когда один диск уже умер) — да. Но вообще ситуации не аналогичные. И в случае 3 дисков вероятность потерять данные заметно выше.
Пусть вероятность отказа диска за неделю — 0.01 (для наглядности). В случае с одним большим накопителем вероятности такими и остаются. Вероятность отказа — 0.01, вероятность безотказной работы — 0.99. В случае же с тремя накопителями вероятность безотказной работы равна лишь 0.99^3 = 0.9703, потому что для безотказной работы рейда необходимо чтобы не отказали все 3 диска. Соответственно, вероятность отказа рейда — 0.0297. Почти в 3 раза выше, чем у однодискового случая (и с уменьшением вероятности отказа одного диска, это соотношение становится все ближе к 3).
Где и когда они позиционировали себя как "противоположность жадным Microsoft и Apple"?
Хотя для начала наверное стоит прояснить, что вы понимаете под жадностью. Если жадность в вашем понимании — это в принципе любая попытка заработать денег, тогда да, RedHat и Canonical — страшные жадины. Но чтобы называть их лицемерами стоит привести хоть один пример, когда они заявляли, что зарабатывание денег не входит в их цели.
Если "жадность" значит для вас что-то другое, то тем более непонятно, в чем лицемерие. Сервисы, на которых зарабатывают RedHat с Canonical, у Майкрософта тоже стоят денег. А Эпл таких сервисов вообще не предоставляет. При этом ОС у них бесплатна (в отличие от достаточно дорогой винды и псевдо-бесплатной макоси, стоимость которой включена в стоимость железа, за пределами которого по условиям лицензии эту макось использовать нельзя). В чем здесь жадность и где здесь лицемерие?
Вы так пишите, будто эти злые огромные корпорации коварно обманули несчастных волонтёров и заработали свои несметные богатства за счет честного труда этих бедолаг.
Во-первых, "волонтёров, вложивших в него своё свободное время" никто не заставлял это делать. Это был их выбор. Им с самого начала никто не обещал "хороших заработков" в награду за то, что они делают (да и вообще хоть каких-либо заработков). Итог закономерен — волонтеры ничего и не заработали. В то же время, злые корпорации изначально ставили себе целью именно зарабатывание денег. И в итоге (сюрприз!) — денег заработали. Обе группы получили то, на что рассчитывали с самого начала. Корпорации — деньги, волонтёры — опыт и чувство причастности к чему-то большему.
Во-вторых, времена, когда силами волонтёров велась значительная часть разработки открытого ПО — давно прошли. Подавляющую часть работы в свободном ПО на сегодняшний день выполняют сотрудники тех самых злых корпораций. Которым эти злые корпорации платят деньги за работу.
В-третьих, "зарабатывают на свободном ПО" корпорации зачастую вовсе не путем прямой продажи кода, написанного бедными волонтёрами (трудно заработать на продаже того, что ты обязан выкладывать в свободный доступ. GPL беспощаден). А путем продажи сопутствующих сервисов, к которым волонтёры не имеют никакого отношения.
Как-то умудрился пропустить момент, что вы это дело еще и в плейграунде пытались запустить. Тогда да, тут еще меньше поводов для удивления. Мало того, что код без оптимизаций собирается, так к нему еще дебаггер приаттачен, через который в риалтайме куча рюшечек в gui красиво мигает и обновляется.
Инструменты стоит использовать по назначению. Плейграунды — не для того, чтобы в них гонять миллионы итераций. А консоль Xcode не для того, чтобы выводить в нее мегабайты текста одной строкой.
я изначально не гнался за эффективностью выполнения
И к чему тогда все эти замеры времени в коде?
демонстрация возможностей Swift. Зато тут вся реализация заключена в трех строчках в цикле while, включая условие выхода.
Если стояла цель показать лаконичность свифта, то стоило нормально структурировать код хотя-бы путем выноса самого алгоритма в отдельную функцию. А в текущем виде — что у вас, что у меня, код — это полу-хаотичная мешанина из ввода-вывода, замеров времени, вспомогательных расширений и собственно самого алгоритма. Лаконичностью это все и не пахнет.
Если же под "возможностями" вы подразумеваете не лаконичность, а функциональные возможности, то выбор решета в качестве примера для демонстрации — очень странный. Какие возможности показаны? Циклы, массивы и замыкания? Исчерпывающая деморнстрация.
Есть спецификация языка. В случае Си — это стандарт ISO/IEC 9899. Все, что не входит в эту спецификацию частью языка не является. Компилятор (и уж тем более его конкретная реализация) туда не входит. Стандартная библиотека входит, но её реализация — не входит.
Кому должен? Поведение puts и printf в данном случае одинаково. printf при этом более универсален в общем случае.
Чем конкретно он хуже puts-а в контексте хеллоуворлда и си как языка?
Еще раз. Тот факт, что вызов printf в данном случае транслируется в вызов puts вызван не языком С, а компилятором gcc (конкретной версии, использованной автором) и glibc версии 2.17. Когда Ричи с Керниганом работали над Си и хеллоуворлдом для него — ни gcc, ни glibc еще и в помине не было.
Нет. В качестве примера первой «самой простой» программы Керниган взял программу, которая выводит одну строку и завершается. Именно это написано в тексте программы и именно это делает программа после компиляции и выполнения. И делает это вполне просто и однозначно с точки зрения программиста, пишущего Hello World.
А то, каким образом она это делает под капотом — к Си как к языку никоим образом не относится. Это детали реализации компилятора, стандартной библиотеки и операционной системы.
А если так сильно хочется попричитать по поводу "слишком сложного и неоднозначного" hello world, то вы идите дальше — жалуйтесь на то, как неоднозначно выполняется код на разных архитектурах процессоров. А какие сложные квантовые эффекты в чипе процессора этот якобы "простой" код вызывает! Жуть! Ужасный пример Керниган взял, слишком уж всё сложно и неоднозначно.
Вот я посчитал заранее хеши двух строк. Как теперь мне определить, какая из них лексикографически меньше?
47bce5c74f589f4867dbd57e9ca9f808
08f8e0260c64418510cefb2b06eee5cd
Картинка с его сайта не соответствует его текущей реализации. Сейчас у него глубина воронки 1. Т.е. пристроить текущий элемент пробуем только к одному списку. Если не получилось, то этот список отправляем в буфер и больше не трогаем. А элемент заносим в новый пустой список и работаем дальше с ним.
От воронок осталось одно название. На деле входной поток просто разбивается на отсортированные подпоследовательности, которые потом сливаются мердж-сортом.
Создаем новый бакет. Это за константу делается.
Не получится, потому что см. пункт 1. Мы не сливаем, мы просто создаем новый бакет
Не n. Мы сравниваем только с одним текущим бакетом. Т.е. по 1-2 сравнения на элемент выходит.
Для худшего случая в конце у нас будет n/2 бакета по 2 элемента.
Слияние тут работает аналогично слиянию в MergeSort. С аналогичной асимптотикой.
Посмотрите предпоследний абзац здесь #comment_20205630
Не совсем. Сравнение только с одним текущим бакетом, а не со всеми. Если к нему пристроить не получается, то текущий отправляется в "буфер", а очередной элемент добавляется в новый пустой бакет.
Изначально — да, гениальная задумка автора была похожей — завести несколько бакетов (не динамически добавлять новые, а статически задавать "глубину воронки") и по ходу чтения пристраивать очередной элемент к концу одного из бакетов. Если ни к одному пристроить не получилось — сливаем 2 самых маленьких и пихаем наш элемент в образовавшийся пустой бакет.
Но в итоге он осознал, что это работает плохо, поэтому в своем сортире реализовал вариант с одним бакетом. Читаем данные, по ходу пристраиваем их к бакету. Если пристроить не вышло — откладываем текущий бакет в "буфер", как он это назвал и продолжаем читать дальше в новый бакет. В конце в "буфере" будет набор отсортированных бакетов, которые он сливает MergeSort-ом.
В конечном варианте, асимптотика аналогична асимптотике MergeSort-а.
Чтение за O(N) т.к. всего у нас N элементов и каждый из них пристраивается за O(1): пристройка к существующему бакету — очевидно, константа (если бакет реализован связным списком как у него). Перенос бакета в "буфер" — тоже константа.
А после этого мы просто оказываемся в ситуации "MergeSort посреди выполнения". Для хороших данных — ближе к концу выполнения. Для плохих — ближе к началу. Но в общем случае для завершения сортировки MergeSort-у потребуется O(N * Log N) времени. Не О(n^2).
Изначально у нас К бакетов. Мы можем их попарно слить друг с другом за О(n). После этого шага у нас количество бакетов уменьшится в 2 раза. Соответственно, всего на слияние всех бакетов в один потребуется Log2 K шагов. Т.е. общая асимптотика слияния будет O(N * Log К), а учитывая, что в худшем случае К = O(N), получаем асимптотику O(N * Log N)
В общем, алгоритм не ужасен. Он правда работает. Местами как MergeSort, местами даже лучше. Ужасен автор) Ну и сам алгоритм, хоть и не ужасен, но и явно не дотягивает до общепринятых на сегодняшний день. А потому применение его не оправдано практически нигде.
Ну не read-only, а 1 коммент в день. Даже с кармой -100 он сможет писать. Но лишь раз в неделю.
Но в любом случае, оно и к лучшему. Кроме агрессивного невежества комментарии автора ничего не содержали (и его заметка на сайте — не исключение). По существу с ним общаться невозможно.
П.С. А кодом он с вами поделился с условием неразглашения? Если нет, то может вы его опубликуете, чтобы была возможность у желающих все таки провести адекватные бенчмарки?
Нет. А вы?
А чего так скромно-то? Давайте сразу на сто. А лучше на тысячу. Главное продолжайте всеми силами избегать замеров времени работы своего сортира и других сортировок в равных условиях. А там уж для "уравнивания" условий можно брать любой коэффициент. Хоть 3, хоть 4, хоть 100500. Предел — лишь ваше воображение!
Это уже все поняли :)
Вторая группа в плане оценки асимптотики среднего случая совершенно бесполезна и не показательна. Но вам (как практику) это понимать не обязательно, так что не берите в голову.
Нет. А вы?
Да, именно это я и написал. В первой заметке вы поняли, что на практике ваша концепция воронок оказалась бесполезной и потому остановились на банальном разбиении входного потока на отсортированные подпоследовательности и дальнейшем слиянии этих подпоследовательностей как в merge sort.
И полученный вариант в плане асимптотики абсолютно аналогичен сортировке слиянием. Такие дела. На практике — да, может быть немного быстрее MergeSort-а для "реальных" данных. На некоторых очень специфичных данных (полностью отсортированный массив) — заметно быстрее. Но в целом по-прежнему хуже общепринятых алгоритмов сортировки, вроде того-же TimSort.
Доказать, что воронка идеальна, уж простите, у вас не получилась. Если сравнить ваши числа с числами из первой статьи (хоть их и нельзя сравнивать, об этом дальше), то окажется, что на случайных данных воронка мощно всасывает по сравнению со всеми алгоритмами из первой статьи, за исключением SmoothSort. На частично отсортированных данных дела получше, но воронка по-прежнему и близко не подходит к тому-же TimSort-у на всех без исключения "степенях" частичной отсортированности. А в отдельных случаях работает медленнее шелла.
Но на самом деле, даже этих выводов сделать из статьи нельзя. Причин много, выбирайте любую:
Все содержание заметки сводится к тому, что воронка сортирует непонятно какие данные на непонятно каком железе за 195 секунд. А какие-то другие — за 57. А третьи — за 3210.
Как на этом железе работают другие алгоритмы? Неизвестно — автор не удосужился измерить. Как воронка работает на другом железе? Тоже неизвестно — автор не удосужился предоставить референсную реализацию алгоритма или хотя-бы вменяемый исполнительный файл, который можно запустить на какой-либо современной платформе, а не только на музейном экспонате.
Единственное, что можно вынести из статьи — это то, что поведение воронки и правда похоже на O(n * log n). Ну круто, че. Только вот ни разу не удивительно, учитывая, что самым производительным у вас оказался вариант с воронкой глубины 1, который от обычной сортировки слиянием отличается деталями, не влияющими на асимптотику.
Они тоже "уже были". Их никто не предлагает добавлять снова. Они уже добавлены.
В начале ветки речь шла в том числе и об этом:
https://habr.com/ru/post/452584/#comment_20174850
Да. Потому что мешает не тот факт, что новый год летом, а тот факт, что он будет постепенно "плыть" от зимы к лету.
С этим есть одно большое различие и 2 проблемы.
Различие (которое является причиной первой проблемы). Время рассвета и заката меняется по синусоиде. Оно остается в неких рамках. А с отменой високосных годов — времена года будут постоянно ползти в одну сторону. Никаких рамок не будет.
И проблемы:
1) Кто пользуется расписанием закатов и рассветов? Какому проценту населения вообще интересна информация о точном времени рассвета или заката? Единицам. Остальным более чем достаточно общих рамок, о которых я писал выше. А вот постоянная смена графика времен года в той или иной мере заденет всех людей без исключения.
2) Насколько удобно лично вам было бы каждый вечер сверяться с расписанием рассветов прежде, чем завести будильник на утро? Зачем делать так же неудобно и с временами года?
У вас 29 февраля день рождения? Если нет, то не понимаю, как у вас может получаться справлять день рождения не ровно через год. И главное — зачем.
В том, что это дико неудобно. Например, придется постоянно корректировать графики огромной кучи различных сезонных мероприятий. Это и даты запуска/отключения централизованного отопления. И графики проведения ремонтных/профилактических работ в системах водоснабжения. Графики ремонта дорог. Графики проведения абсолютно всех аграрных работ. И еще куча всего. Что заденет всех людей без исключения, а не только 0,07% тех, кто родился 29 февраля и других бедолаг, которые хотели бы что-то справлять ровно, а не криво.
Если отменить високосный год, то всего за 120 лет все времена года съедут на целый месяц. А через 500 лет новый год станут отмечать с шашлыками на природе, отмахиваясь от комаров.
В такой формулировке (когда один диск уже умер) — да. Но вообще ситуации не аналогичные. И в случае 3 дисков вероятность потерять данные заметно выше.
Пусть вероятность отказа диска за неделю — 0.01 (для наглядности). В случае с одним большим накопителем вероятности такими и остаются. Вероятность отказа — 0.01, вероятность безотказной работы — 0.99. В случае же с тремя накопителями вероятность безотказной работы равна лишь 0.99^3 = 0.9703, потому что для безотказной работы рейда необходимо чтобы не отказали все 3 диска. Соответственно, вероятность отказа рейда — 0.0297. Почти в 3 раза выше, чем у однодискового случая (и с уменьшением вероятности отказа одного диска, это соотношение становится все ближе к 3).
Хоть убейте, не вижу лицемерия.
Где и когда они позиционировали себя как "противоположность жадным Microsoft и Apple"?
Хотя для начала наверное стоит прояснить, что вы понимаете под жадностью. Если жадность в вашем понимании — это в принципе любая попытка заработать денег, тогда да, RedHat и Canonical — страшные жадины. Но чтобы называть их лицемерами стоит привести хоть один пример, когда они заявляли, что зарабатывание денег не входит в их цели.
Если "жадность" значит для вас что-то другое, то тем более непонятно, в чем лицемерие. Сервисы, на которых зарабатывают RedHat с Canonical, у Майкрософта тоже стоят денег. А Эпл таких сервисов вообще не предоставляет. При этом ОС у них бесплатна (в отличие от достаточно дорогой винды и псевдо-бесплатной макоси, стоимость которой включена в стоимость железа, за пределами которого по условиям лицензии эту макось использовать нельзя). В чем здесь жадность и где здесь лицемерие?
Вы так пишите, будто эти злые огромные корпорации коварно обманули несчастных волонтёров и заработали свои несметные богатства за счет честного труда этих бедолаг.
Во-первых, "волонтёров, вложивших в него своё свободное время" никто не заставлял это делать. Это был их выбор. Им с самого начала никто не обещал "хороших заработков" в награду за то, что они делают (да и вообще хоть каких-либо заработков). Итог закономерен — волонтеры ничего и не заработали. В то же время, злые корпорации изначально ставили себе целью именно зарабатывание денег. И в итоге (сюрприз!) — денег заработали. Обе группы получили то, на что рассчитывали с самого начала. Корпорации — деньги, волонтёры — опыт и чувство причастности к чему-то большему.
Во-вторых, времена, когда силами волонтёров велась значительная часть разработки открытого ПО — давно прошли. Подавляющую часть работы в свободном ПО на сегодняшний день выполняют сотрудники тех самых злых корпораций. Которым эти злые корпорации платят деньги за работу.
В-третьих, "зарабатывают на свободном ПО" корпорации зачастую вовсе не путем прямой продажи кода, написанного бедными волонтёрами (трудно заработать на продаже того, что ты обязан выкладывать в свободный доступ. GPL беспощаден). А путем продажи сопутствующих сервисов, к которым волонтёры не имеют никакого отношения.
Как-то умудрился пропустить момент, что вы это дело еще и в плейграунде пытались запустить. Тогда да, тут еще меньше поводов для удивления. Мало того, что код без оптимизаций собирается, так к нему еще дебаггер приаттачен, через который в риалтайме куча рюшечек в gui красиво мигает и обновляется.
Инструменты стоит использовать по назначению. Плейграунды — не для того, чтобы в них гонять миллионы итераций. А консоль Xcode не для того, чтобы выводить в нее мегабайты текста одной строкой.
И к чему тогда все эти замеры времени в коде?
Если стояла цель показать лаконичность свифта, то стоило нормально структурировать код хотя-бы путем выноса самого алгоритма в отдельную функцию. А в текущем виде — что у вас, что у меня, код — это полу-хаотичная мешанина из ввода-вывода, замеров времени, вспомогательных расширений и собственно самого алгоритма. Лаконичностью это все и не пахнет.
Если же под "возможностями" вы подразумеваете не лаконичность, а функциональные возможности, то выбор решета в качестве примера для демонстрации — очень странный. Какие возможности показаны? Циклы, массивы и замыкания? Исчерпывающая деморнстрация.