Языки программирования становятся более похожими на естественные языки?


27

Можем ли мы изучать языки программирования в контексте лингвистики? Языки программирования развиваются естественным образом аналогично естественным языкам?

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

Развиваются ли языки программирования, чтобы стать более лингвистическими и, следовательно, более естественными? Например, машинный код, перфокарты и языки ассемблера уступили место более читаемым языкам, таким как Ruby, Python и т. Д.

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

Что вы все думаете? Становятся ли языки программирования более похожими на естественные языки и, таким образом, становятся применимыми к законам лингвистики?

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

Есть ли связь между (эффектом Вавилонской башни) разделения человеческих языков и компьютерных языков? Становятся ли они более разнообразными по одним и тем же причинам (т. Е. Для решения различных проблем в постоянно развивающихся компьютерных системах / системах культуры и т. Д.)?


3
краткий ответ: да, да, они есть.

17
Краткий ответ: нет, нет, это не так.


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

@ryanOptini: C #, JavaScript, Python или SQL выглядят как естественные языки? Хотя все они используют ключевые слова из английского языка, ни одно из них не сходится в формате естественного языка. КОБОЛ, возможно, был самым близким, но я не думаю, что многие люди используют КОБОЛ для своих проектов с нуля.
Джим Г.

Ответы:


32

Не на самом деле нет. Языки программирования стали больше похожи на естественные языки только в смысле «слов, которые у нас есть в английском» ( sic ).

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

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

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

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

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


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

Сравнение между архитектурой процессора и программированием несколько неискренне, аппаратное проектирование всегда было в значительной степени не основанным на тексте, так как у него были совершенно другие проблемы, например, для решения проблемы размещения и маршрутизации. (во всяком случае, аппаратный дизайн движется к более текстовому дизайну с использованием HDL)
jk.

2

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

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

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


2

Интересным примером в этой области является Perl против RubyPython ). Perl - это язык сценариев, разработанный в начале 90-х годов, который значительно расширил возможности по сравнению с предыдущими языками сценариев на основе Unix (например, bash). Автор Ларри Уолл официально заявил, что его опыт в лингвистике вдохновил некоторые особенности языка.

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

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


У вас неправильные даты: Perl был выпущен в 1987 году, Bash - в 1989 году. Он также беспокоится о том, чтобы прочитать ваши сообщения из-за ошибок в их заглавных буквах.
tchrist

1

Машинный язык очень точен, в то время как текст, написанный человеком, обычно можно интерпретировать по-разному (например, поэтический текст).

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

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

Конечно, программа основана на точных механизмах, поэтому вам нужны точные языки (не естественные), в то время как простой веб-поиск в Google очень естественен, вам просто нужно набрать несколько слов, и вы получите то, что хотите.

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

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


1

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

  1. Могут ли программы низкого уровня (например, компиляторы) быть удобно и эффективно написаны на языках высокого уровня (например, английском)?

  2. Могут ли естественные языки анализироваться относительно «небрежно» и при этом обеспечивать достаточно стабильную среду для продуктивного программирования?

  3. Легче ли программировать, когда вам не нужно переводить свои мысли на естественном языке в альтернативный синтаксис?

Теперь мы можем ответить на каждый из этих трех вопросов, исходя из непосредственного опыта, с громким «Да».

Наш парсер работает, мы думаем, что-то вроде человеческого мозга. Рассмотреть возможность. Отец говорит своему маленькому сыну:

"Хочешь пососать эту бутылку, маленький парень?"

И ребенок слышит,

"бла, бла, сосать, бла, бла, БУТЫЛКА, бла, бла".

Но он правильно отвечает, потому что у него есть «изображение» бутылки в правой части его головы, связанной со словом «бутылка» на левой стороне, и уже существовавшее «умение» в задней части его шеи, соединенное с Термин "сосать". Другими словами, ребенок сопоставляет то, что он может, с фотографиями (типами) и навыками (процедурами), которые он накопил, и просто игнорирует все остальное. Наш компилятор делает то же самое, с новыми изображениями (типами) и навыками (процедурами), определяемыми не нами, а программистом, когда он пишет новый код приложения.

Типичное определение типа выглядит так:

Многоугольник - это вещь с некоторыми вершинами.

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

Типичная рутина выглядит так:

Чтобы добавить координаты x и ay к многоугольнику: создайте вершину, заданную x и y. Добавьте вершину к вершинам многоугольника.

Обратите внимание, что формальные имена (собственные имена) не требуются для параметров и переменных. Мы считаем, что это главное понимание. Мой реальный стул и стол никогда не (в обычном разговоре) называются «c» или «myTable» - я называю их просто «стул» и «стол». Аналогично здесь: "вершина" и "многоугольник" являются естественными названиями для таких вещей.

Также обратите внимание, что пробелы допускаются в рутинных и переменных именах (например, x координат). Это 21 век, да? И это «псевдонимы» также разрешены (например, «х» для «х координат»). И эти притяжки («вершины многоугольника») используются очень естественным образом для ссылки на «поля» внутри «записей».

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

