Newsgroup: it.comp.lang.c
Titolo: quando è meglio programmare in C

Ciao a tutti, mi � sempre piaciuta la programmazione in C/C++, e stavo
valutando se dare uno sbocco professionale a quasto mio interesse.
Premesso che non mi piacerebbe la programmazione gestionale, che
programmi potrei scrivere in C/C++, per quali piattaforme hardware e
sistemi operativi?
Ciao,
Alberto.

 Ciao a tutti, mi è sempre piaciuta la programmazione in C/C++, e stavo


 situazione :)
se il datore di lavoro te lo permette...
Ciao Jack

 mio punto di vista... In bocca al lupo!
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 fare puro number cruncing.
Come hai ricavato questo dato?
E.

 Come hai ricavato questo dato?
C'erano dei bench di IBM che promuoveva il compilatore JIT della sua VM 
e ricordo che grossomodo i numeri erano quelli.
Probabilmente ne esistono anche di fonti più indipendenti.


da test che ho fatto io.
Ciao Jack

Andrea D'Amore ha scritto:

Ho trovato questo:
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
che dice delle cose interessanti. In particolare dà tre motivazioni 
teoriche sul perché il Java diventerà più veloce del C.
Le motivazioni 1 e 2 non mi convincono molto, credo che dei buoni 
compilatori (insieme a codice scritto bene) non dovrebbero avere quei 
problemi. La 3 mi sembra invece molto sensata.
E.

 Ciao Jack
Ciao

 diventerà più veloce del C.
Ho letto, un JIT con conoscenza più approfondita si potrebbe 
implementare anche per gli eseguibili nativi, certo è un discorso 
ipotetico e probabilmente non ci sarà la necessaria spinta mentre Java i 
JIT compiler li ha già.
Per la cronaca non mi piace mai leggere "assembler" al posto di 
"assembly", sezione "What is slow?".

 embedded non c'è spazio per questa roba. 
Da quanto mi dice un amico sulle SIM va molto Java Micro Edition.

Jack ha spiegato il 20/07/2009 :

Allora devi dire:
"dai _miei_ test Java e' piu' lento del C di al massimo il 5%"
-- 
Mio figlio: 
http://it.youtube.com/davideippopotamo
La violenza non puï¿œ essere una esclusiva dei malfattori.
Ladri del mio appartamento, vi siete dimenticati un coltellaccio da 
cucina, tornate.

Andrea D'Amore ha scritto:

Ecco perché il mio telefono ci mette mezz'ora ad accendersi ;-)
E.

 E tu che hai risposto?
io non ho risposto a al poster originale e non era neanche mia
intenzione farlo, ho fatto dei commenti su tuo post.
Ciao Jack

 Assembly
Se ben progettato e strutturato è semplice come mantenere un programma 
in C.  E questo dipende da chi lo ha scritto.


 
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Mi sembrano una discreta serie di minchiate. Per esempio nessun dottore 
ha mai vietato di usare una GC in C/C++. Se uno pensi che la GC gli dia 
un "boost" di prestazioni, che la usi. Non c'ï¿œ bisogno di cambiare 
linguaggio.
Quando qualcuno poi mi fa vedere dei test su una montagna di codice, e 
che dimostra che abilitando delle ottimizzazioni particolari, in 
generale, si ha un significativo incremento di prestazioni, allora 
pensero che "in generale" le ottimizzioni specifiche fanno la 
differenza. Ovvero: per un gestionale che differenza fa avere codice 
ottimizzato per sse? Ma anche ipotizzando che fosse vero, da tempo nei 
codec ci sono routine ottimizzate per i vari processori che vengono 
caricate "al volo", quindi volendo non si puï¿œ eliminare il presunto 
gap. Ma a parte chi sviluppa codec video e cryptografia, non ï¿œ che il 
mondo sia pieno di programmatori che non possono vivere senza sse e 
similari.
Infine mai nessuno parla dell'impronta del run-time. In C/C++, se vuoi, 
puoi non usare nessun run-time del C/C++, "appoggiarti" direttamente 
sul S.O., e avere programmi "leggerissimi". Cosa che in Python, DotNet, 
Java non puoi fare. Ora portarsi dietro un impronta di qualche mega di 
ram puï¿œ essere un conto, portarsi qualche centinaia di mega di ram di 
impronta puï¿œ essere tutto un'altro paio di maniche. Nell'articolo, se 
uno non ï¿œ scafato, potrebbe pensare che il costo di un cache missing 
interessa solo il programma, mentre il run-time sia esente da problema.
Aggiungo che esistono processori che eseguono direttamente bytecode 
java, perï¿œ non mi sembra che abbiano avuto un grande successo 
commerciale. Cosï¿œ come esistono almeno un paio di s.o. scritti in 
dotnet. Ma non mi sembra la norma.
Infine aggiungo che niente vieta di fare il JIT su codice nativo. L'IBM 
lo fa da tempo sui As400 per mantenere la compatibilitï¿œ con il passato, 
e visto che fornisce anche i processori per la ps3, magicamente si 
parla di jit su codice nativo anche per i giochi della ps2 da fare 
girare sulla ps3. In questo caso perchï¿œ sia preferibile un jit ad una 
macchina virtuale ps2 da far girare sulla ps3 non lo so. Non so quanto 
sia complesso un jit su codice nativo, e quanto sia complesso scrivere 
una macchina virtuale.


