Gli ingegneri del software hanno davvero bisogno di sapere cose di basso livello? [chiuso]

Mentre si stanno sviluppando linguaggi di programmazione di alto livello come C #, Java, ecc., Molte persone affermano che saranno un'alternativa a linguaggi come il linguaggio assembly e C / C ++, che ti dà accesso e controllo all'hardware del computer, perché i programmatori dovrebbero concentrarsi sulla creazione del programma e sulla risoluzione dei problemi, senza perdere tempo a occuparsi del computer per farlo funzionare. Poiché l'hardware continua a migliorare, la differenza di prestazioni tra C / C ++ e Java non sarà significativa e i grandi giochi potrebbero essere programmabili in un linguaggio come Java.

Questa è l'idea generale che riassumo brevemente dopo aver esaminato questo argomento su Internet. Pensi che diventerà reale nel prossimo futuro? Significa che tutto ciò che apprendiamo su cose di basso livello non è più pratico per l'industria del software? Ciò significa che il linguaggio assembly e C / C ++ diventeranno rilevanti solo per gli ingegneri elettrici, dal momento che sarebbero gli unici a dover programmare per i loro componenti elettrici?

---

Quanto è sufficiente l'apprendimento? Se imparassimo troppe cose di basso livello, alla fine diventeremmo più orientati all'ingegneria elettrica o se imparassimo troppa matematica, potremmo imparare a diventare matematici, non programmatori. Voglio solo sapere se le cose matematiche che ho imparato (ho seguito un corso di matematica che copre il materiale simile a questo libro (hanno usato diversi libri di testo): matematica discreta e la sua applicazione) sono effettivamente utili quanto il nostro set di abilità di programmazione. Molti esercizi di matematica possono richiedere la maggior parte di noi ore per farlo, e se lo fai sul serio, avrai meno tempo per studiare la programmazione. Nel nostro forum su gamedev, anche la matematica e la fisica hanno solo una sezione per confrontarla con quelle di programmazione.

In questo momento ho appena iniziato a leggere "The Art of Computer Programming". La matematica è trattata solo in circa un quarto del libro, ma l'esercizio è difficile per noi non matematici. Persino tale matematica "elementare", l'abbiamo usata tanto nella nostra carriera? Alcune persone probabilmente mi direbbero che leggere il libro TACOP è una perdita di tempo e probabilmente dovrebbe dedicare del tempo a qualcos'altro di più pratico, anche se il libro è incentrato sulla programmazione (un po 'più accademico rispetto al libro spiega cose simili). Ma penso che l'autore abbia dedicato molto tempo e sforzi per produrlo. Può persino scrivere l'intero set di 5 libri, mentre noi - il pubblico - abbiamo solo la missione di leggerlo. Perchè no?

Domanda interessante. Sono un programmatore C ++ da molto tempo che ora lavora in C # (con un po 'di C ++ non gestito per il lavoro critico per le prestazioni), e storicamente ho dovuto aggiungere occasionalmente un po' di codice assembly, di solito per motivi di prestazioni.

Alcuni punti nel preparare una risposta alla domanda:

• Per motivi di confronto, suggerisco che la principale distinzione tra le lingue che menzioni, C # e Java, dall'altro set, Assembly, C / C ++ è che la prima utilizza un runtime gestito per fornire la garbage-collection. Esistono altre differenze (ad es. Portabilità binaria, dimensioni del framework e portabilità), ma se si sta confrontando le differenze di prestazioni, questo è un (il?) Contributo principale.

• Assembly, C e C ++ sono tutt'altro che "di basso livello". Penso che tu abbia ragione nell'associare i linguaggi Assembly e C con gli sviluppatori hardware / firmware / driver, ma C ++ è in genere usato a un livello superiore, ed è ancora in uso pesante - anche se chiaramente C # / Java lo stanno facendo a pezzi secondo il TIOBE indice.

• Nel livello C ++, aggiungerei Objective-C, poiché è più simile a C ++ che a C # / Java. Infine, noterei che con l'aggiunta di shared_ptr <> e altre funzionalità di gestione automatica delle risorse, queste lingue supportano qualcosa di simile alla garbage collection.

OK, alla domanda principale: gli ingegneri del software hanno davvero bisogno di sapere cose di basso livello?

La mia risposta: Sì

Motivi:

