La scienza dell'informatica è morta? [chiuso]

Domanda: la scienza e l'arte di CS sono morte? Con questo voglio dire, i reali requisiti per pensare, pianificare e risolvere in modo efficiente i problemi sembrano non essere più disponibili in questi giorni. Il campo sembra abbassare la barriera d'ingresso in modo che più persone possano "programmare" senza dover imparare a programmare veramente.

Background: sono un neolaureato con una laurea in informatica. Sto lavorando in una posizione di partenza presso un'azienda di dimensioni decenti nel dipartimento IT. Faccio principalmente .NET e altre tecnologie Microsoft nel mio lavoro, ma prima ho fatto cose Java attraverso stage e simili. Personalmente sono un programmatore C ++ per i miei progetti per divertimento.

Approfondimento: attraverso il lavoro che ho svolto, mi sembra che le intense discipline di una vera scienza non esistano più in CS. In passato, i programmatori dovevano risolvere i problemi in modo efficiente affinché i sistemi fossero robusti e rapidi. Ma ora, con le tecnologie prevalenti come .NET, Java e i linguaggi di scripting, sembra che l'efficienza e la solidità siano state scambiate per facilità di sviluppo.

La maggior parte dei colleghi con cui lavoro non ha nemmeno una laurea in Informatica. Molti si sono laureati in Ingegneria Elettrica, alcuni in Ingegneria del Software, anche alcuni provenienti da scuole di tecnologia senza un programma di 4 anni. Tuttavia riescono a cavarsela bene senza avere il background tecnico di CS, senza aver studiato teorie e algoritmi, senza avere alcun riguardo per la creazione di una soluzione elegante (cercano solo la soluzione più semplice ed economica).

L'azienda ci spinge a utilizzare le tecnologie Microsoft, che eliminano tutto il vero pensiero e lo sostituiscono con librerie e strumenti che possono auto-costruire il tuo progetto per la metà del tempo. Non sto cercando di odiare le lingue, capisco che servono a uno scopo e lo fanno bene, ma quando i tuoi dipendenti non sanno come funziona una tabella hash e usano i metodi di ordinamento sbagliati o eseguono comandi SQL che sono orribilmente inefficienti (ma svolgono il lavoro in un tempo accettabile), sembra che si stiano facendo più sforzi nello sviluppo di tecnologie che codificano i nuovi "programmatori" piuttosto che insegnare effettivamente alle persone come fare le cose nel modo giusto.

Sono interessato a realizzare programmi efficienti e, secondo me, belli. Se c'è un modo migliore per farlo, preferirei tornare indietro e riformattarlo piuttosto che lasciarlo scivolare. Ma nel mondo aziendale, mi spingono a completare le attività rapidamente piuttosto che con eleganza. E questo mi infastidisce davvero.

È questo ciò che non vedo l'ora del resto della mia vita? Ci sono ancora posizioni là fuori per le persone che amano la scienza e l'arte della CS piuttosto che solo la busta paga?

E sulla stessa nota, ecco una buona lettura se non l'hai mai vista prima di The Perils Of Java Schools

Sì e no

Bella domanda, ma pessima ipotesi.

La parte scientifica dell'educazione sembra mancare, ma l'ipotesi che la scienza fosse lì solo per rendere efficienti i programmi è sbagliata.

La scienza era necessaria per insegnare alle persone come definire e risolvere i problemi.

Purtroppo, questa parte di alcuni curricula "CS" (curricula?) Sembra essere completamente omessa, sostituita da problemi di giocattoli con soluzioni banali o conosciute e intesa semplicemente per insegnare la familiarità con gli strumenti

deludente; molti diplomati della scuola Java sono stati modificati, non hanno mai insegnato come scomporre un problema, progettare un algoritmo, specificare un test o persino eseguire il debug in modo efficace.

La scienza dell'informatica è morta? "..." Sono un neolaureato in scienze informatiche. Sto lavorando in una posizione di partenza presso un'azienda di dimensioni decenti nel dipartimento IT .

Onestamente, i miei due centesimi: non troverai la "scienza" dell'informatica che lavora in un dipartimento IT in un'azienda di dimensioni decenti, perché è il dipartimento IT, non il dipartimento CS. Prova a tornare a scuola per un dottorato di ricerca o a lavorare nei dipartimenti di ingegneria di una società il cui focus è l'informatica (ad esempio elaborazione di immagini, reti ad alte prestazioni, sistemi di algebra informatica, aerospaziale, ecc ...). Qui troverai i problemi difficili e interessanti in cui il design sciatto [generalmente] non sarà tollerato.

