Чи стали мови програмування більше схожими на природні мови?


27

Чи можемо ми вивчати мови програмування в контексті лінгвістики? Чи розвиваються мови програмування природним шляхом аналогічно природним мовам?

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

Чи розвиваються мови програмування, щоб вони стали більш мовними і, отже, більш природними? Наприклад, машинний код, перфокарти та мови складання поступилися місцем більш читаним мовам, як Ruby і Python тощо.

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

Що ви все думаєте? Чи стають мови програмування більш схожими на природні мови і, таким чином, стають застосовними до законів лінгвістики?

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

Чи існує зв’язок між (ефектом Вавилонської вежі) поділу людських мов та комп'ютерних мов? Чи стають вони більш різноманітними з одних і тих же причин (тобто для вирішення різних проблем у постійно розвиваються комп'ютерних системах / системах культури тощо)?


3
коротка відповідь: так, так вони є.

17
Коротка відповідь: ні, ні вони не є.


3
Комп'ютерні мови, як правило, добре справляються з терміновістю та точністю, дещо схожими на математичні позначення, які не виявляли особливих схильностей до розвитку природної мови (що мені відомо) протягом останніх кількох тисяч років. Я також сумніваюся, що якби ви спілкувались зі своїм немовлям виключно в Хаскеллі протягом перших кількох років його життя, він розвивав би природне володіння мовою. Отже, я думаю, що між природними та комп'ютерними мовами існує досить різкий контраст. Можливо, більш широке розповсюдження методів побудови мови, я думаю, з часом трохи покращило "природність".

@ryanOptini: Чи C #, JavaScript, Python чи SQL виглядають як природні мови? Хоча всі вони використовують ключові слова з англійської мови, жодне з них не переходить у природний мовний формат. COBOL, можливо, був найближчим, але я не думаю, що багато людей використовують COBOL для своїх проектів на тему «зелені поля».
Джим Г.

Відповіді:


32

Не дуже, ні. Мови програмування стали більше схожими на природні мови лише у значенні "слів, якими ми володіємо англійською мовою" ( sic ).

Ключовою особливістю мов програмування є те, що вони неоднозначні. Коли ви пишете програму та виконуєте її, вона має чітко визначене значення, яке полягає у її поведінці. Якщо ви хочете написати програму, яка працює за призначенням (складна мета), важливо, щоб поведінка¹ програми була максимально передбачуваною. Мови програмування не мали великої різниці в широкому розриві до природних мов.

І навпаки, проводилася робота з подолання розриву з іншого боку: аналіз природних мов з тими ж інструментами, що й мови програмування. Це поле називається природною обробкою мови . Ці підходи були майже відкинуті на користь машинного навчання . Я наводжу уривок у статті Вікіпедії, яка безпосередньо стосується тут:

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

Одним із способів розвитку програмування є те, що, коли ми розробляємо все більші та більші системи, вихідний код не завжди є хорошим способом їх розуміння. Наприклад, процесор Intel є одним із найскладніших об'єктів, який коли-небудь розробляв Man, і його "вихідний код" - це не просто колекція текстових файлів, далеко від нього. Але повний дизайн також не розвивається до того, що нагадує людську мову. Я не знаю, які відповідні когнітивні засоби чи метафори тут, і я не думаю, що ще ніхто не знає; запитайте знову через пару століть.

¹ А точніше, сукупність можливих поведінок, що пояснюється обставинами, за яких вони виникають, але це лише додає один крок непрямості в моделюванні, тому це насправді не актуально.


Варто зазначити, що спроби зробити "природні" мови, схожі на мови програмування, були не надто успішними. Дивіться Лойбана як найбільш розвинений приклад.
Дугал

порівняння між архітектурою процесора та програмуванням дещо хитрує, апаратне проектування завжди було в основному не текстовим, оскільки воно має зовсім інші проблеми для вирішення, наприклад, проблеми з розміщенням 2D та маршрутизацією. (якщо що-небудь апаратне проектування рухається до більш текстового дизайну з HDL)
jk.

2

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

Я також сумніваюся, що якби ви спілкувались зі своїм немовлям виключно в Хаскеллі протягом перших кількох років його життя, він розвивав би природне володіння мовою. Отже, я думаю, що між природними та комп'ютерними мовами існує досить різкий контраст.

Можливо, ширше розповсюдження методів побудови мови дещо покращило "природність", оскільки програмісти "голосують з ніг", використовуючи мови, які їм здаються легшими, а кількість людей, здатних створювати мови, збільшилася практиків і кращих інструментів, але це невеликий ефект по краях і не означає принципової трансформації мов програмування в людські.


2

цікавим тематичним прикладом у цій галузі є Перл проти Рубі (та Пітон ). Perl - це сценарій мови, розроблений на початку 90-х, який додав багато можливостей порівняно з попередніми сценаріями на основі Unix (наприклад, bash). автор Ларрі Уолл зазначає, що його досвід в мовознавстві надихнув деякі мовні особливості.

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

