Perché il C ++ è ancora "ibrido"

Sì, c'è una strong motivazione: il codice C ++ deve quasi sempre chiamare il codice C esistente. Il meglio che possiamo fare è rendere facile la scrittura di un buon codice. Non c'è nulla che un designer del linguaggio possa fare per rendere impossibile scrivere codice cattivo.

IMHO, it would be better if the language/compiler forced to some extent programmers to write more elegant code.

No, non lo farebbe. Affatto. Come una banale dimostrazione del perché, definisci elegante, e poi scommetto che dieci persone si presenteranno in disaccordo con te.

Gli stili di codifica applicati dalla lingua sono davvero, davvero pessimi. Per non parlare di tutto il codice legacy che verrà rotto.

In particolare, la stringa standard e le classi di flusso effettivamente suck . std::string non ha supporto Unicode e la peggiore interfaccia che tu possa immaginare. I flussi hanno un overhead orrendo e un design scarso, anche ricorrendo all'ereditarietà virtuale e ai puntatori di funzione, e const char* e brutti simili. Non penalizzo nessuno per sostituire completamente entrambe le classi / gruppi di classi con quelli personalizzati.

Non usare classi e spazi dei nomi va bene per il codice in stile lavagna, e ci sono molte, molte librerie che forniscono funzioni non in una classe. La classe forzata è una pessima idea.

C ++ è un ibrido non perché consente di scrivere codice in stile C, ma perché supporta diversi paradigmi di programmazione, come procedurale, orientato agli oggetti e generico. Il C ++ non ti costringe in un modo di fare le cose, e questa è la sua forza, perché i diversi problemi possono essere risolti più facilmente utilizzando diversi paradigmi.

IMHO, it would be better if the language/compiler forced to some extent programmers to write more elegant code.

Quindi devi prima definire cosa significa elegante . Quindi dovresti vedere se la tua definizione di elegante è appropriata a tutti i domini e piattaforme problematici per i quali viene usato il C ++. Uno stile di codifica che sia elegante per scrivere un word processor per Windows potrebbe essere completamente inadatto per scrivere un sistema embedded.

Considera di scrivere codice C ++ per l'esecuzione su un DSP. Innanzitutto, il compilatore C ++ per quel DSP potrebbe semplicemente non supportare alcune funzionalità di C ++, come gli stream. In secondo luogo, sei strongmente limitato dalla velocità della CPU e probabilmente dalla memoria, quindi alcune funzionalità del C ++ potrebbero semplicemente uccidere le tue prestazioni. Ad esempio potrebbe essere necessario evitare le funzioni virtuali per motivi di velocità. Tali considerazioni cambierebbero radicalmente il tuo stile di programmazione, rispetto a quello che useresti su un PC, e C ++ lo consente.

Per riassumere, C ++ è un linguaggio enorme e complicato con molte funzionalità. Esistono molte ragioni per cui qualsiasi sottoinsieme di queste funzionalità potrebbe non essere applicabile a un particolare progetto: velocità, portabilità, supporto del compilatore o persino esperienza e familiarità del programmatore. Per questo motivo, il linguaggio che impone allo sviluppatore di utilizzare determinate funzionalità rispetto ad altre per qualsiasi attività specifica è una cattiva idea. Pensa a Java, dove la lingua impone che ogni funzione debba essere un metodo di una classe. Ci sono così tanti casi in cui la creazione di una classe solo per avvolgere un metodo è scomoda e inutile, e tuttavia devi farlo perché il linguaggio ti costringe a.

IMHO, it would be better if the language/compiler forced to some extent programmers to write more elegant code.

Nessuno è costringendo qualcuno a usare C ++ in primo luogo. Se la lingua non ti soddisfa, allora usane una diversa - ci sono molte lingue fatturate come "C + + senza C".

La filosofia del design C ++ è di lasciare decidere al programmatore. Se vogliono spararsi nel piede, allora lasciali. Ciò consente di fare molte cose brutte, ma consente anche una grande flessibilità. Ad esempio, è improbabile che Boost possa essere scritto in un linguaggio come Java, poiché sfrutta le caratteristiche linguistiche e le pratiche comunemente evitate. È anche improbabile che il C ++ diventi grande come oggi - avere accesso alla vasta libreria C è un vantaggio enorme, prendilo o lascia.

