Скорее OutOfElectricityException

Я физик, а не математик, мне ближе какие-то реальные сущности. Я понимаю Unit и Nothing как некоторый вариант контрактов. Unit подразумевает, что функция что-то вернет, но это что-то никогда не будет использовано, а Nothing - функция никогда ничего не вернет

Если совсем уж откинуть практическую ценность, никто не мешает использовать результат функции, которая возвращает Unit. fun unitFn(a: Int) {} fun main(args: Array<String>) { val result = unitFn(5) println("${result.javaClass.canonicalName}") } вполне себе напечатает kotlin.Unit, к примеру ?

Это я понимаю, но это в некотором смысле нарушение контракта, бессмысленный код.

Я могу в принципе и `Nothing`обмануть, сделав вроде как бесконечный цикл, но прервав его по дороге каким-то способом

наверное... не пробовал

Да нет, на самом деле, никакого нарушения контракта нету -- функция возвращает объект-синглтон, всё в порядке. И прерванный бесконечный цикл -- не обман Nothing, который, собственно, просто гарантирует, что функция не вернёт значение в рамках обычного control flow. Ну то есть если, положим, вызвать посредством JNI код, который поднимет нативный сигнал, и таким образом выйти из функции не через исключение в рамках JVM -- это всё ещё в рамках Nothing ?

Какая в этом практическая ценность -- другой вопрос.

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

Дык я наоборот о том, что никто ничего не нарушает. Всё вполне логично ложится в систему типов. Для понимания конкретно Unit и Nothing на уровне, на котором они нужны практику, который JSON-чики в БД укладывает -- вряд ли. Для расширения кругозора наверняка штука полезная. Но я боюсь глубоко нырять -- вдруг я ознакомлюсь с темой и пойму, что Kotlin -- ужасно неполноценный язык и уйду писать на Frege ?

Дык я наоборот о том, что никто ничего не нарушает. Всё вполне логично ложится в систему типов. Для понимания конкретно Unit и Nothing на уровне, на котором они нужны практику, который JSON-чики в БД укладывает -- вряд ли. Для расширения кругозора наверняка штука полезная. Но я боюсь глубоко нырять -- вдруг я ознакомлюсь с темой и пойму, что Kotlin -- ужасно неполноценный язык и уйду писать на Frege ?

> уйду писать на Frege Как что-то плохое)) главное не на скале (и кстати есть же Eta )

Дык я наоборот о том, что никто ничего не нарушает. Всё вполне логично ложится в систему типов. Для понимания конкретно Unit и Nothing на уровне, на котором они нужны практику, который JSON-чики в БД укладывает -- вряд ли. Для расширения кругозора наверняка штука полезная. Но я боюсь глубоко нырять -- вдруг я ознакомлюсь с темой и пойму, что Kotlin -- ужасно неполноценный язык и уйду писать на Frege ?

А он еще жив?

А вообще, во многих знаниях многие печали

Последний коммит 27 мая, вполне себе жив. А он собирался умирать? Я не интересовался особо им никогда)

module Hello where greeting friend = "Hello, " ++ friend ++ "!" main args = do println (greeting "World")

чота два плюсика в синтаксисе настораживают

У нас хаскелист в группе, как-то обсуждали

чота два плюсика в синтаксисе настораживают

Наоборот круто, явно разделённые понятия о сложении и конкатенации.

module Hello where greeting friend = "Hello, " ++ friend ++ "!" main args = do println (greeting "World")

Хаскель жи

Не лезте в синтаксис хаскеля, у меня только от чтения голова болит

книжка валяется по нему, скучает )

Наоборот круто, явно разделённые понятия о сложении и конкатенации.

почему-то подумал про пхп

почему-то подумал про пхп

там конкатенация через точку

почему-то подумал про пхп

Слушай, но не может же быть язык идеально плохим, должно же в нём быть хоть что-то хорошее. ?

Хаскелисты - это секта, они от него прутся

А потом мы удивляемся, что функциональщики в чатике набегами пытаются Котлин унижать. Надо быть выше этого, товарищи.

Слушай, но не может же быть язык идеально плохим, должно же в нём быть хоть что-то хорошее. ?

а как же javascript? )))

а как же javascript? )))

В основе JS стоят вполне себе крутые идеи, между делом.

