Newsgroup: it.lavoro.informatica
Titolo: I linguaggi

Ho lurkato volentieri il thread sui linguaggi, secondo me sarebbe una 
discussione davvero interessante. Anche i dibattiti accessi vanno bene, 
peccato che una volta finiti gli argomenti si sfocia nel personale e allora 
tanti saluti.
Mi piaceva riprendere la discussione.
Lo spunto potrebbe essere: linguaggi dinamici vs. linguaggi "statici", che 
pro e che contro?
Un'altro spunto e C# vs. Java. Siccome sento fin troppo dire in giro "sono 
la stessa cosa", io francamente trovo il primo MOLTO più moderno del secondo 
(si può fare di meglio, sia chiaro) e concludo che questa affermazione è 
sintomo di ignoranza. Voi che ne pensate?

 sintomo di ignoranza. Voi che ne pensate?
Che stai per scatenare un altro flame :-)
-- 
Lawrence - 
http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

per la lotta guelfi-ghibellini qualcuno è finito all'inferno :)

 per la lotta guelfi-ghibellini qualcuno è finito all'inferno :)
Semplicemente perchè credevano nell'esistenza dell'inferno ;-)


 sintomo di ignoranza. Voi che ne pensate?
c# e java non ha senso confrontarli.
si usano per intenti diversi e dipende più che altro da cosa il
cliente vuole, per che archittettura e su che SO e che grado di
integrazione e assistenza desidera nella azienda.
se vuoi portabilità, scalabilità e costi contenuti, java
se vuoi perfetta integrazione e assistenza con sistemi e reti
microsoft, c#
come performance sono scarsi tutti e due, quindi in quello non c'è
differenza
come semplicità e sintassi del linguaggio sono molto molto simili, con
la differenza che java puo' essere o meno esteso da vari frameworks
esistenti, c# usa un solo framework che deve per forza essere
installato sulla macchina che serve l'applicazione.

A me sembrano discorsi un po del c...
Ogni linguaggio e' valido dal C/C++ al PHP a Java e C#, Bash scripting,
Perl, phyton etc.
In generale credo sia sbagliato soffermarsi su uno solo, ogni linguaggio
"insegna" qualcosa di nuovo ed e' piu' adatto per certi scopi piuttosto
che per altri.
La scelta del linguaggio dipende anche dalle situazioni: gli obiettivi,
la formazione del team, i costi nello sviluppare nel tal linguaggio etc.
Credo sia opportuno, piu' che farsi seghe mentali di questo tipo, se
possibile cercare di estendere la propria "cultura" sul maggior numero
possibile di linguaggi in modo da essere sempre pronti ad ogni soluzione.

 ha scritto nel messaggio 
news:4511127c$0$35083$4faf...@reader4.news.tin.it...

Sei pazzo? I linguaggi dinamici sono meglio in tutto e per tutto!
E' tutta una questione di ficate come safety vs freedom, numero di righe del 
codice, numero di colonne del codice (eh si perche' System.out.println ne 
occupa davvero troppe!), e chi piu' ne ha piu' ne metta. 

 installato sulla macchina che serve l'applicazione.
Mi spieghi sta cosa che mica l'ho capita.
Saluti.


cos' è che non hai capito?

 c# e java non ha senso confrontarli.
Sicuro? In fondo io li trovo sintatticamente e funzionalmente simili. Ci
sono vantaggi e svantaggi in entrambe le piattaforme ma sono linguaggi
simili.
ps. penso che il topic fosse "Linguaggi", non "piattaforme" o
"framework"


 che per altri.
Concordo, linguaggi diversi insegnano cose diverse. Ma dovremmo definire
"diversi". Io sono un Pythonista e ho imparato Ruby per fare una
applicazione ma personalmente non ho alcun interesse or ora a passare a
Ruby perchè in quanto a funzionalità e caratteristiche è molto simile a
Python e in fondo ha qualche "problemino" che Python non ha solo perchè
è sviluppato da più tempo e curano parecchio l'ottimizzazione. Quando
Ruby 2.0 arriverà tra noi magari potrei riconsiderare la cosa.
I pragmatic programmers hanno inventato il motto di "un linguaggio
all'anno" non per fanatismo o narcisismo ma per esplicitare il concetto
che un programmatore dovrebbe conoscere differenti _TIPI_ di linguaggi.
Imparare C# e Java e _basta_ non rientra in questo tipo di formazione.
Imparare un linguaggio statico, uno dinamico, uno funzionale, uno
dichiarativo sarebbe già qualcosa... Imparare paradigmi diversi secondo
me apre la mente e gli occhi. Fossilizzarsi su LinguaggioX release 1,
LinguaggioX release 2, LinguaggioX release 3 ti fa diventare solo un
esperto di quel linguaggio ma resti comunque "chiuso" nella tua botte di
ferro.
Per questo sorrido quando c'è gente che si vanta di conoscere C# e
VB.NET
 a menadito... cambia solo la sintassi!
