Newsgroup: it.comp.programmare
Titolo: scelta?

Imparare un linguaggio visuale per obiettivo lavoro:
Tra Visual C++ e Visual Java quale è la scelta migliore?
beppe 


Visual Java++ è morto.
Visual C++ è una localizzazione del C++ per i sistemi microsoft.
Perché proprio questi linguaggi e non ad esempio il PHP? Scusami ma
dall'impostazione della tua domanda mi sa che dovresti chiarirti un
po' le idee... improvvisare porta a perdite di tempo e a zero
risultati.
Ciao.


obbiettivo lavoro... parfti da zero oppure hai un'infarinatura?
comunque visto che di server per lavoro, vedi che tipo di knowon è 
richiesto dalle aziende della tua zona...

 Perché proprio questi linguaggi e non ad esempio il PHP?
Mi inserisco per chiedere una cosa da utente Visual C++,quasi del tutto
ignorante per quanto riguarda PHP:con PHP si fanno anche applicazioni
desktop?Esiste un IDE visuale sul genere di Visual Studio?
Lo chiedo perchč sono molto interessato a PHP,ma finora ho letto solo poche
cose riguardo ad esso e mi sono fatto l'idea (probabilmente sbagliata) che
serva solo in ambito di realizzazione di pagine web


nessuno dei due.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 desktop?Esiste un IDE visuale sul genere di Visual Studio?
php č un linguaggio di scripting per web. esiste anche phpgtk che 
dovrebbe portare php sul dektop, ma non ne so nulla.
se vuoi utilizzare un linguaggio differente da visual c++ prova ruby o 
python che permettono anche di creare applicazio ni web

 desktop? Esiste un IDE visuale sul genere di Visual Studio?
non sono un esperto di PHP, mi occupo principalmente di HTML, VB6 e C+
+.
Tutto si può fare ma forse esistono linguaggi più appropriati.
Per la seconda domanda:
http://www.codegear.com/products/delphi/php
che è proprio un RAD, a pagamento... free non so nulla.
ciao.

 Tutto si puň fare ma forse esistono linguaggi piů appropriati.
E qui colgo l'occasione per chiedere:per applicazioni desktop,qual'č (o
quali sono) il linguaggio piů appropriato?

 quali sono) il linguaggio piů appropriato?
Direi che dipende dall'applicazione.

 Direi che dipende dall'applicazione.
Puoi fare una classificazione abbastanza generica?Sono molto interessato


in ambito desktop, tanto più deve essere performente l'applicazione 
tanto più il linguaggio deve essere vicino alla macchina. quindi per 
performance massime c/c++. chiaramente un gestionale non lo realizzerei 
mai in c/c++. comunque con i pc di oggi questi discorsi assumono sempre 
meno importanza.

 meno importanza.
non commettere l'errore di ritenere che l'avanzamento dell'hardware
possa sopperire a "lentezze" insite nel linguaggio utilizzato.
"Lentezze" tra trenta virgolette, ovvio, come nel caso dei software
visti prima; lì la differenza tra un linguaggio di scripting e il C ad
esempio, si farà sentire sempre. Ovvio che per una semplice
interrogazione di database il discorso è più sfumato...
ciao.

 possa sopperire a "lentezze" insite nel linguaggio utilizzato.
