Re: [Wpaisb-devel] MANIFESTO il mio diritto di argomentare sul MANIFESTO in maiera convulsa e 'circoncisa'

[Luca Saiu]

Salute.
Francesco, penso che tu abbia scrito l'e-mail piu` intelligente che sia
passata di qui finora. Mi pento d'aver incitato a scrivere in italiano
perche` questa conversazione sarebbe molto istruttiva da leggere per i
posteri -sarebbe divertente riprenderla tra qualche anno- e meriterebbe
piu` larga diffusione e accessibilita`. Possiamo sempre pubblicarne una
traduzione da qualche parte.

nids wrote:
> Il sistema attuale di programmazione web prevede l'interazione di
> peer che fra loro sono collegati da reti lente. Il problema della
> lentezza si presenta non solo nel fantomatico "ultimo miglio" ma
> anche nei tronconi intermedi di rete sovraccarichi: TCP in caso
> di perdita di pacchetti non fa lo "spaccone" ma cerca di tenere
> un "profilo basso".

Una parentesi seria: TCP e` probabilmente migliorabile, ma non e`
uno degli obiettivi che mi pongo adesso; attualmente non sarei
nemmeno in grado, perche` non conosco abbastanza bene i livelli
"bassi" della rete. Ma penso che sarebbe faticoso ottenere
miglioramenti significativi, e qualsiasi cambiamento incompatibile
richiederebbe supporto a livello di sistema. Sarebbe *molto* difficile
ottenere consenso su questo, e per un nuovo transport purtroppo c'e`
bisogno di consenso.

Quanto al resto: e` evidente che la posizione che esprimi qui e` solo
quella di avvocato del diavolo, come del resto dichiari, e che non
riflette davvero le tue opinioni. Rispondo comunque ai punti che poni
anche a costo di apparire ridicolo, per chiarire quello che penso alle
persone con cui non ho parlato in modo approfondito.

Ovviamente le mie contro-obiezioni non sono rivolte a Francesco ma a un
interlocutore ipotetico che potrebbe porle davvero. Ci sono, eccome se
ci sono.

> HTTP e' usato anche in locale perche' in questo nodo si possono fare
> applicazioni modulari in grado di richiamarsi a vicenda tra di loro.

Le applicazioni modulari si possono fare anche con i socket, con le
pipe, con le RPC in stile Sun, con RMI o Corba (tutte soluzioni
migliori di HTTP quando applicabili). Ma una applicazione che usa HTTP
nel modo convenzionale (cioe` tramite uno o piu` server HTTP e magari
qualcosa come Tomcat) non e` facile da trasportare e riutilizzare.

> XML ormai e' uno standard affermato e ci sono "decinaia" di
> librerie che lo parsano... e chi ha piu' il tempo di scriversi
> un parser oggi?

Quando e` la cosa giusta si dovrebbero scrivere un parser e un printer
(non e` poi un gran lavoro), ma nei casi comuni questo non serve. Nella
mia proposta dovremmo scrivere noi un marshaller/unmarshaller, qualora
si rivelasse necessario; con Scheme non e` indispensabile perche` le
S-espressioni in forma testuale sono gia` una rappresentazione
abbastanza ragionevole, ma usare un formato binario piu` compatto
migliorerebbe le prestazioni; si tratta comunque di scrivere un supporto
nell'infrastruttura, una volta per tutte e non una volta per applicazione.
Un lavoro simile a quello che ha fatto ciascuno di quella banda di
parassiti perditempo e rubastipendio che ha scritto tutte le librerie
per gestire XML. Dove hanno trovato il tempo loro? Direi che possiamo
trovarlo anche noi nello stesso posto, e nel frattempo divertirci molto
di piu`.

>> 2) implementation complexity:
>> Most web application actually compute quite little but are
>> surprisingly
>> complex to write.
>> Many different tools and languages are used:
>> On the server side (at least three of the following ones for most
>> appications):
>> - One or more HTTP servers
>
> Il problema e' stato trattato sopra.

