[MontelLUG] Vista funziona! E anche bene!

[Samuele Zanin]

Scusate se rispondo solo adesso, ma da casa è un casino con internet,
intanto rispondo alle mail arrivate fino a venerdì.
Poi vi è andata bene che ieri sera avevo risposto punto per punto, ho
salvato la mail ma non si è salvata, e adesso rispondo molto brevemente.
Davide Rondini wrote:
> Alle 17:47, mercoledì 15 agosto 2007, Samuele Zanin ha scritto:
>> Adesso scateniamo un bel flame :-).
>
> Questo l'ho notato anche io, ma sarei piuttosto restio a pensare che
> un gestionale sia una killer app per Linux.
Non dico che sia un'applicazione fondamentale per linux, quanto il fatto che
nelle aziende proliferano tutta una serie di programmi più o meno
personalizzati che vanno dal controllo di produzione alla contabilità
passando per il magazzino. Nelle aziende che conosco la maggior parte di
essi è sviluppata sotto win. L'utente se al lavoro è abituato ad usare win,
a casa non vorrà vedersi linux. Tieni conto che la maggior parte degli
utenti di pc, ad esclusione di quelli usciti dalle scuole negli ultimi anni,
ha avuto il primo approccio con il pc sul posto di lavoro.

> Se si parla di C/C++ la tua sensazione corrisponde di sicuro alla
> verità, e non vedo il senso all'esistenza di progetti alternativi.
> gcc funziona bene, implementa perfettamente gli standard ANSI e
> POSIX, genera codice veloce.

Neanche io vedo la necessità di progetti alternativi, creerebbero solo più
caos.

> Non ho mai sviluppato un gestionale, ma limitare l'usi del C/C++ a
> cose di basso livello è sinceramente un pregiudizio che si sente
> spesso, ma a mio parere del tutto ingiustificato. La gestione della
> memoria è una rogna, è vero, ma quando mio fratello mi ha spiegato
> per sommi capi come ad esempio Java gestisce certe cose, ti giuro che
> ho rimpianto i puntatori.

Io conosco bene il C, al C++ ho dato solo un'occhiata quando ero infognato
nei programmi C e cercavo un'alternativa. In seguito ho chiesto
delucidazioni a chi diceva di conoscerlo riguardo ad alcuni aspetti critici
che avevo con il C e mi è stato confermato che continuano ad esistere in
C++.

Dalla mia esperienza in 3 software house diverse, sviluppare un gestionale
significa:
a) partire con lo sviluppo una settimana dopo la data di consegna;
b) in alcuni casi ti trovi un'analisi di 110 ore contenuta su una pagina A4
scritta con Arial 12;
c) quando consegni il programma al cliente di norma c'è sempre qualcosa che
chi ha fatto l'analisi non si è capito con il cliente ed è da rifare, a
volte anche con modifiche pesanti. Quando va bene manca solo qualche
funzionalità;
d) il cliente dopo qualche giorno di utilizzo ha subito in mente nuove
implementazioni, il fatto che queste a volte implichino il ribaltare la
logica del programma ha poca importanza;
e) "Questo programma ha eseguito un'operazione non valida e sarà terminato.
Se il problema persiste contattare il fornitore del programma." non è un bel
messaggio che compare a video dopo che uno ha caricato un centinaio di righe
di bolla e preme il pulsante per registrarla;
f) ultimo ma molto importante: i dati che vengono scritti sul database sono
SACRI, quindi una stampa che mentre stampa i dati li cancella anche
dall'archivio a causa di un buffer overflow non è cosa carina.

