Недавно я прочитал сообщение Питера Бургона, в котором он описывает с набором примеров и изображений, как современное искусство и архитектура перешли от модерна к постмодерну. Давайте применим это различие к современным языкам программирования. Можно ли считать нынешнюю культуру языков программирования постмодернистской? Я имею в виду, что мы только начали. Если нынешние постмодернистские, что будет считаться модерном?
Тогда вы можете сказать - я могу дать вам этот ответ, но не хотите ли провести различие между ними? Так,
Это современно -
Это постмодернист -
Разве это не красиво? Сложный, но красивый.
Итак, как язык программирования может быть сложным, но красивым?
В последнее время я много занимаюсь программированием на Go в своей работе и побочных проектах. Я начал им пользоваться, потому что была необходимость. Но с тех пор это во мне приросло. Так же, как на тебе растет постмодернистское искусство. Языки программирования долгое время предназначались для правильного выполнения одной (а может быть и пары) вещей и предназначены именно для этого. Некоторые вводят функциональные концепции, некоторые упрощают использование функциональных концепций, некоторые лучше подходят для объектно-ориентированного программирования, другие - для параллельного ввода-вывода и т. Д. Когда вы в последний раз слышали, что язык разрабатывается для хорошего дизайна, внедряет передовой опыт и упрощает выполнение сложных задач? В этом суть Go (кроме того, что он просто лексер + парсер + компилятор + компоновщик, генерирующий машинный код). Звучит постмодернистски? Давайте посмотрим на пару образцов -
Печатание ›
Неслучайно система типов Го заимствована из языка, который считается пионером парадигмы «сложные идеи становятся простыми» - PASCAL (1970). Как и его предшественник, Go не требует строгих деклараций, и выбор остается за стилем каждого программиста. Итак, все нижеперечисленное являются одинаково допустимыми способами объявления переменной целочисленного типа без знака:
# var a uint32 # a := uint32(10) // or any other +ve 32 bit int # var( # a uint32 # ) # type A uint32 # var a A
То, как они смотрят на корку, может отличаться, но в сущности все они означают одно и то же. Даже это -
# type T uint32 # type A = T # var a A
Последний в Go называется «псевдонимом типов».
Каждый тип соответствует пустому интерфейсу, а любой тип соответствует непустому интерфейсу, если он реализует методы, определенные в указанном интерфейсе. Это неявный процесс. Здесь нет действующей директивы «орудия».
Компилятор Go помещает программу в Duck Test, чтобы узнать соответствующие типы. Вот почему иногда эту технику называют утиной типизацией во время компиляции.
Это слои в форме искусства, которые только опытный наблюдатель (в данном случае компилятор) может посмотреть, понять и понять. Детали могут не попасться обычному глазу, но это не снижает качества работы, которая привела к чему-то столь же интуитивно понятному и плавному, как это.
Отправка ›
Идея разделяемых изменяемых состояний - старая. Каждый язык на Земле предоставляет способ доступа к общим переменным через несколько потоков одновременным и безопасным способом. Go имеет коммуникационную конструкцию - канал, которая является потокобезопасной по своей конструкции, поэтому ее можно свободно читать или записывать из любого количества параллельных потоков. Канал обычно используется вместе с собственными горутинами, которые являются основным способом выполнения асинхронного программирования в Go. Этот вид многопоточности является вариантом разделения состояний в стиле CSP, который изначально был разработан C.A.R. Хоара в своей основополагающей работе 1978 года. Однако это не означает, что Go не поддерживает традиционные мьютексы. Оно делает. Он должен. Иногда это имеет больше смысла.
Другие языки на основе акторов, такие как Erlang и Scala, также поддерживают каналы или некоторую форму передачи сообщений. Здесь просто больше похоже на то, что здесь дома -
Поставить канал в очередь -
chan <- 1
Удалить канал из очереди -
<- chan
Один или несколько каналов могут быть общими для горутин и при этом иметь для них разное значение. Затем программист может использовать эти знания для создания любого количества отправителей / получателей (есть некоторые подводные камни при правильной обработке каналов, например, буферизованные или небуферизованные, копирование по значению или указателю и т. Д., Но это тема для другого дня).
Фундаментальные идеи параллелизма остаются неизменными, и все же ваша программа или, скорее, интерпретация решения может сильно отличаться от моей.
Когда вы возвращаетесь с художественной выставки или архитектурной экскурсии, то, что остается с вами, - это форма и ощущение изображения. Он во многом укоренился в вас, как и традиционные концепции программирования в современном мире вычислений. Они стареют, теряют форму, но не перестают удивлять вас снова и снова. Это характеристика постмодернистского искусства. Это характеристика постмодернистского языка программирования.
Спасибо за прочтение.