>In bocca al lupo!
Grazie :-)
Alberto.

 E.
Se "la 3" è il JITing è tutta fuffa. Personalmente sembra una vera
follia: per far girare un programma non basta "far girare il
programma": ne devi avviare un'altro che lo legge e lo traduce (VM) e
nel frattempo l'analizza (JIT, probabilmente in un altro processo). Mi
chiedo come solo possano pensare di fare credere a qualcuno che le
prestazioni possano arrivare ad essere più elevate di un normale
programma stand-alone compilato staticamente. Boh.
Poi certo - se prendono un programmatore java senior e un pischello
dell'università che ha fatto un corso di C di un mese il risultato è
scontato. Poi vabbè, personalmente non ho niente in contrario al fatto
che a qualcuno piaccia scrivere chili e chili in più di codice per un
programma finale più lento e meno portabile per ottenere lo stesso
risultato. Ovviamente nella business logic un programmatore Java costa
meno, quindi Java è migliore.
P.S. Per chi se lo chiedesse, il java è meno portabile del C, visto
che per tutte le piattaforme possibili, ci sono più compilatori C che
JVM.


Da quanto ne so inizialmente la JVM doveva essere una stack machine
appunto per facilitarne l'implementazione (a scapito delle
performances). A forza di aggiungere roba sulla macchina è presto
diventata così complessa che nemmeno più questo vantaggio è rimasto.
Mamma mia che schifo Java e il suo zozzo mondo.

 possibili, ci sono più compilatori C che JVM.
Ma ci sono più variazioni nei dialetti C da piattaforma a piattaforma, o 
sbaglio?

 sbaglio?
per quanto riguarda la "variazione nei dialetti" si tratta di piccole
differenze a livello di keywords, facili da individuare (e nel
peggiore dei casi aggiustare con un replace :D) e il tutto fa sempre
riferimento uno degli standard ISO.
Ricordo che Java *non ha* uno standard ISO.

 in C.  E questo dipende da chi lo ha scritto.
Però il programmatore non è l'unico parametro, alcuni linguaggi sono più 
o meno di aiuto forzando a scrivere in un modo piuttosto che un altro.

 piattaforma, o sbaglio?
Cosa intendi per dialetti?  A parte le variazioni introdotte dagli 
standard ANSI il C è ancora uguale al K&R.
Probabilmente ci sono differenze in aree indefinite dello standard fra 
compilatore e compilatore, ma non ho mai trovato differenze nel 
linguaggio fra le varie piattaforme.


 che un altro.
Io ho iniziato a programmare in Assembly ia86 su micro-controller e 
sicuramente all'inizio avevo difficoltà ma dopo aver studiato il C mi 
ero abituato a scrivere programmi strutturati come il C tutto fu più 
facile.


 o meno di aiuto forzando a scrivere in un modo piuttosto che un altro.
Questo significa che il programmatore *è* l'unico parametro. Un
programmatore bravo non ha bisogno delle "forzature", scrive come deve
e basta. Un programmatore inesperto ha bisogno di "forzature"
implicite nel linguaggio che lo guidino nella scrittura, ma IMHO è una
tecnica "povera" per limitare i danni. Basta comparare la "qualità"
media dei prodotti realizzati in diversi linguaggi per rendersi conto
che più il linguaggio "aiuta" il programmatore più la qualità del
prodotto finale sarà scarsa (ovviamente con le dovute eccezioni).

 (java,python,...) rispetto a C/C++.
