Именно, самое главное замечание про него. Он перестал быть открытым и независимым. Да и при всех красивых словах практически все его публичные заявления некрасивы, всегда кого-то оскорбляют. Но это было нормально, когда он ругался на неквалифицированных программистов. А после его заявлений по национальному признаку уважение к нему сильно упало.
Ну так они на то и новые, первые полгода после выхода новый релиз трогать вообще не надо. Менять что-то надо, когда старое не поддерживает больше, вот с 20.04 перехожу на 22.04 плавно
Смысл музыки хэштеги и чтобы несколько нейронов пошевелить? Ну да, слова читать и понимать слишком сложно, а ноты вообще. Для фоновых звуков во время работы или отдыха примерно так, но вы же не ограничиваете и под это рассуждение всю музыку подгоняете.
Согласен. Диванные специалисты по ИИ пророчат, как изменится мир и всех захватят, только такой эксперт каждый второй школьник, хотя почему-то люди старше туда же. А недиванных специалистов, которые смотрят на это как на численную оптимизацию, матан, линейную алгебру и не вопят на каждом углу, не читают вот те "эксперты", сложно и непонятно, диванные не в курсе, как часто в нейронках хотя бы матрицы перемножаются. И тем более, как!
После того, как всякие такие навайбкодят, когда всё начнёт ломаться и трещать по швам, а починить они не смогут сами, настоящие нормальные программисты станут на порядки ценнее. Просто подождём.
Пик численных методов и математики тоже близок? В ИИ важнее не фреймворки и архитектура, а как просто матрицы множить численно устойчиво и быстро. Не надо называть численную оптимизацию сознанием просто. Её пика не предвидится, а пик хайпа на нейронках случится, как придёт новое, как нейро- заменило нано-.
Я и удивился перечислению numpy. А blas и lapack даже скорее фортрановские, больше f77. Но там не прям всё распараллелено, например, стандартный gemm нет. Можете убедиться в исходниках))
Расскажите, как это можно непосредственно применить для ускорения numpy, раз он стал потокобезопасен? И коснулся ли threading используемых blas и lapack? С какими сложностями пришлось столкнуться для numpy, scipy, pyarrow?
А с какого момента "чувак, который освоил ИИ" стало значить того, кто генерирует код нейронками, а не того, кто понимает ML, матан, линейную алгебру, численные методы и в состоянии реализовать многое с нуля, потому что понимает? Кажется, произошла подмена программиста пользователем.
Мне кажется, многое на деле проще. Под конкретную задачу выбор инструмента обычно легче сделать из логики проекта, а популярность инструментов тут неважна.
Если проект учебный, чтобы научиться чем-то пользователься, то выбор уже сделан. Если чтобы научиться что-то сделать (а не чем-то), то выбор сделан и состоит в том, чтобы попробовать разное и сравнить (в том числе под что способы ищутся легче).
Если речь о выборе чего-то для самого начала обучения, величина проблемы тоже преувеличена. Во-первых, необязательно выбирать что-то, что точно пригодится. У меня в школе был BASIC, но я не сокрушаюсь о "бесцельно потраченных годах". Если тревожно искать вариант, который явно пригодится, то (как мне кажется) ещё долго будет надёжно как скриптовый выбирать Python, как более мощный чистый C (с учётом C API как универсальной связки разных инструментов между собой). Хотя надеяться изучить всё за минимум времени и не потратить лишней минуты зря уже ошибка, без готовности тратить много времени хорошо программирование не учится. Для изучения самых основ конкретный язык не так важен. После основ C и Python понимать стоит ну большинству. А дальше выбор более конкретных инструментов и выбор языка очень связаны. Тодга лучше выбирать, что хочется делать [новичку] на будущем месте работы, а не при помощи чего.
Общие рейтинги ЯП вообще штука заранее сомнительная, предвзятая и неоднозначная. А если делать их менее общими и специализировать под интересующую область, то рейтинги становятся неинтересными и рассыпаются, всё становится нередко "и так понятно", и рейтинг на практике бесполезен, вещь в себе.
Сначала и во-первых это красиво, учит правильным привычкам и любопытная головоломка. Но потом и во-вторых продолжать конкретные инструменты именно под Haskell оказывается надо очень редко, вакансии довольно редки, а также проблематично прототипировать, дебажить и оптимизировать, связь исходного кода и ассемблера тут ну очень непрозрачна. А делать производительные части условно на C/C++/Fortran, чтобы использовать Haskell как фронтенд вместо питона ну как-то overkill (и претит любителым чистых функций без unsafe, что часто среди ярых хаскелистов), тем более что потенциальных пользователей окажется тогда очень мало (а если делать под питон, то его условно "знают все" или по крайней мере, смогут воспользоваться), встречал такой пример, как hasktorch, который вроде забросили. Так что для любознательности и кругозора Haskell — это прекрасно и полезно, но чаще для души, чем для работы. А поскольку язык общего назначения, задач, под которые Haskell был бы идеально заточен, чтобы где-то сказать, что вот тут точно надо делать именно на нём, я не встречал.
Если апатия приводит в python, а безысходность в js, то конструктивный поиск приводит к Rust или порой к Go. Ещё бывает, что долг возвращает к C++ или Fortran.
Именно, самое главное замечание про него. Он перестал быть открытым и независимым. Да и при всех красивых словах практически все его публичные заявления некрасивы, всегда кого-то оскорбляют. Но это было нормально, когда он ругался на неквалифицированных программистов. А после его заявлений по национальному признаку уважение к нему сильно упало.
"Ты Гоголь, допиши второй том".
"Ты Ферма, докажи свою теорему".
Ну так они на то и новые, первые полгода после выхода новый релиз трогать вообще не надо. Менять что-то надо, когда старое не поддерживает больше, вот с 20.04 перехожу на 22.04 плавно
Калькулятор очень мощный инструмент, но при вычислении спрашиваю себя, не подвожу ли я его примером к правильному ответу?..
У садовой улитки такой смысл жизни. Человеку доступно большее осмысление. Хотя, видимо, не каждому.
Смысл музыки хэштеги и чтобы несколько нейронов пошевелить? Ну да, слова читать и понимать слишком сложно, а ноты вообще. Для фоновых звуков во время работы или отдыха примерно так, но вы же не ограничиваете и под это рассуждение всю музыку подгоняете.
Автор думает, ноты в прошлом? Музыкальные инструменты, стало быть, тоже? И живое исполнение тогда.
Согласен. Диванные специалисты по ИИ пророчат, как изменится мир и всех захватят, только такой эксперт каждый второй школьник, хотя почему-то люди старше туда же. А недиванных специалистов, которые смотрят на это как на численную оптимизацию, матан, линейную алгебру и не вопят на каждом углу, не читают вот те "эксперты", сложно и непонятно, диванные не в курсе, как часто в нейронках хотя бы матрицы перемножаются. И тем более, как!
После того, как всякие такие навайбкодят, когда всё начнёт ломаться и трещать по швам, а починить они не смогут сами, настоящие нормальные программисты станут на порядки ценнее. Просто подождём.
все такие умные стали, проверяют наличие сознания у функции, которая даже вычисляется неточно...
Пик численных методов и математики тоже близок? В ИИ важнее не фреймворки и архитектура, а как просто матрицы множить численно устойчиво и быстро. Не надо называть численную оптимизацию сознанием просто. Её пика не предвидится, а пик хайпа на нейронках случится, как придёт новое, как нейро- заменило нано-.
Потому что она предобучалась на примерно миллионе партий про до того, как играла сама с собой.
Я и удивился перечислению numpy. А blas и lapack даже скорее фортрановские, больше f77. Но там не прям всё распараллелено, например, стандартный gemm нет. Можете убедиться в исходниках))
Расскажите, как это можно непосредственно применить для ускорения numpy, раз он стал потокобезопасен? И коснулся ли threading используемых blas и lapack? С какими сложностями пришлось столкнуться для numpy, scipy, pyarrow?
Есть обратная сторона вопроса: новость получается сгенерированной и может быть иногда не совсем правдой, а отсылки к первоисточнику для проверки нет.
А с какого момента "чувак, который освоил ИИ" стало значить того, кто генерирует код нейронками, а не того, кто понимает ML, матан, линейную алгебру, численные методы и в состоянии реализовать многое с нуля, потому что понимает? Кажется, произошла подмена программиста пользователем.
Да на код свой гляньте. Если вам реально нужны vtables, ну ок. Иначе ооп только compile time приблуда. Вы задачи решаете или тексты пишете?
Мне кажется, многое на деле проще. Под конкретную задачу выбор инструмента обычно легче сделать из логики проекта, а популярность инструментов тут неважна.
Если проект учебный, чтобы научиться чем-то пользователься, то выбор уже сделан. Если чтобы научиться что-то сделать (а не чем-то), то выбор сделан и состоит в том, чтобы попробовать разное и сравнить (в том числе под что способы ищутся легче).
Если речь о выборе чего-то для самого начала обучения, величина проблемы тоже преувеличена. Во-первых, необязательно выбирать что-то, что точно пригодится. У меня в школе был BASIC, но я не сокрушаюсь о "бесцельно потраченных годах". Если тревожно искать вариант, который явно пригодится, то (как мне кажется) ещё долго будет надёжно как скриптовый выбирать Python, как более мощный чистый C (с учётом C API как универсальной связки разных инструментов между собой). Хотя надеяться изучить всё за минимум времени и не потратить лишней минуты зря уже ошибка, без готовности тратить много времени хорошо программирование не учится. Для изучения самых основ конкретный язык не так важен. После основ C и Python понимать стоит ну большинству. А дальше выбор более конкретных инструментов и выбор языка очень связаны. Тодга лучше выбирать, что хочется делать [новичку] на будущем месте работы, а не при помощи чего.
Общие рейтинги ЯП вообще штука заранее сомнительная, предвзятая и неоднозначная. А если делать их менее общими и специализировать под интересующую область, то рейтинги становятся неинтересными и рассыпаются, всё становится нередко "и так понятно", и рейтинг на практике бесполезен, вещь в себе.
Сначала и во-первых это красиво, учит правильным привычкам и любопытная головоломка. Но потом и во-вторых продолжать конкретные инструменты именно под Haskell оказывается надо очень редко, вакансии довольно редки, а также проблематично прототипировать, дебажить и оптимизировать, связь исходного кода и ассемблера тут ну очень непрозрачна. А делать производительные части условно на C/C++/Fortran, чтобы использовать Haskell как фронтенд вместо питона ну как-то overkill (и претит любителым чистых функций без unsafe, что часто среди ярых хаскелистов), тем более что потенциальных пользователей окажется тогда очень мало (а если делать под питон, то его условно "знают все" или по крайней мере, смогут воспользоваться), встречал такой пример, как hasktorch, который вроде забросили. Так что для любознательности и кругозора Haskell — это прекрасно и полезно, но чаще для души, чем для работы. А поскольку язык общего назначения, задач, под которые Haskell был бы идеально заточен, чтобы где-то сказать, что вот тут точно надо делать именно на нём, я не встречал.
Если апатия приводит в python, а безысходность в js, то конструктивный поиск приводит к Rust или порой к Go. Ещё бывает, что долг возвращает к C++ или Fortran.