Da esattamente 12 anni sono uno sviluppatore (tra le altre cose ad. es.
web) di Visual Basic. Quello che attraeva del Visual Basic era senza
dubbio la IDE molto indovinata. Il Visual C/C++ di allora non poteva
competere nemmeno lontanamente, (nonostante l'attributo 'Visual') per
quanto riguarda l'immediatezza di creativitá. Basta ricordarsi la
difficoltá di cambiare il colore di background di un Form in Visual C/C++.

L'anno scorso, forte del fatto che ormai anche il Visual Basic era
'cresciuto', adottando tutte le classi .NET, che lo mettevano (pensavo)
allo stesso livello di C#, C/C++, Java, nel Visual Studio, ho continuato
ad usarlo.

Ma ora mi rendo conto che nonostante la pubblicità, *qualcosa* di
diverso esiste, ANCHE NELLE CLASSI che hanno lo stesso nome.

Anche se hanno lo stesso nome, sono diverse. Si comportano diversamente.
Sono poche cose ma in alcuni casi determinanti. Come il metodo
Print.Document ed altre amenità.

Quindi ho deciso di passare definitivamente a C# ed abbandonare VB al
suo destino. O di usarlo solo a scopi 'didattici'. Infatti, l'ho trovato
un ottimo modo per passare da Visual Basic a C# in modo 'indolore',
quasi trasparente.

Infatti, il vero 'salto di qualitá' é stato il passare da Visual Basic 6
a Visual Basic .NET. Quello sì che era come cambiare pianeta.

Ma passare dal VB. NET a C# è uno scherzo. Quindi per motivi didattici
consiglio senzaltro il passaggio Visual Basic 6 --> VB.NET --> Visual C#.

Detto questo, ora finirò di fare alcuni test e se i miei sospetti sono
veri, come qualche indizio giá mi ha confermato, adotterò
senzaltro Visual C# per prodotti che devono essere venduti sul mercato
Windows XP/Vista.

Per altre cose private (in ambiente Windows) ho scoperto il wxDEV C++
che ho installato e mi sembra ottimo.

Vabbé, questo è quanto. Magari se qualcuno ha dei commenti, secondo le
sue esperienze, ne sarei molto felice.

In article <hnbie7$jr5$1>, john, dummy ha
scritto...

> Ma passare dal VB. NET a C# è uno scherzo. Quindi per motivi didattici
> consiglio senzaltro il passaggio Visual Basic 6 --> VB.NET --> Visual C#.

Appoggio in pieno , io ho fatto il salto Vc++ ->C# ai tempi dell'1.0
non me ne sono mai pentito anzi :-).

Anzi quando entra qualche lavoro in VB6 è una sofferenza farlo nel 2010.