Non metterei Java allo stesso livello di Python e non metterei C++ allo
stesso livello di C.
-- 
-riko

 JVM.
Purtroppo la portabilita' non e' solo questo. In effetti portare C e'
fattibile, ma ha chiaramente un costo in termini di sviluppo e di
assunzioni che puoi o non puoi fare (che in definitiva possono pure
avere un costo prestazionale).
Tipicamente sulla *mia* esperienza fare portabile un programma C di un
certo tipo ha un costo tutto fuorche' trascurabile. Farlo in Java e'
pressoche' gratis.
Nota che i tipi di cui parliamo sono tipi di portabilita' diversa: in un
caso sei portabile *implementando* la cosa, nell'altro sei portabile di
default. Personalmente con i tempi di sviluppo di oggi non ho
*minimamente* dubbi su quale situazione preferire e proporre al mio
cliente.
Comunque no, a me Java non piace.
-- 
-riko

 operativo.
No. Gli altri linguaggi che indica sono tipicamente eseguiti
server-side. Il browser non mette a disposizione un bel niente.
Di fatto gli unici diffusamente eseguiti client side sono Javascript e
Java (e Flash).
Se vai a vedere un po' di statistiche scoprirai che le applet Java sono
una tecnologia che non ha sostanzialmente mai preso piede per una lunga
serie di motivi. Buona parte del software Java sta server side per
applicazioni server aziendali, bancarie et simili + applicazioni web +
siti web.
-- 
-riko

 prodotto finale sar� scarsa (ovviamente con le dovute eccezioni).
Puoi provare quello che dici?
-- 
-riko

 applicazioni web + siti web.
Ciao


 Questo significa che il programmatore *è* l'unico parametro.
Hai un concetto di dipendenza funzionale molto particolare, puoi 
analizzare la qualità di un programma sia al variare del linguaggio che 
al variare del programmatore e sono parametri "ortogonali".

 Ricordo che Java *non ha* uno standard ISO.
Per la certificazione ISO non basta pagare l'organizzazione?


A me invece sì ;-)


Purtroppo no, e infatti ho virgolettato "qualità". Occorrerebbe
scegliere vari parametri ed effettuare una stima per ognuno. Pur non
avendo prove in mano personalmente rimango di questa idea basandomi
sull'esperienza personale, che magari non sarà numericamente valida ma
in assenza di prove contrarie continua a darmi ragione.

 Per la certificazione ISO non basta pagare l'organizzazione?
Certo, ma bloccherebbe il linguaggio in una determinata sintassi,
mentre vogliono tenersi la possibilità di cambiare il linguaggio man
mano che vanno avanti.

 seguito) il C/C++ � predominante.  Anche su windows mi sembra.
Credo che l'onere della prova (90% C e C++) stia a te: tu hai fatto
l'affermazione.
Devi anche definire meglio le metriche: parli di linee di codice oppure
di programmi (o di programmi usati da almeno x persone e lunghi almeno y
righe di codice)?
In particolare su Windows penso che parlare del 90% del software in
C/C++ sia surreale: il triste e spropositato successo di Visual Basic
credo possa essere ben piu' responsabile del 10%. Non parliamo poi di
Delphi, i vari RAD per fare gestionali e applicazioni business. 
E qui abbiamo ancora tenuto fuori tutti i linguaggi dinamici, Java e
PHP. 
Riformuliamo: il 90% del core di una distribuzione linux e' C (tipo
debian-base)? Si. Questa mi sembra un'affermazione plausibile. Comincia
a costruire sopra e vedi che non e' piu' vero.
-- 
-riko

 A me invece s� ;-)
Forse dovrei dire che non mi piacciono i Javisti. Poi dipende, dopo un
po' che non lavoro in Java o che lavoro in C++ la mia simpatia per Java
aumenta.
-- 
-riko

 Per la certificazione ISO non basta pagare l'organizzazione?
Magari fornendo loro il paperozzo. Microsoft mi sembra abbia fatto
questo per C#.
-- 
-riko


Quindi confermi quello che dicevo: sia in C che in Java bisogna
comunque rimettere mano al codice. Chi più chi meno, certamente, ma la
"portabilità di Java" è solo un mito da sfatare.
Sul tutto il resto del tuo discorso mi trovo perfettamente d'accordo.

  l'affermazione.
E tu hai l'onere di provare la tua contestazioni


 appunto per facilitarne l'implementazione
