Есть ли основания полагать, что языки программирования сойдутся?

Сегодня на Земле, несмотря на то, что большинство людей немного говорит по-английски, по-видимому, нет оснований полагать, что основной язык будущего поколения останется тем же самым через десятилетия/столетия (т. е. у нас будут разные родные языки и мы будем изучать общий язык). позже в жизни).

Точно так же существует куча разных языков программирования. Но процесс итерации здесь намного быстрее. Регулярно создаются новые языки программирования, старые устаревают...

Есть ли основания полагать, что языки программирования сойдутся в единый язык в ближайшие десятилетия/столетия?

Я думаю, что для того, чтобы языки сошлись, нам сначала понадобится аппаратное обеспечение. Параллельные вычисления вынуждают некоторых переходить с современных языков, таких как Java, на более подходящие. Хотя, если у нас есть экзафлопсные персональные компьютеры, то кому нужны эти надоедливые хорошие алгоритмы. Языки высокого уровня не будут сильно отличаться от языков низкого уровня.
В последнее время я мечтаю об одном хорошем языке, который будет уметь все, но это не так просто. К настоящему времени все методы управления компьютером можно представить как один большой сложный язык. Хороший унифицированный язык мог бы использовать все парадигмы, избегая ненужных противоречивых соглашений, таких как размер и длина, но, например, а) людям нравятся разные вещи, и они могут не легко согласиться б) унификация в любом случае потребует очень много работы.
Конечно нет причин. Как именно вы собираетесь «сводить» такие вещи, как Brainfuck и Haskell?
На самом деле есть два типа программистов: те, кто гонится за новейшим языком, полагая, что он решит все их проблемы, и остальные, которые выполняют полезную работу. Могу поспорить, что через столетия люди по-прежнему будут использовать C и FORTRAN, а причудливые языки пойдут по пути SNOBOL, Forth и многих других, названия которых я даже не могу вспомнить.
Это вопрос, который иногда задают на Programmers.SE: почему бы нам не создать один универсальный язык? Потому что семантика высокого уровня может быть несовместима, а проектирование ЯП — это игра компромиссов .
@ Mints97 Mints97 Честно говоря, Brainfuck задуман как пародия на язык программирования. Я бы предпочел, возможно, LISP, C и Perl. По крайней мере, все они были разработаны для реальных целей.
@BartekChom Да. Microsoft тоже начала с OpenGL — они ушли, чтобы сделать свой собственный DirectX , потому что им нужно было создавать программное обеспечение . Комитет просто слишком долго решал самые простые вопросы. Объединение — заманчивая перспектива, но она также медленная, болезненная и негибкая. Если Один Путь причиняет вред, кто-то создаст Другой Путь, который не вредит, и ваши усилия по объединению напрасны.
Я не понимаю предпосылку... Если C++ сходится с Java, на самом деле происходит то, что вы используете Java. Если появится новый язык, представляющий собой смесь Java и C++ (и, предположительно, лучший, чем оба), это будет не конвергенция Java и C++, а новый, другой язык (то есть это не «два сходящихся в один язык»). один" как "появляется новый, а два других забрасываются")...
Сообщества Perl и Python когда-то пытались объединиться ;-)
Языки действительно устаревают, но очень медленно, чистый C все еще широко используется в определенных областях, но для более крупных проектов это вообще не оптимальный выбор. Таким образом, кажется, что всегда будут разные языки для разных ситуаций (например, драйверы и веб-приложение для бизнеса).
Почему языки программирования должны конвергировать? В конце концов, это инструменты. Сходятся ли кузнечные инструменты? Сходятся ли столярные инструменты?
@el.pescado Ну, у нас есть фабрики, которые могут делать практически все из металла или дерева...
@Sheraff Тем не менее, если фабрика хочет сделать что-то из металла, она может это отлить, она может это сделать с ЧПУ, прокатать, сварить из более мелких деталей… Множество методов.
Обязательный xkcd по теме xkcd.com/927 Частично проблема в том, что не все согласны с тем, каким должен быть этот язык программирования.
Может быть, если ИИ будущего, который сам себя программирует, сможет прийти к соглашению. Но я сомневаюсь, что они тоже могут.
Этот язык программирования уже существует, он называется языком ассемблера. Это НОД всех языков.
С языками программирования это еще менее вероятно: некоторые люди получают больше удовольствия от изобретения новых языков программирования, чем от реального программирования. Новые естественные языки возникают чаще всего непреднамеренно; новые языки программирования, напротив, появляются потому, что в умных людях заложено стремление к инновациям. Обратите внимание, что это не стремление к консолидации; это стремление смело идти туда, куда еще не ступала нога человека.
Поскольку все остальные представили хорошие аргументы, я привожу аргумент по аналогии: лучше иметь один инструмент для каждой работы, чем швейцарский армейский нож для всех.

Ответы (20)

Это технически невозможно, по крайней мере, без отказа от функциональности.

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

Другим важным примером является то, как обрабатывается память. В языках сценариев (и даже в некоторых скомпилированных языках) память в значительной степени не находится в руках программиста и управляется интерпретатором или какой-либо другой системой. Напротив, языки более низкого уровня предоставляют возможность напрямую манипулировать памятью и обращаться к ней, например, к указателям C/C++.

Хотя можно подумать, что, возможно, с ростом производительности мы когда-нибудь перестанем заботиться о низкоуровневом программировании и все начнем использовать какой-то странный аналог PHP для всего, я думаю, что это непонимание того, как на самом деле устроен мир. Я считаю C/C++ языком низкого уровня, как и большинство людей; но когда-то, и до сих пор среди некоторых, это был язык высокого уровня, а низкий уровень был бы подобен ассемблеру. Это не просто терминология: по мере того, как меняется постановка вопроса об эффективности, меняются и ее меры. Упрощения, которые мы теперь можем считать слишком дорогостоящими для реализации даже в интерпретируемых языках, однажды могут стать обычным явлением среди языков «высокого уровня», Java может считаться «низкоуровневым»,

Я думаю, что по этой причине гораздо меньше шансов, что языки программирования сойдутся, чем разговорные языки. Человеческий язык выполняет одну фиксированную задачу — передавать информацию. Хотя вы можете утверждать, что разные языки лучше или хуже в какой-то части этой цели, чем другие, все они могут достичь этих целей. Однако есть вещи, которые вы просто не можете сделать в PHP. Есть также вещи, которые ни один здравомыслящий человек не стал бы делать (в наши дни) на ассемблере.

Один из способов подумать об этом может быть таким. Если бы завтра все в мире бегло говорили по-валлийски, что бы произошло? Что ж, все смогут общаться на валлийском, переводческие услуги будут дешеветь, и, возможно, лук-порей станет более популярным. Если бы завтра единственным доступным языком программирования был JavaScript, мы все были бы в полной заднице.

Это не считая инерции. В человеческом языке инерция в основном связана со способностью читать старые литературные произведения, что редко является решением при принятии решения об изучении нового языка и никогда не является решением при изучении родного языка. Хотя потеря понимания классических произведений была бы культурной потерей, вряд ли это побудит к действиям в больших масштабах. С другой стороны, необходимость перепрограммирования ядра Linux, Windows, почти всех драйверов устройств и веб-серверов определенно повлияет на более широкие решения языков программирования. То, что COBOL все еще живет, на мой взгляд, является довольно сильным аргументом против конвергенции языков программирования.

