L'eccessiva dipendenza dagli strumenti implica che sei pigro? [chiuso]

Ho iniziato a programmare in C ++ su uni e l'ho adorato. Nel prossimo termine siamo passati a VB6 e l'ho odiato.

Non saprei dire cosa stia succedendo, trascini un pulsante in un modulo e l'ide scrive il codice per te.

Mentre odiavo il modo in cui VB funzionava, non posso sostenere che fosse più veloce e più facile che fare la stessa cosa in C ++, quindi posso capire perché è un linguaggio popolare.

Ora non sto definendo pigri gli sviluppatori VB nel dirlo più facilmente di C ++ e ho notato che molti nuovi linguaggi stanno seguendo questa tendenza come un C #.

Questo mi porta a pensare che man mano che più aziende vogliono risultati rapidi, più persone programmeranno in questo modo e prima o poi non ci sarà nulla di ciò che chiamiamo programmazione ora. I futuri programmatori diranno al computer ciò che vogliono e il compilatore scriverà il programma per loro come in Star Trek.

È solo un'opinione poco informata di un programmatore junior o i programmatori stanno diventando più pigri e meno competenti in generale?

EDIT: Molte risposte dicono perché reinventare la ruota e sono d'accordo con questo, ma quando ci sono ruote disponibili le persone non si preoccupano di imparare a costruire la ruota. Posso google come fare praticamente qualsiasi cosa in qualsiasi lingua e metà delle lingue fanno così tanto per te quando si tratta di debug non hanno idea di cosa faccia il codice di come correggere l'errore.

È così che mi convengo con la teoria secondo cui i programmatori stanno diventando più pigri e meno competenti in quanto a nessuno importa come funzionano le cose solo che fanno fino a quando non lo fanno.

No, gli sviluppatori non sono più pigri o meno competenti. Sì, c'è una necessità in costante calo di sviluppo reale, nel senso che lo conosci. E sì, questo è molto perché le aziende vogliono risultati rapidi, e perché non dovrebbero?

Tuttavia, esiste un punto finale. Ci sarà sempre bisogno di alcuni sviluppatori.

Molti requisiti sono gli stessi per progetti diversi. Quello di cui stai parlando è il codice dell'interfaccia utente. La maggior parte delle interfacce utente sono costituite da una serie specifica di campi (casella di testo, casella di controllo, radio, selezione, ecc.) E non ha davvero senso svilupparli da zero, ancora e ancora e ancora. Quindi vengono inseriti gli strati di astrazione per rimuovere tutto quel codice della piastra di caldaia.

Allo stesso modo il livello dati, che di solito non è altro che Inserisci questo, Elimina questo, Sostituisci questo e un gran numero di viste diverse degli stessi dati. Perché continuare a scriverlo ancora e ancora? Inventiamo gli ORM.

L'unica cosa che dovresti sviluppare è il codice che è unico per il business per cui stai sviluppando.

Ma ci sarà sempre quella unicità - dove non c'è, c'è un'opportunità commerciale - e ci sarà sempre la necessità che le persone scrivano codice.

Detto questo, tieni anche presente che c'è molto di più nell'essere uno sviluppatore che scrivere codice. Sia che tu stia codificando in puro assemblaggio o mettendo insieme componenti Drupal per creare un sito basato sui contenuti, stai traducendo le esigenze aziendali in qualcosa che il computer capisce.

La parte più importante dell'essere uno sviluppatore di software è essere in grado di comprendere i requisiti aziendali abbastanza bene da spiegarlo al computer.

Non importa quale lingua stai usando per spiegare le cose al computer, conta solo che puoi. E questo è un duro lavoro, niente di pigro al riguardo.

Un meccanico è pigro e meno competente perché usa una chiave idraulica ?

Immagine due ragazzi, diciamo Brad e Pete. Entrambi lavorano in due garage cambiando le gomme su base giornaliera. Brad è un ragazzo intelligente, sa che l'uso di strumenti migliori può fare il suo lavoro meglio e più rapidamente. L'uso della chiave idraulica lo aiuta a cambiare più pneumatici. I clienti stanno aspettando in una coda più breve - tutti sono felici. Bard sa anche che questa chiave a volte è troppo grande e non può aiutarlo con diversi tipi di viti.

D'altra parte, Pete afferma che la chiave idraulica è una bestemmia e Brad non è un "vero meccanico". Certo Pete può fare solo la metà di quello che fa Brad, ma lo fa in "modo giusto".

Cosa ne pensi, quali clienti del garage sceglierebbero? Uno che impiega 20 minuti o uno con 40 minuti di attesa.

È abbastanza simile con la programmazione. Il C ++ è un buon linguaggio e ha il suo scopo (principalmente le prestazioni). Quello che mi piace di linguaggi come C # è che posso concentrarmi su un problema, pensare all'algoritmo senza tutto il rumore che fa C ++ come avvisi ambigui sul compilatore, comportamenti indefiniti eccetera. Lo sviluppo sta diventando sempre più complicato che ai vecchi tempi di mainframe e primi PC, ma il cervello umano rimane lo stesso - praticamente stupido. Un'app può essere eseguita in cloud, mobile, desktop e ci sono molte dipendenze, problemi di sicurezza e altri problemi. Voglio avere uno strumento migliore per concentrarmi su problemi più complicati e risolverli.

