Говорят, что любая аксиоматическая формальная система либо не полна, либо противоречива. Т.е. в ней либо есть хоть одно невыводимое утверждение, либо вы получите какую-нибудь тавтологию. В этом не ни чего фундаментального, просто особенность популярного метода все формализовать, записывая рассуждения буковками и составлять из них какие-нибудь теории.
На практике с неполнотой мириться проще. Обычно выбирают так, что под невыводимое подпадают какие-то второстепенные вещи, которые нас не особо затрагивают при решении практических задач. Я думаю, что так называемая проблема остановки это частный пример такого случая, примерно к машине Тьюринга.
Пусть нельзя в рамках этого формализма доказать остановится программа или нет, зато можно много другое. Вон там в блокчейне крипты намайнить или коммент на Хабре написать. Кого в самом деле волнует когда все это закончится? В общем переживём как нибудь (хотя у людей своя проблема - жизнь отдельных особей всегда когда-нибудь точно останавливается).
Объективная реальность - не только результат общественного консенсуса, но и результат, подкрепленный рядом доказательств
Что есть доказательства как не результат консенсуса? Одни сведения принимаются, другие - нет. Но в итоге все сводится к некоему набору критериев, относительно которых какие-то люди договорились между собой считать их мерилом истинности.
Чтобы выделить особую значимость, к названию обычно добавляют слово фундаментальные. Но достаточно посмотреть в историю, чтобы увидеть как этот самый фундамент только и делает что шатается, разрушается и заменяется новым.
Я работаю в айти и регулярно вижу как одни и те же решения могут трактоваться совершенно по-разному и даже прямо противоположно, в зависимости от контекста и текущей конъюнктуры. Да я и сам в этом уже почти профи и многие вещи могу как разнести в пух и прах, так и наоборот продать как что-то крайне ценное. Естественно все трактовки сопровождая набором доказательств.
По аналогии, мы затратим энергию и растянем/сожмём резиновый мячик, но мячик не перестанет существовать.
Объективная реальность это результат общественного консенсуса. Физика предложила удобный и практичный инструмент для его достижения, что попутно дало толчок развитию технологий. И любого кто считает иначе, по общему мнению наверняка объявят сумасшедшим. Но это сами по себе технологии не решают всех человеческих проблем, а могут даже и усугублять. Состояние мира или войны за окном, размер ставки по ипотеке, или настроение любимой - вещи для нас не менее объективные, чем свет звезды за на ночном небе, прошедший сотни тысяч световых лет (считать ее и по сей день существующей или её уже давно нет - как договоритесь).
Просто в языках с динамической типизацией, к коим относится и JS, типы связаны со значениями в рантайме и по-другому не бывает.
В теории, если разделять понятия Model of computation и Execution model, то можно говорить о корректности программы - с точки зрения алгоритма (где для проверки на помощь приходит логика, в т.ч. автоматика в виде статического код анализа и тайп чекеров), и с точки зрения рантайма - как о связанных, но не тождественных понятиях. В этом смысле система типов в TS и особенности исполнения JS вещи ортогональные.
Тип Undefined явно лишний, гораздо логичней было бы выбрасывать исключение при попытке прочитать несуществующее поле или неинициализированную переменную, но Брендан Айк пошел по другому пути, впрочем, винить его за это сложно
В первых версиях JS не было поддержки исключений и undefined в результате по замыслу был равносилен ошибке. Если в ваших вычислениях или данных появился undefined, то все дальнейшие манипуляции это UB. Поэтому иметь в результатах undefined считалось плохой практикой (хотя на практике с этим можно жить, до поры до времени, - ваши примеры с JSON и lodash в этом смысле показательны).
В дальнейшем это было несколько раз переосмыслено. Был период, когда void(0) в коде вызывал неодумение. Потом стал паттерном в порядке вещей. Потом придумали разные optional (arguments, chaining и т.п.), сделав вычисления с undefined вполне легитимными. В результате имеем то, что имеем.
Причём Optional позволяет описывать гораздо более сложные ситуации, чем null, благодаря тому что его можно сколько угодно раз друг в друга вкладывать.
У автора вылезла проблема при сериализации структуры данных в JSON. Как вы посоветуете представлять в этом формате Optional? А для ситуации когда они вложены друг в друга?
Если глобализация все же продолжится, то со временем к чему-то такому и придем. Я работаю с распределенными командами. Для коротких интервалов удобно использовать относительное время (собираемся через 30 минут, а не во столько-то часов, что каждый будет трактовать по-своему). Для чего-то регулярного или глобального наружу используется UTC.
Технически, каждый хост живёт в некотором своем текущем времени. В линуксах есть уже почти десяток констант, сильно меняющих представление о нем, в зависимости от вопроса. 3600 это 3600 секунд, а что такое через час и во сколько это будет - уже вопросы консенсуса. Причем часто ответа в рамках хоста не достаточно - нужен глобальный консенсус (в рамках всей вашей системы).
Если у вас есть актуальные фотографи нужных площадок и территория хорошо знакома, то оценивать обстановку со свободными местами на них можно и глазками, с помощью естественного интеллекта.
Дальше в задаче для парковок, где нет четких границ расположения авто, появляются чисто субъективные моменты. Такие как габариты конкретной машины, или водительский опыт запарковаться. Для одних место может показаться недостаточным, а другие сочтут его свободным.
Значит, в теории, они теперь могут экономить и на гриме, просто дорисовывая макияж вместо того, чтобы платить актерам за часы в гримёрке? Там же целая индустрия останется не у дел.
Возможно, для задачи сбора метрик лучше бы подошла time series database, а не rdbms. Разные типы баз данных предлагают разные модели работы с этим самыми данными, что отражается и в языках запросов.
В рамках теории.
Говорят, что любая аксиоматическая формальная система либо не полна, либо противоречива. Т.е. в ней либо есть хоть одно невыводимое утверждение, либо вы получите какую-нибудь тавтологию. В этом не ни чего фундаментального, просто особенность популярного метода все формализовать, записывая рассуждения буковками и составлять из них какие-нибудь теории.
На практике с неполнотой мириться проще. Обычно выбирают так, что под невыводимое подпадают какие-то второстепенные вещи, которые нас не особо затрагивают при решении практических задач. Я думаю, что так называемая проблема остановки это частный пример такого случая, примерно к машине Тьюринга.
Пусть нельзя в рамках этого формализма доказать остановится программа или нет, зато можно много другое. Вон там в блокчейне крипты намайнить или коммент на Хабре написать. Кого в самом деле волнует когда все это закончится? В общем переживём как нибудь (хотя у людей своя проблема - жизнь отдельных особей всегда когда-нибудь точно останавливается).
Что есть доказательства как не результат консенсуса? Одни сведения принимаются, другие - нет. Но в итоге все сводится к некоему набору критериев, относительно которых какие-то люди договорились между собой считать их мерилом истинности.
Чтобы выделить особую значимость, к названию обычно добавляют слово фундаментальные. Но достаточно посмотреть в историю, чтобы увидеть как этот самый фундамент только и делает что шатается, разрушается и заменяется новым.
Я работаю в айти и регулярно вижу как одни и те же решения могут трактоваться совершенно по-разному и даже прямо противоположно, в зависимости от контекста и текущей конъюнктуры. Да я и сам в этом уже почти профи и многие вещи могу как разнести в пух и прах, так и наоборот продать как что-то крайне ценное. Естественно все трактовки сопровождая набором доказательств.
Объективная реальность это результат общественного консенсуса. Физика предложила удобный и практичный инструмент для его достижения, что попутно дало толчок развитию технологий. И любого кто считает иначе, по общему мнению наверняка объявят сумасшедшим. Но это сами по себе технологии не решают всех человеческих проблем, а могут даже и усугублять. Состояние мира или войны за окном, размер ставки по ипотеке, или настроение любимой - вещи для нас не менее объективные, чем свет звезды за на ночном небе, прошедший сотни тысяч световых лет (считать ее и по сей день существующей или её уже давно нет - как договоритесь).
Вообще вопрос "покажите .." подразумевает ответ в виде именно показывания конечного результата, а не объяснение как бы вы это делали. ;)
Просто в языках с динамической типизацией, к коим относится и JS, типы связаны со значениями в рантайме и по-другому не бывает.
В теории, если разделять понятия Model of computation и Execution model, то можно говорить о корректности программы - с точки зрения алгоритма (где для проверки на помощь приходит логика, в т.ч. автоматика в виде статического код анализа и тайп чекеров), и с точки зрения рантайма - как о связанных, но не тождественных понятиях. В этом смысле система типов в TS и особенности исполнения JS вещи ортогональные.
по-хорошему Parse, don’t validate.
В первых версиях JS не было поддержки исключений и undefined в результате по замыслу был равносилен ошибке. Если в ваших вычислениях или данных появился undefined, то все дальнейшие манипуляции это UB. Поэтому иметь в результатах undefined считалось плохой практикой (хотя на практике с этим можно жить, до поры до времени, - ваши примеры с JSON и lodash в этом смысле показательны).
В дальнейшем это было несколько раз переосмыслено. Был период, когда void(0) в коде вызывал неодумение. Потом стал паттерном в порядке вещей. Потом придумали разные optional (arguments, chaining и т.п.), сделав вычисления с undefined вполне легитимными. В результате имеем то, что имеем.
У автора вылезла проблема при сериализации структуры данных в JSON. Как вы посоветуете представлять в этом формате Optional? А для ситуации когда они вложены друг в друга?
Отлично. Ждём ebuild'ов.
Они это не совсем так считают, точнее даже совсем не так: https://docs.github.com/en/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces. В остальном похоже на
рекламуправду.Если глобализация все же продолжится, то со временем к чему-то такому и придем. Я работаю с распределенными командами. Для коротких интервалов удобно использовать относительное время (собираемся через 30 минут, а не во столько-то часов, что каждый будет трактовать по-своему). Для чего-то регулярного или глобального наружу используется UTC.
В полночь по местному времени или по Москве?
https://man7.org/linux/man-pages/man2/clock_gettime.2.html
Технически, каждый хост живёт в некотором своем текущем времени. В линуксах есть уже почти десяток констант, сильно меняющих представление о нем, в зависимости от вопроса. 3600 это 3600 секунд, а что такое через час и во сколько это будет - уже вопросы консенсуса. Причем часто ответа в рамках хоста не достаточно - нужен глобальный консенсус (в рамках всей вашей системы).
У сеньера были свои счёты со временем.
Если у вас есть актуальные фотографи нужных площадок и территория хорошо знакома, то оценивать обстановку со свободными местами на них можно и глазками, с помощью естественного интеллекта.
Дальше в задаче для парковок, где нет четких границ расположения авто, появляются чисто субъективные моменты. Такие как габариты конкретной машины, или водительский опыт запарковаться. Для одних место может показаться недостаточным, а другие сочтут его свободным.
Значит, в теории, они теперь могут экономить и на гриме, просто дорисовывая макияж вместо того, чтобы платить актерам за часы в гримёрке? Там же целая индустрия останется не у дел.
Теперь понятно. А почему не подходит key-value?
Возможно, для задачи сбора метрик лучше бы подошла time series database, а не rdbms. Разные типы баз данных предлагают разные модели работы с этим самыми данными, что отражается и в языках запросов.
Вряд-ли вы имели ввиду разработку программного обеспечения с открытыми исходниками.