Хорошо, допустим я вкачусь в C++23, буду самым модным в индустрии
Пройду интервью в некоторые компании, где меня спросят о самых сложных пет проектах которые я делал
Мне расскажут как в компании используют новые стандарты, о новых фишках в их проекте
Таким образом выйду на свой первый рабочий день и увижу C++03, C++Builder. Увижу что auto вместо дедукции типа делает подстановку int. Увижу что все пользуются своей имплементацией std::string, std::unique_ptr
И что мне делать? Увольняться и искать самую модную компанию? А что если мне на кодревью скажут провести бенчмарк между подходом с ranged/views и самым обычным проходом? Может компилятор сделает хорошую векторизацию, так как у него было 20 лет для выявления оптимизаций на простейшем цикле
Может мне стоит прочитать книги дедов и разобраться хотя бы что такое bss? Почитать про паттерны?
А может ли быть такое что std::unordered_map сделана через одно место и будет куча коллизий с пустого места? А какие контейнеры сделаны дедами в pbds?
Посыл правильный, что нужно пользоваться инструментами языка, а не писать на языке "С+"
Но при чем тут изучение с нуля? В чем будет разница между профессионалом, который не знает ничего что было до нового стандарта и claude code?
Нанимает сотрудников HR, а тех интервью для галочки, для веселья
Ох, что могу сказать. Было весело! Чувствовал прям азарт в себе
У меня после прочтения статьи лишь возникли следующие вопросы:
А остались ли специалисты с 5 годами реального опыта, которые будут трудиться за зарплату миддлов?
Если остались, то как думаете, проходили ли они ваши так называемые assestments ? Будут они тратить на это время?
Могут ли кандидаты врать?
Но всё оказалось ещё хуже, почитал прошлые посты, про зарплатные вилки на синьоров, про то что "у нас программист не отдельная каста". Честно говоря, в шоке что немецкий миддл с 5 годами может получать меньше чем L3 в гугле
Интересный эксперимент! Но, кажется, практическая ценность близка к нулю: стандарт не гарантирует порядок в unordered_map, и полагаться на порядок не стоит
Вы продемонстрировали пример хорошего инженерного мышления: эмпирически исследовали "черный ящик" и сделали выводы о реализации его в clang
Но в чужих статьях подробно разобрано, как именно устроены реализации в Clang, GCC и MSVC, откуда можно узнать исчерпывающую информацию для вопроса в начале этой статьи
Например, в MSVC бакеты хранятся иначе, в глобальном списке, и «обратный порядок» при rehash там не воспроизводится -- так что наблюдения из статьи применимы только к libc++
Так и в чём смысл? В чем образовательная ценность? Показать, что можно угадать устройство библиотеки по косвенным признакам, вместо того чтобы прочитать её код?
Да и не только в танчики, какие-нибудь супер киберспортивные дисциплины тоже прошли мимо автора. Вряд ли час игры в доту даст залипательный и милый опыт видеоигр.
Честно, выглядит как конспект лекции (даже порядок идей в видео такой же), нежели "статья", но спасибо, есть на чем теперь тренировать пересказы яндекса...
Так для "динамических кешей" может пригодятся более эффективные структуры данных нежели использование массива и его сортировки? Здесь и сравнивать бессмысленно метод "бинпоиск" со структурой данных SkipList. Допустим не вижу никаких проблем использовать к/ч дерево чисто для вашей задачи, где поиск элемента и есть по своей сути бинарный поиск.
В комментариях под статьёй, что вы предоставили, сравнили к/ч дерево и SkipList, к сожалению SkipList оказался медленнее почти в 2 раза. (все-таки обе структуры имеют логарифмическую сложность, но так как у SkipList в основе вероятностный алгоритм, то бывают так называемые выбросы, из-за которых придется потратить чуток поболее времени).
И какой вывод тогда?
Конечно, стоит использовать тот или иной инструмент не потому что о нём написали в статье и сказали что log(n) -- это очень круто, но и впадать в другую крайность бессмысленно. Иногда простейший бинарный поиск оказывается ни чем не хуже, а может даже и лучше каких-то замудрёных математических штук.
Простите, возможно явно не по теме сравнения батареек, но нельзя было сделать таблицы таблицами, а не картинками?
Захотел загуглить что-нибудь про конкретные батарейки, лезу выделять текст, а мне открывает картинку) Я понимаю что все есть в "Базе данных" и на крайний случай можно написать название ручками, но таблица кажется немного удобнее картинки...
Когда я ищу какую-нибудь информацию, например, по коду. То первой ссылкой идёт условный stackoverflow, а следующие 2-3 сайта это всегда просто парсинг stackoverflow.
Или аналогичный пример с википедией, когда первой ссылкой идёт русскоязычная вики, а следующими идут автопереводы английской вики, где порой даже картинок нет...
Потому я думаю что этим должен заниматься сам поисковик / браузер, всё-таки довольно простая концепция с крестиками то.
Да ладно уж вам, ещё не скоро всеми любимые ИИ научатся самостоятельно создавать полноценные приложения. А вот очередные copilot'ы точно скоро внедрятся во многие среды разработки.
Всё-таки сгенерировать несколько тысяч строк без ошибок — это надо очень постараться. А дополнить несложный код шаблончиком, который использовали несколько миллионов раз, задача несложная.
Я могу ошибаться, но мне казалось, что предметный указатель заменили так называемые "сноски", которые прямо на странице с текстом указывают что имелось в виду.
Мне кажется, что автор преувеличивает проблему нейросетей, так как в статье разобраны примеры не самых объемных и сложных задач, которые целесообразно скорее при устном собеседовании спрашивать. Например, команда VK Видео в этом году отбирала весной людей на летнюю стажировку, соответственно, чтобы ускорить процесс людям выдали всем одно и то же задание на реализацию какого-то сервиса. Задача была достаточно объемной и комплексной, что для неё нужны были изначально знания даже чтобы понять что именно искать надо. Объективно ChatGPT не поможет сделать правильные запросы к самому себе (а если и выдаст, то не факт что верно), потому я более чем уверен, что с отбором они отлично справились. Да и если программист пишет верный код, то какая разница с помощью чего он это делает?
Хорошо, допустим я вкачусь в C++23, буду самым модным в индустрии
Пройду интервью в некоторые компании, где меня спросят о самых сложных пет проектах которые я делал
Мне расскажут как в компании используют новые стандарты, о новых фишках в их проекте
Таким образом выйду на свой первый рабочий день и увижу C++03, C++Builder. Увижу что auto вместо дедукции типа делает подстановку int. Увижу что все пользуются своей имплементацией std::string, std::unique_ptr
И что мне делать? Увольняться и искать самую модную компанию? А что если мне на кодревью скажут провести бенчмарк между подходом с ranged/views и самым обычным проходом? Может компилятор сделает хорошую векторизацию, так как у него было 20 лет для выявления оптимизаций на простейшем цикле
Может мне стоит прочитать книги дедов и разобраться хотя бы что такое bss? Почитать про паттерны?
А может ли быть такое что std::unordered_map сделана через одно место и будет куча коллизий с пустого места? А какие контейнеры сделаны дедами в pbds?
Посыл правильный, что нужно пользоваться инструментами языка, а не писать на языке "С+"
Но при чем тут изучение с нуля? В чем будет разница между профессионалом, который не знает ничего что было до нового стандарта и claude code?
Я правильно понял, что:
Ищем миддла
Ищем человека с опытом в 5 лет
Удивляемся низкой компетенции кандидатов
Нанимает сотрудников HR, а тех интервью для галочки, для веселья
У меня после прочтения статьи лишь возникли следующие вопросы:
А остались ли специалисты с 5 годами реального опыта, которые будут трудиться за зарплату миддлов?
Если остались, то как думаете, проходили ли они ваши так называемые assestments ? Будут они тратить на это время?
Могут ли кандидаты врать?
Но всё оказалось ещё хуже, почитал прошлые посты, про зарплатные вилки на синьоров, про то что "у нас программист не отдельная каста". Честно говоря, в шоке что немецкий миддл с 5 годами может получать меньше чем L3 в гугле
Удачного поиска людей с такими требованиями!
Не переоценивайте людей, которые делают запрос в gpt на подобии "Какой язык самый быстрый? Перепиши на него код сайта"
COBOL кстати уже насчитывает 64 года, но мало кто его знает почему-то
Схемотехнику, я уверен, вообще никто не откроет из тех кто только начинает свою карьеру
Интересный эксперимент! Но, кажется, практическая ценность близка к нулю: стандарт не гарантирует порядок в unordered_map, и полагаться на порядок не стоит
Вы продемонстрировали пример хорошего инженерного мышления: эмпирически исследовали "черный ящик" и сделали выводы о реализации его в clang
Но в чужих статьях подробно разобрано, как именно устроены реализации в Clang, GCC и MSVC, откуда можно узнать исчерпывающую информацию для вопроса в начале этой статьи
Например, в MSVC бакеты хранятся иначе, в глобальном списке, и «обратный порядок» при rehash там не воспроизводится -- так что наблюдения из статьи применимы только к libc++
Так и в чём смысл? В чем образовательная ценность? Показать, что можно угадать устройство библиотеки по косвенным признакам, вместо того чтобы прочитать её код?
Кому-нибудь пригодилось, мне например
Да и не только в танчики, какие-нибудь супер киберспортивные дисциплины тоже прошли мимо автора. Вряд ли час игры в доту даст залипательный и милый опыт видеоигр.
А возведение в степень здесь происходит за логарифм или линейное? Просто в этом и заключается вся задача
Кажется по выводу, что в 100 раз увеличили число, в ~100 раз увеличилось и время. Хотя возможно это вина длинной арифметики
Теперь каждая задача easy на литкоде будет выложена отдельным постом?
Честно, выглядит как конспект лекции (даже порядок идей в видео такой же), нежели "статья", но спасибо, есть на чем теперь тренировать пересказы яндекса...
Так для "динамических кешей" может пригодятся более эффективные структуры данных нежели использование массива и его сортировки? Здесь и сравнивать бессмысленно метод "бинпоиск" со структурой данных SkipList. Допустим не вижу никаких проблем использовать к/ч дерево чисто для вашей задачи, где поиск элемента и есть по своей сути бинарный поиск.
В комментариях под статьёй, что вы предоставили, сравнили к/ч дерево и SkipList, к сожалению SkipList оказался медленнее почти в 2 раза. (все-таки обе структуры имеют логарифмическую сложность, но так как у SkipList в основе вероятностный алгоритм, то бывают так называемые выбросы, из-за которых придется потратить чуток поболее времени).
И какой вывод тогда?
Конечно, стоит использовать тот или иной инструмент не потому что о нём написали в статье и сказали что log(n) -- это очень круто, но и впадать в другую крайность бессмысленно. Иногда простейший бинарный поиск оказывается ни чем не хуже, а может даже и лучше каких-то замудрёных математических штук.
Простите, возможно явно не по теме сравнения батареек, но нельзя было сделать таблицы таблицами, а не картинками?
Захотел загуглить что-нибудь про конкретные батарейки, лезу выделять текст, а мне открывает картинку)
Я понимаю что все есть в "Базе данных" и на крайний случай можно написать название ручками, но таблица кажется немного удобнее картинки...
Когда я ищу какую-нибудь информацию, например, по коду. То первой ссылкой идёт условный stackoverflow, а следующие 2-3 сайта это всегда просто парсинг stackoverflow.
Или аналогичный пример с википедией, когда первой ссылкой идёт русскоязычная вики, а следующими идут автопереводы английской вики, где порой даже картинок нет...
Потому я думаю что этим должен заниматься сам поисковик / браузер, всё-таки довольно простая концепция с крестиками то.
Да ладно уж вам, ещё не скоро всеми любимые ИИ научатся самостоятельно создавать полноценные приложения. А вот очередные copilot'ы точно скоро внедрятся во многие среды разработки.
Всё-таки сгенерировать несколько тысяч строк без ошибок — это надо очень постараться. А дополнить несложный код шаблончиком, который использовали несколько миллионов раз, задача несложная.
Я могу ошибаться, но мне казалось, что предметный указатель заменили так называемые "сноски", которые прямо на странице с текстом указывают что имелось в виду.
Кажется, что в статье просто написаны вещи, которые итак все понимают.
Схлопнутся проекты инфоцыган, которые обещают много и быстро, обманывают покупателей. А проекты, которые длительно и методично чему-то учат останутся.
И не поспоришь ведь.
Мне кажется, что автор преувеличивает проблему нейросетей, так как в статье разобраны примеры не самых объемных и сложных задач, которые целесообразно скорее при устном собеседовании спрашивать.
Например, команда VK Видео в этом году отбирала весной людей на летнюю стажировку, соответственно, чтобы ускорить процесс людям выдали всем одно и то же задание на реализацию какого-то сервиса.
Задача была достаточно объемной и комплексной, что для неё нужны были изначально знания даже чтобы понять что именно искать надо. Объективно ChatGPT не поможет сделать правильные запросы к самому себе (а если и выдаст, то не факт что верно), потому я более чем уверен, что с отбором они отлично справились.
Да и если программист пишет верный код, то какая разница с помощью чего он это делает?