Quello di HTTP. Ma il problema della complessita` delle applicazioni e`
fondamentale e *non* e` stato trattato. Penso sia il mio argomento piu`
forte, perche` e` facile da percepire e verificare.

>> - Java/Perl/Python/PHP/JSP/ASP
>
> Sono linguaggi molto affermati e usati in questo campo da molti anni.

Stocazzo. La moda non e` un argomento.

>> - SQL/the filesystem (often *both* SQL and the filesystem)

> Bhe'... volendo possiamo usare XML anche qua!

Non ci scherzare troppo, c'e` gente che lo fa davvero. XML (parsato
e/o generato a macchina) su filesystem. Esistono addirittura dei
geniali "database XML" come eXist.
Parlavo proprio oggi con una persona, tutt'altro che stupida, che
ritiene sia la cosa giusta. Il condizionamento sociale inconscio tende
sempre a portare verso il conformismo. Sottile e pericoloso, anche per
il fatto che non c'e` una categoria che spinge attivamente in questa
direzione; e` la gente che impara una soluzione e pensa che sia l'unica
senza neanche porsi il problema. Poi la gente adotta questa soluzione,
la insegna a sua volta, contribuisce a diffonderla. In una comunicazione
a rete in cui si ripete un unico messaggio l'idea trasmessa
-indipendentemente da quanto sia sbagliata- acquisisce forza, e
indebolisce la percezione della plausibilita`, quasi dell'esistenza
delle alternative.
Ma in questa fase i problemi stanno esplodendo, diventando evidenti a
tutti. Per avere qualche possibilita` dobbiamo costruire uno strumento
conveniente da usare, che riduca i tempi di sviluppo e la complessita`.
A quel punto penso che la strada sia in discesa: basta poca esperienza
per riconoscere che una soluzione e` *giusta*; penso sia piu` difficile
riconoscerne una sbagliata.

>> - XML (with DTD, XSLT, XQuery, WSDL...)
>
> Per l'appunto! Figurarsi: Sull' "Oracle Journal" una volata
> spiegavano come estrarre i dati da un DB facendosi dare l'XML
> corrispondente al risultato della query e poi con PHP se lo
> parsavano... Ehi bello mica sono dei coglioni alla Oracle!

Visto che credo nel software libero io nel mio ingenuo ottimismo
ammetto di sperarlo (che siano dei coglioni). Mi rincuori.

>> - CORBA/RMI
>
> Sono un po' macchinosi ma una volta che uno ha imparato ad usarli
> non sono mica male... ti risolvono unsacco di problemi difficili
> (come aprire un socket)

Vero, tranne la parte del socket :-). L'idea centrale infatti mi piace;
sono basati sul modello delle RPC.

>> - A CMS
>
> Cosa hai da dire contro i CMS? :)
> Specie quelli in PHP che si parsano 2 volte lo stesso testo per
> essere visualizzati!

Un CMS fatto bene potrebbe anche essere una cosa utile. Idealmente
non ce ne dovrebbe essere bisogno, visto che dovrebbe essere facile
combinare componenti, sia di calcolo che d'interfaccia, e farli
comunicare per realizzare quelle quattro cazzate che servono. La
realta` e` diversa perche` i CMS sono scritti male ma soprattutto
perche` sono basati su un'infrastruttura completamente sbagliata,
a partire dai linguaggi.

>> - SSL, certificates
>
> Non vorrai mica che il sistemista di turno sbirci quando scarico
> la pornografia da internet!

Certo che no, anzi penso che per il sistemista non deva esistere un
modo di vedere nemmeno con quale server tu sia collegato. Mi sembra
il minimo che anche lui si faccia le sue ricerche come hai fatto tu,
se vuole la tua pornografia :-).
La crittografia e` utile, ma non c'e` motivo per cui debba aggiungere
complessita` all'applicazione.

>> On the client side (at least three of the following ones for
>> most appications):
>> - HTML/XHTML
>
> Ormai HTML e' uno standard affermato e figurati: La maggior parte
> dei browser usa lo stesso motore di rendering.

Vero, quindi e` davvero un gran peccato che HTML vada distrutto e
riscritto. Anche se direi non da me (magari qualcuno di voi :-)),
e non ora.

