Newsgroup: it.lavoro.informatica
Titolo: Quanti conoscono linguaggi - meno diffusi

Questo č un interrogativo sul 'modo di operare' delle aziende,
forse č anche un sondaggio.
Generalmente le aziende richiedono conoscenza/esperienza di
programmazione in uno o piů linguaggi di programmazione,
 tra i piů diffusi java, c++, vb, javascript...
e anche framework nei vari linguaggi.
Le aziende raramente immaginano di sviluppare in linguaggi meno
diffusi come lisp, python, ruby, o'caml, erlang
Ipotizziamo che un'azienda decidesse di sviluppare un sw in lisp, o
usando ruby on rails, o in un'altro di questi linguaggi o suo
framework,
e che questo avesse perfettamente senso per il progetto:
quanti sanno progammare o
sanno che potrebbero imparare a programmare: in breve in:
lisp (e famiglia)
python, ruby
o'caml
haskell
N.B. per i meno ferrati ricodo che un diverso linguaggio NON č solo
una diversa sintassi e che (questa č una mia opinione) per imparare
certi linguaggi non bastano tre mesi.
Ciao
Chairam

 certi linguaggi non bastano tre mesi.
A parte haskell che e` totalmente diverso dai linguaggi 'tradizionali' e
o'caml che non conosco quasi per nulla.
lisp, python e ruby si imparano (e intendo imparare a pensare come dio
comanda usando quei linguaggi, perche` tanto la libreria non la impari
neanche dopo 5 anni, lo standard CL sono 1300 pagine) tranquillamente in
3 settimane.
Per python ci sono svariati libri ovunque (scritti anche da italiani,
alcuni revisionati da me ufficialmente, con citazione negli Ack) tipo
Python Cookbook (2nd edition), Python in a nutshell, Learning Python,
win32 applications with python, game programming with python blablabla e
tanti tanti altri tra cui l'ultimo Twisted: Networking Essentials (tutti
di O'Reilly). Ci sono anche infiniti libri online tipo How to think like
a computer scientist o Dive into python (anche edito da APress mi
sembra) o Text processing with python ecc ecc.
Per Ruby c'e` il Pragmatic Programmers, la poignant ruby guide
(
http://poignantguide.net/ruby/
) e altra roba che pero` non conosco
molto (non e` documentato COSI` tanto questo linguaggio ma in generale
quello che c'e` basta e avanza) e per lo sviluppo web Ruby on Rails
Developer Guide (o come cavolo si chiama).
Anche per lisp (Common Lisp per la precisione) ci sono svariati libri.
Da onlisp di Paul Graham (non facile per iniziare) al Practical Common
Lisp (
http://www.gigamonkeys.com/book/
) appena uscito e sempre
aggiornato nella versione online e in arrivo il bestione  The Ansi
Common Lisp Reference Book
(
http://www.apress.com/book/bookDisplay.html?bID=263
)
Per haskell oltre al corposo elenco sul loro sito:
http://www.haskell.org/bookshelf/
C'e` anche questo interessante tutorial:
http://www.haskell.org/~pairwise/intro/intro.html
Detto spassionatamente da uno che lavora al 100% su python e ci vive,
uno solo dei linguaggi di cui sopra vale 10-100-1000
vb/C++/java/C#/.Net/sticaz/enterpraiseBlabla/vattelapesca, poi puo`
essere questione di scelta e convenienza (il C no, quello e` una manna).
Sinceramente un linguaggio che necessita di anni per essere imparato
alla perfezione come il C++ puo` difficilmente essere messo tra i
linguaggi produttivi o 'belli', anche se ovviamente puo` piacere; pero`
se ti parlo di metaprogrammazione in C++ ti spari in testa, se lo faccio
in Common Lisp o Python o Ruby o simili diventa una discussione del
livello di quelle in cui ti chiedi come funziona il copy constructor in
C++.
E` una diversa concezione di lavoro. Io sto realizzando un software
decisamente complesso per la gestione delle email (con in ballo diversi
standard ETSI, ISO, IEEE e sticazzi sulle firme digitali, sulla firma
con smartcard, sullo scambio di informazioni in modo sicuro e
quant'altro visto che e` commissionato da un gruppo notarile grosso
grosso) in python. Siamo 4 sviluppatori di cui solo io a tempo pieno e
gli altri impegnati dall'80% al 40% del loro tempo a seconda del
periodo. In 2 mesi (da meta` settembre circa, con una settimana passata
a parigi a fare altro) e circa 400 ore di lavoro di sviluppo abbiamo
tutto funzionante, distribuito, facilmente aggiornabile, quasi
totalmente failsafe (usavamo il nostro servizio mentre lo sviluppavamo e
non e` stato perso un dato, nonostante i riavvii, crash, cadute della
rete, non-risposte della macchina ecc ecc) con un deployment da far
ridere per la semplicita`.
Il progetto ne integra ed estende altri per un totale di oltre 450 mila
linee di codice senza contare il codice di applicazioni esterne tipo
postfix o gnupg che non fa parte della codebase ma e` usato.
E gli sviluppatori sono sparsi in europa (2 in germania, uno in olanda e
io in italia). Sinceramente non so quanti altri linguaggi permettano di
gestire un progetto di tali dimensioni e complessita` senza ore e ore
spese a fare pianificazioni dell'architettura (che noi abbiamo cambiato
3 volte mentre scrivevamo il codice, ma tanto coi test sappiamo sempre
cosa funziona. Abbiamo test che fanno partire 3 server di posta che si
rimbalzano le mail che vengono spedite dal test e ne fanno i dovuti
controlli. Altri che fanno partire web services o che creano repository
svn di test che vengono poi usati per popolare di dati il test ecc ecc).
Di solito il modello di sviluppo in voga in Italia e` il waterfall.
Modello che e` in crisi anche da prima della pubblicazione del libro di
Kent Beck Test Driven Development.
Insomma... Il mercato italiano e` gia` saturo cosi` com'e` di gente che
sa Java/c++/blabla. Meglio impararsi altra roba che lavoro lo trovi
comunque, magari all'estero, e la vita ne guadagna parecchio.
In universita` invece ho visto dottorandi e dottorati che lavoravano a
un progetto per il ministero dell'istruzione (o era innovazione, boh)
che solo per installare un plug-in di eclipse per tomcat fatto da loro
impiegavano tanto quanto impiegherei io per installare il succitato
software in almeno 15 diverse postazioni su macchine virtuali (con Xen)
con 256 MB di ram e processori modesti. Mentre la sempre succitata
applicazione per il ministero che girava su J2EE con tomcat e compagnia
impiegava quasi 2 minuti solo per partire sul mio ibook.
Inoltre un mio amico che si laureava in quei giorni 3 giorni prima della
laurea dovette lavorare come un matto per aggiornare il suo motore di
workflow perche` il capo progetto dell'applicazione aveva cambiato un
metodo della classe base piu` importante rompendo completamente tutta
l'applicazione da cima a fondo (ricordo con compassione la frustrazione
del mio amico, e con allegria il momento in cui, dopo la laurea, quando
l'hanno chiamato per chiedergli una mano per finire di sistemare li ha
mandati a quel paese che in quell'inferno non ci voleva tornare).
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
http://weever.berlios.de

mandati a quel paese che in quell'inferno non ci voleva tornare).
eh che ci vuoi fare, lo capisco il tuo amico,
bisogna bilanciare conscenze teoriche e pratica
Ciao
Chairam

 certi linguaggi non bastano tre mesi.
Verissimo. Ma in 3 mesi con certi linguaggi puoi fare molto.
-- 
Lawrence
http://www.oluyede.org/blog


Io concordo in parte con quello che dici.
Il linguaggio in se inteso come sintassi richiede pochi giorni.
In pochi mesi si padroneggia bene lo strumento.
COn questa conoscenza si e' in grado di scrivere un algoritmo, anche
complesso.
Nel mondo Aziendale le cose cambiano e non poco.
e condivido quello che dice Chairam
Di fatto il 90% dei Progetti sono di Integration.
Ci sono Databases, application server, Hosts, Firewall, Protocolli, Client,
server, File systems, LDAP, ..........
posso andare avanti 20 righe
poi ci sono metolodogie di lavoro, il Versionin, il branching, il linguaggi
di script e quelli di batch, gli IDE , i Rad
Condisci con tutte le problematiche di reaeasing e team working, che non
sono da poco
Mettici in fine i pattern, che oggi dominano ovunque e la minestra e'
pronta.
Io ancora oggi continuo a imparare, non solo roba nuova che sostituisce
vecchie tecnologie, ma anche nuove abilita' che inspessiscono la mia
Proifessionalita'
PEr questo motivo oggi la differenza fra un junior e un senior non e'
quantificabile, ma e' confrontabile con una laurea piena secondo me.
Per quello io dico che chi sa bene lavorare in certi settori non e'
possibile che soffre lka concorrenza del figlio del giornalaio, e la suia
tariffa la puo' e la deve tenere a un certo livello non per tariffario ma
perche saranno gli stessi che gli danno il lavoro che gliela alzano per
paura di perderlo.
Per questo dico a tutti di specializzarsi specializzarsi specializzarsi.
Per quanto rigurada le teconlogie nuove tuypo Pyton, che sicuramente essendo
nuove sono di alto valore scientifico, il problema e' che le Aziende oggi
non possono rischiare su tecnologie che potrebbero essere nate morte, basta
pensare ai miliioni che volano nei progetti, oltre che ai danni indiretti di
dover poi riconvertire in caso di fallimento.
Cosi' per noi e' una scommessa ad alto rischio.
Puntare oggi su una nuova tecnologia puo' voler dire domani essere il numero
uno
come puo' voler dire ritrovarsi fuori mercato e soprattutto senza lavoro.
Questa e' una scelta che ognuno deve fare.
Se si punta alla Ricerca tutto e' piu' facile perche si va sul nuovo per
definiziano.
Nel mondo Aziendale ci sono logiche piu' complesse nella scelta tecnologica.
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 haskell
Io lavoro da anni in Java, e ho provato per interesse personale Python e
Ruby. 
E' vero che come linguaggi hanno una sintassi semplice (sicuramente si
impara in 3 settimane) ma da lì a dire che potrei "rivendermi" come
consulente su queste tecnologie ne passa! Già quando scrivo qualche
paginetta in PHP (che non conosco ma utilizzo per qualche sito personale)
mi vengono mille dubbi che derivano dal fatto che non conosco a fondo i
framework che sto utilizzando, non ne ho letto il codice, e che non ci ho
"messo le mani dentro" come sui vari Struts, Spring, Hibernate e soci..
sono molto scettico (eufemismo) quando qualcuno dice "imparo un linguaggio
in 3 settimane"; costruire una applicazione vera necessità ben più della
conoscenza del linguaggio: bisogna conoscere le librerie, i framework, ed
averci passato le ore a debuggarli per capire perche' cavolo non
funzionano come crediamo 
detto questo, tra i clienti italiani dubito che qualcuno mi chiederà mai
di utilizzare queste tecnologie. non ho dubbi ad esempio che python (che è
quello che ho usato un po' di +) sia anni luce più produttivo e agile di
java, ma raramente (ok, mai) ho conosciuto clienti che fossero in grado di
valutare questi aspetti.
A me personalmente va bene così. Il giorno che dovessi far partire
un'azienda mia, so che avrò un grosso vantaggio sulla concorrenza ;-)
Mopo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 un'azienda mia, so che avrò un grosso vantaggio sulla concorrenza ;-)
Beh dipende...
-- 
Lawrence
http://www.oluyede.org/blog

 haskell
Non molti, anche se python e ruby fanno sempre meno parte della
categoria "linguaggi meno diffusi".
IMHO però l'approccio dovrebbe essere diverso: è il programmatore (in
senso lato) che incide su queste scelte aziendali, non viceversa. Non
si è tutti e sempre junior. E' comunque compito della programmazione
compiere le scelte tecniche come l'adozione di un linguaggio anzichè
un'altro.

 Beh dipende...
ok, ok. Vedo un sacco di "prodotti software" orribili, bacati, scritti con
piattaforme obsolete, in tempi biblici, da programmatori che mi raccontano
che hanno appena scoperto "le meraviglie del pattern DAO" (nel 2005) o che
"sai, fare il programmatore sarebbe anche divertente se si potessero
scrivere Ejb dalla mattina alla sera" (poi non ricordo altro, penso di
essere svenuto).
Non posso essere ottimista ;-) ?


un'altro.
Beh, più che il programmatore, ritengo che debba essere l'analista a
decidere quale soluzione sia migliore per risolvere un certo problema. Solo
chi ha la visione d'insieme può fare una seria valutazione sulla scelta
delle tecnologie da utilizzare e valutare in base al rapporto
costi/benefici, cosa sia migliore fare e perché.
Poi, che  qui in Italia, almeno per ciò che concerne la mia esperienza, si
tenda a confondere il programmatore per un analista... Beh, questa è tutta
un'altra storia.
Ciao,
Maurizio

 Non posso essere ottimista ;-) ?
Ben vengano altri pythonisti, certo che quella del "che bello scrivere ejb
tutto il giorno" non l'avevo mai sentita. I Javisti son masochisti, come la mia
amica che si diverte a programmare in BPEL tutto il giorno (!!)
-- 
Lawrence
http://www.oluyede.org/blog

 ha
scritto:

Discordo
In Progetti grossi in fase di architettura si devono mettere dei paletti.
Si dice consa e' lecito e cosa no.
Se sono molto grossi bisogna anche irrigidire e obbligare i developer in
certe tecnologie e addirittura obbligare certi pattern e framework
Scherzi ? se no dopo 2 anni hai un il classico progetto incasinato coin
dentro tutto lo scibile e ti va fuiori controllo.


 un'altra storia.
Tu pero' confondi l'analista con l'Architetto


dentro tutto lo scibile e ti va fuiori controllo.
...Win XP? :-)))
Piero

 Mopo


 certi linguaggi non bastano tre mesi.
principalmente la differenza più grossa è fra linguaggi funzionali e imperativi. Chi non ha mai 
lavorato con linguaggi funzionali ci mette un bel po ad entrarne nella logica, ho conosciuto gente 
che anche dopo un anno che ne faceva uso tendeva ad usarli con logica imperativa!

 Tu pero' confondi l'analista con l'Architetto
effettivamente mi è poco chiara la differenza tra analista ed architetto.
Sarà che non ne ho mai visti... ;-)
Ciao,
Maurizio.



Prendiamo l'esempio di un progetto bancario
L'analista continua a intervistare le persone del cliente , analizza le
applicazioni esistenti. Cerca di capire cosa gli serve al cliente eccetera.
Alla fine l'analista dice al team di sviluppo che fare, dettagliatamente. Di
solito non sa nulla di come il progetto verra' fatto.
L'architetto progetta come il SW andra' ffatto, le teconologie i pattern , i
tools, di solito anche le basi dati .... tutto. E poi di solito sta col team
di sviluppo.
N
N


 dentro tutto lo scibile e ti va fuiori controllo.
Non conosco 1 progetto scritto in un linguaggio dinamico o in cui i
programmatori, ovviamente capaci, siano stati lasciati liberi di agire,
organizzarsi e decidere sul progetto che sia finito in quella
situazione. E partecipo pure a un progetto dell'unione europea che e`
organizzato a quel modo e probabilmente e` uno dei pochi progetti che
davvero termina (PyPy).


 pronta.
I pattern di programmazione? cioč intendi tipo il singleton, i visitor,
virtual factory, pimpl, queste cose?
bye
-- 
Computer Science in the 1960s to 80s spent a lot of effort making
languages which were as powerful as possible. Nowadays we have to appreciate 
the reasons for picking not the most powerful solution but the
least powerful.
The reason for this is that the less powerful the language, the more you can 
do with the data stored in that language.
Tim Berners-Lee 

 Progettare può essere più o meno conveniente di usare 'prefabbricati'
Tipo J2EE? Tipo Struts? Dio me ne scampi. Non e` che i framework
esistono solo in java comunque eh. Specialmente quando altri linguaggi
sono piu` facilmente estendibili. Sono d'accordo che contano le librerie
ma conta anche che le librerie sono limitate dal linguaggio stesso, ad
esempio in java spendi tante linee per la configurazione in XML quante
ne impiego io per scrivere l'applicazione e tutto questo con i framework
ovviamente.


 virtual factory, pimpl, queste cose?
si
N


ovviamente.
alle volte ti può capitare cosi:
o usi java con un framework
o progetti da zero con python
ma non vorrei che la discussione si limitasse a questi due linguaggi
Ciao
Chairam

 un'altra storia.
"quì in italia" siamo anche tanto facili a parlare del belpaese come
se fossimo sul balcone a guardarci dall'alto. Discutere di etichette,
come si è visto nell'altro thread, lasciano il tempo che trovano;
personalmente faccio sia analisi che sviluppo a seconda delle
circostanze e del progetto, magari sarò il frutto di questa confusione
ma funziona. In fondo l'interazione e il feedback continuo non è un
punto cardine di XP?

 punto cardine di XP?
Va benissimo che fai analista e programmatore, io a livello di tendenza
eliminerei gli analisti.
Pero' non mi sta bene che ti svelgi la mattina e mi scrivi un pezzo in
usando il pattern di moda questo mese
Ci sara' un Architecyt, che puoi essere tu stesso che tiene omogeneo e
organizzato tutto il progetto, e decide di volta in volta se inserirer o
meno tecnologie nuovi.


di sviluppo.
discordo
troppi passaggi, troppo ingessato
in realtà è una questione di dimensione del problema e del sw da
realizzare, tutti questi passaggi potrebbero avere perfettamente senso
(la vedo dura)
in scenari come questi viene da chiedersi se non sia il caso di usare
strumenti diversi o programmatori esperti
in generale
c'è confusione sulla differenza tra analista programmatore e analista
funzionale, ammesso che ci sia (appunto)
infine spera che non cambino i requisiti se no auguri...
Ciao
Chairam

 dentro tutto lo scibile e ti va fuiori controllo.
Non sto dicendo che ognuno scriva il software per i cacchi suoi.
Il ciclo di sviluppo è fatto sicuramente anche da fasi decisionali
oltre che esecutive: ovviamente le decisioni le prende chi ne ha la
responsabilità, ma sempre responsabilità che ricadono nell'ambito
dello sviluppo.

 ma non vorrei che la discussione si limitasse a questi due linguaggi
No no infatti, estendiamola
-- 
Lawrence
http://www.oluyede.org/blog

 infine spera che non cambino i requisiti se no auguri...
Ci sono progetti in cui i requisiti cambiano continuamente per i seguenti
motivi:
1. Il cliente e' una testa di cazzo
2. la materia e' intrinsecamente liquida. Pensa al caso in cui si lavora su
un progetto per cui continuano a cambiare le leggi ad esempio.
3. 1+2 :)
In questi casi bisogna attrezzarsi al cambio requisiti, sia con i processi
che con la bravura dei singoli.


 Difatti Valentino ha detto: 3 settimane per imparare il _linguaggio_.
Personalmente posso essere d'accordo che sapendo il python è
probabile che il ruby lo si impari molto in fretta.
Sono meno d'accordo quando il linguaggio è diverso nell'impostazione.
Come il lisp.
A quel punto non si tratta di imparare una sintassi nuova.
Piuttosto di imparare un nuovo modo di affrontare il problema, a
prescindere dalle librerie, dal framework e da tutto il resto.
Che poi questo porti via 3 settimane o 3 mesi non so;
dipende dalle capacità, dalle attitudini, dall'effettivo tempo che
ci si dedica.
-- 
Gerolamo 

 dello sviluppo.
Vedi risposta sopra a chairamm
N


 framework, e che questo avesse perfettamente senso per il progetto:
Il punto è che raramente si fa una scelta di questo tipo per vari
ordini di problemi:
Primo fra tutto è che il processo decisionale passa prima da:
"cosa dobbiamo fare", "cosa abbiamo di già fatto", "cosa sappiamo
fare senza nuove risorse" e "quali risorse in più ci servono".
Se si arriva a quest'ultimo passaggio (raro), sicuramente passando da
quello precedente si sono già scartate tutte le tecnologie che non
consentano un profiquo sfruttamento delle risorse già presenti.
Solo a quel punto tra le possibili alternative tecnologiche rimaste
si fa una scelta tecnologica, appunto.
Se internamente si usano tecnologie di largo consumo (Java, C,
PHP, per parlare di linguaggi...) allora il problema non si pone.
Se internamente si programma in lisp o in erlang, allora l'importante
non sarà tanto di trovare uno che sappia il lisp, quanto di trovare chi
sia abbastanza "versatile" da adattarsi alla nuova situazione.
Ma soprattutto il problema sarà di far recuperare il gap di know how
su quanto già esistente internamente, non tanto sul linguaggio in se.
Insomma: secondo me la questione è mal posta, perchè per la
maggior parte dei casi, è probabile che il fatto che una persona
sappia già il lisp o l'erlang è cosiderato (giustamente o meno) poco
importante (rispetto ad altri fattori).
-- 
Gerolamo 

 
Dato questo tempo (3 mesi), diciamo che per python sono ragionevolmente
sicuro di essere produttivo in quei tempi. Per lisp e erlang posso solo
sperare. Per gli altri, solito punto interrogativo.
Ciao,
Marco.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 impiegava quasi 2 minuti solo per partire sul mio ibook.
Se mi parli di efficienza non credo che C/C++ abbiano rivali nemmeno
oggi (java e' gia' molto ma molto piu' pesante). Non credo che
mi convincerai facilmente che un kernel di SO e' piu' efficiente
se scritto in python rispetto a C/C++.
[SNIP]


 di sviluppo.
Mah... le basi di dati qui sono gia' nei documenti di specifica
provenienti dal "solution architect" (che qui e' quello che tu
hai chiamato analista). L'architetto come lo intendi tu, in un
buon numero di casi sono io  :-).


 infine spera che non cambino i requisiti se no auguri...
Ti informo che ho appena finito di scrivere i test di integrazione
di un progetto il cui documento "solution description" e' in PA,
ovvero e' in revisione A "provvisioria" (come indica la P), 
il che significa che domani
mattina potrebbero essere cambiati i requisiti (e probabilmente entro
una settimana lo saranno, visto che tale documento in PA contiene
molti TBD).
E ti informo anche che questo e' il modo italiano di intendere
il modello "waterfall" (per fortuna a questo giro il programmatore non
sono io)


 se scritto in python rispetto a C/C++.
Non ho scritto quello. Io ho parlato di confronto col Java. Ma ci sono
molti piu` ambiti in cui cio` che conta e` l'efficienza dello
sviluppatore e non del linguaggio. Quindi se anche perdo qualcosina sul
linguaggio ma guadagno in tempi di sviluppo sono decisamente piu`
contento.
1 server in piu` di costa 5000 euro. Un programmatore che ti lavora 2
mesi in piu` ti costa decisamente di piu`.


 davvero termina (PyPy).
Non ho capito cosa intendi con PyPy, ma se intendi che i progetti
dell'unione europea di solito non terminano allora io sono un fenomeno
:-)
visto che i 2 progetti (grossi) della UE a cui ho partecipato sono 
terminati entrambi, sia pure con molto ritardo il primo 
(molto piu' complesso del secondo) mentre addirittura con 
circa 1 mese di anticipo il secondo 
(che poi era quello del simulatore di UMTS satellitare 
dell'altro thread).
E nel caso del primo progetto credo che quelli che lo hanno portato
a termine fossero in piccola percentuale presenti quando il
progetto e' partito (e un progetto piu' eXtremeProgramming
di quello non credo che possa esistere).


 
'Azz.
Sono cosi' potente :-)?


 dell'altro thread).
Ecco, diciamo allora che PyPy non solo e` in completamento ma anche in
perfetto orario.


 Sono cosi' potente :-)?
Io ti sto parlando di quello che ho visto in atto bnelle aziende migliori
che coincide imho con il processo corretto.
Chiaramente l'Architect si prende queste responsabilita' tecnologiche e deve
dare supporto perche le cose vadano bene a tutto il team e se per caso ha
preso qualche cantonata va anche cazziato.
Chiaramente questa responsabilita' va pagata :-)


 e real time come il VoIP. Ad esempio...
Senza entrare nel merito del "mio linguaggio è più veloce del tuo",
ho quantomeno un dubbio sul fatto che una applicazione VoIP sia
una applicazione real time.( 
http://en.wikipedia.org/wiki/Real_time
 )
-- 
Gerolamo 

 una applicazione real time.( 
http://en.wikipedia.org/wiki/Real_time
 )
Decisamente lo e` proprio da quella definizione.
==
An operation within a larger dynamic system is called a real-time
operation if the combined reaction- and operation-time of a task is
shorter than the maximum delay that is allowed
==
E piu` in basso l'esempio:
==
A common life example is that of standing in a queue (line of customers)
waiting for the checkout in a grocery store. The queue is "real-time"
if, on average, customers are being processed and outputted as quickly
as they arrive. Under these circumstances, a queue of customers may
occasionally form, but the queue cannot grow without bound.
==
Che e` esattamente cio` che succede nel conferencing VoIP (il fatto che
gli utenti arrivano e sono serviti subito).
Per cui ti ringrazio di aver citato un documento che conferma cio` che
dicevo :).
Anzi, inizio pure a pensare che questa non solo sia un operazione
Real-Time ma direi quasi Hard Real-Time.
==
Alternately, a system is said to be hard real-time if the correctness of
an operation depends not only upon the logical correctness of the
operation but also upon the time at which it is performed.
==
Infatti per lo standard (non perche` l'ho deciso io) ci vuole un
pacchetto ogni 20ms non importa cosa fai ma un pacchetto ogni 20ms
manderai.


 l'ultima cosa che ho trovato e` hyperestraier.
Se mi dici efficiente, posso essere d'accordo; se mi dici migliore nel 
senso più facilmente mantenibile nel tempo, permetti, ho i miei dubbi (e 
io ho lavorato qualche annetto, in C prima e in C++ poi..)
-- 
Ciao!
Luca

 io ho lavorato qualche annetto, in C prima e in C++ poi..)
