Newsgroup: it.comp.lang.c++
Titolo: Quanto e' attuale il C++?

Ciao a tutti, e' da un po' che leggo il NG perche' da qualche tempo
sto tentando con relativa fatica di imparare a programmare in C++,
questo un po' per interesse personale e un po' per gonfiare e rendere
piu' appetibile il mio curriculum vitae. Proprio in quest'ultima
ottica mi domandavo quale fossero le prospettive "lavorative" di u
nprogrammatore c++. Quali linguaggi di programmazione e' oppurtuno
affiancare alla conoscenza del c++ per inserirsi nel mondo lavorativo.
Il mio modo di pensare e' che comunque conoscere il C++, o comunque un
linguaggio di programmazione vicino al linguaggio macchina, non possa
far altro che bene. Oltre questo, che rappresenta appunto la base, e'
opportuno imparare qualche cosa che attualmente sia molto richiesto in
ambito lavorativo. L'HTML (con JAVA e compagnia bella), meglio se
dinamico, mi sembra una scelta corretta visto la situazione attuale di
internet e dell'e-commerce. Quale e' la vostra opinione?
Grazie e un saluto a tutti. 
P.S. Se avete testi da consigliare fatelo tranquillamente! :) grazie.
Ciao.

 P.S. Se avete testi da consigliare fatelo tranquillamente! :)
Scaricati Thinking in C++ di Bruce Eckel dalla rete.
EMG

]

 Ciao.
Ok ma scusate i file PHP3 non sono mica in C++, quindi con qualche piccolo
accorgimento girano anche su macchine linux, con le stesse potenzialità dei
CGI, "se abilitati" o sbaglio??
Altrimenti troverei molto più semplice gestire file Visual Basic genrando
ASP, ed utilizzando suite della macromedia, come drumbeat, o generator.


E chi decide la qualità del programmatore? Tu? 
   Roberto
email: 
ro...@ctonline.it

 E chi decide la qualità del programmatore? Tu? 
Secondo me non e' questione di qualita' del programmatore, e' come al
solito questione di tempo/denaro. Utilizzare alcuni oggetti standard in VB
che mi permettono di fare certe operazioni e' sicuramente piu' rapido che
crearne di nuovi in C++, magari piu' veloci, ma che per farli devo
impiegare un po' di tempo. Anche se un programma gestionale in VB
risultera' essere lento in alcuni punti, sara' impercettibile e l'avro'
fatto in meno tempo che farlo in C++... e ovviamente avro' piu' tempo per
lanciarmi subito a fare un altro programma gestionale, e quindi piu' soldi,
ecc...
  E' una visione un po' venale, ma se ci si butta come programmatori
"commerciali" non si puo' perdere tempo, si cerca sempre di usare cose
belle e pronte...
Alla prossima,
Gianluca C.

 belle e pronte...
"Cercare di usare sempre cose belle e pronte" e` una MERAVIGLIOSA
qualita` in un programmatore.  Ne trovassi, di buoni programmatori C++
che hanno questa mentalita`!!!  Purtroppo, fra di noi tende spesso a
prevalere l'hobbista/perfezionista "no, me lo rifaccio da zero cosi` ci
risparmio mezzo bananosecondo" [e, aspetto inespresso, mi diverto
come un babbuino a rifarmelo], che gioca di squadra con la "sindrome
Not Invented Here".
La mia visione e` puramente ingegneristica; gli aspetti "venali" sono
una ricaduta (eventuale, e naturalmente sperabile) dei vantaggi
_ingegneristici_.  Se a usare un pre-fabbricato ottengo un edificio
sostanzialmente equivalente alla costruzione da zero, a meta` del
costo, una parte di quel risparmio la intasca il cliente, una parte io --
la divisione della torta e` determinata dalle leggi di mercato, l'esistenza
della torta e` merito dell'avere usato il giusto approccio tecnologico.
Visual Basic e altri linguaggi di scripting hanno il grande pregio di
incoraggiare una cultura del riuso.
C++ non inibisce affatto il riuso, *anzi*, grazie all'esistenza dei template
("Generic Programming") *tecnicamente* lo facilita in modo estremo.
Non *obbliga*: come sempre, C++ verte sull'assunto che il programmatore
e` un genio, e quel che fa e` ben fatto:-).
Ma il problema e` che la *cultura di provenienza*, il *mindset* dei buoni
programmatori C++ e`, spesso, assai poco orientato al riuso.
Basta vedere le mille scuse che si trovano, le mille capziose paglie cui
ci si attacca, per non riusare anche cose fondamentali come std::vector
o std::string, preferendo costrutti di bassissimo livello come gli array
e i vari new[]/delete[]... 99.44% delle volte (sono scientifico eh?-),
senza benefici di sorta.
Alex

 E chi decide la qualità del programmatore? Tu?