Spero che il mio ragionamento fili :-)


 "framework"
prova a slegare c# dal suo framework e poi utilizzalo, se ci riesci.

 installato sulla macchina che serve l'applicazione.
Pure la JVM va installata nella macchina su cui si va ad eseguire e
infatti da qui nacque la causa tra microsoft e Sun che porto` microsoft
a iniziare a scrivere .net e C#. Ancora non vedo differenze.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 
ha scritto nel messaggio 
news:1hlyrup.aausjkzz755oN%dial%23%23%23%23%23$$NOSPAM%23%23$%23$%23%23t...@gmail.com...
Oh no, sono arrivati i moschettieri... 

 Haskell, C++, C, C#, Java sono i primi che mi vengono in mente.
scusa eh, mi pare che in C++ e C la memoria utilizzata dal programma
non venga interamente determinata a livello di compilazione come nei
linguaggi statici, ma viene utilizzata memoria heap, appunto dinamica.
quelli si chiamano linguaggi semi-dinamici e non statici, in quanto
allochi memoria a tempo di esecuzione.
C# e Java invece sono linguaggi dinamici, in quanto la memoria non
viene nemmeno gestita dal programmatore ma decisa run-time dal runtime
environment.
per il resto nemmeno commento.

 me apre la mente e gli occhi. 
ecco era in parte quello che intendevo. Oltre a questo aggiungerei che
conoscendone un po' ... uno sa anche quale e' il piu' adatto ad un certo
tipo di problema magari quello che gli risolve la soluzione nel minor tempo.

mah io ti dico quello che sta nel mio bagaglio culturale (avendo ormai
passato parecchi linguaggi) ... se poi non sei d'accordo libero di farlo.

 per il resto nemmeno commento.
-- 


> tipo di problema magari quello che gli risolve la soluzione nel minor tempo.
mamma mia come mi sono espresso male!

 passato parecchi linguaggi) ... se poi non sei d'accordo libero di farlo.
Guarda che era sarcastico. 

 prova a slegare c# dal suo framework e poi utilizzalo, se ci riesci.
Prova a capire il concetto di linguaggio se ci riesci :-)


 tipo di problema magari quello che gli risolve la soluzione nel minor tempo.
Aggiungo anche il fatto che intrinsecamente si migliora il codice. Io
programmo in modo diverso ora che conosco un pň meglio piů paradigmi
rispetto a quando conoscevo solo l'imperativo.


 
ops ... chiedo scusa :-) ...

 che per altri.
Non mi pare che la domanda fosse questa.

 
a me sembra comunque del c... poi se mi sono sbagliato chiedo scusa e
sono certo che voi guru sappiate dare una risposta piu' sensata ed
intelligente della mia. :-)


Ahahah, povero Dialtone, dove andrai a nasconderti ora? 

 environment.
Certo che fare una ricerca su Google per il significato di "linguaggio
dinamico" no eh?
Povera Microsoft che ha tenuto un simposio in cui ha invitato
ricercatore e presentato progetti vari per portare linguaggi dinamici su
.NET... non s'è accorta che sono 5 anni che ne usava uno già dinamico
<g>
ps. 
http://www.langnetsymposium.com/speakers.asp


 sintomo di ignoranza. Voi che ne pensate?
Fra java e c# si fa prima ad enumerare le ugualianze che non le
differenze.
In c# trovi effettivamente delle caratteristiche che denotano qualche
passo avanti anzichè indietro rispetto a java, dalle cose banali come
le properties all'overload degli operatori o le collections (già prima
dei generics c'erano le basi per fare le collection strong-typed, c'era
da scrivere un po' di codice ma almeno ci avevano pensato).


Ma ROTFL che arroganti che siete.
Linguaggio dinamico e' quello che dice lui non tu. Ora siccome tu 
sottointendi tipizzazione, e non sai nemmeno cosa sia un linguaggio dinamico 
nel vero senso del termine, dovresti per lo meno risparmiarti questi 
consigli...altrimenti rischi di prenderti le solite bastonate. 

 Linguaggio dinamico e' quello che dice lui non tu.
http://en.wikipedia.org/wiki/Dynamic_language

 Prova a capire il concetto di linguaggio se ci riesci :-)
essi' certo.
ho programmato per 5 anni sia in java che in c# che in c, e stai a
vedere che non so che cosa è un linguaggio di programmazione e
soprattutto stai a vedere che non conosco le differenze tra i linguaggi.

 ha scritto nel messaggio 
news:1158756857....@h48g2000cwc.googlegroups.com...

E allora?
Non ho detto che non si possa intendere cosi', ho detto che la prima 
definizione e' l'altra. 

Maro' ... sempre a litigare ...
io ce l'ho piu' grosso del tuo, io sono piu' bravo di te, io so' questo
tu no ... mah!
A me questo sa di ignoranza.
Poi mi posso sbagliare ... non sono un "guru" come voi!

 definizione e' l'altra.
"la prima definizione" perchè? Forse perchè l'ha scritto prima nel
thread?
Suvvia, i linguaggi dinamici sono questi... perchè arrampicarsi
inutilmente sugli specchi solo per la voglia di contraddire?

 Maro' ... sempre a litigare ...
dici a me?

thread?
No, cosi' dicono i testi universitari, che se permetti vengono prima della 
wikipedia (se non altro in termini di tempo). 

 inutilmente sugli specchi solo per la voglia di contraddire?
io sui testi di fondamenti di informatica mi ricordo di aver letto
diversamente.
in ogni caso, ho dato una occhiata e l'articolo stesso (wiki è creata
anche dagli utenti per quanto attendibili, molti articoli sono cmq da
prendere con le pinze...) dice che ci sono più aspetti da considerare
per definire un linguaggio dinamico e nessuno è "definitivo e
assoluto".
e nella lista dice linguaggi che *solitamente* sono considerati
dinamici.

 soprattutto stai a vedere che non conosco le differenze tra i linguaggi.
Sto ancora aspettando la tua definizione di linguaggi dinamici e
statici, possibilmente da una fonte che non sia tu. 


 statici, possibilmente da una fonte che non sia tu.
guarda che l'ho già data, leggi il thread.
la definizione che ho dato a memoria, quindi con parole mie,
la puoi trovare ad esempio su un qualsiasi testo universitario di
informatica di base.
i tesi universitari non li scrivo io, te l'assicuro.

 cos' è che non hai capito?
Il senso dell'affermazione.
Saluti.

 prova a slegare c# dal suo framework e poi utilizzalo, se ci riesci.
Perchè, Java funziona su di una piattaforma senza che su questa esista la 
JVM?
Non mi venire a parlare dei convertitori da Java ad exe.....
Saluti.
PS: C# funziona su almeno due framework distinti (in realtà sono 
quattro...): .NET e Mono.

 wikipedia (se non altro in termini di tempo).
Fra i testi informatici (universitari e non) ne esistono pochi con la
valenza di bibbia. Che vengano prima della wikipedia è tutto da
dimostrare, dipende dall'autore, alcuni valgono meno del manuale delle
giovani marmotte.

 diversamente.
L'informatica evolve e la terminologia con essa. Il mio testo di
linguaggi (Programming Language Concepts di Ghezzi - Jazayeri) non fa
distinzione tra tipizzazione statica/dinamica e forte/debole ma
considera solo tipizzazione statica forte/debole e tipizzazione debole.
Questo sfortunatamente poteva essere considerato vero qualche anno fa ma
10 anni dopo che questo libro e` stato scritto effettivamente non puo`
piu` essere considerato sufficientemente esaustivo, con buona pace di
quel birbante Ghezzi. Che ha il coraggio di dire che i linguaggi statici
non supportano la ricorsione, peccato che Haskell lo faccia e che
quest'ultimo sia un linguaggio nato per essere completamente statico e
analizzabile completamente a compile time.
E` chiaro comunque come dici tu che non basta un solo aspetto per essere
considerati dinamici e non e` neanche necessario averli tutti tutti.
Pero` e` prassi comune nel mondo dell'informatica aggiornata considerare
C, C++, Java e C# come linguaggi statici.
Esiste pure una conferenza dedicata ai linguaggi dinamici:
http://www.oopsla.org/2006/program/program/dynamic_languages_symposium.h
tml


 guarda che l'ho già data, leggi il thread.
