Newsgroup: it.lavoro.informatica
Titolo: per i colleghi javisti

Che ne pensate di velocity? Altri template engine ne avete provati?
Esperienze? Tips&Tricks. TIA

 Che ne pensate di velocity?
Java e velocity? E' un nome volutamente ironico, no? 
-- 
__________________________________________________
Luc (34, CO)
MS Visual Studio developer - Programmer since 1985
__________________________________________________

Luc ha scritto:

Ehhh , hai poco da fare il gallo, visto che .NET funziona con una VM
proprio come Java...

 Esperienze? Tips&Tricks. TIA
Lo uso spesso, e mi trovo molto bene. Il principale concorrente è
Freemarker, ma non l'ho mai utilizzato.
L'utilizzo principale per me è la generazione di documenti basati su
template, in particolare email. Qualcun altro lo utilizza come tecnologia
di rendering alternativa a jsp, sulla qual cosa ho qualche dubbio visto
che favorisce una programmazione un po' troppo "spaghetti" per i miei
gusti.
L'api è di una banalità unica, almeno nelle funzionalità di base.
Lo inizializzi con qualcosa tipo
Properties p = new Properties();
p.setProperty("file.resource.loader.path", templateDirectory);
Velocity.init(p);
dove a 'templateDirectory' sostiuisci la cartella del tuo filesystem in
cui tieni i template (l'errore tipico è non fare questa inizializzazione,
o sbagliarla, per cui avrai un eccezione tipo 'non riesco a trovare il
template')
Dopodiche' renderizzi il template con qc del tipo
VelocityContext context = new VelocityContext();
context.put("foo", myFooObject);
context.put("bar", myBarObject);
Template template = Velocity.getTemplate("mio_template.vm");
template.merge( context, ... );
e il tuo template e' un comune file di testo (di solito con estensione .vm)
in cui metterai i marcatori ${foo} e ${bar} che nel rendering saranno
sostituiti col valore degli oggetti myFooObject e myBarObject che hai
messo nell'oggetto context.
--
Mopo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 proprio come Java...
Ciò che io programmo genera efficienti eseguibili win32... :-PPPPPPPPPPPPPPPPPP 


 proprio come Java...
Figlio mio (;-) ), dovresti sapere che:
a) il mio omonimo programma in C++ (sei l'unico che non lo sa, a quanto
pare);
b) dei linguaggi presenti in 
VS.NET
, C++ è l'unico che ti consente la
scelta fra ambiente managed e unmanaged (e in questo caso, è
esattamente identico al C++ precedente, nel senso che vai direttamente
a MFC o addirittura a Win32, volendo).
Se mi parli di ambiente managed, comunque, mi tocca darti ragione, .NET
è lentulo tanto quanto.
-- 
Ciao!
Luca

 Che ne pensate di velocity?
Per il 90% dei miei lavori uso Perl con HTML::Template e dovendo usare Java 
per alcuni lavori ho provato Velocity e mi sono trovato molto bene (sono 
abituato a lavorare con il concetto di codice separato dal template).
Confronto a HTML::Template la sintassi risulta molto più pasticciata ma è 
indubbio che potendo gestire i parametri passati come veri oggetti Java 
risulta molto potente.


Ahhh, usi Delphi!! ;-)

 a MFC o addirittura a Win32
Ehi, grazie della spiega, ma questa di cui sopra è un po tirata per le 
orecchie... MFC è solo un wrapper di win32, quindi sempre codice win32 è... :) 


 Per il 90% dei miei lavori uso Perl
Il peggior linguaggio che abbia mai visto "since 1985". Parlo dal punto di 
vista del programmatore, non delle capacità del linguaggio... Or Die... :P 


 
già, come se efficienza significasse aprire una finestrella.
ciao, U.

 win32 è... :)