Usa strumenti migliori per fare il lavoro - non c'è niente di sbagliato in questo.

Quindi, come chiamiamo programmazione ora

Tu dici:

I futuri programmatori diranno al computer ciò che vogliono e il compilatore scriverà il programma per loro come in Star Trek.

fai solo un esperimento: guarda Star Trek e prova a interpretare le cose che al computer viene ordinato di fare un po '"senza grazia".

• Tè, grigio conte, caldo -> molto vapore.
• Tè, grigio conte, 60 gradi Celsius -> una pozzanghera e una nuvola di vapore
• Earl Grey, 60 gradi Celsius -> una pozzanghera
• Earl Grey, 60 gradi Celsius, in una tazza -> una tazza con una goccia dentro
• Earl Grey, 60 gradi Celsius, 0,2 litri, in una tazza. -> finalmente (ok, puoi aggiungere altro)

Quando chiami la programmazione: "Conoscere l'utilizzo della memoria, i puntatori, ecc.", Sì, immagino che diventerà meno importante (poiché "Conoscere http, openid, unicode" diventerà più importante).

Ma, a mio avviso, tutto è "complessità accidentale", e il vero lavoro come programmatore è "Fare in modo che le macchine per la costruzione risolvano i problemi, assicurandosi di aver compreso abbastanza dei problemi accidentali per raggiungere il compito" e, in base a tale definizione, qualcuno che conversa con un Star Trek il computer deve essere un programmatore (cioè avere le stesse virtù di adesso).

I programmatori non stanno diventando più pigri. I programmatori sono sempre stati pigri. Essere pigri fa parte della natura fondamentale del lavoro. Il problema è che le persone presumono che essere pigri sia negativo. Essere un programmatore "pigro" è una virtù.

Ricorda il vecchio adagio "Lavora in modo più intelligente, non più difficile". Questa è l'unità fondamentale dei programmatori.

I ragazzi che hanno costruito e programmato i primi computer non lo hanno fatto perché a loro piaceva fare un duro lavoro, lo hanno fatto per EVITARE un lavoro ancora più duro. (facendo pagine di calcoli a mano)

Essere "pigri" è una delle ragioni fondamentali per cui i programmatori programmano. Ecco perché scriviamo linguaggi nuovi e sempre di livello superiore, debugger e IDE migliori e migliori, script di shell e build, ecc ...

Un programmatore osserva un problema, qualunque cosa faccia o pensi;

"posso automatizzare questo?" , "quanto tempo ci vorrebbe?" , "quanto tempo mi risparmierebbe?"

Lo facciamo perché siamo pigri, non vogliamo fare un compito ripetitivo e noioso quando potremmo fare cose molto più divertenti.

Se i programmatori non fossero pigri, nessun programmatore avrebbe mai visto la necessità di scrivere un nuovo linguaggio o compilatore.

Per quanto riguarda l'idea che un programmatore sia "pigro" perché deve "cercare le cose", e allora, chi se ne frega. Il presupposto che sia più lavoro per imparare ogni sfumatura di una determinata lingua (e non cercare mai qualcosa) quindi è quello di trovare e usare ciò di cui hai bisogno quando ne hai bisogno è un errore. Inoltre, il processo di ricerca delle cose è il processo di apprendimento e la ragione stessa per cui esistono siti come questo.

Se qualcuno vuole un duro lavoro di programmazione, direi loro di scrivere a mano un codice macchina grezzo in esadecimale. Fatto? Vuoi qualcosa di più duro? Ora esegui il debug.

Prima di tutto chiamare le persone che usano, ad esempio, le lingue con lazy garbage collector, è un po 'come chiamare le persone che guidano le auto con la trasmissione automatica pigra. IMO è un po 'ridicolo.

Per quanto riguarda la competenza, la programmazione è molto più popolare ed egualitaria di un tempo. Quindi sì, ci sono molti nuovi arrivati, che mancano di conoscenza. Non intendo tuttavia che ci siano improvvisamente programmatori meno competenti. In effetti ce ne sono altri. Stai solo guardando il lato sbagliato della curva a campana.

Sono tentato di dire "sì, i programmatori junior presunti non informati sono diventati pigri e meno competenti", ma proviamo una risposta seria:

Molte cose sono diventate più facili, ma ci si aspetta di più da noi. Attualmente sto creando un'app Web che ha molte funzionalità che si trovano in genere in app gui ben fatte (visualizzazioni a schede, griglie modificabili e ordinabili, esportazione Excel ecc.). Gli strumenti che sto usando (ExtJS ecc.) Rendono ragionevolmente poco costoso creare tale app.

Dieci anni fa, sarebbe stato quasi impossibile, almeno molto costoso, creare una tale app. Ma dieci anni fa, un semplice modulo HTML con una tabella HTML sarebbe stato sufficiente per i clienti. Oggi, con lo stesso sforzo, sono possibili risultati migliori (almeno più belli) e i clienti si aspettano di ottenerli!

In generale, uno sviluppatore di software di oggi ha bisogno di conoscere più lingue di uno sviluppatore di software 20 anni fa. Allora, qualcosa come C e SQL erano sufficienti. Oggi sto usando JavaScript, HTML, Groovy, Java, SQL tutti nello stesso progetto.

I programmatori stanno diventando meno competenti e più pigri in alcuni modi, ma più competenti in altri, sebbene il divario C ++ / VB non sia la ragione o un sintomo nella mia mente.

L'uso di un builder GUI non è pigro, è solo diverso, riguarda gli strumenti per il lavoro in corso. Se un programmatore di assemblatori chiamasse un programmatore C ++ pigro, chiameresti cazzate (giustamente) e lo stesso vale per C ++ e VB. VB ti consente di fare rapidamente alcune cose a scapito di un certo controllo. Le barriere per iniziare a scrivere codice sono certamente inferiori ma è una cosa molto diversa dalla pigrizia: impari cose diverse e le applichi in modi diversi. I programmatori VB non sono più pigri di quanto i programmatori C ++ non siano produttivi, funzionano e producono semplicemente in modi diversi.

Su un punto più ampio, generalmente l'educazione dei programmatori è migliore di quanto non sia mai stata. L'idea di non utilizzare il controllo del codice sorgente, ad esempio, è piuttosto odiosa per quasi tutti ora dove 10 o 20 anni fa non sarebbe stato così vero. Allo stesso modo sono più propensi a capire e vogliono usare test unitari automatici, integrazione continua e così via, quindi in questo senso sono più competenti di loro.

Ma ciò che penso sia cambiato è che le persone non sanno più come risolvere i problemi nel modo in cui erano abituati ed è vero praticamente per qualsiasi linguaggio tradizionale. La risposta immediata a qualsiasi problema ora è Google e sebbene sia eccezionale e funzioni il 95% delle volte, vedo troppi programmatori che non hanno idea di cosa fare quando non lo fanno.

Non è che non capiscono i fondamenti (non lo fanno, ma in realtà non è un grosso problema), è che non riescono a scomporre i problemi in modo tale che possano persino capire quali fondamentali hanno bisogno essere alle prese con.

Prima di Google non avevi scelta. Le tue risorse erano la tua squadra, alcune decine di libri fisici a cui potresti avere accesso e il tuo cervello. Tale impostazione significa che se trovi un problema, è probabile che lo risolvi da qualcosa vicino ai primi presidi, quindi sei diventato abbastanza bravo o abbastanza disoccupato rapidamente.

E questo era vero indipendentemente dalla lingua che hai usato. VB è di alto livello e si nasconde molto, ma ciò significa che, quando si tratta di risolvere i problemi, ciò significa che in realtà c'era molto di più da fare. Se qualcosa non funzionava, dovevi diventare più creativo e lavorare di più perché avevi meno controllo. Come programmatore VB (e parlo per esperienza) non conoscevi meno dei ragazzi del C ++, sapevi solo cose diverse ma entrambi sapevi come risolvere i problemi.

Ma è probabilmente difficile vederlo come una critica significativa dei programmatori in questi giorni, non sviluppano le abilità perché non ne hanno bisogno, ma è una debolezza rispetto a coloro che hanno acquisito le abilità da quando erano necessarie.

Vedo dal tuo profilo che hai 23 anni. Lascia che ti metta i denti e ti dia una prospettiva da qualcuno circa il doppio della tua età che lo fa da molto tempo:

In passato c'era molto meno di tutto, a cominciare dalla potenza di calcolo, dalla memoria e dalla larghezza di banda della rete, se si avesse una rete. Quelle scarsità mettono limiti a ciò che potresti ragionevolmente fare, rendendo molto più facile avvolgere la testa intorno a tutto. Il software che eseguiamo oggi è molto più capace rispetto alle cose con cui ho lavorato 25 o 30 anni fa, e queste capacità significano che ce ne sono molte di più. Ciò rende molto più difficile la raccolta di una comprensione approfondita di tutto ciò che una persona può fare. Parte di ciò ha a che fare con il fatto che le cose continueranno ad aumentare di complessità e una parte ha a che fare con gli effetti collaterali dell'età.

L'ecosistema informatico sta diventando molto simile ai sistemi biologici: gli esseri umani sono più complessi degli organismi monocellulari e parti di noi devono specializzarsi se vogliamo diventare bravi a fare qualcosa. Le mie cellule cerebrali sono terribilmente brave nelle cose intelligenti, ma andrebbero perse se immerse nel mio rene e ci si aspetta che facciano cose renali. Allo stesso modo, il tipo che è bravo a scrivere processori di segnali digitali potrebbe non avere idea di come funzioni l'indicizzazione full-text, perché non è la sua specialità. Ma entrambi potrebbero evolversi un po 'e imparare a capirlo se necessario, ma ci sono limiti a quanto lontano puoi diffonderti ed essere comunque efficace in quello che fai.