La compatibilità di C ++ con C è sicuramente uno dei suoi punti più deboli, ma ricorda anche che è uno dei più grandi.

Aggiungerò una meravigliosa citazione di Jon Purdy che ritengo estremamente rilevante:

It all comes down to pragmatism versus elegance, and for me, despite my obsession with precise, beautiful code, writing an ugly program that works is better than writing a beautiful program that does nothing.

Rimuovere l'ibrido può migliorare l'eleganza, ma ne ostacola la capacità.

Se il comitato dovesse tentare di costringere le persone a usare (la nozione di qualcuno) un linguaggio più elegante, sarebbe probabilmente ignorato. Le persone continuerebbero a fare quello che vogliono, e i produttori di compilatori seguirebbero il mercato (ma i produttori di compilatori hanno una rappresentanza sufficiente nel comitato per impedirlo).

Gran parte di ciò che stai sostenendo è davvero una questione di giudizio, basata comunque sul dominio del problema. Ci sono molti piccoli programmi che non hanno bisogno (per un esempio) di namespace. Cercare di costringermi a usare uno spazio dei nomi quando sto scrivendo un filtro di testo a 30 righe sarebbe sciocco e arrogante. Anche se decidessi che si applicherebbe solo quando più di X linee di codice, o funzioni Y, o qualsiasi altra cosa fosse implicata, sarebbe comunque generalmente controproducente. I namespace sono stati progettati per una ragione, per prevenire / curare problemi specifici. Il tentativo di forzare il loro uso in assenza di questi problemi non porta a nulla di utile per nessuno.

Allo stesso tempo, penso che valga la pena notare che molte persone passano molto tempo e sforzi cercando non solo di abilitare l'eleganza in C ++, ma di insegnare e guidare le persone a usare quelle capacità per scrivere codice migliore (ad esempio, molti contributori Boost). In quanto tale, le persone che continuano a insistere per scrivere il loro codice come "C con classi" ignorano praticamente ciò che è là fuori comunque. Penso che sarebbe altrettanto comodo ignorare i nuovi compilatori poiché ignorano tutto ciò che è stato appreso su come usare il C ++ nell'ultimo decennio o più (ad esempio, Modern C ++ Design è stato pubblicato 11 anni fa ora - ma la maggior parte delle persone di cui parli a quanto pare non ne hanno ancora sentito parlare, tanto meno ne hanno letto o capito anche le parti più semplici).

La tua idea costituisce gran parte della logica progettuale alla base di Java. Java ti obbliga a utilizzare le classi, a organizzare la gerarchia dei file in base alla gerarchia dei pacchetti, a rilevare le eccezioni, ecc. Le persone riescono comunque a scrivere codice simile a C al suo interno.

Come programmatori, a volte dimentichiamo che la soluzione migliore potrebbe non essere tecnica. Le recensioni tra pari sono la soluzione più conosciuta in questo caso.

C ++ non ha "un vero modo"; ogni approccio ha punti di forza e di debolezza. La soluzione può essere scritta in centinaia di modi diversi.

Tu come sviluppatore di software devi decidere qual è l'approccio migliore per l'attività in corso.

Penso che tutte le cose che hai elencato siano opzionali crea un potenziale per più eleganza, non meno. Una caratteristica usata inutilmente è inelegante nei miei occhi.

I problemi che dobbiamo risolvere usando la programmazione sono molto diversi.
Alcuni sono risolti pozzetto utilizzando principi OO (es GUI), alcuni si prestano meglio ad un trattamento puramente funzionale (roba esempio numerico), mentre altri sono meglio espresso in un basso livello "vicino al silicio" linguaggio.

Un sacco di software ha bisogno di risolvere i sottoproblemi che sono meglio risolti in uno di questi modi. Forzare la soluzione in un modulo specifico porterà solo a un codice meno adatto al suo scopo (potresti persino dire "meno elegante").

Questo è il motivo per cui l'ibrido-ness di C ++ è un bene cosa - ci permette di risolvere una vasta gamma di problemi in un modo che si adatta alle il problema , non il dogma attuale.
Naturalmente può essere oggetto di abuso - ogni volta che si dispone di una cosa flessibile, c'è il rischio di voi piegarlo in un brutto modo - ma l'eleganza viene da un'attenta riflessione e l'esperienza, non per l'adesione a tutto ciò che è la moda del giorno