Soprattutto quando la scelta del linguaggio puo' portare a tempi di
esecuzione decuplicati o centuplicati:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=php
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=ruby
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=python
Con questo non volgio dire che il C++ sia una buona scelta per il
lavoro (non lavorando nell'IT francamente non ne ho idea). Pero' dove
le performance in termini di tempo di esecuzione e allocazione di
memoria sono importanti, il C++ e' sicuramente un'ottima scelta e
continua ad esserlo nonstante la disponibilita' di processori piu'
potenti e quantita' di RAM.
Saluti,
The Librarian

 terabyte, matematica avanzata eccetera.
Si, ma non credo che qualcuno si mettera' mai a scrivere primitive per 
il riconoscimento vocale, o per fare ricerche di occorrenze in qualche 
terabyte o matematica avanzata eccetera...
Ci sono librerie gia' pronte che fanno questo sporco lavoro e al limite 
uno se le importa perfino in visual basic.
Poi, per carita', bellissimo cimentarsi con queste cose a basso livello, 
ma o lavori in una software house che ha queste cose come prodotto di 
punta, oppure si utilizza la pappa pronta.

 terabyte o matematica avanzata eccetera...
Il C è cresciuto nei settori nei quali l'Assembly è stato usato e il C+
+ cresce soprattutto nei settori del C: da questi ambiti non si
scappa: il C++ serve, punto e basta. Per altre cose ci sono mille modi
di affrontare il problema. Persino nell'embedded si possono
programmare i micro col basic.
Ciao.

 potenti e quantita' di RAM.
inoltre è un ottimo investimento culturale. Curiosità che strumenti
utilizzi?
ciao.

 serva solo in ambito di realizzazione di pagine web
Allora per le pagine web fa schifo. Per il resto è ancora peggio.
Giudica tu.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 tanto più il linguaggio deve essere vicino alla macchina.
Così magari il bottone risponde in un millesimo di secondo invece che in
1.5 millesimi di secondo. Se riesci a cliccare un milione di volte in
stecca hai un bel vantaggio: guadagni mezzo secondo.


 potenti e quantita' di RAM.
Allora quei benchmark sono tutta roba puramente *algoritmica*. Come dire
che un motore di calcolo va fatto in un linguaggio quanto più possibile
performante, bella forza.
In compenso non tengono conto che per la maggior parte delle
applicazioni i colli di bottiglia sono altri: chiamate di sistema, di
I/O (sia locale che di rete), chiamate a db. Queste sono tutte cose in
cui il linguaggio conta relativamente poco.
Tipicamente non riuscirai a distinguere un'applicazione desktop in
Python da una in C++. Se non per il fatto che probabilmente quella in
Python sarà pronta in un quinto del tempo, sarà lunga circa un quinto e
probabilmente conterrà un numero significativamente minore di bachi
(proprio perchè è più *facile* lavorare in Python).


 scappa: il C++ serve, punto e basta. 
E chi dice che non serve? Solo č abusatissimo anche dove č uno
*svantaggio* competitivo. 


 forum:
http://www.akropolix.net/forum/
    | bacchette per voi.
sul fatto dell'"abusatissimo" avrei i miei dubbi; sullo svantaggio che
è "competitivo" non ti seguo.
Giusto per chiarire: nessuno qui vuole intendere C++ contro "resto del
mondo" :)
ciao.

 
Beh, preferire un linguaggio di basso livello come il C ad altri per ottimizzare 
un singolo click è effettivamente troppo (a meno di applicazioni realtime, ma è 
un altro discorso).
Però per applicazioni complete, dove il codice non deve solamente gestire un 
click, allora può valerne la pena.
Poi non bisogna dimenticare che ci sono anche linguaggi interpretati che in 
certe condizioni fanno mangiare la polvere al C (come il Perl sulle stringhe), 
non fosse altro per il fatto che in C c'è la possibilità di scegliere tra 
centinaia di librerie già esistenti e linguaggi come il Perl sono stati 
costruiti e ottimizzati per alcuni compiti specifici. È quindi possibile 
raggiungere lo stesso risultato scrivendo un programma in C, ma al costo di 
essere tu a doverti smazzare le ottimizzazioni.
Nonostante questo sono in parte in disaccordo con jamba: un linguaggio vicino 
alla macchina ti permette di avere il massimo potenziale, ma un linguaggio più 
di alto livello (non Java, comunque :-) ), se ben organizzato (non Java, quindi 
;-) ), permette di esprimere al meglio il potenziale di una macchina con poco 
sforzo, e quindi essere più efficente (occhio che non ho detto efficace) del C.
LP

 è "competitivo" non ti seguo.