Тем не менее, есть один момент, в котором можно ожидать некоторой конвергенции языков программирования: синтаксис. Это уже происходит, и C-подобная семья в значительной степени победила. Языки C, C++, Java, JavaScript и PHP в основном имеют идентичный синтаксис, сопровождаемый некоторыми изменениями в операторах, в основном отражающими присущие им различия. Никакой работы с указателями *и &в PHP, никакой забавной и простой конкатенации строк .в C. Однако, помимо этого, эти языки почти полностью взаимно понятны, по крайней мере, в структуре. Альтернативным семейством может быть линия BASIC, включая VB и, я бы сказал, Python.

Я согласен, если вы в основном занимаетесь текстовыми манипуляциями, вы не хотите использовать все функциональные возможности полнофункционального языка, такого как C++, поэтому вы придерживаетесь COBOL. И наоборот, если вы просто выполняете математические вычисления, вы можете использовать FORTRAN, а не C++. По сути, мы можем создать язык, который «делает все», но за счет усложнения его использования, если вам нужно только подмножество функций. ИМО, мы всегда будем хотеть и использовать специальные языки, даже если они нам не нужны .
На самом деле, C, в частности, очень снисходительно относится к типам: вы можете привести что угодно к чему угодно, и это будет «просто работать». Очевидно, что вы не получите желаемого результата, если попытаетесь использовать a char*как a short(если, конечно, это не то, что вы хотели сделать ), но компилятор позволит вам; он может выдать предупреждение, и многие компиляторы имеют настройку для обработки предупреждений как ошибок, но это все. Я помню, как играл с указателями памяти в C еще в 90-х, под DOS; указатель short*на видеопамять, трактуя его как chars для записи на экран.
Согласовано. Компания, в которой я работаю, поддерживает/разрабатывает программы на CFML, COBOL, VB, Ruby и т. д. и имеет несколько различных форм баз данных, а также использует javascript. У каждого из этих языков есть свои сильные и слабые стороны, и я не вижу возможности объединить их все в один язык, который не был бы полным беспорядком.
Что останавливает языковую форму, включающую как ручное, так и автоматическое управление памятью? Или включить как статическую, так и динамическую типизацию? C# (очень популярный современный язык программирования) имеет как статическую типизацию, так и тип, называемый динамическим , который имитирует динамическую типизацию, используемую в языках сценариев.
@JohnColanduoni Сочетание динамической и статической типизации, например, с помощью различных форм постепенной типизации и частичного вывода типа, является актуальной темой в разработке и исследованиях PL. Комбинация автоматического и ручного управления памятью невозможна, если доступ к памяти, управляемой вручную, осуществляется только через слабые указатели, которые явно могут стать недействительными в любое время — необходимо гарантировать, что автоматически управляемая память никогда не будет освобождена, пока она все еще доступна. Таким образом, в комбинированной системе память, управляемая вручную, будет иметь тип, отличный от автоматической памяти.
@amon Им не нужно было бы иметь полностью отдельные типы. Например, у вас может быть тип слитного указателя, который не позволяет хранить указатель; вместо этого он позволяет только получить доступ к объекту или передать указатель на подпрограммы с тем же ограничением. Пока это подпрограммы (т. е. они выполняются только во время выполнения вызывающего объекта), не имеет значения, управляется ли значение вручную или автоматически, поскольку вызывающий объект поддерживает ссылку на него (хотя при ручном управлении памятью можно, конечно, удалить указатель в любое время).
@JohnColanduoni С++ вроде как идет по этому пути с такими вещами, как «умные указатели», но вам все равно нужно вызывать его, и отсутствие универсального выбора одного или другого в системе вводит собственные ограничения и сложности. Я не уверен, что это хорошая идея смешивать оба, но это в основном мое мнение, и многие люди явно не согласны с этим, поскольку это продолжается. Теперь, если бы у вас был язык, режим которого вы могли бы переключать, это также могло бы стать более философским подмножеством этого вопроса: если бы существовал язык, который мог бы делать все, но не все сразу, был бы он действительно одним языком?
Управление памятью и проверка типов на самом деле являются двумя функциями языка, которые, как я ожидаю , станут стандартом в течение ста лет. Обе эти проблемы являются проблемами, которые для 99% реалистичных программ имеют решение во время компиляции, но найти его трудно; по мере того, как компьютеры становятся невероятно мощными, становится возможным гораздо больше автономного анализа полноразмерных программ.
«Если бы завтра единственным доступным языком программирования был JavaScript, мы все были бы в полном дерьме». Будьте осторожны, мы можем увидеть день, когда C будет скомпилирован в Javascript, поэтому его можно будет запускать с помощью движка JavaScript, который будет JIT-компилировать его в фактическую сборку;)
@hyde Я думаю, у тебя есть отличная концепция антиутопического научно-фантастического сеттинга!
@hyde Вы имеете в виду как asm.js ?
Строго говоря, почти все языки программирования сегодня являются полными по Тьюрингу, и все полные по Тьюрингу языки могут делать все то же, что и любой другой полный по Тьюрингу язык, при наличии бесконечного времени и памяти. Таким образом, утверждение, что «Однако есть вещи, которые вы просто не можете сделать в PHP», просто неверно — есть много вещей, которые было бы ужасно пытаться сделать в PHP (на самом деле, как кто-то с большим количеством профессионального опыта с этим, я бы сказал, что пытаться сделать что- либо на PHP довольно ужасно), но вы могли бы .
@KRyan Полнота по Тьюрингу нарушается, когда вам приходится иметь дело с реальным оборудованием (полнота по Тьюрингу касается только реализации алгоритмов , а не выполнения соответствующих действий с электрическими сигналами). PHP не может обрабатывать прямую адресацию памяти, точка. С/С++ может. То, что требует прямой адресации памяти, не может быть написано на PHP.
@cpast Я думаю, что хороший тест: «Можете ли вы реализовать этот язык на этом языке?» Поскольку PHP нужен интерпретатор, ответ — нет. С другой стороны, компиляторы и библиотеки C/C++ в основном написаны на C/C++.
@ John Colanduoni: What stops a language form including both manual and automatic memory management?Взгляните на язык программирования D, который пытался заставить эту работу работать, и в основном потерпел неудачу по причинам, которые совсем не удивят любого, знакомого с законом Грешема .
Я согласен почти со всем этим, и все же я должен отметить, что все языки являются полными по Тьюрингу, вы можете делать что угодно на любом языке ... если вы достаточно мазохист, чтобы попробовать. Однако я согласен с тем, что некоторые языки НАМНОГО лучше подходят для достижения определенных целей, и попытка запрограммировать крошечный процессор в устройстве с использованием Python, вероятно, будет плохой идеей. По большей части человеческие языки примерно одинаково хороши для передачи понятий; языки программирования намеренно разрабатываются для наилучшего достижения определенных целей.
Мало того, что не все языки полны по Тьюрингу, число таких языков растет. Для реального программирования TC создает больше проблем, чем решает: еще один столетний прогноз будет заключаться в том, что полнота по Тьюрингу, скорее всего, в какой-то момент уйдет из мейнстрима. Оказывается, возможность доказать что-то о выполнении вашей программы на самом деле полезно, кто бы мог подумать.
Неявное предположение о продолжении использования архитектуры фон Неймана через 100 лет почти смехотворно и делает многие аргументы, связанные с указателем, доступом к памяти и т. д., спорными. Не забывайте о квантовых компьютерах... Еще я хотел бы отметить, что в следующие 10 или 20 лет у нас будет программирование на естественном языке, когда мы просто говорим с компьютером, и он переводит наши намерения в то, что мы сейчас называем язык «высокого уровня». Как только это произойдет, те, кто пишет интерпретатор естественного языка, вероятно, выберут один или, возможно, два языка, которые будут делать все, что нам нужно.

