Newsgroup: it.comp.lang.c++
Titolo: Che ne pensate di...

Ciao,
il mio nome è Benedetto a sono uno studente di Matematica.
Da un pò di tempo con i miei professori di Informatica stiamo
riflettendo sulla possibilità teorica di realizzare un compilatore con
queste caratteristiche:
- un programma sorgente è compilato per la prima volta e delle
informazioni sono memorizzate.
- successive modifiche al detto sorgente possono venire gestite cosicché
solo una piccola porzione di codice è ricompilata, e il codice generato
è propriamente inserito nel file precedentemente compilato.
Per piccola porzione intendo una funzione, uno statement o meno!
Il design e l'implementazione di questa idea costituiscono ovviamente un
lavoro non triviale, ciononostante può essere fatto.
Le successive ricompilazioni sono stimate impiegare 1 decimo di secondo
o meno.
Le mie prime domande per voi, che sicuramente conoscerete molto bene i
tradizionali compilatori e sistemi di sviluppo, sono:
Domanda 1- Può questo tipo di compilatore essere utile a voi ed al
vostro tipo di lavoro?
Domanda 2- Usereste questo tipo di compilatore "incrementale" o "real
time" nel vostro lavoro?
Domanda 3- Quali altre funzionalità questo tipo di compilatore dovrebbe
avere secondo voi?
Qualche tempo ebbi la fortuna di parlare con il direttore della
divisione "Ricerca e Sviluppo" di una grande azienda di compilatori (per
inciso, Borland International).
Gli dissi della possibilità di costruire (con un "pò di lavoro") questo
tipo di compilatore e lui mi rispose "Perché dovremmo costruire questo
compilatore "incrementale" quando abbiamo computer sempre più veloci e
più potenti?"
Io capisco che compagnie come Microsoft, Borland, ..., e specialmente
Intel, non gradiscano software potenti come il suddetto compilatore che
non hanno bisogno di processori veloci su cui girare.
Domanda 4: Perché dovremmo comprare un nuovo processore quando il nostro
compilatore impiega un decimo a compilare sorgenti normali e mezzo
secondo per quelli grandi?
Ancora, non potremmo usare il tempo guadagnato durante la compilazione
per cose tipo l'ottimizzazione (tanto cara alle compiler-companies!) o
per compilare linguaggi più potenti e più ricchi?
Domanda 5: Potete immaginare che tipo di ottimizzazione il compilatore
potrebbe fare nelle decine di secondi guadagnati? Io non penso di
farcela!
Siamo veramente così assuefatti alla mentalità di obsolescenza da non
riconoscere nuove e interessanti tecnologie? da addirittura non
prenderle affatto in considerazione?
Vi ringrazio di cuore del tempo che avete dedicato a questa idea.
Apprezzerò molto ogni tipo di commento vogliate fare a questi problemi;
potete rispondere liberamente a questa newsgroup.
Ciao.
Benedetto
bene...@altavista.net

