Newsgroup: it.scienza.informatica
Titolo: Linguaggi di programmazione.

Sono uscito dall'universita` "ormai" da 6 anni e dato che l'informatica ha
una evoluzione molto veloce probabilmente le mie vedute sono "gia`"
antiquate (incredibile vero?).
Chiedo allora ai laureandi o neolaureati in ing. informatica quali
linguaggi o filosofie di sviluppo sono da considerarsi attualmente le piu`
moderne.
Grazie 1000.

 Grazie 1000.
Prego 1k.
  AO.


E in 6 anni non hai ancora capito che le filosofie più moderne sono 
quelle che nelle università nessuno ha mai sentito nominare e che una 
importante differenza fra un neo-laureato e un laureato che si tiene 
informato è che il primo non ha la minima idea di quali siano i 
linguaggi e le filosofie di sviluppo più moderne?
Comunque la domanda è troppo generica. Dovresti perlomeno individuare un 
ambito. C'è una grossa differenza fra lo sviluppare, ad esempio, 
firmware e sistemi di controllo e lo sviluppare, sempre per esempio, 
"groupware oriented network-based application".

 gusti :)
La sensazione è che gli sviluppi più interessanti stiano avvenendo a 
livello di Networked Application. Per esempio una cosa che pur essendo 
"vecchia" sta esplodendo in questi mesi è Ajax.
Un'altro punto di grosso fermento gravita intorno al Duck Typing e al 
linguaggio Ruby. La mia sensazione è che si sia vicini a un piccolo 
paradigm-shift simile al movimento che, partendo da Smaltalk, ha portato 
all'OOP, ai Pattern, e all'XP.
Per il momento il più significativo risultato ottenuto è Rails. Ma la 
sensazione è che sia solo un punto di partenza che potrebbe portare a 
molto di più (cioè molto al di la di una applicazione, con influenze 
anche nell'engineering e nei paradigmi).
Le keyword da tenere a mente, secondo me, sono: Duck Typing, Test Driven 
Programming e Extreme Programming, Programming By Convention.

 linguaggi e le filosofie di sviluppo più moderne?
Poi ci sono anche gli studenti che si tengono informati e che a causa di
questa loro "curiosita'" su argomenti che esulano dai corsi universitari
finiscono con il laurearsi con un bel po' di ritardo...
mica puzza troppo di alibi 'sta cosa che ho detto, no? :)
Ciao,
   AO.


Quando parli di questo paradigm-shift che vedi, ti riferisci alla tendenza ad
usare sempre piu' i linguaggi "debolmente" tipati?
Grazie per gli spunti,
   AO.

AO wrote:
 > Il 2006-04-28, AnalogFile <ne...@NOSPAMkuva.itREALLYNO> ha scritto:
...
 > Mi sentirei quindi di aggiungere fra le "innovative" quelle tecniche 
che hanno
 > come motto: "far scrivere il meno possibile codice agli essere umani" 
e dunque
 > le tecniche di generazione automatica del codice sorgente, o quei 
metodi, che
 > ho solo sentito nominare, di verifica di correttezza dei programmi 
(ma qui
 > sforiamo nello sperimentale? forse e' di scarso interesse per questa
 > discussione specifica).
In prima media presi alcune lezioni da un ragazzo che si stava laureando 
a Milano con una tesi sulla generazione automatica del codice (mi 
incuriosii, gli chiesi di leggerla, mi incuriosii di più e gli chiesi un 
testo che spiegasse quello strano formalismo che usava e che si chiamava 
LISP. Non mi sono più fermato).
Sono nato nel 1966. Fai i conti.
I metodi per il completo test automatico (prova della correttezza) sono 
stati di moda (così come quelli per la generazione di programmi) molti 
anni fa. Soprattutto come canto del cigno per quelli che pochi anni 
prima consideravano l'intelligenza artificiale la soluzione finale.
In termini industriali le applicazioni sono sempre state piuttosto scarse.
Oggi direi che vengono considerati più interessanti metodi per la 
scrittura veloce di codice con pochi errori (per esempio l'extreme 
programming) e per il riutilizzo di codice (aspect programming). Ma la 
mia sensazione è che anche questi siano solo dei possibili modi per 
lavorare, non dei silver bullet.
 >> Un'altro punto di grosso fermento gravita intorno al Duck Typing e al
 >> linguaggio Ruby. La mia sensazione Ãš che si sia vicini a un piccolo
 >> paradigm-shift simile al movimento che, partendo da Smaltalk, ha 
portato
 >> all'OOP, ai Pattern, e all'XP.
 >>
 >
 > Quando parli di questo paradigm-shift che vedi, ti riferisci alla 
tendenza ad
 > usare sempre piu' i linguaggi "debolmente" tipati?
Non proprio. Il vantaggio di linguaggi "debolmente tipati" è conosciuto 
da tempo. L'OO nasce come debolmente tipizzata. La sua impraticabilità 
in contesti in cui serve (o si spera di poter ottenere) la verifica 
formale della correttezza, lo sviluppo di C++ e l'affermarsi di 
formalismi di modellazione (3 dei 5 più importanti poi confluiti come 
sappiamo in UML) hanno poi "allontanato" questo aspetto dall'attenzione 
della massa.
La verifica formale della correttezza di fatto non si è mai raggiunta (o 
almeno non in sistemi complessi come quelli in cui si voleva 
utilizzarla). Ci si limita ad utilizzare l'ADA e a dei massicci code 
review (ma non sempre questo basta come dimostrano l'Ariane V, i 
problemi con i patriot usati nella prima GdG e altri interessanti 
"incidenti").
Il riutilizzo del codice (a parte i tentativi, che vedremo come 
andranno, legati agli aspect) avviene oggi principalmente tramite i 
"framework". Ma la realtà è che la cosa avviene solo quando il framework 
copre un sottosistema intrinsecamente ipercomplesso. Al punto da rendere 
l'utilizzo dello stesso l'unica alternativa percorribile. E anche chi lo 
usa ne farebbe volentieri a meno. Il caso più eclatante sono le MFC.
L'espressione massima dell'extreme programming (e anche dei pattern e di 
altre cose più o meno fondamentali dell'informatica moderna) è ancora 
oggi legata al mondo di smalltalk. Ma il movimento
FOSS sta dimostrando che in alcuni ambiti un linguaggio a binding 
dinamico e non fortemente tipizzato è superiore. E' anche più facile da 
imparare. Ed è molto più produttivo. Python, con il suo sforzo verso la 
leggibilità, è vincente ovunque vincoli prestazionali o di portabilità 
non impongano il C/C++ o vincoli di piattaforma (esecuzione nel browser) 
non impongano JavaScript.
Ruby è un linguaggio invero abbastanza vecchio. Ma solo 
recentissimamente è uscito dai confini del Giappone. Ma sta rapidamente 
diventando importante. Deve moltissimo a Smalltalk e parecchio anche a 
Perl (forse un pochino troppo, come ammette lo stesso Matz).
Non solo è debolmente tipizzato e utilizza il binding dinamico, è anche 
interpretato (è in sviluppo il supporto per la compilazione JIT) e ha 
una sintassi semplice e con alcune convenzioni che lo rendono molto 
flessibile. Si possono fare cose impossibili in molti altri linguaggi (o 
possibili ma difficili da implementare). Il primo vero esempio di 
utilizzo massiccio delle caratteristiche di Ruby unite non solo al Duck 
Typing ma anche ad altri principi quali DRY (do not repeat yourself) e 
Progreamming By Convention lo troviamo in Rails. Rails è un framework, 
una killer application e qualche altra cosa, a seconda dei punti di 
vista. Ma Rails ha degli "elementi costitutivi" che possono essere usati 
anche al di fuori di Rails stesso. Come per esempio ActiveRecord.
Nella seconda metà degli anni 80 e per buona parte degli anni 90 era 
chiaro che i principi emergenti erano l'OOA/OOD e l'OOP. La "morte" di 
COBOL e FORTRAN e l'avvento di C e C++ si sentivano nell'aria. In 
background Smalltalk da un lato e linguaggi a paradigma funzionale (LISP 
e derivati) dall'altro. Nel 95, con internet oramai una realtà, si 
cominciava ad intravvedere la "rivoluzione" che sarebbe stata portata da 
XML e Java. Ora, a metà della prima decade del nuovo millennio, la mia 
sensazione è che C resiste ovunque le performance sono fondamentali (con 
C++ che ha perso molta importanza ma che resiste come alternativa a C o 
come "better C"). Java (o meglio JavaScript) resiste come browser 
language anche per mancanza di alternative portabili (VBScript è in via 
di estinzione tranne che per applicazioni intranet e C# non è ancora 
affermato, ma MONO potrebbe cambiare questo aspetto del problema). Sul 
lato server scripting c'è ancora molto Perl e Bash, ma Python e Ruby 
stanno emergendo. E per il Web le CGI (una volta molto di moda) sono in 
agonia, vanno forte Java, Perl e PHP, con Python e Ruby in forte ascesa.
La "moda" attuale è l'introduzione di AJAX. Il timore principale è che 
venga utilizzato troppo e a sproposito, andando a ledere i principi che 
hanno reso HTTP il successo che è (fra cui il fatto di essere stateless, 
che è una sua forza e non una sua debolezza).
Ma si sente odore di cambiamento. E DRY è una delle parole chiave. 
Seguita da Programming By Convention che è il suo principale enabler. 
Pensa a ActiveRecord. Quando hai "disegnato" il database e ne hai creato 
le tabelle hai dovuto specificare i nomi delle varie colonne (campi). 
Ora devi scrivere il programma che usa il database. Se nel programma 
devi specificare il nome delle colonne (o devi dichiarare i metodi per 
accedervi, o i membri che terranno la copia in-memory dei valori) allora 
non sei DRY. Perchè quelle cose le hai scritte già nel database. Non ha 
senso ripeterle.
Guarda questo codice:
class Person < ActiveRecord::Base
end
Supponendo che da qualche parte ActiveRecord sia stato inizializzato e 
gli sia stato indicato un database (con nome e password per accedervi), 
quel codice tutto quello che serve per accedere alla tabella chiamata 
"people" nel database.
p = Person.new
p.name
 = "Analog"
p.surname = "File"
p.age = 39
p.save
Creato un nuovo record nel database. I campi name, surname e age sono 
stati valorizzati, il campo id ha assunto un valore univoco, eventuali 
altri campi sono NULL. Nessuna necessità di dichiarare il nome dei campi 
o dei metodi o dei membri della classe. Tutto automatico. Il campo id 
non viene neppure menzionato! Il codice SA GIA' come è fatto il 
database. Perchè queswte info si trovano nel deatabase stesso. La 
creazione di variabili membro e metodi per accedervi avviene 
automaticamente (e anche il tipo delle variabili viene "estratto" dal 
database).
Supponi di voler aggiungere un nuovo campo alla tabella. Basta un "alter 
table" sul database. Il codice del programma si aggiorna da solo (se non 
altro perché il codice del programma NON C'E').
La totale riflessività dei metadati del linguaggio, il binding dinamico, 
la possibilità di creare codice a runtime, la possibilità di cambiare il 
tipo (la classe) di un oggetto DOPO averlo creato e altre cosette come 
queste, stanno aprendo la strada a possibilità espressive che fin'ora 
richiedevano un complesso front-end di generazione del codice. E' quasi 
possibile definire dei "mini linguaggi" specifici per una applicazione 
utilizzando Ruby stesso come interprete.
Tutto questo verrà osteggiato molto dai teorici. Questo tipo di 
applicazioni NON PUO' essere modellato ne in UML ne in altri formalismi 
attuali. Ma i pratici e i pragmatici sposeranno la tecnologia a frotte.
Questo non significa che Ruby (o Rails) siano il silver bullet. Sono 
solo pionieri. Forse avremo un altro linguaggio (o molti altri 
linguaggi) che supporteranno la parte migliore dei nuovi paradigmi che 
stanno emergendo. E forse avremo nuove metodologie di analisi e design.
Oppure ci sarà qualche cosa di totalmente nuovo. L'OO è nato negli anni 
70. Era solido e utilizzabile (e utilizzato) già all'inizio degli 80. E' 
diventato mainstream a metà degli anni 90. I concetti che stanno 
emergendo ora sono già vecchi di 10 anni. Ora sono solidi e vengono 
utilizzati. Forse richiederanno altri 10 anni per diventare mainstream 
(e per essere citati nelle nostre università).

Il 2006-05-01, AnalogFile <ne...@NOSPAMkuva.itREALLYNO> ha scritto:
un bel po' di cose.
Volevo solo ringraziare, e' stata una lettura ricca ed arricchente,
senza dubbio.
Ciao, AO.

 Ed è molto più produttivo. 
Come sopra, fermo restando che fatico a vedere la produttività come un 
aspetto tecnico (per quanto sia al giorno d'oggi -purtroppo- fondamentale).
Ciao.

 aspetto tecnico (per quanto sia al giorno d'oggi -purtroppo- fondamentale).
Curioso, per uno che difende Python, dire che fatichi a vedere la 
produttività come un aspetto tecnico. Fra i linguaggi più diffusi Python 
  è proprio quello che si distingue per avere leggibilità e produttività 
fra le priorità del design del linguaggio.



Io ho una visione per il futuro...
Nel passato, siamo stati abituati tutti, programmatori e utenti finali a
concepire il "software" come un qualcosa di pacchettizzato da installare
sul proprio PC, sul proprio server o workstation del quale nel bene o nel
male ci si doveva occupare (aggiornamenti, backups ecc...).
Fortunatamente l'incubo sta per finire, nel prossimo futuro i "programmi"
gestionali in primis gireranno in remoto su server dedicati che
garantiranno l'High-Availability implementando politiche di
Disaster-Recovery che certo non sono alla portata di aziende medio-piccole.
Quindi si passerà dai prodotti "software" ai servizi "software" che
integreranno tutto server(hardware e software) sistemi automatici di
replica dei dati sensibili, ecc..
In pratica meno sbattimento per gli utenti e maggior lavoro lato server.
Io punto tutto sul LAMP e relative implementazioni AJAX che in pratica si
potrebbero condensare in MySQL, PHP, Javascript, CSS, XML, HTML.

 replica dei dati sensibili, ecc..
ma questo non lo avevamo gia' nel 1964?
-- 
"...non potresti desiderare di essere nato in un'epoca migliore 
di questa, in cui si e' perduto tutto..."         S.WEIL

 ma questo non lo avevamo gia' nel 1964?
Si. Ma:
1) l'interfaccia era text-based
2) dovevi avere un cavo diretto dal tuo terminale al server (e se volevi 
usare tre server, dovevi avere tre terminali e tre cavi)
3) si pagava per "tempo CPU"
4) mettere su un server costava quanto un palazzo di 5 piani in centro 
Milano
oggi:
1) l'interfaccia è grafica e persino a colori
2) puoi usare una connessione ad internet e connetterti a milioni di 
server da un unico terminale
3) si paga flat
4) se hai un servizio che vuoi offrire puoi permetterti di farlo dato 
che un buon server costa poche migliaia di euro al mese

 che un buon server costa poche migliaia di euro al mese
VERAMENTE???  :-)
