Newsgroup: it.comp.lang.c++
Titolo: Come mai Visual Basic viene preferito al C++?

Non riesco proprio a capire come mai in tutte le ditte di programmazione
viene preferito il Visual Basic al C++.Ce ne sono alcune che addirittura si
accontentano del Visual Basic 3.0(per Win 3.1)che é vecchio e
limitatissimo.Insomma:il C++ é molto più veloce, molto più
stabile,affidabile e generalmente ha un sacco di possibilità in più.Invece
in VB basta fare un paio di 'for' annidati per farlo rallentare,e
complessivamente non mi pare che sia molto più facile da utilizzare rispetto
al C++.Allora come mai nelle ditte di programmazione viene strapreferito?
Il Ghenio

 wrote in message 7nu8rd$gk7$1...@nslave1.tin.it...


A mio parere è unicamente una questine di costi:
Al di là del fatto che fornire ad uno staff di
sviluppo un ambiente integrato VC++ comporta una
spesa maggiore che non il corrispettivo in VB, la
vera differenza è data dal costo orario dei programmatori.
Oggigiorno chiunque utilizzi un PC per lavoro conosce 2
cose: come si scrive una pagina HTML e come si programma
(anche se spesso molto alla lontana) in VB. Un programmatore
di VC++ competente (cosa che ancora non mi sento di essere)
è una persona che in generale si è fatta un mazzo così ed
ha affrontato spese non trascurabili per acquisire le
competenze che adesso possiede ed ovviamente quando mette
queste competenze a disposizione di terzi vuole (ed a buon diritto)
essere pagato per quanto vale. Problema: il committente tipo
non distingue tra un ambiente di programmazione ed un altro
(altrimenti le applicazioni se le scriverebbe da solo)
, in generale se si lamenta perchè il programma è lento gli si dice: 
guardi che il suo sistema è obsoleto, lei necessita di
un upgradare tutto. E questo (imho) e quanto.

 al C++.Allora come mai nelle ditte di programmazione viene strapreferito?
