I linguaggi tipizzati dinamici meritano tutte le critiche? [chiuso]


35

Ho letto alcuni articoli su Internet sulla scelta del linguaggio di programmazione nell'impresa. Recentemente sono stati diffusi molti linguaggi tipizzati dinamici, ad esempio Ruby, Python, PHP ed Erlang. Ma molte aziende continuano a utilizzare linguaggi tipizzati statici come C, C ++, C # e Java.

E sì, uno dei vantaggi dei linguaggi tipizzati statici è che gli errori di programmazione vengono rilevati prima, in fase di compilazione, anziché in fase di esecuzione. Ma ci sono anche vantaggi con i linguaggi tipizzati dinamici. ( altro su Wikipedia )

Il motivo principale per cui le aziende non iniziano a usare linguaggi come Erlang, Ruby e Python, sembra essere il fatto che siano tipizzati in modo dinamico. Questo sembra anche essere il motivo principale per cui le persone su StackOverflow decidono contro Erlang. Vedi Perché hai deciso "contro" Erlang .

Tuttavia, sembra esserci una forte critica contro la tipizzazione dinamica nelle imprese, ma non capisco perché sia così forte.

Davvero, perché ci sono così tante critiche contro la tipizzazione dinamica nelle imprese? Incide davvero tanto sul costo dei progetti o cosa? Ma forse mi sbaglio.


3
Penso che la tipizzazione statica con l'inferenza del tipo e la possibile digitazione anatra sia il modo migliore per fare le cose. È anche molto complicato
Casebash,

2
Ho appena dato un'occhiata alla tipizzazione di anatre di C # (non uso la lingua), e mentre sembra soddisfare la definizione di tipizzazione di anatre, la verbosità richiesta sembra vanificare lo scopo. Questo non vuol dire che a volte non sia utile.
Chinmay Kanchi,

3
Sono solo io o ci sono più critiche nei confronti dei linguaggi tipicamente statici rispetto a quelli tipicamente dinamici? Inoltre, nella mia esperienza, le scelte linguistiche / tecnologiche delle grandi "imprese" sembrano essere dettate dalle tendenze attuali / scelte sicure piuttosto che da un reale merito tecnico.
MAK

2
@ChinmayKanchi: Verbosity? Devi solo dichiarare qualcosa come dynamice iniziare a usarlo. Non è più dettagliato delle normali chiamate di metodo o sovraccarichi dell'operatore.
Joey,

4
Non riesco a contare il numero di ore che ho perso con gli errori di debug della mia attuale azienda nel codice Groovy on Grails, che il compilatore avrebbe rilevato immediatamente se avessimo usato Java.
WKS,

Risposte:


46

Sì, credo che lo facciano.

Ci sono alcuni motivi che devono essere considerati nella selezione di una lingua per un nuovo progetto:

  • Velocità di runtime. Rispetto a C / C ++ / Fortran, Perl e Python sono così lenti che è divertente.
  • Velocità di inizializzazione. Rispetto alle lingue veloci sopra, Java cade e piange mentre la JVM continua a caricare e caricare e ... while(1)....
  • Prototype-abilità. Esaminare in modo esaustivo e facendo il lavoro di dichiarazione / definizione richiesto per C ++ o Java aumenta il LOC, che è l' unica metrica nota che si correla in modo affidabile con i conteggi dei bug. Ci vuole anche molto tempo. Richiede anche un po 'più di pensiero su tipi e connessioni.
  • Fiddlability interna. Fare scherzi dinamici con gli interni è fantastico fino a quando non si inizia a eseguire il debug del codice di auto-modifica . (Python, Lisp, Perl)
  • Verifica della correttezza. Un compilatore può fornire un rapido passaggio di semi-correttezza del tuo codice in C ++, e questo può essere davvero bello.
  • Dettagli di analisi statica. C e Java hanno un'analisi statica piuttosto buona. Perl non è completamente staticamente analizzabile a livello teorico (eventualmente anche Python). Sono ragionevolmente sicuro che neanche Lisp.
  • Le piattaforme strane prendono solo C, in generale.
  • Catena di supporto. Se si può avere un contratto che sarà ottenere i bug guardato e ha lavorato su, questo è enorme .

