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

Наши инструменты

Делаем это с помощью инструментов. Как любой хороший ремесленник, мы приспосабливаемся к инструментам, которые используем, чтобы научиться решать проблемы людей. Мы делаем это настолько хорошо, что часто в конечном итоге делаем все больше и больше работы для самого инструмента и все меньше и меньше работы для решения проблем людей. Видите ли, проблема в том, что у нас есть желание освоить и приспособиться к инструменту, который у нас есть. Мы поняли это неправильно. Инструмент должен подстраиваться под нас. Как мы работаем, как читаем, как пишем. Эргономика имеет значение. Возможно, это самая большая инновация ChatGPT. Они придумали один из самых эргономичных способов взаимодействия со своей моделью: естественный язык.

О Котлине

На мой взгляд, одним из самых больших преимуществ Kotlin являются не классы данных, сопрограммы, синтаксис when или какие-либо из этих отдельных функций, которые Java будет заново реализовывать в течение следующих нескольких десятилетий. Видите ли, Java с запечатанными классами, записями и так далее остается и всегда будет Java. Конечно, у многих разработчиков с мозолями в форме Java не будет проблем с этим. Они привыкли писать код для Java, и их устраивает плата, которую они за это получают. Для меня самое большое преимущество Kotlin в том, что он побуждает вас писать код для людей. Для людей, которые должны будут прочитать его, расширить его, сохранить его живым. Для людей, которые не будут проклинать ваше наследие.

Но не поймите меня неправильно, я не говорю, что сам Kotlin заставляет писать лучший код. Конечно, удобно использовать функции Java 25 с 2018 года, но вы все еще пишете код для машин. Kotlin позволяет вам и рекомендует в первую очередь писать код для людей. Но вы должны использовать Kotlin как Kotlin, а не как замену Java 34. Конечно, ваш код Spring Boot может потерять несколько строк здесь и там, но у всех нас был разговор с этим членом команды, который сказал: «Да, круто, но почему бы не придерживаться Java до Java 42 с Project Gollum? Это то же самое". Эти коллеги правы. Project Gollum и Project Nirvana предоставят лучшие способы выполнения функционального программирования и объектно-ориентированного программирования, как только Java 48 выйдет в следующий вторник, но знаете что, это уже старые новости.

Куда дальше?

Языки программирования распределены по уровням. Ассамблею можно рассматривать как низшую, а человеческий естественный язык — как высшую. Для каждого языка мы разработали парадигмы. Благодаря Java и другим ООП стал популярен. С появлением Scala и Kotlin некоторые концепции FP стали мейнстримом. Тенденция заключается в очевидном переходе к постоянно возрастающим уровням абстракции. С ChatGPT и другими моделями мы сейчас наблюдаем появление новой парадигмы, люди, работающие над ней, называют себя «Prompt Engineers», я полагаю. Итак, у нас есть эти парадигмы: императивная, объектно-ориентированная, функционально-ориентированная. Возможно, следующим будет человеко-ориентированное программирование. Возможно, в будущем мы все будем развиваться в стиле HO. Я не уверен в названии, но я думаю, что «HO» может быть прилипчивым. Кто знает, может быть, дойдет до того, что ГО можно будет увидеть абсолютно везде, как, например, в Вегасе.

Стиль ChatGPT HO, кажется, таков, как идут дела. Это может быть конечная точка, или, возможно, она будет вытеснена материалами с поддержкой Nerulink. Но мы еще не там. ChatGPT недостаточно точен, чтобы позволить нам писать сложные и надежные программы. Инструмент еще не готов, но что, если мы пока просто возьмем стиль?

Но как?

Я много лет обдумывал эту идею и написал Snitch, чтобы удовлетворить свое любопытство по поводу HO. Как мы можем справиться с довольно жестким аспектом разработки, таким как разработка на уровне HTTP, максимально человечным образом? Вот так выглядит Снитч:

withTransaction {
    POST() with body<CreateUserRequest>() isHandledBy createUser
    POST("login") with body<LoginRequest>() isHandledBy userLogin
    userId / "posts" / {
        authenticated {
            GET() onlyIf principalEquals(userId) isHandledBy getPosts
            POST() onlyIf principalEquals(userId) with body<CreatePostRequest>() isHandledBy createPostGET(postId) isHandledBy getPost
            PUT(postId) with body<UpdatePostRequest>() onlyIf principalEquals(userId) isHandledBy updatePost
            DELETE(postId) onlyif (principalEquals(userId) or hasAdminRole) isHandledBy deletePost
        }
    }
}

Я не буду делать вид, что это само по себе что-то новаторское. Многие другие фреймворки могут делать что-то очень похожее. Но обратите внимание на детали. Просто взглянув на код, вы можете сказать, что конечные точки, объявленные внутри блока withTransaction, будут иметь транзакцию. Что некоторые конечные точки, но не другие, являются authenticated и что некоторые конечные точки имеют проверки, которые выполнили onlyIf некоторые условия. Отличие состоит не в том, что делает Snitch, а в том, как он это делает и, что более важно, в том, что он делает это с явным намерением. У этого есть прецеденты, например, мы столкнулись с Gherkin, и мы знаем, что Ruby и RoR проделали большую работу по улучшению читабельности. Http4k на самом деле довольно хорош в этом отношении, и с его помощью вы можете добиться замечательных результатов. Но зачем останавливаться на достигнутом?

Заключительные мысли

Человеческий язык великолепен, а ChatGPT чрезвычайно эргономичен, но, как подтвердит любой оперативный инженер, человеческий язык также удручающе расплывчат, если вы хотите каждый раз получать какое-то точное поведение. Мы хотим писать код для людей, сотрудничая с другими людьми, и, похоже, мы хотим сделать это как можно более человечным, потому что, знаете ли, мы люди. Но мы должны быть точными и точными, когда взаимодействуем с машинами и диктуем их поведение. Возможно, стоит посмотреть, как этот стиль HO может или должен выглядеть на практике. С Kotlin и Snitch я изучил эту тему, чтобы увидеть, к чему она ведет. Скорее всего, любой такой подход в лучшем случае является временной мерой, пока подходы, подобные ChatGPT, не станут более совершенными и точными. Но, возможно, ChatGPT застрянет на локальном минимуме и не сможет полноценно дополнять языки программирования и фреймворки. В этом случае, возможно, нам будет лучше с чем-то, что движется дальше в этом направлении, но все еще в некоторой степени основано на некоторых проверенных в бою концепциях устаревшего программирования. Что теперь вы думаете об этом?