La mia esperienza personale di lavoro ad un gestionale in C Ansi (no C++ in
quanto doveva essere retrocompatibile con alcuni dinosauri UNIX) è stata
decisamente traumatica. In quei 14 mesi ho visto più clienti incazzati,
casini e perdite di dati che in 7 anni dove lavoro adesso (qui nessuno
finora ha mai perso un dato per colpa del programma).
Lo so che se un programma ha un problema è colpa del programmatore, però
devi anche ammettere che dopo 8/9 ore passate davanti ad un monitor,
alternando 10 minuti di sviluppo a mezz'ora di assistenza telefonica, ad un
certo punto il cervello va anche a quel paese, quindi dimenticarti un &
oppure qualche sostituzione di variabile in un copia incolla di massa può
succedere.
Quindi avere un compilatore che non fa un minimo di controllo sui tipi di
dati nel passaggio di parametri a funzioni oppure in caso di assegnazioni in
pezzi di codice dove usi un puntatore a stringa ogni volta di dimensioni
diverse ogni tre righe di codice, non è di aiuto.
Se poi ci aggiungi il fatto che devi sviluppare il più rapidamente
possibile, che non appena il programma supera un minimo di test è già
consegnato al cliente e che a volte devi fare copia e incolla di massa per
ribaltare la logica, penso tu possa capire quanti casini vengono fuori in
quei programmi.
Per me il successo di programmi come COBOL, Clipper/dbIV, Vb e Delphi è
dovuto al fatto che una volta compilato sei sicuro che il programma esegue
quello che hai scritto. Se il programma non fa quello che ti aspetti è
perché c'è un errore di logica e non perché un'assegnazione a una variabile
ha modificato il valore della variabile adiacente in memoria, oppure
un'azzeramento di stringa è andato a sovrascrivere una parte di memoria dove
c'è il codice eseguibile e quindi l'eccezione ti viene sollevata da un'altra
parte del programma che non ha niente a che fare.
Ti dico, in quei 14 mesi ne ho viste di tutti i colori e non mi sono
scottato, ma ho riportato ustioni di 3° grado.
Senza contare le opzioni di ottimizzazione del compilatore. Mi avevano detto
che quando dovevo consegnare il programma al cliente era bene compilarlo in
modalità release (più veloce e compatto). Poi dopo che al cliente si blocca
il programma in fase di fatturazione e questo chiama diretto il tuo capo, il
quale si mette a strillarti dientro (con tutte le porte degli altri uffici
del piano che magicamente si chiudono sincronizzate) senza sentire ragioni,
poi scopri che mentre la versione compilata in debug funziona, mentre quella
in release va in eccezione e non si capisce il punto, stai certo che dopo la
prima volta non ho più consegnato programmi compilati in release, ma in con
tutte le informazioni di debug incluse, e se il programma è troppo pesante
che il cliente si prenda un pc più potente.

Poi se uno si può permettere di scrivere il programma in un ambiente dove
chi è addetto allo sviluppo fa solo quello, le date di consegna sono umane,
oltre a te ci sono anche altre persone che fanno i test, il codice è scritto
secondo sani principi di programmazione strutturata e non da profondi
estimatori dei goto, allora ti posso anche credere se dici che il C può
andare bene anche per altri tipi di applicazioni.
Alla fin fine, un gestionale lo puoi anche scrivere in assembler, nessuno te
lo vieta, ma vienne fuori poi.

Purtroppo almeno nel compilatore di visual studio 5 che usavo oppure sul cc
di Sco Unix 5.x non mi risultava ci fosse un'opzione per fare il range
checking delle variabili e altri controlli simili.

> Ah, conosci wxWidgets? In caso negativo, preparati al mio talk per le
> conferenze autunnali :-)

No, ho usato solo librerie proprietarie vecchie più del cucco.

>
> La portabilità è una bella gatta da pelare: in pratica si hanno poche
> alternative se si vuole mantenerla:

Concordo.
L'ideale sarebbe wine.

> Questa poi io la trovo una affermazione arbitraria: io da
> sviluppatore devo ancora trovare una attrattiva che mi induca a
> sviluppare _anche_ per Windows. Visual Studio è brutto, sporco e
> cattivo, soprattutto se tenti di lavorare con cose portabili o quasi.
> Ci sono 853 modelli di programmazione, linguaggi, estensioni M$ agli
> standard incompatibili tra loro. E la cosa più fastidiosa è che è
> tutto documentato con i piedi, non si reperisce un'info neanche a
> pagarla oro.
Io non dicevo che mi trovavo bene con visual studio.
Per me sotto DOS (ci ho programmato pochino) mi trovavo bene con Clipper 5.2
della Computer Associates, sotto windows con Delphi della Borland (che fa
ottimi compilatori/ide, ma ha pessimi commerciali e/o responsabili
marketing).
Nel mio caso, la VCL di Delphi è molto ben documentata dall'help in linea,
inoltre sono inclusi circa il 90% dei sorgenti di cui è costituita (mancano
le unit di alcune routine di basso livello e i sorgenti del Bde).
Praticamente se hai un problema puoi debuggare fino alla chiamata delle api
di windows, capire dove è il problema e come aggirarlo, senza contare che a
leggersi quei sorgenti si vedono tante belle robette.
Mi è capitato qualche volta mettere mano ad un programma scritto in VC++ con
MFC. Mi sono fatto tre volte il segno della croce par dritto e par storto.
Non so se dipendeva da come era stato implementato il programma, ma abbiamo
dovuto modificare delle query per aggiungere dei campi, siamo andati avanti
mezz'ora a modificare include.

