Что случится раньше: умрет С++ или вымрут С++ программисты?

Автор оригинала: Oleksandr Kaleniuk
  • Перевод

Еще вчера я думал, что ИИ никогда не заменит меня как программиста.

Что же, программирование, как профессия, с самого начала боролось с собственной смертью. Я полагаю, что когда кто-то впервые придумал Ассемблер, многие думали, что это конец профессии.

Какого лешего? Программа, которая превращает написанные каракули в настоящий машинный код? Значит, теперь каждый менеджер может писать код? Мы устарели? Нашу работу автоматизировали? Пора собирать вещи и уходить?

Далее появились языки высокого уровня. Такие языки, как FORTRAN и COBOL. Это определенно делает ненужными настоящих программистов, не так ли? Теперь вы можете быть инженером-механиком или бизнес-аналитиком и быть профессионалом с компьютером. Вам больше не нужен программист, чтобы писать за вас код.

А потом пришло индуктивное программирование. Функциональность, как в Haskell, или логика, как в Prolog. Идея индуктивного программирования заключается в том, что вы не пишете код, вы только устанавливаете ограничения, в которых должна работать программа, и, если возможно, язык сам напишет код для нее.

Код стал независимым от языка по мере того, как перерос в системы компьютерной алгебры. Теперь вы можете написать несколько уравнений в записной книжке Python и превратить их решение в код для любого другого языка. Таким образом, вам не только не нужен программист, чтобы писать код, даже не нужно писать код самому.

И хотя все эти вещи угрожали убить программирование как профессию, количество программистов росло, растет и продолжает расти. И даже экспоненциально. Каждые пять лет их число увеличивается вдвое. Численность программистов растет быстрее, чем человечество. При таких темпах все мы, все ~ 10 миллиардов будущих нас, к 2075 году будем иметь по три должности программиста.

Конечно, в какой-то момент этот рост должен прекратиться. В мире просто не хватит кокаина, чтобы мы все могли безостановочно заниматься программированием днями напролет. Но этот рост не остановится из-за каких-то прорывных технологий, а прекратится только тогда, когда спрос на другие профессии перевесит спрос на программистов.

Прорывные технологии, такие как ассемблер, языки высокого уровня, индуктивное программирование или искусственный интеллект, могут только изменить способ программирования, но не убить программирование как занятие.

По крайней мере, так я думал позавчера.

Вы можете подумать, что я початился с GPT-3, и это окончательно убедило меня перейти в гламурную и процветающую карьеру мужчины-проститутки. Но нет. Фактически, вчера был просто еще один день, когда я просто выполнял свою работу. Ну, вообще то, это не совсем моя работа. Я делал то, что должен был сделать за меня C ++, но он не смог. Я переносил фрагмент высокопроизводительного кода из MSVC в GCC.

Почему нам нужны высокопроизводительные программы в 2021 году? Память по-прежнему относительно медленная и имеет громадный объем, поэтому явное управление памятью все еще необходимо. Теперь у нас много ядер на процессор, поэтому нам нужны параллельные вычисления. Кроме того, процессоры работают не намного быстрее, чем 20 лет назад, но сейчас у них действительно много конвейеров, поэтому, если нам нужен быстрый код, мы должны суперскаляризовать все, что только можно. Итак, мы имеем три вызова.

C ++ - отвечает на все три весьма слабо.

1) Да, в C ++ есть стандартный способ выделения выровненной памяти, но MSVC его не поддерживает.
2) Параллелизм из коробки настолько анемичен, что вам приходится полагаться на сторонние библиотеки, такие как TBB от Intel.
3) Компиляторы пытаются использовать SIMD, когда это возможно, но они не могут сделать это эффективно, поэтому вам придется писать свой код в intrinsics функциях, чтобы получить нужный результат.

Это нормально, если вы на всю жизнь привязаны к Microsoft и Intel.

Но когда вы пытаетесь перенести что-то с одной платформы на другую, вы видите, что C ++ с годами незаметно проиграл игру переносимости. Да, вы можете бороться с несоответствиями выравнивания с помощью дефайнов. Технически вы можете сделать клон TBB для ARM, поскольку Intel, естественно, не заинтересована в поддержке своих конкурентов. Но с intrinsics функциями у вас тупик. Внутренние функции зависят от процессора, поэтому ваш код нельзя пере-оптимизировать или импортировать.

Это иронично, поскольку C изначально был изобретен для переноса того, что станет UNIX, с PDP-7 на PDP-11. Его единственной целью было обеспечение переносимости. Спустя 50 лет мы сталкиваемся с неприятной правдой. Чтобы добиться максимальной производительности, вы должны использовать инструкции процессора лучше, чем это делает компилятор. По сути, код возвращается к своему исходному виду, как на заре программирования.

Хорошо, но при чем тут ИИ?

Рад, что ты спросили. Я чувствую, что, хотя спрос на программистов по-прежнему наличествует на мировом рынке, спрос на инновации имел пик 70-х годах и постепенно снижается с годами.

Не будет другой прорывной технологии, столь же блестящей, как индуктивное программирование или даже языки высокого уровня, поскольку на них нет спроса. Я явно недоволен недостаточным развитием C ++ в области высокопроизводительных вычислений, но угадайте, будет ли лучше. Я не настолько несчастен, чтобы изобретать еще один Фортран. Судя по всему, и остальные тоже.

С ++ в общем работает. Он не идеален, но и не так уж плох. Вот почему он остается.

Да, я провел день, переписывая код с MSVC C ++ на GCC C ++, и это было скучно, и я написал это нытье, но это ничего не меняет. День - это просто день. Нытье - это просто нытье.