Che ti devo dire... Sarai un bel campione statistico.


 
Io no. E' che conosco bene assai entrambi i mondi. E se la 
programmazione strutturata è stata superata dall'OOP, è proprio per quel 
motivo.
-- 
Ciao!
Luca

 motivo.
Infatti di software grossi scritti in C non ne esistono...
C'e` da dire poi che l'OOP c'entra un tubo. Puoi tranquillamente
programmare con i concetti dell'OOP in C (come fanno nel kernel di
FreeBSD, nel kernel di Linux, nelle GTK+, in hyperestraier, in qualsiasi
libreria gestita con due dita di cervello).


io ho lavorato qualche annetto, in C prima e in C++ poi..)
Anche io e ancora ci lavoro.
C'ya
	Steve
-- 
Legge di Flon
Non c'e' linguaggio in cui sia difficile scrivere cattivi programmi.
FAQ del gruppo : 
http://www.sen.it/faq/it.lavoro.informatica.faq.html

 mesi in piu` ti costa decisamente di piu`.
dipende dal contesto in cui lavora.


 manderai.
Hard real time sarebbe se il tuo sistema si dovesse accorgere che
per un tempo > 20 ms non gli sono arrivati pacchetti e, resosi
conto della cosa, il tuo sistema iniziasse una operazione automatica
di shutdown per evitare danni peggiori. Ad esempio quando lavoravo
al simulatore motociclistico, c'era necessita' di acquisire dati dai
sensori ogni 10 ms (in alcuni casi anche ogni 1 ms). Se si fossero
verificati ritardi maggiori non si sarebbe potuta garantire la
stabilita' del sistema (meccanicamente instabile, come una moto
che meccanicamente e' instabile) => per evitare che una tonnellata
di ferraglia si abbattesse sul malcapitato pilota, si avviava uno
shutdown automatico del sistema quando uno dei task si accorgeva
di avere sforato la deadline di 10 ms.
Nel caso del VOIP se per una volta si perde un pacchetto non succede
quasi niente, se quelli successivi arrivano regolarmente 
(a dimostrazione di questo il fatto che se non sbaglio RTP va 
di solito su UDP, anche perche' in genere nella trasmissione voce
e anche nella trasmissione video e' molto meglio perdere un pacchetto
che avere ritrasmissioni incontrollate che darebbero luogo a rumore
di sottofondo o sfarfallio del video).


 dipende dal contesto in cui lavora.
