Qual è lo scopo di aggiungere il supporto dell'identificatore Unicode a varie implementazioni linguistiche?

Personalmente trovo confuso il codice di lettura pieno di identificativi Unicode. A mio avviso, impedisce anche che il codice venga facilmente gestito. Per non parlare di tutto lo sforzo richiesto agli autori di vari traduttori per implementare tale supporto. Noto anche costantemente la mancanza (o la presenza) del supporto degli identificatori Unicode negli elenchi dei (dis) vantaggi delle varie implementazioni linguistiche (come se davvero importasse). Non capisco: perché tanta attenzione?

Quando pensi all'unicode, pensi ai caratteri cinesi o russi, il che ti fa pensare a qualche codice sorgente scritto in russo che hai visto su Internet e che era inutilizzabile (a meno che tu non conosca il russo).

Ma se unicode può essere usato in modo sbagliato, ciò non significa che sia di per sé dannoso nel codice sorgente.

Quando si scrive il codice per un campo specifico, con Unicode, è possibile abbreviare il codice e renderlo più leggibile . Invece di:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

tu puoi scrivere:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

che potrebbe non essere facile da leggere per uno sviluppatore medio, ma è comunque facile da leggere per una persona che usa quotidianamente simboli matematici .

Oppure, quando si esegue un'applicazione correlata alla fotografia reflex, anziché:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

puoi sostituire l' apertura con il suo simbolo ƒ, con una scritta più vicina a ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

Questo può essere scomodo : quando si digita un codice C # generale, preferirei scrivere:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

piuttosto che:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

perché nel primo caso IntelliSense mi aiuta a scrivere l'intero codice quasi senza digitare e soprattutto senza usare il mouse, mentre nel secondo caso non ho idea di dove trovare quei simboli e sarei costretto a fare affidamento sul mouse per andare e cercarli nell'elenco di completamento automatico.

Detto questo, è ancora utile in alcuni casi. currentLens.GetMaximumƒ();del mio esempio precedente posso fare affidamento su IntelliSense ed è facile da scrivere come GetMaximumAperture, essendo più breve e più leggibile. Inoltre, per domini specifici con molti simboli, le scorciatoie da tastiera possono aiutare a digitare i simboli più velocemente dei loro equivalenti letterali nel codice sorgente.

Lo stesso vale per i commenti. Nessuno vuole leggere il codice pieno di commenti in cinese (a meno che tu non conosca bene il cinese da solo). Ma in alcuni linguaggi di programmazione, i simboli unicode possono ancora essere utili. Un esempio sono le note a piè di pagina¹.

