# paludis vs portage vs pkgcore

## lucapost

Portage negli ultimi mesi ha fatto diversi passi avanti, dovrebbe essere imminente il rilascio della versione 2.2.

Comunque noto ancora un'eccessiva lentezza nella risluzione delle dipendenze.

Ai tempi bui di portage, utilizzai per diversi mesi anche paludis, che poi abbandonai in quanto era in pieno sviluppo e "conveniva" stare dietro i troppo frequenti aggiornamenti.

Invece, no strumento che non ho mai provato ma che tutt'ora mi incuriosisce è pkgcore.

Queste sono le versioni disponibili oggi:

```
[I] sys-apps/portage

     Available versions:  [P]2.0.51.22-r3 [P]2.1.1-r2 2.1.4.4 2.1.4.5 ~2.1.5.6 ~2.2_rc11 (~)2.2_rc12 {build doc elibc_FreeBSD elibc_glibc elibc_uclibc epydoc linguas_pl selinux userland_GNU}

     Installed versions:  2.2_rc12(01:12:56 PM 10/10/2008)(-build -doc -epydoc -linguas_pl -selinux)

     Homepage:            http://www.gentoo.org/proj/en/portage/index.xml

     Description:         Portage is the package management and distribution system for Gentoo

* sys-apps/paludis

     Available versions:  ~0.26.2 ~0.28.0 ~0.28.1 ~0.28.2 ~0.30.0 ~0.30.1 {bash-completion doc glsa inquisitio pink portage python qa ruby vim-syntax visibility zsh-completion}

     Homepage:            http://paludis.pioto.org/

     Description:         paludis, the other package mangler

* sys-apps/pkgcore

     Available versions:  ~0.4.7.4 ~0.4.7.5 ~0.4.7.6 ~0.4.7.7 ~0.4.7.8 ~0.4.7.11 ~0.4.7.12 {doc}

     Homepage:            http://www.pkgcore.org

     Description:         pkgcore package manager
```

Avete opinioni/commenti/esperienze da riportare?

----------

## Peach

io ho letto la GMN e parlava proprio EAPI-2 e oggi ero quasi in procinto di installarlo, ma dopo aver visto che è ancora in rc mi sono bloccato.

che parere puoi dare a riguardo? apparte la lentezza solita nella risoluzione delle dip.?

gli altri due non so, sono incuriosito anche io da pkgcore nn l'avevo mai sentito.

----------

## topper_harley

 *Peach wrote:*   

> io ho letto la GMN e parlava proprio EAPI-2 e oggi ero quasi in procinto di installarlo, ma dopo aver visto che è ancora in rc mi sono bloccato.
> 
> che parere puoi dare a riguardo? apparte la lentezza solita nella risoluzione delle dip.?
> 
> gli altri due non so, sono incuriosito anche io da pkgcore nn l'avevo mai sentito.

 

Stando a sentire ciaranm pkgcore è terribilmente rotto, porta alla devastazione del sistema, diarrea, vomito, peste e tifo... (a dire il vero pensa lo stesso anche di portage, peste compresa)

http://www.nabble.com/EAPI-2-is-brokened-:(-td19905090.html

----------

## cloc3

 *lucapost wrote:*   

> 
> 
> Comunque noto ancora un'eccessiva lentezza nella risluzione delle dipendenze.
> 
> 

 

secondo me, portage non sarà mai veloce.

guai se lo fosse: la velocità nella risoluzione delle dipendenze decresce esponenzialmente con il numero degli ebuild disponibili.

una sua piccola variazione determina un rallentamento sensibile di emerge.

se vuoi un segnale, come chiedevi nell'altro post, gentoo comincerà davvero il proprio declino il giorno in cui emerge sarà diventato un programma veloce.

----------

## bandreabis

Sarò io, ma non la vedo tutta sta lentezza di emerge.  :Embarassed: 

----------

## cloc3

 *bandreabis wrote:*   

> Sarò io, ma non la vedo tutta sta lentezza di emerge. 

 

ma infatti, la questione è controversa.

la cosa dipende da troppi fattori diversi dalla qualità del software.

oltre ai problemi di efficienza dell'accesso fisico al filesystem (portage, volutamente, è un database collocato nei file), emerge rallenta in particolare se il file world contiene troppe voci, o peggio, ne contiene di superflue a causa di qualche pacchetto riemerso senza l'uso dell'opzione -1.

oppure se la cartella /etc/portage e la variabile USE di /etc/make.conf sono particolarmente complesse.

