Newsgroup: it.comp.programmare
Titolo: Esiste un motivo, oggi, per non avere linguaggi "grandi"?

Ciao,
in questi giorni sto rispolverando PHP e pure un pò di Java, e durante 
questa domenica di pausa ho riflettuto sulla gran quantità di funzioni 
di libreria che questi linguaggi hanno: Java moltissime, il PHP molte 
meno, il C e il C++ fra libreria standard e STL pure loro un bel pò; il 
Turbopascal all'epoca con le sue unit aveva anche lui la sua pletora di 
funzioni "esterne" ecc. ecc.
Per quanto ne so e ne conosco, tutti i linguaggi usati per programmare 
praticamente si ritrovano con centinaia di funzioni "di libreria" che 
seppure non parte del linguaggio lo accompagnano invariabilmente nel suo 
uso pratico: sostanzialmente non è pensabile scrivere un programma 
appena complesso senza usare funzioni di libreria, in qualsiasi 
linguaggio che io conosca (se ce n'è uno che invece se la cava bene 
anche senza librerie, sono curioso di conoscerlo).
Questo è fatto per avere un piccolo nucleo di keyword del linguaggio, 
suppongo, estremamente portabile e compilabile da un compilatore 
"semplice" in un tempo decente.
Ma questo è ancora necessario??? Voglio dire, con i popò di computer che 
ci ritroviamo sotto le scrivanie, non sarebbe più logico e pratico avere 
un linguaggio con alcune migliaia di keyword e senza librerie di 
sistema, ovvero integrare le librerie di sistema all'interno del 
linguaggio stesso? La maggiore complessità del compilatore e lentezza di 
compilazione verrebbe ripagata da un controllo semantico molto più 
accurato, una migliore gestione degli errori, eseguibili più compatti. 
Certo, un programmatore finirebbe per non conoscere bene tutte le 
keyword del linguaggio che usa, ma d'altra parte non è che anche oggi i 
programmatori conoscano a menadito TUTTE le librerie dei loro linguaggi...
PHP segue, più o meno, proprio questa strada: vabbè che è un linguaggio 
di scripting e che pure lui ha delle librerie caricate dall'interprete, 
però è un passo nella direzione di cui parlo.
Qualcuno ha mai posto o affrontato questo argomento, della "grandezza" 
sintattica/semantica di un linguaggio? Ci sono delle conclusioni che 
sono state tratte in un senso o nell'altro?

Cosa cambia ? inoltre per esempio nel C il sistema degli #include e 
relative librerie ti permette di non portarti dietro negli eseguibili 
ciò che nn utilizzi  ..... che vantaggio avresti da una struttura 
monolitica  ?
ciao
PP


 monolitica  ?
Cambia che, appunto, il compilatore potrebbe intervenire più 
efficacemente sugli errori, perchè potrebbe inferire molte più 
informazioni a partire da dove le variabili sono usate, essendo gli 
argomenti delle funzioni di tipo obbligato: come minimo i messaggi di 
errore del compilatore sarebbero molto più precisi e descrittivi.
Cambia che un linguaggio "grande" permetterebbe al compilatore di 
ottimizzare il codice molto più di adesso, o addirittura di fare cose 
che ora non sono nemmeno immaginabili, perchè in base alle funzioni 
chiamate (e che il compilatore ora conosce interamente) acquisterebbe la 
capacità di capire "cosa fa" il codice che sta compilando, e regolarsi 
di conseguenza. Tutte le varie opzioni di compilazione potrebbero 
diventare superflue.
Cambia che un sorgente di quel linguaggio sarebbe portabile molto più 
facilmente, perchè avresti già nel linguaggio tutto quello che ti serve 
e non dovresti preoccuparti se str**cmp o sa Dio cosa sia presente su 
quel S.O./compilatore o no.
Cambia che ti porteresti dietro ancora meno roba del caso delle librerie 
esterne: per esempio se di time.h ti serve solo una funzione, 
includendola ti porti comunque dietro TUTTE le funzioni della time.h e 
non solo una. Invece, se le funzioni di libreria fossero keyword del 
linguaggio, ti porteresti dietro solo ed esattamente il codice che ti 
serve, e non altro.
Cambia, per ultimo, che il sistema degli #include sarebbe molto meno 
necessario, semplificando il codice.

 meno necessario, semplificando il codice.
Anche linguaggi che avevano fatto a meno degli #include li hanno 
introdotti (C# consente di splittare il codice della classe in più 
file). Il problema degli include, al limite, consiste nel recuperare 
le definizioni dei vari simboli, ma un buon sistema di browse lo 
risolve senza tirare in ballo il compilatore.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 serve, e non altro.
Quindi sarebbe un linguaggio assolutamente non espandibile.
Non e' una bella cosa.

 sono state tratte in un senso o nell'altro?
Più è semplice il linguaggio e autocontenuto più è facile apprenderlo.
Python è sempre stato un linguaggio facile e affrontabilissimo. Le
keywords aggiunte negli ultimi 3 anni l'hanno sicuramente reso più
complesso ma non più di tanto. La forza del C è che la sua sintassi si
impara in un pomeriggio, la complessità è usarlo. Sbattendo le syscall
nel linguaggio quel pomeriggio diventerebbe un mese e non diminuiresti
di certo la difficoltà di usare il C.
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier


Mi sembra di capire che ciò che tu cerchi è avere un DSL (Domain
Specific Language) per ogni libreria disponibile. Questo è già
possibile, e molti linguaggi e librerie lo supportano permettendo di
avere un controllo degli errori migliore (ad esempio stai creando un
html tramite un'api del tuo linguaggio e il compilatore si accorge di
un <li> fuori da una lista).
Se vuoi un controllo degli errori a compile-time specializzato per il
tuo dominio applicativo/libreria è necessario soltanto che il tuo
linguaggio ti fornisca lo strumento sintattico per costruire tale
controllo (ed ovviamente tu devi sperare che qualcuno scriva le
librerie usando queste feature!).
Il linguaggio imho deve soltanto avere gli operatori che ti permettono
di creare/combinare le astrazioni (sui dati e sulle procedure) che
preferisci. Insomma non hai bisogno di un martello grande ma di un
grande martello (non potevo resistere!).