La notazione ungherese è una soluzione alternativa per le lingue con tipizzazione statica insufficientemente espressiva? [chiuso]

Direi "Sì".

Come dici tu, lo scopo della notazione ungherese è codificare le informazioni nel nome che non possono essere codificate nel tipo. Tuttavia, ci sono fondamentalmente due casi:

1. Questa informazione è importante.
2. Questa informazione non è importante.

Iniziamo dal caso 2: se questa informazione non è importante, allora la notazione ungherese è semplicemente un rumore superfluo.

Il caso più interessante è il numero 1, ma direi che se l'informazione è importante, dovrebbe essere controllata, cioè dovrebbe essere parte del tipo , non il nome .

Il che ci riporta alla citazione di Eric Lippert:

extend the concept of "type" to encompass semantic information in addition to storage representation information.

In realtà, non è "estendere il concetto di tipo", che è il concetto di tipo! Lo scopo completo dei tipi (come strumento di progettazione) è quello di codificare le informazioni semantiche! La rappresentazione dello storage è un dettaglio di implementazione che di solito non appartiene al tipo affatto . (E in particolare in un linguaggio OO non può appartenere al tipo, poiché l'indipendenza dalla rappresentazione è uno dei prerequisiti principali per OO.)

L'intero scopo dei tipi (come strumento di progettazione) è quello di codificare le informazioni semantiche!

Mi è piaciuta questa risposta e volevo dare seguito a questa risposta ...

Non so nulla di Haskell, ma puoi realizzare qualcosa come l'esempio di xFoo + yBar in qualsiasi linguaggio che supporti qualche forma di sicurezza di tipo come C, C ++ o Java. In C ++ è possibile definire classi XDir e YDir con operatori "+" sovraccarichi che accettano solo oggetti del proprio tipo. In C o Java, è necessario eseguire l'aggiunta utilizzando una funzione / metodo add () anziché l'operatore '+'.

Ho sempre visto la notazione ungherese usata per le informazioni sul tipo, non la semantica (eccetto che la semantica potrebbe essere rappresentata dal tipo). Un modo conveniente per ricordare il tipo di una variabile nei giorni precedenti agli editor di programmazione "intelligenti" che visualizzano il tipo per te in un modo o nell'altro direttamente nell'editor.

Mi rendo conto che la frase "Notazione ungherese" ha finito per significare qualcosa di diverso che l'originale , ma lo farò rispondi "no" alla domanda. Assegnare nomi a variabili con tipo semantico o computazionale non fa la stessa cosa della digitazione SML o Haskell. Non è nemmeno un bandaid. Prendendo C come esempio, potresti nominare una variabile gpszTitle, ma quella variabile potrebbe non avere scope globale, potrebbe anche non costituire un punto per una stringa con terminazione null.

Penso che le notazioni ungheresi più moderne abbiano divergenze ancora maggiori da un sistema di detrazione di tipo strong, perché mescolano informazioni "semantiche" (come "g" per globali o "f" per flag) con il tipo di calcolo ("p" pointer, "i" intero, ecc. ecc.) che finisce come un disastro in cui i nomi delle variabili hanno solo una vaga somiglianza con il loro tipo di calcolo (che cambia nel tempo) e sembrano tutti così simili che non è possibile usare "next corrisponde "per trovare una variabile in una funzione specifica - sono tutti uguali.

La notazione ungherese è stata inventata per BCPL, un linguaggio che non aveva affatto alcun tipo. O meglio, aveva esattamente un tipo di dati, la parola. Una parola potrebbe essere un puntatore o potrebbe essere un carattere o booleano o un numero intero semplice a seconda di come lo hai usato. Ovviamente questo ha reso molto facile fare errori orribili come il dereferenziamento di un personaggio. Quindi è stata inventata la notazione ungherese in modo che il programmatore potesse eseguire almeno il controllo manuale del tipo osservando il codice.

C, un discendente di BCPL, ha tipi distinti per interi, puntatori, caratteri ecc. Ciò ha reso la notazione base ungherese superflua in una certa misura (non era necessario codificare nel nome della variabile se fosse un int o un puntatore), ma la semantica oltre questo livello non può ancora essere espressa come tipi. Ciò ha portato alla distinzione tra ciò che è stato chiamato "Sistemi" e "Apps" ungherese. Non hai bisogno di esprimere che una variabile era un int, ma potresti usare le lettere di codice per indicare se l'int era un dire una coordinata xoy o un indice.

Più lingue moderne consentono definizioni di tipi personalizzati, il che significa che puoi codificare i vincoli semantici nei tipi, piuttosto che nei nomi delle variabili. Ad esempio, un tipico linguaggio OO avrà tipi specifici per coppie di coordinate e aree, quindi eviti di aggiungere una coordinata x a una coordinata y.

Ad esempio, in Joels famoso articolo che elogia le app ungheresi, usa l'esempio del prefisso us per una stringa non sicura e s per una stringa sicura (codificata in html), al fine di impedire l'inserimento di HTML. Lo sviluppatore può prevenire gli errori di iniezione di HTML semplicemente ispezionando attentamente il codice e ensyre che i prefissi delle variabili combaciano. Il suo esempio è in VBScript, un linguaggio ormai obsoleto che inizialmente non permetteva classi personalizzate. In un linguaggio moderno il problema può essere risolto con un tipo personalizzato, e infatti questo è ciò che Asp.net fa con la classe HtmlString . In questo modo il compilatore troverà automaticamente l'errore, che è molto più sicuro affidandosi all'occhio umano. Quindi chiaramente una lingua con tipi personalizzati elimina la necessità di "App ungheresi" in questo caso.

Sì, anche se molte lingue che hanno sistemi di tipi abbastanza potenti hanno ancora un problema: l'espressività di nuovi tipi basati su / simili ai tipi esistenti.

vale a dire. In molti linguaggi in cui potremmo usare il sistema di tipi in più non lo facciamo perché il sovraccarico di creare un nuovo tipo che è fondamentalmente lo stesso di un tipo esistente diverso dal nome e un paio di funzioni di conversione è troppo grande.

Essenzialmente abbiamo bisogno di una sorta di typedef strongmente tipizzati per eliminare completamente la notazione ungherese in questi linguaggi (anche l'UoM in stile F # potrebbe farlo)

Ricorda, c'è stato un tempo in cui gli IDE non avevano i suggerimenti popup che ti dicevano che tipo di variabile è. C'è stato un tempo in cui gli IDE non capivano il codice che stavano modificando in modo da non poter passare facilmente dall'uso alla dichiarazione. C'è stato anche un tempo in cui non è stato possibile effettuare il refactoring di un nome di variabile senza passare manualmente attraverso l'intero codice, apportando il cambiamento a mano e sperando di non averne perso uno. Non puoi usare search & sostituisci perché la ricerca di Cliente ti dà anche CustomerName ...

In quei giorni bui, era utile sapere che tipo era una variabile dove veniva usata. Se correttamente mantenuto (un GRANDE se a causa della mancanza di strumenti di refactoring) notazione ungherese che ti ha dato.

Il costo in questi giorni dei nomi orribili che produce è troppo alto, ma questa è una cosa relativamente recente. Esiste ancora un sacco di codice che precede gli sviluppi IDE che ho descritto.

Una corretta!

Al di fuori delle lingue totalmente non tipizzate come Assembler, la notazione ungherese è superflua e fastidiosa. Doppiamente così quando consideri che la maggior parte degli IDE controllano il tipo di sicurezza come tu, er, digita.

L'extra "i" "d" e "?" i prefissi rendono il codice meno leggibile e, può essere davvero fuorviante - come quando un "cow-orker" cambia il tipo di iaSumsItems da Integer a Long ma non si preoccupa di refactoring il nome del campo.