cose queste che interessano chi conserva la propria installazione da lungo tempo, magari da anni, senza reinstallare e modificando frequentemente il proprio assetto e aggiungendo di continuo nuovi overlay.

in pratica, la lentezza di portage è figlia della propria versatilità e della propria stabilità.

----------

## djinnZ

ehm... non per fare il bastancontrario ed indulgere nella mia solita crociata anti-prof...  :Laughing:  ma hai torto  :Twisted Evil: 

python non è certo performante quanto un eseguibile; avere quel marasma di file e subdirectory non aiuta:

se inserisci il supporto a psyco, pysql e metti portage su squashfs e la differenza ti salta all'occhio già al primo emerge system, non su una "vecchia" installazione desktop;

se poi (a parte la locazione quantomeno infelice) metti /var/db/pkg su ram (per test, non è una operazione raccomandabile) ti spaventi della differenza.

per non dire del fatto che se vedi cosa c'è in /var/db/pkg/categoria/pacchetto restyi un tantino basito dall'uso di un file per ogni variabile e finezze simili.

Per non dire delle rogne che comporta avere python come dipendenza (a questo punto si poteva pensare, per il gorsso della struttura a bash+eseguibili dedicati per la ricerca, sul modello di q, almeno sarebbe stato assolutamente portabile).

Non sono un fanatico di paludis ma ci sono i problemi. Di certo non mi pare che nessuno si preoccupi di risolverli e si pensa ancora a chi è più bello e più figo.

----------

## lordalbert

ma per lentezza intendete soltanto la risoluzione delle dipendenze?

In quel caso l'ho notata anche io.... ma per il resto...

Una curiosità, come mai è stato scelto proprio python per lo sviluppo di portage?  Intendo, se si fosse usato un linguaggio compilato probabilmente sarebbe stato un poì più veloce....

----------

## cloc3

 *djinnZ wrote:*   

> se inserisci il supporto a psyco, pysql e metti portage su squashfs

 

questi sono fatti noti, soprattutto per lucapost.

ma lui forse non desidera sbattersi a fare lo script che comprime di notte lo squashfs, oppure apprezza la comodità del database rw nei files.

ora, l'unica alternativa attuale è probabilmente proprio paludis, che però è troppo votato allo sviluppo, che dicono non essere così miracoloso nelle situazioni complesse, nemmeno sul piano della velocità  e che lui comunque afferma di avere spontaneamente abbandonato.

pkgcore ... è scritto in python.

perciò al momento è necessario rassegnarsi al fatto che gentoo non è solo portage, fermo restando che comunque portage non è neppure strumento così rudimentale da doversene sbarazzare troppo di fretta.

----------

## cloc3

 *lordalbert wrote:*   

> 
> 
> Una curiosità, come mai è stato scelto proprio python per lo sviluppo di portage?

 

Drobbins ha voluto un linguaggio di scripting.

lo riteneva più flessibile e maneggevole. e probabilmente riteneva effimero ed irrilevante il vantaggio legato all'adozione di un linguaggio compilato, tant'è che non ha mai considerato seriamente di discutere di questa scelta.

per quanto riguarda la collocazione nel file system, prima di tutto, risolve un problema di dipendenze più grave che quello del python.

ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata?

ma soprattutto, hanno avuto un peso le attese che Robbins nutriva nello sviluppo dei filesystem di Reiser (e dei filesystem linux in generale). perciò le "finezze simili" che dice djinnZ, come riservare un file per ciascuna variabile non sono ingenuità imperdonabili di un programmatore in erba, ma rappresentano l'esperimento di qualcuno che spingeva la sguardo un passetto più in là di quanto noi stessi, tutt'oggi, sappiamo vedere.

piuttosto che impegnarsi a riscrivere portage, gli sviluppatori di gentoo farebbero bene a spingere lo sviluppo in questa direzione: quella dei filesystem.

----------

## Kernel78

ognuno ha le sue priorità e se qualcuno si lamenta di qualcosa allora questa rappresenta un problema, almeno per lui.

Io me ne frego altamente della velocità di risoluzione dipendenze, tanto sul tempo di compilazione non influisce che per una frazione insignificante ...

Per quanto riguarda gli aggiornamenti avevo scritto un post su come ottimizzare il sync notturno e mi invio via mail il diff-eix (così vedo quali pacchetti sono aggiornati) e anche un pretend dell'aggiornamento così posso valutare se devo sistemare qualche USE, mascherare o smascherare qualche pacchetto prima di procedere. Poi prima di andare in ufficio lancio l'aggiornamento effettivo e tanti saluti al tempo di risoluzione dipendenze.

