Newsgroup: it.comp.java
Titolo: "Praticabilità" di Java e J2EE (lungo)

Salve a tutto il ng,
vorrei avere qualche vostro parere / impressione sulla effettiva 
produttività del linguaggio Java, sui tempi di sviluppo e sull'efficacia di 
quanto si riesce a sviluppare.... Premesso, ovviamente, che ognuno di noi ha 
i suoi tempi e i suoi ritmi, quello di cui vorrei parlare è sulla praticità 
di usare Java nello sviluppo di certi tipi di applicazione. Lavoro ad un 
progetto di sviluppo di un gestionale Java oriented, vagamente come 
responsabile tecnico nonchè ovviamente sviluppatore, ormai da un po' di anni 
e, tra una balla e l'altra, giudico decisamente scarsi i risultati 
conseguiti, sia come performance, sia come tempi medi per realizzare una 
funzione qualunque.
Vi faccio un esempio: realizzare la funzionalità di immissione di ordini di 
acquisto: ho impiegato circa 12 giorni lavorativi per realizzare 
l'interfaccia, la business logic, l'accesso ai dati e il controllo di 
coerenza dei dati immessi (che al 90% sono costituiti da verifica, su 
database, dell'esistenza di questo o quel codice articolo o del cliente). 
Domanda : è troppo ?  Secondo me, assolutamente SI, e in primis quello che 
non mi soddisfa è la lentezza con cui riesco a scrivere il codice che esegue 
query, realizza le operazioni CRUD, controlla la concorrenza dei dati (e non 
solo a livello dell'applicativo Java: si deve verificare che nessun altro 
programma, o un utente che effettua correzioni direttamente con SQL sul 
database (!!!!)  ) che consiste nella pratica nella rilettura del record già 
letto prima di effettuare una modifica,  l'esecuzione di decodifiche (senza 
alcuna possibilità di eseguire caching dei dati decodificati, che possono 
cambiare in qualunque momento)
Vi sono anche situazioni in cui dovrei consentire all'utente di editare una 
tabella e di ottenere, direttamente, la scrittura dei dati su varie tabelle, 
come se vi fosse un collegamento diretto tra la parte Java ed il DBMS.
Ovviamente un gestionale è assolutamente database centrico quindi difficoltà 
di questo genere sono ovviamente da mettere a consuntivo, e non dico che le 
specifiche di cui sopra siano impossibili da ottenere, ma, almeno per quello 
che mi riguarda, le ottengo in tempi che considero biblici.
E le prestazioni del software ottenuto non sono entusiasmanti, soprattutto 
se li si confronta con la versione attuale del sistema gestionale sviluppata 
in COBOL. Cose che in Cobol richiedono mezza giornata, a me possono 
richiedere anche una settimana.
Io sicuramente non sono, per fare un paragone da trekker, l'androide Data in 
quanto a capacità di analisi e sviluppo di algoritmi, però per quel che 
posso sapere ed avere imparato sul campo o studiando a destra e manca le 
best practices, non vi sono poi così tante "scappatoie" al problema 
dell'accesso efficiente ai dati, alla costruzione di una business logic 
distribuita con una serie di crismi (transazionalità, scalabilità, etc etc). 
Che abbia un Entity EJB o un JavaBean reso persistente da qualche framework 
(ma quale framework controlla che il dato non sia stato alterato con un SQL 
da un operatore di DBMS ?)  *devo* passare attraverso uno strato di accesso 
ai dati, se ho una serie di campi cliente, articolo, prezzo etc non riesco a 
scrivere direttamente il loro contenuto su DBMS senza costruire una query, 
settarvi i parametri etc etc. E per controllare gli N (con N abbastanza 
alto) campi di un form / videata, devo giocoforza scegliere o un'unica query 
di decodifica del form su un numero grande di tabelle o realizzare un 
Decodificatore che, decodificando una tipologia di campo per volta, esegue N 
query. Con buona pace delle prestazioni.
Vi chiedo allora, sperando di non passare per troll : Java e J2EE - ma non 
credo che la solfa cambierebbe utilizzando per esempio .NET - è davvero un 
linguaggio *praticabile* per scrivere applicazioni gestionali in tempi umani 
e con pochi (per non dire pochissimi) uomini a disposizione, o richiede per 
essere utilizzato a piena potenza uno staff di sviluppatori decisamente 
importante come numero di addetti ?
Temo di conoscere la risposta, ma vorrei avere un parere da chi, come voi, 
mastica e *respira* Java /J2EE da parecchio tempo.
Saluti e grazie per la pazienza,
Scorpio.


Francamente non ho capito questo punto. Che sia fatto da Java o da un editor
non cambia molto, a parte il fatto che non puoi usare il caching.
A naso mi sembra la problematica del versionamento, che dovrebbe essere ben 
gestita da framework come Hibernate, ma non ne sono sicuro...potresti 
rispiegarla con un esempio o maggiori dettagli? 

 rispiegarla con un esempio o maggiori dettagli?