Есть ли основания полагать, что языки программирования сойдутся в единый язык в ближайшие десятилетия/столетия?

Как программист, я, конечно, надеюсь, что нет. Скорее всего, это будет огромным неудобством практически для всех и практически никому не принесет пользы.

Разные языки хороши для разных типов задач. Если вы пишете короткий сценарий, чтобы скрыть поле на веб-странице, когда пользователь делает определенный выбор в форме, вам не нужна способность C напрямую манипулировать любым адресуемым адресом памяти, но на самом деле вы не можете иметь C без понятия указателей. (Вы можете не использовать их, но это сильно ограничивает ваши возможности; например, теперь у вас нет встроенной в язык конструкции, которую можно было бы использовать для строк переменной длины, поэтому вам нужно заново изобрести этуколесо.) Если вы пишете операционную систему для работы на «голом железе», отсутствие в Javascript контроля соглашений о вызовах, управления памятью и обработчиков прерываний сделает задачу почти невыполнимой, если не полностью невозможной. Если вы обучаете кого-то основам программирования как концепции, ассемблер не поможет (он слишком углубляется в мельчайшие детали сложения двух чисел или доступа к памяти); с другой стороны, если вы пишете критический раздел обработчика высокочастотных прерываний, PHP, вероятно, не тот язык, который вам нужен. Язык со сборкой мусора, такой как Java, — плохой выбор для системы реального времени .где предсказуемость выполнения является требованием, потому что в большинстве языков GC сборщик мусора технически может включиться в любое время и начать перетасовывать ваши данные, одновременно занимая процессорное время и вызывая очистку кеша. Написание запросов к данным на основе наборов на языке C представляет собой головную боль, но SQL позволяет, по крайней мере, относительно легко выразить то, что вы хотите сделать с вашими данными, а не механику того , как это сделать .

И так продолжается. Хотя, конечно, есть некоторое совпадение, например, между такими языками, как C# и Java или BASIC и Pascal, во многих широко используемых языках каждый язык программирования занимает определенную нишу . Выбор между, скажем, Java и C# довольно произволен ( в общем случае ни один из них явно не лучше другого , хотя один может быть лучше другого в любом конкретном случае); выбор между Ada и C++ не является произвольным (есть вещи, которые вы можете сделать в одном, но не можете сделать в другом или не можете сделать без существенного изменения языка).

Даже если мы пренебрегаем специфическими для архитектуры языками, такими как ассемблер, который уже является довольно серьезной рукой (на чем вы собираетесь писать инициализацию загрузчика «BIOS» и код загрузки операционной системы; двоичный машинный язык?), по крайней мере, с технологии компьютеров, как мы знаем и признаем их сегодня, существует множество задач, которые необходимо выполнить, и требования для каждой из них различны. Производительность, предсказуемость, простота для программиста, доступность API, набор возможностей (как необходимых, так и явно не нужных или нежелательных) и так далее и тому подобное. В некоторых случаях определенные функции являются абсолютным требованием для предполагаемой цели языка; в других отсутствуетнекоторых особенностей является особенностью. Как указано в комментариях, а также в других местах, некоторые специфические функции по своему определению доказуемо несовместимы друг с другом, независимо от того, как они реализованы или выражены, и, следовательно , не могут сосуществовать в одном и том же языке программирования, поэтому любой такой язык должен был бы обменять одно на другое. Теперь рассмотрим людей, которым по той или иной причине действительно нужна функция, которую вырезали; какой язык программирования они будут использовать?

Все это, казалось бы, делает крайне маловероятным, что все это сойдется в единый язык программирования, который в равной степени подходит для написания ядра операционной системы и сценария скрытия полей для веб-страницы (или чего-то еще, что заменяет веб-страницы в вашем сценарии). Я бы даже сказал, что на самом деле этого не произойдет.

Если вы хотите, чтобы компьютерное программирование выглядело реалистично в вашем мире, вам нужно учесть тот факт, что для разных задач требуются разные инструменты и что эти разные инструменты будут использоваться разными людьми. Язык программирования является одним из таких инструментов, и поскольку сегодня у нас есть как электроинструменты, так и ручные инструменты, которые выполняют одно и то же — скажем, проделывают дыру в стене, — почти наверняка будут существовать разные языки программирования, подходящие для этих целей. для разных задач.

И это даже не говоря о переписывании каждой части программного обеспечения или его эквивалента в EZ++2108. Что, независимо от того, насколько продуктивным может быть кто-то в этом новом языке, было бы гигантским предприятием.

Также сравните Почему существует так много языков программирования? на сайте Computer Science Stack Exchange и Почему люди используют C, если он так опасен? на бирже стека программистов.

Я думаю, что этот ответ успешно доказывает, что из языков программирования, которые у нас есть в настоящее время, некоторые языки могут быть совершенно неподходящими для данной задачи. Но это не означает, что не может существовать универсальный язык, пригодный для любых целей. Чтобы опровергнуть эту возможность, нам просто нужно найти пример двух желаемых функций, которые не могут сосуществовать в одном и том же языке, например, безопасность памяти и неограниченная арифметика указателей.
@amon Возможно, но почему язык сценариев веб-страниц должен иметь (и обременять программиста) неограниченную арифметику указателей только потому, что это необходимо для написания операционной системы? По сути, языки программирования предназначены для выражения того, что вы хотите, чтобы компьютер делал. Если язык программирования веб-страниц (например, Javascript) совпадает с языком программирования операционной системы (например, C или ассемблер) с лишенными функций, можно утверждать, что это не один и тот же язык; они имеют разные наборы функций и удовлетворяют разные потребности, даже если основной синтаксис, возможно, одинаков.
Если у них одинаковый синтаксис и одинаковый набор функций, то да, это один и тот же язык, но также допускающий очень опасные конструкции, которые могли бы быть без очень тщательной песочницы (что нам не всегда удается сделать правильно даже с Javascript). , по крайней мере, повредить процесс веб-браузера. Я посмотрю, смогу ли я включить это в свой ответ, чтобы сделать его более понятным.
@amon есть функции, которые доказуемо несовместимы. Например, с помощью типов в качестве доказательств вы можете доказать различные свойства программы, в том числе в некоторых вариантах (TLC, Agda, ...), которые она завершает. Легко думать, что они все еще достаточно сильны, чтобы выразить многие интересные проблемы. Однако доказано, что из-за проблемы остановки вы не можете реализовать в них универсальную машину Тьюринга, поэтому у вас есть компромисс. Точно так же, если вы добавите достаточное количество функций в систему типов, вы получите неразрешимую систему типов (нет никакого возможного алгоритма для проверки типа программы).

TL; DR Это не невозможно, но я очень сомневаюсь в этом.


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

Во- первых, разговорные языки НЕ являются хорошей аналогией для языков программирования . Ведь по своей природе они значительно различаются. За исключением конланга , разговорные языки являются результатом многовековой эволюции. Разделение увеличивает разницу, но общение делает их более однородными. Основная идея — общаться друг с другом, понимать друг друга и обмениваться (или делать бизнес). Тем не менее, на этих языках говорят многие носители, и никто или никто фактически не контролирует эволюцию языка. Даже такие организации, как Французская академия Франции , просто отражают эволюцию языка, апостериори . Нет никаких размышлений о «лучшем» или «более эффективном».

ИМО, «английский» в качестве языка общения будет постоянно сближаться, но даже это будет отличаться от настоящего английского. И я также сомневаюсь, что другие языки полностью исчезнут из-за инерции, упомянутой Вильямом Капплером.

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

