Newsgroup: it.comp.lang.c++
Titolo: Del C++ e dei frameworks

Ciao a tutti,
Si notano spesso svariati postings che recitano piu' o meno:
"voglio imparare il C++ usando il VisualC++ " (o altro framework del momento)
Le risposte, immancabilmente, consigliano di lasciare da parte il
Visual per concentrarsi sul rimanente C++.
Tutto questo  e' sicuramente vero, pero'... 
Per usare MFC, o un altro framework, in realta' non serve davvero conoscere il C++ piu'
di tanto. Si possono scrivere delle belle applicazioni nel giro di un mese anche 
se non si sa esattamente cosa succede per davvero, e questo porta come
effetto collaterale l'impressione di sapere usare il C++;  non credo di
esagerare se dico che un buon 80% di sviluppatori MFC viene facilmente messo 
con le spalle al muro da un discreto conoscitore di C++. 
Il fatto e' che questo non e', all'atto pratico, significativo piu' di tanto. Buona
parte delle applicazioni MFC che ho visto e' fatta in genere male, se non malissimo, 
ma se funziona, chi se ne frega.
E' un ragionamento terribilmente sbagliato? Si' , ma la realta' ci insegna diversamente.
Quando si ha a disposizione uno strumento piu' o meno succulento, la tendenza 
e' quella di arrivare al piu' presto a scrivere delle belle applicazioni piene di grafica e
finestre; e' molto piu' divertente che copiarsi gli esercizi sui testi di C++ e studiarci su.
Questa tendenza viene aizzata particolarmente da due cose: l'innegabile attrazione, 
del tutto comprensibile, che hanno le applicazioni grafiche, ed il fatto che quelle che 
 vengono piu' richieste sono applicazioni sempre piu' belle, appunto,  e sempre piu' complesse.
Questo ha portato alla proliferazione dei framework, il cui scopo e' di facilitare
la risposta a queste esigenze. Un framework, piu' e' ben fatto e piu' nasconde la complessita'
sottostante,e questo, inevitabilmente, allontana la percezione di quello che lo sviluppatore sta
facendo.
Il risultato di questa 'ansia' di saper creare delle meraviglie, unito alla disponibilita' di
strumenti sempre piu' potenti,  produce degli sviluppatori che spesso non sanno cosa stanno facendo;
sanno solo che i loro programmi in qualche modo funzionano, e questo in buona parte dei casi basta.
L'anomalia che ne deriva e' che se da una parte  vengono richieste 
applicazioni sempre piu' belle e complicate, dall'altra la qualita' degli
sviluppatori che le implementano diminuisce a vista d'occhio. 
La trappola dei framework e' proprio questa: permettono di arrivare a buoni risultati 
senza dover passare attraverso lunghi studi. 
Il sugo di questo discorso e' che uno sviluppatore MFC non deve necessariamente
essere uno sviluppatore C++ nel senso piu' pieno del termine, deve solo conoscere un minimo
delle caratteristiche del linguaggio, e invece conoscere bene quello che il suo framework gli
permette di fare.
Sarebbe bene che lo 'sviluppatore da framework' (non inteso in senso denigratorio) tenesse 
sempre ben presente questa differenza. Approfondire e perfezionare la conoscenza del
linguaggio che rende possibile tutto cio' e' lasciato al proprio senso di responsabilita'
professionale, ed e' una grande fonte di soddisfazione personale. I framework cambiano
piu' spesso dei linguaggi, quindi chi sa cosa c'e' sotto trovera' piu' semplice adattarsi ai
nuovi modelli.
Se MFC sparisse domani, quanta gente si sorprenderebbe di scoprirsi ignorante?
Scusate la sbrodolata; questo e' il Lupo Buono-pensiero di oggi; attendo commenti!!

 Se MFC sparisse domani, quanta gente si sorprenderebbe di scoprirsi
ignorante?
Personalmente ignoro anche le MFC. Almeno finchè riesco ad evitarle.
Io in realtà sono per un altro approccio: con tanta varietà di linguaggi e
framework, purchè interoperabili, perchè non usare ogni volta quello più
adatto all'applicazione da realizzare?
Perchè "sprecarsi" con il C++ se devo realizzare una maschera di input sotto
windows? Con il VB la realizzo in 5 minuti (perlomeno un prototipo
funzionante, poi andrà raffinato) e non vado incontro a sorprese solo perchè
ho dimenticato un puntatore in giro... Ovvio che se servono parti di
programma che facciano operazioni più complicate, allora bisogna essere in
grado, come minimo, di scriversi funzioni in C (una DLL per esempio).
Se i framework sono sufficentemente "aperti", non c'è niente di male ad
usarli, se invece ti impongono la loro "visione" a tutti gli aspetti della
programmazione, sono fuorvianti.
Tutto ciò, ovviamente, secondo la mia opinione.
--
Alessandro Monti


~~~~~~~~~~~~~~~~~
MAINARDI Gianfranco
Burago di Molgora (MI)
Italia
Email : 
main...@rete039.it
ICQ# number : 31334916
~~~~~~~~~~~~~~~~~

 ignorante?


