Fork me on GitHub
#clojure-russia
<
2015-07-21
>
Kira Sotnikov11:07:02

racktear: welcome!

racktear11:07:06

Привет!

racktear11:07:51

А вот расскажите, как в clojure можно удобно герерировать список? Я имею ввиду аналог “loop” (http://www.gigamonkeys.com/book/loop-for-black-belts.html)

racktear11:07:49

В common lisp есть удобная кляуза “collect”, которая позволяет добавить в результирующий список что-то

racktear11:07:27

Я могу сделать процедурно, сделав биндинг при помощи let, и в for собирать туда данные

racktear11:07:40

но хочется более функциональное решение

delaguardo11:07:07

(map lambda (range 100))

delaguardo11:07:27

если я правильно вас понял)

delaguardo11:07:13

а так еще есть repeat и его производные

racktear11:07:17

Это хорошо, когда количество результирующих элементов - такое же

racktear11:07:49

а у меня есть необходимость в результирующую коллекцию иногда по нескольку элементов вставлять

racktear11:07:31

Пример:

racktear11:07:49

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

konukhov11:07:49

привет. “взять исходный список и продублировать все четные элементы” mapcat тут подойдет. (mapcat #(if (even? %) [% %] [%]) (range 1 100))

racktear11:07:20

Вот! mapcat это то, что нужно

racktear11:07:22

спасибо!

konukhov11:07:24

а collect это же reduce, нет?

racktear11:07:42

это я про CL

konukhov11:07:04

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

racktear11:07:50

вот как сделать процедурно - это понятно. у меня за 2 последних года мозг размяк, похоже

racktear11:07:05

Вообще в common lisp было вот такое еще: https://common-lisp.net/project/iterate/doc/Introduction.html#Introduction

konukhov11:07:07

у меня тоже, но от clojure и чтения про функциональные языки – твердеет постепенно.

konukhov11:07:40

как раз искал про коллект в cl, спасибо

racktear11:07:11

В iterate вообще магия:

racktear11:07:25

Я исключительно на нем решил около 50 задач на project euler в свое время

racktear11:07:49

вот бы такое на кложе

konukhov11:07:48

крутая штука.

delaguardo13:07:49

а пользовал кто boot для сборки?

konukhov13:07:11

я использовал

konukhov13:07:52

сейчас подумываю свой апп c lein на boot перетащить. кода больше писать, но так намного удобнее таски описывать.

konukhov13:07:04

удобнее, чем этот огромный map в project.clj

konukhov13:07:40

я не могу этого объяснить

konukhov13:07:01

представь, у тебя есть core неймспейс с -main

konukhov13:07:16

если ты хочешь заинжектить какие-то дополнительные :resource-paths для какого-то таска, придется писать таск, который динамически реквайрит твой основной неймспейс после таска с путями, а main вызывать через ns-resolve. как-то так.

konukhov13:07:29

но в целом, я бы только им пользовался.

konukhov14:07:24

cljs не пробовал с ним еще, кстати. писал микросервис без фронтенда simple_smile

delaguardo14:07:24

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

racktear14:07:44

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

konukhov14:07:47

в целом, мне кажется, логично, что тебе в build.boot не нужен (require ‘[my-app.core]), потому что там могут быть таски (большинство), которым не нужен твой кор, и следовательно правильно реквайрить его только там, где будут вызываться методы оттуда. более того, я недавно видел в каком-то репо, как чуваки так же делают. бут развивается, думаю, это просто надо как-то стандартизировать. или сделать плагин для неймспейсов.

konukhov14:07:28

внутри которого уже будут макросы, которые все эти ns-resolve вызывают.

konukhov14:07:53

@racktear: я читал, что вроде для ноды кто-то пробовал или использует.

konukhov14:07:06

чуть ли не тут, в чатике cljs

racktear14:07:41

да, хочется на ноде запустить

racktear14:07:02

у меня есть проектик, который в будущем упакую в нативное приложение

konukhov14:07:19

нативное для чего?

konukhov14:07:38

а, понял. я про ios спросил, потому что Девид Нолен как раз рассказывал про cljs под ios – https://github.com/omcljs/ambly может быть под мак это тоже как-то портируют, хотя я не представляю, насколько это возможно.

dottedmag15:07:14

JavaScriptCore.framework в OS X с 10.4, что ли, в базовой системе.

racktear15:07:25

мне интересно вот так

racktear15:07:36

лайт тейбл написан на кложе

Kira Sotnikov15:07:52

racktear: а что не так?

Kira Sotnikov15:07:58

имакс на илиспе

racktear15:07:10

я хочу так же приложение запаковать

racktear15:07:17

но не понимаю, как они это сделали

racktear15:07:43

они используют node.js + chromium

racktear15:07:56

и clojurescript и на фронте и на бэке

racktear15:07:32

а, все. нашел. вопрос отпал.

racktear15:07:45

Они используют electron: http://electron.atom.io

kirillov16:07:14

а вот ребята на CommonLisp сделали оринигальную вещь https://github.com/ceramic/ceramic Друзья, теоретически, такое возможно на Clojure?

racktear16:07:45

возможно. LightTable так сделан

linuccio18:07:51

LightTable на ClojureScript поверх хромиума

linuccio18:07:46

Если проект уровня Emacs, то можно смириться с размерами и аппетитами simple_smile

delaguardo18:07:59

что atom, что lighttable тормозят как черт знает что

linuccio18:07:20

Вообще, LightTable сыроват, и загнётся видимо через какое-то время

delaguardo18:07:26

и это, скорей всего, корни хромиума

delaguardo18:07:04

ну врядли загнется, идеи там верные заложены

linuccio18:07:20

Кто-то мне рассказывал, что как раз немного не подрасчитали с философией и реализацией

linuccio18:07:01

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

linuccio18:07:04

Особенно, когда дело касается работы с БД

delaguardo18:07:25

ну не, философию они взяли из emacs, а вот реализацию перетащили в хроимиум

delaguardo18:07:55

тут то все и накрылось, (имхо, имхо)

linuccio19:07:06

я в основном про inline evalution, ну надеюсь обойдут это и компы помощнее станут через несколько лет simple_smile

linuccio19:07:52

Я сильно не углублялся, но первые впечатления были не очень приятные

linuccio19:07:06

В частности и из за багов

racktear19:07:14

Ваш slack - тоже джаваскрипт поверх хромиума

racktear19:07:20

так, к слову

gordon19:07:15

по нему, кстати, заметно

delaguardo19:07:15

для слака это оправданно

delaguardo19:07:24

)) и то верно)