vostro tipo di lavoro?
No.
I programmatori con un minimo di intelligenza non usano file lunghi
decine di kb e quindi a compilarne uno ci vuole comunque un attimo.
Per inciso ho forti dubbi che la cosa che proponi di fare sia fattibile,
se non altro perche` bisognerebbe comunque rifare da capo tutte le
ottimizzazioni.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]    | Be happy.
Marco | What was you username again? <clickety clickety click> | Be root.
      | Linux: be your own luser!
      | Visitate #linux-it su 
irc.openprojects.net

 vostro tipo di lavoro?


 prenderle affatto in considerazione?
Il mercato purtroppo ha la sua logica (totalmente opposta alla mia,
comunque).
EMG

 
bene...@altavista.net
Una curiosita': la vostra idea e' di realizzare un compilatore "da zero"
o modificare i sorgenti di uno gia' esistente ?
***
Come idea sembra buona .... mi chiedo piu' che altro se la soluzione non
sia troppo onerosa, tanto da vanificare i possibili benefici (?:-7
Ciao, U D A.
-- 
<><><><><><><><><><><><><><><><><><><><><><><><
UDA'Software
mailto:
u...@freemail.it
mailto:
uda.so...@iol.it
http://www.GeoCities.com/SiliconValley/Bay/2165

 o meno.
Non credo che da questo tipo di approccio se ne ricaverebbe un
vantaggio pratico: probabilmente non avete considerato tutti i
problemi e la gestione delle modifiche al codice. Il risultato
pratico e' una riduzione della velocita' di compilazione.
La cosa che puo' essere interessante, invece, e' la precompilazione
degli header: da quanto ne so Corel aveva fatto un accordo con Cygnus 
per aggiungere questa feature a gcc (ad uso di wine e del porting
delle applicazioni office).
Se ne avete la possibilita', date una mano a questo progetto.
lupus
-- 
-----------------------------------------------------------------
lu...@debian.org
                                     debian/rules

 
Su questo hai perfettamente ragione: le ottimizzazioni vanno ripensate,
o per lo meno gestite in un altro modo.
Ti faccio una domanda:
ipotizza che tale compilatore possa ricompilare singoli statement
modificati, e possa individuare nel sorgente tutti gli statement che
devono essere ricompilati perché potrebbero assumere altri significati
dopo la modifica (ciò si estende anche a statement di altri file, come
nel caso di modifiche ad headers), si hanno due possibilità per le
ottimizzazioni:
1- Si studia come la ricompilazione di singoli statement influisca su
ogni singola ottimizzazione.
2- Si riottimizza ex-novo tutta la funzione dove uno statement è stato
ricompilato.
Ora, se la prima ipotesi potrebbe avere dei tempi di esecuzione
velocissimi, è ovvio che il lavoro che richiede è enorme sia dal punto
di vista teorico che di implementazione; d'altro canto la seconda
ipotesi è facile da realizzare e non è poi così dispendiosa...
Ribadisco il concetto che tutto il tempo guadagnato (anche se fossero
"solo" pochi secondi) potrebbe dare al compilatore la possibilità di
ottimizzare drasticamente il codice!
Cosa ne pensi?
Ciao e grazie!
Benedetto
bene...@altavista.net

 Ciao, U D A.
E' sicuramente un'idea su cui bisogna lavorare molto, soprattutto perché
non è stato fatto nulla o quasi in questo campo.
L'unica eccezione è il brevetto US 5204960 di Microsoft chiamato
"Incremental Compiler" che è poco più di:
- lasciare spazi "bianchi" nell'object file alla fine di ogni funzione.
- se si cambia il corpo di una funzione la si ricompila e si sivrascrive
il codice su quello vecchio della stessa funzione: se bastano gli spazi
"bianchi" bene altrimenti si ricompila daccapo!
Tutto ciò e non avvengono errori, se non ci sono macro "strane" (tipo
__LINE__, __FILE__ etc..), se non si aggiungono troppi simboli
(dimenticavo, anche la symbol table sull'object file ha degli spazi
bianchi che poi vengono riempiti).
Non considero tale brevetto una innovazione tecnologica: non hanno
lavorato alla logica di base del processo di compilazione e non hanno
fornito innovazioni teoriche.
In definitiva non saprei dire se la soluzione sia o meno così onerosa da
vanificare i benefici, non avendo nessuno lavorato su questa idea non ho
punti di riferimento.
D'altronde, sappiamo sempre cosa troviamo quando iniziamo un nuovo
lavoro, un nuovo progetto o cambiamo qualcosa nella nostra vita?
Non è lo spirito di ricerca che spinge avanti l'uomo e che ci ha fatto
scoprire e creare un sacco di cose?
Scusate questo slancio romantico, ma d'altronde siamo uomini oltre che
sviluppatori!
Ciao e grazie
Benedetto
bene...@altavista.net

 Microsoft 1999
Non mi sembra un grosso problema...
Voglio dire che se cambi qualcosa dentro un blocco #if .. #endif
precedentemente non compilato non cambia nulla; se il blocco era stato
compilato ti comporti come una compilazione incrementale "normale"; se
la modifica avviene nella clausola dell'#if vedi se è cambiata o no
rispetto a prima e ti comporti di conseguenza.
A proposito, anche considerando il vostro brevetto US 5204960 (che,
senza offesa, non è il massimo dell'innovazione tecnologica ed ha un
sacco di punti deboli [leggi: ricompila tutto un pò troppo spesso!]), la
Microsoft sarebbe interessata ad una tecnologia del genere? 
Ritieni che sia commerciabile e che possa dare un apprezzabile vantaggio
sulle aziende rivali?
Una battuta: quanto pagherebbe Microsoft per un brevetto del genere?
Con un buon team di lavoro forse anche in due anni si può fare,
sfruttando le nostre ricerche.
Ti ringrazio per la risposta, fammi sapere!
Ciao
Benedetto
bene...@altavista.net

 Il risultato pratico e' una riduzione della velocita' di compilazione.
Perché?
Si ricompilerebbe solo una parte, solo quella influenzata dalla
modifica.
Ciao e grazie per le tue idee.
Benedetto
bene...@altavista.net

 EMG
Ti ringrazio moltissimo per le tue opinioni, spero di risentirti presto.
Ciao
Benedetto
bene...@altavista.net

 writes:
   Il design e l'implementazione di questa idea costituiscono ovviamente un
   lavoro non triviale
triviale ???!!???

secondo per quelli grandi?
Perche` sul mio Pentium ci impiega 3-4 secondi. E non comprero` certo un 
processore nuovo per portarlo a 1 secondo.
-- 
Ciao, Andrea

Ciao Benedetto Proietti,
 > - un programma sorgente è compilato per la prima volta e delle
 > informazioni sono memorizzate.
 > - successive modifiche al detto sorgente possono venire gestite cosicché
 > solo una piccola porzione di codice è ricompilata, e il codice generato
 > è propriamente inserito nel file precedentemente compilato.
 > Per piccola porzione intendo una funzione, uno statement o meno!
scusa maaaaaa....
hai mai compilato un programma?
E poi lo hai mai modificato?
Secondo te le modifiche fatte in una linea del sorgente non si riperquotono
anche altrove? Magari in posti molto distanti?
Prova ad aggiungere un parametro ad una funzione....
dovrei modificare tutte le linee di sorgente che contengono la chiamata alla
funzione.
Altra dimostrazione:
compila un programma, modificalo (anche di poco), ricompilalo con un altro
nome.
Fai il diff dei due file (binari).
 > Gli dissi della possibilità di costruire (con un "pò di lavoro") questo
 > tipo di compilatore e lui mi rispose "Perché dovremmo costruire questo
 > compilatore "incrementale" quando abbiamo computer sempre più veloci e
 > più potenti?"
non e' questo il discorso.
Basta saper utilizzare bene i Makefile.
 > Domanda 5: Potete immaginare che tipo di ottimizzazione il compilatore
 > potrebbe fare nelle decine di secondi guadagnati? Io non penso di
 > farcela!
perche' al posto di ripartire da zero non partecipi all'ottimizzazione di
egcs ? Credo sarebbe molto meglio.
-- 
Paolo Pedaletti, Como, ITALYa < paolo . pedaletti @ flashnet . it >
VOTE AGAINST SPAM! 
http://www.politik-digital.de/spam/it/

 Non ti preoccupare, anche se fosse non sarà per i prossimi 4-5 anni!
Ulp! Ma tra 4-5 anni esisterà ancora il C++ oppure sarà un linguaggio
obsoleto? Mah...
EMG


semplice, banale, di poca importanza...

 egcs ? Credo sarebbe molto meglio.
 
Forse.
Ma ... perché ignorare le possibilità?
Ciao e grazie.
Benedetto
bene...@altavista.net

Ciao Benedetto Proietti,
 > > Prova ad aggiungere un parametro ad una funzione....
 > > dovrei modificare tutte le linee di sorgente che contengono la chiamata alla
 > > funzione.
 > Si, si devono ricompilare tutti gli statement che usano quella funzione.
 > Sbaglio, o indipendentemente dal compilatore che usi, tu DEVI rieditare
 > tutti gli statement che accedono alla funzione per metterci il parametro
 > in più? Non ti piacerebbe che ogni statement che riaggiusti sia
 > correttamente ricompilato mentre tu ti sposti a quello successivo.
mi ritorna in mente..... la programmazione CASE (vado a memoria, posso
sbagliarmi) di moda qualche anno fa (circa 10).
Aveva ambiziosi obbiettivi, e poi e' morta li' perche' troppo semplicistica
(credo)
 > Ma ... perché ignorare le possibilità?
no, ignorare le possibilita' no, ma consumare un sacco di risorse (umane,
soldi, tempo) per un programma dai dubbi risultati e vantaggi... mah!
(in ogni caso gran parte delle scoperte piu' interessanti sono state fatte
andando contro corrente, quindi AUGURI).


Cosa ne pensi?
Che non e` fattibile.