Certamente, ti accontento subito. Premessa: le tabelle esistenti sono incise 
sulla pietra e NON sono alterabili, quindi NON possiamo usare tecniche tipo 
versioningID (peraltro ottime).
Supponiamo che tu abbia letto una riga ordine da una tabella "ORDINI" e che 
abbia memorizzato i dati in un
JavaBean "RigaOrdine", con i campi:
- numero ordine
- cliente
- articolo
- quantità
etc etc..
Il JavaBean è "rimappato" su un form, web o client Java non ha molta 
importanza, che l'utente edita per modificare l'ordine. In un framework di 
persistenza io potrei scrivere qualcosa del tipo:
persistenceengine.persist(mybean)
ed il framework a livello SQL genererà una UPDATE che, se assumiamo che 
numero ordine sia la chiave, sarà del tipo UPDATE table WHERE numeroordine = 
?.
Però la stessa tabella può essere modificata dal programma COBOL precedente, 
o, addirittura, potrebbe essere alterata da SQL "diretto"  da parte di 
qualche operatore a cui viene chiesto di forzare un dato (lo so, è assurdo 
ma succede !), e senza il versioning si potrebbe avere un simile scenario :
- io : leggo l'ordine 1 con qta = 5
- tu : da programma B leggi l'ordine 1 con qta 5
- tu : memorizzi la qta 10
- io: scrivo qta = 9
La tua modifica è perduta. Invece la richiesta è del tipo : il programma 
Java deve accorgersi che il valore quantità è cambiato, e per farlo l'unico 
modo è seguire una logica del tipo:
UPDATE TABELLA SET Campo1= nuovoValoreCampo1 ... Campo2 = 
vecchioValoreCampo2 WHERE Campo1 = valoreCampo1AcquisitoInLetturaOriginale 
etc...
Se la riga è stata modificata da chiunque, la clausola where NON è 
soddisfatta quindi l'update aggiorna 0 righe (condizione di errore).
Ciò significa che comunque vada io devo mantenere in memoria una "copia 
sacra" di ogni oggetto persistente, per poter verificare se i dati sono 
stati aggiornati da un altro client. Ciò non è comodissimo, ma  comunque è 
fattibile.
Il mio post ad ogni modo sollevava, credo, un certo dubbio di problemi 
"esistenziali"... nessun problema di quelli che ho esposto è irrisolubile da 
un punto di vista tecnico, ma è oneroso dal punto di vista del codice da 
scrivere: J2EE o Java o  comunque qualunque altro linguaggio "moderno" sono 
efficaci / efficienti laddove ci debba essere una dipendenza CONTINUA da un 
database ?
Io, ormai, ne dubito davvero tanto.
Salute e grazie per il tuo intervento.
Scorpio. 

 quanto si riesce a sviluppare....
Senza dilungarmi troppo, almeno per ora ;), direi che il fatto che sia 
java che il suo diretto concorrente .net stiano includendo un supporto 
sempre più esteso e integrato a linguaggi dinamici che fino a pochi anni 
fa venivano etichettati e liquidati come "di scripting", secondo me la 
dice lunga.
Nel jdk 1.6 troviamo Rhino (javascript), facile che presto ne compaiano 
altri:
https://scripting.dev.java.net/
www.jcp.org/en/jsr/detail?id=223
Cosa che non può che fare che bene a un linguaggio, e una piattaforma, 
che ormai dimostra ampiamente la sua età e i suoi limiti.
Ciao,
Paolo

 cambiare in qualunque momento)
premetto che j2ee è indubbiamente sovraingegnerizzato.
tuttavia osservo nel tuo approccio una enorme quantità di energia che 
non è il caso di disperdere. in alcuni casi anche delle lacune 
java-independent, come quando descrivi il metodo per controllare la 
concorrenza: ci sono "pattern" universali per farlo, che vanno dalla 
aggiunta di restrizioni coi valori originari nella where fino alla 
version della riga, a seconda delle esigenze.
ma la cosa assurda è che se usi un framework per la gestione della 
persistenza di queste e altre cose il tuo programma non se ne deve 
proprio preoccupare.
lo stesso dicasi per i controlli. a parte quelli che puoi delegare in 
ultima istanza al database (ad esempio, se metti la constraint sulla 
riga ordine non sull'articolo ma sull'articolo/cliente hai la certezza 
che puttanate sul db non ce ne vanno) ma anche in quel caso li risolvi 
con gli strumenti di persistenza, a patto che tu progetti correttamente 
le relazioni.
in ultimo spendo due parole sull'approccio complessivo al progetto.
ad oggi vale decisamente la pena di spendere buona parte del tempo alla 
progettazione, alla scelta dei framework e degli strumenti nonchè 
all'integrazione degli stessi. la produttività si migliora in questo modo.
dai un'occhiata a questo progetto: 
http://www.appfuse.org/


Non sono un esperto Hibernate, ma se ti interessa prova a dare un'occhiata 
qua:
http://www.hibernate.org/hib_docs/reference/en/html/transactions.html
capitolo
11.3.4. Customizing automatic versioning


Ti ringrazio per i suggerimenti, spero di riuscirne a fare tesoro.
Scorpio 

 ?
l'integrità dei dati spetta per contratto al db garantirla. questo non 
risparmia al programma i controlli dell'input ma la responsabilità non 
può essere delegata alla business logic (così come la sicurezza, ad 
esempio).

 importante come numero di addetti ?
La mia personalissima opinione è che c'è in giro di molto meglio. Ma
ribadisco, piuttosto che COBOL, benvenga Java.
In particolare penso a Python o a Ruby come 'molto meglio'.
Poi il punto è che se continui a ragionare in COBOL, allora tanto vale
che tu lavori pure in COBOL. Piegare un linguaggio che non è COBOL per
funzionare come COBOL (quindi prendendosi tutti gli svantaggi di questo,
senza averne i vantaggi) è puro masochismo.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 wrote:
[CUT]
Hai centrato il punto. Il fatto, è che io NON conosco COBOL nè lo uso: 
sviluppo in Java. Sono gli altri colleghi
che, con COBOL, hanno una ferrari mentre io ho una cinquecento....

 che, con COBOL, hanno una ferrari mentre io ho una cinquecento....
no, loro hanno la cinquecento. mentre tu hai un enorme suv con il quale 
stai sbattendo ripetutamente contro la colonna facendo manovra per 
uscire dal garage.

 che, con COBOL, hanno una ferrari mentre io ho una cinquecento....
Mi pare che non si possano fare molti paragoni (anche perchč dire COBOL
č dire tutto e niente). Con che linguaggio hai piů esperienza? E davvero
dove lavori puoi scegliere il linguaggio e basta?
Ad ogni modo, che dire. Fra Java e COBOL, senza dubbio Java. Devi solo
metterti sotto e prendere confidenza. Anche se, ammesso che tu possa
scegliere, io credo ci siano piattaforme ben piů agili.


 ha scritto nel messaggio 
news:f7t4am$vb2$1...@tdi.cu.mi.it...

Uhm. Non ho capito come interpretare questa tua affermazione: sono un 
incompetente ?
O è Java ad essere mastodontico ?

 uscire dal garage.
Direi che la metafora č sostanzialmente perfetta :)


 scegliere, io credo ci siano piattaforme ben piů agili.
Saran 8 anni che utilizzo Java. Forse dovrei cambiare mestiere :-(

 O è Java ad essere mastodontico ?
entrambi :-)
non prenderla come offesa, ma onestamente dalla discussione emergono 
limiti tuoi che dovresti colmare. poi parliamo della indubbia 
sovraingegnerizzazione di java che è un problema ma non il genere di 
problema che stai evidenziando tu.
ribadisco, dovresti investire tempo per integrare *almeno* un framework 
di persistenza e uno mvc perchè altrimenti non esci dal garage.

 limiti tuoi che dovresti colmare.
Se me li enumeri, mi fai un favore. Sul serio.

 Se me li enumeri, mi fai un favore. Sul serio.
beh, quando hai descritto come gestivi gli update in concorrenza sul 
database. oppure quando hai mostrato (correggimi se sbaglio) di non 
conoscere l'esistenza delle foreign key e delle constraint. oltre al 
fatto che (correggimi ancora se sbaglio) sul db ci vai con jdbc invece 
che con strumenti per la gestione della persistenza, cosa che equivale a 
volersi parecchio male ma anche a produrre codice molto esposto a bug e 
instabilità di vario genere.
sia chiaro che non voglio essere offensivo, solo critico ma costruttivo.

 Saran 8 anni che utilizzo Java. Forse dovrei cambiare mestiere :-(
Mi viene un po' da ridere perchè, dopo 8 anni (10 totali, ma un paio 
"ibridi") di java, è quello che ho fatto io tre settimane fa... ;)
Ciao,
Paolo

 "ibridi") di java, č quello che ho fatto io tre settimane fa... ;)
Hai proprio cambiato mestiere oppure solo linguaggio? ;)


 Saran 8 anni che utilizzo Java. Forse dovrei cambiare mestiere :-(
Scusa, ma ti sei accorto adesso di questo problema? Intendo dire del
problema di produttività (e soprattutto, strano che nessuno abbia detto
nulla, da quanto dici tu i tuoi colleghi sono più produttivi di te di
ordini di grandezza, come mai i tuoi datori di lavoro non hanno detto
nulla? -- e ancora... stranissimo che tu pensassi che COBOL fosse più
produttivo di Java).
Poi anche qui, cosa intendi? Io saranno forse solo 4 anni che 'utilizzo'
Java, ma il grosso della roba lo ho fatto con altre piattaforme. Anche
perchè la prima volta che ho deciso di guardarci (correva Java 1.3), mi
ha fatto ribrezzo ad alto livello. Mi sono trovato meglio con la 1.4 e
ancora meglio con la 1.5. Ma nel frattempo avevo 'saltato' Java,
passando principalmente da C a linguaggi dinamici (o roba 'esotica' come
Haskell  o di recente Prolog).
Adesso butta bene la 1.6, specialmente tenendo conto di JRuby, ma non ho
tempo di affrontare seriamente la cosa. Per cui, tornando a noi, è vero
che è un po' che mastico Java, ma non è certo li dove le mie skills
stanno.


 sia chiaro che non voglio essere offensivo, solo critico ma costruttivo.
Non sei stato assolutamente offensivo.
Ciao,
    Scorpio. 

 produttivo di Java).
Sì, dopo circa una dozzina di progetti sviluppati in quattro anni mi sembra 
di aver fatto poco. Tutto qui. E non è che *penso* che COBOL (che in realtà 
è RPG, solo che si adotta la tecnica mista...) sia più produttivo. Lo vedo. 
Tu un order entry completo lo scriveresti in un giorno ? E' una curiosità, 
non una domanda retorica e polemica....
Scorpio. 

 Hai proprio cambiato mestiere oppure solo linguaggio? ;)
Ho cambiato "tipologia" di mestiere: da programmatore (anche se negli 
ultimi anni ho programmato poco, ricoprendo altri ruoli) a imprenditore.
Poi, come ben sai, sto anche cambiando linguaggio, che è la cosa più 
divertente ;)
Ciao,
Paolo

 non una domanda retorica e polemica....
Se usi le librerie e gli strumenti giusti, un inserimento ordini lo puoi 
fare in quattro ore, IMHO. Poi ovviamente dipende dai dettagli.
Se hai un tool che ti permette di pubblicare tabelle su web, tanto per 
fare un esempio, puoi ottenere il risultato anche in meno tempo: ti crei 
le tabelle che ti servono e le pubblichi.
Secondo me il problema è un altro: lavori in un'azienda in cui non sanno 
lavorare e ti devi adeguare.
Non so come altro si possa descrivere un'azienda in cui c'è un db senza 
chiavi e non lo si può modificare.
Se poi c'è chi si è preparato negli anni i suoi begli strumenti, per 
usare questo sistema anomalo e folle (e, ovviamente, intoccabile. Pena 
il crollo del loro bel "castello di carte"), non è un problema di 
produttività tua o loro.
Ciao,
Paolo

 chiavi e non lo si può modificare.
Non si può perchè questo significherebbe toccare i programmi pregressi. E 
questo nessuno lo vuole fare.
Scorpio.

 questo nessuno lo vuole fare.
i miei suggerimenti tecnici sono eventualmente validi, a patto però che 
siano applicabili.

 divertente ;)
Eh. :)


 wrote:

Una volta uno bravo, ma davvero bravo(*) mi citava "1 giorno" per avere
una buona gestione in RPG di una _anagrafica_, non di un'immissione
ordini.
E tutti queelli a cui riciclavo la citazione commentavano : "si, ma se è
un programmatore RPG proprio bravo", cioè se magari ne ha fatte una
decina in fila.
In compenso ho lavorato in una software house dove chi metteva mano alla
"vestizione" ad oggetti (Smalltalk, all'epoca) della gestione ordini
(taglia-colore-stagione, canvas, etc etc etc) si licenziava dopo un mese
!!!
... e credo di essere stato l'ultimo ad occuparsene !!!
Ri-ciao,
    Davide
(*) a Rochester, Minnesota, in un cigarette break sotto la neve
--
Ing. Davide Grandi
davide...@mclink.it

 
Lavoro "da sempre" a gomito con programmatori RPG e/o COBOL e questa
tecnica si chiama "immagine record" o con nomi simili. A volte ci sono
anche dei contatori di versione del record aggiornati ad ogni update.
L'unica realtà dove non la usavano ti concedevano il lock dei record con
la "select for update" rischiando, in compenso, l'attesa infinita (o il
fallimento della transazione per timeout).
In un post di qualche tempo fa su it.comp.as400 un poster diceva :
---
Gli aggiornamenti fatti con dei programmi dotati di mappa vanno fatti
con la tecnica delle immagini ossia caricare l'immagine del record ....
l'utente lavora ad ogni invio prima dell'aggiornamento confrontare con
l'immagine salvata se coincide salvare il record e reimpostarsi
l'immagine per il prossimo confronto.
Se l'immagine é diversa segnalare con "Il record e stato aggiornato da
un altro utente" e precedere un tasto di Reload=F5 per rivisualizzare i
dati ...
---
Poi si potrebbe aprire un thread infinito (e sciocco) su "E' meglio il
COBOL - è meglio Java per scrivere un ERP".
Lavoro nel mercato del software da 14 anni e ti posso dare un paio di
fatti "base" (al limite banali), lasciandoti volentieri l'analisi :
- scrivere e mantenere software Java che stia in piedi per anni è più
complicato e difficile che in RPG e COBOL
- in Java è più facile gestire aspetti "moderni" di comunicazione,
grafica ed integrazione (anche perchè hai un mare di librerie già pronte
e testate)
- qualcuno (grosso) ha trasferito il suo ERP in Java ed è sopravvissuto,
qualcuno (medio - piccolo) ci ha provato ed ha fallito, licenziando
programmatori Java ed RPG
- le quattro software house COBOL ed RPG che mi hanno stipendiato in
questi anni usavano i linguaggi cosiddetti "legacy" per fatturare con i
loro ERP e le nuove tecnologie per "rivestirli" adeguatamente
- esistono realtà "moderne" che usano solo Java EE + db + trigger e
stored procedure (e se la cavano egregiamente)
Ciao,
    Davide