Java nasce per far funzionare le lavatrici, poi ï¿œ diventato qualcosa 
d'altro. Per i miei gusti c'ï¿œ troppo marketing intorno. Mi sono fatto 
piacere il C#, ma con java non c'ï¿œ santo che tenga. Non fa per me.


 questo per C#.
Se ben ricordo il C# non ï¿œ ISO per non mi ricordo che motivo, credo di 
tempistiche. E' stato standardizzato dall'ente europeo, mi pare di 
ricordare.


 nel frattempo l'analizza (JIT, probabilmente in un altro processo).
Dipende da quel che di devi fare. Un conto ï¿œ se sei una lavatrice, ma 
se sei un programma fortemente dall'I/O avere una VM potrebbe essere 
totalmente influente.
Poi il tuo programma deve girare una volta sola? Magari il jit ï¿œ fatta 
una volta sola.
Ma anche se tu fossi una lavatrice, ï¿œ la velocitï¿œ di esecuzione che ti 
fa la differenza? Di solito, nel caso della lavatrice, ï¿œ la ram/rom il 
problema, non tanto il ciclo in piï¿œ di CPU.
La velocitï¿œ mi sembra molto un mito. Non credo che in questo news group 
siamo tutti programmatori intenti a spaccare il secondo su tutti i 
programmi che scriviamo.


 da test che ho fatto io.
A questo punto mi intrometto (e non per far polemica)... visto che parli
anche di python (e LISP), puoi portarmi qualche fonte? Mi interessa
parecchio.
d 


Tutto vero, ma un programma più veloce equivale a meno risorse
necessarie, quindi chipset meno costosi. Piano piano i micro diventano
più potenti a parità di prezzo, ma anche un centesimo risparmiato
equivale a una bella fetta di prezzo del prodotto finale (soprattutto
per grandi produzioni).
Non ho la più pallida idea di come funzioni con le lavatrici, ma ad
occhio e croce non mi stupirei se nelle lavatrici di grandi marche i
micro fossero ad otto bit, meno di una decina di megahertz e
programmati direttamente in assembler: voglio dire... che ci dovrai
mai fare? :-)

 mai fare? :-)
Infatti sicuramente basta un 8 bit, e *non* serve comunque "spaccare il 
secondo". Puï¿œ anche essere che se il figlio del padrone programma in 
java, che gli costi complessivamente meno metterci un 16 bit e una java 
machine sopra.
Tornando a bomba, oggi, per non sono poi tanti gli ambiti in cui 
bisogna spaccare il secondo. Per dire, se sviluppi apache devi spaccare 
il secondo, ma non certo fino ad arrivare a programmare in codice 
macchina.



Sò solo che con questo post su frigoriferi e focacce m'è venuta una
fame assurda :-O Nemmeno ho pranzato.
Comunque... Sì, è il discorso di preferire l'abbassamento dei tempi di
sviluppo rispetto ai costi fissi che non mi torna, comunque tutto può
essere, non sono del settore.
Gli ambiti in cui bisogna "spaccare il secondo" sono tantissimi invece
(giusto due/tre dove lavoro io sono automotive, aerospaziale e
codifica video) e in ogni caso i cicli di avanzo (in caso ci fossero)
si possono sempre sfruttare per fare tante belle cose in più.

 poi anche permetterti di metterci un risc a 64 bit.
Sono curioso: come mai questo amore per le lavatrici?

 Sono curioso: come mai questo amore per le lavatrici?
Perchï¿œ ne ho comprata una poco tempo fa, scoprendo per altro che tra 
quella "economica" di prima, e finita in pochi anni all'isola 
ecologica, e quella "costosa" di adesso c'ï¿œ una discreta differenza.
Nella prima avranno spaccato il secondo una volta di troppo. Tra 
l'altro credo che anche se i marchi sono diversi il gruppo che possiede 
quei marchi sia lo stesso, ma non ci giurerei.
Gli elettrodomestici Miele, non credo che valgano il loro (assurdo) 
prezzo, perï¿œ sono di una fattura incredibile. Magari dentro c'ï¿œ un risc 
a 64 su un RTOS solo per poterlo dire nel depliant.
Per altro nel mondo dell'automazione io ero uno dei fautori delle 
maniere pesanti. Computer super carrozzati, cablaggi di reti con 
schermatura militare, e cosï¿œ via, secondo la logica che in un fabbrica 
di lavatrici, con un'automazione dal costo di 200 mila ï¿œ, 10 mila di 
hardware hanno un loro perchï¿œ (viste le rogne che puoi evitare con 10 
mila ï¿œ di hardware). In quell'ambiente il fermo di produzione di un'ora 
ha dei costi folli. Ma questa teoria che i costi fissi non sono cosï¿œ 
cruciali come altri tipi di costo (di sviluppo, di test, di 
manutenzione, di failure, di backup) ï¿œ una teoria mia, non molto 
seguita.


 :-P

 mai fare? :-)
