Краткая выжимка из статьи: возможность писать любые типы данных в одну переменную затруднит отладку. Языки не отличающиеся высокой производительностью кода априори плохие.
Очень узкий обзор в плане применения языков. Контраргументы не рассмотрены вообще. Зачем я вообще это читал...
А насчёт языка для новичков. Я бы порекомендовал, например, встроенные скриптовые языки в любимых компьютерных играх, или например язык любимого опенсорс софта, куда можно законтрибутить какие-то полезные изменения (или другими словами то, что изначально кажется интересным). Прекрасно прокачивает базовые навыки, так как мотивация как правило и так хлещет через край. А дальше и на что-то более практичное можно будет переключиться.
Я, например, в детстве начал с Бейсика (встроен в zx spectrum) и довольно быстро переключился на ассемблер (на спектруме других классных альтернатив не было). Меня сильно забавляло делать разные графические и звуковые эффекты и менять/изучать код игр (благо встроенный в ПЗУ дизассемблер позволял творить чудеса). Так что в университете были моменты, когда не преподаватели учили меня а я их. Также как и была вполне приличная работа начиная где-то с 3го курса.
Искал такой коммент перед тем как написать свой такой же :) но теперь нет необходимости писать.
А вообще при прочтении первых строк статьи сразу подумалось о линуксовых /dev /sys /proc и прочих подобных. Автору видимо ещё многому предстоит научиться. Не умеет мыслить абстрактно.
Тоже склоняюсь к тому, что прогноз вполне реальный. Научные открытия делаются каждый день. И то, что вчера казалось невозможным с текущим трендом развития технологий, сегодня кажется уже более чем возможным.
Взять, например, квантовые компьютеры или недавно обнародованные исследования по выращиванию из стволовых клеток и обучению человеческого мозга "в пробирке", который обучается куда эффективнее имеющихся нейронных сетей. И таких открытий будет сделано огромное множество в ближайшее время. Всё это очень сильно ускорит развитие ИИ. Ускорит на столько на сколько нам сейчас сложно представить.
Симпатичный плеер-агрегатор облачной музыки с возможностью кэширования любимых произведений/альбомов а также умной (AI) подборкой оных, с более качественной интеграцией в систему (например MPRIS под линукс, интеграция с системными десктоп виджетами, синхронизация с подключенными мобильными девайсами, возможность управления с пульта и другими альтернативными способами и тд и тп), кучей плагинов как обычно на любой вкус и цвет, социальная интеграция (аля пошарь песню/альбом/всю коллекцию с другом).
Я бы заинсталил такой, если запилят под линукс. И судя по тому что ищут бэкэндщиков, наверное стоит ожидать чего-то интересного.
Есть проекты, где сэкономленные такты имеют значение. Взять тот же крипто майнинг или какое-нибудь потоковое шифрование/кодирование.
Но если есть возможность писать с первого взгляда понятный код — надо именно так и делать.
no es la primera vez cuando escucho sobre chile como un país muy desarrollado de toda america latina. Te envidio un poco. :-) Espero moverme algun día ahí tambien.
Так я и говорю, если правильно приложить к этому руки, то к продукту и люди потянутся и со временем превратят его в стандарт. И тогда, конечно, выпуск новой версии скажем раз в год строго с определенным тулчейном и определенной версией Qt — лучше чем клепать 100500 рантаймов. И вопрос портабельости в этом случае вполне решаем до определенной степени.
Насчет студийных рантаймов, это очень странно что MS не может решить эту проблему по-человечески много лет. Давно могли бы сделать (полу-)автоматическую установку.
А насчет размера бинарей. Я догадываюсь вряд ли количество подобных утилит дотянет в сумме до внушительных гигабайтов. А если и дотянет, то видимо время задуматься о выпуске пакета утилит с одним набором библиотек.
Я было подумал пост десятилетней давности, присмотрелся, нет свежий. Не понимаю зачем так экономить когда речь по большому счету не идет об embedded системах.
Лучше вложить свои силы создание красивого, правильного и простого установщика Qt runtime на системы где с этим туго. А для проектов побольше можно даже попробовать научить приложение дергать сей установщик, дабы подтянул необходимые компоненты.
В общем время — это деньги. И нужно всегда искать баланс на потери времени на разработке или дальнейшей поддержке (дальнейшей доработке другими программистами).
К тому же изначально писать досконально продуманный, качественный продукт — зло, ибо требования часто меняются как и происходит переосмысление дизайна продукта.
Краткая выжимка из статьи: возможность писать любые типы данных в одну переменную затруднит отладку. Языки не отличающиеся высокой производительностью кода априори плохие.
Очень узкий обзор в плане применения языков. Контраргументы не рассмотрены вообще. Зачем я вообще это читал...
А насчёт языка для новичков. Я бы порекомендовал, например, встроенные скриптовые языки в любимых компьютерных играх, или например язык любимого опенсорс софта, куда можно законтрибутить какие-то полезные изменения (или другими словами то, что изначально кажется интересным). Прекрасно прокачивает базовые навыки, так как мотивация как правило и так хлещет через край. А дальше и на что-то более практичное можно будет переключиться.
Я, например, в детстве начал с Бейсика (встроен в zx spectrum) и довольно быстро переключился на ассемблер (на спектруме других классных альтернатив не было). Меня сильно забавляло делать разные графические и звуковые эффекты и менять/изучать код игр (благо встроенный в ПЗУ дизассемблер позволял творить чудеса). Так что в университете были моменты, когда не преподаватели учили меня а я их. Также как и была вполне приличная работа начиная где-то с 3го курса.
Искал такой коммент перед тем как написать свой такой же :) но теперь нет необходимости писать.
А вообще при прочтении первых строк статьи сразу подумалось о линуксовых /dev /sys /proc и прочих подобных. Автору видимо ещё многому предстоит научиться. Не умеет мыслить абстрактно.
Думаю, надёжнее было бы заблокировать интернет в стране.
Тоже склоняюсь к тому, что прогноз вполне реальный. Научные открытия делаются каждый день. И то, что вчера казалось невозможным с текущим трендом развития технологий, сегодня кажется уже более чем возможным.
Взять, например, квантовые компьютеры или недавно обнародованные исследования по выращиванию из стволовых клеток и обучению человеческого мозга "в пробирке", который обучается куда эффективнее имеющихся нейронных сетей. И таких открытий будет сделано огромное множество в ближайшее время. Всё это очень сильно ускорит развитие ИИ. Ускорит на столько на сколько нам сейчас сложно представить.
Симпатичный плеер-агрегатор облачной музыки с возможностью кэширования любимых произведений/альбомов а также умной (AI) подборкой оных, с более качественной интеграцией в систему (например MPRIS под линукс, интеграция с системными десктоп виджетами, синхронизация с подключенными мобильными девайсами, возможность управления с пульта и другими альтернативными способами и тд и тп), кучей плагинов как обычно на любой вкус и цвет, социальная интеграция (аля пошарь песню/альбом/всю коллекцию с другом).
Я бы заинсталил такой, если запилят под линукс.
И судя по тому что ищут бэкэндщиков, наверное стоит ожидать чего-то интересного.
Но если есть возможность писать с первого взгляда понятный код — надо именно так и делать.
Насчет студийных рантаймов, это очень странно что MS не может решить эту проблему по-человечески много лет. Давно могли бы сделать (полу-)автоматическую установку.
А насчет размера бинарей. Я догадываюсь вряд ли количество подобных утилит дотянет в сумме до внушительных гигабайтов. А если и дотянет, то видимо время задуматься о выпуске пакета утилит с одним набором библиотек.
Лучше вложить свои силы создание красивого, правильного и простого установщика Qt runtime на системы где с этим туго. А для проектов побольше можно даже попробовать научить приложение дергать сей установщик, дабы подтянул необходимые компоненты.
UPD: хотя тогда я рассматривал всё только с точки зрения подчиненного.
автору респект!
В общем время — это деньги. И нужно всегда искать баланс на потери времени на разработке или дальнейшей поддержке (дальнейшей доработке другими программистами).
К тому же изначально писать досконально продуманный, качественный продукт — зло, ибо требования часто меняются как и происходит переосмысление дизайна продукта.