Certo, però sai meglio di me che MFC aggiunge un bel po' di overhead
che se scrivi applicativi win32 "Petzold's style" non hai. Il risultato
è drammaticamente differente, anche solo in termini di dimensione degli
eseguibili, senza contare i bencmark che giravano all'epoca (io ho
smesso con il C++ nel '98, purtroppo... :()
Certo, MFC è MOLTO, MA MOLTO più comodo se si vuol fare roba complessa
(anch'io ho usato MFC, e dalla prima versione).
-- 
Ciao!
Luca

 già, come se efficienza significasse aprire una finestrella.
O calcolare gli algoritmi di trasparenza sopra le bitmap... o il drop-shadow di 
un testo... o la massima efficienza di lettura/scrittura su DB...
A tua scelta! :-P 


 (anch'io ho usato MFC, e dalla prima versione).
MFC lo uso principalmente per le interfacce o per la comoda "CString". Quando 
il gioco si fa duro, MFC non c'è più... :)


 linguaggio... Or Die... :P
Questione di punti di vista.
Anche io all'inizio ero decisamente scettico, ma con il tempo ho imparato ad 
apprezzarlo moltissimo (sia in ambito web che per script in ambito 
sistemistico).
Ovviamente non è adatto a tutto (mai a poi mai lo userei per esempio per 
interfacce grafiche), ma per certe cose è di una comodità enorme 
(soprattutto per via di CPAN e di nostre librerie interne sviluppate e 
consolidate negli anni).

 
ciao, U.

 ovvero aprire le finestrelle
Si, si... Sai che belle le finestrelle in Postscript? :-PPP 


 è lentulo tanto quanto.
dipende di cosa parli.
le interfaccie java tipo swing e awt sono di una lentezza e di una
macchinosità ineguagliabile da sempre.
quelle .NET in release no a meno che non usi componenti come datagrid
o simili che nel frmework 2.0+ hanno introdotto molta flessibilità e
molte più opzioni biltin che poi si traducono in più codice e quindi
più lentezza a parità di potenza di calcolo.
per altre cose e in generale, considerando che .NET è monopiattaforma
e quindi in teoria più specializzato di java, direi che comunque le
performance sono migliori.
Chiaro che se cominci ad usare per .NET -ad esempio- per accesso ai db
relaz. dei driver non nativi come quelli per SqlServer perdi in
prestazioni dovendo usare dei provider esterni, mentre se per java usi
quelli classici guadagni. ecc. ecc.

Luc ha scritto:

Quando il gioco si fa duro.. Windows non c'e' piu'! ;)

 Quando il gioco si fa duro.. Windows non c'e' piu'! ;)
Vero fin la. Io ho visto Win, adeguatamente ritagliato, impiegato in
posti impensabili.
-- 
Ciao!
Luca

 Quando il gioco si fa duro.. Windows non c'e' piu'! ;)
Molte aziende danno XP o CE di serie, versione embedded, in
applicazioni
di controllo industriale.
Se facesse tanto schifo perchè lo farebbero? D'altronde mica
tutti hanno tempo per ricompilare il SO su misura come il vestito del
sarto: questa dll ce la metto, quest'altra no che mi brucia
10k.... :-)
 W W(in)! :-))

 che se scrivi applicativi win32 "Petzold's style" non hai. 
non è vero, ma vedo che questa è una leggenda dura a morire.
quella di ottimizzare un programma win32 (non console, ovviamente) 
facendo a meno di framework come mfc è una teoria più o meno equivalente 
al paradosso di zenone.
in un programma win32 chi richiama la tua logica applicativa? le window 
proc. praticamente delle funzioni che per il 99% del tempo non vengono 
invocate o vengono invocate per dei messaggi che ignori. quindi con 
tutto il tuo ottimizzare agisci se va bene sull'1% del tempo di 
esecuzione del programma. e sempre che tu riesca ad ottimizzare, perchè 
non sta scritto da nessuna parte che tu scriva codice più performante 
delle mfc, dato che esse fanno largo uso delle macro a scapito delle 
caratteristiche tipiche del C++ proprio per evitarne l'overhead.

 consolidate negli anni).
sulla modularità nulla da dire... vai di comandi tipo
cpan install;
e sei "compatibile" con il mondo!

 Quando il gioco si fa duro.. Windows non c'e' piu'! ;)
Ecco il furbone del thread... :-/ 


 Io non ho MAI programmato con MFC
MFC non è un linguaggio. Non te ne intendi molto, eh... 


 MFC non è un linguaggio. Non te ne intendi molto, eh...
microsoft foundation classes, librerie surclassate da .NET framework
capace delle stesse cose ma con un risparmio di tempo e di lavoro
mostruoso, automatizzando e standardizzando procedure e chiamate alle
winAPI che prima richiedevano di essere trattate nei dettagli e
creando una gerarchia di oggetti molto più definita.
Sono utili quando o non si utilizza il framework .NET (quindi in
genere per applicativi su win98 o precedenti o su server non NT) o per
mantenere  compatibilità con vecchi programmi o ambienti che non si
vogliono rifare completamente.
per il resto oggi non vedo necessità pratiche di usarle se non per
applicativi molto specializzati e critici e per nulla portabili che
necessitano di esplicita programmazione massiva a medio-basso livello,
visto che anche .NET consente di usare codice unsafe all'interno di
codice c#/vb ecc.

 E che esiste anche Mono...