>> - CSS
>
> Chi ha paura di CSS? e' cosi' intuitivo e pulito che lo puoi usare
> ad occhi chiusi:
> [...]

Seriamente: si`, CSS fa schifo, quasi come HTML. Ma in questa fase
sarebbe bene mantenere la compatibilita`. Gira sul client, e questo
e` un problema che affronti anche tu piu` avanti. Il fatto che
l'utente finale "programmatore web" debba essere esposto direttamente
a tutto questo e` ovviamente un'altra questione.

>> - JavaScript/VBScript
>
> Se voglio fare delle operazioni "evolute" sul lato client ho
> bisogno di potenti linguaggi, ad alta espressivita' e facili da
> usare. ma soprattutto questi linguaggi sono portabili e multi
> piattaforma:

Giustissimo, quindi direi Lisp. Questo e` un problema molto
importante che non ho ancora affrontato, ma ho qualche idea. More
on this to come.

> var request = null;
> try {
> request = new ActiveXObject('Msxml2.XMLHTTP');
> } catch(e) {
> try {
> request = new ActiveXObject('Microsoft.XMLHTTP');
> } catch(ee) {
> }
> }

Che tristezza. Spero che l'autore di questo codice non sia chi penso
io.

>> - Flash/Java
>
> Con i processori che ci sono oggi in giro non ti fara' mica paura
tirar
> su un interprete!

  No, ma mi rifiuto di tirar su un interprete proprietario e di
suggerire (o imporre) ad altri di farlo. Se poi il linguaggio
realizzato dall'interprete (libero) non facesse anche tecnicamente
schifo sarebbe meglio.

>> - XML, this time from JavaScript
>
> E che fai? Te lo parsi a mano? Ma dai non schersare su ste cose
> che ci sono dei "creaturi" che leggono! :)

Curioso, hai proposto la stessa cosa piu` avanti nella parte
in cui parli seriamente, forse senza accorgertene; guarda
quanto e` sottile il confine tra la pratica corrente e l'iperbole
ridicola.

> La maggior parte delle applicazioni sono del tipo: fai il display
> di una form, prendi i dati mandali al server dove fai una query e
> poi mandi tutto indietro al client facendo il display di una bella
> tabella. Non hai bisogno di un gran che' di strumenti.

Giusto, questo e` un caso comune, come dite voi oggettisti un
'pattern'. A proposito dei "pattern" intesi in questo senso e`
interessante quello che si dice qui:
http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures .

L'esistenza di pattern *nel codice* e` un sintomo di astrazione
insufficiente. O e` troppo debole il linguaggio, o e` troppo
debole il programmatore.
La mia opinione e` che una volta riconosciuta l'esistenza di un
pattern il linguaggio debba poter essere *esteso* per supportarlo
in modo da astrarre l'implementazione della soluzione, e renderla
facilmente riusabile (e modificabile: in particolare deve essere
presente una sola istanza dell'implementazione). Come penso di aver
dimostrato in pratica con il pattern-matching (l'uso dei pattern nel
senso che intendo io e` un pattern nel senso che intendi tu) le macro
di Scheme sono uno strumento eccellente in questo senso; non esiste
niente di altrettanto potente in nessun altro linguaggio che conosca.