Теперь, можно ли их объединить? Я бы сказал, что это не невозможно . Если оглянуться на 10-15 лет назад, мало кто мог представить, насколько широко распространится такой язык, как Java. Действительно, его размер, производительность и время компиляции были значительно хуже, чем, скажем, у C++. Но с тех пор язык, JVM и компиляторы значительно улучшились. И, кроме того, прогресс в компьютерах означает, что здесь или там появляется еще несколько МБ, а разница в производительности едва заметна в большей части пользовательского опыта.

В микроконтроллерах наблюдается тенденция к адаптации все большей и большей ARM-архитектуры. Что, кажется, указывает на слияние аппаратного обеспечения. И если мы увидим войну операционных систем для мобильных приложений: например, Microsoft возвращается к ARM или планшетам, смартфонам и т. д. Если им удастся фактически иметь одну ОС, работающую на всех системах, это будет способствовать унификации языков программирования. По мере снижения цены на память будет меньше стимулов для фактического использования решений с малым объемом памяти, позволяющих приложениям больших ОС (посмотрите, насколько «низким» становится Linux через Embedded-Linux).

Однако я вижу четыре аргумента против .

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

  • доступность: насколько легко выучить язык/читать программу?
  • эффективность: то есть уже втрое: размер бина, объем ОЗУ и скорость
  • функциональность: что мы можем сделать с языком?
  • переносимость: какова область, в которой это может быть реализовано? Насколько легко связаться с нашими клиентами?

И, вероятно, есть еще несколько. Единственный способ унифицировать языки — сделать язык лучшим по всем этим параметрам. Просто чтобы дать некоторую иллюстрацию,

  • ruby легко читать и изучать, но он не особенно эффективен,
  • Java широко применяется, но слишком велика/сложна для встраиваемых систем,
  • C может быть очень эффективным, но трудным для изучения (сравнительно).

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

Мы также должны учитывать инерциюизменений. Языки программирования родились в полностью связанном мире (среди их пользователей). Следовательно, дальнейшее общение не изменит их курса (как и в случае с разговорными языками). Большинство пользователей неохотно осваивают новые и часто ждут до последнего момента, чтобы прибегнуть к изучению чего-то нового. Но здесь может сыграть роль «естественный отбор», отдающий предпочтение тем, кто это делает. Но вместе с программистами в их коде прописана инерция языков программирования. Во многих областях исследований Fortran является предпочтительным языком (я даже видел код в F77), хотя 1) исследователи часто знают о новых инструментах, и 2) некоторые утверждают, что Fortran — это умерший язык. Но почему? Потому что на Фортране было реализовано огромное количество кода! И это было бы огромным усилием, и, вероятно, окажется невозможным перевести все это на другой язык (первоначальные авторы недоступны, трудно проверить науку). То же самое и с другим большим кодом: вряд ли кто-то будет переписывать ядро ​​Linux. Вам необходимо реализовать совместимые языки. Но даже тогда это означает, что «старый» язык все еще нужно поддерживать в актуальном состоянии.

Эффект анархо-либерализма программирования и Интернета. Это хорошо видно по многочисленным форкам на FOSS: если кто-то не согласен с решением по новому стандарту, он, скорее всего, либо останется на старом, либо создаст альтернативу. Во многом подобно тому, как указал Уильям, многие современные языки произошли от C. И если бы мы могли положиться на последние 30 лет или около того, мы увидели бы взрывной рост числа приложений языков программирования, развитие большинства языков, некоторые из них выглядят как выведение тех, других как новых понятий (редко). Но старые стандарты все еще используются сегодня. Так происходит умножение и разнообразие языков. Трудно представить, что эта тенденция обратится вспять.

Последний из четырех пунктов — иррациональность участников сектора, а также программистов. Новые языки внедряются ради иррациональных факторов: пробелы — прекрасный пример. Некоторые люди будут защищать элегантность, поэтичность и т. д. своего языка. Это создает некоторые из известных войн флейма в Интернете. Я предлагаю вам посмотреть "С++ против Java". Возьмите с собой бинт. Новые пользователи часто встают на одну из сторон. Как мы видели в знаменитой печально известной войне emacs vs vim.

В заключение я бы сказал, что я вижу сценарий, в котором аппаратная память становится дешевой, аппаратная архитектура ограничивается несколькими (X86, ARM) и что одна ОС преобладает во всех них. Появляется новый язык, который является лучшим или почти лучшим по всем вышеперечисленным осям. Затем, по прошествии достаточного времени, другие языки могут исчезнуть.

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

Ассемблер? Пфф. В мои дни , когда нам хотелось быть новомодными и причудливыми, мы пользовались намагниченной иглой .
Я не говорил, что он был забавным злобным гением-диктатором. Но я никогда не видел дальше пунктирного картона.

TL;DR: Нет. Языки программирования слишком разнообразны.

Причина 1: цель

Согласно списку языков программирования Википедии , существует 806 различных языков программирования, не считая диалектов BASIC и эзотерических языков программирования.

У каждого языка есть некоторые особенности, которые нетрудно объединить: большинство языков программирования имеют ту или иную форму условной обработки, объявления переменных, арифметических и математических операций, вывода и ввода — среди прочих сходств. Это те части, которые было бы относительно легко объединить вместе (пока мы можем определиться со стилем, что может занять довольно много времени...).

Есть и другие части других языков, которые нелегко объединить, многие из которых зависят от цели языка. Например, JavaScript — это динамический язык веб-скриптов, используемый для интерактивности веб-страниц. Многие из них используются здесь, на StackExchange, для динамической загрузки контента без перезагрузки страницы. Этот процесс называется AJAX .

AJAX разработан для Интернета. Он не предназначен для настольных приложений, которые могут быть написаны на Java, C#, C или C++ (и т. д. и т. д.), которые могут быть многопоточными и динамически загружать контент без упоминания AJAX: именно так работают эти языки.

Взяв в качестве примера JavaScript и Java, мы также видим, что назначение языка программирования имеет значение. JavaScript разработан для Интернета; Java для установки в систему. Таким образом, JavaScript не имеет доступа к файлам из соображений безопасности, чтобы вредоносные веб-сайты не могли легко получить доступ к вашим файлам. Предполагая, что этот теоретический универсальный язык программирования (который я назову Σ∞ или Sigma Infinity) также должен подходить для всех целей, он должен подходить как для Интернета, так и для установленных версий. Чтобы удовлетворить это требование, разработчики языка были бы вынуждены выпустить две разные версии языка — одну без доступа к файлам, другую с — для обеспечения безопасности.

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

  • Совместимы друг с другом
  • Своевременно
  • Максимально близкие к идентичным
  • Поддерживается
  • Протестировано
  • Задокументировано
  • Использовал

... большой вопрос. Вам нужно будет создать огромную компанию, чтобы поддерживать Σ∞.

Нет, правда, это не исключает возможности существования Σ∞. Однако, поскольку мы говорим здесь о практичности, для нескольких компаний более практично поддерживать несколько языков, чем для одной крупной компании поддерживать Σ∞.


Причина 2: Особенности

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

введите описание изображения здесь

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

Да, возможно, я немного преувеличиваю, и вы можете просто нанять много разработчиков, но время и деньги, вложенные в проект Σ∞, будут значительными.


Причина 3: Размер файла

Простой, и один легче преодолеть, чем два предыдущих, но все же стоит упомянуть. Распространяемый файл C и среда выполнения занимают 37 МБ в сжатом виде на моем компьютере. Это около 45 МБ без сжатия. Предполагая, что C является репрезентативным языком с точки зрения размера файла, это дает нам 38700 МБ или 38,7 ГБ в качестве общего размера Σ∞.

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

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