Se puoi presumere che l'organizzazione con cui stai lavorando abbia un principio di "Andare avanti" (c'è un termine contabile per questo) e non deciderai semplicemente di non lavorare sul software in modo casuale, allora hai un caso molto migliore per utilizzando il software. Dal momento che non ci sono vendite di grandi aziende (implicando l'assunzione della responsabilità di mantenerlo) Python / Perl / $ dynamic_language, riduce considerevolmente il rischio.

Nella mia esperienza, i manutentori dell'open source hanno spesso un problema con la piena responsabilità per le correzioni di bug e il rilascio di aggiornamenti. "È gratis, ci lavori!" non è una risposta accettabile per la maggior parte delle aziende (non le loro competenze fondamentali, tra le altre cose).

Naturalmente, non sto parlando del mondo delle webapp / startup, che tende a giocare secondo regole ad alto rischio / alta ricompensa ed essere molto aperto a rimanere all'avanguardia della tecnologia.


16
"È gratis, ci lavori!" <- Il più grande problema con F / OSS in generale, farei +1 ma non ho voti :(
Billy ONeal

4
Bel riassunto. Affermerò che i tipi ben costruiti trasmettono un significato semantico (posso guardare un tipo e capire cosa fa, come può essere usato) e posso essere usato per imporre la correttezza (posso costruire un tipo che accetta solo inpus vincolato ) e non ottengo errori stupidi da errori di battitura (odio la dichiarazione con variabile automatica)
smithco

4
Puoi ottenere supporto commerciale per qualsiasi grande progetto open source. Le grandi aziende usano PL tipizzato dinamicamente per parti grandi (sicuramente adatte), Facebook usa PHP (UI) ed Erlang (chat), Twitter usa Ruby (UI), Google usa Python (non so per cosa) e Lisp e Python sono utilizzato in molti sofisticati progetti di ricerca. Nota: sono uno sviluppatore C # che non ho (quasi) mai usato un linguaggio tipizzato dinamicamente; tuttavia questi punti non sono validi in larga misura.
Kaveh Shahbazian,

4
Mi piace la tua risposta ma Java non viene digitato in modo dinamico ...
Mehrdad,

2
@PaulNathan: Stai pensando troppo. La domanda era relativa ai linguaggi tipizzati dinamicamente e questa risposta menziona Java come se fosse tipizzato dinamicamente.
Mehrdad,

24

Stai dando troppo credito tecnico ai decisori aziendali. C'è un vecchio detto: "Nessuno è stato licenziato per aver acquistato IBM". Se percorri una strada diversa e le cose diventano rocciose (lo fanno sempre), nessuno vuole rischiare di essere incolpato. Attenersi agli standard e incolpare qualcun altro.

Ci sono molte aziende più giovani che alla fine diventeranno le imprese di domani e useranno quelle lingue.

E non dimentichiamoci delle migliaia di righe di codice scritte in VBA!


1
+1 per "... le imprese di domani [e] useranno quelle lingue."
rdmueller,

6
"Ci sono molte aziende più giovani che alla fine diventeranno le imprese di domani e useranno quelle lingue." D'altra parte, i linguaggi dinamici esistono già da molto tempo.
Giorgio,

17

La ragione per cui le aziende usano C, C ++, C # e Java non è perché sono tipizzate staticamente (almeno non direttamente). I decisori aziendali non stanno facendo questo tipo di scelte sulla base di un confronto oggettivo dei sistemi di tipi, ti assicuro.

Le imprese fanno cura di:

  • Costi di manutenzione a lungo termine : puoi ragionevolmente aspettarti che le cose continuino a funzionare bene tra 10 anni? In realtà è una buona cosa se l'evoluzione del linguaggio è conservativa e retrocompatibile (come con Java). La tipizzazione statica è utile qui perché rileva un importante tipo di bug in fase di compilazione prima che entrino nei tuoi sistemi di produzione .....
  • Disponibilità di talenti : riuscirai a trovare gli sviluppatori per mantenere il tuo nuovo brillante sistema? cosa succede se lo sviluppatore originale lascia, tutti capiranno il codice? Ciò pone un grande ostacolo nell'introduzione di qualsiasi "nuovo" linguaggio (soprattutto se crea anche nuovi requisiti per la distribuzione, la creazione di sistemi, il supporto operativo ecc.). Ciò offre enormi vantaggi ai linguaggi ampiamente utilizzati (C, C ++, C # e Java)
  • Costi di integrazione : è facile connettersi / integrarsi con altre tecnologie già in uso o che è probabile che si acquisiscano? Se hai già una pila di sistemi J2EE legacy, devi integrarti con loro. Una nuova soluzione Java EE sarà probabilmente molto più pratica per questo rispetto ad esempio a Python.
  • Prevedibilità / basso rischio : la piattaforma / il linguaggio sono comprovati e posso essere sicuro che funzionerà? Questo di solito è più importante della semplice produttività. È molto più facile per un manager persuadere il suo capo a dargli un grosso budget per la forza lavoro per costruire un nuovo sistema di quanto non lo sia per lui tornare più tardi e dire che non ha funzionato .....
  • Supporto / supporto aziendale : le principali organizzazioni internazionali sono impegnate a supportare la lingua e la piattaforma? Firmeranno un contratto per supportarmi in modo che io abbia qualcuno a cui rivolgersi se le cose vanno male?
  • Neutralità del fornitore / indipendenza della piattaforma - sto per rimanere bloccato in un unico fornitore? O ho una vasta gamma di opzioni di fornitori / percorsi di transizione futuri disponibili? Non vuoi rimanere bloccato in un vicolo cieco architettonico, incapace di fare progressi mentre i tuoi concorrenti mangiano il tuo pranzo. Se stai facendo il tuo lavoro correttamente come architetto aziendale, devi pensare con almeno 5-10 anni di anticipo su queste cose.

Personalmente, penso che se vuoi usare linguaggi dinamici nell'Enterprise, allora la tua migliore possibilità è di usare qualcosa che si ripercuota su un ecosistema aziendale esistente. I più importanti sono i nuovi linguaggi JVM dinamici: ad es. JRuby, Groovy, Clojure. Per quanto riguarda la gestione IT, si tratta di scelte linguistiche dinamiche "sicure" perché operano all'interno e giocano bene con il resto dell'ecosistema aziendale Java.


1
Non posso credere che nessuno abbia ancora votato la tua risposta.
Sebastian N.

11

Il motivo principale per cui le aziende non iniziano a usare linguaggi come Erlang, Ruby e Python, sembra essere il fatto che siano tipizzati in modo dinamico.

Penso che questa sia solo la loro scusa principale. Il vero motivo è che le aziende non li prendono davvero sul serio e pensano che forse sono un po 'troppo dilettanti. Java e .NET sono "nomi di grandi aziende", hanno un buon marketing commerciale, supporto ai clienti commerciali e sono quindi ampiamente presi sul serio.

È un peccato che in pratica non esista un linguaggio tipicamente statico così popolare come i nomi delle grandi aziende. Perché gli ambienti di programmazione open source / software libero sono quasi sempre tipizzati in modo dinamico? Ciò potrebbe indicare che un linguaggio tipicamente statico in realtà non è così facile da realizzare, e che la digitazione dinamica è un "trucco da uomo pigro". In tal caso, le aziende che decidono contro lingue tipizzate dinamicamente potrebbero avere un punto.


8
Veramente? L'ultima volta che ho visto, Google aveva lanciato un bel po 'di peso e un notevole sforzo di sviluppo dietro Python, incluso l'assunzione del creatore di Python e che gli permetteva di trascorrere il 50% del suo tempo lavorando sulla lingua. Google fornisce anche una buona quantità di codice a Python, soprattutto ora che unladen-swallow è stato unito all'albero dei sorgenti di Python 3. Ciò rende Python un "grande nome commerciale" per me.
Chinmay Kanchi,

13
@Chinmay Kanchi: interessante il modo in cui trai le tue conclusioni da una statistica con una dimensione del campione di 1.
Timwi

6
Touché. Tuttavia, anche alcune delle tue conclusioni sono errate. L'implementazione corretta di un linguaggio dinamico è molto più difficile rispetto all'implementazione di un linguaggio tipicamente statico. La digitazione dinamica non è certamente un "trucco da uomo pigro" come dici tu. Permette agli sviluppatori di essere pigri, ma non la persona che scrive il compilatore / interprete. In effetti, l'ottimizzazione di un linguaggio tipizzato in modo dinamico è così difficile che riesco solo a pensare a una lingua che, negli ultimi tempi, ha ricevuto ampiamente questo trattamento (JavaScript), anche se ci sono progetti di ottimizzazione / JITting per altre lingue (Python, PHP).
Chinmay Kanchi,

2
Inoltre, se pensi che i linguaggi tipizzati dinamicamente siano i più comunemente utilizzati in ambienti open source, questo è tutt'altro che chiaro. A seconda della metrica scelta, questo potrebbe essere vero, ma spesso non lo è. Misurando linee di codice, C vince con un tiro lungo. Se si misurano le lingue utilizzate nei progetti open source, compresi quelli multilingue, le lingue più popolari sono JavaScript, C, C ++ e PHP in questo ordine. Se si misura solo la lingua principale, le lingue più popolari sono Perl, Java, C # e JavaScript. bit.ly/C6xTB
Chinmay Kanchi

7
Ovviamente scrivere un ottimizzatore per le lingue tipizzate dinamicamente è difficile, ma non un interprete : puoi fare a meno di tutto il controllo dei tipi, e il resto è lo stesso. Nessun produttore di lingue amatoriale pensa di scrivere un ottimizzatore. - Per quanto riguarda l'ultimo bit, non intendevo implicare che la maggior parte dei software open source sia scritta in un linguaggio di programmazione tipizzato in modo dinamico, ma piuttosto che la maggior parte dei linguaggi di programmazione open source (ho detto "ambienti" perché sto parlando di compilatori / interpreti, IDE, ecc.) sono tipizzati in modo dinamico.
Timwi,

9
  • Le lingue tipizzate dinamicamente tendono ad essere più lente dei loro cugini tipicamente statici.
  • Gli errori sono più difficili da rilevare e possono essere più difficili da eseguire il debug
  • Il compilatore / interprete tende ad essere molto meno esigente su ciò che puoi e non puoi fare. vale a dire, praticamente si rilevano solo errori di sintassi in fase di compilazione
  • Se non stai molto attento alla progettazione di un linguaggio tipizzato in modo dinamico, finisci con Javascript, che è la lingua degli odori di codice

EDIT: dovrei menzionare che il mio principale linguaggio di programmazione al momento è Python, che viene digitato in modo dinamico. Personalmente, adoro la libertà che deriva dal non dover pre-dichiarare le variabili, ma a volte sarebbe bello specificare (ad esempio) quale tipo di parametri richiede una funzione per rilevare gli errori in anticipo piuttosto che in ritardo.


1
Mentre è vero che il compilatore non è fastidioso, l'interprete di solito lo è. Per la maggior parte, l'interprete rileva situazioni problematiche e segnala errori.
Winston Ewert,

17
Adoro la digitazione dinamica ma odio non dover dichiarare le variabili! Tante volte finisco per introdurre accidentalmente una nuova variabile perché ho sbagliato a scrivere un nome di variabile.
Frank Shearar,

1
@Frank: amo in modo inimmaginabile che Perl abbia un'impostazione per forzare la dichiarazione delle variabili. È uno dei vantaggi di Perl, secondo me.
Paul Nathan,

8

I linguaggi tipizzati dinamicamente vengono percepiti (da alcuni programmatori / boss) per produrre codice che non funziona altrettanto bene. Il fatto che un programma digitato in modo dinamico compili ti dice molto poco sulla sua correttezza. Il fatto che venga compilato un linguaggio tipizzato staticamente ti dice molto di più. (D'altra parte, c'è ancora molta strada tra le compilazioni e fa la cosa giusta, quindi questo potrebbe essere meno significativo di quanto sembri)

Le lingue tipizzate dinamicamente sono percepite come linguaggi di scripting. Non scriveresti mai un'applicazione in bash o in un file batch. Tutte le lingue tipizzate dinamicamente tendono ad essere inserite in quella categoria (ingiustamente).

Le lingue tipizzate dinamicamente sono più lente delle lingue tipizzate staticamente. (Ma vedremo quanto bene il lavoro su JIT lo cambi)


2
"Sono percepiti da" alcuni programmatori. Quando ho discussioni con i programmatori sulla digitazione dinamica, di solito finiscono per ammettere di non aver mai usato quel tipo di linguaggio.
Frank Shearar,

1
@Frank stai dicendo che le persone che sostengono l'inferiorità della tipizzazione dinamica in genere non l'hanno usata?
Winston Ewert,

2
@Frank: ho usato quel tipo di linguaggio, e il più delle volte il risultato è stato un casino non mantenibile. (Per essere onesti, era PHP, e PHP ha altri problemi oltre alla tipizzazione dinamica)
Billy ONeal

@Billy: penso che questo sia comune. Sono stato giù per anni sulla tipizzazione dinamica a causa della mia esperienza con VB - quando alla fine mi sono reso conto che questa terribile implementazione schizofrenica della tipizzazione dinamica non era tipica, la mia opinione è cambiata radicalmente.
Shog9

@ Winston: sto dicendo che le persone con cui ho discusso no. Per me è stato un caso "la tipizzazione dinamica non può assolutamente funzionare" ... ma useranno felicemente molte tecniche sviluppate per la prima volta in, da e per linguaggi dinamici (IDE, refactoring, al di sopra della mia testa). Inoltre, domande come questa: stackoverflow.com/questions/2317579 indicano che, sebbene probabilmente non sia universale, il mio caso di discutere con i programmatori che non possono funzionare ma che non ho provato non è isolato. (Io, penso che entrambi gli approcci abbiano valore.)
Frank Shearar,

8

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

Le lingue tipizzate dinamicamente sono molto diverse dalle lingue tipizzate staticamente. Queste differenze probabilmente diventano più importanti nel software aziendale pesante rispetto alla maggior parte delle altre applicazioni.

Le lingue tipizzate staticamente tendono ad essere molto prescrittive. Un metodo prenderà solo input che corrispondono esattamente alla sua firma. I livelli di accesso tendono ad essere molto importanti e le interfacce sono definite in modo esplicito, con restrizioni dettagliate ma inequivocabili in atto per applicare tali definizioni.

D'altra parte, le lingue tipizzate dinamicamente sono molto pragmatiche. Le conversioni di tipo spesso avvengono in modo implicito, le funzioni possono persino giocare se si fornisce un tipo di input errato purché si comporti in modo sufficientemente simile. In lingue come Python, anche i livelli di accesso saranno basati sul contratto piuttosto che sulle restrizioni tecniche (cioè è solo privateperché ti viene detto di non usarlo e ha un nome divertente).

Molti programmatori preferiscono linguaggi dinamici perché (probabilmente) consentono la prototipazione rapida. Il codice spesso finisce più corto (se non altro a causa della mancanza di dichiarazioni di tipo) e se vuoi violare il protocollo corretto perché hai bisogno di una soluzione rapida e sporca o vuoi testare qualcosa, è facilmente possibile.

Ora, la ragione per cui le aziende "enterprise" spesso preferiscono linguaggi tipizzati staticamente è esattamente che sono più restrittive e più esplicite su tali restrizioni. Sebbene in pratica anche il codice tipicamente statico possa essere infranto dagli idioti con un compilatore, molti problemi saranno molto più visibili molto prima nel processo (cioè prima del runtime). Ciò significa che anche se la base di codice è grande, monolitica e complessa, molti errori possono essere colti facilmente, senza dover eseguire il codice o inviarlo al reparto QA.

La ragione per cui il vantaggio non supera gli svantaggi di molti programmatori al di fuori di quell'ambiente è che si tratta di errori che spesso possono essere facilmente rilevati da un'accurata ispezione del codice o anche dal tentativo di eseguirlo. Soprattutto quando si segue una metodologia guidata dai test, questi errori diventano spesso banali da catturare e facili da correggere. Inoltre, con molte di queste aziende che hanno un ciclo di rilascio molto più breve, la produttività è spesso più importante della rigidità e molti test (di base) vengono eseguiti dagli stessi sviluppatori.

L'altro motivo per cui le società aziendali non usano molto i linguaggi tipizzati in modo dinamico è il codice legacy. Per quanto sciocchi possano sembrare noi nerd, le grandi aziende si attengono spesso a soluzioni che funzionano, anche se sono ben oltre la loro shelf-life. Questo è il motivo per cui così tante grandi aziende applicano Internet Explorer 6 e sono così lente ad aggiornare i loro sistemi operativi. Questo è anche il motivo per cui spesso scriveranno un nuovo codice in "vecchie" lingue (ad es. Versioni antiche di Java): è molto più facile aggiungere alcune righe di codice a un software non vivente che ottenere l'approvazione per una riscrittura completa in un nuovo linguaggio.

tl; dr: i linguaggi statici sembrano più una burocrazia, quindi ai dirigenti di impresa piacciono di più.


3
Le lingue con regole di digitazione vaghe creano molte opportunità per cose che sono sbagliate in un certo senso. In JavaScript, ad esempio, passare un numero al codice che prevede una stringa spesso si comporterà come se si fosse passato una rappresentazione di stringa di quel numero, ma non sempre. Cercare di aggiungere, ad esempio, l'appendice da 456 a 123 non produrrà 123456, ma produrrà invece 579. A meno che non sia chiaro chi è responsabile della conversione da numero a stringa, può essere eseguito in modo ridondante o non riuscire a farlo.
supercat,

1
@supercat, penso che PHP e JavaScript siano buoni esempi dei due modi di affrontare quel problema (per quanto riguarda gli operatori): in PHP gli operatori sono inequivocabili - +prende i numeri e li aggiunge, se vuoi concatenare devi usare .; in JS entrambe le operazioni condividono lo stesso operatore: se non sai come si comporteranno i tuoi valori, dovrai convertirli esplicitamente. Naturalmente questo ha a che fare anche con la digitazione libera rispetto alla digitazione rigorosa (Python è ancora più rigorosa), ma in sostanza devi assicurarti che i tuoi valori abbiano il tipo giusto o che le tue operazioni facciano rispettare i tipi previsti.
Alan Plum,

1
Non conosco molto bene PHP, ma sembra che usi quello che definirei l'approccio "giusto". Javascript è IMHO abominevole in molti modi, ma penso che il comportamento di "+" sia uno dei peggiori. In realtà, non sono convinto che la tipizzazione dinamica vagamente sfacciata avrebbe molto vantaggio rispetto a un sistema di tipo più forte che permettesse a un'interfaccia di dichiarare che cose di qualche altra classe o tipo di interfaccia dovrebbero essere considerate come implementate o derivate da essa, con regole specifiche su come dare priorità ai reclami. La grande limitazione di cui sono a conoscenza con gli attuali framework strutturati tipicamente è che ...
supercat

1
... se due persone sviluppano in modo indipendente interfacce simili, non c'è modo per una terza parte di scrivere codice in grado di usarle in modo intercambiabile. Se una terza parte potesse definire una nuova interfaccia e dichiarare che le implementazioni di una o entrambe quelle esistenti dovrebbero implementare automaticamente quella nuova (usando i wrapper forniti nella nuova interfaccia se necessario) penso che gestirà il 99% di ciò che è semanticamente bene sulla digitazione dinamica.
supercat

3

No, non credo che i linguaggi tipizzati dinamicamente meritino tutte le critiche. (O se preferisci, meritano tante critiche quanto le lingue tipizzate staticamente.)

Nella mia esperienza (e non faccio alcun tentativo di generalizzare questa affermazione), i programmatori che criticano i linguaggi dinamici non li hanno usati. La conversazione di solito va "ma con la digitazione statica il compilatore rileva così tanti errori!" e dico "beh, non è un problema, nella mia esperienza". (Di solito l'altro programmatore proviene da Java, Delphi o background simili; non conosco nessun programmatore Haskell o ML.)

L'unica cosa che mi affligge davvero è quando qualcuno afferma che la tecnica Foo non può essere eseguita (o potrebbe essere molto difficile da fare) in un linguaggio tipizzato in modo dinamico ... quando quella tecnica è stata inventata in, da e per un tipo digitato in modo dinamico linguaggio. IDE? Smalltalk. Refactoring automatico? Smalltalk. I chiamanti-di / implementatori-di? Smalltalk.


Non volevo ingombrare la mia risposta con la mia posizione personale, che è questa: lo strumento giusto per il lavoro giusto. Qualunque sia il tipo di linguaggio che usi è più adatto per alcuni compiti, e peggio per altri, di un altro tipo di linguaggio.
Frank Shearar,

6
Quando l'altro programmatore viene da Haskell, sa già che è il linguaggio superiore sia a Java che a linguaggi dinamici;)
Andres F.

0

Le aziende non stanno adottando nuove lingue e strumenti abbastanza velocemente e ci sono buone ragioni per farlo. Ma quando uno degli strumenti tradizionali come C # implementerà alcune di queste funzionalità, entreranno nelle aziende tradizionali ...


Non so perché sia ​​stato sottoposto a downgrade, ma è un'affermazione approfondita. Le imprese sono lente e prudenti. Le persone preferiscono anche il cambiamento graduale (come la parola chiave dinamica in C # che consente di utilizzare occasionalmente la digitazione dinamica in un linguaggio tipicamente statico) per un cambiamento improvviso (come Ruby).
Vaddadi Kartick,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.