DO Diesis?

[axias41]

Anche se sembra dal titolo, non voglio scrivere nulla sulla musica. Ma sul C# si.
Scorrendo un pò di pagine del forum,mi sono accorto quante domande ci siano ancora sul vb6, e quante poche su vb .net e soprattutto c#.
Arrivando da c e java, ho avuto occasione di provarli tutti, ma sinceramente per adesso sto sostando appunto sul c#.
Ho iniziato per provare col Visual C# Express, riscrivendo un applicazione che avevo fatto in vb per confronto, e devo dire di essere rimasto veramente soddisfatto.
Tanti problemi avuto col C non si ripresentano e la velocità di sviluppo ne ha risentito,cioè è aumentata.
Inoltre la curva di apprendimento è secondo me decisamente più dolce,come infatti è stato voluto fosse per questo linguaggio.

Voi che ne pensate? Perché ancora in molti si rivolgono a VB6,quando ormai è già stata decisa la data della fine del supporto?

[fabianoda]

Il fatto che molta gente utilizzi vb6 è legato alla necessità dell'utilizzo del framework .net per vb.net e c#.net.

Questo implica un'installazione presso il cliente, e se questo è un'organizzazione di medio - grandi dimensioni, risulta antieconomico per l'azienda che produce il software.

Da notare inoltre che con il framework gli applicativi sono più lenti in generale, ad esempio per l'accesso ai files.


Sono d'accordo invece sul fatto che c#.net sia molto comodo da utilizzare, e questo perché le API sono organizzate secondo una gerarchia molto intuitiva.

[axias41]

Beh, l'installazione del framework è possibile farla assieme all'applicativo,che può essere distribuito in rete, dunque non ci sono problemi da questo punto di vista.

Quanto a performance, riesco comunque a far girare l'applicativo di cui ho scritto prima anche su un portatile con duron a 500Mhz a batteria e 128 di ram,con prestazioni pari alla versione VB6,se non superiori.
Non ho ottenuto questo risultato al primo colpo, un pò di ottimizzazione del codice ci vuole sempre:

make it runs,make it right,make it fast,make it small...

[fabianoda]

Sì ma quando tratti con un cliente di grosse dimensioni, e dici ai loro tecnici che devi installare il framework su ogni pc, loro decisamente non ne sono molto felici.

Alcune motivazioni:
1) un nuovo software implica possibili minacce per la sicurezza
2) un numero di installazioni potrebbero andare storte e richiedere assistenza
3) i tecnici possono non aver voglia di monitorare il tutto
4) sistemi operativi datati che non supportano il framework


La situazione reale, in Italia, è che esistono molte aziende con sistemi datati... non è tutto semplice come si possa credere.

Per la velocità, rispetto a vb6 può essere, ma rispetto a c++?

[axias41]

Beh, certo, se confrontiamo con C++... ma se il cliente vuole il prodotto non subito,prima? Quanto tempo/uomo serve a parità di funzionalità richiesta? E quante volte è preferibile un prodotto un pò più lento, ma che dia maggiori garanzie quanto a errori, di ogni genere? Avrebbe senso perdere 6 mesi per l'ottimizzazione di un prodotto col C++ senza che ci sia reale necessità?

Quanto ai sistemi datati,in effetti sta diventando un vero problema. Non si può rimanere ancorati alla pietra,informaticamente parlando, purtroppo c'è chi lo fa credendo di risparmiare. Ma è un'altra storia...

[rdefalco]

Originariamente inviato da axias41

Beh, certo, se confrontiamo con C++... ma se il cliente vuole il prodotto non subito,prima? Quanto tempo/uomo serve a parità di funzionalità richiesta? E quante volte è preferibile un prodotto un pò più lento, ma che dia maggiori garanzie quanto a errori, di ogni genere? Avrebbe senso perdere 6 mesi per l'ottimizzazione di un prodotto col C++ senza che ci sia reale necessità?