On 11/03/2010 21:05, john wrote:
> Da esattamente 12 anni sono uno sviluppatore (tra le altre cose ad. es.
> web) di Visual Basic. Quello che attraeva del Visual Basic era senza
> dubbio la IDE molto indovinata. Il Visual C/C++ di allora non poteva
> competere nemmeno lontanamente, (nonostante l'attributo 'Visual') per
> quanto riguarda l'immediatezza di creativitá. Basta ricordarsi la
> difficoltá di cambiare il colore di background di un Form in Visual C/C++.

asd perche' non hai mai usato delphi 6 che gli spaccava le chiappe a
vb6! :-D


> Quindi ho deciso di passare definitivamente a C# ed abbandonare VB al
> suo destino. O di usarlo solo a scopi 'didattici'. Infatti, l'ho trovato
> un ottimo modo per passare da Visual Basic a C# in modo 'indolore',
> quasi trasparente.

mmm hai fatto bene, c# a mio avviso come sintassi e costrutti e' uno dei
linguaggi migliori e anche l'ide e' ottima.

> Infatti, il vero 'salto di qualitá' é stato il passare da Visual Basic 6
> a Visual Basic .NET. Quello sì che era come cambiare pianeta.

il vb.net e' stata una specie di mossa commerciale per invogliare i
numerosissimi programmatori vb a passare a .net! :-D
Imho per me il grosso trauma che accade quando si passa da vb6 a c# e'
che si passa da un linguaggio non a oggetti(per me vb6 non e' a oggetti
delphi si lo era ma vb6 no! :-D ) a uno totalmente a oggetti, l'unico
vantaggio per vb.net e che non devi reimpararti la sintassi(peraltro
odiosa!).

Cya

On Mar 11, 9:05 pm, john <du> wrote:
> Da esattamente 12 anni sono uno sviluppatore (tra le altre cose ad. es.
> web) di Visual Basic. Quello che attraeva del Visual Basic era senza
> dubbio la IDE molto indovinata. Il Visual C/C++ di allora non poteva
> competere nemmeno lontanamente, (nonostante l'attributo 'Visual') per
> quanto riguarda l'immediatezza di creativitá. Basta ricordarsi la
> difficoltá di cambiare  il colore di background di un Form in Visual C/C++.
>
> L'anno scorso, forte del fatto che ormai anche il Visual Basic era
> 'cresciuto', adottando tutte le classi .NET, che lo mettevano (pensavo)
> allo stesso livello di C#, C/C++, Java, nel Visual Studio, ho continuato
> ad usarlo.
>
> Ma ora mi rendo conto che nonostante la pubblicità, *qualcosa* di
> diverso esiste, ANCHE NELLE CLASSI che hanno lo stesso nome.

VB.NET e C# sono solo due sintassi diverse sopra IL e .NET.
Nel 99% dei casi puoi fare la stessa cosa con entrambi e quindi
l'unico motivo per preferire uno all' altro e' la preferenza personale
per lo stile e la sintassi, ovvero la provenienza da un "mondo C" o da
un "mondo VB". Un programmatore decente in ambiente .NET naturalmente
dovrebbe conoscere entrambi. E anche ovvio che VB.NET e' stato utile a
MS per "traghettare" gli ex-sviluppatori VB che non erano degli
irrimediabili sprovveduti al nuovo framework .NET.
Non c'e' molto altro da dire....

non è possibile che due classi del framework si comportino in maniera
diversa.
C#,Vb.net, managed C++, j#, e altri mille vengono compilati in un
linguaggio intermedio che si chiama msil e a quando acceddi alle classi
del framework i linguaggi usano gli stessi tipo del clr (i tipi del
linguaggio vengono mappati su quelli del common language runtime) quindi
alla fine al compilato non fa differenza che sia stato fatto con vb.net
rispetto a c#.
L'unica facilitazione introdotta dal vb.net 2005 è il namespace my che
consente una semplificazione del codice, ma volendo se importi
l'assembly lo puoi usare anche da C#. (anche se per i puristi del C#
quello che ho scritto suonerà come una bestemmia.)
il C# 4.0 introduce invece delle caratteristiche che lo rendono simili
ai linguaggi dinamici quando hai a che fare con i tipi (var e dynamic)
che sinceramente non so se sono stati introdotti anche con vb.net.
Io inoltre non credo che sia un percorso obbligatorio vb.net -> c#,
direi che si può imparare direttamente il c# e amen!

michelangelo giacomelli schrieb:
> non è possibile che due classi del framework si comportino in maniera
> diversa.

E invece ti giuro che è così. Ovviamente non so 'dove sta esattamente'
il 'bug'. Ma è così.

Tant'è vero che MIchael Kofler, uno dei maggiori esperti di Visual
Basic, (ha scritto due meravigliosi volumi, uno su Visual basic 6 ed uno
su Visual basic 2008, che sono le mie 'bibbie') consiglia addirittura
di lasciar perdere la classe Print.Document e di fare tutto 'da soli'
usando le classi XPS.

Io è da tre giorni che mi sto sbattendo la testa per far stampare TUTTE
le pagine di un file rtf con la classe Print.Document.

Ho esaurito giá tutte le opzioni, i metodi, della classe. Mi stampa
sempre solo la prima pagina.

Per questo che ssto facendo dei test paralleli col C# usando le stesse
classi. Voglio vedere come si comportano.

Finora era andato tutto bene, ed in effetti la maggior parte delle
classi non mi dava problemi.


> C#,Vb.net, managed C++, j#, e altri mille vengono compilati in un
> linguaggio intermedio che si chiama msil e a quando acceddi alle classi
> del framework i linguaggi usano gli stessi tipo del clr (i tipi del
> linguaggio vengono mappati su quelli del common language runtime) quindi
> alla fine al compilato non fa differenza che sia stato fatto con vb.net
> rispetto a c#.

Sarà tutto come dici ma voglio vederci fino in fondo alla faccenda. Per
quello che faccio adesso un sacco di tests.

Dopo riferirò qui di quello che ho ottenuto. Ma a me il sospetto resta,
che si comportano diversamente. A primo acchito mi sembra così.

E non sarebbe poi tanto impossibile che ciò avvenga. Dipende da come il
Visual Basic compiler 'chiama' queste classi.
E noi non abbiamo un 'object code' da confrontare con quello del C# e
vedere come il Vb e C# chiamano il msil.

Puo' darsi che ci sia un 'bug' nel Visual Basic compiler. Cosa che sospetto.

> L'unica facilitazione introdotta dal vb.net 2005 è il namespace my che
> consente una semplificazione del codice, ma volendo se importi
> l'assembly lo puoi usare anche da C#. (anche se per i puristi del C#
> quello che ho scritto suonerà come una bestemmia.)
> il C# 4.0 introduce invece delle caratteristiche che lo rendono simili
> ai linguaggi dinamici quando hai a che fare con i tipi (var e dynamic)
> che sinceramente non so se sono stati introdotti anche con vb.net.
> Io inoltre non credo che sia un percorso obbligatorio vb.net -> c#,
> direi che si può imparare direttamente il c# e amen!

