[OT] Conviene davvero aggiornarsi a VB.NET?

[alka]

Originariamente inviato da Kahm
vb6 era un linguaggio ad alto livello proprio per questo

La definizione di "linguaggio di alto livello" si riferisce a quanto un linguaggio è in grado di astrarre dall'architettura e dal sistema operativo sottostante rispetto ai linguaggi macchina e non alla quantità e alla tipologia di possibilità che offre.

Infatti, per fare un esempio, Delphi non potrebbe essere considerato di basso livello rispetto a VB6 solo per il fatto che fornisce già da tempo il supporto alla OOP, overloading e tante altre feature.

Originariamente inviato da Kahm
in effetti gli overloading, classi e altre stupidaggini sono sempre esistite, è solo che la microsoft nascondeva il tutto e ti mostrava il codice pulito pulito

Chiamarle "stupidaggini" mi sembra eccessivo: in fondo, sono tecniche che sviluppatori (non VB6) usano da tempo e in modo proficuo.

Ad ogni modo, i controlli ActiveX disponibili in VB6 "di serie) forniti da Microsoft sono stati realizzati con C++, linguaggio in cui le feature suddette sono state presenti da sempre quindi, in effetti, non è possibile escludere che siano comunque state utilizzate.

Originariamente inviato da Kahm
quello che i programmatori che hanno creato visual basic 6 , secondo te nn hanno usato neanche un overloading, una classe? secondo me si, e pure a bizzeffe

Non sarei così fiducioso nei confronti degli sviluppatori Microsoft.
Se confrontato con gli ambienti di sviluppo concorrenti, come Delphi, di allora così come si evince dal salto qualitativo fatto adesso nel passaggio a .NET, direi che l'ambiente VB6 in quanto tale era piuttosto limitativo.

Comunque, i mezzi utilizzati dagli sviluppatori VB6 per costruire l'ambiente sono irrilevanti: ciò che conta è quanto viene reso disponibile agli utenti.

Originariamente inviato da Kahm
ma essendo progettato come un ambiente RAD per utenti sia con poca esperienza che esperti, ovviamente molte cose andavano nascoste (nn credi?)

Non sarei così d'accordo. Un ambiente RAD è progettato per rendere appunto, come indica l'acronimo, veloce lo sviluppo di applicazioni; questo non significa dover nascondere o limitare le funzionalità del linguaggio.

Sono recidivo ma prendo di nuovo come esempio l'ambiente Delphi: il linguaggio ha sempre fornito pieno supporto alla OOP permettendo lo sviluppo rapido ma lasciando, all'occorrenza, la possibilità di scendere nei dettagli implementativi e di approfondire tecnicamente quanto avviene nell'ambiente.

La definizione che attribuisci all'ambiente RAD non è adatta, poichè così come la proponi non sarebbe allora applicabile a VS.NET, mentre VS è a pieno titolo un ambiente RAD, che consente lo sviluppo rapido di applicazioni fornendo un supporto completo a designtime ma consentendo, attraverso l'immissione automatica di codice, di poterlo vedere e modificare, nonchè di poter sfruttare caratteristiche nuove (per il solo linguaggio VB.NET rispetto a VB6) ampliando le possibilità fruibili dall'ambiente precedente che erano piuttosto limitato.

Originariamente inviato da Kahm
ora è tutto visibile, e puoi interagire con le classi,
facendo in vb6 nomeform.show, ovviamente il codice sottostante faceva tutto , ora devi gestirlo tu
praticamente la pappa è la stessa, cambia solo il modo di programmare, in quanto puoi manipolare meglio tutti gli oggetti che ti mette a disposizione l'ambiente di sviluppo

Concludendo, il linguaggio supporta ora la programmazione ad oggetti (OOP) e, pertanto, per poterlo utilizzare al meglio e fino a fondo è conveniente conoscere i dettagli di questo paradigma o metodologia di programmazione; solo in questo modo si costruisce software decente e ottimale, usando in modo appropriato lo strumento.

E' chiaro che se questa metodologia non viene assimilata dal programmatore VB.NET, si incontreranno solamente difficoltà rispetto all'uso di VB6 e si avrà una visione distorta del primo poichè non si è in grado di valutare le potenzialità rispetto al secondo.

