Hai mai letto le specifiche della lingua? [chiuso]

Come una delle parti colpevoli, aggiungerò il mio valore di 2 ¢. No, non penso sia necessario. Sfortunatamente, in C ++ è più vicino necessario a quasi chiunque desideri - cioè, come dice Bjarne, C ++ è "esperto amichevole". Devi essere a conoscenza di molti più dettagli di quelli che vorrebbero poter usare bene. Sebbene sia probabilmente vero per un certo grado alcuni in quasi tutti i casi, questo è molto meno vero in molti (più?) Altri linguaggi.

L'altro lato è che molte volte le persone si chiedono dettagli relativamente sottili della lingua che, francamente, danneggino poche persone che sanno davvero di testa, quindi quelli di noi che forniscono risposte su di loro spesso devono cercare i dettagli per essere sicuri che abbiamo ragione. Trovo anche che la citazione dallo standard abbia la tendenza a prevenire un sacco di argomenti - anche quando conosco una risposta, verrà spesso messa in discussione (almeno in una certa misura) se dico solo: "ecco come è ". Se si cita lo standard, molte meno persone discutono, quindi può risparmiare tempo e fatica a lungo termine.

In definitiva, penso che conoscere bene lo standard (o gli angoli oscuri della lingua) sia meno importante per programmare di per sé piuttosto che mentorare gli altri sulla lingua - anche nei casi in cui si dice semplicemente "non andare lì! " Riguardo l'unica programmazione alla quale è importante scrivere codice che funzioni effettivamente con la lingua (tokenizing, parsing, analysis, ecc.)

Direi che conoscere a fondo le specifiche non è un requisito per sapere come programmare in C ++ o anche per diventare un eccellente programmatore C ++.

Direi comunque che essere in grado di trovare informazioni dalle specifiche è importante, se c'è una parte della lingua che stai utilizzando non è molto ben documentata.

È anche importante sapere dove il tuo compilatore non soddisfa le specifiche se vuoi che il tuo codice sia protetto tra i compilatori.

No, non è essenziale essere un buon sviluppatore in una determinata lingua. Tuttavia aiuta molto quando risponde a una domanda in modo definitivo. Quindi gli utenti di StackOverFlow lo usano molto.

Il Common Lisp Hyperspec è un po 'di documentazione davvero utile. Mi riferisco ad un lotto .

Ho letto la specifica Haskell, che è utile non solo per la definizione della lingua ma anche perché contiene il codice sorgente per il Preludio Haskell. Leggere il codice del Preludio mi ha dato una buona conoscenza dei comuni idiomi di Haskell.

A volte leggo gli standard linguistici, ma non tutti lo sanno. Certamente è possibile essere uno sviluppatore eccellente senza mai toccarne uno.

Ciò di cui hai bisogno è la conoscenza delle parti del linguaggio che utilizzerai e un posto dove andare per scoprire quali sono le cose che non capisci nei programmi di altre persone. Non devi sapere esattamente cosa costituisce un comportamento indefinito se ti assicuri di non avvicinarti mai.

Per fare un esempio, in C ++ potresti evitare di iniziare qualsiasi nome identificativo che scrivi con un carattere di sottolineatura. Ci sono delle regole su quali nomi che iniziano con underscore sono riservati per l'implementazione con quali collegamenti potresti imparare, oppure potresti semplicemente smettere di scrivere i tuoi identificatori con i trattini bassi.

Ho letto una versione annotata dello Spec C # (per la versione 3 penso). Non posso dire di aver imparato qualcosa di completamente nuovo (sono sicuro di aver imparato un po ', ma nulla spicca nella mia mente) ma ho avuto una comprensione più profonda del perché le cose sono come sono. Ho trovato le annotazioni davvero preziose dove hanno esplorato i compromessi che erano stati fatti nell'uno o nell'altro. Per quanto mi riguarda, questa conoscenza di base rende le cose molto più impresse nella mia mente e penso di essere uno sviluppatore molto migliore di conseguenza.