C++ è un linguaggio notevolmente efficiente, tuttavia ha dei tempi di
sviluppo notevolmente maggiori delle alternative.
Quando puoi fare una stima in ore uomo che sarebbe 1/5 di quella che
dovresti fare in C++ (o magari ti limiti a tenerla ad 1/3 e ci stai
dentro *largo), hai un grosso vantaggio.
Abusato perchè in molti contesti *non* serve. Per un'applicazione
desktop per esempio la velocità aggiuntiva è per la maggior parte
inutile. Perchè un'applicazione desktop sta per gran parte del suo tempo
idle. Questo è il fatto fondamentale. 
Allo stesso modo su rete e i/o buona parte del vantaggio di C++ si
riduce, fino a scomparire su applicazioni complesse dove, per esempio,
un punto di vista asincrono può aumentare le prestazioni molto più di
quanto faccia un linguaggio più prestante.


 desktop
perdonami ma tolti piccoli progetti come MSWord o OpenOffice ;), non
ho notizie di gestionali fatti in C++.
ciao.

 ciao.
scusami refuso da fretta: ovviamente per i suddetti trattasi di altro
rispetto ai gestionali. Ma il concetto rimane.
ariciao.

 (occhio che non ho detto efficace) del C.
Si, sono d'accordo. Ma allora non capisco quello che dicevi sopra.


 Giudica tu.
Beh,allora quale consiglieresti?

 solo se si è effettivamente constatato che le cose sono troppo lente.
Scusate se mi inserisco in questa discussione,decisamente al di sopra delle
mie conoscenze,con una domanda piuttosto ignorante:se scrivo una parte di
codice in un linguaggio e un'altra in uno diverso,come faccio a farli
"comunicare"?

 
La scelta di un linguaggio dipende da molti fattori.
Avevo semplicemente discusso la velocità di esecuzione contro la dimensione del 
codice nei vari linguaggi (stando molto sul generico).
Conosco anche l'assembly (e l'ho utilizzato sui 386 per fare applicazioni di 
animazione grafica dove la velocità di esecuzione era fondamentale), ma adesso 
non lo utilizzerei mai a meno di non essere proprio con l'acqua alla gola :-)
LP


Ci sono diversi metodi.
Il più semplice concettualmente è quello del front-end/back-end dove un processo 
esegue un altro processo e comunicano serializzando opportunamente i dati su un 
canale (ad esempio stdin/stdout o un socket). Complessità implementativa media 
la prima volta e più bassa le altre. Tuttavia va studiato per bene e occorre 
implementare parser e prettyprinter per deserializzare e serializzare dati.
Anche i dati vanno tradotti in una forma comprensibile ad entrambi i processi.
Altro modo è quello delle librerie (che in genere rispettano lo standard C).
Un linguaggio genera una libreria (codice .o, .lib, .a, .so per i sistemi *nix, 
.obj, .lib, .dll per quelli Win) e l'altro linguaggio s'attacca a questa libreria.
Il linking potrebbe essere dinamico o statico. Nel caso di linking dinamico, la 
libreria è un .so o un .dll e il processo principale si collega a questa 
libreria per utilizzarne le funzioni esportate solo in fase di esecuzione. Nel 
caso di linking statico, la libreria viene inglobata nell'eseguibile (che quindi 
cresce di dimensione).
Quando uno o quando l'altro, dipende anche dalle caratteristiche dei linguaggi 
di poter essere compilati verso il codice macchina del processore (in genere il 
linking dinamico va per la maggiore per motivi di riusabilità del codice e di 
scalabilità, infatti mantenendo l'interfaccia uguale, è possibile aggiornare 
solo uno dei due elementi).
Difficoltà implementativa variabile in base alle caratteristiche dei linguaggi, 
al sistema operativo, ecc.
Si possono anche utilizzare altri metodi (come shared memory, mailbox condivise 
e sincronizzate con mutex e semafori, file binari), ma necessitano di una 
compatibilità maggiore dei linguaggi (C-C funziona benissimo, con altri non saprei)
Normalmente si preferisce la generazione di un .so o di una .dll
LP

 Beh,allora quale consiglieresti?
Qualcosa che non abbia (a breve) 3 versioni incompatibili fra loro e una
pletora di bachi di security :-P
Io ti consiglierei di studiare un solido linguaggio dinamico (hint:
Python o Ruby) e sceglierti il framework che piů ti aggrada (per Ruby
c'č praticamente solo Rails, per Python ce ne sono parecchi tipo Django,
Pylons, Turbogears, blah blah)
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 Pylons, Turbogears, blah blah)
Ehmmm..scusa per la domanda da ignorante :-P...ma un framework in pratica
cos'e? Una mega libreria? Un IDE?

 cos'e? Una mega libreria? Un IDE?