Ciao!

[esposito]

Domanda (forse banale) rivolta a chi conosce bene sia VB6 sia VB.NET: considerando soltanto lo sviluppo di applicazioni Win32 lato desktop, che cosa è possibile realizzare in VB.NET che non è possibile realizzare in VB6?

Per quanto riguarda lo sviluppo per il Web, so bene che a VB6 mancano tutte le potenzialità di ASP.NET, quindi eviterei di trattare questo aspetto.

Badate che la mia non è una domanda provocatoria: mi piacerebbe soltanto che qualcuno illustrasse i vantaggi nell'utilizzare VB.NET spiegando ciò che costituisce prerogativa del managed code nella realizzazione di eseguibili per Windows.

In altre parole, prescindendo da questioni quali la robustezza del Framework o la rapidità nel realizzare applicazioni, la mia domanda è: esistono tipi di applicativi Win32 lato desktop che è possibile sviluppare solo in VB.NET e non in VB6?

Grazie in anticipo.

[alka]

Originariamente inviato da esposito
Domanda (forse banale) rivolta a chi conosce bene sia VB6 sia VB.NET: considerando soltanto lo sviluppo di applicazioni Win32 lato desktop, che cosa è possibile realizzare in VB.NET che non è possibile realizzare in VB6?

Rispondere a questa domanda è sempre stato abbastanza semplice, poichè è sufficiente valutare cosa può essere fatto in Delphi, sfruttando la OOP, a discapito di VB6 in cui è quasi totalmente assente questo concetto.

Per citare un caso del tutto pratico, non è possibile ad esempio creare un finestra delle proprietà riferite ad un elemento della propria applicazione visualizzandola in "duplice copia", poichè non esistono le istanze di un form: in VB6, ciascun form è allo stesso momento classe e istanza del form.

Non essendo presente un concetto di classe completo, non si riutilizza completamente il codice ma, spesso, per creare qualcosa di simile a ciò che si ha già modificandolo leggermente per un caso specifico è necessario fare "copia e incolla" duplicando automaticamente tutti gli errori eventuamente presenti al suo interno, rendendone davvero difficile la manutenibilità, a discapito della qualità generale del software e dei tempi di sviluppo.

Prendiamo la questione del threading: è totalmente assente come concetto all'interno di VB6 che sono notoriamente "mono thread", escludendo così una vasta gamma di soluzioni possibili e generalmente diffuse e adottate in altri linguaggi concorrenti, basati sulla piattaforma .NET e non.

Costruire interfacce utente complesse, ad esempio simili ad Outlook, diventa impossibile a meno di non ricorrere totalmente all'uso delle API.

Sulla gestione degli errori, per toccare un altro aspetto, credo che le differenze sostanziali tra VB6 e VB.NET siano evidenti senza entrare troppo nel merito.

Solo questi aspetti meriterebbero un passaggio istantaneo da VB6 a VB.NET.

Ce ne sono senz'altro tanti altri che però al momento non mi vengono in mente (e inoltre, sono collegato da casa e non ho molto tempo), ma posso sempre aggiungere integrazioni in seguito se l'argomento nel dettaglio interessa molto.

Per il momento, spero di aver scritto a sufficienza.

Ciao!

[XWolverineX]

Bhe tornando alla mia opinione,
cosi microsoft ha trasformato il vb in uno dei tanti linguaggi come gli altri, mentre il vb6 è il linguaggio della velocità, senza dubbio...
Limitato ma veloce.
Rapidi sviluppi aziendali in modo pressappoco istantaneo

"Perchè non ti fai i cazzi tuoi e non rimanete sul Vb6 allora?"
Mi direte...
Perchè non sarà supportato e aggiornato piu'.
Addio!!

[Jupy64]

Originariamente inviato da XWolverineX
Bhe tornando alla mia opinione,
cosi microsoft ha trasformato il vb in uno dei tanti linguaggi come gli altri, mentre il vb6 è il linguaggio della velocità, senza dubbio...
Limitato ma veloce.
Rapidi sviluppi aziendali in modo pressappoco istantaneo
....