^{¹ Di certo non mi piacerebbero le note a piè di pagina nel codice C # dove esiste un rigido set di regole di stile su come scrivere commenti. In PHP, d'altra parte, se ci sono molte cose da spiegare, ma quelle cose non sono molto importanti, perché non metterle in fondo al file e creare una nota a piè di pagina nel PHPDoc del metodo?}

Direi:

1. per facilitare i non professionisti e i principianti che imparano la programmazione (ad esempio a scuola) e non conoscono l'inglese. Non scrivono comunque codice di produzione. Ho visto molte volte codice come:

   double upsos, baros;
   cin >> upsos >> baros;
   

   Lascia che il povero ragazzo lo scriva nella sua lingua:

   double ύψος, βάρος;
   cin >> ύψος >> βάρος;
   

2. Non ti piace?

   class ☎ {
   public:
       ☎(const char*);
       void 📞();
       void 🎧(👨);
   };
   
   ☎ ☏("031415926");
   ☏.🎧(👨("Bob"));
   ofstream f;
   f.💾();
   

Naturalmente, ogni moderno compilatore deve gestire il codice sorgente Unicode oggi. Ad esempio, potrebbe essere necessario che le costanti di stringa contengano caratteri Unicode. Ma una volta raggiunto questo obiettivo, perché non consentire anche gli identificatori unicode? Non è un grosso problema a meno che il codice del compilatore non dipenda dal fatto che i caratteri siano codici a 7 bit.

Ma il PO è giusto nella misura in cui: ora è possibile che un indiano di lingua hindi debba mantenere il codice con identificatori russi e commenti arabi. Che incubo per il povero cinese che dovrebbe fare il controllo di qualità e che non sa leggere nessuno dei 3 alfabeti sopra!

Quindi, ora è un compito organizzativo assicurarsi che gli identificatori di programmi e i commenti siano scritti in un linguaggio comune. Non posso farci niente ma penso che questo sarà inglese per un po 'di tempo a venire.

Penso che abbia molto senso consentire caratteri unicode in stringhe e commenti. E se il lexer e il parser devono supportare unicode per quello, lo scrittore del compilatore probabilmente ottiene gratuitamente il supporto dei caratteri unicode negli identificatori, quindi sembrerebbe una limitazione arbitraria consentire solo i caratteri ASCII negli identificatori.

Per quanto mi riguarda, ciò è puramente per ragioni di marketing . E inoltre potrebbe rendere le nostre vite più difficili.

Gli argomenti di marketing

Conosci questo folle elenco di funzionalità di cui la maggior parte delle lingue si vanta? È praticamente inutile in generale, perché è così lontano dal linguaggio che non fornisce molte informazioni su specifici, ma consente di vestire rapidamente le tabelle con tick e croci e giustamente concludere che poiché X ha più tick di Y, deve essere migliore.

Bene, il supporto Unicode per gli identificatori è una di quelle righe. Non importa che rispetto al supporto Lambda, supporto alla programmazione generica, ecc ... potrebbe non essere molto, le persone che disegnano i tavoli non si preoccupano della qualità di ogni linea, ma solo del numero di esse.

E così possono vantarsi: "Ah, con Y non hai il supporto Unicode per i tuoi identificatori! In X lo facciamo, quindi per gli studenti è molto più facile!"

L'errore dell'accessibilità

Sfortunatamente, l'argomento dell'accessibilità è fallace.

Oh, capisco che poter scrivere "résultatDuJetDeDé" anziché "diceThrowResult" (sì, sono francese) potrebbe sembrare una vittoria a breve termine ... tuttavia ci sono degli svantaggi!

La programmazione riguarda la comunicazione

Il tuo programma non è pensato solo per il compilatore (che potrebbe interessare meno agli identificatori che usi), ma è anche pensato per i tuoi compagni. Devono essere in grado di leggerlo e capirlo.

• leggerlo implica essere in grado di visualizzare i caratteri che hai usato, Unicode non è così ben supportato da tutti i caratteri
• capirlo significa fare affidamento sugli identificatori, a meno che non li si integri con commenti lunghi, ma ciò viola la regola DRY.

Certo, il tuo compagno di classe può parlare la stessa lingua che conosci (non ovvio, ho avuto lezioni di programmazione con tedeschi, spagnoli, libanesi e cinesi), e così può il tuo insegnante ... ma supponi che in qualche modo ci stai lavorando a casa e improvvisamente hai bisogno di aiuto: Internet è fantastico, puoi parlare con migliaia di migliaia di persone che conoscono la soluzione, risponderanno solo se capiscono la tua domanda. E devi anche capire la loro risposta.

La programmazione richiede comprensione

L'accessibilità e l'iniziazione richiedono di basarsi sulle librerie per fare il lavoro pesante per te: non vuoi reinventare un livello IO per leggere / scrivere sulla console al tuo primo incarico.

• In quale lingua sono scritte quelle biblioteche?
• In quale lingua sono documentate quelle biblioteche?

Se rispondi all'arabo marocchino, rimarrò sorpreso.

A meno che non solo contare sulle lezioni si assiste a, e quelli presenti una documentazione completa su ogni funzione di libreria è necessario l'uso (e forse anche le librerie tradotti), allora si dovrà imparare un modicrum della lingua inglese. Ma poi, probabilmente hai già fatto molto prima di iniziare questo corso di programmazione.

L'inglese è...

... la lingua franca dei programmatori (e della maggior parte degli scienziati).

Prima lo ammetti e lo segue piuttosto che combatterlo, prima può davvero imparare e progredire.

Alcuni inevitabilmente si opporranno a questo, e giustamente difenderanno il loro diritto di parlare la lingua di loro scelta (la loro lingua materna di solito), tuttavia, come dimostrò Babele, più lingue vengono utilizzate, più diventa difficile la comunicazione.

Ancora...

Sì, come è stato ribadito più volte, alcuni supporti Unicode (principalmente simboli) possono facilitare notevolmente la comprensione per le persone che devono tradurre formule matematiche o fisiche, ad esempio, in codice. Lo svantaggio è che alcuni simboli sono sovraccarichi, ma potrebbe comunque aiutare.

Allora perchè?

Bene, come detto, non si tratta in realtà della praticità dell'utente, quanto delle rivendicazioni di marketing. È anche facile, dato che il parser è già Unicode consapevole di stringhe e commenti, quindi la maggior parte fa il salto.

E potrebbe esserci un vantaggio per alcuni utenti.

Personalmente mi occuperò solo del codice scritto con identificatori inglesi. Non mi importa se hai bisogno del mio aiuto con il tuo pezzo di codice o se la tua libreria è semplicemente fantastica e potrei guadagnare molto usandolo: se non riesco a capirlo, dovrò semplicemente ignorarlo.

Come hai intenzione di digitare identificatori ASCII su una tastiera cinese? Alcune parole chiave in una lingua sono una cosa, e dover fare l'intero codice in questo modo è un'altra.

I programmatori dovrebbero avere il diritto e la capacità di chiamare le loro variabili come vogliono. Non sono affari tuoi in che lingua è.

Se ti senti così confuso nel leggere il codice con identificatori che contengono simboli delle lingue di altre persone, allora sono sicuro che capisci esattamente quanto si sentono confusi quando devono usare identificatori con simboli della tua lingua.

Secondo PEP 3131 - Supporto degli identificativi non ASCII datati nel 2007, la prima parte della motivazione afferma:

Il codice Python è scritto da molte persone nel mondo che non hanno familiarità con la lingua inglese o che non conoscono bene il sistema di scrittura latina. Tali sviluppatori desiderano spesso definire classi e funzioni con nomi nelle loro lingue native, piuttosto che dover inventare una traduzione inglese (spesso errata) del concetto che vogliono nominare. Utilizzando gli identificatori nella loro lingua madre, migliora la chiarezza del codice e la manutenibilità del codice tra i parlanti di quella lingua.

Non ho ancora studiato altre lingue, ma dovrebbe essere tra i motivi per cui hanno aggiunto il supporto.

Renderebbe davvero la vita più semplice (per alcuni di noi, comunque) se il compilatore non supportasse Unicode. Gli identificatori da destra a sinistra sono terribili. Gli identificatori di alfabeto romano combinato e Unicode da destra a sinistra sono anche peggio.

La cosa negativa del non supporto è che alcune procedure guidate della GUI prendono il testo che hai inserito per un oggetto e lo usano automaticamente come identificativo dell'elemento. Quindi cosa farebbero esattamente con il testo Unicode su quegli elementi? Nessuna risposta facile, temo.

Anche i commenti Unicode da destra a sinistra possono essere divertenti. Ad esempio, in VS 2010, i commenti XML vengono visualizzati (correttamente) come RTL nel codice ... ma quando si utilizza Intellisense per estrarre l'identificatore altrove nel codice, la descrizione comandi visualizza (erroneamente) LTR. Meglio, forse, se non ci fosse supporto in primo luogo? Ancora una volta, non è una chiamata facile.