programmazione, sono fuorvianti.
Qui la pensiamo allo stesso modo.
AB
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrea Baruzzo
Via Circonvallazione, 26
Muzzana del Turgnano (UD) - Italy
e-mail: 
andrea....@ud.nettuno.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

D'accordo con te sul discorso generale (anche se i tool facilitano la 
vita solo sul fronte delle cose per cui sono stati pensati e niente 
altro), ma se la richiesta e` imparare il C++ non posso non raccomandare
il percorso piu` idoeno (IMO) alla cosa.
Se la domanda fosse voglio fare applicazioni windows in VC++
la risposta sarebbe:
a) it.comp.programmare.win32
Paolo
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

 E' un ragionamento terribilmente sbagliato? Si' , ma la realta' ci insegna diversamente.
Il ragionamento è sbagliato e la realtà ci insegna proprio questo. Basta
vedere la qualità media del software in circolazione. Roba sviluppata in
fretta e furia e rilasciata senza neanche un test. E i risultati si
vedono.
EMG

chi sa cosa c'e' sotto trovera' piu' semplice adattarsi ai nuovi modelli.
yes!
Ciao


 Conclusione troppo superficiale. Troppi altri parametri da considerare.
Io ne ho considerato uno solo: il duro mondo del lavoro.
Se lo guardiamo dal punto di vista della "migliore programmazione", il C++ è
senz'altro preferibile, ma vallo a spiegare ai clienti che devono "solo"
lavorarci col programma, non rigirarselo tra le dita.
Mi dispiace di essermi espresso male. Una buona parte del mio discorso era
forse uno sfogo riguardo il fatto che sul lavoro ci sono tempi da rispettare
di solito molto stringenti, e la buona programmazione diventa spesso un
lusso non sostenibile.
Principi del programmatore: (ovviamente scherzosi)
Un cliente che si sente dire che ci vogliono mesi per avere il programma, è
un cliente perso.
Un cliente che ha in fretta un buon prototipo per cominciare a lavorare, è
disposto ad aspettare un po' per avere una versione stabile, e di solito
criticherà la scelta dei colori a video, non la lentezza o la grandezza del
programma.
Un cliente che deve sborsare milioni per fare realizzare un programma, non
si fa problemi a spenderne un paio in più per cambiare PC, tantomeno poi se
bastano solo qualche centinaio di K£ per aggiornare RAM o HD.
Tutto ciò a meno di lavorare a progetti "seri", dove c'è qualcuno realmente
interessato alla qualità del SW.
A me è non è mai capitato, tutto qui; logico quindi che la mia opinione sia
a "favore" dei framework. Con sguardo critico.
--
Alessandro Monti