• Anche quando si utilizza C # / Java, è probabile che si verifichino entità framework che richiedono una gestione esplicita delle risorse e / o problemi con grafici di memoria "bloccati" su qualsiasi applicazione non banale. È necessario capire come funzionano questi sistemi per evitare ed eseguire correttamente il debug di questi problemi.
• Le piattaforme mobili dispongono di risorse più limitate e, sebbene su alcune versioni siano supportate versioni limitate di Java e .NET, l'attuale predominio di iOS e Objective-C suggerisce un live rinnovato da tempo.
• Prestazioni: ogni volta che colpisci un muro delle prestazioni, dovrai probabilmente cadere in un blocco di codice compilato in modo nativo per aggirarlo.
• Supporto legacy: ogni volta che devi interoperare per ottenere l'accesso a una funzione non ancora (ancora) esposta nel codice gestito, dovrai fare lo stesso.

Bella domanda, ma non vedo le lingue non gestite andare via nel breve termine.

• Che qualcuno non legittimamente apprenda e non capisca la funzionalità di livello inferiore, e sia comunque uno sviluppatore molto produttivo e prezioso, è già il caso.
• Che nessuno avrà bisogno di imparare o comprendere funzionalità di livello inferiore, che sarebbe sempre una perdita di tempo, non sarà mai il caso.

Come in qualsiasi disciplina ingegneristica, ci sono molti passaggi per il prodotto finale, tutti importanti, che richiedono competenza e sono preziosi. In particolare nell'ingegneria del software, abbiamo molti livelli di astrazione. Tutti sono necessari e nessuno può essere un esperto in tutti loro.

Detto questo, abbiamo bisogno di più sviluppatori C # / Java / Ruby rispetto agli sviluppatori Assemby / C. Per noi sviluppatori "di livello superiore", capire di più su ciò che accade "sotto il cofano" è utile e ci renderà sviluppatori migliori. Ma anche molte altre cose . Come sviluppatore .NET, per esempio, c'è così tanto che posso imparare che mi renderà più produttivo, che studiare il nostro linguaggio intermedio (molto meno C ++ / C / Assmebly), sebbene molto utile, spesso deve prendere un posto indietro.

Puoi guadagnarti da vivere oggi come programmatore senza conoscere le cose di basso livello. Penso che ti renda un programmatore migliore per conoscerlo.

Mantenere un alto livello di competenza con le cose di basso livello, tuttavia, sta diventando sempre meno importante. Voglio dire, non ho fatto nulla in assemblea da 20 anni e probabilmente avrei bisogno di un serio aggiornamento prima di poter essere di nuovo produttivo in esso, ma i concetti generali di come funzionano le cose a quel livello fanno ancora parte della mia coscienza e trovo di tanto in tanto è utile anche quando si lavora in lingue di livello superiore.

Non credo, gli sviluppatori del kernel avranno sempre bisogno di cose di basso livello. Inoltre non fa male capire come funziona tutto, se fondamentalmente capisci cosa sta facendo il codice che stai scrivendo imparerai a scrivere codice migliore. Penso che rimuovere le cose di basso livello sia un'idea orribile in quanto questo pensiero astratto è utile a volte ma può effettivamente essere un ostacolo se vuoi che il problema sia risolto nel migliore dei modi. Ad esempio capire che quando si concatenano le stringhe in realtà si stanno creando nuove stringhe è importante, ma se non si capisce come sono state implementate le stringhe, è possibile concatenarsi e attendere 5 minuti per l'esecuzione del programma. Questo è un eccellente articolo su cose come questa: http://www.joelonsoftware.com/articles/fog0000000319.html

Questo dipende da cosa sta effettivamente lavorando l'ingegnere del software. È possibile avere una carriera produttiva, felice e redditizia senza mai toccare nulla di basso livello ora, ma non è tutto programmato. Perché ci siano sistemi operativi e compilatori, ci devono essere ingegneri che lavorano su sistemi operativi e compilatori e dovranno conoscere C, C ++ e il linguaggio assembly della loro macchina.

Anche le prestazioni possono avere importanza. Il mio attuale laptop è circa un milione di volte più potente del mio primo computer di casa e l'esecuzione del software può ancora richiedere tempo. Riesco ancora ad avere ritardi nei videogiochi. Certo, i videogiochi sembrano migliori, perché a ciascuno di oltre un milione di pixel sullo schermo può essere assegnato uno dei milioni di colori (al contrario di mille posizioni dei personaggi in bianco e nero, con alcuni dei personaggi utilizzati per la grafica ). Dubito che avremo un ulteriore aumento di mille volte della potenza del computer nel prossimo futuro e, se lo facciamo, mi aspetto che venga utilizzato da software sempre più complesso.

