О технической и прочей культурности
Feb. 27th, 2023 10:54 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bowhillНедавно была запись о сложном времени, изменениях в принципах устройства UTC.* На неё я получил интересный комментарий в FB, который, в свою очередь, получил множество хороших откликов. Вообще комментариев много, но этот текст вполне развёрнутый.
https://www.facebook.com/daniel.dbg.ginsburg/posts/10230444406915196
Что здесь для меня интересного я и хотел бы рассказать, Даниила я не знаю, так что далее о том, что он сам и сказал.
Принципы
Начнём с двух высказываний:
«3. Следует проявлять эпистемологическую скромность. Есть вещи, которые мы не знаем. Не надо стесняться в этом признаться» и «Автор поленился сделать хоть какие-то численные прикидки, поэтому сделаем за него».
В этих высказываниях две проблемы. Во-первых, Даниил сам не пользуется принципами, которые провозглашает. Он ничего не знает обо мне, о чём сам и говорит: пост какого-то чувака. И тут же пишет, что я поленился сделать хоть какие-то прикидки. Во-вторых, не видит внутренней противоречивости своих собственных высказываний.
Далее, судя по датам и ссылкам, он наверное видел саму запись и разговор о UTC и TAI. То есть, я как бы знаю об этих шкалах, но, видимо, не знаю в чём между ними разница и какова она. Это смело, но неверно.
Инженерные принципы
Посмотрим другие предложенные признаки.
«2. Следует пересматривать требования к решению. Вполне возможно, что мы решаем несуществующую задачу».
Что же, верный тезис. Но что же должно из этого следовать в контексте именно этого обсуждения? Что любое изменение будет более удачным решением? Маловероятно, что именно это подразумевалось.
Или что именно мы знаем и определяем требования любых проектов и решаем задачи для всех и за всех? Тоже, наверное, маловероятно, если озвучивать таким образом.
«1. Следует проверять качественные модели количественными методами. Объяснения на пальцах хороши, но расчеты лучше».
И это верно. Тем более, что дальше следуют количественные оценки. Но что из этого должно следовать в терминах упрощения и уменьшения точности UTC?
Есть и другой принцип: точность результата определяется точностью наших измерений. И если написать результат 2,7182345678 ±10, то это будет демонстрацией технической неграмотности.
Теперь вернёмся к требованиям и пересмотрам. Так что же, у нас теперь стабильно понижаются требования к точности? Не особо. Структуры timespec и timeval определяют значения с точностью до нано- и микросекунд, java.time.LocalTime – наносекунды, .NET DateTime – 0,1 us.
Но о какой точности в микросекундах мы говорим, если мы теперь желаем игнорировать секунды десятками? И какая шкала у нас теперь будет? Астрономическая, атомная, линейная, координированная?
И здесь можно сделать лирическое отступление. Сколько прошло секунд с 1955 года мы как-то себе представляем. А сколько прошло секунд с 1900-01-01 – мы не знаем, не говоря уже о 0001-01-01. И говоря или используя разные шкалы и механизмы в программировании, люди не всегда понимают, что именно они делают, предлагают и получают. Но, бывает, что определяют требования и решения для широкого спектра проблем.
Сложности программирования и вычисления
Для чего вообще надо менять принципы и точность UTC? Здесь может быть много разных ответов. Один из них – для упрощения жизни программистов и компьютеров. Но можно вспомнить, что за последние 50 лет программисты с задачей дополнительной секунды справлялись. На PDP, IBM S/370, x86.
И что же, это теперь единственный способ – всё бросить и забить? Всё бросить уже не получится, ретроспективно дополнительные секунды уже есть. И повторюсь, если вам и вашим процессам удобнее работать с TAI – можно пользоваться этой шкалой.
И кому-то, со временем, придётся всё это переделывать и чинить, и не через тысячу лет.
***
Наверное, можно обойтись без дополнительных секунд, наверное, можно обойтись и без инженеров. Наверное, можно заменить принципы на «и так сойдёт». Наверное, будет весело.
Развитие и игноранс – разные процессы, такая эпистемология.
---
* «О сложном времени». https://bowhill.dreamwidth.org/381192.html (2023.02.21)
https://www.facebook.com/daniel.dbg.ginsburg/posts/10230444406915196
Что здесь для меня интересного я и хотел бы рассказать, Даниила я не знаю, так что далее о том, что он сам и сказал.
Принципы
Начнём с двух высказываний:
«3. Следует проявлять эпистемологическую скромность. Есть вещи, которые мы не знаем. Не надо стесняться в этом признаться» и «Автор поленился сделать хоть какие-то численные прикидки, поэтому сделаем за него».
В этих высказываниях две проблемы. Во-первых, Даниил сам не пользуется принципами, которые провозглашает. Он ничего не знает обо мне, о чём сам и говорит: пост какого-то чувака. И тут же пишет, что я поленился сделать хоть какие-то прикидки. Во-вторых, не видит внутренней противоречивости своих собственных высказываний.
Далее, судя по датам и ссылкам, он наверное видел саму запись и разговор о UTC и TAI. То есть, я как бы знаю об этих шкалах, но, видимо, не знаю в чём между ними разница и какова она. Это смело, но неверно.
Инженерные принципы
Посмотрим другие предложенные признаки.
«2. Следует пересматривать требования к решению. Вполне возможно, что мы решаем несуществующую задачу».
Что же, верный тезис. Но что же должно из этого следовать в контексте именно этого обсуждения? Что любое изменение будет более удачным решением? Маловероятно, что именно это подразумевалось.
Или что именно мы знаем и определяем требования любых проектов и решаем задачи для всех и за всех? Тоже, наверное, маловероятно, если озвучивать таким образом.
«1. Следует проверять качественные модели количественными методами. Объяснения на пальцах хороши, но расчеты лучше».
И это верно. Тем более, что дальше следуют количественные оценки. Но что из этого должно следовать в терминах упрощения и уменьшения точности UTC?
Есть и другой принцип: точность результата определяется точностью наших измерений. И если написать результат 2,7182345678 ±10, то это будет демонстрацией технической неграмотности.
Теперь вернёмся к требованиям и пересмотрам. Так что же, у нас теперь стабильно понижаются требования к точности? Не особо. Структуры timespec и timeval определяют значения с точностью до нано- и микросекунд, java.time.LocalTime – наносекунды, .NET DateTime – 0,1 us.
Но о какой точности в микросекундах мы говорим, если мы теперь желаем игнорировать секунды десятками? И какая шкала у нас теперь будет? Астрономическая, атомная, линейная, координированная?
И здесь можно сделать лирическое отступление. Сколько прошло секунд с 1955 года мы как-то себе представляем. А сколько прошло секунд с 1900-01-01 – мы не знаем, не говоря уже о 0001-01-01. И говоря или используя разные шкалы и механизмы в программировании, люди не всегда понимают, что именно они делают, предлагают и получают. Но, бывает, что определяют требования и решения для широкого спектра проблем.
Сложности программирования и вычисления
Для чего вообще надо менять принципы и точность UTC? Здесь может быть много разных ответов. Один из них – для упрощения жизни программистов и компьютеров. Но можно вспомнить, что за последние 50 лет программисты с задачей дополнительной секунды справлялись. На PDP, IBM S/370, x86.
И что же, это теперь единственный способ – всё бросить и забить? Всё бросить уже не получится, ретроспективно дополнительные секунды уже есть. И повторюсь, если вам и вашим процессам удобнее работать с TAI – можно пользоваться этой шкалой.
И кому-то, со временем, придётся всё это переделывать и чинить, и не через тысячу лет.
***
Наверное, можно обойтись без дополнительных секунд, наверное, можно обойтись и без инженеров. Наверное, можно заменить принципы на «и так сойдёт». Наверное, будет весело.
Развитие и игноранс – разные процессы, такая эпистемология.
---
* «О сложном времени». https://bowhill.dreamwidth.org/381192.html (2023.02.21)
Re: Петька, приборы
Date: 2023-03-08 04:39 am (UTC)хренасе у тебя память! :)
я этот эпизод 2019 года забыл на 100%.