А я не унижаю, я думаю, что они слишком умные для нас простых смертных

а как же javascript? )))

Но как язык я его от этого любить не начинаю, конечно ?

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

(Теория струн - это еще не самое мощное)

Хаскелисты - это секта, они от него прутся

Они прутся от: - краткости + выразительности - понятности тк что бы понять что делает функция, надо видеть только сигнатуру (тк они чистые и не делают ничего неявно) - стат. типизации (там ведь даже эффекты выражены в типах) - простое тестирования (даешь аргументы - смотри результат, каждый раз возращается одно и тоже) (а не просто от факта, что пишут на хаскеле и знаю (на пол шишечки) теоркат)

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

Да какие возражения. Но от синтаксиса голова болит

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

Вообще любой контроль рантайма.

Которого кстати нет

Которого кстати нет

Я вот тут не просто "не настоящий сварщик", а "даже рядом не сварщик", но разве это не должно решаться в рамках IO?

Я тоже не прикладывался, говорю же, аллергия, но в чисто функциональных языках вообще нет рантайма, соответственно нет контроля поведелния в рантайме. Вроде как там все тоже можно сделать, но слооожно

Я тоже не прикладывался, говорю же, аллергия, но в чисто функциональных языках вообще нет рантайма, соответственно нет контроля поведелния в рантайме. Вроде как там все тоже можно сделать, но слооожно

Ну вот да, я не видел чисто функциональных языков без бекдора в страшный мир сайдэффектов.

Это был бы сферический язык в вакууме

Да фиг знает, никто не мешает писать на чисто функциональном языке библиотечный код и вызывать его из кода на другом языке. Тот же F# вполне себе могёт общаться с ООП-миром, но на нём всё-таки библиотеки пишут обычно ?

В качестве альтернативного варианта можно посмотреть на какую-нибудь прототипную Lua с подобной картиной.

Да фиг знает, никто не мешает писать на чисто функциональном языке библиотечный код и вызывать его из кода на другом языке. Тот же F# вполне себе могёт общаться с ООП-миром, но на нём всё-таки библиотеки пишут обычно ?

Да никто и не мешает взять Kotlin и писать чисто функционально (вывожу разговор на тему чата ?)

Да никто и не мешает взять Kotlin и писать чисто функционально (вывожу разговор на тему чата ?)

Как это никто? А как же соблазн писать императивщину?)) Я в Arrow до сих пор не смог, отчасти, конечно, потому, что его авторы не умеют на человеческом языке а) объяснять подходы, б) объяснять практическую ценность. Выпуск Talking Kotlin на эту тему, ИМО, был просто отвратительный.

Как это никто? А как же соблазн писать императивщину?)) Я в Arrow до сих пор не смог, отчасти, конечно, потому, что его авторы не умеют на человеческом языке а) объяснять подходы, б) объяснять практическую ценность. Выпуск Talking Kotlin на эту тему, ИМО, был просто отвратительный.

Так там авторы же упоротые. Если глянуть их github, они в основном на скале пишут с либа, которые вообще из хаскеля принесены. А теперь они еще и решили портануть их котлин ? - ну это же бред

Так там авторы же упоротые. Если глянуть их github, они в основном на скале пишут с либа, которые вообще из хаскеля принесены. А теперь они еще и решили портануть их котлин ? - ну это же бред

Спасибо, теперь предпосылки к этой картине яснее стали.

Как это никто? А как же соблазн писать императивщину?)) Я в Arrow до сих пор не смог, отчасти, конечно, потому, что его авторы не умеют на человеческом языке а) объяснять подходы, б) объяснять практическую ценность. Выпуск Talking Kotlin на эту тему, ИМО, был просто отвратительный.

Arrow не нужен чтобы писать в функциональном стиле. Хотя наверное только частично можно

Arrow не нужен чтобы писать в функциональном стиле. Хотя наверное только частично можно

В этом "только частично" вся суть. То, что в коде есть композиция чистых функций, ещё не значит, что весь код выдержан в функциональном стиле. Хотя Arrow, само собой, не обязательное требование ?

В этом "только частично" вся суть. То, что в коде есть композиция чистых функций, ещё не значит, что весь код выдержан в функциональном стиле. Хотя Arrow, само собой, не обязательное требование ?