>>
>> Sinceramente, sotto linux che ci sia il desktop con il cubo oppure
>> che le finestre abbiano le trasparenze per me lascia il tempo che
>> trova.
>
> Invece conta, anche l'occhio vuole la sua parte e non tutti gli
> utenti sono sviuppatori o sysadmin.
>
Ok, anche l'occhio vuole la sua parte, ma se vado dal cliente e gli mostro
guarda che bello che è il cubo, ma non ha i programmi che gli servono, tira
fuori il cubo dallo schermo e me lo da giù per la testa.


Daneel Olivaw wrote:
> Il 15/08/07, Davide Rondini <davide.rondini a gmail.com> ha scritto:
>> Alle 17:47, mercoledì 15 agosto 2007, Samuele Zanin ha scritto:
>>> Adesso scateniamo un bel flame :-).
>>
>> Vuoi il flame? E flame sia! :-)
>> Un bel flame ferragostano è il massimo per svegliare un po' la ml!
>
> Sììììì, fuoco, fiamme sangue!!!! >:-DDD
>
> Facciamo così: taglio tutto e descrivo la mia modestissima esperienza.
>
> - Diffusione GNU/Linux: per quanto riguarda la mia ditta, come
> diceva... non ricordo chi, beh, anche da me non fosse per i programmi
> di gestione fatti all'epoca in access perché non si era in tanti, non
> si aveva tempo e serviva qualcosa che funzionasse senza tante pretese,
> sarei attorniato da pinguini :-)
> Dovremmo ricreare i programmi in altri linguaggi più decenti, ma come
> al solito manca tempo...
Classico...

> Sto cercando di studiarmi Ruby, che pare veramente ottimo per fare
> anche gestionali, ma vado molto a rilento... vedremo se mai riuscirò a
> combinare qualcosa :-)

> Ah, poi abbiamo un programmino in visual basic (basta fare boccacce e
> versacci, anche qui doveva essere una cosa con 2 mascherine per
> buttare dei dati iin un database e poi è cresciuto, non vi dico
> come...); come potete immaginare, ogni tanto si devono fare delle
> modifiche perché cambia qualcosa o un cliente si sveglia con idee
> geniali e ogni volta si fanno rituali per propiziarci gli dei del
> codice affinché non ci crolli tutto sotto i piedi.
Conosco, ci ho dovuto sbattere parecchio anche io la testa con vb.
Se da una parte ti permette di sviluppare inizialmente in modo abbastanza
veloce, all'aumentare di complessità del progetto, il sorgente cresce in
complessità in modo più che proporzionale. E' un dato di fatto.
I controlli te li devi creare tutti a design time (al massimo puoi
indicizzare), i componenti te li devi per forza prendere da ocx, non c'è il
sorgente e non puoi estenderli. Hanno aggiunto la programmazione ad oggetti,
ma non si capisce perché l'hanno castrata di brutto.
La mia opinione è che il vb si regge a forza di copia e incolla. Se provi a
strutturarti per bene il programma fin tanto che è codice che fa "calcoli"
od operazioni su db ci riesci anche, ma quando tenti di razionalizzare la
parte visuale sbatti contro un muro di gomma. Fare una form ereditabile
sembra chiedere oro.


> riusciva a superare l'inconveniente. Da qualche settimana, invece, su
> tutti gli xp ha cominciato ad aver problemi nella creazione della mail
> con l'allegato, molto probabilmente grazie a qualche importantissimo
> aggiornamento di sicurezza... soluzione: buttare la creazione in
Ricorda che un pc sicuro, è un pc con il cavo di rete staccato :-)
Che metodo usi per l'invio via mail?