http://it.wikipedia.org/wiki/Framework
ciao

 (proprio perchè è più *facile* lavorare in Python).
Mi dispiace dirlo ma con questo post hai dimostrato soltanto di voler
fare advocacy per python. Sei partito a razzo a difendere python solo
perche' ho fatto notare che per programmi CPU bound perdeva molto
rispetto al C++.
Ah, nota che il mio post iniziale non aveva nessun intento
denigratorio nei contronti di python (che considero un ottimo
linguaggio), volevo solo far notare che non e' vero che con cpu piu'
potenti si risolve tutto.
Saluti,
The Librarian

 benissimo, con altri non saprei)
Tutto quello che non passa per roba 'troppo binaria' (che so, mutex e
semafori) funzionano chiaramente benissimo. Per il resto, pure, è
banale.
Come ultima cosa ti chiederei per favore di settare il tuo client in
modo tale che wrappi a tipicamente 72 caratteri, in modo che aggiungendo
le quotature si stia sotto gli 80.


 migliore.
Conosco OCaml, anche se gli preferisco Haskell. Perdo performance ma
guadagno la possibilità di operare su strutture dati infinite. Oltre che
godo come un caimano ad avere un linguaggio funzionale *puro* dove posso
anche con estrema facilità tratteggiare dimostrazioni di correttezza.
Non ho nulla in se contro OCaml, eh. Solo lo trovo un po' troppo
ridondante in fatto di costrutti (e per certi versi preferisco SML).
D'altra parte estreme lodi agli sviluppatori del compilatore, hanno
fatto davvero un bel lavoro.
Il problema è che per molti programmatori il paradigma funzionale è in
qualche modo troppo arduo. Devono imparare a pensare in modo diverso, e
mi rendo conto che non tutti sono in grado.
Idem con i linguaggi dichiarativi.
Per dire di questi tempi sto lavorando in Prolog (e io sono un *pessimo*
programmatore prolog). Eppure ho visto codici di miei amici che
gridavano vergogna. Choice point evidenti *a me* aperti da tutte le
parti, left-recursion a gogo e così via. 


 cos'e? Una mega libreria? Un IDE?
Vedilo come una megalibreria, anche se č un po' riduttivo.


 potenti si risolve tutto.
Ma cosa vuole dire 'difendere' Python. Mi limito a farti notare lo scope
e la validità dei benchmark.


 
Fatto.
LP

 
Concordo.
LP

 applicazioni con Java GTK.
A me non vengono in mente applicazioni desktop fatte in Java :-D
Tool per sviluppatori a parte ;-)


 e la validità dei benchmark.
Come ti ho scritto sopra, lo scope non e' incredibilemente ampio, ma
e' piu' ampio di quanto pensi per l'utente medio desktop.
Saluti,
The Librarian

 devo ammettere che e' piuttosto seccante.
Ribadisco, questo non mi è capitato in Python più che in C++. Per dire
aMule (che è per l'appunto scritto in C++ su wx) ha una GUI poco
reattiva.
O poi ricordo che fino a pochi anni fa c'erano quelli che 'guai al C++
che è lento bisogna fare tutto in C'. Pochi anni fa vuole dire 5 o forse
6. Non so se seguivi, ma non erano pochi.
Il principale colpevole era un software piuttosto grosso scritto in C++
e che risultava molto meno parco di risorse e meno prestante di un
analogo software scritto in C. Solo che il punto era che il software in
C era per i fatti suoi piccolo e parco, mentre l'altro tendeva un po'
per i fatti suoi al feature bloat. 
Certo, anche il fatto che all'epoca gcc compilasse C molto meglio che
C++ ha la sua influenza. Ma complessivamnente il punto era proprio il
design e l'ottimizzazione dei due software.


 ho notizie di gestionali fatti in C++.
aMule per esempio č fatto in C++. 
Se no puoi fare una ricerca su sourceforge per linguaggio e vedere
quanta roba viene fatta in C++.
Farti l'elenco č un po' lunghetto. :P



Touché! :)

 design e l'ottimizzazione dei due software.