так, тут той випадок , коли еволюція комп'ютерних мов пішла геть від ідеї природної мови. більше того, загальна історія мов комп'ютерного програмування полягає в тому, що вони були розроблені та змінені для усунення неоднозначності (що дуже притаманне природній мові). це не було зрозуміло на початку історії компіляторів (скажімо, можливо, у 1970-х), і, наприклад, ранні версії мови Fortran мали висловлювання з неоднозначним значенням, які залежали від реалізації компілятора. деякі теорії мови CS, пов'язані з розбором, були розроблені частково у відповідь на виявлення неоднозначності в мовному синтаксичному розборі.


У вас неправильні дати: Perl був випущений у 1987 році, Bash у 1989 році. Також важко читати ваше повідомлення через помилки з великої літери.
tchrist

1

Машинна мова дуже точна, тоді як текст, написаний людиною, зазвичай може бути інтерпретований різними способами (наприклад, деякий поетичний текст).

Все більше і більше розвиваються відповідність шаблонів, наприклад, коли ви пишете якийсь некрасивий код, компілятор може допомогти вам запропонувати кілька можливих рішень, а потім викинути попередження або помилку, яка може допомогти вам висловити себе. (наприклад, на основі поширених моделей коду)

Існує специфічне дослідження взаємодії / моделей дизайну, навіть T9 та SWYPE - це розпізнавачі шаблонів, які дуже допомагають вам (програми, які записують ваш голос і перетворюють його в текст, є і розпізнавачами шаблонів).

Звичайно, програма - це те, що покладається на точні механізми, тому вам потрібні точні мови (не природні), тоді як простий веб-пошук в Google є дуже природним, вам просто потрібно набрати кілька слів, і ви отримаєте те, що хочете.

У кожного різних завдань і цілей є своя мова, це не проста "еволюція однієї мови", є набагато більше мов. Точні завдання потребують точних мов, а розслаблені - потрібні розслаблені мови

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


1

Декілька років тому ми з моїм старшим сином розробили звичайну систему програмування та розробки англійської мови з інтересом відповісти на наступні питання:

  1. Чи можуть програми низького рівня (як компілятори) бути написані зручно та ефективно написаними мовами високого рівня (наприклад, англійською)?

  2. Чи можна природні мови аналізувати відносно "неохайно" та все ж забезпечувати достатньо стабільне середовище для продуктивного програмування?

  3. Чи легше програмувати, коли не потрібно переводити свої думки на природній мові в альтернативний синтаксис?

Тепер ми можемо відповісти на кожне з цих трьох питань із прямого досвіду з гучним "Так".

Наш парсер працює, ми думаємо, щось на зразок людського мозку. Розглянемо. Батько каже своєму синові-немовляті:

"Хочете смоктати цю пляшку, хлопче?"

І дитина чує,

"бла, бла, СУК, бла, бла, БУТЬ, бла, бла."

Але він належним чином реагує, тому що у нього в правій частині голови є "зображення" пляшки, пов'язане зі словом "пляшка" з лівого боку, і попередньо "майстерність" біля задньої частини шиї, підключена до термін "смоктати". Іншими словами, малюк відповідає тому, що може, з накопиченими ним малюнками (типами) та навичками (підпрограми) та просто нехтує рештою. Наш компілятор робить те саме, що нові зображення (типи) та навички (підпрограми) визначаються - не нами, а - програмістом, коли він пише новий код програми.

Типове визначення типу виглядає так:

Багатокутник - це річ з деякими вершинами.

Всередині назва "багатокутник" тепер пов'язане з типом динамічно виділеної структури, яка містить подвійно пов'язаний список вершин. "Вершина" визначається в іншому місці (до або після цього визначення) аналогічно; множина розуміється автоматично.

Типовий розпорядок виглядає так:

Щоб додати багатокутник x і ay координату: Створіть вершину, задану x і y. Додайте вершину до вершин багатокутника.

Зауважте, що формальні імена (власні іменники) не потрібні для параметрів та змінних. Ми вважаємо, що це головне розуміння. Мій стілець і стіл у реальному світі ніколи (в звичайній розмові) не називаються "c" або "myTable" - я називаю їх просто як "стілець" і "стіл". Так само і тут: "вершина" та "багатокутник" - це природні назви таких речей.

Зауважте також, що пробіли дозволені в рутинних та змінних "іменах" (наприклад, "x координата"). Це 21 століття, так? І що "прізвиська" також дозволені (наприклад, "x" для "x координата"). І що володарі ("вершини полігону") використовуються дуже природним чином для посилання на "поля" в межах "записів".

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

На найнижчому рівні все виглядає так:

Щоб додати номер до іншого числа: Intel $ 8B85080000008B008B9D0C0000000103.

Зауважте, що в цьому випадку ми маємо як найвищий, так і найнижчий з мов - англійську та машинний код (хоча і в шістнадцятковій) - в єдиному розпорядку. Розуміння тут полягає в тому, що (як типова математична книга) програма повинна бути написана головним чином на природній мові, з відповідними фрагментами в більш зручних синтаксисах (як і потрібно).