> automatico della mail e spiegare all'utente come farsela a manina
> partendo dal file generato in una cartella... Cercare documentazione?
> Buona fortuna...
> Ditemi voi se questo si dice lavorare bene... ho il s.o. dell'azienda,
> il suo linguaggio di programmazione originale, uso il suo cavolo di
> pseudo-database e ad ogni minima modifica devo accendere ceri in
> almeno 5 santuari per sperare che non mi vada in pappa tutto (già
> successo: modifiamo iuna stringa da una parte, ne salta un'altra che
> non c'entrava assolutamente niente e che non era neanche stata
> toccata...). Quando poi pare che vada tutto bene, ci si mette la casa
> madre con le sue scoperte e novità... E li paghi pure! E poi zitti che
> loro sì che sono seri, loro sì che fanno le cose che funzionano, ecc.,
> mentre chi "gioca" con l'open source sono i ragazzetti brufolosi, gli
> hobbisti, gli alternativi che ti lasciano in brache di tela, ecc.

Sinceramente gli unici prodotti di casa M$ con i quali mi trovo bene sono
Win 2000 e Sql Server.
Di Sql server ho usato sia la versione 7 che 2000 e ultimamente sto
cominciando anche con la 2005 (solo che l'interfaccia dell'ex Enterprise
Manager l'hanno basata su .NET con tutti i casini di pesantezza e lentezza
connessi).
Sql server non mi si è mai impallato, mai avuto problemi di perdite di dati
o altro.
Non è proprio il massimo della velocità con insert e update.
Gli unici inconvenienti li abbiamo avuti da un'incompatibilità tra Sql
server e BDE con la gestione delle eccezioni derivate dai deadlock.
Per completezza devo ammettere che mettere su sul 2000 le repliche
transazionali con sottoscrittore in aggiornamento è stato un bel bagno di
sangue, ma per fortuna è una cosa che nel mio caso si è fatta per fortuna
solo una volta.


> Bah... Il vero problema è che la m$ viaggia coi commerciali, fa le
> cose belle graficamente, ci butta dentro facilitazioni e cose carine
> per il programmatore e poi più nulla... Ma intanto si è fatta lo
> zoccolo duro ed è a posto.

Pienamente d'accordo.

> Per quanto riguarda poi l'aiuto, sfido chiunque a capire cosa c'è
> scritto nella msdn e nelle altre guide; i quella poche volte che ho
> guardato, ho trovato sì esempi, ma o erano troppo semplici e non mi
> dicevano niente o completamente diversio da ciò che mi era successo...
> sì, vabbè, ho programmato pochissimo, ma mi è bastato. Sotto Ruby,
> invece, ho trovato gente che mi ha RISOLTO il problema, che mi ha
> PASSATO IL LORO CODICE come esempio e come unica pretesa mi hanno
> detto: "Poi dimmi se va" o "fammi sapere se ho scritto vaccate" o
> ancora: "la prossima volta tocca a te risolvere le mie rogne ^_^"
>
L'msdn ammetto che in alcuni casi è un po' ostica, ma penso che sia un
problema in generale di tutta la documentazione. Documentare tutti i
possibili problemi penso sia impossibile.
Poi per l'aiuto che puoi trovare su internet, penso molto non dipenda tanto
dal prodotto quanto da chi ti trovi dall'altra parte in quel momento, se ha
il tempo e voglia di darti una mano.

Diego Rondini wrote:


> Prendi il pallottoliere che poi ti faccio tre domandine:
> 1) fai il rapporto tra numero di computer desktop e computer server
> con Linux?
> 2) fai lo stesso rapporto desktop/server per Windows?
> 3) è più diffuso Linux o Windows?
> Ora scrivi un tema sulle conclusione che ne trai. :-)

In generale nelle ditte dove gironzolo, contando i clienti più grossi almeno
200 client totali win, 20ina di server windows, 3 server di posta linux.
L'unica cosa che vedo e che sapevo già senza fare tanti conti è che win è
più diffuso.
Il mio discorso non si basava tanto sulla diffusione, quanto sul fatto di
che possibilità ho per farlo entrare in uso anche in un certo tipo di
ambiente lavorativo/produttivo.


> Appunto, è quello di cui senti la necessità tu. Ognuno ha le sue
> necessità, chi vuole una piattaforma di sviluppo, chi un CAD, chi un
> gestionale, chi server, ecc. Certo è che chi sceglie Linux non lo fa
> per semplificarsi la vita!