anche meno.
Di sicuro non c'e' dentro un ARM.
Ciao Jack

 macchina.
sono di piu' gli ambiti dove DEVI spaccare il secondo piuttosto a
quelli dove non devi.
Apache e' un esempio dove non devi.
Nei router, gli switch, le centraline delle auto o nei cellulari (non
l'interfaccia, ma il DSP che traduce la tua voce in segnale GSM) sono
esempio dove c'e' bisogno di spaccare il secondo, altrimenti non
funziona niente.
Ciao Jack

 in assenza di prove contrarie continua a darmi ragione.
Diciamo piuttosto che si auto-sostiene, nel senso che si basa sulla tua
esperienza, verosimilmente acquisita in un determinato mondo e continua
a ritrovare conferma in quel mondo.
A me basta per esempio mettere in campo i linguaggi dichiarativi, e in
particolare quelli funzionali (che inequivocabilmente "aiutano" il
programmatore) e invalidare la tesi: la quasi totalita' dei
programmatori proficienti in queste tecnologie sono effettivamente
ottimi sviluppatori, il prodotto che usano e' solido e ben fatto
(sebbene non necessariamente facile da imparare, e' molto facile da
usare). E i progetti che producono sono di qualita' davvero elevata. 
Allo stesso modo nella comunita' Python riscontro una qualita' di
progetto, design e implementazione (e di fatto degli sviluppatori) che
ho visto davvero raramente.
Il mondo Java invece e' troppo vasto e ci sono arrivati cani pazzeschi.
Io credo che questo sia il punto: se tu prendi un cane e lo metti a
lavorare con Java fara' una schifezza. Se lo avessi preso e messo a
lavorare con C (o con Python) avrebbe pure prodotto una schifezza.
Probabilmente con Python avrebbe imparato prima a non fare schifezze, ma
questa e' una mia congettura: il progetto corrente sarebbe stato
comunque una schifezza.
-- 
-riko

 funziona niente.
Tutti casi in cui, se va bene, il linguaggio a piï¿œ alto livello 
disponibile ï¿œ il C o un C++ castrato. Non certo Java. Poi in quanti al 
mondo programmaranno router o switch? Se sono un centinaio di persone 
in tutto il mondo mi meraviglio.
Anche perchï¿œ per il router di fascia bassa che ho hanno fatto presto. 
CPU sovrabbondante, e linux sopra. Non si sono sbattuti piï¿œ di tanto a 
"programmare". Mica tutti usano Cisco.
Le centraline delle auto, almeno di quelle di una noto produttore 
italiano, sono programmate in assembly. Non in C, men che meno in java. 
E non ci giurerei che spacchino il secondo. Almeno 15 anni fa, quando 
ci entrai in contatto di striscio, ebbi l'impressione di un prodotto di 
merda; ma magari in 15 il responsabile software della nota casa ï¿œ 
andato in pensione, e al suo posto ce una persona competente. Spero.


 ricordare.
ISO/IEC 23270
Poi non so se *prima* lo ha standardizzato l'europeo e in seconda
battuta anche ISO.
-- 
-riko


Beh sì, alla fine il 90% di tutto è una schifezza :-)


E quante persone al mondo ci sono che programmano un kernel linux? ;)
Forse dovresti rivedere le tue stime numeriche.

 battuta anche ISO.
Magari ï¿œ successo quello.


 Forse dovresti rivedere le tue stime numeriche.
Il kernel? Dubito che siano "tante". Ci saranno tante persone che 
girano "intorno" a Linux, ma non ï¿œ detto che a scriverlo sian poi cosï¿œ 
in tanti. Immagino. Tu hai dati sull'attuale numero di persone che oggi 
scrive linee di codice nel kernel?
Usando google e capitando qui: 
http://vger.kernel.org/vger-lists.html
mi viene da pensare che non ci sia tutta questa folla a sviluppare.


 per grandi produzioni).
