Java-код пишу в Idea, но мне вот лично неудобно писать фронтенд в ней (пишу всё в Atom'е).
Основные причины: медленная скорость и низкая отзывчивость интерфейса и
не всегда можно настроить проект и всякие пути в нём так, чтобы не было предупреждений или ошибок. Например, я поставил ангуляр через npm. Подключаю его через es6 import: import angular from 'angular'; Ещё я использую webpack и хочу подключить бутстраповский less в свой: @import "~bootstrap/less/bootstrap"; Вот что в итоге:
картинки
Мелочь, но неприятно.
В итоге, так или иначе приходится работать в консольке. Например, мне удобнее набрать npm i -S some-module нежели делать это через GUI Идеи.
Для запуска/сборки/тестов достаточно настроить секцию scripts в package.json и запускать нужное командой npm run %имя_задачи%.
Компиляция (в том числе в live-режиме) less/sass/ts/coffee/es2015 и т.д. настраивается в сборщиках/бандлерах, что заменяет file watchers в идее.
В итоге, я просто настраиваю webpack на разные окружения. В dev-режиме у меня запущен dev-server, который при изменении файлов пересобирает проект (вернее, только необходимые кусочки, вебпак круто отслеживает зависимости) и перегружает страницу (или её кусок) в браузере. Для prod добавляются всякие минимизаторы, префиксеры и т.д.
Сборка/запуск тестов запускается одной командой.
Ну а всякие плюшки, типа stylecheck, linters и др. есть и в атоме. Да, нет такого же автодополнения, как в идее. Но и без него нормально живётся.
Это вы не видели ещё формулу Эйлера, там вообще показатели степени мнимые.
Собственно, эта формула и позволяет расширить тригонометрические функции на комплексную плоскость.
Но лучше всего прослушать лекции по матанализу и теории функции комплексного переменного в каком-нибудь ВУЗе.
Если нужно подключить пару jquery-плагинов на страницу и суммарный объем js-кода небольшой, то это нормально. Как только проект побольше, то без полезных инструментов разрабатывать и поддерживать его становится намного сложнее. А тенденции нынче идут в сторону сложного фронтенда...
На мой взгляд, именно эта возможность является необходимой и достаточной для существования самообучающихся программ
Вместо пустых и довольно глупых заявлений лучше почитайте про нейронные сети, например. Для обучения необходимы данные. При чём тут исходный алгоритм самой программы? Если же рассматривать саму программу, как данные, то обучение может привести лишь к оптимизации самой программы. Но все компиляторы это и так умеют. А JIT-компиляторы делают это как раз в рантайме.
К слову, нейронные сети, как пример обучающихся программ, можно реализовать даже на языках, где из коробки нет AST-преобразований в рантайме. Например, на C.
Модель памяти в java — вот это сложно. Но при этом несёт большую практическую пользу.
А придумать какую-то якобы фичу (бесполезную с практической точки зрения) и с трудом её реализовывать — как-то глупо. Вон на Malbolge тоже трудно программы писать.
Вам написали кучу комментов со вполне конструктивной критикой. Если вы ожидали похвал, то неудивительно, что эта критика не воспринялась.
Ну а в написании своего языка нет ничего сложного. Другой вопрос, зачем это делать? Новые языки, которые реально полезны, разрабатывают обычно для какой-то конкретной цели. Разрабатывать язык ради самой разработки хорошо только для самообразования (и то не всегда).
Ещё вспомнился давний пост на хабре, где FB превозмогал ограничения андроида на количество классов. Вот только они в своё приложение хотели запихнуть почти всё (помню оно ужасно тормозило и выжирало кучу памяти, так что я его снёс и больше не трогал). При этом, приложение ВК с почти аналогичным функционалом работало отлично.
Опять сами создали себе проблему и опять героически боролись с ней. Ну хоть делом заняты…
Например, почему от вьюх идут стрелки к моделям, хотя должны идти к контроллерам? Ну и вообще, почему на второй картинке остался только 1 View? Будь их там побольше, оно выглядело бы так же запутанно.
В итоге они взяли всё тот же MVC (одну из вариаций), только назвали его по-другому.
Может я что-то не понимаю, но в чём отличие от флакса от классического MVC? Там модель содержит всю логику и оповещает подписавшиеся на неё вьюхи о изменениях в своих данных. Там почти такой же однонаправленный поток данных: от модели ко вьюхам. Никакого двунаправленного связывания, от которого многие не в восторге. А действия пользователя всё так же идут от вью через контроллеры к моделям (или другим контроллерам).
Да и автор, по-сути, опять пересказал старый добрый MVC.
Расскажите автору про Object.assign() или какой-нибудь другой способ слияния объектов. А то трудно серьёзно воспринимать человека, который ещё пишет как на рисунке 1.
Критика вполне обоснованная.
Задача изначально не для юзкейса ангуляра, т.к. все шаблоны и так грузятся с сервера. Да и сам по себе ангуляр — фреймворк для построения сложных MV*-приложений на фронтенде, а не либа для биндинга атрибутов.
Но нет, это не Вы не умеете инструмент выбирать, а это ангуляр плохой. У него сразу же нашлись недостатки, которых в реальной жизни нет, просто нужно поизучать ангуляр чуть больше 1-го дня.
И тут же началась борьба против ветряных мельниц, которые сами себе и воздвигли. И вместо того, чтобы взять какой-нибудь jquery/knockout и написать всё быстренько на нём, зачем-то началось велосипедостроение.
Просто когда человек сам ошибся в выборе технологии, но винит её, а не себя, о нём сразу складывается негативное впечатление.
А из статьи я так и не понял, зачем оно и что делает, что рендерит yii, а что подгружается аяксом, и т.д.
зачем вообще AngularLight или vue.js, если есть Angular?
Просто не всем нужны DI и сервисный слой.
Проблема в том, что записи добавляются/изменяются динамически через ajax-запросы. Каким будет ваше решение?
При изменении/добавлении записи выставляем флаг, что началась загрузка и отправляем запрос к API. После получения ответа убираем флаг и обновляем данные в контроллере.
Основные причины: медленная скорость и низкая отзывчивость интерфейса и
не всегда можно настроить проект и всякие пути в нём так, чтобы не было предупреждений или ошибок. Например, я поставил ангуляр через npm. Подключаю его через es6 import:
import angular from 'angular';
Ещё я использую webpack и хочу подключить бутстраповский less в свой:@import "~bootstrap/less/bootstrap";
Вот что в итоге:Мелочь, но неприятно.
В итоге, так или иначе приходится работать в консольке. Например, мне удобнее набрать
npm i -S some-module
нежели делать это через GUI Идеи.Для запуска/сборки/тестов достаточно настроить секцию scripts в package.json и запускать нужное командой
npm run %имя_задачи%
.Компиляция (в том числе в live-режиме) less/sass/ts/coffee/es2015 и т.д. настраивается в сборщиках/бандлерах, что заменяет file watchers в идее.
В итоге, я просто настраиваю webpack на разные окружения. В dev-режиме у меня запущен dev-server, который при изменении файлов пересобирает проект (вернее, только необходимые кусочки, вебпак круто отслеживает зависимости) и перегружает страницу (или её кусок) в браузере. Для prod добавляются всякие минимизаторы, префиксеры и т.д.
Сборка/запуск тестов запускается одной командой.
Ну а всякие плюшки, типа stylecheck, linters и др. есть и в атоме. Да, нет такого же автодополнения, как в идее. Но и без него нормально живётся.
Потом стоит взяться за ТФКП.
Собственно, эта формула и позволяет расширить тригонометрические функции на комплексную плоскость.
Но лучше всего прослушать лекции по матанализу и теории функции комплексного переменного в каком-нибудь ВУЗе.
Даже если три точки лежат на одной прямой?
Но это уже другая задача из немного другой области математики.
ТЗ нужно утверждать предварительно, чтобы не было такого.
Вместо пустых и довольно глупых заявлений лучше почитайте про нейронные сети, например. Для обучения необходимы данные. При чём тут исходный алгоритм самой программы? Если же рассматривать саму программу, как данные, то обучение может привести лишь к оптимизации самой программы. Но все компиляторы это и так умеют. А JIT-компиляторы делают это как раз в рантайме.
К слову, нейронные сети, как пример обучающихся программ, можно реализовать даже на языках, где из коробки нет AST-преобразований в рантайме. Например, на C.
А придумать какую-то якобы фичу (бесполезную с практической точки зрения) и с трудом её реализовывать — как-то глупо. Вон на Malbolge тоже трудно программы писать.
Да, а сервисный слой — это что?
Ну а в написании своего языка нет ничего сложного. Другой вопрос, зачем это делать? Новые языки, которые реально полезны, разрабатывают обычно для какой-то конкретной цели. Разрабатывать язык ради самой разработки хорошо только для самообразования (и то не всегда).
Опять сами создали себе проблему и опять героически боролись с ней. Ну хоть делом заняты…
Например, почему от вьюх идут стрелки к моделям, хотя должны идти к контроллерам? Ну и вообще, почему на второй картинке остался только 1 View? Будь их там побольше, оно выглядело бы так же запутанно.
В итоге они взяли всё тот же MVC (одну из вариаций), только назвали его по-другому.
Может я что-то не понимаю, но в чём отличие от флакса от классического MVC? Там модель содержит всю логику и оповещает подписавшиеся на неё вьюхи о изменениях в своих данных. Там почти такой же однонаправленный поток данных: от модели ко вьюхам. Никакого двунаправленного связывания, от которого многие не в восторге. А действия пользователя всё так же идут от вью через контроллеры к моделям (или другим контроллерам).
Да и автор, по-сути, опять пересказал старый добрый MVC.
Ну и второй коммент в этой статье доставляет)
Ну прям ужасно увеличивает
Много элементов в массиве? Серверная пагинация в помощь.
Задача изначально не для юзкейса ангуляра, т.к. все шаблоны и так грузятся с сервера. Да и сам по себе ангуляр — фреймворк для построения сложных MV*-приложений на фронтенде, а не либа для биндинга атрибутов.
Но нет, это не Вы не умеете инструмент выбирать, а это ангуляр плохой. У него сразу же нашлись недостатки, которых в реальной жизни нет, просто нужно поизучать ангуляр чуть больше 1-го дня.
И тут же началась борьба против ветряных мельниц, которые сами себе и воздвигли. И вместо того, чтобы взять какой-нибудь jquery/knockout и написать всё быстренько на нём, зачем-то началось велосипедостроение.
Просто когда человек сам ошибся в выборе технологии, но винит её, а не себя, о нём сразу складывается негативное впечатление.
А из статьи я так и не понял, зачем оно и что делает, что рендерит yii, а что подгружается аяксом, и т.д.
Просто не всем нужны DI и сервисный слой.
При изменении/добавлении записи выставляем флаг, что началась загрузка и отправляем запрос к API. После получения ответа убираем флаг и обновляем данные в контроллере.