> The functional programmer sounds rather like a mediæval monk, denying himself the pleasures of life in the hope that it will make him virtuous.

> It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be.

> One cannot write a program that is particularly lacking in assignment statements, or particularly referentially transparent.

> When writing a modular program to solve a problem, one first divides the problem into subproblems, then solves the subproblems, and finally combines the solutions. The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language.

Слушай, а тебя случайно не Григорием звать?

```haskell map f = foldr ((:).f) [] ``` неплохо

> Whenever a new datatype is defined, higher-order functions should be written for processing it. This makes manipulating the datatype easy, and it also localizes knowledge about the details of its repre- sentation. The best analogy with conventional programming is with extensible languages — in effect, the programming language can be extended with new control structures whenever desired.

> Since this method of evaluation runs f as little as possible, it is called “lazy evaluation”. It makes it practical to modularize a program as a generator that constructs a large number of possible answers, and a selector that chooses the appropriate one.

> We have described lazy evaluation in the context of functional languages, but surely so useful a feature should be added to nonfunctional languages — or should it? Can lazy evaluation and side-effects coexist? Unfortunately, they cannot: Adding lazy evaluation to an imperative notation is not actually impos- sible, but the combination would make the programmer’s life harder, rather than easier. Because lazy evaluation’s power depends on the programmer giving up any direct control over the order in which the parts of a program are executed, it would make programming with side effects rather difficult, because predicting in what order —or even whether— they might take place would require knowing a lot about the context in which they are embedded. Such global interdepen- dence would defeat the very modularity that —in functional languages— lazy evaluation is designed to enhance.

> [Lazy evaluation] allows termination conditions to be separated from loop bodies — a powerful modularization.

ет ты кокспект делаеш? )))

ех, как молоды мы были...

@o01eg Жми лайк если раст безопаснее потому что картонный хаскелист взял хуйню в описании которой английским по белому написано что она даёт непредсказуемые результаты в мультитредовом контексте (https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-IORef.html#g:2), и заюзал в мультитредовом контексте, а растоёб успел четырежды охуеть от вербозности и лайфтаймов, а в будущем ещё охуеет от того что гринтреды выкинули на мороз (https://stackoverflow.com/a/29791242/4095104), а местная реализация STM не даёт ожидаемой от ней безопасности (https://github.com/Marthog/rust-stm#usage) из-за убогой системы типов.

@l29ah Гринтреды возвращают в виде async

@l29ah > что картонный хаскелист взял хуйню в описании которой английским по белому написано что она даёт непредсказуемые результаты в мультитредовом контексте Разбудите, когда хаскель станет выдавать ошибку компиляции на использование !Sync в многопотоке

@o01eg Разбудите, когда раст станет выдавать ошибку компиляции на грязные операции в STM.

@o01eg https://github.com/rust-lang/rust/issues/50547 пролистал, так и не понял будет оно использовать epoll для I/O, или для того чтобы "гринтреды" работали c I/O, им нужно будет выделить по одному осёвому треду на каждый I/O "гринтред".

@l29ah Ты можешь написать исполнитель для работы с epoll. Вроде как такой уже есть в mio

@o01eg > [no longer maintained] Scalable, coroutine-based, fibers/green-threads for Rust. (aka MIO COroutines). Ясно.

@l29ah Напиши в tokio баг, у них всё поверх него работает

@l29ah Ты нашёл не тот mio https://crates.io/crates/mio

@o01eg Тот, проскролль по своему линку ниже и жомай на хуйню с надписью COroutines.

@l29ah Зачем тебе играть в переключение в контекст, когда можно просто написать футуру?

@o01eg Как и когда будет исполняться I/O в ФУТУРЕ?

@l29ah Какой Waker и Executor напишешь, так и будет.

@o01eg Я могу синхронизировать несколько ФУТУР между собой, юзать STM там?

@o01eg То есть никак, я понял.

@l29ah Напиши их поверх epoll, хотя в mio оно уже написано.

@o01eg Почему-то все попытки написать на которые ссылаются из mio сломаны или брошены.

@l29ah Хотя, кажется tokio жив и делает то что нужно.