Newsgroup: it.comp.lang.c++
Titolo: Riflessione sul linguaggio C

Circa 2 anni fa ho dovuto, per motivi di lavoro, imparare il C.
L'impatto è stato traumatizzante!
Attualmente continuo ad utilizzarlo (sempre per lavoro) ma tuttora ho seri 
dubbi su come è stato concepito questo linguaggio.
Premetto che non sono nuovo in fatto di programmazione, ho quasi venti anni 
di esperienza, conosco oltre 15 linguaggi di programmazione e il mio lavoro 
è proprio il programmatore.
Ammetto che il C è un linguaggio è molto potente, permette di fare cose 
(soprattutto a basso livello) che con altri linguaggi diventa dura.
Premesso ciò mi chiedo: ma chi ha inventato il C non poteva creare una 
sintassi più semplice?
Ogni programma realizzato in C è imbottito di ";" , "{}" e altre cose senza 
senso!
Ogni simbologia utilizzata con altri linguaggi viene abolita in C.
Un semplice esempio:
In C una comparazione viene scritta:
 if ((a!=c) && (b==d))
{
       a=c;
}
In BASIC (e in tanti altri linguaggi) si scrive:
IF (a<>c) AND (b=d) THEN
      a=c
ENDIF
Con questi esempi è possibile vedere la differenza di chiarezza tra le due 
sintassi.
Siamo abituati a scrivere DIVERSO con i simboli <> e non !=.
Siamo abituati a scrivere AND con il simbolo AND e non &&.
Siamo abituati a scrivere UGUALE con il simbolo = e non ==.
Che senso ha mettere un ";" per indicare il fine della riga?
Penso che ogni linguaggio di programmazione debba avere alcune 
caratteristiche fondamentali che non è possibile farne senza e sono: 
potenza, chiarezza, semplicità.
Il C ha molta potenza, poca chiarezza e poca semplicità.
Ciao a tutti
T_C
 

 L'impatto è stato traumatizzante!
Sei serio, o sei un troll?
In ogni caso sei OT. Spostati su alt.comp.lang.c.sucks.
Max

 Siamo abituati a scrivere UGUALE con il simbolo = e non ==.
...siamo... chi? io diverso sono abituato a scriverlo "?"; and, or e not
come "^", "v" e "¬"; ecc...
-- 
Under construction

sintassi piů semplice?
ah ah ah... era da tempo che non compariva un troll!! :-)

...siamo... chi? 
Don't feed the troll!, non è un caso che tale
"
the_carp_...@libero.it
" compaia una sola volta su Google
Groups e qui dentro ;-)

Secondo me T_C ha ragione, fondamentalmente il C rimane un linguaggio a 
basso livello
con tutti i limiti sintattici che può avere un sw a basso livello.
Ciao Andrea 

cos'è un troll?

 Don't feed the troll!, non č un caso che tale


Secondo me T_C ha ragione
AH AH AH...
http://groups.google.it/groups/search?hl=it&q=a.chista%40tiscali.it&qt_s=Ricerca

cos'è un troll?
"In Internet terminology, a troll is a person who enters an
established community such as an online discussion forum and
intentionally tries to cause disruption, most often in the form of
posting inflammatory, off-topic, or otherwise inappropriate messages."
http://en.wikipedia.org/wiki/Internet_troll

Troll a te e a tua mamma!
Ah ah ah.. e certo, come no... :-)

E' fantastico tentare di parlare di qualcosa e trovarsi un malato mentale 
che risponde in un NG di programmazione.
Ha scritto 4 risposte senza un senso logico.
Hai problemi mentali?
La cagna del vicino non te la da piů?
Ti sei rovinato le mani a forza di guardare film porno?
Le scimmie che hai in testa hanno cominciato a cagare?
Hai finito i soldi per la droga e cosě sei fumato i tuoi escrementi?
Ti hanno preso i VILLAGE PEOPLE?
Ti do un consiglio: se tutto quello che sai dire č quello che ho letto nelle 
tue risposte VAI DA UN PSICHIATRA al piů presto!
T_H
"Andrea Laforgia" <a.laf...@andrealaforgia.it.invalid> ha scritto nel 
messaggio news:b05fl2pmmbna8k8hi...@4ax.com...


 
Perché hai aperto un thread dal titolo "Riflessione sul linguaggio C" in 
  un ng che si chiama it.comp.lang.c++ ?!?!


