никаких оптимизаций производительности не применяется?
Ну нет, зачем так категорично.
На такие случаи в Java есть модель памяти и синхронизаций, с разграничением на то, что платформа может обещать и чего не может. И если вот в модели говорится, что некое действие строго после — то хоть обоптимизируйся, но придётся потом ждать на мониторе. Зато вот там, где гарантий не давалось, будет самая мякотка. К примеру, вполне может быть, что для итерации по циклу с созданиями объектов внутри — на самом деле не будет создаваться никаких объектов, а может и итерации не будет, несмотря на то, что в исходном коде по этому поводу написано.
Если же переход из валидного состояния A в валидное состояние B требует выполнения операций i, j, k, и во время выполнения операции j возникло исключение, то возникнет невалидное состояние. Чтобы такого не было в среде с исключениями, надо ловить исключения каждой промежуточной операции и откатывать состояние до валидного.
Вне интернета это тоже работало, во времена судов Линча. Но разговор как раз не про "вне интернета" — травят-то в интернете. Причём для неокрепших мозгов жертв (и взрослых жертв тоже) напор негатива может оказаться неподъёмным, и где-нибудь зашкалит, а конкретно у детей ведь пофигизма ещё выработалось недостаточно, а ближайшее окружение их зачастую прямо носит на руках.
На взрослых конкретно Cancel Culture срабатывает сейчас ещё и от того, что никому не хочется отбиваться от твиттерных толп, а в разгаре гона оные толпы не чураются нападать не только на прямую жертву, но и на родственников, детей, коллег и работодателей. Которым (особенно работодателям) такое внимание ну вот совсем никуда не впилось. Ну тут скорее всего тоже пока ещё не выработалось достаточно пофигизма, среда-то новая.
Ну, формальных доказательств нет, конечно же, но существенное ухудшение производительности будет регрессией и багом.
Понимаете, какая штука. Улучшение производительности — это, зачастую, тоже регрессия. Потому, к примеру, в стандартной библиотеке Java есть уже несколько версий по-разному работающих классов, абстрагирующих одно и то же, по сути. Потому, что как ни старайся — а иногда код написан с расчётом на сайд-эффекты. Плохо ли это? Разумеется. Но код работал до обновления, и там было вложенное ожидание, что некое действие займёт как минимум 13 миллисекунд, а после обновления функция иногда выполняется за 9, а значит код ломается. Вот такие вещи в Java тоже во многих случаях считаются регрессией. Если что в Haskell — не будут — то это нехорошо для развитого, устаканившегося бизнеса.
травящий может сколотить некую группу сообщников, но это надо их очень сильно [за]мотивировать против жертвы, что в реальной жизни практически невозможно, если они с ней не знакомы, плюс их должно быть много, и в идеале у каждого из них должно быть по нескольку аккаунтов.
На Twitter и в социальных сетях очень хорошо в последнее время работают обвинения в различных -измах. Доказательств особо не требуется, нужны только навыки убедительно играть жертву, толпы получаются — одно загляденье.
Почитать можно начиная вот отсюда: Wiki:Call-out culture Urban Dictionary:Cancel Culture
Отсюда достаточно легко, я думаю, перейти к ещё более немотивированным травлям. Всего лишь нужна какая-нибудь достаточно плотная группа по интересам и желание участников разносить негодование в другие группы.
То есть для каждой временной метки в UTC можно однозначно посчитать её локальное представление
Вот именно, что сдвиг можно элементарно узнать когда вам уже известен момент в UTC и имя зоны. В нашем случае же задача стоит именно в том, чтобы узнать, какой момент UTC закодирован в строке.
выглядит громоздко и страшно, как по мне…
Код выглядит громоздко от того, что изначально постановка задачи предполагает, что кто-то должен сделать много допущений. Как вы (должно быть) знаете, OffsetDateTime — это как раз момент времени, специфическая его форма, когда часовой пояс представлен неким смещением относительно UTC. При этом, в строке "2012-11-30" содержится только дата. То есть, чтобы составить из этой даты момент времени, нам не хватает "всего-то" остатка совы — времени и смещения относительно UTC. Вы кому предлагаете эти данные "родить" — разработчикам стандартной библиотеки, которые о специфике вашей программы ничего не знают? Нет, согласно дизайну java.time допущений следует делать как можно меньше (в идеале — не делать вообще), и все необходимые данные нужно предоставить разработчику, так как это он лучше должен знать, какие допущения можно делать, а каких — нельзя. Вот второй блок кода как раз этим и занимается, кстати — говорит, что делать парсеру если данных недостаточно, а OffsetDateTime всё-таки нужен. Причём, вот это всё вообще можно вынести в соответствующую утилиту, назвать метод getOffsetDateTimeFromAnyString, и там в комментариях объяснить всю степень редисочности вашей внешней системы, которая меняет формат кодировки дат непредсказуемым образом.
С другой стороны, если вам всегда приходит yyyy-MM-dd, и вам, опять же, всегда нужен оттуда OffsetDateTime на момент начала дня в Мадриде, нет ничего проще:
Ну что вы, право, это же несерьёзно. Никакого масштаба, никаких новых ведомств (ни даже завалящих новых должностей в уже существующих!), не нужно нескольких миллиардов нерублей на разработку (и ещё два-три по столько в год на содержание).
На человечество как-то всё равно, речь про государство.
Вот и писали бы про "ВО вредно для государства" или как-нибудь так. В моём словаре "общество" и "государство", даже не близко расположены.
Если у обоих родителей ВО, то среднее число детей менее 1
А эти цифры берутся снапшотом или на момент конца жизни? Я скорее поверю, что у людей с ВО сдвигается в бо́льшую сторону возраст заведения детей, чем то, что это как-то влияет на их количество. Ну а уже из-за возраста могут быть проблемы с беременностью и родами.
"You bring me the beer" звучит не менее повелительно. Это — форма приказа, а кто "условный я" такой, чтобы приказывать полупьяному члену рабочего класса? Моё мнение — за попытки приказывать незнакомым людям в любой стране и на любом наречии можно поймать дозу кинетической энергии. Попробуйте на русском с кем-нибудь в таком же баре фразу "Вы — метнитесь-ка мне за пивком". Вроде и вежливо обратились, а результат сходу неоднозначный.
Человечеству уже не нужна высокая рождаемость — детская смертность намного ниже, продолжительность жизни в целом тоже. На горизонте всё отчётливее маячит автоматизация труда, и никто не уверен, что второй раз прокатит история с кучерами гужевого транспорта.
В принципе, замещающего воспроизводства уже должно вполне хватать в целом (пока не начнётся колонизация космоса).
Чем этим вашим богатым мужикам брать в жёны 16-летних девушек принципиально более допустимо, чем 15-летних?
Принципиальность состоит исключительно в статусе 16-летнего человека относительно статуса его же в 15 лет. С точки зрения законодательства, не общества, морали и прочих Овертонов.
Если закон убрать, то принцип уловить я тоже не смогу, т.к. всё это строго индивидуально, тут уже на принцип не пойдёшь. История хранит много свидетельств о людях, оставшихся ментально несовершеннолетними несмотря на достижение соответствующего биологического возраста. Это даже в различных поговорках отражено. Точно так же есть и обратные примеры. Вот чтоб всё это пространство вариантов сжать до приемлемых размеров закон и придумали.
Ну вопрос же про признание в РФ, следовательно — по законам РФ. Опять же, по законам сферической страны, заключению брака несовершеннолетие может и не препятствовать. Думаю, как тут выше уже сказали, брак-то будет, а вот секс по-прежнему будет незаконным. Кажется, даже уже прецеденты такие были.
Кстати, стало интересно: будет ли в России признан брак с несовершеннолетним ребёнком, если он заключён в стране, где такое разрешено?
Я слыхал, с однополыми браками такое работает.
А он сын эмигрантов куда?
Я спрашиваю потому, что в англоговорящих странах, к примеру, ко всем обращаются на "вы". Несмотря на то, что "thou" всё ещё часть языка. Так что вопрос не в культуре, а в неправильном объяснении.
JIT и конкретная реализация GC не являются частью Java — они точно такие же расширения, как конструкции у GHC (хоть я и не смогу сказать точнее ввиду отсутствия информации по GHC). Потому в JLS искать их бесполезно.
Большая часть того, что вам будет известно о GC, к примеру, заключено вот на этой странице: https://docs.oracle.com/javase/specs/jls/se12/html/jls-12.html (кстати, обратите внимание, сколько там нудятины) — в остальное время вы знаете только что он "где-то там". В самом деле, не так давно появился No-OP GC, который просто ожидает, что программа не проработает достаточно долго, чтобы отсутствие сборщика вызывало какие-то проблемы, а ОС уж соберёт после процесса как полагается.
JNI это тоже отдельная спецификация. Потому что с точки зрения языка в целом это только единственное ключевое слово, указатель на то, что реализация метода находится "снаружи". Как именно снаружи — шерифа не волнует.
Ну как же не выродились, если всяческие Авраамы, согласно книге, почти все прожили больше ста лет (иногда намного больше) — и это когда медицины, можно сказать, не было. А многих потомков уже к 40 косило только в путь.
Боюсь, что если мы начнём сравнивать де-факто стандарт GHC и его отличия от репорта, то джава по фичам будет выглядеть вообще блекловато
Так а я не говорил про фичи, тут многие языки будут впереди. Зато смотрите: спек Java описывает модель памяти программы (вместе с гарантиями от этой модели), и, например, обратную совместимость, включая различные виду, и что будет, а что не будет обратно совместимо. То есть там немалая часть спека занимается разрешением возможных разночтений, которые бывают у писателей на Java и писателей самой Java.
Если отбросить от комментария user_man эмоции и пассаж по описании библиотек (которого и в спеке Java точно так же нет), я вижу, что HLR это далеко не единственный источник правды — значит ли это, что не всякий текст на Haskell понимается разными компиляторами одинаково? Что насчёт обратной совместимости? Кто и какими средствами сможет гарантировать, что один раз написанная программа будет по-прежнему работать предсказуемо после обновления мажорной версии компилятора, а не станет, например, требовать значительно больше памяти? Что насчёт смены компилятора? Какие гарантии у меня есть в этом случае?
Ну нет, зачем так категорично.
На такие случаи в Java есть модель памяти и синхронизаций, с разграничением на то, что платформа может обещать и чего не может. И если вот в модели говорится, что некое действие строго после — то хоть обоптимизируйся, но придётся потом ждать на мониторе. Зато вот там, где гарантий не давалось, будет самая мякотка. К примеру, вполне может быть, что для итерации по циклу с созданиями объектов внутри — на самом деле не будет создаваться никаких объектов, а может и итерации не будет, несмотря на то, что в исходном коде по этому поводу написано.
А как отсутствие исключений решит эту проблему?
Первый блин Qомом.
Вне интернета это тоже работало, во времена судов Линча. Но разговор как раз не про "вне интернета" — травят-то в интернете. Причём для неокрепших мозгов жертв (и взрослых жертв тоже) напор негатива может оказаться неподъёмным, и где-нибудь зашкалит, а конкретно у детей ведь пофигизма ещё выработалось недостаточно, а ближайшее окружение их зачастую прямо носит на руках.
На взрослых конкретно Cancel Culture срабатывает сейчас ещё и от того, что никому не хочется отбиваться от твиттерных толп, а в разгаре гона оные толпы не чураются нападать не только на прямую жертву, но и на родственников, детей, коллег и работодателей. Которым (особенно работодателям) такое внимание ну вот совсем никуда не впилось. Ну тут скорее всего тоже пока ещё не выработалось достаточно пофигизма, среда-то новая.
Понимаете, какая штука. Улучшение производительности — это, зачастую, тоже регрессия. Потому, к примеру, в стандартной библиотеке Java есть уже несколько версий по-разному работающих классов, абстрагирующих одно и то же, по сути. Потому, что как ни старайся — а иногда код написан с расчётом на сайд-эффекты. Плохо ли это? Разумеется. Но код работал до обновления, и там было вложенное ожидание, что некое действие займёт как минимум 13 миллисекунд, а после обновления функция иногда выполняется за 9, а значит код ломается. Вот такие вещи в Java тоже во многих случаях считаются регрессией. Если что в Haskell — не будут — то это нехорошо для развитого, устаканившегося бизнеса.
На Twitter и в социальных сетях очень хорошо в последнее время работают обвинения в различных -измах. Доказательств особо не требуется, нужны только навыки убедительно играть жертву, толпы получаются — одно загляденье.
Почитать можно начиная вот отсюда:
Wiki:Call-out culture
Urban Dictionary:Cancel Culture
Отсюда достаточно легко, я думаю, перейти к ещё более немотивированным травлям. Всего лишь нужна какая-нибудь достаточно плотная группа по интересам и желание участников разносить негодование в другие группы.
Вот именно, что сдвиг можно элементарно узнать когда вам уже известен момент в UTC и имя зоны. В нашем случае же задача стоит именно в том, чтобы узнать, какой момент UTC закодирован в строке.
Код выглядит громоздко от того, что изначально постановка задачи предполагает, что кто-то должен сделать много допущений. Как вы (должно быть) знаете,
OffsetDateTime— это как раз момент времени, специфическая его форма, когда часовой пояс представлен неким смещением относительно UTC. При этом, в строке"2012-11-30"содержится только дата. То есть, чтобы составить из этой даты момент времени, нам не хватает "всего-то" остатка совы — времени и смещения относительно UTC. Вы кому предлагаете эти данные "родить" — разработчикам стандартной библиотеки, которые о специфике вашей программы ничего не знают? Нет, согласно дизайнуjava.timeдопущений следует делать как можно меньше (в идеале — не делать вообще), и все необходимые данные нужно предоставить разработчику, так как это он лучше должен знать, какие допущения можно делать, а каких — нельзя. Вот второй блок кода как раз этим и занимается, кстати — говорит, что делать парсеру если данных недостаточно, аOffsetDateTimeвсё-таки нужен. Причём, вот это всё вообще можно вынести в соответствующую утилиту, назвать методgetOffsetDateTimeFromAnyString, и там в комментариях объяснить всю степень редисочности вашей внешней системы, которая меняет формат кодировки дат непредсказуемым образом.С другой стороны, если вам всегда приходит
yyyy-MM-dd, и вам, опять же, всегда нужен оттуда OffsetDateTime на момент начала дня в Мадриде, нет ничего проще:Ну что вы, право, это же несерьёзно. Никакого масштаба, никаких новых ведомств (ни даже завалящих новых должностей в уже существующих!), не нужно нескольких миллиардов нерублей на разработку (и ещё два-три по столько в год на содержание).
Вот и писали бы про "ВО вредно для государства" или как-нибудь так. В моём словаре "общество" и "государство", даже не близко расположены.
А эти цифры берутся снапшотом или на момент конца жизни? Я скорее поверю, что у людей с ВО сдвигается в бо́льшую сторону возраст заведения детей, чем то, что это как-то влияет на их количество. Ну а уже из-за возраста могут быть проблемы с беременностью и родами.
"You bring me the beer" звучит не менее повелительно. Это — форма приказа, а кто "условный я" такой, чтобы приказывать полупьяному члену рабочего класса? Моё мнение — за попытки приказывать незнакомым людям в любой стране и на любом наречии можно поймать дозу кинетической энергии. Попробуйте на русском с кем-нибудь в таком же баре фразу "Вы — метнитесь-ка мне за пивком". Вроде и вежливо обратились, а результат сходу неоднозначный.
Человечеству уже не нужна высокая рождаемость — детская смертность намного ниже, продолжительность жизни в целом тоже. На горизонте всё отчётливее маячит автоматизация труда, и никто не уверен, что второй раз прокатит история с кучерами гужевого транспорта.
В принципе, замещающего воспроизводства уже должно вполне хватать в целом (пока не начнётся колонизация космоса).
Принципиальность состоит исключительно в статусе 16-летнего человека относительно статуса его же в 15 лет. С точки зрения законодательства, не общества, морали и прочих Овертонов.
Если закон убрать, то принцип уловить я тоже не смогу, т.к. всё это строго индивидуально, тут уже на принцип не пойдёшь. История хранит много свидетельств о людях, оставшихся ментально несовершеннолетними несмотря на достижение соответствующего биологического возраста. Это даже в различных поговорках отражено. Точно так же есть и обратные примеры. Вот чтоб всё это пространство вариантов сжать до приемлемых размеров закон и придумали.
Ну вопрос же про признание в РФ, следовательно — по законам РФ. Опять же, по законам сферической страны, заключению брака несовершеннолетие может и не препятствовать. Думаю, как тут выше уже сказали, брак-то будет, а вот секс по-прежнему будет незаконным. Кажется, даже уже прецеденты такие были.
Кстати, стало интересно: будет ли в России признан брак с несовершеннолетним ребёнком, если он заключён в стране, где такое разрешено?
Я слыхал, с однополыми браками такое работает.
Как раз вот в примитивных случаях ничего подсказывать не нужно — большая вероятность сделать только хуже.
Ну живём же в информационную эпоху, ну. Всё ведь элементарно найти и проверить:
https://en.wikipedia.org/wiki/Thou#Current_usage — ровно противоположно Вашему утверждению.
А он сын эмигрантов куда?
Я спрашиваю потому, что в англоговорящих странах, к примеру, ко всем обращаются на "вы". Несмотря на то, что "thou" всё ещё часть языка. Так что вопрос не в культуре, а в неправильном объяснении.
JIT и конкретная реализация GC не являются частью Java — они точно такие же расширения, как конструкции у GHC (хоть я и не смогу сказать точнее ввиду отсутствия информации по GHC). Потому в JLS искать их бесполезно.
Большая часть того, что вам будет известно о GC, к примеру, заключено вот на этой странице: https://docs.oracle.com/javase/specs/jls/se12/html/jls-12.html (кстати, обратите внимание, сколько там нудятины) — в остальное время вы знаете только что он "где-то там". В самом деле, не так давно появился No-OP GC, который просто ожидает, что программа не проработает достаточно долго, чтобы отсутствие сборщика вызывало какие-то проблемы, а ОС уж соберёт после процесса как полагается.
JNI это тоже отдельная спецификация. Потому что с точки зрения языка в целом это только единственное ключевое слово, указатель на то, что реализация метода находится "снаружи". Как именно снаружи — шерифа не волнует.
Ну как же не выродились, если всяческие Авраамы, согласно книге, почти все прожили больше ста лет (иногда намного больше) — и это когда медицины, можно сказать, не было. А многих потомков уже к 40 косило только в путь.
Так а я не говорил про фичи, тут многие языки будут впереди. Зато смотрите: спек Java описывает модель памяти программы (вместе с гарантиями от этой модели), и, например, обратную совместимость, включая различные виду, и что будет, а что не будет обратно совместимо. То есть там немалая часть спека занимается разрешением возможных разночтений, которые бывают у писателей на Java и писателей самой Java.
Если отбросить от комментария user_man эмоции и пассаж по описании библиотек (которого и в спеке Java точно так же нет), я вижу, что HLR это далеко не единственный источник правды — значит ли это, что не всякий текст на Haskell понимается разными компиляторами одинаково? Что насчёт обратной совместимости? Кто и какими средствами сможет гарантировать, что один раз написанная программа будет по-прежнему работать предсказуемо после обновления мажорной версии компилятора, а не станет, например, требовать значительно больше памяти? Что насчёт смены компилятора? Какие гарантии у меня есть в этом случае?