prima.
Il punto non e` fondamentalismo o no...
Se vuoi imparare il C++ (e non solo averne una vaghissima idea) c'e` 
poco da fare, bisogna studiare e pasticciare con le proprie mani.
Quanto a wizzard e RAD vari, per quanto complessi, non vanno oltre
le poche cose generalizzabili (tipicamente l'interfaccia grafica), ma
ogni applicazione ha delle sue peculiarita` che non sono legate
solamente alla natura del problema. Tali stumenti non hanno nessuna
creativita` e lo sviluppo delle applicazioni e` fondamentalmente
un processo creativo della mente umana.
Quando uno wizzard o un RAD ti impongono una certa visione,
sei costretto a organizzare il tuo progetto di conseguenza...
Che tu ci creda o meno, non e` cosi` che si fanno le cose quando
un certo lavoro nasconde creativita` (i programmi non sono
tutti uguali, neanche nell'abito della stessa tipologia di problema
da risolvere).
Non che tali strumenti siano inutili, ma come tutte le cose hanno i
loro limiti e la comprensione di tali limiti e` legata alla formazione
di chi utilizza tali strumenti.


adatto all'applicazione da realizzare?
Perche' per poter fare questo e' richiesta una padronanza di mezzi e tecniche
che pochi si possono permettere. Non a caso quelle (quella?) che ha  piu' di successo
e' la combinazione di VB e VC++, che vengono dalla stessa casa e sono fatte
in modo da completarsi a vicenda.

quanto inevitabile.
Potrei aggiungere che pero' le ore di lavoro spese a correggere progetti
sbagliati costano ancora di piu'; e non c'e' clock che tenga.

 a "favore" dei framework. Con sguardo critico.
Temo che trovare chi, anche in progetti seri, sia 'realmente interessato
alla qualita' del SW' si dimostri sempre piu' come trovare la pentola d'oro
dove nasce l'arcobaleno. Almeno in Italia.
MM

 a "favore" dei framework.
Io anche sono a favore dei framework. L'importante è che siano ben fatti
e coerenti dal punto di vista OOP e che comunque permettano di scendere
di livello quanto necessario.
EMG


-- 
Valter Minute - 
min...@fortech.it
 (the reply address of this message is 
invalid)
--
Are you looking for a good freeware ScreenSaver? Try FOYD!
http://hotfiles.zdnet.com/cgi-
bin/texis/swlib/hotfiles/getit.bin?fcode=000PZ0
if you want, I can send you the (free) C++ source code.

Intendiamoci, non sto dicendo che per fare le cose in fretta bisogna usare
solo i wizard e il resto scriverlo da schifo!
Certo la manutenibilità del SW va tenuta sempre in considerazione, ed è bene
cercare comunque di dare della "buona" programmazione, dico solo che alla
fine capita spesso di dover inserire ANCHE "sporcizia" nel codice.
Bisogna vedere quanta "sporcizia" si mette mediamente nella versione
definitiva. Se i tempi sono strettissimi e magari non si prevede di
riprendere in mano il lavoro in futuro (o almeno in tempi brevi)
probabilmente il codice farà schifo. Ciò non toglie che è possibile
migliorarlo quando l'urgenza è passata, indipendentemente dalle richieste
del cliente e magari solo per esercizio.
Inoltre come al solito l'esperienza aiuta: se in passato mi sono già posto
il problema di scrivere codice "pulito", sarò in grado di farlo ancora per
situazioni simili, al limite con un taglia-incolla. La sporcizia di solito
si accumula dove non si passa mai...
--
Alessandro Monti

 e' la combinazione di VB e VC++, che vengono dalla stessa casa e sono
fatte
Beh, non è certo l'unica. Anche Borland ha sempre seguito questa strada,
Java ha meccanismi simili (i metodi "nativi" e altro), e i vari COM, DCOM,
CORBA et similia pure.
E non mi sembra una cosa brutta, anzi.
E la padronanza di mezzi e tecniche non è una scusa. Anche perchè se usi un
set di linguaggi per parti diverse dell'applicazione, non hai necessità di
conoscere a fondo tutto il linguaggio.
Parlando in concreto (così il discorso diventa forse più chiaro), io uso il
Visual FoxPro per la gestione dei databases e l'interfacciamento ai DBMS
perchè è lo strumento migliore per farlo, sviluppo anche l'interfaccia
utente con questo linguaggio, anche se i risultati non sono proprio
soddisfacenti (simile al VB e forse inferiore), per pigrizia, ma uso il
C/C++ per tutti gli altri scopi, realizzando DLL ad hoc.
Per cui, da un lato non ho ancora avuto necessità di usare le MFC, tranne
che per qualche cosettina che era veramente troppo comoda, che pertanto non
conosco, dall'altro non ho idea di come FoxPro si comporti in campi come:
manipolazione di stringhe, array, strutture di dati dinamiche, gestione
delle risorse a basso livello, ecc.
Che poi tante cose le abbia lo stesso voluto vedere e provare per mio
interesse personale, non cambia il discorso. La gestione degli array in
FoxPro è un'agonia, ma a che serve usarli? Idem per i database in C++.
Ovvio che tutto ricade ancora sulle spalle del programmatore: se ha voglia e
tempo può imparare cosa sia davvero la programmazione, la novità è che
adesso può anche non farlo. (Frase da prendersi con le dovute "pinze")
Per tornare al caso di prima, è senz'altro possibile realizzare una buona
interfaccia con i databases in C++, ma lo sforzo è enorme e IMHO il
risultato non lo giustifica. (e spero nessuno mi parli di RDO, ADO, ecc.)
--
Alessandro Monti


++EsattoCount :-)
[...]


resto dell'applicazione.
Se mi consentite di riprendere il pensiero di B. Stroustrup, information
hiding non vuol dire nascondere il modo in cui le cose sono state fatte,
ma dare la possibilita` di fare a meno di tali conoscenze. Ad esempio
se mi serve una lista, a me non importa sapere se e` implementata
con un array o tramite puntatori, al piu` mi e` sufficiente sapere
il costo delle operazioni sulla lista (ad esempio in una lista con array
l'inserimento potrebbe costarmi O(1), mentre l'estrazione O(n), con
una lista linkata i risultati potrebbero essere opposti).
In sostanza l'information hiding non e` un concetto assoluto, ma
relativo ad un certo livello di astrazione.


 il discorso cambia di parecchio :-)