se la pensi cosi mi fai venire voglia di impararlo

 Il C ha molta potenza, poca chiarezza e poca semplicità.
Sulla potenza ho i miei dubbi, e' un formalismo come altri. Richiede un po' 
piu' di tempo, forse... credo sia stato creato per creare una barriera 
all'ingresso nello sviluppo software ;)
--
Marco 

 all'ingresso nello sviluppo software ;)
Il C è stato creato per competere con codice asm *ben scritto*, in un 
periodo in cui i compilatori non ottimizzavano quasi niente.
Kiuhnm

 se magari ci fosse un manuale come quello del php per il c non sarebbe male
Cosa non ti piace del K&R? (ma sono io rincoglionito o qui siamo su
iclc++?)
-- 
RiK0

 periodo in cui i compilatori non ottimizzavano quasi niente.
Grazie ancora
T_C

 Il C č stato creato per competere con codice asm *ben scritto*
se posso, mi permetto di aggiungere che faceva concorrenza a un 
buon assembly PER ALCUNE piattaforme (tipicamente quelle a stack 
e architettura lineare di memoria).
Poi č stato adattato con qualche misera facility (2 variabili 
register in croce) a processori a registri interni specifici.
In effetti un tempo mi stupiva quanto efficacemente venissero 
spremuti fino all'ultima goccia i registri puntatori 
stack-oriented (SP, BP, e al limite qualche contatore) e quanto 
poco fossero usati gli altri.
Che macchine andavano in quel modo ? Non ricordo bene .... il 
motorola 68000 era di quel genere ?
Cmq, per alcuni CISC piuttosto macchinosi, non era manco molto 
difficile scrivere a mano pezzi di codice che polverizzavano il 
compilato (in particolare ricordo che il Borland e il Wacom 
erano molto piů deboli di me, che ero mediocrissimo a scrivere 
assembler, nelle subroutine a stringa, e usavano malissimo i 
registri indice di stringa, tipo _SI, _DI degli 8086 e successori).
Ora non so che codice producano i compilatori ottimizzanti.
Spremono per bene l'hardware ? Sfruttano del tutto il set di 
registri interni effettivamente disponibile o l'approccio 
ipercauto dello sfruttamento solo del subset minimo comune ?
ciao
Soviet


 sfruttamento solo del subset minimo comune ?
Il migliore per macchine Intel forse è l'Intel C++ perchè di default usa 
tutte le estensioni dei processori moderni.
Anche il Visual C++ permette di compilare usando MMX, SSE, ecc..
Ed il gcc ha un flag per architettura target (-march=pentium4 per 
esempio) che dovrebbe fare qualcosa di simile.
Io comunque ho l'impressione che tentino di sfruttare al massimo 
l'hardware solo compilatori per sistemi embedded.
Almeno guardando la tendenza verso computer ultrapotenti e linguaggi 
high-level, dinamici con GC delle piattaforme di sviluppo in voga sugli 
OS più diffusi.
Purtroppo non ti so dare dati precisi in quanto è già molto che non 
maneggio assembly.
Ciao

 l'hardware solo compilatori per sistemi embedded.
Io ho l'impressione che succeda anche su piattaforme standard, ma con 
intrinsic non standard (tipo quelli per MMX, SSE, SSE2).
Purtroppo i compilatori non sono (ancora?) in grado di usare le istruzioni 
in streaming decentemente, molto spesso neppure nei casi ovvi.
--
Marco 



Credo di no. Uno degli visi era bene che un compilatore potrebbe
generare un codice abbastanza performante senza troppe
complicazioni, ma già a l'inizio, era admesso che un buon
programmatore assembler poteva fare megliore. In fatti, la
semplicità del compilatore era molto importante, perche era
creato per tornare su delle machine con poche risorse (memoria,
etc.).
Penso anche che il fato che la stampatrice corrente era un
teletype non è senza influenze neanche. Se sei mai stato nella
stessa locale di una teletype in azione, capisci che meno c'è
caratteri, megliore è.
--
James Kanze (GABI Software)             
email:james...@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, 
+33 (0)1 30 23 00 34

 a rispondere e se non hai nulla da dire TACI).