Quanto ai sistemi datati,in effetti sta diventando un vero problema. Non si può rimanere ancorati alla pietra,informaticamente parlando, purtroppo c'è chi lo fa credendo di risparmiare. Ma è un'altra storia...

Aggiungi però il fatto che se voglio una piccolissima utility che faccia una determinata operazione posso scriverla in VB6 e portarmi il file EXE (50KB ad esempio) in qualsiasi PC dove ci sia almeno Windows 2000, mentre col framework sono costretto a tenermi 20MB + 10KB di eseguibile e lanciare l'installazione ogni volta.

Ovviamente del .NET framework non esiste una versione portabile, il che riconduce all'impossibilità di usare in giro gli stessi programmi. E per me che lavoro su 10+ computer diversi ciò è una limitazione a dir poco fastidiosa.

[axias41]

Quanto dici è assolutamente inoppugnabile, anzi io stesso ho fatto come hai scritto,l'unico problema è che continuando così, ci si ritrova ad usare gli stessi strumenti di 10 anni prima, senza alcuna innovazione.
Ogni situazione va valutata a sè stante, e giustamente dove conviene usare gli strumenti più sbrigativi, si fa, ma se è possibile dare l'impulso all'uso di nuovi (ma neanche troppo,ormai il do diesis ha già qualche hanno).
Questi passaggi sono sempre visti con estrema diffidenza. Poi ognuno è libero di fare quel che vuole...per fortuna !

[tomminno]

Originariamente inviato da axias41

Arrivando da c e java, ho avuto occasione di provarli tutti, ma sinceramente per adesso sto sostando appunto sul c#.
Ho iniziato per provare col Visual C# Express, riscrivendo un applicazione che avevo fatto in vb per confronto, e devo dire di essere rimasto veramente soddisfatto.