Beh, quanti clienti hai che devono installare il tuo programma su 1000 PC?
Io al massimo arrivo ad una cinquantina, e ti assicuro che gli aggiornamenti
sono possibili.
E poi un cliente che ha 1000 PC credi che abbia solo "scatoloni"?
Probabilmente ha dei tempi già fissati per il cambio del parco macchine
(tipo 50-100 all'anno), e mentre scrivi il programma ha già cambiato
parecchi PC aggiornandoli ai nuovi modelli.
Comunque, tornando a quel mio amico, non so su quanti PC giri il suo
programma in VB (che ti assicuro è mastodontico), ma si tratta di
installazioni su punti vendita di grandi aziende che operano in Italia,
States, Giappone, che so per certo, per cui non credo siano pochi, e gli
vabenissimo così.
Dopotutto anche il VB, dopo la prima decina di mega, produce codice
abbastanza compatto e abbastanza efficente.
Ripeto: nel mio piccolo ho notato che in termini di resa tempo/guadagno,
vale sicuramente la pena di usare tutto ciò che può velocizzare il lavoro,
anche di poco. L'unico motivo per cui vale la pena di sbattersi per produrre
"buon" codice è la manutenibilità, che sia preventivata o meno. Poichè le
cose sono in antitesi, mi sembra ragionevole trovare un buon compromesso se
il tempo è una delle priorità (e spesso è l'unica, ma tu mi dici che sei più
fortunato).
Non voglio entrare nel merito di altre situazioni, io mi riferivo solo a
quelle IMHO più ricorrenti. (per la mia modesta opinione, per chi non
conosce la sigla)
--
Alessandro Monti

resto dell'applicazione.
E' quello che intendevo dire.


dove nasce l'arcobaleno. Almeno in Italia.
Perché, in Italia si sviluppano progetti seri? LOL
In Italia c'è ancora poca cultura informatica (eccezioni escluse).


lavorarci col programma, non rigirarselo tra le dita.
Non puoi mettere tutto nello stesso fagotto. I clienti stessi hanno obiettivi
diversi. Certo, se ci limitiamo ad una certa realtà, posso condividere. Ma in
genere le esigenze sono diverse. L'utente di un GIS (Geographic Information
System - se non erro l'acronimo) ha esigenze diverse rispetto alla ditta che ti
chiede sw per l'automazione industriale che, a loro volta, hanno priorità
diverse rispetto al sw in ambito biomedicale. Non cito neppure i gestionali che
sono ancora totalmente diversi da tutte le precedenti tipologie.


si accumula dove non si passa mai...
Hummm...
??? Si accumula, imho, dove si passa troppo spesso, invece! In fin dei conti una
routine che è corretta non ha bisogno di modifiche. Tendi a lavorare sulle parti
che hanno problemi o sono incomplete.
Comunque non condivido la premessa secondo la quale il codice "si può pulire" in
un secondo tempo. Buon codice deriva da buon design (chi l'ha detto? non
ricordo). Se il design è stato progettato accuratamente, molto del codice
tenderà ad essere sviluppato in modo naturale, armonioso direi. Quando sto
infarcendo il progetto di patch e rattoppi vari, 99 su 100 c'è un problema di
design. E cambiare il design a progetto sviluppato a tali costi che nessuno può
permettersi di farlo. Per questo non credo si possa migliorare molto il codice
in un secondo momento.
Questa, almeno, la mia opinione.


 hiding non vuol dire nascondere il modo in cui le cose sono state fatte,
Personalmente non mi riferivo all'information hiding, semmai alla
documentation hiding e source-code hiding.
Se uso una libreria che mi gestisce le liste, mi sta bene che
l'implementazione sia nascosta al momento della stesura del mio codice, ma
vorrei anche:
a) poter in qualche modo gestirmi le liste da solo (ovviamente in C++ è
possibile, ma altre cose possono essere totalmente nascoste)
b) eventualmente, dare una "sbirciatina" al sorgente delle librerie giusto
per essere sicuro che facciano ciò che mi aspetto senza dover essere
costretto a fare 10'000 programmini di test. (cosa che invece devo fare ogni
volta che malauguratamente mi viene in mente di usare un controllo fornito
da terze parti)
--
Alessandro Monti


Su questo non sono d'accordo, credo che scegliere bene i tool che ti fanno 
risparmiare _davvero_ tempo è fondamentale.



