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

Domanda interessante. Sono un programmatore C ++ di lunga data che ora lavora in C # (con un po 'di C ++ non gestito per il lavoro critico sulle prestazioni) e che storicamente ha dovuto aggiungere il bit occasionale del codice assembly, solitamente per motivi di prestazioni.

Alcuni punti nella preparazione di una risposta alla domanda:

• Per il tuo confronto, suggerisco che la distinzione principale tra le lingue che hai citato, C # e Java, dall'altra serie, Assembly, C / C ++ è che il primo utilizza un runtime gestito per fornire spazzatura -collezione. Esistono altre differenze (ad esempio portabilità binaria, dimensioni della struttura e portabilità), ma dal momento che si sta cercando di confrontare le differenze di prestazioni, si tratta di un (il?) Maggiore contributore.

• Assembly, C e C ++ non sono ugualmente "di basso livello". Penso che tu abbia ragione ad associare i linguaggi Assembly e C con gli sviluppatori di hardware / firmware / driver, ma il C ++ è tipicamente usato su un livello più alto, e è ancora in uso pesante - anche se chiaramente C # / Java lo stanno esaurendo secondo l'indice TIOBE.

• Nel livello C ++, aggiungerei Objective-C, poiché è più simile a C ++ che C # / Java. Infine, osserverei 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 - per la tua domanda principale: Gli ingegneri del software hanno davvero bisogno di sapere cose di basso livello più?

La mia risposta: Sì

I motivi:

• Anche quando si utilizza C # / Java, è probabile che si imbattano in entità quadro che richiedono una gestione esplicita delle risorse e / o si imbattono in problemi di grafici di memoria "appuntati" su qualsiasi applicazione non banale. Devi capire come funzionano questi sistemi per evitare e correggere efficacemente questi problemi.
• Le piattaforme mobili dispongono di risorse più limitate e, sebbene su alcune di esse vi sia il supporto per versioni limitate di Java e .NET, l'attuale dominio di iOS e Objective-C suggerisce una lunga e rinnovata esperienza live.
• Prestazioni: ogni volta che colpisci un muro delle prestazioni, è probabile che tu debba inserire un chunk di codice compilato in modo nativo per aggirarlo.
• Supporto legacy: ogni volta che devi eseguire l'interoperabilità per accedere a una funzione non ancora esposta (ancora) nel codice gestito, devi fare lo stesso.

Buona domanda - ma non vedo lingue non gestite che vanno via nel breve termine.

• Il fatto che qualcuno che legittimamente non venga a conoscenza e non comprenda le funzionalità di livello inferiore e sia ancora uno sviluppatore molto produttivo e prezioso, è già il caso.
• Che nessuno dovrà imparare o capire le funzionalità di livello inferiore, che sarebbe sempre una perdita di tempo, non sarà mai il caso.

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

Detto questo, abbiamo bisogno di più sviluppatori C # / Java / Ruby di noi sviluppatori di Assemby / C. Per noi sviluppatori "di livello superiore", capire meglio cosa succede "sotto le cappa" è utile e ci renderà sviluppatori migliori. Ma anche un sacco di altre cose . Come sviluppatore .NET, per exmaple, c'è così tanto che posso imparare che mi renderà più produttivo, che studiando il nostro Intermediate Language (molto meno C ++ / C / Assmebly), anche se molto utile, spesso deve prendere un sedile posteriore.

Puoi guadagnarti da vivere oggi come programmatore senza conoscere le cose di basso livello. Penso che sia solo un programmatore migliore a saperlo.

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 in 20 anni e probabilmente avrei avuto 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 sono ancora parte della mia coscienza e trovo è utile di tanto in tanto anche quando si lavora in linguaggi di livello superiore.

Non credo, gli sviluppatori del kernel avranno sempre bisogno di cose di basso livello. Inoltre non fa male capire come tutto funzioni, se fondamentalmente capisci cosa sta effettivamente facendo il codice che stai scrivendo imparerai a scrivere codice migliore. Penso che rimuovere la roba di basso livello sia un'idea orribile dato che questo pensiero astratto è utile a volte, ma può essere un ostacolo se si vuole risolvere il problema nel modo migliore. 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 si può semplicemente concatenare e attendere i 5 minuti necessari per l'esecuzione del programma. Questo è un eccellente articolo su cose come questa: link

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 tutti i lavori di programmazione. Perché ci siano sistemi operativi e compilatori, ci devono essere ingegneri che lavorano su sistemi operativi e compilatori, e avranno bisogno di conoscere C, C ++ e il linguaggio assembly della loro macchina.

Anche le prestazioni possono avere importanza. Il mio attuale laptop è molto più potente di un milione di volte rispetto al mio primo computer di casa e il software in esecuzione può richiedere ancora del tempo. Posso ancora rimanere indietro nei videogiochi. Certo, i videogiochi sembrano migliori, perché ciascuno di oltre un milione di pixel sullo schermo può essere dato uno di milioni di colori (al contrario di mille posizioni di caratteri in bianco e nero, con alcuni dei personaggi utilizzati per la grafica ). Dubito che nel prossimo futuro avremo un altro aumento multiplo di potenza del computer, e se lo faremo, mi aspetto che venga utilizzato da un software sempre più complesso.

Mentre la maggior parte dei software aziendali continueranno a essere scritti in ciò che è più veloce da produrre e fuori, che di solito non è C, ci sarà ancora 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 il gioco di grandi dimensioni potrebbe essere programmato in linguaggio come Java."