"Ci sono ancora posizioni là fuori per le persone che amano la scienza e l'arte della CS piuttosto che solo la busta paga?"

Sì, assolutamente, ma probabilmente non presso i dipartimenti IT delle aziende di medie dimensioni.

Se sei un programmatore, non considerarti un "informatico"; gli informatici sono quelli che creano la prossima generazione di computer, alcuni dei quali sono ancora fantascienza fino a quando non si ottiene il giusto mix di materiali, miniatuizzazione e teoria computazionale. Sono solo l'inizio della pipeline. Le persone che sviluppano software nel qui e ora sono "ingegneri del software"; prendono le teorie e gli strumenti, a volte sovrapponendo la teoria pratica e gli strumenti del mondo reale, per sfruttare il potere in potenza di questo complesso pezzo di magia elettronicainica e farlo fare ciò che vogliamo. Questa è a sua volta una specializzazione nel campo dell '"ingegneria informatica", che porta le teorie degli informatici e le applica, hardware e software, alle soluzioni elettroniche degli utenti finali del mondo reale.

Questo è, IMO, dove gli affari incontrano la teoria. In questi tipi di casi, il vecchio adagio "il nemico del meglio è abbastanza buono" può essere facilmente girato per leggere "il nemico del abbastanza buono è meglio". Considerarti un "ingegnere" anziché uno "scienziato" e mettere in parallelo ciò che fai in parallelo con altre discipline ingegneristiche, mette in rilievo le differenze.

Diciamo che un cliente viene da te, un ingegnere civile / strutturale, e ti chiede di costruire un ponte. Il ponte deve superare 20 piedi, sostenere se stesso e una tonnellata di carico, dovrebbe durare 10 anni con manutenzione ordinaria e lo vogliono in un mese per $ 20.000. Questi sono i tuoi vincoli; soddisfare i minimi pur non superando i massimi. Fare questo è "abbastanza buono", e ti dà la busta paga. Sarebbe una cattiva ingegneria per te costruire il Golden Gate Bridge, superando di gran lunga sia le specifiche di progettazione che il budget di diversi ordini di grandezza. Di solito si finisce per mangiare i sovraccarichi di costo e pagare penalità per perdite di tempo. Sarebbe anche una cattiva ingegneria per te costruire un ponte di corda valutato per il peso di 5 uomini adulti anche se costa solo $ 1000 in termini di tempo e materiali; non ottieni buone recensioni e testimonianze dei clienti,

Di nuovo nel software, supponiamo di avere un client che ha bisogno di un sistema di elaborazione dei file creato per digerire i file in arrivo e inserire le informazioni nel sistema. Vogliono farlo in una settimana e deve gestire cinque file al giorno, circa 10 MB di dati, perché è tutto il traffico che ottengono attualmente. Le tue preziose teorie escono in gran parte dalla finestra; il tuo compito è costruire un prodotto che soddisfi tali specifiche in una settimana, perché in tal modo soddisfi anche il budget dei costi del cliente (poiché i materiali sono generalmente una goccia nel secchio per un contratto software di queste dimensioni). Trascorrere due settimane, anche per dieci volte il guadagno, non è un'opzione, ma molto probabilmente non è nemmeno un programma costruito in un giorno in grado di gestire solo metà della velocità effettiva, con l'istruzione di far funzionare due copie.

Se pensi che questo sia un caso marginale, ti sbagli; questo è l'ambiente quotidiano della maggior parte dei proprietari. Il motivo è il ROI; questo programma iniziale non costa molto e quindi si ripaga molto rapidamente. QUANDO gli utenti finali ne hanno bisogno per fare di più o andare più veloce, il codice può essere refactored e ridimensionato.

Questa è la ragione principale dietro l'attuale stato di programmazione; l'ipotesi, confermata dall'intera storia dell'informatica, è che un programma non è MAI statico. Dovrà sempre essere aggiornato e alla fine verrà sostituito. Parallelamente, il costante miglioramento dei computer su cui sono in esecuzione entrambi i programmi consente una minore attenzione all'efficienza teorica e una maggiore attenzione alla scalabilità e al parallelismo (un algoritmo che gira in N-quadrato ma che può essere parallelizzato per funzionare su N core appare lineare e spesso il costo di più hardware è più economico di quello degli sviluppatori per escogitare una soluzione più efficiente).

