class MyClass {
public value: number;
constructor() {
this._initialize();
}
private _initialize() {
if (Math.random() > 0.5) {
throw new Error('Oops');
}
this.value = 0;
}
}
Без какой-либо системы трекинга эффектов (capabilities, algebraic effects, etc.) задача вывода типов в желаемом вами сценарии неразрешима. Если не ошибаюсь, тут мы вообще упираемся в проблему остановки.
Почти всё современное ФП построено на применении законов алгебры и некоторых упрощенных конструкций из теории категорий. Если вам интересны эти темы, можете начать с книги Бартоша Милевского «Category theory for programmers», она написана с примерами на Haskell, но есть переводы на Scala и C# + F#. Примеров на пайтоне, увы, мне быстро найти не удалось — возможно, вы сможете.
Также очень рекомендую посмотреть доклады конференций вроде Strange Loop или Scala Love. Из второй очень советую глянуть доклад Луки Якобовица «Monoids, monoids, monoids», он хорошо дополняет текущую статью.
А по поводу тачбара — у Вастрика был хороший пост на эту тему: https://vas3k.ru/blog/touchbar/
Если не хочется заморачиваться, то можно просто «прибить гвоздями» нужные кнопки и отключить динамическое подстраивание под конкретное приложение. У меня тоже была проблема с тем, что я задеваю пальцами часть панели тачбара. Решил расстановкой спейсеров в нужных местах, получилось
Для макоси есть утилита Amethyst — полноценный тайлинговый оконный менеджер. Решает много проблем, связанных с расположением окон — например, одним сочетанием клавиш можно перебрасывать окно между ноутбучным и внешним дисплеем, другим — переключаться между окнами в пространстве, третьим — перемещать курсор между мониторами (причем работает даже с айпадом в режиме Sidecar); кроме того, можно указывать для каждого рабочего пространства свой порядок разбиения, которых весьма немало:
Поддерживаемые способы разбиения пространства
Очень рекомендую дать Amethyst шанс — лично мне эта утилита сняла вообще все вопросы касательно управления окнами в макоси.
Регулярно использую диаграммы уровней C1 и C2, рисую в draw.io. Очень хорошо помогает быстро структурировать мысли при работе над архитектурой и доносить решения до команды. Что мне нравится в модели C4 — в отличии от совсем неформальной нотации boxes and lines она содержит ровно ту степень формализма, чтобы можно было ограничивать мышление нужным уровнем детализации и не скатываться в ошибочное описание всего архитектурного ландшафта в одной диаграмме, но при этом C4 достаточно либеральна и позволяет вольности — скажем, я люблю выделять зеленым цветом блоки, которые добавились в новой ревизии схемы, и красным те, которые будут удалены. Это позволяет диаграммы C4 вставлять в презентации или в вики «как есть», без лишней редактуры.
Тут не подскажу, к сожалению — такие факты обычно всплывают где-нибудь в GitHub Issues (например), и в публичном роадмапе нечасто появляются. Если этот вопрос интересует, то есть смысл его задать в тех же Issues, команда разработки обычно достаточно доброжелательно относится. Я больше переживал про HKT, про которые им регулярно напоминают тут, но подвижек к имплементации нет.
Пожалуйста, покажите, где в моей статье есть хоть слово про глобальные переменные. И в статье, и в комментарии выше я писал исключительно про систему типов тайпскрипта.
ФП без типов высшего порядка — это только первая ступень в лестнице абстракции, по сути — simply typed lambda calculus, самая нижняя вершина в лямбда-кубе Барендрегта. И даже до STLC система типов TS не дотягивает — в частности, из-за ограничения на глубину рекурсивного спуска. До версии 2.6 она была даже (почти) Тьюринг-полной, и могла с большой натяжкой считаться функциональным ЯП. В третьей ветке команда разработки компилятора затянула гайки по возможности хаков компилятора, так что система типов TS это уже не совсем язык программирования как таковой. Хотя, признаюсь честно, мне хотелось бы иметь возможность писать тайплевел-функции на подобии type families в хаскеле, но расширение системы типов не является ценностью для проекта TypeScript.
К сожалению, это не совсем так. У вывода типов в TS есть ограничение на глубину рекурсивного спуска — то ли 50, то ли 52 шага, не помню точно, — после чего возвращается any. Отсутствие HKT тоже не добавляет радости — те костыли, которые я описывал, нельзя назвать удобным для повседневного использования решением. Но если говорить в общем, то система типов в строгом подмножестве TS достаточно неплоха среди мейнстримных ЯП.
Статья про расширение для Хрома, позволяющее спрятать статьи ноющих авторов, получила немалую поддержку как в виде рейтинга, так и в комментариях. Скажите, пожалуйста, обсуждалась ли среди команды разработки возможность дать хабраюзеру опцию заблокировать конкретных авторов или теги?
И второй вопрос — есть ли у Хабра какой-то публично доступный трекер вроде UserVoice, где можно было бы предложить фичу или проголосовать за существующие предложения, чтобы от АМА к АМА не терялись хорошие идеи, предложенные в комментариях?
Спасибо! Из-за определенных авторов пришлось отписаться от хаба F#, но в ленте посты все равно продолжали проскакивать. Теперь стало чуть чище. На macOS в Safari ваше правило заработало и под AdGuard, благо, формат адблока многие научились понимать.
Вообще хаскель изначально хотели назвать Curry, но после мысли о том, что это приведет к большому количеству шуток вокруг каррированных функций, язык переименовали в Haskell. Вот как отцы-основатели (Уодлер, Пейтон Джонс, Хьюз и Худак) пишут об этом в истории создания языка:
That name was “Curry,” in honour of the mathematician and logician Haskell B. Curry, whose work had led, variously and indirectly, to our presence in that room. That night, two of us realised that we would be left with a lot of curry puns (aside from the spice, and the thought of currying favour, the one that truly horrified us was Tim Curry—TIM was Jon Fairbairn’s abstract machine, and Tim Curry was famous for playing the lead in the Rocky Horror Picture Show). So the next day, after some further discussion, we settled on “Haskell” as the name for the new language. Only later did we realise that this was too easily confused with Pascal or Hassle!
Hudak and Wise were asked to write to Curry’s widow, Virginia Curry, to ask if she would mind our naming the language after her husband. Hudak later visited Mrs. Curry at her home and listened to stories about people who had stayed there (such as Church and Kleene). Mrs. Curry came to his talk (which was about Haskell, of course) at Penn State, and although she didn’t understand a word of what he was saying, she was very gracious. Her parting remark was “You know, Haskell actually never liked the name Haskell.”
В 2013 это оказалось удачным шагом для начала работы в стартапе — тогда нода была на пике популярности. Да и в то время я не так сильно горел идеей строгой типизации, а проблемы при работе со слабой неявной типизацией решал «отладкой вдумчивым взглядом». Понадобилось некоторое количество набитых шишек, чтобы признать, что компилятор с такой задачей справляется гораздо лучше человека.
Знакомые терзания, к сожалению. Вы большой умница, 0xd34df00d, и сможете найти решение этой непростой задаче.
Поделюсь своей историей. Сначала 5 лет писал на дотнете, потом перешел на серверный JS, а последние 3 года пишу на тайпскрипте. При этом последние 2.5 года прошли в попытках сделать из несчастного тайпскрипта то хаскель, то идрис, то раст — GADT и тайплевел-вычисления на нем я писал, свободные монады, схемы рекурсии, tagless final — тоже, даже какое-то подобие сессионных типов удалось состряпать. И проблема в том, что постоянно хочется большего — чуть ли не формальной верификации, чтобы компилятор бил по рукам, а по возвращению к проекту через три месяца, чтобы начать с ним работать, достаточно было взглянуть на типы.
Я тоже сильно выгорел от подобного — писать по-старому, с «ехал any через any», я уже физически не могу, а бросить всё и перейти на хаскель боязно из-за разницы в зарплате. Я для себя нашел ответ в следующем — довести технический уровень до такого, чтобы смотрели, в первую очередь, не на опыт использования конкретного языка в годах и знание вот-этого-конкретного-комбинаторного-парсера, а на совокупность всех навыков — архитектуры, софт-скиллов, технического кругозора. Проще говоря, уход в архитекторскую ветку. Поэтому вместе с GHC User Manual и Thinking with types читаю Клэппмана, статьи по каппа- и лямбда-архитектуре, учебник Левенчука по системному мышлению, поглядываю на SWEBOK.
К чему я это всё: не спешите списывать себя в утиль. Пути для дальнейшего развития есть всегда.
В Эпаме всё-таки несколько проектов на Scala есть, но их действительно ничтожно мало в сравнении с более «конвенционной» Java. Основной же точкой применения для Haskell и Scala я вижу свои проекты. Например, в ближайшее время начну писать одну весьма амбициозную вещь на servant, которая только выиграет от возможностей typelevel API вроде автогенерируемой документации.
Немного усложню ваш пример:
Без какой-либо системы трекинга эффектов (capabilities, algebraic effects, etc.) задача вывода типов в желаемом вами сценарии неразрешима. Если не ошибаюсь, тут мы вообще упираемся в проблему остановки.
А вы не бойтесь :) Посмотрите на
языкиproof assistant'ы Coq, Agda, Lean. Для последнего есть шикарнейшая библиотека с формализацией математики: https://leanprover-community.github.io/index.html. Если вас интересует эта тема, поищите статьи и книги на тему формальной верификации (например, Verified Functional Programming in Agda написана просто отлично).Почти всё современное ФП построено на применении законов алгебры и некоторых упрощенных конструкций из теории категорий. Если вам интересны эти темы, можете начать с книги Бартоша Милевского «Category theory for programmers», она написана с примерами на Haskell, но есть переводы на Scala и C# + F#. Примеров на пайтоне, увы, мне быстро найти не удалось — возможно, вы сможете.
Также очень рекомендую посмотреть доклады конференций вроде Strange Loop или Scala Love. Из второй очень советую глянуть доклад Луки Якобовица «Monoids, monoids, monoids», он хорошо дополняет текущую статью.
А по поводу тачбара — у Вастрика был хороший пост на эту тему: https://vas3k.ru/blog/touchbar/
Если не хочется заморачиваться, то можно просто «прибить гвоздями» нужные кнопки и отключить динамическое подстраивание под конкретное приложение. У меня тоже была проблема с тем, что я задеваю пальцами часть панели тачбара. Решил расстановкой спейсеров в нужных местах, получилось
Для макоси есть утилита Amethyst — полноценный тайлинговый оконный менеджер. Решает много проблем, связанных с расположением окон — например, одним сочетанием клавиш можно перебрасывать окно между ноутбучным и внешним дисплеем, другим — переключаться между окнами в пространстве, третьим — перемещать курсор между мониторами (причем работает даже с айпадом в режиме Sidecar); кроме того, можно указывать для каждого рабочего пространства свой порядок разбиения, которых весьма немало:
Очень рекомендую дать Amethyst шанс — лично мне эта утилита сняла вообще все вопросы касательно управления окнами в макоси.
Регулярно использую диаграммы уровней C1 и C2, рисую в draw.io. Очень хорошо помогает быстро структурировать мысли при работе над архитектурой и доносить решения до команды. Что мне нравится в модели C4 — в отличии от совсем неформальной нотации boxes and lines она содержит ровно ту степень формализма, чтобы можно было ограничивать мышление нужным уровнем детализации и не скатываться в ошибочное описание всего архитектурного ландшафта в одной диаграмме, но при этом C4 достаточно либеральна и позволяет вольности — скажем, я люблю выделять зеленым цветом блоки, которые добавились в новой ревизии схемы, и красным те, которые будут удалены. Это позволяет диаграммы C4 вставлять в презентации или в вики «как есть», без лишней редактуры.
Для котлина есть https://arrow-kt.io от 47 Degrees, в котором даже синтаксический сахар для монадических операций сделан, если я правильно помню.
Тут не подскажу, к сожалению — такие факты обычно всплывают где-нибудь в GitHub Issues (например), и в публичном роадмапе нечасто появляются. Если этот вопрос интересует, то есть смысл его задать в тех же Issues, команда разработки обычно достаточно доброжелательно относится. Я больше переживал про HKT, про которые им регулярно напоминают тут, но подвижек к имплементации нет.
Пожалуйста, покажите, где в моей статье есть хоть слово про глобальные переменные. И в статье, и в комментарии выше я писал исключительно про систему типов тайпскрипта.
ФП без типов высшего порядка — это только первая ступень в лестнице абстракции, по сути — simply typed lambda calculus, самая нижняя вершина в лямбда-кубе Барендрегта. И даже до STLC система типов TS не дотягивает — в частности, из-за ограничения на глубину рекурсивного спуска. До версии 2.6 она была даже (почти) Тьюринг-полной, и могла с большой натяжкой считаться функциональным ЯП. В третьей ветке команда разработки компилятора затянула гайки по возможности хаков компилятора, так что система типов TS это уже не совсем язык программирования как таковой. Хотя, признаюсь честно, мне хотелось бы иметь возможность писать тайплевел-функции на подобии type families в хаскеле, но расширение системы типов не является ценностью для проекта TypeScript.
К сожалению, это не совсем так. У вывода типов в TS есть ограничение на глубину рекурсивного спуска — то ли 50, то ли 52 шага, не помню точно, — после чего возвращается
any. Отсутствие HKT тоже не добавляет радости — те костыли, которые я описывал, нельзя назвать удобным для повседневного использования решением. Но если говорить в общем, то система типов в строгом подмножестве TS достаточно неплоха среди мейнстримных ЯП.Статья про расширение для Хрома, позволяющее спрятать статьи ноющих авторов, получила немалую поддержку как в виде рейтинга, так и в комментариях. Скажите, пожалуйста, обсуждалась ли среди команды разработки возможность дать хабраюзеру опцию заблокировать конкретных авторов или теги?
И второй вопрос — есть ли у Хабра какой-то публично доступный трекер вроде UserVoice, где можно было бы предложить фичу или проголосовать за существующие предложения, чтобы от АМА к АМА не терялись хорошие идеи, предложенные в комментариях?
Спасибо! Из-за определенных авторов пришлось отписаться от хаба F#, но в ленте посты все равно продолжали проскакивать. Теперь стало чуть чище. На macOS в Safari ваше правило заработало и под AdGuard, благо, формат адблока многие научились понимать.
Вообще хаскель изначально хотели назвать Curry, но после мысли о том, что это приведет к большому количеству шуток вокруг каррированных функций, язык переименовали в Haskell. Вот как отцы-основатели (Уодлер, Пейтон Джонс, Хьюз и Худак) пишут об этом в истории создания языка:
В 2013 это оказалось удачным шагом для начала работы в стартапе — тогда нода была на пике популярности. Да и в то время я не так сильно горел идеей строгой типизации, а проблемы при работе со слабой неявной типизацией решал «отладкой вдумчивым взглядом». Понадобилось некоторое количество набитых шишек, чтобы признать, что компилятор с такой задачей справляется гораздо лучше человека.
Знакомые терзания, к сожалению. Вы большой умница, 0xd34df00d, и сможете найти решение этой непростой задаче.
Поделюсь своей историей. Сначала 5 лет писал на дотнете, потом перешел на серверный JS, а последние 3 года пишу на тайпскрипте. При этом последние 2.5 года прошли в попытках сделать из несчастного тайпскрипта то хаскель, то идрис, то раст — GADT и тайплевел-вычисления на нем я писал, свободные монады, схемы рекурсии, tagless final — тоже, даже какое-то подобие сессионных типов удалось состряпать. И проблема в том, что постоянно хочется большего — чуть ли не формальной верификации, чтобы компилятор бил по рукам, а по возвращению к проекту через три месяца, чтобы начать с ним работать, достаточно было взглянуть на типы.
Я тоже сильно выгорел от подобного — писать по-старому, с «ехал
anyчерезany», я уже физически не могу, а бросить всё и перейти на хаскель боязно из-за разницы в зарплате. Я для себя нашел ответ в следующем — довести технический уровень до такого, чтобы смотрели, в первую очередь, не на опыт использования конкретного языка в годах и знание вот-этого-конкретного-комбинаторного-парсера, а на совокупность всех навыков — архитектуры, софт-скиллов, технического кругозора. Проще говоря, уход в архитекторскую ветку. Поэтому вместе с GHC User Manual и Thinking with types читаю Клэппмана, статьи по каппа- и лямбда-архитектуре, учебник Левенчука по системному мышлению, поглядываю на SWEBOK.К чему я это всё: не спешите списывать себя в утиль. Пути для дальнейшего развития есть всегда.