Причина 4: типизация и компиляторы

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

JavaScript, например, интерпретируется во время выполнения . Код браузера переводит JS в исполняемый код непосредственно перед его запуском. Кроме того, JavaScript слабо типизирован — вам не нужно объявлять, что эта переменная является целым числом, а это строка, вы просто говорите var.

C#, для сравнения, является строго типизированным , предварительно скомпилированным языком. Вы должны сказать, что это целое число, а это строка, и ваш код не скомпилируется, если вы этого не сделаете. (Хорошо, varв C# тоже есть, но он все еще печатается во время компиляции.) Кроме того, вы должны запустить свой код через компилятор, который превращает его в исполняемый файл, который вы можете запустить.

Слияние двух типов языков было бы довольно трудным, если не невозможным.


Окончательно...

Поэтому я делаю вывод, что существует слишком много языков программирования и слишком много разных типов языков программирования, чтобы проект Σ∞ был осуществимым, не говоря уже о практическом.

«в C# тоже есть var» — в настоящее время у нас dynamicтоже есть, плюс всегда есть надежный objectтип (который вам нужно будет привести, прежде чем он позволит вам сделать гораздо больше, чем просто передать значение...). :)
@MichaelKjörling - действительно, но все они все равно печатаются во время компиляции (за возможным исключением dynamic- это не проверялось).
Right object(или, скорее, System.Object; object— это просто ключевое слово для удобства в C#) остается до тех пор System.Object, пока вы не приведете его к чему-то другому. Я думаю , что dynamicэто странная утка, набираемая во время выполнения. Сам не имел возможности пользоваться.
@MichaelKjörling Я даже не слышал об этом 4 минуты назад! System.Objectнемного странный в том смысле, что он мало что может сделать, кроме как пройти через него, но это все же тип.
«Visual C# 2010 представляет новый динамический тип. Это статический тип, но объект динамического типа обходит проверку статического типа». «Во время компиляции предполагается, что элемент, типизированный как динамический, поддерживает любую операцию». «[вызов метода для переменной динамического типа] не проверяется компилятором, потому что тип [...] является динамическим. Поэтому об ошибке компилятора не сообщается. Однако ошибка не ускользает от внимания на неопределенный срок. во время выполнения и вызывает исключение во время выполнения. " MSDN
@MichaelKjörling - держу пари, с ним весело играть...
@TracyCramer веб- браузер, да. В нынешнем виде JS не имеет экспериментальных методов или API-интерфейсов, которые могли бы использовать файлы доступа; для его поддержки потребуется изменение языка. Я не включаю измененные языки.
@TracyCramer вопрос касается объединения существующих языков программирования с реалистичными изменениями. JavaScript получить доступ к файлу нереально.
Причина 3: размер файла имеет гораздо худшие последствия, чем вы думаете. 38,7 ГБ — это не так много места на диске, но это место на диске представляет собой гораздо больше обручей, через которые нужно прыгать при каждом проходе вашего компилятора. Этот язык может прекрасно поместиться на вашем жестком диске, но затем компилироваться так медленно, что он никогда не будет работать как язык сценариев.

Надеюсь, что нет.

Языки программирования никогда не должны подчиняться законам, позволяющим сближать естественные языки.

Теперь у нас есть C++, который является английским языком программирования, без разбора заимствующим вещи из других непохожих языков в разные моменты своей истории (вероятно, худшей идеей в его истории был синтаксический сброс дженериков Ады в синтаксис шаблона). C++ больше не может быть разумно описан синтаксическими диаграммами и больше не может быть разумно разобран синтаксическими анализаторами достаточно регулярного класса. Его стандарты колеблются взад и вперед в семантике каждые несколько лет, и только сейчас массивы переменной размерности, которые потребуются для реализации общеполезных числовых библиотек, конкурирующих с библиотеками FORTRAN 50-летней давности, снова были исключены.

Вроде как избавиться от множественного числа "ye" в английском языке.

Теперь сравните с таким языком, как «Lua»: синтаксис помещается на одной странице справочного руководства (это бумага формата A5, примерно половина Legal), единая структура данных, несколько скалярных типов данных, методы программирования ООП реализуются для каждого протокола, а не чем по синтаксису и так далее.

Слияние его с C++ каким-либо образом не имело бы смысла.

Интересно, что происходит конвергенция компьютерных языков на целевом уровне: больше нет выделенных машин Lisp, таких как Symbolics, и современные архитектуры отдают предпочтение стековой адресации с общим стеком возврата и данных, общим адресным пространством программ и данных с вызов/возврат функции (а не переключение стека/сопрограммы) парадигма для организации потока управления и куча, работающая только с данными, а не вызов/возврат функции (как вам нужно для полных продолжений схемы).

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

Таким образом, вы попадаете в ситуацию, когда «языки высокого уровня» часто реализуются на языке низкого уровня (например, Lua в C), а не сами по себе, чтобы получить систему, с которой и компьютер, и программист могут работать без особых усилий. много боли.

Этот фундаментальный раскол не собирается исчезать. Виртуальные машины немного смещают компромиссы и добавляют еще один уровень многоуровневости, но на самом деле ничего не меняют.

Это был очень информативный пост @user9847. Мне очень понравилось читать.

Здесь дано много хороших ответов, обычно не принимающих точку зрения.

Я собираюсь сказать «да », потому что в конечном итоге мы создадим программное обеспечение, достаточно интеллектуальное, чтобы писать код намного лучше, чем люди могут писать код. Через некоторое время после этого события человеческие программисты устареют.

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

Верно, если только идеал недостижим с помощью логики. Например, идеальный язык может быть хаотичным по своей природе.
@CortAmmon Нет пота. Мой суперкомпьютер с этим справится! ;) А если серьезно, то нельзя ли предположить, что компьютер способен только выполнять вычислимые функции, чтобы его идеальное состояние было бы чисто логическим.
На самом деле очень трудно сделать такое предположение. Почти везде, где мы занимаемся информатикой, нас преследуют невычислимые проблемы, такие как хаотические системы или проблема остановки. Удивительно, как трудно, на самом деле. (Для примера, современное исследование DARPA военного ИИ намеренно устанавливает ограничения, подобные тем, о которых вы упоминаете. Доктора наук в области ИИ ненавидят эти правила, потому что практически невозможно сделать что-либо, что можно было бы назвать разумным в соответствии с ними)
@CortAmmon Это очень верно. Я не утверждаю, что невычислимых проблем не существует, я лишь утверждаю, что они не являются особенностью вычислимого мира. Результат Тьюринга — теорема логики, поэтому наш суперкомпьютер должен знать об этих ограничениях и, надеюсь, сможет проложить свой путь к идеальному состоянию, не обращаясь к произвольным программам или невычислимым хаотическим системам. Я, наверное, говорю от моего позади здесь.
Даже в этом случае программисты-люди все равно существовали бы, даже если бы они программировали просто для удовольствия. И они будут изучать, использовать и создавать разные языки программирования, потому что, опять же, разные языки интересны.
@Roux Это хороший момент. Человеческие языки программирования станут для машин «наивным» народным искусством. i.ebayimg.com/00/s/NTk4WDgwMw==/z/ITwAAOSwxH1T1ilb/…

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

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

Языки сценариев, такие как bash и ksh , хороши для простых процедурных задач, которые нужно выполнять снова и снова, но они не обеспечивают всех функций, необходимых для больших приложений. Это скорее вспомогательные структуры.