Perché i programmatori (?) Visual Basic costano meno e producono più in
fretta. Poco importa poi alle ditte se il prodotto ottenuto è meno
efficiente, tanto li pagano lo stesso. :-(
EMG

essere pagato per quanto vale.
Penso comunque che chi ha imparato il Basic possa imparare benissimo anche
il C++,soprattutto adesso.Mi pare di aver visto infatti che il VB
strutturalmente somigli sempre di più ad un compilatore,pur non essendolo.
Il Ghenio

al C++.Allora come mai nelle ditte di programmazione viene strapreferito?
Perche` spesso chi dirige una societa` di sviluppo software poco o niente
gli interessa di come un programma viene fatto. L'importante e` che funzioni
in qualche modo e si faccia in fretta a farlo. Se poi e` lento basta dire al
cliente che ha una macchina obsoleta.
Dalla mia breve esperienza lavorativa ho notato che i concetti di
manutenibilita` e riusibilita` del codice sono quasi sconosciuti.
In giro si trovano tanti smanettoni, ma gente che sa veramente programmare
ad oggetti ce ne` poca.
I RAD sono utili se uno sa quel che fa, altrimenti sono solo dannosi :
tutti sanno trascinare i componenti sulle forms, pochissimi hanno voglia
di ingegnerizzare una gerarchia di classi per gettare delle fondamenta
robuste ad un programma e renderlo facilmente estendibile e/o modificabile.
-- 
Ing. Roberto Gerola
Email: 
robert...@penguinpowered.com
WWW: 
http://www.penguinpowered.com/~The_Cpp_Compass

 ad oggetti ce ne` poca.
Solo una piccola nota: per essere programmatori in gamba non è
indispensabile saper programmare ad oggetti.
EMG

indispensabile saper programmare ad oggetti.
Sono d'accordo.Ho da poco letto un articolo su PDJ in cui si diceva la
stessa cosa e si criticava i famosi 'integralisti della programmazione ad
oggetti'.
Il Ghenio


Non e` questione di essere integralisti, ma e` indubbio che la programmazione
ad oggetti e` fondamentale per spingere al massimo sulla riusabilita`, manu-
tenibilita` e leggibilita` del codice.
Trovo inoltre estremamente piu` naturale quando devo sviluppare un nuovo
programma affrontare il problema pensando ad oggetti che non facendo una
decomposizione top-down.


robuste ad un programma e renderlo facilmente estendibile e/o modificabile.
Parole sante!
Il software spesso funziona male non perché il problema sia molto complesso, ma
semplicemente perché è scritto male. Papale papale. Poi, se vogliamo dare la colpa a
Windows (che comunque non è uno stinco di santo, tanto per intenderci), all'hardware
obsoleto, alla stella cometa o alla fine del mondo che verrà, padronissimi di farlo.
Assumersi le proprie responsabilità, in primis come sviluppatori e proggettisti, richiede
innanzitutto di abbandonare l'ottica "da smanettoni".
Non è una flame gratuita, ma solo una *personale* analisi di un trend diffuso e
generalizzato.
Chi produce software, il più delle volte, non sa neppure che significhi ingegneria del
software, software quality assurance o design architetturale. Che te ne fai del tuo design
architetturale e ammenicoli vari quando ci sono prodotti come VB che ti scrivono il 70-80%
del codice di cui hai bisogno? Vallo a spiegare tu... Non è solo un problema di capacità
prettamente tecniche.
Andrea

 wrote:
Perchè è decisamente più rapido. Fino a che sviluppi software
semplice, il VB è un sogno. VB diventa uno strumento pessimo appena
esci dai binari previsti da mamma M$.
In più, la maggior parte delle ditte vuole piccoli DB, e (sempre per
piccole applicazioni), realizzare un DB in Access + VB è
incredibilmente più rapido che scriverlo in C++.
Che poi Acces+VB sia la soluzione meno affidabile, meno elegante, più
lenta e pesante, più soggetta a bug e piantamenti, poco importa alla
ditta, che punto più a pagare poco lo sviluppatore e a consegnare in
fretta il lavoro.

 rapidità di calcolo é basilare e questo rende il C++ una scelta obbligata...
Guarda, secondo me hai centrato il punto. Non esiste un linguaggio
globale,
uno in grado di essere il migliore tool di sviluppo per qualsiasi
progetto.
Sono d'accordissimo, il C++ è generalmente la soluzione migliore, e
teoricamente
sempre la scelta ideale (se escludi la programmazione ASM). Ma appena
metti in
conto produttività, tempi di realizzazione, e soprattutto specifiche del
committente,
la cose spesso cambiano notevolmente. A volte la soluzione "migliore"
può essere
un file word con all'interno una macro scritta in VBA (sa... devo
stampare delle fatture
ed inserire i nomi dei miei clienti e le cose che ordinano, mi serve tra
due settimane o
non se ne fa niente:
n.b.: mi è capitato.)