prenderle affatto in considerazione?
"La progettazione e la programmazione sono attività umane: se lo si dimentica, tutto è
perduto"
Bjarne Stroustrup
Come dire: solo perché hai un hardware più veloce non significa che tu debba smettere di
pensare. L'hardware non è il centro del mondo; il software lo è in parte e solo nella
misura in cui viene considerato come il risultato di un'attività di organizzazione e
rielaborazione del
pensiero umano.
(pensiero da sviluppatore; magari un ingegnere elettronico ribalterebbe la frase, ma
tant'è, questo è il mio mestiere. Nessuno è perfetto) ;-)
Andrea Baruzzo

 ottimizzazioni.
Concordo

o meno.
Sei sicuro di aver stimato bene i tempi di ricompilazione? 
A parte il fatto che i compilatori nel caso di progetti con molti
files non ricompilano tutte le volte tutti i files ma solo quelli che
hanno subito cambiamenti usando gli obj gia' fatti degli altri.
Secondo me i vantaggi non sono cosi' evidenti e in alcuni casi il tuo
compilatore si potrebbe anche comportare peggio di un ricompilatore ed
ora ti faccio un esempio:
1) Innanzitutto devi controllare cio' che e' cambiato; cio' significa
che in un progetto con 50 files ed un totale di 10000 righe di codice
(non sto' parlando di utopie ma di esempi reali e anche piccoli) ti
devi tenere innanzitutto una copia del progetto per fare il confronto
e poi devi spulciare tutte righe del codice per trovare i cambiamenti,
il che non richiede un tempo nullo.
2) Una volta trovati i cambiamenti devi andare a modificare i files
obj relativi. Per un esempio semplicissimo:
Se io cambio la riga:
	if (i==4) Pippo();