Ви можете отримати нашу систему розвитку тут: www.osmosian.com/cal-3040.zip. Це невелика програма Windows, розміром менше мегабайт. Якщо ви почнете з PDF у каталозі "документація", перед тим, як перейти на десять сторінок, ви будете перекомпілювати весь шебанг у себе (менше ніж за три секунди на найсучаснішій машині від Walmart).

Питання та коментарі слід адресувати на gerry.rzeppa@pobox.com


Чи знаєте ви про керовану англійською мовою спробу.ifi.uzh.ch/site/description ? ви, здається, сидите між цим та Inform7 en.wikipedia.org/wiki/Inform#Example_game_2
Піт

Мені подобається ідея, але, схоже, є ще синтаксичні обручі, щоб проскочити через них. Наприклад, я не думаю, що я чи хтось, хто моделює геометричні речі, вважають, що координати X та Y додаються окремо, тому "Додавання координати x та ay координат ..." для мене звучить дуже дивно. Як і "Створіть вершину, задану x та y". Майже пробачити , так як він на справді читає в основному як англійська мова, але до сих пір здається занадто суворим. Можливо, я просто занадто звик, щоб не думати, як людина чи щось таке, я не знаю.
cHao

1

Відокремлення людських мов походить від (дарвінівської?) Еволюції в окремих громадах. Відокремлення мов програмування відбувається від варіацій технічної потреби, технічної ідеології, від змін у техніко-теоретичному розумінні, від змін у нашій технічній здатності до реалізації. Я думаю, це дещо більш свідомий процес.

Чи можуть комп'ютерні мови більше нагадувати природні мови? Можливо, дещо, до певного моменту. Я здогадуюсь, що значна частина складності природних мов є результатом різноманітних явищ еволюції, що не мають підстав для отримання послідовного результату в будь-який момент часу, хоча, ймовірно, старі невідповідності, ймовірно, прогресивно усуваються, а нові з'являються . Я не знавець діахронічної лінгвістики. Але чи хочемо ми такої складності в мовах програмування.

Питання про неоднозначність є важливим, але не таким, як заявляє більшість людей. Мова - це засіб спілкування, і її треба аналізувати в контексті цього спілкування (людина-людина, людина-машина, обидва, між місцями або між часом, ... сказати це трохи спрощено). Важливо не те, чи можна робити лише однозначні заяви мовою, а чи можна завжди гарантувати, що спілкування буде однозначним у визначеному контексті. Є одна добре відома і широко застосовувана мова програмування, яка дозволяє писати неоднозначні програми (ну, так, але я останній час не переглядав останні версії). У цьому випадку компілятор досить розумний, щоб виявити неоднозначність і попросити роз'яснення, які можуть бути включені в програму усунення неоднозначності. Зауважте, що виявлення неоднозначності не означає, що лише один з можливих варіантів має значення, який вони мають. Питання полягає в тому, чи може хтось із комунікаційних організацій виявити неоднозначність, щоб відправник міг уточнити це. Людям в цьому погано, але комп'ютери можуть бути досить хорошими.

Формалізми та мови програмування можуть мати ситніший і гнучкіший синтаксис. Я вважаю, що головна причина, чому вони цього не роблять, - це простий консерватизм. Синтаксичні інструменти, що застосовуються, як і раніше, дуже часто є інструментами, розробленими тридцять років тому і більше, щоб відповідати обмеженням комп’ютерів того часу. Ефективність розбору вже не є настільки важливим питанням у складанні, і більш потужні методи існують трагічно.

Цікаво, що найбільш широко використовувана основа для синтаксису мов програмування походить від досліджень природних мов: без контексту граматики. Значна частина технічних досліджень перенесла теоретичну / технічну інформатику в шістдесяті роки, щоб бути дещо відтвореною на початку вісімдесятих людей природною мовою (я спрощую). З тих пір було досягнуто значного прогресу в синтаксисі природними мовами, в той час як комп'ютерна наука значною мірою дотримується старих синтаксичних інструментів. Маятник природної мови тепер знову хитається до статистичних прийомів, але алгебраїчні підходи до синтаксису не забуваються. Швидше за все, хороші підходи вийдуть із поєднання алгебраїчних та статистичних методик.

Я відчуваю, що критичною областю є семантика та перехід між синтаксисом та семантикою. Це все ще дуже важко формалізувати для природної мови, тоді як у нас є багато точних методик у випадку мов програмування та формальних систем. Оскільки ця гра далеко не грається для природних мов, важко сказати, який вплив вона може мати на мови програмування в майбутньому.

Ще один момент полягає в тому, що багато дизайнерів мови програмування намагаються щось довести або нав'язати технічну ідеологію. Таким чином, вони отримують надзвичайно вподобання в своєму дизайні, щоб не допустити користувачів відходити від своїх передбачених парадигм. На жаль, це надзвичайно контрпродуктивно для творчості. Найбільш творча мова, яку коли-небудь розробляли, була серед перших: Лісп (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.