Perché il C ++ è ancora "ibrido"

Su una domanda correlata , è stato chiarito perché C ++ non è compatibile con C in molti aspetti. Tuttavia C ++ è ancora un linguaggio "ibrido" *. E sfortunatamente, molti programmatori considerano ancora il C ++ come una "C con flussi e stringhe incorporate". Ciò si traduce in un codice scritto davvero pessimo, che non è né C ++ né C. IMHO, sarebbe meglio se il linguaggio / compilatore costringesse in qualche misura i programmatori a scrivere codice più elegante. Quindi esiste una logica per mantenere l'ibrido C ++ moderno (ad esempio C ++ 0x e versioni future)?

_{* Per ibrido intendo che spetta al programmatore decidere se userà: stringhe e stream standard, classi, spazi dei nomi diversi da quelli predefiniti, ecc.}

Sì, esiste una forte logica: il codice C ++ deve quasi sempre chiamare il codice C esistente. Il meglio che possiamo fare è semplificare la scrittura di un buon codice. Non c'è nulla che un designer linguistico possa fare per rendere impossibile scrivere un codice errato.

IMHO, sarebbe meglio se il linguaggio / compilatore costringesse in qualche modo i programmatori a scrivere codice più elegante.

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

Gli stili di codifica applicati dal linguaggio sono davvero, molto male. Per non parlare di tutto il codice legacy che verrà infranto.

In particolare, le classi String e Stream standard fanno davvero schifo . std::stringnon ha il supporto Unicode e l'interfaccia peggiore che si possa immaginare. I flussi hanno un sovraccarico orrendo e un design scadente, che ricorrono persino all'eredità virtuale e puntatori a funzioni const char*e brutti simili. Non penalizzerei nessuno per aver sostituito completamente entrambe quelle 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.

Il C ++ è un ibrido non perché consente di scrivere codice in stile C, ma perché supporta diversi paradigmi di programmazione, come procedurali, orientati agli oggetti e generici. Il C ++ non ti obbliga a un modo di fare le cose, e questa è la sua forza, perché diversi problemi possono essere risolti più facilmente usando paradigmi diversi.

IMHO, sarebbe meglio se il linguaggio / compilatore costringesse in qualche modo i programmatori a scrivere codice più elegante.

Quindi devi prima definire cosa significa elegante . Quindi dovresti vedere se la tua definizione di elegant è adatta a tutti i domini e piattaforme problematiche per le quali viene utilizzato C ++. Uno stile di programmazione elegante per la scrittura di un elaboratore di testi per Windows potrebbe non essere adatto per la scrittura di un sistema incorporato.

Valuta la possibilità di scrivere codice C ++ da eseguire su un DSP. Innanzitutto, il compilatore C ++ per quel DSP potrebbe semplicemente non supportare alcune funzionalità C ++, come gli stream. In secondo luogo, sei fortemente limitato dalla velocità della CPU e, eventualmente, dalla memoria, quindi alcune funzionalità 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 utilizzeresti su un PC, e C ++ lo consente.

Per riassumere, C ++ è un linguaggio enorme e complicato con molte funzionalità. Esistono molte ragioni per cui un sottoinsieme di tali funzionalità potrebbe non essere applicabile a un determinato progetto: velocità, portabilità, supporto del compilatore o persino esperienza e familiarità del programmatore. Per questa ragione, il linguaggio costringere lo sviluppatore a utilizzare determinate funzionalità rispetto ad altre per ogni dato compito è una cattiva idea. Pensa a Java, dove il linguaggio impone che ogni funzione debba essere un metodo di una classe. Ci sono così tanti casi in cui creare una classe solo per avvolgere un metodo è scomodo e non necessario, eppure devi farlo perché il linguaggio ti obbliga a farlo.

IMHO, sarebbe meglio se il linguaggio / compilatore costringesse in qualche modo i programmatori a scrivere codice più elegante.

