А, ну да.

Фридман отвратительный интервьюер кстати.

почему?

https://github.com/hasura/eff каждый хаскеллист считает своим долгом наспамить нечитаемых операторов

прям как лайфтаймы

https://github.com/Hirrolot/datatype99/blob/master/datatype99.h вот тут операторов нет

каеф, скажи же

во, вот это адекватно выглядит

DATATYPE99_PRIV_genTypedefsMap_IMPL
сразу видно по названиям что продукт прод-реди

+

сразу видно — код серьёзный

с серьёзными намерениями

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

Но прежде всего хочу подчеркнуть, что сам я специалистом в вопросах теории типов не являюсь, и совершенно не претендую на эту роль. Мои мысли носят скорее поверхностный, концептуальный характер, и если я где-то допускаю технические неточности прошу относиться к этому с пониманием.

Я предложил некоторый концепт реализации "утиной типизации" в рамках системы типов. Уважаемые @Psilon, @insert_reference_here, @emmanuelGoldstein и другие участники справедливо указали на то, что при наивной реализации такой подход породит множество двусмысленностей в семантике кода. Это справедливая критика, и концепт нуждается в дополнительном продумывании. Но я хочу подчеркнуть, что он, во-первых, сам по себе не исключает возможности явного объявления именованных типов, например, чтобы специфицировать семантику объектов. Более того, развивая этот концепт в сторону максимизации эргономичности и однозначности интерпретации, мы не обязательно придем именно к моделям и ограничениям на область вывода, например, как в Rust или в Haskell.

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

Тут всё разумно написано.

Но все анонимные подобные вещи обычно касаются локального кода. Когда речь идет про код "по-большому", то анонимные лямбды на 1000 строк никто не пишет.

Насчет "имплиситных аргументов" и "все всё понимают" можно вспомнить например кортежи. Передавать (i32, i32, String, UserInfo, Credentials) просто чтобы не объявлять тип считается дурным тоном. Хотя казалось бы

С кортежами, возможно, это плохая практика по той же причине, почему делать функции со слишком большим числом аргументов тоже некомильфо. Нужно стараться атомизировать как-то. Так же в общем-то и с типами.

Чо делать с дак тайпингом если я хочу иметь тайпкласс
trait Cat {
 fn name(&self) -> &str;
}
Но при этом под этот интерфейс может попасть и интерфейс
trait Dog {
 fn name(&self) -> &str;
}
?

У меня тогда собака станет котом

это фича же

А отличить утку от резиновой утки станет невозможно

В порядке фантазирования. Ввести, например, систему маркеров: fn foo(arg: {name: this -> String} + CatLike). Трейты с этой целью тоже используют иногда.