Попробуйте включить опцию DNT (Do Not Track), Честные сервисы аналитики учитывают ее, а так же можно включить блокирование сторонних кукисов. Как результат — меньше мусора в истории и гугловая реклама не предлагает ничего из того, что ты посещал или гуглил. Для этого нету необходимости ставить сторонние плагины.
Да, это хороший подход, но и он не спасает от проблем. Время идет, техники меняются, то что раньше было спасением, сейчас плохая практика.
В случае с babel уже нету особо смысла в стандарт языка что-то добавлять. Хочешь использовать какую-то фичу — ставишь как плагин к babel, а дальше транслируешь в ES5. Смысл расширять стандарт, если все и так будет транслироваться в ES5?
На данный момент, я считаю, что все новые фичи должны добавляться только через новые api, а не через расширение языка.
Вы не на том делаете акцент. Основная идея в том, что фича в язык добавляется просто, а последствия этого добавления можно выгребать очень-очень долго, именно потому, что никто не выкидывает фичи из языков.
По правде говоря, в историю языков программирования я не сильно углублялся, может и есть. По большей части мой комментарий можно считать гипотезой. Но в подтверждение этой гипотезы есть несколько фактов.
В языках есть фичи, которые негласно считаются плохими: assert, goto, множественное наследование. Их не используют (если по-хорошему), но язык обязан их поддерживать.
Если взять С++, фич у него невероятно много, по-моему, его можно считать одним из самых сложных, если не самым. Да, он жив и он развивается, но кто сейчас захочет его изучать? Когда есть D, Rust, Go, которые предоставляют примерно те же возможности но на много безопаснее и проще, там где нужно залезть глубже можно взять чистый Си, который довольно простой.
Вот только Future в Java имеются еще с версии 1.5 (2004 год). И заменять на async/await, к счастью, не спешат, есть вещи по-важнее.
К сожалению, синтаксический сахар в языках программирования — это плохая идея. Как модная фича — это выглядит круто, но если смотреть на возможности дальнейшего развития языка, каждая языковая фича является якорем, который тянет на дно. Языки, в которых миллион клевых фич очень тяжело выучить, еще тяжелее развивать и поддерживать. И рано или поздно язык достигнет точки в которой он перестанет развиваться или выкинет обратную совместимость и кучу фич, которые у него были.
Для индивидуального разработчика 150$ в год. Это примерно 10$ в месяц. Разве это большая цена за инструмент, который позволяет продуктивнее работать?
Да, корпоративная лицензия стоит дороже и многие корпорации не сильно спешат вкладывать в качество кода, но это уже проблема менеджмента компании. Дополнительные 40-50$ в месяц на одного сотрудника — это не такие и большие деньги, за инструмент, который на порядок уменьшит количество багов и времени потраченного на их поиск и исправления (а это отсутствие сорванных дедлайнов и своевременная поставка).
Спасибо за добавленные JMH тесты, выглядит лучше. Но попробуйте поменять единицы измерения на op/sec, это будет нагляднее при данного рода тестах.
Как вариант, можно еще добавить столбец сравнения с LinkedList (на него будет ориентир при вставках в начало и середину).
Вы в одном тесте замеряете время доступа по индексу, вставку, удаление одновременно. Вместе с этим вы замеряете время работы генерации псевдослучайных чисел.
Как минимум операции доступа и изменения коллекции нужно разбить на разные тесты. Доступ по индексу однозначно будет в разы хуже, чем в ArrayList, т.к. вместо 1 операции взятия элемента из массива, нужно будет сначала из индекса (data) взять данные, и лишь потом из elementData.
И как советовали выше, используйте JMH для тестов.
Идеальный ответ: «Depends on...», — ведь может быть очень много дополнительных условий. К примеру на html это описывается одним тегом без какого-либо кода.
Открытие окна это побочный эффект. ФП говорит, что побочные эффекты — это очень плохо и функции должны быть чистыми. И тут мы становимся перед выбором использовать ФП и нарушать его концепции или использовать ООП.
Тут дело не в шаблонах, скорее язык выбран не правильно; см. «2. Язык, на котором вы написали код, должен выглядеть как будто его создали для решения этой проблемы.»
Решаете функциональную задачу — берите ФП с его паттернами, если же вам нужно решить задачу с изменением глобального состояния — берите ООП с присущими ему паттернами. В противном случае код будет всегда смотреться плохо и излишне усложненным.
Это все хорошие принципы, но никогда не стоит возводить их в абсолют, нужно всегда умело жонглировать ими.
К примеру, «3. Не нужно избыточности» и «6. Нужно минимизировать зависимости» противоречат друг другу.
Первый гласит про DRY принцип, возводя его в абсолют мы получаем множество маленьких кусочков кода, тем самым увеличиваем количество зависимостей. Тот же модуль isArray в npm, с одной стороны хорошо мы не дублируем код, с другой стороны у нас появляется новая зависимость.
Следующим шагом должен быть репозиторий шаблонных проектов.
Запускаешь команду create-elm-app my-webapp --blueprint:full-stack-webapp и получаешь уже готовый шаблон проекта для фулл-стек разработки, который можно сразу же запустить и попробовать на деле.
Спасибо за ссылки. Впечатление, что все эти библиотеки просто были списаны с одного примера и портированы на разные языки.
Но это уже пошел оффтоп. Моя позиция была в том, что такой подход используется в довольно популярных фреймворках и решение по $x = f(), где function f():void, вполне могут быть обоснованы обратной совместимостью.
Так же, я считаю, что в этом случае должна быть какая-то опция, чтобы можно было контролировать уровень ошибки для такого кода: игнорить, ворнинг, эррор, со значением «ворнинг» по-умолчанию.
Посмотрел на WSGI и Rack (остальных не нашел), выглядит действительно не плохо! Но, как мне показалось, это то как на пхп писали еще лет 10 назад. Обработчик запроса, который устанавливает код ответа, хедеры и контент, и все это в одном месте. Для этого в пхп и фреймворки не нужны.
Описанный мною подход — это крайне упрощенный JAX-RS.
На выходе получается крайне простой и самодокументированный код, который не требует пояснений, который не содержит смеси бизнес-логики и формирования конента.
ps: вот пример из мира PHP, чтобы не было притензий, что я с монстроузорной java лезу тут: https://laravel.com/docs/5.3/routing
Фреймворк роутинга, который маппит HttpMethod + PATH [+MimeType] на функцию обработки.
Функция возвращает Объект, этот объект потом превращается в контент (к примеру в json или xml).
Функция может вернуть int, string, number, Object, null.
Пока не было типов функция могла ничего не возвращать, а просто записать что-то в хедеры и/или установить статус.
Черт! А я книгу в телефоне читаю, чтобы скоротать время :-(
В случае с babel уже нету особо смысла в стандарт языка что-то добавлять. Хочешь использовать какую-то фичу — ставишь как плагин к babel, а дальше транслируешь в ES5. Смысл расширять стандарт, если все и так будет транслироваться в ES5?
На данный момент, я считаю, что все новые фичи должны добавляться только через новые api, а не через расширение языка.
В языках есть фичи, которые негласно считаются плохими: assert, goto, множественное наследование. Их не используют (если по-хорошему), но язык обязан их поддерживать.
Если взять С++, фич у него невероятно много, по-моему, его можно считать одним из самых сложных, если не самым. Да, он жив и он развивается, но кто сейчас захочет его изучать? Когда есть D, Rust, Go, которые предоставляют примерно те же возможности но на много безопаснее и проще, там где нужно залезть глубже можно взять чистый Си, который довольно простой.
К сожалению, синтаксический сахар в языках программирования — это плохая идея. Как модная фича — это выглядит круто, но если смотреть на возможности дальнейшего развития языка, каждая языковая фича является якорем, который тянет на дно. Языки, в которых миллион клевых фич очень тяжело выучить, еще тяжелее развивать и поддерживать. И рано или поздно язык достигнет точки в которой он перестанет развиваться или выкинет обратную совместимость и кучу фич, которые у него были.
Да, корпоративная лицензия стоит дороже и многие корпорации не сильно спешат вкладывать в качество кода, но это уже проблема менеджмента компании. Дополнительные 40-50$ в месяц на одного сотрудника — это не такие и большие деньги, за инструмент, который на порядок уменьшит количество багов и времени потраченного на их поиск и исправления (а это отсутствие сорванных дедлайнов и своевременная поставка).
Как вариант, можно еще добавить столбец сравнения с LinkedList (на него будет ориентир при вставках в начало и середину).
Как минимум операции доступа и изменения коллекции нужно разбить на разные тесты. Доступ по индексу однозначно будет в разы хуже, чем в ArrayList, т.к. вместо 1 операции взятия элемента из массива, нужно будет сначала из индекса (data) взять данные, и лишь потом из elementData.
И как советовали выше, используйте JMH для тестов.
> Oracle больше не делает ставку на Java.
Речь ведь про Java EE, может все же стоит сделать это уточнение в первом же предложении?
Открытие окна это побочный эффект. ФП говорит, что побочные эффекты — это очень плохо и функции должны быть чистыми. И тут мы становимся перед выбором использовать ФП и нарушать его концепции или использовать ООП.
Решаете функциональную задачу — берите ФП с его паттернами, если же вам нужно решить задачу с изменением глобального состояния — берите ООП с присущими ему паттернами. В противном случае код будет всегда смотреться плохо и излишне усложненным.
К примеру, «3. Не нужно избыточности» и «6. Нужно минимизировать зависимости» противоречат друг другу.
Первый гласит про DRY принцип, возводя его в абсолют мы получаем множество маленьких кусочков кода, тем самым увеличиваем количество зависимостей. Тот же модуль isArray в npm, с одной стороны хорошо мы не дублируем код, с другой стороны у нас появляется новая зависимость.
Запускаешь команду create-elm-app my-webapp --blueprint:full-stack-webapp и получаешь уже готовый шаблон проекта для фулл-стек разработки, который можно сразу же запустить и попробовать на деле.
Но это уже пошел оффтоп. Моя позиция была в том, что такой подход используется в довольно популярных фреймворках и решение по $x = f(), где function f():void, вполне могут быть обоснованы обратной совместимостью.
Так же, я считаю, что в этом случае должна быть какая-то опция, чтобы можно было контролировать уровень ошибки для такого кода: игнорить, ворнинг, эррор, со значением «ворнинг» по-умолчанию.
Описанный мною подход — это крайне упрощенный JAX-RS.
На выходе получается крайне простой и самодокументированный код, который не требует пояснений, который не содержит смеси бизнес-логики и формирования конента.
ps: вот пример из мира PHP, чтобы не было притензий, что я с монстроузорной java лезу тут: https://laravel.com/docs/5.3/routing
Функция возвращает Объект, этот объект потом превращается в контент (к примеру в json или xml).
Функция может вернуть int, string, number, Object, null.
Пока не было типов функция могла ничего не возвращать, а просто записать что-то в хедеры и/или установить статус.