Mi rendo conto che magari questa latenza possa costituire una noia per chi sperimenta, prova e riprova nuovi pacchetti più volte al giorno ma oggettivamente non mi sarei immaginato che questi costituissero una fetta così abbondante ...

----------

## djinnZ

@kernel78: usiamo più o meno lo stesso metodo per aggiornare quindi non è che ci faccia molto caso però quando devo aggiungere un pacchetto singolo mi scoccia aspettare.

@cloc3: Sarò tradizionalista ma per me la vecchia accoppiata sh(che può essere compilato all'occorenza)+piccoli binari dedicati resta la più valida.

In generale il python si è evoluto peggio del perl e comunque non sto a giudicare a posteriori le scelte di robbins ma la mancata revisione del database e della cache da parte di chi è venuto dopo di lui (e dal non voler affrontare l'incogruenza di certe impostazioni tradizionali della destinazione di var home tmp ed etc).

Usare un singolo file per le variabili è un esempio (e non credo che shell o da python complichi le cose, anzi).

----------

## Kernel78

 *djinnZ wrote:*   

> @kernel78: usiamo più o meno lo stesso metodo per aggiornare quindi non è che ci faccia molto caso però quando devo aggiungere un pacchetto singolo mi scoccia aspettare.
> 
> 

 

personalmente anche quando installo nuovi sw il tempo di risoluzione delle dipendenze mi risulta trascurabile se confrontato con quello della compilazione ...

oggettivamente penso che la maggior parte del tempo d'uso di un sistema gentoo non sia dedicato all'installazione di nuovi sw quindi il tempo dedicato alla risoluzione delle dipendenze sia irrisorio (a meno che non usiate una macchina solo per creare pacchetti binari ma anche in quel caso ...)

----------

## Peach

 *djinnZ wrote:*   

> @cloc3: Sarò tradizionalista ma per me la vecchia accoppiata sh(che può essere compilato all'occorenza)+piccoli binari dedicati resta la più valida.

 

guarda secondo me non è questione di "tradizionalismi"

parlando seriamente, considerando gentoo nel suo insieme ( e quindi non solo come un Desktop-OS ) secondo me, meno dipendenze ci sono meglio si sta. Voglio dire: se anche rimuovi gcc un eseguibile va sempre, ma se rimuovi python... ah sono razzi amari!

Dal suo canto python ha effettivamente la facilità e la comprensibilità paragonabile a quella di un linguaggio naturale, e questo non fa altro che favorire la diffusione di gentoo e quant'altro...

Trovare una via di mezzo? Così come stanno cercando di fare per baselayout? a me non sembra una idiozia, ma è anche vero che io non c'ho mai provato a guardarci dentro.

----------

## oRDeX

Premetto che non programmo in Python (anche se stanno cercando di convincermi  :Razz: ).

Se non sbaglio esiste la possibilità di compilare il python in byte code (stesso procedimento di java quindi) producendo un .pyc (partendo da un .py) che ovviamente, in quanto byte code, deve essere eseguito tramite l'utilizzo del comando python ma potrebbe comunque giovare in qualche modo alle performance. Non è eliminato il discorso della dipendenza dall'interprete, ma penso sarebbe già un passo avanti.

EDIT:

Da una veloce ricerca mi pare di aver capito che c'è chi ha sviluppato alcuni tool per la compilazione del python in linguaggio macchina: http://starship.python.net/crew/atuining/cx_Freeze/

Non ho finito di leggere il README ma non mi pare ci siano controversie. Ovviamente così si risolverebbero mediamente i due problemi di prima: performance (almeno un minimo) e dipendenza (dall'interprete).

----------

## morellik

 *oRDeX wrote:*   

> Premetto che non programmo in Python (anche se stanno cercando di convincermi ).
> 
> Se non sbaglio esiste la possibilità di compilare il python in byte code (stesso procedimento di java quindi) producendo un .pyc (partendo da un .py) che ovviamente, in quanto byte code, deve essere eseguito tramite l'utilizzo del comando python ma potrebbe comunque giovare in qualche modo alle performance. Non è eliminato il discorso della dipendenza dall'interprete, ma penso sarebbe già un passo avanti.
> 
> 

 

Ti devo contraddire perche' internamente, il codice sorgente Python viene sempre convertito nella rappresentazione in bytecode, e questo viene dopo eseguito nella macchina virtuale di Python. Non c'e' nessuna differenza a livello di prestazioni una volta che il file .pyc e' stato caricato, come del resto il bytecode letto dal file .pyc e' lo stesso di quello creato dalla conversione diretta. L'unica differenza e' che il caricamento di codice dal file .pyc e' più veloce dell'analisi e conversione di un file .py, per cui la presenza di file .pyc precompilati migliora il tempo di avvio degli script Python. 

L'unica alternativa potrebbe essere l'uso di psyco, mi pare di aver postato come fare, ma non so se e' sempre compatibile con l'ultima versione di emerge.

----------

## djinnZ

Mettendo /var/db/pkg in ram la differenza è notevole, più che usare psyco, pysql e squashfs (o è meglio cram? Non lo ho mai usato per questo chiedo, già che mi trovo).

Però il fatto che debba attendere sempre almeno quei 30 secondi quando lancio un emerge ltrace (l'ultima cosa che ho fatto) mi scoccia, e non poco, più perchè intuisco che scelte frettolose, fatte da drobbins in una fase iniziale, si sono cristallizate.

Non sto dicendo che drobbins ha sbagliato, solo che ha operato alcune scelte, valide in fase di prima implementazione, che non dovevano rimanere tali.

Per non dire del fatto che avere sulla stessa partizione i file temporanei usati per compilare ed il database dei pacchetti è una spada di Damocle che mi impensierisce non poco; su filesystem come xfs ti ritrovi a terminare il flush della cache e cancellare i file temporanei (e su xfs è da sempre lenta come operazione) e scrivere il database contemporaneamente. Vero che avevo formattato con impostazioni eccessive, tanto era il disco di prova, ma mi sono trovato più volte con il database irrecuperabile, lo ripeto.

Però per quanto riguarda var ci sarebbe da discutere che log, fax e via dicendo non hanno la stessa importanza ed utilità di cache e temporanei vari, ma se penso a quel che sono le espressioni regolari (sia sempre maledetto l'idiota che si è inventato "* *" nella linea di comando) non mi stupisco più di tanto.

Se il python si fosse evoluto senza incompatibilità e problemi (o meglio se non si fosse mai evoluto come il bash scripting) poteva anche andar bene.

Di sicuro elementi come l'init (motivo per il quale non sono passato ad einit, la dipendenza da expat), il gestore dei pacchetti nelle sue funzioni principali (ovvero aggiornare il sistema ed installare/disinstallare), la shell etc. devono avere dipendenze minime o nulle, sia a runtime che in compilazione.

Per esempio a cosa serve la funzione di ricerca in emerge? Non è una cosa che è meglio lasciare ad un pacchetto esterno come eix/q?

Paludis mi pare che voglia ripercorrere lo stesso errore (anzi peggiorarlo e senza la facilità di un linguaggio interpretato) e quindi mi piace poco.

----------

## lucapost

...

----------

## lucapost

 *cloc3 wrote:*   

> 
> 
> ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata?

 

e cosa ci sarebbe di così male? per gestire quasi 13000 pacchetti..., finchè il necessario mi passa in 700mb per l'installazione....

se da qualche parte si andrà a finire, IMHO, si finisce ad un database oppure si spezzerà l'albero di portage perlomeno in overlays di progetti minori. chi vivrà vedrà...

----------

## djinnZ

 :Shocked:   :Confused:  una lettura del buon vecchio knuth o del buon Nick Wirth non farebbe male.

Prima si progetta la struttura dei dati e poi si inizia a scrivere il programma, soprattutto quando si aggiunge.

Datemi pure del rudere arcaico e tradizionalista (in effetti quando scrissi il mio programma in cobol non c'era neppure il C64 in commercio e quando scrissi l'ultimo in c M$ non era ancora imposta per legge, un tantino arretrato lo sono) ma non ho mai letto niente da parte dei devel sul portage, solo implementiamo questo, implementiamo quello.

Ammetto che c'è chi spinge il discorso solo in quella direzione ma in ogni caso non va.

----------

## Peach

vogliamo parlare del futuro? e che dire dell'uscita di Python 3.0? che rompe la compatibilità con le versioni precedenti? beh è sempre un rischio che si ha con qualsiasi linguaggio di programmazione, per carità, però qui si parla di qualcosa che potrebbe affliggere l'intera piattaforma, o dico una scemenza?

----------

## morellik

 *Peach wrote:*   

> vogliamo parlare del futuro? e che dire dell'uscita di Python 3.0? che rompe la compatibilità con le versioni precedenti? beh è sempre un rischio che si ha con qualsiasi linguaggio di programmazione, per carità, però qui si parla di qualcosa che potrebbe affliggere l'intera piattaforma, o dico una scemenza?

 

E' vero, Python 3.0 non sarà retrocompatibile (non starò a discutere su una strategia che secondo me è giusta. Ogni tanto occorre dare un colpo di spugna per far funzionare al meglio le cose.). Ma Python non è M$ che decide da un giorno all'altro smettere di darti un SO in favore di un altro. I developer Gentoo avranno tanto di quel tempo per adattarsi ai cambiamenti che ci potrebbero invecchiare. Oltretutto più versioni di Python possono convivere tranquillamente senza alcun fastidio.

Il tutto IMHO.

 *djinnZ wrote:*   

> Datemi pure del rudere arcaico e tradizionalista (in effetti quando scrissi il mio programma in cobol ...

 

Cobol   :Shocked:   Quanti ricordi....Il mio primo corso di programmazione...... Grande djinnZ, allora non sono l'unico "vecchio" in questa baracca.  :Embarassed: 

----------

## cloc3

 *lucapost wrote:*   

>  *cloc3 wrote:*   
> 
> ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata? 
> 
> e cosa ci sarebbe di così male?

 

me lo chiedi?

intanto, il database non rende più celere il calcolo delle dipendenze. il database sveltisce solo l'accesso ai dati necessari per risolvere le dipendenze...

ma come minimo, se i dati sono inclusi in un database, serve un programma per navigarlo.

al momento il mio browser preferito per navigare portage è ls, in linea di comando.

sono sicuro che sia molto più facile scoprire un programma nuovo così che usando synaptics o qualunque altro gestore di pacchetti strafico della distro più in voga.

e al di là di ogni giudizio tecnico, apprezzo in questo un valore immenso di libertà.

infatti, il database chiuso impone un rapporto privato con l'utente che gentoo risolve con straordinaria leggerezza.

infine, considerato che stiamo parlando di gentoo, è evidente che quel browser non potrebbe funzionare meglio di un certo installer grafico di nostra infelice memoria   :Rolling Eyes:  .

anche un pizzico di realismo e/o di sano umorismo... quando ci vuole ci vuole.

 :Smile: 

----------

## djinnZ

 *cloc3 wrote:*   

> intanto, il database non rende più celere il calcolo delle dipendenze

 una base dei dati decente ben strutturata rende più veloci le operazioni. Per età ed in virtù del lavoro knuth e wirth li devi conoscere...

----------

## cloc3

 *djinnZ wrote:*   

>  *cloc3 wrote:*   intanto, il database non rende più celere il calcolo delle dipendenze una base dei dati decente ben strutturata rende più veloci le operazioni.

 

la struttura del database di portage è decente. infatti tu dici che, caricato in ram, è una scheggia.

knuth e wirth? purtroppo no. la mia è una cultura di nubbio maneggione.

----------

## lordalbert

Knuth io l'ho odiato pronfondamente. O meglio, me l'ha fatto odiare il mio professore che lo esaltava come un dio in terra. E ci ha fatto studiare il suo cavolo di Mixal. Imparare l'assembly senza una guida (perchè la guida non l'ha mai trovata nessuno) non è il massimo... E poi voglio vedere chi, tra quelli che programmano, eseguono OGNUNA di quelle fasi...

----------

## Kernel78

 *lordalbert wrote:*   

> Knuth io l'ho odiato pronfondamente. O meglio, me l'ha fatto odiare il mio professore che lo esaltava come un dio in terra. E ci ha fatto studiare il suo cavolo di Mixal. Imparare l'assembly senza una guida (perchè la guida non l'ha mai trovata nessuno) non è il massimo... E poi voglio vedere chi, tra quelli che programmano, eseguono OGNUNA di quelle fasi...

 

Perdonate l'OT ma vedere qualcuno che chiama il linguaggio assembly con il suo nome mi commuove ... quasi ovunque lo sento chiamare assembler  :Sad: 

----------

## djinnZ

 *lordalbert wrote:*   

> me l'ha fatto odiare il mio professore che lo esaltava come un dio in terra

 e poi mi chiedono perchè me la prendo tanto con cloc3 (anche se universitario Knuth era e resta un professore di matematica, l'informatica è venuta dopo) ...   :Twisted Evil: 

Oddio i due tizi sono le pietre miliari dell'algoritmica, della programmazione strutturata etc. persino dell'editing... Thompson, Ritchie e Kerningam vengono odiati altrettanto, Thorwalds o Stallman forse è solo meno citato dagli imbecilli perchè non è un vecchio o perchè non si atteggia ad alto sacerdote del sapere oscuro del menga come loro.

Quanta gente deve essere odiata e maledetta solo perchè un imbecille in cattedra non sa fare il proprio lavoro.

Tra parentesi in tanti anni testi più chiari e concreti di "algoritmi+strutture dati=programmi", "pascal" ne ho visti pochi (ed erano howto), quanto a "the art of computer programming" sono riuscito a leggerlo in originale, nonostante il mio profondo odio verso l'idioma e la cultura britanniche e derivate (per non dire della matematica), e devo dire che è leggibile, all'epoca il mio prof non lo citava, diceva solo "leggetevelo che vi fa bene" ma l'idiota dell'assistente (un tizio che sosteneva a spada tratta che in un ciclo n=(n+1)/c era meglio di i=n/c e n=n+i) era sempre li a citarlo (quasi sempre a sproposito o sbagliando), oggi sarà diventato professore a sua volta.

A quali "fasi" ti riferisci?

La cosa bella è che non sta scritto da nessuna parte che devi scrivere la struttura dei dati, creare lo schema per l'accesso (ho conosciuto gente che scriveva programmi anche prima che io nascessi e nessuno ha mai fatto un flow chart, lo pensavano e poi scrivevano il programma), scrivere il programma, rifinire le funzioni etc. solo prima pensare a cosa devi maneggiare poi a come.

Allora se voglio scrivere una relazione tecnica od una memoria devo passare per almeno sei stesure successive? Trovami un qualsiasi consulente o avvocato che lo fa.

Si scrive sempre direttamente e di getto ma la si concepisce sempre secondo quelle linee guida di sempre.

Ovviamente chi non sa neppure cosa sia il lavoro si formalizza sui passaggi.

@kernel78: quello che si pronunzia "hassemblérr"?!  :Laughing: 

 *cloc3 wrote:*   

> nubbio maneggione

   :Shocked:   :Question:   :Exclamation:  rapace?

No, dimostra solo che è inefficiente e non tiene conto dei limiti dell'hardware.

----------

## lordalbert

Le "fasi" sarebbero

1) Specifica: Devi scrivere in modo _formale_  (matematico) il problema che il programma deve risolvere, evidenziando i dati in ingresso, quelli di uscita, poi (cito) "specificare l'insieme di condizioni che gli ingressi sono garantiti rispettare, chiamate anche precondizioni, che potrebbero essere espresse nel linguaggio della logica in termini di predicati e relazioni come un'unica formula della logica dei predicati del prim'ordine con variabili in X" (se capisci che vuol dire...).  Insomma, riassumendo (sempre citando): "una specifica è una quadrupla S = <X,Y,I,U> "

2)Progettazione: devi scrivere un diagramma di flusso, con elencati TUTTI i passaggi, ogni assegnamento, etc etc...  (decidendo anche il bottom-up o top-down)

3) Modellazione: Ritrascrivere il diagramma di flusso in uno pseudo codice!   Praticamente come lo scriveresti nel linguaggio, ma con segni/operazioni diverse.  Per esempio, invece di c=1;   devi scrivere  c <- 1  . Insomma, uno speudo codice di facile comprensione

4) codifica: Ritrascrivere tutto nel linguaggio scelto (per esempio C )

5) Documentazione: Scrivere più commenti all'interno del codice, che il codice stesso

6) Verifica e correzione: Verificare che il programma funzioni  (e controllare bug no?! bah....)

(ecco, devi rispettare accuratamente ognuna di queste fasi! Ovviamente secondo il mio caro ed adorato professore..)

Poi vabbè, io non ho mai capito l'utilità della programmazione strutturata... alla fine se il programmatore è bravo, non dovrebbe fare casini...

E la cosa bella, è che lui scriveva del codice (ovviamente seguendo tutte quelle fasi) per farci degli esempi, e non funzionava mai!!  Il compilatore dava sempre qualche errore.. (ah già, dimenticavo, quello fa parte dell punto 6  :Smile:  )

L'odio per Knuth deriva più che altro dal fatto che pretendeva che noi sapessimo perfettamente il Mixal, quando nessuno ha mai trovato una guida per tale "linguaggio". E' un po' difficile quindi impararselo... devi prendere quei pochi esempi di codice disponibile e scoprire la sintassi da quelli...

Vabbè, chiuso OT.. siamo andati un po' troppo OT mi sa  :Smile: 

----------

