Program de calculator și gândire umană

Am ajuns deja la a treia parte a seriei în care vorbesc despre o latură ciudată a semanticii limbajelor de programare. Vorbim întotdeauna despre relația dintre un computer și o persoană în ceea ce privește modul în care un computer poate imita modul în care se comportă o persoană (vorbește, înțelege și așa mai departe). Totuși, aici s-a pus problema care sunt caracteristicile programelor de calculator care le fac atât de dificile de utilizat în comparație cu limbajele umane.

Până acum, am vorbit despre programe care fac același lucru de fiecare dată când rulează, dacă nu ar fi fost parametrii lor, părțile lor variabile, care sunt diferite chiar și cu fiecare alergare valoare și din această cauză, programele se comportă diferit de la un caz la altul. Adică nu descriu un proces destul de precis, ci doar aproximativ, schematic; părțile variabile ale acestora pot fi diferite de la proces la proces, în funcție de parametrii pe care îi setăm, ce valori atribuim parametrilor.

De asemenea, am spus că există două moduri de a specifica parametrii. Una este că există un set Ordin, în care putem specifica parametrii, iar de aici programul „știe” ce parametru are ce valoare. De exemplu, „înlocuiți”, adică trebuie mai întâi să specificăm șirul care trebuie înlocuit, al doilea este ceea ce dorim să înlocuim, iar al treilea este întregul șir în cadrul căruia urmează să se facă înlocuirea. Cealaltă opțiune este că sunt Cuvinte cheie, pe care îl putem folosi pentru a indica la ce parametru ne gândim, de exemplu „înlocuiți ținta =. nou =. plin =. ”, Unde după cuvintele cheie„ obiectiv ”,„ nou ”și„ complet ”, specificăm ce, când și ce vrem să înlocuim. În acest al doilea caz, desigur, nu contează în ce ordine introducem cuvintele cheie (cu valorile care le urmează).

Problema în ambele cazuri este arbitrar. Nu rezultă din nimic (și, prin urmare, este foarte dificil de învățat) de ce este ordinea obligatorie a parametrilor și, de asemenea, rezultă din nimic că este posibil să se specifice valoarea lor chiar cu cuvintele cheie cu care sunt utilizați . Toate acestea sunt decizii ale programatorului și oricine dorește să utilizeze programul poate afla doar din documentație cum să specifice parametrii.

În cele din urmă, am mai spus că, desigur, există o mulțime de arbitrari și în limbile naturale, chiar și în ce caz sau nume pentru a denota rolul diferiților participanți la un eveniment (de ex. lipseste, nu tu). Dar în limbile naturale, cu cât există mai multe verbe cu semnificații similare, cu atât este mai probabil să marcăm rolurile (similare) ale diferiților participanți într-un mod similar, iar acest lucru va face lucrurile mai ușoare pentru cel care învață limba sau copilul care învață limba.

Nu există nicio garanție pentru așa ceva în limbajele de programare. Am putea spune că toate programele sunt în întregime „interne” despre modul în care gestionează parametrii specifici extern (fie în ceea ce privește ordinea lor, fie cuvintele cheie). Fie că identificăm parametrii cu numerele lor de serie sau cuvintele cheie, este ca și cum l-am numi ei, iar lumea exterioară ar trebui să le cunoască numele pentru a-și înregistra valoarea. Cu toate acestea, numele sunt un fel de etichetă, complet arbitrară, derivată din simpla denumire, care nu sugerează în niciun caz la ce ne referim prin ele. Așa că aici trebuie să ridic firele.

În loc de constrângere

Am menționat deja în secțiunea anterioară că, desigur, nu se pune problema unei soluții care presupune reglementarea programatorilor, adică să-i forțăm să folosească obiceiuri diferite decât obiceiurile lor obișnuite. Poate exista o singură soluție, astfel încât fiecare program să nu aibă de-a face cu modul în care sunt tratați parametrii lor.

Grafică: Tóth Róbert Jónás/Qubit

În special, nu ne putem gândi decât la o soluție care înlocuiește actul arbitrar al numelui cu altceva. Cum putem identifica ceva dacă nu numindu-l? Să încercăm doar ce putem face dacă nu știm numele a ceva. Evident, vom încerca „circumscrierea”.

În limbile naturale, așa ceva se întâmplă de fapt. De exemplu, este adevărat că a -cu Sufixul este folosit în mai multe scopuri în limba maghiară, dar dacă ne uităm la utilizarea sa separat, îi putem caracteriza rolul cu un fel de circumscripție. Când denotă adjectivul dispozitivului, înlocuiește o descriere a „folosirii acestui lucru ca dispozitiv”, atunci când identifică un co-adjectiv, înlocuiește „cu acest lucru”. Desigur, este deja la înțelesul afirmației și al extinderii modul în care poate fi realizat exact conținutul acestor circulare. De exemplu, el merge cu mașina pentru a înțelege termenul, trebuie să ne dăm seama cum poate fi folosită mașina ca mijloc de mișcare (probabil stând în interior) și cum poate fi mișcarea atunci când o mașină se face ca mijloc. THE Am mers cu Józsi nu este nevoie de mult pentru a înțelege termenul: Józsi și cu mine am mers undeva în același timp și în imediata apropiere.

Limbajele de programare pentru computer le place să evite ambiguitatea atât de caracteristică a limbajului natural (deși nu în toate). Prin urmare, nu trebuie să ne ocupăm acum de faptul că în exemplele de mai sus a -cu datorită ambiguității sale, trebuie chiar constatat că în cazul mașinii este un dispozitiv, iar în cazul lui Józsi este un ansamblu. Acum putem renunța la faptul că merge verbul este, de asemenea, ambiguu, cel puțin în sensul că trebuie să schimbăm locul folosind un instrument destul de diferit decât pe propriile picioare. Totuși, astfel de diferențe pot apărea și în cazul programelor, adică un program poate funcționa diferit în funcție de valoarea unuia dintre parametrii săi.

Esența paralelei cu limbajul natural este că parametrizarea semnificativă, non-arbitrară, se bazează pe cunoașterea conținutului enunțului sau al programului, astfel încât să conectăm parametrul la acesta în ceea ce privește conținutul, nu mijloacele formale arbitrare. Voi da un exemplu din programe de calculator. Există o mulțime de programe care convertesc fișiere. Indiferent de natura conversiei, aceste programe deschid un fișier, lucrează cu conținutul acestuia și imprimă rezultatele calculelor lor într-un alt fișier. Dacă știm atât de multe despre semantica unui program (și aceasta nu este evident o problemă internă a programului), atunci acest lucru ar trebui să fie suficient pentru a da parametrii corespunzători (numele fișierului citit și scris) într-un mod standard. Ar fi de dorit ca parametrii să fie specificați pentru fiecare membru al familiei exact în același mod în întreaga familie a unor astfel de programe.

Cât de formal s-ar face acest lucru, ar putea fi utilizată și o întrebare secundară, cum ar fi cuvântul cheie (de exemplu, pdf2svg de la f1 lac f2 ar putea indica faptul că este f1 fișier pe care doriți să îl convertiți și f2 va fi numele fișierului convertit). Singurul lucru este că, dacă alegem această soluție, de exemplu, de la și la nu ar trebui să fie cuvinte cheie, ci expresii cu conținut, care pentru programele care nu citesc sau scriu un fișier vor duce la prostii (și acesta este un conținut plăcut) poate fi indicat și printr-un mesaj de eroare). A din f1 și a f2 iar conținutul său este o circumscripție (în lingvistică acestea se numesc descrieri definite), care se referă de fapt la partea programului care conține citirea unui fișier și tipărirea celuilalt.

Chiar mai aproape de limbajul uman