in 
	if (i==5){
		i--;
		Pippo();}
devi eseguire i seguenti passi:
  a) trovare nell'obj gia' compilato i byte corrispondenti al
controllo dell'uguaglianza(supponendo/sperando che i sia in un
registro es. CX) dovrai cercare i byte 80 F9 04 (CoMPare CL 04)
e cambiarli in 80 F9 05
  b) aggiungere l'istruzione i--; che comporta il dover inserire
all'interno del file un byte in questo caso 49 (DEC CX)
  c) andare a cambiare tutti i riferimenti delle JMP sia condizionali
che non all'interno della funzione modificata perche' e' stato
aggiunto un byte e tutti gli offset sono cambiati
  d) andare a cambiare tutti i riferimenti delle CALL per le chiamate
a funzioni all'interno dello stesso obj nonche' la tabella all'inizio
dell'obj sempre per l'aggiunta di quel byte.
Tutto questo per una semplice modifica. Pensa se le modifiche sono
piu' estese. Neanche si puo' ipotizzare di attaccare tutte le
modifiche alla fine dell'obj perche poi impiegheresti si 1 decimo di
secondo per fare le modifiche ma poi il linker sarebbe obbligato ad un
lavoro pazzesco per mettere in ordine il tutto.
Secondo me SE ottieni dei vantaggi, non sono cosi' eclatanti e a quel
punto ti conviene risparmiare lo sforzo e andare a prendere un caffe'
mentre il compilatore che hai lavora.
Naturalmente tutto quello che ho detto non vuole avere l'intenzione di
scoraggiarti, visto che le idee piu' strane a volte hanno portato a
cambiamenti sconvolgenti.
Ciao
AzriEl

 Per piccola porzione intendo una funzione, uno statement o meno!