Mentre la maggior parte dei software aziendali continuerà a essere scritta in ciò che è più veloce da produrre e fuori dalla porta, che di solito non è C, continuerà a esserci molto spazio per gli esperti di C e C ++.

"Con l'hardware che continua a migliorare, le prestazioni tra C / C ++ e Java non saranno significative e i grandi giochi potrebbero essere programmati in un linguaggio come Java".

Non credo che questa affermazione sarà corretta in qualunque momento presto. C'è sempre un successo nel codice gestito a causa dei controlli effettuati dietro la scena. Inoltre, non è una questione di hardware migliore, poiché l'hardware migliora, così come le app che dovrebbero funzionare su di essi. Un sistema scritto in codice nativo deve avere un'interfaccia per il codice gestito. C'è un impatto sulle prestazioni che si verifica quando si passa tra i due.

Tuttavia, solo una percentuale generalmente ridotta di applicazioni necessita davvero di questo codice ottimizzato. La maggior parte delle applicazioni della linea di business va bene con qualsiasi codice gestito, .net, java, ecc. Non significa che le applicazioni che ne hanno bisogno effettueranno il passaggio presto. Tuttavia l'assemblaggio scritto a mano è molto meno utilizzato ora con i compilatori C / C ++ ottimizzati che sono così buoni. Di recente, però, è stato scritto un sistema operativo interamente in assembly, quindi alcuni lo stanno riscontrando. È anche abbastanza importante nel campo della sicurezza.

Direi che, per essere uno sviluppatore davvero bravo, si dovrebbe capire cosa sta succedendo a basso livello. Aiuta a risolvere alcuni problemi difficili, specialmente quando si chiama in codice nativo.

Penso che conoscere alcune cose di basso livello sia molto utile per il debug, come ad esempio con la programmazione Embedded, la maggior parte di essa viene eseguita con C, tuttavia quando si esegue il debug conoscendo l'assemblaggio per quel particolare Micro controller è estremamente utile.

Quando i computer furono inventati per la prima volta, solo poche persone sapevano come usarli. Ora, la maggior parte delle case in un paese ricco ha 1 o più computer utilizzabili dalla persona media. Molte persone comuni hanno lavori che lavorano quotidianamente sui computer. La persona media ha la capacità di usare un computer, ma abbiamo ancora bisogno di programmatori.

Allo stesso modo, il programmatore medio non ha bisogno di conoscere o programmare regolarmente in linguaggio assembly. Questa è una condizione tanto per le abilità commerciabili quanto un saluto a quanto siamo arrivati ​​nel mondo della tecnologia. Le aziende hanno bisogno di computer per automatizzare le attività. Pertanto, i programmatori che possono programmare in .NET / Java sono molto richiesti.

Le attività che possono essere automatizzate saranno automatizzate. Non tutte le attività possono essere automatizzate. Non tutta l'automazione è perfetta. Quindi è importante il montaggio? Ovviamente. È necessario essere un "programmatore". Ovviamente no.

Hmmm In realtà mi piace imparare cose di basso livello.

Forse non è la similitudine più accurata, ma per me è come imparare le macchinazioni all'interno di un'auto. Potrei non sapere come funzionano tutti i pezzi l'uno contro l'altro, ma è divertente sapere che c'è un motore, un albero a gomiti, cilindri, differenziali, gru, freni, olio, combustione, refrigerazione e quindi attrito, stress, calore, forze, scienza: termodinamica, fisica, meccanica dei fluidi ...

