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

комп

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

Я також сказав, що є два способи вказати параметри. Одна з них полягає в тому, що існує безліч порядок, в якому ми можемо вказати параметри, і звідси програма “знає”, який параметр має яке значення. Наприклад, “replace”, тобто спочатку ми повинні вказати рядок, який потрібно замінити, другий - той, який ми хочемо замінити, і третій - весь рядок, у якому відбувається заміна. Інший варіант - вони є ключові слова, який ми можемо використовувати для позначення того, про який параметр ми думаємо, наприклад “replace target =. новий =. повна =. ”, Де після ключових слів„ мета ”,„ новий ”та„ завершена ”ми вказуємо, що, коли і що ми хочемо замінити. У цьому другому випадку, звичайно, неважливо, в якому порядку ми вводимо ключові слова (зі значеннями, що слідують за ними).

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

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

У мовах програмування нічого подібного не гарантується. Ми могли б сказати, що всі програми повністю “внутрішні” щодо того, як вони обробляють зовнішні параметри (або з точки зору їх замовлення, або ключових слів). Незалежно від того, чи ми ідентифікуємо параметри з їх серійними номерами чи ключовими словами, це схоже ми б назвали це їх, а зовнішній світ повинен був би знати їх імена, щоб записати їх значення. Однак імена - це своєрідна мітка, абсолютно довільна, що походить від простого іменування, жодним чином не передбачаючи, що ми маємо на увазі під ними. Тож тут я повинен забрати пряжу.

Замість примусу

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

Графіка: Тот Роберт Йонас/Кубіт

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

У природних мовах щось подібне насправді трапляється. Наприклад, це правда, що a -з Суфікс використовується для багатьох цілей угорською мовою, але якщо ми подивимося на його використання окремо, ми можемо охарактеризувати його роль за допомогою певного обмеження. Коли він позначає прикметник, він замінює опис „використання цієї речі як пристосування”, коли ідентифікує співприкметник, замінює „з цією річчю”. Звичайно, вже залежить від значення висловлювання та розширення, як саме можна реалізувати зміст цих циркулярів. Наприклад, він їде на машині розуміючи цей термін, нам потрібно з’ясувати, як автомобіль можна використовувати як засіб руху (можливо, сидячи всередині) і яким може бути рух, коли автомобіль робиться як засіб. THE Я пішов з Джозі для розуміння цього терміну потрібно не так багато: ми з Йозі пішли кудись одночасно і в безпосередній близькості один від одного.

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

Суть паралелі з природною мовою полягає в тому, що змістовна, не довільна параметризація базується на знанні змісту висловлювання чи програми, тому ми підключаємо параметр до нього з точки зору змісту, а не довільних формальних засобів. Наведу приклад із комп’ютерних програм. Існує багато програм, які перетворюють файли. Незалежно від характеру перетворення, ці програми відкривають файл, працюють з його вмістом і друкують результати своїх обчислень в інший файл. Якщо ми знаємо так багато про семантику програми (і це, очевидно, не є внутрішньою справою програми), то цього має бути достатньо, щоб стандартними способами дати відповідні параметри (назва прочитаного та записаного файлу). Було б бажано, щоб параметри вказувались для кожного члена сім’ї точно однаково для всієї родини таких програм.

Як формально це можна було б зробити, також міг бути використаний такий побічний питання, як ключове слово (наприклад, pdf2svg з f1 озеро f2 може свідчити про те, що це так f1 файл, який потрібно конвертувати, та f2 буде ім'ям перетвореного файлу). Єдине, що якщо ми виберемо це рішення, наприклад, тоді і to повинні бути не ключові слова, а вирази із вмістом, що для програм, які не читають і не записують файл, призводить до дурниць (і це приємний вміст. Може також вказується повідомленням про помилку). А від f1 і до f2 а його зміст - обмежена версія (у лінгвістиці їх називають певними описами), яка фактично стосується тієї частини програми, яка містить читання одного файлу та друк іншого.

Ще ближче до людської мови

Цю „істотну” параметризацію можна було б розвивати у двох напрямках. Одне з них могло б бути те, що, за прикладом природних мов, навіть двозначність могла б бути дозволена, якби це не могло призвести до непорозумінь. Наприклад, можливо, що від та до можуть навіть вказувати віртуальні розташування (наприклад, папки з і до яких ви хочете перемістити файл). Або, наприклад, це можна зробити, якщо є параметр (який називається «об’єктом»), який не має власних позначень, і це завжди той параметр, який відіграє найважливішу роль у процесах, описаних програмою. Тобто тут вже було б багато неоднозначностей, як тема звикла природними мовами. (Позначення "теми" для програм, як правило, безглуздо, оскільки програми завжди використовуються в "швидкому режимі".)

Інший напрямок подальшого розвитку вже трохи потрапляє до категорії наукової фантастики. Можливо, зв’язок між параметрами та програмою також може бути метонімічним. Наприклад, природною мовою ми розуміємо такі терміни, як Я чую Острів, хоча, строго кажучи, можна почути лише звук, а Острів не звук. Зрозуміло, що в процесі розуміння, якщо ми хочемо припустити процес будь-якою ціною, це має місце Острів ми тоді маємо на увазі слово метонімічно як „те, що пов’язано з островом і може бути почуте”, і тому ми потрапляємо туди під музику на острові (або інший шум, що доноситься звідти). Це схоже на випадок, коли зелене яблуко ми говоримо про: метонімія все ще передбачає вставку проміжного елемента значення. Зелене на яблуці має тенденцію не всередині, а шкіркою, тому зелене яблуко Інтерпретація "зеленого яблука".

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

Я думаю, що моделювання метонімії також можна вирішити, все, що нам потрібно зробити, це знати ще більше про зміст програми. Візьміть приклад. Припустимо, у нас є параметр, “значенням” якого є вказання значення гучності, але ми не маємо прямих знань про нашу програму для виведення звуку. Скажімо, це програма відеопрогравача, частина якої, звичайно, піклується про відтворення звуку, але це робиться шляхом запуску іншої програми десь у програмі. Отже, щоб правильно інтерпретувати параметр гучності, нам потрібно знати не тільки саму програму, але й інші програми, що використовуються в ній, які запускаються як підпрограми. Тобто метонімія - це не що інше, як така непряма специфікація параметрів.

Яка мета?

Наразі я писав, що було б простіше навчитися користуватися програмами, якби використання параметрів було рівномірним, на основі вмісту. Це легко можна вважати програмістам досить незначною деталлю, тим більше, що за це доведеться заплатити досить високу ціну: детальна база даних програмного змісту повинна вестись і підтримуватись (хоча, я думаю, це було б дуже автоматизовано ). Тож я почав із простої дидактичної точки зору. У той же час паралелі з природними мовами говорять про те, що цей досвід також може бути корисним для кращого розуміння семантики людських мов. Експерименти зі штучними мовами, такими як мови програмування, можуть наблизити вас до розуміння значення, метонімії та метафори розширень, модифікаторів, дієслів та інших.