A cosa serve aggiungere il supporto dell'identificatore Unicode alle varie implementazioni linguistiche?

13

Personalmente trovo il codice di lettura pieno di identificativi Unicode che confondono. A mio parere, impedisce anche che il codice venga facilmente mantenuto. Per non parlare di tutti gli sforzi richiesti agli autori di vari traduttori per implementare tale supporto. Ho anche notato costantemente la mancanza (o la presenza) di supporto degli identificatori Unicode negli elenchi di (dis) vantaggi di varie implementazioni linguistiche (come se fosse davvero importante). Non capisco: perché tanta attenzione?

    
posta Egor Tensin 13.11.2011 - 18:02
fonte

8 risposte

15

Quando ritieni l'unicode, ritieni che i caratteri cinesi o russi ti facciano pensare a un 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 utilizzato in modo errato, non significa che sia dannoso da solo nel codice sorgente.

Quando scrivi un codice per un campo specifico, con unicode, puoi 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);

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 è ancora facile da leggere per una persona che utilizza quotidianamente simboli matematici .

Oppure, quando si fa un'applicazione relativa 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 digiti il codice generale C #, preferisco scrivere:

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

anziché:

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 a cercarli nell'elenco di completamento automatico.

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

Lo stesso, a proposito, si applica ai commenti. Nessuno vuole leggere il codice pieno di commenti in cinese (a meno che tu non conosca bene te cinese). Ma in alcuni linguaggi di programmazione, i simboli Unicode possono ancora essere utili. Un esempio è footnotes¹.

¹ Di certo non apprezzerei le note a piè di pagina nel codice C # in cui vi è un rigido insieme 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 in PHPDoc del metodo?

    
risposta data 01.01.2012 - 11:46
fonte
8

Direi:

  1. per facilitare i non professionisti e i novizi che apprendono la programmazione (ad es. a scuola) e non sanno l'inglese. Non scrivono comunque codice di produzione. Ho visto molte volte codice come:

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

    Lascia che sia il povero a scriverlo nella sua lingua:

    double ύψος, βάρος;
    cin >> ύψος >> βάρος;
    
  2. Non ti piace?

    class ☎ {
    public:
        ☎(const char*);
        void                                     
risposta data 31.12.2011 - 22:13
fonte
5

Naturalmente, ogni compilatore moderno deve gestire il codice sorgente Unicode oggi. Ad esempio, le costanti di stringa potrebbero dover contenere 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 dai codici a 7 bit.

Ma l'OP ha ragione nella misura in cui: è ora possibile che un indiano che parla 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 può leggere nessuno dei 3 alfabeti precedenti!

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

    
risposta data 21.11.2011 - 15:25
fonte
4

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

    
risposta data 14.11.2011 - 08:53
fonte
4

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

Gli argomenti di marketing

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

Bene, il supporto Unicode per gli identificatori è una di quelle linee. Non importa che rispetto al supporto Lambda, al supporto di programmazione generico, ecc ... potrebbe non essere molto, le persone che disegnano le tabelle non si preoccupano della qualità di ciascuna linea, solo del numero di esse.

E quindi 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 di accessibilità

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

Oh, capisco che essere in grado di scrivere "résultatDuJetDeDé" invece di "diceThrowResult" (sì, sono francese) possa 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 di meno degli identificatori che usi), è anche pensato per i tuoi compagni. Devono essere in grado di leggerlo e comprenderlo.

  • la lettura implica la possibilità di visualizzare i caratteri che hai usato, Unicode non è così ben supportato da tutti i tipi di carattere
  • capirlo significa fare affidamento sugli identificatori, a meno che non li completi con commenti lenghty, ma ciò sta violando la regola DRY.

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

La programmazione richiede comprensione

L'accessibilità e l'iniziazione richiedono di basarsi sulle librerie per eseguire il sollevamento pesi: non si desidera reinventare un livello IO per leggere / scrivere sulla console al primo incarico.

  • In quale lingua sono scritte queste librerie?
  • In quale lingua sono documentate queste librerie?

Se rispondi all'arabo marocchino, sarò sorpreso.

A meno che tu non faccia affidamento solo sulle lezioni alle quali ti assisti e su quelle presenti una documentazione completa su ogni funzione di libreria che dovrai usare (e forse anche le librerie tradotte), allora vorrà imparare un modicrum della lingua inglese. Ma probabilmente hai già fatto molto prima di iniziare questo corso di programmazione.

L'inglese è ...

... la lingua franca dei programmatori (e di molti scienziati).

Prima lo ammette, e lo segue piuttosto che lottare contro di esso, prima puoi veramente imparare e progredire.

Alcuni inevitabilmente si oppongono a questo, e difendono giustamente il loro diritto a parlare la lingua di loro scelta (la loro lingua materna di solito), tuttavia, come ha dimostrato Babel, più le lingue vengono utilizzate, più la comunicazione diventa difficile.

Still ...

Sì, come è stato sostenuto più volte, alcuni supporti Unicode (principalmente simboli) possono facilitare notevolmente la comprensione per le persone che devono tradurre le formule matematiche o fisiche, ad esempio, in codice. C'è l'inconveniente che alcuni simboli sono sovraccaricati, ma potrebbe ancora aiutare.

Allora perché?

Bene, come detto, non si tratta in realtà della comodità dell'utente, tanto quanto delle dichiarazioni di marketing. È anche facile, dal momento che il parser è già in grado di riconoscere Unicode per stringhe e commenti, quindi la maggior parte prenda il salto.

E potrebbe esserci un vantaggio per alcuni utenti.

Ma personalmente mi occuperò solo del codice scritto con identificatori inglesi. Non mi interessa se hai bisogno del mio aiuto con il tuo codice o se la tua libreria è semplicemente fantastica e potrei guadagnare molto usandola: se non riesco a capirlo, dovrò semplicemente ignorarla.

    
risposta data 01.01.2012 - 15:01
fonte
3

Come digiterete gli 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 è affar tuo in quale lingua.

Se ti senti così confuso nel leggere il codice con identificatori che contengono simboli di altre lingue, allora sono sicuro che capisci esattamente come si sentono confusi loro quando devono usare identificatori con simboli da la tua lingua in.

    
risposta data 13.11.2011 - 18:38
fonte
2

Secondo PEP 3131 - Identificativi non ASCII di supporto datati nel 2007, la prima parte di logica afferma:

Python code is written by many people in the world who are not familiar with the English language, or even well-acquainted with the Latin writing system. Such developers often desire to define classes and functions with names in their native languages, rather than having to come up with an (often incorrect) English translation of the concept they want to name. By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves.

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

    
risposta data 23.12.2018 - 02:12
fonte
1

Sarebbe davvero più facile la vita (per alcuni di noi, comunque) se il compilatore non supporti Unicode. Gli identificatori da destra a sinistra sono orribili. L'alfabeto romano combinato e gli identificatori Unicode da destra a sinistra sono anche peggio.

La cosa brutta del non-supporto è che alcune procedure guidate della GUI prendono il testo che hai inserito per un elemento e lo usano automaticamente come identificativo dell'oggetto. Quindi cosa farebbero esattamente con il testo Unicode su quegli oggetti? 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 richiamare l'identificatore altrove nel codice, il suggerimento visualizza (erroneamente) LTR. Meglio, forse, se non ci fosse il supporto in primo luogo? Ancora una volta, non una chiamata facile.

    
risposta data 01.01.2012 - 09:57
fonte

Leggi altre domande sui tag