Non era questo quello che intendevo...
Permettimi di sfruttare il tuo esempio per chiarire/rmi le idee...
io sono ben contento di avere una classe lista già implementata e, se 
questa soddisfa i requisiti della mia applicazione (funzionalità e 
performance) non mi sogno nemmeno di vedere come è implementata a "basso 
livello") ma voglio essere sicuro che se, ad esempio, mi accorgo che la 
lista "impazzisce" se inserisco un elemento in coda e lo rimuovo 
immediatamente, possa andare a verificare esattamente dove si verifica 
l'errore e risolverlo senza dover sconvolgere il programma per poter 
supportare un altra classe lista "preconfezionata" implementata in modo 
diverso e senza quel bug!
Intendevo solamente dire che è importante avere i mezzi per poter 
controllare anche le librerie o gli oggetti sviluppati da terze parti che, 
per velocizzare lo sviluppo, ho inserito nel mio codice. Avere a 
disposizione il codice sorgente di una libreria (specie nel caso di 
librerie "critiche" per il funzionamento dell'applicazione) è un "bonus" a 
cui preferisco non rinunciare.


"Valter Minute" <min...@REMOVEMEfortech.it> wrote
: Intendevo solamente dire che è importante avere i mezzi per poter
: controllare anche le librerie o gli oggetti sviluppati da terze parti che,
: per velocizzare lo sviluppo, ho inserito nel mio codice. Avere a
: disposizione il codice sorgente di una libreria (specie nel caso di
: librerie "critiche" per il funzionamento dell'applicazione) è un "bonus" a
: cui preferisco non rinunciare.
Indubbio vantaggio.
I framework, quasi per definizione, vengono forniti con i sorgenti allegati
(di alcuni vengono forniti solo i sorgenti).
Avere, invece, i sorgenti di librerie e' generalmente costoso (molto,
costoso).
In genere, il vantaggio di avere tali sorgenti e' legato all'importanza del
progetto ed alle risorse disponibili (leggi soldi). Non tutti si trovano
nella condizione di poter avere questi sorgenti. Sei fortunato.
MM

si accumula dove non si passa mai...
Questo' e' certamente vero. Voglio dire, un programmatore COBOL con trent'anni 
di esperienza da soluzioni standard a problemi standard - portandosi dietro 
maree di difetti che alla fine non e' neanche piu' in grado di vedere. Solo 
"risolvere" non basta - puo' essere cattiva esperienza. Risolvere "bene" e' 
buona esperienza. E la differenza si vede.
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

 Parecchi.
Intendi lo stesso cliente con 1000 PC, non 1000 clienti con 1 PC ciascuno?
Ma che programmi fai? (se non sono indiscreto)
Il mio discorso era riferito a SW ad hoc, per aziende medie (in particolare
ASL, forse per questo un po' di spesa in più non è un problema).
Comunque la chiaccherata mi sembra interessante. Forse non è uno dei tools
per velocizzare il lavoro ;-)
--
Alessandro Monti

 nella condizione di poter avere questi sorgenti. Sei fortunato.
Non distribuire i sorgenti, vuole dire che ad ogni bug che viene scoperto,
dimezzi il numero dei clienti della libreria.
Per cui, o la libreria è talmente irrinunciabile/testata/efficente da
potersi vendere e utilizzare comunque, altrimenti non è neanche il caso di
metterla in commercio.
Questa è una specie di "garanzia" che dovrebbe accompagnare le librerie a
pagamento. E in effetti quelle che hanno davvero successo di mercato sono
pochine.
In generale usare una libreria vuole dire abbandonare ogni speranza di
velocità a favore di uno sviluppo rapido.
Se comunque le prestazioni sono soddisfacenti (e di solito lo sono, per i
motivi di cui sopra), val la pena di usarle.
Avere i sorgenti invece è anche una questione di avere la garanzia che, in
caso il produttore decidesse di non supportare più la libreria, non mi
toccherà riscrivere l'intera applicazione, per cui penso possa essere
considerato un buon investimento, nei casi in cui questo è utile.
Ovviamente non sempre è conveniente: faccio l'esempio di una libreria di
crittografia.
Avere i sorgenti sarebbe senz'altro utile, se non altro per assicurarsi che
non ci siano "punti deboli" ammesso che si riesca a capire il codice. Per
contro, potrebbe essere semplicissimo cambiare libreria e/o algoritmo di
crittografazione in un secondo tempo. Questo almeno è quello che è capitato
a me, con esigenze di sicurezza non pressanti (ma comunque ISO9000) e
limitate all'accesso del programma e relative PWD. L'alternativa di
scriversi il codice ad hoc, avrebbe certamente aumentato estensibilità,
manutenibilità ecc, ma abbassato notevolmente la sicurezza.
--
Alessandro Monti

 wrote in message
news:_bKI3.12118$nP6.1...@typhoon.libero.it...
: > In genere, il vantaggio di avere tali sorgenti e' legato all'importanza
: del
: > progetto ed alle risorse disponibili (leggi soldi). Non tutti si trovano
: > nella condizione di poter avere questi sorgenti. Sei fortunato.
: Non distribuire i sorgenti, vuole dire che ad ogni bug che viene scoperto,
: dimezzi il numero dei clienti della libreria.
: Per cui, o la libreria č talmente irrinunciabile/testata/efficente da
: potersi vendere e utilizzare comunque, altrimenti non č neanche il caso di
: metterla in commercio.
Sicuramente abbiamo avuto esperienze diverse riguardo alle librerie, sia per
il settore in cui sono applicate sia per come ne viene definito il successo.
Ho avuto modo di utilizzare librerie, senza alcuna possibilita' di
acquistarne i sorgenti, che hanno manifestato, a volte, bug (comunque
corretti in seguito). Non per questo mi e' stato facile cambiare librerie
(vedi ridisegnare le applicazioni) e non per questo le librerie sono uscite
dal mercato.
MM


Credo che aggiornarsi e confrontarsi sia una componente fondamentale del 
nostro lavoro (e quando smetterà di esserlo vedrò di sfruttare la patente 
"C", tanto per cambiare... :-))


