Newsgroup: it.comp.programmare
Titolo: Che linguaggio e programma?

Ciao a tutti!!
Alla situazione attuale quale linguaggio conviene usare nella
programmazione in windows e quale programma compilatore?
Sarebbe utile anche se portabile su altre piattaforme come UNIX/Linux.
Grazie!!
P.S.
Ho studiato del C++ ma non in ambito visual.

 Sarebbe utile anche se portabile su altre piattaforme come UNIX/Linux.
Se vuoi la portabilita' usa Java, se vuoi la velocita' (e non la
portabilita') usa C/C++.
Davide

Sarebbe utile anche se portabile su altre piattaforme come UNIX/Linux.
Python č molto portabile grazie anche ai suoi moduli standard che
fanno molto di ciň di cui si necessita normalmente.
Se vuoi piů informazioni su Python vai su 
www.python.org
 e
www.python.it
. Esiste anche il ng it.comp.lang, se vuoi parlare di
Python usa il tag [PYTHON].
-- 
Marco Barisione (ICQ 84277092)

 fanno molto di ciň di cui si necessita normalmente.
Si`, comunque questa specifica porta ad escludere ad esempio Visual
Basic, che su Unix &c non va.
Se mai puo` interessare Delphi (per Windows) / Kylyx (per Linux), ma
le versioni professionali costano assai (Python e` gratuito, e vi sono
ottime versioni gratuite di C++ [gcc in varie salse] e Java).
Alex

 portabilita') usa C/C++.
questa frase e` troppo generica per essere vera. In particolare, mette 
in risalto due luoghi comuni non sempre veri:
1) Il Java e` universalmente portabile: non e` vero; non ho esperienza 
diretta, ma molti affermano che anche in Java ci sono dei problemi di 
portabilita` da una data JVM ad un'altra (magari della stessa ditta, ma 
una versione differente). Inoltre bisogna considerare il fatto, non da 
poco, che se il compilato dovrebbe essere (teoricamente) portabile 
"nello spazio" (quindi su piu` S.O.) il sorgente e` assolutamente non 
portabile "nel tempo"; non essendo standardizzato la Sun puo` decidere 
come e quando vuole effettuare cambiamenti al linguaggio, magari a 
scapito della compatibilita` all'indietro; questo implica che potrebbe 
capitare di non riuscire a compilare piu` il programma solo perche` si 
e` cambiata la versione del compilatore.
2) Il C++ non e` portabile: anche questo e` falso. Il C++ e` un 
linguaggio standard e (anche qui teoricamente) universalmente portabile 
tra diversi compilatori e/o S.O. Purtroppo ci sono diverse aree 
applicative non standardizzate, quindi piu` difficilmente portabili (ad 
esempio la parte relativa alla GUI). Questo pero` non significa 
l'impossibilita` di scrivere un programma portabile: esistono decine di 
librerie multipiattaforma che, se usate intelligentemente, permettono di 
scrivere programmi che girano su piu` S.O. Esempi di tali librerie per 
quanto concerne le GUI sono le QT, le GTK+, le wxWindow.
Inoltre, se anche non si dispone di una libreria adatta per il proprio 
scopo, e` sempre possibile isolare facilmente le parti di codice 
non-portabili in modo tale da dover effettuare solo modifiche minime in 
fase di porting ad un'altra piattaforma.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

e` cambiata la versione del compilatore.
Scusa se ti faccio una precisazione, Java è senza l'articolo...
I problemi di portabilità a cui accenni esistono veramente in modo
notevole dal JDK 1.1 al 1.3. Riguardo alle decisioni della Sun...hai
ragione pure li, dato che Java è solamente suo ogni tanto qualche
piccolo "cambio di corsia" lo fa e spiazza i programmatori :)
Un pò di esperienza Java ce l'ho e penso che se .NET andrà in porto
Java sparirà sul lato client (già per altro limitato) come _forse_
anche sul lato server (il nodo centrale della politica Sun) in favore
di linguaggi MS-related (anche se nn saprei + che imparare se dovessi
mettere mano a .NET, C#, J#??). Insomma penso che Java si salverà sul
lato embedded... ma ovviamente queste sono mie considerazione
personali nate dall'esperienza, dall'utilizzo e da letture varie
Io peraltro lo uso molto poco ora che ho scoperto le meraviglie del
C/C++ :)
-- 
Lawrence "Rhymes" Oluyede (
rhy...@myself.com
)
"Per cambiare, per diventare un'altra
cosa dobbiamo prima sapere cosa siamo"
(Bruce Lee)

 scapito della compatibilita` all'indietro;