PS : quando non faccio "programmazione Java in conto terzi" (bel
sinonimo di body rental) webbizzo (in Java) ERP legacy scritti in COBOL
o RPG !!!


 questo nessuno lo vuole fare.
O meglio, nessuno se lo puo' permettere, perchè costa.
E costa perchè :
- è improbabile che ci siano dei casi di test che ti permettano di
ristrutturare il codice senza generare errori in altre funzioni
- ci sono magari tonnellate di personalizzazioni rilasciate presso
clienti che non avranno voglia di pagarsi la "loro" ristrutturazione
e siccome costa e non porta fatturato immediato (anzi) ... difficilmente
verrà fatto. Fine delle ristrutturazioni non obbligatorie.
I pochi papers che ho trovato in giro sulla ristrutturazione di
applicazioni legacy (includendo anche casi di codice _java_ definito
"legacy") partivano da un piano di consolidamento dell'esistente con
piani di test automatici (alla Junit) e _poi_ passavano alla
ristrutturazione del codice (non ricordo però nomi eclatanti da
riportare, tra i riferimenti).
Se parti da zero, puoi fare quello che vuoi con java, db e quant'altro
(ed una gestione ordini java EE-Hibernate-supergrafica la puoi davvero
scrivere in tempi magari non biblici, anche se non in due ore [*]), ma
se _devi_ integrarti con realtà preesistenti ... devi adattarti e
prepararti TU una buona serie di casi di test per beccare i LORO errori
...
Ri-ri-ciao,
    Davide
[*] vero o no, caro il mio sergente delle Sturmtruppen ?


 ...
Siccome però non parto da zero, devo restare fedele alla struttura 
pregressa. Mi sembra comunque che, di post in post, si sia un po' perso lo 
spirito del thread che ho voluto aprire. Non dubito che in J2EE si possa 
fare molto, moltissimo, ma credo che ciò richieda uno sforzo in primis 
concettuale e poi anche pratico che in tanti contesti non è semplicemente 
applicabile: per questo ho parlato di "Praticabilità" di Java e di J2EE.
In tanti in questo thread hanno risposto, con consigli (giusti) critiche 
(giuste) suggerimenti (accettabili) alla mia "provocazione". Sono passato 
anche per *incompetente*, e qualcuno, giustamente, ha detto : " Può darsi 
che sia così", sempre senza offesa, e può anche darsi  benissimo che lo sia 
davvero. Sfido chiunque, però, ad affermare che un buon progetto J2EE non 
deve separare la logica di presentazione da quella di business e da quella 
di accesso ai dati. E ciò significa al di là di qualunque framework o API 
adottata due cose: complessità e rigore nello sviluppo.
Qualcuno ha parlato, e secondo me a rigore, di sovra ingegnerizzazione di 
J2EE. Da ingegnere, rigore e precisione non mi spaventano. Ma mi tremano le 
gambe all'idea di dover usare uno strumento che richiede rigore e precisione 
in un contesto applicativo dove questi sono concetti latitanti. E sono un 
assertore convinto del fatto che "presto e bene raro viene".
In questi anni mi è stato chiesto di tutto: di installare moduli J2EE senza 
interrompere il servizio, di aggiungere a caldo datasource senza riavviare 
l'application server, di creare form direttamente collegati alla tabella su 
database, di non far vedere il refresh delle pagine web quando i dati si 
aggiornano o si passa da una pagina all'altra.
Tutti compiti che, dal momento che AS400 non ha questi problemi, sono stati 
visti come *limiti assoluti di Java*, e che invece sono nella quasi totalità 
dei casi richieste assurde per come J2EE è stato concepito e per come il web 
funziona.
Ma sono richieste, e quando devo rispondere "no"  si solleva sempre il 
dubbio che la tecnologia Java sia *cattiva*, un giocattolone che va bene per 
una demo o per i telefonini. Tu, Davide, che se non sbaglio frequenti anche 
il ng di as400, potrai convermare quanto questa forma mentis sia diffusa....
E, alla lunga, temo che mi abbiano pure convinto.
Saluti
    Scorpio.

 come il web funziona.
Stai criticando il web? ok, allora perche' non fai un applicativo stand 
alone utilizzando che so le Swing o altre librerie java?
Non capisco perche' quelle dovrebbero essere limiti assoluti di Java, 
sinceramente. 

 COBOL - è meglio Java per scrivere un ERP".
per ora mi pare di capire la discussione è limitata ad un order-entry,
che peraltro lavora in concorrenza con altri programmi (cobol?).
lo scenario non è stato descritto ma sono pronto a scommettere che è 
quello tipico: dato un gestionale aziendale, si richiede la possibilità 
di inserire gli ordini via web. da qui la scelta di java (ma poteva 
essere scelto un qualsiasi altro ambiente idoneo allo scopo, i problemi 
sarebbero stati gli stessi) e i problemi di integrazione annessi e connessi.

 sinceramente.