Eh?
EMG

 senza benefici di sorta.
Ach!
Qui mi sento colpito in pieno!!! :-)
Perņ credo che 2 motivazioni possano essere valide:
- la scarsa familiaritą con queste "novitą"
- la possibilitą di dover riscrivere la libreria in un linguaggio che non
supporta questi costrutti
Sono entrambi risolvibili con "non troppo" lavoro, d'accordo, ma possono
essere almeno considerati un piccolo freno al loro utilizzo?
--
Alessandro Monti

 solito questione di tempo/denaro.
Appunto. Un programmatore alle prime armi costa meno di uno esperto.
EMG

 essere almeno considerati un piccolo freno al loro utilizzo?
La mancanza di familiarita` sicuramente lo e`.
La facilita` di scrivere un lookalike di vector<> per eventuali
semiquasicompilatori in cui mancasse, invece, dovrebbe
incoraggiare ad usarlo al posto delle new[]/delete[] nude,
a mio parere.
Alex

 programmatore.
Non sono d'accordo. Certo, se ti limiti ad utilizzare uno strumento per
creare visualmente le pagine allora hai ragione. Ma l'ambito del lavoro
su Internet è molto vasto e coinvolge l'utilizzo di linguaggi di
programmazione e tecniche sofisticate.
EMG

]

 nella vita ho sbagliato tutto :)
No, no, tranquillo. Stai andando bene. :-)
EMG

 P.S. Se avete testi da consigliare fatelo tranquillamente!
Un testo di fondamenti di informatica I e II, in genere le basi per
qualsiasi linguaggio, poi dipende da ciò che vuoi fare.
Per l'html credo che uno dei tanti corsi o manuali via internet sia buono
per imparare, visita il sito 
www.html.it
--
| /
| \Byte - Andrea Briganti
E-Mail 
kbyt...@freemail.it
ICQ 40872731

 E chi decide la qualità del programmatore? Tu?
Non credo che volesse offendere nessuno...
Però c'è da dire che il VB è molto limitato per il tipo di applicazioni che
è possibile scrivere.


nella vita ho sbagliato tutto :)
Non ho capito bene se ti riferivi al mio messaggio .. se si l'hai male
interpretato perche' appunto io intendevo il contrario ...

interpretato perche' appunto io intendevo il contrario ...
Scusa il discorso era generale, anche se l'impressione era un po'
quella, soprattutto sul fatto del confondere un linguaggio di
marcatura con uno di programmazione (nel secondo caso non basta
'conoscere il linguaggio', ma occorre saper maneggiare strutture dati
ed algoritmi)



Non sono daccordo sul tuo discorso. Dipende da che punto di vista guardi la situazione. Se usassimo
tutti i prefabbricati avremmo tutti case identiche e sarebbe una tristezza indescrivibile. Idem per
quanto riguarda il software. Se porti l'idea di "usare sempre cose belle e pronte" al livello
superiore, a quello dei programmi già fatti, elimini tutto il senso della programmazione. Perchè creare
un compilatore quando ne esiste già uno che funziona? Perchè non usare Windows visto che lo fanno
tutti? Perchè scrivere un programma che legge gli mp3 quando ce ne sono decine gratuiti scaricabili
direttamente dalla rete? Sono daccordo che sia utile e persino bello utilizzare una libreria (magari
quella standard) invece che riscriversi delle cose semplici da capo, ma eseguire un puro assemblamento
di oggetti già creati (come del resto è comune fare in Visual Basic) trovo che sia immensamente
produttivo, ma palloso e deprimente. Immagino però, che questo sia opinabile (ciascuno si diverte in
maniera diversa:-)
Ciao Fulvio.

Perchè creare un compilatore quando ne esiste già uno che funziona?
Infatti, se il compilatore risponde alle esigenze del caso, va benissimo così
com'è, ammeno che il mio lavoro non sia quello di scrivere compilatori,
situazioni in cui, invece, tenderei a migliorare il prodotto, ma proprio perché
questi sono i miei requisiti.
Analogamente per gli altri esempi che poni.
Andrea

 maniera diversa:-)
Certamente, e divertiti sinche` vuoi nel costruire Torri Eiffel di cerini,
ma
non confondiamo questa attivita` con la prassi professionale, ok...?
L'unica cosa che trovo a volte "pallosa e deprimente" nella programmazione
sono le dannate e malnate sessioni di debugging che possono, nondimeno,
risultare necessarie.  Se ho a disposizione componenti gia` debuggati, che
posso mettere insieme per comporre una soluzione che risolve tutti i
requisiti tecnici e commerciali del caso, allora sarebbe da pazzi non
usarli.
La fame di soluzioni (spesso, di soluzioni necessariamente innovative) da
parte del mercato e` intensissima.  Un buon ingegnere informatico di
lavoro interessante da fare ne ha sin troppo; se puo` farlo ad un livello
di produttivita` e di soddisfazione superiore, utilizzando componenti gia`
pronti e ben funzionanti per la maggior parte del suo lavoro, BEN VENGA!
Alex

