Il C fu creato dagli ingegneri dei Bell Labs per soddisfare un'esigenza pratica, ovvero scrivere Unix in modo che fosse portabile su decine di architetture hardware, senza dover impazzire con l'Assembly.
In questo è riuscito alla perfezione. Ma considera che uno dei suoi creatori, Dennis Ritchie, disse: "C is crap"!
Pare (e dico pare) che questa sia una storica "fake news".
Nel senso che a domanda provocatoria diretta: "se il C fosse una schifezza" (o qualcosa del genere), Ritchie non si prese la briga di smentire, ma rispose con la famosa frase: “C is quirky, flawed, and an enormous
success.”, che voleva esternare piu' un certo senso di ammirazione e stima per il prorpio "figlio".
Ovviamente fu una manna per i detrattori del C: in primis il fatto che non avesse smentito l'affermazione insita nella domanda... e poi quella frase: "Il C e' eccentrico, imperfetto e di enorme successo" ... si era facilmente trasformata in: "il C e' strambo, difettoso, e (nonostante questo) ha un enorme successo".
Da li', che Dennis Ritchie avesse affermato che il C era una schifezza, il passo fu breve.
E' giusto una curiosita che riporto come tale (un ricordo dell'epoca, fine anni 80... e gia' all'epoca si dibatteva su cio'), perche' ovviamente non e' dato sapere quale sia la realta'... e fa parte ormai della leggenda.
No, il problema è la vaghezza del modello di programmazione del C. Per esempio, il fatto che il concetto di array ( e vale lo stesso per le stringhe ) sia vago, ovvero che abbia una sua sintassi nel linguaggio, ma che possa essere manipolato pure tramite aritmetica dei puntatori, conduce ai tipici buffer overflow.
Fare
C:
int a[4] = {1, 2, 3, 4};
int *ptr = a + 4;
printf("%d\n", *ptr);
in qualsiasi linguaggio con un modello di programmazione ben definito, non sarebbe ammesso. Invece in C puoi andare a pescare un valore che va oltre il limite dell'array e leggere ovviamente quello che c'è in quella locazione di memoria. Ovviamente nessuno può prevedere cosa ci sarà in quella locazione. Da cui il concetto di undefined behavior.
Mi verrebbe da risponderti con un'altra citazione di Ritchie:
"Se fai il cast di un puntatore a un intero lui diventa un intero...
Se fai il cast di un puntatore a una struttura lui diventa una struttura...
... fai del puntatore un tuo amico"
E anche con una citazione da fumetto Marvell:
"Da un grande potere derivano grandi responsabilita'"
Ricordiamoci che il C nacque in un periodo in cui ogni singola istruzione era preziosa (i cicli di clock erano meno di 1000/s e una singola istruzione spesso comprendeva piu' cicli), epoca in cui si preferiva (era quasi obbligatorio) usare lo "<<1", o sommare due volte un float (i coporcessori matematici si acquistavano... a parte), piuttosto che moltiplicare per DUE... (una delle poche ottimizzazioni ottenibile dai compilatori era esplicitamente dichiarare una variabile con lo specificatore "register" nel codice)
In quest'epoca il C permetteva di incrementare direttamente l'indirizzo per scorrere un'area di memoria (stringhe, array, matrici..)... invece che
- incrementare un indice
- sommare l'indice all'indirizzo di memoria
per poi accedere a quell'indirizzo.
In quest'ottica, inserire un controllo sull'incremento di un indice, sarebbe costato ulteriormente sulle performance... oltre che rielaborare il concetto dei puntatori.
Si e' semplicemente scelto di offrire "potenza" a discapito della "sicurezza", lasciando la responsabilita' di questa potenza, nelle mani di chi la utilizzasse (da qui la citazione Marvell).
Non so se c'erano linguaggi migliori (bisognerebbe stabilire "migliore", in che ambito), c'erano sicuramente linguaggi piu' sicuri... ma molti preferirono che il loro programma fosse piu' veloce , e in ques'ottica scelsero il C.
Il C++ ha portato, parzialmente, un rimedio a certe mancanze... anche se in modo indiretto e solo in un secondo momento, attraverso la Standard Template Library: l'uso di contenitori "standard" permette la verifica del buffer overflow, anche se solo in modalita' DEBUG.
(ovviamente nulla, rispetto a linguaggi con un solido Garbage Collection e gestione delle eccezioni)
Certo, oggi il C, come il C++ (di cui si porta dietro l'eredita'), rimane "strambo" e "imperfetto"... e dato che la potenza di calcolo e' abbondante ed i compilatori ottimizzano il codice anche meglio di come lo si possa scrivere... ha un po' meno successo di allora, ma e' ancora molto seguito, nonostante abbia piu' di 40 anni.
Se non erro il C è stato per molto tempo l'alternativa facile all'Assembly. Poi è stato inventato il c++ e tutti sono impazziti per le classi. Io, e ripeto che non sono un programmatore e conosco solo python, odio le classi e se potessi eviterei tutti i linguaggi di programmazione che ne fanno uso, da c++ a java a python, praticamente tutti oggigiorno.
Personalmente, la "liberta'" che offre il C/C++ non riesco (non son riuscito) a sostituirla con altri linguaggi... e pensare che considero il C++ troppo puntiglioso (a volte) per alcuni versi.
Ricordo che resistetti alcuni anni, con tutto me stesso, non volendo ammettere che quella del C++ fosse un'evoluzione "indispensabile".
Alla fine cedetti.
I vantaggi sono innegabilmente maggiori degli svantaggi, per es. nella creazione di nuovi tipi di dati:
- Immagina che in OpenGL volessi creare un nuovo tipo di dato Vettore3D,con 3 componenti (x,y,z), ma non sai se utilizzerai interi, singola o doppia precisione [er questi componenti... o forse tutti e tre i tipi, all'intero del tuo programma: puoi creare una classe, che in base alla dichiarazione del momento diventi specifica. (classe modello)
- Ed ancora, poter usare gli stessi operatori (+,-,*,/) sul nuovo dato Vettore3D, senza doverti occupare dei singoli componenti interni: x,y,z. (overload operatori)
- O gestire il vettore solo in un quadrante dello spazio cartesiano... non riscrivendo tutto... ma creando un nuovo tipo di dato Vettore3D_quadrante, "figlio" di Vettore3D (ereditarieta'), che limita la funzionalita' della classe "genitore" solo a quel quadrante... continuando ad aver disponibili ebtrambi gli oggetti per due usi diversi.
(E' solo un ipotetico esempio... fatto su due piedi)
Certo, tutto cio' si fa anche in C,
attraverso altri metodi, ma la classe (l'oggetto) e' un'astrazione piu' vicina al nostro modo di gestire le informazioni, quindi diventa piu' gestibile e meglio leggibile (se scritta bene)... ergo meno soggetta ad errori... ed anche flessibile (facilmente riutilizzabile senza dover riscrivere pezzi di codice).
Inutile dire che ci son linguaggi che gestiscono gli oggetti con potenzialita' diverse rispetto al C++.
Migliori?
Molto probabilmente...