si, ma in teoria .NET è stato creato monopiattaforma, che poi lo usino
con delle "virtual machine" terze per farlo andare su linux o su altri
SO è un altro discorso, che esula dagli intenti e dal lavoro di chi lo
ha creato.

 microsoft foundation classes, librerie surclassate da .NET framework
Mah... io personalmente ci vedo una radice comune. E se devo essere
sincero, in ordine di prestazioni considero tuttora 1o Win32 diretto,
2o MFC, 3o .NET framework. Possono raccontarmela fin che vogliono, in
base a prove provate .NET è più lento del resto.
-- 
Ciao!
Luca

 E che esiste anche Mono...
si, e anche Babbo Natale e la Befana.
per scrivere programmi multipiattaforma .NET bisogna volerlo,
considerato che .NET è adottato da MS per lo sviluppo specifico per la
piattaforma Windows la cosa è alquanto improbabile. Su Mono non puoi
portarci tutto anzi non ci porti praticamente nulla.

 portarci tutto anzi non ci porti praticamente nulla.
A parte il fatto che ricordo gente che diceva il contrario, nessuno ti
vieta, a quel punto, di sviluppare per Mono anche sotto Windows.
Ottieni il fatto che, dato che comunque si appoggia su GTK+, le
modifiche da un SO a un altro dovrebbero essere tutto sommato limitate.
-- 
Ciao!
Luca

 ha creato.
Non č che lo usano con virtual machine terze eh, l'hanno semplicemente
reimplementato. C'č roba in piů e roba in meno in Mono
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 vieta, a quel punto, di sviluppare per Mono anche sotto Windows.
Me lo vieta quel poco di dignità di programmatore che mi è rimasta...

 Me lo vieta quel poco di dignità di programmatore che mi è rimasta...
Mono è opensource. Se apprezzi l'opensource in generale, non puoi
criticare Mono. Punto.
Purtroppo nasce da specifiche pubbliche di MS, ecco il suo peccato
originale... ;-)
Se le specifiche le avesse scritte Torvalds, o magari Sun, invece,
sai
quante lodi.... Che bel framework, che belle idee...... :-))

 reimplementato. C'è roba in più e roba in meno in Mono
quindi tu mi dici (perchè la mia conoscenza di linux è alquanto
limitata) che hanno riscritto tutto il framework
riadattandolo a linux.
ma mono non serve per fare girare applicativi fatti con .NET sotto
linux?
se è cosi' la struttura del framework (dichiarazioni di interfacce,
classi e namespaces) dovrebbe essere inalterata, semmai quella che
cambia è l'implementazione all'interno delle singole classi.



ahh ok forse ho capito, con roba in meno intendi che non supporta le
pinvoke dirette alle winAPI o la gestione diretta dei messaggi winproc
delle form e cose del genere, che in effetti sono cose specifiche di
windows.
con cose in più invece non capisco cosa intendi.

 cambia è l'implementazione all'interno delle singole classi.
Sicuro. Però concorderai con me che cose come le classi che lanciano IIS
o quelle troppo legate a Windows come sistema operativo difficilmente
funzionano e funzioneranno su altri sistemi operativi


 quante lodi.... Che bel framework, che belle idee...... :-))
