Я скорее имел ввиду haskell, scala, akka/akka-streams (кстати есть порт на scala.js), spark и rx.
Суть в понимании какие плюсы даёт ФП и ФРП: понимание что такое монада (в первом приближении) и зачем они нужны; понимание как разложить любой SQL запрос на map/flatMap (bind)/filter/fold; понимание какую выгоду можно поиметь от генераторов в js помимо бесконечных списков; понимание чем являются генераторы js и чем будут являться async/await; понимание Promise, не в том смысле как пользоваться, а на чём он основан.
P.S. В целом конечно можно представлять ФРП и ФП как магию и при этом пытаться мыслить в категориях потоков данных, но ИМХО это проблематично.
>> Впрочем, задать свой id, как и любой другой атрибут возможность есть. Но лучше ею не пользоваться.
Никогда не надейтесь на условные соглашения, тем более в enterprise, где любой случайный не очень опытный юниор может таким образом создать вам баг на 10+ человеко-часов
>> Правда я не видел ещё ни одного человека, который бы фокусировал поле ввода кликом по подписи к нему
Я тут. И я считаю, что для людей которые не ставят label к элементам формы есть отдельный котёл в аду. Особенно когда речь заходит о чекбоксах. Особенно с мобильных устройств.
>> Второй ориентирован на веб-страницы, а не веб-приложения.
Вам следует сначала посмотреть какой-нибудь функциональный язык (желательно многопоточный), тогда прибавится понимания зачем вам это вообще и действительно ли оно вам надо.
Из близкого по теме рекомендую посмотреть: Binding.scala для понимания тру-реактивности (требует наличия свежей jdk и scala + sbt), elm для понимания ФП и Rx%LANGNAME% для понимания реактивных потоков (советую язык со строгой типизацией)
Идея конечно хороша. Может даже удалось бы уделать ныне покойный extJS, но количество спецсимволов на строку кода просто поражает, даже заядлого скала-кодера… И в целом общий уровень читаемости оставляет желать лучшего, как и уровень знания английского.
Про трамплины познавательно, даже не думал что можно столь универсально оптимизировать хвостовую рекурсию.
**off-topic:** чего только эти императивщики не придумают вместо `@tailrec`. (знаю, что в scala/haskell/kotlin используются подобный метод, просто шутки ради)
*Почти offtop:* для любителей подобных соревнований есть ещё 1k Intro (http://archive.assembly.org/2016/1k-intro), но там несколько хардкорней — ассемблер, бутсектор, крутые демо.
Я видел достаточно не «начинающих» разработчиков, которые на полном серьёзе считают, что хранить в базе сериализованые нативными средствами классы (да, именно классы, а не мапы) — хорошая идея, ещё и через `LIKE` умудряются по ним искать, да и в целом к БД почти у всех разработчиков достаточно наплевательское отношение. Есть ещё особая секта разработчиков — «мастера оптимизации», которые экономят на «скорости обработки типов строк» (т.е. давний холивар на тему `"` vs `'`) при этом используя тяжеловесные ORM, записывая в одну и ту же переменную разные типы, проходя один и тот же массив по 20 раз в разных местах ничего не меняя в промежутках и т.д.
Так что я действительно считаю, что это достойная статья (хоть может и публикация в пятничный вечер была бы более к месту). Особенно, как я уже подметил, на фоне остальных. И я правда искренне удивлён минусам как к своим комментариям, так и к статье.
P.S. Вот так вот неудачно оставишь благодарность и уже не сможешь использовать разметку в комментариях :( Так что уж извиняйте за голый markdown.
Ого-го, целых 12 любителей тех замечательных статей из песочницы "как я делал свой велосипед на костылях и процедурном стиле в 2016 году". Это со мной что-то не так или же ...?
В функциональных языках и без исключений как-то живут. А серверные языки сейчас как раз в сторону функциональщины двигаются, да и не любят там исключения в общем-то, всё чаще пишут что-то подобное (если интересно) и тихо ненавидят яву за её checked-exceptions:
Try<MyResult> attempt = Try.of(this::doMyWork);
MyResult result = attempt
.recover(this::tryToRecover)
.getOrElse(myDefaultResult);
Или просто сразу пишут stateless и повторяют попытку в случае исключения.
И таки да, вроде как вот такая конструкция будет работать в JS: onClick={::this._myOnclick}
Без своих велосипедов далеко не уедешь, ну это ИМХО конечно. Сам ровно так учился к простому (silex) я пришёл в итоге своей php-карьеры, после чего радостно нырнул в яву.
Я не говорил, что велосипед должен быть гигантским, что-нибудь простенькое для понимания фабрик, фронт-контроллера и т.д.
ООП тут нет, почти совсем. Да и не настолько это большое приложение, чтоб об этом думать. (Естественно об этом надо задумываться, но иногда имеет смысл сделать проще) Как домашняя поделка для себя вполне сойдёт, но пожалуй было ошибкой выкладывать это сюда, впрочем как и на гитхаб. Если хотите попрактиковаться в PHP — выберите задачу посложнее (или эту преобразуйте), почитайте PSR, постигните composer, напишите свой велосипедофреймворк (главное не забудьте его потом выкинуть) и возьмите что-нибудь достойное — symfony, zend, phalcon,… Ну и хабру на эту тему почитайте уже сотни одних и тех же рекомендаций написано.
Вот мне только одно в слике не понятно: зачем он нужен, если он не умеет отображать х-to-many на case-классы? (я имею в виду случай, когда полем case-класса является список)
Буду лучом света в этом чане нечистот комментариев. (не воспринимать как абсолютное одобрение)
Вполне нормальная статья для начинающего.
Про злобных комментаторов: не обращай внимания, просто ровно все они писали подобные велосипеды поначалу (а то и хуже) и им так же говорили, что они не правы, вот теперь пришла их очередь наставлять на путь истинный. (Пруфы? Пруфов не будет — все и так это понимают)
Про комментаторов, чьи слова порядком непонятны: временно забудь, повелосипедируй ещё немного в своё удовольствие, потом потыкай какой-нибудь готовый, поддерживаемый сообществом framework (только трупы не тормоши), потом прочти книгу банды четырёх, затем стоит прочесть "Шаблоны корпоративных приложений" и просветление придёт к тебе.
И на будущее: не выкладывай свои велосипеды сюда (по крайней мере пока они полсотни звёзд на гитхабе не наберут, или ты не будешь в них абсолютно уверен), карму потом восстанавливать устанешь.
Его нельзя полностью построить т.к нет ещё значений, которые могут повлиять на выбор индекса.
Я конечно не спец по БД, но для любого подготовленного запроса можно построить план запроса, просто в PHP это не имеет смысла, ибо подготовка жрёт ресурсы, а так как она будет выполняться при каждом запросе к скрипту смысл в ней отпадает, если вы конечно не демона на пыхе пишете.
Подготовка имеет смысл в приложениях, где она происходит один раз — при старте приложания (например в яве [если запросы не динамические])
Суть в понимании какие плюсы даёт ФП и ФРП: понимание что такое монада (в первом приближении) и зачем они нужны; понимание как разложить любой SQL запрос на map/flatMap (bind)/filter/fold; понимание какую выгоду можно поиметь от генераторов в js помимо бесконечных списков; понимание чем являются генераторы js и чем будут являться async/await; понимание Promise, не в том смысле как пользоваться, а на чём он основан.
P.S. В целом конечно можно представлять ФРП и ФП как магию и при этом пытаться мыслить в категориях потоков данных, но ИМХО это проблематично.
Никогда не надейтесь на условные соглашения, тем более в enterprise, где любой случайный не очень опытный юниор может таким образом создать вам баг на 10+ человеко-часов
Я тут. И я считаю, что для людей которые не ставят label к элементам формы есть отдельный котёл в аду. Особенно когда речь заходит о чекбоксах. Особенно с мобильных устройств.
>> Второй ориентирован на веб-страницы, а не веб-приложения.
В чём по вашему принципиальная разница?
Из близкого по теме рекомендую посмотреть: Binding.scala для понимания тру-реактивности (требует наличия свежей jdk и scala + sbt), elm для понимания ФП и Rx%LANGNAME% для понимания реактивных потоков (советую язык со строгой типизацией)
UPD: да прибудут со мной минусы.
**off-topic:** чего только эти императивщики не придумают вместо `@tailrec`. (знаю, что в scala/haskell/kotlin используются подобный метод, просто шутки ради)
Да я-то как раз не удивлён (хоть и не приятно, что простая благодарность принимается настолько в штыки), как говорится «за страну обидно»
Так что я действительно считаю, что это достойная статья (хоть может и публикация в пятничный вечер была бы более к месту). Особенно, как я уже подметил, на фоне остальных. И я правда искренне удивлён минусам как к своим комментариям, так и к статье.
P.S. Вот так вот неудачно оставишь благодарность и уже не сможешь использовать разметку в комментариях :( Так что уж извиняйте за голый markdown.
Подозреваю это был не автор, а те, чей код он читал.
Ого-го, целых 12 любителей тех замечательных статей из песочницы "как я делал свой велосипед на костылях и процедурном стиле в 2016 году". Это со мной что-то не так или же ...?
Пожалуй это одна из лучших статей по PHP из песочницы за последнее время.
Добро пожаловать на хабр!
В функциональных языках и без исключений как-то живут. А серверные языки сейчас как раз в сторону функциональщины двигаются, да и не любят там исключения в общем-то, всё чаще пишут что-то подобное (если интересно) и тихо ненавидят яву за её checked-exceptions:
Или просто сразу пишут stateless и повторяют попытку в случае исключения.
И таки да, вроде как вот такая конструкция будет работать в JS:
onClick={::this._myOnclick}Без своих велосипедов далеко не уедешь, ну это ИМХО конечно. Сам ровно так учился к простому (silex) я пришёл в итоге своей php-карьеры, после чего радостно нырнул в яву.
ООП тут нет, почти совсем.
Да и не настолько это большое приложение, чтоб об этом думать.(Естественно об этом надо задумываться, но иногда имеет смысл сделать проще) Как домашняя поделка для себя вполне сойдёт, но пожалуй было ошибкой выкладывать это сюда, впрочем как и на гитхаб. Если хотите попрактиковаться в PHP — выберите задачу посложнее (или эту преобразуйте), почитайте PSR, постигните composer, напишите свой велосипедофреймворк (главное не забудьте его потом выкинуть) и возьмите что-нибудь достойное — symfony, zend, phalcon,… Ну и хабру на эту тему почитайте уже сотни одних и тех же рекомендаций написано.Ну и добро пожаловать на хабр!
Эхх… Видимо нет для скалы внятного способа использовать бд и иммутабельные кейс-классы :(
Вот мне только одно в слике не понятно: зачем он нужен, если он не умеет отображать х-to-many на case-классы? (я имею в виду случай, когда полем case-класса является список)
Или может это я что-то не так делаю?
Буду лучом света в этом чане нечистот комментариев. (не воспринимать как абсолютное одобрение)
Вполне нормальная статья для начинающего.
Про злобных комментаторов: не обращай внимания, просто ровно все они писали подобные велосипеды поначалу (а то и хуже) и им так же говорили, что они не правы, вот теперь пришла их очередь наставлять на путь истинный. (Пруфы? Пруфов не будет — все и так это понимают)
Про комментаторов, чьи слова порядком непонятны: временно забудь, повелосипедируй ещё немного в своё удовольствие, потом потыкай какой-нибудь готовый, поддерживаемый сообществом framework (только трупы не тормоши), потом прочти книгу банды четырёх, затем стоит прочесть "Шаблоны корпоративных приложений" и просветление придёт к тебе.
И на будущее: не выкладывай свои велосипеды сюда (по крайней мере пока они полсотни звёзд на гитхабе не наберут, или ты не будешь в них абсолютно уверен), карму потом восстанавливать устанешь.
Ну и добро пожаловать на хабр!
Я конечно не спец по БД, но для любого подготовленного запроса можно построить план запроса, просто в PHP это не имеет смысла, ибо подготовка жрёт ресурсы, а так как она будет выполняться при каждом запросе к скрипту смысл в ней отпадает, если вы конечно не демона на пыхе пишете.
Подготовка имеет смысл в приложениях, где она происходит один раз — при старте приложания (например в яве [если запросы не динамические])