Думаю, это будет ядро Windows в конечном итоге (или что-то около того места). На Расте, да. Но это мое персональное мнение диванного аналитика, основанное на наблюдениях, куда дует ветер.
Насчет Linux - Линус сказал (с плохо скрываемым ужасом в голосе), что на Расте сам не пишет и не планирует. Что фигово. (Но хорошо хоть, что ревьюит коммиты на Расте, и что Интернетом пользуется, а не как некоторые, которым «доклады в папках приносят».)
„Новая научная истина торжествует не потому, что ее противники признают свою неправоту, просто ее оппоненты со временем вымирают, а подрастающее поколение знакомо с нею с самого начала.“
Это очень крутые цифры. Можно ТТХ вашей конфигурации и чуть больше деталей? Скорость дорожки например, насколько удобно печатать, смотреть в монитор и т.д.
тригонометрические функции на разных архитектурах процессора, операционных системах и языках программирования могут давать разный ответ
А вот это полный беспредел. Для того и придумывали стандарт IEEE на числа с плавающей точкой (single, double), чтобы результат на разных архитектурах совпадал побитово. Как это может быть, что он различается для синуса?
постулируется, что 1 коммит = 1 PR (т.е. веток как таковых нет, есть просто стек коммитов поверх мастера, и можно редактировать незамердженные еще коммиты-PRы прямо в середине)
код вмердживается в мастер как можно скорее, мелкими порциями
незавершенные (при этом проходящие CI) вещи тоже вмердживаются, но покрываются if-ом с feature-флагом (т.е. они невидимы пользователю)
Эту схему используют некоторые компании в FAANG, она на мой взгляд крайне экономит время, особенно когда кода пишется много, и разработчиков тоже много. Я полгода назад написал утилиту, которой мы пользуемся в компании, она поддерживает бесшовную интеграцию stacked PRs с GitHub (но пока не анонсировал): https://github.com/dimikot/git-grok
Perl5 и так был чересчур замороченный язык по синтаксису. Непонятно, зачем они еще больше ситуацию усугубили. (Правда, у Perl5 есть до сих пор и преимущество - он по дефолту установлен везде, и он везде одинаковый.)
Товарищ переводчик, исправьте какашку в цитате, пожалуйста. Оригинал:
“We have to make changes. We always said that we didn’t want AGI to be controlled by a small set of people, we want it to be democratized. And we clearly got that wrong. So I think if we don't improve our governance structure, if we don’t improve the way we interact with the world, people shouldn’t [trust OpenAI]. But we’re very motivated to improve that.”
Процессор же называется 80386, а не 386. Всегда, кстати, было любопытно, что эти «80» в начале обозначают, и почему их в каждом новом процессоре оставляли.
Вот сколько читаю про «вирусность» async-функций (ну т.е. что, однажды сконвертив одну, приходится всех ее вызывальщиков тоже конвертить), каждый раз удивяюсь, что на практике этой проблемы почему-то нет. Ну не возникает такой сложности и все. Да, иногда надо конвертить несколько функций, но оно как-то легко происходит все время и с небольшими изменениями в коде даже.
Наверное, это потому, что async - в основном про IO, а IO с самого начала в код попадает, и не бывает так (ну почти), чтобы функция была не-IO и вдруг стала IO.
Не получается. O(1) означает, что существует такое константное k, что алгоритм заканчивается за k шагов для всех размеров входа. Целых чисел фиксированное количество (2^32 штук например), а значит, такое k существует.
Если кажется ну совсем сюром, тогда вот другой (на этот раз вполне себе практический, даже по памяти приемлемый): алгоритм сортировки «за O(n)», если диапазон чисел не очень велик и все числа в массиве уникальны (на самом-то деле он тоже O(1), ну да назовем это «похожим на O(n)»). Например, если у нас есть не более 1000 уникальных элементов в диапазоне 0..999, можно их отсортировать за ~2000 шагов: берем зануленную битовую карту на 1000 битов (это всего-то 125 байтов), дальше идем по входному массиву и взводим в 1 бит, соответствующий очередному числу. В конце проходим по битовой карте и выплевываем в качестве результата позиции тех битов, где 1 (тут огромный простор для оптимизаций: можно проскакивать те 8-байтовые группы, где все нули например). Похожий алгоритм широко используется в СУБД.
Обычно люди удивляются и не верят, когда им говоришь, что для целых чисел (int32 например) вычислительная сложность сортировки - это O(1). Но так и есть. По памяти она, правда, хромает, но зато честный научный O(1).
Ни в коей степени не критикуя, но лишь любопытства из, вопрос к тем, кто пишет на Flutter каждый день: что там за история с Dart, в чем сакральный смысл отдельного языка для этого фреймворка? Наверное, он дает какие-то преимущества или специфический для области синтаксический сахар? Может быть, еще что-то? Если сравнивать с другими языками типа TypeScript или Kotlin.
Слово «байт» также немного дискредитировано тем, что в разных языках он то signed, то unsigned; короче, нет акцента на логической равноправности всех битов. А у слово «октет» такой проблемы нет.
Да, 20 лет назад так и думали. Эксперименты и исследования этого не подтверждают, запасаются в жир что быстрые, что медленные углеводы одинаково (одинаково плохо кстати, даже поразительно плохо).
Но: от быстрых углеводов уровень глюкозы в крови быстро повышается, а потом так же быстро снижается. И вот градиент снижения глюкозы ощущается человеком, как голод. В этом коварство: энергия пришла, а есть снова хочется уже через 15 минут, и человек ест еще, и еще, и еще, не может остановиться. Тут как с бросившими курить, которые сразу жиреют: раньше они тянули в рот сигарету в поисках быстрого удовольствия, а теперь тянут в рот, что пожрать. (Диабетиков здесь не рассматриваем.)
Брюс Ли называл это «пустыми калориями». В идеале на долгосроке и в основе рациона есть хорошо такую пищу, которая при минимальной энергетической плотности максимизирует чувство сытости и время сытости, при этом не проигрывая существенно по вкусу, в идеале вообще не проигрывая (спойлер: из качественных источников энергии - это вареная картошка, а из остального - также все, что имеет повышенный объем).
Думаю, это будет ядро Windows в конечном итоге (или что-то около того места). На Расте, да. Но это мое персональное мнение диванного аналитика, основанное на наблюдениях, куда дует ветер.
Насчет Linux - Линус сказал (с плохо скрываемым ужасом в голосе), что на Расте сам не пишет и не планирует. Что фигово. (Но хорошо хоть, что ревьюит коммиты на Расте, и что Интернетом пользуется, а не как некоторые, которым «доклады в папках приносят».)
Я просто оставлю это здесь.
„Новая научная истина торжествует не потому, что ее противники признают свою неправоту, просто ее оппоненты со временем вымирают, а подрастающее поколение знакомо с нею с самого начала.“
— Макс Планк [про ЯВУ для ЭВМ Rust, 1920]
Это очень крутые цифры. Можно ТТХ вашей конфигурации и чуть больше деталей? Скорость дорожки например, насколько удобно печатать, смотреть в монитор и т.д.
А вот это полный беспредел. Для того и придумывали стандарт IEEE на числа с плавающей точкой (single, double), чтобы результат на разных архитектурах совпадал побитово. Как это может быть, что он различается для синуса?
Нет, BF - это почти что классическая машина Тьюринга. Только со скобочками.
Есть еще один workflow, называется “stacked PRs”:
постулируется, что 1 коммит = 1 PR (т.е. веток как таковых нет, есть просто стек коммитов поверх мастера, и можно редактировать незамердженные еще коммиты-PRы прямо в середине)
код вмердживается в мастер как можно скорее, мелкими порциями
незавершенные (при этом проходящие CI) вещи тоже вмердживаются, но покрываются if-ом с feature-флагом (т.е. они невидимы пользователю)
Эту схему используют некоторые компании в FAANG, она на мой взгляд крайне экономит время, особенно когда кода пишется много, и разработчиков тоже много. Я полгода назад написал утилиту, которой мы пользуемся в компании, она поддерживает бесшовную интеграцию stacked PRs с GitHub (но пока не анонсировал): https://github.com/dimikot/git-grok
Perl5 и так был чересчур замороченный язык по синтаксису. Непонятно, зачем они еще больше ситуацию усугубили. (Правда, у Perl5 есть до сих пор и преимущество - он по дефолту установлен везде, и он везде одинаковый.)
Этот комментарий заслуживает того, чтобы добавить его текст в начало статьи.
Видео по перекликающейся теме на очень базовом уровне (от Andrej Karpathy), Intro to LLM: https://youtu.be/zjkBMFhNj_g
Товарищ переводчик, исправьте какашку в цитате, пожалуйста. Оригинал:
“We have to make changes. We always said that we didn’t want AGI to be controlled by a small set of people, we want it to be democratized. And we clearly got that wrong. So I think if we don't improve our governance structure, if we don’t improve the way we interact with the world, people shouldn’t [trust OpenAI]. But we’re very motivated to improve that.”
Процессор же называется 80386, а не 386. Всегда, кстати, было любопытно, что эти «80» в начале обозначают, и почему их в каждом новом процессоре оставляли.
Вот сколько читаю про «вирусность» async-функций (ну т.е. что, однажды сконвертив одну, приходится всех ее вызывальщиков тоже конвертить), каждый раз удивяюсь, что на практике этой проблемы почему-то нет. Ну не возникает такой сложности и все. Да, иногда надо конвертить несколько функций, но оно как-то легко происходит все время и с небольшими изменениями в коде даже.
Наверное, это потому, что async - в основном про IO, а IO с самого начала в код попадает, и не бывает так (ну почти), чтобы функция была не-IO и вдруг стала IO.
Не получается. O(1) означает, что существует такое константное k, что алгоритм заканчивается за k шагов для всех размеров входа. Целых чисел фиксированное количество (2^32 штук например), а значит, такое k существует.
Если кажется ну совсем сюром, тогда вот другой (на этот раз вполне себе практический, даже по памяти приемлемый): алгоритм сортировки «за O(n)», если диапазон чисел не очень велик и все числа в массиве уникальны (на самом-то деле он тоже O(1), ну да назовем это «похожим на O(n)»). Например, если у нас есть не более 1000 уникальных элементов в диапазоне 0..999, можно их отсортировать за ~2000 шагов: берем зануленную битовую карту на 1000 битов (это всего-то 125 байтов), дальше идем по входному массиву и взводим в 1 бит, соответствующий очередному числу. В конце проходим по битовой карте и выплевываем в качестве результата позиции тех битов, где 1 (тут огромный простор для оптимизаций: можно проскакивать те 8-байтовые группы, где все нули например). Похожий алгоритм широко используется в СУБД.
Обычно люди удивляются и не верят, когда им говоришь, что для целых чисел (int32 например) вычислительная сложность сортировки - это O(1). Но так и есть. По памяти она, правда, хромает, но зато честный научный O(1).
Или так:
Похоже на Java, но с вызовом деструкторов как обычно, необязательностью переменной, и также можно было бы опциональный catch-блок.
И то верно. Спасибо. Убрал STL из всех профилей в соцсетях. :)
Ни в коей степени не критикуя, но лишь любопытства из, вопрос к тем, кто пишет на Flutter каждый день: что там за история с Dart, в чем сакральный смысл отдельного языка для этого фреймворка? Наверное, он дает какие-то преимущества или специфический для области синтаксический сахар? Может быть, еще что-то? Если сравнивать с другими языками типа TypeScript или Kotlin.
Слово «байт» также немного дискредитировано тем, что в разных языках он то signed, то unsigned; короче, нет акцента на логической равноправности всех битов. А у слово «октет» такой проблемы нет.
Да, 20 лет назад так и думали. Эксперименты и исследования этого не подтверждают, запасаются в жир что быстрые, что медленные углеводы одинаково (одинаково плохо кстати, даже поразительно плохо).
Но: от быстрых углеводов уровень глюкозы в крови быстро повышается, а потом так же быстро снижается. И вот градиент снижения глюкозы ощущается человеком, как голод. В этом коварство: энергия пришла, а есть снова хочется уже через 15 минут, и человек ест еще, и еще, и еще, не может остановиться. Тут как с бросившими курить, которые сразу жиреют: раньше они тянули в рот сигарету в поисках быстрого удовольствия, а теперь тянут в рот, что пожрать. (Диабетиков здесь не рассматриваем.)
Брюс Ли называл это «пустыми калориями». В идеале на долгосроке и в основе рациона есть хорошо такую пищу, которая при минимальной энергетической плотности максимизирует чувство сытости и время сытости, при этом не проигрывая существенно по вкусу, в идеале вообще не проигрывая (спойлер: из качественных источников энергии - это вареная картошка, а из остального - также все, что имеет повышенный объем).