#типы — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #типы, aggregated by home.social.
-
Трилемма Святого Грааля типизации: почему нельзя всё сразу
Все мы знаем, что языки делятся на динамические и статические: Python или JS позволяют молниеносно прототипировать, но расплачиваться нестабильностью в продакшене приходится потом, тогда как C++, Java или C# требуют прописывать типы сразу, оплачивая монументальную надежность замедлением разработки. В 2006 году Джереми Сиек предложил разрешить этот конфликт концепцией постепенной типизации в работе «Gradual Typing for Functional Languages»: язык остается динамическим по умолчанию, однако разработчик может аннотировать типами отдельные модули или функции, не покрывая ими всю кодовую базу, а типизированный и нетипизированный код взаимодействуют через специальный динамический тип Dyn . Звучит как сказка — быстрое прототипирование с постепенным наращиванием стабильности. Однако при детальной проработке вскрылись фундаментальные нюансы: в серии последующих работ Сиек, Таха, Вадлер и другие показали, что стыковка типизированного и нетипизированного кода требует операции приведения типа (cast), а дизайн этого каста упирается в противоречие между тремя желаемыми свойствами — надёжностью системы типов (soundness), собственно постепенностью (gradual typing) и отсутствием рантайм-обёрток на границах (no wrappers). Позднее сообщество, и я в том числе, переосмыслило третью вершину: no wrappers — это забота о производительности и прозрачности рантайма, безусловно важная, но с позиции программиста, а не математика-оптимизатора, правильнее говорить о удобстве разработчика (developer-friendly). Это свойство вбирает в себя no wrappers как частный случай, добавляя понятные сообщения об ошибках, низкий порог входа и отсутствие многослойных типовых аннотаций, ведь если ради производительности приходится городить бесконечные теоремы типов, такая система едва ли приживётся на суровом рынке опенсорса. Так родилась трилемма Святого Грааля системы типов: выбрать можно любые два свойства, а третье неизбежно пострадает, и в этой статье мы разберём, как создатели языков пытались достичь всех трёх и на какие компромиссы шли.
https://habr.com/ru/companies/timeweb/articles/1055556/
#теория_типов #типизация #система_типов #святой_грааль #типы #gradual_typing #soundness #no_wrappers #developer_friendly #timeweb_статьи
-
Архитектура Android-приложений. Как повысить качество архитектуры, не говоря об архитектуре
Салют, Хабр! Я Марк, Android-разработчик, работаю над мобильным приложением для управления умным домом Салют. Для мира Android-разработки вопросы архитектуры, её надёжности и качества актуальны, но… на самом деле не так уж интересны. Интересно, чтобы приложения были надёжными, устойчивыми к ошибкам, поддерживаемыми и легко масштабируемыми. Самый популярный подход — по-прежнему архитектурные паттерны (MV* паттерны) и разделение архитектуры по слоям. Что никак не избавляет от ошибок. При этом существует множество подходов, которые делают архитектуру надёжнее, а в перспективе исключают целый класс ошибок, как введение в Котлине Null Safety избавило от класса ошибок NPE. Это проектирование на основе состояний (state-oriented programming), логика Хоара, программирование по контракту Бертрана Мейера. Возможно, и более серьёзные — например, формальные методы верификации. Отмечу, что в целом это общие принципы computer science, независимые от платформы. Но мой фокус — Android-разработка клиент-серверных приложений. Сейчас хотел бы поговорить, как создание своей системы типов в проекте исключает популярный класс логических ошибок — semantic type error. Поехали!
https://habr.com/ru/companies/sberdevices/articles/1045987/
#доменная_система_типов #Kotlin #типы #design_by_contract #Android #архитектура_приложений
-
Утро я потратил на план, который дольше самой задачи. И понял, что не сошёл с ума, просто работа переехала
Я всё утро вылизывал план на 1700 строк. Дольше, чем заняла бы сама задача, если бы я сел и написал её руками. И к обеду поймал себя на мысли, что я не написал ни строчки кода, я редактировал документ про то, как код будет написан, и кажется немного поехал 😁 Потом отпустило. Я не поехал. Просто работа переехала, а я не сразу заметил. Короче. Код стал дешёвым. Любой агент перепишет тебе модуль по запросу, в третий раз, в десятый, на другой язык, ему вообще всё равно. То, за что раньше платили деньги, теперь стоит примерно ничего. А дорого стало то, что по краям от кода. Спереди и сзади. И оба края про одно: сделать правду, которую агент не сможет заболтать. Потому что заболтать он умеет шикарно. «Готово, всё работает, тесты зелёные». Ага. Я это понял не из статьи, а из своих же шрамов. Но статья, на которую отвечаю, попала ровно в ту же точку, просто зашла с другой стороны.
https://habr.com/ru/articles/1043582/
#ИИагенты #Claude_Code #Codex #автономные_агенты #планирование #типы #контракты #вайбкодинг
-
[Перевод] Pyrefly vs. ty: битва двух Rust-базированных анализаторов типов для Python
Команда Python for Devs подготовила перевод статьи о двух новых Rust-базированных анализаторах типов для Python — pyrefly и ty. Оба пока в ранней альфе, но уже демонстрируют впечатляющую скорость, разные подходы к выводу типов и новые возможности.
-
[Перевод] Продвинутые методы использования TypeScript в реальных проектах
Ранее на Piccalilli Сэм Роуз поделился реальными примерами использования вспомогательных типов (utility types) TypeScript . Сегодня я хочу продолжить эту тему и поделиться несколькими продвинутыми возможностями TypeScript для работы с типами, которые, на мой взгляд, особенно полезны и применимы в реальных проектах. Цель этой статьи — дать общее представление о каждой из возможностей, а также привести пример ее использования, чтобы вы могли лучше ориентироваться в том, какие инструменты можно использовать при создании типов.
https://habr.com/ru/companies/timeweb/articles/906842/
#timeweb_статьи_перевод #javascript #js #typescript #ts #types #mapped_types #as_const #типы #связанные_типы
-
Нужно ли «развитие» языкам программирования
TL;DR: Нет. Хорошо спроектированный язык в развитии не нуждается. Попробую объяснить, что меня, человека с тридцатилетним стажем в разработке, свободно пишущем на более дюжины языков, привело к такому абсурдному — на первый взгляд — выводу. Более того, ниже я постараюсь уложиться в нескольких абзацев, чтобы рассказать, какие требования лично я предъявляю языку программирования в 2025 году, и почему этому «идеалу» просто некуда «развиваться». Опять школота против ООП и ФП
-
[Перевод] Как типы делают сложные задачи простыми
Последнюю пару лет мой мозг программиста всё больше увлекался типами, принципами функционального программирования и Typescript. По большей мере на это повлияло огромное количество времени, потраченное мной на кодовую базу Heartbeat — фулстек-приложения из трёхсот тысяч строк на Typescript, включающего в себя веб-приложение React, мобильное приложение React Native и сервер Node.js. Мой опыт работы с этой кодовой базой показал мне, что чем больше я полагаюсь на систему типов, тем больше пользы из этого извлекаю. Написание кода в кодовой базе, полностью сделавшей упор на типы, похоже на жульничество. Часто я могу реализовать 80% новой фичи, ни разу не запустив код. Я начинаю работать над крупным рефакторингом, требующим нарушить допущение, принятое во всём коде, но вскоре выясняю, что благодаря системе типов изменения оказываются тривиальными. Простые фичи практически кодируют себя сами, потому что опечатки мгновенно отлавливаются, а половина моего кода пишется автодополнением. На вопросы от команды техподдержки о тонкостях работы какой-то фичи можно ответить при помощи Ctrl+F в коде, даже если письменной документации почти нет. Целые категории багов, с которыми мне приходилось бороться, попросту исчезли. Я начал называть стиль кодинга, позволяющий реализовать подобное, Type Driven Development. В статье я приведу разрозненные мысли и ссылки на ресурсы, сильно повлиявшие на то, как я понимаю type driven development.
https://habr.com/ru/companies/ruvds/articles/871028/
#ruvds_переводы #системы_типов #валидация #типы #автодополнение_кода #проверка_типов
-
Дуалистичная типовая система JavaScript VS Единая объектная система Python. Краткий обзор
Сегодня поговорим о объектах, объектной архитектуре и способах взаимодействия с ними на примере языков программирования Python и JavaScript. Получилось небольшое исследование, противопоставляющее прототипирование и ООП. Давайте разбираться!
https://habr.com/ru/articles/853760/
#ООП #прототипирование #объект #Объектная_архитектура #python #javascript #типы #наследование
-
Типы в программировании как математические множества
Типы в программировании можно( и нужно ) рассматривать как математические множества. Мысль хоть и очевидная, но из моей головы давно выветрилась. Именно поэтому я и решил написать эту статью: чтобы напомнить о ней самому себе и тем, кто о ней тоже забыл или даже не знал.
https://habr.com/ru/articles/847958/
#теория_типов #c# #полиморфизм #множества #типы #математика_для_программистов
-
[Перевод] Реверс-инжиниринг GDB для работы с Pwndbg
Функционал GDB существенно сужается, когда приходится иметь дело с файлами, из которых убраны отладочные символы (получаются так называемые «урезанные бинарники»). Функции и имена переменных превращаются в бессмысленные адреса. Для установки контрольных точек приходится отслеживать адреса нужных нам функций из внешнего источника. Также нужно выводить в консоль структурированные значения и после этого корпеть над дампом памяти, пытаясь вычленить, где именно пролегают границы полей. Вот почему этим летом, работая в Trail of Bits, я расширил Pwndbg — плагин для GDB. Поддерживает его мой наставник Доминик Чарнота . Я добавил в инструмент две фичи, благодаря которым практическая отладка урезанных бинарников сближается с аналогичной работой, знакомой нам из работы с отладчиком в IDE. Теперь в Pwndbg интегрирован инструмент Binary Ninja, позволяющий лучше выяснять специфику GDB+Pwndbg, а также выводить дамп структур Go, чтобы отлаживать бинарники Go стало удобнее.
-
Ты неправильно используешь интерфейсы typescript
A: Не думай о помощи. Б: Сложно не думать о помощи, когда пишешь на javascript. Примерно такой диалог я слышал на одной из конференции. Решить проблему отсутствия строгой типизации был призван typescript. Конкретно в этой статье я хотел бы рассмотреть один из приемов использования интерфейсов typescript, который мне кажется неочевидным, его я подсмотрел и смог оценить его преимущества в процессе написания приложений на языке golang. Для большинства typescript разработчиков типы и интерфейсы, не имеют как таковой большой разницы.