На самом низком уровне все выглядит так:

Чтобы добавить номер к другому номеру: Intel $ 8B85080000008B008B9D0C0000000103.

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

Вы можете получить нашу систему разработки здесь: www.osmosian.com/cal-3040.zip. Это небольшая программа для Windows, размером менее мегабайта. Если вы начнете с PDF-файла в каталоге «документация», перед тем, как перейти на десять страниц, вы будете перекомпилировать весь шебанг сам по себе (менее чем за три секунды на обычном компьютере от Walmart).

Вопросы и комментарии следует направлять на gerry.rzeppa@pobox.com


Известно ли вам о попытках контролируемого английского языка по запросу попытка.ifi.uzh.ch ? Вы, кажется, сидите между этим и Inform7 en.wikipedia.org/wiki/Inform#Example_game_2
Пит

Мне нравится эта идея, но кажется, что есть еще несколько синтаксических скачков, через которые можно перейти. Например, я не думаю, что я или кто-либо, кто моделирует геометрические объекты, посчитал бы, что координаты X и Y добавляются по отдельности, так что «Добавить координаты x и ay координаты ...» звучит очень странно для меня. Как и «Создать вершину, заданную x и y». Почти простительно, потому что на самом деле он читает в основном как английский, но все еще кажется слишком строгим. Может быть, я просто слишком привык думать не как человек или что-то в этом роде, я не знаю.
Чао

1

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

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

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

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

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

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

Другое дело, что многие дизайнеры языка программирования пытаются что-то доказать или применять техническую идеологию. Таким образом, они получают чрезвычайно предписывающий дизайн, чтобы пользователи не отходили от своих намеченных парадигм. Это, к сожалению, крайне непродуктивно для творчества. Самый креативный язык, который когда-либо разрабатывался, был одним из самых первых: Lisp (1958). Свобода и гибкость, которые она позволяла, были источником значительного творчества. Цена заключалась в том, что это требовало самодисциплины и понимания. Но Лисп был действительно метаязыком, языком для создания языков.

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

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

Оглядываясь назад в историю, языки высокого уровня с самого начала (FORTRAN) были попыткой приблизиться к более естественной форме для выражения вычислительных задач, но эти задачи были поняты как математические или логические (Fortran 1957, Algol 1958, Lisp 1958). ) или более ориентированный на бизнес (Cobol 1959). В течение 10 лет люди беспокоились о языках, которые были бы ближе, лучше адаптировались к рассматриваемой проблеме, и было проведено значительное исследование так называемых extensible languages, охватывающих как синтаксис, так и семантику. Одним из основных путей более естественного выражения проблем было появление object orientation(иногда под другими именами). Несмотря на то, что всегда трудно определить родительство, оно, вероятно, возникло из работы по искусственному интеллекту, в основном на Лиспе, и из языка.Simula 67(Семья Алгол), которая была предназначена для более естественного выражения реальных проблем, которые должны быть смоделированы на компьютере. Все это кажется исторически последовательным.


0

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

Возможно, разрыв между естественными языками и языками программирования сократится, если сократится разрыв между учеными-информатиками и «естественными» людьми.


0

В последние годы интерес к (E) DSL и свободным интерфейсам неуклонно растет на самых разных языках: Haskell, различных языках сценариев, C #, Java и даже C ++ (подумайте о перегрузке operator<<для выполнения вывода).

В некоторой степени они позволяют коду читать более естественно. Я проиллюстрирую на примере EDSL в Groovy. Пакет groovy.time позволяет написать

use ( TimeCategory ) {
    // application on numbers:
    println 1.minute.from.now
    println 10.days.ago

    // application on dates
    def someDate = new Date()
    println someDate - 3.months 
}

Если бы вы делали это через класс java.util.Calendar, вам бы пришлось написать что-то вроде этого для первого примера:

void demo() {
    Calendar date = new GregorianCalendar();
    date.add(Calendar.MINUTE, 1);
    System.out.println(date);
}

0

Компьютерные языки (даже рудиментарные машинные языки прошлых дней) являются человеческими языками, так как они в основном предназначены для общения с другими людьми, определяются людьми и используются только для передачи инструкций машине. Таким образом, они развиваются почти так же, как развиваются «естественные» языки (просто посмотрите «идиомы» для вашего любимого языка, посмотрите, как, например, C эволюционировал от K & R C к текущему ISO-C 2011. Но они существуют в другой среде, они должен передавать точное значение (компьютеры все еще слишком глупы, чтобы понимать и исправлять то, что от них требуется), и существует простота в обработке (таким образом, грамматика и словарный запас даже C ++, PL / 1 или APL намного проще чем, например, английский, который, как и естественные языки, довольно прост).

То же самое можно сказать о формализме математики или наук в целом, или даже чертежах (по сути 2D, а не 1D, как другие).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.