meglio delphi o vb?

[willygos]

quale dei due linguaggi ha piu' potenzialita' ?

[matpez]

non vorrei dire un cag..ta ma penso VB!!

[mjordan]

Originally posted by "willygos"

quale dei due linguaggi ha piu' potenzialita' ?

Oggigiorno non è + una questione di "potenzialità" dei linguaggi quanto "quale linguaggio dispone di una buona libreria che assolve al compito che devo risolvere".

Sono 2 linguaggi con una sintassi molto semplice, orientati agli oggetti, facili da programmare.
Visual Basic vanta un gran numero di librerie esterne, Delphi è solo un ambiente di sviluppo per Object Pascal (Ok, ultimamente Borland ha unificato i nomi dell'IDE e del linguaggio, ma solo per coerenza, visto che sempre di Pascal si parla, mai rinnegare le origini ).

Delphi ha il vantaggio che è portabile (leggasi puoi compilare il codice sotto Linux) ed ha il vantaggio che molti compilatori Pascal (FreePascal in primis) includono un buon sottoinsieme di Delphi.

Visual Basic costa un sacco di soldi, è legato indissolubilmente a Windows, è proprietario e proprio perchè non legato ad un comitato di standardizzazione può essere soggetto nel tempo a qualche cambiamento di rotta da parte di Microsoft. Lo usa parecchia gente, + che altro perchè non è troppo complicato. Per giudicare dovresti darti un'infarinatura di entrambi e scegliere da solo.

A me non piace. Un requisito fondamentale che ritengo irrinunciabile in un linguaggio di programmazione è un comitato aperto che gli stia dietro nel processo di standardizzazione. Devo poter parlare di un linguaggio di programmazione indipendentemente dalla macchina che uso. Un linguaggio legato ad un sistema operativo non è molto di + di un linguaggio di scripting.

[cionci]

Originally posted by "mjordan"


Sono 2 linguaggi con una sintassi molto semplice, orientati agli oggetti, facili da programmare.

Visual Basic ha poco dell'OOP fino alla versione 6 Solo nella versione .Net si è rifatto un po'...

Comunque solo confrontando le potenzialità del framework Delphi è nettamente superiore a VB6.... Riguardo a VB.Net le proporzioni cambiano, ma bisogna sempre contare che il framework .Net è ancora troppo giovane (e riguardo alla portabilità è ancora rpesto per giudicarlo)...

[willygos]

quindi penso che mi cerchero' una buona guida di delphi perche' da quanto ho capito delphi ha piu' librerie ed e' piu' portabile

[Ronder17]

Vb.Net un linguaggio puro ad oggetti!
Inizia subito a studiarlo perchè ci saranno dopo tante evoluzioni...
Bye

[cionci]

Originally posted by "Ronder17"

Vb.Net un linguaggio puro ad oggetti!

Soprattutto puro !!!

Comunque vi dico come la penso su VB.Net e C#... Mai buttarsi sulla prima versione di un nuovo linguaggio...ancora di meno quando ha un framework altrettanto giovane e molto complesso come .Net...

[Ronder17]

Originally posted by "cionci"


Soprattutto puro !!!

Comunque vi dico come la penso su VB.Net e C#... Mai buttarsi sulla prima versione di un nuovo linguaggio...ancora di meno quando ha un framework altrettanto giovane e molto complesso come .Net...

Appunto perchè è un bambino bisogna allevarlo nel miglior dei modi cosi quando il bambino crescerà Sarà riconoscente
A parte l'ironia, insieme a me ci si stanno buttando anche tante aziende a marzo 2003 uscirà la versione finale.....
Brivido.....

[roentgen]

sono un delphino nato, ma ho anche programmato in VB. Ho abbandonato dopo pochissimo VB quando, uno dei primi programmini che avevo scritto, un'interfaccia in autoavvio per un cd contenente del software masterizzato, ha ben deciso di non partire sul pc dell'amico a cui quel cd era destinato poichè mancavano le arcinote VBrun ecc. ecc. .dll. Certo oggi quel problema non si presenterebbe più ma VB genera eseguibili mediamente più lenti di quelli generati da Delphi, forse perrchè i suoi .exe non sono veri .exe ma listati che vengono interpretati da librerie. Non so nelle ultimissime versioni come le cose si siano evolute per VB...

[cionci]

Originally posted by "Ronder17"

Appunto perchè è un bambino bisogna allevarlo nel miglior dei modi cosi quando il bambino crescerà Sarà riconoscente
A parte l'ironia, insieme a me ci si stanno buttando anche tante aziende a marzo 2003 uscirà la versione finale.....
Brivido.....

Sinceramente tutte le aziende che conosco e che programmano in VB non si sono ancora buttate su .Net...
Mi sembra o il framwork .Net non gira su Windows 95 e 98 ?

[pippo985]

Io nasco come programmatore VB e ti dico che ci ho fatto praticamente di tutto. Quindi sono un pò di parte
Però a mio avviso, se integrato con le altre applicazione M$, va sicuramente meglio di Delphi.
Anche per il lavoro con DB è un pelino più veloce.
Il contro è che ti devi portare dietro le librerie Runtime.
Il mercato richiede sia Delphi che VB.

Fai te!

[Ronder17]

Originally posted by "roentgen"

sono un delphino nato, ma ho anche programmato in VB. Ho abbandonato dopo pochissimo VB quando, uno dei primi programmini che avevo scritto, un'interfaccia in autoavvio per un cd contenente del software masterizzato, ha ben deciso di non partire sul pc dell'amico a cui quel cd era destinato poichè mancavano le arcinote VBrun ecc. ecc. .dll. Certo oggi quel problema non si presenterebbe più ma VB genera eseguibili mediamente più lenti di quelli generati da Delphi, forse perrchè i suoi .exe non sono veri .exe ma listati che vengono interpretati da librerie. Non so nelle ultimissime versioni come le cose si siano evolute per VB...

Leggi come sono strutturati gli assembly del vb.net poi fammi sapere...

[cionci]

Originally posted by "Ronder17"


Leggi come sono strutturati gli assembly del vb.net poi fammi sapere...

Gli eseguibili di VB.Net sono molto vicini a quelli di cui parlava roentgen (P-Code se non sbaglio, presenti nelle versioni 3 e 4 di VB)...
Sono in un codice intermedio diverso dal codice macchina...

[roentgen]

Originally posted by "Ronder17"


Leggi come sono strutturati gli assembly del vb.net poi fammi sapere...

non ho mai disassemblato un prg scritto in .NET

Originally posted by "cionci"


Gli eseguibili di VB.Net sono molto vicini a quelli di cui parlava roentgen (P-Code se non sbaglio, presenti nelle versioni 3 e 4 di VB)...
Sono in un codice intermedio diverso dal codice macchina...

...ergo non sono eseguibili "puri" ma bordate di chiamate (più o meno lente) a librerire esterne.

Ho disassemblato però un prg compilato dal compilatore di Delphi e so che è codice nativo (lo capisci se hai un minimo di dimistichezza con l'assembly e ci puoi "navigare" dentro con una certa facilità).

Fino a quando VB non compilerà in codice macchina puro non me ne interesserò...

...forse sono solo "fisse" da delphino ma tant'è...

[Kleidemos]

Per assebly del .NET nn itendeva gli exe, penso, ma i manifesti applicabili al prog; una delle nevota del .NET.[/code][/quote]

[cionci]

Originally posted by "roentgen"


Fino a quando VB non compilerà in codice macchina puro non me ne interesserò...

Allora comincia a perdere la speranza vista la direzione che stanno prendendo tutti i linguaggi che supportano .Net...

[atragon]

Idea personale: .NET e quindi VBNet è fortemente improntato verso le applicazioni Web....incidentalmente, se mi passi il termine, sei in grado di creare applicazioni x Win, anche efficienti, ma il suo core business è verso il mondo Internet. Se ti serve qualche cosa decisamente orientato al sistema operativo allora vai con Delphi che, tra l'altro, non ti preclude la possibilità di creare applicazioni web oriented e che, con Kylix, garantisce una certà portabilità verso Linux.

[cionci]

Originally posted by "atragon"

Idea personale: .NET e quindi VBNet è fortemente improntato verso le applicazioni Web....incidentalmente, se mi passi il termine, sei in grado di creare applicazioni x Win, anche efficienti, ma il suo core business è verso il mondo Internet. Se ti serve qualche cosa decisamente orientato al sistema operativo allora vai con Delphi che, tra l'altro, non ti preclude la possibilità di creare applicazioni web oriented e che, con Kylix, garantisce una certà portabilità verso Linux.

Sottoscrivo

[Ronder17]

Originally posted by "Kleidemos"

Per assebly del .NET nn itendeva gli exe, penso, ma i manifesti applicabili al prog; una delle nevota del .NET.[/code]

[/quote]
Esatto... io mi riferivo al manifest dell'assembly che contiene i metadati;metadati che in poche parole descrivono,identificano l'assembly e tutte le altre dipendenze di files, risolvono i tipi, le dichiarazioni e le implementazioni.Cioè forniscono una descrizione completa all'ambiente di runtime.
E bene, gli assembly possono essere statici, dinamici, privati e condivisi.ognuno di queste quattro nature di assembly è strutturato in maniera diversa. Il CLR(COMMON LANGUAGE RUNTIME) dovrà poi controllare la natura degli assembly i loro riferimenti, i criteri di sicurezza e altro ed è proprio il CLR che in questa fase si differisce molto dal vb6.
Il CLR infatti quando si esegue un file.net esamina l'assembly,compila prima in MSIL trova i metadati , ne verifica il codice e solo dopo compila in JIT,(in codice macchina)quindi esegue!A questo punto avviene proprio come per il Java si ha la gestione automatica della memoria (GL) e le risorse vengono liberate.
Inoltre Il CLR del .Net gestisce più versioni dello stesso assembly simultaneamente, questo significa che quando si installeranno versioni nuove dell'applicazione, non ci si dovrà più preoccupare di mantenere la compatibilità tra le librerie e componenti che a loro volta non necessitano della registrazione come in passato.
non è più come in passato, quando si dovevano magari scrivere in c++ componenti per il vb, ma esatamente il contrario; adesso è possibile creare componenti e librerie di classe per altre piattaforme compatibili col CLS quali il visual c++ .net e visual c#. tutto questo va a costituire L'INTEROPERABILITA' tra linguaggi.
Questo sono solo dei granelli di sabbia di quello che rappresenta il framework .net adesso! L'edizione finale del visual studio.net uscirà a marzo per quello che ne so...e ci saranno sicuramente tante altre novità.
Ecco perchè ritenevo che cmq chi è intenzionato a passare un domani a vb.net era meglio che lo facesse subito, in maniera tale da avere già chiari i concetti base e recepire velocemente dopo tutte le implementazioni del linguaggio
Esprimentevi pure adesso....

[cionci]

Ok...ma fatto sta che il codice in qualsiasi forma di una qualsiasi applicazione .Net è un codice intermedio e non un eseguibile come avviene in altri ambienti/piattaforme...