Comments 133
Феерично :D
+27
А есть какой-нибудь специальный хабрамем для банальнейшего комментария, набирающего кучу плюсов только потому, что оставлен первым? )
+27
Просмотр этого доклада продлевает жизнь ))
PS. Полный список докладов с этой конференции frameworksdays.com/event/js-frameworks-day-2013/page/program
PS. Полный список докладов с этой конференции frameworksdays.com/event/js-frameworks-day-2013/page/program
+2
НЛО прилетело и опубликовало эту надпись здесь.


+4
Люблю такие формы докладов, не занудное читание с бумажки, а именно такая импровизация, и классный юмор.
+29
Будьте проще и люди к вам потянутся :-)
+10
Смешной, веселый парень.
«Шота я парю, вообще такое.» ©
«Шота я парю, вообще такое.» ©
+18
Надо распарсить на цитаты его выступление.
+11
UFO just landed and posted this here
хорошо бы увидеть примеры слайдов
+1
Все вставляют в свои доклады женщин и котиков. Все. Уже лет пять. На этих котиков уже смотреть тошно.
Непонятно, почему все считают, что если не смогли интересно подать информацию — котик спасет.
Ох.
Непонятно, почему все считают, что если не смогли интересно подать информацию — котик спасет.
Ох.
+63
А разве это не так?
+1
Видимо потому, что сейчас конференций как грязи и каждый суслик агрономстудент докладчик.
0
Полная версия выступления:
www.youtube.com/watch?v=R4sTvHXkToQ
www.youtube.com/watch?v=R4sTvHXkToQ
+12
Хорошее выступление. Отлично сбалансировано, что, к сожалению, не часто встречается на технических конференциях. Чаще выходит либо совсем-совсем по делу и вдаваясь в детали (аудитория засыпает) либо много шуток и совсем мало по делу (аудитория не понимает, что они тут забыли).
+7
В топике, вообще-то, не очень смешная выжимка. Полный доклад лучше: www.youtube.com/watch?v=R4sTvHXkToQ
+7
Крутой мужик, жму руку :)
+9
Такое выступление, конечно, не утомит, но не факт, что аудитория запомнит главное, а не шутки.
+14
Лично я через пять минут потерял суть доклада :)
Можно объяснить еще и тем, что этот доклад был последним и все уже порядком устали за весь день
Можно объяснить еще и тем, что этот доклад был последним и все уже порядком устали за весь день
+2
Я был уверен, что большая часть аудитории не запомнит главное просто потому, что идея достаточно сложная и таки да, я был последним выступающим — я очень не хотел им быть, потому что был уверен, что будет всë плохо, но в результате таки довольно неплохо получилось, имхо.
Я в целом надеялся, что люди таки уловят суть. Если посмотреть полную версию, то (я очень надеюсь на это!) должно быть заметно, что я таки стараюсь объяснить, о чëм речь. Большая проблема темы в том, что никто о ней не рассказывает/не пишет понятными словами, все быстро скатываются на специфичную терминологию и считают само собой разумеющимся, что всем понятно, о чëм речь и зачем это.
Короче, мне кажется — тема тяжëлая, и понятно рассказать еë тяжело, и я старался, а вот получилось ли… :)
Я в целом надеялся, что люди таки уловят суть. Если посмотреть полную версию, то (я очень надеюсь на это!) должно быть заметно, что я таки стараюсь объяснить, о чëм речь. Большая проблема темы в том, что никто о ней не рассказывает/не пишет понятными словами, все быстро скатываются на специфичную терминологию и считают само собой разумеющимся, что всем понятно, о чëм речь и зачем это.
Короче, мне кажется — тема тяжëлая, и понятно рассказать еë тяжело, и я старался, а вот получилось ли… :)
+95
Чëрт, почему на хабре нельзя редактировать комментарии? Я не всегда так косноязычен, если что, только когда поспешу. :))
+22
В целом, про ячейки таблицы понятно, буду пробовать, тем более все лучше понимается на практике. Сам сейчас копаюсь в событиях и хотелось бы как то упростить вещи, потому что понимаю, что упростить как то можно, но опыта для того чтобы понять как — нет.
+1
Напишите адрес своего блога. Мне бы пофанатить.
+1
Мне кажется, что MVC и Angulare очень близко перекликаются с тем, что состояние приложения нужно обрабатывать переменными, а не событиями.
0
Я не люблю AngularJS за внутренний дизайн, за апи и за доки. Ну и несмотря на data-binding, это таки не FRP, хотя в первом приближении на практике не очень отличается.
MVC — это вообще о другом, реально. И Angular не MVC, и FRP в эту модель тяжело будет впихнуть. Не уверен, что классический MVC — это то, что точно необходимо, впрочем.
MVC — это вообще о другом, реально. И Angular не MVC, и FRP в эту модель тяжело будет впихнуть. Не уверен, что классический MVC — это то, что точно необходимо, впрочем.
+3
Насколько проблема непонятности докладов специфична для области ИТ? Насколько это вообще проблема? Ну, то есть, поверхностно я понимаю идею — если мы будем просто и понятно рассказывать о разных штуках, скорость обмена информацей и развития технологического стека, может быть, увеличатся. Но по размышлении все становится не так однозначно.
Очевидно (мне, но я могу ошибаться), что большая часть технологий, используемых сейчас в индустрии — сложные, и чем глубже ты куда-то закапываешься и чем подробнее начинаешь чем-то заниматься, тем сложнее становится. Очевидно, что освоение каждой технологии занимает слишком много времени и сил, чтобы это можно было считать подходящим способом ознакомления с веяниями нашего ИТ-мира. Отрадно, что несколько тысяч лет назад человек научился использовать метафоры, чтобы доступно объяснять сложные вещи. Но.
Метафора и упрощение работают за счет того, что новую и непонятную для себя ситуацию мы проецируем на знакомую и понятную модель. В том редком случае, когда метафора и исходная модель совпадают, все отлично. Когда же метафора расходится с реальной ситуацией, возникает много проблем, и самое главное, это неявные проблемы для человека, который пытается эту метафору освоить. У меня сейчас не получается внятно сформулировать свою мысль, но суть в том, что когда мы рассказываем про квадрат и говорим «ребят, квадрат — сложная штука, но для простоты давайте представим, что это круг», мы оказываемся в тупике. Часть людей говорит «эй, у меня уже есть мой привычный круг, я давно им пользуюсь, зачем мне какой-то там квадрат?». Другая часть говорит «блин, там какие-то стремные углы, нафига вообще это надо?». Третья часть пишет на форумах «услышали клёвый доклад про квадраты, попытались заюзать в продакшне и, короче, когда рассчитывали площадь по формуле Pi*R^2, все упало. Стали отлаживать — а там вместо радиуса отстой какой-то. Квадраты говно.» И мы оказываемся на исходной — либо рассказывай про детали (и получай сложный доклад), либо рассказывай доступно и оставляй глобальный информационный вакуум вокруг своей темы, но тогда возникает вопрос, а чего изначально мы пытаемся добиться, когда читаем доклады.
Ну, то есть, я к чему вообще всё это словоблудие — есть ли иной путь, кроме как использовать специфичную терминологию и рассказывать тяжело?
Очевидно (мне, но я могу ошибаться), что большая часть технологий, используемых сейчас в индустрии — сложные, и чем глубже ты куда-то закапываешься и чем подробнее начинаешь чем-то заниматься, тем сложнее становится. Очевидно, что освоение каждой технологии занимает слишком много времени и сил, чтобы это можно было считать подходящим способом ознакомления с веяниями нашего ИТ-мира. Отрадно, что несколько тысяч лет назад человек научился использовать метафоры, чтобы доступно объяснять сложные вещи. Но.
Метафора и упрощение работают за счет того, что новую и непонятную для себя ситуацию мы проецируем на знакомую и понятную модель. В том редком случае, когда метафора и исходная модель совпадают, все отлично. Когда же метафора расходится с реальной ситуацией, возникает много проблем, и самое главное, это неявные проблемы для человека, который пытается эту метафору освоить. У меня сейчас не получается внятно сформулировать свою мысль, но суть в том, что когда мы рассказываем про квадрат и говорим «ребят, квадрат — сложная штука, но для простоты давайте представим, что это круг», мы оказываемся в тупике. Часть людей говорит «эй, у меня уже есть мой привычный круг, я давно им пользуюсь, зачем мне какой-то там квадрат?». Другая часть говорит «блин, там какие-то стремные углы, нафига вообще это надо?». Третья часть пишет на форумах «услышали клёвый доклад про квадраты, попытались заюзать в продакшне и, короче, когда рассчитывали площадь по формуле Pi*R^2, все упало. Стали отлаживать — а там вместо радиуса отстой какой-то. Квадраты говно.» И мы оказываемся на исходной — либо рассказывай про детали (и получай сложный доклад), либо рассказывай доступно и оставляй глобальный информационный вакуум вокруг своей темы, но тогда возникает вопрос, а чего изначально мы пытаемся добиться, когда читаем доклады.
Ну, то есть, я к чему вообще всё это словоблудие — есть ли иной путь, кроме как использовать специфичную терминологию и рассказывать тяжело?
+2
Есть две стороны проблемы. Если рассказывать что-то заранее заинтересованному человеку, то можно (попытаться?) устроить полное погружение, рассказывать тяжело и подробно.
Но в моëм случае задача была не столько полностью рассказать о всех тонкостях, сколько заинтересовать слушателей. Очевидно, что тогда рассказ нужен такой, чтоб человек, который не видит особенного смысла в том, о чëм я рассказываю (а такими были фактически все), заинтересовался.
Мне хотелось, чтоб смысл не потерялся, но я не мог себе позволить говорить чëткие и технически верные определения — я до этого доклада (до не в смысле «за ночь до») сам пытался въехать в FRP и хорошо себе в тот момент представлял то, насколько тяжело уловить его полезность за всеми этими технически верными определениями.
Но в моëм случае задача была не столько полностью рассказать о всех тонкостях, сколько заинтересовать слушателей. Очевидно, что тогда рассказ нужен такой, чтоб человек, который не видит особенного смысла в том, о чëм я рассказываю (а такими были фактически все), заинтересовался.
Мне хотелось, чтоб смысл не потерялся, но я не мог себе позволить говорить чëткие и технически верные определения — я до этого доклада (до не в смысле «за ночь до») сам пытался въехать в FRP и хорошо себе в тот момент представлял то, насколько тяжело уловить его полезность за всеми этими технически верными определениями.
+7
Вы в конце прошлись по эрлангу — вы нигде не расписывали свою точку зрения более подробно? Хотелось бы почитать не восторженный отзыв на него. Сам я эрлангом не занимался, но многократно слышал, что scala многое взяла из него.
0
Скала? Из Эрланга? Та ну, никакой связи, кроме Akka, которая сторонняя библиотека (еë взяли внутрь уже, но всë же).
На тему самого Эрланга — не очень подробно, но всë же: www.facebook.com/kachayev/posts/492248150824885
На тему самого Эрланга — не очень подробно, но всë же: www.facebook.com/kachayev/posts/492248150824885
+4
Та ну, никакой связи, кроме Akka, которая сторонняя библиотека (еë взяли внутрь уже, но всë же).
У вас несколько не верные сведения. Акторы изначально часть стандартной библиотеки. Или по крайней мере давно, но версию не найду сходу.
Сейчас они deprecated и вместо них рекомендуется использовать akka, но они все еще в стандартной библиотеке.
Жаль, по ссылке срыва покровов нет. Но все равно спасибо!
PS Забавно, в стандартной библиотеке scala тоже нет дат.
0
Хм, окей, как-то я это пропустил. Буду знать, спасибо.
0
Забыл написать в прошлом комментарии: раньше (уж не знаю как сейчас) на всех презентациях по scala, на которых упоминались акторы, тут же упоминали эрланг как их первоисточник. Потому я и сказал про заимствования.
0
Ага, прикол. Ну, я про скалу читал и чуть разбирался, но презентации не смотрел и этот момент умудрился пропустить абсолютно. Сейчас глянул — даже в википедии есть Influenced by Erlang, глаз замылен.
Да, срыва покровов нет, у меня нелюбовь к Ерлангу больше от того, что его парят как светлое будущее, а он не только не лучше альтернатив, а зачастую заметно хуже. И софт-прорыв-в-мейнстрим, написанный на нëм — Ejabberd — внутри довольно-таки страшен после всех лет развития. Prosody на мой вкус ровнее, а написан на совершенно непримечательной Lua.
Да, срыва покровов нет, у меня нелюбовь к Ерлангу больше от того, что его парят как светлое будущее, а он не только не лучше альтернатив, а зачастую заметно хуже. И софт-прорыв-в-мейнстрим, написанный на нëм — Ejabberd — внутри довольно-таки страшен после всех лет развития. Prosody на мой вкус ровнее, а написан на совершенно непримечательной Lua.
+1
По всему, что я читал о Erlang, он мне тоже не нравится (в основном динамической типизацией и синтаксической бедностью).
Но для меня его преимущество именно в этом «Influenced». И тут не только scala, но и Rust.
Кстати, по поводу FRP и scala: Deprecating the Observer Pattern. Правда все реализации (например 1, 2) как-то застопорились в развитии.
Но для меня его преимущество именно в этом «Influenced». И тут не только scala, но и Rust.
Кстати, по поводу FRP и scala: Deprecating the Observer Pattern. Правда все реализации (например 1, 2) как-то застопорились в развитии.
0
Жаль, что меня не было на этой презентации. К сожалению вам задавали много вопросов не по теме: про Кложу, про Джаваскрипт, про Эрленг, какую-то корпоративную муть даже спрашивали. Хотя на тему самого FRP тут есть много интересных проблем.
Например, хотелось бы услышать вашу точку зрения по поводу проблемы больших графов связей с узлами повторяющихся типов. Самый простой пример такого случая — древовидный, иерархия комментариев, как в Хабре. Непонятно, как в общем случае прибиндить данные к комментариям, не обновляя всю структуру DOM каждый раз при редактировании комментария, и без нереактивных хаков.
К слову, раскритикованный вами elm таки решает эту проблему. Правда создает при этом другие.
В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
Например, хотелось бы услышать вашу точку зрения по поводу проблемы больших графов связей с узлами повторяющихся типов. Самый простой пример такого случая — древовидный, иерархия комментариев, как в Хабре. Непонятно, как в общем случае прибиндить данные к комментариям, не обновляя всю структуру DOM каждый раз при редактировании комментария, и без нереактивных хаков.
К слову, раскритикованный вами elm таки решает эту проблему. Правда создает при этом другие.
В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
+1
> Непонятно, как в общем случае прибиндить данные к комментариям, не обновляя всю структуру DOM каждый раз при редактировании комментария, и без нереактивных хаков.
Да, это очень тяжëлый вопрос и у меня (как в целом и у всех, вроде бы — я пытаюсь следить, что там люди выдумывают) нет ответа. Мне кажется, что можно забить на правильность и внутри реализации списка схачить и завязать его жестко на DOM.
> К слову, раскритикованные вами elm таки решает эту проблему. Правда создает при этом другие.
btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает. Но всë равно он недохаскель и это немножечко страшно (и то, что хаскель, и то, что недо), и всë равно дока говно, примеры говно (впрочем, я 2 месяца назад последний раз смотрел, но лень уже)…
> В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
Для прототипа/концепта сгодится перерисовывание, для рабочих вещей — инкапсуляция работы с домом внутри итерации. Вот как в фейсбуковом React'e, снаружи всë ровно, а внутри хитрые пляски с домом.
Да, это очень тяжëлый вопрос и у меня (как в целом и у всех, вроде бы — я пытаюсь следить, что там люди выдумывают) нет ответа. Мне кажется, что можно забить на правильность и внутри реализации списка схачить и завязать его жестко на DOM.
> К слову, раскритикованные вами elm таки решает эту проблему. Правда создает при этом другие.
btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает. Но всë равно он недохаскель и это немножечко страшно (и то, что хаскель, и то, что недо), и всë равно дока говно, примеры говно (впрочем, я 2 месяца назад последний раз смотрел, но лень уже)…
> В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
Для прототипа/концепта сгодится перерисовывание, для рабочих вещей — инкапсуляция работы с домом внутри итерации. Вот как в фейсбуковом React'e, снаружи всë ровно, а внутри хитрые пляски с домом.
+1
Благодарю вас за ответ.
На мой взгляд, проблема реактивного программирования кроется в том, что система таких вот реактивных связей по большому счету образует не более, чем конечный автомат. Ну, можно сказать, что конечный автомат с параметрами, но в любом случае, мы не можем решать тьюринг-полные задачи таким путем.
Я думаю, что идея не выстрелит в конечном итоге. Хотя большую движуху ожидать стоит.
Более правильным решением было бы что-то между событийно-ориентированным подходом, когда мы явно контролируем все процессы, и реактивным, когда мы вообще ничего не контролируем. Нечто вроде системы сигнал-слот, чтобы можно было соединять слоты пайпами, ставить разные там фильтры(в том числе и фильтры с состоянием). Такая система с одной стороны остается более-менее декларативной и наглядной, как и реактивная, с другой — дает больше свободы действия. Если мы хотим сделать что-то более сложное, чем валидацию формочек, нам не придется хакать, делать что-то сильно неправильно.
Мне кажется elm по большому счету нечто такое нам и предлагает, только там эти «фильтры» хитро запрятаны в ленивые вычисления. Это неплохо, но я боюсь, что для широкого круга программистов освоить «хаскелль» будет слишком сложной задачей. Уже не говоря о том, что из-за принципиального отсутствия сторонних эффектов его будет сложно подружить со всем остальным миром API и библиотек.
> btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает
Я уже несколько месяцев не слежу за проектом. Надо будет посмотреть, что там сделали за это время.
На мой взгляд, проблема реактивного программирования кроется в том, что система таких вот реактивных связей по большому счету образует не более, чем конечный автомат. Ну, можно сказать, что конечный автомат с параметрами, но в любом случае, мы не можем решать тьюринг-полные задачи таким путем.
Я думаю, что идея не выстрелит в конечном итоге. Хотя большую движуху ожидать стоит.
Более правильным решением было бы что-то между событийно-ориентированным подходом, когда мы явно контролируем все процессы, и реактивным, когда мы вообще ничего не контролируем. Нечто вроде системы сигнал-слот, чтобы можно было соединять слоты пайпами, ставить разные там фильтры(в том числе и фильтры с состоянием). Такая система с одной стороны остается более-менее декларативной и наглядной, как и реактивная, с другой — дает больше свободы действия. Если мы хотим сделать что-то более сложное, чем валидацию формочек, нам не придется хакать, делать что-то сильно неправильно.
Мне кажется elm по большому счету нечто такое нам и предлагает, только там эти «фильтры» хитро запрятаны в ленивые вычисления. Это неплохо, но я боюсь, что для широкого круга программистов освоить «хаскелль» будет слишком сложной задачей. Уже не говоря о том, что из-за принципиального отсутствия сторонних эффектов его будет сложно подружить со всем остальным миром API и библиотек.
> btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает
Я уже несколько месяцев не слежу за проектом. Надо будет посмотреть, что там сделали за это время.
+1
> Такая система с одной стороны остается более-менее декларативной и наглядной, как и реактивная, с другой — дает больше свободы действия.
Это да, без некоторого состояния в паре мест ну просто очень тяжело будет. Если что, я не за то, чтоб всë сделать идеально, pure shit, иначе я был бы фанатом Хаскеля. А так как мне нравятся более простые и близкие к жизни решения, то я не против того, что надо сделать рабочую систему. Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
> Если мы хотим сделать что-то более сложное, чем валидацию формочек
Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире. :)
На Эльм еще посмотрим. Но освоить его очевидно тяжело, может позже, когда раздуплятся на внятный туториал, а не «введите эти 3 строки вот в это место; смотрите — мячик прыгает; введите еще 2 строки — и он прыгает иначе!»
Это да, без некоторого состояния в паре мест ну просто очень тяжело будет. Если что, я не за то, чтоб всë сделать идеально, pure shit, иначе я был бы фанатом Хаскеля. А так как мне нравятся более простые и близкие к жизни решения, то я не против того, что надо сделать рабочую систему. Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
> Если мы хотим сделать что-то более сложное, чем валидацию формочек
Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире. :)
На Эльм еще посмотрим. Но освоить его очевидно тяжело, может позже, когда раздуплятся на внятный туториал, а не «введите эти 3 строки вот в это место; смотрите — мячик прыгает; введите еще 2 строки — и он прыгает иначе!»
+1
> А так как мне нравятся более простые и близкие к жизни решения, то я не против того, что надо сделать рабочую систему.
Солидарен. Фанатов Хаскеля, кстати, тоже интересно троллить, особенно новообращенных. В этом языке далеко не все вещи такие уж чистые от сторонних эффектов, но новичики это не всегда замечают.
> Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
Я тоже этим целыми днями занимаюсь. Работу эту не люблю, разумеется, но кушать каждый день хочется. Мне все-таки кажется, причина этого содома не в JS, а в людях. Ну даже во время вашего доклада было видно, что уровень аудитории довольно не высокий. И это, к сожалению, норма.
> Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире.
Особенно если посмотреть на то, что нам предлагает Angular, задача становится вдвойне сложнее. :)
Недавно пришлось поработать с этим фреймвокром вплотную. Осталось впечатление, что API делали фанаты Java/C#. Какие-то повсюду совершенно ненужные нагромождения. При этом отсутствует очевидно необходимые вещи, такие, скажем, как полноценные модули. И подружить Энгьюлар с чем-либо сложно, повсюду швы.
Солидарен. Фанатов Хаскеля, кстати, тоже интересно троллить, особенно новообращенных. В этом языке далеко не все вещи такие уж чистые от сторонних эффектов, но новичики это не всегда замечают.
> Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
Я тоже этим целыми днями занимаюсь. Работу эту не люблю, разумеется, но кушать каждый день хочется. Мне все-таки кажется, причина этого содома не в JS, а в людях. Ну даже во время вашего доклада было видно, что уровень аудитории довольно не высокий. И это, к сожалению, норма.
> Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире.
Особенно если посмотреть на то, что нам предлагает Angular, задача становится вдвойне сложнее. :)
Недавно пришлось поработать с этим фреймвокром вплотную. Осталось впечатление, что API делали фанаты Java/C#. Какие-то повсюду совершенно ненужные нагромождения. При этом отсутствует очевидно необходимые вещи, такие, скажем, как полноценные модули. И подружить Энгьюлар с чем-либо сложно, повсюду швы.
+1
> Мне все-таки кажется, причина этого содома не в JS, а в людях. Ну даже во время вашего доклада было видно, что уровень аудитории довольно не высокий.
Надо сказать, что это была самая классная аудитория этого доклада (я его в общей сложности 5 раз рассказывал). Но на тему «не в жс, а в людях» — я пытался обсуждать проблему с людьми, которые пишут традиционные ГУИ — они ж там должны были всë порешать давно, да? Та же жопа, те же ивенты, такая же лапша.
Я вот в новый проект взял фейсбуковый React и пока доволен, он в целом как компромисс между практичностью и разумностью вроде бы ничего, но еще рано что-то утверждать, 3 недели пока код пишем только. :)
Про angular хочется молчать.
Надо сказать, что это была самая классная аудитория этого доклада (я его в общей сложности 5 раз рассказывал). Но на тему «не в жс, а в людях» — я пытался обсуждать проблему с людьми, которые пишут традиционные ГУИ — они ж там должны были всë порешать давно, да? Та же жопа, те же ивенты, такая же лапша.
Я вот в новый проект взял фейсбуковый React и пока доволен, он в целом как компромисс между практичностью и разумностью вроде бы ничего, но еще рано что-то утверждать, 3 недели пока код пишем только. :)
Про angular хочется молчать.
+1
Хм… не ожидал, что у Фейсбука может быть что-то стоящее :) Ладно, я тогда тоже присмотрюсь к этому фреймворку повнимательнее. Спасибо.
+1
Надо свыкнуться с мыслью, конечно, что это не unobtrusive JS, а прямая противоположность — хтмл внутри жс, но потом всë идëт хорошо. Более того, мне кажется, что unobtrusive JS в случае с полноценными внутрибраузерыми приложениями не работает, и то, что делает реакт — правильно (хотя хоплон делает еще правильнее, имхо — делит на внутреннее апи и внешний интерфейс).
+1
Нет уж, общественность желает знать про angularjs :)
Что там не так?
Что там не так?
0
Пиранья рулит :)
Кложе, в частности кложаскрипте, щас очень популярны заигрывания с core.async. И не просто так, вся та размытость кода сильно уменьшается. А есть еще очень забавный pedastral.io, там стейт эксплицитней некуда.
Вообще, количество движухи в кложа-мире очень радует, я про javelin и не слышал даже.
Спасибо за доклад :)
Кложе, в частности кложаскрипте, щас очень популярны заигрывания с core.async. И не просто так, вся та размытость кода сильно уменьшается. А есть еще очень забавный pedastral.io, там стейт эксплицитней некуда.
Вообще, количество движухи в кложа-мире очень радует, я про javelin и не слышал даже.
Спасибо за доклад :)
0
Да, я вот на clojurecup планирую попробовать интерфейс на core.async построить и посмотреть, как оно. А вот пьедесталом я что-то пока совсем не проникся, может тоже попробовать надо, но вот читал туториал — и сложилось впечатление, что слишком много слов.
На тему джавелина еще надо упомянуть хоплон (который в марте еще хлиспом назывался) — github.com/tailrecursion/hoplon
И вообще, спасибо за отзыв! :)
На тему джавелина еще надо упомянуть хоплон (который в марте еще хлиспом назывался) — github.com/tailrecursion/hoplon
И вообще, спасибо за отзыв! :)
0
Хотел бы прояснить, правильно ли я понял что такое FRP. У себя в проекте мы сделали модель, похожую на сигнал-слотовую модель в QT, только на javascript. Сойдет ли это за FRP?
0
А вообще вы молодец. Я вот человек который долек от программирования (скрипты я не считаю) и который давно мечтает начать, очень захотелось начать теперь не с python, а с lisp :)
Но надеюсь, через неделю остыну и все же достану давно купленную книгу по python.
Но надеюсь, через неделю остыну и все же достану давно купленную книгу по python.
0
Добрый время суток! Алексей, я смотрел ваш доклад в полной версии, веселый и познавательный спасибо!
в конце доклада были ссылки, можно их скинуть?
в конце доклада были ссылки, можно их скинуть?
0
UFO just landed and posted this here
«хотел бы я тоже уметь вот так думать — мозгом!»
Всегда уважал людей, способных объяснить любые вещи просто и понятно. А то бубнят на этих конференциях под нос с бумажки что-то типа «конвергенция эффективности буферизации кластеризированного энвайромента» — и ты просто выпадаешь в осадок от этой лапши на ушах.
Всегда уважал людей, способных объяснить любые вещи просто и понятно. А то бубнят на этих конференциях под нос с бумажки что-то типа «конвергенция эффективности буферизации кластеризированного энвайромента» — и ты просто выпадаешь в осадок от этой лапши на ушах.
+20
Верка Сердючка нервно курит в сторонке :)))
-11
чувак — огонь.
+10
У Scotta Hanselmana из Microsoft тоже веселые доклады.
0
Представил, как я про свою CMS «ДвижОк» рассказываю… думаю, получилось бы примерно также ((
-35
Полностью согласен про Бекон (-:
-2
Библиотека названа в честь философа Фрэнсиса Бэкона.
+4
А, вот оно что.
Как-то не очевидны ни этот факт, ни связь между Френсисом Бэконом и FRP.
Как-то не очевидны ни этот факт, ни связь между Френсисом Бэконом и FRP.
0
Этот факт очевиден из лого на их главной странице на GitHub, а также из этого обсуждения. По поводу связи FRP и Ф.Бэкона я согласен с вами. Но, согласитесь, для FRP непросто придумать осмысленную, краткую, запоминающуюся метафору.
0
Frappe? Behave.js?
Френсис Бэкон выглядит как afterthought, а не как изначальная идея.
Френсис Бэкон выглядит как afterthought, а не как изначальная идея.
0
Да, я посмотрел уже, что это FRP-библиотеки. И это лишний раз доказывает, что изначально идеальных метафор не бывает. Вам они кажутся подходящими потому, что вы их уже видели в этом контексте. Я ими не пользовался, поэтому ассоциации у меня возникают совсем другие.
0
Не понял претензий. FRaPpe — откровенный намëк на FRP, да? Behave — намëк на Behavior'ы, центральную концепцию FRP. Я даже не знал, что такие библиотеки существуют.
Зато Френсис Бэкон — это, конечно, сразу в голове ассоциируется с хорошей архитектурой интерфейсов.
Зато Френсис Бэкон — это, конечно, сразу в голове ассоциируется с хорошей архитектурой интерфейсов.
+1
Не удивительно, что вы не поняли претензий. Их нет у меня. Единственно, что я хотел сделать — это попытаться снять неоднозначность в понимании bacon.js как «бекона». C FRP я встретился первый раз в лице bacon.js, знатоком его себя не считаю, в работе не использую.
Но с университетской скамьи я знаю, что Фрэнсис Бэкон — это один из основоположников эмпиризма. А здесь уже прослеживается связь между «поведением» и «наблюдением» этого поведения. Может быть, я не понимаю FRP на столько, чтобы понять, что эта моя ассоциация лишена основания. Это я допускаю.
Но с университетской скамьи я знаю, что Фрэнсис Бэкон — это один из основоположников эмпиризма. А здесь уже прослеживается связь между «поведением» и «наблюдением» этого поведения. Может быть, я не понимаю FRP на столько, чтобы понять, что эта моя ассоциация лишена основания. Это я допускаю.
0
В комментах на ютубе предположили, что это шутка про игру слов между bacon/beacon, тогда не так всë и безобразно, конечно. :)
+2
В Readme проекта на гитхабе есть еще одно объяснение названия, дающее хорошее семантическое правило (бекон противопоставляется лапше):
Turns your event spaghetti into clean and declarative feng shui bacon
+2
Да, слушал в живую ) Очень и очень.
+2
«В лиспе все списки..»))
Шикарный доклад, запутать правда пытались частенько, но очень интересно слушать из-за «живости».
Шикарный доклад, запутать правда пытались частенько, но очень интересно слушать из-за «живости».
0
Очень крутой доклад, спасибо, как раз о наболевшем говорили.
А можно услышать мнение, почему нокаут — это плохо? Сам сейчас его использую в связке с самописным кодом и пока доволен, но всё равно немного не то. А какие у тебя нарекания к нему?
А можно услышать мнение, почему нокаут — это плохо? Сам сейчас его использую в связке с самописным кодом и пока доволен, но всё равно немного не то. А какие у тебя нарекания к нему?
0
«Я бы тоже хотел бы думать мозгом...»
Спасибо за мега-позитив!
Спасибо за мега-позитив!
0
piranha, куда пропал из emacs@c.j.r? :)
0
Давно фоловлю Александра в Твиттере, но живая речь — это что-то :)
0
Я понимаю, что статья про юморной способ подачи, но все же я скажу про тему доклада — мне кажется, или он рассказывает про что-то, нереально похожее на Qt Quick, а именно property binding? :) Там это есть и давно, и никаких громких красивых слов и абстракций не нужно было, чтобы мы начали это использовать!
0
Если Qt Quick это только property binding, то не совсем, это часть, хоть и важная (важная для юзабельности, для концепции это как раз мелочь и не основное). Я рассказываю про то, что в .NET называется Reactive Extensions (Rx.NET), про ReactiveCocoa, про Flapjax/Bacon.js, про Rx.Java, больше не знаю сходу названий. Trellis в питоне еще есть, но он мог бы быть и попрямее (у меня не получилось его использовать нормально :\).
0
Пересматриваю уже раз 10й :). Позитивчик так и прет.
0
Какой крутой чувак ^_^
0
Пропиарил ClojureScript пополной.
+1
«Ну, я не аналитик… совсем не аналитик, я программист — чихчихчих, и в продакшен»
А вообще, выступление порадовало, посмотрел на одном дыхании.
А вообще, выступление порадовало, посмотрел на одном дыхании.
+1
UFO just landed and posted this here
Если порядок нам важен, надо сделать так, чтоб второе обновление не пришло раньше первого (или как там нужно). Короче, рассчитывать на разные данные — фича в том, что у нас всегда есть какие-то данные, мы работаем со всегда существующими данными.
Т.е. прикол не в том, что с событиями так нельзя писать, прикол в том, что это тяжело делать и в эту сторону никто не направляет.
Т.е. прикол не в том, что с событиями так нельзя писать, прикол в том, что это тяжело делать и в эту сторону никто не направляет.
0
UFO just landed and posted this here
Про весь frp не скажу (не знаю), но судя по докладу, если нам важен порядок, то это уже не Frp.
А вот интересуюет поддержка циклов и интерференции.
Циклы: a->b->c->a
Интерференция: a->b->d, a->c->d
Вообще говоря, у меня сильные сомнения на счет closure — это наше все. Хотя если взглянуть на устройство природы вокруг нас (и вспомнить не менее фееричный доклад Павла Кудинова в 2010-м году), то можно утверждать, что все вокруг нас и есть одно большое closure :)
Но! Накладные расходы на презентацию пользователю глобального состояния, через машину тьюринга очень велики. (Последнее предложение получилось, как тут habrahabr.ru/post/193950/#comment_6735204) :)
А вот интересуюет поддержка циклов и интерференции.
Циклы: a->b->c->a
Интерференция: a->b->d, a->c->d
Вообще говоря, у меня сильные сомнения на счет closure — это наше все. Хотя если взглянуть на устройство природы вокруг нас (и вспомнить не менее фееричный доклад Павла Кудинова в 2010-м году), то можно утверждать, что все вокруг нас и есть одно большое closure :)
Но! Накладные расходы на презентацию пользователю глобального состояния, через машину тьюринга очень велики. (Последнее предложение получилось, как тут habrahabr.ru/post/193950/#comment_6735204) :)
0
a->b->c->a — противоречит идее. Про closure не понял. Речь о замыкании или о чëм?
0
Воодушевленный просмотром твоего доклада посмотрел еще про FRP (http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey)
Дольше и менее весело, но не менее познавательно :) (или даже более).
Если я правильно уловил ключевую мысль FRP, это то, что «ВСЕ» что мы считаем индикаторами состояний меняется постоянно и параллельно. Также, как это происходило бы в реальном мире вокруг нас. Каждый индикатор представлен не своим «значением состояния на сейчас», а виде последовательности значений зафиксированных в каких-то моментах времени. Т.е. всегда, когда мы подсматриваем значение чего-то, это значение на момент начала подглядывания, а к концу подглядывания, значение уже может быть другим, но мы не узнаем если не начнем подглядывать снова (да нам и не надо...). Есть «микро-программки» — они же обсерверы — которые умеют наблюдать «прошлое» и инициировать перевод индикаторов из состояния в состояние посредством «чистой функции», которая не ничего не знает про индикаторы (это самая примитивная машина тьюринга «текущее значение индикатора»+«сивол»->«новое значени индикатора», у тьюринга был еще сайд-эффект — напечатать что-то, которого тут нет :)).
Так к чему я все это. В этой парадигме ничто не мешает делать циклические зависимости. Даже Excel это позволяет делать (через настройки надо только задать количество итераций и/или погрешность, когда можно прекратить считать, полагая, что все ячейки устаканились).
Если пойди дальше, и сформулировать отношения (зависимости) в виде дифференциальных уравнений, то мы еще ближе приближаемся к реальному миру. Визуализацию можно представить на этой картинке: audiomap.tuneglue.net/ (поискать любое слово — потом потыкать и подергать за кружочки — остальные тянутся сами балансируя как-то между собой). То же самое можно отнести и к индикаторам, которые «подтягиваются» к изменившимся значениям других индикаторов. И все это работает параллельно. Т.е. ни у кого нет возможности зафиксировать «все состояние» — оно меняется непрерывно и мы принимая решения опираемся всегда на устаревшие данные.
Боюсь сложно уследить за моим потоком сознания, тем не менее, а причем здесь Павел Кудинов?
Так вот он и говорит (то что я для себя услышал): вычислительные мощности растут и мы можем позволить себе писать программы «а бы как», не увлекаясь исправлением всех ошибок. Ошибки были, есть и будут всегда — это данность, которую надо принять. Гораздо важнее писать код так, чтобы он мог работать с кривыми данными и выдавать приемлемый результат, т.е. чтобы уровень ущерба от ошибок был ниже полезности системы. В cloujure в сам подход закладывается, что она работает с неактуальными данными — ВСЕГДА. Т.е. результат ее работы приблизительный, но нам больше и не нужно. Что-то поменяется, ну и система автоматом поменяет…
Скажем так, аналогия здесь не проглядывается, но просто подход clojure и подход Павла дополняют друг друга.
Я не считаю (пока?) что и то (FRP) и другое (Костыли — это кошерно) — это правильно и надо именно этим пользоваться / так делать :)
И спасибо за доклад! (FRP'ом в мозг)
Дольше и менее весело, но не менее познавательно :) (или даже более).
Если я правильно уловил ключевую мысль FRP, это то, что «ВСЕ» что мы считаем индикаторами состояний меняется постоянно и параллельно. Также, как это происходило бы в реальном мире вокруг нас. Каждый индикатор представлен не своим «значением состояния на сейчас», а виде последовательности значений зафиксированных в каких-то моментах времени. Т.е. всегда, когда мы подсматриваем значение чего-то, это значение на момент начала подглядывания, а к концу подглядывания, значение уже может быть другим, но мы не узнаем если не начнем подглядывать снова (да нам и не надо...). Есть «микро-программки» — они же обсерверы — которые умеют наблюдать «прошлое» и инициировать перевод индикаторов из состояния в состояние посредством «чистой функции», которая не ничего не знает про индикаторы (это самая примитивная машина тьюринга «текущее значение индикатора»+«сивол»->«новое значени индикатора», у тьюринга был еще сайд-эффект — напечатать что-то, которого тут нет :)).
Так к чему я все это. В этой парадигме ничто не мешает делать циклические зависимости. Даже Excel это позволяет делать (через настройки надо только задать количество итераций и/или погрешность, когда можно прекратить считать, полагая, что все ячейки устаканились).
Если пойди дальше, и сформулировать отношения (зависимости) в виде дифференциальных уравнений, то мы еще ближе приближаемся к реальному миру. Визуализацию можно представить на этой картинке: audiomap.tuneglue.net/ (поискать любое слово — потом потыкать и подергать за кружочки — остальные тянутся сами балансируя как-то между собой). То же самое можно отнести и к индикаторам, которые «подтягиваются» к изменившимся значениям других индикаторов. И все это работает параллельно. Т.е. ни у кого нет возможности зафиксировать «все состояние» — оно меняется непрерывно и мы принимая решения опираемся всегда на устаревшие данные.
Боюсь сложно уследить за моим потоком сознания, тем не менее, а причем здесь Павел Кудинов?
Так вот он и говорит (то что я для себя услышал): вычислительные мощности растут и мы можем позволить себе писать программы «а бы как», не увлекаясь исправлением всех ошибок. Ошибки были, есть и будут всегда — это данность, которую надо принять. Гораздо важнее писать код так, чтобы он мог работать с кривыми данными и выдавать приемлемый результат, т.е. чтобы уровень ущерба от ошибок был ниже полезности системы. В cloujure в сам подход закладывается, что она работает с неактуальными данными — ВСЕГДА. Т.е. результат ее работы приблизительный, но нам больше и не нужно. Что-то поменяется, ну и система автоматом поменяет…
Скажем так, аналогия здесь не проглядывается, но просто подход clojure и подход Павла дополняют друг друга.
Я не считаю (пока?) что и то (FRP) и другое (Костыли — это кошерно) — это правильно и надо именно этим пользоваться / так делать :)
И спасибо за доклад! (FRP'ом в мозг)
0
Касаемо циклов — теоретически можно и проблем нет. Практически FRP-системы так не работают (точнее, их создатели не рекомендуют так их использовать). Надо поэкспериментировать. :)
Но в целом я прочитал комментарий и не понял, почему не надо пользоваться. Но окей, выводы каждый делает сам для себя. :)
Но в целом я прочитал комментарий и не понял, почему не надо пользоваться. Но окей, выводы каждый делает сам для себя. :)
0
Если кратко, то из всего сказанного не следует, что концепция FRP проще для работы большими системами.
В свое время все восторгались Prolog'ом, но и где же он?
Также обезумевали от XML'я (XML-RPC), но он занял свое ограниченное место.
Тем временим те самые «бородатые мужики», как писали на C, так и продолжают это делать ;-)
Clojure, больше подходит для программирования на вот таких штуках: ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%BE%D0%B3%D0%BE%D0%B2%D1%8B%D0%B9_%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80
В свое время все восторгались Prolog'ом, но и где же он?
Также обезумевали от XML'я (XML-RPC), но он занял свое ограниченное место.
Тем временим те самые «бородатые мужики», как писали на C, так и продолжают это делать ;-)
Clojure, больше подходит для программирования на вот таких штуках: ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%BE%D0%B3%D0%BE%D0%B2%D1%8B%D0%B9_%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80
0
UFO just landed and posted this here
Тру презентация же) Шутки/стиль не дают аудитории спать или тупить в инстаграм)
0
что не слово — то перл…
+1
Клоунада. С доклада бы вышел уже на обсасывании шутки про бекон.
-4
Спасибо за хорошее настроение с утра :-) бодрит не хуже чем чашка кофе.
+1
Что есть программирование?
Четкая логика решения любой задачи с использованием структур данных, алгоритмов, технологий и пр. Когда к этому добавляется творчество и юмор — получается шедевр. Но здесь… по-моему наоборот: к юмору слегка добавлена четкая логика. Может дело в том, что я не web-разработчик, но мне слушать доклад тяжело, трудно пробиться сквозь слой шуток и грубоватых слов до сути и смысла. Ощущение, что посмотрел ситком, а не техническую презентацию. Честно, не понимаю, что здесь народ цепляет?
Четкая логика решения любой задачи с использованием структур данных, алгоритмов, технологий и пр. Когда к этому добавляется творчество и юмор — получается шедевр. Но здесь… по-моему наоборот: к юмору слегка добавлена четкая логика. Может дело в том, что я не web-разработчик, но мне слушать доклад тяжело, трудно пробиться сквозь слой шуток и грубоватых слов до сути и смысла. Ощущение, что посмотрел ситком, а не техническую презентацию. Честно, не понимаю, что здесь народ цепляет?
+8
Посмотрел полную версию и задав несколько дополнительных вопросов кажется осознал концепцию FRP. И теперь возможно когда-нибудь получив какую-либо сложную задачу, которую нельзя будет очевидным образом решить «традиционными» (в том смысле теми, которые я знал до этого) средствами и методиками — возможно FRP сможет помочь. Как и с любыми другими концепциями.
Может быть доклад действительно не так хорош, но с другой стороны. Если бы он был «обычный» — он не появился бы здесь. И я так и не знал бы о FRP (хотя до этого видел несколько упоминаний, но не смотрел, ибо не было очевидно, стоит ли в этом разбираться).
Ну и что, лучше, чтобы на конференцию javascript-разработчиков вышел какой-нибудь Haskell'ист и начал толкать о том, как при помощи монад, теории категорий, стрелок Клейсли и прочего очень легко и без проблем фигачить UI? Рассказывая при этом уныло и используя половину ныне существующей математики.
Ну и… прикольно же, не?
Может быть доклад действительно не так хорош, но с другой стороны. Если бы он был «обычный» — он не появился бы здесь. И я так и не знал бы о FRP (хотя до этого видел несколько упоминаний, но не смотрел, ибо не было очевидно, стоит ли в этом разбираться).
Ну и что, лучше, чтобы на конференцию javascript-разработчиков вышел какой-нибудь Haskell'ист и начал толкать о том, как при помощи монад, теории категорий, стрелок Клейсли и прочего очень легко и без проблем фигачить UI? Рассказывая при этом уныло и используя половину ныне существующей математики.
Ну и… прикольно же, не?
+2
Да, эксцентричность порою привлекает немало внимания. Как способ привлечь внимание — вариант рабочий, но донести знания в такой форме сложно. Ведь не все после этого пойдут копать тему дальше.
0
Больше дела, меньше юмора — сюда: www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
0
Это, наверное, очень очень странно (раз, кол-во восторженных комментариев так сильно преобладает), но у меня прочитанный текст статьи и просмотренное видео вызвали сильнейший диссонанс.
+1
Весело, не спорю. Но у докладчика просто нехватка словарного запаса.
-2
Нужно было просто видеть, когда уставшая аудитория, готовая уже выйти в окно, начала дружно ржать над этим всем ;) Тогда большинство вопросов отпадет.
0
Only those users with full accounts are able to leave comments. Log in, please.
Замечательное выступление настоящего программиста