Mi hai fatto venire in mente un passo che avevo letto in un articolo di
Stroustrup.
Te lo riporto:
"Already, features that people had deemed impossible for C++ are available
in shipped products. For example, Sun's C++ implementation allows you to
stop an executing program at a breakpoint, rewrite a function, and re­start
using the new function"
Non so altro su questa caratteristica del compilatore della Sun e a seconda
di come è effettivamente realizzata potrebbe essere qualcosa di
completamente diverso oppure abbastanza simile alla tua idea.
Che ne pensi?
L' articolo si intitola "A brief look at C++" (l' avevo trovato sulla
homepage di Stroustrup) ma non c'è altro su questo argomento.

prenderle affatto in considerazione?
Non credo che sia una questione di assuefazione alla mentalita' di
obsolescenza o all'omologazione, ma quanto della mancanza di una
effettiva alternativa.
Per il mercato dei compilatori C++ per Windows da qualche anno, il
riferimento e' senza dubbio Microsoft.
Nel tuo messaggio hai citato Borland. All'inizio degli anni 90 Borland ha
proposto la sua prima versione del compilatore C++ per msdos dotato
di un effettivo e produttivo ambiente di sviluppo integrato e una prima
versione di una container class library (object based) che girava su un
semplice  PC e che ha dato la possibilita' a chiunque di fare le prime
esperienze (almeno per me)  con il linguaggio C++ sul proprio PC di casa.
L'alternativa era Zortech (oggi Symantec) che pero' allora non  disponeva
di un ambiente integrato. La Microsoft arrivo' piu' tardi quando (come
in altre occasioni piu' recenti) ha capito che non poteva continuare a
sottovalutare l'avversario. Microsoft, prima di riuscire a superare il gap
tecnologico  penso' bene di usare la sua solita strategia  mirata a
screditare
l'avversario sul profilo dell'immagine (incompatibilita' con lo standard e i
sistemi operativi), cercare di prelevare dalle file dell'avversario i suoi
pezzi
migliori e aggredendolo con prezzi sempre piu' bassi (salvo poi ricominciare
a
salire una volta fatto fuori).
Alla fine sappiamo com'e' andata, in ogni caso per tornare al tuo discorso
(creare compilatori per linguaggi  più potenti e più ricchi) non credo che
la
strada sia facilmente percorribile con successo se non in ambito accademico
vista la quantita' di strada da percorrere prima di produrre risultati.
Credo comunque che se le idee sono buone prima o poi vengono prese
in considerazione  da qualcuno e a coloro che le propongono sia data la
possibilita' di metterle in pratica.
Saluti.

 punti di riferimento.
E' questo il mio dubbio: certamente se esistesse compilatore
incrementale sarebbe vantaggioso usarlo, ma visto che non esiste, vale
la pena di partire da zero ora?
Ciao,
-- 
Diego Dainese
-> Per le repliche elimina dal mio indirizzo le cifre e le `x'.

...

5 anni è come dire mezzo secolo per l'ICT
Per allora saranno usciti i processori sestium e settium a 2GHz, hard disk
da 2MastodontoByte, e molti :) vorranno ottimizzare il tempo di compiling da
2ns a 1,3ns... senza contare che nel mentre chissà veramente quali
evoluzioni ci saranno state nel linguaggio...

 wrote:
: L'unica eccezione č il brevetto US 5204960 di Microsoft chiamato
: "Incremental Compiler" che č poco piů di:
Ricordo che circa un decennio fa usci` un compilatore di questa azienda
che diceva di fare compilazione incrementale.
L'idea pero` non ebbe seguito. Probabilmente fu solo una trovata di
marketing finita come una bolla di sapone.
-- 
Nando Santagata: Telemastica & infornatica
Key fingerprint = C2 D9 C0 8E D5 B7 04 97  AF E8 3F 3E AF 4E 7F 9E
finger nando (at) mail (dot) ipers (dot) net   for my PGP public key
Home: 
http://www.ipers.net/~nandos

 wrote:
