Топик о возможностях и проблемах статической типизации
Я тут на скале попробовал написать код, чтобы компилятор знал про размерности как в системе СИ, и догадывался, что скорость, поделённая на время — это ускорение. И не давал его складывать с чем-нибудь другим.
(Сам пост тут, сори мне лень из маркдауна в форумный вид форматировать, может потом попробую, да и статья немножкно не об этом).
Так вот, идея размерностей проиходят на физике в шестом классе. Компиляторы развиваются полвека как минимум.
Но почему, блин, я такую относительно простую концепцию смог записать только в довольно простом виде только сейчас и на немейнстримном языке?
На части языков это невозможно, на части языков придётся через числа Чёрча изобретать арифметику заново и писать нечитаемый код. Ещё на С++ на шаблонах можно, но сам по себе С++ можно назвать одним большим извращением.
А казалось бы задача не сложная — параметризовать шаблонный тип целыми числами и делать арифметические операции в compile time. Всё.
(Сам пост тут, сори мне лень из маркдауна в форумный вид форматировать, может потом попробую, да и статья немножкно не об этом).
Так вот, идея размерностей проиходят на физике в шестом классе. Компиляторы развиваются полвека как минимум.
Но почему, блин, я такую относительно простую концепцию смог записать только в довольно простом виде только сейчас и на немейнстримном языке?
На части языков это невозможно, на части языков придётся через числа Чёрча изобретать арифметику заново и писать нечитаемый код. Ещё на С++ на шаблонах можно, но сам по себе С++ можно назвать одним большим извращением.
А казалось бы задача не сложная — параметризовать шаблонный тип целыми числами и делать арифметические операции в compile time. Всё.
На части языков это делается через перегрузку оператора, а на части без него. Не понимаю сути проблемы равно, как и прикладной пользы от такого способа записи. По сути ты, всё равно, перед рассчётами любого физического явления, сначала всё сводишь к удобным скалярам для удобного вычисления и потом считаешь. Покажи пример, где это реально полезно.
Вместо вот такого, я вижу более удобным что-то вот такое:
Правила умножения-деления величин с размерностями в абстрактном виде одни и те же. В java я могу на дженериках сделать числа Пеано типа `Value<Zero, Next<Next>, Negate<Next>`, но это будет извращение и вместо этого начинаются извращения с венгерской нотацией типа long timeMs; double speedKmh; и т.п.
А минусы будут?
в джаве тем более это экономия аллокаций.
ну типа да, ты можешь случайно смешать красное с липким, но от ошибок тебя не застрахуют полностью даже проверки на адекватность комбинаций.
Опять же, имхо, настоящая проблема в ЯП это читаемость кода, а ещё важнее читаемость многопоточного и асинхронного кода. А вот эти все вещи типа «а какой иерархией типов и перегрузками мне выразить мою идеальную модель», за решением таких паззлов это к хаскеллу и прочим функциональщикам. Т.е. кодить не за деньги.
В реальной жизни ты:
1) чтобы не ошибиться в вычислениях тестируешь код
2) если тебе надо вычислить физ величину ты просто её вычисляешь. ты не думаешь.
1) неправильный канкаренси код
2) неэффективные структуры данных
3) решение выдуманных проблем
Если человек называет себя сеньором но при этом не может атомарно работать с конкурентной мапой, а прод «не упал» только потому что ревьюер уже в сотый раз смог это заметить…
А по поводу второго, это зависит от задач. Я тут задушнил не спорю, потому что в 99% случаев тебе будет достаточно простого решения. но в случае где его недостаточно… из недавних примеров, замена EnumMap на ConcurrentHashMap просто чтобы «па-быстраму» сделать класс тред-сейф положила кластер. А вот это на ревью пролетело к сожалению.
По поводу третьего это прямо моя личная жопоболь, когда ты встречаешь в коде воздушный замок который какой-то челик построил сто лет назад. А тебе нужно там что-то поменять. По итогу проблема добавить одно поле в POJO превращается в путешествие туда и обратно только потому что кто-то до тебя решил что тут нужно байткодогенерацию зафигачить.
Сорри за оффтоп уже конкретный от сабжа.
Это два разных типа с разными свойствами. Например, timeSpan можно умножить на число, а дату — бессмысленно. Или например сумма timeSpan + date это date, а сумма date + date это некий объект, который датой не является.
Т.е., чуваки догадались до полезности разных типов, но пишут их всё ещё руками — отдельно Date и отдельно TimeSpan.
Эта разница вылазит в проективной геометрии, когда точку записывают (x, y, z, 1), а вектор как (x, y, z, 0), тогда матрица вращения крутит и то и то, а матрица трансляции двигает только точку.
но тут же всё логично — так работает линал
холиварная тема, но именно из-за неё в джаве например от перегрузок отказались.
то есть если ты будешь читать какой-то код без возможности быстро прыгнуть в дефинишены, тебе вариант с конструкторами или методами подойдёт гораздо больше.
так что логично что тебе нужно их перечислить будет. и самому описать правила их взаимодействия.
кроме того, с конструктором ты получишь как бонус невозможность попутать местами время и расстояние.
мы же прикладные кодеры народ простой — нам джейсончик переложить и изредка литкод порешать.
а академической работой пусть занимаются учёные на грантах. а от изобретения до индустриального применения проходит какое-то время.
ну к примеру тот же paxos. очень сложный капец, поэтому придумали raft для решения задачек попроще.