Ovviamente ma sto parlando di chi lavora su quel codice.


 libreria gestita con due dita di cervello).
Su questo invece concordo.


 Stai scherzando, spero.... 
Mi sembra ovvio. :)


 
[CUT]

 numeri penso che valga la pena.
Dipende da cosa intendi, per me sei ancora troppo vago perche` ti possa
dare una risposta. Fammi un esempio pratico e cerchero` di farti un
controesempio
-- 
Lawrence
http://www.oluyede.org/blog

 
Non saprei immaginare un esempio per il quale non esista un contro 
esempio. Ma questa e' filosofia. Non esiste prova provata che un sistema 
sia meglio di un altro, altrimenti non saremmo neppure qui' a discutere 
e useremmo tutti lo stesso.
La mia e' solo un'opinione basata su qualche lettura sparsa.
Ciao.
	-ema-

 io contesto.
Beh io non ho mi sono mai trovato in carenza di alcunche`...
-- 
Lawrence
http://www.oluyede.org/blog

 
Ascoltami, se vuoi aver ragione, ce l'hai (se da anca ai mussi, si dice 
dalle mie parti). Io non ho negato nulla, so per certo che c'è parecchia 
roba scritta in C. Negare l'evoluzione del software pero' è cosa che 
trovo un tantinello insensata. E questo continuo a pensarlo anche se la 
piccola lista di software che hai messo qui sopra la raddoppi.
-- 
Ciao!
Luca

 sviluppatore che conta.
Stefano, questo è indiscutibile. Ma quando lo sviluppatore non è uno ma 
un team di 20 persone, concorderai con me che la possibilità di 
isolamento che da il C++ consente di muoversi un po' meglio. Se poi 
vogliamo dire che puoi fare porcherie in C++ esattamente quante ne puoi 
fare in C, è ovvio.
-- 
Ciao!
Luca

 io ho lavorato qualche annetto, in C prima e in C++ poi..)
Fra l'altro credo di averlo già scritto. Il C++ è un film a parte, o
lo ami o lo odii. Se lo ami lo usi ovunque, se lo odii cerchi di
evitarlo come la peste. Io sono nella seconda fascia, se possibile lo
evito.

 
Ma va?? Non si era capito. :D
Il problema - grosso - del C++ è che è un linguaggio eccessivamente 
concettoso. Richiede una curva di apprendimento molto lunga, alla fine 
della quale da un lato ti domandi come hai fatto a farne a meno, 
dall'altra ti chiedi se ne è valsa davvero la pena. Certo, così è 
diventato nel tempo, che in origine non era così. Per dirla tutta, poi, 
se c'è stato un tentativo di 'evoluzione', se così si può chiamare la 
creazione di linguaggi più recenti (Java, C# e chi più ne ha più ne 
metta) cerca di eliminare gli orpelli inutili insiti nel C++.
Insomma, come il solito, in medio stat virtus (cosi' ho fatto anche la 
figura di quello colto... :D)!
-- 
Ciao!
Luca

 
Ottimi prodotti. Per molte soluzioni decisamente piu' produttivi di un 
application server java. Ma non mi pare che siano paragonabili ad un 
application server java; non posso dire di conoscerli ma da quel poco 
che so mancano di alcuni concetti tipo le servlet (ma se qualcuno mi 
smentisce sono più che contento).
Ciao.
	-ema-

Ti dirò quella che è la mia esperienza, anche se l'esperienza di un 
singolo consulente è per forza di cose limitata.
Un quadretto tipico può essere il seguente: dentro una grossa azienda 
(>5.000 dipendenti a scrivania)
1. Nasce l'esigenza di una nuova soluzione IT. E già quì ci sarebbe da 
perdere un po' di tempo per capire come nasce questa esigenza
2. Viene eseguita un'analisi preliminare giusto per capire dove sbattere 
la testa. Fase piuttosto delicata perchè se chi esegue l'analisi non 
capisce nulla o è pigro o è "troppo" prudente può essere accantonata 
l'idea in partenza.
3. Se tutto va bene a questo punto si fanno diverse valutazioni:
a. In azienda c'e' già qualcosa che ci "assomiglia" per cui si decide di 
modificare l'esistente.
b. La soluzione è normalmente reperibile sul mercato (es. un fax server)
c. In azienda c'e' una tecnologia che pare adeguata allo sviluppo della 
soluzione.
d. La soluzione appare troppo complessa per un azienda il cui core non è 
il software: ci si rivolge comunque a fornitori esterni anche se si 
"consiglia" una soluzione basata su tecnologie "conosciute aziendalmente".
e. La soluzione è talmente vasta e pervasiva nel tessuto della società 
che vale la pena considerare l'acquisizione di una nuova tecnologia a 
livello aziendale.
Nel caso d. se si trova un manager audace e se la soluzione non richiede 
una eccessiva integrazioni con soluzioni già esistenti si può tentare di 
proporre qualcosa di diverso, altrimenti è veramente difficile.
Come qualcuno ha detto in questo thread la maggior parte dello sviluppo 
sono soluzioni di integrazione ed in questo contesto è difficile 
convincere qualcuno che nel suo sistema IIS+ASP+MSSQL o Websphere+Oracle 
è conveniente inserire un pezzo di Python o ruby + MySQL
Vorrei aggiungere che un grosso problema nelle aziende è la conoscenza. 
Formare delle persone su una nuova tecnologia è un costo molto elevato e 
molte delle persone impiegate possono essere poco ricettive. Se così non 
fosse oggi tutti noi non scriveremmo applicazioni web come le scriviamo, 
ma forniremo dei servizi tramite webservices (SOAP) che verrebbero usati 
in sistemi di portali per integrare tutto in un'unica interfaccia. E 
invece siamo ancora quì a sparare HTML e come se non bastasse il più 
delle volte neppure accessibile.
Ciao.
	-ema-

Io credo che sia il tipo di comparazione che non ha senso. Non hai le
servlet? Beh avrai qualcos'altro. Credo che in fondo tu possa affermare
ciò che dici solo dopo un'attento studio di entrambi i prodotti (ma
basterebbe anche finire un tutorial :P)
Detto questo non mi hai convinto ;)

 smentisce sono più che contento).
Forse perche` la servlet cosi` com'e` e` qualcosa che piace poco a chi
sviluppa application server in Python.
Un application server vecchio e ormai poco sviluppato che supportava il
concetto delle servlet si chiama webware, il suo successore si chiama
pythonpaste.
Sinceramente io ho visto piu` applicazioni che usano roba tipo tomcat e
jakarta e nessuna mi ha fatto particolare impressione, se non che
richiedono 5 volte tanto codice per fare le stesse cose.
La scalabilita` non e` un problema a sua volta, il piu` delle volte,
esattamente come java, ci si appoggia ad apache o a lighttpd. Oppure si
infila il discorso scalabilita` nell'application server. Ad esempio Zope
ha ZEO. Con Twisted Matrix viene piu` semplice creare una rete di server
a se stante che serve i dati alle web application che fanno da front-end
con un web service oppure usando un object broker.
PEAK e` una bestia che ha roba che in java non si sognano neanche (tipo
le generic function con il dispatch e la method combination).
Tutti e 3 quei grossi framework hanno dei loro sistemi di interfacce e
adaptation simili al sistema utilizzato in eclipse (ma sono arrivati
prima loro se si volesse fare a gara)...
Sono delle bestie complesse che meritano di essere studiate prima di
essere giudicate.


 piccola lista di software che hai messo qui sopra la raddoppi.
