Так это, значит, утка, что там на некоторых дорогах даже для грузовиков 100 — это нижний порог, а не верхний? Ну, тогда понятнее, — останется только вопрос обслуживания такого количества коммуникаций.
Это ведь всё же не несколько погасших фонарей, что плохо, но не смертельно, т.к. у каждого автомобиля есть собственный источник света и габаритные огни. Тут это уже равносильно огромной пробке из грузовиков, либо фактическому требованию для условного грузовика всё равно иметь возможность проехать весь путь на собственной батарее.
Ничего удивительного — ведь имеют же телеком-операторы немалый "доход" от подписок гаражных ворот на рассылку старых анекдотов. А так можно будет напрямую, без всяких подписок — клиент сам позвонил на горячую службу и оформил пожертвование в адрес компании, вот и запись имеется.
… причём часто никто из съёмочной команды на самом деле не знает досконально, какие именно эмоции и микроэмоции им в действительности нужны. И не только эмоции — целые фразы, диалоги. В интернете гуляет огромное количество подборок удачных (культовых, даже) сцен из фильмов, которых в сценарии не было — они были импровизациями актёров.
Само собой, всё в итоге может поменяться, но это уже будет утверждение о том, что когда-нибудь будет разработан полноценный ИИ. Ну, когда-нибудь, наверное, будет. Когда-нибудь мы, наверное, и чайник Рассела обнаружим.
Как там с износом таких проводов на скоростях тягачей от 120 км/ч? Не получится как с той дорогой из фотоэлементов? Или это будут отдельные трассы с более низкой максимальной скоростью?
Я по-прежнему думал, что мы там обсуждаем проблему консистентности данных, старый я дурак, а не синтаксические конструкции, которые заставят разработчика обработать исключительные ситуации (а пустой Option это такое же исключение, только вы ещё и не знаете, почему так произошло, пока код не запустите на точно тех же самых данных). Потому что так-то в языках с исключительными ситуациями тоже можно заставить разработчика обработать ваше исключение — и он иногда даже сделает настоящую обработку, основываясь на данных, которые возможно получить из "формы" объекта исключения. То есть, всё то же самое, что и с различными return-кодами, типа Option, Try, и проч.
Так вот, исходя из проблемы консистентности данных любая форма такого Halt это куда хуже так нелюбимых нынче исключений.
что кто-то может начать опираться на конкретный порядок записей в MVar общую между потоками переменную
Это всё, к сожалению, по моему впечатлению, происходит достаточно часто — когда пытаются выжать последние соки из текущей среды исполнения, там могут быть любые грязные хаки. Я, впрочем, согласен, что под такой код что-то делать в спецификации будет ошибкой — достаточно просто указать, с какого момента компилятору разрешено считать программиста "ЗБ".
Ну так и ты им можешь физически навредить точно так же. Это сдерживает обе стороны от физического конфликта, ведь эскалация на самом-то деле никому не выгодна. Потому стараются либо просто словами, либо по-мелочи портят имущество. В интернете никому навредить невозможно (вы и сами согласились), и вот ответить всей толпе на том же уровне невозможно — для этого нужно отвечать лично, и просто не хватит времени в сутках. А инструменты вроде закрытия страницы — уровень уже "продвинутого пользователя", думаю, школьники их осваивают много позже, либо не осваивают вовсе (времена, конечно, меняются).
среднестатистический юзер никогда не назовёт его важным, потому что вообще не задумывается о его существовании
А я думаю не поэтому — а потому, что это программа, которая "тихонечко" кушает его батарейку. Я понял бы ещё антивирус, который сам ставишь и/или выбираешь, ну или хотя бы понимаешь, что он вот прямо сейчас работает (и можешь выбрать время запуска), но так вот — не очень красиво. В конце концов, почему этот защитник работает на моём устройстве, а не на серверах, откуда я приложения скачиваю и устанавливаю — неужели нет доверия собственному магазину?
Ничего такого делать не нужно. Потеря пользователей — сам по себе достаточный стимул. Люди со временем сами покажут, насколько наличие тёмных тем важно. Или не важно.
Ну да, а на этот случай прямо в спеке языка написано "А мы всегда говорили, что результат непредсказуемый". Вы сейчас боретесь с частью утверждения, мне кажется, тогда как исходная идея как раз состоит в том, что в спеке Java есть история многих споров между разработчиками хост-JVM и чего-нибудь энтерпрайзно-банковского. А в спеке Хаскеля, как я понимаю — этого нет, из чего я делал предположение, что там это со временем появится, если язык наберёт популярность.
У этих отношений в целом нет хороших примеров из взаимодействий предметов реальной жизни. Разве что-нибудь вроде испускания и регистрации фотонов в двух релятивистских системах отсчёта. И то не уверен.
Суть-то в том, что у каждого потока собственное время, которое не обязано в общем случае течь так же, как у кого-то ещё.
Самый читаемый вариант тут всё же- MaxBy(...) или MinBy(...). И этот же вариант как раз даёт нужный профиль исполнения — это ж вообще праздник, согласитесь.
Одноклассники в школе — это такие же внешние комментаторы, как в интернете, только одноклассники в школе, а люди из интернета — почти вездесущи, так как в интернете сейчас люди проводят очень много времени. А строгие учителя, всё-таки, явление другого плана, и от них, опять же, проще себя оградить.
высказывания в интернете всегда воспринимаются с изрядной долей скептицизма
Это у вас, во многом, кстати, из-за прошлых нападок в школе. Учитывая, что случаи вплоть до самоубийств таки были — не все насколько же скептичны.
Если бы они действительно заботились о бабушках — не убирали бы кнопки, так-то. У бабушек как раз статистически потребность в кнопках выше, причём не на уровне "неудобно", а вплоть до непонимания, как там вообще хоть что-то теперь сделать.
Если мешает модель памяти, то либо ничего не в итоге ускорилось (потому что более быстрый процесс в итоге парковался и ждал более медленный), либо вам и не обещали, что это будет работать. То есть для части случаев самой спекой регламентирован ответ Won't Fix на некоторые сообщения о "багах".
Именно так вот выбросить — не может (вернее, ему запрещено так делать).
Если же поведение программы после оптимизации не поменялось (X ускорилось на 4мс, но при этом и Y тоже ускорилось на [4,..)мс, так что всё равно happens-before(X, Y)) — то может, но и программа при этом не сломается. Собственно, в этом и заключается вся суть таких отношений и вообще необходимости вводить модель памяти.
Простите, но это — фантастика в языке с командой "а теперь, детишки, падаем в корку" (i.e. halt). В конце концов, f может попытаться выделить память, которой ему не дали — и что, будем везде иметь как возвращаемое значение гигатип Result, одним из вариантов которого будет Result::OOM? И возвращаемое значение конструктора типа T канонически запишем как Either<T, Result::OOM>?
Если человек написал var a = Foo() а функция Foo кидает эксепшн, вы никогда не узнаете, ошибся он и забыл обработчик написать, или надо тут эксепшн обрабатывать
Мне, на самом деле, не интересно, что думал человек, когда не поймал исключение. Как и то, что он думал, когда поймал что-то, что не следовало. Мне больше интересно, что про это исключение говорит внешний контур его модуля, что вообще за тип исключения у меня на руках, и что об этом всём думает архитектор.
Некоторые такие исключения, кстати, вполне можно показать пользователю, потому что ошибка легальная, и нашими силами не исправляется (максимум, что можно сделать — локализацию сообщения). Некоторые — бессмысленно, так как это банальный баг, и надо просто починить код.
Нет, а вот проблему "у нас было изменение состояния в i и j, но потом злобный k бросил исключение, надо теперь обратить i и j" — как решит отсутствие исключений?
Разве отсутствующие исключения не позволят таких ситуаций создавать? Да вроде нет, для этого всего-то надо мутабельное состояние, и в языке оно есть — более того, в языке есть вообще бич любых попыток что-то откатить — переприсваивание значений локальных переменных, переданных по ссылке внутрь j, когда вы уже и не знаете даже, менялось там хоть что-то или нет (мы ведь о чёрных ящиках рассуждаем, раз уж я не могу заглянуть в Foo, или проследить, какие потоки вызовов ведут ко мне извне).
Если у вас раньше была функция, возвращающая результат, а теперь она бросает эксепшн
Вот прямо вдруг бросает? Хорошо, а если я так же вдруг поменяю тип возвращаемого значения на Either<a, b>, но в коде не обработан случай с b (ну, написано там Foo().left, ну так вот) — это разве такой же проблемы не вызовет?
Нет, именно всякоразличных умолчаний там практически нет. Пожалуй, кроме возможности получить XxxDateTime.now(),
которое, по сути, XxxDateTime.now(Clock.system(ZoneId.systemDefault())
(время по системным часам в часовом поясе машины).
Нет, те поймите неправильно, из той исходной строки, вы сможете без всяких проблем распарсить LocalDate. Но вот на случай с недостающими данными, когда нужно больше полей, чем год, месяц, день и epoch-day — увы.
Если вы из просто даты всегда хотите получать момент в UTC (не Лондоне!) на начало суток, то самое простое что я могу придумать — это сделать один раз соответстующий парсер со значениями по умолчанию. Как-то так
new DateTimeFormatterBuilder()
// или append(DateTimeFormatter.ISO_LOCAL_DATE)
.appendPattern("yyyy-MM-dd")
.parseDefaulting(ChronoField.NANO_OF_DAY, 0)
.withZone(ZoneOffset.UTC)
.build();
Это достаточно делать один раз и сохранить в статическое поле — новые парсеры, в отличие от старого SimpleDateFormat потокобезопасные. Но вот "умолчаний" в парсерах нет. Они даже часовой пояс машины не используют — потому что если парсер дёргать из нескольких потоков и вдруг кому-то придёт в голову светлая идея поменять TimeZone.default… я думаю, вы понимаете.
Так это, значит, утка, что там на некоторых дорогах даже для грузовиков 100 — это нижний порог, а не верхний? Ну, тогда понятнее, — останется только вопрос обслуживания такого количества коммуникаций.
Это ведь всё же не несколько погасших фонарей, что плохо, но не смертельно, т.к. у каждого автомобиля есть собственный источник света и габаритные огни. Тут это уже равносильно огромной пробке из грузовиков, либо фактическому требованию для условного грузовика всё равно иметь возможность проехать весь путь на собственной батарее.
Ничего удивительного — ведь имеют же телеком-операторы немалый "доход" от подписок гаражных ворот на рассылку старых анекдотов. А так можно будет напрямую, без всяких подписок — клиент сам позвонил на горячую службу и оформил пожертвование в адрес компании, вот и запись имеется.
… причём часто никто из съёмочной команды на самом деле не знает досконально, какие именно эмоции и микроэмоции им в действительности нужны. И не только эмоции — целые фразы, диалоги. В интернете гуляет огромное количество подборок удачных (культовых, даже) сцен из фильмов, которых в сценарии не было — они были импровизациями актёров.
Само собой, всё в итоге может поменяться, но это уже будет утверждение о том, что когда-нибудь будет разработан полноценный ИИ. Ну, когда-нибудь, наверное, будет. Когда-нибудь мы, наверное, и чайник Рассела обнаружим.
Как там с износом таких проводов на скоростях тягачей от 120 км/ч? Не получится как с той дорогой из фотоэлементов? Или это будут отдельные трассы с более низкой максимальной скоростью?
Я по-прежнему думал, что мы там обсуждаем проблему консистентности данных, старый я дурак, а не синтаксические конструкции, которые заставят разработчика обработать исключительные ситуации (а пустой Option это такое же исключение, только вы ещё и не знаете, почему так произошло, пока код не запустите на точно тех же самых данных). Потому что так-то в языках с исключительными ситуациями тоже можно заставить разработчика обработать ваше исключение — и он иногда даже сделает настоящую обработку, основываясь на данных, которые возможно получить из "формы" объекта исключения. То есть, всё то же самое, что и с различными return-кодами, типа Option, Try, и проч.
Так вот, исходя из проблемы консистентности данных любая форма такого Halt это куда хуже так нелюбимых нынче исключений.
Это всё, к сожалению, по моему впечатлению, происходит достаточно часто — когда пытаются выжать последние соки из текущей среды исполнения, там могут быть любые грязные хаки. Я, впрочем, согласен, что под такой код что-то делать в спецификации будет ошибкой — достаточно просто указать, с какого момента компилятору разрешено считать программиста "ЗБ".
Ну так и ты им можешь физически навредить точно так же. Это сдерживает обе стороны от физического конфликта, ведь эскалация на самом-то деле никому не выгодна. Потому стараются либо просто словами, либо по-мелочи портят имущество. В интернете никому навредить невозможно (вы и сами согласились), и вот ответить всей толпе на том же уровне невозможно — для этого нужно отвечать лично, и просто не хватит времени в сутках. А инструменты вроде закрытия страницы — уровень уже "продвинутого пользователя", думаю, школьники их осваивают много позже, либо не осваивают вовсе (времена, конечно, меняются).
А я думаю не поэтому — а потому, что это программа, которая "тихонечко" кушает его батарейку. Я понял бы ещё антивирус, который сам ставишь и/или выбираешь, ну или хотя бы понимаешь, что он вот прямо сейчас работает (и можешь выбрать время запуска), но так вот — не очень красиво. В конце концов, почему этот защитник работает на моём устройстве, а не на серверах, откуда я приложения скачиваю и устанавливаю — неужели нет доверия собственному магазину?
Ага, и сами себя тоже забанят.
Ничего такого делать не нужно. Потеря пользователей — сам по себе достаточный стимул. Люди со временем сами покажут, насколько наличие тёмных тем важно. Или не важно.
Ну да, а на этот случай прямо в спеке языка написано "А мы всегда говорили, что результат непредсказуемый". Вы сейчас боретесь с частью утверждения, мне кажется, тогда как исходная идея как раз состоит в том, что в спеке Java есть история многих споров между разработчиками хост-JVM и чего-нибудь энтерпрайзно-банковского. А в спеке Хаскеля, как я понимаю — этого нет, из чего я делал предположение, что там это со временем появится, если язык наберёт популярность.
У этих отношений в целом нет хороших примеров из взаимодействий предметов реальной жизни. Разве что-нибудь вроде испускания и регистрации фотонов в двух релятивистских системах отсчёта. И то не уверен.
Суть-то в том, что у каждого потока собственное время, которое не обязано в общем случае течь так же, как у кого-то ещё.
Самый читаемый вариант тут всё же-
MaxBy(...)илиMinBy(...). И этот же вариант как раз даёт нужный профиль исполнения — это ж вообще праздник, согласитесь.Одноклассники в школе — это такие же внешние комментаторы, как в интернете, только одноклассники в школе, а люди из интернета — почти вездесущи, так как в интернете сейчас люди проводят очень много времени. А строгие учителя, всё-таки, явление другого плана, и от них, опять же, проще себя оградить.
Это у вас, во многом, кстати, из-за прошлых нападок в школе. Учитывая, что случаи вплоть до самоубийств таки были — не все насколько же скептичны.
Если бы они действительно заботились о бабушках — не убирали бы кнопки, так-то. У бабушек как раз статистически потребность в кнопках выше, причём не на уровне "неудобно", а вплоть до непонимания, как там вообще хоть что-то теперь сделать.
Если мешает модель памяти, то либо ничего не в итоге ускорилось (потому что более быстрый процесс в итоге парковался и ждал более медленный), либо вам и не обещали, что это будет работать. То есть для части случаев самой спекой регламентирован ответ Won't Fix на некоторые сообщения о "багах".
Именно так вот выбросить — не может (вернее, ему запрещено так делать).
Если же поведение программы после оптимизации не поменялось (
Xускорилось на 4мс, но при этом иYтоже ускорилось на [4,..)мс, так что всё равноhappens-before(X, Y)) — то может, но и программа при этом не сломается. Собственно, в этом и заключается вся суть таких отношений и вообще необходимости вводить модель памяти.Простите, но это — фантастика в языке с командой "а теперь, детишки, падаем в корку" (i.e.
halt). В конце концов, f может попытаться выделить память, которой ему не дали — и что, будем везде иметь как возвращаемое значение гигатипResult, одним из вариантов которого будетResult::OOM? И возвращаемое значение конструктора типаTканонически запишем какEither<T, Result::OOM>?Мне, на самом деле, не интересно, что думал человек, когда не поймал исключение. Как и то, что он думал, когда поймал что-то, что не следовало. Мне больше интересно, что про это исключение говорит внешний контур его модуля, что вообще за тип исключения у меня на руках, и что об этом всём думает архитектор.
Некоторые такие исключения, кстати, вполне можно показать пользователю, потому что ошибка легальная, и нашими силами не исправляется (максимум, что можно сделать — локализацию сообщения). Некоторые — бессмысленно, так как это банальный баг, и надо просто починить код.
Это же язык следующего поколения. Это язык назвал своего автора в честь себя.
Нет, а вот проблему "у нас было изменение состояния в i и j, но потом злобный k бросил исключение, надо теперь обратить i и j" — как решит отсутствие исключений?
Разве отсутствующие исключения не позволят таких ситуаций создавать? Да вроде нет, для этого всего-то надо мутабельное состояние, и в языке оно есть — более того, в языке есть вообще бич любых попыток что-то откатить — переприсваивание значений локальных переменных, переданных по ссылке внутрь j, когда вы уже и не знаете даже, менялось там хоть что-то или нет (мы ведь о чёрных ящиках рассуждаем, раз уж я не могу заглянуть в
Foo, или проследить, какие потоки вызовов ведут ко мне извне).Вот прямо вдруг бросает? Хорошо, а если я так же вдруг поменяю тип возвращаемого значения на
Either<a, b>, но в коде не обработан случай сb(ну, написано тамFoo().left, ну так вот) — это разве такой же проблемы не вызовет?Нет, именно всякоразличных умолчаний там практически нет. Пожалуй, кроме возможности получить
XxxDateTime.now(),которое, по сути,
XxxDateTime.now(Clock.system(ZoneId.systemDefault())(время по системным часам в часовом поясе машины).
Нет, те поймите неправильно, из той исходной строки, вы сможете без всяких проблем распарсить
LocalDate. Но вот на случай с недостающими данными, когда нужно больше полей, чем год, месяц, день и epoch-day — увы.Если вы из просто даты всегда хотите получать момент в UTC (не Лондоне!) на начало суток, то самое простое что я могу придумать — это сделать один раз соответстующий парсер со значениями по умолчанию. Как-то так
Это достаточно делать один раз и сохранить в статическое поле — новые парсеры, в отличие от старого
SimpleDateFormatпотокобезопасные. Но вот "умолчаний" в парсерах нет. Они даже часовой пояс машины не используют — потому что если парсер дёргать из нескольких потоков и вдруг кому-то придёт в голову светлая идея поменятьTimeZone.default… я думаю, вы понимаете.