... nessuno si preoccupa di come funzionano le cose solo che lo fanno fino a quando non lo fanno.

Quando hai un lavoro da svolgere, devi spesso fare il salto di fiducia che uno strumento che stai utilizzando (libreria, RDBMS, intero sottosistema, ecc.) Funziona come dovrebbe. Una delle cose che l'esperienza porta è la capacità di scegliere quali buchi di coniglio farai per scovare i guasti nei tuoi strumenti, risolvere il problema e poi tornare a quello che stavi facendo.

Ora non sto definendo pigri gli sviluppatori VB nel dirlo più facilmente di C ++ e ho notato che molti nuovi linguaggi stanno seguendo questa tendenza come un C #.

È tutta una questione di prospettiva. Ero in giro per vedere la nascita del C ++, e segue anche questa tendenza. C ++ rende le cose molto più facili di C, C rende le cose molto più semplici dell'assemblaggio e l'assemblaggio rende le cose molto più facili della scrittura manuale di codici postali. Come qualcuno che ha scritto molto assemblaggio e assemblato alcune cose a mano da zero, ciò ti metterebbe, come programmatore C ++, a tre passi lungo il percorso "è più facile".

Qualcosa che mantengo da molto tempo ora è:

Uno dei maggiori punti di forza del linguaggio Visual Basic è che un principiante può imparare a fare molte cose utili abbastanza rapidamente.

Uno dei maggiori punti deboli dei programmatori di Visual Basic è che impareranno a fare molte cose utili abbastanza rapidamente e quindi smetteranno di imparare qualsiasi cosa.

Quando ho insegnato a programmare il primo esercizio, il primo giorno di lezione è stato come creare un'applicazione in NOTEPAD e compilarla usando VCC o VBC. Sì, queste sono cose che noi (come programmatori) non facciamo quotidianamente, ma dovremmo capire cosa succede quando premiamo "F6".

I programmatori non stanno (generalmente) diventando più pigri di quanto ci aspettiamo per ottenere di più dai nostri strumenti. Non ho bisogno di digitare "get / set" 10.000 volte al giorno, MI PIACE che Visual Studio e altri strumenti come Code Smith e Resharper lavorino per me per fare ciò che so già fare in modo da poter applicare i miei sforzi per capire come fare "nuove" cose. Ciò non mi rende più pigro, ciò mi rende "innovativo".

Come sviluppatore professionista non dovremmo "perdere tempo" a reinventare la ruota, ma dovremmo chiaramente capire cosa succede nel realizzare la ruota che useremo. Queste sono cose che dovremmo "imparare" come sviluppatori di studenti (ma sfortunatamente spesso non lo sono). Se uno sviluppatore non capisce la tecnologia "scatola nera", ciò li rende davvero meno "competenti". La maggior parte degli sviluppatori "capisce fondamentalmente" come funziona un driver ODBC, capisce solo "cosa" fa. Devo sapere come funziona una trasmissione per essere un conducente competente? Direi di no. Mi rende un proprietario di auto più competente sapere questo, sì.