Te lo ripeto: sarai un buon campione statistico. Tu contro chi sviluppa
postgresql, linux, freebsd, openbsd, netbsd, python, ruby, ..., ...
Sicuramente loro sono incapaci che non hanno capito l'evoluzione del
software mentre tu hai capito tutto.


 smentisce sono più che contento).
Se per "concetto di servlet" intendi un metodo per la generazione delle
pagine dinamiche, ovviamente ci sarà qualcos'altro.
Se invece intendi le servlet come architettura, ti posso dire con
assoluta cognizione di causa che se ne può fare tranquillamente a
meno, è ben lungi dall'essere la migliore possibile (E te lo dice uno
che la certificazione java ce l'ha).

 piccola lista di software che hai messo qui sopra la raddoppi.
Ma guarda che anche se tu provi a scrivere software in C, cercando pero'
di applicare per quanto possibile le i concetti tipici dell' OO 
si ha comunque un'evoluzione del software, anche se continui
a scrivere in C.


 software mentre tu hai capito tutto.
No, pero' io ho l'umiltà di guardarmi attorno. Un paradigma, se fosse 
cosi' palesemente sbagliato come tu affermi, sarebbe già morto e 
sepolto, non lo utilizzerebbe più nessuno e non verrebbero più 
sviluppati strumenti se non, magari, in qualche nicchia universitaria 
(vedi Prolog, ad esempio).
Invece, guarda che caso, tutti gli stumenti recenti, a partire dal 
famoso Python che tu stesso citi, sono fortemente OOP oriented. E lo 
sviluppo del paradigma, che tu voglia o che tu non voglia, è passato 
anche per C++, dal quale, nota, almeno il 90% dei linguaggi recenti trae 
le mosse.
Allora, sono io che domando a te: tutti deficienti?
-- 
Ciao!
Luca

 a scrivere in C.