documentation hiding e source-code hiding.
Ma e` proprio cio` di cui si parla, chiamala pure source-code
hiding, ma alla fine sempre information hiding e`!
Quella che poi tu chiami documentation hiding io la chiamo un grave
difetto del framework che vorrei/dovrei utilizzare. La documentazione
non rientra tra le cose che vanno nascoste.


cui preferisco non rinunciare.
Non posso che essere d'accordo con te, ma questo era un punto che
davo per scontato. D'altronde non ho mai visto un framework
totalmente documentato e spesso avere il codice fa la differenza
tra il riuscire ed il fallire.


 buttare via.. perche' alla fine nessuno butta via niente. :)
 Una considerazione: se scrivere un prototipo mi costa solo qualche
giornata, posso avere il lusso di concentrarmi proprio sul design, invece
che sul codice. Se la scelta a livello di design (o architettura, o come si
vuole chiamare) è buona, sarà poi più facile scrivere del "bel" codice. Se
invece mi perdo già nell'analisi, figuriamoci poi come sarà il codice. In
questo mi sembra che i RAD diano un bell'aiuto. Ovviamente da soli non
bastano, almeno finchè anche l'intelligenza non sarà assistita da wizard :-)
--
Alessandro Monti

 sono ancora totalmente diversi da tutte le precedenti tipologie.
Scusa, devo aver visto tardi questo messaggio.
Ho specificato, forse tardi, che mi riferivo sostanzialmente a gestionali
realizzati per piccole-medie aziende,
quindi progetti fortemente standardizzati.
Avevo forse detto però che una delle specifiche più importanti (non di rado
l'unica), dovesse essere il tempo di sviluppo.
--
Alessandro Monti

Secondo me, tutte queste osservazioni sulla comodita'/necessita'
di avere i sorgenti delle librerie per poter verificare cosa fanno riflettono
solo il fatto che in genere il problema di scrivere delle librerie e' mostruosamente
sottovalutato.
Innanzitutto, e' dovere del fornitore fornire le specifiche precise di cosa fa la libreria,
ed e' LUI che deve verificare che il suo codice faccia quanto dice la documentazione.
Non devo essere io che la compro a debuggargliela.
E' anche vero purtroppo che in molti casi cio' non succede, e questo rispecchia
semplicemente il fatto che scrivere una buona libreria e' una delle cose piu'
difficili che possono capitare. La difficolta' viene dal fatto che il domino in cui
una libreria puo' venire utilizzata e' completamente aperto, e questo e' molto
diverso dallo scrivere una applicazione, il cui dominio e' chiuso.
Il problema piu' tipico che si incontra con le librerie e' che uno delle miriadi di
utilizzatori riesce a creare qualche contesto in cui la libreria non riesce a rispettare
le proprie promesse. Questo puo' avvenire principalmente per due motivi:
- l'utilizzatore ha frainteso, o non ha inteso a fondo, la documentazione della
  libreria, ammesso che questa sia ovviamente esaustiva. In questo caso 
 naturalmente il problema e' dell'utente
- l'altro e' che la documentazione, appunto, non sia sufficientemente completa,
  lasciando spazio ad interpretazioni personali, e qui il problema e' del fornitore.
Da qui nasce il desiderio/necessita' di avere i sorgenti, ossia
-  per controllare che io non ho frainteso la documentazione, e
- per verificare che la libreria stessa rifletta la sua stessa documentazione
Quindi le problematiche sull'uso delle librerie stanno da entrambi i punti di
vista, con pero' una responsabilita' molto piu' grande da parte del fornitore.
Non prendete mai sottogamba il problema di realizzare una libreria, si tratta
di un compito molto difficile.

 Non devo essere io che la compro a debuggargliela.
Certamente, ma come le scrivi le specifiche?
Per essere certo di essere sufficentemente preciso dovresti usare un qualche
linguaggio formale, e a parte che non mi risulta che ne esistano di
abbastanza generali, aumenteresti la probabilità di una mancata comprensione
da parte dell'utilizzatore, che oltre a dover sapere il linguaggio di
programmazione deve conoscere bene anche il linguaggio di specifica.
Forse avere i sorgenti è più facile.
Sono d'accordo sul resto del discorso, fare una libreria è una bella
responsabilità.
--
Alessandro Monti

Ho fatto un po' di confusione; quando scrivevo specifiche intendevo in realta'
la documentazione d'uso, maledetta arteria.
La documentazione, dicevo, puo' e deve essere scritta in modo non ambiguo.
Se uno non riesce a documentare chiaramente cosa fa la sua libreria, vuol
dire che' e' fatta troppo male.

 che sul codice.
Vero ma... quando succede? :) Voglio dire, quante volte hai realmente
buttato via tutto tutto dopo aver fatto vedere la cosa ai committenti?
E poi di un sistema minimamente complesso, costruire un prototipo richiede
ben piu' di qualche giornata. Certo, poi costruire un piccolo pezzo di GUI
(in gneere, i menu e piccole dialog, perche' quelle grosse vanno "pensate"
portano via un sacco di tempo anche disegnandole coi RAD).. ma appena ci
vuoi mettere un minimo di logica (anche far si' che premendo un bottone si
apra una dialog) gia' i tempi diventano.. quelli di codifica. :)

 dire che' e' fatta troppo male.
Oppure che non è riuscito completare la documentazione. Ci vuole
veramente un sacco di tempo...
EMG

 apra una dialog) gia' i tempi diventano.. quelli di codifica. :)
Perfettamente d'accordo. Anzi, ti dirò che io, dopo aver organizzato
molto bene il lavoro (nei limiti delle mie capacità ovviamente), trovo
che l'unica cosa che è rimasta veramente lenta è il disegno delle
maschere...
EMG

 apra una dialog) gia' i tempi diventano.. quelli di codifica. :)
Beh, questo è vero in C/C++.
Con i RAD veri, sono tutte operazioni velocissime. Per aprire una finestra o
un menù di solito basta una "do ...".
Le cose complesse richiedono certo più tempo, ma la cosa comoda dei RAD "ad
oggetti" (scusate il termine) è che è possibile incapsulare nelle finestre
degli oggetti "non visuali" che si occupano della parte "businness" e che
sono usati dai vari pulsanti.
La codifica avviene prevalentemente lì (sempre meglio che "dentro" i
pulsanti); non trovo molta differenza con l'usare altri tipi di astrazione,
e in più ho la possibilità di "trascinare" il codice all'interno delle
finestre che lo usano. Se poi si vuole mettere in discussione la velocità di
sviluppo "visuale" rispetto a quella "manuale", il discorso diventa più
complesso.
Le applicazioni "grosse" invece rischiano IMHO di diventare facilmente più
complesse con i RAD che non in altro modo, ma almeno una prima "sgrossata"
la possono dare. Tutto sommato credo che fare la finestra principale e
qualche dialog non troppo specializzata di un'applicazione complessa grazie
ai RAD porti via poche risorse e "controllo" nelle parti più critiche.
Parla però uno che non ha mai dovuto avere a che fare nemmeno con MFC per le
applicazioni "banali" che mi sono trovato a realizzare, per cui non vorrei
estendere la mia opinione a progetti di natura profondamente diversa.
--
Alessandro Monti

maschere...
Si, concordo. In genere io stimo da mezza giornata a due giorni/uomo per 
dialog, a seconda della complessita' - e solo per il *disegno*.


 sbagliati costano ancora di piu'; e non c'e' clock che tenga.
Non solo, ma esistono moltissime applicazioni pratiche dove errori
concettuali spostano la complessita' di calcolo da un andamento
polinomiale ad uno esponenziale, e questo non c'e' miglioramento
dell'hardware che possa risolverlo!
Ciao,
Nicola Musatti

 di chi utilizza tali strumenti.
Sacrosanta verita, e come tale ignorata dai piu' :-)
Ciao,
Nicola Musatti

 successo questi qua...
Io sono uno di "quelli la'" che si occupa di gestionali e quindi di
problemi (secondo te) banali dal punto di vista informatico. Ebbene. Non
ho affatto il successo (commerciale) che dici e poi:
1. I problemi non sempre sono semplicissimi.
2. Spesso la semplicità è controbilanciata dalla quantità.
3. Per ottenere applicazioni decentemente efficienti è necessario anche
saper sfruttare molto bene lo strumento che si usa.
4. Anche i progetti semplici possono essere affrontati con criteri di
buon design e di buona programmazione.
E poi, mi faresti un esempio di quelli che tu reputi programmi
"complessi"? Tanto per avere un'idea di cosa stai parlando...
EMG

 "complessi"? Tanto per avere un'idea di cosa stai parlando...
Ho partecipato ad un progetto per la realizzazione di un sistema di
gestione di piani di configurazione di reti GSM e di valutazione della
loro efficacia. Ogni piano contiene la configurazione di migliaia di
stazioni di rete, ciascuna delle quali composte di decine di "oggetti"
piu' semplici, a loro volta caratterizzati da un numero variabile di
parametri configurabili. I problemi erano legati alla rappresentazione
grafica/geografica delle informazioni, alla memorizzazione delle
configurazioni su DB ed all'interscambio di informazioni con altri
sistemi.
Oppure, ma questi li ho solo visti usare, non ho partecipato alla loro
realizzazione, diversi applicativi usati nell'esplorazione petrolifera:
cinque anni fa l'elaborazione dei dati relativi ad un'area di qualche
chilometro quadrato impiegava diversi giorni di CPU di un supercomputer
Cray.
Ciao,
Nicola Musatti

occorre molto poco di altro.
Come gia` detto, basta saper scegliere il mezzo piu` adatto...
Per applicazioni di questo tipo probabilmente sceglierei delphi
o comunque mi farei aiutare da un RAD, intervenendo manualmente
soltanto nelle parti critiche dell'applicazione.
Se poi sei abituato ad affrontare problemi complessi (o comunque non ti
spaventano) credo che cose di questo tipo le si riesca a risolvere
relativamente in poco tempo.
E` cmq una opinione personale per'altro non suffragata da
sufficiente esperienza.


