Фантастика программирования

Это не футурология, поскольку планка у футурологии поболее, а кроме того, интересно не "как будет", а "как могло бы быть".

Сразу скажу, что тема "программистов скоро заменит машина" и аналогичные - стара, как само программирование. Причём на всех уровнях, уже в 90е пытались реализовать эти идеи, а ведь ещё раньше их просто думали!

Но как видно, программисты всё ещё нужны.

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

Потому что у нас есть примерно такая цепочка: заказчик - аналитик - архитектор - кодер. (А ещё есть тестировщики, всяческие специалисты по UI и т.п.)

В обиходе программистом называют того, кто пишет код, тут я обозначил это сленговым "кодер". (В данном случае подразумевается джун, которому необходимо ставить задачи.)

Фактически же программистами являются все, кроме заказчика. Если они и не пишут код, то как минимум понимают, как он работает, что технически возможно, и что допустимо по затратам, сложности.

ИИ может заменить в какой-то там далекой перспективе ну кодера.  Остальным ИИ может только лишь ассистировать.

Мечта же некоторого менеджмента - найти такую систему программирования, которая избавит фирму от всех, кроме самого менеджера и нескольких низкооплачиваемых низкоквалифицированных сотрудников, которые и будут объяснять ИИ хотелки заказчика. Иногда мечты более реалистичны, и подразумевается, что останутся и квалифицированные аналитики, разбирающиеся в предметной области.

Фактическая же реальность такова, что самые низкооплачиваемые как раз таки кодеры, которых ИИ может и заменит, но радости от этого мало. Тем более, что через должность кодеров проходит весь тот персонал, что позже становится архитекторами, аналитиками и т.п.

Тестировщиков и т.п. заменить так же не получится - так как системы написанные для людей просто о определению тестировать приходится людям. Всё что можно автоматизировать там давно автоматизируется. ИИ тут опять же не заменяет, а может ассистировать.

В итоге, если мы представит максимально футуристичное программирование, которое хоть как-то работает, то у нас получится набор программистов:

- аналитик, который занимается "переводом" хотелок заказчика с разговорного на формальный язык ТЗ. 

- архитектор, который проектирует систему под это ТЗ.

- небольшой штат высококвалифицированных программистов, которые помогают ИИ реализовывать нестандартные решения

- тестировщики, девопсы и т.п.

Такая схема ничем толком не отличается от нынешней небольшой конторы. Потому что задачи не меняются.

Архитектор от общения с заказчиками поседеет и уедет нафиг лечить нервы. Если ИИ дорастёт до замены архитектора, то он дорастёт и до эквивалента человеческого разума. 

Аналитику же нужен хороший навык общения с людьми, поиска компромиссов, и умения разбираться в бизнес процессах заказчика. Заказчик общаться с ИИ не станет, а ИИ не сможет залезть в тёмные недра производства и у рядового менеджера вытребовать разъяснений по странному бизнес-процессу, который "судя по официальному описанию, смысла не имеет".

Нестандартные решения - занимают 80% времени разработки. Всё что стандартно давно есть в библиотеках программирования и наваливается чуть ли не автоматически. (А то и готовое.) Можно посмотреть кучи обучающих видео - пока задачи не выходят за границы шаблона, то программирование легко и быстро. Но в реальности всё не так.

Ладно, команда разработки выглядит как-то не футуристично. Хотя там все будут телепатически общаться с ИИ, носить импланты и всё такое прочее. Но в целом всё по старому. 

Может язык программирования станет футуристичным, в картинках?

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

Проблемы у этого:

- Возюкать кубички это долго и неудобно (для программиста, а как я писал выше, там все программисты). Феномен в том, что систему с кубиками придумывает тот, кто не программирует, "для себя". Кроме того приходится часто переключаться между клавиатурой и мышью, чтобы вбивать значения. А уж найти ошибку в этих макаронах...

- Программа на кубичках выглядит просто и наглядно, пока там полтора кубичка. Как-только кубичов становится больше, то всё быстро запутывается больше, чем текстовый код, например вот в блендере: https://author.today/post/428901 - схема на третьем скриншоте в виде текста ну заняла бы полтора экрана примитивного кода. (У меня есть эпическая схема генерации города, там вообще мрак.)

- Если возникает задача сделать что-то нестандартное, то кубичков становится очень много, всё это превращается в кошмар и макароны. А нестандартное нужно почти всегда, когда возникает задача что-то программировать.

Ну хорошо, картинки не подходят, а просто программы на человеческом языке?

Ответ: Программами на человеческом языка люди каждый день пользуются в быту (на протяжении тысяч лет), чтобы программировать друг-друга. Книги тоже пример "программ на человеческом языке". Как показывает опыт, в значительном числе случаев нихрена не понятно, что же конкретно имелось ввиду. Потому пока не будет формально точного и однозначного человеческого языка, к этой идее можно не возвращаться.

Ну хоть чуть-чуть?

Комичным примером хоть чуть-чуть человеческого языка программирования является SQL:

в 1973 году, Чемберлин и Бойс начали работу над совершенно новым языком, который был назван SEQUEL (от Structured English QUEry Language, «английский язык структурированных запросов»). Авторы надеялись, что после небольшой практики даже пользователи-неспециалисты (например, бухгалтеры, инженеры, архитекторы, градостроители) смогут читать запросы так, словно последние написаны на обычном английском языке. Язык был назван «декларативным», поскольку он описывал желаемый результат, а не детальный план поиска этой информации.

Лет десять назад мы занимались разработкой генератора запросов на SQL, который выдавал запросы в пяток экранов (есессно с подзапросами, функциями и прочими фишками). Есессно, такой хтонический трындец не то что бухгалтеры читать не смогут, это даже мы читали с трудом и часами, когда там генерировалось "что-то не то". 

И сейчас в почти любом крупном и среднем проекте SQL не используется напрямую, а через "упрощающие" прослойки. При том, что сам по себе язык то прост, пока задача стандартная, а как только задача не стандартная, то ой. А как я уже не раз писал, они всегда "нестандартные".

С другой стороны, тенденции к ктулхизированию языков (превращению в нечитабельную хренопись из небуквенных символов) программирования тоже нет. Для ценителей давно есть perl и более загадочные штуки. А программирование давно и прочно ушло в массы,  с одной стороны. То есть требуется небольшой порог входа. С другой, философы процесса разработки ПО, давно уяснили, что программный код должен быть понятным, однозначным и т.п. То есть тут с одной стороны "давит" понятность, с другой стороны "выразительность" - и широкие языки программирования (высокого уровня, есессно) балансируют посередине.

И нет никаких признаков, что тенденция когда-либо поменяется. Так что в фантастике не обязан быть жаваскрипт (ха, исходный он кстати весьма не очевиден из-за прототипов) или сишарп, но что-то похожее по уровню. Может с квадратными скобочками вместо фигурных, может не на базе английского, а на базе египетских иероглифов (иероглифы это кстати не очень удобно - давать имена объектам муторно). Может с большей примесью функциональщины или вовсе на прототипах - ООП то популярно именно из-за исторических предпосылок и интуитивности. 

Но в любом случае это будет тарабарщина для специалистов, а не для широкой публики.