Комментарии 14
Так что, вероятно, нас ещё ждут новые языковые парадигмы, которые
ответят на запросы нового времени. Как думаете, какими они будут? Есть
ли у вас запросы, на которые языки пока что не ответили?
Обработка больших данных и тензорные вычисления на уровне базового синтаксиса языка, а не с помощью использования дополнительных библиотек.
Это нужно для того, что бы "больше времени" тратить непосредственно на алгоритм, а не на написание текста для вызова различных оберток над данными.
Это нужно для того, что бы "больше времени" тратить непосредственно на алгоритм, а не на написание текста для вызова различных оберток над данными.
Это зависит от того как хорошо или профессионально написана обёртка. Возьмите любой скриптовый язык, например, упоминающиеся в статье JavaScript, PHP, Python, или мною уважаемый tcl (tcl/tk), ведь без наличия в них широкого спектра пакетов/балалаек/модулей, т.е. тех же обёрток, они были бы мало интересны.
А я имею ввиду не качество реализованной обертки, а многословность и сложность написания того или иного алгоритма с её помощью. Ведь если смотреть на историю развития программирования, то можно увидеть, что постоянно повышается уровень абстракции, которыми оперируют люди при разработке вычислительных машин и алгоритмов.
Сперва, реализация непосредственно в железе, потом, машинные коды, далее ассемблер, языки высокого уровня, ООП ... И с каждым этапом добавляются новые возможности, а старые становятся лишними и неудобными для использования.
Сейчас мейнстрим - тензорные вычисления, но нет языков, которые их поддерживают из коробки на уровне синтаксиса. И это отвлекает от решения основной задачи, т.к. приходится работать с обертками на старых языках программирования, синтаксис которых разработан еще в прошлом веке.
А я имею ввиду не качество реализованной обертки, а многословность и сложность написания того или иного алгоритма с её помощью.
Но это же и зависит как раз от того как написана обёртка. Кстати, всё это относится и к языкам. Что такое повысить уровень абстракции, ведь его кто-то должен обрабатывать, а это может быть и транслятор и компилятор и препроцессор и интерпретатор и библиотека!
Сейчас мейнстрим — тензорные вычисления, но нет мейнстримовых языков, которые их поддерживают из коробки на уровне синтаксиса. И это отвлекает от решения основной задачи, т.к. приходится работать с обертками на старых языках программирования, синтаксис которых разработан еще в прошлом веке.
Так может для начала переработать обёртку, чтобы она была из нашего века, а не из прошлого?
Но это же и зависит как раз от того как написана обёртка.
Потому что изначальных синтаксис языка это не предполагает, поэтому и приходится использовать обертки.
Я думаю, что новые парадигмы программирования, это оперирование тензорами или даже целыми понятиями. А возможно и создание языков программирования на основе каких нибудь регулярных человеческих языков для прямого общения между машиной и человеком.
Это называется APL. Из более модерновых - Julia
Simula и Smalltalk - не совсем ООП. К современному его пониманию они не имеют вообще никакого отношения. Simula, при всей её фундаментальности, создавалась с достаточно узконконретной задачей - имитационное дискретное моделирование (Discrete Event Simula-tion)
Описаная эволюция скорее не самих языков программирования, так как тут каждый сам за себя в своей области эволюционирует, а методов формализации знаний о мире. Какие слова и значки используются не настолько важно, как сам подход к формальному описанию решения задачи. Пока создали два независимых подхода: формализация через объект и формализация через функцию. На мой взгляд следующий уровень отойдет от строгого описания алгоритма, программист будет переводить в формальное описание новым языком программирования не решение задачи, а само условие задачи для того, чтобы исполнитель типа ИИ искал ее решение. Но чтобы начать ставить задачи таким образом надо создать то, что будет ее решать.
А в рамках существующих подходов эволюция идет в область расширения сфер применения, соотвественно все большее число функций и объектов надо описывать. Сначало это поиск наиболее удобного и быстрого способа формализации новой сферы с созданием нового языка, а потом попытки создать один инструмент, позволяющий решать любую поставленную задач. И вот здесь можно будет заметить эволюционные изменения в рамках одного языка (Примерно как менялись FORTRAN, C, C++, Java)
Язык программирования, в первую очередь, это язык коммуникации одного программиста с другим. Коммуникация программист - компьютер имеет значение, но, чем дальше, тем все более второстепенное. И именно из-за этого языки программирования будут развиваться по законам в чем то сходным с законами развития естественных языков. Так же как в естественных языках мы "коллективно договариваемся" о новых словах для обозначения новых явлений, типовые решения для задач замеченные по мере накопления опыта появляются в виде новых синтаксических конструкций.
Если пофантазировать, то вполне может быть, что дальнейшее развитие языка будет сочетаться с нейросетями и позволит уйти от конкретного синтаксиса и даже языка для большинства задач, описывая логику работы программы, а не конкретный код. А конкретный код мог бы в рамках описанного генерироваться сеткой, подобной AlphaCode.
В этом смысле весь процесс развития инструментов выглядит как путь от машинно-ориентированного языка на человеко-ориентированный. Вместе с ростом мощности вычислений и сложности это вполне разумный и даже необходимый переход.
В целом дебаты о GOTO, разгоревшиеся в 60-е и 70-е, закончились тем, что некоторые новые языки и реализации существующих не включали пресловутый оператор безусловного перехода в явном виде
Вот в Python нет GOTO, но в любом учебнике по этому языку показано как его вставить в собственную софтинку. Правда в Python это называется обработка исключений и реализуется не без танца с бубнами. Иногда, когда нужно выйти из нескольких вложенных циклов одним махом, жалеешь, что в Python нет GOTO. Я раньше выходил всегда через исключение, а сейчас всё чаще использую генераторы в заголовке цикла 'for', чтобы выйти одной командой 'break' или продолжить цикл с новыми переменными через 'continue'.
GO
Спрос рождает предложение: как потребности программистов выливались в языки программирования