Вот если бы ещё и в Туле то же самое организовать, было бы вообще отлично. Тут с пробками похуже всё, чем в Новомосковске. И администрация у нас сами как настроят какой-нибудь кривой режим, так всё встаёт конкретно, нет бы нормальных специалистов позвать. Был у меня небольшой опыт общения с ними на эту тему.
Я просто процитировал его коммент, с которым тоже не согласен. Как доказываются теоремы в математике я знаю.
Даже если человек не разбирается в математике и сказал глупость, разве это повод карму ему сливать? Заминусовали коммент и ладно.
Недавно был пост про гипотезу Коллатца, и человек оставил такой коммент:
«Никогда не понимал одержимости математическими доказательствами и профита от них. Вот в данном случае можно было написать скрипт на языке программирования и проверить на практике. Но математиков это не устроит, так как доказательства должны быть по местным понятиям.»
Ему слили карму просто потому что он не разделяет восторга математиков от поиска доказательств гипотез, далёких от практического применения. Это конечно очень справедливо лишать человека возможности комментировать из-за такой его позиции по этому вопросу.
Вот к чему (Deligne (1974, section 8) used the Weil conjectures to prove estimates for exponential sums. (что бы это ни значило)).
Я согласен с тем, что науку надо развивать ради науки, но при условии что такое развитие приводит к какому-то результату (доказательству гипотезы или более простое изложение существующей теории). А в чём ценность теории, которая пока выглядит как жонглирование абстракциями? Вот он формулирует алгебру на базе своей теории, а сможет ли он получить какие-то новые результаты в алгебре, если даже с таким базовым понятием как ассоциативность возникли такие сложности.
Вот Мотидзуки, например, построил свою новую теорию (но хотя бы не просто так, а с целью доказательства abc-гипотезы), но пока результата не получил. Какова ценность его теории?
Что-то я не понял, принесёт ли эта теория какие-то результаты? Вот его с Гротендиком сравнивают — развитие Гротендиком алгебраической геометрии привело, например, к доказательству гипотез Вейля. А здесь что? Поможет ли эта теория какую-нибудь гипотезу доказать?
Я так понял что они работают над precise GC, чтобы точно отличать при сборке мусора ссылку от набора битов, но сделать сборку мусора с поколениями это не поможет. И параллельную сборку мусора в другом потоке они тоже сделать не смогут по причине отсутствия write barrier. Только stop the world и полная сборка.
Про тесты не знаю, но я так понимаю что сборщики мусора в C# и Java достаточно хороши
Потому что GC в D медленный. Причина в том что в D не стали вводить write barrier, аргументируя это тем что это приведёт к снижению производительности, которое непозволительно для системного языка программирования. А без write barrier нельзя сделать сборщик мусора с поколениями. Поэтому в D каждая сборка мусора — это полная сборка мусора.
А если GC отключить, то тогда нельзя использовать некоторые конструкции языка типа ренджей, лямбд по-моему тоже, и стандартной библиотекой тоже нельзя было пользоваться в этом случае, так как она использовала такие конструкции (возможно её уже отвязали от GC).
Правильно ли я понимаю, что этот HoTT нужен для того чтобы формализовать математические теоремы, то есть перевести их на этот язык типов, чтобы программно можно было проверить что доказательство теоремы верно? А если так, то можно ли тогда программно найти доказательство какой-нибудь открытой гипотезы, например, путём перебора всех возможных доказательств?
Вопрос. Допустим я продал биткоин и теперь должен заплатить налог с прибыли. Как мне указать это в налоговой декларации? Может ли налоговая заинтересоваться происхождением этого биткоина? Вдруг мне его террористы/иностранные агенты прислали, которые так меня финансируют?
Это должно быть напечатано крупным шрифтом на главной странице вашего статического анализатора.
Причём тут вообще наш анализатор? Он не имеет отношения к этому обсуждению.
Это ничего, что речь идет не об освобождении ресурсов, а о сохранении изменений?
Этот пример про StreamWriter к тому что если финализатор создаст больше потенциальных проблем чем пользы, то от него стоит отказаться. Solved там в кавычках разумеется не просто так, а потому что проблема на самом деле ни разу не solved. Вот что им мешало сбросить недозаписанные байты в файл в финализаторе? Да ничего не мешало, технически это можно сделать, вот только выстрелить себе в ногу при этом очень просто, поэтому и не стали.
Никто не обязан освобождать неуправляемые ресурсы в финализаторе.
Прежде чем бросаться добавлять финализаторы для всех классов, реализующих IDisposable, стоит подумать, а действительно ли они так нужны…
Я так написал, потому что если вы зайдёте на страницу IDisposable в MSDN, например, то там сразу и пример, в котором используется Dispose() вместе с финализатором. И некоторые программисты просто берут и копируют этот пример к себе, а когда спрашиваешь у них зачем тут финализатор, отвечают — потому что паттерн такой.
Сразу скажу, что Reactive Extensions я никогда не использовал, поэтому могу ошибаться. Я так понял что IDisposable, который возвращается из Subscribe, нужен для того чтобы потом отписаться от нотификаций через вызов Dispose(), а в RxJava аналогичный метод называется unsubscribe(). То есть если мне не нужно отписываться, то я могу и не звать Dispose(). Я не уверен что они правильно выбрали интерфейс IDisposable для этих целей, потому что IDisposable предполагает что ресурс в конце надо задиспозить, а здесь вроде как можно этого и не делать, что сбивает с толку и приводит вот к таким вопросам To Dispose or not to Dispose, that is the question?
Никто не обязан освобождать неуправляемые ресурсы в финализаторе. Если я считаю что финализатор принесёт больше проблем чем пользы, то я могу вообще его не добавлять, а возложить всё это на плечи того кто использует мой объект. В качестве примера вот вам цитата из вашей статьи: «The StreamWriter class owns a Stream object; StreamWriter.Close will flush its buffers and then call Stream.Close. However, if a StreamWriter was not closed, its finalizer cannot flush its buffers. Microsoft „solved“ this problem by not giving StreamWriter a finalizer, hoping that programmers will notice the missing data and deduce their error.»
Так я и не предлагаю писать финализаторы, и тем более обращаться там к стриму.
MemoryStream реализует IDisposable, но не держит неуправляемый ресурс только потому что он является наследником Stream. А если бы он не был его наследником, то и IDisposable у него реализовывать смысла не было бы. Если у вас есть просто Stream и вы не знаете что там, ну или в общем случае объект, реализующий IDisposable, то следует предполагать что там внутри может оказаться неуправляемый ресурс, и поэтому нужно в конце явно позвать Dispose() у этого объекта.
Я не согласен с тем, что закрыть хэндл это проблемы стрима. Это проблемы того кто использует стрим — освободить его через Dispose().
Умные светофоры могут быть настроены так чтобы давать приоритет ОТ
Даже если человек не разбирается в математике и сказал глупость, разве это повод карму ему сливать? Заминусовали коммент и ладно.
«Никогда не понимал одержимости математическими доказательствами и профита от них. Вот в данном случае можно было написать скрипт на языке программирования и проверить на практике. Но математиков это не устроит, так как доказательства должны быть по местным понятиям.»
Ему слили карму просто потому что он не разделяет восторга математиков от поиска доказательств гипотез, далёких от практического применения. Это конечно очень справедливо лишать человека возможности комментировать из-за такой его позиции по этому вопросу.
Я согласен с тем, что науку надо развивать ради науки, но при условии что такое развитие приводит к какому-то результату (доказательству гипотезы или более простое изложение существующей теории). А в чём ценность теории, которая пока выглядит как жонглирование абстракциями? Вот он формулирует алгебру на базе своей теории, а сможет ли он получить какие-то новые результаты в алгебре, если даже с таким базовым понятием как ассоциативность возникли такие сложности.
Вот Мотидзуки, например, построил свою новую теорию (но хотя бы не просто так, а с целью доказательства abc-гипотезы), но пока результата не получил. Какова ценность его теории?
Про тесты не знаю, но я так понимаю что сборщики мусора в C# и Java достаточно хороши
А если GC отключить, то тогда нельзя использовать некоторые конструкции языка типа ренджей, лямбд по-моему тоже, и стандартной библиотекой тоже нельзя было пользоваться в этом случае, так как она использовала такие конструкции (возможно её уже отвязали от GC).
Причём тут вообще наш анализатор? Он не имеет отношения к этому обсуждению.
Этот пример про StreamWriter к тому что если финализатор создаст больше потенциальных проблем чем пользы, то от него стоит отказаться. Solved там в кавычках разумеется не просто так, а потому что проблема на самом деле ни разу не solved. Вот что им мешало сбросить недозаписанные байты в файл в финализаторе? Да ничего не мешало, технически это можно сделать, вот только выстрелить себе в ногу при этом очень просто, поэтому и не стали.
Вот вам ещё мнение Эрика Липперта по поводу финализаторов:
Sharp Regrets: Top 10 Worst C# Features
When everything you know is wrong, part one
When everything you know is wrong, part two
This feature is confusing, error-prone, and widely misunderstood.… And in most cases, use of the feature is dangerous, unnecessary, or symptomatic of a bug.
It is therefore very difficult indeed to write a correct finalizer, and the best advice I can give you is to not try.
Я так написал, потому что если вы зайдёте на страницу IDisposable в MSDN, например, то там сразу и пример, в котором используется Dispose() вместе с финализатором. И некоторые программисты просто берут и копируют этот пример к себе, а когда спрашиваешь у них зачем тут финализатор, отвечают — потому что паттерн такой.
Никто не обязан освобождать неуправляемые ресурсы в финализаторе. Если я считаю что финализатор принесёт больше проблем чем пользы, то я могу вообще его не добавлять, а возложить всё это на плечи того кто использует мой объект. В качестве примера вот вам цитата из вашей статьи: «The StreamWriter class owns a Stream object; StreamWriter.Close will flush its buffers and then call Stream.Close. However, if a StreamWriter was not closed, its finalizer cannot flush its buffers. Microsoft „solved“ this problem by not giving StreamWriter a finalizer, hoping that programmers will notice the missing data and deduce their error.»
MemoryStream реализует IDisposable, но не держит неуправляемый ресурс только потому что он является наследником Stream. А если бы он не был его наследником, то и IDisposable у него реализовывать смысла не было бы. Если у вас есть просто Stream и вы не знаете что там, ну или в общем случае объект, реализующий IDisposable, то следует предполагать что там внутри может оказаться неуправляемый ресурс, и поэтому нужно в конце явно позвать Dispose() у этого объекта.
Я не согласен с тем, что закрыть хэндл это проблемы стрима. Это проблемы того кто использует стрим — освободить его через Dispose().