Quale lingua di basso livello di prossima generazione è la migliore scommessa durante la migrazione di una base di codice? [chiuso]

https://stackoverflow.com/questions/1815613

07-07-2019
|

Domanda

Supponiamo che tu abbia un'azienda che gestisce molto C / C ++ e desideri iniziare a pianificare la migrazione verso nuove tecnologie in modo da non finire come le società COBOL 15 anni fa.

Per ora, C / C ++ funziona più che bene e ci sono molti sviluppatori sul mercato per questo.

Ma ora vuoi iniziare a pensarci, perché data l'enorme base di codice in esecuzione e la sensibilità dei dati, ritieni che possano essere necessari 5-10 anni per passare al passaggio successivo senza sovraccaricare il budget e i team di sviluppo.

Hai sentito parlare di D , iniziando a essere abbastanza maturo, e Vai , promettendo di essere abbastanza popolare.

Quale sarebbe la tua scelta e perché?

Soluzione

D and Go probabilmente diventeranno popolari quanto lo sono oggi Python e Ruby. Ognuno di loro riempie una nicchia, e anche se D doveva essere una sostituzione a tutti gli effetti del C ++, probabilmente non acquisirà mai abbastanza massa per allontanare il C ++. Per non parlare del fatto che entrambi non sono abbastanza stabili / abbastanza maturi ed è sconosciuto se tra 10-20 anni avrai il supporto per queste lingue per l'hardware e i sistemi operativi attuali. Considerando che C / C ++ è praticamente la lingua compilata e viene utilizzata nella stragrande maggioranza dei sistemi operativi e delle applicazioni in codice nativo, è molto improbabile che scompaia nel prossimo futuro.

Altri suggerimenti

C e C ++ sono una combinazione praticamente imbattibile quando si tratta di nativo / non gestito / "basso livello" lingue.

Non perché sono le migliori lingue, tutt'altro, ma perché sono lì, fanno il loro lavoro e sono abbastanza bravi . Non c'è dubbio che D, per esempio, è meglio di C ++ per molti aspetti. Ma fallisce in quello più importante: compatibilità con tutto il codice C ++ esistente. Senza tale requisito, la maggior parte di quel codice verrebbe comunque scritta oggi in una lingua gestita. L'unica ragione per cui così tante basi di codice usano il C ++ oggi è perché l'hanno usato l'anno scorso e sarebbe troppo doloroso passare a qualcos'altro. Ma se e quando cambiano, in genere non passano a D. Passano a C # o Java o Python.

Il problema per D e altri "in arrivo" le lingue in competizione per le stesse nicchie, è che mentre sono migliori, non sono abbastanza innovative da motivare le persone a passare effettivamente a loro.

Quindi C e C ++ sono qui per restare. È improbabile che C evolva ulteriormente. È così com'è, e una delle nicchie che deve riempire è "semplicità, anche per gli scrittori di compilatori". Nessun'altra lingua è in grado di batterlo in quella nicchia, anche se non rivedranno mai più lo standard.

Il C ++ si sta evolvendo molto più drammaticamente, con il C ++ 0x che si avvicina e hanno già un enorme elenco di funzionalità che vogliono fare in seguito . Il C ++ non è in alcun modo un vicolo cieco.

Entrambe le lingue sono qui per restare. Forse tra 50 anni altre lingue li avranno sostituiti, ma non accadrà in questo decennio.

Attualmente uso D regolarmente. Non lo consiglierei ancora a chi scrive codice di produzione perché è troppo sanguinante. Me ne vado perché la maggior parte del mio codice sono prototipi di ricerca in bioinformatica. Tuttavia, la lingua sta iniziando a stabilizzarsi. Andrei Alexandrescu sta pubblicando un libro intitolato "The D Programming Language" il prossimo marzo, e proprio ora c'è una spinta per stabilizzare le specifiche per la versione 2 della lingua in tempo per il libro.