Eh?
Nella parte del tuo messaggio che ho quotato sembra che tu stia
stabilendo una relazione fra la programmazione in VB e la
programmazione di bassa qualità. Relazione che, secondo me, non
esiste.
   Roberto
email: 
ro...@ctonline.it

esiste.
Diciamo che se si fa a vedere la funzione di distribuzione di prob. di
trovare un programmatore non preparato si ha un picco in
corrispondenza del VB. Cosi' va bene? :)
A parte gli scherzi, il VB e' un linguaggio di programmazione con un
ambito di applicazione ben definito e sotto certi aspetti limitato, un
ambito dove di solito le applicazioni non raggiungono dimensioni o non
hanno requisiti tali  da essere ingestibili da programmatori naif.
Quindi P(scarso|VB)!=1, ma neppure trascurabile...


 esiste.
Nella mia esperienza invece esiste e come. Il VB è il linguaggio
elettivo dei "praticoni" (termine preso in prestito da Alex :-) ) che
sono gli stessi che poi vengono impiegati, magari come esterni, dalle
ditte poco serie (che sono, purtroppo, la maggioranza).
EMG


Perche' non si riesce a capire come far funzionare quello esistente (o
equivalentemente, perche' per far funzionare quello esistente ci vorrebbe
piu` tempo che non per riscriverlo) ?
Se la documentazione del prodotto esistente consiste in un manuale
di 1.000.000 pagine, prima di aver capito bene come funziona il tutto,
avrei potuto riscrivermi forse quel sottoinsieme di funzionalita` che mi
servono (dipende da come e` fatto il manuale, da quante e quali funzionalita`
mi servono, ecc.)
Ovviamente il tutto e` un po' provocatorio, ma comunque per la mia
esperienza qualcosa di vero c'e`
Marco Guidi


