Fare dinamiche lingue digitati meritano tutte le critiche? [chiuso]

Question

Ho letto un paio di articoli su Internet sulla programmazione scelta della lingua in azienda. Recentemente molti linguaggi dinamici digitato sono stati popolari, cioè Ruby, Python, PHP e Erlang. Ma molte imprese ancora rimanere con linguaggi statici digitato come C, C ++, C # e Java.

E sì, uno dei vantaggi di linguaggi statici digitato è che gli errori di programmazione vengono catturati in precedenza, al momento della compilazione, piuttosto che in fase di esecuzione. Ma ci sono anche vantaggi con dinamiche digitato lingue. ( più su Wikipedia )

Il motivo principale per cui le imprese non iniziano a utilizzare linguaggi come Erlang, Ruby e Python, sembra essere il fatto che essi vengono digitati dinamica. Che sembrano anche essere la ragione principale per cui la gente su StackOverflow decidono contro Erlang. Vedere Perché hai deciso "contro" Erlang .

Tuttavia, ci sembra essere una forte critica contro la tipizzazione dinamica nelle imprese, ma io non capisco proprio perché è che forte.

In realtà, il motivo per cui c'è tanta critica contro la tipizzazione dinamica nelle imprese? E 'davvero incidere sul costo dei progetti che molto, o cosa? Ma forse mi sbaglio.

Answer 1

Sì, credo che lo facciano.

Ci sono alcuni motivi che devono essere considerati nella scelta di un linguaggio per un nuovo progetto:

• velocità di run-time. Rispetto al C / C ++ / Fortran, Perl e Python sono così lenti che sia divertente.
Velocità
• inizializzazione. Rispetto a quanto sopra lingue veloci, Java cade e piange come la JVM mantiene carico e carico e ... while(1) ....
• Prototype-abilità. Esaurientemente passare attraverso e fare il lavoro di dichiarazione / definizione necessaria per C ++ o Java aumenta la LOC, che è il solo noto metrica che si correla in modo affidabile con bugcounts. Ci vuole anche un sacco di tempo. Si richiede anche un po 'di più a pensare a tipi e le connessioni.
• fiddlability interno. Dinamicamente fare in giro con i tuoi interni è grande fino a quando si inizia a eseguire il debug del il codice di auto-modifica . (Python, Lisp, Perl)
• Verifica correttezza. Un compilatore in grado di fornire un rapido una volta-over passare di semi-la correttezza del codice in C ++, e questo può essere davvero bello.
• statici dettagli analisi. C e Java hanno abbastanza buona analisi statica. Perl non è completamente statico analizzabile a un livello teorica (Possibilmente Python troppo). Sono ragionevolmente sicuro Lisp non è neanche.
• piattaforme strano prendere solo C, in generale.
• Catena di supporto. Se si può avere un contratto che si si ottenere i bug guardato e ha lavorato su, che di enorme .

Se si può presumere che l'organizzazione si sta lavorando con ha un principio di "Andando avanti" (C'è un termine di contabilità per questo), e non sarà solo decidere in modo casuale a non lavoro sulla software, quindi si ha un caso molto meglio per l'utilizzo del software. Dal momento che non c'è nessuna grande azienda vendita (portando implicazione di assumersi la responsabilità di mantenerla) Python / Perl / $ dynamic_language, si riduce notevolmente il rischio.

Nella mia esperienza, i manutentori open source hanno spesso un problema con l'assunzione di piena responsabilità di bugfix e rilasciando aggiornamenti. "E 'gratuito, si lavora su di esso!" è non una risposta che sia accettabile per la maggior parte delle imprese (non i loro compentencies fondamentali, tra le altre cose).

Naturalmente, non sto parlando del / mondo startup webapp, che tende a giocare da alto rischio / alto rendimento regole ed essere molto aperto a stare sul bordo schiuma di tecnologia.

Answer 2

Si sta dando modo troppo credito tecnica ai decisori aziendali. C'è un vecchio detto, "Nessuno stato licenziato per l'acquisto di IBM". Se si va un percorso diverso e le cose ottenere rocciosa (fanno sempre), nessuno vuole rischiare di essere accusato. Stick alle norme e la colpa a qualcun altro.

Ci sono un sacco di aziende più giovani, che finirà per diventare imprese di domani e sarà utilizzando queste lingue.

E cerchiamo di non dimenticare le linee buggillion di codice scritto in VBA!

Answer 3

La ragione per cui le imprese utilizzano C, C ++, C # e Java non è perché sono tipizzati staticamente (almeno non direttamente). decisori Enterprise non stanno facendo questo tipo di scelte sulla base di un confronto oggettivo dei sistemi di tipo, te lo assicuro.

Aziende do cura di:

• i costi di mantenimento a lungo termine : si può ragionevolmente aspettarci che le cose continuino a funzionare bene tra 10 anni? In realtà è una buona cosa se l'evoluzione lingua è conservatore e retrocompatibile (come Java). La tipizzazione statica è utile qui perché coglie un importante tipo di bug in fase di compilazione, prima che entrino nella sistemi di produzione .....
• disponibilità Talent - si sarà in grado di trovare gli sviluppatori per mantenere il vostro nuovo sistema lucido? Che cosa succede se le foglie sviluppatore originale, sarà tutti gli altri capire il codice? Questi luoghi un alto ostacolo sull'introduzione di qualsiasi "nuovo" linguaggio (soprattutto se si crea anche nuovi requisiti per la distribuzione, sistemi di compilazione, supporto operativo, ecc). Questo dà una massiccia vantaggi alle lingue che sono ampiamente utilizzati (C, C ++, C # e Java)
• costa Integrazione : è facile collegare / integrarsi con altre tecnologie che avete già in atto o sono suscettibili di acquisire? Se si dispone già di una pila di sistemi J2EE legacy, allora avete bisogno di integrarsi con loro. Una nuova soluzione Java EE è probabile che sia molto più pratico per questo che per esempio Python.
• Predicatbility / basso rischio : è la piattaforma / lingua provata, e posso essere sicuro che funzionerà? Questo è di solito più importante della semplice produttività. E 'molto più facile per un manager di convincere il suo capo di dargli un grosso budget di manodopera per costruire un nuovo sistema di quello che è per lui di tornare più tardi e dire che non ha funzionato .....
• Enterprise Backup / supporto - sono le principali organizzazioni internazionali impegnata a sostenere la lingua e la piattaforma? Saranno in grado di firmare un contratto a sostenermi in modo da avere qualcuno da chiamare in caso di problemi?
• Venditore neutralità / indipendenza dalla piattaforma - sono io che vado a ottenere bloccato dentro ad un unico fornitore? O devo una vasta gamma di percorsi futuri opzioni fornitore / transizione disponibili? Se non si desidera essere bloccato dentro un insieme architettonico vicolo cieco, in grado di fare progressi, mentre i concorrenti mangiare il pranzo. Se state facendo il vostro lavoro correttamente come architetto impresa, è necessario pensare almeno 5-10 anni a venire su questa roba.

Personalmente, penso che se si desidera utilizzare i linguaggi dinamici in azienda, allora la vostra migliore possibilità è di gran lunga usare qualcosa che piggy-back su un ecosistema aziendale esistente. Degna di nota sono i nuovi linguaggi dinamici JVM: per esempio JRuby, Groovy, Clojure. Per quanto riguarda la gestione IT interessato, queste sono scelte linguaggio dinamico "sicuri" perché operano all'interno e giocare bene con il resto dell'ecosistema enterprise Java.

Answer 4

Il motivo principale per cui le imprese non iniziano a utilizzare linguaggi come Erlang, Ruby e Python, sembra essere il fatto che essi vengono digitati dinamici.

Credo che questo sia solo il loro scusa primaria. La vera ragione è che le imprese in realtà non li prendono sul serio e sentono che sono forse un po 'troppo amatoriale. Java e .NET sono “grandi nomi commerciali”, hanno un buon marketing commerciale, assistenza clienti commerciali, e sono quindi ampiamente preso molto sul serio.

E 'un peccato che non c'è praticamente nessun linguaggio staticamente tipizzato che è nemmeno lontanamente così popolare come i grandi nomi aziendali. Perché sono open-source / ambienti di programmazione di software libero quasi sempre digitati in modo dinamico? Questo potrebbe indicare che un linguaggio staticamente tipizzato in realtà non è così facile da fare, e che la tipizzazione dinamica è un “hack uomo pigro”. Se questo è il caso, le imprese che decidono nei confronti delle lingue dinamicamente tipizzati potrebbe effettivamente hanno un punto.

Answer 5

• dinamicamente tipizzato linguaggi tendono ad essere più lento rispetto ai loro cugini staticamente tipizzati.
• Gli errori sono più difficili da catturare e possono essere difficili da eseguire il debug
• Il compilatore / interprete tende ad essere molto meno fastidioso di quello che si può e non può fare. vale a dire, si cattura praticamente solo gli errori di sintassi in fase di compilazione
• Se non siete molto attenti con la progettazione di un linguaggio tipizzato in modo dinamico, si finisce con Javascript, che è il linguaggio del codice-odori

Modifica Devo dire che il mio principale linguaggio di programmazione in questo momento è Python, che viene digitato in modo dinamico. Personalmente, amo la libertà che viene con non dover prima dichiarazione delle variabili, ma a volte, avrei essere piacevole per specificare (per esempio) che tipo di parametri di una funzione serve per errori di cattura presto piuttosto di ritardo.

Answer 6

dinamicamente tipizzato lingue sono percepiti (da alcuni programmatori / boss) per produrre codice che non funziona pure. Il fatto che un programma digitato in modo dinamico compila ti dice molto poco circa la sua correttezza. Il fatto che un linguaggio a tipizzazione statica compila ti dice molto di più. (D'altra parte, c'è ancora una lunga strada tra compila e fa la cosa giusta, quindi questo potrebbe essere meno significativo allora sembra)