Lo suggerivo senzaltro per quelli che provengono da VB e vogliono
'giocare un po' per impararlo divertendosi.

Il percorso è un po' più facile e la salita non è così ripida.
Alla fine comunque si arriva sempre allo stesso target.

"john" ha scritto nel messaggio news:r681
>
> E non sarebbe poi tanto impossibile che ciò avvenga. Dipende da come il
> Visual Basic compiler 'chiama' queste classi.
> E noi non abbiamo un 'object code' da confrontare con quello del C# e
> vedere come il Vb e C# chiamano il msil.
>
> Puo' darsi che ci sia un 'bug' nel Visual Basic compiler. Cosa che
> sospetto.
>

:-?

Creati due progetti libreria, uno in VB.NET e uno in C#.
Ci ficchi dentro una classina che usa le classi e i metodi del fx che te
ritieni "sospetti", generi le 2 dll, ti scarichi il red gate reflector e ti
apri le 2 dll. Fai un confronto tre i due codici nella forma che ti piace di
più (via vb, c# o anche se vuoi il... :-)

>
> E non sarebbe poi tanto impossibile che ciò avvenga. Dipende da come il
> Visual Basic compiler 'chiama' queste classi.
> E noi non abbiamo un 'object code' da confrontare con quello del C# e
> vedere come il Vb e C# chiamano il msil.
>
> Puo' darsi che ci sia un 'bug' nel Visual Basic compiler. Cosa che
> sospetto.

non credo proprio, non ho mai sentito colleghi lamentarsi di
document.print e alcuni usano vb.net, inoltre c'è modo di vedere il
codice intermediate language, ci sono vari disassembler ma se la memoria
non mi inganna c'è pure un tools dato con il framework che si chiama
ildasm che fa quanto chiedi. (guarda vado davvero a memoria perché io
ormai mi sono specializzato su php/c++/java e lavoro con linux/solaris
il 90% del mio tempo)

AleTV schrieb:

>
> Creati due progetti libreria, uno in VB.NET e uno in C#.


E' proprio quello che sto facendo. Per ora mi limito alle classi di
Print.Document e affini, e quella di Savefile.

> Ci ficchi dentro una classina che usa le classi e i metodi del fx che te
> ritieni "sospetti", generi le 2 dll, ti scarichi il red gate reflector e
> ti apri le 2 dll. Fai un confronto tre i due codici nella forma che ti
> piace di più (via vb, c# o anche se vuoi il... :-)
>

Vedremo cosa viene fuori dai test. Poi saprò dire.

Prima devo resinstallarmi tutto il sistema, ora che ho allargatola boot
partition. E poi reinstallare tutti iprogrammi, tra cui Visual Studio.

Insomma. Ancora un po' di tempo e poi posso continuare i test.

michelangelo giacomelli schrieb:
>
> non credo proprio, non ho mai sentito colleghi lamentarsi di
> document.print e alcuni usano vb.net, inoltre c'è modo di vedere il
> codice intermediate language, ci sono vari disassembler ma se la memoria
> non mi inganna c'è pure un tools dato con il framework che si chiama
> ildasm che fa quanto chiedi. (guarda vado davvero a memoria perché io
> ormai mi sono specializzato su php/c++/java e lavoro con linux/solaris
> il 90% del mio tempo)

Eppure il manuali Visual basic 2008 e il Visual C# 2008 della Microsoft
Press me li sono letti tutti fino in fondo. Non mi sembra di aver
tralasciato niente. E sì che questultimo ha 1264 pagine.

Sai menzionarmi un po' di letteratura che mi dia le informazioni di cui
hai scritto ?

>
> Eppure il manuali Visual basic 2008 e il Visual C# 2008 della Microsoft
> Press me li sono letti tutti fino in fondo. Non mi sembra di aver
> tralasciato niente. E sì che questultimo ha 1264 pagine.
>
> Sai menzionarmi un po' di letteratura che mi dia le informazioni di cui
> hai scritto ?
>

Cartaceo direi che il top è "Expert .NET 2.0 IL Assembler" di Serge
Lidin, edizioni Apress, è fermo a net 2.0 perché è del 2006 ma secondo
me è ancora valido per capire i meccanismi che stanno dietro i vari
linguaggi del net framework.

> Ma ora mi rendo conto che nonostante la pubblicità, *qualcosa* di
> diverso esiste, ANCHE NELLE CLASSI che hanno lo stesso nome.

E mi sa che ti sbagli, e manco di poco. Controlla prima di tutto di
aver linkato le stesse classi. E secondo esiste il reflector, le
compili e guardi il codice in vb.net, c# o qualunque altro dialetto.

Da come lo dici, dovresti scrivere del codice vb.net, compilarlo,
decompilarlo in c# ed il codice dovrebbe essere diverso. Mah...

On Thu, 11 Mar 2010 22:03:36 +0100, 4r4g0rn wrote:

> asd perche' non hai mai usato delphi 6 che gli spaccava le chiappe a
> vb6! :-D

perchè non hai mai usato powerbuilder che sia a delphi che a vb che a
winforms (morto) che a wcf gli spacca il culo ancora oggi!

On Thu, 11 Mar 2010 17:32:40 -0800, riccardo wrote:

> ovvero la provenienza da un "mondo C"

c# è praticamente una copia 1:1 di java, non di c

In article <hnh74i$1or$2>, tre,
tre ha scritto...

>
> c# è praticamente una copia 1:1 di java, non di c

certo certo , come no :-)
Anche la una ferrari F50 è una copia 1:1 della prima automobile
costruita al mondo, ma tu potendo scegliere cosa guideresti?