[CUT]
Ma stai scherzando??? ...Ma credi che la sun si *diverta* a cambiare sotto i
piedi dei suoi sviluppatori le specifiche del suo linguaggio?? non credi che
si darebbe la così detta *zappa sui piedi* ??? non credo sia una società
masochista :-)
Pensa che addirittura piuttosto che togliere un metodo da una classe la SUN
lo definisce *deprecato*  cioè significa che è sconsigliato il suo utilizzo
perchè non si garantisce che ci sia anche in futuro ma ti garantisco che non
ti crea i problemi che pensi :) tutti i programmatori Java sanno che è
cattiva norma utilizzare metodi deprecati e cmq sia non sono tanti metodi...
penso che sia una politica corretta così non PROLIFICANO i *cadaveri* dovuti
alle evoluzioni future di un linguaggio.
Mi scuso se sono sembrato un pò polemico o *di parte* ma non è così ... solo
che ero stanco di persone che, solo perchè conoscono il C++ disprezzano Java
o danno delle opinioni su tale linguaggio non conoscendolo... non mi è mai
capitato di leggere che il C++ fosse il linguaggio prescelto dal DIVINO ....
:-)
Scusate lo sfogo.
Ciao ciao
Dany
(un programmatore sia JAVA che C++)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If at first the idea is not absurd then there is no hope for it. - Albert
Einstein
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Una sola osservazione.
Lavoro da anni nel settore informatico ed ho visto decine di aziende alla
disperata ricerca di programmatori di tutte le salse; ma mai nessuna a cui
servisse un programmatore Python. D'altro canto non conosco nemmeno nessun
software commerciale di un certo livello che sia stato sviluppato in Python.
Condivido con te il giudizio estremamente positivo su questo linguaggio (che
conosco a titolo personale) ma se con la programmazione ci devi anche
campare meglio lasciarlo perdere e dedicarti a qualcosa di più remunerativo
(e allo stato attuale Java o C++ lo sono di sicuro).
Ciao.
Greybear

 (e allo stato attuale Java o C++ lo sono di sicuro).
