Хорошее замечание. На мой взгляд, тут скорее математически неправильная трактовка понятия асимптота. Всё-таки появление нового оборудования, типа квантовых компьютеров, может принести что-то новое и в программирование, но процесс идёт крайне медленно…
Там список для демонстрации непонимания самого понятия «альтернатива» со стороны тех, кто слишком подвержен хайпу. Если вчитаетесь, заметите, что в этот список свалено всё в одну кучу.
Каждый стоящий новый язык тянет за собой новую парадигму.
А можно парочку примеров?
Инструменты должны изначально писаться не под конкретный язык, выделять свои функционально независимые блоки в отдельные взаимозаменяемые модули
Это да. Но поддержку нового языка всё равно надо будет дописать, при этом не факт, что язык позволит использовать возможности такой IDE в полной мере.
В целом я согласен, что развитие инструментов должно продолжаться и там до асимптоты ещё далеко.
Именно такие статьи и побудили меня перевести эту, когда я её увидел… Люди часто забывают, что любая технология — это всего лишь инструмент со своей областью применения. А если выбирать из 3 примерно одинаковых инструментов, то выбор получится чисто субъективный.
Да, у IDE на Java всегда были приличные требования к железу.
Я подумывал заменить пример на Visual Studio для C#, но всё-таки решил оставить как в оригинале.
Статья немного провокационная… Бывает по разному, переключаться между технологиями вполне допустимо, если от этого есть практическая выгода. А прыгать между примерно одинаковыми вариантами — это уже непрофессионально.
В Вашем же примере речь скорее не о переключении, а об изначальном выборе технологий для проекта. И тут уже Ваша задача как профессионала обосновать свой выбор заказчику, если для его проекта Java идеально подходит.
Ну что ж, радует, что есть какой-то прогресс и в этой области.
Расширение крутое, но будет лучше, когда подобные возможности появятся в самом языке. Это, кстати, хороший вариант и обратную совместимость сохранить ещё на пару версий и параллельно новую согласованную stdlib сделать.
Когда в Go дело доходит до использования сторонних библиотек, то ситуация становится гораздо печальнее, чем в Java. Куча библиотек, которые делают примерно одно и то же, приходится реально вчитываться в код каждой, чтобы сделать адекватный выбор.
Да что там библиотеки… Попробуйте для начала веб-фреймфорк выбрать: awesome-go#web-frameworks
Это понятно, про аббревиатуру я написал просто, чтобы подчеркнуть насколько давно на практике используется этот способ загрузки страницы. Ну а то, что его не патентовали… так что ж теперь каждый алгоритм патентовать?
А как им удалось это запатентовать то? Этой технологии уже 100 лет в обед… статья 2011 года, статья 2009 года и скорее всего и более ранние упоминания можно найти, ещё тех времён, когда аббревиатура AJAX в употребление ещё не вошла.
А кто говорил про остановку разработки… какая связь…
У вас если у провайдера авария и интернет отключился, то программисты домой уходят вместо того, чтобы продолжать работать? Если да, то вот это уже точно можно считать п-цом.
Вообще, я невнимательно прочитал комментарий Lertmind… и по сути ответил на цитату из ЖЖ, что не имело особого смысла.
Просто меня удивляют подобные формулировки… типа, если Github закроется (допустим не роскомнадзором, а сам по себе), то пи**ец всей отрасли… программисты работать сразу не смогут. Это ведь неправда.
И что? Вы каждый день обновляете/добавляете зависимости в проект?
Документация обычно ещё и локально сохраняется при установке пакетов.
Понятно, что ряд неудобств это несёт, но пару дней поработать даже без интернета вполне можно и вполне эффективно. А у минусующих, видимо, сильная гитхабозависимость и это повод задуматься…
Это да. Но поддержку нового языка всё равно надо будет дописать, при этом не факт, что язык позволит использовать возможности такой IDE в полной мере.
В целом я согласен, что развитие инструментов должно продолжаться и там до асимптоты ещё далеко.
Я подумывал заменить пример на Visual Studio для C#, но всё-таки решил оставить как в оригинале.
В Вашем же примере речь скорее не о переключении, а об изначальном выборе технологий для проекта. И тут уже Ваша задача как профессионала обосновать свой выбор заказчику, если для его проекта Java идеально подходит.
Расширение крутое, но будет лучше, когда подобные возможности появятся в самом языке. Это, кстати, хороший вариант и обратную совместимость сохранить ещё на пару версий и параллельно новую согласованную stdlib сделать.
Да что там библиотеки… Попробуйте для начала веб-фреймфорк выбрать: awesome-go#web-frameworks
пруф
статья 2011 года, статья 2009 года и скорее всего и более ранние упоминания можно найти, ещё тех времён, когда аббревиатура AJAX в употребление ещё не вошла.
У вас если у провайдера авария и интернет отключился, то программисты домой уходят вместо того, чтобы продолжать работать? Если да, то вот это уже точно можно считать п-цом.
Просто меня удивляют подобные формулировки… типа, если Github закроется (допустим не роскомнадзором, а сам по себе), то пи**ец всей отрасли… программисты работать сразу не смогут. Это ведь неправда.
Документация обычно ещё и локально сохраняется при установке пакетов.
Понятно, что ряд неудобств это несёт, но пару дней поработать даже без интернета вполне можно и вполне эффективно. А у минусующих, видимо, сильная гитхабозависимость и это повод задуматься…
По сути я написал то же самое :-)