La necessità di un rapido sviluppo delle applicazioni (link wiki obbligatorio: http://en.wikipedia.org/wiki/Rapid_application_development ) ha significato che gli sviluppatori scrivono meno codice e gli sviluppatori più recenti comprendono meno, perché non hanno bisogno di capire come implementare un elenco collegato poiché hanno qualcosa di più alto livello su cui concentrarsi.

Non riesco a catturare, uccidere, spellare, macellare e curare la carne, e dubito che il tipo al bar al piano di sotto possa farlo, ma continuo a ricevere il mio panino al bacon da lui, proprio come gli uomini d'affari ottengono le loro app da sviluppatori che non conoscono puntatori (come me!)

È stato detto che le grandi discipline scientifiche sono esempi di giganti in piedi sulle spalle di altri giganti. È stato anche detto che l'industria del software è un esempio di nani in piedi sulle punte di altri nani.
- Alan Cooper

Un buon sviluppatore di software non è colui che reinventa la ruota. È in grado di utilizzare gli strumenti che sono stati costruiti prima di lui. Non perde tempo a riscrivere le stesse vecchie cose noiose, che sono state scritte centinaia di volte, diventa fastidioso rapidamente e probabilmente esiste già in una versione di qualità superiore.
Se dai loro un linguaggio che ha già in bundle dischi di pietra rotondi, è probabile che non passino troppo tempo a reinventare le ruote. Se avessi un centesimo per ogni routine di copia di stringhe mai scritta in C, probabilmente avrei potuto acquistare l'intero settore del software.

La pigrizia è infatti una delle tre grandi virtù di un programmatore. Gli strumenti di cui parli sono stati costruiti da buoni programmatori per buoni programmatori, per ridurre la ridondanza e la noia e quindi aumentare la produttività e la motivazione. Tali strumenti possono infatti avere effetti negativi sui principianti, in quanto inibiscono una comprensione più profonda dell'aspetto di programmazione che semplificano.

No. Stai solo invecchiando.

Non scherzando, quello che stai vivendo è una sorta di diritto di passaggio per gli sviluppatori. Da quando le prime lingue di livello superiore hanno soppiantato l'assemblea. Allora avresti sentito tutti i programmatori ASM lamentarsi della stessa cosa. Tra 5 anni, tutti gli sviluppatori di Ruby on Rails si lamenteranno di quanto pigro l'ennesimo raccolto di nuovi strumenti stia rendendo le persone.

Questo ritornello verrà ripetuto fino a quando le macchine non ci distruggeranno tutti: "Sembra che la tecnologia X stia rendendo gli sviluppatori più pigri e peggiori della tecnologia Z che ho sempre usato?"

La buona notizia è che, sebbene i compilatori abbiano fatto molta strada, le persone hanno ancora bisogno di assemblaggio e C e di tutti gli altri vecchi sostenitori per molte cose ... non solo la maggior parte dell'innovazione tecnologica all'avanguardia. Se vuoi essere all'avanguardia, ti suggerisco di aggiornare il tuo set di abilità.

Dalla mia esperienza, sì e no, ma non è colpa delle lingue; è colpa degli stessi sviluppatori. Ho lavorato con molti sviluppatori a cui non importava nulla di fare le cose nel modo giusto, di migliorare se stessi o di fare davvero altro che sfornare la stessa merda che hanno fatto per anni. Cercare di far migliorare queste persone è come parlare a un muro di mattoni: per la metà del tempo ignorano qualsiasi cosa che non hanno usato in passato o non sono del tutto disposti a "rischiare" con qualcosa che potrebbe migliorare la loro produttività .

Le lingue più avanzate non sono il problema, sono i programmatori che non trattano questa professione come un mestiere in continua evoluzione. Non devi essere intimamente consapevole di tutto ciò che è nuovo o saltare su ogni nuovo carrozzone, ma almeno dovresti cercare di diventare migliore in quello che fai.

Per un esempio concreto: sono uno sviluppatore .NET di professione. Mi aspetto che uno sviluppatore .NET competente sia a conoscenza di cose come LINQ, Entity Framework, WPF, MVC e simili; non devono averlo usato o spingerlo sul posto di lavoro, ma almeno una comprensione passeggera di "Questo esiste" è meglio dell'assoluta mancanza di conoscenza che vedo troppo spesso.

Ho programmato solo per circa 4 anni di lavoro ora e questo è stato quasi interamente c #. Ho imparato il C ++ quando ero al College e Uni, ma non sarei in grado di farci molto adesso.

Quindi, per lo sviluppo della GUI, potrebbe essere considerato pigro, ma poi non si può vedere che è possibile concentrarsi meno sulla codifica di quella parte e più sullo sviluppo della logica dell'applicazione stessa.

quindi forse piuttosto che diventare meno competenti stanno spostando l'attenzione, probabilmente molto verso sistemi di comunicazione e distribuiti, ad esempio cloud computing e SOA. Anche se questo potrebbe essere lo stesso dei pensieri simili di un programmatore intermedio.

È probabilmente vero che la barriera all'ingresso nei lavori di programmazione è diminuita ogni anno. Ad esempio, è ora possibile per gli ingegneri la cui specialità non è principalmente software e artisti di scrivere codice usando linguaggi di scripting.

Ciò implica che il livello di competenza è effettivamente aumentato, se si considera l'ampiezza. Il fatto che gli artisti possano programmare significa anche che ora ci sono più programmatori con capacità artistiche.

C'è una differenza tra "programmatore" e "programmatore reale". Si prega di non chiamare HTML un linguaggio di programmazione, ma ci sono molti "programmatori HTML". Ognuno di voi (programmatori / sviluppatori) può fare un'esperienza con i colleghi - basta "disattivare Internet (in realtà non consentire loro di utilizzare i motori di ricerca)", e vedrete che siederà una grande varietà di "programmatori" senza lavoro. Che cosa possono fare, sanno solo che se hanno bisogno, ad esempio, di cercare nel testo, dovrebbero "cercare" la ricerca di testo in% language_name% '"? Non possono rispondere a questo: quali sono le differenze negli algoritmi di Boyer-Moore e Knuth-Morris-Pratt.

Quindi, IMO, programmare significa risolvere i problemi, conoscere molto bene come minimo un linguaggio di programmazione con il suo "STL" e altre cose importanti. La programmazione è un'arte, è un tipo di vita, non è una cosa che può essere fatta da tutti.

Ci scusiamo per più sarcasmo del necessario, ma penso che questo articolo dica meglio di me.

Ho sbagliato?

UPD: La cosa principale e importante è la conoscenza dei fondamenti, come algoritmi, strutture di dati ecc. Quanti di voi possono implementare le librerie / funzioni standard / ecc nel caso in cui oggi venga rimosso accidentalmente? IMO, il programmatore dovrebbe usare un codice "alieno" sviluppato / ben debug (librerie / framework / ecc.), Ma dovrebbe essere in grado di reinventare la ruota, sempre!

Considerando che VB è facile da usare e programmatori pigri scelgono VB per questo:

Penso che VB sia circondato da un grande mito di essere facile da usare. Questo mito era originariamente in qualche modo vero: nei giorni intorno al 1991-1994, quando i dinosauri camminavano sulla terra, c'erano solo due veri strumenti RAD in giro, VB e Delphi. Erano abbastanza simili, ma NOTA QUESTO: Delphi e VB erano ugualmente facili da usare! L'unica differenza notevole tra loro era che VB aveva una sintassi completamente illogica e produceva programmi incredibilmente lenti.

Le GUI C / C ++ sono state scritte in MFC o in API Win non elaborate. Quindi VB era certamente più facile da usare rispetto all'alternativa Microsoft. Quindi il frantoio è andato così:

• VB è più facile da usare rispetto all'API Microsoft C / C ++ / Win. ->
• VB è più facile da usare. ->
• VB è facile da usare. ->
• VB è il più semplice.

Questa voce continuò poi, anche se Delphi era sempre altrettanto facile, se non più facile, dal momento che Pascal è un linguaggio logico e sano.

Alla fine degli anni '90 Borland pubblicò un C ++ equivalente a Delphi: C ++ Builder. Ora c'erano 3 strumenti altrettanto facili. Intorno a questo tempo, i pochi argomenti razionali rimanenti per usare VB sono morti. Eppure il mito è sopravvissuto ancora. "VB è il più semplice".

Poi è arrivato Java e c'erano anche diversi strumenti RAD per esso (e per la sua versione fiasco di Microsoft chiamata J ++). Eppure il mito di VB sopravvisse.

Quindi Microsoft ha creato anche il supporto RAD per C ++, e ha anche creato C #, trasformando tutto in una grande sostanza chiamata .NET. Dato che il mito di VB sopravvisse ancora, furono in grado di ingannare i vecchi sviluppatori VB per usare VB.NET invece di C ++ o C #. Anche se VB.NET era piuttosto non compatibile con le versioni precedenti di VB.

Oggi VB è un linguaggio completamente ridondante. Lo strumento RAD non è più semplice di qualsiasi altro strumento RAD. La sintassi del linguaggio è decisamente orribile, così grave che in realtà incoraggia la cattiva progettazione del programma e la cattiva pratica di programmazione.

Esiste un'enorme varietà di attività raggruppate sotto la bandiera della "programmazione" e un numero sempre maggiore di lavoratori coinvolti nella parte "tecnica" della scala. Non è necessario essere in grado di scrivere compilatori o anche di scegliere tra una serie di algoritmi per risolvere un problema specifico per mettere insieme un sito Web in PHP. L'industria / società ha bisogno di molte persone che producono tali siti Web (apparentemente) e anche un certo numero di programmatori che lavorano su problemi più difficili. Quel secondo gruppo non è pigro o incompetente, nel suo insieme, o i nostri aeroplani andrebbero in fiamme, i bancomat che erogano quantità casuali di denaro, le macchine a raggi X che erogano dosi fatali di radiazioni, i mercati finanziari diventano assenti ecc. Aspetta, dimentica a proposito di quest'ultimo :-)

Un lato di ciò che penso che tutte le altre risposte stiano solo dando un'occhiata è che questa è solo la tendenza generalizzata che va dalle lingue di basso livello a quelle di alto livello.

Sì, l'industria del software si sta spostando da lingue di basso livello a lingue di alto livello, lo ha sempre fatto e probabilmente continuerà a farlo finché creeremo strumenti migliori. Sì, questo potrebbe essere considerato diventare pigro, poiché hai dovuto lavorare molto duramente per fare cose che sono fondamentali per lo standard di oggi. Ma non direi meno competente. La competenza sta semplicemente passando dall'implementazione alla progettazione.

Livello basso È in qualche modo soggettivo, ma a un livello basso, stai lavorando più vicino all'hardware. C'è meno tenuta di mano e ipotesi di intenti. Vengono presentati gli strumenti di base e le operazioni eseguite vengono lasciate al programmatore. Le lingue di basso livello sono arrivate per prime, e di solito sono gli strumenti della vecchia guardia poiché le lingue di livello superiore non esistevano all'inizio. Ci sarà sempre qualche sviluppo di basso livello. Ma non vorrei creare un sito Web in assemblea.

Alto livello L'obiettivo ad alti livelli è automatizzare la funzionalità di base e semplificare la programmazione. Abbassa la barra di accesso per i nuovi programmatori, esegue le operazioni più rapidamente e standardizza il modo in cui rappresentiamo ed elaboriamo i dati, spesso con un sovraccarico. Prendi in considerazione una stringa. All'inizio, qualcuno probabilmente usava 1-26 per az, e usava solo 5 bit e doveva solo sapere che dimensione avevano le sue parole. Quindi è stato sviluppato lo standard ascii e abbiamo avuto stringhe C con un carattere di terminazione. Ora abbiamo oggetti che gestiscono le cose per evitare overflow del buffer e sottotipi speciali che non consentono i caratteri di escape. O un ciclo. Un ciclo "for" è sempre leggermente più alto di un ciclo "while". E un ciclo "while" è in realtà solo la rappresentazione di un modo strutturato di chiamare GOTO.

Anche,

I futuri programmatori diranno al computer ciò che vogliono e il compilatore scriverà il programma per loro come in Star Trek.

Benvenuti nel futuro! Questo è esattamente ciò che fanno i compilatori. In passato la gente doveva scrivere a mano il codice della macchina. Ora l'abbiamo automatizzato e diciamo semplicemente al computer come scrivere il codice macchina per noi.

Penso che da qualche parte lungo la strada hai perso di vista ciò che i programmatori vengono pagati per fare.

Il nostro prodotto non è un codice, è un software funzionante.

Non stiamo costruendo mobili in cui le code di rondine tagliate a mano in qualche modo conferiscono un valore aggiunto a causa di tutta la "maestria" manuale che è stata inserita.

Siamo pagati per risolvere i problemi aziendali sui computer). Se riesci a consegnare lo stesso prodotto in meno tempo per meno soldi, penso che sia nostro OBBLIGO eliminare la pretesa che i programmi C ++ siano superiori semplicemente perché sono più complessi da costruire.