Inoltre, c'è il principio molto semplice che ogni riga di codice sviluppatore è qualcos'altro che può andare storto. Meno uno sviluppatore scrive, meno è probabile che ciò che scrive abbia un problema. Questa non è una critica al "bug rate" di nessuno; è una semplice dichiarazione di fatto. Potresti sapere come scrivere un MergeSort avanti e indietro in 5 lingue, ma se hai il dito solo un identificatore in una riga di codice l'intero ordinamento non funziona e se il compilatore non lo rileva potrebbe prenderti ore per il debug. Contrastalo con List.Sort (); è lì, è efficiente nel caso generale e, ecco la cosa migliore, funziona già.

Quindi, molte delle funzionalità delle piattaforme moderne e principi delle moderne metodologie di progettazione sono state costruite tenendo presente questo aspetto:

• OOP - costruisci dati e logica correlati in un oggetto e ovunque il concetto di quell'oggetto sia valido, quindi l'oggetto o una derivazione più specializzata.
• Modelli predefiniti: un buon 60% o più di codice è un'innesto sintattico e le basi per far sì che il programma mostri qualcosa sullo schermo. Standardizzando e generando automaticamente questo codice, riduci della metà il carico di lavoro dello sviluppatore, consentendo un aumento della produttività.
• Librerie di algoritmi e strutture dati - Come in precedenza, potresti sapere come scrivere Stack, Queue, QuickSort, ecc., Ma perché devi farlo, quando c'è una libreria di codice che ha tutto questo integrato? Non riscriveresti IIS o Apache perché avevi bisogno di un sito Web, quindi perché implementare un algoritmo QuickSort o un oggetto albero rosso-nero quando sono disponibili diverse grandi implementazioni?
• Interfacce fluide - Sulla stessa linea, potresti avere un algoritmo che filtra e ordina i record. È veloce, ma probabilmente non è molto leggibile; al tuo sviluppatore junior ci vorrebbe un giorno solo per capirlo, figuriamoci fare le modifiche chirurgiche necessarie per ordinare su un campo aggiuntivo nell'oggetto record. Invece, librerie come Linq sostituiscono un sacco di codice molto brutto, spesso fragile, con una o due linee di chiamate di metodo configurabili per trasformare un elenco di oggetti in oggetti filtrati, ordinati e proiettati.

Mi sembra che tu stia facendo IT e non CS e questo non dovrebbe implicare che CS sia morto. CS non è morto, è solo che la maggior parte dei lavori sono in sviluppo software. Dato che la maggior parte degli studenti di CS imparano a programmare, di solito finiscono per assumere come programmatori e non come informatici. I lavori di informatica sono minuscoli rispetto ai lavori di programmazione. Potresti persino realizzare un'app complessa usando tecniche di informatica, ma secondo me (e non mi piacciono le risposte d'opinione perché sono soggettive), che rientra in un campo di ingegneria che in un campo di scienziati.

Inoltre, il codice bello ed elegante è negli occhi di chi guarda , ma per la maggior parte delle aziende / manager, avere un design abbastanza buono in tempo è molto più importante del bel codice ma non finisce mai in tempo.

Infine, c'è il mondo reale e la terra-lala. Sfortunatamente, riceviamo la busta paga dalla prima, ed è qui che la "scienza / arte" dello sviluppo del software arriva su come produrre alta qualità del software con vincoli di tempo / budget. Ho provato lo stesso tipo di sentimenti che provi all'inizio della mia carriera. Ho sempre voluto creare "il meglio", ma presto mi rendo conto che "il migliore" non è il design più efficiente o elegante, ma il più conveniente.

Prima di tutto, hai sbagliato. "pensare, pianificare e risolvere efficacemente i problemi" non è scienza, è ingegneria. La scienza è molto di più sull'esplorazione di nuovi campi. E in realtà nel mondo accademico la gente si preoccupa molto meno dell'efficienza del codice molto meno, che nell'industria. In ambito accademico si tratta più di prove di concetti, ecc.

No, quello che stai descrivendo, è che sono richieste conoscenze meno approfondite per lo sviluppo del software. Il che potrebbe essere vero, se i requisiti fossero gli stessi. Ma al giorno d'oggi, ci si aspetta che l'ingegnere del software sappia come gestire il multi-threading, il calcolo distribuito, il ridimensionamento ecc. Ci si aspetta che sappiano come condurre i progetti in modo efficiente. La maggior parte di questo non era affatto nei curricula alcuni decenni fa.

Non penso che quello che hai detto sia esattamente giusto, ma hai comunque qualcosa di utile. In particolare, penso che nel tempo l'informatica e l'ingegneria del software siano cresciute.