Questo discorso e' vero praticamente solo nell'embedded. Al di fuori di
questo mercato il ttm, l'estensibilita', il costo dei programmatori,
designer e compagnia cantante si mangia in pratica le performance. 
-- 
-riko

 macchina.
E poi apache come performance non eccelle... troppo mastodontico. Nginx
invece vola. Piccolo, veloce, compatto.
-- 
-riko


O anche mojito! :D
(So che non lo conoscete, visto che l'ho scritto poco tempo fa e non è
neppure ancora online se non per test - appena finisco la prima alpha
scrivo una riga anche qui)


Questo dimostra quanto ci azzecco poco fuori dal mio mondo :-)


http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php
circa un migliaio solo sul mainstream

 circa un migliaio solo sul mainstream
Ammazza quanti


 Questo discorso e' vero praticamente solo nell'embedded.
Intendiamoci anche sulla parola embedded. I PLC io li ho visti 
programmare, e richiedere dal cliente di essere programmati, con dei 
linguaggi molto _semplici_. Di solito era cosï¿œ. Spesso in fabbrica chi 
tiene dietro al software dei PLC ï¿œ l'elettricista, e non certo un 
programmatore "professionista".
Visto che si possono fare delle modifiche al codice "al volo", senza 
compilare, ho sempre pensato che sotto sotto fosse codice interpretato. 
Il pcode versione automazione industriale.
Per un PLC ï¿œ qualcosa di incredibilmente vicino al ferro.


 scrivo una riga anche qui)
Volentieri! 
-- 
-riko

buh la tua risposta � di parte...
� vero che esistono pi� compilatori c che vm ma quando hai una vm hai
anche tutto il framework (o tutto quello inerente il profilo se guardi i
microdevice ad esempio) quando hai un compilatore c hai solo quello (no
gui, no thread, no network, no database, no zip, etc...)
java � pi� lento ma in condizioni particolari, come ad esempio il
calcolo numerico, una volta bypassata la fase iniziale (quella di
caricare il runtime, avviare il jit, etc) un codice ottimizzato tramite
jit potrebbe essere performante quanto l'equivalente in C o C++.
(inoltre il jit potrebbe tenere una cache delle classi gi� jitttate)
non � vero che bisogna scrivere pi� codice java che c++ per fare le
stesse cose, forse un p� meno in C++ (alle volte avere eredit� singola
effettivamente porta a spararsi tante seghe mentali e scrivere pi�
codice tra interfacce e simili) ma sicuramente rispetto ad esempio varie
strutture C, una serie di funzioni con convenzione sul nume, visto che
non c'� polimorfismo devi fare qualcosa alla io opengl
somma3f, somma3i, somma2f, somma2i (somma 3float, 3interi, 2float,
2interi) mentre questo in java e c++ � pi� compatto.
C/C++ pu� essere usato praticamente ovunque ma per scrivere un software
gestionale come era l'esempio proposto avresti bisogno di:
* una gui
* thread
* network
* accesso ai db
se usi le api del sistema operativo la portabilit� diventa zero, se usi
ad esempio il C++ e  un framework come qt di nokia sei apposto (di fatti
oltre a quanto elencato ha pure, svg, opengl, classi container che
possono essere usati al posto della stl etc..) altrimenti ti devi
cercare una libreria per ogni funzionalit�.
Java ha gi� tutto questo.
per il deploy invece va tutto  a vantaggio di C++ fai una compilazione
statica e distribuisci l'eseguibile. su java oltre a distribuire una
forma binaria che non � vista direttamente dal sistema obblighi il
povere utente a installare un runtime che non � proprio 2k ma svariati
mega quindi ci sono molti fattori da considerare, principalmente anche
tempi di sviluppo, piattaforme, etc... altrimenti non ti spiegheresti
perch� la maggior parte dei gestionali sono fatti in visualbasic (alle
volte anche peggio ieri mattina ne ho visto uno sviluppato tutto in
access e vba).

 access e vba).
Veramente l'OP aveva premesso che *non* voleva avere a che fare con i
gestionali.

 gestionali.