: mi ritorna in mente..... la programmazione CASE (vado a memoria, posso
: sbagliarmi) di moda qualche anno fa (circa 10).
: Aveva ambiziosi obbiettivi, e poi e' morta li' perche' troppo semplicistica
: (credo)
No. Mancavano i modelli e i prodotti costavano troppo e giravano su
macchine troppo potenti (per l'epoca) e troppo costose.
Ricordo di aver partecipato allo sviluppo di un software fatto quasi
interamente usando un CASE.
Ando` benissimo e fu pronto in tempi brevissimi.
Un CASE funziona bene per alcuni tipi di software, gestionali ad
esempio, dove devi creare interfacce per la gestione di tavole di DB,
report ed elaborazioni "standard".
Se disegni bene i dati (diagrammi ER e DF) hai gia` fatto i tre quarti
del lavoro.
Questo quando ci si accontentava di una produzione di interfacce
"industriali", senza troppi fronzoli :-)


del lavoro.
Ultimamente ne ho visti pochi di disegni in giro :-)
ormai si fa tutto con l'SQL Manager :-(
( e poi gli stronzi si lamentano ... sgrunt )

per compilare linguaggi più potenti e più ricchi?
Dubito.
Ma so di essere poco lungimirante. Buon lavoro!

1) Innanzitutto devi controllare cio' che e' cambiato;
Macchč! Controlli dalla data del file *quali* file sono cambiati, e
controlli solo quelli. Altrimenti, annoti durante l'editing quali
righe sono cambiate.

 righe sono cambiate.
Non mi pare si parlasse di fare compilatore + IDE integrati. Se fosse
cosi' per me non avrebbe senso: come farei ad usare il compilatore con
emacs?
Comunque ammettendo anche che fossero integrati, credo sia molto piu'
semplice fare un diff di 2 file piuttosto che memorizzarsi tutte le
modifiche a mano a mano che le fai, perche' il codice oggetto deve
passare da uno stato iniziale a quello finale, tutti i passaggi
intermedi non sono rilevanti.


intermedi non sono rilevanti.
Piů semplice sicuramente si, ma se si parlava delle prestazioni credo
davvero che il modo piů efficace non sarebbe quello che proponi tu.
Non sei daccordo? Che poi integrare l'IDE col compilatore sia un
casino incredibile sono stradaccordissimo. E' uno dei motivi per cui
ritengo che il gioco non valga la candela.
Topoldo
(Grazie a Dio, sono ateo)

Il compilatore Sun combina debugger e link incrementale per andare a
sostituire al volo in un file obj la definizione della funzione
modificata. Per inciso, questo tipo di direzione mi pare piu'
interessante di quella all'origine di questa catena di messaggi.
Cioe' ritengo piu' utile lavorare sull'integrazione dell'ambiente di
sviluppo che non sul semplice compilatore. Qualcuno ha gia' menzionato i
class browser: per esempio, nessuno si e' mai posto il problema di
perche' a pochi giorni dal duemila gli IDE usano ancora semplici file
ASCII come base del loro lavoro? A me piacerebbe un ambiente che
indentasse automaticamente ed al volo il codice come piace a me, senza
cablare l'indentazione nel file sottostante, in modo che chiunque legga
il mio codice possa vederlo indentato come piace a lui; che permettesse
di usare (e che riconoscesse) HTML nei commenti per aumentare le
possibilita' di autodocumentazione, che mi segnalasse al volo gli errori
sintattici, almeno quelli piu' banali...
Penso che un ambiente integrato che usasse direttamente un albero
sintattico come rappresentazione e l'ASCII solo per l'export potrebbe
fornirmi abbastanza semplicemente queste cose ed anche garantire i
vantaggi prestazionali che Benedetto promette...
Saluti a tutti,
Nicola Musatti

possibilita' di autodocumentazione, che mi segnalasse al volo gli errori
Se hai veramente bisogno dell'HTML per documentarti forse hai sbagliato
mestiere.


 Non sei daccordo? 
In effetti col "tuo" sistema non si avrebbe piu' il passo di
compilazione, ma siamo sicuri che l'over-head del compilatore non
influirebbe sulla velocita' dell'editor? IMHO no. Pensa a tutte le
modifiche sostanziali che puoi fare (ad esempio muovere la definizione
di una classe da un file ad un altro) e successivamente disfare: l'IDE
sarebbe costretta a compilare ogni modifica, mentre con il "mio"
sistema sarebbe addirittura libera di decidere quando valga la pena
fare una compilazione incrementale (-> poche modifiche) e quando farla
da 0 (-> tante modiche).
+++
Poi comunque resta il fatto che secondo me e' meglio avere tanti tools
ognuno ottimizzato per il proprio compito, a la UNIX.


 sintattici, almeno quelli piu' banali...
qualunque editor decente ( e quindi il visual c++ è già fuori) con
sintassi colorata,
come ad esempio vim5.4 che ti completa il nome dei simboli e ti accorgi
subito se
le parentesi non sono accoppiate.
-- 
Rimuovi .x dal mio indirizzo, non usare HTML
Linux FAQ: 
http://members.bigfoot.com/%7Eranger_rg/linux/

 mestiere.
Io e Javasoft? Il loro meccanismo di documentazione non e' molto lontano
da quello che intendo, e poiche dopo un '//' puo' stare qualsiasi cosa,
perche' non prevedere un ambiente che sfrutti questa possibilita'.
Saluti,
Nicola

 garantire i vantaggi prestazionali che Benedetto promette...
E perche' non fare il contrario? Puoi benissimo mantenere i sorgenti
in file di testo e usare strutture dati come queste nell'editor per
ottenere le features che richiedi.
Non mi pare proprio che fare il parsing di un file di testo richieda
cosi' tanto tempo...


perche' non prevedere un ambiente che sfrutti questa possibilita'.
Io uso Linux perche' di questi inutili fronzoli ne faccio a meno,
la tua e' comunque una buona idea per un ambiente di programmazione
Windows, non ti aspettare troppi consensi da gente che venderebbe
la mamma per l'ultima versione di vim :-)

 la mamma per l'ultima versione di vim :-)
Cosa vuol dire, io ho lavorato su macchine UNIX per 15 anni e ne
rimpiango molti aspetti, resta il fatto che ritengo la mia
produttivita', almeno come programmatore, molto migliorata (ed anche
sviluppare piu' divertente...) da quando ho accesso ad un IDE. Ritengo
che quelli che chiami fronzoli non lo siano piu' quando i gruppi di
lavoro crescono e la durata dei progetti si allunga.
Ciao,
Nicola Musatti

 cosi' tanto tempo...
E' vero, ma un editor che ti permette di andare da una parte all'altra
di un programma, individuando il file corrispondente in modo automatico
ad esempio cliccando su un identificatore, puo' dover tener conto di
moltissimi file ed i tempi si allungano notevolmente...
Ciao,
Nicola Musatti

 lavoro crescono e la durata dei progetti si allunga.
Se veramente un progetto e' grosso ed ha bisogno una *forte*
documentazione interna, allora, pretendere di usare html ed un'ide e'
un po' una pazzia.  C'e' un metodo inventato da Knuth & Levy negli
anni 70, il literate programming (WEB), che consiste nello scrivere
file (ascii! ma puoi usare un editor tipo emacs o addirittura un
programma di impaginazione tipo lyx) contenenti il codice commentato e
poi usare un applicativo che da li' produce sia il sorgente che un
manualone con tutto il sorgente documentato (e non semplicemente
commentato, sono due cose differenti.)
Un buon inizio e' il sistema noweb, che con 5 comandi fa tutto... se
usi la Debian lo trovi gia' impacchettato altrimenti preparati a
faticare un po'... (
http://www.cs.virginia.edu/~nr/noweb/intro.html
)
Ciao e buon divertimento, 
Federico (che dopo 1 anno di VB e VC++ e' *veramente* felice di essere
          tornato ad emacs/gcc/gdb/noweb/TeX, il miglior sistema integrato
          disponibile.)

 moltissimi file ed i tempi si allungano notevolmente...
 
Ne piu' ne meno che se i sorgenti fossero in un formato diverso;
l'unica cosa che cambierebbe e' il tempo di parsing dei sorgenti che
comunque, come ho gia' detto, e' sempre piuttosto irrisorio.
Ciao,
-- 
Diego    | Per le repliche elimina dal mio indirizzo le 
Dainese  | `x' e inverti le due parole intorno alla `@'