Сегодня на Земле, несмотря на то, что большинство людей немного говорит по-английски, по-видимому, нет оснований полагать, что основной язык будущего поколения останется тем же самым через десятилетия/столетия (т. е. у нас будут разные родные языки и мы будем изучать общий язык). позже в жизни).
Точно так же существует куча разных языков программирования. Но процесс итерации здесь намного быстрее. Регулярно создаются новые языки программирования, старые устаревают...
Есть ли основания полагать, что языки программирования сойдутся в единый язык в ближайшие десятилетия/столетия?
Это технически невозможно, по крайней мере, без отказа от функциональности.
Например, языки имеют разные уровни строгости, которые пропорциональны их высокому или низкому уровню. Языки сценариев имеют мягкую типизацию, потому что они могут легко выполнять проверки и преобразования типов во время выполнения. Сравните это с C/C++, у которого гораздо больше проблем с гибкостью типов из-за того, что он ближе к памяти. Несмотря на то, что добавляются дополнительные функции, не зависящие от типа, в конце концов, большинство из них по-прежнему основаны на компиляторе: они служат скорее вспомогательными средствами программирования, чем реальной функциональностью языка.
Другим важным примером является то, как обрабатывается память. В языках сценариев (и даже в некоторых скомпилированных языках) память в значительной степени не находится в руках программиста и управляется интерпретатором или какой-либо другой системой. Напротив, языки более низкого уровня предоставляют возможность напрямую манипулировать памятью и обращаться к ней, например, к указателям C/C++.
Хотя можно подумать, что, возможно, с ростом производительности мы когда-нибудь перестанем заботиться о низкоуровневом программировании и все начнем использовать какой-то странный аналог PHP для всего, я думаю, что это непонимание того, как на самом деле устроен мир. Я считаю C/C++ языком низкого уровня, как и большинство людей; но когда-то, и до сих пор среди некоторых, это был язык высокого уровня, а низкий уровень был бы подобен ассемблеру. Это не просто терминология: по мере того, как меняется постановка вопроса об эффективности, меняются и ее меры. Упрощения, которые мы теперь можем считать слишком дорогостоящими для реализации даже в интерпретируемых языках, однажды могут стать обычным явлением среди языков «высокого уровня», Java может считаться «низкоуровневым»,
Я думаю, что по этой причине гораздо меньше шансов, что языки программирования сойдутся, чем разговорные языки. Человеческий язык выполняет одну фиксированную задачу — передавать информацию. Хотя вы можете утверждать, что разные языки лучше или хуже в какой-то части этой цели, чем другие, все они могут достичь этих целей. Однако есть вещи, которые вы просто не можете сделать в PHP. Есть также вещи, которые ни один здравомыслящий человек не стал бы делать (в наши дни) на ассемблере.
Один из способов подумать об этом может быть таким. Если бы завтра все в мире бегло говорили по-валлийски, что бы произошло? Что ж, все смогут общаться на валлийском, переводческие услуги будут дешеветь, и, возможно, лук-порей станет более популярным. Если бы завтра единственным доступным языком программирования был JavaScript, мы все были бы в полной заднице.
Это не считая инерции. В человеческом языке инерция в основном связана со способностью читать старые литературные произведения, что редко является решением при принятии решения об изучении нового языка и никогда не является решением при изучении родного языка. Хотя потеря понимания классических произведений была бы культурной потерей, вряд ли это побудит к действиям в больших масштабах. С другой стороны, необходимость перепрограммирования ядра Linux, Windows, почти всех драйверов устройств и веб-серверов определенно повлияет на более широкие решения языков программирования. То, что COBOL все еще живет, на мой взгляд, является довольно сильным аргументом против конвергенции языков программирования.
Тем не менее, есть один момент, в котором можно ожидать некоторой конвергенции языков программирования: синтаксис. Это уже происходит, и C-подобная семья в значительной степени победила. Языки C, C++, Java, JavaScript и PHP в основном имеют идентичный синтаксис, сопровождаемый некоторыми изменениями в операторах, в основном отражающими присущие им различия. Никакой работы с указателями *
и &
в PHP, никакой забавной и простой конкатенации строк .
в C. Однако, помимо этого, эти языки почти полностью взаимно понятны, по крайней мере, в структуре. Альтернативным семейством может быть линия BASIC, включая VB и, я бы сказал, Python.
char*
как a short
(если, конечно, это не то, что вы хотели сделать ), но компилятор позволит вам; он может выдать предупреждение, и многие компиляторы имеют настройку для обработки предупреждений как ошибок, но это все. Я помню, как играл с указателями памяти в C еще в 90-х, под DOS; указатель short*
на видеопамять, трактуя его как char
s для записи на экран.What stops a language form including both manual and automatic memory management?
Взгляните на язык программирования D, который пытался заставить эту работу работать, и в основном потерпел неудачу по причинам, которые совсем не удивят любого, знакомого с законом Грешема .Есть ли основания полагать, что языки программирования сойдутся в единый язык в ближайшие десятилетия/столетия?
Как программист, я, конечно, надеюсь, что нет. Скорее всего, это будет огромным неудобством практически для всех и практически никому не принесет пользы.
Разные языки хороши для разных типов задач. Если вы пишете короткий сценарий, чтобы скрыть поле на веб-странице, когда пользователь делает определенный выбор в форме, вам не нужна способность 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, если он так опасен? на бирже стека программистов.
TL; DR Это не невозможно, но я очень сомневаюсь в этом.
Уже есть хорошие ответы, но я хотел добавить немного другую точку зрения.
Во- первых, разговорные языки НЕ являются хорошей аналогией для языков программирования . Ведь по своей природе они значительно различаются. За исключением конланга , разговорные языки являются результатом многовековой эволюции. Разделение увеличивает разницу, но общение делает их более однородными. Основная идея — общаться друг с другом, понимать друг друга и обмениваться (или делать бизнес). Тем не менее, на этих языках говорят многие носители, и никто или никто фактически не контролирует эволюцию языка. Даже такие организации, как Французская академия Франции , просто отражают эволюцию языка, апостериори . Нет никаких размышлений о «лучшем» или «более эффективном».
ИМО, «английский» в качестве языка общения будет постоянно сближаться, но даже это будет отличаться от настоящего английского. И я также сомневаюсь, что другие языки полностью исчезнут из-за инерции, упомянутой Вильямом Капплером.
С другой стороны, языки программирования обсуждаются в рамках сотрудничества, которое устанавливает стандарты. Наиболее известным является ANSI для C. Но в большинстве языков есть группа людей, участвующих в принятии решений об эволюции языка. Это полностью меняет характер эволюции языков программирования по сравнению с разговорными языками.
Теперь, можно ли их объединить? Я бы сказал, что это не невозможно . Если оглянуться на 10-15 лет назад, мало кто мог представить, насколько широко распространится такой язык, как Java. Действительно, его размер, производительность и время компиляции были значительно хуже, чем, скажем, у C++. Но с тех пор язык, JVM и компиляторы значительно улучшились. И, кроме того, прогресс в компьютерах означает, что здесь или там появляется еще несколько МБ, а разница в производительности едва заметна в большей части пользовательского опыта.
В микроконтроллерах наблюдается тенденция к адаптации все большей и большей ARM-архитектуры. Что, кажется, указывает на слияние аппаратного обеспечения. И если мы увидим войну операционных систем для мобильных приложений: например, Microsoft возвращается к ARM или планшетам, смартфонам и т. д. Если им удастся фактически иметь одну ОС, работающую на всех системах, это будет способствовать унификации языков программирования. По мере снижения цены на память будет меньше стимулов для фактического использования решений с малым объемом памяти, позволяющих приложениям больших ОС (посмотрите, насколько «низким» становится Linux через Embedded-Linux).
Однако я вижу четыре аргумента против .
Как указывают другие ответы, языки программирования , как правило, специализируются на нише. Я мог видеть несколько осей, чтобы различать языки
И, вероятно, есть еще несколько. Единственный способ унифицировать языки — сделать язык лучшим по всем этим параметрам. Просто чтобы дать некоторую иллюстрацию,
Из-за этих разных осей и специализации, которую мы наблюдаем сегодня, сомнительно, чтобы один из языков эволюционировал , чтобы доминировать над другими.
Мы также должны учитывать инерциюизменений. Языки программирования родились в полностью связанном мире (среди их пользователей). Следовательно, дальнейшее общение не изменит их курса (как и в случае с разговорными языками). Большинство пользователей неохотно осваивают новые и часто ждут до последнего момента, чтобы прибегнуть к изучению чего-то нового. Но здесь может сыграть роль «естественный отбор», отдающий предпочтение тем, кто это делает. Но вместе с программистами в их коде прописана инерция языков программирования. Во многих областях исследований Fortran является предпочтительным языком (я даже видел код в F77), хотя 1) исследователи часто знают о новых инструментах, и 2) некоторые утверждают, что Fortran — это умерший язык. Но почему? Потому что на Фортране было реализовано огромное количество кода! И это было бы огромным усилием, и, вероятно, окажется невозможным перевести все это на другой язык (первоначальные авторы недоступны, трудно проверить науку). То же самое и с другим большим кодом: вряд ли кто-то будет переписывать ядро Linux. Вам необходимо реализовать совместимые языки. Но даже тогда это означает, что «старый» язык все еще нужно поддерживать в актуальном состоянии.
Эффект анархо-либерализма программирования и Интернета. Это хорошо видно по многочисленным форкам на FOSS: если кто-то не согласен с решением по новому стандарту, он, скорее всего, либо останется на старом, либо создаст альтернативу. Во многом подобно тому, как указал Уильям, многие современные языки произошли от C. И если бы мы могли положиться на последние 30 лет или около того, мы увидели бы взрывной рост числа приложений языков программирования, развитие большинства языков, некоторые из них выглядят как выведение тех, других как новых понятий (редко). Но старые стандарты все еще используются сегодня. Так происходит умножение и разнообразие языков. Трудно представить, что эта тенденция обратится вспять.
Последний из четырех пунктов — иррациональность участников сектора, а также программистов. Новые языки внедряются ради иррациональных факторов: пробелы — прекрасный пример. Некоторые люди будут защищать элегантность, поэтичность и т. д. своего языка. Это создает некоторые из известных войн флейма в Интернете. Я предлагаю вам посмотреть "С++ против Java". Возьмите с собой бинт. Новые пользователи часто встают на одну из сторон. Как мы видели в знаменитой печально известной войне emacs vs vim.
В заключение я бы сказал, что я вижу сценарий, в котором аппаратная память становится дешевой, аппаратная архитектура ограничивается несколькими (X86, ARM) и что одна ОС преобладает во всех них. Появляется новый язык, который является лучшим или почти лучшим по всем вышеперечисленным осям. Затем, по прошествии достаточного времени, другие языки могут исчезнуть.
Но на самом деле, проще всего было бы, наверное, получить диктатора-злого гения, который взял бы под контроль мир и запретил бы любой язык, кроме ассемблера. Потому что кому что-то еще нужно?
TL;DR: Нет. Языки программирования слишком разнообразны.
Согласно списку языков программирования Википедии , существует 806 различных языков программирования, не считая диалектов BASIC и эзотерических языков программирования.
У каждого языка есть некоторые особенности, которые нетрудно объединить: большинство языков программирования имеют ту или иную форму условной обработки, объявления переменных, арифметических и математических операций, вывода и ввода — среди прочих сходств. Это те части, которые было бы относительно легко объединить вместе (пока мы можем определиться со стилем, что может занять довольно много времени...).
Есть и другие части других языков, которые нелегко объединить, многие из которых зависят от цели языка. Например, JavaScript — это динамический язык веб-скриптов, используемый для интерактивности веб-страниц. Многие из них используются здесь, на StackExchange, для динамической загрузки контента без перезагрузки страницы. Этот процесс называется AJAX .
AJAX разработан для Интернета. Он не предназначен для настольных приложений, которые могут быть написаны на Java, C#, C или C++ (и т. д. и т. д.), которые могут быть многопоточными и динамически загружать контент без упоминания AJAX: именно так работают эти языки.
Взяв в качестве примера JavaScript и Java, мы также видим, что назначение языка программирования имеет значение. JavaScript разработан для Интернета; Java для установки в систему. Таким образом, JavaScript не имеет доступа к файлам из соображений безопасности, чтобы вредоносные веб-сайты не могли легко получить доступ к вашим файлам. Предполагая, что этот теоретический универсальный язык программирования (который я назову Σ∞ или Sigma Infinity) также должен подходить для всех целей, он должен подходить как для Интернета, так и для установленных версий. Чтобы удовлетворить это требование, разработчики языка были бы вынуждены выпустить две разные версии языка — одну без доступа к файлам, другую с — для обеспечения безопасности.
Как вам скажут сопровождающие модульных языков или языков с несколькими версиями, это большая задача — убедиться, что обе версии...
... большой вопрос. Вам нужно будет создать огромную компанию, чтобы поддерживать Σ∞.
Нет, правда, это не исключает возможности существования Σ∞. Однако, поскольку мы говорим здесь о практичности, для нескольких компаний более практично поддерживать несколько языков, чем для одной крупной компании поддерживать Σ∞.
806 языков программирования содержат множество функций. Игнорируя проблемы совместимости целей, которые мы только что обсудили, создание Σ∞ займет много времени просто из-за огромного количества вещей, которые создатели должны включить. Для каждого языка процесс создания может выглядеть примерно так:
Глядя на старый пост на StackOverflow , кажется, что многие разработчики тратят гораздо больше времени на исправление ошибок, чем на написание новых функций. Таким образом, потребуется много времени, чтобы реализовать даже одну функцию, не говоря уже об одном языке, не говоря уже о 806 языках.
Да, возможно, я немного преувеличиваю, и вы можете просто нанять много разработчиков, но время и деньги, вложенные в проект Σ∞, будут значительными.
Простой, и один легче преодолеть, чем два предыдущих, но все же стоит упомянуть. Распространяемый файл C и среда выполнения занимают 37 МБ в сжатом виде на моем компьютере. Это около 45 МБ без сжатия. Предполагая, что C является репрезентативным языком с точки зрения размера файла, это дает нам 38700 МБ или 38,7 ГБ в качестве общего размера Σ∞.
Это немного меньше, чем я ожидал, и, конечно, немного с точки зрения требований к памяти. Тем не менее, подключение к Интернету должно быть значительно развито, прежде чем загружать такой файл - пользователи не хотят слишком долго ждать, пока установщики загрузят один файл, особенно если для программы нужно загрузить больше файлов.
Как я уже сказал, с этой проблемой справиться гораздо проще: мы говорим о будущем, поэтому вы, вероятно, можете предположить лучшее интернет-соединение. Просто момент, о котором стоит упомянуть.
Это было рассмотрено в других ответах, поэтому я просто быстро пройдусь по нему: в зависимости от цели и уровня языка в вычислениях процессы компиляции и выполнения значительно различаются.
JavaScript, например, интерпретируется во время выполнения . Код браузера переводит JS в исполняемый код непосредственно перед его запуском. Кроме того, JavaScript слабо типизирован — вам не нужно объявлять, что эта переменная является целым числом, а это строка, вы просто говорите var
.
C#, для сравнения, является строго типизированным , предварительно скомпилированным языком. Вы должны сказать, что это целое число, а это строка, и ваш код не скомпилируется, если вы этого не сделаете. (Хорошо, var
в C# тоже есть, но он все еще печатается во время компиляции.) Кроме того, вы должны запустить свой код через компилятор, который превращает его в исполняемый файл, который вы можете запустить.
Слияние двух типов языков было бы довольно трудным, если не невозможным.
Поэтому я делаю вывод, что существует слишком много языков программирования и слишком много разных типов языков программирования, чтобы проект Σ∞ был осуществимым, не говоря уже о практическом.
dynamic
тоже есть, плюс всегда есть надежный object
тип (который вам нужно будет привести, прежде чем он позволит вам сделать гораздо больше, чем просто передать значение...). :)dynamic
- это не проверялось).object
(или, скорее, System.Object
; object
— это просто ключевое слово для удобства в C#) остается до тех пор System.Object
, пока вы не приведете его к чему-то другому. Я думаю , что dynamic
это странная утка, набираемая во время выполнения. Сам не имел возможности пользоваться.System.Object
немного странный в том смысле, что он мало что может сделать, кроме как пройти через него, но это все же тип.Надеюсь, что нет.
Языки программирования никогда не должны подчиняться законам, позволяющим сближать естественные языки.
Теперь у нас есть C++, который является английским языком программирования, без разбора заимствующим вещи из других непохожих языков в разные моменты своей истории (вероятно, худшей идеей в его истории был синтаксический сброс дженериков Ады в синтаксис шаблона). C++ больше не может быть разумно описан синтаксическими диаграммами и больше не может быть разумно разобран синтаксическими анализаторами достаточно регулярного класса. Его стандарты колеблются взад и вперед в семантике каждые несколько лет, и только сейчас массивы переменной размерности, которые потребуются для реализации общеполезных числовых библиотек, конкурирующих с библиотеками FORTRAN 50-летней давности, снова были исключены.
Вроде как избавиться от множественного числа "ye" в английском языке.
Теперь сравните с таким языком, как «Lua»: синтаксис помещается на одной странице справочного руководства (это бумага формата A5, примерно половина Legal), единая структура данных, несколько скалярных типов данных, методы программирования ООП реализуются для каждого протокола, а не чем по синтаксису и так далее.
Слияние его с C++ каким-либо образом не имело бы смысла.
Интересно, что происходит конвергенция компьютерных языков на целевом уровне: больше нет выделенных машин Lisp, таких как Symbolics, и современные архитектуры отдают предпочтение стековой адресации с общим стеком возврата и данных, общим адресным пространством программ и данных с вызов/возврат функции (а не переключение стека/сопрограммы) парадигма для организации потока управления и куча, работающая только с данными, а не вызов/возврат функции (как вам нужно для полных продолжений схемы).
Это приводит к тому, что разные языки программирования имеют разные характеристики производительности и, следовательно, разные варианты выбора языка программирования в зависимости от требуемого уровня соответствия мышления программистов или компьютеров.
Таким образом, вы попадаете в ситуацию, когда «языки высокого уровня» часто реализуются на языке низкого уровня (например, Lua в C), а не сами по себе, чтобы получить систему, с которой и компьютер, и программист могут работать без особых усилий. много боли.
Этот фундаментальный раскол не собирается исчезать. Виртуальные машины немного смещают компромиссы и добавляют еще один уровень многоуровневости, но на самом деле ничего не меняют.
Здесь дано много хороших ответов, обычно не принимающих точку зрения.
Я собираюсь сказать «да », потому что в конечном итоге мы создадим программное обеспечение, достаточно интеллектуальное, чтобы писать код намного лучше, чем люди могут писать код. Через некоторое время после этого события человеческие программисты устареют.
Согласно хорошо известному аргументу, эта машина будет неоднократно переписывать свой собственный код, увеличивая свой интеллект с каждой итерацией. Если предположить, что у машинного интеллекта есть предел, он быстро приблизится к этому уровню интеллекта, и язык, который он использует, также приблизится к идеалу.
Может ли быть единый язык программирования в будущем? Конечно, но давайте посмотрим, почему у нас их так много сегодня.
В настоящее время существует множество языков , которые используются или использовались, но этот список на самом деле не демонстрирует, почему у нас сегодня разные языки, поэтому давайте вместо этого используем этот список языков по типу .
Языки сценариев, такие как bash и ksh , хороши для простых процедурных задач, которые нужно выполнять снова и снова, но они не обеспечивают всех функций, необходимых для больших приложений. Это скорее вспомогательные структуры.
Компилируемые языки, такие как C++ и Python , имеют большие преимущества. Первый поддерживает точный контроль памяти и управление ресурсами. Python предназначен для легкого чтения, а исходный код должен быть коротким, определенно намного короче, чем C++. Эти два языка также работают на разных уровнях: C++ — это язык низкого уровня (исходный код выглядит как системные инструкции), а Python — язык высокого уровня (исходный код выглядит как разговорный язык).
Есть также Prolog , забавный язык, функционирующий как язык баз данных с правилами и запросами. Prolog основан на логике, а не на процедурах, как bash и C++. В результате он хорошо имитирует интеллект (системы ИИ) и не так хорош в манипулировании регистрами в памяти.
Каждый из этих языков имеет собственный синтаксис и правила синтаксического анализа. Кто-то, кто понимает C++, обычно может получить довольно хорошее представление о коде Python, взглянув на него, но bash и Prolog настолько разные, что их нельзя читать друг с другом.
Но синтаксис на самом деле не влияет на то, что поддерживается языком. Рабочий проект стандартов C++ 2014 года занимает более 1300 страниц. Это определенно не простой язык.
Если не произойдет серьезного прорыва в построении и применении языков, я ожидаю, что языки программирования останутся отдельными структурами, сосредоточенными на конкретных действиях. Мы можем увидеть меньший пул используемых языков, но я не ожидаю, что это число когда-либо достигнет единицы.
Он мог бы слиться в один язык, но он был бы очень разнообразен.
Метапрограммирование — это то, где ваш код взаимодействует с самим кодом. У вас может быть один язык программирования, но в разных областях применения он будет использоваться по-разному, возможно, даже несовместимо. В конце концов, язык будет очень продвинутым.
Интересно, что 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 или что-то в этом роде. Помните, чтобы все было просто, нужно потрудиться — беспорядок возникает вполне естественно. Всегда будут беспорядок и разногласия, и оба они будут подпитывать множественность.Уменьшение сложности — сложная часть.
Нет, нет. Возможно, было бы проще смешивать языки, но такие языки очень формальны и не будут смешиваться на уровне концептуальной основы.
Perl близок к тому, чтобы быть естественным креольским языком, но только среди подобных «типов» языков. Вы не можете просто смешать что-то, что построено на более примитивных манипуляциях с памятью, или добавить что-то чисто функциональное. Общий стиль синтаксиса также может иметь вариации, но вы не можете использовать конструкцию с совершенно другим синтаксисом.
Возможно нет.
Как вы (правильно) заявили, существует много языков программирования. Подобно разговорным (естественным) языкам, они часто заимствуют друг у друга. Однако, в отличие от естественных языков, языками программирования управляют интеллектуальные дизайнеры, также известные как программисты, у которых есть свои (противоречащие) представления о том, что лучше всего.
Как отмечает Я. Длугош, языки программирования всегда очень формальны. В естественном языке изменения речевых моделей и произношения в изолированной группе людей могут привести к различным вариантам (мягкий пример — американский и британский английский). В языках программирования все иначе: программа либо соответствует спецификации, либо нет. Изменение спецификации происходит не просто так: авторы компилятора/интерпретатора должны согласиться с изменением, которое может нарушить работу сотен программ, зависящих от конкретного поведения. Во всяком случае, языки программирования на самом деле расходятся , потому что авторы компиляторов/интерпретаторов не удосуживаются придерживаться спецификации языка (см. regex , есть: Perl, POSIX, emacs, vim и т. д.).
Я также считаю маловероятным, что программисты, как правило, люди, смогут договориться об одном единственном, всеобъемлющем языке. Новые идеи всегда будут интегрироваться, чтобы языки оставались современными, идеи разделяются, но я считаю маловероятным, что все языки программирования сойдутся воедино.
По мере того, как компиляторы получают все больше памяти и вычислительной мощности процессора, они могут справляться с тем, что могут захватывать все больше и больше языков исходного кода. Например, gcc обычно может компилироваться как ansi-c или c## по мере необходимости, а также может компилироваться как fortran F77 или менее старый вариант. Я ожидаю, что удобочитаемый исходный код продолжит добавлять произвольные пользовательские настройки и предпочтения компании к известным стандартам, и иногда они могут быть нечитаемыми для кого-либо еще, но действительно оптимальный исполняемый машинный код на действительно произвольном RISC-процессоре, вероятно, сойдется. насколько это возможно.
Когда-нибудь исходный код мог бы быть настолько абстрагирован за инструкциями высокого уровня, что можно было бы встать перед вашим MakeAnythingBot и сказать: «Компьютер, спроектируй и создай космическую программу, денежную систему, систему сельскохозяйственного производства, все необходимые материалы». поставки и улучшенный MakeAnyThingBot", и он будет. Если это произойдет, я думаю, у нас большие проблемы.
tldr Я считаю, что языки программирования сойдутся просто потому, что для этого существует слишком много способов.
Давайте коснемся некоторых основных моментов (несколько) короткой истории программирования.
Всего за 70 лет мы перешли от переключателей и рукояток к невероятно эффективным компиляторам с проверкой как синтаксиса, так и семантики. Через сто-двести лет я даже не представляю, как мы будем программировать (если будем вообще), но рискну предположить.
Большинство ответов здесь делают неявное предположение о продолжении использования архитектуры фон Неймана, которая для всех практических целей является единственной архитектурой, существующей в настоящее время. Но сбрасывать со счетов другую архитектуру, особенно когда появляются оптические или квантовые компьютеры, недальновидно.
Все «причины» того, что единый язык несостоятелен, просто подчеркивают недостатки нашей нынешней вычислительной архитектуры. Они не касаются какого-либо будущего прогресса в этой области. Сказать, что через 100 лет мы все еще будем использовать архитектуру фон Неймана, было бы весьма спекулятивно.
Так как же нам перейти к одному языку?
На самом деле мы были на пути к тому, чтобы Java стал нашим «единственным» языком, когда разрабатывался «чип Java». Он изначально понимал байт-код Java - не было бы необходимости иметь какой-либо другой язык, кроме одного, если бы каждый компьютер использовал «чип Java». А для веб-программирования мы могли бы использовать подмножество языка для работы в браузерах. Ничто (технически) не мешает нам сейчас использовать один язык. Мы могли бы написать браузеры для использования C или C++ и просто отредактировать некоторые команды языка, например доступ к файлам.
Если мы изменим архитектуру, то один язык может стать неизбежным и очевидным выбором.
Мы можем дойти до того, что просто говорим о том, что мы хотим, чтобы компьютер делал, и он понимает, что мы имеем в виду — программирование на естественном языке. Новым компьютерным «языком» будет то, на что мы запрограммируем программиста. И нет причин иметь 10 языков «высокого уровня» на выбор.
А как же нейронные имплантаты? Возможно, мы просто «думаем», что мы хотим делать.
И, возможно, в будущем мы вообще не будем программировать. Искусственный интеллект будет просто строить машины, выращивать еду и удовлетворять все наши потребности, как в мультфильме «ВАЛЛ-И». Надеюсь, мы не станем просто оседлыми, а станем художниками, музыкантами и т. д.
Самолеты были изобретены 112 лет назад, ракеты вышли на орбиту 30 лет спустя, на Луну 20 лет спустя, человек на Луне 17 лет спустя (примерно в то время, когда была изобретена буква С), то есть всего 46 лет назад. На Венеру в следующем году, а затем на Марс в следующем году. Сказать, что через 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, очень велико по сравнению с тем, как быстро мог бы развиваться принимающий объект, если бы захотел.
Если все аппаратные архитектуры в конечном итоге будут одинаковыми, то универсальным языком будет язык, на котором аппаратное обеспечение запрограммировано на самом низком уровне программируемости. Языковые абстракции, построенные поверх этого, вероятно, не квалифицируются как языки точно так же, как мы не будем думать о научной терминологии, изложенной в английском языке, как о языке, отличном от самого английского.
Наконец, если аппаратное обеспечение (компьютрониум) само по себе является реконфигурируемым (несомненно, за счет нетривиальных термодинамических издержек), то концепции программного и аппаратного обеспечения не имеют большого значения. На самом деле и то, и другое сводилось бы к одним и тем же термодинамическим принципам, хотя контроль версий (который на этом уровне может только попытаться отделить подлинно необратимые процессы от обратимых) может играть некую независимую роль.
Очевидно, что этот сценарий находится в некотором отдалении, но размещение сюжетной линии в какой-то точке этой траектории — это, по моему мнению, правильный научный подход.
В целом нет — по всем указанным причинам, однако вполне вероятно, что мы разработаем универсальный язык дескрипторов для программ/функций, который будет понятен как людям, так и специализированным экспертным системам, использующим их для написания базовых приложений. См. раздел Обработка естественного языка .
Например, мы можем сказать: «Мне нужно приложение, которое собирает, архивирует и отображает данные о погоде для моего региона». Экспертная система интерпретирует это и напишет эффективно одноразовый модуль, который выполняет эту функцию (с некоторым пониманием ваших личных предпочтений графического интерфейса посредством анализа вашего профиля или динамически генерируемого на основе предпочтений стиля терминала, на котором вы просматриваете приложение). ).
Естественно, описание игры было бы очень длинным и сложным с точки зрения графики, но, разбив описание на функции и уровни, этого можно было бы добиться. Язык дескрипторов — чем бы он ни оказался — будет структурирован для решения этих задач.
Существует множество причин, перечисленных выше, по которым никогда не будет Единого Истинного Языка. Однако вполне возможно создать мегаязык, который по своей сути представляет собой набор DSL.
Все языки должны будут использовать одну и ту же среду выполнения или виртуальную машину, и должна быть некоторая стандартизация пространства имен. Если у вас есть это, вы можете иметь:
Простой императивный язык программирования, когда вы хотите сказать: «Сделай это , затем это , а затем это » .
Настоящий объектно-ориентированный язык для инкапсуляции и подобных вещей.
Функциональный язык программирования без нефункциональных «утечек» (не столько как оператор печати), чтобы вы могли гарантировать изоляцию фрагмента кода.
Реляционный язык, может быть, даже разновидность SQL, чтобы он мог быть первоклассным языком, а не списком строк, которые нельзя проверить во время компиляции.
Декларативный язык, похожий на Make или Prolog.
Первоклассный язык регулярных выражений, поэтому вам не нужно писать код, который выглядит как линейный шум.
Надлежащие синтаксические анализаторы - что-то вроде Lex и YACC, которые не компилируются в C, но сами по себе становятся первоклассными языковыми конструкциями.
Системный язык сборки программного обеспечения — что-то вроде Maven или Ant или что-то в этом роде.
Это все равно не будет Единственным Истинным Языком — что-то настолько большое, вероятно, нужно будет реализовать в чем-то более простом (С снова наносит удар!). Однако на этом можно было далеко зайти. Изучение его не должно быть намного (если вообще будет) труднее, чем изучение одного языка сегодня, потому что каждый язык может позволить себе быть неполным. Например, никакой язык, кроме языка регулярных выражений, не должен иметь функциональные возможности регулярных выражений. Декларативному языку не обязательно иметь возможность запускать императивный код только для того, чтобы быть полезным. Императивный язык может быть простым, так как он не обязан поддерживать все известные парадигмы программирования.
Короткий ответ: компьютерные языки написаны с синтаксисом и семантикой для решения проблем. Я уверен, что если бы круг проблем, которые требуется решить с помощью компьютерного программирования, оставался бы постоянным, мы бы обнаружили, что языки сближаются довольно быстро.
Однако найти кого-либо, кто думает, что область компьютерного программирования остается неизменной, или, если уж на то пошло, любого, кто думает, что область компьютерного программирования делает что-то кроме необузданного спринта в будущее, может быть трудным.
Следуя по пути Microsoft, теореме «Используйте свой собственный язык в .NET framework», она началась примерно с 26 языков, а сейчас насчитывает около 146 языков и продолжает расти. И каждый из них развивается вместе с новыми аппаратными тенденциями. Языки программирования только повзрослели, а не упали.
Идти по пути Java "Забудьте обо всем, учитесь только Java". Я не очень уверен в текущем статусе, в то время как Java перешла от Sun к Oracle/IBM... и так далее медленно теряет основную цель переносимости.
В отличие от человеческих языков, языки ПК должны развиваться и добавляться новые. У нас были «C/Fortran» и «Basic». Потом по схеме. Так что дело в том, какой вкус программисту нравится.
Мой личный язык апелляции — VB, и он всегда решал то, что мне было нужно. Что наиболее важно в более позднем периоде, код так же хорош, как обычный английский для чтения и понимания, и при этом компилируется в высокоэффективные двоичные файлы.
Позвольте новым языкам программирования развиваться, чтобы могли появиться новые методологии. Давайте не будем ограничивать во имя конвергенции, пожалуйста.
Ньютон1212
БартекЧом
Минц97
джеймскф
амон
пользователь
Луан
SJuan76
el.pescado - нет войны
Максим
el.pescado - нет войны
Шераф
el.pescado - нет войны
ГроссмейстерБ
пользователь
ДвухместныйДабл
Фред
Питер - Восстановить Монику
Криш