Caro Nicola, ho letto con molto interesse i tuoi posting, e condivido
pienamente le tue osservazioni.
Una cosa che posso agiungere e' che spesso anche i clienti
contribuiscono al dilagare di applicazioni approssimative.
Direi che l'impegno che uno sviluppatore medio mette nello sviluppo delle applicazioni e' 
in buona misura proporzionale alla "qualita' " del cliente. Ci sono
clienti che non vogliono sapere nulla su come i loro problemi vengono
affrontati e risolti, ed altri che invece partecipano attivamente e
sono abbastanza competenti da stimolare un impegno piu' profondo.
Non che con questo voglia dare addosso ai clienti, non sono tenuti 
piu' di tanto ad occuparsi di certe cose, ma anche loro non farebbero poi male
a preoccuparsi un po' di piu' su come spendono i loro soldi. Questo non 
dovrebbe essere difficile, perche' il cliente, per poco che sappia, comunque
ha una conoscenza discreta, se non buona, del problema; ma per qualche 
motivo questa conoscenza viene trasmessa spesso in modo frammentario e
incompleto, per cui gli sforzi dello sviluppatore si moltiplicano. Insomma, se 
noi sviluppatori ci sentiamo autorizzati a considerare ignoranti i clienti (piu' o
meno a ragione), anche loro sono autorizzati a pensare altrettanto. Non fornire
le informazioni necessarie porta a prodotti che stanno insieme con zeppe e
puntelli, e nessuno ha nulla da guadagnare in tutto questo.
Mi rendo conto che questo e' un discorso piuttosto spinoso, perche' i limiti 
dell'interazione tra cliente e sviluppatore non sono ben definiti e variano di
molto a seconda dei casi, pero' credo che la linea generale del discorso
abbia un suo senso: il cliente e' parte integrante di un progetto, e spesso 
non se ne capacita a sufficienza.

 sufficiente esperienza.
