Ну, если не воспринимать вопрос чересчур серьёзно, то можно ответить что бойцы Сопротивления будут вполне себе востребованы.
(Если воспринимать, то вероятнее всего процесс будет постепенно смещаться в сторону профессий оперирующих технологиями на более высоком уровне. Я знаю пару художников которые уже сейчас используют нейросети для генерации идей для концепт-арта, точно так же как раньше они начали использовать 3D редакторы для того чтобы не заморачиваться со сложной перспективой если надо быстро набросать концепт.)
Наверное к тому и придут, да. :) У этого CEO журналист спросил на CET2023 - мол, посмотрел на ноутбук с этой системой, и всё равно медные трубки к ней идут, а CEO отвечает - ну, у нас системы плоские но подложка большая, сам процессор маленький, лучше трубок для равномерного распределения тепла пока что ничего не придумали, так и живём. Так что пакеты из них дело времени, было бы производство открыто. :)
Он не постоянный поток вроде, это просто пульсирующий поток с потолком скорости (во время вертикального соударения с теплоотводящей поверхностью) до 200 км/ч. Это они так создают jet impingement эффект.
Они пока не раскрывают, но обещают сопоставимую и говорят что в третьем квартале должны появиться устройства с этими охладителями внутри, у них контракт с какими-то производителями. Но пока только для разнообразных низкопотребляющих устройств, потому что готовые продукты пока есть только для низких TDP (в районе 20 ватт).
...и в цитаты из Стругацких, которые описали проблему из статьи и возможный вариант развития событий ещё в 1964 году, включая общество достатка, растительное существование большинства и возможность замещения реальной жизни более яркой и насыщенной виртуальной. Наверное мне стоит быть благодарным за то что вы меня не заподозрили в принадлежности к злобной элите из этой цепочки, хоть на том спасибо. :( Small favors.
В жизни должно быть немного юмора, право, иначе мы не проживём достаточно долго чтобы увидеть прекрасное ужасное будущее своими глазами.
Луддиты уже пробовали, но были не поняты и больших успехов не сыскали. :) Не думаю что повторная попытка увенчается успехом.
Это усугубляется тем, что современный человек вовсе не против плодов прогресса науки и технологий, а работу (в контексте статьи) теряют не все и сразу, а профессия за профессией и растянуто во времени, группа людей там, группа тут. Так что человек голоса не имеет, а он, сами понимаете, не карась, он же человек всё-таки, ему же скучно, а придумывать сам ничего не умеет; это ведь надо особые способности иметь - придумывать... :)
А давно начали слушать аудиокниги? Обычно с практикой восприятия на слух (и вообще практикой) приходит момент когда обдумывать фразу уже не надо, смысл приходит на уровне всего предложения. Вообще, если вы лучше воспринимаете информацию визуально, то можно попробовать слушать и параллельно читать (я так когда-то делал с "Властелином Колец" и "Тёмной Башней", тем более что Rob Inglis и Frank Muller отличные чтецы - не знаю большой ли это был для меня вклад в то время, но попробовать стоит).
Хотя да, в статье верно сказано, идеал недостижим. Я говорю свободно, но всякий раз когда общаюсь с одним другом, лондонцем (он из Чешира понаехал), я то и дело ему - "...come again?". То, на чём говорят в повседневной жизни, очень сильно отличается от того что в аудиокнигах.
Я не ради аргумента, на самом-то деле, просто отметил что сравнивать с тем сколько литографов выпускает в год ASML будет наверное не совсем корректно. :) Грубо говоря, их литографы используются только при изготовлении масок для всего последующего производства, а безмасочные - это уже "станки" непосредственно участвующие в производстве каждого кристалла, я вот только это хотел сказать - что, наверное, не очень много смысла в таком сравнении.
Насколько меньше (или больше) безмасочных литографов надо чем газовых центрифуг, я понятия не имею, не занят в этой индустрии - может быть @Armmaster может сказать, просто любопытства ради, какие объёмы выпуска могут быть у безмасочного литографа.
А сто процентов — это откуда-то взято, официально? Просто статья ведь как раз про то, что некоторые разработчики roguelike делают игры где идеальные действия не гарантируют победу, или даже такие где само понятие "идеальных действий" иллюзорно: опыт игрока не даёт ему каких-либо серьёзных подвижек к идеалу и даже самый опытный игрок может получить непроходимый сценарий где опыт никак ему не поможет (а новичок наоборот получит лёгкий вариант где никакого умения не надо). Пример лабиринта из статьи это иллюстрирует — даже если бы у игрока была бы информация о расположении яблок в лабиринте, их конфигурация всё ещё могла была бы быть такой, что никакое напряжение мозга не поможет ему этот лабиринт пройти, вот просто rng сдал ему теоретически непроходимый лабиринт. Иначе говоря, если бы игрок видел весь лабиринт и был бы идеальный счётчиком, он мог бы сразу перезапустить игру, не тратя своё время на бессмысленную попытку прохождения. Речь в статье как раз о засилье игр, которые говорят "а ну-ка пройди этот лабиринт", а потом читерят, генерируя лабиринт который непроходим даже в теории — ха-ха, два часа игры насмарку, try again. А у игроков создаётся чувство, что это они что-то делают неправильно. Статья выступает как раз против изобилия таких неоттестированных игр в жанре, а не против жанра вообще.
Если бы только игры при этом позиционировались как игры об управлении рисками, и вовсе хорошо было бы. Но игроки обычно думают "если я приноровлюсь к <ситуация> и улучшу свой скилл, то буду проходить этот уровень безупречно" а не "если я найду правильную последовательность действий, то я буду проходить этот уровень в 92% случаев, а всю игру — в 77% случаев, ура". Потому что если бы мне кто сказал, что суть игры вот в этом последнем, то это мне бы сэкономило время — не стал бы даже пробовать. Максимизировать шансы и мириться с возможностью того, что обстоятельства окажутся сильнее — спасибо, этого хватает в жизни, игру я открываю не за этим. :)
Там вроде только OSD переписали — то есть собственно демон который висит над диском и шурудит секторами, по одному демону на диск, а остальное осталось как есть; да и Magic Pocket там важная, но не самая объёмная часть инфраструктуры. То есть да, в целом дело хорошее и вселяет надежду (я уже джва году жду не дождусь возможности попробовать Rust в embedded продакшне), но я не уверен, что это большая веха для Rust. Скорее просто ещё одно напоминание о том что такие вещи вообще не стоит писать на garbage collected языках.
А точно был мальчик? Потому что я тоже эту публикацию помню, а потом вроде бы оказалось что там журналистов учёные насиловали как могли, и на самом деле Dropbox переписал на Rust только пару мелких служб в которых у них затык по производительности был, а всё остальное как было на Go так и есть.
function show_author(name) {
user = get_user(name)
if ok?(user) {
show(user)
} else {
log("Something wrong with " + user)
show(ADMIN)
}
}
Спасибо что исправили, но я всё ещё не вижу, что этот пример показывает. Если вы подразумеваете, что возможность передать в show_author() не строку а Null (то есть всё-таки имеете в виду статическую а не сильную типизацию) экономит вам время на обработку ошибок, то, во-первых, вы игнорируете другие методы обработки ошибок...
// name типизировано и всё-таки компилируется - поздравляю вас гражданин соврамши.
void show_author(std::string name) { // Строка может быть пустой.
auto user = get_user(name); // Проверяет name.empty().
… делаете предположение, что надо изобретать собственный тип...
// Опять типизировано и опять компилируется - дважды соврамши.
void show_author(std::optional<std::string> name) { // Из стандартной библиотеки.
… неконсистентны в том, где вы обрабатываете ошибки; user проверили перед передачей в show() но предполагаете, что show_author() может получить аргумент без проверки; ну и наконец умалчиваете о том, что в вашем варианте вам ещё потребуется написать тест, который вам покажет что ваша нетипизированная show_author() (а заодно и get_user(), потому что контроля типов и там нет) не взрывается при передаче не только строки или Null, но и какого-то другого типа.
В общем, что не компилируется — не показано (на самом деле компилируется). Что быстрее бы в продакшн ушло — тоже не показано (вы не упоминаете время на компенсацию возросших рисков). Я понимаю, что писать корректные примеры (и даже корректный код) ниже людей с критическим складом ума, но хотелось бы поменьше статей в которых сильная типизация путается со статической, треть кода формально некорректна и вдобавок ничего не иллюстрирует, а ещё одна треть опровергается в одно предложение.
Я прошу вас поправить некорректный псевдокод, в котором откуда-то магически возникают переменные (а использование других переменных бессмысленно — вы вызываете get_name() чтобы получить, внезапно, уже имеющееся name).
Похоже на то… chapuza, какие-то комментарии будут? Код в статье некорректный (а это, если что, треть всего кода в статье), хочется увидеть корректный и понять, как он иллюстрирует недостатки сильной типизации.
Я имел в виду то, что непонятно, по какой причине — как автор утверждает — не скомпилируется код с сильными типами (если автор вообще имел в виду сильные типы а не статические — я не могу додумать правильный пример за него). С сильными vs. слабыми я даже не могу придумать вариант — код выше не делает никакого преобразования типов. Если же автор имел в виду static vs. dynamic, что-то вроде name = get_user(user); if name != Null ..., подразумевая что со статическими типами мы не можем вернуть Null вместо строки и вынуждены изобретать variant type (подозреваю что это, судя по "… изобрести новый монадический тип для возможно указанного автора"), то получается уже совсем другой код, в котором get_user() сознательно написана без возможности вернуть ошибку (кодом возврата с передачей name через аргумент / пустой строкой / исключением и т.п.).
Ну, если не воспринимать вопрос чересчур серьёзно, то можно ответить что бойцы Сопротивления будут вполне себе востребованы.
(Если воспринимать, то вероятнее всего процесс будет постепенно смещаться в сторону профессий оперирующих технологиями на более высоком уровне. Я знаю пару художников которые уже сейчас используют нейросети для генерации идей для концепт-арта, точно так же как раньше они начали использовать 3D редакторы для того чтобы не заморачиваться со сложной перспективой если надо быстро набросать концепт.)
Наверное к тому и придут, да. :) У этого CEO журналист спросил на CET2023 - мол, посмотрел на ноутбук с этой системой, и всё равно медные трубки к ней идут, а CEO отвечает - ну, у нас системы плоские но подложка большая, сам процессор маленький, лучше трубок для равномерного распределения тепла пока что ничего не придумали, так и живём. Так что пакеты из них дело времени, было бы производство открыто. :)
Он не постоянный поток вроде, это просто пульсирующий поток с потолком скорости (во время вертикального соударения с теплоотводящей поверхностью) до 200 км/ч. Это они так создают jet impingement эффект.
Они пока не раскрывают, но обещают сопоставимую и говорят что в третьем квартале должны появиться устройства с этими охладителями внутри, у них контракт с какими-то производителями. Но пока только для разнообразных низкопотребляющих устройств, потому что готовые продукты пока есть только для низких TDP (в районе 20 ватт).
...и в цитаты из Стругацких, которые описали проблему из статьи и возможный вариант развития событий ещё в 1964 году, включая общество достатка, растительное существование большинства и возможность замещения реальной жизни более яркой и насыщенной виртуальной. Наверное мне стоит быть благодарным за то что вы меня не заподозрили в принадлежности к злобной элите из этой цепочки, хоть на том спасибо. :( Small favors.
В жизни должно быть немного юмора, право, иначе мы не проживём достаточно долго чтобы увидеть
прекрасноеужасное будущее своими глазами.На самом деле к 2525, у нас есть прогноз от Загера и Эванса. :)
Луддиты уже пробовали, но были не поняты и больших успехов не сыскали. :) Не думаю что повторная попытка увенчается успехом.
Это усугубляется тем, что современный человек вовсе не против плодов прогресса науки и технологий, а работу (в контексте статьи) теряют не все и сразу, а профессия за профессией и растянуто во времени, группа людей там, группа тут. Так что человек голоса не имеет, а он, сами понимаете, не карась, он же человек всё-таки, ему же скучно, а придумывать сам ничего не умеет; это ведь надо особые способности иметь - придумывать... :)
А давно начали слушать аудиокниги? Обычно с практикой восприятия на слух (и вообще практикой) приходит момент когда обдумывать фразу уже не надо, смысл приходит на уровне всего предложения. Вообще, если вы лучше воспринимаете информацию визуально, то можно попробовать слушать и параллельно читать (я так когда-то делал с "Властелином Колец" и "Тёмной Башней", тем более что Rob Inglis и Frank Muller отличные чтецы - не знаю большой ли это был для меня вклад в то время, но попробовать стоит).
Хотя да, в статье верно сказано, идеал недостижим. Я говорю свободно, но всякий раз когда общаюсь с одним другом, лондонцем (он из Чешира понаехал), я то и дело ему - "...come again?". То, на чём говорят в повседневной жизни, очень сильно отличается от того что в аудиокнигах.
Это не меняет основного тезиса о том что их не требуется так много в силу темпов производства, но спасибо что поправили.
Я не ради аргумента, на самом-то деле, просто отметил что сравнивать с тем сколько литографов выпускает в год ASML будет наверное не совсем корректно. :) Грубо говоря, их литографы используются только при изготовлении масок для всего последующего производства, а безмасочные - это уже "станки" непосредственно участвующие в производстве каждого кристалла, я вот только это хотел сказать - что, наверное, не очень много смысла в таком сравнении.
Насколько меньше (или больше) безмасочных литографов надо чем газовых центрифуг, я понятия не имею, не занят в этой индустрии - может быть @Armmaster может сказать, просто любопытства ради, какие объёмы выпуска могут быть у безмасочного литографа.
Так у ASML вроде масочные литографы? Их так много не надо как безмасочных. (Пардон что отвечаю через голову собеседников.)
Тут я полез смотреть, когда была написана "Имею скафандр — готов путешествовать". :) Но нет, история Масеко совсем недавняя.
А сто процентов — это откуда-то взято, официально? Просто статья ведь как раз про то, что некоторые разработчики roguelike делают игры где идеальные действия не гарантируют победу, или даже такие где само понятие "идеальных действий" иллюзорно: опыт игрока не даёт ему каких-либо серьёзных подвижек к идеалу и даже самый опытный игрок может получить непроходимый сценарий где опыт никак ему не поможет (а новичок наоборот получит лёгкий вариант где никакого умения не надо). Пример лабиринта из статьи это иллюстрирует — даже если бы у игрока была бы информация о расположении яблок в лабиринте, их конфигурация всё ещё могла была бы быть такой, что никакое напряжение мозга не поможет ему этот лабиринт пройти, вот просто rng сдал ему теоретически непроходимый лабиринт. Иначе говоря, если бы игрок видел весь лабиринт и был бы идеальный счётчиком, он мог бы сразу перезапустить игру, не тратя своё время на бессмысленную попытку прохождения. Речь в статье как раз о засилье игр, которые говорят "а ну-ка пройди этот лабиринт", а потом читерят, генерируя лабиринт который непроходим даже в теории — ха-ха, два часа игры насмарку, try again. А у игроков создаётся чувство, что это они что-то делают неправильно. Статья выступает как раз против изобилия таких неоттестированных игр в жанре, а не против жанра вообще.
Если бы только игры при этом позиционировались как игры об управлении рисками, и вовсе хорошо было бы. Но игроки обычно думают "если я приноровлюсь к <ситуация> и улучшу свой скилл, то буду проходить этот уровень безупречно" а не "если я найду правильную последовательность действий, то я буду проходить этот уровень в 92% случаев, а всю игру — в 77% случаев, ура". Потому что если бы мне кто сказал, что суть игры вот в этом последнем, то это мне бы сэкономило время — не стал бы даже пробовать. Максимизировать шансы и мириться с возможностью того, что обстоятельства окажутся сильнее — спасибо, этого хватает в жизни, игру я открываю не за этим. :)
Там вроде только OSD переписали — то есть собственно демон который висит над диском и шурудит секторами, по одному демону на диск, а остальное осталось как есть; да и Magic Pocket там важная, но не самая объёмная часть инфраструктуры. То есть да, в целом дело хорошее и вселяет надежду (я
уже джва годужду не дождусь возможности попробовать Rust в embedded продакшне), но я не уверен, что это большая веха для Rust. Скорее просто ещё одно напоминание о том что такие вещи вообще не стоит писать на garbage collected языках.А точно был мальчик? Потому что я тоже эту публикацию помню, а потом вроде бы оказалось что там журналистов учёные насиловали как могли, и на самом деле Dropbox переписал на Rust только пару мелких служб в которых у них затык по производительности был, а всё остальное как было на Go так и есть.
Спасибо что исправили, но я всё ещё не вижу, что этот пример показывает. Если вы подразумеваете, что возможность передать в
show_author()не строку а Null (то есть всё-таки имеете в виду статическую а не сильную типизацию) экономит вам время на обработку ошибок, то, во-первых, вы игнорируете другие методы обработки ошибок...… делаете предположение, что надо изобретать собственный тип...
… неконсистентны в том, где вы обрабатываете ошибки;
userпроверили перед передачей вshow()но предполагаете, чтоshow_author()может получить аргумент без проверки; ну и наконец умалчиваете о том, что в вашем варианте вам ещё потребуется написать тест, который вам покажет что ваша нетипизированнаяshow_author()(а заодно иget_user(), потому что контроля типов и там нет) не взрывается при передаче не только строки или Null, но и какого-то другого типа.В общем, что не компилируется — не показано (на самом деле компилируется). Что быстрее бы в продакшн ушло — тоже не показано (вы не упоминаете время на компенсацию возросших рисков). Я понимаю, что писать корректные примеры (и даже корректный код) ниже людей с критическим складом ума, но хотелось бы поменьше статей в которых сильная типизация путается со статической, треть кода формально некорректна и вдобавок ничего не иллюстрирует, а ещё одна треть опровергается в одно предложение.
Я прошу вас поправить некорректный псевдокод, в котором откуда-то магически возникают переменные (а использование других переменных бессмысленно — вы вызываете get_name() чтобы получить, внезапно, уже имеющееся name).
Похоже на то… chapuza, какие-то комментарии будут? Код в статье некорректный (а это, если что, треть всего кода в статье), хочется увидеть корректный и понять, как он иллюстрирует недостатки сильной типизации.
Я имел в виду то, что непонятно, по какой причине — как автор утверждает — не скомпилируется код с сильными типами (если автор вообще имел в виду сильные типы а не статические — я не могу додумать правильный пример за него). С сильными vs. слабыми я даже не могу придумать вариант — код выше не делает никакого преобразования типов. Если же автор имел в виду static vs. dynamic, что-то вроде
name = get_user(user); if name != Null ..., подразумевая что со статическими типами мы не можем вернуть Null вместо строки и вынуждены изобретать variant type (подозреваю что это, судя по "… изобрести новый монадический тип для возможно указанного автора"), то получается уже совсем другой код, в которомget_user()сознательно написана без возможности вернуть ошибку (кодом возврата с передачей name через аргумент / пустой строкой / исключением и т.п.).