A mio parere e' un problema di cultura.
Innanzitutto c'e' da considerare che VB risponde molto al motto 'facile e'
bello'.
La situazione e' che molte aziende che sono sul mercato da vecchia data (ed
hanno esperienze, e capitali per investire, di conseguenza) hanno prodotti
che sono anche loro di vecchia data, e ovviamente con la rivoluzione
tecnologica in atto si scoprono che sono rimasti obsoleti o arretrati.
A questo punto si trovano davanti a scelte quantomeno di difficile
misurazione.
Da un lato sanno che cosa significa riprogettare un prodotto completamente,
e sono molti soldi, basta fare una semplice moltiplica : costo di un
dipendente annuo * numero di anni uomo necessari.
Tanto per dare delle cifre, neanche tanto lontane dalla realta, un prodotto
non estremamente complesso che gestisca una azienda commerciale medio
piccola (si intende 5-15 posti di lavoro)
abbisogna circa di 6 anni uomo per la realizzazione e stabilizzazione.
NB. 6 anni uomo si ottengono con 6 persone x 1 anno o 3 x 2.
Considerando la velocita' dell'evoluzione tecnologica, a causa della spinta
sempre crescente dell'offerta di tecnologie x necessita' varie (vedi bilanci
MS o IBM o HP o tanti altri) diluire l'investimento su un arco temporale
superiore diventa automaticamente disastroso : significa costruire un
prodotto che e' gia' obsoleto, e con necessita' di continuo adeguamento.
D'altro canto utilizzare le tecnologie nuove per non dir nuovissime e'
sempre un salto nel buio.
Comunque 6 persone costano circa 50 MLN  l'una (costo azienda di 1800 netti
al mese) e il totale e' 300.000.000. Per una software house che fa circa 5
MLD di fatturato diventa una cifra interessante poiche' gia' a tavolino
siamo intorno al 6/7% del fatturato (circa) che considerato i margini
attuali non e' poi poco.
Da considerare che la spesa e' senz'altro superiore xche' ci sono tutti i
costi accessori.
Infine bisogna poi considerare il piano di rientro dall'investimento.
Un prodotto del genere quando viene venduto bene a listino porta in casa
circa 10MLN x 8 posti di lavoro.
Per poter rientrare dalle spese vive occorre almeno venderne 30 nei due anni
successivi, seguire i clienti, sperare che non ci siano troppi BUG,  e/o
puntare a rivenderlo su scala nazionale tramite rivenditori.
Notare che ho parlato di un gestionale commerciale e non di produzione
(leggi ERP).
A questo punto mettiamo in gioco la tecnologia ad oggetti, e mi fermo alla
OOP e non a COM o DCOM o CORBA.
I titolari delle software house sono persone che con tutta probabilita' non
fanno piu' della programmazione, ma si occupano solo del lato commerciale
della azienda.
Queste persone hanno fondamentalmente una cultura di tipo RPG o COBOL.
Ai loro occhi non c'e' molta differenza, la cosa viene vista come un utente
fniale, tra una immagine video basata su una pagina HTML, un programma VB o
su una serie di classi C++ con ereditarieta' e poliformismi vari.
Che metro hanno per decidere quale sara' la tecnologia di piu' lunga portata
negli anni.
Bisogna considerare che un prodotto deve durare almeno 10 anni, altrimenti
sono soldi sprecati.
Vi ricordate come erano le tecnologie nel 1989 ? Avete presente quanto sono
cambiate ?
Che cosa c'e' di piu' bello che un RAD che genera l'80% del codice da solo,
comprime i costi di sviluppo a circa un 30% o meno, e trovi programmatori,
spesso ragazzi di 20 anni che non hanno grosse pretese economiche ?
E' una decisione presa per ignoranza.
Io personalmente e aziendalmente, non la condivido.
Nella mia azienda i programmi vengono sviluppati in C++, quelli che mi
conoscono da tempo del NG lo sanno gia', per una serie di motivi che io
ritengo fondamentali, tra cui la lunghezza della vita del linguaggio e la
portabilita' fuori dal mondo dei WIN (Oggi leggi LINUX domani BEOS ? o MAC
?).
Per dire il mio parere riguardo l'investimento, con una base del genere
posso permettermi di diluirlo nel tempo molto + a lungo di quello che dovrei
fare con VB.
Questa e' un opinione personale e anche non condivisibile, ci mancherebbe !
Allo stato attuale delle cose, i fatti mi stanno dando ragione, poi del
futuro non v'e' certezza alcuna .....
(magari conosco una bella tibetana, mi separo da mia moglie e vado con lei a
portare le capre al pascolo, ecc. ecc. )
Saluti a tutti.
ZEC



