А зачем это нужно? Вроде бы индустрия верно сделала, что ушла от этих обязательных бумажек вроде дипломов и сертификатов, которые едва ли что-то показывают, а тут - это
Слишком сложный и нетривиальный. Примерно как C++, только без кучи ненужного барахла и с избивающим тебя до полусмерти borrow checker за любую провинность - новичкам будет очень тяжко, особенно если у них нет опыта, и не стоит забывать, что они дети
Если они приучаться к нему без опыта в других языках, то в дальнейшем изучение других языков будет ещё большей пыткой: в других языках всё сделано тяп-ляп, будут пропагандироваться практики, приводящие к выстреливанию себе в ногу и т.д. Перфекционизм, выработанный при освоении раста, будет сильно мешать. ~80% разрабов итак неохотно учат что-то кроме того, что они выучили когда в школе/универе, а вы предлагаете им переход с +/- идеального языка на что-то... далёкое от того, чтобы считать идеальным
Даже когда я закончил среднюю школу, я полагал, что мир «профессиональной разработки» выглядит совсем иначе, чем код, который я писал в свободное время
Значит вам удалось попасть лишь в недалекую галеру с такими же маслятами у руля.
Нормальные кодовые базы может быть не всегда соответствуют всем идеалам, вроде соблюдения всех форм нормализации данных в бд или какой-нибудь Чистой Архитектуры, но уж точно лучше того, что вы описали на порядки
бодрых школьников предпочтёт Python, продвинутые — C++
Уверен, тут все зависит от того, чему их учили в школе. Сам в школе не изучал ни одного языка, так что не знаю, могу лишь предполагать, что вряд ли школьники выбирают язык индивидуально, т.к. не знают, что лучше, да и тогда пришлось бы делить их на группы по выбранному языку и учить по отдельности.
Что до самого языка, в целом, формирование SQL-запроса путем форматирования строк - задача простейшая, знание основ любого из C/C++/Java/Python не будет слишком различным по сложности, все же мы говорим об азах.
монструозного с использованием всяких там вложенностей и группировок
Проще вложенных запросов, группировок и джоинов - только базовый селект, ну максимум с WHERE-clause. Ну думаю, что это стоит называть монструозным.
Я уже не говорю о том, что вы банально приучаете делать 20 запросов вместо того, чтобы сделать все в рамках одного, без необходимости производить некоторые CPU-действия на стороне ЯПа, где вам ещё повезет, если это будет язык на уровне языка, на котором написана сама бд, потому что так вы сильно замедлите скорость выполнения, и без необходимости гонять данные туда-сюда, создавая нагрузку на сеть, которая сожрёт 99% всего времени ожидания программы, и не важно, как бы ученик написал обратку - на питоне или с супер-топовым алгоритмом на C с наилучшей асимптотической сложностью. Дело же в том, что ребята просто прочтут и будут повторять за вами, понимаете?
Статья о том, что простенькие программы писать не зазорно, а использовать полезно. Буду рада, если в следующем году это сделает на актуальных данных какой-нибудь бодрый школьник
Я вас правильно понимаю, что проще выучить С и SQL, чем немного дооптимизировать 1 SQL-запрос? Особенно, какому-нибудь "бодрому школьнику". Две технологии вместо одной?
почему организаторы лото всегда в плюсе, зная все поданные данные
Меня тоже удивляло, почему люди пользуются кредитками, у которых всегда есть беспроцентный период. Особенно в период не слабой инфляции: просто бери и даже зарабатывай, вкладывая деньги в актив на время данного периода - и банки просто обанкротятся.
Но, как видите, они всё ещё в плюсе. И все просто: большинство людей, которые берут кредитку - в итоге пропускают чтото (а чаще всего - многое) и потом влипают в долги.
Тоже самое и с теми, кто играют в лотерею - не особо умные или не особо гонятся за выйгрышем, а играют чисто ради самого чувства азарта
А вот, кстати, насколько бесполезны? ... RasberryPi в режиме слой-на-железку --- то что получится?
Там важно распораллеливание вычислений. И если CPU-bound занимает по ядру, то у обычных CPU обычно ядер 1-24 (не знаком особо с кол-вом ядер в расбери, но думаю там на порядки хуже, чем даже на офисном ПК, что уж говорить о ПК с хорошими процами)
И того десяток ядер CPU против тысяч CUDA-ядер в GPU. Что будет эффективнее?
Кол-во инструкций CPU-ядра слишком большое для операций перемножения матриц, в итоге ядра сами по себе используются менее оптимальнее. В этом плане, кстате, сам GPU проигрывает TPU, т.к. тоже содержит лишние инструкции
Ниже уже написали про пропускную способность памяти, повторяться не буду, просто выделю как пункт
условные 500 слоев
Не знаю нейронок на 500 слоев, знаю на десятки слоев, да и те - обучаются уже точно не на своих машинах и серверах, а крупными компаниями, которые могут позволить себе огромные инфраструктуры для таких вычислений. Плюс, слои разные бывают, те же трансформеры обычно не содержат много слоев, но при этом демонстрируют результаты в разы превосходящие предыдущие поколения NLP, использовавших порой десятки слоев LSTM или GRU для более глубокого анализа контекста. При этом трансформеры требуют тех же огромных вычислительных мощностей для обучения, недаром ходят шутки про Илона, который говорит, что для обучения GPT-5 не хватит всей энергии человечества за пол года или год
Пыха долгое время была по возможности выстрелить себе в ногу хуже, чем даже js. И там, и там - слабая утиная типизация. В том же питоне, который все презирают, типизация сильная.
С другой стороны, golang - строгая статическая типизация с компиляцией. Просто так написать фигню и запустить едва ли получится.
В какой-то момент в пыху завезли статическую типизацию, но пользуются ей далеко не всегда и не охотно, люди не привыкли) Но зато язык все ещё для вкатунов, и те самые пол интернета, ранящиеся на нем, чем гордится все сообщество вкатунов php, использует lamp с хостингом.
P.s.: разумеется, что язык - лишь инструмент. И если знать, что ты делаешь - то все ништяк с любым. На том же PHP нормальные люди с IQ не как у картошки используют Лару, симфони, yii2 или ещё что-то, адекватно проектируя систему и код-стайл. Но то, что некоторые технологии позволяют все подряд и плодят убогое ПО уже 30 лет подряд - это проблема!
Процессоры бесполезны для подобных задач, графические ускорители применяются для этого чаще всего. Есть также TPU и NPU, ещё больше подходящие для данных целей, но сервера с ними предоставляются лишь бигтехом, вроде GCP и AWS
Вот какой "выхлоп" будет - это да, это держателям бюджета нравится
Это инвестор. Он не думает о том, как бизнес устроен детально, а просто вкладывается и ждёт аналитики, которая будет ему максимально проста и понятна
"минимизацию зависимостей и максимизацию внутренней связности" одинаково бессмысленно как и про " низкую связанность и высокое зацепление"
А вот это уже вполне для самих бизнесменов, т.к. организация бизнеса, структуры того, из чего он состоит и как что с чем взаимодействует - это уже на плечах бизнесмена. Например, откуда берется сырье, как преобразуется и как и куда потом продается - бизнесмен должен не то, что знать, а сам придумать и контролировать! И да, тут все эти DDD как раз и всплывают на поверхность, т.к. высокоуровневая разработка ничем не отличается от организации бизнеса, особенно малого, где сами бизнесмены должны делать все сами, без аналитиков и тд. И автор пытался сказать именно это
А те, кто просто хочет вложить свои миллионы туда, не знаю куда, и получать супер разжеванную аналитику на пальцах, потому что сам не хочет вникать ни в организацию, ни в расчеты расходов, налогов и прибыли - это просто инвесторы
А DI в FastAPI есть, но, насколько мне известно, только как раз таки на уровне контроллера
А где они еще нужны?
Еще по заветам незабвенного Дяди Боба, вы не должны позволять технологиям, которые вы используете, диктовать вам то, как слои проекта должны общаться друг с другом! И ладно бы речь шла о фреймворке вроде Django, но речь то о FastAPI, который чисто предоставляет роутинг и работу с запроса-ответами. Да, он также дает функционал и по хукам цикла жизни самого приложения (которые не обязательны и могут быть заменены), но смысл как раз в том, что вы и должны использовать FastAPI не более чем как слой роутинга со всякими удобными плюшками. БЛ не должно знать, что его вызывает - роутер, вы из консольки, gRPC или вообще кто или что угодно!
Я почти уверен, что можно что-то придумать со сторонними либами для DI. Так что чтобы получить DI на уровне бизнес логики, тебе ещё нужно докрутить логики и нести доп. зависимости в проект. Не минус, но такое есть
Всегда также можно написать что-то свое (обычно так делаю, там ничего особо сложного, если знаешь, что хочешь, + контроль имеешь и представление о том, как и что у тебя работает), или посмотреть в сторону продвинутого DI - IoC-контейнера
"Когда в руках молоток - всё вокруг кажется гвоздями"
А зачем это нужно? Вроде бы индустрия верно сделала, что ушла от этих обязательных бумажек вроде дипломов и сертификатов, которые едва ли что-то показывают, а тут - это
Rust точно не стоит:
Слишком сложный и нетривиальный. Примерно как C++, только без кучи ненужного барахла и с избивающим тебя до полусмерти borrow checker за любую провинность - новичкам будет очень тяжко, особенно если у них нет опыта, и не стоит забывать, что они дети
Если они приучаться к нему без опыта в других языках, то в дальнейшем изучение других языков будет ещё большей пыткой: в других языках всё сделано тяп-ляп, будут пропагандироваться практики, приводящие к выстреливанию себе в ногу и т.д. Перфекционизм, выработанный при освоении раста, будет сильно мешать. ~80% разрабов итак неохотно учат что-то кроме того, что они выучили когда в школе/универе, а вы предлагаете им переход с +/- идеального языка на что-то... далёкое от того, чтобы считать идеальным
Вы пишите как типичный "программист с 40летним стажем" на уровне интерна. Отпинать бы вас самих, да жизнь вас уже отпинала
Что за "явные операторы скобок"?
Значит вам удалось попасть лишь в недалекую галеру с такими же маслятами у руля.
Нормальные кодовые базы может быть не всегда соответствуют всем идеалам, вроде соблюдения всех форм нормализации данных в бд или какой-нибудь Чистой Архитектуры, но уж точно лучше того, что вы описали на порядки
Уверен, тут все зависит от того, чему их учили в школе. Сам в школе не изучал ни одного языка, так что не знаю, могу лишь предполагать, что вряд ли школьники выбирают язык индивидуально, т.к. не знают, что лучше, да и тогда пришлось бы делить их на группы по выбранному языку и учить по отдельности.
Что до самого языка, в целом, формирование SQL-запроса путем форматирования строк - задача простейшая, знание основ любого из C/C++/Java/Python не будет слишком различным по сложности, все же мы говорим об азах.
Проще вложенных запросов, группировок и джоинов - только базовый селект, ну максимум с
WHERE-clause. Ну думаю, что это стоит называть монструозным.Я уже не говорю о том, что вы банально приучаете делать 20 запросов вместо того, чтобы сделать все в рамках одного, без необходимости производить некоторые CPU-действия на стороне ЯПа, где вам ещё повезет, если это будет язык на уровне языка, на котором написана сама бд, потому что так вы сильно замедлите скорость выполнения, и без необходимости гонять данные туда-сюда, создавая нагрузку на сеть, которая сожрёт 99% всего времени ожидания программы, и не важно, как бы ученик написал обратку - на питоне или с супер-топовым алгоритмом на C с наилучшей асимптотической сложностью. Дело же в том, что ребята просто прочтут и будут повторять за вами, понимаете?
Я вас правильно понимаю, что проще выучить С и SQL, чем немного дооптимизировать 1 SQL-запрос? Особенно, какому-нибудь "бодрому школьнику". Две технологии вместо одной?
Во первых, не очень понял, зачем нужно писать программу на С, если все можно составить на чистом SQL?
А о чем статья в итоге? О том, как вы собрали данные в одну таблицу и сделали один простенький селект?
Лучшая статья про Python! Автор – большой молодец, даже не забыл прорекламить свой ТГ канал, ДВАЖДЫ!
Google Hum релизнулась ещё в 2020
Меня тоже удивляло, почему люди пользуются кредитками, у которых всегда есть беспроцентный период. Особенно в период не слабой инфляции: просто бери и даже зарабатывай, вкладывая деньги в актив на время данного периода - и банки просто обанкротятся.
Но, как видите, они всё ещё в плюсе. И все просто: большинство людей, которые берут кредитку - в итоге пропускают чтото (а чаще всего - многое) и потом влипают в долги.
Тоже самое и с теми, кто играют в лотерею - не особо умные или не особо гонятся за выйгрышем, а играют чисто ради самого чувства азарта
Вы не понимаете, автор настолько прошарен, что даже подмечает свою продвинутость:
Типо, не вчера загуглил
Там важно распораллеливание вычислений. И если CPU-bound занимает по ядру, то у обычных CPU обычно ядер 1-24 (не знаком особо с кол-вом ядер в расбери, но думаю там на порядки хуже, чем даже на офисном ПК, что уж говорить о ПК с хорошими процами)
И того десяток ядер CPU против тысяч CUDA-ядер в GPU. Что будет эффективнее?
Кол-во инструкций CPU-ядра слишком большое для операций перемножения матриц, в итоге ядра сами по себе используются менее оптимальнее. В этом плане, кстате, сам GPU проигрывает TPU, т.к. тоже содержит лишние инструкции
Ниже уже написали про пропускную способность памяти, повторяться не буду, просто выделю как пункт
Не знаю нейронок на 500 слоев, знаю на десятки слоев, да и те - обучаются уже точно не на своих машинах и серверах, а крупными компаниями, которые могут позволить себе огромные инфраструктуры для таких вычислений. Плюс, слои разные бывают, те же трансформеры обычно не содержат много слоев, но при этом демонстрируют результаты в разы превосходящие предыдущие поколения NLP, использовавших порой десятки слоев LSTM или GRU для более глубокого анализа контекста. При этом трансформеры требуют тех же огромных вычислительных мощностей для обучения, недаром ходят шутки про Илона, который говорит, что для обучения GPT-5 не хватит всей энергии человечества за пол года или год
Пыха долгое время была по возможности выстрелить себе в ногу хуже, чем даже js. И там, и там - слабая утиная типизация. В том же питоне, который все презирают, типизация сильная.
С другой стороны, golang - строгая статическая типизация с компиляцией. Просто так написать фигню и запустить едва ли получится.
В какой-то момент в пыху завезли статическую типизацию, но пользуются ей далеко не всегда и не охотно, люди не привыкли) Но зато язык все ещё для вкатунов, и те самые пол интернета, ранящиеся на нем, чем гордится все сообщество вкатунов php, использует lamp с хостингом.
P.s.: разумеется, что язык - лишь инструмент. И если знать, что ты делаешь - то все ништяк с любым. На том же PHP нормальные люди с IQ не как у картошки используют Лару, симфони, yii2 или ещё что-то, адекватно проектируя систему и код-стайл. Но то, что некоторые технологии позволяют все подряд и плодят убогое ПО уже 30 лет подряд - это проблема!
Процессоры бесполезны для подобных задач, графические ускорители применяются для этого чаще всего. Есть также TPU и NPU, ещё больше подходящие для данных целей, но сервера с ними предоставляются лишь бигтехом, вроде GCP и AWS
Чтобы к медленному выполнению добавились ещё и неуловимые баги из-за слабой типизации?)
Pydantic не слабо рассчитан и на валидацию, так что сравнение не совсем честное
Следует отличать бизнесменов от инвесторов
Это инвестор. Он не думает о том, как бизнес устроен детально, а просто вкладывается и ждёт аналитики, которая будет ему максимально проста и понятна
А вот это уже вполне для самих бизнесменов, т.к. организация бизнеса, структуры того, из чего он состоит и как что с чем взаимодействует - это уже на плечах бизнесмена. Например, откуда берется сырье, как преобразуется и как и куда потом продается - бизнесмен должен не то, что знать, а сам придумать и контролировать! И да, тут все эти DDD как раз и всплывают на поверхность, т.к. высокоуровневая разработка ничем не отличается от организации бизнеса, особенно малого, где сами бизнесмены должны делать все сами, без аналитиков и тд. И автор пытался сказать именно это
А те, кто просто хочет вложить свои миллионы туда, не знаю куда, и получать супер разжеванную аналитику на пальцах, потому что сам не хочет вникать ни в организацию, ни в расчеты расходов, налогов и прибыли - это просто инвесторы
А где они еще нужны?
Еще по заветам незабвенного Дяди Боба, вы не должны позволять технологиям, которые вы используете, диктовать вам то, как слои проекта должны общаться друг с другом! И ладно бы речь шла о фреймворке вроде Django, но речь то о FastAPI, который чисто предоставляет роутинг и работу с запроса-ответами. Да, он также дает функционал и по хукам цикла жизни самого приложения (которые не обязательны и могут быть заменены), но смысл как раз в том, что вы и должны использовать FastAPI не более чем как слой роутинга со всякими удобными плюшками. БЛ не должно знать, что его вызывает - роутер, вы из консольки, gRPC или вообще кто или что угодно!
Всегда также можно написать что-то свое (обычно так делаю, там ничего особо сложного, если знаешь, что хочешь, + контроль имеешь и представление о том, как и что у тебя работает), или посмотреть в сторону продвинутого DI - IoC-контейнера