Cosa c'è di sbagliato nell'usare un framework che ha molte dipendenze?

Question

Recentemente ho detto ad un amico che stavo iniziando ad imparare Catalyst (Perl) e lui ha sottolineato abbastanza fortemente che, poiché Catalyst ha così tante dipendenze, dovrei usare qualcosa come Rails.

Non è una buona cosa che ci siano molte dipendenze? Non indica un sacco di riutilizzo del codice? Capisco che potrebbe esserci più impegno nell'installazione del framework ma ci sono altri svantaggi?

Riprenderò il mio Catalyst tutorial fino a ottenere alcune risposte succose. :-)

Answer 1

Quando ci sono delle dipendenze tra i componenti, è possibile trovarsi in una situazione non funzionante se si è costretti ad aggiornare un componente (per esempio, per motivi di sicurezza) prima di una versione compatibile di un componente dipendente è disponibile.

Ciò presuppone che è possibile entrare in uno stato operativo in primo luogo. Può darsi che se cerchi di utilizzare le versioni correnti di tutte le dipendenze, scoprirai che non giocano.

Più grande è il numero di dipendenze, maggiore è il rischio.

Rails non è esente da questo problema. Con ogni nuova versione di Ruby, c'è una scramble per aggiornare le istruzioni su come ottenere, ad esempio, i driver del database costruiti.

Per essere onesti, questo problema è tendenzialmente "migliore" nel tempo, anche se con dossi stradali.

Answer 2

La mia esperienza personale è che più dipendenze hai, più versioni devi tenere traccia e questo può portare a situazioni da incubo. In particolare, l'aggiornamento di una dipendenza (a causa di un bug che si desidera correggere, ad esempio) può portare problemi di compatibilità con le altre dipendenze. Ad esempio, ho avuto una situazione in cui gcc 4.0.3 ha funzionato con foo ma non con bar (dipendenza di foo), e gcc 4.0.5 ha funzionato con la barra ma non con foo. Fortunatamente, 4.0.2 ha funzionato.

Inoltre, più dipendenze tendono a segnalare i prodotti "mostri di Frankenstein", fatti di parti che non sono state progettate in anticipo per giocare insieme. Un framework ben integrato è progettato per suonare piacevole e coerente. Questo, naturalmente, può essere risolto con il corretto avvolgimento delle differenze.

Answer 3

Non c'è niente di particolarmente sbagliato in questo. Il vantaggio di Catalyst è che i suoi pezzi possono essere utilizzati da persone che non utilizzano tutto Catalyst. Ciò significa che ci sono più occhi che guardano e correggono bug nelle parti critiche.

Il più grande lamentela che sento è che è fastidioso osservare tutti quei messaggi nella shell CPAN mentre Catalyst sta installando. La soluzione è approfittare del gestore di pacchetti del tuo sistema operativo mentre inizi. Su Debian, l'installazione di apt-get install libcatalyst-perl richiede 15 secondi su una macchina senza altri moduli Perl installati. 15 secondi. (Una semplice installazione CPAN non è difficile, ma suppongo che la shell CPAN standard ti faccia un sacco di domande stupide, e che rimandi i neofiti.)

Non preoccuparti delle dipendenze, ci sono buoni strumenti per gestendoli e rendono il quadro più forte e flessibile.

Answer 4

Questo è un argomento che ho visto in precedenza. Ho intenzione di scrivere un articolo a riguardo e finalmente l'ho fatto.

E 'qui: The Lie of Independence

Vi incoraggio a leggerlo. L'essenza è semplice, però. La domanda è sbagliata. Non è "Usi un'applicazione o un framework con molte dipendenze o una che non le possiede?"

È: "Utilizzi un'applicazione o un framework che ha molte dipendenze esterne o che tenta di eseguire tutto internamente?"

E la domanda che segue è "Hai davvero fiducia che la persona o le persone che scrivono questo framework capiscano ogni sfumatura di ogni piccolo dettaglio di ogni attività che deve essere eseguita per elaborare una richiesta web?"