PS4: attenzione, un messaggio può bloccare la console

Sì sì. E' proprio questo il bello.

Infatti un altro dei problemi è non usare il linguaggio giusto per la giusta occasione.

Ad esempio, JavaScript andava bene per quello per cui era stato pensato. È invece una porcata anche solo immaginare di realizzare applicazioni desktop dovendoti portare dietro un browser. Ma ripeto, questo è dovuto al voler far credere che chiunque possa realizzare buon software.

Comunque, anche pensare di scrivere una GUI in C è un'idea bizzarra. lo dico da utilizzatore assiduo di tale linguaggio.

IMO Javascript non andava bene nemmeno per quello per cui era pensato, ma qui sono chiaramente "biased".

L'hanno già fatto: dai un'occhiata a GNOME e, specificamente, a glib.

E' quel che dicevo prima, infatti: si usa lo strumento che si presta "meglio" per un determinato compito.

Nessuna polemica anche da parte mia. Non era questo lo scopo del mio commento: è solo che non ce l'ho fatta proprio a lasciar passare quel che era stato scritto.

C si porta già dietro un bel po' di librerie standard: il suo problema è che ha avuto una lenta evoluzione, perché per qualcosa di più complesso c'era C++.

Sia chiaro: il minimalismo di C, a livello di linguaggio, mi sta abbastanza bene, per gli ambiti in cui è ancora usato.

Qui, però, parli già di ANSI C, e non più C K&R. Io mi riferivo a quest'ultimo, che non aveva/ha né const come keyword, né tanto meno enum, che si usano in genere per definire delle costanti, in modo più o meno comodo.

Senza const ed enum eri costretto ad andare a colpi di #define (che peraltro sono ampiamente usate proprio in quella sezione del libro. Chiaro retaggio delle origini del linguaggio, IMO), con tutte le problematiche del caso.

A chi lo dici. Quando ero alla Intel avrei dovuto scrivere dei test in TCL, per le estensioni al GDB che sviluppavamo. Roba da non dormirci la notte (anche perché i test di GDB sono script TCL che hanno MONTAGNE di regex ). Ho preferito scrivermi un mini-framework in Python allo scopo, e usarlo per una nuova test suite: ho impiegato di gran lunga meno tempo, e quel codice è molto più facilmente leggibile e manutenibile.

Questo lo lasciamo come esercizio a chi vuole cimentarsi con una versione C o C++.

In realtà il C di K&R, soprattutto inizialmente, era disastroso. Anche le funzioni, per dire, non erano esattamente come adesso.

Comunque tutt'oggi le direttive #define sono ovunque.

E' sempre la solita storia: è colpa del linguaggio. Però i bug, anche rognosi, chissà come mai saltano fuori anche da gente che il linguaggio lo conosce benissimo.

Non mi pare di aver detto qualcosa in contrario.

Non hai risposto alla mia domanda.

Perché il C si è diffuso ed è diventato lo standard di fatto in quegli ambiti, ma s.o. e software di basso livello venivano già ampiamente scritti con altri linguaggi.

Come già detto, C è nato per scrivere velocemente codice, senza tanti fronzoli, per velocizzare la scrittura di Unix (e da lì in poi anche per altri s.o. o roba di basso livello). Questo non perché lo dico io, ma gli stessi autori del linguaggio.

Quello che t'ho riportato è un aneddoto raccontato dai creatori del linguaggio. Almeno loro dovrebbero saperlo, no?