Această parametrizare „substanțială” ar putea fi dezvoltată în continuare în două direcții. Una ar fi că, urmând exemplul limbajelor naturale, chiar și ambiguitatea ar putea fi permisă dacă nu ar putea duce la neînțelegeri. De exemplu, este posibil ca de la și la să poată indica chiar locații virtuale (cum ar fi foldere din și către care doriți să mutați un fișier). Sau, de exemplu, se poate face pentru a avea un parametru (numit „obiect”) care nu are notație proprie și acesta este întotdeauna parametrul care joacă cel mai important rol în procesele descrise de program. Adică, ar exista multiple ambiguități aici, deoarece subiectul este folosit în limbi naturale. (Marcarea „subiectului” pentru programe este de obicei lipsită de sens, deoarece programele sunt întotdeauna utilizate în „modul prompt”.)

Cealaltă direcție a dezvoltării ulterioare se încadrează deja în categoria science fiction un pic. Acest lucru ar putea fi faptul că relația dintre parametri și program ar putea fi, de asemenea, metonimică. De exemplu, în limbaj natural, înțelegem termeni precum Aud Insula, deși, strict vorbind, se poate auzi doar sunet, iar Insula nu este sunet. Este clar că, în procesul de înțelegere, dacă vrem să presupunem cu orice preț un proces, are loc acest lucru Insulă atunci ne referim la cuvântul metonimic ca „ceea ce este conectat la insulă și poate fi auzit”, așa că ajungem acolo la muzica de pe insulă (sau alt zgomot care vine de acolo). Acest lucru este similar cu cazul când Mar verde vorbim despre: metonimia presupune încă inserarea unui element intermediar de semnificație. Ceea ce tinde să fie verde pe măr nu este interiorul, ci coaja, deci Mar verde Interpretarea „mărului verde”.

Cum ar arăta acest lucru pentru programe? Vorbeam despre precizarea că ar trebui să aibă sens atunci când se specifică parametrii rolul lor lăsați parametrul să fie, iar acest rol trebuie să fie unul care, pe baza cunoștințelor noastre despre program, poate corespunde în mod clar unui detaliu al programului. (De exemplu, în exemplul de mai sus, pentru programele de conversie a fișierelor, aceste cunoștințe sunt că o parte a programului citește un fișier și o altă parte imprimă un fișier.) Metonimia ar însemna că o presupunere a unui element de raport intermediar. De ce nu?

Cred că poate fi rezolvată și simularea metonimiei, tot ce trebuie să facem este să știm și mai multe despre conținutul programului. Luați un exemplu. Să presupunem că avem un parametru al cărui „sens” este să specificăm o valoare a volumului, dar nu avem cunoștințe directe despre programul nostru pentru a emite sunet. Să presupunem că este un program de redare video, o parte din care, desigur, se ocupă de redarea sunetului, dar se face pornind un alt program undeva în cadrul programului. Deci, pentru a interpreta corect parametrul volumului, trebuie să cunoaștem nu numai programul în sine, ci și celelalte programe utilizate în acesta care sunt pornite ca subrutine. Adică, metonimia nu este altceva decât o astfel de specificație indirectă a parametrilor.

Care este scopul?

Până acum, am scris că ar fi mai ușor să învăț cum să folosesc programe dacă utilizarea parametrilor ar fi uniformă, bazată pe conținut. Programatorii ar putea considera cu ușurință un detaliu destul de nesemnificativ, mai ales că ar trebui să plătiți un preț destul de ridicat pentru acesta: o bază de date detaliată a conținutului programului ar trebui menținută și întreținută (deși cred că acest lucru ar fi extrem de automatizat) ). Așa că am început dintr-un simplu punct de vedere didactic. În același timp, paralelele cu limbajele naturale sugerează că aceste experiențe ar putea fi utile și pentru o mai bună înțelegere a semanticii limbilor umane. Experimentarea cu limbaje artificiale, cum ar fi limbaje de programare, vă poate aduce mai aproape de înțelegerea sensului, metonimiei și metaforelor extensiilor, modificatorilor, verbelor și altele.