Если это троллинг, то я на него почти повёлся. В ином случае вам стоит изучить Haskell (или его браузерную инкарнацию Elm), иначе ну нельзя же таким быть! Особенно вот это понравилось:
питон пробовал — синтаксис не понравился, скобочек нет
Я кстати уверен что в будущем люди не то что «забудут этот недохаскель». Но реально перейдут на хаскель. Ну точнее его браузерную инкарнацию какую-нибудь, типа Elm. Очевидно же, что все к тому идет, просто не революционным, а эволюционным путем. JS все больше и больше становится похож на это, в какой-то момент уже просто не будет смысла использовать JS, все свитчнутся на какой-нибудь транспилируемый в него язык. Они и сейчас есть, такие языки, просто люди еще не понимают до конца, зачем они нужны — но это в какой-то момент станет очевидно всем. И появление таких вещей как React/Redux в массовом сознании это очень мощные сигналы к этому.
[...]
И тут интересный дальше момент — это определяет архитектуру нашего приложения. То есть, выгодно юзать Redux. А это уже все прямиком пришло их функциональных языков, из Elm в частности. И постепенно никакого смысла в том чтобы использовать JS вместо Elm не будет. Потому что Elm позволяет еще и статически верифицировать всю программу так, что у вас вообще нет runtime exceptions. А это и есть ультимативная цель всего этого замеса.
Согласен, я погорячился с выводами. Просто я часто замечаю, что люди пытаются сделать из JS какой-то Java, хотя куда правильнее было бы двигаться в сторону функциональных вещей — и таким образом достигать статической верифицируемости. Собственно, я в этой статье и изложил видение того, как этого можно было бы достичь. А прототипы и динамичность языка мне нравятся именно возможностями метапрограммирования (embedded DSL), и это не очень пока совместимо с Java-подходом. Java это такой энтерпрайз-фашизм, а в JS есть дух хардкора, молодости и эксперимента. И вот это я и называю «фишкой».
Пользователю фреймворка это дает React, лол. Он был бы невозможен без этого. Я именно об этом и говорю, это не просто «быстро найти изменения», это и есть ключевой момент во всем этом. В макро масштабе.
И тут интересный дальше момент — это определяет архитектуру нашего приложения. То есть, выгодно юзать Redux. А это уже все прямиком пришло их функциональных языков, из Elm в частности. И постепенно никакого смысла в том чтобы использовать JS вместо Elm не будет. Потому что Elm позволяет еще и статически верифицировать всю программу так, что у вас вообще нет runtime exceptions. А это и есть ультимативная цель всего этого замеса.
Ну это меня не печалит, потому что у меня свои «декораторы», которые вообще даже в ES5 работают. Я просто прикидывал, как их можно было бы реализовать, будь у нас нативный синтаксис. Хотя по мне, лучше бы они классы депрекейтнули, ха-ха.
Какие чужие? Это мои слова, и это основано на моём опыте. Я как раз делал систему классов и декораторов для ES5, и вижу какие напряги возникают с попытками перенести это на нативные ES6 классы. Я не готов отказываться от этого только для статического анализа типов, это совершенно неразумный tradeoff в моем случае.
Просто вы видимо пришли из мира Java и пытаетесь писать код в таком же стиле. Разумеется, в таком случае JavaScript покажется каким-то ущербным Java без системы строгой статической типизации. Но это просто потому что вы не понимаете фишки JS.
Так же можно сказать что и immutable state это легкий сахар над mutable state, ведь архитектура компов это Тьюринг-машина. Я не очень понимаю такую «логику» рассуждений. Про преимущества есть в статье.
Я кстати уверен что в будущем люди не то что «забудут недохаскель». Но реально перейдут на хаскель. Ну точнее его браузерную инкарнацию какую-нибудь, типа Elm. Очевидно же, что все к тому идет, просто не революционным, а эволюционным путем. JS все больше и больше становится похож на это, в какой-то момент уже просто не будет смысла использовать JS, все свитчнутся на какой-нибудь транспилируемый в него язык. Они и сейчас есть, такие языки, просто люди еще не понимают до конца, зачем они нужны — но это в какой-то момент станет очевидно всем. И появление таких вещей как React/Redux в массовом сознании это очень мощные сигналы к этому.
В чистом C возможно. Но в C++ это не так. Я писал на C++ много лет (3D графика), и мне ни разу не пришлось использовать goto. Хотя он там есть. Я именно об этом и говорю — наличие инструмента не делает его использование оправданным.
Так же и мутабельность — это только выглядит «удобным», как гото когда-то выглядел удобным, пока не появились лучшие инструменты. И точно так же находились те, кто считал, что старый подход лучше, потому что «удобнее». Вы думаете мало было холиваров насчет гото? Вот и mutable state ждет такая же судьба. Останется уделом низкоуровневых вещей каких-то, где без этого вообще нельзя. А на макроуровне это забудут, как страшный сон.
У реакта иммутабельность это не ограничение. Это как говорить что автомобиль это ограничение, потому что он плавать не умеет, а вы умеете. Да, он не умеет плавать, зато он ездит в десять раз быстрее чем вы бегаете. И в реальности это намного важнее. Я полагаю, что вы когда рассуждаете об этом, как об ограничении — то за деревьями не видите леса, не понимая до конца преимуществ иммутабельности в макромасштабе. Я кстати об этом написал статью сегодня.
Просто, как я понимаю, по дефолту Реакт свои компоненты не считает за чистые функции. И вызывает render() всегда. Я именно поэтому и упомянул два раза в статье, что описываю «идеализированный» Реакт :)
Ага, как и setjmp и longjmp. Только эти вещи используются в очень частных случаях, и только когда это реально оправдано. Observables это реально интересная вещь — ложится на наши естественные ментальные модели хорошо. Как и гото, например. Он ведь тоже когда-то появился, потому что это для нашего мышления естественная штука. Проблема в том, что наши ментальные модели зачастую говно. Человеку свойственно ошибаться и нести чушь.
То есть, иногда встает выбор — либо учить что-то новое и прорывное (новую ментальную модель) — что дает принципиально новые возможности (как функциональный подход и redux) — либо заниматься луддизмом, и цепляться за mutable state, просто потому что мы уже привыкли так мыслить, а новые парадигмы мы в голове помещать не хотим. Но время все расставляет по местам, думаю что штуки типа mobx для менеджмента состояний будут оправданы только в маленьких простых приложениях, а в больших и сложных это будет шаг назад в сравнении с Redux. Это чем-то похоже на дилемму из статьи, кстати (jquery vs react).
Не использовать их, к счастью, мне ничто не мешает. Но именно поэтому я и недоумеваю, зачем они вообще нужны. Их функциональность прекрасно была доступна на уровне библиотек, и при этом была намного гибче. Что именно они уничтожили, я описал в начале статьи (где про декораторы написано). Без декораторов для моих задач ES6 классы вообще выглядят как бессмысленный огрызок.
Пока что мне вот подсказали, что для статического анализа типов классы хорошо, как хинт. Это действительно так, наверное.
Всему свое время. Просто его код пока еще слишком плох для opensource (много проприетарщины и левых зависимостей), и я хочу его отрефакторить перед публикацией, но никак не могу найти время на это. Тут очень важно maintainability, потому что у меня нет времени это развивать самому (мне за это не платят), а комьюнити могло бы помочь. Вообще-то он валяется на гитхабе, но пока что в реально стремном состоянии, not for human consumption.
Это шаг назад по сравнению с redux, потому что теряется predictability. Выглядит мощно да, но и goto в C выглядел мощно. А потом все поняли, что это верный способ себе ногу отстрелить.
Object.getOwnPropertySymbols нужен, чтобы можно было склонировать объект. Например если вы миксины делаете, без этого никак. Или для отладки, чтобы например в консоли было видно, че там за символы у объекта. Дырой было бы, если бы эту информацию нельзя было бы получить — это как раз разрушило бы консистентность.
данным мог получить доступ только тот, для кого они предназначены
Это так и есть. Ведь если у вас нет ссылки на символ (и он безымянный, не через реестр), то вы не можете никакой осмысленный доступ к свойству такому получить. Это как квантовая информация, она вроде бы есть, а вроде бы и нет. Но её можно скопировать, вот за этим и нужно.
Язык же не висит в сферическом вакууме отдельно от его реализации и от стандартной библиотеки, тонкостей очень много. Да и в самом языке странностей хватает вообще-то. Где-то был пост с хорошей подборкой их, я запамятовал.
Ну да, это просто терминологическая путаница. Я почти сразу подправил статью после публикации, просто видимо вам в RSS (или еще куда) старая версия подсосалась.
Спросонья показалось, что это какая-то операционка сделанная на ReactJS, лол. Надо меньше упарываться фронтендом...
Если это троллинг, то я на него почти повёлся. В ином случае вам стоит изучить Haskell (или его браузерную инкарнацию Elm), иначе ну нельзя же таким быть! Особенно вот это понравилось:
Согласен, я погорячился с выводами. Просто я часто замечаю, что люди пытаются сделать из JS какой-то Java, хотя куда правильнее было бы двигаться в сторону функциональных вещей — и таким образом достигать статической верифицируемости. Собственно, я в этой статье и изложил видение того, как этого можно было бы достичь. А прототипы и динамичность языка мне нравятся именно возможностями метапрограммирования (embedded DSL), и это не очень пока совместимо с Java-подходом. Java это такой энтерпрайз-фашизм, а в JS есть дух хардкора, молодости и эксперимента. И вот это я и называю «фишкой».
Пользователю фреймворка это дает React, лол. Он был бы невозможен без этого. Я именно об этом и говорю, это не просто «быстро найти изменения», это и есть ключевой момент во всем этом. В макро масштабе.
И тут интересный дальше момент — это определяет архитектуру нашего приложения. То есть, выгодно юзать Redux. А это уже все прямиком пришло их функциональных языков, из Elm в частности. И постепенно никакого смысла в том чтобы использовать JS вместо Elm не будет. Потому что Elm позволяет еще и статически верифицировать всю программу так, что у вас вообще нет runtime exceptions. А это и есть ультимативная цель всего этого замеса.
Ну это меня не печалит, потому что у меня свои «декораторы», которые вообще даже в ES5 работают. Я просто прикидывал, как их можно было бы реализовать, будь у нас нативный синтаксис. Хотя по мне, лучше бы они классы депрекейтнули, ха-ха.
Какие чужие? Это мои слова, и это основано на моём опыте. Я как раз делал систему классов и декораторов для ES5, и вижу какие напряги возникают с попытками перенести это на нативные ES6 классы. Я не готов отказываться от этого только для статического анализа типов, это совершенно неразумный tradeoff в моем случае.
Просто вы видимо пришли из мира Java и пытаетесь писать код в таком же стиле. Разумеется, в таком случае JavaScript покажется каким-то ущербным Java без системы строгой статической типизации. Но это просто потому что вы не понимаете фишки JS.
Так же можно сказать что и immutable state это легкий сахар над mutable state, ведь архитектура компов это Тьюринг-машина. Я не очень понимаю такую «логику» рассуждений. Про преимущества есть в статье.
Я кстати уверен что в будущем люди не то что «забудут недохаскель». Но реально перейдут на хаскель. Ну точнее его браузерную инкарнацию какую-нибудь, типа Elm. Очевидно же, что все к тому идет, просто не революционным, а эволюционным путем. JS все больше и больше становится похож на это, в какой-то момент уже просто не будет смысла использовать JS, все свитчнутся на какой-нибудь транспилируемый в него язык. Они и сейчас есть, такие языки, просто люди еще не понимают до конца, зачем они нужны — но это в какой-то момент станет очевидно всем. И появление таких вещей как React/Redux в массовом сознании это очень мощные сигналы к этому.
В чистом C возможно. Но в C++ это не так. Я писал на C++ много лет (3D графика), и мне ни разу не пришлось использовать
goto. Хотя он там есть. Я именно об этом и говорю — наличие инструмента не делает его использование оправданным.Так же и мутабельность — это только выглядит «удобным», как гото когда-то выглядел удобным, пока не появились лучшие инструменты. И точно так же находились те, кто считал, что старый подход лучше, потому что «удобнее». Вы думаете мало было холиваров насчет гото? Вот и mutable state ждет такая же судьба. Останется уделом низкоуровневых вещей каких-то, где без этого вообще нельзя. А на макроуровне это забудут, как страшный сон.
У реакта иммутабельность это не ограничение. Это как говорить что автомобиль это ограничение, потому что он плавать не умеет, а вы умеете. Да, он не умеет плавать, зато он ездит в десять раз быстрее чем вы бегаете. И в реальности это намного важнее. Я полагаю, что вы когда рассуждаете об этом, как об ограничении — то за деревьями не видите леса, не понимая до конца преимуществ иммутабельности в макромасштабе. Я кстати об этом написал статью сегодня.
Мб туда надо PureRenderMixin вкорячить?
https://facebook.github.io/react/docs/pure-render-mixin.html
Просто, как я понимаю, по дефолту Реакт свои компоненты не считает за чистые функции. И вызывает render() всегда. Я именно поэтому и упомянул два раза в статье, что описываю «идеализированный» Реакт :)
Ага, как и setjmp и longjmp. Только эти вещи используются в очень частных случаях, и только когда это реально оправдано. Observables это реально интересная вещь — ложится на наши естественные ментальные модели хорошо. Как и гото, например. Он ведь тоже когда-то появился, потому что это для нашего мышления естественная штука. Проблема в том, что наши ментальные модели зачастую говно. Человеку свойственно ошибаться и нести чушь.
То есть, иногда встает выбор — либо учить что-то новое и прорывное (новую ментальную модель) — что дает принципиально новые возможности (как функциональный подход и redux) — либо заниматься луддизмом, и цепляться за mutable state, просто потому что мы уже привыкли так мыслить, а новые парадигмы мы в голове помещать не хотим. Но время все расставляет по местам, думаю что штуки типа mobx для менеджмента состояний будут оправданы только в маленьких простых приложениях, а в больших и сложных это будет шаг назад в сравнении с Redux. Это чем-то похоже на дилемму из статьи, кстати (jquery vs react).
Не использовать их, к счастью, мне ничто не мешает. Но именно поэтому я и недоумеваю, зачем они вообще нужны. Их функциональность прекрасно была доступна на уровне библиотек, и при этом была намного гибче. Что именно они уничтожили, я описал в начале статьи (где про декораторы написано). Без декораторов для моих задач ES6 классы вообще выглядят как бессмысленный огрызок.
Пока что мне вот подсказали, что для статического анализа типов классы хорошо, как хинт. Это действительно так, наверное.
Всему свое время. Просто его код пока еще слишком плох для opensource (много проприетарщины и левых зависимостей), и я хочу его отрефакторить перед публикацией, но никак не могу найти время на это. Тут очень важно maintainability, потому что у меня нет времени это развивать самому (мне за это не платят), а комьюнити могло бы помочь. Вообще-то он валяется на гитхабе, но пока что в реально стремном состоянии, not for human consumption.
Это шаг назад по сравнению с redux, потому что теряется predictability. Выглядит мощно да, но и
gotoв C выглядел мощно. А потом все поняли, что это верный способ себе ногу отстрелить.Object.getOwnPropertySymbolsнужен, чтобы можно было склонировать объект. Например если вы миксины делаете, без этого никак. Или для отладки, чтобы например в консоли было видно, че там за символы у объекта. Дырой было бы, если бы эту информацию нельзя было бы получить — это как раз разрушило бы консистентность.Это так и есть. Ведь если у вас нет ссылки на символ (и он безымянный, не через реестр), то вы не можете никакой осмысленный доступ к свойству такому получить. Это как квантовая информация, она вроде бы есть, а вроде бы и нет. Но её можно скопировать, вот за этим и нужно.
Лучше тогда вообще… постойте, это уже какая-то пропаганда самоубийств получается. Я слышал, это незаконно теперь!
Язык же не висит в сферическом вакууме отдельно от его реализации и от стандартной библиотеки, тонкостей очень много. Да и в самом языке странностей хватает вообще-то. Где-то был пост с хорошей подборкой их, я запамятовал.
Ну да, это просто терминологическая путаница. Я почти сразу подправил статью после публикации, просто видимо вам в RSS (или еще куда) старая версия подсосалась.
Они не обязаны в них упираться. Вы можете сделать так (делая отсылку к моему предыдущему примеру):
И никаких коллизий.