Non credo che Alex Martelli si riferisse a questo.
Il suo discorso era relativo a cose di impiego generale, come appunto
gli algoritmi e le strutture dati contenute nella libreria standard.
Il suo discorso e` dunque da intendersi in questo senso:
"Che motivo c'e` di riscriversi ogni volta una classe list
o vector o un algoritmo di sorting quando c'e` gia` pronto
ed e` perfettamente adatto alle tue esigenze?"
In sostanza una cosa dovrebbe essere riscritta se ne hai
veramente bisogno (ad esempio vuoi un algoritmo di sorting
piu` veloce di quello di cui disponi). Il vantaggio sarebbe
quello di poter dedicare piu` tempo ad altre cose, magari
proprio alle funzionalita` che il tuo programma deve fornire
all'utente...
Lo stesso vale per una qualsiasi libreria, se devi realizzare
un programma di modellazione 3D non credo che vorresti
perdere tempo a realizzare una libreria per la grafica 3d
quando le opengl sarebbero sufficienti, al limite la tua
preoccupazione potrebbe essere quella di realizzare uno strato
software che ti permetta successivamente di cambiare
libreria senza dover riscrivere tutto da zero.
Il concetto lo si applica poi anche al caso in cui si debba realizzare
la nuova versione di una certa applicazione (e credo che il riferimento 
fosse anche a questo). Se ci si trova
in una tale situazione evidentemente e` perche` la precedente
versione non soddisfa appieno le attuali esigenze, in questo
caso di solito non si riscrive tutto da zero, ma si lavora
alle parti che non soddisfano cercando di riciclare il resto
(con un grande risparmio di tempo e soldi e consentendo
potenzialmente una migliore qualita` del prodotto).
Oppure pensi che MS nel realizzare win2000 abbia riscritto
tutto da zero?
Paolo

 tutto da zero?
Hai fatto l'esempio peggiore. Una riscrittura da zero di Windows sarebbe
più che auspicabile... :-)
EMG

ditte poco serie (che sono, purtroppo, la maggioranza).
Posso confermare anche io.
Certo non si puo` fare di tutta l'erba un fascio, ma fin'ora tutte le
mie esperienze (in campo lavorativo e accademico) mi confermano
cio`. Per quanto ho visto VB e` un linguaggio che permette con pochi
sforzi e poche conoscenze di fare molte cose e molti si trastullano
con il solo saper fare funzionare qualcosa, salvo poi doverci
rimettere le mani per un qualche motivo.
Paolo

esperienza qualcosa di vero c'e`
Raramente esiste una verita` unica ed assoluta, la critica comunque
era diretta a chi a priori si ostina a riscrivere tutto da zero quando
invece non ne avrebbe bisogno.
Paolo


Grazie per la risposta.
Sono abbastanza d'accordo con te, pero`,  secondo me,
se non si riesce a stabilire un criterio di misura quantitativo
per alcuni dei concetti che tu esprimi, mi sembra che
la cosa sia un po` ardua.
Ad esempio tu dici "si puo` evitare di scrivere codice
oscuro". D'accordo, pero` bisognerebbe avere un modo
per misurare quantitativamente il
"livello di oscurita`" di due codici diversi per capire quale
e` migliore.
Dico questo perche' alcuni miei colleghi ogni tanto mi
dicono: "io faccio cosi` perche' cosi` il codice risulta
piu`  'pulito'". Io magari nel frattempo
facevo una scelta opposta perche' con la mia scelta, a me
sembrava di rendere il codice piu`  'puilito'
(esempio stupido: io in genere in un file .c o .cc, tipo pippo.cc,
cerco di includere tutti e soli gli header che mi servono.
A me sembrava e sembra ancora la tecnica piu` 'pulita'.
Alcuni miei colleghi trovano migliore includere in pippo.cc
solo un header, tipo pippo.h; poi pippo.h includera` tutti
gli altri header che servono. Se non ho una metodo per fare
una  valutazione
quantitativa, io continuero` a credere che il mio modo di
procedere sia 'piu` pulito', i miei colleghi considereranno che
il loro modo di procedere sia 'piu` pulito' e nessuno potra`
dire di aver ragione).
Oppure quando dici "..che conosca il suo mestiere
quanto basta per ...".
Anche qui si dovrebbe stabilire quantitativamente
in qualche modo quale e` il livello di conoscenza che
"...basta per...".
Ad esempio io penso  che
per capire il codice sia spesso importante capire
il problema che con quel codice si vorrebbe risolvere.
(Altro esempio stupido: se un codice e` scritto per risolvere
qualche problema economico in ambito bancario,
io che non so nulla di come funziona una banca credo
di avere poche probabilita` di capire come funziona
quel codice, anche se e` scritto bene.
D'altra parte se io scrivo codice per un
sistema real-time, dubito che chi si e` sempre
occupato di scrivere codice per applicazioni gestionali
possa capire molto nel codice scritto da me.
E questo, credo, anche a parita` di preparazione su
argomenti puramente informatici).
[RISNIPPATOTUTTO]
Grazie ancora per la risposta
Marco Guidi

Mi autorispondo, per spiegarmi meglio. Mi rendo conto di avere fatto un osservazione più filosofica che da
programmatore. Certo anch'io uso la libreria standard e addirittura le MFC più spesso che posso. Non volevo
sostenere assoulamente che bisognerebbe di volta in volta riscriversi una classe vector o un algoritmo di
ordinamento invece di utilizzare quelli standard. Io ho cominciato a programmare che ero, mi sembra, in 2a
media, su un C64, lo avevo preso per giocarci ed assieme al computer c'era in "offerta speciale" un manuale
per programmare il basic C64. Non mi ricordo quasi nulla di quel manuale, ma una delle cose che mi è
rimasta impressa era un consiglio ai futuri programmatori (:-) "non innamoratevi dei vostri programmi, ma
siate sempre pronti a buttare tutto e a ricominciare da capo." Era nato tutto dall'affermazione di Martelli
:"Cercare di usare sempre cose belle e pronte" che mi sembrava eccessiva, troppo squadrata. Il mio non
voleva essere un inno al bricolage (magari agli artisti un po' sì :-).
Ciao FBF.

 da capo una cosa che ha gia` pronta.
Tanto per intervenire, la mia esperienza è stata questa: all'inizio mi
piaceva fare tutto da zero e avevo non vi dico quali velleità (e questo
mi è sicuramente servito ad imparare tante belle cose). Poi, quando
l'informatica è diventata per me anche un lavoro, mi sono trovato quasi
ad essere due persone diverse (un professionista ed un hobbista) con due
interessi e due tipi di approccio completamente diversi (anche se
riguardanti la stessa materia). Ora devo dire che, forse a causa
dell'età (beh, non esageriamo), l'energia iniziale si è molto smorzata e
la ricerca del miglior rapporto risultati/fatica è diventata ormai il
mio normale modo di procedere.
Ciao a tutti.
EMG

esiste.
Parlare di qualità senza stabilire delle metriche di riferimento non ha senso.
Altrimenti cadiamo nelle guerre di religione o simili. Tu affermi che
programmare in VB consente di produrre codice di medio-alta qualità (cioè di non
bassa qualità). Io dissento, però ti chiedo: quali sono le metriche alle quali
ti riferisci, anche informalmente?
Ad esempio, alcune tipologie di metriche di qualità che io considero sono le
seguenti:
1 Metriche a livello architetturale
2 Metriche a livello di design dettagliato
3 Metriche relative alla codifica
4 supporto per il design by-reliability
5 supporto per il design by-testing
Apparte il punto 3, tutte le altre vertono su questioni di design. Buon codice
deriva da buon design e quest'affermazione (non mia, per altro) è tanto più vera
quanto più il progetto ha dimensioni importanti. Gli ambienti di sviluppo RAD
tendono a farmi lavorare più a livello di interfaccia utente che a livello di
architettura. Questo va benissimo per applicazioni piccole o fortemente
standardizzate, laddove la "meccanica" delle operazioni logiche è più o meno
sempre la stessa. La creazione di una finestra Windows si fa sempre nello stesso
modo, il meccanismo generale di handling dei messaggi è prototipato e così via.
Non ha senso riprogettare tutto da capo (oltre che dispendioso, essendo
un'attività ripetitiva, è anche error-prone).
Purtroppo non è altrettanto facile sfruttare il medesimo riuso prototipato per
scrivere architetture di sistemi software più complessi. Qui nascono i guai con
ambienti di sviluppo stile VB: ti danno l'illusione di una maggiore
produttività, ma non hanno la sufficiente potenza per astrarre architetture
complesse, nè tanto meno personalizzabili. Allora si deve procedere
"manualmente", e il Wizard o il RAD di turno (discorso non limitato al solo VB)
fa invece di tutto per tenerti a un livello d'astrazione più altro; fa di tutto
per farti prendere meno decisioni possibile (questi erano i suoi requisiti,
d'altronde).
Prova a valutare la qualità del codice di un tuo progetto VB, non solo in
termini di velocità o di tempo uomo impiegato per la prima scrittura (o di
quanto è bella una dialog box col pulsantino e un animazione ;-)). Il
software, soprattutto quello non banale, si evolve, viene modificato. Quanto
facilmente riesci ad estendere il tuo progetto (prevedi prima modifiche banali,
ma aggiungi almeno una modifica non banale)? Quanto riesci a riusare
dell'architettura originaria? E' *abbastanza strutturata* tale architettura da
permetterti di isolare le modifiche in porzioni limitate di codice, oppure hai
un'architettura monololitica? Che grado di accoppiamento c'è fra i vari moduli
e, soprattutto, il tuo ambiente di sviluppo che grado di libertà ti concede
rispetto a questo vincolo?
Spostandoti dal design by-reliability al design by-testing, puoi chiederti:
Quanto facilmente la mia applicazione e testabile? E una modifica che impatto
ha sul testing già eseguito? Quanta porzione di codice devo ritestare? ...
In base alle risposte a domande come queste puoi avere una visione più
ingegneristica del livello di qualità e del supporto ad esso che uno strumento
software ti fornisce.
A questo punto mi scuso doverosamente con tutti per la lunghezza di questa
risposta che, mi sono accorto adesso, è pure OT. Queste sarebbero più
considerazioni da
it.scienza.informatica.software-eng dove, se volete, si può continuare la
discussione.
Ciao
AB
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrea Baruzzo
Via Circonvallazione, 26
Muzzana del Turgnano (UD) - Italy
e-mail: 
andrea....@ud.nettuno.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 voleva essere un inno al bricolage (magari agli artisti un po' sě :-).
Nulla in contrario agli artisti, purche` si facciano pagare da qualcun
altro (e rendano ben chiaro a questo 'altro' che si stanno facendo
pagare per la loro 'arte').  Un programmatore che, a spese del cliente,
riscrive codice che avrebbe invece potuto riutilizzare, e` come un
idraulico che, sempre a spese del cliente, sceglie di costruire lui i
tubi da istallare invece di comperarli (a un decimo del prezzo) dal
ferramenta: se, come e` presumibile, riesce ad imporre al cliente
questa spesa extra solo perche` il cliente e` stato male informato o
ingannato, e` colpevole come minimo di grave scorrettezza dal punto
di vista professionale, se non di circonvenzione d'incapace.
Se poi l'idraulico in questione, per suo privato e personale hobby,
spende i propri soldi e il proprio tempo libero nella costruzione di
tubi, cavoli suoi.  Ma questo ha circa altrettanto a che vedere con
la sua professionalita`, quanto ne avrebbe la pesca alla trota.
Alex

il problema che con quel codice si vorrebbe risolvere.
Anche...
Ripeto, non credo si possa sempre trovare un metro
assoluto, in queste cose probabilmente il metro migliore
e` il buon senso.
Paolo

quanto riguarda il software.
Io penso che Alex si riferisse al fatto di usare componenti software
giá testati e che puoi riutilizzare nel tuo codice. Prendendo il tuo
esempio sulle case, direi che nessuno che deve costruire un'abitazione
si fabbrica da solo i mattoni, il cemento, le finestre, le piastrelle
ecc....ecc....  Perché devo andare a riscrivere ogni volta il codice
per gestire uno stack, una lista o quant'altro quando quello esistente
soddisfa le mie esigenze ? Un caso in cui ció é utile, se non
indispensabile, é quello didattico o quello di colui sta imparando un
linguaggio di programmazione. Una volta capito il concetto e toccato
con mano posso riusare benissimo cose giá fatte. E' lo stesso discorso
che si puó fare con i  wizard dei vari ambienti di sviluppo tipo VC++,
VB, BCB etc.. (ma qui siamo OT)
Ciao
Pierluigi