Вы напрасно сравниваете гото и иммутабельность, в плане их «старины», пытаясь из этого какие-то выводы сделать. Гото это чисто инженерное решение, которое было обусловлено низкоуровневой архитектурой вычислительного железа. Оно старое просто потому что компы старые.
Иммутабельность же появилась именно как абстрактная академическая идея, и оставалось игрушкой, пока не появились задачи, в которых это очевидно удобно. То есть миру нужно было просто дорасти до таких задач. Это сложные, высокоуровневые задачи, очень далекие от архитектуры железа и гото. Они не могли возникнуть сразу, это вопрос эволюции.
Точно так же как и другие вещи из функциональных языков, типа лямбд или замыканий. Представьте себе, лямбда-исчислению уже скоро будет 100 лет. И вот только-только это становится мейнстримом.
Задача которую вы описываете — это не высокоуровневая задача, это как раз область применимости отверток.
> То, что вы почему-либо с таким классом задач не сталкивались
С чего это я не сталкивался? Я с таких задач и начинал, можете резюме глянуть. В детстве 3D движки писал (DX/GL), там таких задач как раз полно. Это все лоу левел.
Я вам привел совершенно конкретный пример весьма сложной высокоуровневой задачи (WYSIWYG редактор), где immutable state упрощает код на порядок, делая его предсказуемым, высокопроизводительным и легко расширяемым: https://github.com/ianstormtaylor/slate#principles
А вы мне про какие-то EXIF из фоток. Детский сад...
Так вы посмотрите с чего ветка-то началась, пример goto не просто так был приведён. Каждая новая технология не отменяет старой, но расширяет горизонт возможностей, а старая технология остается в рамках этого расширенного горизонта маленькой нишей. Сегодня люди до сих пор используют и C++, и ассемблер даже — но на прикладном уровне этого уже нет давно. Вот так же и mutable state — это старая парадигма, которая не способна решать «бытовые» задачи, с которыми люди сталкиваются сегодня. Просто это новые задачи, новые вызовы. В рамках которых люди действительно уже отказались от «отверток». А отвертки остались в своей области применимости.
Тест как раз нормальный, реалистичный. Потому что на большинстве работ вы будете заняты как раз тем, что будете переписывать легаси код, в котором вот такого будет полно. Вы конечно можете всегда найти работу в светлом и чистом стартапе (чтобы потом в будущем кто-нибудь точно так же чесал репу над вашим кодом), но надо понимать реалии рынка — в мире есть очень много плохо написанного кода, который нужно поддерживать или хотя бы переписать. А для этого нужно как минимум уметь в сортах говна разбираться.
Как пел Кровосток, «в наше время, в нашем месте, стоит разбираться в жести...»
На высокоуровневых задачах в вебе про mutable state уже забыли. Я в прошлом году писал WYSIWYG редактор который работал с изменяемым состоянием, хранящимся напрямую в DOM. Было очень сложно добиться безглючности и понятности кода, а также работы штук типа стека undo/redo. Сейчас я смотрю на последние разработки редакторов типа Slate или Draft.js — это невероятно, насколько иммутабельность помогла им выстроить хорошую архитектуру, позволяющую в разы больше, чем возможно было до того.
Есть такой принцип — «не сломано, не трогай». Никто не будет переписывать миллионы строк работающего кода, только чтобы чуваки могли еще парочку статей об этом написать в модный журнал.
Вы уже много фейсбуков написали? :) Просто у вас о нем очень примитивизированное представление. Любой веб-проект на деле намного сложнее чем кажется.
Фейсбук стали использовать React не так давно, значительная часть их кода всё еще на условных «джиквери» (разных предшествующих реакту технологиях, в общем). Если бы они с самого начала юзали React, им бы возможно удалось избежать как раз-таки их этой многомиллионной кодовой базы.
Про то что Flow не умеет в типизацию destructuring-выражений это, конечно, печально — но думаю это всего лишь временная неувязка. По поводу ваших сетований об алгоритмической сложности «хипстерского» (wtf) кода — вы же должны понимать, что это лишь специфика вашей работы (игры?), связанной с повышенными требованиями к производительности.
В достаточно сложном проекте (ERP предприятия), работающем с кучей данных (сотни тысяч записей в таблицах, обрабатываемых на client-side) мне пришлось всего пару раз вручную написать цикл — это собственно, табличный контрол который осуществлял виртуализацию рендеринга и фильтрацию/сортировку датасетов. Во всем остальном, «прикладом» коде я с радостью использовал все прелести функциональных выражений, вообще не думая о том, насколько быстро они работают (покуда это не начинало тормозить).
Premature optimization is the root of all evil, как говорится. Я в JS пришел из C++ и дико рад, что мне в моих повседневных задачах больше не надо думать о таких вещах, как ручной менеджмент памяти или там, упаси боже, какие-нибудь cache misses. Я хочу забыть про это, как про страшный сон, и заниматься вещами поинтереснее, чем бессонными ночами думать о «протекающих абстракциях» в моем коде. Покуда он работает и работает приемлемо — я не хочу об этом думать.
Да, это все становится оправдано когда кол-во файлов переваливает за несколько десятков. Для проектов из трех-четырех файлов смысла в вебпаке, мб, никакого и нет. По крайней мере все эти проблемы я начал неиллюзорно ощущать только когда проект порядком разросся.
Но при этом мне проще мейнтейнить свой проект, т.к. каждый модуль знает только то, от чего он зависит. И плоский список всех зависимостей получается как производное от этого.
А у вас получается делокализация — скажем, я поменял модуль A так, что он теперь зависит от модуля B. И эту информацию мне нужно добавить в какое-то совершенно третье место («главный заголовочный файл», со плоским списокм всех зависимостей), в котором никак не отражена связь между модулями. Это значит, что если модуль A перестанет зависеть от B, то «мусорная» зависимость с высокой вероятностью останется в том третьем файле, потому что вы забудете про неё. Или кто-нибудь еще забудет. В общем, у меня был опыт разработки проекта где именно таким образом все делалось — я не юзал import/require для декларирования межмодульных зависимостей, и поимел все возможные связанные с этим проблемы. Самая жесть началась, когда я попытался сделать свой код re-usable, расшарив его между многими проектами. Сразу же возникает такого рода проблема, что вам нужно во всех этих проектах менять список зависимостей, когда в каком-то модуле что-то меняется. Это приводило к труднообнаружимым багам, к избыточности кода, и так далее.
Если бы я с самого начала использовал import/require и автоматическое разрешение зависимостей (webpack), то сэкономил бы кучу времени...
Ну склеивать удобно хотя бы потому, что браузер не поддерживает директивы import и require. А любой более-менее сложный проект это сотни файлов, связанных такими зависимостями.
Каким образом вы это на HTML страничку доставите? Будете вручную script теги прописывать для каждого, еще и вручную нужный порядок подключения высчитывая?
Конечно же, вы возьмете webpack, укажете ему «точку входа» (js-файл), и он разрешит все дерево зависимостей, высрав это в один файл, который вы можете банальным script тегом подключить. Как бонус — вебпак поддерживает горячую перезагрузку модулей.
Я вот буквально прямо щас настраиваю у нас в сервере Webpack HMR (hot module replacement) + React HotReload. Очень удобная вещь — я жму Ctrl-S в редактируемом модуле, и моментально получаю в браузере обновленный код, без перезагрузки страницы. А поскольку архитектура React/Redux предполагает разделение кода и данных, то при такой замене кода «на горячую», даже не теряется состояние моих компонентов. Это очень круто и дает 100% буста продуктивности.
О, замечательная штука. Меня правда больше заинтересовал Draft.js сейчас фейсбучный — т.к. он куда более примитивный, для образовательных целей больше подходит. В общем, щас буду думать, как такую механику взаимодействия реализовать для React-based редакторов, может это не так уж и сложно, как кажется. Потому что очень хочется перейти на VirtualDOM и иммутабельность состояния — плюсы от этого перевешивают все минусы, когда речь заходит о такой сложной вещи, как современные контент-редакторы.
Насчет телефонов я с вами согласен. Я вообще телефон не использую уже пару лет как — не хочу кормить зажравшихся операторов связи, которые отчаянно не хотят быть просто «трубой для данных», и ведут себя как цыгане на рынке, пытаясь обобрать пользователя до последней копейки. Это не партнерство, это не сотрудничество — это воровство… И бороться с этим можно только прекратив эти «отношения». Но это так, оффтоп :)
Но если вы думаете, что концепция «функций как объектов первого класса (first class citizen)» и замыканий вам подобным образом чем-то навредит, обокрав ваше внимание и время — то это вы зря. Мне вот есть с чем сравнивать, могу вас уверить, что это вас только обогатит, сократив ваши трудозатраты. Ну это конечно, если вы собираетесь зарабатывать написанием кода. В ином случае вам это, действительно, не нужно...
По сравнению с реактом — это голый дом, т.к. к нему прямой доступ, оно работает напрямую с его узлами (без виртуальной прослойки). На реакте я такое не знаю как сделать, мне кажется это просто невозможно на данный момент. По поводу эксепшенов я хз, я это вообще не планировал публиковать пока что, пока не отвяжу это от проприетарных библиотек. Зря я ссылку выложил.
Это просто SerafimArts панику наводит. На самом деле это не депрекейт, а просто обновляют черновик стандарта, и пока апдейт идет, из Babel временно убрали текущую реализацию (она доступна в виде внешнего плагина). Это нормальный процесс работы, и декораторы еще вернутся. Их уже юзают многие технологии популярные — например ангуляр2, mobx.
Я хаскеллом не обмазываюсь уже лет восемь, поэтому совершенно выпал из контекста — про ghcjs и purescript впервые слышу. Я про Elm-то узнал буквально на днях, когда узнавал откуда у React/Redux ноги растут. Даже не успел его попробовать толком.
И одновременно стало проще — но на другом уровне. Такой стек технологий ведь не просто так возник, это именно ответ на вызовы современности, это реакция на необходимость делать вещи, которые лет 5 назад были просто немыслимы из-за сложности реализации.
То есть оно «все усложнилось» разве что только в какой-то статичной системе отсчета… ну типа, если вы в 2016 все еще ориентируетесь на проекты уровня 2008 года, то это действительно кажется чем-то безумным. Я занимаюсь веб-фронтендом примерно с того года как раз, и прекрасно помню, как я тогда несколько недель (на голом DOM / HTML / CSS) возился с проектом, на который сегодня у меня ушел бы один рабочий день. Тогда просто не было таких инструментов.
На самом деле, код на jQuery намного дороже. Это примерно как лечить зубы у плохого стоматолога. Вроде бы дешевле, но выходит что дороже. И потерянное время вам никто не вернет.
И оправдано это именно в мегапроектах типа Фейсбука. У них тысячи компонентов, миллионы строк кода. Для маленьких же сайтов-визиток, конечно же, лучше использовать jQuery. Или вообще голый DOM (в jQuery смысла не очень много с появлением нативных селекторов).
Вы напрасно сравниваете гото и иммутабельность, в плане их «старины», пытаясь из этого какие-то выводы сделать. Гото это чисто инженерное решение, которое было обусловлено низкоуровневой архитектурой вычислительного железа. Оно старое просто потому что компы старые.
Иммутабельность же появилась именно как абстрактная академическая идея, и оставалось игрушкой, пока не появились задачи, в которых это очевидно удобно. То есть миру нужно было просто дорасти до таких задач. Это сложные, высокоуровневые задачи, очень далекие от архитектуры железа и гото. Они не могли возникнуть сразу, это вопрос эволюции.
Точно так же как и другие вещи из функциональных языков, типа лямбд или замыканий. Представьте себе, лямбда-исчислению уже скоро будет 100 лет. И вот только-только это становится мейнстримом.
Вы просто путаете теплое с мягким.
Задача которую вы описываете — это не высокоуровневая задача, это как раз область применимости отверток.
> То, что вы почему-либо с таким классом задач не сталкивались
С чего это я не сталкивался? Я с таких задач и начинал, можете резюме глянуть. В детстве 3D движки писал (DX/GL), там таких задач как раз полно. Это все лоу левел.
Я вам привел совершенно конкретный пример весьма сложной высокоуровневой задачи (WYSIWYG редактор), где immutable state упрощает код на порядок, делая его предсказуемым, высокопроизводительным и легко расширяемым: https://github.com/ianstormtaylor/slate#principles
А вы мне про какие-то EXIF из фоток. Детский сад...
Так вы посмотрите с чего ветка-то началась, пример goto не просто так был приведён. Каждая новая технология не отменяет старой, но расширяет горизонт возможностей, а старая технология остается в рамках этого расширенного горизонта маленькой нишей. Сегодня люди до сих пор используют и C++, и ассемблер даже — но на прикладном уровне этого уже нет давно. Вот так же и mutable state — это старая парадигма, которая не способна решать «бытовые» задачи, с которыми люди сталкиваются сегодня. Просто это новые задачи, новые вызовы. В рамках которых люди действительно уже отказались от «отверток». А отвертки остались в своей области применимости.
Тест как раз нормальный, реалистичный. Потому что на большинстве работ вы будете заняты как раз тем, что будете переписывать легаси код, в котором вот такого будет полно. Вы конечно можете всегда найти работу в светлом и чистом стартапе (чтобы потом в будущем кто-нибудь точно так же чесал репу над вашим кодом), но надо понимать реалии рынка — в мире есть очень много плохо написанного кода, который нужно поддерживать или хотя бы переписать. А для этого нужно как минимум уметь в сортах говна разбираться.
Как пел Кровосток, «в наше время, в нашем месте, стоит разбираться в жести...»
https://habrahabr.ru/post/308154/
На высокоуровневых задачах в вебе про mutable state уже забыли. Я в прошлом году писал WYSIWYG редактор который работал с изменяемым состоянием, хранящимся напрямую в DOM. Было очень сложно добиться безглючности и понятности кода, а также работы штук типа стека undo/redo. Сейчас я смотрю на последние разработки редакторов типа Slate или Draft.js — это невероятно, насколько иммутабельность помогла им выстроить хорошую архитектуру, позволяющую в разы больше, чем возможно было до того.
Есть такой принцип — «не сломано, не трогай». Никто не будет переписывать миллионы строк работающего кода, только чтобы чуваки могли еще парочку статей об этом написать в модный журнал.
Вы уже много фейсбуков написали? :) Просто у вас о нем очень примитивизированное представление. Любой веб-проект на деле намного сложнее чем кажется.
Фейсбук стали использовать React не так давно, значительная часть их кода всё еще на условных «джиквери» (разных предшествующих реакту технологиях, в общем). Если бы они с самого начала юзали React, им бы возможно удалось избежать как раз-таки их этой многомиллионной кодовой базы.
Про то что Flow не умеет в типизацию destructuring-выражений это, конечно, печально — но думаю это всего лишь временная неувязка. По поводу ваших сетований об алгоритмической сложности «хипстерского» (wtf) кода — вы же должны понимать, что это лишь специфика вашей работы (игры?), связанной с повышенными требованиями к производительности.
В достаточно сложном проекте (ERP предприятия), работающем с кучей данных (сотни тысяч записей в таблицах, обрабатываемых на client-side) мне пришлось всего пару раз вручную написать цикл — это собственно, табличный контрол который осуществлял виртуализацию рендеринга и фильтрацию/сортировку датасетов. Во всем остальном, «прикладом» коде я с радостью использовал все прелести функциональных выражений, вообще не думая о том, насколько быстро они работают (покуда это не начинало тормозить).
Premature optimization is the root of all evil, как говорится. Я в JS пришел из C++ и дико рад, что мне в моих повседневных задачах больше не надо думать о таких вещах, как ручной менеджмент памяти или там, упаси боже, какие-нибудь cache misses. Я хочу забыть про это, как про страшный сон, и заниматься вещами поинтереснее, чем бессонными ночами думать о «протекающих абстракциях» в моем коде. Покуда он работает и работает приемлемо — я не хочу об этом думать.
Да, это все становится оправдано когда кол-во файлов переваливает за несколько десятков. Для проектов из трех-четырех файлов смысла в вебпаке, мб, никакого и нет. По крайней мере все эти проблемы я начал неиллюзорно ощущать только когда проект порядком разросся.
Но при этом мне проще мейнтейнить свой проект, т.к. каждый модуль знает только то, от чего он зависит. И плоский список всех зависимостей получается как производное от этого.
А у вас получается делокализация — скажем, я поменял модуль A так, что он теперь зависит от модуля B. И эту информацию мне нужно добавить в какое-то совершенно третье место («главный заголовочный файл», со плоским списокм всех зависимостей), в котором никак не отражена связь между модулями. Это значит, что если модуль A перестанет зависеть от B, то «мусорная» зависимость с высокой вероятностью останется в том третьем файле, потому что вы забудете про неё. Или кто-нибудь еще забудет. В общем, у меня был опыт разработки проекта где именно таким образом все делалось — я не юзал import/require для декларирования межмодульных зависимостей, и поимел все возможные связанные с этим проблемы. Самая жесть началась, когда я попытался сделать свой код re-usable, расшарив его между многими проектами. Сразу же возникает такого рода проблема, что вам нужно во всех этих проектах менять список зависимостей, когда в каком-то модуле что-то меняется. Это приводило к труднообнаружимым багам, к избыточности кода, и так далее.
Если бы я с самого начала использовал import/require и автоматическое разрешение зависимостей (webpack), то сэкономил бы кучу времени...
Ну склеивать удобно хотя бы потому, что браузер не поддерживает директивы
importиrequire. А любой более-менее сложный проект это сотни файлов, связанных такими зависимостями.Каким образом вы это на HTML страничку доставите? Будете вручную
scriptтеги прописывать для каждого, еще и вручную нужный порядок подключения высчитывая?Конечно же, вы возьмете
webpack, укажете ему «точку входа» (js-файл), и он разрешит все дерево зависимостей, высрав это в один файл, который вы можете банальнымscriptтегом подключить. Как бонус — вебпак поддерживает горячую перезагрузку модулей.Я вот буквально прямо щас настраиваю у нас в сервере Webpack HMR (hot module replacement) + React HotReload. Очень удобная вещь — я жму Ctrl-S в редактируемом модуле, и моментально получаю в браузере обновленный код, без перезагрузки страницы. А поскольку архитектура React/Redux предполагает разделение кода и данных, то при такой замене кода «на горячую», даже не теряется состояние моих компонентов. Это очень круто и дает 100% буста продуктивности.
О, замечательная штука. Меня правда больше заинтересовал Draft.js сейчас фейсбучный — т.к. он куда более примитивный, для образовательных целей больше подходит. В общем, щас буду думать, как такую механику взаимодействия реализовать для React-based редакторов, может это не так уж и сложно, как кажется. Потому что очень хочется перейти на VirtualDOM и иммутабельность состояния — плюсы от этого перевешивают все минусы, когда речь заходит о такой сложной вещи, как современные контент-редакторы.
Насчет телефонов я с вами согласен. Я вообще телефон не использую уже пару лет как — не хочу кормить зажравшихся операторов связи, которые отчаянно не хотят быть просто «трубой для данных», и ведут себя как цыгане на рынке, пытаясь обобрать пользователя до последней копейки. Это не партнерство, это не сотрудничество — это воровство… И бороться с этим можно только прекратив эти «отношения». Но это так, оффтоп :)
Но если вы думаете, что концепция «функций как объектов первого класса (first class citizen)» и замыканий вам подобным образом чем-то навредит, обокрав ваше внимание и время — то это вы зря. Мне вот есть с чем сравнивать, могу вас уверить, что это вас только обогатит, сократив ваши трудозатраты. Ну это конечно, если вы собираетесь зарабатывать написанием кода. В ином случае вам это, действительно, не нужно...
По сравнению с реактом — это голый дом, т.к. к нему прямой доступ, оно работает напрямую с его узлами (без виртуальной прослойки). На реакте я такое не знаю как сделать, мне кажется это просто невозможно на данный момент. По поводу эксепшенов я хз, я это вообще не планировал публиковать пока что, пока не отвяжу это от проприетарных библиотек. Зря я ссылку выложил.
Practice makes perfect… Или «дорогу осилит идущий». Вы же просто не хотите идти.
Смешно как раз то, что от скобочек-то кровь из глаз и течет, а вы это «приятным синтаксисом» называете. Вспоминается автомобиль Гомера Симпсона сразу.
Это просто SerafimArts панику наводит. На самом деле это не депрекейт, а просто обновляют черновик стандарта, и пока апдейт идет, из Babel временно убрали текущую реализацию (она доступна в виде внешнего плагина). Это нормальный процесс работы, и декораторы еще вернутся. Их уже юзают многие технологии популярные — например ангуляр2, mobx.
Я хаскеллом не обмазываюсь уже лет восемь, поэтому совершенно выпал из контекста — про ghcjs и purescript впервые слышу. Я про Elm-то узнал буквально на днях, когда узнавал откуда у React/Redux ноги растут. Даже не успел его попробовать толком.
И одновременно стало проще — но на другом уровне. Такой стек технологий ведь не просто так возник, это именно ответ на вызовы современности, это реакция на необходимость делать вещи, которые лет 5 назад были просто немыслимы из-за сложности реализации.
То есть оно «все усложнилось» разве что только в какой-то статичной системе отсчета… ну типа, если вы в 2016 все еще ориентируетесь на проекты уровня 2008 года, то это действительно кажется чем-то безумным. Я занимаюсь веб-фронтендом примерно с того года как раз, и прекрасно помню, как я тогда несколько недель (на голом DOM / HTML / CSS) возился с проектом, на который сегодня у меня ушел бы один рабочий день. Тогда просто не было таких инструментов.
На самом деле, код на jQuery намного дороже. Это примерно как лечить зубы у плохого стоматолога. Вроде бы дешевле, но выходит что дороже. И потерянное время вам никто не вернет.
И оправдано это именно в мегапроектах типа Фейсбука. У них тысячи компонентов, миллионы строк кода. Для маленьких же сайтов-визиток, конечно же, лучше использовать jQuery. Или вообще голый DOM (в jQuery смысла не очень много с появлением нативных селекторов).