Forse non molto utile (non sarò in grado di riparare un'auto conoscendo tutto questo), certamente non professionalmente pratico, ma, beh, divertente. L'arte per l'arte: la connaissance pour la connaissance.

Penso che una regola empirica utile sia: più veloce deve essere, più basso livello devi raggiungere.

Quindi i tuoi sparatutto in prima persona con grafica intensiva, o il tuo sistema di trading FX algoritmico, sono ancora di livello abbastanza basso (C ++, ecc.) Perché la velocità è la chiave. Ma l'app Web che genera in tempo un rapporto sulle vendite? Cavolo, potresti scriverlo in Sinclair BASIC, e sarebbe comunque accettabile.

Non tutti i lavori di ingegneria del software sono uguali . Le persone che lavorano su sistemi operativi, compilatori, framework, driver di dispositivi, sistemi integrati e elaborazione scientifica ad alte prestazioni devono ben conoscere "cose ​​di basso livello". Le persone che scrivono moduli Access CRUD o carrelli PHP per i negozi Mom e Pop, forse non così tanto. Che tipo di ingegneria del software vuoi fare e vuoi farlo per il resto della tua vita?

La mia opinione è che devi imparare almeno un livello di astrazione al di sotto di quello in cui lavori abitualmente. Se lavori in C / C ++ allora dovresti prendere un po 'di architettura e assemblaggio di macchine. Se lavori in PHP, dovresti capire HTTP e un po 'di C / C ++ o Perl. Se Access è il tuo pane e burro, allora faresti meglio a conoscere un po 'di teoria RDB, e forse un po' di COM o .Net. A volte nella tua carriera alla fine ti fermerai morto nelle tue tracce a causa di un problema a un livello inferiore di astrazione, e dovrai essere in grado di comunicare almeno un po 'con qualcuno che è un esperto in quella zona. Puoi "cavartela" senza queste cose? Certo, ma pianificare di "cavarsela" in un mercato del lavoro competitivo è pericoloso.

Io stesso lavoro ampiamente in C # .NET e mi sono sempre allontanato da C, C ++. Di recente ha iniziato a cercare lavoro ed è stato sorpreso di vedere quanti lavori sono disponibili e richiedono esperienza per C, C ++. Inizialmente pensavo che C, C ++ stessero diventando obsoleti ma guardando i lavori disponibili, non sembra che sia così.

Tutte le lingue gestite che hai elencato hanno interpreti o macchine virtuali scritti in C / C ++. Senza quei due, la maggior parte delle lingue gestite o interpretate non esisterebbe nemmeno. Direi che hai sottovalutato il loro valore.

Odio davvero l'idea stessa di una conoscenza "pratica" . Tutto ciò che impari è altrettanto pratico. Non importa se non opererai a un livello di astrazione vicino all'hardware, semplicemente conoscere i concetti di quel dominio è sempre utile per costruire nuove conoscenze a un altro livello di astrazione. Più concetti correlati conosci, meglio è.

Per quello che faccio normalmente, C # è un linguaggio di livello molto basso e lo considero qualcosa di molto simile a un hardware. Ma credo ancora che anche la mia conoscenza rudimentale e arrugginita dell'elettronica digitale, del design della CPU, ecc. Sia molto utile per tutto ciò che faccio.

No, la maggioranza non ne ha bisogno. Sebbene la pratica di tecniche di basso livello offra allo sviluppatore una migliore conoscenza di ciò che potrebbe influenzare il ciclo nel suo insieme, oggi gli sviluppatori potrebbero sfruttare quel tempo per studiare le nuove tecnologie, che a loro volta richiedevano la conoscenza di cose di basso livello da sviluppare ma da non fare affidamento su.

A mio avviso, quando usi una parola "Ingegnere", intendi che l'uomo / donna è colui che progetta e costruisce le cose da zero. Il vero problema di un ingegnere del software è quello di risolvere un problema, ma quale problema? È una grande domanda.

Uno sviluppatore è diverso da un ingegnere in molti modi. Uno "sviluppatore" è una persona che di solito costruisce cose su piattaforme già esistenti. Sviluppa le piattaforme esistenti o costruisce nuove eredità di piattaforme da quelle più vecchie usando sicuramente il componente del suo sistema genitore.

Uno sviluppatore di solito pensa dal punto di vista aziendale, non è uno scienziato. :) Lo sviluppatore è più vicino all'utente del sistema, pensa le cose dal punto di vista dell'utente e quindi finisce per risolvere i problemi degli utenti usando la tecnologia.

Un ingegnere intelligente. È uno scienziato, risolve un problema molto autentico. La maggior parte dei problemi, che il computer stesso ha come caratteristica .. Noi utenti non ci avviciniamo mai a quel problema, è incapsulato. Gli ingegneri sono quelli che lasciano gli studi alle spalle dopo aver studiato molto sul sistema esistente e escogitano qualcosa di nuovo per risolvere il problema, se la soluzione richiede, se il loro sistema ha bisogno di una nuova lingua, inventa una nuova lingua perché il sistema esistente non è in grado di risolvere quel problema. Gli ingegneri hanno finito per costruire un sistema su cui gli sviluppatori costruiscono il loro sistema.

In effetti, un ingegnere del software deve imparare ed essere esperto di cose di basso livello ... :)

Considerando che uno sviluppatore, dipende completamente dal suo interesse. :)