Solo una piccola osservazione SOLO 1800 netti????? Qui il meno che prende
sono io e ne prendo 2500 netti (12 anni d'esperienza), vogliamo aprire un
dibattito sugli stimendi?
Ciao

--
Posted from 
vela.split.it
 [194.244.84.6]
via Mailgate.ORG Server - 
http://www.mailgate.org


Guarda che sono stato basso come valori !
Il fatto che gli stipendi siano piu' alti significa solo che i costi per
l'azienda sono piu' alti e
quindi l'investimento e tutto di conseguenza.
Per tua informazione con 2.5M netti si ha un costo aziendale circa di 70M
annui.
Fai tu le moltipliche di conseguenza.
Per quel che riguarda il fatto che lo stipendio di 1.8M sia basso per una
persona con 12 anni di esperienza potrei essere d'accordo (mi riservo una
valutazione di capacita', conoscenze, competenza), ma se trovi chi puo'
permettersi di fare investimenti a lungo termine con persone pagate in quel
modo ......
Saluti.
Zec.

Uno dei motivi per cui il Visual Basic viene preferito al C++ è il seguente:
Con Visual Basic è possibile sviluppare rapidamente un programma
professionale, subito, e con una medio-bassa conoscenza della
programmazione. E la qualità del prodotto finale è praticamente paragonabile
a quella che si ottiene utilizzando un linguaggio C++, che a differenza di
VB richiede una conoscenza nella programmazione nettamente superiore.
Infatti utilizzando un linguaggio C++ ci si "scontra" subito con i
puntatori, con le classi, ecc. che sono ostiche per chi è alle prime armi...
Comunque una volta imparato il Visual C++, non lo si abbandonerà mai più...
Io lo trovo stupendo!

 programmazione. 
Sono d'accordo sul rapidamente. Sul professionale....no comment.
Tutto dipende da quello che si deve fare.
Enrico

Io lo trovo stupendo!
Non la trovi una contraddizione con quanto affermato prima?
Paolo
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

puntatori, con le classi, ecc. che sono ostiche per chi è alle prime armi...
E si imparano tante di quelle cose che ti permettono di affrontare
altri linguaggi senza troppa fatica.
-- 


 puntatori, con le classi, ecc. che sono ostiche per chi è alle prime
armi...


>Io lo trovo stupendo!
Personalmente non sono per nulla d'accordo...
so che questo e' un vecchio thread, ma vorrei aggiungere un mio commento 
: il C++ oggi ha tutto, quello che ha sempre avuto (potenza espressiva, 
adattabilita', flessibilita', manutenibilita') , e quello che ha oggi 
grazie ai moderni ambienti di svluppo RAD (il C++Builder 4)
Velocita' di sviluppo, base di Codice riutilizzabile
Il fatto bello e' che , al contrario del visual basic, le due cose non 
vanno in contrapposizione nei RAD C++ ben fatti (praticamente il Borland 
CB++ e basta), certo, si perdono delle peculiarita' del linguaggio 
(standard ANSI, una certa pulizia mentale che il programmatore assume 
quando si scrive tutto da se), ma i vantaggi sono enormi, IHMO.
Personalmente continuo ad utilizzare compilatori come l'EGCS, il Visual 
C++ per progetti medio-grandi, con tanto codice da progettare e da 
scrivere, e il BCB per applicazioni gestionali. data-aware o comunque che 
presuppongono un tempo di consegna rapido (e cmq al contrario del visual 
basic la coerenza implementativa del programmatore in questo ambiente e' 
pressoche' intaccata, alla Imprise hanno fatto un ottimo lavoro...)
A volte mi capita di usarli insieme...anche perche' il BCB non e' SOLO 
Rad, ma consente allo sviluppatore di lavorare come piu' preferisce
Certo, ci sono difetti anche in quest'ambiente: in particolare nelle VCL 
(un nuovo Form: derivo una classe da TForm...ma quando impareranno che 
implementare una nuova finestra nella gui non equivale affatto a 
espandare le funzionalita' dell'entita' "finestra")
Ma se il progetto e medio-piccolo a queste cose ci si puo' passare sopra, 
e doptutto, le MFC non e' che siano granche' meglio...