Certo che l'hai data, ma è quella che ho contestato. Ti va di citarmi
una fonte? Sui libri di linguaggi che girano nella mia università Java è
decisamente un linguaggio statico. Cosi dicono anche i miei docenti (qui
facciamo quasi _tutto_ in Java). Idem i libri di Java. Andando a memoria
lo dicono anche i libri di C# e .NET che ho nell'armadio. Non pretendo
di avere ragione per forza ma quando si parla di linguaggio dinamico si
parla della sua tipizzazione. Ovvio che poi a runtime ogni linguaggio
allochi memoria per qualcosa :-)


 giovani marmotte.
Purtroppo è vero, ci sono libri che sono _illeggibili_ e non solo per la
qualità dei contenuti. Sembrano scritti da persone che vivono fuori dal
mondo. Comunque appena torno in uni vado a scandagliare tutti i libri
sui linguaggi che ci sono in biblioteca e posto un resoconto di quello
che ho trovato.


 considerati dinamici e non e` neanche necessario averli tutti tutti.
I linguaggi sono statici / dinamici rispetto a certi attributi: gestione 
memoria, tipizazzione ecc...
Non ha senso per quanto mi riguarda statico o dinamico al di fuori di 
questo. 

 allochi memoria per qualcosa :-)
Errato. Un linguaggio statico (riguardo alla gestione della memoria) non 
alloca alcuna memoria a run time.

 allochi memoria per qualcosa :-)
il punto non è allocare o meno memoria, ma come si alloca la memoria e
che porzione di memoria viene alloca.
c'è memoria stack, memoria heap, memoria statica.
ecc. ecc.

 tipizzazzione ecc..)?
Quando dico "linguaggio dinamico" l'aggettivo "dinamico" è riferito al
linguaggio. Quindi deve essere *lui* dinamico, ovvero capace di
definire un *proprio* comportamento a runtime anzichè a compile time.
Passi che tu dica che dynamic language non comprende necessariamente
dynamically typed, ma riferirsi all'allocazione dinamica della memoria
mi sembra un concetto un po' vecchiotto... di quando erano quei libri
di testo? :-)

 quattro...): .NET e Mono.
trovami una azienda con sever unix disposta a fare girare applicazioni
.NET grazie a mono.
trovami un cliente che abbia SO linux disposto a far girare per motivi
professionali programmi .NET.
poi (almeno era cosi' un po' di tempo fà) mono è sempre indietro come
versioni rispetto al framework. forse sono ancora alla 1.0?

di testo? :-)
Questo punto l'abbiamo ormai superato. Io non intendevo quello che hai 
detto.
Lawrance sembra non aver ancora capito a cosa si riferisce Joneleth, tutto 
qua.
E' un po' duro ma ci arrivera' forse... 

 ecc. ecc.
Potremmo aprire un altro thread e discutere dei vari tipi di allocazione
della memoria ma in fondo qui si parlava di altro no?


 versioni rispetto al framework. forse sono ancora alla 1.0?
No ora supporta anche la versione 2.0 ma è comunque indietro, per questo
secondo me Mono non ha mai avuto un gran senso. Checchè ne dica de Icaza
(che comunque qualche utente "aziendale" di Mono ce l'ha), il suo
progetto è costretto ad inseguire e mi viene da ridere a pensare che ha
recentemente dichiarato che a lui di WPF e XAML non frega una mazza. Il
che significa che probabilmente il giorno in cui uscirà Vista saranno
indietro anni luce per un cross (MS <-> Mono). 
Certo a loro in fondo non frega nulla di avere le stesse feature di .NET
(che in pratica _non_ possono avere) ma forse non era meglio investire
su una delle piattaforme esistenti nel mondo opensource?
Mistero della fede.


 detto.
Allora dimmi cosa intendevi, joneleth ha dato questa definizione.
Se è solo una questione tua personale con qualcuno in particolare, 
chiedo scusa per non averlo capito prima e mi ritiro.


Intendevo che joneleth stava parlando di memoria, mentre quell'altro di 
tipizazzione, quindi gli ho fatto notare questo fatto.

 no, ma paragonare JVM a .NET framework č alquanto azzardato.
Perchč?
Saluti.

 Mistero della fede. 

 Quale?
Python, Ruby, Perl ad esempio. Tutte presenti prima di Mono e ampiamente
diffuse nell'opensource (anche più di Mono attualmente dopo 5 anni)


 dopo 5 anni)
La piattaforma è la stessa cosa del linguaggio?
Saluti.

 sintomo di ignoranza. Voi che ne pensate?>
concordo che il dibattito fra i linguaggi se non degenera in tifoseria da
stadio e' un dibattito molto interessante e per noi che ci lavoriamo impatta
sulla nostra vita quotidiana e sulle strategie di medio periodo
Bisogna separare nettamente il confronto purista fra linguaggi , inteso alla
Crespi Reghizzi per capirci e il confronto fra piattaforme.
Ci sono alcune aziende che sposano l'intera piattaforma Microsoft e il
naturale linguaggio e' il .NET e per molte cose C#.
Questo e' di fatto un clone di Java e come tutti i cloni e' migliori
dell'originale perche' gli hanno tolto alcuni difetti.
Per le applicazioni molto server side oggi Java offre piu' soluzioni e
parecchia ricerca mondiale sviluppa software di base per quetsa piattaforma.
A livello "puristico" e' abbastanza riconosciuto che Python e' forse la
proposta migliore
C++ predomina nella grafica
C per sistemi operativi e driver
il resto al momento e' archeologia.
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 La piattaforma è la stessa cosa del linguaggio?
No ma che c'entra? Investi in qualcosa di esistente e se non ti va bene
lo estendi. Perchè inseguire il business di MS? Non ha neanche molto
senso il discorso multilinguaggio perchè Mono supporta praticamente un
solo linguaggio. VB si vede solo ora dopo 5 anni


 praticamente un solo linguaggio. VB si vede solo ora dopo 5 anni
Posso dire una cosa rimanendo nel contesto piattaforma/infrastruttura?
Se non ci fosse java credo che pochi userebbero Linux in ambiente 
enterprise.
Ho detto una fesseria?
Saluti.

 Ho detto una fesseria?
No non mi pare una fesseria (anche se a lungo andare per vari fattori
probabilmente questo non sarà più un fattore predominante), ma continuo
a non capire cosa questo avrebbe a che vedere con il partire da zero
inseguendo MS? 


 Ho detto una fesseria?
Boh. Secondo me si.


 La piattaforma è la stessa cosa del linguaggio?
No ma ognuno dei linguaggi di cui sopra viene con la sua bella
piattaforma e i suoi bei framework per risolvere svariati problemi.


 Nicola
non hai idea  quante righe di cobol/rpg vengono scritte nuove nuove 
tutti i giorni ...


domanda: sai cos'è un batch? secondo te qual'è il linguaggio più
"efficiente"
(velocità, occupazione di memoria) per "masticare" milioni di letture
I-O
in un server classe enterprise?

 da scrivere un po' di codice ma almeno ci avevano pensato).
Giusto, anche se con l'avvento delle Generics le differenze per quanto 
riguarda le collection si sono praticamente appiattite. Ma andiamo con 
ordine. Dalla mia (seppur limitata) esperienza posso dire che:
- C# ha un meccanismo per gli eventi decisamente "interessante" (basato 
in pratica sui delegate).
- C# permette l'overload degli operatori, a me ultimamente è tornato 
parecchio utile.
- C# ha introdotto le properties, che permettono di sostituire i vecchi 
metodi GetXXX() e SetXXX(...) con delle strutture molto più semplici ed 
immediate; parallelamente permettono di esporre i campi di un oggetto 
associando alle operazioni di lettura/scrittura di tali campi delle 
operazioni "trasparenti" per l'utente.
- Java permette di (ad esempio) creare una classe base visibile solo 
all'interno di un package, con membri visibili solo all'interno di un 
package e farla ereditare da altre classi pubbliche, che mantengano tale 
comportamento non esposto (non public, insomma), questo favorisce 
*decoisamente* il riutilizzo del codice tramite ereditarietà.
- Lo sviluppatore Java ha a disposizione una marea di librerie di terze 
parti oltre che quelle Sun (java.*).
Il discorso portabilità (che qualcuno nel thread aveva tirato in ballo, 
ora non ricordo di preciso...) è relativo. IMHO le scelte politiche di 
Sun e MicroSoft sono state quasi agli antipodi. La Sun ha scelto *un* 
linguaggio che tramite una piattaforma portabile potesse essere usato 
per scrivere software che girasse ovunque (il discorso Solaris, Win, 
Linux può anche starci, fermo restando che Sun ha rilasciato già da 
tempo le specifiche della JVM, dunque i vari Mac o BSD possono 
svilupparsela per conto loro... che io sappia esistono diverse JVM oltre 
a quella Sun). La MicroSoft ha scelto *una* piattaforma che gira su *un* 
OS (escludendo il progetto mono, che non è certo targato MS) su cui 
poter scrivere programmi in *più* linguaggi (C++,J# cio+ Java, VB, C#).
Portabilità sulla piattaforma vs portabilità del programmatore ;-)
Ciao,
Giulio

 Portabilità sulla piattaforma vs portabilità del programmatore ;-)
C'è anche da dire che MS è arrivata prima e (in teoria) ha potuto
osservare Sun e imparare dai suoi "errori".


 *decoisamente* il riutilizzo del codice tramite ereditarietà.
In C# è più forte il concetto di assembly che di package. Cioè,
quello che dici può essere fatto con la parola chiave internal, dove
puoi avere una classe base visibile solo nell'assembly. Non so, ci sono
pro e contro anche in questo caso: il pro è che puoi proteggere la
visibilità dalle classi "intruse" ma che dichiarano di appartenere
allo stesso namespace.


La M$ ha rilasciato pubbliche specifiche della VM Net, ed anche una
versione
con sorgente per uso universitario/di ricerca (mi sembra si chiami
Rotor).
Il progetto Mono è partito da tali specifiche.
Per cui non vedo differenze rispetto a Sun, se non che quest'ultima
supporta
direttamente Windows e Linux (oltre al suo sistema operativo Solaris,
come
M$ supporta il suo Windows).
Inoltre ci sono altri progetti open source, come DotGnu, più o meno
completi.

 read-only pubblica ma writable dall'interno...
Tu pensa che in Python non ha da pensare a sti problemi :)
Ah! Morirņ felice senza pensare a "sealed", "public static void main",
"final", "protected readonly"
:-)


 completi.
Decisamente al passo con la versione MS...


 Tu pensa che in Python non ha da pensare a sti problemi :)
Che vita vuota... :-)


Mono ha un compilatore C#, ma anche una VM che esegue il codice
intermedio
(CLR). Perciò programmi scritti in qualunque linguaggio e compilati su
Windows in codice intermedio Net possono, in linea di principio, girare
direttamente immutati su Mono ed altre
implementazioni di Net. Quindi i linguaggi utilizzabili possono essere:
C#, VB Net,
Java (c'è anche un compilatore Mono e forse pure M$ per Java), Cobol,
Delphi/Pascal, ecc. ecc.

 Perchè?
perchè sarebbe come paragonare il motore di una fiat panda vecchio
modello con una bmw nuova full optional.
JVM nella pratica è un mero motore, serve per fare girare il
linguaggio intermedio dei .class su una piattaforma specifica e basta.
se hai bisogno di qualcosa di più di istruzioni elementari, devi o
farti i tuoi framework o usare framework esistenti.
.NET framework è invece un framework completo sotto quasi tutti i
punti di vista (per il purpose per il quale è stato creato...),
contiene tutte le classi e interfacce necessarie per interfacciarsi con
sistemi microsoft e nuovi supporti per varie cose (remoting, sicurezza,
accesso alle API windows con unmanaged code, ecc.).


Non capisco perchè Mono, progetto opensource, deve essere meno
degno di fiducia di, poniamo, JBoss, progetto opensource.
Può essere meno "maturo" di tanti altri progetti opensource, ma non
può
essere criticato in quanto fa riferimento a tecnologie M$ invece
che di altro tipo.
Inoltre chiedo: le versioni non-Sun di Java VM sono al passo con
l'ultimissima di Sun? Se non è così, come credo, su questo punto
Mono non è particolarmente criticabile.
.

 in un server classe enterprise?
MapReduce


 punti di vista (per il purpose per il quale è stato creato...),
Non è esatto. Java VM non va paragonata a "Net framework" ma al
"Common
Language Runtime", che è appunto la VM inclusa in Net. Dopodichè
la Java VM fa riferimento, come minimo, al Java runtime (rt.jar), ed il
CLR, come minimo,
alle sue librerie di runtime (svariate DLL) . L'esatta suddivisione di
queste funzionalità
(cioè VM vera e propria, e librerie di run time) tra i diversi moduli
eseguibili
(EXE, DLL, .O, ecc.) sicuramente è diversa tra Java e Net.


ho scritto *un* server, ce n'è uno solo.
Niente parallelismo. Niente macchina dedicata, tanti task "batch"
(decine) che girano contemporaneamente e puntano
allo stesso DBMS. Inoltre spazio su disco per file temporanei
limitato, limitatissimo. Schedulazioni temporali da rispettare
rigorosamente.

 Delphi/Pascal, ecc. ecc.
Certo ma rimane il fatto che tra 6 mesi gli sviluppatori cominceranno ad
usare WPF massivamente e Mono sarà indietrissimo. Io non sto cercando di
evidenziare il problema tecnologico o la scelta tecnologica. Secondo me
è sbagliato dal punto di vista "filosofico" inseguire una piattaforma
che è in mano ad una corporation che notoriamente produce _tanta_ roba e
ha miliardi di dollari per fare quel che gli pare.


 Mono non č particolarmente criticabile.
Certo, ma essendoci una VM Sun di riferimento su parecchi ambienti la
percentuale di utilizzatori delle alternative scende. Inoltre c'č da
considerare che Sun potrebbe rendere Java opensource entro la fine del
prossimo anno.
Comunque ripeto, forse non mi son spiegato: non č Sun o MS o Java o .NET
che sto criticando. Personalmente, ripeto _personalmente_, trovo l'idea
(l'idea non l'implementazione che č una cosa slegata) del progetto Mono
piuttosto perdente per vari motivi che trovi sparsi qua e la in alcuni
post. 
Speriamo che un giorno MS non esca con una versione di .NET per Linux
perchč mono avrebbe vita davvero dura.


 Language Runtime", (...)
bene, bravo, è esattamente quello che ho detto io: non si puo'
paragonare un motore ad una macchina completa, metaforicamente
parlando.
se poi uno vuol sapere i dettagli tecnici, puo' andare a leggere
svariati siti che li spiegano.

 
E pure Java

 allo stesso namespace.
No io intendevo: una classe pubblica non può ereditare da una classe 
internal con solo membri internal. Questo a volte mi *snerva*. ;-)
Ciao,
Giulio

 "internal" in scrittura!
Bastardi! Lo vedo, dalla versione 2 del framework.... :-)
Sono rimasto indietro perchè il progetto più grosso che sto facendo
lo sto portando avanti con VS 2003 e .Net 1.1.

 proposta migliore
In che senso a livello puristico?

 rigorosamente.
Con una macchina singola non si puo` ottenere questo neanche con un
linguaggio dedicato mi spiace. Se la macchina e` un multiprocessore
funziona sempre e comunque MapReduce (o analoghi sistemi di
distribuzione del carico come multiprocesso) ma hai detto niente
parallelismo.


 svariati siti che li spiegano.
Ma io sapevo che Java veniva distribuito con anche delle librerie e che
la disponibilita` delle tali nel mondo del software fosse sterminato, e`
cambiato qualcosa?



Non è così. Quanto ho descritto è il modo in cui sono organizzati i
centri
elaborazione dati di molti grandi enti, e delle problematiche  più
spinose che si trovano a gestire.
I linguaggi non sono dedicati, ma semplici linguaggi "vecchio stile"
(Cobol,
magari C) i quali risultano molto più "efficienti" per svolgere le
elaborazioni "batch"
senza richiedere macchine 4-5 volte più grosse e costose come Java.
Indovinello: cosa sono le elaborazioni "batch"? sicuramente anche tu
sei
un "utente" di qualche elaborazione batch, ma forse non lo sai! ;-)

 E pure Java
Beh Sun avrą gią reso la sua JVM opensource quel giorno, immagino.


 In che senso a livello puristico?
Magari dove realmente tutto è un oggetto :-)


 un "utente" di qualche elaborazione batch, ma forse non lo sai! ;-)
Io le scrivo le elaborazioni batch :), magari non dentro agli enti e
quindi non conosco la loro situazione interna ma da quello che hai
scritto o sei stato piuttosto vago oppure hai voluto esagerare.


 cambiato qualcosa?
no, o meglio si, dipende cosa intendi per "cambiato".
adesso, io non sono un guru di java, programmo *anche* in java tra gli
altri linguaggi.
per quel che ne so,  se parliamo di JVM le librerie built-in della JRE
sono poche.
poi ci sono le API java standard della sun, che vengono aggiornate ad
ogni rilascio della JDK e quindi ogni volta che la JVM viene
aggiornata: queste ultime sono abbastanza ricche, pero' non soddisfano
certo ogni necessità.
poi ci sono, come dici, librerie fatte da associazioni (ad esempio
CORBA come protocollo per la serializzazione dei dati binaria o una
cosa simile, il cui nome del package infatti inizia cosi') e librerie
fatte da privati.
pero' in questo brodo primordiale di jar et simila, succede che:
1) trovare quello che esattamente ti serve è difficile
2) se usi librerie fatte da privati ti devi comunque fidare,
soprattutto se non hai i sorgenti
3) la JVM originale ha dei limiti, certe cose non le fà, ecco che
ognuno si fà le sue versioni più o meno compatibili con l'originale
ed ecco allora che spuntano come per magia i framework: e se ci avrai
fatto caso, la maggiorparte delle aziende e ditte richiede infatti
gente che sappia usare alcuni fra i più famosi come struts, hibernate
ecc. ecc.


In realtà io rispondevo a chi faceva un elenco di tipi di applicazioni
con
relativi linguaggi, e si scordava i batch che sono di particolare
interesse
in certi ambienti, dove tuttora si usa molto il Cobol. E dove un
programma
Java batch talvolta mostra grossi problemi di efficienza nei tempi
rispetto ad
uno analogo in C o Cobol. Non essendo Java nato per tali tipi di
elaborazioni.

 ecc. ecc.
Non devo questo cosa abbia a che fare con la JVM, al massimo ha a che
fare con il runtime. Detto questo i framework ormai esistono e sono
utilizzabili, che problema c'e`? Anche windows ha poco software quando
lo installi e poi devi installarne che viene da terze parti, questo non
significa che eviti di usare windows e usi un sistema operativo come
BeOS solo perche` fanno tutto loro.
In tutto quello che hai detto l'unica cosa diversa tra i due e` che .Net
ha qualche classe/funzione in piu` builtin. Decisamente nulla che non si
possa risolvere con librerie di terze parti (e java l'ha gia` fatto).


 possa risolvere con librerie di terze parti (e java l'ha gia` fatto).
io non stavo elogiando .NET rispetto a Java e nemmeno stavo elencando
differenze di linguaggio. semmai stavo specificando che JVM della sun e
.NET framework sono cose ben diverse.
punto.

 punto.
Certo... Una e` una Virtual Machine, l'altro e` un insieme di librerie.
Anche il motore della panda e i sedili della ferrari sono due cose ben
diverse.


 librerie.
Beh, per come la vedo io di fatto le due cose sono analoghe. In fin dei
conti, quando con .NET compili un'applicazione, ottieni un eseguibile
in IL, che poi viene trattato dal JITter. Vero che il .NET la
centralità del JITter è più rilevante, ma in fin dei conti mi facevano
notare che pure in Java, almeno a partire dalla versione 1.3, il JITter
è abbastanza rilevante.
Che poi, inter nos, il JITTer cosi' come concepito oggi per me è una
belinata.
-- 
Ciao!
Luca

 belinata.
Come mai? Son curioso. Non so molto dei Jitter .NET e Java...


 Come mai? Son curioso. Non so molto dei Jitter .NET e Java...
Non conosco quello di Java, ma ho approfondito quello per .NET. Se
ricordi, poi, ne avevamo già parlato. Dunque.
Il JITter traduce 'al volo' per la macchina specifica l'eseguibile IL
in codice macchina. Io pensavo lo facesse una volta per tutte, invece
no, lo fa ogni volta che un'applicazione viene eseguita. Che significa?
che se io mando in esecuzione per 10 giorni la stessa applicazione
sulla stessa macchina, questa come minimo verrà ri-compilata (da IL a
codice macchina) 10 volte.
Per come la vedo io, è un lavoro inutile, per il motivo che se è bene
che la traduzione in codice macchina avvenga sulla macchina in cui
l'applicativo dovrà essere eseguito, la reale esigenza di
ricompilazione si verifica in pochi casi, ossia:
- sostituisco qualcosa dell'applicativo (chesso', aggiorno un
eseguibile e/o una dll);
- modifico la configurazione dell'hardware della macchina (è già più
improbabile e assai meno utile; ho reale vantaggio se la RAM viene
portata da 1 a 2gb?).
-- 
Ciao!
Luca

 portata da 1 a 2gb?).