Компилируемые языки, такие как C++ и Python , имеют большие преимущества. Первый поддерживает точный контроль памяти и управление ресурсами. Python предназначен для легкого чтения, а исходный код должен быть коротким, определенно намного короче, чем C++. Эти два языка также работают на разных уровнях: C++ — это язык низкого уровня (исходный код выглядит как системные инструкции), а Python — язык высокого уровня (исходный код выглядит как разговорный язык).

Есть также Prolog , забавный язык, функционирующий как язык баз данных с правилами и запросами. Prolog основан на логике, а не на процедурах, как bash и C++. В результате он хорошо имитирует интеллект (системы ИИ) и не так хорош в манипулировании регистрами в памяти.

Каждый из этих языков имеет собственный синтаксис и правила синтаксического анализа. Кто-то, кто понимает C++, обычно может получить довольно хорошее представление о коде Python, взглянув на него, но bash и Prolog настолько разные, что их нельзя читать друг с другом.

Но синтаксис на самом деле не влияет на то, что поддерживается языком. Рабочий проект стандартов C++ 2014 года занимает более 1300 страниц. Это определенно не простой язык.

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

Я не уверен, что все согласятся с тем, что Python является компилируемым языком.
@PaŭloEbermann Он указан в скомпилированном разделе во второй ссылке. Он частично компилируется, но также интерпретируется, так что это спорный вопрос.

Он мог бы слиться в один язык, но он был бы очень разнообразен.

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

Интересно, что LISP, один из старейших языков, вероятно, чаще всего делает это. В LISP сам исходный код также является наиболее распространенной структурой данных, списком. LISP потенциально может иметь разные «подъязыки», которые будут иметь разные части LISP. Это что-то вроде монад Haskell.

Haskell — еще один интересный случай для рассмотрения. Он очень математический по своей природе, поэтому компиляторы могут математически манипулировать им, чтобы сделать программы быстрее. Кроме того, у него есть монады и DSL, которые в основном являются программируемыми подъязыками. Вы можете запрограммировать свой графический процессор на haskell (а именно, программа haskell создает программу для запуска программ на вашем графическом процессоре).

Следует отметить, что хотя они и существуют, и Лисп, и Хаскелл кое в чем неясны. Тем не менее, они находятся на подъеме, поэтому в будущем мы могли бы представить, что у нас есть какой-то суперязык, в вас, который в основном делает программу самой программой. Это позволило бы использовать множество различных вариантов использования.

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

Столько же оснований, сколько верить в то, что человеческие языки сойдутся воедино.

Давным-давно люди предсказывали быстрое сближение человеческих языков, но этого еще не произошло. Языки программирования имеют дополнительную особенность, которой нет в человеческих языках, это придуманные языки .по своей природе (в отличие от эсперанто и других придуманных человеком языков, которые являются исключением, а не правилом). Это означает, что в то время как человеческие языки могут конвергировать в результате естественной эволюции и расширения коммуникаций, обеспечиваемых технологиями, что может привести к созданию в будущем универсального языка, на котором говорит абсолютное большинство населения мира, и даже если компьютерные языки подчиняются тем же принципам конвергенции, у нас есть дополнительный фактор, заключающийся в том, что каждый день создаются новые компьютерные языки. Некоторые новые языки могут достичь гегемонии в определенной нише, а затем расшириться и стать общим языком porpuse. Мы не можем этого исключить.

Итак, я считаю, что компьютерные языки всегда будут гетерогенной областью. Даже старые компьютерные языки, которые считаются устаревшими (я сам программист на Паскале), могут получить новую обработку и стать современными. Паскаль сталкивается с большим количеством предубеждений со стороны людей, которые знают его только из таких текстов, как Керриган «Почему Паскаль не мой любимый язык», тем не менее, современный Паскаль намного более продвинут, чем язык Си, с полным набором объектно-ориентированных дополнений и ни одним из вещи, которые Керриган критиковала в этом популярном эссе. Итак, я считаю, что языки не будут объединены в единый универсальный язык, а продолжат модернизироваться и принимать новые вещи из других языков, как это делают наши собственные человеческие языки.

Во-первых, когда компьютеры пришли в Бразилию (я бразилец), мы «создали» новые слова из их английских аналогов, например, «удалить», которые имеют определенный общий корень в латыни, но не используются в современном португальском языке. Но это не заставит нас использовать английские слова для обычных вещей, таких как традиционная еда или другие предметы общего пользования, потому что у нас нет причин делать это, это было бы бесполезной тратой усилий и малой выгодой. Вы можете сказать, что люди должны учить английский, чтобы иметь лучшие перспективы трудоустройства (как мы обычно думаем здесь), или чтобы увеличить аудиторию, или что-то в этом роде. Но в этом случае люди не будут использовать английские слова в обычном разговоре.

Таким образом, это заставляет людей иметь два языка, чтобы не забывать свой родной язык или адаптировать его без необходимости. Это заставляет меня поверить, что человеческие языки никогда (точно так же, как компьютерные языки) не сольются в единое целое.

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

Это уже показывает, что всегда будет что-то абсолютно мешающее одному общему языку для всех. Например, программисты на языках с управляемой памятью вполне довольны тем, что им не приходится иметь дело с явным выделением и освобождением памяти — это означает, что вы можете больше сосредоточиться на вещах, которые мы еще не можем автоматизировать (даже частично). Юристская речь очень хороша, когда вы пытаетесь быть как можно более конкретным и иметь мало возможностей для альтернативной интерпретации.

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

Теперь вы, очевидно, можете создать язык, который разрешает и запрещает все, например, на основе некоторых предопределенных конструкций или даже директив компилятора. Например, когда я работал над своей ОС C#, у меня фактически был код C#, который компилировался в эквиваленты сборки, что-то вроде:

registers.AX = memory.Indirect(variable1.Address); // Translated into mov ax, [EBP-20h]

(просто псевдокод, фактический код был немного другим, но он должен иллюстрировать идею)

Фактически это позволило мне написать весь код на C#, включая загрузчик и драйверы устройств.

Вопрос в том, означает ли тот факт, что он написан на C#, что это всего лишь один язык под названием C#?

Я бы сказал, что нет . На самом деле значительную часть обычной работы программиста составляет создание собственных языков. Заметьте, не такие языки, как C# или LISP, а скорее предметно-ориентированные языки для решения конкретных проблем и ничего больше. Хотя они всегда реализуются на другом конкретном языке, они являются собственным языком, подмножеством — точно так же, как английский юрист — это подмножество общеанглийского.

