Помните анекдот: мне не нужно бежать быстрее тигра, мне нужно бежать быстрее тебя?
Тест Тьюринга не определяет точность ответов, он определяет "похожесть на человека". Исходя из исследования, людей тестирующие чаще определяют, как ии, чем сам ии. И наоборот.
Как к этому относиться - дело ваше. А уж вопросы веры - дело каждого.
Мне, как разработчику, последние несколько лет хранящему часть сбережений в крипте, история выглядит неправдоподобно. Каждая деталь не на своем месте. Лень расследовать, но я бы поставил пару сотен тезера, что это если не фейк, то сильно искаженная версия как минимум.
Забавно, мне все мои женщины говорили, что это у меня мания все выбрасывать. Не могу сказать, насколько они правы, но я определенно люблю избавляться от старья и всегда выбрасывал кратно больше всех своих домочадцев. Однажды умудрился выбросить буквально мешок обуви жены. Первой. Давняя история, я был тогда достаточно молод и наивен думать, что у женщины может быть лишняя обувь. В любом случае, я всегда интуитивно полагал, что это женщины скорее склонны к накопительству и излишне привязываются ко всякому хламу. Еще один пример того, что личный опыт обманчив.
Разумеется дженерик лучше. По целой куче причин, от контроля типов до производительности.
Вы приводите пример в котором явным образом выброс исключения нарушает все возможные бест практисез по выбросу исключений. Я не могу сказать про конкретные версии студии, и дефолтные настройки, но последние анализаторы рослина ругаются на выброс базового эксепшена точно, а любой дополнительный тул в виде решарпера, или сонаркуба, дополнит про потерянный стек трейс. Не давайте плохих примеров - это мой поинт. Если эксепшен не важен - не бросайте. Если это плейсхолдер - напишите это через коммент // Here is the placeholder for exception handling. И тд. Не давайте плохой код в качестве примера. Разработчик не может по ошибке передать налл в объект, который он не создает, поэтому этот код - мертвый в релизе. Не пишите мертвый для релиза код в проектах, и тем более в примерах, где этот код не важен. Не говоря о том, что ребята из МС озаботились созданием хэлперов и аттрибутов для описания и валидации параметров, и ваш код выглядит по-школьному даже если предположить что эта проверка там нужна. Тогда параметр надо объявить как наллабл, пометить аттрибутом для анализаторов и было бы хорошо воспользоваться хэлпером ArgumentNullException.ThrowIfNull(...); чтобы было по-взрослому.
Не нужно для примера, не важно в контексте - не пишите! Это рекомендация.
Да и вообще базовый эксепшен выкидывать это моветон. О чем там даже варнинг должен быть от рослина. Тут прям академический пример как не надо делать: максимально безликий эксепшен и похереный стек трейс) Или в иннер завернуть, или голый throw; но не так.
Но тут явно проигнорированы все усилия команды майкрософта) Проверка аргумента в конструкторе на налл - для чего? DI контейнер все равно раньше эксепшен выбросит если сервис в контейнере не найдет. Это мертвый код. К дизайну тоже есть претензии, а List<object> вызывает просто скрежет зубовный, ну не фреймворк же 2.0 на дворе. А если б был, ну хоть бы ArrayList тогда. Ну да ладно, все равно велосипед.
Про бэкап позволю себе не согласиться. Что бы мы ни сделали с Землей, терраформировать Марс в Землю будет неизмеримо, на много порядков сложнее, чем терраформировать подпорченную Землю обратно в Землю, комфортную для проживания. Это абсолютно несопоставимые усилия и ресурсы, оправдать которые не сможет даже самый фантастический сценарий. Ни ядерная война, ни даже второй Чиксулуб, не сделают Землю настолько же безнадежным для выживания вариантом, как Марс.
Нам не стоит колонизировать Марс, потому что это а) абсолютно нецелесообразно б) попросту невозможно на сегодня.
Исследовательские экспедиции - безусловно, как элемент развития научно-технического прогресса. Аргументов в пользу траты ресурсов на развитие науки и технологий масса и они очевидны. Но в качестве бэкапа Марс бесполезен.
Ну, плоской Земля тоже быть не могла, иначе котики сбросили бы все с ее края )
Удручает, что мыслители античности смогли не только определить форму Земли, но и довольно точно рассчитать ее радиус, имея в распоряжении только тень, отбрасываемую палкой воткнутой в землю, а сегодня, имея в распоряжении спутники джипиэс, находится так много интеллектуалов, не осиливших программу пятого класса :(
На этот вопрос не существует ответа, потому что никаких внутриатомных расстояний на первых порах не было, по причине отсутствия атомов ) Вещество на ранних стадиях существования Вселенной представляло из себя кварк-глюонную плазму. Это такой "суп" где не существует не только атомов, но даже их "запчастей": протонов, нейтронов и тд. Только глюоны и кварки. Даже привычных нам четырех взаимодействий не существовало (ядерное, электросильное, электрослабое, гравитация). Все частицы имели нулевую массу. По прошествии некоторого времени после Большого Взрыва, которое сейчас принято делить на несколько раздельных эпох, по мере остывания и расширения Вселенной, сформировалась известная нам стандартная модель. Сперва сформировались протоны и нейтроны (упрощенно, там тоже есть целый ряд стадий), затем была эпоха излучения а уже за ней эпоха первичной рекомбинации, в процессе которой появились первые атомы, когда Вселенная достаточно остыла, чтобы электроны могли быть захвачены ядрами. Ушло на это порядка 350 000 лет. Сами атомы уже были такими же, как и сейчас. Правда, из атомов были только водород да гелий. Чтобы этот раскаленный газ остыл и начали образовываться первые звезды, ушло порядка полмиллиарда лет по последним оценкам. И только в процессе "жизнедеятельности" появившихся звезд стали образовываться более тяжелые элементы, сформировавшие привычную нам таблицу Менделеева.
Вообще говоря вопрос о "внутриатомных расстояниях" и сегодня не совсем однозначный. У атомов нет привычных нам размеров, как у объектов макромира, электроны "размазаны" по некоторому объему вокруг ядра, где существует некоторая плотность вероятности их обнаружить, а уж что до расстояний внутри атома, то это понятие вообще не имеет смысла.
Большой Взрыв - это одно из тех метафорических, остроумных и поэтичных названий, которое ученые иногда дают различным явлениям (объектам, событиям, законам), а потом сильно об этом жалеют, потому что большинство воспринимает эти явления абсолютно не тем, чем они являются :)
Самый, наверное, яркий пример - это митохондриальная Ева и Y-хромосомный Адам. Дернуло же молекулярных биологов на библейские аллегории, теперь у рвущихся запретить теорию эволюции в школах есть "весомый" аргумент: Адам и Ева существовали, доказано учеными...
Понять природу Большого Взрыва навряд ли получится до конца, пока не будут решены важнейшие вопросы космологии, такие как форма Вселенной, например. Аналогии с шариком и прочие объяснения "на пальцах" работают, но если попытаться составить полную картину приходят к противоречиям. После планковской эпохи, за стадию инфляции, линейный размер Вселенной вырос в 10^26 раз, а объем соответственно в 10^78. Мы не можем делать подобные утверждения для бесконечного объекта. То есть Вселенная была определенного, конечного размера, и в момент фазового перехода, когда плотность кварк-глюонной плазмы была без малого гугол кг на куб, а температура около сотни кветта-Кельвин, ее объем и линейные размеры были небольшими. Если Вселенная плоская, то она определенно должна быть конечной, а если она конечна, то ее размер можно экстраполировать. При этом способа заглянуть за радиус Хаббла у нас нет и пока даже теоретически быть не может, поэтому для нас она в любом случае бесконечна: мы существуем где-то меж двух сингулярностей. А мы пока даже с переменчивой постоянной Хаббла разобраться не можем.
Как-то не очень похожая. new[] {1,2,3} - это синтаксис для создания массива int[] и лист там не фигурирует. То есть тут код создает экземпляр класса Array и приводит его к интерфейсу IList. Array реализует IList только частично и это разумеется надо иметь в виду при приведении к интерфейсу. Тем более что анализаторы кода ругаются и рекомендуют использовать адекватный синтаксис вида:
IList<int> example = [1, 2, 3];
Для наглядности оба варианта и лоу-левел шарп, генерируемый компилятором:
Класс может не поддерживать все методы интерфейса, это вполне распространенное явление. ReadOnlyCollection и Array реализуют IList и ICollection, но методы связанные с добавлением и удалением элементов у них выбрасывают NotSupported. Когда вы создаете и используете каку-то конкретную реализацию - выбор на вашей совести. Как и то, зачем вы вообще используете интерфейс в локальном методе, где прямым образом создаете конкретную реализацию. Нужен вам лист, ну так и объявляйте лист.
Это все не очень похоже на ситуацию, когда статический метод класса List, возвращает экземпляр класса-наследника, о котором он и знать-то по хорошему не должен, при этом возвращает как самого себя, то есть базовый класс, так что при вызове .of(..) у вас не существует никакого способа определить эту подставу, кроме как знать его реализацию. И подстава не была бы такой подставой, если бы наследник следовал принципу Барбары Лисков (вот уж не думал что буду упоминать его всуе), однако вот. Выходит, что вам нужен лист, вы честно создаете лист, собираетесь пользовать - да не тут-то было...
Тут ее можно скастить потому что она по факту создана листом. Лист реализует интерфейс IReadonlyList в числе прочих, поэтому вы можете привести экземпляр листа к IReadonlyList, но можете соответственно и обратно. Как в примере. Если у вас разрабы так и ищут, как бы хакнуть ваш собственный код, а процессы код ревью и прочие отсутствуют, то лучше пользоваться более надежными конструкциями, как советуют выше:
List<int> list = [1,2,3]; //создали лист
var roCollection = list.AsReadOnly(); //получили экземпляр ReadOnlyCollection
ReadOnlyCollection никакой злостный вредитель к листу обратно не приведет и она тоже реализует IReadOnlyList который нам нужен. Конечно, никто не помешает потенциальному вредителю изменить коллекцию через рефлексию, бесовщину с указателями, или просто-напросто создать из нее лист, добавить туда значение и переприсвоить без всякой магии в одну строку, вот так:
Безопасность типов в языке это не защита от злонамеренного вредительства, а лишь дополнительное средство контроля ошибок. Ни один из примеров невозможно воспроизвести случайно в рамках повседневной разработки. Даже этот несчастный ref параметр. Вообще, этот пример - баг компилятора, который позволял делегат (ref x) => ... присвоить переменной типа (in x) => ..., что неправильно по сути, приводило к некорректному поведению и было соответственно пофикшено после баг репорта. У вас не может быть объективной причины для подобного каста. Да и в принципе нужна веская причина, чтобы сделать параметр ref, и чтобы иметь такую причину, нужно хорошо понимать как он работает, и почему он у вас ref, а не ref readonly, не scoped ref и не scoped ref readonly. Если вам необходимо изменить значение static readonly поля (да, в примере не константа, константу изменить не выйдет в принципе) - вы можете это сделать и без бага: через рефлексию. Зачем это вам может понадобиться - вопрос отдельный, но возможность есть и всегда была. И сделать это можно только намеренно, хорошо понимая что вы делаете.
Многие фичи, позволяющие "творить всякую дичь" создавались для хардкорной оптимизации, кодогенерации, анализаторов кода, создания нативных AOT сборок, кастомизации работы компилятора и других узкопрофильных, редких, но в отдельных случаях очень полезных вещей. Чтобы понять зачем и почему та, или иная дичь имеет место быть, можно пойти на гитхаб в репы МС и либо почитать обсуждение конкретной фичи самими разрабрами, либо поискать примеры использования в коде. Благо там все нынче опенсурс, вплоть до митинг ноутс. Я на 100% уверен, найдете рациональное зерно, либо баг репорт для любой дичи. И, к слову, ребята из МС, которые пилят сдк, рослин и все остальное, точно не уступают в квалификации джетбрейновцам. Конечно, если это не ваш профиль, тратить время на это вам вряд ли захочется.
Разные синтаксические фокусы, производящие человеконечитаемый, но валидный код, как-то тоже на дичь не тянут. И без греческого можно написать нечитаемый вырвиглаз, только за счет нейминга и форматирования.
Речь о том, что прикладной смысл может отставать от фундаментальной науки на десятилетия, может быть не прямым, но косвенным, однако он всегда появляется. За неимением обратных примеров.
У них есть контекстное окно в рамках которого они "помнят". Новый диалог - новое окно. Я и вы общаемся с одной и той же моделью, но ваш чат не помнит мой диалог и наоборот, хотя это физически одна и та же модель. Каждый раз задавая вопрос модели вы подаете ей на вход весь контекст, вот и вся "память". Можно также добавить дополнительные инструкции к контексту, все модели сейчас позволяют это, таким образом меняя настройки "личности".
Разумеется дело в желании, это именно то, что я сказал. В обсуждение мотивов я не вдавался, это неважно для контекста.
Отрицать что угодно нельзя, как и нельзя что угодно декларировать как истину, по желанию. С тех пор, как сформировался научный метод около 200 лет назад, прогресс ускорился экспоненциально, и не благодаря выходу за рамки, но ровно наоборот. Выдвигать беспочвенные гипотезы о философском камне более нет нужды, существует намного более быстрый и надежный гносеологический инструментарий. Сегодня как раз сторонники плоской Земли, инопланетян - строителей пирамид и тому подобной ахинеи постоянно кричат о выходе за рамки. Выходите, кто ж не дает. Обнаружите там что-то полезное - поделитесь. Пока только торсионные поля и рептилоиды с Нибиру.
Сейчас вообще довольно сложно сказать, где опаснее: в космосе, или на Земле. Многовато переменных.
Что касается рисков на дистанции, то их всегда было сложно оценить. Оно и без облучения шансы дожить до следующего дня рождения с каждым годом все падают, и это не фатализм, а просто статистика. То, что большинство страшных вещей, в реальности много менее страшны - вполне согласуется со здравым смыслом. Даже пяток поговорок можно про это попытаться припомнить) Преувеличение опасности - это очень даже удачная эволюционная стратегия на самом деле. Потому и популярная.
И кого отсекаете? Вы не в курсе какую вы страницу в браузере открыли? Или думаете оттуда с вами человек может разговаривать?
Фантазия бьет ключом. Или это ии-галлюцинации?..
Помните анекдот: мне не нужно бежать быстрее тигра, мне нужно бежать быстрее тебя?
Тест Тьюринга не определяет точность ответов, он определяет "похожесть на человека". Исходя из исследования, людей тестирующие чаще определяют, как ии, чем сам ии. И наоборот.
Как к этому относиться - дело ваше. А уж вопросы веры - дело каждого.
Мне, как разработчику, последние несколько лет хранящему часть сбережений в крипте, история выглядит неправдоподобно. Каждая деталь не на своем месте. Лень расследовать, но я бы поставил пару сотен тезера, что это если не фейк, то сильно искаженная версия как минимум.
Забавно, мне все мои женщины говорили, что это у меня мания все выбрасывать. Не могу сказать, насколько они правы, но я определенно люблю избавляться от старья и всегда выбрасывал кратно больше всех своих домочадцев. Однажды умудрился выбросить буквально мешок обуви жены. Первой. Давняя история, я был тогда достаточно молод и наивен думать, что у женщины может быть лишняя обувь. В любом случае, я всегда интуитивно полагал, что это женщины скорее склонны к накопительству и излишне привязываются ко всякому хламу. Еще один пример того, что личный опыт обманчив.
Разумеется дженерик лучше. По целой куче причин, от контроля типов до производительности.
Вы приводите пример в котором явным образом выброс исключения нарушает все возможные бест практисез по выбросу исключений. Я не могу сказать про конкретные версии студии, и дефолтные настройки, но последние анализаторы рослина ругаются на выброс базового эксепшена точно, а любой дополнительный тул в виде решарпера, или сонаркуба, дополнит про потерянный стек трейс. Не давайте плохих примеров - это мой поинт. Если эксепшен не важен - не бросайте. Если это плейсхолдер - напишите это через коммент // Here is the placeholder for exception handling. И тд. Не давайте плохой код в качестве примера. Разработчик не может по ошибке передать налл в объект, который он не создает, поэтому этот код - мертвый в релизе. Не пишите мертвый для релиза код в проектах, и тем более в примерах, где этот код не важен. Не говоря о том, что ребята из МС озаботились созданием хэлперов и аттрибутов для описания и валидации параметров, и ваш код выглядит по-школьному даже если предположить что эта проверка там нужна. Тогда параметр надо объявить как наллабл, пометить аттрибутом для анализаторов и было бы хорошо воспользоваться хэлпером ArgumentNullException.ThrowIfNull(...); чтобы было по-взрослому.
Не нужно для примера, не важно в контексте - не пишите! Это рекомендация.
Да и вообще базовый эксепшен выкидывать это моветон. О чем там даже варнинг должен быть от рослина. Тут прям академический пример как не надо делать: максимально безликий эксепшен и похереный стек трейс) Или в иннер завернуть, или голый throw; но не так.
Но тут явно проигнорированы все усилия команды майкрософта) Проверка аргумента в конструкторе на налл - для чего? DI контейнер все равно раньше эксепшен выбросит если сервис в контейнере не найдет. Это мертвый код. К дизайну тоже есть претензии, а List<object> вызывает просто скрежет зубовный, ну не фреймворк же 2.0 на дворе. А если б был, ну хоть бы ArrayList тогда. Ну да ладно, все равно велосипед.
Про бэкап позволю себе не согласиться. Что бы мы ни сделали с Землей, терраформировать Марс в Землю будет неизмеримо, на много порядков сложнее, чем терраформировать подпорченную Землю обратно в Землю, комфортную для проживания. Это абсолютно несопоставимые усилия и ресурсы, оправдать которые не сможет даже самый фантастический сценарий. Ни ядерная война, ни даже второй Чиксулуб, не сделают Землю настолько же безнадежным для выживания вариантом, как Марс.
Нам не стоит колонизировать Марс, потому что это а) абсолютно нецелесообразно б) попросту невозможно на сегодня.
Исследовательские экспедиции - безусловно, как элемент развития научно-технического прогресса. Аргументов в пользу траты ресурсов на развитие науки и технологий масса и они очевидны. Но в качестве бэкапа Марс бесполезен.
Ну, плоской Земля тоже быть не могла, иначе котики сбросили бы все с ее края )
Удручает, что мыслители античности смогли не только определить форму Земли, но и довольно точно рассчитать ее радиус, имея в распоряжении только тень, отбрасываемую палкой воткнутой в землю, а сегодня, имея в распоряжении спутники джипиэс, находится так много интеллектуалов, не осиливших программу пятого класса :(
На этот вопрос не существует ответа, потому что никаких внутриатомных расстояний на первых порах не было, по причине отсутствия атомов ) Вещество на ранних стадиях существования Вселенной представляло из себя кварк-глюонную плазму. Это такой "суп" где не существует не только атомов, но даже их "запчастей": протонов, нейтронов и тд. Только глюоны и кварки. Даже привычных нам четырех взаимодействий не существовало (ядерное, электросильное, электрослабое, гравитация). Все частицы имели нулевую массу. По прошествии некоторого времени после Большого Взрыва, которое сейчас принято делить на несколько раздельных эпох, по мере остывания и расширения Вселенной, сформировалась известная нам стандартная модель. Сперва сформировались протоны и нейтроны (упрощенно, там тоже есть целый ряд стадий), затем была эпоха излучения а уже за ней эпоха первичной рекомбинации, в процессе которой появились первые атомы, когда Вселенная достаточно остыла, чтобы электроны могли быть захвачены ядрами. Ушло на это порядка 350 000 лет. Сами атомы уже были такими же, как и сейчас. Правда, из атомов были только водород да гелий. Чтобы этот раскаленный газ остыл и начали образовываться первые звезды, ушло порядка полмиллиарда лет по последним оценкам. И только в процессе "жизнедеятельности" появившихся звезд стали образовываться более тяжелые элементы, сформировавшие привычную нам таблицу Менделеева.
Вообще говоря вопрос о "внутриатомных расстояниях" и сегодня не совсем однозначный. У атомов нет привычных нам размеров, как у объектов макромира, электроны "размазаны" по некоторому объему вокруг ядра, где существует некоторая плотность вероятности их обнаружить, а уж что до расстояний внутри атома, то это понятие вообще не имеет смысла.
Большой Взрыв - это одно из тех метафорических, остроумных и поэтичных названий, которое ученые иногда дают различным явлениям (объектам, событиям, законам), а потом сильно об этом жалеют, потому что большинство воспринимает эти явления абсолютно не тем, чем они являются :)
Самый, наверное, яркий пример - это митохондриальная Ева и Y-хромосомный Адам. Дернуло же молекулярных биологов на библейские аллегории, теперь у рвущихся запретить теорию эволюции в школах есть "весомый" аргумент: Адам и Ева существовали, доказано учеными...
Понять природу Большого Взрыва навряд ли получится до конца, пока не будут решены важнейшие вопросы космологии, такие как форма Вселенной, например. Аналогии с шариком и прочие объяснения "на пальцах" работают, но если попытаться составить полную картину приходят к противоречиям. После планковской эпохи, за стадию инфляции, линейный размер Вселенной вырос в 10^26 раз, а объем соответственно в 10^78. Мы не можем делать подобные утверждения для бесконечного объекта. То есть Вселенная была определенного, конечного размера, и в момент фазового перехода, когда плотность кварк-глюонной плазмы была без малого гугол кг на куб, а температура около сотни кветта-Кельвин, ее объем и линейные размеры были небольшими. Если Вселенная плоская, то она определенно должна быть конечной, а если она конечна, то ее размер можно экстраполировать. При этом способа заглянуть за радиус Хаббла у нас нет и пока даже теоретически быть не может, поэтому для нас она в любом случае бесконечна: мы существуем где-то меж двух сингулярностей. А мы пока даже с переменчивой постоянной Хаббла разобраться не можем.
Как-то не очень похожая. new[] {1,2,3} - это синтаксис для создания массива int[] и лист там не фигурирует. То есть тут код создает экземпляр класса Array и приводит его к интерфейсу IList. Array реализует IList только частично и это разумеется надо иметь в виду при приведении к интерфейсу. Тем более что анализаторы кода ругаются и рекомендуют использовать адекватный синтаксис вида:
Для наглядности оба варианта и лоу-левел шарп, генерируемый компилятором:
Класс может не поддерживать все методы интерфейса, это вполне распространенное явление. ReadOnlyCollection и Array реализуют IList и ICollection, но методы связанные с добавлением и удалением элементов у них выбрасывают NotSupported. Когда вы создаете и используете каку-то конкретную реализацию - выбор на вашей совести. Как и то, зачем вы вообще используете интерфейс в локальном методе, где прямым образом создаете конкретную реализацию. Нужен вам лист, ну так и объявляйте лист.
Это все не очень похоже на ситуацию, когда статический метод класса List, возвращает экземпляр класса-наследника, о котором он и знать-то по хорошему не должен, при этом возвращает как самого себя, то есть базовый класс, так что при вызове .of(..) у вас не существует никакого способа определить эту подставу, кроме как знать его реализацию. И подстава не была бы такой подставой, если бы наследник следовал принципу Барбары Лисков (вот уж не думал что буду упоминать его всуе), однако вот. Выходит, что вам нужен лист, вы честно создаете лист, собираетесь пользовать - да не тут-то было...
Ну "я хочу" и "нерешенная проблема" все же не совсем одно и то же)
А чем не подходит xml документация?
Не знаю как это выглядит в джаве.
Тут ее можно скастить потому что она по факту создана листом. Лист реализует интерфейс IReadonlyList в числе прочих, поэтому вы можете привести экземпляр листа к IReadonlyList, но можете соответственно и обратно. Как в примере. Если у вас разрабы так и ищут, как бы хакнуть ваш собственный код, а процессы код ревью и прочие отсутствуют, то лучше пользоваться более надежными конструкциями, как советуют выше:
ReadOnlyCollection никакой злостный вредитель к листу обратно не приведет и она тоже реализует IReadOnlyList который нам нужен. Конечно, никто не помешает потенциальному вредителю изменить коллекцию через рефлексию, бесовщину с указателями, или просто-напросто создать из нее лист, добавить туда значение и переприсвоить без всякой магии в одну строку, вот так:
Если кому-то надо накосячить, компилятор не поможет.
Безопасность типов в языке это не защита от злонамеренного вредительства, а лишь дополнительное средство контроля ошибок. Ни один из примеров невозможно воспроизвести случайно в рамках повседневной разработки. Даже этот несчастный ref параметр. Вообще, этот пример - баг компилятора, который позволял делегат (ref x) => ... присвоить переменной типа (in x) => ..., что неправильно по сути, приводило к некорректному поведению и было соответственно пофикшено после баг репорта. У вас не может быть объективной причины для подобного каста. Да и в принципе нужна веская причина, чтобы сделать параметр ref, и чтобы иметь такую причину, нужно хорошо понимать как он работает, и почему он у вас ref, а не ref readonly, не scoped ref и не scoped ref readonly. Если вам необходимо изменить значение static readonly поля (да, в примере не константа, константу изменить не выйдет в принципе) - вы можете это сделать и без бага: через рефлексию. Зачем это вам может понадобиться - вопрос отдельный, но возможность есть и всегда была. И сделать это можно только намеренно, хорошо понимая что вы делаете.
Многие фичи, позволяющие "творить всякую дичь" создавались для хардкорной оптимизации, кодогенерации, анализаторов кода, создания нативных AOT сборок, кастомизации работы компилятора и других узкопрофильных, редких, но в отдельных случаях очень полезных вещей. Чтобы понять зачем и почему та, или иная дичь имеет место быть, можно пойти на гитхаб в репы МС и либо почитать обсуждение конкретной фичи самими разрабрами, либо поискать примеры использования в коде. Благо там все нынче опенсурс, вплоть до митинг ноутс. Я на 100% уверен, найдете рациональное зерно, либо баг репорт для любой дичи. И, к слову, ребята из МС, которые пилят сдк, рослин и все остальное, точно не уступают в квалификации джетбрейновцам. Конечно, если это не ваш профиль, тратить время на это вам вряд ли захочется.
Разные синтаксические фокусы, производящие человеконечитаемый, но валидный код, как-то тоже на дичь не тянут. И без греческого можно написать нечитаемый вырвиглаз, только за счет нейминга и форматирования.
Речь о том, что прикладной смысл может отставать от фундаментальной науки на десятилетия, может быть не прямым, но косвенным, однако он всегда появляется. За неимением обратных примеров.
У них есть контекстное окно в рамках которого они "помнят". Новый диалог - новое окно. Я и вы общаемся с одной и той же моделью, но ваш чат не помнит мой диалог и наоборот, хотя это физически одна и та же модель. Каждый раз задавая вопрос модели вы подаете ей на вход весь контекст, вот и вся "память". Можно также добавить дополнительные инструкции к контексту, все модели сейчас позволяют это, таким образом меняя настройки "личности".
Разумеется дело в желании, это именно то, что я сказал. В обсуждение мотивов я не вдавался, это неважно для контекста.
Отрицать что угодно нельзя, как и нельзя что угодно декларировать как истину, по желанию. С тех пор, как сформировался научный метод около 200 лет назад, прогресс ускорился экспоненциально, и не благодаря выходу за рамки, но ровно наоборот. Выдвигать беспочвенные гипотезы о философском камне более нет нужды, существует намного более быстрый и надежный гносеологический инструментарий. Сегодня как раз сторонники плоской Земли, инопланетян - строителей пирамид и тому подобной ахинеи постоянно кричат о выходе за рамки. Выходите, кто ж не дает. Обнаружите там что-то полезное - поделитесь. Пока только торсионные поля и рептилоиды с Нибиру.
Сейчас вообще довольно сложно сказать, где опаснее: в космосе, или на Земле. Многовато переменных.
Что касается рисков на дистанции, то их всегда было сложно оценить. Оно и без облучения шансы дожить до следующего дня рождения с каждым годом все падают, и это не фатализм, а просто статистика. То, что большинство страшных вещей, в реальности много менее страшны - вполне согласуется со здравым смыслом. Даже пяток поговорок можно про это попытаться припомнить) Преувеличение опасности - это очень даже удачная эволюционная стратегия на самом деле. Потому и популярная.
Они не учатся на диалогах. Они обучаются один раз на подобранных датасетах, после чего они статичны.
Личность начинается там, где нам нравится ее видеть.
Лучше бы вы просто последовали совету. Определенно этот поток демагогии рассортировывать бесплатно - подвиг. А я не герой.
Ого, открытие. Вот буквально недавно читал подобную статью. Когда ж это было? В 2005? Или 2004? Склероз одолел. Про поток там еще было.