Хотя если он вам так нужен, тогда о каком Vue может идти речь? Поддержка TS там ± такая же как в Svelte.
TypeScript — это не синтаксический сахар для корпораций, это автоматизация работы/тестирования, статический анализ, вместе с Реактом шел Flow, а затем и полноценная поддержка TS.
Писать на чистом JavaScript в 2020 — это откат назад, в прошлое, где нужно проверять типы руками и писать тесты там, где TS покрывает этот код автоматически, синтаксисом.
Та же проблема с Angular и шаблонами в нем, с учетом директив, пайпов и всего того, что можно засунуть в шаблон — это нереальная боль. С другой стороны во всем остальном, Angular полностью поддерживает TS.
Последняя версия Vue достаточно хорошо поддерживает типизацию из коробки, но до Реакта далеко.
Конечно, есть инструменты для статического анализа и шаблонов ангуляра и Svelte, но говорить в 2020 году, что статическая типизация во Frontend только для корпораций — это провокация или глупость.
Где люди жили в мире и согласии, защищенные законами и государствами тех стран, устройство которых они критиковали и прогрессом, технологиями человечества, которое неправильно устроено и развивается?
Довольно часто наблюдается такая картинка: кредит на айфон, кредит на холодильник, кредит на X,Y,Z и жизнь впроголодь. В России, например, статистика закредитованность населения скорее говорит о низкой финансовой грамотности.
Вопрос, что важнее иметь айфон X или качественную еду уже не стоит.
Каждый знает, что если долго поднимать тяжести, то без должной подготовки (или даже с ней) гарантировано получишь проблемы со спиной и суставами. То же самое можно сказать про мозг, только это менее очевидно. Наша работа требует высокой отдачи и концентрации, даже если мы всего-лишь рефачим тесты на автомате, слушая в фоне очередной разведопрос. Мне кажется, что мозг просто не предназначен для таких ежедневных подвигов. Я работал на разных дерьмовых работах, в том числе физических и могу сказать, что я нигде не чувствовал себя настолько выжатым и разбитым, как выходя каждый день из офиса. Многие мои коллеги 35+ чувствуют примерно тоже самое, а на форумах начали появляться вопросы “Что делать, если тебе 25 и ты выгорел?” или “Как выйти из айти?”. Как долго удастся протянуть в таком режиме — вопрос интересный.
Рекомендую посмотреть видео доктора биологических наук МГУ и профессора Вячеслава Дубынина "Нейросети не хотят стареть".
Он рассказывает абсолютно о противоположном, чтобы избежать деменции и паркинсонизма нужно интересоваться как можно больше разными вещами и максимально избегать рутинной работы (один ЯП и 2 библиотеки).
А какая может быть цель у «редакторов», раньше то основной мотивацией было возвышение над другими, а тут о них никто ничего не знает и даже запрещено знать? Ну еще возможна идея рабства, но тут тоже непонятно, что за рабство, электричество вырабатывать, как в матрице?
Идея наказания за изучения законов бытия из Стругацких «Миллиард лет до конца света»? Типа, мы создали автоматически работающую систему, чтобы спасти человечество и все живое от вымирания и она предотвращает любые ведущие к этому шаги?
В случае класса со свойствами (или глобальными переменными, или переменными модуля), мы даем имя этим переменным и складываем туда результат вычислений. В случае ФП — это всегда константы, т.е. мы можем «сохранить» результат вычислений с помощью каррирования и дать на него ссылку, но не можем подменить находящееся там значение. В этом есть свои плюсы и минусы. Для программ с большим числом вычислений и малым хранилищем (по времени), это позволяет писать чистые функции, не беспокоясь, что кто-то где-то как-то подменит значение, не нужно мокать для тестов глобальные объекты, объекты по ссылкам и т.д.
Однако, для программ с необходимостью хранения множества объектов с часто изменяющимся внутренним состоянием — удобнее, когда имя дается один раз, а значения под этим именем меняются.
Это как если бы мы дали одно и то же название любому каррированию этой конкретной функции, вне зависимости от аргументов. Чего мы сделать в ФП не можем, да и зачем.
Наверное тем, что каррированию, как хранилищу, нельзя дать имя, реализовать синглтон с произвольной точкой доступа таким образом тоже невозможно. В итоге все равно все сводится либо к прокидыванию аргументов через всю цепочку вызовов, либо к прокидыванию ссылки на именованное хранилище.
ООП не обязано, в отличии от ФП, быть деревом, оно может быть любым видом графа, а в случае метапрограммирования, еще и многомерным. (В функциональный Реакт это заставляет вводить Context, в дополнение к глобальному стору).
Если копнуть глубже, то видно, что особой разницы между ООП и ФП нет. ООП — практически то же, что и ФП.
В ФП данные и функции существуют отдельно.
В примере из статьи, ООП написано как ФП, поэтому не нашлось разницы.
На самом деле в описанном классе не хватает тех самых данных, которые будут отличать ООП от ФП, а конкретно — можно закешировать внутри объекта результаты вычислений радиуса. Именно это является ключевым отличием, а не синтаксис. В ФП нет таких отдельных маленьких сущностей с состоянием, его приходится хранить отдельно в глобальных структурах и прокидывать для вычислений внутрь каждой функции.
Конечно, если у нас в программе нет закешированных данных и есть лишь небольшой объем входных, т.е. каждое значение мы считаем заново, то использовать парадигмы, предназначенные для кеширования результатов вычисления глупо.
Например, во фронтенде сейчас это прекрасно видно на примере React+Redux, когда Store становится большим, он становится поистине God-object и весь выигрыш в чистых функциях и едином месте, где видно состояние всего приложения пропадает.
А когда в дело вступает многопоточность — идея глобальных хранилищ начинает еще сильнее трещать по швам, в случае редакса опять же прекрасно видно на примере асинхронных экшнов.
Идея ООП хранить данные не в одном месте, а в виде графа, распределенного по всей программе не лучше и не хуже идеи хранить данные в одном месте.
Не нужна компиляция, но сейчас есть куча инструментов для запуска компилируемых языков на лету, тот же ts-node, в частности. В GoLang это идет из коробки go run.
Для чего нужно редактирование JSON? Странный вопрос, но ладно:
1. Редактирование файла-конфига
2. От API внешнего пришел ответ в виде JSON, иногда нужно лишнее убрать/изменить.
3. Свое тело запроса подготовить для Postman, к примеру.
Все это можно и в IDE делать или в консоли браузера, но тут такие возможности!
TypeScript — это не синтаксический сахар для корпораций, это автоматизация работы/тестирования, статический анализ, вместе с Реактом шел Flow, а затем и полноценная поддержка TS.
Писать на чистом JavaScript в 2020 — это откат назад, в прошлое, где нужно проверять типы руками и писать тесты там, где TS покрывает этот код автоматически, синтаксисом.
Та же проблема с Angular и шаблонами в нем, с учетом директив, пайпов и всего того, что можно засунуть в шаблон — это нереальная боль. С другой стороны во всем остальном, Angular полностью поддерживает TS.
Последняя версия Vue достаточно хорошо поддерживает типизацию из коробки, но до Реакта далеко.
Конечно, есть инструменты для статического анализа и шаблонов ангуляра и Svelte, но говорить в 2020 году, что статическая типизация во Frontend только для корпораций — это провокация или глупость.
Вопрос, что важнее иметь айфон X или качественную еду уже не стоит.
Рекомендую посмотреть видео доктора биологических наук МГУ и профессора Вячеслава Дубынина "Нейросети не хотят стареть".
Он рассказывает абсолютно о противоположном, чтобы избежать деменции и паркинсонизма нужно интересоваться как можно больше разными вещами и максимально избегать рутинной работы (один ЯП и 2 библиотеки).
Это уже не так.
Однако, для программ с необходимостью хранения множества объектов с часто изменяющимся внутренним состоянием — удобнее, когда имя дается один раз, а значения под этим именем меняются.
Это как если бы мы дали одно и то же название любому каррированию этой конкретной функции, вне зависимости от аргументов. Чего мы сделать в ФП не можем, да и зачем.
ООП не обязано, в отличии от ФП, быть деревом, оно может быть любым видом графа, а в случае метапрограммирования, еще и многомерным. (В функциональный Реакт это заставляет вводить Context, в дополнение к глобальному стору).
В примере из статьи, ООП написано как ФП, поэтому не нашлось разницы.
На самом деле в описанном классе не хватает тех самых данных, которые будут отличать ООП от ФП, а конкретно — можно закешировать внутри объекта результаты вычислений радиуса. Именно это является ключевым отличием, а не синтаксис. В ФП нет таких отдельных маленьких сущностей с состоянием, его приходится хранить отдельно в глобальных структурах и прокидывать для вычислений внутрь каждой функции.
Конечно, если у нас в программе нет закешированных данных и есть лишь небольшой объем входных, т.е. каждое значение мы считаем заново, то использовать парадигмы, предназначенные для кеширования результатов вычисления глупо.
Например, во фронтенде сейчас это прекрасно видно на примере React+Redux, когда Store становится большим, он становится поистине God-object и весь выигрыш в чистых функциях и едином месте, где видно состояние всего приложения пропадает.
А когда в дело вступает многопоточность — идея глобальных хранилищ начинает еще сильнее трещать по швам, в случае редакса опять же прекрасно видно на примере асинхронных экшнов.
Идея ООП хранить данные не в одном месте, а в виде графа, распределенного по всей программе не лучше и не хуже идеи хранить данные в одном месте.
1. Редактирование файла-конфига
2. От API внешнего пришел ответ в виде JSON, иногда нужно лишнее убрать/изменить.
3. Свое тело запроса подготовить для Postman, к примеру.
Все это можно и в IDE делать или в консоли браузера, но тут такие возможности!