Si vede che non hai usato altri linguaggi. Intanto, come dicevo prima, non aveva nemmeno la definizione delle costanti, poi:
- tipizzazione debole;
- assenza di riferimenti;
- assenza del concetto di modulo (devi ricorrere anche qui al famigerato preprocessore usando #include, e all'interno di questi sfilze di #ifdef o #if per evitare ridefinizioni et similia);
- assenza di un vero tipo stringa;
- assenza di costrutti di più alto livello (non solo stringhe, dunque).

Questi sono quelli che personalmente reputo grossi difetti, ma potrebbero essercene altri.

Scusami, ma che c'entra Tanenbaum adesso? Mica l'ha inventato (anche) lui il C...

Ma che stai a dire? Scusa, ma quanti altri linguaggi conosci, oltre a C e C++?

E' del '72.

Che ormai da tempo preferiscono Python.

Che da tempo si sta spostando verso il C++.

Fortran è ancora molto usato per questo.

Senz'altro, e come già detto lo apprezzo pure, eh! Mica sono un hater del C: quando mi serve lo uso...

Purtroppo direi proprio di no, e scusami se questa mia opinione cozzi con la tua, ma ho anch'io le mie brave ragioni per affermarlo.

E' un grande, ma non credo che si possa considerare il più grande. Personalmente nutro una stima maggiore per Turing, Knuth, Wirth.

Certo che è una parte delle specifiche del C: senza quello vorrei ben vedere quanto sarebbe stato utile e utilizzato il C.

Anche gli assembler fanno pesante uso del preprocessore, e per il solito motivo: compensare le lacune che hanno a livello di linguaggio...

Che funzionino bene per il C, non faccio fatica a crederlo. Ma altri linguaggi mettono a disposizioni strumenti ben più comodi (e qui rientriamo nel discorso di prima: per risolvere certi problemi è meglio scegliere lo strumento "migliore".

Le difficoltà col C le hanno anche quelli che lo conoscono bene, come dicevo prima.

Vedi sopra: non cambia di una virgola il discorso. Anche programmatori molto esperti scrivono codice con bug rognosi. Capita. Specialmente con linguaggi che danno la libertà/possibilità di farlo.

Intanto Tanenbaum non c'entra niente.

Su Richie ho già detto che è stato un grande.

Ciò, però, non implica che per questo abbia fatto un gran lavoro col C. Logica spicciola alla mano...

Premesso che, come dicevo, per determinati problemi si scegli lo strumento migliore, a livello puramente implementativo Python è di gran lunga più flessibile e produttivo di C e C++.

E' molto probabile che i tuoi sorgenti in C++ li scriverei molto più velocemente in Python. Partendo dalle specifiche: i sorgenti in C++ non li voglio nemmeno vedere, perché mi farebbero soltanto perdere tempo.

Anche per altri linguaggi. E generalmente gli altri linguaggi consentono di usare librerie scritte in C (o altri linguaggi: l'importante è esporre un'interfaccia standard)

Se togliessero ci sarebbero sicuramente altri linguaggi a occupare lo stesso ruolo. Come c'erano anche prima del C, che come dicevo non ha portato alcun contributo alla letteratura informatica.

P.S. Scusa, ma non ho tempo di rileggere. Tanto dovrebbe capirsi lo stesso.

Esattamente. Passare dal K&R all'ANSI C è stato già un bel passo avanti, anche se è rimasta la brutta abitudine di continuare a definire le constanti con le #define nonostante la keyword const.

Ma infatti io tifo proprio per quello: che webassembly si diffonda più velocemente possibile, soprattutto come adozione standard da parte dei browser più diffusi.

Così finalmente si potrà usare il linguaggio che si vuole anche per il weeeebbbe.

Francamente preferisco usare il preprocessore il meno possibile (in genere per la definizione di simboli e relative #ifdef / #if. Molto più raramente per delle macro), se il linguaggio offre già dei costrutti sintattici.

Poi, sia chiaro, è una questione di gusti.

Sì, i bug rognosi ci sono anche in altri linguaggi, ma quelli prodotti da C/C++ lo sono di più. Ci sarà un motivo per cui sono stati inventati Java, C#, Go, e per ultimo Rust, no? E cito questi perché a livello sintattico sono abbastanza ispirati a C/C++.

Guarda che il C è decisamente poco portabile come linguaggio: più utilizzi costrutti di basso livello, e meno portabile diventa.

Quanto alla flessibilità, non è chiaro tu cosa intenda.

Comunque se recupero l'intervista ai suoi creatori che parlano di come sia nato il linguaggio la posto, anche se mi pare difficile (potrei averla letta una trentina d'anni fa, fra le riviste d'informatica dell'epoca).

Ma anche no: ce n'era diversi scritti in linguaggi di alto livello. Persino su Amiga è stato usato il BCPL, predecessore del C, per scrivere l'AmigaDOS.

Intanto sulla portabilità vedi sopra. Poi proprio se vuoi sfruttare meglio la macchina ti tocca scrivere codice non portabile in C (o portabile, ma a colpi di #ifdef et similia).

La velocità di scrittura è proprio "buttare giù" il codice nel minor tempo possibile.

Poi che questo sia produttivo è, invece, tutt'altro che scontato. Difatti le due cose non sono strettamente collegate.

E questo lo si faceva già con altri linguaggi di alto livello.

Cobol ammetto di non averlo usato (anche se gli ho dato un'occhiata 35 anni fa circa). Per il resto ho usato o studiato diversi linguaggi, spaziando da quello macchina al Prolog.

Su questo ho già ampiamente risposto. E mi sa che, a questo punto, tu debba essere abbastanza giovincello da non aver mai usato il C K&R, perché altrimenti non avresti scritto questa cosa. Pretendi di conoscere il C, ma non ne conosci nemmeno le origini, che poi era esattamente ciò a cui mi sono sempre riferito finora, inclusa la mia domanda a cui continui a non voler dare una precisa risposta.

Lo è, perché è fonte di bug. Se hai una tipizzazione forte già a priori certe porcate non le puoi fare.

Il C NON ha un tipo stringa. Quello che offre è soltanto dello zucchero sintattico per inizializzare o passare come parametro un vettore di caratteri. Nient'altro.

Quanto alla velocità di cui parli, è del tutto falso, visto che per conoscere la lunghezza di una stringa (operazione abbastanza comune) devi per forza scorrertela tutta fino alla fine.

E meno male che hai detto di conoscere diversi linguaggi. No, il concetto di modulo è ben diverso, e c'è persino un linguaggio che ce l'ha per nome, proprio per rimarcarlo.

Quella #ifdef la piazzi TU, programmatore, su UN sorgente C che verrà compilato come oggetto.

Il che non ha NULLA a che vedere col concetto di modulo di cui parlavo.

Forse perché oltre a C non conosci altri linguaggi. Eccone uno che è stato pubblicato 2 anni PRIMA e che era ben fornito di costrutti di alto livello:
https://en.wikipedia.org/wiki/Pasca...uage_constructs

Beh, parlane pure: qual è il problema?

Tranquillo: ho messo le mani in pasta ovunque.

Semplicemente se devo dimostrare la produttività di Python, preferisco partire dalle condizioni iniziali: avere le specifiche del progetto, e lavorarci direttamente. Che dovrebbe essere quello che hai fatto tu coi tuoi progetti C/C++, giusto? O li hai convertiti da linguaggi come Python?

Stroustrup l'ho conosciuto personalmente a un seminario che tenne alla New York University nel '95 (se non ricordo male), quando all'epoca girava per presentare la neonata stdlib del C++.

Alla fine del seminario ci fu un sorteggio con alcuni premi. Vinsi un biglietto per la successiva conferenza sul C++, ma siccome di natura sono molto fortunato dovetti rinunciare perché sarei stato già in Italia. Avrei preferito di gran lunga vincere il suo libro autografato.

Scusami, ma in cosa avrebbe preso spunto Python dal C? Dalla presenza dell'operatore != per disuguaglianza (fino alla versione 2.7 del linguaggio c'era anche <>, che da pascaliano preferivo nettamente)?

Quanto ai primi 3 che hai citato, chiediti perché si sia sentito il bisogno di crearli anziché continuare a usare C (magari evolvendolo) o il C++.

Conta quando ha rilasciato il linguaggio pubblicamente, e altri programmatori hanno cominciato a poterlo usare.

Anch'io ho scritto dei linguaggi di programmazione (HLA, per essere precisi) più di 20 anni fa, ma non li ho mai pubblicati e ovviamente a parte me nessuno li ha mai potuti usare. Se li pubblicassi adesso, citando il '96 come anno di inizio mi renderei soltanto ridicolo.

E niente, continui a parlare di cose che non conosci. Fatti una ricerchina su qualche hackcon, guardati un po' di talk, e vedi cosa utilizzano gli hacker moderni come strumenti per il loro lavoro.

Oppure fai prima a dare un'occhiata a questo:
https://www.amazon.it/Black-Hat-Pyt...s/dp/1593275900

E a metterti l'anima in pace.

http://www.treccani.it/vocabolario/molto/

Per il resto Fortran rimane il linguaggio più usato in ambito HPC, con grossi nomi che continuano a usarlo. E i compilatori Fortran sono rinomati per offrire le prestazioni più elevate in quest'ambito.

Guarda hai sbagliato TU quando hai preteso di far passare gli altri programmatori come degli inetti.

Considerate le lacune che hai dimostrato finora, sei l'ultimo che se lo possa permettere.

Un paio di post che capitano a fagiolo:
https://amigaworld.net/modules/newb...forum=17#817713
https://amigaworld.net/modules/newb...forum=17#817715

Non era mia intenzione comunque dire che K&R erano degli inetti il C negli anni '70 era una gran cosa, insomma sempre meglio che scrivere Unix tutto in ASM sul PDP-11!
Ma appunto aveva senso negli anni '70 con un processore che a quanto andava? 1 MHz?

Riguardo poi le "leased string" (stringhe con lunghezza incorporata) non sono nulla di più che questo:

[CODE]
typedef struct {
size_t size;
const char *value;
} leased_str_t;
[/CODE]

certo ogni volta che fai una copia devi verificare la size della stringa di destinazione e se fai str[x] dovresti di nuovo verificare che x sia <= size, ma almeno per il primo caso ogni libreria C come si deve lo dove fare... mica puoi davvero usare sprintf() giusto? Si deve SEMPRE usare snprintf()... quindi fai sempre una strlen() che è una ricerca dentro tutta la stringa del byte col valore 0x00 che è sicuramente più lenta che accedere al campo size[1].

Aggiungo un altra cosa riguardante C#, il CLR impone che ogni accesso agli array sia buond checked è vero, ma il compilatore è libero di cambiare il codice durante l'ottimizzazione quando può dimostrare oltre ogni dubbio che è safe farlo per esempio questo for:

[CODE]
for (int i = 0; i < arr.Len; i++) {
arr[i] = 0;
}
[/CODE]

non avrà buond check nell'ASM generato alla fine.

Poi certo per fare decoding / encoding il C ha magari più senso che C#, ma qui stiamo parlando di una applicazione di messaggistica quel 10% in più causata dall'uso di un linguaggio managed sarebbe stato così disastroso?

O siete ancora convinti che scriverlo in C# vorrebbe dire che andrebbe a scatti mentre scrivi?

[1] falsa sensazione di sicurezza tra l'altro visto che il C ha la tendenza a sbordare sui tappi delle povere "stringhe" e quindi la strlen() si può tranquillamente spazzolare 1024 byte prima di trovare sto povero "tappo"

Ecco qui:
[I][INDENT]Potro' sbagliare, ma il "difetto" di c, e c++, e' che non perdonano lo sviluppatore. se uno e' incompetente, ti massacrano.
se programmi alla cazzo di cane, o alla "stackoverflow-dipendente", ti distruggono. diventano delle bombe a tempo, che prima o poi esploderanno lasciandoti nella merda piu' nera. se non li studi, lasciali perdere, non li impari con wikipedia.[/INDENT][/I]
Come già detto, tali linguaggi ti massacrano (usando un tuo termine) anche se li conosci bene.

Se sei così bravo e sai fare di meglio puoi sempre farti assumere da qualche multinazionale come quelle che ho citato (anche nella mia azienda ci sono posizioni aperte che cercano esperti programmatori C++), ma con la clausola che se fai un cazzata non soltanto ti mandano subito via a calci in culo, ma devi restituire tutti gli stipendi moltiplicati per 10.

Tanto sei così bravo che non succederà mai, no?

Non ho mai affermato questo. Adesso sei partito col puerile vittimismo da due soldi, mettendomi in bocca cose che non mi sono mai sognato di dire. Evidentemente non ti rimane altro che mentire e mistificare.

Poi che tu non possa rispondere non è una questione di perdita di tempo, ma perché hai già ampiamente dimostrato le tue scarse conoscenze, com'è messo nero su bianco in particolare nel mio ultimo commento.

EDIT. Questo l'hai aggiunto dopo:

E chi se ne frega. La prossima volta pensaci invece di raccontare frottole e falsità, offendendo anche professionisti che sicuramente C/C++ lo conoscono di gran lunga meglio di te, che non sai nemmeno come sono implementate e quanto sono lente le "stringhe" in C...