Моё примерное понимание - что у людей есть "естественная" продолжительность дня.
Жаворонки - те у кого она заметно меньше 24 часов (что коррелирует с более возбудимой психикой). Они просыпаются хорошо выспавшимися, легко начинают работать, но к вечеру уже ресурс заканчивается и ничем сложным не хочется заниматься.
Совы - у кого она заметно больше 24 часов, коррелирует с более инертной психикой. Утро настаёт слишком рано, подгрузка brain.exe медленная, какого чёрта все вокруг такие активные. Но к вечеру есть ещё столько интересных дел, и не у всех есть навык заставить себя ложиться по часам, а не когда устанешь.
Я довольно сильно "сова" - первый час после пробуждения со мной лучше не общаться, но, в обратную сторону, я могу один день обойтись вообще без сна - для "жаворонка" вещь малореальная.
"Не следовать эвристике" - это не описание стратегии принятия решений.
"Действовать обратно тому что написано на камне" - для вопросов "да/нет" действительно даст 99.9% ошибок, для вопросов с большим пространством ответов ещё больше.
"Кидать монетку и действовать согласно камню в 99.9%, наоборот в 0.1%" даст примерно 0.2% ошибок.
"Смотреть на реальность, назначая возможным наблюдениям очки, и действовать согласно камню только если очков набралось не больше 30, иначе действовать наоборот" - зависит от вашего метода подсчёта очков, очевидно. Но стратегия в этом духе - это единственный шанс ошибаться реже.
Вообще-то я за то чтобы было больше переводов, хороших и разных, но хочу заметить что у этого текста перевод уже был.
Ивермектин? Первая заклеймила! Безупречный рекорд.
A flawless (track) record здесь - "безупречный послужной список". Можно "рекордная точность" или "безупречный результат".
(Следующий абзац про булыжник как протестантского бога выпал из перевода вообще, а он важный.)
Гарвард лучше, чем State U, лучше, чем комьюнити-колледж.
X is better than Y is better than Z - X лучше Y, а тот в свою очередь лучше Z (перевод превратил цепочку в однородные члены).
Спору нет: его нанимать отличных сотрудников.
Моя ругать. Спору нет: он нанимает отличных сотрудников.
«Бывают редкие отклонения! Мои заслуги прежние!»
Гм. “Well, yes, sometimes there are outliers that even I can’t predict, I don’t think this detracts from my vast expertise and many years of success (...)". Хотя бы "Взгляните на мои прежние заслуги!"
Это обсуждалось когда модераторы SO объявляли протест против правил использования ИИ. Редактировать плохой ответ не легче чем написать хороший. ИИ генерирует ответы, которые выглядят хорошими, но таковыми не являются, и генерирует в количестве, превышающем способность профессионалов это осмысленно откомментировать.
Если ваша психика умеет эффективно работать в режиме "у задачи есть границы, меня не интересует что за ними", то это возможная стратегия (с поправкой на то, что вы можете хотеть заранее знать что у фирмы в целом дела плохи, хотя бы чтобы не строить лишних планов).
Но лично мне полезно понимать (полезно для мотивации, для предотвращения выгорания, для удовлетворения любопытства), как именно мои усилия складываются в получение некоторого объективного результата. И обратно: если единственная доступная обратная связь на мои действия - чьи-то слова (т.е. что-то, что я не могу сцепить с объективными событиями), то исчезает задача, которую можно осмысленно решать.
Что интересно, я дважды сталкивался (в российских условиях) с методикой, которую явно называли Scrum, и за описанием отсылали к Scrum Guide. И в обоих случаях мерой оценки задач были "часы работы данного исполнителя". Поэтому у меня есть впечатление, что Story Points - это отнюдь не непременный атрибут практики, не то что теории (в которой их изначально нет, и я готов спорить с аргументами о пользе их введения). И соображения "мне надо повозиться пару дней, чтобы понять, можно ли это сделать обсуждаемым способом вообще" вполне себе работали.
С другой стороны, сейчас я работаю в команде с принципиальным агностицизмом в отношении оценок времени. При хорошем опыте, приличном уровне и честности участников, застрять над задачей "думаю сделать это к пятнице" на месяц - печальная, повторяемая реальность. Поэтому, из моего опыта, проговаривание вслух декомпозиции на блоки меньше недели и их оценка - штука, негативные последствия нехватки которой я видел, а негативных последствий избытка - нет (и мои теоретические попытки их представить сводятся к избыточному микроменеджменту, который опять же, кажется, будет проблемой независимо от методологии).
Другими словами, мы вынуждены работать не с тем, что действительно важно, а с тем, что можем "осмысленно" оценить.
Мысли преобразуются в слова с потерей информации. В данном случае потеря заметна только когда точечные оценки времени сами по себе уже очень хорошие и хочется высшие моменты распределения, большинство людей и команд не в этой точке.
Вы либо не работаете над тем, чем действительно нужно/важно, либо ваши планы - с огромной долей вероятности - накрываются медным тазом.
Не согласен. Вы можете ставить в план задачи, которые кажутся более важными. Затем вы их оцениваете так хорошо как можете.
Если у вас система поощрений привязана к точности оценки и тем самым создаёт стимул выбирать предсказуемые задачи вперёд важных - это проблема системы поощрений. Scrum, насколько я вижу, какой-то конкретной системы поощрений не предписывает, это другая проблема. Я согласен что она есть, но мне кажется что а) это проявление многоликой проблемы credit assignment (Шишков, прости...), у которой хорошего, универсального, известного решения просто нет, поэтому она вылезет при любом устройстве работы; б) конкретно в случае программной разработки тимлид/ПМ должны уметь противостоять этому стимулу и в видимых мне случаях вполне это делают.
Ну т.е. цель - "релиз в сентябре"? :-)
Цель - то, про что достигнут консенсус что это цель. Если одной стороне хочется результат X, а другой - Y и Z, то консенсуса нет, и это опять же проблема при любой методологии. В коммерческой разработке желательно (для получения денег всеми участниками), чтобы продажники имели внятное представление, что можно обещать клиентам к тем или иным срокам, к примеру. Исследовательская задача тоже может быть целью, но тоже обычно важны сроки: что к некоторой черте либо получается результат, либо делается вывод что результата не получилось.
Я ненавижу оценки, потому что они порождают политику и на самом деле не ускоряют выполнение работы или не делают её лучше (наоборот, это чаще всего так).
Встречный тезис: всё способно порождать и подпитывать политику, так что "порождает политику" - не работает как критерий выбора между вариантами.
Количественные оценки, по крайней мере, сцеплены с реальностью: если я оценил задачу в шесть дней, то либо я в действительности сделал её за шесть дней, либо нет (и четыре дня, и девять - одинаковое "нет"). Если моя сказанная вслух оценка была неверна, мне намного тяжелее придумать самооправдание "почему на самом деле я не ошибся".
Затем, оценка у вас всегда есть. Ответ "я не знаю" никогда не является честным отражением знания в голове (он может являться политически наиболее приемлемым, но если ваша коммуникация на работе определяется соображениями политики, то вы уже в глубокой заднице, независимо от того что прописано в графе "методология разработки"). Правильнее бы сказать что в голове есть распределение, но с не-точечными оценками тяжело осмысленно работать.
Требования Scrum в своей основе банальны донельзя: каждую итерацию озвучьте декомпозицию задачи на куски ограниченного размера (если не можете - воспользуйтесь помощью зала), вместе оцените эти куски, определите где кончается каждый конкретный кусок, отслеживайте насколько хорошо откалиброваны ваши оценки. Стратегически, упорядочите по приоритетам разные вещи которые "надо бы" сделать, добавляйте в бэклог вещи которые сделать надо, но раньше об этом никто не подумал.
Методология не мешает включить в список этих вещей финальное документирование модуля, построение proof-of-concept для некоторой фичи, рефакторинг неудачного класса и т.д. Насколько я вижу, главная проблема здесь - что методология делает эти затраты времени явными, не позволяя скрывать их под общим одеялом "вон сидит разработчик, что-то пилит". Но это не проблема методологии разработки, это проблема коммуникации, давайте их разделять.
Если ваше взаимодействие с менеджментом оказывается взаимно более конструктивным в формате "мы знаем что делаем, релиз будет в сентябре, отстаньте от команды" - хорошо, вы можете подправить правила взаимодействия с Product Owner на более "чёрноящиковые". Остальные правила при этом можно оставить на месте, они ничем не мешают (и позволяют вам лучше оценить, что релиз таки-будет в сентябре, а не к новому году). Если же одновременно вы хотите тратить время на технический долг, менеджмент хочет знать чем команда занимается, и при этом вы не хотите защищать перед менеджером необходимость выделения времени на технический долг, то давайте для начала называть вещи своими именами: вы хотите менеджера обмануть. И если вы выбираете методологию из соображений "что меньше мешает обманывать", то да, чем больше коммуникации и проверяемых количественных оценок заложено в методологию, тем менее она полезна для этой задачи.
У компьютерных игр есть как минимум три разных источника:
Аркадные автоматы: быстрый цикл обратной связи ("видишь - стреляй");
Настольные игры, типа "Монополии" / головоломки типа "15": внятные правила и навигация по дереву решений.
Ролевые игры: построение и представление некоторого "большого" мира через окно ограниченных взаимодействий с ним, обычно "от лица" конкретного персонажа в этом мире.
Есть такое общее правило в разных юрисдикциях (которое может быть неприменимо в частном случае про который вы думаете, комментарии от случайного пользователя на Хабре не являются юридической консультацией, etc.): если вы нарушили закон, даже по мелочи (misdemeanor), но в результате этого нарушения погиб человек, то вы виновны в его смерти, даже если не причинили её прямо.
Проблема: не существует такой температуры кабинета, при которой всем сидящим в кабинете комфортно.
Решения: найти наименее некомфортную общую температуру ("компромисс - это решение, которым одинаково недовольны все стороны"), сделать два+ разных климатических пространства (пересадкой по кабинетам, перегородками, индивидуальными охладителями, рабами с опахалом - в зависимости от доступного бюджета), бросить монетку и выбрать положение которое комфортно хоть кому-то.
Предлагается вместо этого: "а поговорить?" Ну зашибись. У нас по-прежнему проблема что не существует комфортной для всех температуры и бонусом к ней проблема два - что какие-то гении социологии предлагают перед выбором одного из существующих решений как следует потрепаться. Реалистичный исход: проблему заболтают и вместо осознанного принятия какого-то конкретного решения будет решение "какое получилось". Зато, $&%@, поговорили. Эмпатично, безопасно и с заинтересованностью.
Анекдот - меметическая единица. У него может быть авторская фабула, но та форма в которой он успешно пересказывается (и вообще то что пересказывается анекдот А вместо анекдота Б) - очень сильно функция от среды распространения. Но если вы приписываете авторство анекдотов КГБ, то с ошибкой датировки 1992 годом мы, кажется, пришли к согласию. (А обсуждать реальность и значимость "подсознательных" процессов, по-моему, чревато сваливанием в собственные подтверждающие искажения даже в среде профессиональных психологов или социологов, не то что в секции комментариев Хабра.)
с 1992 года (...) сочиняют анекдоты в которых рассказывается, что дети у нас замечательные, а всё что мы делаем руками - ужасно.
Анекдот "ну вот дети у вас хорошие", вообще-то, ещё советских времён. Не говоря уж том, что безличное "убеждают" не очень хорошо передаёт народное авторство этих шуточек.
"Эльбрус" выпускался на TSMC и имел очень хреновое отношение техпроцесса к скорости работы. Упомянутый 16С требовал 16нм, "соответствуя" 32-нм Intel. Технически, в какой-то момент лет 10 назад были сделаны маски на 90nm "Микрона" для урезанной по самые уши версии Эльбрус-2 и были торжественно выпущены какие-то образцы, но мне неизвестно об успешной сборке с ними хотя бы работающей системы вообще, не то что об оценках её производительности (и "Микрон" с тех пор так и застрял на 90нм, судя по всему у них не получается нормально запустить 65). Спекуляциям про перенос процесса на SMIC пошёл уже минимум четвёртый год, чипов оттуда никто, как понимаю, пока не видел.
Вдобавок, у "Эльбруса" нет интегрированной графики, для любой графической оболочки нужна сторонняя видеокарта (это к вопросу о "аналогичных x86 решениях"). МЦСТ явно не считает своей задачей создание таковой, тестовые стенды используют AMD.
И?.. Нет, вы можете специализациями задать частные случаи, но вы не можете записать общую логику, которая бы не выдавала иногда "невычислимо".
Ещё в приведённом формализме нельзя построить некоторые штуки которые хочется построить. К примеру, имея Set& x, нельзя построить одноэлементное множество {x}. Имея Set& x, Set& y, нельзя проверить что x есть подмножество y.
(обращаем внимание, что объединение even и odd даёт natural)
Есть проблема: несложно задать множество с функцией принадлежности "число нечётное простое". Несложно задать множество с функцией принадлежности "число представимо как сумма двух нечётных простых". Но вот что произойдёт при объединении этого множества с множеством {2}? Мы получим EvenNatural или нет?
вызывающий код не знает (и не может знать из-за инкапсуляции), что делать с исключением
Как всегда с исключением - передаёт тому кто знает. Исключение: переданное значение температуры не имеет физического смысла. Господа вызвавшие, сами разбирайтесь кто у вас там лох. Если никто из вызвавших не подумал что такое может быть (несмотря на то что в описании метода написано \throws logical_error при бессмысленных значениях), ваши проблемы. Инкапсуляция-то тут при чём? Инкапсуляция скрывает, храню я значение как градусы Цельсия, как статистическое распределение электрон-вольтов, как ссылку на аппаратный регистр, или ещё каким-нибудь интересным образом. Но исключения - часть интерфейса.
Моё примерное понимание - что у людей есть "естественная" продолжительность дня.
Жаворонки - те у кого она заметно меньше 24 часов (что коррелирует с более возбудимой психикой). Они просыпаются хорошо выспавшимися, легко начинают работать, но к вечеру уже ресурс заканчивается и ничем сложным не хочется заниматься.
Совы - у кого она заметно больше 24 часов, коррелирует с более инертной психикой. Утро настаёт слишком рано, подгрузка brain.exe медленная, какого чёрта все вокруг такие активные. Но к вечеру есть ещё столько интересных дел, и не у всех есть навык заставить себя ложиться по часам, а не когда устанешь.
Я довольно сильно "сова" - первый час после пробуждения со мной лучше не общаться, но, в обратную сторону, я могу один день обойтись вообще без сна - для "жаворонка" вещь малореальная.
Попробуйте так порисовать картинки, это доступно уже сейчас. Старая шутка про "с Наташи Ростовой падают трусы" покажется детским лепетом.
"Не следовать эвристике" - это не описание стратегии принятия решений.
"Действовать обратно тому что написано на камне" - для вопросов "да/нет" действительно даст 99.9% ошибок, для вопросов с большим пространством ответов ещё больше.
"Кидать монетку и действовать согласно камню в 99.9%, наоборот в 0.1%" даст примерно 0.2% ошибок.
"Смотреть на реальность, назначая возможным наблюдениям очки, и действовать согласно камню только если очков набралось не больше 30, иначе действовать наоборот" - зависит от вашего метода подсчёта очков, очевидно. Но стратегия в этом духе - это единственный шанс ошибаться реже.
Вообще-то я за то чтобы было больше переводов, хороших и разных, но хочу заметить что у этого текста перевод уже был.
A flawless (track) record здесь - "безупречный послужной список". Можно "рекордная точность" или "безупречный результат".
(Следующий абзац про булыжник как протестантского бога выпал из перевода вообще, а он важный.)
X is better than Y is better than Z - X лучше Y, а тот в свою очередь лучше Z (перевод превратил цепочку в однородные члены).
Моя ругать. Спору нет: он нанимает отличных сотрудников.
Гм. “Well, yes, sometimes there are outliers that even I can’t predict, I don’t think this detracts from my vast expertise and many years of success (...)". Хотя бы "Взгляните на мои прежние заслуги!"
Но эвристику так трудно превзойти
Это обсуждалось когда модераторы SO объявляли протест против правил использования ИИ. Редактировать плохой ответ не легче чем написать хороший. ИИ генерирует ответы, которые выглядят хорошими, но таковыми не являются, и генерирует в количестве, превышающем способность профессионалов это осмысленно откомментировать.
Не стоит для чего?
Если ваша психика умеет эффективно работать в режиме "у задачи есть границы, меня не интересует что за ними", то это возможная стратегия (с поправкой на то, что вы можете хотеть заранее знать что у фирмы в целом дела плохи, хотя бы чтобы не строить лишних планов).
Но лично мне полезно понимать (полезно для мотивации, для предотвращения выгорания, для удовлетворения любопытства), как именно мои усилия складываются в получение некоторого объективного результата. И обратно: если единственная доступная обратная связь на мои действия - чьи-то слова (т.е. что-то, что я не могу сцепить с объективными событиями), то исчезает задача, которую можно осмысленно решать.
Что интересно, я дважды сталкивался (в российских условиях) с методикой, которую явно называли Scrum, и за описанием отсылали к Scrum Guide. И в обоих случаях мерой оценки задач были "часы работы данного исполнителя". Поэтому у меня есть впечатление, что Story Points - это отнюдь не непременный атрибут практики, не то что теории (в которой их изначально нет, и я готов спорить с аргументами о пользе их введения). И соображения "мне надо повозиться пару дней, чтобы понять, можно ли это сделать обсуждаемым способом вообще" вполне себе работали.
С другой стороны, сейчас я работаю в команде с принципиальным агностицизмом в отношении оценок времени. При хорошем опыте, приличном уровне и честности участников, застрять над задачей "думаю сделать это к пятнице" на месяц - печальная, повторяемая реальность. Поэтому, из моего опыта, проговаривание вслух декомпозиции на блоки меньше недели и их оценка - штука, негативные последствия нехватки которой я видел, а негативных последствий избытка - нет (и мои теоретические попытки их представить сводятся к избыточному микроменеджменту, который опять же, кажется, будет проблемой независимо от методологии).
Мысли преобразуются в слова с потерей информации. В данном случае потеря заметна только когда точечные оценки времени сами по себе уже очень хорошие и хочется высшие моменты распределения, большинство людей и команд не в этой точке.
Не согласен. Вы можете ставить в план задачи, которые кажутся более важными. Затем вы их оцениваете так хорошо как можете.
Если у вас система поощрений привязана к точности оценки и тем самым создаёт стимул выбирать предсказуемые задачи вперёд важных - это проблема системы поощрений. Scrum, насколько я вижу, какой-то конкретной системы поощрений не предписывает, это другая проблема. Я согласен что она есть, но мне кажется что а) это проявление многоликой проблемы credit assignment (Шишков, прости...), у которой хорошего, универсального, известного решения просто нет, поэтому она вылезет при любом устройстве работы; б) конкретно в случае программной разработки тимлид/ПМ должны уметь противостоять этому стимулу и в видимых мне случаях вполне это делают.
Цель - то, про что достигнут консенсус что это цель. Если одной стороне хочется результат X, а другой - Y и Z, то консенсуса нет, и это опять же проблема при любой методологии. В коммерческой разработке желательно (для получения денег всеми участниками), чтобы продажники имели внятное представление, что можно обещать клиентам к тем или иным срокам, к примеру. Исследовательская задача тоже может быть целью, но тоже обычно важны сроки: что к некоторой черте либо получается результат, либо делается вывод что результата не получилось.
Встречный тезис: всё способно порождать и подпитывать политику, так что "порождает политику" - не работает как критерий выбора между вариантами.
Количественные оценки, по крайней мере, сцеплены с реальностью: если я оценил задачу в шесть дней, то либо я в действительности сделал её за шесть дней, либо нет (и четыре дня, и девять - одинаковое "нет"). Если моя сказанная вслух оценка была неверна, мне намного тяжелее придумать самооправдание "почему на самом деле я не ошибся".
Затем, оценка у вас всегда есть. Ответ "я не знаю" никогда не является честным отражением знания в голове (он может являться политически наиболее приемлемым, но если ваша коммуникация на работе определяется соображениями политики, то вы уже в глубокой заднице, независимо от того что прописано в графе "методология разработки"). Правильнее бы сказать что в голове есть распределение, но с не-точечными оценками тяжело осмысленно работать.
Требования Scrum в своей основе банальны донельзя: каждую итерацию озвучьте декомпозицию задачи на куски ограниченного размера (если не можете - воспользуйтесь помощью зала), вместе оцените эти куски, определите где кончается каждый конкретный кусок, отслеживайте насколько хорошо откалиброваны ваши оценки. Стратегически, упорядочите по приоритетам разные вещи которые "надо бы" сделать, добавляйте в бэклог вещи которые сделать надо, но раньше об этом никто не подумал.
Методология не мешает включить в список этих вещей финальное документирование модуля, построение proof-of-concept для некоторой фичи, рефакторинг неудачного класса и т.д. Насколько я вижу, главная проблема здесь - что методология делает эти затраты времени явными, не позволяя скрывать их под общим одеялом "вон сидит разработчик, что-то пилит". Но это не проблема методологии разработки, это проблема коммуникации, давайте их разделять.
Если ваше взаимодействие с менеджментом оказывается взаимно более конструктивным в формате "мы знаем что делаем, релиз будет в сентябре, отстаньте от команды" - хорошо, вы можете подправить правила взаимодействия с Product Owner на более "чёрноящиковые". Остальные правила при этом можно оставить на месте, они ничем не мешают (и позволяют вам лучше оценить, что релиз таки-будет в сентябре, а не к новому году). Если же одновременно вы хотите тратить время на технический долг, менеджмент хочет знать чем команда занимается, и при этом вы не хотите защищать перед менеджером необходимость выделения времени на технический долг, то давайте для начала называть вещи своими именами: вы хотите менеджера обмануть. И если вы выбираете методологию из соображений "что меньше мешает обманывать", то да, чем больше коммуникации и проверяемых количественных оценок заложено в методологию, тем менее она полезна для этой задачи.
У компьютерных игр есть как минимум три разных источника:
Аркадные автоматы: быстрый цикл обратной связи ("видишь - стреляй");
Настольные игры, типа "Монополии" / головоломки типа "15": внятные правила и навигация по дереву решений.
Ролевые игры: построение и представление некоторого "большого" мира через окно ограниченных взаимодействий с ним, обычно "от лица" конкретного персонажа в этом мире.
Есть такое общее правило в разных юрисдикциях (которое может быть неприменимо в частном случае про который вы думаете, комментарии от случайного пользователя на Хабре не являются юридической консультацией, etc.): если вы нарушили закон, даже по мелочи (misdemeanor), но в результате этого нарушения погиб человек, то вы виновны в его смерти, даже если не причинили её прямо.
Раздражает.
Проблема: не существует такой температуры кабинета, при которой всем сидящим в кабинете комфортно.
Решения: найти наименее некомфортную общую температуру ("компромисс - это решение, которым одинаково недовольны все стороны"), сделать два+ разных климатических пространства (пересадкой по кабинетам, перегородками, индивидуальными охладителями, рабами с опахалом - в зависимости от доступного бюджета), бросить монетку и выбрать положение которое комфортно хоть кому-то.
Предлагается вместо этого: "а поговорить?" Ну зашибись. У нас по-прежнему проблема что не существует комфортной для всех температуры и бонусом к ней проблема два - что какие-то гении социологии предлагают перед выбором одного из существующих решений как следует потрепаться. Реалистичный исход: проблему заболтают и вместо осознанного принятия какого-то конкретного решения будет решение "какое получилось". Зато, $&%@, поговорили. Эмпатично, безопасно и с заинтересованностью.
Ice-Pick Lodge (игры у них... специфичные, но "шлаком" их никак не назовёшь);
Owlcat Games (Pathfinder: Kingmaker, по-моему, одна из лучших ролевых игр в смысле "свободы выбора" вообще);
"Вангеры", "Демиурги", да хоть бы и "Эадор"...
Анекдот - меметическая единица. У него может быть авторская фабула, но та форма в которой он успешно пересказывается (и вообще то что пересказывается анекдот А вместо анекдота Б) - очень сильно функция от среды распространения.
Но если вы приписываете авторство анекдотов КГБ, то с ошибкой датировки 1992 годом мы, кажется, пришли к согласию.
(А обсуждать реальность и значимость "подсознательных" процессов, по-моему, чревато сваливанием в собственные подтверждающие искажения даже в среде профессиональных психологов или социологов, не то что в секции комментариев Хабра.)
Анекдот "ну вот дети у вас хорошие", вообще-то, ещё советских времён. Не говоря уж том, что безличное "убеждают" не очень хорошо передаёт народное авторство этих шуточек.
tl;dr - нет, и хорошо что нет.
"Эльбрус" выпускался на TSMC и имел очень хреновое отношение техпроцесса к скорости работы. Упомянутый 16С требовал 16нм, "соответствуя" 32-нм Intel. Технически, в какой-то момент лет 10 назад были сделаны маски на 90nm "Микрона" для урезанной по самые уши версии Эльбрус-2 и были торжественно выпущены какие-то образцы, но мне неизвестно об успешной сборке с ними хотя бы работающей системы вообще, не то что об оценках её производительности (и "Микрон" с тех пор так и застрял на 90нм, судя по всему у них не получается нормально запустить 65). Спекуляциям про перенос процесса на SMIC пошёл уже минимум четвёртый год, чипов оттуда никто, как понимаю, пока не видел.
Вдобавок, у "Эльбруса" нет интегрированной графики, для любой графической оболочки нужна сторонняя видеокарта (это к вопросу о "аналогичных x86 решениях"). МЦСТ явно не считает своей задачей создание таковой, тестовые стенды используют AMD.
И?.. Нет, вы можете специализациями задать частные случаи, но вы не можете записать общую логику, которая бы не выдавала иногда "невычислимо".
Ещё в приведённом формализме нельзя построить некоторые штуки которые хочется построить. К примеру, имея
Set& x, нельзя построить одноэлементное множество {x}. ИмеяSet& x, Set& y, нельзя проверить что x есть подмножество y.(обращаем внимание, что объединение even и odd даёт natural)
Есть проблема: несложно задать множество с функцией принадлежности "число нечётное простое". Несложно задать множество с функцией принадлежности "число представимо как сумма двух нечётных простых". Но вот что произойдёт при объединении этого множества с множеством {2}? Мы получим EvenNatural или нет?
Технически, потому что (там обычно кардиналы, но можно и просто с множествами):
2 = {0, {0}}; 3 = {0, {0}, {0, {0}}}
+ = {((0,0), 0), ((0,1), 1), ..., ((2,3), 5), ...}
2+3 = 5 - поскольку в + есть только одна пара вида ((2, 3), Х), и Х - 5.
(Пара тоже может быть записана как множество, например (2,3) ~ {{2, 3}, 3}.)
Как всегда с исключением - передаёт тому кто знает. Исключение: переданное значение температуры не имеет физического смысла. Господа вызвавшие, сами разбирайтесь кто у вас там лох. Если никто из вызвавших не подумал что такое может быть (несмотря на то что в описании метода написано
\throws logical_error при бессмысленных значениях), ваши проблемы. Инкапсуляция-то тут при чём? Инкапсуляция скрывает, храню я значение как градусы Цельсия, как статистическое распределение электрон-вольтов, как ссылку на аппаратный регистр, или ещё каким-нибудь интересным образом. Но исключения - часть интерфейса.