Programmering: Die sielkunde van rekenaars

Ons is almal nou verwant aan programmering, hetsy as gebruiker, as administrateur, as programmeerder self, maar uiteindelik is dit iets wat met die jare meer aan ons lewens gekoppel sal wees.

In hierdie artikel (die begin van 'n klein reeks wat ek beplan om te skep), Wil ek met u 'n paar konsepte deel oor wat ek oor die jare ontdek het oor programmering. Ek beweer nie dat ek te tegnies is nie, en ek sal later verduidelik. Maar wat ek wel van plan is, is om hulle die wêreld met my oë te laat sien, en as hulle hou van hoe dit lyk, laat hulle dan bietjie daarin delf

Ek sal eers die eenvoudigste punt aanval voordat ek in besonderhede ingaan.

Hoekom gaan ek nie 'n tegniese pos doen nie?

Wel, vir diegene wat my berig oor gelees het beste Linux-opdrag, sal u 'n bietjie weet oor die oorsaak van hierdie fokus. Tegnologie verander altyd, en as ek vandag iets skryf, as die pos goed ontvang word, sal ek altyd die inligting moet opdateer. In die mees algemene tale van vandag is die enigste sekerheid verandering. Hiermee bedoel ek (en die programmeerders kan my reg bewys) raamwerke groei en verander altyd vanaf hul kern, dit is omdat daar foute voorkom, en sommige kan as eenvoudig beskou word foute, terwyl ander kan word kwesbaarhede. Dit is die rede waarom ek vandag 'n boodskap oor 'n spesifieke taal kan beskerm, miskien 'n paar maande van nut, hoogstens een of twee jaar, maar dit is nie die idee nie 🙂

Elektrisiteit is belangrik

Diegene onder u wat 'n bietjie navorsing gedoen het oor die laer sagtewareprogrammeringstale, sal weet dat dit alles teruggaan na elektrisiteit. In die verlede is programmering op hardeware-vlak gedoen, dit beteken dat die ou horlosies, sakrekenaars en baie ander toestelle hul lot kon vervul deur te programmeer deur hardeware.

Die probleem

Die verandering van apparatuurprogrammering is duur en ingewikkeld 🙂 (dit is altans wat hulle vir my gesê het 🙂 ). Dit is die rede waarom verwerkers ontstaan ​​het, wat daardie hardeware-laag eintlik onttrek om ons 'n paar opdragte te gee om alles wat moontlik was deur middel van hardeware te kan doen, nou eers in die hardeware-laag. sagteware.

Verwerkers

Die verwerkers van vandag het 'n beperkte aantal funksies instruksies in baie boeke. Hierdeur kan u die mees basiese funksies uitvoer wat hardeware kan verrig, en om inligting deur die geheue van die rekenaar te mobiliseer.

registers

Registers is 'n ruimte waarin die verwerker inligting stoor om werk aan die kern te kan doen, afhangende van die argitektuur, dit kan 'n ander grootte en volgorde hê, maar op 'n eenvoudige manier is dit om data te stoor wat die verwerker een van volgende soorte werk: beweeg data, rekenkunde en logika, en beheer oor vloei. In hierdie tipe funksies kan alles saamgevat word.

Binario

Die verwerkers werk op binêre vlak, dit beteken dat hulle net verstaan 0sy 1ja 🙂. 'N Merkwaardige feit hier 😀onthou u GNU / Linux-toestemmings? wel,het u al ooit gewonder hoe die verwerker daai regte erken?? Eenvoudig 🙂 binêr. Op die laagste vlak sal 'n verwerker die toestemmings as 'n opeenvolging van 0s en 1s verstaan, en dit is die rede waarom die oktale wat ons vorm, die waardes het 1 vir uitvoering, 2 vir lees en 4 vir skryf. Vir diegene wat binêre kan lees, sal hulle verstaan ​​dat:

111100101111

Hulle gee die lees-, skryf- en uitvoertoestemmings vir die groep otros terwyl u opvoering en leeswerk vir die groep lewer groep en lees slegs vir die lêer-eienaar. Vir die nuuskieriges aktiveer die laaste drie 1's die setguid, setuid en sticky bit. As u nie weet wat hierdie binêr is nie, kan ek dit in 'n ander pos verduidelik, as u nie weet van setuid, setgid en die klewerige bietjie nie, laat ek dit aan u oor 😉 maar ek kan dit ook elders verduidelik indien nodig.

As nuuskierigheid roep ...

Wel, as u my hier gevolg het, dan moet u nuuskierigheid baie dinge begin vra, die eerste wat ek wil beantwoord (en miskien die enigste wat hierdie boodskap my sal toelaat omdat ek al baie skryf): As die oproepe dieselfde is, waarom verskil die programme dan so?

Sielkunde

Programmering is die kuns om gedagtes te leer lees 🙂 Ek wil hierdie gedeelte begin met 'n aanhaling wat ek lank gelede gelees het, het Edsger Dijkstra gesê:

As ontfout die proses van ontfout is, moet programmering die proses wees om dit in te voer

En ek kan nie 'n beter manier vind om dit alles te verklaar nie 🙂 waarom is die kuns om foute in te stel programmeer? meer as een sal op hierdie stadium wonder. Die antwoord is eenvoudig, want ons gedagtes is menslik en mense maak foute - dit is in ons natuur, en dit sal so lank wees as wat die mens op die planeet bestaan.

Rekenaars is nie verkeerd nie

Ons is diegene wat foute maak, die spanne sal hulself altyd beperk tot die weergawe van wat ons vir hulle sê, hulle neem niks aan nie, hulle interpreteer niks nie, hulle maak niks beswaar nie, hulle lees en doen net. Daarom het ek in 'n ander C-boek ooit so iets gelees:

C is onbeskof, jy kan baie daarmee doen, maar dit sal jou nooit keer om jouself in die voet te skiet as jy dit wil doen nie, of so vertel jy dit.

Dit is nogal 'n eienaardige waarheid 🙂 Aangesien u op so 'n lae vlak kan werk, is dit moontlik dat baie bewerkings wat uitgevoer word, vernietigend kan wees, iets wat nie met tale op 'n hoër vlak gebeur nie, aangesien die foutvoorkomingslae is hulle is ouer.

Alles is sielkunde

Elke taal, raamwerk, programmeerder respekteer en volg 'n soort filosofie, en as dit nie gebeur nie, het dit nie 'n baie belowende toekoms nie. Diegene onder ons wat aan UNIX en afgeleide instrumente werk, sal waarskynlik die ou frase ken:

Doen een ding en doen dit baie goed.

Hierdie filosofie word gevolg deur sommige projekte soos die kern, baie klein funksies wat net een ding doen, maar dit die beste doen.

As ons na ander tale gaan, sal elkeen 'n funksie en objektiewe funksie hê, sommige meer toegelaat en ander beperkter, maar almal volg hul eie manier van dink.

Leer om gedagtes te lees

Daar is 'n redelike algemene gesegde onder programmeerders dat daar honderde maniere is om dieselfde probleem op te los. Dit is waar, maar daar is iets dieper aan hierdie aspek. Deur bronkode te lees, kan u gedagtes lees - nie net enige gedagtes nie, maar ook die verstand van die programmeerder (of programmeerders) wat dit geskryf het. Dit is 'n soort virtuele en diepe dagboek 🙂 waarmee u die brein van die ontwikkelaar diep kan ken, en in die geval van groot projekte, kan u sien hoe hul logiese en kritiese denke mettertyd gegroei het. Iets buitengewoon wat die gedagtes van die jongste baie voed, want jy kan die beste paaie ken van mense wat dit moes ontdek 🙂

Om konsekwent te wees

Baie programmeerders en spesialiste sê dat ons daaruit moet gaan geriefsone, en hoewel dit waar is, is dit ook meer as nodig om sekere prosesse en formate te handhaaf. Dit is eenvoudig om te verklaar, ons gedagtes is herhalend en respekteer strukture, as u elke dag op dieselfde manier kode skryf, sal u binne 'n kort tydjie ophou dink aan die vorm en u daarop kan konsentreer. agtergrond. Hiermee kan u die logika van die program in plaas van die taalsintaksis. En dit is die rede waarom ek dink dat die leer van die conceptos sal altyd belangriker wees as om te leer die vorms. Dit is 'n persoonlike opinie, maar ek hoop dat u, nadat u dit alles gelees het, kan verstaan ​​waarom ek dit so beskou - ook iemand wat in C, Java, Javascript, Python, Ruby, PHP en ander moes programmeer, vertel hulle 🙂 ken die konsepte maak dit maklik om kode te skryf.

Ter opsomming

Wel, dit is die eerste stap in 'n reeks wat ek hoop dat u anders sal kan dink oor die kuns van programmering, en u selfs sal uitnooi om die konsepte te verdiep wat u in staat stel om die kode wat u miskien honderde kere geskryf het, uit te voer, maar hulle het nie opgehou om na te dink oor wat dit regtig doen nie. En vir diegene wat nog nie begin programmeer het nie, maar wel 'n bietjie wil prioritiseer bo wat regtig belangrik is om te weet 🙂 Groete