если не ошибаюсь, zlib под win32 (или ssleay, или еще кто, не помню) собирается в трёх не совместимых по ABI вариантах, и все они типа extern "C"
Вот чтобы не иметь себе мозги и делают более высокоуровневые языки. Но конечно есть люди которым нравится мозго*ство, у них еще и утиный синдром обычно они предпочитают заниматься им на том уровне который был когда они входили в профессию, а каждый новый уровень считается "для лохов" и "деградацией".
Что из перечисленного «специализированные алгоритмы»?
Прочитайте определние порятия "алгоритм". Что из вышеперечисленного не подходит под "алгоритм"? Или по вашему алгоритм это только quicksort или A* а остальное это не алгоритм?
Те же вопросы на манипуляции битами вообще раньше на собесах спрашивали, сейчас это уже почти нигде не надо.
Когда производительность действительно важна, приходится по-старинке делать всё самому.
Это 0.01% случаев. Большинство разработчиков в ассемблер залазит примерно 0 раз за всю карьеру. Это не означает что они деградировавшие идиоты. Это означает что для большинства задач это не нужно.
Не любой, а тот в котором забросили архитектуру и забили на техдолг ради сиюминутной выгоды. Если у вас это так, не значит что везде так.
Тратить неделю на то чтобы разобраться куда что добавить в собственной код базе с котороый вы работаете на ежедневной основе - это не нормально! Это говорит о том что с кодбазой большие проблемы.
Вот в ассемблере их знать не надо. Как хочешь - так и делаешь.
Ага, а расскажите пожалуйста как это самое "как хочешь" будет потом работать при линковке с другим бинарем написанным другим разрабом который тоже делал "как хочешь". Сейчас вы можете extern C написать и ни о чем не думать. И это еще без учета разных архитектур где вообще всё по разному, сейчас вам ваш тулчен соберет что под x86 что под arm, а раньше это всё руками приходилось переписывать.
...убило развитие процессоров: теневые регистры, суперскалярность и внеочередность и прочее обумнение когда-то простых железок.
Зачем ходить глубоко? Возьмите те-же inline, rvo (nvro), оптимизация хвостовой рекурсии, сейчас это всё компилятор делает. Раньше вы сами это были вынуждены делать руками. Если вы написали функцию в которую вы идете через call никакой ассемблер вам её автоматом на инлайн не подменял.
Вы очевидно вообще не понимаете что такое ассемблер и что такое архитектура процессора. На лицо абсолютная деградация. x86 и ARM совершенно разные! Чтобы printf позвать надо сискол сделать на x86 это int 80 или syscall на арм это svc.
Перечислить эту кучу вы, естественно, не сможете.
Вот вам несколько примеров:
Ручное управление регистрами
Ручно разворачивание циклов (чтобы избежать лишних cmp jmp на коротких циклах)
Замена медленного деления на эквивалент
Ветвление без условий через setcc, cmov, and, xor
Ручной prefetch данных
Ручное выравнивание кода и данных
Оптимизация под конкретные CPU
Очевидно вы ничего из этого не знаете и даже не подозреваете о существовании. Теперь расскажите, мешает ли вам ваша деградация работать разработчиком или нет.
а зачем тогда в том дивном мире будущего, описываемом вами, чистые разработчики(а скорее даже кодеры)?
Я не описываю "мир будущего" я описываю мир настоящего. Что будет в будущем - будущее покажет. Сейчас разработчики нужны для того же что и всегда - разрабатывать фичи. Продакт решает что делать (для кого, кто ЦА, каую боль решает, какая планируется прибыль, ROI etc.). Разработчик решает как делать и собственно делает. В настоящий момент нужны и те и другие.
переход на компиляторы не забрал алгоритмические задачи с разработчика. Да и и с переходом на компиляторы и сам вектор того же дебага поменялся.
Переход с ассмеблера на высокоуровневые языки забрал с разработчика необходимость знать архитектуру процессора, конвенции вызовов, целую кучу разных оптимизацией и целую кучу специализированных алгоритмов.
Переход на вайб кодинг так же не забирает алгоритмические задачи с разработчика, вам по прежнему нужно понимать какой алгоритм вы хотите, нужно мочь объяснить это LLM, нужно понимать что вам нагенерировали, как оно работает какая тут сложность и т. д.
Просто из-за решения менеджмента сэкономить и использовать дешёвые ресурсы — будь то недорогие индусы или, как сейчас, AI.
Не надо смешивать мухи с котлетами. Желать менеджеры могут что угодно, мы сейчас не на стадии когда LLM заменят разработчиков. Мы сейчас на стадии что LLM это инструмент для разработчиков.
Я сейчас смотрю на AI как на замену индусам для MVP.
Не правильно смотрите. Генератор MVP это лишь одно из применений. Другое применение - это инструмент для разработчиков ускоряющий написание кода.
все, кто сейчас бездумно перекладывает всю разработку на AI, постепенно превратятся в те самые дешёвые индусские команды, пишущие код за копейки
У вас очень странное представление об LLM. В вашем мире есть две крайности. Крайность 1 - я луддит разраб и всё пишу руками. Крайность 2 - я тупой менеджер и отдал разработку некоему "AI".
По 1-му пункту - ну ок каждый пишет как он хочет но зачем? LLM тупо экономят время, писать те-же тесты руками - зачем, карл, зачем???
По 2-му, сейчас нету полноценных "AI" которым можно "отдать разработку". Ну ок тебе пообещали что некий "AI" заменит всю команду - ну уволь свою команду и купи мега-про-подписку, но нет, начинается какая-то х*ня описанная в статье когда "AI всё сделал надо только пофиксить мелкую багу"
от 2 часов до нескольких дней — на анализ того, как эти изменения повлияют на продукт в целом и на разных пользователей
Только вот это не задача разработчиков. Это задача аналитиков / продакт менеджеров.
Если бы не NDA, я бы показала вам коммиты, которые делают мои индусы после 3–4 дней (а то и недель) работы 🙂. Там и на 5 минут изменений в день не наберётся.
Что вам сказать - это печально. У вас видимо лютое легоси и сапорт без новых фичей. Даже средняя фича это обычно строк 300-500 кода, крупные по несколько тысяч минимум в разных частях проекта на фронте на беке в ядре и тд.
Добавьте к этому код-ревью, тестирование (которое порой может быть весьма долгим)
Код-ревью - сильно, не просто сильно а оочень сильно ускоряется LLM. Раньше у меня каждое замечание - это головняк (подправить в куче мест какую-то мелочь, подправить тесты, протестировать заново). Теперь большую часть правок делает LLM включая тесты => код ревью ускорилось раза в 3.
Тестирование - аналогично, написание юнит тестов, e2e тестов и прочих тестов ооочень сильно упрощается LLM. Если у вас вдруг еще нету тестов или индусы сидят и тестируют всё руками - самое время начать их писать (генерировать LLM - опишите ей ваши тест кейсы она нагенерит на них кодярник).
Имхо, почему бы в git-e не хранить историю запросов и сидов, в место кода.
Потому что промпты сами по себе не описывают состояние, а описывают запросы на изменение. Возможно скоро появятся какие-то промпто-подобные способы описания текущего состояния приложения. Чтобы из набора фраз "А теперь добавь кнопку!" "А теперь перекрась её в зеленый" генерировалось состояние "Зеленая кнопка слева по центру", из которого уже потом будет генерироваться полное приложение.
пример который Вы привели - это не уровень даже джуна, это секретарша, или кодогенератор
Это рутина, зачем набирать код самому если это может делать LLM. Просто из за хейта LLM? Меня на 90% устраивает кодярник от LLM, я 50 строк кода набираю медленней чем несколько фраз.
это нафиг не надо, это времени не занимает
У меня написание юнит тестов занимало довольно существенную часть времени. Намного больше чем написать "сделай тест который проверяет кейс с такими-то шагами".
в фиксе бага главное анализ истории изменений
Чтобы не нужно было делать "анализ истории изменений" люди пишут юнит тесты. Которые отломаются если вы сломаете полезный функционал. И не зачем руками историю поднимать и думать "ой зачем же он так сделал".
и вот хоть убей не представляю как на таком проекте можно использовать ИИ.
для любого изменения нужно понимать архитектуру и код проекта
Не надо делегировать LLM архитектуру. Для архитектуры есть собственная живая нейросеть, обычно неплохо работает. LLM нужно конкретно писать что конкретно ей сделать так как будто это тупой джуниор только что пришедший на проект. Типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там. И добавь юнит тест который проверит такой и такой кейсы."
фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое, пофиксать так чтобы не сломать и старое и новое.
Для начала неплохо бы написать юнит тест который этот баг воспроизводит. Если сам уже понял шаги - заставить LLM сгенерировать код юнит-теста не проблема.
Затем заставляешь LLM найти причину бага, типо "фигани дофига принтов, запусти тесты и скажи - ты понял в чем бага или нет".
Повторить пункт два до тех пор пока LLM и ты сам не поймешь и не убедишься в чем баг
Дальше просишь LLM сгенерировать фикс, можно для верности уточнить какой фикс ты хочешь
Где пункт в опросе "уже вайб-кодю и счастлив"? Но конечно не так как у автора.
Самому вайбкодить когда четко понимаешь что почему и зачем делегируешь LLM - это норм. Поддерживать то что там навайбкодил кто-то там еще без опыта разработки - не норм.
Представляешь, да, всё когда-то случается в первый раз.
Обоснование почему именно этот цикл последний будут? Или хотя бы пруфы ваших шорт позиций?
Вообще-то ещё и для эстетических потребностей
Промышленность + ювелирка не объясняют стоимость текущую стоимость золота. Текущую стоимость золота объясняет его хранение в качестве ЗВР крупными нациями, отсюда вся капитализация. Если завтра крупные нации распродадут всё золото и пополнят ЗВР чем угодно другим - стоимость золота обвалится катастрофически, а стоимость "чего-то другого" катастрофически вырастет.
Я не понимаю с чем вы спорите. Капитализация золота используемого в промышленности / ювелирки / в качестве ЗВР общедоступная информация. Вас в гугле забанили?
>> Стоимость акций на 90% - 99% спекулятивная. В десятки / сотни раз превышающая реальную стоимость
Ну тут без комментариев. Вопросов к твоей "реальности" всё больше.
Загуглите P/E индекс теслы, nvidia, apple и других топ компаний из S&P500. Ах да, вас же в гугле забанили. В моей реальности у теслы P/E индекс ±100, у apple ±40, у nvidia ±40. С учетом того что в среднем в дивиденды идет только 35% прибыли окупаться всё это будет примерно лет 100-200.
Да ну. Застройщик видимо должен в 0 работать, на энтузиазме. А учитывая расходы на землю, инфраструктуру, которую часто тоже должен застраивать, маркетинг и т.д. - вообще в минус.
Объясните пожалуйста какая себестоимость земли в центре Москвы например. И чем она отличается от точно такой же земли но в 300 км от Москвы. И почему это не "пузырь". Чтобы жить вам не нужна квартира именно именно в центре вы вполне можете жить на окраине / в области или даже в другом городе.
Вот вам несколько подсказок: "ограниченное предложение", "невозможность эмиссии новой земли в центре москвы", "закон спроса и предложения", "спекулятивный инструмент".
Так и где здесь генерация прибыли? Речь только об обесценивании фиата.
А при чем тут вообще прибыль? Откуда вы её вообще взяли? Я пояснял своё мнение почему "фиксация прибыли" в фиате - это идиоизм. Если так хочется зафиксировать то хотя бы во что-то что не обесценится в ближайшем будущем.
Обычно при легализации цена уменьшается. Откуда у вас цена в 100к? За 100 тысяч она может быть если покупать в рабство белого американца добровольно заплатив ему за пожизненое рабство. На практике их будут завозить из тех регионов где 100$ это годовая зарплата. Будут сами продаваться или с рождения уже рабами идти. Рабы это инфляционный ресурс с бесконечной эмиссиией => стоимость рабов будет вечно снижаться так как предложение и эмиссия ничем не ограничена (кроме регуляции).
Поздравляю! Теперь вы не разработчик а просто очень дорогая замена вики-движка.
А можете и не рассказать так как теперь у вашей конторы bus factor равный единице.
Все неочевидные решения должны быть задокументированы во внутренней вики, в jira таске и в коде в виде юнит-теста на эдакий подвыподверт.
Вот чтобы не иметь себе мозги и делают более высокоуровневые языки. Но конечно есть люди которым нравится мозго*ство, у них еще и утиный синдром обычно они предпочитают заниматься им на том уровне который был когда они входили в профессию, а каждый новый уровень считается "для лохов" и "деградацией".
Прочитайте определние порятия "алгоритм". Что из вышеперечисленного не подходит под "алгоритм"? Или по вашему алгоритм это только quicksort или A* а остальное это не алгоритм?
Те же вопросы на манипуляции битами вообще раньше на собесах спрашивали, сейчас это уже почти нигде не надо.
Это 0.01% случаев. Большинство разработчиков в ассемблер залазит примерно 0 раз за всю карьеру. Это не означает что они деградировавшие идиоты. Это означает что для большинства задач это не нужно.
Не любой, а тот в котором забросили архитектуру и забили на техдолг ради сиюминутной выгоды. Если у вас это так, не значит что везде так.
Тратить неделю на то чтобы разобраться куда что добавить в собственной код базе с котороый вы работаете на ежедневной основе - это не нормально! Это говорит о том что с кодбазой большие проблемы.
Ага, а расскажите пожалуйста как это самое "как хочешь" будет потом работать при линковке с другим бинарем написанным другим разрабом который тоже делал "как хочешь". Сейчас вы можете extern C написать и ни о чем не думать. И это еще без учета разных архитектур где вообще всё по разному, сейчас вам ваш тулчен соберет что под x86 что под arm, а раньше это всё руками приходилось переписывать.
Зачем ходить глубоко? Возьмите те-же inline, rvo (nvro), оптимизация хвостовой рекурсии, сейчас это всё компилятор делает. Раньше вы сами это были вынуждены делать руками. Если вы написали функцию в которую вы идете через call никакой ассемблер вам её автоматом на инлайн не подменял.
Вы очевидно вообще не понимаете что такое ассемблер и что такое архитектура процессора. На лицо абсолютная деградация. x86 и ARM совершенно разные! Чтобы printf позвать надо сискол сделать на x86 это int 80 или syscall на арм это svc.
Вот вам несколько примеров:
Ручное управление регистрами
Ручно разворачивание циклов (чтобы избежать лишних cmp jmp на коротких циклах)
Замена медленного деления на эквивалент
Ветвление без условий через setcc, cmov, and, xor
Ручной prefetch данных
Ручное выравнивание кода и данных
Оптимизация под конкретные CPU
Очевидно вы ничего из этого не знаете и даже не подозреваете о существовании. Теперь расскажите, мешает ли вам ваша деградация работать разработчиком или нет.
Я не описываю "мир будущего" я описываю мир настоящего. Что будет в будущем - будущее покажет. Сейчас разработчики нужны для того же что и всегда - разрабатывать фичи. Продакт решает что делать (для кого, кто ЦА, каую боль решает, какая планируется прибыль, ROI etc.). Разработчик решает как делать и собственно делает. В настоящий момент нужны и те и другие.
Переход с ассмеблера на высокоуровневые языки забрал с разработчика необходимость знать архитектуру процессора, конвенции вызовов, целую кучу разных оптимизацией и целую кучу специализированных алгоритмов.
Переход на вайб кодинг так же не забирает алгоритмические задачи с разработчика, вам по прежнему нужно понимать какой алгоритм вы хотите, нужно мочь объяснить это LLM, нужно понимать что вам нагенерировали, как оно работает какая тут сложность и т. д.
Не надо смешивать мухи с котлетами. Желать менеджеры могут что угодно, мы сейчас не на стадии когда LLM заменят разработчиков. Мы сейчас на стадии что LLM это инструмент для разработчиков.
Не правильно смотрите. Генератор MVP это лишь одно из применений. Другое применение - это инструмент для разработчиков ускоряющий написание кода.
У вас очень странное представление об LLM. В вашем мире есть две крайности. Крайность 1 - я луддит разраб и всё пишу руками. Крайность 2 - я тупой менеджер и отдал разработку некоему "AI".
По 1-му пункту - ну ок каждый пишет как он хочет но зачем? LLM тупо экономят время, писать те-же тесты руками - зачем, карл, зачем???
По 2-му, сейчас нету полноценных "AI" которым можно "отдать разработку". Ну ок тебе пообещали что некий "AI" заменит всю команду - ну уволь свою команду и купи мега-про-подписку, но нет, начинается какая-то х*ня описанная в статье когда "AI всё сделал надо только пофиксить мелкую багу"
Только вот это не задача разработчиков. Это задача аналитиков / продакт менеджеров.
Что вам сказать - это печально. У вас видимо лютое легоси и сапорт без новых фичей. Даже средняя фича это обычно строк 300-500 кода, крупные по несколько тысяч минимум в разных частях проекта на фронте на беке в ядре и тд.
Код-ревью - сильно, не просто сильно а оочень сильно ускоряется LLM. Раньше у меня каждое замечание - это головняк (подправить в куче мест какую-то мелочь, подправить тесты, протестировать заново). Теперь большую часть правок делает LLM включая тесты => код ревью ускорилось раза в 3.
Тестирование - аналогично, написание юнит тестов, e2e тестов и прочих тестов ооочень сильно упрощается LLM. Если у вас вдруг еще нету тестов или индусы сидят и тестируют всё руками - самое время начать их писать (генерировать LLM - опишите ей ваши тест кейсы она нагенерит на них кодярник).
Интересно, как же их держат на работе если они "деградировали и не могут решить задачу"?
И насколько вы сами деградировали после того как не пишите код на ассемблере, а пользуетесь одними компиляторами?
1 процент времени - это значит вы за 8-ми часовй день набираете код меньше 5 минут. Верю, я поверил.
Потому что промпты сами по себе не описывают состояние, а описывают запросы на изменение.
Возможно скоро появятся какие-то промпто-подобные способы описания текущего состояния приложения. Чтобы из набора фраз "А теперь добавь кнопку!" "А теперь перекрась её в зеленый" генерировалось состояние "Зеленая кнопка слева по центру", из которого уже потом будет генерироваться полное приложение.
Это рутина, зачем набирать код самому если это может делать LLM. Просто из за хейта LLM? Меня на 90% устраивает кодярник от LLM, я 50 строк кода набираю медленней чем несколько фраз.
У меня написание юнит тестов занимало довольно существенную часть времени. Намного больше чем написать "сделай тест который проверяет кейс с такими-то шагами".
Чтобы не нужно было делать "анализ истории изменений" люди пишут юнит тесты. Которые отломаются если вы сломаете полезный функционал. И не зачем руками историю поднимать и думать "ой зачем же он так сделал".
Не надо делегировать LLM архитектуру. Для архитектуры есть собственная живая нейросеть, обычно неплохо работает.
LLM нужно конкретно писать что конкретно ей сделать так как будто это тупой джуниор только что пришедший на проект. Типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там. И добавь юнит тест который проверит такой и такой кейсы."
Для начала неплохо бы написать юнит тест который этот баг воспроизводит. Если сам уже понял шаги - заставить LLM сгенерировать код юнит-теста не проблема.
Затем заставляешь LLM найти причину бага, типо "фигани дофига принтов, запусти тесты и скажи - ты понял в чем бага или нет".
Повторить пункт два до тех пор пока LLM и ты сам не поймешь и не убедишься в чем баг
Дальше просишь LLM сгенерировать фикс, можно для верности уточнить какой фикс ты хочешь
Профит.
Где пункт в опросе "уже вайб-кодю и счастлив"? Но конечно не так как у автора.
Самому вайбкодить когда четко понимаешь что почему и зачем делегируешь LLM - это норм. Поддерживать то что там навайбкодил кто-то там еще без опыта разработки - не норм.
Не описан самый простой вариант - заставить имеющегося агента (cursor / etc.) написать для вас нового.
Очередной крипто-хейтер
Обоснование почему именно этот цикл последний будут? Или хотя бы пруфы ваших шорт позиций?
Промышленность + ювелирка не объясняют стоимость текущую стоимость золота. Текущую стоимость золота объясняет его хранение в качестве ЗВР крупными нациями, отсюда вся капитализация. Если завтра крупные нации распродадут всё золото и пополнят ЗВР чем угодно другим - стоимость золота обвалится катастрофически, а стоимость "чего-то другого" катастрофически вырастет.
Я не понимаю с чем вы спорите. Капитализация золота используемого в промышленности / ювелирки / в качестве ЗВР общедоступная информация. Вас в гугле забанили?
Загуглите P/E индекс теслы, nvidia, apple и других топ компаний из S&P500. Ах да, вас же в гугле забанили. В моей реальности у теслы P/E индекс ±100, у apple ±40, у nvidia ±40. С учетом того что в среднем в дивиденды идет только 35% прибыли окупаться всё это будет примерно лет 100-200.
Объясните пожалуйста какая себестоимость земли в центре Москвы например. И чем она отличается от точно такой же земли но в 300 км от Москвы. И почему это не "пузырь". Чтобы жить вам не нужна квартира именно именно в центре вы вполне можете жить на окраине / в области или даже в другом городе.
Вот вам несколько подсказок: "ограниченное предложение", "невозможность эмиссии новой земли в центре москвы", "закон спроса и предложения", "спекулятивный инструмент".
А при чем тут вообще прибыль? Откуда вы её вообще взяли? Я пояснял своё мнение почему "фиксация прибыли" в фиате - это идиоизм. Если так хочется зафиксировать то хотя бы во что-то что не обесценится в ближайшем будущем.
Обычно при легализации цена уменьшается. Откуда у вас цена в 100к?
За 100 тысяч она может быть если покупать в рабство белого американца добровольно заплатив ему за пожизненое рабство.
На практике их будут завозить из тех регионов где 100$ это годовая зарплата. Будут сами продаваться или с рождения уже рабами идти.
Рабы это инфляционный ресурс с бесконечной эмиссиией => стоимость рабов будет вечно снижаться так как предложение и эмиссия ничем не ограничена (кроме регуляции).
Ну если сейчас теневое рабство и стоимость составлят от 500$ до 5K$, в случае если его легализовать думаю цена просядет до 100-1000$.