Vero, Python produce il .pyc e basta, senza sti patemi :-)
-- 
Lawrence - 
http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 Vero, Python produce il .pyc e basta, senza sti patemi :-)
Vero anche che il livello di ottimizzazione č assai piů basso. Ora,
sono il primo a riconoscere che Python č parecchio efficiente (mi ha
abbastanza stupito, in effetti - ma in fin dei conti non si usava un
interprete anche con VB?), pero' devo anche riconoscere che un
applicativo .NET in release mode č davvero un fulmine.
-- 
Ciao!
Luca

 assolutamente trasparente.
Capisco. Ricordo che ne avevmo già parlato però non ricordo quale era la
motivazione per cui NGEN non è integrato nel processo di
"jittizzazione". Probabilmente perchè vogliono mantenere la portabilità
dei binari il più possibile.


 ad usare WPF massivamente
Mi viene da piangere....Ora che sono diventato superproduttivo su .NET 2.0 
questi mi cambiano tutto sotto il naso un'altra volta....MONDO CRUDELE!!!!!

 questi mi cambiano tutto sotto il naso un'altra volta....MONDO CRUDELE!!!!!
Ah ah :-)
si stava meglio quando si stava peggio e si usava tutti C :D


GdG ha scritto:

Questo vuol dire invecchiare... una volta avresti fatto salti di gioia 
perchè cambiava tutto il framework... :-)

 portabilità dei binari il più possibile.