ahh errore tragicomico avevo letto il contrario alle volte la stanchezza
altre il venerd� farei meglio a restare a letto.
chiedo venia.
allora correggo il tiro, per quanto ho visto in giro:
* programmazione web: java (j2ee),php,
asp.net
,ruby,python,perl (server)
* programmazione web: flex, actionscript, javascript (client)
* intranet: cosa ti pare o cosa ti obbligano
* audio/video: C++ compilatore  e librerie intel non c'� storia
* utility: C/C++
* cad/cam: C/C++ opengl
* videogiochi 3d: ora i processori sono potenti si va dal C++ (con
motori come irrlich (multipiattaforma), dark gdk(windows), ogre (multi)
e affini, passando per java3d (multi) ma anche linguaggi e ambienti di
sviluppo apposta: torque (multi), darkbasic (win), unity (multi), pygame
(multi)
* videogiochi 2d: C/C++ (sdl, clamlib), java2d, blitzbasic, etc...
* videogiochi 2d,isonometri e finti 3d su web: flash, javascript (con
componenti o meno lato server)
* driver, mondo micro edition: C molto poco in C++ magari castrato e
senza template library
* videogiochi mondo windows e affini: xna e c#
* gestionali e affini: mondo .net
* cruscotti (ossia gui che si integrano con servizi di vario tipo,
sottostanti, webservice, xmlrpc): wxwidgets (multi), qt (multi), fltk
(multi), mfc (win), gtk++ (multi) ma anche C# e windows form (o GTK#)
il C e C++ possono pure essere visti come linguaggi di integrazione,
esempio:
ho necessita tramite php di acceddere alla libreria tal dei tali, mi
scrivo un modulo C che si integra con php (tramite zend_interface)
ho necessita da java di accedere all'hardware mi scrivo qualcosa tramite jni
ho un gestionale in realbasic che deve accedere al database tizio, mi
scrivo tramite il plugin sdk un plugin in C++
e via dicendo, fa sempre bene conoscere il C, uno perch� � il linguaggio
principe per dialogare col sistema operativo, due perch� prima o poi ti
ci imbatti in un sorgente C, tre perch� alle volte potresti avere solo
un os e un compilatore C.
Lo stesso discorso pi� o meno valido per il C++

 "portabilit� di Java" � solo un mito da sfatare.
No. Se usi le specifiche Java MicroEdition *non* rimetti mano al codice.
Tutti i dispositivi che usano Java ME lo supportano e basta. 
Ovviamente se hai una libreria per gestire bluetooth (opzionale) la
trovi sui dispositivi che hanno bluetooth. Chi non ce lo ha nisba.
Hai anche i vari standard grafici (lcd, roba piu' sofisticata).
Chiaramente se un dispositivo non ha uno schermo a colori da 320x240
pixel non ha senso mettergli su una GUI per quello schermo. Tipicamente
vai a "classi" di dispositivi, ma la cosa e' necessaria per il mercato
che si va a colpire, non certo per i "limiti" di portabilita' di Java.
Tra l'altro con un corretto MVC la cosa e' comunque molto poco costosa.
La portabilita' di Java *non* e' un mito da sfatare: e' una realta' da
constatare. Certo, non sono mica gli unici e non hanno innovato un
granche'. Poi io su Java ME non entro in maggiore dettaglio: non me lo
sono mai filato, a me l'embedded interessa meno della cucina sumera. 
Su destkop e' una cosa piuttosto evidente da constatare.
-- 
-riko


Ah, ecco. Allora non lo sapevi.

 codice come dice lui. Per il resto è ok.
sono curioso... mi fai un esempio in cui l'indentazione di python non è
quella che useresti *comunque*?
-- 
By ZeD


wrote:

Guarda di preciso adesso non mi viene. So solo che ogni volta che ci
devo mettere mano è un'agonia. Il problema ovviamente è mio: io penso
in C qualsiasi linguaggio uso (dall'assembler al Java), ma in Python
non si può fare - e perdo.

 Sul tutto il resto del tuo discorso mi trovo perfettamente d'accordo.
Per portabilità di Java s'intende portabilità del codice, non
dell'intera applicazione. Il codice Java è portabile perché non
definisce il programma in termini di basso livello. Il codice C ( e C+
+) non è portabile perché di basso livello e gli standard prevedono
delle situazioni system-dependent.
La portabilità dei programmi, tuttavia, non dipende solo dal codice,
anche dal framework in cui ti muovi.
Se usi Gtk3.2, Qt4.5 o JRE1.2 sai che i tuoi programmi potrebbero non
funzionare su ambienti che non dispongono dell'esatta versione di
quelle librerie/run-time-environments.
Andrea