Io sto appunto lasciando un lavoro dove il linguaggio piu` usato e` il
C++ per passare invece a "campare" piu` che altro con Python (e non lo
faccio certo per rimetterci).  Cinque anni fa non mi sarei sentito
abbastanza tranquillo delle prospettive (e infatti lo faccio oggi, non
lo feci cinque anni fa:-), oggi, a mio vedere, le cose sono cambiate.
Lentamente, gradualmente, perche` nessuno ha mai lanciato "campagne
promozionali" per Python: si impone invece per la sua reale efficacia,
e quindi solo mano mano che "si sparge la voce".
Certo, tante aziende hanno gia` fatto le loro scelte tecnologiche (il
che magari comprende il dato linguaggio X di programmazione) e, a torto
o a ragione, non se ne smuoveranno.  Fra i vantaggi pragmatici di Python
c'e` la sua capacita` di infiltrarsi in ogni e qualsiasi "nicchia
ecologica".  In un'azienda che ha scelto, ad esempio, "100% Pure Java",
J2EE, ecc, ecc, Jython (che e` certificato appunto 100% Pure Java) permette
di programmare in Python utilizzando le stesse JVM, librerie e framework
usate in Java (le .class e .jar prodotte dal compilatore Jython essendo
indistinguibili da quelle prodotte dal compilatore Java), ma con tutti i
vantaggi di produttivita` di Python.  In un'azienda che ha scelto le
attuali tecnologie Microsoft, Python permette di sfruttarle al meglio
(segno dei tempi: il nuovo release del Visual Studio di Microsoft permette,
agganciandovi l'opportuno prodotto Activestate, di programmare in Python
nello stesso ambiente in cui si programma in VB, VC++, eccetera).  In
un'azienda che preferisce invece tecnologie piu` aperte, come Linux o
BSD, Corba, Mozilla, ecc, Python si incastra esattamente altrettanto bene.
Persino piattaforme oggi un po' marginali come BeOS, Macintosh, Sony
Playstation II, Palm Pilot, e cosi` via, Python comunque le supporta.
Che sia SOAP o XMLRPC, che sia Apache o IIS, che sia Oracle o SQL Server
(o DB2 o MySQL o Postgres o...:-), eccetera, eccetera, Python e` pronto a
giocare altrettanto bene il suo ruolo.  E` anche questo fattore
"diffusione",
oltre all'eccellenza intrinseca di Python, che gli sta dando successo.
Alex

o danno delle opinioni su tale linguaggio non conoscendolo
Tutte le cose positive che hai detto su Java mi ricordano molto
Python... :-)


 lo feci cinque anni fa:-), oggi, a mio vedere, le cose sono cambiate.
Sarà che io bazzico gli ambienti sbagliati ma mi sembra che la notorietà
odierna di Phyton non sia poi molto diversa di quella di cinque anni fa. Ho
già il grosso timore che Java non resista all'onda d'urto di .NET
figuriamoci la fiducia che ho sul fatto che lo possa fare Phyton.
Sono convinto che Phyton sia un ottimo linguaggio e in un mondo perfetto
potrebbe avere tutto il successo che merita. Ma ricordiamoci che nel mondo
reale l'ambiente di sviluppo più diffuso è il Visual Basic...
Ciao.
Greybear

 figuriamoci la fiducia che ho sul fatto che lo possa fare Phyton.
Salvo per il particolare che è molto probabile che su .NET assumano
importanza questi tool (in ordine di importanza):
1) C#
2) 
VB.NET
3) Python.NET
4) 
ASP.NET
5) Managed Extensions for C++
6) SmallScript.NET, Eiffel.NET etc. etc.
--
Andrea Ferro
IHHC - Member of HT-Group  DVD Authoring operator  Fan of I.Asimov
C++ Master: 
http://www.brainbench.com/transcript.jsp?pid=2522556
This post expresses personal opinions which may or may not be the
opinions of the company(s) I work for. I speak for myself only.

 problema non deve essere solo espresso ma anche motivato.
Piu` che altro, io direi, _negoziato_.  Se vuoi X1, costa X2 ma penso
che ti dia il beneficio X3 a fronte del rischio X4, pero` io invece
suggerirei Y1 che costa solo Y2 e permette un discreto Y3 senza Y4.
Questo vale sia che X e Y siano esatte feature del sistema, sia che
siano eventuali vincoli tecnologici per il suo deployment.  "Agile
Programming" ("Extreme Programming" e` il tipo piu` usato di AP, ma
ahime` la sigla XP oggi e` stata rapita da MS per altri scopi:-) &c.
Alex

odierna di Phyton non sia poi molto diversa di quella di cinque anni fa
Onestamente un anno fa non avevo la minima idea di cosa fosse Python,
e adesso ne sento parlare sempre di più.
Un grande problema di Python IMHO è che non viene insegnato in nessuna
scuola, questo potrebbe giovare molto alla sua diffusione.


 reale l'ambiente di sviluppo più diffuso è il Visual Basic...
...che MS sta cambiando drasticamente e incompatibilmente in
tantissimi modi grandi e piccoli, implicitamente ammettendo che
era un linguaggio cosi` cattivo da non permettere neppure di
conservare la compatibilita` all'indietro.  E nel nuovo Visual
Studio (l'ambiente ormai unificato per Visual Basic, VC++ ecc),
quello che esce fra neppure un mese, si puo` "agganciare" un
componente di ActiveState per sviluppare programmi in Python
usando esattamente gli strumenti che gia` l'utente conosce e
presumibilmente apprezza per l'uso con Visual Basic (designer
di form, debugger, ecc ecc).  Altra nicchia ecologica in cui
Python (ovviamente denominato per l'occasione "Visual Python",
cosi` si gioca anche sull'equivoco) penetra con successo.  La
prossima volta che un committente cerca di convincerti a usare
Visual Basic, fagli vedere VStudio 7 con Visual Python dentro
ovvero VB dentro -- cambia solo il linguaggio, tutto il resto
resta eguale, non e` OVVIAMENTE meglio Python...?  Certo!
La perfezione tecnica in se e per se non basta a garantire ad
una tecnologia un'accettazione buona e crescente sul mercato.
Ma Python non punta e non ha mai puntato all'arida e sterile
"perfezione tecnica fine a se stessa": e` un linguaggio
altamente pragmatico e ha alle spalle una comunita` altrettanto
pragmatica.  A me (egoisticamente parlando) interessa poi sino
a un certo punto che Python lo usino "tutti".  Basta che possa
usarlo *io*, guadagnandoci il pane (e il salame:-), e su questo,
ormai, (che posso campare, e meglio, puntando su Python come
prima e principale tecnologia nel mio pur ampio arsenale) ho
deciso che posso scommetterci.
Alex

 Sarebbe utile anche se portabile su altre piattaforme come UNIX/Linux.
Delphi! Delphi! :-)

servizi alle aziende che li richiedono.
E lo hai fatto?
Cmq dopo tutto il tuo discorso mi č quasi venuta voglia di iniziarmi
al Python seriamente :P (in Windows...). Ti serve un collaboratore? Io
per ora un pņ di tempo liberņ ce l'ho :))



wrote:
[...cut...]
una precisazione Python si scrive cosi e non come l'hai scritto tu:
Phyton... e cmq magari dalle ceneri di Java rinascerà il Python...
^_^


 per ora un pņ di tempo liberņ ce l'ho :))
Passiamo in e-mail per queste discussioni interessanti ma personali.
La mia email ce l'hai (non mi antispammo neppure...:-).  Non ho
intenzione di mettermi a fare il "procacciatore d'affari" di professione,
ma scambiarsi contatti sulla base di competenze, zone geografiche, e
cosi` via, male non puo` fare.  Ovviamente per segnalare un nome con
fiducia servono anche "delle referenze" (ad esempio, le mie si trovano
sul Python Cookbook, ad 
aspn.activestate.com
; su 
google.groups.com
,
ricerca avanzata, autore=alex martelli; su 
gmpy.sourceforge.net
; e fra non 
troppo, spero, su www.oreilly.com:-).
Alex

 deciso che posso scommetterci.
gia` che bazzichi su questo ng ne approfitto per farti una domanda che 
mi assilla da un po'; premetto che non conosco (per ora) Python ma ho 
letto qualcosina qua e la: la cosa che mi ha colpito piu` di tutte (da 
C++ista quale sono) e` il fatto che non e` possibile specificare livelli 
di accesso all'interno delle classi (quelli che in C++ sono 
public-private-protected): che fine ha fatto l'incapsulazione? A quali 
conseguenze si va incontro? Perche` e` stata fatta questa scelta? Quali 
sono i vantaggi del tutto-pubblico anziche` la politica scelta da 
C++/Java/ecc.?


 sotto i piedi dei suoi sviluppatori le specifiche del suo linguaggio??
