"Oбычные" программисты (т.е. "джуны"), которые даже не понимают что стоит за словом "rand" скоро никому не будут нужны. Их сейчас увольняют пачками, успешно заменяя ИИ. Реально выживут (или проживут дольше) лишь инженеры с хорошим математическим образованием и архитектурным видением.
Библиотеки это, понятное дело, хорошо. Однако, для получения качественного продукта, необходимо хорошо понимать характеристики (в плане функциональности, масштабируемости и производительности) используемых библиотек. Вот даже автор статьи, похоже, понял разницу между std::map и std::unordered_map.
Автор доказал, что C++ это, на самом деле, лучший язык программирования :) В условиях естественного отбора, при наличии разнообразных ограничений, выживают не самые сильные, красивые (и далее по списку), а те, кто способен к адаптации. В отношении C++ можно сказать, что это язык который поддерживает множество парадигм программирования:
процедурное
объектно-ориентированное
шаблонное (generic programmimg)
функциональное
параллельное (и, что очень важно, с четко определенной семантикой модели памяти)
Язык предлагает несколько уровней абстракций. Не буду их анализировать здесь. Это отдельная тема.
Производительность языка максимально близка к железу.
Существует огромное количество библиотек и фреймворков.
Сотни тысяч (миллионы) программистов знают (хотя и в разной степени) этот язык.
Язык хорошо стандартизирован (есть комитет по стандартизации, в котором представлены интересы больших корпораций) и документирован.
В совокупности, все эти факторы позволяет использовать язык для разработки практически любых классов приложений: моделирование, обработка данных, системы управления, системы реального времени, встроенные приложения (микроконтроллеры, GPU), системы высокочастотной торговли, сервисы, сетевые приложения, базы данных, игры, 99% модулей для Пайтона, и т.д. и т.п.
Ни один другой язык и близко не обладает всей совокупностью качеств C++. Вопрос лишь в том, каким образом его используют. В этом плане, C++ мало чем отличается от естественных языков на котором говорят люди. Например, на (условно) английском в мире говорят сотни миллионов людей. В этом языке 2.5 миллиона слов. Однако речь забулдыги из подворотни, жителя гетто, продавца автомобилей и представителя высшего сословия отличаются так, как если бы они говорили на совершенно разных языках. Та же самая картина и у программистов на C++.
Ну и еще один комментарий. Автор статьи явно не понимает почему генерация случайных чисел реализована именно так (хотя вопрос не возник бы в принципе, если бы автор прошел хотя бы вводный курс математической статистики):
std::random_device rd;
std::mt19937 gen(rd()); // а что такое mt19937?
std::uniform_int_distribution<int> dist(1, 100); // а почему отдельно?
int value = dist(gen); // ну наконец-то
Ответ здесь очень простой. Когда речь идет о генерации случайных чисел, то есть две вещи:
функция распределения (uniform, Gauss, etc.). Строка 3 вверху.
собственно генератор случайных (или псевдо-случайных) последовательностей. Строка 2 вверху.
Библиотека четко разделяет эти концепции, предлагая программисту максимальную свободу выбора генератора в соответствии с требованиями задачи. Например:
дефолтный алгоритм mt19937 генерирует псевдослучайную последовательность при умеренной производительности. Это делает его приемлемым для большинства приложений, где не требуется ничего иного.
в ряде случаев (серьезная криптография) требуется более надежный генератор, либо генератор на основе физических эффектов (квантовых) с привлечением специализированного железа. Такие генераторы будут генерировать действительно случайные и невоспроизводимые последовательности.
либо может потребоваться очень быстрый генератор (заметьте, что mt19937 является довольно медленным). И тогда программист может разработать свою версию которая удовлетворяет стандартному интерфейсу.
Второй аспект модели генерации случайных чисел это функции распределения. Модель, в которой генераторы отделены от функций позволяют программисту разработать свою функцию распределения используя при этом любой генератор последовательностей.
Ну и если уж речь идет о том, что Вам непонятно что такое mt19937то напишите простой класс и используйте его в своем коде так, как если бы Вы писали на Пайтоне или Ржавчине :)
История разнообразных союзов сама по себе весьма интересна. Но это отклонение от основной темы. "Союзы" были лишь способом монетизации для писателей и иже с ними. "Союза Программистов Игр" не было. И слава богу! Можно себе представить каким образом требование т.н. "партийности" (отсыл к "дедушке" Ленину) трансформировалось бы в сюжет и реализацию игр. Но мы, люди с богатой фантазией, можем и пофантазировать на эту тему! Может все же вернемся к вопросу монетизации усилий по разработке игр в СССР?
Первые рыночные механизмы монетизации появились в конце 80х с внедрением кооперативов (по сути дела, это были первые частные предприятия, если не считать т.н. артелей в части различных промыслов). Основной вопрос - почему в позднем СССР и "новой" России не появились команды разработчиков игр? Я предполагаю, что проблема была в ментальности и внутренней закомплексованности доставшейся разработчикам того периода. Люди не были готовы выйти за рамки привычной модели мировоззрения, начать фантазировать и увидеть возможности реализации фантазий в виде игр. Процесс трансформации потребовал поколения.
Писать игры на ассемблере это круто! В конце 80х/начале 90х я также писал на MACRO-11 и VAX MACRO (MACRO-32), но не игры, а программы для работы с оборудованием.
Вот Вам пример "монетизации" в СССР (смайлик). Вместо того, чтобы продавать свои произведения (книги, музыку, программы) творческий человек должен был вступить в "союз" (контролируемо стадо) и получать вознаграждение от государства.
Читал, давно, еще в школе в СССР. Произведения были написаны по велению души и сердца замечательными людьми - Солоухиным, Паустовским и Пришвиным, а не "Союзом Писателей СССР" по заказу партии в соответствии с планами очередной пятилетки развития народного хозяйства страны. Хуже того, им приходилось пробивать свои произведения через цензуру. По этой же самой причине, они должны были стать членами "Союза Писателей/Поэтов СССР" и, возможно, членами партии. Иначе никак! Неужели Вы не видите нюансы в этой картине?
Вот если бы в СССР был "Союз Программистов Игр"! Вот тогда бы да, программисты бы зажили и начали творить шедевры, которые бы вошли в анналы мировой цивилизации (не подскажете как тут поставить "смайлик"?).
Вот Вы прямо и просто ответили на вопрос, которым так мучается автор статьи. Начнем с того, что, в рамках советской ментальности и экономической системы, монетизация игр была просто невозможна. За это можно было легко "присесть" на несколько мест в места не столь отдаленные. Соответсвенно, и не было и рынка, на котором индивидуальный программист (или группа) мог продать свой продукт. Убогие игры делали лишь в КБ в соответсвии техзаданиием, ГОСТ-ами, фондами, планами текущей пятилетки, и решениями пленума последнего сьезда КПСС. (В отличии от военной техники, систем управления электростанциями и т.д.) Игры, как живопись и музыка, это полет творчества и безумной фантазии! И их загнали в КБ. Какую музыку написал Союз Композиторов СССР, и какие стихи/прозу написал Союз Писателей СССР? А еще цензура. Просто представьте себе, насколько идеологически "вредной" была бы игра Цивилизация, со всей "буржуазной" терминологией, свободой воли и рынка. За такое - исключение из комсомола (партии) и, вполне вероятно, ... психушка или Колыма. Потребовалось не одно поколение прежде чем (ныне уже) российские программисты стали (научились) разрабатывать интересные игры.
Вопрос даже не в том, что оба кандидата проявили смекалку (хотя, как я подозреваю, они узнали о подобном способе из третьего источника), а в том, что этот подход "попахивает" откровенным враньем. Если вранье начинается уже на уровне резюме, тогда что можно ожидать от такого кандидата дальше? Хороший инженер (разработчик) все же должен быть честным человеком. Честный разработчик не будет закапывать ошибки "под ковер" или срезать углы. Подобное непосредственно влияет на качество разрабатываемого продукта и на общую атмосферу в коллективе, постепенно отравляя ее.
Хотя с честными (особенно с бескомпромиссными) людьми порой бывает трудно работать. Сознательные компромиссы при разработке неизбежны. Однако они должны быть озвучены, обоснованы и приняты.
Именно так! Упоминание Брина в качестве "весомого аргумента" в логике рассуждений автора статьи и общем контексте самой статьи это либо ошибка либо сознательная манипуляция.
У нас недавно случилась вообще интересная история имеющая непосредственное отношение к теме поднятой Юрием. Мы искали в проект специалиста по C++, database design, parallel programming, distributed systems. В течении пары недель после публикации объявления о найме (в районе SF Bay Area) у нас накопилось для рассмотрения более 100 резюме. Большинство было отброшено по очевидным причинам - недостаточная квалификация, невнятное резюме и т.п. Лишь около 5 могли представлять интерес. Из них 3 явно несли отпечаток индивидуальности соискателей и их интересного опыта. Всех троих пригласили на интервью. А еще два резюме выглядели ... просто идеально! Резюме были очень грамотно составлены. Но самое интересное было в том, что спектр опыта и знаний обоих кандидатов идеально совпадал с нашими ожиданиями. Более того, кандидаты отмечали некоторые особенности проекта, о которых могли знать лишь мы сами, как если бы они УЖЕ были нашими коллегами. По прочтении документов складывалось ощущение, что любой из этих двоих мог начать приносить реальную пользу уже через несколько недель после начала работы в нашей команде.
Однако дальнейший анализ резюме и некоторые размышления привели к интересным выводам и наблюдениям. Прежде всего нас насторожило то, что около 25% текста в резюме практически совпадали, причем именно в сферах, имеющих непосредственное отношение к нашему проекту (коду). При этом, оба кандидата находились в географически удаленных друг от друга регионах, не пересекались в одних и тех же учебных заведениях, не работали в одних и тех же компаниях. Следующее наблюдение состояло в том, что описание технологий и проблем было удивительно знакомо. В итоге, мы заподозрили (а позже и получили прямое подтверждение этого), что текст был основан на прямом цитировании некоторых комментариев к коду (C++ классам) нашего проекта. На этом этапе пришло прозрение - резюме были сгенерированы с помощью ИИ инструментов непосредственно на основании нашего кода.
Весь код нашего проекта находится в открытом доступе в GitHub.
Ну а что произошло дальше, наверное, уже понятно - оба резюме были отправлены в мусорную корзину, кандидаты добавлены в "черный список", а остальные резюме были подвергнуты критическому анализу на основании полученного опыта.
О том, что резюме должно писаться (настраиваться) под конкретную компанию/организацию известно давно. И в этом есть большой смысл - кандидат должен иметь хотя бы базовое представление о том, в какой среде и над какими задачами ему предстоит работать. Новость (возможно лишь для нас?) состояла в возможностях полной "виртуализации" и "супер-тонкой" настройки профиля соискателей инструментами ИИ на основании кода проекта.
В даном примере, ИИ сыграла действительно злую шутку с обоими кандидатами полностью лишив их шансов попасть даже на интервью.
кто-то эмигрировал (Сергей Брин и основатели многих западных студий тоже из этой волны),
В действительности:
Сергей Михайлович Брин родился в Москве в семье советских евреев[8][9] — математиков, переехавших на постоянное место жительства в США в 1979 году, когда ему было 6 лет.
SAMRH71 (150nm): A rad-hard by design 32-bit ARM Cortex-M7 microcontroller, part of the SAMV71 family, built on 150nm SOI CMOS technology designed for high-density space applications.
AT65RHA (65nm): Rad-hard ASICs manufactured on 65nm technology, offering high-speed links and up to 50 million gates for next-generation satellite systems.
RTG4 FPGAs (65nm): Radiation-tolerant FPGAs with 65nm flash-based technology, immune to configuration upsets (SEU) without needing background scrubbing.
SAMRH707 (150nm): A rad-hard microcontroller featuring a >100 DMIPS processor core and embedded non-volatile flash memory for high-integration, stand-alone computing in space. [1, 2, 3, 4]
Я согласен с Вами о том, что подобный сценарий имеет смысл, особенно для простых приложений. Но дело в том, что в современном мире большинство приложений раздаются с использование лишь двух основных способов (по крайней мере для Linux):
Docker containers (DockerHub, GitHub CR, etc.)
source code (GitHub)
Собственно для них лучше подходят разделяемые библиотеки.
В первом случае, все взаимо-согласованные внешние зависимости (LIBC, библиотеки исполнения компилятора, и прочее, что не является продуктом компиляции Вашего кода) включаются в базовый образ (image) run-time контейнерa. Run-time контейнер обеспечивает правильную среду для приложения. На основании такого контейнера вы уже строите следующий уровень - application container, который содержит лишь Ваше приложение скомпилированное для версий библиотек базового контейнера. Помимо собственно бинарников, Вы можете включить в свой контейнер все, что нужно для их работы - конфигурационные файлы, и прочее. Контейнеры это очень удобный механизм позволяющий максимально упростить application deployment либо через Docker run-time либо в Kubernetes.
Второй способ обычно требует CMake, который используется для сборки приложения там где оно и будет работать.
[ Я совершено не оспариваю неявное утверждение о том, что iostream в C++ это полнейшее "гуано". ]
Вопрос лишь - в чем, собственно, смысл делать сборку без динамических/разделяемых библиотек (флаг -static который при сборке передается в ld)? Если Вы строите бинарник для встроенных приложений (микроконтроллеров, систем реального времени) то C++ Standard Library вам точно не нужна поскольку эта библиотека (по умолчанию, если Вы не используете специальные аллокаторы) динамически аллокирует/освобождает память. Во всех осталных случаях удобнее использовать разделяемые библиотеки.
Если уберете этот флаг и скомпилируете:
g++ -O2 hello.cpp -o hello.exe
То результат будет совсем иной:
ls -al
total 39
drwxr-xr-x 2 xxx yyy 4 May 8 15:23 .
drwxr-xr-x 8 xxx yyy 8 May 8 15:05 ..
-rw-r--r-- 1 xxx yyy 75 May 8 15:05 hello.cpp
-rwxr-xr-x 1 xxx yyy 18192 May 8 15:23 hello.exe
ldd hello.exe
linux-vdso.so.1 (0x00007ffed21c3000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4b17c00000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4b17b25000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4b17eca000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4b17800000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4b17ef0000)
nm hello.exe
0000000000403de0 d _DYNAMIC
0000000000404000 d _GLOBAL_OFFSET_TABLE_
0000000000401140 t _GLOBAL__sub_I_main
0000000000402000 R _IO_stdin_used
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U _ZNKSt5ctypeIcE13_M_widen_initEv@GLIBCXX_3.4.11
0000000000401260 W _ZNKSt5ctypeIcE8do_widenEc
U _ZNSo3putEc@GLIBCXX_3.4
U _ZNSo5flushEv@GLIBCXX_3.4
U _ZNSt8ios_base4InitC1Ev@GLIBCXX_3.4
U _ZNSt8ios_base4InitD1Ev@GLIBCXX_3.4
U _ZSt16__throw_bad_castv@GLIBCXX_3.4
0000000000404080 B _ZSt4cout@GLIBCXX_3.4
0000000000404191 b _ZStL8__ioinit
U _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@GLIBCXX_3.4
0000000000402118 r __FRAME_END__
000000000040201c r __GNU_EH_FRAME_HDR
0000000000404060 D __TMC_END__
000000000040037c r __abi_tag
000000000040405c B __bss_start
U __cxa_atexit@GLIBC_2.2.5
0000000000404058 D __data_start
0000000000401220 t __do_global_dtors_aux
0000000000403dd8 d __do_global_dtors_aux_fini_array_entry
0000000000402008 R __dso_handle
0000000000403dc8 d __frame_dummy_init_array_entry
w __gmon_start__
U __libc_start_main@GLIBC_2.34
00000000004011a0 T _dl_relocate_static_pie
000000000040405c D _edata
0000000000404198 B _end
0000000000401264 T _fini
0000000000401000 T _init
0000000000401170 T _start
0000000000404190 b completed.0
0000000000404058 W data_start
00000000004011b0 t deregister_tm_clones
0000000000401250 t frame_dummy
00000000004010b0 T main
00000000004011e0 t register_tm_clones
Вы совершенно забыли о такой вещи как РЕПЛИКАЦИЯ. Эта технология определенно поможет Вам решить часть перечисленных проблем: https://www.mydbops.com/blog/postgresql-replication. Технология (репликации) также поддерживается MySQL/MariaDB.
Какой-же этот геймер-ютубер молодца! Если бы вместо ИИ в тренде было гуано, а вместо Minecraft обычные палки, то он бы запостил видео с демонстрацией того, как из палок у гуано можно натянуть сову на глобус. Ну а результат (в виде дохода от рекламы на ютубе) был бы не меньше.
Прикольно было бы если бы модели тренировали не на существующем коде, а книгах, наподобие:
"Relational Database Design and Implementation" by Jan L. Harrington
Database Systems: The Complete Book
by Hector Garcia-Molina (Author), Jeffrey Ullman (Author), Jennifer Widom (Author)
Любопытно было бы посмотреть на результат :)
"Oбычные" программисты (т.е. "джуны"), которые даже не понимают что стоит за словом "rand" скоро никому не будут нужны. Их сейчас увольняют пачками, успешно заменяя ИИ. Реально выживут (или проживут дольше) лишь инженеры с хорошим математическим образованием и архитектурным видением.
Библиотеки это, понятное дело, хорошо. Однако, для получения качественного продукта, необходимо хорошо понимать характеристики (в плане функциональности, масштабируемости и производительности) используемых библиотек. Вот даже автор статьи, похоже, понял разницу между
std::mapиstd::unordered_map.Презабавная статья!
Автор доказал, что C++ это, на самом деле, лучший язык программирования :) В условиях естественного отбора, при наличии разнообразных ограничений, выживают не самые сильные, красивые (и далее по списку), а те, кто способен к адаптации. В отношении C++ можно сказать, что это язык который поддерживает множество парадигм программирования:
процедурное
объектно-ориентированное
шаблонное (generic programmimg)
функциональное
параллельное (и, что очень важно, с четко определенной семантикой модели памяти)
Язык предлагает несколько уровней абстракций. Не буду их анализировать здесь. Это отдельная тема.
Производительность языка максимально близка к железу.
Существует огромное количество библиотек и фреймворков.
Сотни тысяч (миллионы) программистов знают (хотя и в разной степени) этот язык.
Язык хорошо стандартизирован (есть комитет по стандартизации, в котором представлены интересы больших корпораций) и документирован.
В совокупности, все эти факторы позволяет использовать язык для разработки практически любых классов приложений: моделирование, обработка данных, системы управления, системы реального времени, встроенные приложения (микроконтроллеры, GPU), системы высокочастотной торговли, сервисы, сетевые приложения, базы данных, игры, 99% модулей для Пайтона, и т.д. и т.п.
Ни один другой язык и близко не обладает всей совокупностью качеств C++. Вопрос лишь в том, каким образом его используют. В этом плане, C++ мало чем отличается от естественных языков на котором говорят люди. Например, на (условно) английском в мире говорят сотни миллионов людей. В этом языке 2.5 миллиона слов. Однако речь забулдыги из подворотни, жителя гетто, продавца автомобилей и представителя высшего сословия отличаются так, как если бы они говорили на совершенно разных языках. Та же самая картина и у программистов на C++.
Ну и еще один комментарий. Автор статьи явно не понимает почему генерация случайных чисел реализована именно так (хотя вопрос не возник бы в принципе, если бы автор прошел хотя бы вводный курс математической статистики):
Ответ здесь очень простой. Когда речь идет о генерации случайных чисел, то есть две вещи:
функция распределения (uniform, Gauss, etc.). Строка 3 вверху.
собственно генератор случайных (или псевдо-случайных) последовательностей. Строка 2 вверху.
Библиотека четко разделяет эти концепции, предлагая программисту максимальную свободу выбора генератора в соответствии с требованиями задачи. Например:
дефолтный алгоритм
mt19937генерирует псевдослучайную последовательность при умеренной производительности. Это делает его приемлемым для большинства приложений, где не требуется ничего иного.в ряде случаев (серьезная криптография) требуется более надежный генератор, либо генератор на основе физических эффектов (квантовых) с привлечением специализированного железа. Такие генераторы будут генерировать действительно случайные и невоспроизводимые последовательности.
либо может потребоваться очень быстрый генератор (заметьте, что
mt19937является довольно медленным). И тогда программист может разработать свою версию которая удовлетворяет стандартному интерфейсу.Второй аспект модели генерации случайных чисел это функции распределения. Модель, в которой генераторы отделены от функций позволяют программисту разработать свою функцию распределения используя при этом любой генератор последовательностей.
Ну и если уж речь идет о том, что Вам непонятно что такое
mt19937то напишите простой класс и используйте его в своем коде так, как если бы Вы писали на Пайтоне или Ржавчине :)История разнообразных союзов сама по себе весьма интересна. Но это отклонение от основной темы. "Союзы" были лишь способом монетизации для писателей и иже с ними. "Союза Программистов Игр" не было. И слава богу! Можно себе представить каким образом требование т.н. "партийности" (отсыл к "дедушке" Ленину) трансформировалось бы в сюжет и реализацию игр. Но мы, люди с богатой фантазией, можем и пофантазировать на эту тему! Может все же вернемся к вопросу монетизации усилий по разработке игр в СССР?
Первые рыночные механизмы монетизации появились в конце 80х с внедрением кооперативов (по сути дела, это были первые частные предприятия, если не считать т.н. артелей в части различных промыслов). Основной вопрос - почему в позднем СССР и "новой" России не появились команды разработчиков игр? Я предполагаю, что проблема была в ментальности и внутренней закомплексованности доставшейся разработчикам того периода. Люди не были готовы выйти за рамки привычной модели мировоззрения, начать фантазировать и увидеть возможности реализации фантазий в виде игр. Процесс трансформации потребовал поколения.
Писать игры на ассемблере это круто! В конце 80х/начале 90х я также писал на MACRO-11 и VAX MACRO (MACRO-32), но не игры, а программы для работы с оборудованием.
Вот Вам пример "монетизации" в СССР (смайлик). Вместо того, чтобы продавать свои произведения (книги, музыку, программы) творческий человек должен был вступить в "союз" (контролируемо стадо) и получать вознаграждение от государства.
Помните "Золотого теленка" Ильфа и Петров?
Читал, давно, еще в школе в СССР. Произведения были написаны по велению души и сердца замечательными людьми - Солоухиным, Паустовским и Пришвиным, а не "Союзом Писателей СССР" по заказу партии в соответствии с планами очередной пятилетки развития народного хозяйства страны. Хуже того, им приходилось пробивать свои произведения через цензуру. По этой же самой причине, они должны были стать членами "Союза Писателей/Поэтов СССР" и, возможно, членами партии. Иначе никак! Неужели Вы не видите нюансы в этой картине?
Вот если бы в СССР был "Союз Программистов Игр"! Вот тогда бы да, программисты бы зажили и начали творить шедевры, которые бы вошли в анналы мировой цивилизации (не подскажете как тут поставить "смайлик"?).
Вот Вы прямо и просто ответили на вопрос, которым так мучается автор статьи. Начнем с того, что, в рамках советской ментальности и экономической системы, монетизация игр была просто невозможна. За это можно было легко "присесть" на несколько мест в места не столь отдаленные. Соответсвенно, и не было и рынка, на котором индивидуальный программист (или группа) мог продать свой продукт. Убогие игры делали лишь в КБ в соответсвии техзаданиием, ГОСТ-ами, фондами, планами текущей пятилетки, и решениями пленума последнего сьезда КПСС. (В отличии от военной техники, систем управления электростанциями и т.д.) Игры, как живопись и музыка, это полет творчества и безумной фантазии! И их загнали в КБ. Какую музыку написал Союз Композиторов СССР, и какие стихи/прозу написал Союз Писателей СССР? А еще цензура. Просто представьте себе, насколько идеологически "вредной" была бы игра Цивилизация, со всей "буржуазной" терминологией, свободой воли и рынка. За такое - исключение из комсомола (партии) и, вполне вероятно, ... психушка или Колыма. Потребовалось не одно поколение прежде чем (ныне уже) российские программисты стали (научились) разрабатывать интересные игры.
Вопрос даже не в том, что оба кандидата проявили смекалку (хотя, как я подозреваю, они узнали о подобном способе из третьего источника), а в том, что этот подход "попахивает" откровенным враньем. Если вранье начинается уже на уровне резюме, тогда что можно ожидать от такого кандидата дальше? Хороший инженер (разработчик) все же должен быть честным человеком. Честный разработчик не будет закапывать ошибки "под ковер" или срезать углы. Подобное непосредственно влияет на качество разрабатываемого продукта и на общую атмосферу в коллективе, постепенно отравляя ее.
Хотя с честными (особенно с бескомпромиссными) людьми порой бывает трудно работать. Сознательные компромиссы при разработке неизбежны. Однако они должны быть озвучены, обоснованы и приняты.
Именно так! Упоминание Брина в качестве "весомого аргумента" в логике рассуждений автора статьи и общем контексте самой статьи это либо ошибка либо сознательная манипуляция.
У нас недавно случилась вообще интересная история имеющая непосредственное отношение к теме поднятой Юрием. Мы искали в проект специалиста по C++, database design, parallel programming, distributed systems. В течении пары недель после публикации объявления о найме (в районе SF Bay Area) у нас накопилось для рассмотрения более 100 резюме. Большинство было отброшено по очевидным причинам - недостаточная квалификация, невнятное резюме и т.п. Лишь около 5 могли представлять интерес. Из них 3 явно несли отпечаток индивидуальности соискателей и их интересного опыта. Всех троих пригласили на интервью. А еще два резюме выглядели ... просто идеально! Резюме были очень грамотно составлены. Но самое интересное было в том, что спектр опыта и знаний обоих кандидатов идеально совпадал с нашими ожиданиями. Более того, кандидаты отмечали некоторые особенности проекта, о которых могли знать лишь мы сами, как если бы они УЖЕ были нашими коллегами. По прочтении документов складывалось ощущение, что любой из этих двоих мог начать приносить реальную пользу уже через несколько недель после начала работы в нашей команде.
Однако дальнейший анализ резюме и некоторые размышления привели к интересным выводам и наблюдениям. Прежде всего нас насторожило то, что около 25% текста в резюме практически совпадали, причем именно в сферах, имеющих непосредственное отношение к нашему проекту (коду). При этом, оба кандидата находились в географически удаленных друг от друга регионах, не пересекались в одних и тех же учебных заведениях, не работали в одних и тех же компаниях. Следующее наблюдение состояло в том, что описание технологий и проблем было удивительно знакомо. В итоге, мы заподозрили (а позже и получили прямое подтверждение этого), что текст был основан на прямом цитировании некоторых комментариев к коду (C++ классам) нашего проекта. На этом этапе пришло прозрение - резюме были сгенерированы с помощью ИИ инструментов непосредственно на основании нашего кода.
Весь код нашего проекта находится в открытом доступе в GitHub.
Ну а что произошло дальше, наверное, уже понятно - оба резюме были отправлены в мусорную корзину, кандидаты добавлены в "черный список", а остальные резюме были подвергнуты критическому анализу на основании полученного опыта.
О том, что резюме должно писаться (настраиваться) под конкретную компанию/организацию известно давно. И в этом есть большой смысл - кандидат должен иметь хотя бы базовое представление о том, в какой среде и над какими задачами ему предстоит работать. Новость (возможно лишь для нас?) состояла в возможностях полной "виртуализации" и "супер-тонкой" настройки профиля соискателей инструментами ИИ на основании кода проекта.
В даном примере, ИИ сыграла действительно злую шутку с обоими кандидатами полностью лишив их шансов попасть даже на интервью.
Здесь Вы не правы:
В действительности:
Никакой принципиальной разницы между ними нет. Вопрос лишь в лицензии и наличии готовых и проработаных IPs. В этом плане, ARM предпочтительнее.
Процессор разработан Microchip.
https://www.nasa.gov/technology/hello-universe-nasas-next-gen-space-processor-undergoes-testing/
https://www.nasa.gov/game-changing-development-projects/high-performance-spaceflight-computing-hpsc/
Вот информация, которая есть в открытом дотупе на эту тему:
Microchip Rad-Hard/Rad-Tolerant Processor Portfolio [1]
SAMRH71 (150nm): A rad-hard by design 32-bit ARM Cortex-M7 microcontroller, part of the SAMV71 family, built on 150nm SOI CMOS technology designed for high-density space applications.
AT65RHA (65nm): Rad-hard ASICs manufactured on 65nm technology, offering high-speed links and up to 50 million gates for next-generation satellite systems.
RTG4 FPGAs (65nm): Radiation-tolerant FPGAs with 65nm flash-based technology, immune to configuration upsets (SEU) without needing background scrubbing.
SAMRH707 (150nm): A rad-hard microcontroller featuring a >100 DMIPS processor core and embedded non-volatile flash memory for high-integration, stand-alone computing in space. [1, 2, 3, 4]
Я согласен с Вами о том, что подобный сценарий имеет смысл, особенно для простых приложений. Но дело в том, что в современном мире большинство приложений раздаются с использование лишь двух основных способов (по крайней мере для Linux):
Docker containers (DockerHub, GitHub CR, etc.)
source code (GitHub)
Собственно для них лучше подходят разделяемые библиотеки.
В первом случае, все взаимо-согласованные внешние зависимости (LIBC, библиотеки исполнения компилятора, и прочее, что не является продуктом компиляции Вашего кода) включаются в базовый образ (image) run-time контейнерa. Run-time контейнер обеспечивает правильную среду для приложения. На основании такого контейнера вы уже строите следующий уровень - application container, который содержит лишь Ваше приложение скомпилированное для версий библиотек базового контейнера. Помимо собственно бинарников, Вы можете включить в свой контейнер все, что нужно для их работы - конфигурационные файлы, и прочее. Контейнеры это очень удобный механизм позволяющий максимально упростить application deployment либо через Docker run-time либо в Kubernetes.
Второй способ обычно требует CMake, который используется для сборки приложения там где оно и будет работать.
[ Я совершено не оспариваю неявное утверждение о том, что iostream в C++ это полнейшее "гуано". ]
Вопрос лишь - в чем, собственно, смысл делать сборку без динамических/разделяемых библиотек (флаг
-staticкоторый при сборке передается вld)? Если Вы строите бинарник для встроенных приложений (микроконтроллеров, систем реального времени) то C++ Standard Library вам точно не нужна поскольку эта библиотека (по умолчанию, если Вы не используете специальные аллокаторы) динамически аллокирует/освобождает память. Во всех осталных случаях удобнее использовать разделяемые библиотеки.Если уберете этот флаг и скомпилируете:
То результат будет совсем иной:
У Вас в арифметике есть небольшая ошибка. Прибыль 100% :)
Очень интересная и познавательная статья! Портят ее вызывающие рвоту "иллюстрации сгенерированы(е) нейросетью". Зачем они? Дань моде?
Вы совершенно забыли о такой вещи как РЕПЛИКАЦИЯ. Эта технология определенно поможет Вам решить часть перечисленных проблем: https://www.mydbops.com/blog/postgresql-replication. Технология (репликации) также поддерживается MySQL/MariaDB.
Какой-же этот геймер-ютубер молодца! Если бы вместо ИИ в тренде было гуано, а вместо Minecraft обычные палки, то он бы запостил видео с демонстрацией того, как из палок у гуано можно натянуть сову на глобус. Ну а результат (в виде дохода от рекламы на ютубе) был бы не меньше.