Зачем нужна статическая типизация?, или Вы всё врете!

/me грустно пишет struct’ы для Go, а хочется как-то так:

kubectl get secret some-config -o json | jq -r '."data"."config.yaml"'|base64 -d

(в большой джейсонине все поля кроме нужного проигнорированы).

строго статически типизированная вообще падать не будет.

Что, даже не скомпилируется?

ИМХО логические ошибки, много «каверзней».
Бывает код выглядит как «правильный», а при тщательном анализе
выявляются немало не только логических ошибок, но и кривоватость алгоритма в целом.

Шутка

Используем try и все ошибки нам не страшны.

Пожалуй, в этом суть.

Скучно выписывать классы и сигнатуры методов и продумывать иерархии.

Куда веселее окунуться с головой в увлекательный и неизведанный мир стектрейсов по обращениям к несуществующим методам и полным тайн и адреналина падениям на проде.

А как известно, за имитацию бурной деятельности можно стрясти больше бабла.

Смысл статической типизации в том, чтобы неправильный код не выглядел как правильный с точки зрения компилятора. Даже если разработчику показалось иначе.

Разные подходы и системы типов - это попытки придумать всё более мощный язык описания этой неправильности. Начиная от простейшей типизации в Си и заканчивая всякими системами зависимых типов.

Это метаязык, язык над языком, который призван в формальной логике задавать соотношения предметной области так, чтобы машина была способна проверить рассуждения автора и найти в них ошибку.

Ничуть не скучно. Когда задача не ложится на типы и приходится использовать жёсткий матан, это очень весело.

Шутка

В 1С можно компилятору можно подсунуть хоть корень квадратный из объекта и он ругаться не будет.
Просто удивительно, но в 1С при этом несложно писать вполне корректный код, а ошибки run-time быстро исправляются.

Или к примеру, обращение через точку типа:

 Дуракам  = "";
 VpДураки = "";

 VpДураки = Дуракам.Закон.Не.Писан;

И компилятор считает этот код вполне корректным.

А Вам всем видите-ли Python не такой.
Радуйтесь!

а в хаскеле есть что-то, что не укуренный матан?

Вычисление факториалов!

Или к примеру, обращение через точку типа

К примеру, в 1С и Python этот код будет не работать одинаково. Узбагойтесь, Владимир.

Профдеформация, как и было сказано. Подсказка: «IDE не дополняет дополнения» — это не проблема реального мира.

Да при чем здесь ИДЕ? Такое чувство, что тебе вообще насрать, что тебе говорят, ты заранее приготовил остроумные (как тебе кажется) высказывания и постишь их по порядку.

Вот пример из собственной практики. Есть довольно старый проект, который переписывали пару лет назад с 2.7, в процессе переписывания выяснилась удивительная вещь. Функция выглядела примерно так:

def create_key(metrics):
   """
      :type metrics: tuple(str, str, str) 
   """
   return "".join(get_metric_key(m) for m in metrics)

Когда добавили аннотации типов, mypy внезапно заругался на вызывающий код, оказалось, что в одном из модулей вместо кортежа в функцию подавался первый элемент кортежа. Функция без малейшего сомнения итерировалась по строке и применяла get_metric_key к символам строки, тоже без колебаний. В итоге, мы получали промахи кеша. Не критичная ошибка, но неприятная.

давай, скажи мне, что в твоём чудесном коде такое невозможно и «IDE не дополняет дополнения»

Всё, что ложится на его систему типов пишется просто прекрасно: всякого рода преобразование текстов, списков, формул, вычисления…

С учётом типа Dynamic, там можно и динамическую типизацию использовать. Но когда хочется выразить то, что легко выражается в Typed Racket, а система типизации заставляет это делать через какие-то вспомогательные структуры, грустно.

Да при чем здесь ИДЕ?

Ну, надо же чем-то пробить вашу упёртость. Впрочем, я сдаюсь. Когда хаскеллист пытается выразить на типах сложную систему ограничений это ещё интересно обсудить. А вам желаю всего хорошего.

Я стар. Не пори чушь. А перловикам вообще под 60

Я кстати так и не понял нахрена нужны «type hints», все равно в рантайме они не проверяются. Похоже на еще один вариант комментариев.

Это комментарии для линтера.

Проверка перед использованием - и правда зачем нам это.

Это когда в чужой огород да со своим уставом.

Оно нам и ненадово вовсе, как выше по треду завещали, настоящий погроммист никогда с параметрами методов не ошибается. А кто ошибается, тот ненастоящевый. А от этих проверок заморских один только расход CPU впустую и порча экологии.

Я скорее про то что каждой задаче свой инструмент, а не про идеальных разработчиков.

А так, к вопросу об идеальных писателях - пишешь код, который будет использоваться не только тобой - будь добр обложиться тестами, ты же в динамике, хоть и строгой.

вот так читаешь и сразу чувствуешь государственного человека! быть тебе спикером нижней палаты парламента… до что там нижней! сразу верхней и председателем всех комитетов.

Мда, баш офигенный пример. Наверное его распространение связано исключительно с его удобством, а вовсе не с тем, что другого ничего лучше не было.

А можно пример, когда статическая типизация мешает?

Отсутствие статической типизации так или иначе вынуждает применять другие методики/инструменты для компенсации этого отсутствия, а потом гордо заявлять, что она не нужна. При отсутствии ложки можно и руками поесть, нафиг вообще эти ложки.

Самое банальное: Зачем нужна статическая типизация?, или Вы всё врете! (комментарий) Вы скажете, это ерунда, и я даже соглашусь. Но бесит.

В Typescript, например, бывают совершенно издевательскіе ошибки node_modules/path/to/type != node_modules/another/path/to/this/type. И вместо решения реальной проблемы приходится плясать вокруг компилятора. Особенно доводит, когда компилятор ты ублажил, но программа всё равно валится, потому что внезапно в одном из аккаунтов ты упёрся в лимиты AWS.

В Хасскелле (когда-то я делал подход к этому снаряду), жутко не понравилось, что программа должна быть корректно типизирована вся целиком, даже когда я этого не хочу. В процессе разработки я сам ещё не знаю как должен выглядеть результат, поэтому мне нужно делать много маленьких экспериментов. Я хочу из всей программы изменить пару функций и посмотреть как они себя поведут на определённых данных. Хрен тебе, золотая рыбка, переписывай половину функций, иначе не скомпилирую! Соответственно цикл идея→проверка→вывод замедляется и результат в целом становится хуже.

Один мальчик однажды взял в руки молоток. С тех пор любая проблема кажется ему гвоздём.

нужно делать много маленьких экспериментов

Лишь Истинный Светоч Поможет.

Такая же проблема была с гошечкой, без репла как без рук.

Выглядит так, что на Хаскеле надо было учиться по-другому разрабатывать программы. Я не утверждаю, что это будет так же быстро, как с REPL driving development 😊. Сильная статика делает код сильно связанным, что плюс, когда мы не можем обрушить его целиком изменениями в одном месте программы — потому что придётся не в одном месте это делать, чтоб статика это позволила сделать, но если мы хотим намеренно временно ввести систему в нестабильное положение, получая от этого определённую выгоду, мы не можем этого сделать.

Этот вывод, по крайней мере, полезен. Хотелось бы еще штангистов послушать по этому вопросу, желательно КМС как минимум.

Возможно это чисто психологическая особенность. Как с иностранными языками. Кому-то (мне) проще научиться говорить простые фразы, а потом как-то их комбинировать, расширять словарный запас, учиться строить более сложные предложения. При этом ты общаешься практически сразу, но первое время разговариваешь как чурка. А кто-то штудирует всю грамматику целиком, а потом начинает разговаривать правильно. Разные головы различно устроены.

Аналогия хорошая, но таких людей

А кто-то штудирует всю грамматику целиком, а потом начинает разговаривать правильно.

практически не бывает. Как и штангистов 🙂.

В Хаскеле тоже есть REPL: GHCi называется.

Если «Я хочу из всей программы изменить пару функций и посмотреть как они себя поведут на определённых данных.», то просто даю изменённым функциям новые имена. Ведь в остальном коде их всё равно пока нельзя использовать.

Да, есть небольшая дополнительная работа, если меняешь синтаксис типа. Например, передавал просто String и было

f uuid = ... uuid ...

Стал передавать newtype стало

f (UUID uuid) = ... uuid ...

Стал передавать data с 16 байтами

f buuid =
  let uuid = show buuid in ... uuid ...

Дальше от внутреннего устройства типа уже ничего не меняется.

И типы надо именовать, тогда сигнатура f будет вообще неизменной:

f :: UUID -> ...

В первом случае с String должно быть

type UUID = String

Сказал хер, который вообще понятия не имеет о чем говорит. Впрочем обычно для лора

Ты ответил только на мою аналогию, а что относительно первой части предложения?

Я хочу из всей программы изменить пару функций и посмотреть как они себя поведут на определённых данных. Хрен тебе, золотая рыбка, переписывай половину функций, иначе не скомпилирую!

А что поменять то хотел? Тип параметров? Возвращаемый?

Соответственно цикл идея→проверка→вывод замедляется и результат в целом становится хуже.

Т.е. этот довод в пользу того, что на языках с ДТ только MVP писать и идеи проверять?

В Typescript, например, бывают совершенно издевательскіе ошибки

Пока TS не имеет собственного интерпретатора - это обвес для js. Вот когда будет, тогда может быть будет иначе.

Узбагойтесь, Владимир.

Этот код ни в одном ЯП нормально работать не будет, но 1С такой синтаксис считает корректным.

«Узбагойся» аноним и не злобствуй.

Шутка

За это мы 1С любим, ценим и в обиду не дадим.
Для меня всё же «загадка», почему в 1С non problem с компилятором.

В Хаскеле тоже есть REPL: GHCi называется.

Видел, когда трогал хаскелль. Признаться, не понял тогда, зачем оно (хотя я и в питоне-то не особо репл люблю: вводишь функцию, ошибся => вывалился экзепшен и вводи всё заново; однострочник проверить какой, не более того).

И типы надо именовать, тогда сигнатура f будет вообще неизменной:

f :: UUID -> ...

В первом случае с String должно быть

type UUID = String

Это «алиасы», насколько я понимаю. Есть такое, удобная штука.

Спасибо Вам за этот тред.

Ещё много чего полезного можно сказать по теме треда.
Всё ещё впереди!

Зато при обращении у полям статических структур они (поля) там точно будут.

Признаться, не понял тогда, зачем оно (хотя я и в питоне-то не особо репл люблю: вводишь функцию, ошибся => вывалился экзепшен и вводи всё заново; однострочник проверить какой, не более того).

По нормальной схеме REPL должен использоваться в связке с IDE. leksah и Emacs умеют.

Тогда написал функцию, в REPL тут же погонял тесты, что она делает то, что ожидается. Потом из REPL скопировал в авто-тесты, чтобы при рефакторинге не поломалось.

Ещё в REPL удобно типы получать. Пишешь функцию, тип не указываешь. То есть просто

f x y z = ...

Потом в REPL пишешь:

:t f

и видишь наиболее общий тип, который подходит под тело функции. Дальше его либо копируешь как есть, либо уточняешь.

leksah

Лет -ть назад устанавливал — интерфейс разъезжался за края экрана, снес, очень понравилось. Судьба ☺️.

Помню, мне запомнился Hackage (если не путаю название сервиса) своей идеей: забил нужную сигнатуру, тебе выдает библиотечную функцию, которая делает, что тебе нужно.

но 1С такой синтаксис считает корректным

Как и Python (нужно только убрать точки с запятой). Что ты пытаешься этим сказать?

однострочник проверить какой, не более того

Или ознакомиться с библиотечным методом. Удобно, когда можно быстро посмотреть глазами на возвращаемое значение, поэкспериментировать с аргументами.

https://hoogle.haskell.org/

Сейчас новый тренд - «Забор в Австралии»!

Шутка

Это «статическая типизация» на государственном уровне.

Это нерешительность и боязнь ошибок, возведенные в абсолют