Некоторые языки очень хорошо подходят для таких подъязыков — LISP/ML (и их производные, такие как F# или Scala), конечно, являются ярким примером. Интересно то, что именно строгие языки наиболее полезны для создания таких подъязыков, вне зависимости от того, должны ли подъязыки быть строгими или нет.

Так будет ли когда-нибудь один суперязык? Конечно, почему бы и нет. Уже есть много кандидатов, которые подошли довольно близко - x86 какое-то время был почти универсальным, исходный C имел цель быть компилируемым где угодно (многие компиляторы все еще просто создают код для компиляции для какого-либо компилятора C). Или современный JVM-байткод, или IL. Но это примерно тот уровень, на котором я ожидаю его появления - средний. Уровень конечного пользователя (-разработчика) будет приятной небольшой экосистемой различных языков, хорошо подходящих для их работы - ни меньше, ни больше. Если, конечно, вы не планируете антиутопию, в которой Apple-the-world-haegemon заставляет всех использовать Objective-C или что-то в этом роде. Помните, чтобы все было просто, нужно потрудиться — беспорядок возникает вполне естественно. Всегда будут беспорядок и разногласия, и оба они будут подпитывать множественность.Уменьшение сложности — сложная часть.

Боюсь, я должен не согласиться с этим - динамическую/статическую и сильную/слабую типизацию невероятно сложно объединить в один язык.
@ArtOfCode Я не говорю, что это легко, но очевидно, что это возможно. Помимо того факта, что каждый язык программирования на планете в конечном итоге работает на некотором физическом оборудовании, существуют также исследовательские языки, такие как Systems C# (управляемый + неуправляемый) и даже сам C# (статический + динамический). Это непросто, но и сделать паровую машину тогда тоже было непросто. На самом деле, C# также имеет как динамическую, так и статическую модели памяти, хотя статическая часть очень ограничена (она по-прежнему в основном безопасна; с другой стороны, Systems C# во многом является новым C++).
Боюсь, я все еще не согласен - ответ Уильяма Капплера вверху демонстрирует, что в принципе невозможно объединить языки разных уровней (которые часто также являются языками разных типов).
@ArtOfCode Я чувствую, что вы полностью упустили суть моего ответа. Вы только что прочитали часть "Конечно, почему бы и нет", или я так не понимаю? :D Я утверждаю, что даже если бы существовал один суперязык для всего, вы бы все равно не кодировали на нем — у вас были бы меньшие, более подходящие языки для всего, что вы делаете. Так же, как IL объединяет (в некоторой степени) весь мир .NET, но все по-прежнему пишут на C#, F#, LINQ, IronPython, C++/CLI, EntityFramework,...
Нет, я не к тому, что не было бы меньшего набора языков для конкретных задач — он уже есть, и я с вами в этом согласен. Я хочу сказать, что создание одного суперязыка почти невозможно, если вообще возможно.

Нет, нет. Возможно, было бы проще смешивать языки, но такие языки очень формальны и не будут смешиваться на уровне концептуальной основы.

Perl близок к тому, чтобы быть естественным креольским языком, но только среди подобных «типов» языков. Вы не можете просто смешать что-то, что построено на более примитивных манипуляциях с памятью, или добавить что-то чисто функциональное. Общий стиль синтаксиса также может иметь вариации, но вы не можете использовать конструкцию с совершенно другим синтаксисом.

Возможно нет.

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

Как отмечает Я. Длугош, языки программирования всегда очень формальны. В естественном языке изменения речевых моделей и произношения в изолированной группе людей могут привести к различным вариантам (мягкий пример — американский и британский английский). В языках программирования все иначе: программа либо соответствует спецификации, либо нет. Изменение спецификации происходит не просто так: авторы компилятора/интерпретатора должны согласиться с изменением, которое может нарушить работу сотен программ, зависящих от конкретного поведения. Во всяком случае, языки программирования на самом деле расходятся , потому что авторы компиляторов/интерпретаторов не удосуживаются придерживаться спецификации языка (см. regex , есть: Perl, POSIX, emacs, vim и т. д.).

Я также считаю маловероятным, что программисты, как правило, люди, смогут договориться об одном единственном, всеобъемлющем языке. Новые идеи всегда будут интегрироваться, чтобы языки оставались современными, идеи разделяются, но я считаю маловероятным, что все языки программирования сойдутся воедино.

По мере того, как компиляторы получают все больше памяти и вычислительной мощности процессора, они могут справляться с тем, что могут захватывать все больше и больше языков исходного кода. Например, gcc обычно может компилироваться как ansi-c или c## по мере необходимости, а также может компилироваться как fortran F77 или менее старый вариант. Я ожидаю, что удобочитаемый исходный код продолжит добавлять произвольные пользовательские настройки и предпочтения компании к известным стандартам, и иногда они могут быть нечитаемыми для кого-либо еще, но действительно оптимальный исполняемый машинный код на действительно произвольном RISC-процессоре, вероятно, сойдется. насколько это возможно.

Когда-нибудь исходный код мог бы быть настолько абстрагирован за инструкциями высокого уровня, что можно было бы встать перед вашим MakeAnythingBot и сказать: «Компьютер, спроектируй и создай космическую программу, денежную систему, систему сельскохозяйственного производства, все необходимые материалы». поставки и улучшенный MakeAnyThingBot", и он будет. Если это произойдет, я думаю, у нас большие проблемы.

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

tldr Я считаю, что языки программирования сойдутся просто потому, что для этого существует слишком много способов.

Давайте коснемся некоторых основных моментов (несколько) короткой истории программирования.

  • Переключатели
  • Перфокарты
  • язык ассемблера
  • Интерпретируемые/скриптовые языки
  • Языки высокого уровня
  • Объектно-ориентированные языки
  • «Управляемые» языки

Всего за 70 лет мы перешли от переключателей и рукояток к невероятно эффективным компиляторам с проверкой как синтаксиса, так и семантики. Через сто-двести лет я даже не представляю, как мы будем программировать (если будем вообще), но рискну предположить.

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

Все «причины» того, что единый язык несостоятелен, просто подчеркивают недостатки нашей нынешней вычислительной архитектуры. Они не касаются какого-либо будущего прогресса в этой области. Сказать, что через 100 лет мы все еще будем использовать архитектуру фон Неймана, было бы весьма спекулятивно.

Так как же нам перейти к одному языку?

На самом деле мы были на пути к тому, чтобы Java стал нашим «единственным» языком, когда разрабатывался «чип Java». Он изначально понимал байт-код Java - не было бы необходимости иметь какой-либо другой язык, кроме одного, если бы каждый компьютер использовал «чип Java». А для веб-программирования мы могли бы использовать подмножество языка для работы в браузерах. Ничто (технически) не мешает нам сейчас использовать один язык. Мы могли бы написать браузеры для использования C или C++ и просто отредактировать некоторые команды языка, например доступ к файлам.

Если мы изменим архитектуру, то один язык может стать неизбежным и очевидным выбором.

Мы можем дойти до того, что просто говорим о том, что мы хотим, чтобы компьютер делал, и он понимает, что мы имеем в виду — программирование на естественном языке. Новым компьютерным «языком» будет то, на что мы запрограммируем программиста. И нет причин иметь 10 языков «высокого уровня» на выбор.

А как же нейронные имплантаты? Возможно, мы просто «думаем», что мы хотим делать.

И, возможно, в будущем мы вообще не будем программировать. Искусственный интеллект будет просто строить машины, выращивать еду и удовлетворять все наши потребности, как в мультфильме «ВАЛЛ-И». Надеюсь, мы не станем просто оседлыми, а станем художниками, музыкантами и т. д.

Самолеты были изобретены 112 лет назад, ракеты вышли на орбиту 30 лет спустя, на Луну 20 лет спустя, человек на Луне 17 лет спустя (примерно в то время, когда была изобретена буква С), то есть всего 46 лет назад. На Венеру в следующем году, а затем на Марс в следующем году. Сказать, что через 200 или более лет программирование будет таким же, как сейчас, — значит бросить вызов истории.

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

Я согласен с тем, что утверждение о том, что архитектура фон Неймана не будет единственной архитектурой через 200 лет, является чистой спекуляцией. Но то же самое относится и к заявлениям о том, что «Один чип/одна архитектура», независимо от того, какой из них будет. История показывает, что она имеет тенденцию расходиться. Таким образом, вы на самом деле не доказываете вероятность уникального языка, на который указывает ваш «tl: dr».
@bilbo_pingouin, я согласен, но я сомневаюсь, что кто-то может «доказать» предсказание на 200 лет. Даже орбита Земли подвержена неизвестным неизвестным.

Как указывали многие другие, разные языки программирования имеют разные области использования, поэтому, вероятно, нет. И я согласен с этим.

Но я хочу добавить еще одну точку зрения. Вычислительная техника молода. Первым языком программирования был Plankalkül от Конрада Цузе , разработанный между 1942 и 1945 годами. Это 70 лет назад. Люди того времени живы до сих пор. Но это были первые детские шаги, тогда вычислительная техника не достигла масс.

На самом деле это началось позже, поэтому я бы предположил, что первым языком программирования с широким охватом был АЛГОЛ , появившийся в 1958 году. Это чуть более 55 лет назад. Этот язык не используется , вопросов по переполнению стека в этом году нет, в прошлом году только три; Я думаю, мы можем с уверенностью предположить, что он уже мертв.

Итак, давайте посмотрим немного дальше. COBOL был выпущен в 1959 году. Уже 88 вопросов в этом году на Stack Overflow показывают, что этот язык все еще используется. Мы говорим о языке, который комикс Дилберта почти 20 лет назад уже показал как ископаемое:введите описание изображения здесь

Даже C уже довольно стар, и это один из самых популярных языков.

Так что же здесь происходит? Как я уже сказал, вычислительная техника довольно молода. Если новому языку нужно 5 лет, чтобы стать популярным, и он остается популярным в течение 5 лет, и молодежь изучает его, когда он популярен, скажем, в среднем 25 лет, а затем работает до 65 лет, то вы можете видеть, что это приносит по крайней мере 50 лет жизни. на язык, который становится популярным. Единственные, кто умер раньше, — это языки, которые никогда не становятся популярными. И это время продлевается, если на этом языке нужно поддерживать большую кодовую базу, которая была создана во времена, когда язык был популярен. Это одна из причин, по которой C все еще так широко используется, и причина, по которой я думаю, что Java будет программироваться даже через эоны лет.

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

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

В пределе вся материя в Солнечной системе была преобразована в компутрониум с помощью наномашин, и весь этот компутрониум выстраивается вокруг Солнца, чтобы собрать максимально возможную энергию.

На этом далеком этапе базовая аппаратная архитектура, вероятно, довольно однородна — даже сегодня мы видим признаки конвергенции аппаратной архитектуры — особенно в отношении высокоскоростной последовательной связи (PCI 4.0, 100 GBE, USB3.0 — под капотом они все очень близки с точки зрения электрических свойств и протоколов канального уровня, тогда как когда-то они были весьма разнообразны). Люди зацикливаются на компьютерных науках с точки зрения наборов инструкций и языков, а не того, что действительно важно — как сегодня, так и в моем предельном сценарии, который представляет собой термодинамические затраты на перемещение данных из точки А в точку Б. Как только данные перемещаются, стоимость и особенности обработка второстепенна.

По мере повышения вычислительной мощности и увеличения расстояний, которые должны пройти данные для обработки, обработка информации становится в основном термодинамическим учетом, описываемым законами Шеннона и фундаментальной физикой.

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

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

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

Очевидно, что этот сценарий находится в некотором отдалении, но размещение сюжетной линии в какой-то точке этой траектории — это, по моему мнению, правильный научный подход.

Мне очень нравится ваш подход. Но я должен сказать, что универсальный язык, который вы упомянули, звучит как скомпилированная версия инструкций. Для человека, дающего эти инструкции, все еще должен быть способ сделать это простым способом. Именно для этого сейчас нужны языки программирования. С чего вы взяли, что в вашей сюжетной линии не будет нескольких языков программирования, которые компилируются в один и тот же максимально эффективный универсальный язык?
Абстрактные языки программирования полезны, чтобы помочь людям, которые мыслят категориями конкретных абстракций. Когда большая часть перепрограммирования выполняется от машины к машине, и большая часть машин запрограммирована на обучение (например, глубокое обучение, реализованное сегодня Google, Microsoft и т. д.), требования к программированию другие. Абстракции по-прежнему будут полезны и необходимы для сжатия передачи данных, но они, вероятно, будут зависеть от предметной области в зависимости от характера отправляемой информации. Я хочу сказать, что протоколы связи становятся гораздо более важными, чем программы.
Также я должен сказать, что в моем предельном случае нет людей-программистов, за исключением зоопарков и музеев.

В целом нет — по всем указанным причинам, однако вполне вероятно, что мы разработаем универсальный язык дескрипторов для программ/функций, который будет понятен как людям, так и специализированным экспертным системам, использующим их для написания базовых приложений. См. раздел Обработка естественного языка .

Например, мы можем сказать: «Мне нужно приложение, которое собирает, архивирует и отображает данные о погоде для моего региона». Экспертная система интерпретирует это и напишет эффективно одноразовый модуль, который выполняет эту функцию (с некоторым пониманием ваших личных предпочтений графического интерфейса посредством анализа вашего профиля или динамически генерируемого на основе предпочтений стиля терминала, на котором вы просматриваете приложение). ).