Vorrei farti notare che, software particolari a parte, che l'affermare
che il C sia piu' veloce del C++ e' sostanzialmente corretto anche se
va fatta una precisazione.
Infatti gli strumenti (eredita', chiamate e funzioni virtuali, etc...)
che ti mette a disposizione il c++ per ottenere un livello
d'astrazione maggiore nel codice causano inevitabilmente delle
inefficienze sia in termini di velocita' di esecuzione che di utilizzo
di memoria. C'e' da dire che per il 99.99% dei programmi queste
inefficienze sono completamente trascurabili, visto che rappresentano
un overhead minimo, ma in alcuni casi rari possono essere rilevanti
(anche se IMHO alcuni di questi casi possono essere accuratemente
evitati cambiando il design).
Per quanto riguarda la precisazione di cui parlavo prima, devo
aggiungere che si' il C e' piu' veloce del C++, ma solo se facciamo il
confronto a differente livello di astrazione. Se in C provi
raggiungere lo stesso livello di astrazione del C++, con ottima
probabilita' incorrerai in un overhead comparabile.
Visto che ci sono, ti parlo di un'altra disputa che penso sia
rilevante ai fini della questione: velocita' di Java vs. C++.
Non so se ti ricordi, ma qualche anno fa Java andava sostanzialmente
piu' lento del C++. Caso strano ogni volta che usciva fuori la frase
"Java e' lento", tutti i programmatori Java si agitavano come matti e
incominciavano delle discussioni furibonde nel tentativo di difendere
il lovo linguaggio. C'era addirittura chi aveva pubblicato dei
benchmark che dimostravano come Java fosse in realta' piu' veloce del C
++. Non solo... Dopo che questo era stato pubblicamente svergognato,
un'altro se n'era uscito fuori con la spiegazione *teorica* del
perche' Java doveva essere piu' veloce. Insomma si vedevano scenette
che ricordavano la negazione dell'olocausto da parte dei nazisti.
Poi, grazie a vari miglioramenti (specialemte sul JIT), pian piano
Java e' diventato molto piu' veloce, in molti casi comparabile come
velocita' al C++. E da quel momento, stranamente, si respira un'aria
rilassata e si puo' parlare serenamente della velocita' di esecuzione
di Java (a parte per la presenza occasionale di qualche fanboy che
ancora non ha capito che la guerra e' finita).
Ora ti chiederai qual'e' il punto di questa bella storiella. Te lo
dico subito: vedo generalmente nei programmatori Python lo stesso
atteggiamento che vedevo dei programmatori Java di allora quando si
parlava della velocita' del loro linguaggio.
Quello che mi sembra e' che (parlo sempre in generale) i programmatori
Python non vogliano ammettere (anche a loro stessi) che il loro
linguaggio non e' perfetto (e la velocita' e l'eccessivo consumo di
memoria sono un grossa pecca). Francamente spero che il JIT per Python
faccia velocemente passi avanti, sia perche' mi piace python come
linguaggio, sia perche' forse cosi' si potra' discutere serenamente di
certi argomenti.
Saluti,
The Librarian
PS: visto che ho fatto un'esplicito riferimento al nazismo, per la
legge di Godwin mi trovo costretto a dichiarare il thread terminato ;-)

 memoria sono un grossa pecca). 
Ma va, mica siamo Perlisti :P Il linguaggio non è affatto perfetto,
proprio per questo c'è il progetto Python 3000.


 proprio per questo c'è il progetto Python 3000.
Beh, spero che il nome non indichi che sara pronto per l'inizio del
prossimo millennio :P
Saluti,
The Librarian

 prossimo millennio :P
No dovrebbe essere pronta una release per Giugno 2008. L'intenzione di
Guido è proprio quella di NON replicare Perl 6


 certi argomenti.