beh..non direi proprio!
Una volta familiarizzato con VB.NET, ti rendi conto che sviluppare programmi è più facile e veloce del VB6!

[esposito]

Originariamente inviato da alka

Costruire interfacce utente complesse, ad esempio simili ad Outlook, diventa impossibile a meno di non ricorrere totalmente all'uso delle API.

Potresti essere più preciso? Qual è l'elemento dell'interfaccia di Outlook così complesso da non poter essere realizzato in VB6?

Originariamente inviato da alka
Sulla gestione degli errori, per toccare un altro aspetto, credo che le differenze sostanziali tra VB6 e VB.NET siano evidenti senza entrare troppo nel merito.

Io non ho ancora trovato l'equivalente di "On Error Resume Next" in VB.NET e devo dire che in qualche caso questa mancanza rappresenta un serio problema, dato che il metodo "Try/Catch/End Try" non riesce a sopperire a tale funzione.

[cassano]

puoi sempre usare on error resume next non te lo vieta nessuno.

[alka]

Originariamente inviato da XWolverineX
Bhe tornando alla mia opinione,
cosi microsoft ha trasformato il vb in uno dei tanti linguaggi come gli altri, mentre il vb6 è il linguaggio della velocità, senza dubbio...
Limitato ma veloce.
Rapidi sviluppi aziendali in modo pressappoco istantaneo

Con VB6 è la stessa cosa. Basta conoscerlo.

Originariamente inviato da XWolverineX
"Perchè non ti fai i cazzi tuoi e non rimanete sul Vb6 allora?"
Mi direte...
Perchè non sarà supportato e aggiornato piu'.
Addio!!

Ahimè, le cose cambiano così come cambiano le esigenze e le caratteristiche dei prodotti nati per risolverle.

Usa le tue conoscenze di VB6 per avere una base di familiarità da unire alla tua buona volontà per studiare VB.NET: gli sforzi saranno apprezzati.

Più che addio, vedilo come un "a buon rendere"!

[alka]

Originariamente inviato da esposito
Potresti essere più preciso? Qual è l'elemento dell'interfaccia di Outlook così complesso da non poter essere realizzato in VB6?

Tutto. Prendi l'applicazione come esempio nelle sue caratteristiche peculiari: un'area centrale in cui vi sono pagine intercambiabili che hanno alcune caratteristiche in comune, altre invece diverse (specializzazioni) che vengono create dinamicamente e visualizzate nella parte centrale dell'applicazione, oltre a finestre di dialogo (come quella di un contatto, ad esempio) che può essere aperta più volte relativamente a contatti diversi.

In realtà, è difficile analizzare l'esempio sotto questo aspetto: si dovrebbe vedere quanto è facile implementare una cosa simile in VB.NET e, allo stesso tempo, quando è impossibile farlo con VB6.

Originariamente inviato da esposito
Io non ho ancora trovato l'equivalente di "On Error Resume Next" in VB.NET e devo dire che in qualche caso questa mancanza rappresenta un serio problema, dato che il metodo "Try/Catch/End Try" non riesce a sopperire a tale funzione.

Serio problema??
Il costrutto On Error Resume Next è un obrobrio che non ha alcun senso di esistere: gli errori vanno gestiti attraverso un apposito costrutto che, a seconda dell'errore, compia operazioni specifiche e, nel caso in cui tale errore non venga gestito, vi sia comunque a monte una gestione predefinita dell'errore stesso, che interrompa l'esecuzione del metodo risalendo lo stack delle chiamate.

Gestire un errore in modo preciso e serio richiede costrutti ben strutturati, non l'indicazione di procedere alla riga successiva quando avviene un errore di qualsiasi tipo, oltre al fatto che se ci si dimentica di indicare questa clausola il programma termina inesorabilmente.

Inoltre, il costrutto Try...Catch...End Try gestisce ottimamente e nel modo corretto tutte le problematiche di sollevamento di un'eccezione. Dove sta il serio problema? :master:

[alka]

Originariamente inviato da cassano
puoi sempre usare on error resume next non te lo vieta nessuno.

Se usi On Error Resume Next all'interno di VB.NET, qualcosa te lo vieta senz'altro: il...buon senso!