Естественно, описание игры было бы очень длинным и сложным с точки зрения графики, но, разбив описание на функции и уровни, этого можно было бы добиться. Язык дескрипторов — чем бы он ни оказался — будет структурирован для решения этих задач.

Существует множество причин, перечисленных выше, по которым никогда не будет Единого Истинного Языка. Однако вполне возможно создать мегаязык, который по своей сути представляет собой набор DSL.

Все языки должны будут использовать одну и ту же среду выполнения или виртуальную машину, и должна быть некоторая стандартизация пространства имен. Если у вас есть это, вы можете иметь:

  • Простой императивный язык программирования, когда вы хотите сказать: «Сделай это , затем это , а затем это » .

  • Настоящий объектно-ориентированный язык для инкапсуляции и подобных вещей.

  • Функциональный язык программирования без нефункциональных «утечек» (не столько как оператор печати), чтобы вы могли гарантировать изоляцию фрагмента кода.

  • Реляционный язык, может быть, даже разновидность SQL, чтобы он мог быть первоклассным языком, а не списком строк, которые нельзя проверить во время компиляции.

  • Декларативный язык, похожий на Make или Prolog.

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

  • Надлежащие синтаксические анализаторы - что-то вроде Lex и YACC, которые не компилируются в C, но сами по себе становятся первоклассными языковыми конструкциями.

  • Системный язык сборки программного обеспечения — что-то вроде Maven или Ant или что-то в этом роде.

Это все равно не будет Единственным Истинным Языком — что-то настолько большое, вероятно, нужно будет реализовать в чем-то более простом (С снова наносит удар!). Однако на этом можно было далеко зайти. Изучение его не должно быть намного (если вообще будет) труднее, чем изучение одного языка сегодня, потому что каждый язык может позволить себе быть неполным. Например, никакой язык, кроме языка регулярных выражений, не должен иметь функциональные возможности регулярных выражений. Декларативному языку не обязательно иметь возможность запускать императивный код только для того, чтобы быть полезным. Императивный язык может быть простым, так как он не обязан поддерживать все известные парадигмы программирования.

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

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

Следуя по пути Microsoft, теореме «Используйте свой собственный язык в .NET framework», она началась примерно с 26 языков, а сейчас насчитывает около 146 языков и продолжает расти. И каждый из них развивается вместе с новыми аппаратными тенденциями. Языки программирования только повзрослели, а не упали.

Идти по пути Java "Забудьте обо всем, учитесь только Java". Я не очень уверен в текущем статусе, в то время как Java перешла от Sun к Oracle/IBM... и так далее медленно теряет основную цель переносимости.

В отличие от человеческих языков, языки ПК должны развиваться и добавляться новые. У нас были «C/Fortran» и «Basic». Потом по схеме. Так что дело в том, какой вкус программисту нравится.

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

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