и это боль

jar собрать? сиди 5 минут

там трамполин вроде ускоряет (LEIN_FAST_TRAMPOLINE вроде, давно было), есть плюс еще какие-то тулзы

да и репл не закрывают обычно

jar собрать? сиди 5 минут

Да как-то быстрее было

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

Repl driven development

Repl driven development

это да. но говорю ж — есть всякие линтеры, сборки jar и тд

в репле как-то не очень

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

да я тоже так жил но чет задолбало потом ( и типов хочется

а это юзал? https://github.com/clojure/core.typed http://typedclojure.org/ я сам не пробовал если что ну и пишу на ts пока что) просто интересно мнение

да мы выше обсуждали это если коротко, то идея втащить типы в язык который изначально задумывался как очень динамический не то чтоб обречена на успех

http://mutanatum.com/posts/2017-01-12-Browser-FP-Head-to-Head.html

странный пост "Flow types are optional, so you can not gain a guarantee of safety." интересно, что вообще он имеет ввиду хотя, много всего затронуто, как минимум стоит внимания

да, прогон какой-то

возможно за этим стоит какая-то разумная мысль, но выразить ее автор не смог

Ну типа на тебя ничто не ругается, когда где-то что-то не type-safe

это как так? в чем тогда смысл flow?

ну ты можешь сделать что-то type-safe, но никогда не уверен, что сделал всё

почему? ну то есть в существующем проекте такая проблема может быть, да и то должна решаться добавлением // @flow во все существующие файлы если проект пишется с нуля, но вообще такой проблемы нет

если ты не напишешь где-то тип, это не ошибка с точки зрения flow

да, но если эта часть кода как-то связана с уже аннотированным, то будет работать type inference

"Flow types are optional, so you can not gain a guarantee of safety" – просто с тз логики это странное утверждение

да

в данном случае под guarantee имеется в виду ситуация "если бы где-то не было safety, я бы об этом узнал"

всё в порядке с точки зрения логики

ладно, я не использовал толком, так что хз если читать документацию, то в статье какой-то бред

в ts это решается включением noImplicitAny

я это понял так "если можно не писать типы, то нельзя гарантировать типобезопасность", но это же не так, такой вывод нельзя сделать правильно было бы сказать "если можно не использовать типы и их не использовать, то нельзя гарантировать типобезопасность"

ишуе почти 2 года https://github.com/facebook/flow/issues/298

да, я это прямо сейчас читаю

как-то печально это

если можно не использовать типы, нельзя гарантировать что ты их не (не (используешь))

вот это корректно, да, тут не поспоришь) а у него – нет

но из этого и второго твоего утверждения следует авторское

хотя да, ты прав это я дурак

это и называется плохо выразить свою мысль )

)

он перепрыгнул часть рассуждений

стало непонятно

Когда там котлинджс выползет?

фанаты прогрессивных систем типизации поговаривают, что из компилируемых в джс f# очень приятен и котлин на его фоне не нужен

фанаты прогрессивных систем типизации поговаривают, что из компилируемых в джс f# очень приятен и котлин на его фоне не нужен

ну, ф-шарп это ж под мелкомягких

Привет Игорь

Так можно просто кавередж типами чекать у флоу

Выставить 100% и ронять билд, если не 100

Привет Игорь

Привет ?

а зачем вообще curryN? зачем сознательно ограничивать "кол-во каррируемых аргументов"? почему просто не юзать постоянно curry? хотя..

Разные кейсы бывают

я в общем-то как-то вроде уяснил, но пример не могу себе придумать, а в доках такие примеры, типа сложить 4 числа) ну, т.е. хорошие для понимания что делается

наверное просто оптимизация типа там случай для 2-3-4 аргументов написан руками и быстрее чем общий

вот тоже думал об этом, ну и + еще чтобы наложить ограничение там, где это мб нужно явно

Не быстрый, они почти одинаково медленные)

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

Ну там ничего особо сложного)

Не быстрый, они почти одинаково медленные)

если были бы почти одинаково медленные не было 4 функций каррирования

хотяяя

ща

https://github.com/ramda/ramda/blob/v0.23.0/src/internal/_curry1.js

https://github.com/ramda/ramda/blob/v0.23.0/src/internal/_arity.js#L4

https://github.com/ramda/ramda/blob/v0.23.0/src/internal/_curryN.js

в _arity.js я не понял зачем так делается UPD: понял, все просто

если были бы почти одинаково медленные не было 4 функций каррирования

Ну я забенчмаркал рамду немного, результаты меня не очень впечатлили)

а ты ждал что будет как js-лапша по скорости? )

а ты ждал что будет как js-лапша по скорости? )

В лодаше например compose почти в два раза быстрее

В лодаше например compose почти в два раза быстрее

лодаш не настолько упорото-функционален ) ну и лодаш вылизать успели за эти годы прилично так

лодаш не настолько упорото-функционален ) ну и лодаш вылизать успели за эти годы прилично так

+

а зачем вообще curryN? зачем сознательно ограничивать "кол-во каррируемых аргументов"? почему просто не юзать постоянно curry? хотя..

нужно для каррируемых функцией с плавающей арити

а почему просто не использовать для каррируемых функций с плавающей арити обычный curry все время?

эм

ну

чтобы каррировать арити должен быть фиксированным, например

пока не понимаю, а можно пример? если не сложно

понял, все

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

да, пробовал

=)

я видел у тебя еще https://github.com/iamstarkov/fp-js-workshop/blob/master/02-practical-intro.md#curry-from-the-inside ок, ну я понял R.curryN(4, (...args) => R.sum(args))(1, 2)(3)(4); — curry: https://goo.gl/gsUFyG но curryN: https://goo.gl/o18lH5, https://goo.gl/1L2zDL

тип того

Скидывали статью на днях, что в МИТ перестали преподавать по сицп. Имеет смысл её все еще изучать или стоит что-то другое искать?

если устраивает programming by poking, то не надо

а так же надо пользоваться питоном

и из этого чата выйти :)

http://www.posteriorscience.net/?p=206

на самом деле SICP там все еще используют, но в другом курсе

надо пропускать некоторые задачки

имхо

иначе невозможно осилить

почему?

сложна)

да ну )

хотя я не знаю

читаю вторую главу

но задачи не пропускаю

другое дело, что там были задачи для которых современные компы слишком быстрые

ну круто, я так не смог сначала решал все подряд тоже, потом стал пропускать, потом просто стал читать

может спешил слишком? там если отложить задачу и дать мозгу отвлечься, через пару дней становится понятнее

да, спешил

ясно