Intanto io non sto prentendendo niente da nessuno. Ho semplicemente detto
che mi piacerebbe se in linux ci fossero certe cose, in modo da potermi
permettere di scrivere programmi e così aumentare la diffusione.
Questo alla fine è sempre il solito discorso, si sente tanto invocare i vari
pregi, ma appena uno fa un appunto viene prontamente freddato e in modo più
o meno gentile gli viene detto "Questo el xe. se nol te comoda fatte ti queo
che te serve".
Adesso, spero di riuscire con quattro parole a riassumere il succo del mio
discorso:
"Se la diffusione di un sistema operativo passa per il numero di software
che ci possono girare e dal numero di sviluppatori che ci stanno dietro,
dovrebbe essere un obiettivo di chi "gestisce" il sistema operativo fornire
gli strumenti per poter creare il software.
Il compilatore c è indispensabile, ma non lo vedo sufficiente. Invece di
avere n diversi progetti che portano avanti ambienti di sviluppo, con il
rischio di vari fork, non sarebbe bello se la gnu (o chi coordina un po'
tutta la baracca) dicesse creiamo anche degli altri compilatori "standard"
che possano essere utilizzati per altri tipi di applicazioni? Ad esempio nel
campo delle pagine web si è affermato con successo php."
Non sono riuscito ancora a rendere il concetto. Spero si sia capito.



Alessandro Galli wrote:
> Sono d'accordo. Non vedo possibile che M$ passi dal 99,7% del mercato
> desktop a 0% sforando un SO.
Fare il passaggio no, ma cominciare a buttarci su qualcosa sarebbe bello.


> Quindi quando confronto i due sistemi devo tenere in considerazione
> che per M$ è più problematico essere innovativo, mentre per Linux
> basta che qualcuno non abbia nulla da fare per due mesi e magari
> inventa un programma nuovo mai visto.
> D'altro canto quando installo Linux è ovvio che abbia la sensazione di
> un'accozzaglia di programmi non omogenei (alcuni in qt, alcuni in
> gtk, alcuni tcl/tk etc.).
>
> Rimangono quindi due cose diverse, ognuna delle quali si comporta
> meglio in alcune condizioni rispetto ad altre.
> E' innegabile però che Linux porta vantaggi all'umanità (in termini di
> innovazione e libertà) mentre M$ porta vantaggi alla M$. Questa non è
> una questione morale ma è insito nell'essere di questi due SO.

Devo dire anche che fino a win 2000 di problemi non ce ne sono stati.
Abbiamo cominciato ad avere problemi penso in larga parte dovuti alle fisime
di sicurezza con Xp e 2003 Srv.

> Il problema dei driver è duplice. Ci sono ambiti, tipo quello server
> high end, dove i driver in genere sono disponibili.
> Per il lato destkop sicuramente l'unica soluzione è guadagnare quote
> di mercato.
L'importante è che ci sia il supporto quanto più completo per l'hardware dei
server.
Poi per i client, quando c'è il supporto per scheda di rete e video 2d per
me va più che bene.
Con le stampanti non ci ho mai sbattuto la testa.

> Secondo me è falso. Il fatto principale è la mancanza di investimenti
> su linux. Diciamocelo, i programmatori programmano su quello che il
> Technology Manager decide, almeno in aziende di una certa dimensione.
> Se ti offrono un lavoro ti frega veramente in che linguaggio devi
> programmare o ti importa più l'ingaggio, le ferie, il contatto etc.?
> Se domani ti offro un lavoro a pari condizioni di quello attuale ma
> ti dò 100? in più mi chiedi in cosa programmo?