Per gli scopi di questa discussione, definiamo "stupid-form" il pattern
che descrivi. Noi, in quanto autori dell'infrastruttura, ma anche un
qualsiasi utente che scriva una libreria basata sulla nostra
infrastruttura, potremo implementare la stupid-form in modo che
l'interazione client->server->client sia nascosta. I parametri
dipendenti dall'istanza saranno parametri di una procedura o di una
macro, che consisteranno essenzialmente nei nomi dei campi. Se
riusciremo a fare un buon lavoro con la persistenza e/o l'interfaccia
al DB non ci sara` nemmeno bisogno di specificare una query SQL tra i
parametri. Vedremo a cosa si riuscira` ad arrivare.

> Del resto la maggior parte delle applicazioni e' simile: si fa un
> bel copy and paste e sei a posto: cambi un paio di nomi di variabili
> e poi... anche tu "software engineer" come noi!

Non sei un software engineer, non fingere di abbassare il tuo livello
per sfuggire alla discussione. Non ti ho mai visto usare UML, per
esempio. Mi ricordo di quando parlando degli oggetti mi disegnasti alla
lavagna un omino... *Non* era un attore :-).

> Del resto sono interfacce generate da un linguaggio di alto
> livello tipo XML. Anche se non sono bellissime dove sta il problema:
> sono facili da scrivere!

Ahah. Mmm. No, forse l'interfaccia e` accettabilmente facile da
scrivere. Il problema e` tutto il resto, cioe` la parte difficile.

> Allora... adesso torniamo in modalita' seria e vediamo di
raccogliere le
> idee.

Benissimo.

>> Some of this complexity may be justified by search for
>> compatibility (but even this is often pointless: try to use
>> a recent web application from a browser of ten years ago); but
>> the web was designed for simple static HTML pages ("HT" in
>> "HTTP" stands for hyper-text) and not for complex applications:
>> the result is evident.
>
> Non abbiamo bisogno di andare indietro nel tempo: ci sono
> differenze di visualizzazione tra IE e Firefox! La comatibilita'
> e' una "requirement sperato" dal cliente, che tipicamente non sa
> manco cosa compra.

Giusto, e poi perche` ho scritto dieci anni? Cinque sono gia`
abbastanza.