Nessuno sta obbligando nessuno a usare C ++ in primo luogo. Se la lingua non ti soddisfa, utilizzane una diversa: ci sono molte lingue fatturate come "C ++ senza C".

La filosofia di progettazione C ++ è di decidere il programmatore. Se vogliono spararsi al piede, allora lasciali. Ciò consente di fare molte cose cattive, ma consente anche una grande flessibilità. Ad esempio, è improbabile che Boost possa essere scritto in una lingua come Java poiché sfrutta le funzionalità e le pratiche linguistiche comunemente evitate. È anche improbabile che il C ++ cresca tanto quanto ha oggi: avere accesso alla vasta libreria C è un vantaggio enorme, prenderlo o lasciarlo.

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

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

Tutto si riduce al pragmatismo contro l'eleganza e per me, nonostante la mia ossessione per un codice preciso e bello, scrivere un brutto programma che funziona è meglio che scrivere un bellissimo programma che non fa nulla.

La rimozione dell'ibrido può migliorare l'eleganza, ma ne ostacola la capacità.

Se il comitato tentasse di costringere le persone a usare (l'idea di qualcuno) un linguaggio più elegante, verrebbe probabilmente ignorato. Le persone continuerebbero a fare ciò che vogliono, ei venditori di compilatori seguiranno il mercato (ma i venditori di compilatori hanno abbastanza rappresentanza nel comitato per impedirlo).

Gran parte di ciò che stai sostenendo è in realtà una questione di giudizio, basata comunque sul dominio del problema. Esistono molti piccoli programmi che non necessitano (ad esempio) di spazi dei nomi. Cercare di costringermi a usare uno spazio dei nomi quando scrivo un filtro di testo a 30 righe sarebbe sciocco e arrogante. Anche se decidessi che sarebbe applicabile solo quando più di X righe di codice, o funzioni Y, o qualunque cosa fosse coinvolta, sarebbe comunque generalmente controproducente. Gli spazi dei nomi sono stati progettati per una ragione, per prevenire / curare problemi specifici. Il tentativo di forzare il loro uso in assenza di tali problemi non compie nulla di utile per nessuno.

Allo stesso tempo, penso che valga la pena notare che un bel po 'di persone spende davvero molto tempo e sforzi nel tentativo non solo di abilitare l'eleganza in C ++, ma anche di insegnare e indurre le persone a usare quelle capacità per scrivere codice migliore (ad es. molti collaboratori Boost). Come 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 starebbero ignorando altrettanto bene i nuovi compilatori quanto 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 stai parlando apparentemente non ne ho ancora sentito parlare, tanto meno letto o compreso anche le sue parti più semplici).

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

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

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

Come sviluppatore di software devi decidere quale approccio è il migliore per l'attività da svolgere.

Penso che il fatto che tutte quelle cose che elenchi siano opzionali crei un potenziale per maggiore eleganza, non meno. Una caratteristica usata inutilmente è inelegante ai miei occhi.

I problemi che dobbiamo risolvere utilizzando la programmazione sono molto diversi.
Alcuni sono risolti bene usando i principi OO (es. GUI), altri si prestano meglio a un trattamento puramente funzionale (es. Roba numerica), mentre altri sono meglio espressi in un linguaggio di basso livello "vicino al silicio".

Un sacco di software deve risolvere i sottoproblemi che sono meglio risolti in uno di questi modi. Forzare la soluzione in una forma specifica porterà solo a un codice che è meno adatto al suo scopo (potresti anche dire "meno elegante").

Questo è il motivo per cui l'ibridità del C ++ è una buona cosa: ci consente di risolvere una vasta gamma di problemi in un modo che si adatta al problema , non al dogma attuale.
Ovviamente può essere usato in modo improprio - ogni volta che hai una cosa flessibile c'è il rischio che tu la pieghi in modo negativo - ma l'eleganza deriva da un pensiero ed esperienza attenti, non dall'adesione a qualunque cosa sia la moda del giorno.