L'ingegneria del software (come l'altra ingegneria) riguarda l' applicazione della scienza per costruire prodotti, risolvere problemi, ecc. L'informatica riguarda principalmente la ricerca negli algoritmi e (sebbene questa parte sia spesso un po 'dimenticata) come implementare quegli algoritmi (almeno in un senso teorico - ad esempio, forse trattando tutte le macchine PRAM come equivalenti).

Tenendo conto di ciò, penso che la ragione alla base della biforcazione diventi evidente: la maggior parte dei problemi algoritmici coinvolti in qualcosa come un tipico sito Web sono già stati risolti - la maggior parte di loro, molto tempo fa. Forse ancora più importante, la maggior parte di questi sono stati risolti abbastanza bene che per lo sviluppatore web medio, il problema è scomparso quasi completamente. Ad esempio, fare aggiornamenti atomici a database distribuiti è sicuramente un'attività non banale, ma un tipico sviluppatore Web scrive solo un po 'di SQL e non ha idea (o cura) di quanta ricerca è stata impiegata per capire come far funzionare affidabile.

Un tempo, era sostanzialmente impossibile separare l'informatica dall'ingegneria del software. Sono stati risolti così pochi problemi che scrivere anche un programma relativamente banale ha richiesto una ricerca sui fondamenti. Se volevi fare qualcosa di semplice come ordinare un mucchio di dati alla fine degli anni '50 o all'inizio degli anni '60, era abbastanza probabile che avresti dovuto fare qualche analisi dei tuoi dati e provare a progettare un algoritmo che si adatta al meglio a ciò che sarebbe necessario per ordinare quei dati particolari - in nessun posto vicino a tanti algoritmi di ordinamento erano conosciuti come oggi, e persino gli algoritmi che erano conosciuti non erano conosciuti così bene come lo sono oggi .

50 anni di ricerca e sviluppo hanno dato i loro frutti: lo sviluppo più tipico può utilizzare non solo algoritmi noti, ma implementazioni già scritte. I problemi più tipici possono essere risolti abbastanza ragionevolmente sulla base delle conoscenze esistenti (e persino delle implementazioni esistenti) degli algoritmi.

Ciò non significa che l'informatica sia morta - ci sono ancora più algoritmi da ricercare e persone che fanno ricerche su di essi. Ciò significa, tuttavia, che la maggior parte della ricerca è più specializzata e probabilmente si applica solo ad aree abbastanza specializzate. C'è probabilmente anche un "divario" maggiore tra l'acquisizione e l'applicazione della conoscenza. Una volta, hai trovato un modo migliore di ordinare nel processo di scrittura di un programma di ordinamento, ed è stato scritto in codice reale quasi immediatamente. Ora molta informatica è dedicata a cose come usare un numero essenzialmente infinito di processori - che probabilmente un giorno saranno utili, ma anche le tribù primitive non considererebbero i doppi nuclei nel mio computer come "molti" ... :-)

Lo sviluppo del software e l'informatica non sono la stessa cosa, e ho scoperto che la maggior parte dei miei compagni di classe in un B.Sc. Questo è stato frustrato dal programma Comp Sci.

Penso al software come un prodotto dell'informatica ... come i dipinti sono un prodotto dell'arte visiva.

Penso che la maggior parte delle persone con diplomi CS siano assunti per svolgere attività di sviluppo software, soprattutto nelle prime fasi della loro carriera. Penso che molte persone in questo ruolo rimangano lì e non vadano oltre.

Penso che la differenza cominci ad apparire quando compaiono nuovi problemi o paradigmi o quando "schiaffeggiarli insieme" non è abbastanza buono. Chi costruisce i nuovi framework o linguaggi? Chi si siede e martella i dettagli di un nuovo motore fisico? Chi usa la teoria dei grafi / trasformazioni dei grafi per eseguire alcuni cicli per iterazione delle prestazioni da un algoritmo?

Finirò da dove ho iniziato, concordando sul fatto che ci sono molti scienziati informatici nei ruoli di sviluppo / ingegneria del software, forse non all'altezza del loro potenziale.

Sembra che tu stia confondendo l'informatica con la programmazione e lo sviluppo del software in generale. I due non sono uguali, nemmeno vicini. Indipendentemente da ciò che i nostri gradi possono dire, la stragrande maggioranza di noi sono programmatori, non informatici. A meno che tu non sia attivamente coinvolto nel mondo accademico ad alto livello, scommetterei che non hai davvero idea di cosa stia succedendo nell'informatica.