delaguardo19:07:10

а вот редактор завязывать на него… хреновая идея. имхо

racktear19:07:40

elisp медленнее джаваскрипта

delaguardo19:07:31

ого, а пруф?

dottedmag19:07:34

Точнее, реализация ELisp в Emacs медленнее, чем какой-нибудь V8

dottedmag19:07:58

delaguardo: JIT V8 генерирует код, сравнимый с нативным по производительности.

delaguardo19:07:15

реализация ELisp и V8 это немного разные веши

linuccio19:07:32

Вообще, хотелось бы конечно Emacs на Clojure

linuccio19:07:40

И ещё Clojure на LLVM simple_smile

linuccio19:07:01

вроде была попытка Clojure на LLVM, но загнулась

linuccio19:07:30

У меня оконный менеджер StumpWM написанный на Common Lisp - прекольный, но лезть в исходники пока желания нет

linuccio19:07:43

Был бы на Clojure, можно было бы что-то помастерить

linuccio19:07:54

Ну, это уже субъективное конечно...

dottedmag19:07:27

Clojure на LLVM - это Clojure без библиотек

linuccio19:07:41

Без каких?

linuccio19:07:00

Ну, у него и цели немного другие будут

linuccio19:07:26

Что-то без изменений перенесётся, что-то нужно портировать будет

linuccio19:07:29

А что-то и не нужно

racktear19:07:29

emacs не перепишется на другой лисп

racktear19:07:33

были попытки

racktear19:07:42

кода слишком много.

linuccio19:07:40

Да, но хочется

linuccio19:07:20

По идее, куча вещей, модулей не нужных лично мне там

linuccio19:07:55

Я вот не догоню только, почему Clojure на LLVM основывали на ClojureScript компиляторе...