Infatti ci si è convertiti a fare quello, con business logic spostati 
comunque sul server.

 non una domanda retorica e polemica....
In un giorno a tempo perso. :) In effetti molto meno. Le 2-4 ore mi
sembra una valutazione realistica (e anche con un certo margine).
Chiaramente ammesso che possa progettare tutto da 0. Come ti hanno fatto
notare il problema è tutto li. 


 Beh, un passo avanti dire. In bocca al lupo per la tua attività.
Crepi il lupo! ;)
Da dire che la tentazione di cambiare mestiere "in toto" ogni tanto 
appare: dopo 15 anni di informatica ho la falegnameria che mi attira... :D

univoche.....
Con tutto il rispetto, state messi abbastanza male. A questo punto, io
credo che, prima di parlare di produttività, abbiate molti altri
problemi da risolvere.

non una domanda retorica e polemica....
In Delphi anche meno :-)

chiavi e non lo si può modificare.
Concordo.

questo nessuno lo vuole fare.
Non è un'azienda, è un buco nero :-)

funziona.
Secondo me è qui il punto. E' una questione di percezione da parte
delgi utenti. Io sono dell'idea che le applicazioni web non siano
affatto adatte a ricostruire i meccanismi desktop classici dei
gestionali. L'interfaccia web è nata per presentare i dati e non
risalire la corrente. Addirittura sono convinto che, per questo tipo
di applicazioni, l'interfaccia a caratteri e l'interazione tramite
tastiera siano ancora meglio della GUI con bottoni e finestre (chi usa
i terminali con AS400 lo sa bene). Tutto quello che è conseguito
all'uso passivo dei browser, ovvero il voler avere a tutti i costi
l'interazione, è stata una forzatura. Oggi pare che AJAX sia una
grandissima novità e che si possano fare cose mirabolanti, quando alla
fine le stesse cose, su un'interfaccia "attiva" di un'applicazione
desktop esistono naturalmente. Ho colleghi che si entusiasmano, perché
nel progetto intranet sono riusciti a far agire in modo dinamico
l'interfaccia web, quando le stesse cose, in Delphi (ambiente RAD,
peraltro) si facevano in due secondi. Mi viene da ridere perché non si
può parlare di produttività diversa, se si usano strumenti diversi in
contesti in cui almeno uno dei due è inadeguato. Il problema non è
Java o COBOL, il problema è interfaccia di un tipo o di un altro e
quindi lo strumento più adatto per gestirla.
Tutto questo IMHO, ovviamente.

Proposi AJAX e fu bocciato.
Ma nella tua azienda si puň andare almeno a pisciare? :-)

"Andrea Laforgia" <a.laf...@andrealaforgia.it.invalid> ha scritto nel 
messaggio news:6i77a31ukubdati9j...@4ax.com...

Mi sto facendo l'idea che l'informatica in Italia sia questo...per quanto 
riguarda la maggior parte dei casi (almeno nord-est).
Piena di dilettanti che non comprendono la necessita' di cose come le 
constraints di un database, unit testing (per loro facilmente sostituibile 
apendo il browser e provando cosa succede quando premo un link), l'utilita' 
dei framework, la corretta gestione delle eccezioni, logging, ecc..
Francamente sono stufo di sentire cose come "le JSP pure sono meglio" 
(avessero mai provato un framework web!), funziona pure lo stesso (tipica 
frase che ti senti dire quando trovi buchi spaventosi nella gestione della 
concorrenza). 

Ti parlo da ex-programmatore COBOL e ora programmatore java.
Il COBOL, rispetto al java, è un linguaggio specifico per fare programmi 
gestionali che accedono ad un database e che elaborano una quantità enorme 
di dati.
Il java invece è un linguaggio general purpose, con il quale puoi fare 
qualsiasi applicativo (grafico, gestionale, ecc. ecc.).
Purtroppo i "puristi" del java se ne fregano altamente di facilitare la vita 
al programmatore "gestionale" che deve focalizzare il suo sviluppo sul 
problema da risolvere e non per es. sul fatto che un stringa sia a null e 
quindi prima di confrontarla con un'altra devo sempre testare che non sia 
null.
Quello che non sopporto di java nel fare programmi gestionali è per es.:
1) Le stringhe sono oggetti coe gli altri (quanti null pointer exception mi 
sono beccato non ne hai idea...)
2) I BigDecimal sono oggetti (pensa te se per fare un'aoperazione che in 
COBOL scriverei a=b+c*d-e, in java devo usare i metodi add, multiply ecc. 
ecc.)
3) Le date in java sono una cosa allucinante (per sapere per es. de una data 
è uguale a 01/01/2007 devo scrivere almeno 6 o 7 righe di codice, assurdo)
Ci sono invece altre cose che apprezzo di java:
1) Ci sono un sacco di librerie che fanno di tutto e di più
2) Ti permette di strutturare meglio l'applicativo
3) Se usi framework tipo Spring hai la vira un po' più facile
Spero che con i nuovi linguaggi di scripting per la JVM la vita dei 
programmatori gestionali migliori :-)
Saluti,
G. 

Linguaggi non strongly-typed ? Brrrr :) !!!
Perché "brrr"?

 programmatori gestionali migliori :-)
Linguaggi non strongly-typed ? Brrrr :) !!!

 Linguaggi non strongly-typed ? Brrrr :) !!!
A tal proposito ho trovato illuminante questo articolo di Eckel:
http://www.mindview.net/WebLog/log-0025
In sintesi: è un test approfondito che rende solido il codice, non la 
tipizzazione.
Ma l'articolo merita una lettura, anche lui era partito con molti dei 
pregiudizi tipici degli sviluppatori java (sottoscritto compreso).
Aggiungo una considerazione personale: perché java usa una tipizzazione 
forte per tutto, eccetto che per i tipi "null" (e, non a caso, è stata 
necessaria l'introduzione di un'eccezione ad hoc)?
Ciao,
Paolo

 Ti parlo da ex-programmatore COBOL e ora programmatore java.