Beh, ma in fin dei conti la portabilità dei binari rimarrebbe. Segui
l'idea: se invece di fare la compilazione ogni volta che lancio un
eseguibile rendo il JITter un po' meno stupido e faccio in modo che la
esegua solo quando serve, attivando caching su disco del compilato, non
devo modificare la compatibilità binaria, che è fin da subito garantita
solo a livello di IL e tale deve rimanere.
-- 
Ciao!
Luca

 solo a livello di IL e tale deve rimanere.
Beh l'idea ci starebbe. Prova a proporla a chi di dovere...


 Beh l'idea ci starebbe. Prova a proporla a chi di dovere...
Chi sono io per discutere Microsoft? ;-)
Lawrence, io sono in piedi perché non riesco a prendere sonno, tu che
scusa hai?
-- 
Ciao!
Luca

 scusa hai?
Deve commentare il mio blog :-D tiè.
-- 
*Ester Memoli*
________________________________________________
My favourite query:
http://office.microsoft.com/it-it/results.aspx?Scope=TC&Query=memoli
:-D ________________________________________________ 

 Deve commentare il mio blog :-D tič.
Donna, non mi stuzzicare... :-D
-- 
Ciao!
Luca

 scusa hai?
Io sto imparando Common Lisp sul serio (anche perchè mi serve per l'uni)
:P


 :P
Ahah! Un giorno ti contaminera` a tal punto che non potrai piu` farne a
meno... Pensare in common lisp apre una serie di evoluzioni future.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 meno... Pensare in common lisp apre una serie di evoluzioni future.
Lo so lo so, è il funzionale che ci attrae :)
Dopo 2 settimane di Erlang già "odio" i thread più di prima fai te :P


 applicativo .NET in release mode è davvero un fulmine.