Il rapporto di (sviluppatori di programmi principali / conteggio degli sviluppatori) sta diminuendo perché:

• Gli strumenti stanno diventando più facili, questo significa che sono necessari talenti più piccoli per lo stesso problema

• Le persone si stanno abituando alle tecnologie IT, questo è più disposto a spendere soldi per strumenti personalizzati

• La letteratura informatica sta crescendo esponenzialmente, la specializzazione e la divisione del lavoro sono in aumento, quindi non ci sono più persone "Aristotele" che parlano di tutto (in realtà non hanno bisogno di sapere tutto a causa degli strati di astrazione)

• Più posti di lavoro offerti, il filtro viene allentato

• È necessaria una maggiore automazione in ogni ciclo di vita, la domanda è in aumento e l'offerta non è sufficiente

• Il rapporto degli sviluppatori rispetto alla popolazione è in aumento.

  Quindi le persone non diventano più pigre e meno competenti, la media cala perché l'informatica è un'area più aperta ora.

Molte risposte dicono perché reinventare la ruota e sono d'accordo con questo, ma quando ci sono ruote disponibili le persone non si preoccupano di imparare a costruire la ruota.

Stai minando il tuo intero punto dal fatto che in qualche modo, le ruote sono ancora fatte. Vedo il tuo punto, ma ho notato che in qualsiasi disciplina, ci sono abbastanza persone interessate a cose di basso livello per continuare. Ad esempio, utilizzo Qt per creare GUI. Quello strumento non è arrivato per magia, le persone hanno sviluppato il legame tra le cose di basso livello e quelle che faccio. Meno persone capiscono le cose di basso livello, sì. Sempre meno persone possono anche uccidere il proprio cibo o riparare la propria auto, ma la società riesce a sopravvivere.

Prima del 1940 i computer erano circuiti cablati. Quindi Von Neuman ha avuto l'idea delle posizioni di memoria memorizzata. Sono sicuro che quei programmatori del MIT pensavano che avrebbe degradato il loro commercio in qualcosa di troppo semplice. Poi è arrivato assembly, poi è arrivato FORTRAN, quindi ada, quindi C, quindi c ++, quindi java e così via. Il punto è che il punto di una lingua è consentire un'ulteriore e ulteriore astrazione. Questo è sempre stato l'obiettivo ed è la ragione per cui c ++ ha preso piede e poi java dopo di esso. La mia più grande mania è che le università non insegnano più agli studenti nulla sui computer. Non assumo programmatori c # se non conoscono c ++ come il palmo della propria mano. Perché? Perché è troppo facile essere un cattivo programmatore tanto più il linguaggio diventa astratto. Devono comprendere i puntatori, la gestione della memoria, l'associazione dinamica ecc. . dentro e fuori prima che potessero eventualmente capire C # al livello in cui mi fido di loro per contribuire alla nostra base di codice. Faccio anche fatica a creare file prima di consentire loro di utilizzare Visual Studio. Detto questo, adoro C # e un buon IDE, ma sono buoni come strumenti quando vengono compresi correttamente. Secondo me, un'astrazione è molto utile quando comprendi i particolari che vengono sottratti - è un'idea molto vecchia, vedi Thomas Aquinas sulla relazione dell'Astrazione con i particolari.

Penso che un altro buon esercizio per gli sviluppatori entry level sia quello di far loro scrivere alcune applicazioni usando l'API di Windows. Quindi, dopo averlo finito, fallo diventare orientato agli oggetti dove ogni modulo eredita dalla tua classe di finestra generica. Invitali a incapsulare il ciclo degli eventi e a riportare alcuni puntatori di funzioni che tornano alla loro classe di modulo. Quindi dì buon lavoro, Microsoft l'ha già fatto per te, si chiama System.Windows.Forms. Divertiti.