А вообще, есть теория что в программах _которые мы обычно пишем_, вообще не нужно сложное-типизированое-ФП. Заодно закину интересную мысль и пропиарю @pofftop чатик https://t.me/pofftop/14527

Я согласен с тем, что соблюдать конкретную парадигму не должно быть самоцелью. Как обычно пафосно заявляют в таких случаях, каждой задаче -- свой инструмент. *ушёл искать наушники*

В целом логично. Не зря же тут в чатике постоянно ругают даггер и зависимости пропагандируют исключительно через конструкторы передавать. Оно ж о том же ?

сейчас бы кучу сервисов через конструктор тащить

сейчас бы кучу сервисов через конструктор тащить

куча сервисов == нарушение SRP

куча сервисов == нарушение SRP

почему?

куча сервисов == нарушение SRP

а 0 сервисов в зависимостях == анемичные ДО

А 0 сервисов в зависимостях -- не лучше, чем куча.

Уже два-три сервиса замусорят параметры конструктора

Уже два-три сервиса замусорят параметры конструктора

ну тогда только DI на синглтонах

Уже два-три сервиса замусорят параметры конструктора

Звучит как объективный аргумент ? </sarcasm>

ну тогда только DI на синглтонах

типа service locator?

типа service locator?

Типа сарказм. Зависимости не в конструктор == говнокод.

Типа сарказм. Зависимости не в конструктор == говнокод.

не, DI это нормально

если только у тебя не прилождение на 10 классов с моделями

ERROR: S client not available

причем тут di ))

ну тогда только DI на синглтонах

а зачем синглтоны то?

не, DI это нормально

всё зависит то того, что такое DI

а зачем синглтоны то?

ну чтобы конструкторы не замусоривать

ну чтобы конструкторы не замусоривать

так не замусореваются. для чего request/session/prototype scope?

автовайринг

причем тут di ))

ок, ioc)

автовайринг и прочее это по моему просто скоупы не?

и сколько инстансов создастся

да, я это к синглтонам

что не обязательно все синглтонами делать

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

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

они создаются что бы передавать что либо только там где надо передавать, а не что бы пропихивать на 10 вызовов вглубь, когда он нужен на 11-м

не надо вглубь, все зависимости должна создать точка входа

Б-же, что я наделал ?

Б-же, что я наделал ?

you are holywar god :)

you are holywar god :)

А я просто хотел, чтобы у меня хотя бы в чатике был чистый код ?

они создаются что бы передавать что либо только там где надо передавать, а не что бы пропихивать на 10 вызовов вглубь, когда он нужен на 11-м

this

А вы говорите, хаскеллисты упоротые. Вон люди усиленно прячут от себя свои графы зависимостей за 3rd-party фреймворками и слоем рефлексии / кодогенерации, вместо того, чтобы меньшими усилиями собрать их явно, и утверждают, что это круто.

аминь

А вы говорите, хаскеллисты упоротые. Вон люди усиленно прячут от себя свои графы зависимостей за 3rd-party фреймворками и слоем рефлексии / кодогенерации, вместо того, чтобы меньшими усилиями собрать их явно, и утверждают, что это круто.

ты сможешь поддерживать граф из 50-70 объектов с передачей через параметры конструктора?

а если нужна динамика?

а если нужна динамика?

тогда Python, Clojure, Groovy

ты сможешь поддерживать граф из 50-70 объектов с передачей через параметры конструктора?

Ты чем пользуешься? Даггером?

тогда Python, Clojure, Groovy

я про динамический граф

Ты чем пользуешься? Даггером?

spring

и самое интересное, как в этом динамическом дереве делать hot replace в зависимости от контекста?

и самое интересное, как в этом динамическом дереве делать hot replace в зависимости от контекста?

самое интересное — зачем

самое интересное — зачем

иначе получим anemic data model либо фп на объектах

иначе получим anemic data model либо фп на объектах

я про динамическое дерево

Не доводилось с этим чудом инженерной мысли работать, потому не скажу ничего конкретного. Пользуюсь Ktor -- вполне себе всё успешно руками раскладывается на модули в духе тех, которые генерирует даггер на основании задекларированных интерфейсов, без существенного увеличения количества кода, но с заметным повышением наглядности. В том же Android без DI-фреймворка кода рисуется больше, но исключительно за счёт идиотской архитектуры. Присоединяюсь к вопросу, зачем hot replace.