Lasciando stare che non mi sembra *affatto* che Python abbia un consumo
di memoria 'eccessivo' (eccessivo rispetto a cosa, poi?).
Non è questione di ammettere che Python è più lento di C++. Questo è del
tutto evidente e ci sono svariati modi per accorgersene. Inoltre dubito
seriamente che Python riuscirà mai ad essere efficiente come C++. 
Ma IMHO la tua prospettiva è errata. Ogni linguaggio ha punti di forza e
punti deboli. Il 'linguaggio perfetto' non esiste (chiaramente un Lisper
non sarebbe d'accordo con me). È sempre una questione di bilanciare
diversi fattori.
Certo se Python fosse più veloce sarebbe meglio. Ma se per diventare più
veloce si dovesse rinunicare a qualcuna delle caratteristiche che
rendono Python Python, bene, allora ci rinuncio volentieri.
Se per una serie di ragioni la velocità è un fattore critico, ho diverse
soluzioni. Come ti ho detto in lungo e in largo posso ottimizzare le
funzioni critiche in C o in Pyrex, posso scegliere un linguaggio
differente. O semplicemente (e vale nella maggior parte dei casi) posso
migliorare il design e le strutture dati. E normalmente ottengo il
risultato sperato.
Il motivo per cui noi che usiamo Python siamo abbastanza scettici sulla
velocità, è proprio perchè ci rendiamo conto che nella maggior parte
delle situazioni è un falso problema. Esattamente come non mi preoccupo
che la mia macchina non farebbe i 280 Km/h, non mi preoccupo che Python
non sia il linguaggio più veloce. Come la mia macchina è più che
adeguata per girare in città e in autostrada, così non mi preoccupo per
Python. Quando dovrò andare a fare le gare di corsa, vedrò.
Quello che mi fa intervenire è generalmente l'errore di prospettiva.
Come se la velocità fosse un fattore critico *sempre*. Questo non è
vero.
E per questo intervengo. Pensa, mi è capitato anche di fare notare in
giro come Java non fosse lento. E fra tutti i linguaggi che uso e
conosco, è uno di quelli che mi piace di meno. Non per Python, Prolog o
Ruby. Perchè individuo un errore di fondo, tutto qui. D'altra parte Java
ha in buona parte contribuito a questa pessima fama dei linguaggi a
bytecode. E la cosa ridicola, è che lo ha fatto per i motivi sbagliati.
In particolare la lentezza di determinate librerie (non di Java in se),
la lentezza di avvio dell'interprete stesso e soprattutto la maledetta
tendenza alla sovraingegnerizzazione che si ha in Java, per cui si
finiscono per creare quasi esclusivamente dei mammuth che fanno anche il
caffè (in ambito desktop).


 delle estenzioni verso python).
Mi è sfuggito il motivo, scusa. Per quale motivo non si potrebbe
scrivere SW professionale in Python? Devo dedurre che si ritorna
sempre al solito discorso della "velocità a tutti i costi"...

 vero.
Scusa ma quest'errore l'hai visto solo te. Ti sfido a trovare una
frase nel mio post iniziale che dimostri questo errore di prospettiva.
[cut su java]
Su Java concordo pienamente
Saluti,
The Librarian

 frase nel mio post iniziale che dimostri questo errore di prospettiva.
Immagino che ci siamo fraintesi a vicenda.


 utilizzi?
Sotto windows utilizzo MS Visual Studio 2005 con compilatore annesso.
Sotto linux utilizzo emacs e gcc, ma faccio, per lo piu', cose
amatoriali. Francamente avrei preferito un IDE alla visual studio ma
non mi sono trovato molto bene ne' con KDevelop ne' con Anjuta.
Saluti,
The Librarian

 The Librarian
io sono per ragioni lavorative legato (leggi ancorato) ai sistema Win,
anche se cerco di utilizzare quanti più strumenti opensorce possibili.
Sto ponderando di passare a linux quanto prima ma è come per emacs: mi
spaventa il vagare qualche secondo sulla tastiera per operazioni che
mi risulterebbero immediate con altri prodotti. Ho coscienza del fatto
che mi perdo molti vantaggi.
Sugli IDE o peggio RAD, per C++ penso che sia solo come disse qualcuno
"zucchero sintattico". Sarei OT, ma mi sa che qui lo si è da molti
giorni.
Ciao.