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

[nids]

Cari tutti,

Allora vi scrivo questa mail in veste di avvocato del diavolo
dell'attuale sistema di programmazione web commentando il documento
MANIFESTO.

> Flaws of the common web programming style
> -----------------------------------------
> Web programming as it's usually done has several very serious flaws:
>
> 1) inefficiency: Current web applications are slow and
> resource-hungry. Processes and even virtual machines with high startup
> time are continuously spawned and killed. HTTP connections even in
> local. XML used for everything."

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".

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

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?

> 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.

>       - Java/Perl/Python/PHP/JSP/ASP

Sono linguaggi molto affermati e usati in questo campo da molti anni.
Che centra se la maggior parte di questi non sono nati per fare
applicazioni web? (Java per le set-top box, perl per il processing di
testi e python per sport :) )

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

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

>       - 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!

>       - 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)

>       - A CMS

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

>       - SSL, certificates

Non vorrai mica che il sistemista di turno sbirci quando scarico la
pornografia da internet!

>     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.

>       - CSS

Chi ha paura di CSS? e' cosi' intuitivo e pulito che lo puoi usare ad
occhi chiusi:

table {
        padding-right: 11em;
        border-width: 1px 1px 1px 1px;
        border-spacing: 0px 0px;
        border-style: solid solid solid solid;
        border-color: #FF6600;
        border-collapse: collapse;
        background-color: white;
}
table th {
        padding-right: 11em;
        border-width: 1px 1px 1px 1px;
        padding: 0px 0px 0px 0px;
        border-style: solid solid solid solid;
        border-color: #FF6600;
        background-color: white;
        -moz-border-radius: 0px 0px 0px 0px;
}
table td {
        border-width: 1px 1px 1px 1px;
        padding: 0px 0px 0px 0px;
        border-style: solid solid solid solid;
        border-color: #FF6600;
        background-color: white;
        -moz-border-radius: 0px 0px 0px 0px;
}

solo per definire una tabella! Figurarsi, a guardarlo cosi' deve essere
TC: Ha anche i campi negativi ("-moz-border-radius")!

>       - 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:

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

nel caso ci metti un if o un try e festa finita!
[codice gentilmente in presito dal toolkit per ajax fornito agli
studenti di PA --- http://medialab.di.unipi.it/web/AP/TermFinal05-dec.doc ]

>       - Flash/Java

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

>       - 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! :)

>  Most code deals with translation of data from a format to another.
>  There's much interface code, and very little useful computation; that
>  very little is obscured by the rest, and difficult to follow.
>  Web applications are hard to debug. Their output is spread across a
>  multitude of log files. Often there's no direct way to see error
>  messages.

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.

>  Most of the above tools are badly designed beyond any possibility of
>  repair. Many of them are used even when they don't solve any problem.
>  The code for web applications is always *ugly*. It doesn't even look
>  like concurrent programming.

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!

> 3) user interface weakness:
>  Graphic web interfaces are limited by the quirks of HTTP forms.
>  Overcoming them requires complex JavaScript, Java or Flash code.
>  Such solutions are often proprietary, not portable, and
>  inaccessible
>  to disabled users. Web interfaces "feel" worse than any common
>   graphical user interfaces.

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!

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

> All such problems are essentially instances to one single mistake:
> - using the wrong tool.

E qui siamo tutti d'accordo. HTML non e' piu' sufficiente e ci serve
qualcosa che possa dare la possibilita' di costruire web/distributed
applications in maniera semplice e pulita.

> Causes
> ------
>
> 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.

> 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 :)

-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"The best way to predict the future is to invent it."
-- Alan Kay
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=