Sebbene D non sia un superset formale di C, è quello che definirei un superset idiomatico, tranne per la mancanza di un preprocessore. In altre parole, qualsiasi codice scritto in C proprio (ignorando il preprocessore), può essere banalmente tradotto in D senza una riprogettazione, perché concetti C come puntatori e ASM in linea sono presenti e funzionano allo stesso modo in D come in C. D supporta anche direct il collegamento al codice C e alla libreria standard D include l'intera libreria standard C.

Inoltre, nonostante la mancanza di librerie di D perché è ancora un linguaggio spietato, è il sogno di uno scrittore di biblioteche a causa delle sue capacità di metaprogrammazione. Se decolla, probabilmente avrà delle librerie piuttosto impressionanti. Per un'anteprima di ciò, vedi std.range o std.algorithm nella libreria standard D2 (Phobos). Come altro esempio, ho implementato un modello di parallelismo simile a OpenMP (foreach parallelo, mappa parallela, riduzione parallela, futures) come una libreria pura in D, senza alcun supporto compilatore speciale. (Vedi http://cis.jhu.edu/~dsimcha/parallelFuture.html )

Dato che sei principalmente interessato a lungo termine, direi di dare a D 6 mesi per stabilizzarsi (dato il libro di Andrei e l'attuale spinta a stabilizzare la lingua, la versione 2 dovrebbe essere stabile a quel punto) e quindi prendere un sguardo duro.

Modifica: ora che le specifiche del linguaggio principale sono relativamente stabili e l'attenzione si è concentrata sullo sviluppo di toolchain e librerie, io consiglierei D per piccoli progetti di produzione a meno che non ci si trovi in ??un ambiente molto avverso al rischio . Tuttavia, i progetti più grandi che devono assolutamente disporre di un buon supporto per toolchain e librerie dovrebbero comunque attendere.

Se credi nei principi di produzione snella, dovresti cercare di "decidere il più tardi possibile". Il momento dovrebbe essere l'ultimo momento responsabile, ovvero il momento in cui la mancata decisione elimina un'alternativa importante.

Penso che questo principio possa essere applicato alla tua situazione. Invece di impegnarti ora in una lingua (che non sai nemmeno tra 10 anni), dovresti tenere aperte le tue opzioni. Magari refactificare parte del tuo codice in modo che sia un po 'più generico o sia basato su più astrazioni, in modo che quando sarà effettivamente necessario migrare, il processo sarà più semplice.

Stick con C e C ++. Non lo vedo andare come COBOL, funziona bene e niente, e non avrai problemi a trovare le persone a scrivere codice in C e C ++.

C ++ - è relativamente giovane e aggiornato ... Ha un gran numero di venditori di compilatori e ha ottenuto migliorato continuamente.

C - vivrebbe a lungo colmando il divario tra assemblatore e linguaggi di livello superiore. È anche molto semplice e facile da implementare il linguaggio, quindi rimarrebbe il prima lingua per vari "strani" architetture come quelle incorporate o estremamente nuove.

D è specifiche e librerie promettenti ma ancora molto nuove e instabili.

Go è nato poche settimane fa ... Non usare mai nulla della versione 0 per grandi progetti importanti. Inoltre è significativamente più limitato il C ++ o D .

Aggiornamento 2019: C ++ rimarrà in circolazione per i prossimi 10 anni ... (in caso contrario, correggerò questa risposta, quando non sarà più pertinente ....)

il motivo per cui le aziende lavorano oggi con COBOL è che hanno già scritto milioni di codice COBOL. se potessero lanciarlo - lo faranno immediatamente, d'altra parte - le aziende lavorano con C / C ++ come parte delle loro esigenze e nuovi progetti che usano questo linguaggio b / c che non possono / non vogliono usare java / c # qualsiasi altro linguaggio basato su framework - quindi COBOL non è l'analogia qui.

Come dsimcha ha detto che il modo D è attualmente rischioso. Eppure il linguaggio ha un enorme potenziale, è di basso livello e ho sperimentato una produttività drasticamente migliore con D (anziché C ++). Forse ciò che le persone provano con i linguaggi dinamici.

Go è così tanto commercializzato sul blog che mi sembra uno scherzo. L'invio di un metodo di interfaccia non è banale e in realtà più lento rispetto all'invio di un normale metodo di ereditarietà singola.

Se avessi un enorme codebase la decisione è ovviamente più difficile, consiglierei solo di passare a nuovi progetti, non a quelli esistenti.

Non mi concentrerei su una lingua ma più sulle biblioteche che la circondano. Il C ++ in combinazione con le librerie boost è una scelta eccellente. Le persone che sviluppano in C ++ tendono ad avere una migliore comprensione dell'informatica, io stesso ho iniziato con Java che mi ha semplificato la vita nascondendo molte cose fondamentali, il che è buono, tuttavia ho iniziato davvero a capire la programmazione solo dopo aver appreso C / C ++ (puntatori ecc.).

Riconosco che il C ++ può essere difficile (ad esempio la gestione della memoria), quindi penso che sia buono avere un linguaggio 'add on' in cui le prestazioni non sono essenziali e la leggibilità (== manutenibilità) ha un punteggio elevato: per questo consiglio Python.

Ci sono innumerevoli macchine che eseguono software C ++, non le vedo spegnere tutte in una volta. Se il C ++ ostacolerà COBOL, ci sarà un enorme mercato per la migrazione delle applicazioni. Saranno sviluppati strumenti specializzati per tradurre le applicazioni C ++ nella lingua popolare dell'epoca (Z ++ ???).

Quindi credo che il miglior consiglio sia quello di attraversare quel ponte quando ci arrivi.

Scopri Kit di sviluppo software Intel® Cilk ++ se vuoi suscitare il tuo interesse per lo sviluppo C ++ / Multi-Core. Non vedo C o C ++ sparire presto o presto.

Il confronto tra C * e Cobol è discutibile

Il confronto tra C * e Cobol può portare a conclusioni errate. C è stato perfetto per la sua giornata, un grande balzo in avanti nella sua introduzione, e fa ancora il lavoro oggi.

Riassumerei Cobol nel mio giorno più caritatevole con " bel tentativo " ;.

C e C ++ sopravviveranno a lungo perché si adattano bene al conto e ai linguaggi di implementazione. Questo non cambierà mai veramente.

Inoltre, considera che il principale problema negativo con C / C ++ è la mancanza di sicurezza della memoria. Questo tende ad essere sempre meno un problema man mano che i codici maturano. Ciò significa che non ci sarà una ragione seria per sostituire i vecchi codici.

Mi aspetto che i sistemi software crescano verso l'esterno da C. Guarda la gerarchia oggi:

applicazione scritta in un framework come Rails
back-end dell'applicazione scritto in Ruby, PHP, Python, C #, qualunque cosa
Implementazione runtime di Ruby, PHP, Python o C # (scritta in C *)
kernel OS (scritto in C89)

Non penso che i vecchi strati svaniranno, e penso che i livelli superiori legacy scritti in C e C ++ saranno semplicemente supportati in quel modo per un periodo di tempo indefinito, alla fine saranno gradualmente eliminati per i loro sostituti scritti in Ruby, Python , C # o uno sviluppo futuro.

Non abbiamo idea se Go troverà accettazione. Il solo fatto di essere su Google non sarà probabilmente sufficiente.

D? Bene, alcune cose carine si stanno dicendo, ma non decollerà neanche. Nessuna base di utenti di cui parlare. D è il numero 20 in popolarità nell' TIOBE Index e cadendo velocemente.

Potresti dire che la popolarità di una lingua ha poco a che fare con quanto sia adatta al lavoro della tua azienda. Ma ha molto a che fare con quanto sarà facile trovare persone qualificate per programmare in esso.

Java è in cima e sarei sorpreso se andasse lontano nei prossimi 20 anni. Non è considerato un linguaggio di programmazione dei sistemi ma si comporta abbastanza bene che ci sono poche attività che faresti in C ++ che non potresti in Java. Certamente in questi giorni nessuno è disposto a incaricare i programmatori umani del lavoro svolto (in modo impeccabile e spesso più efficacemente) dal garbage collector. Personalmente, ho considerato Java un significativo passo avanti rispetto al C ++ in termini di efficacia della programmazione.

Sono abbastanza impressionato da Ruby . È un linguaggio elegante ed espressivo: puoi fare molto con non troppo codice, ma quel codice è ancora per lo più leggibile. Uno dei principi principali di Ruby è quello di essere coerenti e non tenere sorprese per lo sviluppatore. Questa è un'ottima idea, IMO, e aumenta la produttività. Al tempo del grande clamore di Rails (che potrebbe essere ancora in corso), ho fatto un largo giro intorno a Ruby perché la sua implementazione di riferimento è spaventosamente lenta. Tuttavia, le persone JRuby di Sun hanno reso incredibilmente veloce su una JVM, quindi ora vale sicuramente la pena prendere in considerazione. Ruby offre chiusure e una buona manciata di capacità di programmazione funzionale (vedi sotto per questo importante), sebbene non sia davvero considerato un linguaggio FP. Indice TIOBE: 10 e in aumento.

Qualcosa da considerare per il futuro è il fatto che i produttori di CPU si sono imbattuti in un limite di prestazioni imposto dalla fisica. Ogni Natale non è più disponibile una CPU più veloce del 30%, come in passato. Quindi ora per ottenere più prestazioni hai bisogno di più core. Lo sviluppo del software avrà bisogno di tutto l'aiuto possibile per supportare la programmazione simultanea multi-core. C ++ ti lascia per lo più solo con questo, e le soluzioni Java sono orribili per gli standard moderni.

In considerazione di ciò, c'è una certa tendenza verso la programmazione funzionale (che elimina gran parte della seccatura associata alla concorrenza) così come i linguaggi con un migliore supporto della concorrenza. Erlang è stato scritto appositamente per questo e per la possibilità di scambiare codice in un programma in esecuzione (Ericsson voleva tempi di attività incredibili). Scala è simile a Java ma con un supporto molto più forte per la programmazione funzionale e la concorrenza. Clojure , idem, ma è un Lisp e non è nemmeno tra i primi 50 (ancora !!).

Scala è stato sviluppato da accademici e lo dimostra: è sofisticato e decisamente pedante riguardo ai tipi di dati; cerca di essere il coltellino svizzero di linguaggi di programmazione. Credo che un sacco di programmatori medio-intelligenti avranno difficoltà a prendere confidenza con Scala. Ruby è meno FP e non fa molto per quanto riguarda la concorrenza, ma è pragmatico, divertente e facile da svolgere. Inoltre, in esecuzione su JVM, c'è un'enorme quantità di codice prontamente disponibile nelle librerie Java, che Ruby può interfacciarsi con. Quindi:

La mia scommessa sarebbe su Ruby, con una possibilità esterna su Scala. Ma ci sono molte alternative!

Java. Per la maggior parte delle cose di basso livello Java va bene in questi giorni. Perché scegliere una soluzione parziale a C / C ++ come D o Go quando puoi avere qualcosa di altrettanto sicuro e facile da sviluppare come Java? Se stai cercando una soluzione in tempo reale, D e Go sono sicuramente non , per non parlare del fatto che probabilmente sono anche meno supportati di Java.

Java ora è un linguaggio di programmazione del sistema . Non vedo come puoi considerare qualsiasi cosa con costrutti non sicuri come puntatori "next gen". L'unica ragione per cui quei costrutti insicuri sono mai esistiti è perché era l'approccio pragmatico alla costruzione di un linguaggio completo turing. Non c'era alcuna preoccupazione di rappresentare la memoria in oggetti discreti, perché volevano solo costruire qualcosa che funzionasse . Esistono già applicazioni hardtime soft e soft in Java, una varietà di processori hardware bytecode e oltre 2 miliardi di dispositivi mobili che eseguono Java. Al massimo tutto ciò che dovresti fare è aggiungere alcuni costrutti per l'interoperabilità con i dispositivi, che non sarebbero tanto codice; anche in C / C ++ dovresti comunque aggiungere questi costrutti ...

Che cosa stai programmando? Microcontrollori a 8 bit con ram da 1KB? In tal caso, sarebbe inutile usare qualcosa di diverso dall'assemblatore per quella piattaforma ...

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow