M>>Ни в одном. Ты просто не способен понимать, что твои оппоненты пишут.
WH>В одном сообщении ты говоришь, что всё работает на ура.
WH>А в другом говоришь, что сыпятся ошибки типов.

Охохо.

Давай сначала.

Ты утверждаешь, что статическая проверка проверит все и все и не позволит допустить ошибок при смене протокола: «Если бы протокол был статически типизирован и компилятор бил бы по рукам разработчиков, которые пытаются сделать что-то не так, то данного класса проблем бы не было.»

Причем ты моментально вводишь вводишь два условия:
— Нормальные люди не забывают проверять версию протокола при соединении.
— При обновлении кода клиента компилятор будет бить по рукам везде.

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

Два примера, что я приводил в развернутом виде выглядят так:

Пример первый

Наш код вызывает сторонний сервис через клиентскую библиотеку. Сторонний сервис написан на Java (!), клиентская библиотека — на Эрланге.

Клиентская библиотека — это, по сути, один API вызов, который принимает на вход объект X, который проверяется на валидность, и потом отсылается в сторонний сервис.

Пацаны из сервиса по какой-то причине подумали, что этим API-вызовом еще никто не пользуется и решили его улучшить (на самом деле) и заменить поле country_code с целого числа на ISO Alpha 2. И забыли обновить клиентскую библиотеку у нас.

С нашей стороны ничего не изменилось: передаваемый в API объект с точки зрения библиотеки был абсолютно валидным. Она формировала с ее точки зрения абсолютно валидный объект для передачи в сервис. Сервис падал с HTTP 500 и стектрейсом, включающим в себя что-то типа IllegalArgumentException.

Когда мы пришли к пацанам, реализующим сервис с вопросом «какого хрена», они слегка похватались за головы и быстренько выкатили для нас обновление своей библиотеки, которое добавляло конвертацию country_code:integer (который везде используется внутри нашей системы) в ISO Alpha 2 код (используемый сервисом). Код, вызывающий API этой библиотеки не надо было править нигде, от слова вообще. И наступило щастя.

— Каким образом помогла бы стат. типизация, учитывая, что разработчики этого сервиса оказались «ненормальными», и внесли ломающие изменения в протокол без изменения версии и обновления клиентского кода? Да никак, от слова вообще.
— Каким образом помогла бы стат. типизация нашему коду, если клиентская библиотека не обновлена? Да никак, от слова вообще. Да, она бы помогла при условии, если клиентская библиотека обновлена и ее интерфейс поменялся (и такие случаи бывают, и я про это говорил, что тогда стат. типизация весьма желанна).

Пример второй

На этот раз сервис предоставляем мы. На насквозь динамически типизированном эрланге. Но мы оказались, во-первых, «нормальными разработчиками»©™. Любые ломающие обратную совместимость изменения вводятся обязательно с изменением версии. Минимум две предыдущие версии продолжают поддерживаться.

И IllegalArgumentException или что-либо подобное у нас невозможно вообще. Не из-за того, что язык динамически типизированный, а из-за того, что мы:
— проверяем версии протокола
— проверяем соотвествие присылаемых данных заявленной версии

В случае несоответствия данные даже до собственно бизнес-кода не доходят, а возвращается предназначенная для этого ошибка HTTP 400 Bad Request с указанием, где именно проблемы. Еще раз. Это не ошибка из-за того, что в рантайме вместо типа X пришел тип Y, у нас вылетело исключение и мы трепыхаемся. Код, требующий тип X даже не увидит аргумент типа Y, потому что это дело отловит валидатор по схеме на самых ранних подступах.

Так как у нас нет никакого контроля над клиентским кодом, то клиенты будут присылать все, что им в голову взбредет, потому что никто не защищен от «ненормальных разработчиков», кривых рук да и банальной реализации (абсолютно математически выверенной и статически типизированной, и скомпилированной) типа «отсылаем заголовок Content-Type одной версии, а тело запроса — другой».