[CUT]
Ti ringrazio x l'intervento. Io non sono un ex programmatore COBOL, vengo 
dal C++ ed utilizzo Java da un bel po' di tempo, pertanto la facilità con 
cui COBOL legge e scrive su una base di dati non ho potuto mai sperimentarla 
dal punto di vista dello sviluppatore... solo per sentito dire da colleghi. 
Che non vale molto come esperienza.
Il mio post originale poneva il dubbio se Java fosse o meno un linguaggio 
idoneo x scrivere programmi gestionali  dove il compito principale è leggere 
e scrivere in modo continuo dal DB.
Scorpio

 e scrivere in modo continuo dal DB.
Secondo me lo è. Esistono però sistemi più adatti se vuoi tirare su
applicazioni desktop in pochissimo tempo. Cito il caso più eclatante e che
deriva dalla mia personale esperienza: Delphi. Ci programmo da 8 anni,
parallelamente a C e C++ e Java. E' un sistema di sviluppo formidabile,
RAD e component-based. I componenti hanno un utilizzo immediato,
intuitivo, sicuro.
In Delphi tirare in piedi un'applicazione gestionale, con tanto di
interfaccia, è roba di poche ore. Non ho mai visto nessun sistema di
sviluppo che consentisse una rapidità tale. L'unico problema è che i modi
di fare le stesse cose sono talmente vari, con Delphi, che prima di
apprendere quello più corretto ci vuole diverso tempo e bisogna essere
necessariamente guidati.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Scorpio.
Nicola
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Il 25 Lug 2007, 16:55, 
n...@libero.it
 (n.n) ha scritto:
Scusate avevo bruciato l'oggetto del 3d


 necessaria l'introduzione di un'eccezione ad hoc)?
Forse per pigrizia degli implementatori della JVM, forse per semplicita'.
Non fosse stato tipizzato, un sintassi del tipo "Object myObj = null; 
myObj.getClass()" non avrebbe generato una NPE, cosa che io pero' mi 
aspetto.
Null e' "null" e basta, a scuola mi insegnavano che "zero non e' un 
numero" :)

 Perché "brrr"?
Perche' sono cocciuto e disordinato :)
Un linguaggio strongly-typed mi obbliga a seguire un certo tracciato e 
mi risparmia brutte sorprese @runtime.
Un linguaggio non strongly-typed, IMHO, ha senso solo per piccoli 
progetti e con un grado di complessita' basso.

 numero" :)
Spero non fosse l'insegnante di matematica a insegnare una assurdità 
come questa... ;)
Ciao,
Paolo

 progetti e con un grado di complessita' basso.
I progetti più grossi e corposi (sia come numero di righe di codice che 
come complessità) sono scritti in C o C++, che sono debolmente tipati.
Ciao,
Paolo

progetti e con un grado di complessita' basso.
Be', posso smentirti almeno sul piano Python. Nonostante (il
"nonostante" lo specifico solo per via del tuo parere :-) abbia il
cosiddetto "duck typing", viene utilizzato anche per grandi progetti.
Il fatto è che, quando assumi un approccio corretto alla
programmazione (vedi l'uso estensivo dei test al punto da diventare un
"test infected" come il buon Bruce Eckel), ha poca importanza la
tipizzazione forte o debole: l'aiuto che ti dà il compilatore nella
sua analisi statica è di gran lunga inferiore a quello offerto dalla
suite di test nella sua analisi dinamica. La cosa sconfortante oggi
come oggi è notare quanta gente programmi ancora senza mettere a punto
una buona batteria di test per il proprio codice.


Tutt'altro. Sarei ben contento di sentirmi dire l'esatto contrario, e, 
personalmente, sono un convinto fautore degli EJB come componenti *davvero* 
distribuiti. Non sono convinto che Java sia uno schifo, anzi. Forse sono io 
che sono uno schifo (o programmo da schifo) o lavoro in un contesto in cui 
Java non va bene.... ma queste ipotesi non possono essere verificabili se 
non con l'esperienza diretta (di come e dove lavoro, si intende).
Scorpio. 

 sviluppo che consentisse una rapidità tale. 
io ne ho conosciuto uno che consentiva uno sviluppo più rapido. si 
chiama powerbuilder (sybase) e ai suoi tempi su applicazioni 
client-server orientate ai dati era insuperabile (fra le altre cose 
aveva la possibilità di usare sql embedded direttamente nel linguaggio).
ora però le dolenti note...
chi ha investito anni uomo sviluppando un gestionale su powerbuilder si 
è ritrovato un prodotto:
- vecchio e non rinnovabile
- tecnologicamente ingessato (i report in pdf ti toglievano il sonno)
- monopiattaforma
- monodatabase (quando hai un sql così invasivo nel codice finisce che 
tutti i propositi di multidatabase vanno in cavalleria)
- non integrato e non integrabile con altri sistemi
- cresciuto su se stesso come un callo, a strati, senza 
ingegnerizzazione (si sviluppa rapidamente? si vede...).
insomma, lo sviluppo rad non va esattamente a braccetto con la qualità e 
la longevità tecnologica dei prodotti. è vero che spesso questi prodotti 
sono di per se "statici", ovvero il cliente che lo compra poi lo usa per 
vent'anni così com'è: però è anche vero che questi programmi dopo due 
anni smetti di venderli perchè sono già vecchi e non ce la fai 
materialmente a rinnovarli.

la longevità tecnologica dei prodotti.
No no no, non ci siamo. Non è il modello, non è il RAD che non va a
braccetto con la qualità e la longevità tecnologica dei prodotti (che
cosa c'entra mai?). Con Delphi si possono sviluppare applicazioni di
altissima qualità e longevità, basta saperlo fare ;-)
p.s.: le pessime qualità di PowerBuilder che hai citato non sono
condivise da Delphi che, anzi, le rovescia tutte meno, ahimé, il
x-platform; avevano fatto un timido tentativo con Kylix, suo gemello,
ma non ha avuto una gran sorte.

Pablo Xon wrote:

Forse perche' quando il progetto e' partito, Java ancora non esisteva :)
Applicazioni di eBanking, logistica per grosse ditte di spedizioni, 
applicazioni finanziarie, perfino programmi per la sicurezza 
dell'esercito: Ho visto solo Java :)

 dell'esercito: Ho visto solo Java :)
Mi sa che confondi marketing e incapacità (o semplice ignoranza) dei 
proggettisti capi con i meriti del linguaggio/piattaforma...

 Forse perche' quando il progetto e' partito, Java ancora non esisteva :)