Non penso che non leggere le specifiche del linguaggio in sé impedisce a nessuno di essere un buon programmatore, ma leggerle certamente non farebbe male. Leggere le specifiche direttamente è noioso come diamine, e non incolpo nessuno per non farlo, ma leggere le specifiche in pezzi quando si lavora su elementi correlati non è poi così male e trovo che mantengo più nel tempo farlo in quel modo comunque.

Ho imparato C # dalle specifiche del linguaggio, che credo sia stato diffuso almeno un paio di anni prima che Visual Studio.NET venisse rilasciato. Ma era più una questione di prendere atto di ciò che era diverso da Java - non so se sarebbe un ottimo modo per imparare una lingua che era molto diversa da quello che già sapevo.

Non leggo mai le specifiche perché per lo più uso lingue più recenti che non hanno ancora una specifica legale e formale. Le mie lingue principali sono Python e D e AFAIK, nessuno dei due ha una specifica formale, ad esempio quella il cui pubblico previsto sono gli avvocati / implementatori linguistici, non gli utenti medi.

Una volta. Ho letto le specifiche Java. L'unica ragione per cui l'ho letto è stato il fatto di competere a livello nazionale in Java Programming for FBLA (Future Business Leaders of America) e ho pensato che mi avrebbe dato un vantaggio.

È stato utile, ma il ROI (ritorno sull'investimento) era troppo basso per poterlo fare ancora.

Una volta ho avuto l'insonnia per alcuni giorni, quindi ho letto l'ECMA pubblicata con le specifiche C ++ / CLI. Che bella lettura.

Conoscere le specifiche C ++ (essere in grado di cercare le cose o citarla su StackOverflow) è relativamente importante per C ++ perché il linguaggio ha un sacco di comportamenti non definiti che gli implementatori del compilatore possono fare qualsiasi cosa sia conveniente con quelle aree non definite. Solo perché il tuo compilatore accetta il codice e solo perché viene eseguito correttamente non significa che sia portatile. Potresti affidarti alle funzionalità della tua architettura, alle caratteristiche dell'ABI / API del tuo sistema operativo o alle caratteristiche del tuo compilatore (o di una particolare versione del tuo compilatore). Quindi, per sapere cos'è C ++ portatile e su quali garanzie puoi fare affidamento, devi fare riferimento alle specifiche. Il tuo compilatore non lo saprà.

La maggior parte delle altre lingue lascia molto meno il comportamento del programma esplicitamente indefinito, quindi fai riferimento alle specifiche nella misura in cui ritieni utile come riferimento API.

Ero solito essere un "avvocato linguistico" non ufficiale per C in cui lavoravo. Ho avuto la specifica ufficiale ANSI X3J11, e ho avuto modo di rispondere a tutti gli strani "dovrebbe farlo?" - tipo domande. Sicuramente non ne hai bisogno per fare il 95% + della maggior parte dei negozi di codice, ma può essere utile in quei casi in cui ti imbatti in alcuni casi d'angolo strani che il manuale del compilatore non tenta nemmeno di spiegare.

Dipende da quanto è grande la specifica. La specifica C # è grande e ha un linguaggio molto complicato, quindi non l'ho mai letto.

Ho imparato C # attraverso i soliti metodi di Experimenting e Googling e solo dopo aver ottenuto una buona comprensione ho letto piccole parti nelle specifiche, principalmente sugli operatori di Bitwise perché ne avevo bisogno.

Ad un certo punto ho deciso che volevo scrivere un compilatore per .net, quindi ho letto grandi parti delle specifiche CIL / CLR (e ho dimenticato di nuovo la maggior parte di esso).

D'altra parte, ho letto le specifiche Lua prima di usarlo, principalmente perché era economico ($ 17 come libro stampato) e molto piccolo, con solo ~ 100 pagine che sono scritte anche in inglese "più semplice".

Ma poi di nuovo, Lua è molto più semplice di C #.