Non credo che la dichiarazione sarà corretta in qualunque momento presto. C'è sempre un colpo nel codice gestito a causa dei controlli eseguiti dietro la scena. Inoltre, l'hardware non è più un problema, in quanto l'hardware migliora, quindi le app che dovrebbero essere eseguite su di esse. Un sistema che viene scritto nel codice nativo deve avere un'interfaccia per il codice gestito. C'è un problema di prestazioni che si verifica quando si passa da uno all'altro.

Tuttavia, solo una percentuale generalmente bassa di applicazioni ha davvero bisogno di questo codice ottimizzato. La maggior parte delle applicazioni di business line si adattano perfettamente a qualsiasi codice gestito, .net, java, ecc. Ciò non significa che le applicazioni che ne hanno bisogno lo faranno presto. Tuttavia, l'assembly scritto a mano è molto meno utilizzato ora con l'ottimizzazione dei compilatori C / C ++ che sono così buoni. Di recente c'è stato un sistema operativo interamente scritto in assembly, quindi alcuni ancora ci stanno provando. È anche abbastanza importante nel campo della sicurezza.

Direi però, per essere uno sviluppatore davvero bravo, bisogna capire cosa sta succedendo a un livello basso. Aiuta a risolvere alcuni problemi difficili, soprattutto quando si chiama in codice nativo.

Penso che conoscere alcune cose di basso livello sia molto utile per il debugging, come ad esempio con la programmazione Embedded, la maggior parte viene eseguita con C, tuttavia quando il debugging dell'assembly per quel particolare Micro controller è estremamente utile.

Quando i computer sono stati inventati per la prima volta solo poche persone sapevano come usarli. Ora, la maggior parte delle case in un paese ricco dispone di 1 o più computer che sono utilizzabili dalla persona media. Molte persone comuni lavorano quotidianamente su 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 sapere o programmare regolarmente in linguaggio assembly. Questa è una condizione altrettanto importante per le competenze commerciali, quanto un saluto a quanto siamo arrivati nel mondo della tecnologia. L'azienda ha 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 tutto l'automazione è perfetta. Quindi, l'assemblea è importante? Ovviamente. È richiesto di essere un "programmatore". Certo che no.

Hmmm Mi piace davvero 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 tutti i pezzi funzionano l'uno contro l'altro, ma è divertente sapere che c'è un motore, un albero motore, 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.

Non tutti i lavori di ingegneria del software sono uguali . Le persone che lavorano su sistemi operativi, compilatori, framework, driver di dispositivo, sistemi embedded e calcolo scientifico ad alte prestazioni, hanno bisogno di conoscere "roba di basso livello". Le persone che scrivono i moduli Access CRUD, o PHP shopping-carts 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 hai bisogno di imparare almeno un livello di astrazione sotto quello in cui lavori di solito. Se lavori in C / C ++, dovresti prendere in considerazione alcuni aspetti dell'architettura e dell'assemblaggio della macchina. Se lavori in PHP, dovresti capire HTTP e un po 'di C / C ++ o Perl. Se Access è il tuo pane e burro, allora è meglio conoscere una teoria RDB e forse un po 'di COM o .Net. A un certo punto della tua carriera finirai per essere fermato nelle tue tracce da un problema a un livello inferiore di astrazione, e dovrai essere in grado di comunicare almeno un po 'con qualcuno che è un esperto in quell'area. Puoi 'cavartela' senza questa roba? Certo, ma pianificare di "cavarsela" in un mercato del lavoro competitivo è pericoloso.

Io stesso lavoro estesamente in C # .NET e sono sempre stato lontano da C, C ++. Recentemente ho iniziato a cercare lavoro e sono rimasto sorpreso nel 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 scritte in C / C ++. Senza questi due, la maggior parte delle lingue gestite o interpretate non esisterebbe nemmeno. Direi che sottovaluti il loro valore.

Odio davvero la nozione di una "pratica" conoscenza . Tutto ciò che apprendi è altrettanto pratico. Non importa se non lavorerai a un livello di astrazione vicino all'hardware, semplicemente sapere che i concetti di quel dominio sono sempre utili 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 come qualcosa di molto vicino 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 dia a uno sviluppatore una migliore conoscenza di ciò che potrebbe influenzare il ciclo nel suo complesso, oggi lo sviluppatore potrebbe utilizzare quel tempo per studiare nuove tecnologie, che a loro volta richiedono la conoscenza di materiale di basso livello da sviluppare ma non da contare sopra.

Penso che una buona regola empirica sia - più veloce deve essere, il livello più basso che devi ottenere.

Quindi lo sparatutto in prima persona della tua grafica, o il tuo sistema di trading FX algoritmico, sono ancora abbastanza bassi (C ++, ecc.) perché la velocità è la chiave. Ma l'app web che sputa un rapporto di vendita in tempo? Diavolo, potresti scriverlo in Sinclair BASIC, e sarebbe comunque accettabile.

Secondo me, quando usi una parola "Ingegnere", intendi che l'uomo / donna è colui che progetta & costruisci le cose da molto tempo. Il vero problema di un Software Engineer è 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 piattaforme ereditate da quelle più vecchie utilizzando sicuramente il componente del sistema principale.

Uno sviluppatore di solito pensa da una prospettiva 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 utilizzando la tecnologia.

Un ingegnere intelligente. È uno scienziato, risolve un problema molto genuino. La maggior parte dei problemi, che il computer stesso ha come caratteristica. Noi non ci avviciniamo mai a quel problema, è incapsulato. Gli ingegneri sono quelli che lasciano i loro studi dopo aver fatto molte ricerche sul sistema esistente e inventato qualcosa di nuovo per risolvere il problema, se la soluzione richiede, se il loro sistema ha bisogno di un nuovo linguaggio inventa un nuovo linguaggio perché il sistema esistente non è in grado di risolvere questo 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 ...:)

Mentre uno sviluppatore, dipende completamente dal suo interesse. :)