Size: a a a

Scala User Group

2020 September 08

SA

Sergey Alaev in Scala User Group
Λнтон Войцишевский
А что такое тофу-спринг?
Это когда в тофу добавят всё, что в него предлагают добавить
источник

E

Elijah in Scala User Group
Nikita Vilunov
чистый сабсет скалы, да
чистый в смысле без ООП?
источник

AT

Aλeksei Tereχin in Scala User Group
Elijah
чистый в смысле без ООП?
источник

ΛВ

Λнтон Войцишевский... in Scala User Group
Elijah
чистый в смысле без ООП?
Чистый в смысле функциональщины
источник

E

Elijah in Scala User Group
о, спасибо
источник

E

Elijah in Scala User Group
Λнтон Войцишевский
Чистый в смысле функциональщины
ну да, как-то так я и хотел это сформулировать
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Elijah
чистый в смысле без ООП?
Нет. Разработчики тофу не противники ООП
источник

λ

λoλdog in Scala User Group
Oleg ℕizhnik
Нет. Разработчики тофу не противники ООП
За всех не говори))))
источник

Oℕ

Oleg ℕizhnik in Scala User Group
хочу и говорю за всех
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Elijah
чистый в смысле без ООП?
тофу - это сравнительно небольшая библиотека, по большей части состоящая из абстракций.
Она нужна для решения частовозникающих проблем для людей, которые решили написать приложение или какую-то его часть с использованием монадического(процедурного) ТФ
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Прошу прощения за маркетинг, но раз уж возник вопрос
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Частоиспользуемая практика в ООП - это процедурный\императивный способ написания методов, полагаю, что ООП станет не намного менее ООП, если процедур на базе встроенных в java команд заменяют на какие-то монадические структуры данных, к.н. IO/ZIO/Task, для описания той же императивной логики, но с некоторым оверхедом на синтаксис и немалым количеством автоматически приобретаемых качеств.
Процедурный ТФ помогает определить свои собственные бизнес-ДСЛ, которые всё ещё так же последовательно, с разбиением на команды описывают решение задачи, но тем не менее позволяют выполнять преобразования данных  с помощью чистых функций, и обеспечивают поддержку неблокирующего исполнения и структурированной конкаренси.
Использование его не противоречит, с моей точки зрения, большинству формулировок ООП, которые я слышал.
источник

NG

Nick Gushchin in Scala User Group
Oleg ℕizhnik
Частоиспользуемая практика в ООП - это процедурный\императивный способ написания методов, полагаю, что ООП станет не намного менее ООП, если процедур на базе встроенных в java команд заменяют на какие-то монадические структуры данных, к.н. IO/ZIO/Task, для описания той же императивной логики, но с некоторым оверхедом на синтаксис и немалым количеством автоматически приобретаемых качеств.
Процедурный ТФ помогает определить свои собственные бизнес-ДСЛ, которые всё ещё так же последовательно, с разбиением на команды описывают решение задачи, но тем не менее позволяют выполнять преобразования данных  с помощью чистых функций, и обеспечивают поддержку неблокирующего исполнения и структурированной конкаренси.
Использование его не противоречит, с моей точки зрения, большинству формулировок ООП, которые я слышал.
Аминь!
источник

K

Kai in Scala User Group
Oleg ℕizhnik
Ребята давайте вы расскажете о случаях, когда асинхронный трейсинг вам помог.
Призываем @kai_neko
vsegda pomogaet kazhdyi den'
источник

𝛈µ

𝛈 µ in Scala User Group
Oleg ℕizhnik
Ребята давайте вы расскажете о случаях, когда асинхронный трейсинг вам помог.
Призываем @kai_neko
Слишком много случаев будет. В целом, когда случается что-то неожиданное, а оно случается, куда приятнее видеть общий флоу программы, хотя бы примерно, а только конкретную точку падения. Это экономит очень много времени в сравнении с условными сраными кошками
источник

𝛈µ

𝛈 µ in Scala User Group
Собственно лично для меня главным аргументом против сраных кошек всегда было именно отсутствие стека
источник

𝛈µ

𝛈 µ in Scala User Group
И именно по этой причине зиотрейсинг вообще и появился
источник

𝛈µ

𝛈 µ in Scala User Group
Мы тут очень грызлись на тему необходимости стеков
источник

𝛈µ

𝛈 µ in Scala User Group
Oleg ℕizhnik
Частоиспользуемая практика в ООП - это процедурный\императивный способ написания методов, полагаю, что ООП станет не намного менее ООП, если процедур на базе встроенных в java команд заменяют на какие-то монадические структуры данных, к.н. IO/ZIO/Task, для описания той же императивной логики, но с некоторым оверхедом на синтаксис и немалым количеством автоматически приобретаемых качеств.
Процедурный ТФ помогает определить свои собственные бизнес-ДСЛ, которые всё ещё так же последовательно, с разбиением на команды описывают решение задачи, но тем не менее позволяют выполнять преобразования данных  с помощью чистых функций, и обеспечивают поддержку неблокирующего исполнения и структурированной конкаренси.
Использование его не противоречит, с моей точки зрения, большинству формулировок ООП, которые я слышал.
Жуткий тлдр. ООП ортогонален императивности
источник

λ

λoλegΥch in Scala User Group
ооп предполагает скрытый мутабельный стейт
источник