Теперь о революционных технологиях. Хотя ИИ пока не может делать все, что хотят от меня мои клиенты, у него есть все возможности для выполнения скучной части моей работы. Он может исправить несоответствия кросс-компилятора или оптимизировать код на внутреннем уровне. Даже повторная реализация parallel-for с помощью std :: threads выглядит достаточно утомительно, чтобы можно было делегировать ее машине.

AI даже может по завершению работы написать мне нытье.

Все это возможно, выгодно и, вероятно, легко для тех, у кого больше опыта работы с ИИ, чем у меня. Мы уже используем SymPy для написания кода на C ++, использование ИИ для оптимизации этого кода будет всего лишь одним маленьким шагом вперед, но люди с радостью сделают этот шаг. У такого ИИ есть стартовый потенциал, так что я ожидаю, что он появится в ближайшее время

Есть большая вероятность, что ИИ в конечном итоге заменит меня, может быть, не как программиста, а как программиста на C ++. Но есть небольшой шанс, что какая-то новая технология убьет сам C ++.

Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 14

    0
    Админы, что за фигня? Почему снаружи виден не отредактированный текст, а когда входишь, он становится нормальным?
      0
      В оригинале:
      What? A program that turns human-readable scribbles into real machine code?


      В переводе:
      Какие? Программа, которая превращает читабельные каракули в настоящий машинный код?


      Перевести what как какие в контексте статьи — это, конечно, верх мастерства. Я так понял после прочтения, вся статья — это какой-то кривой машинный перевод?

      UPDATE. По ходу да, изначально я увидел сырую версию текста, до того, как вошел под своим аккаунтом. Был неправ
        –1
        Похоже, это какая то бага нового редактора. Конечно, я беру сырой текст из Гугл переводчика и редактирую его. Но снаружи виден исходный текст — фигня какая то.
          0
          конечно, я беру сырой текст из Гугл переводчика и редактирую его
          и вам за это деньги платят?
            0
            Нет, не платят, а должны?
            Мне кажется, как и автору оригинально поста, что у часть работы, которую можно переложить на плечи компьютера, следует перекладывать, просто потому, что намного проще редактировать уже готовый текст, нежели набирать свой. По моим оценкам, раза в 3-4 быстрее и почему я должен этой возможностью пренебречь?
        –2

        Новые технологии будут, но в другом направлении. Не упрощения а стандартизации программирования.
        Программисты никуда не денутся, а c/c++ вымрет став лишь одним из вариантов синтаксиса поверх единого для всех языков ядра. Тонкой оптимизацией под конкретное железо займётся компилятор, а интрисинки вымрут окончательно.

          +1
          Автор оригинала завязался на проприетарные и не переносимые решения MSVC/TBB и жалуется что код на с++ не переносим. Ну вот какое отношение с/с++ имеет к тому, что aligned_malloc не реализуем на винде? MS должны были сделать винду posix совместимой еще в 80-е. В общем, ссзб.
          AI даже может по завершению работы написать мне напыщенную речь.
          rant здесь по смыслу ближе к «нытью» чем к «напыщенной речи» или «тираде»
            0
            Ну я не настолько продвинут в языке оригинала, чтобы менять термины, предложенные программой, написанной носителями языка, хотя, в данном конкретном случае, Вы скорее всего правы, мне почему то «нытье» не пришло в голову.
              0
              что aligned_malloc не реализуем на винде?
              А это по-вашему что?
                0

                это _aligned_malloc, который имеет совершенно другую семантику (несовместим с free/realloc)

                  0
                  Ничто не мешает для POSIX-ОС объявить aligned_realloc и aligned_free как синонимы для realloc, и free, и использовать именно эти синонимы при работе с выровненными данными, чтобы получался кроссплатформенный код.

                  Разработчики стандартной библиотеки VC++ могли бы сделать malloc и aligned_malloc совместимыми, но наверное их останавливает то, что тогда бы пришлось пожертвовать совместимостью с системным HeapAlloc, которая хоть и не заявлялась в документации, но какими-то разработчиками воспринималась как нечто очевидное, и какой-то софт на это наверняка полагается. Также катастрофически сломалась бы совместимость разных библиотек, использующих разные версии рантайма, где данные выделяются в одной библиотеке, а освобождаются в другой. Такой вариант использования тоже официально не поддерживается, но наверняка случается. Ну и Microsoft старается без острой надобности не ломать даже такие кривые случаи, когда код неправильный, и оно вроде как работает, но совсем по счастливому стечению обстоятельств.

                  Лучше бы, конечно, Microsoft добавила системный HeapAllocAligned, совместимый с HeapAlloc/HeapFree, и через лет 10 его можно было бы уже везде использовать без дополнительных танцев…
                    0
                    А это по-вашему что?
                    нестандартная функция сишного рантайма мс, не удовлетворяющая требованиям к aligned_malloc?
                    Ничто не мешает для POSIX-ОС объявить aligned_realloc и aligned_free как синонимы для realloc, и free, и использовать именно эти синонимы при работе с выровненными данными, чтобы получался кроссплатформенный код.
                    мешает то, что _aligned_free не может освобождать память, выделенную через malloc.
                      0
                      мешает то, что _aligned_free не может освобождать память, выделенную через malloc.
                      Это не мешает писать кроссплатформенный код. Выделил память через aligned_malloc/_aligned_malloc? Значит освобождай через algined_free (который под Windows будет синонимом _aligned_free, а под POSIX будет просто free).
              0
              На C/C++ написаны такие огромные и важные системы, что в ближайшие лет 100 он точно никуда не денется. Никто не станет переписывать тот же Blink на каком-то другом языке. Слишком дорого. Проще потихонечку причёсывать сам C/C++.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое