Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 133
Феерично :D
А есть какой-нибудь специальный хабрамем для банальнейшего комментария, набирающего кучу плюсов только потому, что оставлен первым? )
Просмотр этого доклада продлевает жизнь ))
PS. Полный список докладов с этой конференции frameworksdays.com/event/js-frameworks-day-2013/page/program
PS. Полный список докладов с этой конференции frameworksdays.com/event/js-frameworks-day-2013/page/program
НЛО прилетело и опубликовало эту надпись здесь.
Люблю такие формы докладов, не занудное читание с бумажки, а именно такая импровизация, и классный юмор.
Будьте проще и люди к вам потянутся :-)
Смешной, веселый парень.
«Шота я парю, вообще такое.» ©
«Шота я парю, вообще такое.» ©
Надо распарсить на цитаты его выступление.
хорошо бы увидеть примеры слайдов
Все вставляют в свои доклады женщин и котиков. Все. Уже лет пять. На этих котиков уже смотреть тошно.
Непонятно, почему все считают, что если не смогли интересно подать информацию — котик спасет.
Ох.
Непонятно, почему все считают, что если не смогли интересно подать информацию — котик спасет.
Ох.
Полная версия выступления:
www.youtube.com/watch?v=R4sTvHXkToQ
www.youtube.com/watch?v=R4sTvHXkToQ
Хорошее выступление. Отлично сбалансировано, что, к сожалению, не часто встречается на технических конференциях. Чаще выходит либо совсем-совсем по делу и вдаваясь в детали (аудитория засыпает) либо много шуток и совсем мало по делу (аудитория не понимает, что они тут забыли).
В топике, вообще-то, не очень смешная выжимка. Полный доклад лучше: www.youtube.com/watch?v=R4sTvHXkToQ
Крутой мужик, жму руку :)
Такое выступление, конечно, не утомит, но не факт, что аудитория запомнит главное, а не шутки.
Лично я через пять минут потерял суть доклада :)
Можно объяснить еще и тем, что этот доклад был последним и все уже порядком устали за весь день
Можно объяснить еще и тем, что этот доклад был последним и все уже порядком устали за весь день
Я был уверен, что большая часть аудитории не запомнит главное просто потому, что идея достаточно сложная и таки да, я был последним выступающим — я очень не хотел им быть, потому что был уверен, что будет всë плохо, но в результате таки довольно неплохо получилось, имхо.
Я в целом надеялся, что люди таки уловят суть. Если посмотреть полную версию, то (я очень надеюсь на это!) должно быть заметно, что я таки стараюсь объяснить, о чëм речь. Большая проблема темы в том, что никто о ней не рассказывает/не пишет понятными словами, все быстро скатываются на специфичную терминологию и считают само собой разумеющимся, что всем понятно, о чëм речь и зачем это.
Короче, мне кажется — тема тяжëлая, и понятно рассказать еë тяжело, и я старался, а вот получилось ли… :)
Я в целом надеялся, что люди таки уловят суть. Если посмотреть полную версию, то (я очень надеюсь на это!) должно быть заметно, что я таки стараюсь объяснить, о чëм речь. Большая проблема темы в том, что никто о ней не рассказывает/не пишет понятными словами, все быстро скатываются на специфичную терминологию и считают само собой разумеющимся, что всем понятно, о чëм речь и зачем это.
Короче, мне кажется — тема тяжëлая, и понятно рассказать еë тяжело, и я старался, а вот получилось ли… :)
Чëрт, почему на хабре нельзя редактировать комментарии? Я не всегда так косноязычен, если что, только когда поспешу. :))
В целом, про ячейки таблицы понятно, буду пробовать, тем более все лучше понимается на практике. Сам сейчас копаюсь в событиях и хотелось бы как то упростить вещи, потому что понимаю, что упростить как то можно, но опыта для того чтобы понять как — нет.
Напишите адрес своего блога. Мне бы пофанатить.
Мне кажется, что MVC и Angulare очень близко перекликаются с тем, что состояние приложения нужно обрабатывать переменными, а не событиями.
Я не люблю AngularJS за внутренний дизайн, за апи и за доки. Ну и несмотря на data-binding, это таки не FRP, хотя в первом приближении на практике не очень отличается.
MVC — это вообще о другом, реально. И Angular не MVC, и FRP в эту модель тяжело будет впихнуть. Не уверен, что классический MVC — это то, что точно необходимо, впрочем.
MVC — это вообще о другом, реально. И Angular не MVC, и FRP в эту модель тяжело будет впихнуть. Не уверен, что классический MVC — это то, что точно необходимо, впрочем.
Насколько проблема непонятности докладов специфична для области ИТ? Насколько это вообще проблема? Ну, то есть, поверхностно я понимаю идею — если мы будем просто и понятно рассказывать о разных штуках, скорость обмена информацей и развития технологического стека, может быть, увеличатся. Но по размышлении все становится не так однозначно.
Очевидно (мне, но я могу ошибаться), что большая часть технологий, используемых сейчас в индустрии — сложные, и чем глубже ты куда-то закапываешься и чем подробнее начинаешь чем-то заниматься, тем сложнее становится. Очевидно, что освоение каждой технологии занимает слишком много времени и сил, чтобы это можно было считать подходящим способом ознакомления с веяниями нашего ИТ-мира. Отрадно, что несколько тысяч лет назад человек научился использовать метафоры, чтобы доступно объяснять сложные вещи. Но.
Метафора и упрощение работают за счет того, что новую и непонятную для себя ситуацию мы проецируем на знакомую и понятную модель. В том редком случае, когда метафора и исходная модель совпадают, все отлично. Когда же метафора расходится с реальной ситуацией, возникает много проблем, и самое главное, это неявные проблемы для человека, который пытается эту метафору освоить. У меня сейчас не получается внятно сформулировать свою мысль, но суть в том, что когда мы рассказываем про квадрат и говорим «ребят, квадрат — сложная штука, но для простоты давайте представим, что это круг», мы оказываемся в тупике. Часть людей говорит «эй, у меня уже есть мой привычный круг, я давно им пользуюсь, зачем мне какой-то там квадрат?». Другая часть говорит «блин, там какие-то стремные углы, нафига вообще это надо?». Третья часть пишет на форумах «услышали клёвый доклад про квадраты, попытались заюзать в продакшне и, короче, когда рассчитывали площадь по формуле Pi*R^2, все упало. Стали отлаживать — а там вместо радиуса отстой какой-то. Квадраты говно.» И мы оказываемся на исходной — либо рассказывай про детали (и получай сложный доклад), либо рассказывай доступно и оставляй глобальный информационный вакуум вокруг своей темы, но тогда возникает вопрос, а чего изначально мы пытаемся добиться, когда читаем доклады.
Ну, то есть, я к чему вообще всё это словоблудие — есть ли иной путь, кроме как использовать специфичную терминологию и рассказывать тяжело?
Очевидно (мне, но я могу ошибаться), что большая часть технологий, используемых сейчас в индустрии — сложные, и чем глубже ты куда-то закапываешься и чем подробнее начинаешь чем-то заниматься, тем сложнее становится. Очевидно, что освоение каждой технологии занимает слишком много времени и сил, чтобы это можно было считать подходящим способом ознакомления с веяниями нашего ИТ-мира. Отрадно, что несколько тысяч лет назад человек научился использовать метафоры, чтобы доступно объяснять сложные вещи. Но.
Метафора и упрощение работают за счет того, что новую и непонятную для себя ситуацию мы проецируем на знакомую и понятную модель. В том редком случае, когда метафора и исходная модель совпадают, все отлично. Когда же метафора расходится с реальной ситуацией, возникает много проблем, и самое главное, это неявные проблемы для человека, который пытается эту метафору освоить. У меня сейчас не получается внятно сформулировать свою мысль, но суть в том, что когда мы рассказываем про квадрат и говорим «ребят, квадрат — сложная штука, но для простоты давайте представим, что это круг», мы оказываемся в тупике. Часть людей говорит «эй, у меня уже есть мой привычный круг, я давно им пользуюсь, зачем мне какой-то там квадрат?». Другая часть говорит «блин, там какие-то стремные углы, нафига вообще это надо?». Третья часть пишет на форумах «услышали клёвый доклад про квадраты, попытались заюзать в продакшне и, короче, когда рассчитывали площадь по формуле Pi*R^2, все упало. Стали отлаживать — а там вместо радиуса отстой какой-то. Квадраты говно.» И мы оказываемся на исходной — либо рассказывай про детали (и получай сложный доклад), либо рассказывай доступно и оставляй глобальный информационный вакуум вокруг своей темы, но тогда возникает вопрос, а чего изначально мы пытаемся добиться, когда читаем доклады.
Ну, то есть, я к чему вообще всё это словоблудие — есть ли иной путь, кроме как использовать специфичную терминологию и рассказывать тяжело?
Есть две стороны проблемы. Если рассказывать что-то заранее заинтересованному человеку, то можно (попытаться?) устроить полное погружение, рассказывать тяжело и подробно.
Но в моëм случае задача была не столько полностью рассказать о всех тонкостях, сколько заинтересовать слушателей. Очевидно, что тогда рассказ нужен такой, чтоб человек, который не видит особенного смысла в том, о чëм я рассказываю (а такими были фактически все), заинтересовался.
Мне хотелось, чтоб смысл не потерялся, но я не мог себе позволить говорить чëткие и технически верные определения — я до этого доклада (до не в смысле «за ночь до») сам пытался въехать в FRP и хорошо себе в тот момент представлял то, насколько тяжело уловить его полезность за всеми этими технически верными определениями.
Но в моëм случае задача была не столько полностью рассказать о всех тонкостях, сколько заинтересовать слушателей. Очевидно, что тогда рассказ нужен такой, чтоб человек, который не видит особенного смысла в том, о чëм я рассказываю (а такими были фактически все), заинтересовался.
Мне хотелось, чтоб смысл не потерялся, но я не мог себе позволить говорить чëткие и технически верные определения — я до этого доклада (до не в смысле «за ночь до») сам пытался въехать в FRP и хорошо себе в тот момент представлял то, насколько тяжело уловить его полезность за всеми этими технически верными определениями.
Вы в конце прошлись по эрлангу — вы нигде не расписывали свою точку зрения более подробно? Хотелось бы почитать не восторженный отзыв на него. Сам я эрлангом не занимался, но многократно слышал, что scala многое взяла из него.
Скала? Из Эрланга? Та ну, никакой связи, кроме Akka, которая сторонняя библиотека (еë взяли внутрь уже, но всë же).
На тему самого Эрланга — не очень подробно, но всë же: www.facebook.com/kachayev/posts/492248150824885
На тему самого Эрланга — не очень подробно, но всë же: www.facebook.com/kachayev/posts/492248150824885
Та ну, никакой связи, кроме Akka, которая сторонняя библиотека (еë взяли внутрь уже, но всë же).
У вас несколько не верные сведения. Акторы изначально часть стандартной библиотеки. Или по крайней мере давно, но версию не найду сходу.
Сейчас они deprecated и вместо них рекомендуется использовать akka, но они все еще в стандартной библиотеке.
Жаль, по ссылке срыва покровов нет. Но все равно спасибо!
PS Забавно, в стандартной библиотеке scala тоже нет дат.
Хм, окей, как-то я это пропустил. Буду знать, спасибо.
Забыл написать в прошлом комментарии: раньше (уж не знаю как сейчас) на всех презентациях по scala, на которых упоминались акторы, тут же упоминали эрланг как их первоисточник. Потому я и сказал про заимствования.
Ага, прикол. Ну, я про скалу читал и чуть разбирался, но презентации не смотрел и этот момент умудрился пропустить абсолютно. Сейчас глянул — даже в википедии есть Influenced by Erlang, глаз замылен.
Да, срыва покровов нет, у меня нелюбовь к Ерлангу больше от того, что его парят как светлое будущее, а он не только не лучше альтернатив, а зачастую заметно хуже. И софт-прорыв-в-мейнстрим, написанный на нëм — Ejabberd — внутри довольно-таки страшен после всех лет развития. Prosody на мой вкус ровнее, а написан на совершенно непримечательной Lua.
Да, срыва покровов нет, у меня нелюбовь к Ерлангу больше от того, что его парят как светлое будущее, а он не только не лучше альтернатив, а зачастую заметно хуже. И софт-прорыв-в-мейнстрим, написанный на нëм — Ejabberd — внутри довольно-таки страшен после всех лет развития. Prosody на мой вкус ровнее, а написан на совершенно непримечательной Lua.
По всему, что я читал о Erlang, он мне тоже не нравится (в основном динамической типизацией и синтаксической бедностью).
Но для меня его преимущество именно в этом «Influenced». И тут не только scala, но и Rust.
Кстати, по поводу FRP и scala: Deprecating the Observer Pattern. Правда все реализации (например 1, 2) как-то застопорились в развитии.
Но для меня его преимущество именно в этом «Influenced». И тут не только scala, но и Rust.
Кстати, по поводу FRP и scala: Deprecating the Observer Pattern. Правда все реализации (например 1, 2) как-то застопорились в развитии.
Жаль, что меня не было на этой презентации. К сожалению вам задавали много вопросов не по теме: про Кложу, про Джаваскрипт, про Эрленг, какую-то корпоративную муть даже спрашивали. Хотя на тему самого FRP тут есть много интересных проблем.
Например, хотелось бы услышать вашу точку зрения по поводу проблемы больших графов связей с узлами повторяющихся типов. Самый простой пример такого случая — древовидный, иерархия комментариев, как в Хабре. Непонятно, как в общем случае прибиндить данные к комментариям, не обновляя всю структуру DOM каждый раз при редактировании комментария, и без нереактивных хаков.
К слову, раскритикованный вами elm таки решает эту проблему. Правда создает при этом другие.
В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
Например, хотелось бы услышать вашу точку зрения по поводу проблемы больших графов связей с узлами повторяющихся типов. Самый простой пример такого случая — древовидный, иерархия комментариев, как в Хабре. Непонятно, как в общем случае прибиндить данные к комментариям, не обновляя всю структуру DOM каждый раз при редактировании комментария, и без нереактивных хаков.
К слову, раскритикованный вами elm таки решает эту проблему. Правда создает при этом другие.
В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
> Непонятно, как в общем случае прибиндить данные к комментариям, не обновляя всю структуру DOM каждый раз при редактировании комментария, и без нереактивных хаков.
Да, это очень тяжëлый вопрос и у меня (как в целом и у всех, вроде бы — я пытаюсь следить, что там люди выдумывают) нет ответа. Мне кажется, что можно забить на правильность и внутри реализации списка схачить и завязать его жестко на DOM.
> К слову, раскритикованные вами elm таки решает эту проблему. Правда создает при этом другие.
btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает. Но всë равно он недохаскель и это немножечко страшно (и то, что хаскель, и то, что недо), и всë равно дока говно, примеры говно (впрочем, я 2 месяца назад последний раз смотрел, но лень уже)…
> В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
Для прототипа/концепта сгодится перерисовывание, для рабочих вещей — инкапсуляция работы с домом внутри итерации. Вот как в фейсбуковом React'e, снаружи всë ровно, а внутри хитрые пляски с домом.
Да, это очень тяжëлый вопрос и у меня (как в целом и у всех, вроде бы — я пытаюсь следить, что там люди выдумывают) нет ответа. Мне кажется, что можно забить на правильность и внутри реализации списка схачить и завязать его жестко на DOM.
> К слову, раскритикованные вами elm таки решает эту проблему. Правда создает при этом другие.
btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает. Но всë равно он недохаскель и это немножечко страшно (и то, что хаскель, и то, что недо), и всë равно дока говно, примеры говно (впрочем, я 2 месяца назад последний раз смотрел, но лень уже)…
> В общем, хотелось бы услышать вашу точку зрения как вы видите решение проблемы в нечистых функциональынх языках, таких как та же Кложа.
Для прототипа/концепта сгодится перерисовывание, для рабочих вещей — инкапсуляция работы с домом внутри итерации. Вот как в фейсбуковом React'e, снаружи всë ровно, а внутри хитрые пляски с домом.
Благодарю вас за ответ.
На мой взгляд, проблема реактивного программирования кроется в том, что система таких вот реактивных связей по большому счету образует не более, чем конечный автомат. Ну, можно сказать, что конечный автомат с параметрами, но в любом случае, мы не можем решать тьюринг-полные задачи таким путем.
Я думаю, что идея не выстрелит в конечном итоге. Хотя большую движуху ожидать стоит.
Более правильным решением было бы что-то между событийно-ориентированным подходом, когда мы явно контролируем все процессы, и реактивным, когда мы вообще ничего не контролируем. Нечто вроде системы сигнал-слот, чтобы можно было соединять слоты пайпами, ставить разные там фильтры(в том числе и фильтры с состоянием). Такая система с одной стороны остается более-менее декларативной и наглядной, как и реактивная, с другой — дает больше свободы действия. Если мы хотим сделать что-то более сложное, чем валидацию формочек, нам не придется хакать, делать что-то сильно неправильно.
Мне кажется elm по большому счету нечто такое нам и предлагает, только там эти «фильтры» хитро запрятаны в ленивые вычисления. Это неплохо, но я боюсь, что для широкого круга программистов освоить «хаскелль» будет слишком сложной задачей. Уже не говоря о том, что из-за принципиального отсутствия сторонних эффектов его будет сложно подружить со всем остальным миром API и библиотек.
> btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает
Я уже несколько месяцев не слежу за проектом. Надо будет посмотреть, что там сделали за это время.
На мой взгляд, проблема реактивного программирования кроется в том, что система таких вот реактивных связей по большому счету образует не более, чем конечный автомат. Ну, можно сказать, что конечный автомат с параметрами, но в любом случае, мы не можем решать тьюринг-полные задачи таким путем.
Я думаю, что идея не выстрелит в конечном итоге. Хотя большую движуху ожидать стоит.
Более правильным решением было бы что-то между событийно-ориентированным подходом, когда мы явно контролируем все процессы, и реактивным, когда мы вообще ничего не контролируем. Нечто вроде системы сигнал-слот, чтобы можно было соединять слоты пайпами, ставить разные там фильтры(в том числе и фильтры с состоянием). Такая система с одной стороны остается более-менее декларативной и наглядной, как и реактивная, с другой — дает больше свободы действия. Если мы хотим сделать что-то более сложное, чем валидацию формочек, нам не придется хакать, делать что-то сильно неправильно.
Мне кажется elm по большому счету нечто такое нам и предлагает, только там эти «фильтры» хитро запрятаны в ленивые вычисления. Это неплохо, но я боюсь, что для широкого круга программистов освоить «хаскелль» будет слишком сложной задачей. Уже не говоря о том, что из-за принципиального отсутствия сторонних эффектов его будет сложно подружить со всем остальным миром API и библиотек.
> btw, он серьëзно обновился месяц-два назад и теперь чуть прямее работает
Я уже несколько месяцев не слежу за проектом. Надо будет посмотреть, что там сделали за это время.
> Такая система с одной стороны остается более-менее декларативной и наглядной, как и реактивная, с другой — дает больше свободы действия.
Это да, без некоторого состояния в паре мест ну просто очень тяжело будет. Если что, я не за то, чтоб всë сделать идеально, pure shit, иначе я был бы фанатом Хаскеля. А так как мне нравятся более простые и близкие к жизни решения, то я не против того, что надо сделать рабочую систему. Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
> Если мы хотим сделать что-то более сложное, чем валидацию формочек
Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире. :)
На Эльм еще посмотрим. Но освоить его очевидно тяжело, может позже, когда раздуплятся на внятный туториал, а не «введите эти 3 строки вот в это место; смотрите — мячик прыгает; введите еще 2 строки — и он прыгает иначе!»
Это да, без некоторого состояния в паре мест ну просто очень тяжело будет. Если что, я не за то, чтоб всë сделать идеально, pure shit, иначе я был бы фанатом Хаскеля. А так как мне нравятся более простые и близкие к жизни решения, то я не против того, что надо сделать рабочую систему. Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
> Если мы хотим сделать что-то более сложное, чем валидацию формочек
Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире. :)
На Эльм еще посмотрим. Но освоить его очевидно тяжело, может позже, когда раздуплятся на внятный туториал, а не «введите эти 3 строки вот в это место; смотрите — мячик прыгает; введите еще 2 строки — и он прыгает иначе!»
> А так как мне нравятся более простые и близкие к жизни решения, то я не против того, что надо сделать рабочую систему.
Солидарен. Фанатов Хаскеля, кстати, тоже интересно троллить, особенно новообращенных. В этом языке далеко не все вещи такие уж чистые от сторонних эффектов, но новичики это не всегда замечают.
> Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
Я тоже этим целыми днями занимаюсь. Работу эту не люблю, разумеется, но кушать каждый день хочется. Мне все-таки кажется, причина этого содома не в JS, а в людях. Ну даже во время вашего доклада было видно, что уровень аудитории довольно не высокий. И это, к сожалению, норма.
> Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире.
Особенно если посмотреть на то, что нам предлагает Angular, задача становится вдвойне сложнее. :)
Недавно пришлось поработать с этим фреймвокром вплотную. Осталось впечатление, что API делали фанаты Java/C#. Какие-то повсюду совершенно ненужные нагромождения. При этом отсутствует очевидно необходимые вещи, такие, скажем, как полноценные модули. И подружить Энгьюлар с чем-либо сложно, повсюду швы.
Солидарен. Фанатов Хаскеля, кстати, тоже интересно троллить, особенно новообращенных. В этом языке далеко не все вещи такие уж чистые от сторонних эффектов, но новичики это не всегда замечают.
> Просто то, что сейчас происходит в написании приложений на жс — это содом и гоморра, и надо чота решать.
Я тоже этим целыми днями занимаюсь. Работу эту не люблю, разумеется, но кушать каждый день хочется. Мне все-таки кажется, причина этого содома не в JS, а в людях. Ну даже во время вашего доклада было видно, что уровень аудитории довольно не высокий. И это, к сожалению, норма.
> Я бы так словами не разбрасывался, валидация формочек это в целом показательная задача, там довольно много состояний и это не самая простая вещь в мире.
Особенно если посмотреть на то, что нам предлагает Angular, задача становится вдвойне сложнее. :)
Недавно пришлось поработать с этим фреймвокром вплотную. Осталось впечатление, что API делали фанаты Java/C#. Какие-то повсюду совершенно ненужные нагромождения. При этом отсутствует очевидно необходимые вещи, такие, скажем, как полноценные модули. И подружить Энгьюлар с чем-либо сложно, повсюду швы.
> Мне все-таки кажется, причина этого содома не в JS, а в людях. Ну даже во время вашего доклада было видно, что уровень аудитории довольно не высокий.
Надо сказать, что это была самая классная аудитория этого доклада (я его в общей сложности 5 раз рассказывал). Но на тему «не в жс, а в людях» — я пытался обсуждать проблему с людьми, которые пишут традиционные ГУИ — они ж там должны были всë порешать давно, да? Та же жопа, те же ивенты, такая же лапша.
Я вот в новый проект взял фейсбуковый React и пока доволен, он в целом как компромисс между практичностью и разумностью вроде бы ничего, но еще рано что-то утверждать, 3 недели пока код пишем только. :)
Про angular хочется молчать.
Надо сказать, что это была самая классная аудитория этого доклада (я его в общей сложности 5 раз рассказывал). Но на тему «не в жс, а в людях» — я пытался обсуждать проблему с людьми, которые пишут традиционные ГУИ — они ж там должны были всë порешать давно, да? Та же жопа, те же ивенты, такая же лапша.
Я вот в новый проект взял фейсбуковый React и пока доволен, он в целом как компромисс между практичностью и разумностью вроде бы ничего, но еще рано что-то утверждать, 3 недели пока код пишем только. :)
Про angular хочется молчать.
Хм… не ожидал, что у Фейсбука может быть что-то стоящее :) Ладно, я тогда тоже присмотрюсь к этому фреймворку повнимательнее. Спасибо.
Надо свыкнуться с мыслью, конечно, что это не unobtrusive JS, а прямая противоположность — хтмл внутри жс, но потом всë идëт хорошо. Более того, мне кажется, что unobtrusive JS в случае с полноценными внутрибраузерыми приложениями не работает, и то, что делает реакт — правильно (хотя хоплон делает еще правильнее, имхо — делит на внутреннее апи и внешний интерфейс).
Нет уж, общественность желает знать про angularjs :)
Что там не так?
Что там не так?
Пиранья рулит :)
Кложе, в частности кложаскрипте, щас очень популярны заигрывания с core.async. И не просто так, вся та размытость кода сильно уменьшается. А есть еще очень забавный pedastral.io, там стейт эксплицитней некуда.
Вообще, количество движухи в кложа-мире очень радует, я про javelin и не слышал даже.
Спасибо за доклад :)
Кложе, в частности кложаскрипте, щас очень популярны заигрывания с core.async. И не просто так, вся та размытость кода сильно уменьшается. А есть еще очень забавный pedastral.io, там стейт эксплицитней некуда.
Вообще, количество движухи в кложа-мире очень радует, я про javelin и не слышал даже.
Спасибо за доклад :)
Да, я вот на clojurecup планирую попробовать интерфейс на core.async построить и посмотреть, как оно. А вот пьедесталом я что-то пока совсем не проникся, может тоже попробовать надо, но вот читал туториал — и сложилось впечатление, что слишком много слов.
На тему джавелина еще надо упомянуть хоплон (который в марте еще хлиспом назывался) — github.com/tailrecursion/hoplon
И вообще, спасибо за отзыв! :)
На тему джавелина еще надо упомянуть хоплон (который в марте еще хлиспом назывался) — github.com/tailrecursion/hoplon
И вообще, спасибо за отзыв! :)
Хотел бы прояснить, правильно ли я понял что такое FRP. У себя в проекте мы сделали модель, похожую на сигнал-слотовую модель в QT, только на javascript. Сойдет ли это за FRP?
А вообще вы молодец. Я вот человек который долек от программирования (скрипты я не считаю) и который давно мечтает начать, очень захотелось начать теперь не с python, а с lisp :)
Но надеюсь, через неделю остыну и все же достану давно купленную книгу по python.
Но надеюсь, через неделю остыну и все же достану давно купленную книгу по python.
Добрый время суток! Алексей, я смотрел ваш доклад в полной версии, веселый и познавательный спасибо!
в конце доклада были ссылки, можно их скинуть?
в конце доклада были ссылки, можно их скинуть?
«хотел бы я тоже уметь вот так думать — мозгом!»
Всегда уважал людей, способных объяснить любые вещи просто и понятно. А то бубнят на этих конференциях под нос с бумажки что-то типа «конвергенция эффективности буферизации кластеризированного энвайромента» — и ты просто выпадаешь в осадок от этой лапши на ушах.
Всегда уважал людей, способных объяснить любые вещи просто и понятно. А то бубнят на этих конференциях под нос с бумажки что-то типа «конвергенция эффективности буферизации кластеризированного энвайромента» — и ты просто выпадаешь в осадок от этой лапши на ушах.
Верка Сердючка нервно курит в сторонке :)))
чувак — огонь.
У Scotta Hanselmana из Microsoft тоже веселые доклады.
Представил, как я про свою CMS «ДвижОк» рассказываю… думаю, получилось бы примерно также ((
Полностью согласен про Бекон (-:
Библиотека названа в честь философа Фрэнсиса Бэкона.
А, вот оно что.
Как-то не очевидны ни этот факт, ни связь между Френсисом Бэконом и FRP.
Как-то не очевидны ни этот факт, ни связь между Френсисом Бэконом и FRP.
Этот факт очевиден из лого на их главной странице на GitHub, а также из этого обсуждения. По поводу связи FRP и Ф.Бэкона я согласен с вами. Но, согласитесь, для FRP непросто придумать осмысленную, краткую, запоминающуюся метафору.
Frappe? Behave.js?
Френсис Бэкон выглядит как afterthought, а не как изначальная идея.
Френсис Бэкон выглядит как afterthought, а не как изначальная идея.
Возможно. К примеру, изначально это вообще мог быть акроним. Но теперь налицо четкая связь с философом.
Обратите внимание, к примеру, на этот порт Bacon.js — Francis.
Кстати, мне ваши метафоры почти ни о чем не сказали (а ведь это главная цель метафоры).
Обратите внимание, к примеру, на этот порт Bacon.js — Francis.
Кстати, мне ваши метафоры почти ни о чем не сказали (а ведь это главная цель метафоры).
Да, я посмотрел уже, что это FRP-библиотеки. И это лишний раз доказывает, что изначально идеальных метафор не бывает. Вам они кажутся подходящими потому, что вы их уже видели в этом контексте. Я ими не пользовался, поэтому ассоциации у меня возникают совсем другие.
Не понял претензий. FRaPpe — откровенный намëк на FRP, да? Behave — намëк на Behavior'ы, центральную концепцию FRP. Я даже не знал, что такие библиотеки существуют.
Зато Френсис Бэкон — это, конечно, сразу в голове ассоциируется с хорошей архитектурой интерфейсов.
Зато Френсис Бэкон — это, конечно, сразу в голове ассоциируется с хорошей архитектурой интерфейсов.
Не удивительно, что вы не поняли претензий. Их нет у меня. Единственно, что я хотел сделать — это попытаться снять неоднозначность в понимании bacon.js как «бекона». C FRP я встретился первый раз в лице bacon.js, знатоком его себя не считаю, в работе не использую.
Но с университетской скамьи я знаю, что Фрэнсис Бэкон — это один из основоположников эмпиризма. А здесь уже прослеживается связь между «поведением» и «наблюдением» этого поведения. Может быть, я не понимаю FRP на столько, чтобы понять, что эта моя ассоциация лишена основания. Это я допускаю.
Но с университетской скамьи я знаю, что Фрэнсис Бэкон — это один из основоположников эмпиризма. А здесь уже прослеживается связь между «поведением» и «наблюдением» этого поведения. Может быть, я не понимаю FRP на столько, чтобы понять, что эта моя ассоциация лишена основания. Это я допускаю.
В комментах на ютубе предположили, что это шутка про игру слов между bacon/beacon, тогда не так всë и безобразно, конечно. :)
В Readme проекта на гитхабе есть еще одно объяснение названия, дающее хорошее семантическое правило (бекон противопоставляется лапше):
Turns your event spaghetti into clean and declarative feng shui bacon
Да, слушал в живую ) Очень и очень.
«В лиспе все списки..»))
Шикарный доклад, запутать правда пытались частенько, но очень интересно слушать из-за «живости».
Шикарный доклад, запутать правда пытались частенько, но очень интересно слушать из-за «живости».
Очень крутой доклад, спасибо, как раз о наболевшем говорили.
А можно услышать мнение, почему нокаут — это плохо? Сам сейчас его использую в связке с самописным кодом и пока доволен, но всё равно немного не то. А какие у тебя нарекания к нему?
А можно услышать мнение, почему нокаут — это плохо? Сам сейчас его использую в связке с самописным кодом и пока доволен, но всё равно немного не то. А какие у тебя нарекания к нему?
«Я бы тоже хотел бы думать мозгом...»
Спасибо за мега-позитив!
Спасибо за мега-позитив!
piranha, куда пропал из emacs@c.j.r? :)
Давно фоловлю Александра в Твиттере, но живая речь — это что-то :)
Я понимаю, что статья про юморной способ подачи, но все же я скажу про тему доклада — мне кажется, или он рассказывает про что-то, нереально похожее на Qt Quick, а именно property binding? :) Там это есть и давно, и никаких громких красивых слов и абстракций не нужно было, чтобы мы начали это использовать!
Если Qt Quick это только property binding, то не совсем, это часть, хоть и важная (важная для юзабельности, для концепции это как раз мелочь и не основное). Я рассказываю про то, что в .NET называется Reactive Extensions (Rx.NET), про ReactiveCocoa, про Flapjax/Bacon.js, про Rx.Java, больше не знаю сходу названий. Trellis в питоне еще есть, но он мог бы быть и попрямее (у меня не получилось его использовать нормально :\).
Пересматриваю уже раз 10й :). Позитивчик так и прет.
Какой крутой чувак ^_^
Пропиарил ClojureScript пополной.
«Ну, я не аналитик… совсем не аналитик, я программист — чихчихчих, и в продакшен»
А вообще, выступление порадовало, посмотрел на одном дыхании.
А вообще, выступление порадовало, посмотрел на одном дыхании.
Если порядок нам важен, надо сделать так, чтоб второе обновление не пришло раньше первого (или как там нужно). Короче, рассчитывать на разные данные — фича в том, что у нас всегда есть какие-то данные, мы работаем со всегда существующими данными.
Т.е. прикол не в том, что с событиями так нельзя писать, прикол в том, что это тяжело делать и в эту сторону никто не направляет.
Т.е. прикол не в том, что с событиями так нельзя писать, прикол в том, что это тяжело делать и в эту сторону никто не направляет.
Про весь 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) :)
a->b->c->a — противоречит идее. Про closure не понял. Речь о замыкании или о чëм?
Воодушевленный просмотром твоего доклада посмотрел еще про 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'ом в мозг)
Касаемо циклов — теоретически можно и проблем нет. Практически FRP-системы так не работают (точнее, их создатели не рекомендуют так их использовать). Надо поэкспериментировать. :)
Но в целом я прочитал комментарий и не понял, почему не надо пользоваться. Но окей, выводы каждый делает сам для себя. :)
Но в целом я прочитал комментарий и не понял, почему не надо пользоваться. Но окей, выводы каждый делает сам для себя. :)
Если кратко, то из всего сказанного не следует, что концепция 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
Тру презентация же) Шутки/стиль не дают аудитории спать или тупить в инстаграм)
что не слово — то перл…
Клоунада. С доклада бы вышел уже на обсасывании шутки про бекон.
Спасибо за хорошее настроение с утра :-) бодрит не хуже чем чашка кофе.
Что есть программирование?
Четкая логика решения любой задачи с использованием структур данных, алгоритмов, технологий и пр. Когда к этому добавляется творчество и юмор — получается шедевр. Но здесь… по-моему наоборот: к юмору слегка добавлена четкая логика. Может дело в том, что я не web-разработчик, но мне слушать доклад тяжело, трудно пробиться сквозь слой шуток и грубоватых слов до сути и смысла. Ощущение, что посмотрел ситком, а не техническую презентацию. Честно, не понимаю, что здесь народ цепляет?
Четкая логика решения любой задачи с использованием структур данных, алгоритмов, технологий и пр. Когда к этому добавляется творчество и юмор — получается шедевр. Но здесь… по-моему наоборот: к юмору слегка добавлена четкая логика. Может дело в том, что я не web-разработчик, но мне слушать доклад тяжело, трудно пробиться сквозь слой шуток и грубоватых слов до сути и смысла. Ощущение, что посмотрел ситком, а не техническую презентацию. Честно, не понимаю, что здесь народ цепляет?
Посмотрел полную версию и задав несколько дополнительных вопросов кажется осознал концепцию FRP. И теперь возможно когда-нибудь получив какую-либо сложную задачу, которую нельзя будет очевидным образом решить «традиционными» (в том смысле теми, которые я знал до этого) средствами и методиками — возможно FRP сможет помочь. Как и с любыми другими концепциями.
Может быть доклад действительно не так хорош, но с другой стороны. Если бы он был «обычный» — он не появился бы здесь. И я так и не знал бы о FRP (хотя до этого видел несколько упоминаний, но не смотрел, ибо не было очевидно, стоит ли в этом разбираться).
Ну и что, лучше, чтобы на конференцию javascript-разработчиков вышел какой-нибудь Haskell'ист и начал толкать о том, как при помощи монад, теории категорий, стрелок Клейсли и прочего очень легко и без проблем фигачить UI? Рассказывая при этом уныло и используя половину ныне существующей математики.
Ну и… прикольно же, не?
Может быть доклад действительно не так хорош, но с другой стороны. Если бы он был «обычный» — он не появился бы здесь. И я так и не знал бы о FRP (хотя до этого видел несколько упоминаний, но не смотрел, ибо не было очевидно, стоит ли в этом разбираться).
Ну и что, лучше, чтобы на конференцию javascript-разработчиков вышел какой-нибудь Haskell'ист и начал толкать о том, как при помощи монад, теории категорий, стрелок Клейсли и прочего очень легко и без проблем фигачить UI? Рассказывая при этом уныло и используя половину ныне существующей математики.
Ну и… прикольно же, не?
Больше дела, меньше юмора — сюда: www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
Это, наверное, очень очень странно (раз, кол-во восторженных комментариев так сильно преобладает), но у меня прочитанный текст статьи и просмотренное видео вызвали сильнейший диссонанс.
Весело, не спорю. Но у докладчика просто нехватка словарного запаса.
Нужно было просто видеть, когда уставшая аудитория, готовая уже выйти в окно, начала дружно ржать над этим всем ;) Тогда большинство вопросов отпадет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Замечательное выступление настоящего программиста