I problemi sono diversi, non più semplici. Credo che troveresti delle
sorprese. Almeno ne trovo sempre io :-(
Cosa ne pensi di un'analisi che viene scartata per poi procedere senza?
Pensa che questa è stata una richiesta esplicita del committente, che voleva
anche che i sorgenti che fossero in un particolare modo: brutti.
Salvo poi stupirsi dei risultati quando si riusciva di nascosto ad infilare
qualcosa fatto bene...
--
Alessandro Monti

Sono completamente d'accordo. Aggiungerei solo che l'insufficiente
attenzione del cliente e' indipendente dalla portata del progetto, cioe'
gli stessi problemi li trovi sia sviluppando il gestionalino per il
negozio all'angolo che collaborando a progetti di centinaia di anni/uomo
e molti miliardi di costo.
E forse e' piu' comprensibile il negoziante dell'angolo che non il
dirigente del grosso progetto...
Ciao,
Nicola Musatti

un menù di solito basta una "do ...".
Certo, ma  quel "do" *e'* esattamente la codifica. :) Moltiplicala per ogni 
bottone e ci perderai ore.. :) Se poi devi aggiungere un minimo di logica 
ulteriore (del tipo - il bottone e' abilitato o meno, etc), ale'. 
Il punto e' che anche scrivendolo a mano, il codice non e' molto diverso (come 
dici, la produttivita' dipende dal linguaggio: anche scrivere "Hello world" e' 
piu' *veloce* in VB che in C++, ad esempio). Ma e' la *logica* di cui il codice 
e' implementazione ad essere complessa. E qui il RAD non aiuta. Aiuta solo dove 
la logica e' assolutamente standard, come ad esempio nel codice che gestisce i 
menu'.


 non se ne capacita a sufficienza.
C'è chi ha proposto che insieme a cliente e sviluppatore ci sia uno
psicologo :-))
La questione non è banale, soprattutto se anche il cliente ha una solida
preparazione nella sua materia o una lunga esperienza nel suo settore, e non
si rende conto che le cose banali pel lui non lo sono per gli altri. Il
programmatore, dal canto suo, dà per scontate tantissime cose, che il
cliente potrebbe non conoscere (e non voler conoscere). Le due cose insieme
sono un intruglio percolosissimo.
La classica domanda di qualche amico è:
"Ho trovato un programmino che fa al caso mio, tranne che per qualche
cosetta da niente. Tu che sei programmatore non potresti modificarlo?"
Ovviamente è solo un esempio banale, ma credo indicativo del fatto che la
visione della programmazione può essere molto diversa a seconda delle
competenze.
--
Alessandro Monti

anche che i sorgenti che fossero in un particolare modo: brutti.
Questo non e` un problema, un capitello qua, una colonna la... :)
Ma che non si aspetti piena aderenza alle specifiche!


competenze.
Ecco la parola chiave: competenze
Bisogna saper distinguere ruoli e competenze!


 Ma che non si aspetti piena aderenza alle specifiche!
Certamente no, dato che non esistono :)
Per dirla tutta, mi basta avere i miei soldi, poi possono chiedere quello
che vogliono.
E chiamare un altro per la manutenzione :-))
--
Alessandro Monti