Io personalmente non amo Mono perché lo trovo un enorme sforzo per una
motivazione un po' blanda. All'inizio rincorrevano MS, ora non più ma
rimane il fatto che nell'opensource non c'era bisogno di Mono :-D O
meglio... si potevano spendere in mille altri modi i soldi e il sudore
spesi per Mono.
Questa è la mia personalissima opinione ovviamente. Mono in fondo è
un'altra opzione e si sa come nell'opensource la concorrenza sia un
bene.
Per me può benissimo restare ma non credo che lo userò tanto presto di
nuovo (son passati anni dall'ultima volta)


 vogliono rifare completamente.
Non utiliziamo .net nei prodotti di cui mi occupo ed essendo stati inizialmente 
progettati circa 8 anni fa solo MFC c'era. :)


 windows.
Cose tipo: creazione di servizi Windows; gestione
infrastruttura Windows component server (COM+, transaction
coordinator, ecc.); classi per accesso diretto/ottimizzato
a Sql Server; ed altro

 motivazione un po' blanda.
Ok. Ma nell'opensource si trovano molte altre attività abbastanza
inutili. Per esempio, Freebsd è un SO equivalente a Linux, o viceversa
se vuoi.

 se vuoi
Questa è un po' una cazzata eh ;-)
Potevi trovare un esempio migliore :P
FreeBSD c'azzecca poco con Linux. È come dire che Windows assomiglia a
[scegli un altro sistema operativo]
su quali basi lo affermi?



 Bè, allora non l'ho scritta io la prima cazzata ;-)
FreeBsd è un SO opensource come Linux. Non so chi dei due è
arrivato primo, chi è meglio e chi è peggio, ma uno dei 2 gruppi di
sviluppo potrebbe oggi tranquillamente dedicarsi ad altro, invece di
fare un'altro SO.
Mono ha solo il problema di non essere supportato da MS, per il resto
è un'iniziativa interessante.

 è un'iniziativa interessante.
Nasce proprio per staccarsi da MS ;-)


 quante lodi.... Che bel framework, che belle idee...... :-))
La mia è una affermazione di sostanza, non di filosofia.

 se vuoi.
In che senso equivalente?

 vedo UN solo motivo per cui dovrei rivolgermi a .NET.
- E' basatto su un'ottima analisi, che funziona.
- E' già presente una ottima documentazione, milioni di esempi, libri,
corsi ecc..
- Ha già una base di software sviluppato
Se l'obbiettivo fosse la produttività a basso prezzo, MONO sarebbe una
ottima scelta....



Permetterai che proprio su quei tre punti che hai citato ci sono altri
strumenti che lo surclassano di qualche ordine di grandezza. Voglio
dire, se la metti su questo piano basta Java, il che è tutto dire...

 dire, se la metti su questo piano basta Java, il che è tutto dire...
Java dici ? Va molto bene in embedded ed in enterprise dove regna IBM,
ma è stato di fatto scartato per lo sviluppo spicciolo sul web (php
docet) e sul client server (librerie grafiche scadenti).


Bè, magari perchè i clienti ti chiedono quello, invece che Java.....
Di solito quello è uno dei motivi decisivi :-)
Per adesso Mono non è strombazzato come Java, ma diamo
tempo al tempo.

 docet) e sul client server (librerie grafiche scadenti).
Sono il primo a dire che Java è il peggio di tutti, ma sei tu che
l'hai messa sul piano della letteratura e dei corsi. La prossima
settimana 2-5 luglio se ti interessa a Milano c'è un training RedHat
per la certificazione JBoss, io ci sarò (pagato dall'azienda perchè un
po' caro). Non sono potuto passare dal PyCon a Firenze per impegni
contingenti ma mi hanno detto che è stato molto interessante. Insomma,
di iniziative ce ne sono e si fa fatica a stargli dietro. Però Mono
sarà anche il più attivo e documentato di tutti ma non lo vedo, per
carità è per colpa mia che non mi interesso, ogni delucidazione da chi
ne sa di più è ben accetta.

 vedo UN solo motivo per cui dovrei rivolgermi a .NET.
Beh, il primo motivo potrebbe essere perché tutto sommato è un buon
framework, armonico e molto completo. Almeno, è così perché è
relativamente giovane, vedrai che crescendo troveranno modo di
complicarlo inutilmente, come è già successo per molte altre cose... ;-)
-- 
Ciao!
Luca

 dire, se la metti su questo piano basta Java, il che è tutto dire...
Beh, se Java surclassa .NET è solo per una questione di tempo di
presenza sul mercato. IMHO Java è tecnicamente leggermente inferiore a
.NET (dico leggermente perché, sempre IMHO, i progettisti di .NET
qualche occasione l'hanno persa...)
-- 
Ciao!
Luca

 docet)
Anche questo non mi vede d'accordo. Ho visto molta roba in PHP, ma se
vuoi fare delle servlet decenti non c'è PHP che tenga, devi andare con
Java.
-- 
Ciao!
Luca

 Java.
Beh sostanzialmente il concetto di servlet è Java :D
Diciamo che quasi tutto è meglio di PHP sul web ;-)


 qualche occasione l'hanno persa...)
