Не хватает историй про то, как Валера разобравшись в бизнесе, рассказал заказчику, что тому уже год пудрят мозги и ушел работать к нему напрямую. А Гоша разобравшись в бизнесе, открыл свою фирму, уведя у прежнего работодателя часть клиентов.
Инженерные задачи от абстрактно логических отличаются там, что решаются всегда в ограничениях. Веб работает начиная с допотопных телефонов, телевизоров и вплоть до мощных ПК. Наши бекендеры если время поджимает то и дело норовят перетащить куски логики на фронтенд потому, что тут разрабатывать в разы проще и быстрее.
Там другие типы. AOT и JIT оптимизации дополнят друг друга, между ними нет противоречий. JIT выводит типы (hidden classes) на основе реальных данных, а не каких-то абстрактных описаний. Это дает дополнительные очки.
WASM является многообещающей технологией уже много лет, как замена JS, но пока используется лишь в нишевых решениях.
По моим наблюдениям, в веб хорошо живется текстовым протоколам и открытым решениям. Бинарные заняли какие-то свои узкие ниши, но остаются маргиналами в этой среде.
А представьте, сколько времени можно сэкономить, не проверяя постоянно типы в рантайме!
Проверка типов на старте программы это дополнительные секунды, когда пользователь результат не видит. Есть ненулевая вероятность, что большая часть поанализированного кода вообще не будет востребована на странице. В вебе идет борьба за микросекунды, поэтому все что можно отложить, откладывается до того момента, пока оно реально не понадобится. С дальнейшей оптимизацией хорошо справляется JIT.
Если вам нужен анализ кода и AOT — делайте это на сервере, один раз во время сборки для продакшена. Тащить все вот это в браузеры ваших пользователей нет ни какого смысла.
JavaScript в современном веб это по сути универсальный ассемблер. В свое время были попытки продвинуть другие языки: Visual Basic, Python, Dart и т.п. — результат мы знаем. Серьезно, корпорации были готовы вкладывать большие деньги в технологии и маркетинг. Но чисто экономически от нативной поддержки второго, третьего и так далее языка в браузере поверх того же рантайма нет ни какой пользы.
Статическая проверка типов удобна для разработки, но зачем ее тащить в продакшен? У популярных сайтов десятки миллионов посещений в день. Каждый пользователь загружает один и тот же код. Выполнять в браузерах пользователей такие проверки по сто раз на дню это бесполезная трата ресурсов и лишние секунды для старта страницы. Отдавайте валидный код.
Написать альтернативный рантайм, который будет кроссплатформенным, быстрым, безопасным и удобным для разработки это крайне сложная инженерная задача. В эпоху продвижения аплетов, флеша и сильверлайт сообщения о критических уязвимостях выходили чуть-ли не каждую неделю. Долгая компиляция и проблемы с отладкой кода так же играли не в пользу таких решений. Про кроссплатформенность то и дело сочиняли анекдоты.
Сейчас вы можете писать код практически в любой парадигме, транслировать результат в JS, с большой долей уверенности, что он будет выполнен везде. Хотите берите местные решения: Closure, TypeScript, PureScript, Elm и т.п. Не хотите, можете попробовать LLVM.
Короче, попытка в исходном комментарии хорошая, но, увы, устаревшая лет на 30 (или когда там Хиндли-Милнера изобрели)
А мне понравилось, прямо в точку. Хиндли-Милнер выводит общие типы. Инструмент для графоманов, чтобы налить в текст больше воды и абстрактных рассуждений. Но ведь порой так хочется конкретики.
Были же попытки завести — сначала Java applets, потом Silverlight. Как видим, ни то и не другое не выжило в браузерах, вчистую проиграв конкуренцию JS, по вполне объективным причинам.
Надежность это комплексная метрика, имеющая ненулевую цену. Всегда нужно искать узкое место. У меня есть возможность наблюдать развитие проекта, где используется больше десятка разных языков и технологий. Баги, тех.долг, легаси, проблемы с перфомансом, неоднозначности во входных данных, ошибки интерпретации требований, изменчивость ситуации, ротация инженеров и тому подобные прелести есть везде.
Скорость исправления ошибок в основном зависит от того, насколько просто человеку разобраться в проблеме и локализовать изменение. Мудреные решения не всегда этому способствуют, скорее даже наоборот. Самое накладное в поддержке большого проекта, на мой взгляд, это knowledge sharing. Поэтому, чем проще решение — тем лучше даже если оно на идрисе.
The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).
Так, что она напрямую связана со статической типизацией.
Что-то вы не туда. Вопрос был не про типизацию как таковую, а про динамическую типизацию, когда типы определяются в рантайме. JIT оптимизации используется не только в скриптовых языках, но и во многих компилируемых со статической типизацией — Java, C# и т.п. Это как раз следствие того, что системы типов обладают ограниченной выразительностью, оставляя массу возможностей получать дополнительный выигрыш, анализируя реальные данные.
Написать можно что угодно на чем угодно, только нужно-ли? Поэтому одно из возможных решений — не создавать себе проблемы. Но если интересно заморочиться, то зав.типы в последнее время опять активно копают. Думаю 0xd34df00d про это лучше расскажет.
Динамическая типизация нужна там, где вычисления определяются данными.
Например JavaScript. :) Если смотреть с точки зрения рантайма, то благодаря динамической типизации экономится куча времени на старте программы, которую бы в противном случае приходилось делать браузеру для анализа корректности программы при каждой загрузке скриптов.
С позиции разработчика — формулы в Excel, bash, lua и прочие встраиваемые сценарии — где полезный эффект будет ничтожным по сравнению с трудозатратами на дополнительные церемонии с типами.
Тут подвох в другом. Это выглядит очевидным лишь для простых случаев. Развивая идею дальше, вводя чуть более сложные теоремы и их доказательства, вы упретесь в интересную математику.
Например, пусть в функцию суммирования прилетают два числа с ограничением 0 < Int < INT_MAX & Int <> 42. Что будет корректным типом для результата? Чтобы вывести, компилятор должен знать кое-что о целых числах, свойствах операции сложения и, возможно, переполнении.
Реальный код, как правило, будет еще чуть более сложным, чем эта функция сложения. Даже если математика сойдется, то вы вряд-ли будете довольным временем, которое тратится на компиляцию.
Все заморочки делятся на две категории: задачи и научные проблемы. Первые решаются понятным способом. У последних либо нет общего решения, либо есть множество альтернативных.
Все существующие системы типов обладают ограниченной выразительностью. Поэтому рано или поздно это становится проблемой (например wiki.c2.com/?ExpressionProblem). В таком случае прагматики выбирают инструмент по задаче, а фанатики идут искать себе новую работу чтобы смешить народ дальше.
По моим наблюдениям, в веб хорошо живется текстовым протоколам и открытым решениям. Бинарные заняли какие-то свои узкие ниши, но остаются маргиналами в этой среде.
Если вам нужен анализ кода и AOT — делайте это на сервере, один раз во время сборки для продакшена. Тащить все вот это в браузеры ваших пользователей нет ни какого смысла.
Статическая проверка типов удобна для разработки, но зачем ее тащить в продакшен? У популярных сайтов десятки миллионов посещений в день. Каждый пользователь загружает один и тот же код. Выполнять в браузерах пользователей такие проверки по сто раз на дню это бесполезная трата ресурсов и лишние секунды для старта страницы. Отдавайте валидный код.
Написать альтернативный рантайм, который будет кроссплатформенным, быстрым, безопасным и удобным для разработки это крайне сложная инженерная задача. В эпоху продвижения аплетов, флеша и сильверлайт сообщения о критических уязвимостях выходили чуть-ли не каждую неделю. Долгая компиляция и проблемы с отладкой кода так же играли не в пользу таких решений. Про кроссплатформенность то и дело сочиняли анекдоты.
Сейчас вы можете писать код практически в любой парадигме, транслировать результат в JS, с большой долей уверенности, что он будет выполнен везде. Хотите берите местные решения: Closure, TypeScript, PureScript, Elm и т.п. Не хотите, можете попробовать LLVM.
Скорость исправления ошибок в основном зависит от того, насколько просто человеку разобраться в проблеме и локализовать изменение. Мудреные решения не всегда этому способствуют, скорее даже наоборот. Самое накладное в поддержке большого проекта, на мой взгляд, это knowledge sharing. Поэтому, чем проще решение — тем лучше
даже если оно на идрисе.Так, что она напрямую связана со статической типизацией.
Например JavaScript. :) Если смотреть с точки зрения рантайма, то благодаря динамической типизации экономится куча времени на старте программы, которую бы в противном случае приходилось делать браузеру для анализа корректности программы при каждой загрузке скриптов.
С позиции разработчика — формулы в Excel, bash, lua и прочие встраиваемые сценарии — где полезный эффект будет ничтожным по сравнению с трудозатратами на дополнительные церемонии с типами.
Например, пусть в функцию суммирования прилетают два числа с ограничением
0 < Int < INT_MAX & Int <> 42. Что будет корректным типом для результата? Чтобы вывести, компилятор должен знать кое-что о целых числах, свойствах операции сложения и, возможно, переполнении.Реальный код, как правило, будет еще чуть более сложным, чем эта функция сложения. Даже если математика сойдется, то вы вряд-ли будете довольным временем, которое тратится на компиляцию.
Какое решение порекомендуете?