Fermo, Marco, che se no non ci capiamo.
Io non sto dicendo, ne mai lo dirò, che C sia da buttare. E' il primo 
amore, e il primo amore non si scorda mai.
Ne sto dicendo che non si possano applicare alcuni concetti - non tutti, 
ma alcuni si - . Pensa che io riesco a fare applicazioni OO anche in VB. 
Il fatto è che se hai un linguaggio già orientato opportunamente. Hai la 
vita più facile.
Per fare un esempio concreto, doverti scrivere le vtables a manina si 
può fare, C te lo consente. Certo, C++ è già implementato a livello di 
linguaggio, per cui la vita per te è più semplice.
-- 
Ciao!
Luca

 Allora, sono io che domando a te: tutti deficienti?
Tutti chi? Chi non legge cio` che scrivo oppure chi usa C++?



Temo di essere stato frainteso. Io non dico che java è meglio o peggio. 
Se vi rileggete questo ramo del thread ad un certo punto c'e' chi 
afferma che tutto quello che c'e' in java c'e' anche in python. Io ho 
contestato quell'affermazione.
Ho le mie opinioni basate su un po' di esperienza e su qualche lettura; 
ma ho solo la mia di esperienza e non ho letto tutto quello che c'e' da 
leggere sull'argomento (anche perchè è ovviamente impossibile).
Ciao.
	-ema-

 Tutti chi? Chi non legge cio` che scrivo oppure chi usa C++?