A quali occasioni ti riferisci?


 A quali occasioni ti riferisci?
Ricordi ad esempio la questione, di cui parlavamo proprio io e te, del
compilato invece della compilazione JIT se le condizioni della macchina
non cambiano?
-- 
Ciao!
Luca

 E non farmi le pulci sulla frase...
Guarda che è la frase standard di tutti coloro che non usano MFC:
"io non programmo con MFC"
La quale dimostra la loro "coglionagine" in materia. :P


> Ripeto: per i tre punti da te citati basta e avanza Java.
Aspetta, ci stiamo staccando dal discorso base :
La domanda era il perchè uno dovrebbe sviluppare un compilatore .net
multipiattaforma.
In questo senso ti dicevo che su .net c'è letteratura (già fatta),
analisi (già fatta) ecc.. e che quindi, nell'ottica di fare una
piattaforma di sviluppo open source alternativa a Java ha
perfettamente senso copiare la .net. Anzi, è decisamente una furbata,
in questo modo hai analisi, concetti e task facilmente assegnabili a
chi vuole contribuire.
Il discorso "ma non bastava java" invece non ha senso : si potrebbe
dire la stessa cosa delle varie distribuzioni o di mille altre cose.

 non cambiano?
IMHO la JIT è la soluzione migliore. Il compilato è più veloce ma ha
delle controindicazioni enormi.
Prima fra tutte l'aggiornamento del framework, con la frequenza di
patch attuale se hai un JIT puoi sempre assicurare la compatibilità
perchè cambi anche l'interprete.
Poi se vuoi un exe indipendente che fai ? Linki tutte le librerie ?
Otteresti un exe da 50 MB per un notepad.
Se invece le linki dinamicamente torni alle vecchie dll e
all'incompatibilità tra versioni alla maniera del VB6.
Tanto se vuoi velocità ed affidabilità devi usare MFC....

 non cambiano?
Capito :-)


> Diciamo che quasi tutto è meglio di PHP sul web ;-)
E questo lo quoto. Ma è un dato oggettivo che per il piccolo
cabotaggio e per tanti progetti (
http://opensourcecms.com/
 ) php venga
usato tantissimo.
Può non piacere ma per tante cose ad oggi è il linguaggio vincente.

 Otteresti un exe da 50 MB per un notepad.
Ovviamente no. Pero' compilo il codice IL in eseguibile in una specie
di cache solo le volte in cui serve, e non tutte le volte che
l'eseguibile viene lanciato. In fin dei conti non è una cosa
trascendentale sapere che sono state aggiornate patch e/o che è
modificato l'hardware. E in ogni caso, la compilazione in blocco
monolitico non si fa più nemmeno con MFC da anni e annorum (anche se la
possibilità penso esista ancora)
-- 
Ciao!
Luca


Anche il runtime ormai è di 50 mb o giù di lì, sia per Java che per
Net. Volendo essere del tutto indipendenti dalla piattaforma si
trascinano
dietro un sacco di roba. Quindi non è che cambia molto.
Anche l'incompatibilità tra le versioni di runtime esiste, quindi può
essere
che devi installare diversi runtime contemporaneamente per differenti
eseguibili.

 multipiattaforma.
Veramente la domanda era (in soldoni) perchè scegliere .NET per
sviluppare in multipiattaforma.
Io non lo sceglierei. E sia chiaro che con .NET sotto Windows ci ho
lavorato per anni, anche con soddisfazione, però su Windows hai MSDN.
Inoltre su Windows il framework è praticamente concepito come l'API
della piattaforma (lo raccomanda la Microsoft stessa), quindi la
scelta conveniente per chi vuole sfruttare al meglio Windows. Ma se
uno non ha questa esigenza anzi ha l'esigenza della multipiattaforma
ci sono scelte molto migliori.
Ovviamente a mio avviso.
Poi ovviamente gli scenari cambiano e cambiano anche le idee,  In
futuro si vedrà, la mia opinione è sul presente.


 eseguibili.
Tra patch in .net mi risulta che esista la compatibilità verso il
basso.

 l'eseguibile viene lanciato. In fin dei conti non è una cosa
Ah ok, l'idea sarebbe quindi di mettere il compilato da qualche parte
ed eseguire quello. Sarebbe più veloce ma delegherebbe la gestione
memoria ad una qualche forma di heap. Controllare diritti a livello
profondo, garbage ed eccezioni come fa la .net sarebbe molto ma molto
più difficile.
Magari c'è da dire che la .net risponde molto di più al problema
soluzione web, e molto meno per il client server...

 più difficile.