Qui dipende secondo me da che obiettivo ha la software house. Se sviluppa
software su commissione, li penso che sia proprio come dici tu, basta che il
cliente paghi, poi gli si consegnano i sorgenti e buona notte.
Se invece lo scopo della sh è quello di sviluppare un proprio software da
commercializzare, e questo software dovrà rimanere sul mercato n anni con
costanti aggiunte ecc., allora penso che la scelta della tecnoligia da
utilizzare sia molto più oculata e non basata sulla moda corrente.
Oltretutto bisognerà sviluppare in modo da rendersi il meno vulnerabili
possibili a cambiamenti possibili (es. driver per l'accesso ai dati).

> Io invece penso che nell'ambito aziendale ormai abbiamo ottime
> possibilità! Ora come ora si stà tornando a termiali stupidi (per
> quanto graficamente capaci) e server (o cluster) intelligenti.
> In questo ambito io sceglierei di utilizzare terminali con linux per:
> * non pagare costi di licenze
> * stabilità
> * possibilità di aggiornamenti automatici non invasivi
> * possiblità di assistenza remota (anche solo via console)
> * capacità di supporto per hw obsolescenti
> * automatizzazione del collegamento con server di terminale grafico
> * sicurezza
> * azzerato il costo di manutenzione causato dai virus
> Come server può essere utilizzato sia linux (per il software tipo
> webmail, openoffice tramite vnc o rdp etc.) sia winzozz (per
> Exchange, db, gestionali sempre tramite rdp o cytrix).

Il costo della licenza di win sulla macchina allo stato attuale sei
costretto a pagarlo, in molti casi assemblarti un pc costa più che prenderne
uno con già il so. preinstallato. L'unico costo in meno che si avrebbe forse
sarebbe quello delle licenze antivirus e di eventuali rimozioni di virus.
Per contro però dovrei comunque comprare altrettante licenze di terminal
server senza contare che dovrei avere un server molto ben carrozzato sul
quale far girare i vari applicativi. C'è anche da dire che dall'esperienza
che ho alcuni utenti si trovano abbastanza impacciati ad avere il gestionale
su terminal server, mentre ad esempio la posta e gli altri applicativi sul
desktop locale.
Terminal server lo vedo bene al momento attuale solo per utenti in sedi
remote rispetto al db server o per applicativi con installazioni
impegnative.
Fin tanto che l'installazione del programma consiste solo nel copiare un
link e lanciare un paio di file .reg, nel mio caso conviene l'installazione
client per client.
Per il discorso della "manomissione dei client" da parte degli utenti vedo
che in genere dopo che stanno senza il pc per mezza giornata per la pulizia
e la strillata del loro capo dopo che ha visto la fattura, questo
costituisce un ottimo deterrente contro l'installazione di porcherie.


> Ci sono dei progetti molto interessanti, ovviamente general pourpose.
> In questo ambito il problemi fondamentali sono due:
> a) mancanza di pressione commerciale
> b) spinte derivanti dal ruolo in azienda
>
> Il primo problema è ovvio. Se uno non se li va a cercare non saprà mai
> dell'esistenza e delle capacità  dei sw gestionali opensource su
> linux. Invece, quelli commerciali su Win hanno frotte di
> agenti/commerciali che spingono dalla mattina alla sera (è il loro
> lavoro) per vendere i loro prodotti.
>
> Il secondo problema si basa sul fatto che le persone tendono,
> logicamente, ad assumere le decisioni più convenienti per loro.
> Chi in azienda decide che sistema operativo o sw utilizzare, ha due
> scelte: 1) sceglie il prodotto leader del mercato
> 2) sceglie un'alternativa in base al rapporto prestazioni/costi
>
> Nel primo caso un eventuale insuccesso del progetto non è a lui
> addebitabile, in quanto ha fatto la scelta sicuramente migliore, per
> quanto non abbia risposto alle aspettative.
> Nel secondo caso invece si assume la responsabilità di un eventuale
> insuccesso, perchè se le cose vanno male la colpa è sua che ha fatto
> una scelta "creativa" o "innovativa". Se invece va bene diventa un
> "mago" del software.
> Ma per fare la seconda scelta ci vogliono le palle e bisogna sapere
> di cosa si stà parlando in prima persona.
Purtroppo quest'ultima ipotesi raramente funziona in quanto in azienda
difficilmente c'è qualcuno che ha una visione dettagliata di tutti i
settori. Spesso succede nelle migrazioni da altri software che si pianifica
il tutto, si parla con i vari responsabili in modo da includere e sistemare
tutte le funzionalità. Poi si parte e c'è sempre qualcuno che ha il caso
sfigato tutto per i cavoli suoi di cui solo tizio sapeva dell'esistenza.

> Non sono d'accordo. Il C forse ma il C++ è tutto un'altro linguaggio.
> Solo il nome e la compatibilità con il vecchio C li accomuna in
> qualche modo.

