SO
как это будет работать?
Size: a a a
2020 November 09
SO
Мне уже за тридцатник, какой кулхацкер? Это просто работает, в отличие от бесконечных глюков IDE
в TS как пример, ничего не глючит по этому поводу, с рефакторингом идентификаторов
2020 November 10
ЕО
Ну ладно, я наверное просто не понимаю
SO
Ну ладно, я наверное просто не понимаю
вот есть у тебя какой-то рекорд та поле
first ты его хочешь заменить на firstName что ты будешь везде менять с помощьб команды (sed).first или first? Бог его знает что ты зацепишь, в этом реплейсе, потом ползать руками исправлять то, что задел лишнего или чего не дотянулся?ЕО
Ну, у меня sed в редактор встроенный. Да, я так реплейсом и делаю всегда. Но я на работе не на purescript пишу
SO
в общем это всё суровость хаскель программистов, могли бы в vi без подсветки писать
ЕО
Из ide-like фичей я юзаю goto defenition и find implementations, чуть реже find usages (но не в purescript, опять же). У нас проект на 300к слок.
Зачем такое в маленьком пет-проджекте я не понимаю, правда
Зачем такое в маленьком пет-проджекте я не понимаю, правда
SO
у кого-то, есть не маленькие вроде бы
SO
как разница вообще, размер, понятно, что если человек привык на лошади ездить, его вот так и не убедишь, что автомобиль быстрее и удобнее
ЕО
Ну, я думаю не так много бы людей пользовались автомобилем, если бы задержка управления у него была бы медленнее чем у лошади
ЕО
Идея просто физически не успевает за моей скоростью печати из-за того, что у G1 огромные STW на первом поколении до 120мс.
SO
причем если сравнивать тот же PS и TS, то с точки зрения языка TS - лошадь с телегой, а PS как правильно замечали ламборджини, но вот с точки зрения языковых тулзов - как-то наоборот получилось
ЕО
ЕО
Я вот всё прододжаю разбираться с FRP. И в классическом FRP, и в push-pull события это бесконечный список [(Time, a)].
И в результате возникает впечатление, что FRP задумывался как нечто, неизбежно использующееся с lazy IO. И, понятное дело, что это не очень перспективное направление из-за принципиальной невозможности настоящего lazy IO.
В реактивных бананах нет ленивого IO, но зато там очень много ленивого, но "грязного" кода, т.е. всякие бесконечные списки и графы, содержащие IO a.
И у меня возник вопрос: а можно ли сделать FRP чистым, но при этом строгим при соприкосновении с IO? Не превращая просто чистую часть программы в :: a -> State (Time -> b) c ?
И в результате возникает впечатление, что FRP задумывался как нечто, неизбежно использующееся с lazy IO. И, понятное дело, что это не очень перспективное направление из-за принципиальной невозможности настоящего lazy IO.
В реактивных бананах нет ленивого IO, но зато там очень много ленивого, но "грязного" кода, т.е. всякие бесконечные списки и графы, содержащие IO a.
И у меня возник вопрос: а можно ли сделать FRP чистым, но при этом строгим при соприкосновении с IO? Не превращая просто чистую часть программы в :: a -> State (Time -> b) c ?
NI
Я вот всё прододжаю разбираться с FRP. И в классическом FRP, и в push-pull события это бесконечный список [(Time, a)].
И в результате возникает впечатление, что FRP задумывался как нечто, неизбежно использующееся с lazy IO. И, понятное дело, что это не очень перспективное направление из-за принципиальной невозможности настоящего lazy IO.
В реактивных бананах нет ленивого IO, но зато там очень много ленивого, но "грязного" кода, т.е. всякие бесконечные списки и графы, содержащие IO a.
И у меня возник вопрос: а можно ли сделать FRP чистым, но при этом строгим при соприкосновении с IO? Не превращая просто чистую часть программы в :: a -> State (Time -> b) c ?
И в результате возникает впечатление, что FRP задумывался как нечто, неизбежно использующееся с lazy IO. И, понятное дело, что это не очень перспективное направление из-за принципиальной невозможности настоящего lazy IO.
В реактивных бананах нет ленивого IO, но зато там очень много ленивого, но "грязного" кода, т.е. всякие бесконечные списки и графы, содержащие IO a.
И у меня возник вопрос: а можно ли сделать FRP чистым, но при этом строгим при соприкосновении с IO? Не превращая просто чистую часть программы в :: a -> State (Time -> b) c ?
> FRP задумывался как нечто, неизбежно использующееся с lazy IO
Потоки можно использовать.
Потоки можно использовать.
ЕО
> FRP задумывался как нечто, неизбежно использующееся с lazy IO
Потоки можно использовать.
Потоки можно использовать.
Потоки это Iteratee и иже с ним?
NI
Потоки это Iteratee и иже с ним?
Типа того, но не обязательно именно так.
ЕО
Наверное почитаю про arrowised frp сначала, возможно там все ответы есть
NI
Стрелочное же оно всё ленивое?
NI
Но так-то, обработку потоков (ну типпаа "строгих") можно и в стрелочном сделать и вполне ничотак будет выглядеть.