Ah, non lo so. Io in questo momento non sto usando C++, l'ho utilizzato 
proficuamente fino a 6 anni fa.
-- 
Ciao!
Luca

 intrinseche del linguaggio che talora sono assolutamente inutili.
Se tu fossi l'autore del C++ ti avrei gia` dato del pallone gonfiato.
Spero tu capisca che cio` che hai scritto sopra, come se passare per
l'esperienza del C++ sia assolutamente fondamentale per tutti i
linguaggi... Quale assurdita`.
Comunque il thread sta degenerando e gli argomenti ti scarseggiano per
cui direi di tagliare corto...


Ho dato una rapida occhiata e mi sembrano veramente interessanti. Ma non 
è che tra 3 anni queste architetture diventano complesse come J2EE vero?
Ciao.
	-ema-

 cui direi di tagliare corto...
Guarda, non c'è miglior sordo di chi non vuol sentire. E' inutile che io 
ti cerchi di spiegare che il cielo è blu, se tu sei convinto non solo 
che è rosso ma che sto cercando di convincerti che è verde. Non ci 
riuscirò mai.
-- 
Ciao!
Luca

 che ci mettiamo d'accordo.
Potresti chiarire questa tua affermazione? In che senso traerebbero
tutti giovamento dagli errori e dalle esperienze di C++?
-- 
Lawrence
http://www.oluyede.org/blog

 è che tra 3 anni queste architetture diventano complesse come J2EE vero?
No, perche` non usano Java ;-)
-- 
Lawrence
http://www.oluyede.org/blog


  Guarda, se vuoi lo facciamo - volentieri - in privato. Io sono 
stremato, oggi non ce la faccio!! :D
-- 
Ciao!
Luca

fare in C, è ovvio.
Mica poi tanto.
So che non e' il tuo caso, ma anche solo leggendo questo gruppo, vedo
che c'e' troppa gente che da' troppa importanza alla conoscenza di
qualche specifico linguaggio piuttosto che la metodologia di lavoro,
che ritengo fondamentale.
Piu' della conoscenza di qualche linguaggio.
-- 
Legge di Flon
Non c'e' linguaggio in cui sia difficile scrivere cattivi programmi.
FAQ del gruppo : 
http://www.sen.it/faq/it.lavoro.informatica.faq.html

 ==
Non ho capito.
Non ho mai sviluppato una applicazione VoIP.
Per quello che so io una applicazione real-time fallisce se
non esegue entro un tempo limite.
Vuoi dirmi che una applicazione VoIP assicura che il lag non
oltrepassi una certa soglia prestabilita nell'applicazione?
E la fai girare su un sistema operativo real time? (perchè se no,
comunque, non puoi assicurare i tempi...)
In questo caso... sono d'accordo con te.
Confermi il tutto?
Puoi farmi un esempio?
Intendevamo due cose diverse?
-- 
Gerolamo 

 è che tra 3 anni queste architetture diventano complesse come J2EE vero?
Il rischio e` sempre in agguato.  :)
Twisted Matrix piu` che un application server e` un framework per la
programmazione di rete a tutto tondo.
Gli application server che lo usano sono almeno 2: Nevow e Mantissa (che
usa Nevow comunque al suo interno) che sono utilizzati, ad esempio, per
questa applicazione: 
http://www.clickchronicle.com
Twisted Matrix infatti e` usato anche per scrivere streaming server come
fluendo (
www.fluendo.com
).
Nevow di suo e` stato usato, ad esempio, per:
http://www.superleague.co.uk
Il sito del creatore (da cui cito) dice:
""
Superleague initially needed a reimplementation of their old site but
with very tight time constraints. Pollenation delivered a site plus
basic content management system, registration and a ticket ordering page
within 4 days
""
Ora il sito gestisce anche le scommesse ecc. ecc. Oppure
www.cpushare.com
 e 
klive.cpushare.com
 sono entrambi sviluppati con