Posso dirti che l'Informatica è viva e vegeta. Devo risolvere ogni giorno nuovi problemi e trovare una soluzione efficace ed elegante a questi problemi. Devo usare le mie capacità come ingegnere ogni giorno e usare la conoscenza di me stesso e dei miei colleghi per risolvere questi problemi per i nostri clienti.

Non sto cercando di odiare le lingue, capisco che servono a uno scopo e lo fanno bene, ma quando i tuoi dipendenti non sanno come funziona una tabella hash e usano i metodi di ordinamento sbagliati o eseguono comandi SQL che sono orribilmente inefficienti (ma svolgono il lavoro in un tempo accettabile), sembra che si stiano facendo più sforzi nello sviluppo di tecnologie che codificano i nuovi "programmatori" piuttosto che insegnare effettivamente alle persone come fare le cose nel modo giusto.

Sembra un problema con il dipendente e certamente non è vero per ogni programmatore.

Solo perché esistono strumenti che facilitano il nostro lavoro non significa che non dovremmo capire la tecnologia sottolineata, se non lo facciamo non stiamo aiutando nessuno e certamente non stiamo facendo il nostro lavoro nel risolvere i problemi nel modo corretto.

Non hai ancora capito il problema. Il problema non sta ottenendo le massime prestazioni: sta ottenendo prestazioni sufficienti per la tua app per essere reattiva e abbastanza veloce. Imparare a programmare significa risolvere il problema, con la minima quantità di denaro.

Odio esprimerlo in questo modo, ma ogni impressione che hai sotto la morte di CS è solo la tua pre-concezione di ciò che un "vero" programmatore dovrebbe fare.

Bene, morto o no è discutibile!

Il fatto è che nell'era tecnologica di oggi la maggior parte delle aziende assume persone per risolvere attività del tipo di flusso di lavoro nel mondo reale attraverso l'automazione del software. Non sono interessati a quanto un programma sia elegante o veloce da scrivere, purché consenta all'azienda di eseguire più velocemente con un output più elevato.

Lo stress è su più output in meno tempo. (Pensa alla commercializzazione di colture / alimenti; più rapida e più crescita con meno costi). Lo stesso sta accadendo nel mondo della tecnologia (la prossima nuova idea).

Ricorda, al giorno d'oggi, le cose si stanno muovendo più velocemente che mai a causa della quantità e dell'accesso alla conoscenza rispetto ai giorni nostri. Ai vecchi tempi, la produzione era piccola e migliore, i profitti erano maggiori. Ora il gioco è completamente cambiato. Dai un'occhiata a cose come la qualità del servizio clienti e in generale le cose non durano più a lungo.

L'eleganza e l'efficienza sono importanti per le aziende tecnologiche come Google, ecc., Anche se quei posti non sono perfetti ma puoi avvicinarti lavorando una di quelle aziende nei prossimi anni.

C'è sempre un compromesso nella vita. Puoi trovare un lavoro che paga meno, dove hai tutto il tempo e l'attenzione. Oppure, scegli di nuotare con il resto di noi per pagare meglio e ignorare le cose che non sono perfette. Più velocemente questa realizzazione sprofonda in te, puoi prepararti per il mondo reale. Non sto dicendo che dovresti ignorare la qualità e l'eleganza ma conoscere la dinamica. Sarai più felice :)

A mio avviso, alcune delle cose più interessanti che il futuro potrebbe riservare saranno sicuramente basate sulla parte scientifica dell'informatica, in particolare su una visione computerizzata / apprendimento automatico e altri algoritmi di sematisizing. Questi saranno probabilmente portati avanti nel settore (ad esempio, prendi il Microsoft Kinect) ma sono problemi così estremamente difficili che saranno certamente basati sul vasto corpus di ricerche e sui progressi compiuti negli accademici (di nuovo, prendi il Microsoft Kinect).

Penso che la normale programmazione quotidiana sia tanto un'arte quanto una scienza, ma certamente esistono aree che sono profondamente interessate agli aspetti scientifici dell'informatica. Ad esempio ricercatori per aziende e università. Se vuoi davvero essere coinvolto nelle scienze professionalmente, allora dovresti cercare un dottorato di ricerca. Tuttavia, ho trovato che le parti scientifiche della mia educazione sono continuamente preziose, nonostante abbia anche bisogno di fare affidamento sul mio lato più creativo nella realtà!

Le persone che non sanno cosa stanno facendo possono hackerare le cose con alcuni degli strumenti che hai citato ma di solito assumono le persone CS reali per creare gli strumenti, devi solo ottenere più astratto per spingerti davvero.