>> In the long term new reasonable standards should be written,
and
>> compatibility with past protocols and conventions should be
>> discontinued.
>
> Io sono un amante dei tagli netti ma siamo in pochi a pensarla in
> questa maniera: Si veda il caso della programmazione parallela
> strutturata schiacciata a Los Alamos dal peso di $2,000,000,000
> (si, miliardi) in codice HPF ed MPI che deve continuare a girare
> e di tool tagliati per macchine specifiche che fanno l'assunzione
> che il tipico programmatore e' un fisico o un biologo o un
> matematico o qualcos'altro, ma non un informatico.
>
>> An apparently common and possibly well meaning approach is very
>> dangerous:
>> giving higher priority to the simplicity of already simple
cases than
>> to
>> expressivity: "really *anybody* should be able to use this,
even
>> without
>> any knowledge". It doesn't work that way.
>
> Io come amante (diciamo fondamentalista :) ) degli oggetti sono
convinto
> che anche la programmazione debba essere intuitiva: Guidata dalla
buona
> progettazione delle interfacce degli oggetti offerti dal sistema
> sottostante (per un oggetto 'file' mi apettero' sempre un metodo
'open'
> ed un 'close').
> D'altro canto, so benissimo che un sistema intuitivo richiede, per
un
> uso corretto di due cose: 1) esperienza e 2) conoscenza dello
strumento
> per un suo uso efficiente.
>
> 1) L'esperienza e' necessaria per conoscere i modi migliori di
usare uno
> strumento e usarlo nella maniera appropriata, se per fare un
operazione
> ho bisogno di 3 righe di codice non ne devo usare 20. L'esperienza
e'
> anche "nell'intorno" quindi sapere soluzioni furbe ed intelligenti
in
> altri campi possono essere riusate anche per i propri problemi.
>
> 2) La conoscenza dello strumento (in questo caso i suoi internals)
> permette di riconoscere particolari comportamenti e prevedere
> l'efficienza del sistema.
>
>> Social pressure: fashion. Everybody does it that way, can they
all be
>> wrong?
>> They can.
>
> Milioni di mosche non potranno mica sbagliarsi!
>
>> Over-engineering. Might it have some superficial appeal for
people
>> with very empty lives?
>
> Ho un paio di esempi in mente ma vorrei trattenermi.
>
>> However most problems are due to simple incompetence. Web
programming
>> is programming, and programming is hard. Let's leave it to
people able
>> to do it.
>
> Sante parole!
>
>
>> The right solution
>> ------------------
>>
>> A web application is made of several "services", i.e.
distributed
>> processes
>> exchanging messages. In nearly all cases the simplest style of
>> communication
>> is required: synchronous messages. An RPC interface should be
used,
>> possibly
>> augmented with some form of asynchronous RPC, for
non-functional
>> interfaces.
>
> Se ho capito bene la tua proposta e' quella di creare dei sistemi
di
> programmazione distribuita in grado di scambiarsi messaggi in
maniera
> semplice ed intuitiva.
>
> Il sistema RPC da te proposto, cito la mail con il Golfarini:
((rpc port
> f) parametro-1 ... parametro-n), e' molto semplice (dal punto di
vista
> dell'uso) ma ho delle puntualizzazioni:
>
> - Per un sistema server<->server e' l'ideale, in quanto
tutti i servizi
> sono acceduti in maniera omogenea. Una cosa buona sarebbe quella
di dare
> una generica idea di "funzione" la cui invocazione viene passata al
> run-time (e a chi altri?) e quest'ultimo decide se fare una RPC o
una
> LPC. Io devo poter ignorare il fatto che la funzione sia remota o
> locale. Pero' ci serve un modo semplice ed intuitivo per
> specificare/trovare le funzioni discriminando fra quelle locali e
quelle
> che non lo sono. Volendo un run-time distribuito fra i server
sarebbe
> l'ideale.
>
> - Per un sistema client<->server ho delle perplessita'. In
questo caso
> avremmo delle vere e proprie applicazioni distribuite. Un pregio
delle
> applicazioni web e' che queste possono essere "distribuite"
facilmente:
> ho un client (IE, Firefox...) lo accendo mi collego all'indirizzo
> pinco.palla e va. Una buona soluzione potrebbe essere quella di
avere un
> environment dinamico che si collega al server e inizia a
modificarsi in
> modo da diventare l'applicazione che vogliamo. Ma sara' semplice
> abbastanza da programmare?
>
> - Per un sistema client<->server che voglia usare i vecchi
browser si
> potrebbe progettare l'environment di cui sopra in modo che venga
> eseguito dal browser: Pensiamo un attimo al client che si connette
e che
> scarica un file, ad esempio js, che e' il motore di
interpretazione del
> nostro sistema. A qusto punto dovremo essere in grado di generare
> l'interprete in maniera automatica ed il server dovrebbe essere in
grado
> di capire le richieste http che fa sia il browser per connettersi
che
> quelle che fa il js tramite il browser medesimo. Le risposte
ovviamente
> dovrebbero essere capibili da js e quindi cari miei XML ed HTML ci
> toccano: pero' potremo generare tutta sta bella roba in maniera
> automatica. Useremo i metodi di Ajax senza scriverne una riga che
sia una!
>
> - Il sistema di memorizzazione ortogonale mi piace molto in quanto
> permette di evitare l'uso di dati strutturati come i tradizionali
DB.
> Una opportunita' interessante e' quella di avere un sistema di
> "ibernazione" distribuito: lo stato dei vari pezzi del sistema e'
> salvato e/o puo' essere salvato in modo che l'applicazione diventi
in
> un certo senso un input per una sua futura esecuzione.
>
> Ciao a tutti!
> Francesco
>
> ps: il subject della mail e' da considerarsi quasi casuale :)
>

La mia lista personale di categorie da cancellare dopo la rivoluzione:
- notai
- sommelliers
- avvocati