Sparisci deficiente.

 etc.).
Da "The Development of the C Language":
---
Aside from the problems with the language itself, the B compiler’s 
threaded-codetechnique
yielded programs so much slower than their assembly-languagecounterparts 
that we discounted
the possibility of recoding the operating system or its central 
utilities in B.
In 1971 I began to extend the B language by adding a character type and 
also rewrote its
compiler to generate PDP-11machine instructions instead of threaded 
code. Thus the transition
from B to C was contemporaneous with the creation of a compiler capable 
of producing programs
fast and small enough to compete with assembly language. I called the 
slightly-extendedlan-
guage NB, for ‘new B.’
[...]
C is quirky, flawed, and an enormous success. While accidents of history 
surely helped, it
evidently satisfied a need for a system implementation language 
efficient enough to displace
assembly language, yet sufficiently abstract and fluent to describe 
algorithms and interactions in a
wide variety of environments
---
Kiuhnm

Kiuhnm ha scritto:

mah, questa è una dichiarazione di intenti. Cosa dimostra, e che 
generalità ha ?
Ripeto, che a me personalmente (anni addietro, sottolineo), che 
pure ero mediocre in asm, capitava di battere tranquillamente le 
routine C di puro calcolo matematico o di elaborazione stringa o 
3D, cose simili, anche solo usando l'assemblatore inline (che 
era ben più ristretto del TASM standalone).
Ora questo non era una regola aurea, non è che scrivessi interi 
programmi in asm, solo pezzi di codice limitante, riguardava 
piccole routine di cui conoscevo bene cosa dovevano fare e 
discretamente cosa desiderava il processore per dare il suo 
meglio. Era pure codice non portabile, ovviamente, e fungeva 
bene per quella classe di processori.
Ma imho è sintomatico che un mediocre programmatore scrivesse 
codice più rapido, anche di un ordine di grandezza. Non dimostra 
che il C sia poco efficiente, ma imho toglie generalità alla 
pretesa che il C batta il codice scritto a mano sempre o spesso.
La ragione penso non sia tanto nella cattiva qualità del C, ma, 
semplicemente, che un compilatore non può permettersi il grado 
di non portabilità che un uomo si concede se scrive a mano su 
misura per la sua CPU. Il linguaggio deve fare compromessi 
decenti tra performance e generalità di piattaforma.
Oggigiorno invece non so, ma questo l'ho detto subito.
E' possibile che la specializzazione per date piattaforme sia 
diventata molto spinta e possano essere prodotte versioni 
specifice per pentium IV, o per athlon 64 o core 2 duo o 
chissachi ...
ciao
Soviet


 mah, questa è una dichiarazione di intenti.
Che è esattamente quello di cui si stava parlando.
Kiuhnm

 Kiuhnm

 rileggere testualmente era stata solo una mia idea, una interpretazione.
Non ti preoccupare :)
Aggiungo che se a volte rispondo in fretta è perché ho veramente poco 
tempo. Le mie non vogliono essere risposte sprezzanti.
Kiuhnm

 era ben più ristretto del TASM standalone).
Ma Richie non ci dice altre cose. L'espressione americana "fast
and small enough to compete with assembly language" non vuol
dire che vincono la competizione. In fatti, quando leggo questo
passagio, capisco solo che B era cosi lente che non poteva
essere presso in considerazione, che con C (o NB) inveci, la
differenza di performance era abbastanza piccola che era
possibile considerarlo.
Espressioni come "can compete with" o "is in the same ballpark
as" non danno un limita precisa. Possiamo dire che se C è 10%
meno rapido, son vere, e se è 10 volte meno rapido, non son
vere. In fatti, su un processore con un'architettura ortogonale,
come il PDP-11, coi compilatori d'allora, un codice C era far
1,5 e 2 volte meno rapido dello stesso programma scritto in
assembler. (Con un compilatore moderne, la differenze è forse
1,2 o meno.)


 dire che vincono la competizione.
E in italiano?
Kiuhnm


Pure. "Essere competitivi con" non significa necessariamente "vincere".
Ciao
  Andrea