Perché? Scusa, se la prima cosa che fa IL con il JITter è quella di
compilare in memoria il codice per trasformarlo in codice binario, mi
spieghi che differenza ci sarebbe a farlo una tantum, e depositare il
compilato in una cache da richiamare a meno che qualcosa nell'ambiente
sia cambiato, invece che tutte le volte che l'applicativo viene
eseguito?
-- 
Ciao!
Luca


Esiste il comando da console: ngen, fa parte delle utility di Net
(non ricordo se nel SDK od anche nel runtime). Fa proprio quello.
Ciao

 (non ricordo se nel SDK od anche nel runtime). Fa proprio quello.
No. NGEN produce un compilato che, una volta generato, non viene più
modificato. Ergo, quando cambia qualcosa, il compilato non viene
rigenerato.
Ciò cui pensavo io è una soluzione intermedia, ossia: il JITter
verifica l'ambiente; l'ambiente è cambiato e/o non ho un compilato in
cache? bene, eseguo la compilazione del codice IL; l'ambiente non è
cambiato e ho un eseguibile in cache? bene, lancio direttamente
l'esecuzione di quanto in cache e mi metto da parte. E'
un'ottimizzazione IMHo rispetto al fatto che il codice IL venga
ricompilato virtualmetne TUTTE le volte che un eseguibile viene
lanciato!
-- 
Ciao!
Luca

 eseguito?
Ah, ok, dici prendiamo il codice generato dal JIT, salviamolo al primo
utilizo ed eseguiamo quello.
Quindi l'ipotesi è continuare a "rilasciare" l'MSIL ma la prima volta
che viene eseguito su quella macchina generi un compilato e poi esegui
quello.
Penso che non sia stato fatto non perchè non ci hanno pensato, ma
perchè gli svantaggi non coprivano i vantaggi, in fin dei conti
risparmi solo qualcosa a volte in avvio.

 risparmi solo qualcosa a volte in avvio.
Veramente risparmi TUTTE le volte che avvii l'applicazione...
-- 
Ciao!
Luca

 (non ricordo se nel SDK od anche nel runtime). Fa proprio quello.
E infatti soffre di tutti i problemi del caso.
Ngen ti compila l'applicazione ma poi gira in nativo praticamente solo
su quella macchina.
In oltre devi essere (ovviamente) amministratore di macchina per
compilare un exe, quindi neppure puoi usarlo in automatico.

> Veramente risparmi TUTTE le volte che avvii l'applicazione...
Si ma dovresti quantificarlo. Quanto costa compilarlo rispetto a
caricare tutte le dll ? E quanto costa fare tutti i controlli a cui
accennavi ? E cosa dire circa la sicurezza della presenza di un
precompilato su disco che verrà eseguito al posto dell'exe
originale ?
Sono sicuro che al tempo i progettisti si sono scannati usando
esattamente i nostri pro ed i nostri contro ;-)
Probabilmente la tua soluzione (che è più "prestante") è stata
scartata perchè non gli funzionava, troppo difficile da gestire.
Comunque sarebbe una idea far uscire dei processori in grado di
eseguire l'MSIL.... sai che dispositivi embedded si potrebbero fare !

 compilare un exe, quindi neppure puoi usarlo in automatico.
Se vuoi che l'eseguibile si adatti automaticamente alla macchina su
cui
gira, che riconosca *tutti* i cambiamenti di runtime, altre librerie,
ecc.
allora.... vuoi il Jit! :-)
E comunque puoi usare ngen su alcuni assembly, e lasciare altri al
Jit.
Non si può avere la botte piena e la moglie ubriaca, urca! :-)

 su quella macchina.
Dimenticavo. Lo usi quando installi su una determinata macchina,
e risolvi il problema.

 direttamente in C.
Sì ma fra perl e awk non so chi abbia la sintassi peggiore :)
-- 
Vide

 - Mostra testo tra virgolette -

 Sě ma fra perl e awk non so chi abbia la sintassi peggiore :)
Il Perl ha una sintassi criptica se viene usata male, ma se usata 
correttamente risulta perfettamente leggibile a chiunque e ha anche delle 
finezze molto carine.
Tutto dipende da come la si usa.