E tra l'altro, java non è che sia poi così fortemente tipato come 
vorrebbe intendere di essere, altrimenti non esisterebbero mica i cast
che mi sa che confondi dinamico e statico con tipizzazione debole e 
forte: python e ruby, tanto per fare un esempio, sono strongly typed ed 
estremamente dinamici

 Ho visto solo Java :)
Mi spiace per te... ;)
Ti assicuro che il mondo va ben oltre Java, basta guardare con più 
attenzione.
Ciao,
Paolo


Mi pare poco probabile che l'ignoranza sia cosi' ampiamente radicata a 
tutti i livelli, non credi :) ?


Oh, ho visto anche front-end per database in C dannare l'anima degli 
sviluppatori, applicazioni di portfolio management in C++ collassare 
sotto il loro stesso peso e "controller" in python esplodere al minimo 
problema :)
Mi correggo con "ho visto solo Java funzionare correttamente" ;)
Sara' che per un buon 70% degli sviluppatori richiesti sul mercato e' 
ancora richiesta la conoscenza di Java ...

 ancora richiesta la conoscenza di Java ...
Sì, con contratti cocopro a 1000 euro al mese.
Non ti viene il dubbio che ci sia qualcosa di "distorto" sotto?
Ciao,
Paolo

 Sì, con contratti cocopro a 1000 euro al mese.
Non so come sia in Italia, ma qui un lavoro a 1000 Euro al mese e' 
impossibile da trovare ;)
Forse e' questa la differenza: Il mondo del lavoro nel quale mi muovo io 
e' diverso dal tuo, cambiando le premesse cambia anche tutto il resto ...

 e' diverso dal tuo, cambiando le premesse cambia anche tutto il resto ...
Sicuramente, perň eravamo partiti da questioni tecniche (tipizzazione, 
operator overloading) e ora ci stiamo un po' perdendo in discorsi un po' 
meno oggettivi (per usare un eufemismo)... ;)
Tempo fa ho iniziato questo articolo: 
www.concavi.net/pages/j2py/
che tratta i temi di cui si parlava; magari puň essere un ulteriore 
spunto per questo dibattito.
E' completo solo nella parte strettamente legata al linguaggio (non alle 
piattaforme piů in generale), ma visto che il thread partiva proprio da 
questi aspetti (inclusione di linguaggi dinamici nel JDK) forse puň 
essere di interesse.
Ciao,
Paolo

 spunto per questo dibattito.
Prendo spunto dall'esempio sui vettori:
   lista1 = [1, 2, 3]
Una cosa del genere mi lascia una brutta sensazione. Cosa sono ? Double 
? Stringhe ? Interi ?
Una domanda sul "==": In Python come faccio a comparare due istanze (Il 
"==" di Java) ?

 "==" di Java) ?
Per comparare il valore di due oggetti usi '==', per verificare se è la 
stessa istanza 'is'.
E vale per tutto (metodi compresi, per dirne una), non ci sono eccezioni 
alla regola.
Ciao,
Paolo

 impossibile da trovare ;)
Beh, io non credo che accetterei un lavoro da 1000 euro al mese.
Dovrei averne *proprio* bisogno, ma guardando appena appena bene si
trova di meglio (ma non ho presente il mondo di Java più di tanto).
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 progetti e con un grado di complessita' basso.
Il problema è che tu non usi propriamente il concetto di
'strongly-typed'. Tipicamente Python e Ruby *sono* strongly typed.


 tutti i livelli, non credi :) ?
Tutt'altro. La mamma degli ignoranti č pure piů prolifica di quella dei
cretini. :)


 ancora richiesta la conoscenza di Java ...
Questa è poi una stima che non so bene da dove derivi. Certo, Java è
*molto* richiesto, ma da qui al 70%...


 estremamente dinamici
Esatto.


 una buona batteria di test per il proprio codice.
Esatto. E ribadisco, non è che in un linguaggio tipizzato staticamente i
test puoi ometterli: comunque il buon null si può infilare qua e la e
fare schiantare tutto.
Per non parlare dei vari bachi comuni a tutti i linguaggi: roba di più
alto livello riguardante come devono funzionare i vari componenti, che
appunto vanno testati.
Ed è roba che si fa in ogni caso.


 *molto* richiesto, ma da qui al 70%...
Dipende in che ambiti. Nell'ambito finanziario/bancario trovo poche
richieste che (come linguaggio) siano diverse da java.
Ma spero che cambi in fretta, altrimenti...

 tutti i livelli, non credi :) ?
No, non tutti sono così ignoranti (e per fortuna).
Ma per una serie *enorme* di motivi l'andazzo che vedo è quello: si usa
java perché è figo, si usa java perché è l'unica cosa che si conosce, si
usa java perché è XXX (riempi pure come meglio credi).
E raramente si usa java solo perché è lo strumento migliore per quel
dato compito.
Il marketing ha vinto.

 sicurezza sui tipi la sua bandiera la cosa è curiosa.
Appunto, tutti osannano java perché fa i controlli[1] a compile-time,
poi per poterlo usare per fare qualcosa oltre l'hello world *devi* usare
un costrutto che viola la staticità.
[1] tra l'altro, offre una falsa sicurezza: i controlli logici non li
fai durante la compilazione, indi ti servono per forza dei test

 fai durante la compilazione, indi ti servono per forza dei test
Appunto.


 Ma spero che cambi in fretta, altrimenti...
Certo, dipende dall'ambito. Ma li era una frase 'globale'. Ovvero non
ristretta ad un ambito: in quel numero ci vanno quindi le richieste per
programmatori embedded, sitarelli web da quattro soldi e così via.
Come scrivere che in ambito di calcolo ad alte prestazioni FORTRAN ha
che so il 50% delle richieste e 'generalizzarlo' con il fatto che
FORTRAN occupi il 50% del mercato :)


 chiavi-valori.
Beh, ogni implementazione assolve un compito diverso, non vedo grande 
duplicazione ...

 trova di meglio (ma non ho presente il mondo di Java piů di tanto).
Intendevo dire che qui di lavori a paga cosi' bassa non si trovano, 
praticamente in nessun ambito :)

 Certo, Java è *molto* richiesto, ma da qui al 70%...
Nel Paese Delle Banche, java la fa da padrone ;) !

 duplicazione ...
L'"anomalia", se cosě vogliamo definirla, č che in molti altri linguaggi 
tutti questi compiti diversi vengono gestiti da un numero *molto* minore 
di strutture dati.
Persino in VB (agh! ;)
Ciao,
Paolo