Sul C++ non mi esprimo direttamente, in quanto avevo cominciato solo a
leggere un manuale, poi per fortuna sono partito per naia e ho abbandonato
quel posto.
Ho provato a chiedere invece a persone che usavano il C++ se alcuni dei
problemi che avevo con il C sono stati risolti e la risposta è stata
negativa (non so  se il motivo sia perché loro non avevano mai affrontato il
problema e la risposta sia stata più o meno a casaccio).
Bisognerebbe mettersi qui a discutere di persona se non non se ne viene più
fuori.

> I puntatori per lavorare sulle stringhe li usi in modo trasparente
> con classi tipo <string.h> o <qstring.h>.
> Se poi il progetto delle classi è fatto bene è facile evitare anche i
> memory leak e i SIGSEGV.
> I puntatori li puoi anche in C++ usare solo quando ti servono.
Il problema è proprio questo. Spesso ti tocca mettere le mani su programmi
fatti da altri e non è detto che questi abbiano rispettato i principi di una
sana programmazione. Se il linguaggio non ti lascia fare cazzate già
dall'inizio è un buon punto di partenza.
Per capirci dovrei farti vedere alcuni sorgenti che però per vari motivi non
posso spedire.

> E' certo che quando si programma in C++ le classi che tu disegni
> vanno a rappresentare un modello. Se le condizioni a contorno o una
> maggior definizione delle specifiche vanno ad "intaccare" il modello
> è sempre necessario tirarsi su le maniche e modificare il modello,
> quindi modificare le classi, in modo che rappresentino le nuove
> condizioni.
> Procedere come spesso si usa patchando il sw porta sempre ad avere un
> sw che non ci appartiene perchè non sappiamo più come funziona.
> E allora sì non si capisce nulla tra puntatori e variabili globali.

Nelle due esperienze precedenti di lavoro si andava al rattoppo sul rattoppo
all'ennesima potenza come diceva Daneel Olivaw.
Dove sono adesso meno ma ogni tanto succede.

> Per quanto riguarda Java penso che ti sbagli del tutto. Non è molto
> diverso da .NET per quanto riguarda l'architettura. Sicuramente nei
> suoi primi anni di vita ha patito la pesantezza della RM e la
> limitatezza delle funzionalità ma penso che questo tempo sia finito.
> Con la JRE 1.6 sono stati fatti passi da gigante. Se poi la paura è la
> gestione della garbage collection, basta avere l'accortezza di
> impostare a null i puntatori alle classi che non ti servono più.

Java non l'ho potuto sperimentare di persona. Avevo la collega di fianco che
ci ha programmato dei terminali, mi sembra con il jdk 1.4.
Nulla da dire sulla sintassi/costrutti del linguaggio. Il problema
principale era dato dalla lentezza e dalla mancanza di controlli grafici
(es. griglie) adatte agli scopi che servivano.
Da quello che mi diceva, se servivano dei controlli grafici personalizzati
bisognava scriverseli in C++.

> L'attrattiva c'è, ma non stà nei linguaggi e nelle librerie.
> L'alternativa è nell'informazione che hai disponibile. Ricordati che
> se quando hai un problema puoi googlare e trovare la soluzione bell'
> e pronta è solo grazie alla comunità open source. Inoltre se stai
> usando una libreria di qualcun'altro puoi studiarla, capire come
> funziona ed anche modificarla in base a quello che ti serve. Ad
> esempio nell'azienda dove lavoro si usava una libreria open source
> per aprire svg da qualche mega. Andando a vedere il sorgente della
> libreria sono state disabilitate alcune funzionalità non necessarie e
> si sono ridotti i tempi di apertura da 20 secondi a 2!

Infatti non ho mai detto nulla contro l'open source, nei miei programmi,
quando ho bisogno di qualche libreria/componente prendo (e impongo ai
colleghi) di prendere quelli che hanno il sorgente. Mi è già capitato più di
qualche volta di aver a che fare con componenti bacati e che sono riuscito a
sistemare avendo i sorgenti.
L'unica cosa da fare è appena avrò un po' di tempo cominciare a scaricare i
vari ambienti e provare ad approfondire e vedere fin dove ci si può
spingere.

Ringrazio tutti per la "chiacchierata", mi scuso ancora per il ritardo con
il quale ho risposto (maledetta Telecom!!! mi offro volontario per test di
connettività tramite ponti radio :-)), alcune idee mi si sono chiarite,
altri dubbi rimangono... vedremo tra qualche tempo come proseguirà la
storia.