parliamone.
un po' meglio di java si, ma un fulmine...
la MS aveva provato a scrivere varie librerie grafiche di vista in c#,
ed infatti poi hanno abbandonato il tutto e sono tornati al C++, o al
VC++ per interfacce grafiche.

 VC++ per interfacce grafiche.
Beh, detto fra noi, non mi aspetterei nulla di meno. Librerie grafiche
= necessità di prestazioni, io addirittura ci vedrei bene un buon C.
-- 
Ciao!
Luca


Questo vale anche per il JIT della JVM: ogni santa volta che il
programma
va in esecuzione il JIT ricompila tutto.
Sia in Java che in Net la compilazione è parziale: vengono compilate
solo le
classi/moduli realmente eseguiti nel momento che servono, ed appoggiati
in una cache, naturalmente solo per quella esecuzione.
Alcuni giustificano questo dicendo che sarebbe più efficiente questa
compilazione "dinamica" di quella "statica" fatta una volta per tutte.
Sarà..............

 siamo stanchi.
Clone di java e c++ ci sta... ma secondo me clone del C che è un 
linguaggio procedurale non ad oggetti nn ci sta... magari possiamo 
definirlo C-Like come sintassi :)


Dal momento che Vincent Vega sa benissimo che non e' tutto un oggetto, 
immagino che intendesse che non esistono variabili, funzioni esterne alle 
classi.