Перевести проект в закрытый коммерческий можно только либо если в проекте один единственный контрибьютор, либо если первоначальная лицензия проекта такое допускала.
Это становится частью стандарта языка. А значит требует поддержки (усложнит добавление нового функционала в связанном коде) и усложняет альтернативные реализации Python.
Что-то вспомнилась история про врача ЭКО, который использовал свои собственные "образцы" для оплодотворения и наделал себе с десяток детей. И таких историй — далеко не одна.
Во-первых, он использовал не самую лучшую технологию модификации из числа доступных.
Во-вторых, он убедил родителей ребенка, что будет отредактировано только то, что нужно, при том, что было заранее известно, что используемая технология часто даёт много побочных мутаций. Фактически — обманул. Замечу, что в итоге как минимум у одного из двух детей не было отредактировано то, что нужно, но есть признаки того, что у обоих детей были побочные мутации. Также важно, что даже если бы модификация сработала идеально, то скорее всего заявленная родителям ребенка цель (полная защита от ВИЧ) не была бы достигнута.
В-третьих, вам не кажется преступным использовать на людях технологию, которая еще не до конца обкатана в экспериментов на животных? Животинку в случае каких-то патологий и ликвидировать можно. А с ребенком что? "Извините, мы в результате незапланированной модификации в геноме вашего ребенка создали мутацию, которая сделает его инвалидом к 40 годам — давайте его сейчас убьем, чтобы эта мутация не пошла дальше в популяцию". Так что ли?
Ну и, в-четвертых, представьте себе ситуацию, когда ученые дружно и полностью перестают думать о морально-этических соображениях (и о вопросах безопасности для общества) и начинают делать абсолютно всё, что захочется. Что раньше случится: куча новых генетических заболеваний, новые искусственные болезни или катастрофы вроде Чернобыля? Вы точно хотите узнать?
Теория интересная, но, по сути, никак к парадоксу Ферми не относится. Ведь в парадоксе Ферми по сути рассматривается то, что попало в наш "световой конус", а раз мы существуем (еще), значит в пределах нашего светового конуса коллапса ложного вакуума не происходило. А раз не происходило, значит и на прочие факторы влияния нет. То есть теория фактически полностью "перпендикулярна" тому факту, что мы не наблюдаем другие цивилизации.
Допустим, что конкретно для JS есть вот эта lerna, описываемая в статье. И которая требует, чтобы структура репозитория была перекроена под нее. А что с бэкэндом делать? Отдельный репозиторий? Но ведь это не монорепозиторий тогда.
Как насчет многократного разбухания очереди тестов на CI? Пока были отдельные репозитории — при коммите в проект гонялись только тесты этого проекта. С монорепозиторием — каждый коммит по-умолчанию будет запускать тесты всех-всех проектов.
Математикам и физикам не нужны именно двоичные расчеты. Им нужны либо приближенные расчеты, либо точные.
Для приближенных расчетов им нужно, чтобы в вычисления вносилось как можно меньше ошибок связанных с техническим исполнением этих вычислений. Будет там двоичная арифметика или нет "под капотом" — им всё равно.
Для точных же вычислений нужно, чтобы при невозможности точного представления числа система явном образом сообщала об этом либо чтобы вообще не допускала ситуацию, когда потеря точности возможна. Но эта задача к обсуждаемой к теме не относится.
Конкретно двоичная арифметика нужна, например, в криптографии. Но в первую очередь потому как современная криптография вся построена вокруг двоичной аппаратной базы. Да и требуется там обычно только целочисленная арифметика. Опять мимо.
Как только оказывается, что fixed point вам не подходит (так как в одном типе могут быть и очень большие и очень маленькие значения), то сразу появляется необходимость постоянно контролировать положение точки, следить за переполнением и т.д. В конечном счете получаете в том или ином виде эмуляцию десятичной арифметики с плавающей запятой.
Пример проблемной ситуации: вам хочется в одном типе данных хранить суммы в Биткоинах (в том числе очень маленькие значения, 0.00000001 и меньше) и в Зимбабвийских долларах (очень большие значения, триллиарды и больше). Fixed point с целым числом вам не подойдет — ему не хватит значащих цифр (19 десятичных значащих цифр в эквиваленте для int64).
Все финансовые расчеты, весь бухгалтерский учет по-хорошему должен делаться в десятичной арифметике с использованием правил десятичного округления, а не двоичного. Сейчас ради этого при выполнении финансовых расчетов идут на всяческие ухищрения (используют высокоуровневые эмуляции того или иного рода).
Вообще говоря, двоичные вычисления как раз почти никому не нужны. Просто в подавляющем большинстве задач детали округления и количество значащих цифр в результате не очень существенны, поэтому особой разницы в том, была ли использована двоичная или десятичная арифметика нет и поэтому все привыкли относиться к двоичным вычислениям, которые нам обычно предлагают по-умолчанию, как к чему-то самом собой разумеющемуся или даже "единственно правильному".
ведь и диапазон значений очень сильно урезается
Нет, не сильно. IEE 754 decimal64 хранит каждые 3 десятичных разряда в блоках размером 10 бит. 10^3=1000, 2^10=1024, т. е. потеря тут небольшая. См. вики.
только вот IEE 754 реализован в железе практически везде
Чуть-чуть повздыхаю: в железе практически везде реализована часть IEE 754, а именно бинарные типы. Что же касается таких типов как decimal32, decimal64, decimal128, то они реализованы в относительно экзотических процессорах (POWER и RISC-V). Так что сейчас если хочется честной десятичной арифметики, то приходится так или иначе прибегать к эмуляции. Несмотря на то, что в IEE 754 нужные типы как бы есть.
Во-первых, в докладе может и есть, но в статье выше про это ни слова.
Во-вторых, вполне может быть (и даже скорее всего), что раскрытие HTTPS идет именно по схеме, которую я описал выше, а со стороны СОРМ-а у провайдеров и операторов мобильной связи подтягивается информация типа номера телефона, IMEI, привязанное ФИО и т.д. Т.е. СОРМ присутствует и у провайдеров, и в дата-центрах.
Еще вариант проще: на входе в сеть mail.ru (и ICQ) стоят балансировщики (вероятно аппаратные), которые и оборачивают трафик в HTTPS для клиентов; внутри же сети ходит нешифрованный HTTP-трафик. СОРМ работает внутри сети и видит уже расшифрованный трафик. Никаких ключей при этом СОРМу не нужно.
Вы передали в функцию первым аргументом экземпляр класса, т.е. явно ей сказали: вот тебе объект, работай с ним. Где здесь как-то используется знание функции о том, что она относится к какому-то классу?
Перевести проект в закрытый коммерческий можно только либо если в проекте один единственный контрибьютор, либо если первоначальная лицензия проекта такое допускала.
Это становится частью стандарта языка. А значит требует поддержки (усложнит добавление нового функционала в связанном коде) и усложняет альтернативные реализации Python.
Что-то вспомнилась история про врача ЭКО, который использовал свои собственные "образцы" для оплодотворения и наделал себе с десяток детей. И таких историй — далеко не одна.
Во-первых, он использовал не самую лучшую технологию модификации из числа доступных.
Во-вторых, он убедил родителей ребенка, что будет отредактировано только то, что нужно, при том, что было заранее известно, что используемая технология часто даёт много побочных мутаций. Фактически — обманул. Замечу, что в итоге как минимум у одного из двух детей не было отредактировано то, что нужно, но есть признаки того, что у обоих детей были побочные мутации. Также важно, что даже если бы модификация сработала идеально, то скорее всего заявленная родителям ребенка цель (полная защита от ВИЧ) не была бы достигнута.
В-третьих, вам не кажется преступным использовать на людях технологию, которая еще не до конца обкатана в экспериментов на животных? Животинку в случае каких-то патологий и ликвидировать можно. А с ребенком что? "Извините, мы в результате незапланированной модификации в геноме вашего ребенка создали мутацию, которая сделает его инвалидом к 40 годам — давайте его сейчас убьем, чтобы эта мутация не пошла дальше в популяцию". Так что ли?
Ну и, в-четвертых, представьте себе ситуацию, когда ученые дружно и полностью перестают думать о морально-этических соображениях (и о вопросах безопасности для общества) и начинают делать абсолютно всё, что захочется. Что раньше случится: куча новых генетических заболеваний, новые искусственные болезни или катастрофы вроде Чернобыля? Вы точно хотите узнать?
Веб-сервера собирают, Nginx-ы там всякие :)
А когда это Ли Седоль стал "чемпионом мира по го"?
Теория интересная, но, по сути, никак к парадоксу Ферми не относится. Ведь в парадоксе Ферми по сути рассматривается то, что попало в наш "световой конус", а раз мы существуем (еще), значит в пределах нашего светового конуса коллапса ложного вакуума не происходило. А раз не происходило, значит и на прочие факторы влияния нет. То есть теория фактически полностью "перпендикулярна" тому факту, что мы не наблюдаем другие цивилизации.
Какие билд системы уже так умеют?
Допустим, что конкретно для JS есть вот эта lerna, описываемая в статье. И которая требует, чтобы структура репозитория была перекроена под нее. А что с бэкэндом делать? Отдельный репозиторий? Но ведь это не монорепозиторий тогда.
Как насчет многократного разбухания очереди тестов на CI? Пока были отдельные репозитории — при коммите в проект гонялись только тесты этого проекта. С монорепозиторием — каждый коммит по-умолчанию будет запускать тесты всех-всех проектов.
"дебажный" → "отладочный"
Я бы не сказал, что 11 лет — это "новый формат". У тех же Intel и AMD за это время сменилось не одно поколение процессоров.
Математикам и физикам не нужны именно двоичные расчеты. Им нужны либо приближенные расчеты, либо точные.
Для приближенных расчетов им нужно, чтобы в вычисления вносилось как можно меньше ошибок связанных с техническим исполнением этих вычислений. Будет там двоичная арифметика или нет "под капотом" — им всё равно.
Для точных же вычислений нужно, чтобы при невозможности точного представления числа система явном образом сообщала об этом либо чтобы вообще не допускала ситуацию, когда потеря точности возможна. Но эта задача к обсуждаемой к теме не относится.
Конкретно двоичная арифметика нужна, например, в криптографии. Но в первую очередь потому как современная криптография вся построена вокруг двоичной аппаратной базы. Да и требуется там обычно только целочисленная арифметика. Опять мимо.
Как только оказывается, что fixed point вам не подходит (так как в одном типе могут быть и очень большие и очень маленькие значения), то сразу появляется необходимость постоянно контролировать положение точки, следить за переполнением и т.д. В конечном счете получаете в том или ином виде эмуляцию десятичной арифметики с плавающей запятой.
Пример проблемной ситуации: вам хочется в одном типе данных хранить суммы в Биткоинах (в том числе очень маленькие значения, 0.00000001 и меньше) и в Зимбабвийских долларах (очень большие значения, триллиарды и больше). Fixed point с целым числом вам не подойдет — ему не хватит значащих цифр (19 десятичных значащих цифр в эквиваленте для int64).
Все финансовые расчеты, весь бухгалтерский учет по-хорошему должен делаться в десятичной арифметике с использованием правил десятичного округления, а не двоичного. Сейчас ради этого при выполнении финансовых расчетов идут на всяческие ухищрения (используют высокоуровневые эмуляции того или иного рода).
Вообще говоря, двоичные вычисления как раз почти никому не нужны. Просто в подавляющем большинстве задач детали округления и количество значащих цифр в результате не очень существенны, поэтому особой разницы в том, была ли использована двоичная или десятичная арифметика нет и поэтому все привыкли относиться к двоичным вычислениям, которые нам обычно предлагают по-умолчанию, как к чему-то самом собой разумеющемуся или даже "единственно правильному".
Нет, не сильно. IEE 754 decimal64 хранит каждые 3 десятичных разряда в блоках размером 10 бит. 10^3=1000, 2^10=1024, т. е. потеря тут небольшая. См. вики.
Во-вторых, вполне может быть (и даже скорее всего), что раскрытие HTTPS идет именно по схеме, которую я описал выше, а со стороны СОРМ-а у провайдеров и операторов мобильной связи подтягивается информация типа номера телефона, IMEI, привязанное ФИО и т.д. Т.е. СОРМ присутствует и у провайдеров, и в дата-центрах.