ma sei in grado di capire cosa scrivo??? Ho detto che la Sun *puo`* 
cambiare le carte in tavola, non ho detto che la Sun lo fara`. Ma gia` 
in passato e` accaduto (lo hai ammesso tu stesso) e quindi non ci vedrei 
nulla di strano se accadesse anche in futuro (soprattutto in un periodo 
di grandi cambiamenti come questo).


 C++/Java/ecc.?
Rispetto a C++, il tema fondamentale e` la semplicita`.  In effetti c'e`
anche un controcanto di flessibilita`.  Il C++ (e il Java) a volte sembrano
predicati sull'ipotesi che chi progetta le classi che vengono usate sia un
superuomo, chi scrive il codice che le usa, un subnormale.  Quante volte
una libreria peraltro utile risulta inusabile perche` il progettista ha 
usato alcuni dei mezzi che ha per rimuovere flessibilita`, "proteggere da
se stesso" il programmatore subnormale che usera` le sue classi?  Non
solo con private (o protected) inopportuni, ma anche (in Java) con 'final'
che non permette l'eredita` o l'override, o (in C++) scordando di rendere
virtual un dato metodo.  In Python, non si complica il linguaggio allo scopo
di togliere flessibilita`!  Chi progetta e implementa le classi usate, e 
chi le usa, sono sullo stesso piano, due adulti consenzienti.  Il linguaggio
permette al progettista di indicare chiaramente le sue intenzioni, e chi
usa le classi, si presume, lo fara` con la stessa intelligenza usata da chi
le ha progettate.  La flessibilita` c'e` sempre, da usarsi con misura, da 
una parte e dall'altra.
Il risultato e` fantastico.  A volte, dare fiducia alla gente e` un buon 
modo perche` questa fiducia se la meritino.  Guido van Rossum, il mago di 
Python, viene dall'Olanda e abita da qualche anno in USA.  Ha notato che ad 
Amsterdam le numerosissime biciclette sono chiuse con lucchettini da due
lire, che anche un ragazzino romperebbe senza fatica: il lucchetto serve per
impedire che uno per sbaglio prenda la tua bici invece della sua, non altro 
(un ladro deciso non fatichera` a sconfiggerlo).  In USA, le pochissime 
bici in giro sono chiuse con sistemi tecnologici fantasmagorici e costosi.  
E sono rubate molto piu` spesso che in Olanda.  Oh com'e`?-)
In Java e` diverso: Java usa private &c anche come parte del suo modello
di *protezione* da codice sospetto (ad esempio una applet per default e`
sospetta, se non firmata e validata).  In Python, le rare volte che devi
eseguire codice che potrebbe essere studiato per danneggiarti, tu lo
indichi esplicitamente: lo carichi attraverso l'apposito modulo rexec, e gli
esponi solo oggetti incapsulato con l'apposito modulo Bastion.  Nel modo
"restricted execution", e solo in quello, il codice sospetto e` vincolato 
ad una "sandbox" e la normale flessibilita` di introspezione eccetera gli 
e` preclusa.  Di default, Bastion nasconde totalmente al codice sospetto 
gli attributi privati (il cui nome inizia con uno o piu` '_'), ma puoi 
anche assai facilmente personalizzarlo ad esempio passandogli un predicato 
per determinare quali attributi vanno mostrati e quali no.
Nel caso su mille in cui devi eseguire codice che puo` cercare di causarti
deliberatamente dei danni, meglio affrontare questo rischio in modo del 
tutto esplicito e consapevole.  Distorcere e complicare l'intero linguaggio 
per gestire questo 1/1000 delle situazioni, a spese delle altre 999, non e` 
per nulla un buon progetto -- tanto piu` che gestire bene una sandbox 
richiede comunque riflessione e azioni esplicite, per cui le complicazioni 
e la distorsione sono fatica sprecata.  (In C++, non esiste alcun modo di
proteggerti davvero dal codice stesso che stai girando; non e` compatibile 
con l'obbiettivo di prestazioni massime assolute, e ai tempi del progetto 
del C++ non se ne sentiva piu` di tanto il bisogno).
Alex (MVP di Brainbench per il C++, ma patito di Python)

 e SDL su tutte.
Ottime raccomandazioni.  Per inciso, tutte e tre esistono e sono molto
popolari anche in versione interfacciata a Python (PyQt, wxPython, PyGame; 
immagino intendessi wxWindows quando dici vwWindow?).
Per inciso dell'inciso, se poi uno decide che una data funzionalita` puo`
dargliela al meglio una libreria che esiste solo per Java, non occorre
cambiare linguaggio.  Basta usare sino dall'inizio Python: nella versione
CPython puo` usare librerie C o C++ appositamente incapsulate, nella
versione Jython puo` usare qualsiasi libreria per Java senza neppure
nessuna necessita` di incapsularla, bensi` in modo trasparente (e cosi`
pure puo` produrre file .class e .jar come puo` farlo Java, eccetera).
Alex (MVP Brainbench C++, non disprezzo Java, ma e` Python che amo:-)

 posteriori,
stai dicendo che sarebbe meglio sostituire "protected" con "public"?
ti ringrazio per le esaurienti spiegazioni per quel che riguarda la mia 
domanda originale.


 domanda originale.
Prego!
Alex (MVP C++ di Brainbench)

 livello che sia stato sviluppato in Python.
hmmm... le animazioni 3D usate dagli artisti Disney, ad esempio? č di 
un livello sufficiente secondo te?
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.18. C, C++ and ASM developers
                              and beta testers are welcome!

 
In effetti le visibilita' intermedie far public e private spesso vengono 
abusate e anche a me non sono mai piaciute, a prescindere dal 
linguaggio... pero' IMHO non bisogna fare di tutta l'erba un fascio
per un Singleton, ad esempio, protected ci sta proprio bene:
  class Singleton {
  public:
    static Singleton* Instance();
  protected:
    Singleton();
  private:
    static Singleton* _instance;
  };
dove poi
Singleton* Singleton::_instance = 0;
Singleton* Singleton::Instance () {
   if (_instance == 0) {
     _instance = new Singleton;
   }
   return _instance;
}
poiche' il costruttore protected evita che il client istanzi 
direttamente un oggetto di classe Singleton ma debba per forza passare 
attraverso tutto l'arcinoto meccanismo, c'e' la garanzia che il tutto 
stia in piedi e non ci siano piu' istanze di quelle che desideriamo.
Per il resto, quando mi capita di vedere molti protected nel codice di 
qualcuno, penso immediatamente che siamo in presenza di un bad design, o 
meglio di un code smell, come va ora di moda ;)
uL

 meglio di un code smell, come va ora di moda ;)
E se i protected sono pochi, sono comunque da riesaminare criticamente:
-- se bisogna impedire la chiamata a questi metodi nel codice-cliente,
        perche` d'improvviso va invece permessa se il cliente sceglie
        di ereditare invece di usare l'oggetto per composizione?
-- se al codice-cliente questi metodi potrebbero servire, a che pro forzarlo
        a ereditare invece di usare l'oggetto per composizione per chiamarli?
Il C++ sarebbe un linguaggio migliore (se non altro un pochettino piu`
semplice, e senza un paio di "tentazioni" a opposti errori di progetto) se
il protected non lo avesse, come Stroustrup stesso dichiara (credo che
sia l'unica feature di cui si dichiara totalmente pentito in "D&E").  Anche
se in un caso su mille facesse risparmiare un po' di fatica:-).
Alex

 se in un caso su mille facesse risparmiare un po' di fatica:-).
Non dirlo a me. Quest'anno a San Francisco ho visto una maglietta 
fantastica di un produttore di una qualche libreria che recitava, piu' o 
meno, "C++ e' il massimo voto che il mio capo prendeva al college": non 
sono riuscito pero' a strappargliela neanche con dei soldi...
uL

 
Io utilizzo la coincidenza di acronimi come test di conoscenza dell'OO:
- Qual'e' la prima cosa che ti viene in mente con la sigla X.P.?
- Il Sis... BOCCIATO!!! ;)
sorry per l'OT
uL

 sono riuscito pero' a strappargliela neanche con dei soldi...
Carina... forse da imitare!-)
Alex

 
Si, intendo questo: pero' in Java il target e' piu' alto con la presenza
di J2EE. A parte Jython, ti puoi interfacciare in Python "classico" con
un Transaction Server OTS, ad esempio?
ciao
uL
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 un Transaction Server OTS, ad esempio?
Certamente, visto che Python classico ha un ottimo supporto Corba
(varie ORB), e vari prodotti come TPBroker e tanti altri offrono
OTS (ad esempio TPBroker usa l'OTS e il Transaction Manager di
Hitachi) attraverso Corba.  (Non so quali linguaggi, se pure ne
esistono, NON abbiano un buon supporto Corba, d'altra parte...).
Alex

 esistono, NON abbiano un buon supporto Corba, d'altra parte...).
Si, ma non credo ci siano delle API equivalenti alle JTA. O si?
(Correggimi se sbaglio) Ed hai il supporto per ORB come ORBix e
Visibroker, tanto per intenderci?
BTW, non voglio aprire flame su Python: penso sia un buon linguaggio e
tu abbia fatto bene ad investirci il tuo tempo. Volevo solo un parere su
cosa ci si fa bene, cosa male e cosa cosi' cosi', visto che hai anche
esperienza di altri linguaggi.


 esperienza di altri linguaggi.
Nella mia esperienza, si "fanno male" in Python puro (cioe` senza alcuna
estensione) le operazioni fortemente CPU-bound, tipicamente quelle
numericamente intensive (algebra matriciale, elaborazione di immagini,
rendering 3D, ...); esse, se codificate in puro Python, risultano
infatti troppo lente.  Appunto per questo, per ciascuno di questi campi,
esistono estensioni assai diffuse (Numeric, PIL, PyGame ...) che
risolvono il problema prestazionale.  Posso dunque scrivere la mia
logica applicativa in Python, e trattare come primitive (anche se
non me le fornisce il linguaggio come built-in, ma una "libreria",
cioe` un modulo o package internamente implementato in un linguaggio
piu` a basso livello, tipo il C) operazioni tipo "inverti questa
matrice", "moltiplica questa matrice per quest'altra", "prendi il
coseno iperbolico di ciascuno di questo milione di numeri" e via
elencando.  Similmente, in "puro Python" non si fa per niente bene
la programmazione di sistema in senso stretto, cioe` quella che
dipende dall'accesso diretto ad API e syscall di un dato sistema
operativo; anche qui occorre usare librerie (che siano parte del
"core" di Python, o distribuite separatamente come estensioni),
tipicamente codificate internamente in C, che "espongano" i bassi
livelli del sistema operativo al codice Python (esempio tipico le
win32all per la piattaforma Win32).
Naturalmente non mancano i progetti, come Psyco (Python
Specializing Compiler) di Armin Rigo,
http://homepages.ulb.ac.be/~arigo/psyco/
 , che mirano a superare
o ammorbidire il problema delle prestazioni.  Considerando
quando c'e` voluto per ottenere serie accelerazioni per Java
(quanti anni, e soprattutto quanti miliardi d'investimenti:-),
e che ancora (nonostante tutti gli anni ed i miliardi:-) il
problema non e` affatto risolto, io personalmente non ci faccio
molto conto.  Secondo me, nel futuro prevedibile lo sviluppo in
Python continuera` ad appoggiarsi su componenti di basso livello
per le operazioni strettamente CPU-bound (e/o quelle che devono
interfacciare aspetti specifici di un dato sistema operativo) --
sia che questi componenti si presentino come parte di una JVM,
o librerie per essa, ovvero come "estensioni" da usare con la
versione classic di Python.  Fortunatamente non manca gran
copia di questi componenti, ne` fanno difetto gli strumenti per
svilupparne degli altri per eventuali necessita` "custom".
Alex

 
Grazie della dissertazione!
ciao e buon lavoro


 Vai a vedere gli ultimi volanomark!
Cosa c'entrano con il calcolo numericamente intensivo?  Non sono
invece benchmark relativi alle prestazioni di server di rete?
Alex

 
Si, non credevo parlassi di calcolo numericamente intensivo. Solo che in 
applicazioni server side tipiche le prestazioni delle JVM piu' 
performanti sono migliorate anni luce negli ultimi anni... e la 
tecnologia delle VM, dei garbage collector e dei compilatori JIT e' 
andata molto avanti proprio grazie a Sun. Immagino che la maggior parte 
delle innovazioni tecnologie saranno applicabili anche a Python, se e 
quando lo si riterra' necessario.
uL

 quando lo si riterra' necessario.
Senza dubbio.  Per ora, con l'1.4 si ha gia` un sostanziale miglioramento
di prestazioni di Jython rispetto all'1.3, ad esempio.
Le principali "innovazioni" (in senso molto relativo...) relative alle
prestazioni di Python sono quelle (in realta` note e stabili da anni
in ambiente accademico, e non solo) relative al "type inferencing" e
al suo uso nei compilatori fortemente ottimizzanti.  Scheme, linguaggio
(Lisp-like) non meno dinamico di Python, ha gia` da anni un compilatore
(che produce codice macchina nativo, quindi non e` questione di
tecnologie di VM), chiamato "stalin" (mi dicono che significa "acciaio":-),
che genera codice del tutto competitivo con quello di un compilatore C.
Allo scopo, visto che in Scheme come in Python non vi e` una associazione
statica di un tipo ad una variabile (tipizzazione forte ma dinamica), il
compilatore deve analizzare ("inferire") i possibili tipi associati alle
variabili e "specializzare" il codice che le usa.  Un linguaggio dinamico
ampiamente usato in ambito industriale (Erlang, originalmente sviluppato
da Ericsson) utilizza anch'esso questo tipo di tecnologie (ottenendo
prestazioni sufficienti per essere usato per pilotare le centrali
telefoniche Ericsson, e non solo quelle).  Il progetto Python che usa
(per ora sperimentalmente) queste tecnologie si chiama Psyco.
Quel che dicevo io e` che, personalmente, non ci faccio troppo
affidamento, soprattutto considerando i miliardi di dollari (e
gli anni) che ci sono voluti per vedere migliorare le prestazioni
di Java (e mi pare che siamo d'accordo che il grosso delle
migliorie e` stato comunque sulle parti I/O bound, come quelle
relative ai server di rete, piuttosto che non su quelle CPU
bound e numericamente intensive, su cui girano meno miliardi).
Scheme ha trent'anni di storia alle spalle, Erlang e` comunque
costruito sulla base dell'intera storia pregressa (soprattutto
accademica) della programmazione funzionale (con le grandi e
importanti innovazioni della tipizzazione dinamica e del supporto
diretto alla programmazione distribuita) e ha dunque tratto diretto
beneficio da milioni e milioni di ore-uomo spese in tesi di
dottorato e simili nel corso dei decenni:-).  Le tecnologie
dunque ci sono, ma la loro applicazione secondo me non sara`
rapidissima...
Alex

 di seguire quale azienda stia spingendo meglio queste tecnologie.
in effetti IBM e' sempre stata la VM piu' "veloce", fin dai tempi della 
1.1.8 (al prezzo di una grosse mole di RAM necessaria, e non 
necessariamente in contesti SMP dove il fattore numero uno e' la 
scalabilita')
Intendevo che "grazie" alla iniziale lentezza di Java alcune tecnologie 
sono state applicate in progetti di una certa visibilita' pubblica con i 
risultati che sono sotto gli occhi di tutti.
buon lavoro!
uL

 chimera dei Web Services.
Chimera?  Sun sembra che ci creda, 
http://java.sun.com/j2ee/webservices/
 ,
e non capisco perche` dovrebbe investire tanto su di una chimera.
Comunque, verissimo, "Python" e "hype" da sempre sono agli antipodi:
Python e` solido, semplice, funzionante e pragmatico, e nessuno ha mai
avuto un "budget di marketing" per spingerlo o enfatizzarlo.  Quello
che sottolineavo e` il potenziale, per fornitori come SAP e altri che
a tutti i costi devono avere grosso modo le stesse applicazioni sia su
.NET sia su J2EE, di un linguaggio di alto livello pienamente funzionale
e usabile su entrambe le piattaforme.  Chi segue con attenzione gli
aspetti concreti della tecnologia puo` cogliere questo potenziale, chi
invece compra sulla base della pubblicita` difficilmente lo fara`.
Alex


Io continuo a pensare che sia una chimera, almeno per quest'anno e forse 
pure il prossimo. Spero che non mi licenzino per questo, io lo affermo 
anche in situazioni ufficiali ;)
Questo articolo mi trova completamente d'accordo
Web Services: It's So Crazy, It Just Might Not Work
http://www.xml.com/pub/a/2001/10/03/webservices.html
C'e' stato anche un articolo simile di D.Savarese (autore di diversi 
progetti Apache) su uno degli ultimi numeri di JavaPRO.
Sostanzialmente, piu' che chimera, i web services non rappresentano il 
futuro di internet, ma solo di un pezzetto del dominio delle possibili 
applicazioni. Il marketing di MS e Sun richiede invece un po' di enfasi 
su cosa ci si fara'. Per chi se lo ricorda, nel 1997/98 si parlava di 
IIOP come del futuro di Internet, tanto che in NS 4.x ci sono i jar di 
Visibroker, e i Web Services sono una versione riveduta e corretta del 
tutto con XML che fa da colla "universale": spero non ne condivideranno 
il fallimento, ma non credo che la cosa diventera' pervasiva come la 
pubblicita' lascia credere.
In giro ci sono annunci pubblicitari come quello di SilverStream extend:
"to those not interested in rapid web services development: it's been 
nice knowing you, and we wish you luck in your next career"
che, anche se ovviamente il tono e' scherzoso, lascia trasparire la 
pressione IMHO solo parzialmente giustificata che si sta creando 
sull'argomento
ciao
uL

 (errata?) ipotesi che cosi` non sia, che le possibilita` quelle siano.
Direi che 
VB.NET
 puň usare tutto di .NET ma con qualche complicazione in 
piů rispetto al C#: per esempio per quanto riguarda i tipi definiti la 
mancanza del "sovraccarico" degli operatori rende tutto molto piů 
scomodo.
Maurizio
-- 
Maurizio Sambati
Skice Software
E-mail: 
gsm...@inwind.it
--------------------------