[OT] Perché non dividere il forum in due?

[esposito]

Salve, non vi sembra una buona idea dedicare un forum a VB6 ed un altro a VB.NET, considerato che si tratta di due tecnologie completamente diverse?

Ciò semplificherebbe di molto la vita di chi, come me, è interessato soltanto ad uno dei due ambienti.

[xegallo]

Originariamente inviato da esposito
Salve, non vi sembra una buona idea dedicare un forum a VB6 ed un altro a VB.NET, considerato che si tratta di due tecnologie completamente diverse?

direi di no se si specifica linguaggio e versione è molto difficile fare confusione

Ciò semplificherebbe di molto la vita di chi, come me, è interessato soltanto ad uno dei due ambienti.

e la complica a chi li usa entrambi

[alka]

Già c'è molta gente che sbaglia forum pur essendocene solamente due, uno principale dedicato a tutti i linguaggi, uno secondario riguardante VB e il .NET Framework in generale...figuriamoci se ce ne fossero altri ancora.

Ciao!

[Kahm]

direi di creare un forum per vb3
direi di creare un forum per vb4
direi di creare un forum per vb5
direi di creare un forum per vb6
direi di creare un forum per vb.net
direi di creare un forum per framework 1.1
direi di creare un forum per framework 2.0
direi di creare un forum per c#
direi di creare un forum per vba

uhm infatti mi sa che sono troppi
poi i linguaggi si somigliano cosi tanto che se uno trova la soluzione per un problema il codice per il 90% se è vb6 puo andar bene aneh per vb.net e forse (in senso logica) per c#

[xegallo]

se la discussione rimane seria lka proposta si può anche considerare altrimenti chiudiamola pure qui.

[Luciano79]

Ho visto domande su VB.NET con risposte del tipo:
"Non so su VB.NET, ma su VB6 funziona che..."
e parecchie volte va anche bene.
Quindi possiamo comunque darci una mano tutti quanti, in fondo ci sono parecchie cose in comune.

[Kahm]

Originariamente inviato da xegallo
se la discussione rimane seria lka proposta si può anche considerare altrimenti chiudiamola pure qui.

:master:


@esposito
esistono gia forum su inetrnet che distintguono tra .net e vb6
e sinceramente ritrovo soluzioni ripetute

[raffaeu]

No!
Primo perché io sono uno di quegli esempi che usa sia VB NET che VB 6 e mi trovo bene cosi' ...

Secondo proprio perchè a volte si confrontano codici 6 e NET per arrivare a una soluzione.

A me sembra solamente dispersivo avere piu' forum per un' unica Tecnologia.

[Kahm]

Originariamente inviato da raffaeu
No!
Primo perché io sono uno di quegli esempi che usa sia VB NET che VB 6 e mi trovo bene cosi' ...

Secondo proprio perchè a volte si confrontano codici 6 e NET per arrivare a una soluzione.

A me sembra solamente dispersivo avere piu' forum per un' unica Tecnologia.

senza pensare che j# ha molte funzionalita e parole chiave identiche a vb.net e c# dove lo metteremo questo forum?

ah..una cosa
premetto che esiste gia un forum che si parla di tecnologia .net ma è diverso da questo---->il forum di asp.net
ebbene se controlli molte sluzioni possono funzionare anche in vb!
solamente che ragionando forse è stato meglio in questo senso creare un forum ulteriore,

[Brainjar]

Secondo me la questione si pone in questi termini :

VB60 è stata l'evoluzione della rivoluzione VB come strumento RAD.
Dove per RAD ci si riferisce al Rapid Application Development.
Per un decennio, infatti, VB X.0 ha rappresentato lo strumento per
creare rapidamente 'prototipi di applicazioni' funzionanti a cui,
inizialmente mancavavo tutte quelle funzionalità e peculiarità di una
applicazione Win32.

All'inizio, e parlo della versione 1.0, non esistevano accessi a DB,
controlli griglia e oggetti data. Tutto era demandato a DLL win32
scritte in C++ (Visual C++) e componenti di terze parti (VBX e OCX).
Basti pensare ai prodotti di Pinnacle, Sheridan, Q+E, APEX ecc..

Con il tempo VB ha assunto una propria indipendenza e ha acquistato
sempre più potenza e popolarità.

Con l'avvento prima di COM e MTS e poi di COM+, VB 6.0 è diventata
una 'piattaforma' completa per lo sviluppo di applicazioni anche
complesse in ambiente Enterprise.

Grandi gruppi Assicurativi e Bancari hanno attualmete le operazioni
di sportello e di agenzia completamente scritte in VB 6.0.
Difficilmente, passeranno, nellimmediato ad applicazioni .NET.
VB 6.0, però, resterà lo strumento utilizzato principalmente dai
free-lancers per le loro applicazioni.

Se devo fare un programma per la 'gestione delle gare di pesca alla
trota', non la faccio in Java, ma in VB 6.0. Perchè :
1) Le forms le creo in un momento e non con passaggi complessi
con creazione di oggetti JFrame e JTable ecc...
2) La manutenzione del codice VB, se ben strutturato, non ha
equivalente con quella per Java (ed è anche una questione di
cap, ovviamente)
3) Posso cominciare da un 'giocattolino' minimale e avere il tempo
di consolidare l'applicazione aggiungendo parti e funzionalità,
cosa che con Java, e ci lavoro da tre anni, non è così semplice.
4) .....

Venedo a DOT.NET, questa è la risposta Microsoft a Java e
della programazione OOP (OOA, OOD, OOP) che miete sempre più
consensi. Il framework è il tentativo di opporsi a Linux.
(Questo ovviamente è il mio personalissimo parere....)

Questa lotta, comunque, coinvolgerà quasi esclusivamente grosse
realtà informatiche, e grossi progetti. Per cui ci sarà sempre
il progetto delle dimensioni adatte ad essere sviluppato in VB 6.0 e
ci sarà sempre il cliente che lo richiederà.

Per raggiungere i livelli di produttività di VB 6.0 un programmatore
dovrà fare, oltre al già citato salto di mentalità, anche molto
lavoro di studio e di prova per trasferire le sue competenze nel
nuovo ambiente di sviluppo Lo stesso che farebbe per passare da
VB 6.0 a Java.

Quindi per me VB.NET non può definirsi un ambiente RAD come lo
è stato e sempre lo sarà VB 6.0.

Per cui IMHO il Forum dovrebbe rimanere tale e quale ad adesso, con
il solo spostamento di VB.NET e C# in Programmazione, lasciando il
sub Forum VB 6.0 e 'inferiori'.

Il primo 'Programmazione' accomunerebbe programmatori OOP che hanno
la reale necessità di un confronto su tematiche rigorose e lineari
come appunto la OOP, il secondo accomunerebbe quei programmatori
che sono dei 'fornitori di soluzioni ad utenti finali' che per la
loro stessa natura (le soluzioni) non avranno mai la connotazione
di applicazioni enterprise.

Ciao,