Twisted Matrix e Nevow.
Zope e` ormai una certezza da parecchi anni. Esiste da quasi 10 anni e
la versione 3 (che e` uscita da un po` piu` di un anno) e` in sviluppo
da 4 anni e entrata in produzione da 1 con la versione 3.1.
PEAK e` un prodotto che e` nato per lo piu` in america e non l'ho mai
usato particolarmente. Pero` e` composto da PyProtocols e RuleDispatch
che sono due pacchetti molto famosi, estremamente ben fatti e molto
potenti. Questo nella parte web si appoggia a FastCGI su Apache ma con
poco sforzo si puo` passare su lighttpd. 
Zope 3.2 utilizza Twisted Matrix come suo server web/ftp/webdav/ssh(ecc.
ecc.)
Chi ti parla e` un po` biased essendo sviluppatore ufficiale di Nevow e
collaboratore di Twisted Matrix :).


 Questo direi decisamente di no.
Ah... adesso sono d'accordo sul concetto di real-time!
-- 
Gerolamo 

 comunque, non puoi assicurare i tempi...)
Dipende da che significato dai alla parola assicurare. Il fatto che se
anche sfori di 5ms non succede nulla non cambia il fatto che un buon
servizio richiede tempi di reazione inferiori ai 20ms.
Dette queste 2 cose: abbiamo appurato che 
a) se la rete e` lenta non e` colpa di python
b) se il sistema operativo non e` real time non e` colpa di python
(Twisted Matrix gira tranquillamente su QNX come lo fa python, quindi se
serve...)
Il punto comunque era nato dicendo che python era
lento/inadatto/non-scala/realtime-non-lo-fai ecc ecc.
Ora stiamo discutendo sul fatto che potrebbero esserci fattori esterni
che peggiorano il QoS di un server di streaming VoIP il che mi sembra
abbia spostato il fattore prestazioni da python a un "altro" non ben
identificato :).


 identificato :).
Ma io non ho affatto detto questo.
Anzi, in una applicazione di streaming immagino che il fatto di farla
in C piuttosto che in Python influisca più sui tempi di sviluppo che
sulle prestazioni.
Il punto era invece nato da un uso a mio avviso improprio del
concetto di applicazione real-time. E di questo stavo parlando.
-- 
Gerolamo 

 concetto di applicazione real-time. E di questo stavo parlando.
Per nulla improprio perche` il VoIP e` soft real time come ampiamente
dimostrato. Non sei real time soltanto quando se sgarri crepa qualcuno.


 questione di gusti...
Credo che il discorso sia da portare un po` piu` in alto:
ti serve davvero il C++? puoi gestire la sua complessita`? sei produttivo?
-- 
Lawrence
http://www.oluyede.org/blog

[CUT]
Ciao
Chairam

 sul mio volto.
Dubito che senza precedenti esposizioni al paradigma funzionale tu 
possa prendere in mano in breve Lisp o Haskell.
Io ad esempio per programmare in Lisp devo fare uno sforzo *enorme*, e 
non accetterei mai un lavoro in Lisp.
Ed e' un peccato, perche' una volta nella vita vorrei passare il 
capitolo due del SICP (che e' Scheme, ma vabbe').
  ngw


Facciamo così.
Io ammetto che una interpretazione _lasca_ di SOFT real time
_assomiglia_ a quanto si _potrebbe_ fare in una applicazione VoIP.
Tu ammetti che la frase:
"esistono cose che richiedono prestazioni [...] real
time come il VoIP."
è sbagliata.
ok?
-- 
Gerolamo 

 possa prendere in mano in breve Lisp o Haskell.
Infatti dicevo in tempi "non brevi".
Una volta su lisp mi ero letto qualcosa, ma certo su una scala
da 1 a 10 non posso che dire di partire da 0.
Poi per capire davvero, dovrei provare a fare qualcosa di minimamente
"serio".
Comunque a me questo thread e' piaciuto molto
motivazione:
a- e' tecnico, molto piu' di altri [e dal mio punto di vista questo
   fa guadagnare moltissimi punti]
b- e' tecnico su argomenti che mi piacciono 
   e mi interessano anche professionalmente 
   (linguaggi di programmazione,
  real-time, VoIP)
c- mi da' lo spunto per provare a conoscere "robe" nuove (haskell,
o'calm, mai sentiti prima. Prima o poi qualcosa provero' a fare)
d- si e' mantenuto su toni accettabili
Propongo di votarlo come thread dell'anno :-).
Ciao,
Marco


 o'calm, mai sentiti prima. Prima o poi qualcosa provero' a fare)
Vedo che insisti e ancora non te l'hanno fatto notare:o'calm,a meno che tu
intenda Giggetto O'Calm di Pozzuoli,non l'hai mai sentito prima e mai lo
sentirai. 
OCAML

 da 1 a 10 non posso che dire di partire da 0.
http://mitpress.mit.edu/sicp/full-text/book/book.html
Con questo insegnano a programmare al MIT. E' Scheme, un dialetto Lisp.
  ngw

Braindead ha scritto:

ma LOL!

 Con questo insegnano a programmare al MIT. E' Scheme, un dialetto Lisp.
mitico lo scheme, ricorsivo all'ennesima potenza :-)
Ci feci un paio di videogiochi per impararlo, davvero divertente e veloce e le gui non sono poi così 
male.
Il più è entrare nella logica nella ricorsione forzata, delle funzioni higher order ecc...

 Vedo che insisti e ancora non te l'hanno fatto notare:o'calm,
Per forza che insisto (o meglio insistevo) .
Come ho detto non l'avevo mai sentito prima per cui o'calm o ocaml
cambiava poco per me.
Viceversa ora ( o meglio ieri) che mi sono installato la versione per
cygwin
e ho scritto le prime "cianfrusaglie informatiche"
in tale linguaggio ti posso
dire che questa cosa che mi fai notare e'
appunto la prima cosa che ho notato quando ho cercato su internet
da dove potevo scaricarmelo.
Sono ancora al I capitolo di "An introduction to objective caml"
e ora vado a leggermi il paragrafo "Imperative features".
Peccato; volevo leggermi la quarta lezione di 
"Teach yourself hungarian" ma questa cosa dei linguaggi "strani" mi
ha un po' risvegliato antichi istinti informatici.
Ciao,
Marco.


> Sono ancora al I capitolo di "An introduction to objective caml"
Prima che mi correggi ancora...
Volevo dire al I capitolo di
"The Objective Caml system" release 3.09, 
di cui "An introduction to objective caml" e' la parte I.


 è che tra 3 anni queste architetture diventano complesse come J2EE vero?
Zope gia' lo e'.
E te lo dice uno che si e' rovinato la vita con Zope 2 ed e' stato uno
dei primi a tentare di rirovinarsela con Zope 3 :D
Gli altri li conosco poco.
  ngw
-- 
checking for life_signs in -lKenny... no
	Oh my god, make (1) killed Kenny ! You, bastards !
nicholas_wieland-at-yahoo-dot-it