dinamicamente tipizzato lingue sono percepiti da linguaggi di scripting. Non avresti mai scrive un'applicazione in bash o un file batch. Tutte le lingue dinamicamente tipizzati tendono ad essere passato in quella categoria (ingiustamente).

dinamicamente tipizzato lingue sono più lento di lingue staticamente tipizzati. (Ma vedremo quanto bene il lavoro sulle modifiche JIT che)

Answer 7

Nota: questo è per lo più soggettivo e basato sulle mie esperienze e impressioni

.

dinamicamente tipizzato lingue sono molto diverse dalle lingue staticamente tipizzati. Queste differenze probabilmente diventano più importanti nel software enterprise pesi massimi che in molte altre applicazioni.

staticamente tipizzato lingue tendono ad essere molto prescrittivo. Metodo vorranno solo input che corrisponde esattamente la sua firma. I livelli di accesso tendono ad essere molto importante e interfacce sono definite in modo esplicito, con verbose ma restrizioni inequivocabili in atto per far rispettare tali definizioni.

dinamicamente tipizzato lingue d'altra parte sono molto pragmatico. conversioni di tipo accadono spesso in modo implicito, le funzioni possono anche giocare insieme se si fornisce il tipo sbagliato di ingresso finché si comporta sufficientemente simili. In linguaggi come Python, i livelli di accesso anche saranno basati su contratto piuttosto che restrizioni tecniche (cioè è solo private perché ti dicono di non usarlo e ha un nome buffo).

Molti programmatori preferiscono i linguaggi dinamici, perché (forse) consentono la prototipazione rapida. Il codice spesso finisce più breve (se non altro per la mancanza di dichiarazioni di tipo), e se si vuole violare il protocollo corretto perché avete bisogno di una soluzione rapida e sporca o si desidera qualcosa di prova, che è facilmente possibile.

Ora, la ragione per cui "enterprisey" spesso le aziende preferiscono lingue staticamente tipizzati è esattamente che sono più restrittive e più esplicito su tali restrizioni. Se in pratica anche codice tipizzazione statica può essere rotto da idioti con un compilatore, molti problemi saranno molto più visibili molto prima nel processo (cioè prima della fase di esecuzione). Ciò significa che anche se il codice di base è grande, monolitico e complesso, molti errori possono essere catturati con facilità, senza dover eseguire il codice o inviarlo verso il reparto di QA.

La ragione per cui beneficio non superano gli svantaggi per molti programmatori esterni che l'ambiente è che questi sono errori che spesso essere facilmente catturati mediante ispezione approfondita del codice o addirittura tentando di eseguirlo. Soprattutto quando a seguito di una metodologia di test-driven, questi errori spesso diventano banali da catturare e facile da risolvere. Inoltre, con molte di queste aziende hanno un ciclo di rilascio molto più breve, la produttività è spesso più importante della rigidità e un sacco di (base) il test è stato fatto dagli stessi sviluppatori.

L'altro motivo che le aziende enterprisey non usano lingue dinamicamente tipizzati costa codice legacy. Come sciocco come può sembrare a noi nerd, le grandi aziende spesso attaccano a soluzioni che funzionano, anche se sono ben oltre la loro shelf-life. Questo è il motivo per cui così tante grandi aziende fanno rispettare Internet Explorer 6 e sono così lenti ad aggiornare i loro sistemi operativi. Questo è anche il motivo per cui spesso scrivere nuovo codice in "vecchie" lingue (ad es antiche versioni di Java): è molto più facile aggiungere alcune righe di codice per un pezzo unliving di software che per ottenere l'approvazione per una completa riscrittura in una nuova lingua.

tl; dr:. linguaggi statici sentire più come la burocrazia, in modo da manager enterprisey come loro meglio

Answer 8

No, non credo lingue dinamicamente tipizzati meritano tutte le critiche. (O se si preferisce, che meritano tanto critica come lingue staticamente tipizzati.)

Nella mia esperienza (e faccio nessun tentativo di cercare di generalizzare questa affermazione), i programmatori che criticano linguaggi dinamici non li hanno utilizzati. La conversazione di solito va "ma con tipizzazione statica catture compilatore tanti errori!" e dico "bene, che non è solo un problema, nella mia esperienza". (Di solito l'altro programmatore di da una Java, Delphi o background simile,. Non so alcun programmatori Haskell o ML)

L'unica cosa che mi ha veramente lamentele è quando qualcuno reclami che la tecnica Foo non possono eventualmente essere fatto (o potrebbe essere molto difficile da fare) in un linguaggio tipizzato in modo dinamico ... quando quella tecnica è stato inventato in, da e per un linguaggio tipizzato in modo dinamico. IDE? Smalltalk. refactoring automatico? Smalltalk. I chiamanti-di / implementatori-di? Smalltalk.

Answer 9

Le imprese non sono solo l'adozione di nuovi linguaggi e strumenti abbastanza veloce e ci sono buone ragioni per questo. Ma, quando uno degli strumenti tradizionali come C # attuare alcune di queste caratteristiche, allora avranno filo nella corrente principale delle imprese ....