Se devono essere sviluppatori web, chiedi loro di scrivere alcuni programmi CGI in modo che comprendano il POST, GET ecc ... e quindi eseguano lo scripting della pagina. Ha ASP.NET e PHP molto più sensati.

Se stanno lavorando a un livello inferiore su una rete, falli scrivere alcune app usando i socket prima di introdurle nelle librerie che l'hanno già fatto.

Ho scoperto che questo migliora la produttività a lungo termine perché fornisce loro gli strumenti e le intuizioni corrette per risolvere i propri problemi.

Le università dovrebbero farlo, ma non lo sono, quindi dobbiamo farlo.

Detto questo, concordo sul fatto che sta diventando sempre più difficile trovare programmatori che valga la pena di uscire dal college, principalmente perché non sono stati eliminati perché sono stati costretti a scrivere algoritmi ricorsivi ed elenchi collegati. Inoltre, di solito hanno avuto solo corsi Java o .NET e quindi non capiscono niente del modo in cui funzionano. Tuttavia, l'astrazione è piuttosto utile se utilizzata correttamente.

(..) prima o poi non ci sarà più ciò che chiamiamo programmazione ora

Non sono d'accordo con questo punto.
Senza sapere cos'è la coscienza, il lavoro del programmatore è sicuro.

Ecco come appaiono le "macchine pensanti" al momento:

-Ferma cambiando argomento!
-Pensavo che il nostro amore fosse speciale.
-Ferma cambiando argomento!
-Non sto cambiando argomento.
-Sei! Sto cercando di parlare della tua incapacità di capire di cosa stiamo parlando.
-Non è nemmeno vicino. la mia canzone dei Beatles preferita è in tutto l'universo. qual è il tuo?

Credo che solo quei programmatori che non ottengono questo punto siano in qualche modo condannati.

Ad esempio la risposta di Dehumanizer :

Non possono rispondere a questo: quali sono le differenze negli algoritmi di Boyer-Moore e Knuth-Morris-Pratt.

E con "questo punto" intendo - è sbagliato provare a superare i computer con quelli che sono i migliori - algoritmi. Invece il programmatore dovrebbe aiutare il computer con il contesto, raccontando dei problemi che stiamo cercando di risolvere.

Gli strumenti stessi non risolvono i problemi, ma solo (a volte) rendono i programmatori più efficienti.

È come con: "le pistole non uccidono, gli umani fanno".

Assolutamente no. Nella mia esperienza, l'uso degli strumenti di sviluppo corretti consente un rapido sviluppo delle applicazioni senza sacrificare la qualità. In effetti, direi che, per la maggior parte, la qualità è aumentata a causa della nostra "eccessiva dipendenza dagli strumenti". Inoltre, gli strumenti di sviluppo possono ridurre la curva di apprendimento e introdurre più persone nella programmazione. Questo, ovviamente, ha un aspetto negativo, poiché ci sono molti più programmatori alle prime armi, ma tutto sommato, aiuta nel processo creativo e spinge la tecnologia in avanti.

L'eccessiva dipendenza dagli strumenti implica che sei pigro?

In generale, 'No'; ma c'è un grande avvertimento.

Ho iniziato a programmare in C ++ su uni e l'ho adorato. Nel prossimo termine siamo passati a VB6 e l'ho odiato.

Non saprei dire cosa stia succedendo, trascini un pulsante in un modulo e l'ide scrive il codice per te.

Si Certamente. La tua esperienza in uni parla della stessa avvertenza che ho citato.

Se non sai quale problema sta risolvendo il tuo strumento o non sei in grado di risolvere i problemi quando il tuo strumento ha problemi propri, allora questa è una grande bandiera rossa. Questa circostanza non implica necessariamente pigrizia, ma probabilmente implica inesperienza.

Penso che ci siano 2 tipi di programmatori. Ci sono programmatori che programmano solo per portare a termine il lavoro a causa forse di una scadenza o forse solo per essere più produttivi. Direi che erano pigri. Credo semplicemente che non abbiano interesse a "come" un computer fa quello che fa o "come" un programma fa quello che fa.

Poi ci sono programmatori appassionati, come me. I programmatori appassionati, come me, amano sapere esattamente cosa sta succedendo nella CPU. Proprio come un bravo psicologo cerca di capire cosa sta succedendo nella testa umana, i progchologi, come me, vogliono sapere cosa sta succedendo all'interno della CPU. Quindi apprendiamo, analizziamo e analizziamo un programma e utilizziamo strumenti come Reflector e disassemblatori per cercare di capire come funziona un programma.

Ho una silenziosa speranza che le cose cambino. Le CPU non si ridimensionano così tanto verticalmente, solo orizzontalmente, e ARM, ecc. Saranno limitate dalle risorse nel prossimo futuro.

È del tutto possibile che la domanda di programmazione senza trascinamento diminuirà e vedremo alcuni lavori più interessanti.