Certo che se la paragoni a quanto può fare il vb...
E' impossibile non notare quanto siano lenti i programmi vb.
Mi è capitato nel caso di un applicativo pesante (che doveva percorrere il grafo della cartografia d'Italia), di dover spezzare l'esecuzione perchè il garbage collector non riusciva a liberare le risorse tanto che nel giro di 10 minuti Windows segnalava la necessità di aumentare la memoria virtuale e il programma doveva girare per un intero fine settimana prima di analizzare una parte d'Italia!
Mi chiedo ancora come si faccia a pensare di fare un applicativo del genere in vb, purtroppo a decidere sono sempre i capi che di programmazione non sanno una beneamata cippa.

Tanti problemi avuto col C non si ripresentano e la velocità di sviluppo ne ha risentito,cioè è aumentata.

Io mi trovo decisamente meglio con il C, oltre ad essere leggermente più versatile, per scrivere firmware è ancora imbattibile (lasciamo da parte l'assembly, perchè se uno dovesse impararselo per ogni micro adottato...).
Poi con altri linguaggi mi manca la possibilità di fare un bel free/delete quando qualcosa non serve più

Inoltre la curva di apprendimento è secondo me decisamente più dolce,come infatti è stato voluto fosse per questo linguaggio.
Voi che ne pensate? Perché ancora in molti si rivolgono a VB6,quando ormai è già stata decisa la data della fine del supporto?

Al lavoro si sono decisi finalmente ad abbandonare vb6 in favore di C# ma non è che mi piaccia troppo questo linguaggio, a parte l'editor visuale dell'interfaccia grafica che non puoi metterci mano che a volte va in botta totale (sono abituato a scrivere a mano l'interfaccia, mal digerisco gli strumenti automatici), l'efficienza nell'accesso ai file non è il massimo, inoltre penso che l'impalcatura copiata da Java non aiuti l'efficienza.
Continuo a trovare un sacco di problemi con l'interfaccia seriale se utilizzata ad alte velocità, cosa che non riscontro in una implementazione C++ (tra l'altro c'è un problema nel codice C# per gestire la seriale che si trova su msdn, per cui superati i 38400 in ricezione quella implementazione va in botta), oltre ad un sacco di problemi per la conversione dei caratteri, che di fatto non lo rendono interoperabile con programmi scritti in altri linguaggi, come il vb6; lavorando con protocolli binari ormai ci ho fatto il callo.
Poi c'è qualche incongruenza logica nella sintassi del linguaggio del tipo un metodo lo si dichiara a void (per similitudine con C/C++) quando poi il tipo void nel C# non esiste.
Per non parlare delle assurdità dell'IDE del tipo dopo un ora di lavoro si arriva allegramente a superare i 150MB di memoria, ma gli ho visto raggiungere i 220MB, rallentando la macchina notevolmente e obbligando ad un riavvio dell'applicazione. Questo comportamento non lo riscontro quando programmo in c++, con il quale si accontenta al massimo di occupare 60MB.

Ciao!

[axias41]

Sulla mia macchina, ho visto l'ide superare anche i 300MB: ma stavo facendo il debug a un'applicazione che da sola me ne occupava 150 (programma con circa 80 jpeg alla volta) Per il resto anche dopo tante ore, questi problemi non li ho avuti,e ho anche provato su una macchina che non è certo più un missile (un athlon 1200 con 384ram)

Il vb l'ho tirato dentro per via dei post nel forum,non per altro.

Con java mi son trovato discretamente per un periodo,poi mi ha stufato

Quanto a comodità di uso dell'uno e dell'altro,c c++ e c#, credo siano preferenze personali, come ho già scritto: per fortuna ognuno può scegliere
Penso che i capoccia le provino tutte per aumentare quella cosina magica chiamata produttività, e non è detto che sempre vada bene

La diversa efficienza,già detto, i problemi di conversione li ho trovati anch'io, quelli dell'interfaccia seriale no. Quanto alla gui, a me sembra di star meno col visuale per le piccolezze. Le altre le scrivo per piacere mio

See you soon,space cowboy...

[tomminno]

Originariamente inviato da axias41

Sulla mia macchina, ho visto l'ide superare anche i 300MB: ma stavo facendo il debug a un'applicazione che da sola me ne occupava 150 (programma con circa 80 jpeg alla volta) Per il resto anche dopo tante ore, questi problemi non li ho avuti,e ho anche provato su una macchina che non è certo più un missile (un athlon 1200 con 384ram)

A me l'IDE continua ad occupare memoria anche quando il debug è finito, 512MB gli vanno un pò strettini e ho visto .NET 2005 partire all'avvio già con 100MB di memoria

Con java mi son trovato discretamente per un periodo,poi mi ha stufato

Io devo ancora capire oggi quali possono essere i vantaggi di java al di fuori di internet. Applicazioni multipiattaforma ormai si scrivono benissimo in C++.

Penso che i capoccia le provino tutte per aumentare quella cosina magica chiamata produttività, e non è detto che sempre vada bene

Non si può certo abbandonare il know-how dell'azienda solo per migliorare la produttività

La diversa efficienza,già detto, i problemi di conversione li ho trovati anch'io, quelli dell'interfaccia seriale no. Quanto alla gui, a me sembra di star meno col visuale per le piccolezze. Le altre le scrivo per piacere mio

See you soon,space cowboy...

Cosa hai usato per l'interfaccia seriale? Io ho fatto ricorso alle API di Windows, perchè fino a .NET2003 l'alternativa era MSCOMM e con protocolli binari nascono i soliti problemi di conversione.
Per l'editor visuale quando devi far apparire una cosa sopra l'altra è veramente impossibile lavorarci, specialmente se bisogna far sparire un intero panel e modificando a mano il codice a volte capita che .net non ci capisca più niente e cominci a dare errori strani, risolvibili facendo taglia e incolla del codice su se stesso.

Ciao!