Pablo Xon wrote:

Uh ? Potresti fare qualche esempio concreto ? Non mi viene in mente 
nulla al momento :) ...

 praticamente in nessun ambito :)
Beh, non mi stupirei se uno buttato fuori dalle superiori per fare
sitarelli in PHP e affini prendesse cifre in quell'ordine di grandezza.


 nulla al momento :) ...
Facciamo un esempio concreto, ok.
In Java per gestire una lista di oggetti si utilizza quello che dalla 
versione 1.4 si chiama Java Collections Framework (che riunifica, almeno 
nel nome, quello che prima era solo un malloppo di classi sfuse).
La struttura di questo framework è questa:
(
http://java.sun.com/docs/books/tutorial/collections/implementations/index.html
)
Dove sono citate una ventina di classi e una decina di interfacce. Poi 
ci sono le classi Vector e Hashtable, Iterator e Enumeration per 
leggerne i contenuti, e non dimentichiamo gli array nativi ([]).
La cosa "divertente" è che alla fine del documento si legge: se non si è 
sicuri di quale implementazione sarà la migliore per le nostre esigenze, 
usare quelle generiche: HashSet, ArrayList, LinkedList, HashMap.
Da notare che la stessa situazione si trova sotto .NET, dove si sono 
ispirati molto a questo stato di cose.
In VB6, invece, c'era *un* oggettino molto comodo (e molto usato), 
Collection, che funzionava sia come lista che come hash/dizionario (la 
chiave era/è opzionale nel metodo, discriminando le due tipologie).
In Python ci sono due oggetti, la lista ([val1, val2]) e il dizionario 
({1:'primo', 2:'secondo'}), che coprono tutte le esigenze.
Da notare che a livello formale/matematico ci sono sì quattro tipi di 
strutture dati di questo tipo (vettore, lista, coda e pila), ma negli 
ultimi tre cambia l'ordine di restituzione rispetto a quello di 
inserimento (linked, FIFO o LIFO) mentre il primo ha una mappatura 
chiave-valore. Servono quindi almeno due implementazioni separate (FIFO 
e LIFO si possono implementare come due diversi metodi della stessa 
struttura ordinata).
L'"anomalia" di cui parlavo è nella discrepanza tra queste quattro 
strutture dati astratte, le due implementazioni minime necessarie per 
gestirle e le circa 40 classi usate invece in Java.
Penso di aver chiarito il mio punto di vista.
Ciao,
Paolo

 gestirle e le circa 40 classi usate invece in Java.
Ogni implementazione in Java assolve un compito specifico. Per lo 
sviluppatore e' una grande comodita' sapere di usare lo strumento giusto 
per quel tipo di problema.

 sitarelli in PHP e affini prendesse cifre in quell'ordine di grandezza.
Questo non so dirtelo, ho sempre avuto la fortuna di lavorare con 
colleghi che avevano un titolo di studio "adatto" :)
Forse e' anche per questo che vedo molto Java che "funziona" in giro ...

 per quel tipo di problema.
Il problema è che così ci sono sviluppatori che invece di conoscere le 
strutture logiche (che sono quelle che contano, e che servono), 
conoscono in che modo un gruppo di progettisti ha pensato/deciso che 
andassero risolte le cose.
Poi (ma questo è un commento assolutamente personale) con quanti 
sviluppatori hai lavorato, che conoscessero bene il collection framework 
e che sapessero bene come e quando usare cosa?
Il 99% di quelli che ho conosciuto io (e ti assicuro che in quasi dieci 
anni, in almeno quattro aziende diverse, ne ho conosciuti) usavano 
sempre Vector e Hastable.
Lo stesso discorso si può fare per molti altri sottoinsiemi (mi vengono 
in mente la gestione dei file, dei socket, delle GUI...) di Java.
Ciao,
Paolo

 Forse e' anche per questo che vedo molto Java che "funziona" in giro ...
Guarda tu, la vita! ;)
nel mio caso i migliori sviluppatori che ho conosciuto erano o laureati 
in materie non scientifiche o non laureati, mentre i laureati in materie 
"adatte" sono la netta minoranza.
Ciao,
Paolo

 in mente la gestione dei file, dei socket, delle GUI...) di Java.
Gestione dei files ?
Per la GUI potrei darti quasi ragione in un paio di casi, tu a quali ti 
riferisci :) ?

 No, prende proprio il posto: [...]
No, vedi, quello che scrivono nella documentazione o nei commenti conta 
relativamente.
Ciò che conta è che finché non lo dichiarano come deprecato, ognuno 
potrà usare indifferentemente quello che vuole e, a livello di codice e 
di compilatore, sarà assolutamente la stessa cosa.
Per questo in uno dei primi post dicevo che Java ha avuto successo 
troppo in fretta, quando non era ancora maturo, e ora si paga per 
mantenere la retrocompatibilità.
Ciao,
Paolo

 di compilatore, sarà assolutamente la stessa cosa.
Putroppo SUN e' piuttosto restia a buttare a mare API deprecate, si vede 
che ci tiene alla retrocompatibilita' tanto quanto la Microsoft ;)
Per quel che mi concerne, faccio di tutto affinche' il codice dei miei 
progetti non abbia nemmeno un warning del tipo "deprecated"

 mio problema.
Da quello che ci siamo detti con Java puoi scegliere quella che meglio 
si adatta al _suo_ problema... ;)

 mio problema.
Di solito Java (ma non sono lui eh) introduce problemi che in altri
ambienti non ci sono facendoti passare
la soluzione come una cosa che _SI DEVE FARE_ quando basta accorgersi
che la soluzione è una pezza
ad un problema che i progettisti han creato (capita eh, nessun
progettista e nessun linguaggio è perfetto)

 progettista e nessun linguaggio è perfetto)
Esatto, nessun linguaggio e' perfetto. Ma certi sono piu' perfetti di 
altri ;)
Potresti citarmi uno di questi casi ? Sono seriamente interessato ...

Pablo Xon wrote:

Il problema di un accesso concorrente ad una struttura di dati non si 
presenta solo in Java. Lo stesso si dica per queue bloccanti, buffer 
circolari, ...
Come risolvi questi problemi, per esempio, in Python ? Devi crearti ogni 
volta da zero la struttura ?