wi_lius

Ne programavimo kalboje esmė. Svarbiausia susidaryti „programuotojo“ mąstymą, po to lieka tik formalumas išmokti naujos kalbos sintaksę ir API. Aš esu C++ šalinkinas, bet čia nelabai verta per daug ginčytis – rinkis tą, kurią nori.
HTML yra žymėjimo kalba (markup), skirta aprašyti vartotojo sąsajai. Dabar dauguma technologijų turi XML stiliaus GUI aprašymą. Šiaip HTML kaip ir būtinas – būti programuotoju ir nemokėti net paprasto puslapiuko sukoduoti būtų gėda.
Kiek įmanoma dažniau naudok ciklus. Net jei reikia tik nuo 1 iki 2 prasukti – vis tiek naudok. Svarbu, kad išmoktum nerašyti pasikartojančio kodo.
Programavimas kur kas daugiau nei kodo rašymas. Visų pirma turi kažkokią problemą, kuri gali būti ne visai elementari. Turi sugalvoti, kaip ją spręsti. Tada reikia apmąstyti, kaip geriausia tą sprendimą implementuoti. Galiausia eini kodo rašyti. Tikėtina, kad berašydamas susidursi su nauja problema, ir vėl teks pereiti prie mąstymo stadijos.

Ne programavimo kalboje esmė. Svarbiausia susidaryti „programuotojo“ mąstymą, po to lieka tik formalumas išmokti naujos kalbos sintaksę ir API. Aš esu C++ šalinkinas, bet čia nelabai verta per daug ginčytis – rinkis tą, kurią nori.
HTML yra žymėjimo kalba (markup), skirta aprašyti vartotojo sąsajai. Dabar dauguma technologijų turi XML stiliaus GUI aprašymą. Šiaip HTML kaip ir būtinas – būti programuotoju ir nemokėti net paprasto puslapiuko sukoduoti būtų gėda.
Kiek įmanoma dažniau naudok ciklus. Net jei reikia tik nuo 1 iki 2 prasukti – vis tiek naudok. Svarbu, kad išmoktum nerašyti pasikartojančio kodo.
Programavimas kur kas daugiau nei kodo rašymas. Visų pirma turi kažkokią problemą, kuri gali būti ne visai elementari. Turi sugalvoti, kaip ją spręsti. Tada reikia apmąstyti, kaip geriausia tą sprendimą implementuoti. Galiausia eini kodo rašyti. Tikėtina, kad berašydamas susidursi su nauja problema, ir vėl teks pereiti prie mąstymo stadijos.

Kaip minėjo, viskas priklauso nuo to, kur darbinsies.
 
Visai neseniai ieškojau praktikos, būtent junior Java developer. Tai kiek susidariau nuomonę iš interviu, tai daugiau dėmesį skyrė į mano asmenines savybes (mano požiūrį ir sugebėjimą bendrauti). Klausimų grynai apie Java nebuvo, gal tik viena užduotėlė išspręsti tam tikrą problemą su iteratoriumi, bet ir tai labiau buvo žiūrima į problemos sprendimą iš probleminės pusės, nei į sąsajas su Java programavimo kalba:
 
 
Gal tam turėjo įtakos šie faktoriai:

Turėjau parodyti su kuo buvau dirbęs – ne tik Java, bet ir kitomis technologijomis;
darbas ne grynai Java, bet kiek supratau labiau linksta į funkcinio programavimo pusę su Scala;
dirbama bus su Lietuvoje mažai paplitusiomis technologijomis (patys sakė, kad labai sunku surasti tų technologijų specialistų), todėl turbūt didesnį dėmesį skiria darbuotojų apmokymams/ugdymui, nei „gatavo“ darbuotojo suradimui;
pažįstamas dirba toje įmonėje ir jis mane parekomendavo;
pokalbių metu teko užsiminti, su kokiomis dar technologijomis buvau dirbęs (bet tik tiek, nereikėjo įrodynėti savo išmanymo apie šias technologijas).

 
Užbėgsiu komentarams už akių ir pasakysiu, kad darbinuosi į pakankamai rimtą įmonę, turinčią ofisus penkiolikoje Europos šalių bei savo veikla apimančią nemažą dalį Europos (bei dabar plečiasi į Ameriką).
 
Vėlgi, kai paskambino ir pranėšė, kad sutinka įdarbinti, tai akcentavo ne mano žinias, bet kad patikau žmonėms, su kuriais teko kalbėtis.
 
-------------
 
Buvo kitas atvejis, kai man vasarą dirbant vienoje įmonėje, tos įmonės potencialus klientas norėjo įvertinti mūsų kompetenciją. Tada būtent Skype skambučio metu mūsų klausinėjo apie įvairius Android niuansus.

Labai tikėtina, kad numažintų.
 
Šiaip, visus funkcijai reikalingus duomenis reikėtų perduoti per parametrus. Jeigu naudojami globalūs kintamieji, funkcija praranda savo lankstumą: negali pasirinkti, ką paduoti kaip parametrą; rekursija praranda savo privalumus.
 
Be to, globalūs kintamieji užteršia kintamųjų erdvę. Tarkim, turi globalų kintamąjį max, tai bet kurioje iš esamų funkcijų nelabai begali (nors niekas nedraudžia) susikurti kintamojo taip pat pavadinto max. Tokiu atveju vienas kintamasis užklos kitą, todėl programos kodas pasidarys sunkiau skaitomas ir suvokiamas.

Tas 12 nurodo masyvo dydį, nors šiuo atveju jis nėra reikalingas. Kompiliatorius automatiškai nustato dydį pagal paduotą string'ą.
 
Globalių kintamųjų nepatartina naudoti. Globalios gali būti tik konstantos.

Vietoj „x“ turėtum pakeisti į „i“ ir vietoj „if (x=s)“ turėtų būti „if (i == s)“.

Aš nenoriu daugiau ginčytis, bet dar duosiu kelis argumentus:

Trečioj pastraipoj aptariau nišinę programinę įrangą, kuriai reikalingas aukščiausias saugumo laipsnis (ar tai banko sistema, ar medicinos programinė įranga, ar programa, kuri atneša didžiulius nuostolius klaidos atveju). Paprasta programinė įranga, daugų daugiausiai apsiriboja dviejų žingsnių autentifikacija (tik nereikia sakyti, kad jau kiekviena programa – bankinė sistema). Be to, apie saugumo iškėlimą aukščiau visko taip pat paminėjau.
Niekur nesakiau, kad kodo kokybė ar dokumentacija yra visiškai nesvarbi. Tiesiog tai iškelti aukščiau programos funkcionalumo būtų neprotinga (išskyrus saugumą; saugumas tam tikrais atvejais būna pirmoje vietoje). Galų galiausiai, galutinis vartotojais nemato nei dokumentacijos, nei kodo kokybės, ir po vartotojo sąsajos jam rūpi tik tai, kad programa veiktų teisingai ir veiktų greitai.
Testavimas be algoritmo suvokimo yra nieko vertas. Turi suvokti, kurie duomenys yra probleminiai tavo parašytam kodui. Kitaip išeis, kad tiesiog random duomenis padavinėji.
Niekur nesakiau, kad vietoj to, kad panaudotum kažkieno kito biblioteką, geriau pasirašyti savo algortimą. Tik va, dar neradau jokios bibliotekos, kuri išspręstų visas iškilusias problemas... Turbūt teks pačiam pasirašyti...
Paimkim, tarkim, max flow problemą. Vikipedijos straipsnyje paminėta vienuolika šios problemos sprendimo algoritmų su įvairiais laiko sudėtingumais. Sakyčiau visai be reikalo, jei tokiam menką reikšmę turinčiam dalykui reikėjo skirti tiek daug pastangų... Užtektų bruteforce sprendimą parašyti ir toliau eiti refactor'int kodo bei rašyt dokumentacijos...
Kiek paskutinį kartą bandžiau optimizuoti dokumentaciją, programos sparta visai nepadidėjo...
Turbūt žodis algorithm čia per klaidą pavartotas, nes pagal kai kuriuos žmones, algoritmai ir scalability nieko bendro neturi.
Google'as matyt irgi neturi kur pinigų dėti.
Labai geras pavyzdys su ta transporto sistema. O kas atsitiktų, jei puft ir pradingsta ta maža bibliotekėlė su visu algoritmu, bet palieka tik visi WEB API, visi apps'ai tabletams ir visas gražus jų kodas? Būtų daug kodo, kuris nedaro nieko naudingo...
Google pakeičia savo paieškos algoritmą ir tinklapių savininkai susiima už galvos, kaip dabar susigrąžinti buvusias pozicijas paieškos sistemoje...
Duomenų struktūrų suvokimas gali duoti didelę reikšmę net kai nereikia pačiam jų implementuoti. Vien pasirinkimas tarp sąrašo, masyvo ar set'o gali paveikti tavo kodo fragmentą taip, kad jis bus vykdomas tūkstančiais kartų lėčiau.

 
TL;DR: Jeigu didžiąją laiko dalį darbe užima ne patys algorimai, o pagalbiniai darbai, tai dar nereiškia, kad algoritmai nėra svarbu. Aš, pavyzdžiui, per dieną miegu 9 val. ir tai didžiausią procentą mano dienos laiko užimanti veikla. Bet aš nesakau, kad gyvenimo prasmė yra miegoti...
 
Daugiau šioje temoje nebekomentuosiu.

Gal ir praeitame teiginyje nepaminėjau visko, ką reikėjo paminėti, bet reikalingiausią paminėjau.
 
Labai paprasta nustatyti, kas yra programavimo esmė. Tiesiog reikia įvardinti prioritetus tokiems punktams:

funkcionalumas (programa gražina reikiamus rezultatus pradiniams duomenims);
efektyvumas (programa įvykdo skaičiavimus per protingą laiko tarpą ir su protingu atminties kiekiu);
saugumas, patikimumas (čia galima įskaityti ir testus);
kodo kokybė (gerai dokumentuotas, lengvai palaikomas kodas su geru API);
aparatinės įrangos išnaudojimas (čia jau galima paminėti ir scalability);

 
Sakyčiau, įprastinei programinei įrangai prioritetai būtų sudėlioti tokia tvarka, kokia ir paminėjau (nesigilinant į kraštutinumus). Žinoma, gal būtų keisti parametrus vietomis, bet čia jau turėtų būti labai specializuotą programinė įranga, kad funkcionalumas ir efektyvumas būtų ne sąrašo viršuje (ir tai matyt būtų įmanoma tik saugumui).
 
Ir čia jau joks scalability, joks moduliškumas, jokie testai, joks duomenų saugojimas nepagelbės, jei nesugebėsi parašyti algoritmo, kuris spręstų užduotį.
 
O iš ko susidaro tas „scalability“? Iš gražiai pavadintų klasių, ar yra kažkokie algoritmai ir duomenų struktūros, kurie leidžia protingai manipuliuoti duomenimis tarp kelių prietaisų? O duomenų apsauga iš kur: gražiai užvadintų kintamųjų, ar iš tam tikro algoritmo, kuris užtikrina specifinį manipuliavimą duomenimis, dėl kurio informacija nebūtų atskleista trečiosioms šalims? O bibliotekos iš kur gimsta: iš geros dokumentacijos ar iš algoritmų ir duomenų struktūrų implementacijos? O iš kur greitis atsiranda: implementuoji bet kokį algortimą ir pasimeldi C#'pui, kad greitai veiktų, ar implementuoji laiko atžvilgiu efektyviausią algoritmą?
 
Visa kompiuterija pastatyta ant algoritmų. Giliai giliai procesoriuose implementuota tik maža dalis funkcionalumo ir duomenų struktūrų (pavyzdžiui, matematinės operacijos, paprastieji duomenų tipai). Ir su kiekvienu abstrakcijos sluoksniu iš paprastų operacijų, duomenų struktūrų ir algorimų sudaromos sudėtingesnės operacijos, duomenų struktūros ir algoritmai.
 

 
ACM ICPC pasaulio finalas (kas nežino, tai panašiai kaip mokyklinės olimpiados, tik daugiau ir sudėtingesni uždaviniai bei dirbama komandomis po tris). Apdovanojama pirmos 12 vietų. Priedo prie užkabintų medalių IBM atstovas kiekvienam duoda po voką. Voke – pakvietimas dirbti į IBM. Pastebėsit, kad niekas nei vieno iš nugalėtojų nepaklausė, kaip gražiai jie užvadina klases, kokiomis kalbomis programuoja, kokias bibliotekas žino bei kokias UML diagramas moka nubraižyti. Užteko išmanyti ir sugebėti implementuoti tam tikrą kiekį algoritmų bei duomenų struktūrų ir tai atlikti greičiau už kitus, kad IBM juos įvertintų daugiau nepaklausę nė vieno klausimo.

Pavartojau žodį automatizuotas dėl to, nes gali atsidaryt kalkuliatorių ir rankomis suskaičiuoti bei gauti rezultatą. Tačiau jau tai nebus automatizuota. O teiginio esmė yra „problemų sprendimas“. Bet ne tokių problemų, kurias sukelia pats kodo rašymas, o tokių, kurios atsiranda iš išorės (kaip sako, kompiuteris padeda išspręsti tūkstančius problemų, kurių nebuvo prieš atsirandant kompiuteriams).
 
 
Tikrai ne visi su tuo susiduria ir nevisi tai išsprendžia (bent jau per protingą laiko tarpą). Jei taip būtų, tai Google'as be atrankos žmones priiminėtu. Akivaizdžiai per mažai esi sprendęs konkursinių uždavinių, kad taip šneki.
 
Ne viskam yra parašytos bibliotekos. Ne visi algoritmai tinka tiesiog nukopijuoti iš interneto, kartais reikia ir juos pamodifikuoti. Ne visada aišku, kaip reikia spręsti, net jei supranti sąlygą ir pačią problemą.
 
Programavimo esmė – paimi pradinius duomenis ir išvedi rezultatus. Problema yra tas tarpas tarp duomenų ir rezultatų, o algoritmas yra tas problemos sprendimas. Ir visiškai nesvarbu, kaip tu tą kodą parašysi, jei pradiniams duomenims bus duoti teisingi rezultatai, tai problema bus išspręsta.
 
Visos kitos su programavimu susijusios užduotys kyla dėl ilgos programinės įrangos kūrimo trukmės, didelios jos apimties, poreikio dirbti komandomis ir PĮ palaikymo po jos išleidimo. Bet visi su tuo susiję darbai yra tik pagalbiniai. Esmė lieka vis tiek iš pradinių duomenų gauti rezultatus.
 
Pagal tave taip išeina, kad olimmpiados metu turėtum įdiegti Wordpress temą, gražiai aprašyti klasių ir kintamųjų pavadinimus, gražią vartotojo sąsają sukurti ar dar kažką. Bet kad ir kaip gerai tai mokėtum padaryti, vis tiek būsi niekam tikęs, jei nesugebėsi nei vidurkio suskaičiuoti, masyve paieškos atlikti ar elementų surikiuoti.

Manau, kad neteisingai įsivaizduoji, kas yra programuotojas. Programuotoją apsprendžia ne kodo rašymas. Programuotojas yra tas, kuris sugeba spręsti problemas automatizuotai naudojantis kompiuterio pagalba (todėl ir angliškuose konkursuose užduotys būna įvardijamos „Problem A“, „Problem B“ ir t. t.).
 
Taip pat negalima teigti, kad programavimo konkursuose naudojamos užduotys neturi atitikmenų realiame gyvenime. Oi, dar ir kaip turi. Visi žinomi algoritmai buvo sukurti ne tam, kad tiesiog kažkas galėtų padaryti uždavinį, o tam, kad būtų galima kažką efektyviai apskaičiuoti. Ir kad ir kokia kvaila pasakėlė būtų aprašyta uždavinio salygoje, vis tiek galėtum rasti reikiamam algoritmui pritaikyma realiame gyvenime.
 
Be to, realiame gyvenime susiduriama su dar sudėtingesnėmis užduotimis, negu pateikiamos konkursuose. Vien užtenka pagalvoti apie vaizdo ar garso apdorojimą…
 
Minėjo „generic error'u handlinimo sistemą“. Žinoma, kuriant programinę įrangą prireikia ir kitokių gabumų be algoritmavimo, kaip antai tvarkingas kodo rašymas, geri testai, geras API ir pnš. Tačiau visa tai yra ne esminis komponentas, o pagalbinis. Jei iškils kokia problema, visiškai nepagelbės tai, kad moki gražų kodą rašyti, jeigu nesugebi sugalvoti algoritmo. Priešingai, jei žinai algoritmą, kad ir kokį baisų kodą parašyti, kad ir su 0 testų, bet rezultatas bus – problema bus išspręsta.
 
Būtent programavimo konkursai ir tikrina tavo sugebėjimus spręsti problemas, nes tai ir yra esminis programuotojo sugebėjimas.

if (x = 0) { ... }
Sugadina tau x reikšmę. Pataisyk į ==.

Adobe Flash Proffesional tinkama vektorinėms 2D animacijoms.

Don't send dažniausiai išmeta dviem atvejais – kai užeini už masyvo ribų ir kai dalini iš nulio.
 
Turbūt visi sutiks, kad niekas negimė mokėdamas šviesofo. Bet visiems pavyksta susieti galvoje, kad kai žalia – galima eiti per gatvę. Visi tai supranta ir nebūtina rašyti „GalimaEitiPerGatvęException“.
 
Žalia reiškia galima eiti per gatvę.
Don't send reiškia užėjai už masyvo ribų.
…
Žalia ≡ eiti per gatvę.
Don't send ≡ peržengtos masyvo ribos.

 
Jei pritaisai prie dviračio pagalbinius ratukus, tai nesakyčiau, kad taip padidinamas meistriškumas.

Ne programavimo kalbos sintaksėje visas sudėtingumas. Galim paimti, pavyzdžiui, matematiką. Konkrečiau – integralus:
Sakyčiau, pakankamai sudėtinga. Užrašykim viską supaprastintai:
Akivaizdžiai dabar viskas pasidarė daug aiškiau ir dabar net penktokas galėtų suskaičiuoti tokį integralą!
 
Kaip matematika sprendžia visą šį sudėtingumą? Ar susigalvoja atskirą sintaksę? Ne. Tiesiog viskas, kas svarbu, duodama palaispniui. Iš pradžių išmoksti paprastus aritmetinius veiksmus, vėliau kintamuosius, tada lygtis, dar vėliau šaknį ir galiausiai integralą. Ir taip, nors ir sintaksiškai sudėtingas integralas tampa išsprendžiamas. Ir tampa išsprendžiamas ne dėl to, kad vietoj to kringelio užrašytas žodis integralas, o todėl, kad pasidaro aišku, kas yra integralas ir kokia jo prasmė.
 
 
Dabar su ciklais. Jeigu žmogus supranta, ką šitas kasdieniniame nenaudojamas simbolis reiškia:
tai pagal visą logiką reikės metų metus studijuoti, kol jis sugebės suprasti šitai?

int sum = 0; for (int i = 1; i <= 100; i++) sum = sum + i;
 
 
O ką, jei paimsim autoriaus pavyzdį:

cin >> a, b;
Ar taip sunku suprasti, kad sum + a , b negalima rašyti, o reikia rašyti sum + a + b?
 
 
Nepamirškim ir pointer'ių. Matyt visas sudėtingumas kyla dėl to, kad atsiranda žvaigždutė:

int *p = new int(0);
O pasiėmę Java ir C# kalbas visi galėtų išsamiai paaiškinti objektus ir jų reference'us, nes čia jau nebėra žvaigždutės:

Integer p = new Integer(0);

 
Visas programavimo sudėtingumas kylo iš to, kad mokiniai nesugeba suvokti kaip veikia kintamieji, kaip veikia masyvas, kaip veikia pointer'iai, kaip veikia atmintis, kokia eilės tvarka vykdomi programos sakiniai. Ir lygiai taip pat, kaip mįslė nepasidaro lengvesnė, jei vietoj Žemaičių tarmės aš tau ją pasakau Aukštaitiškai, taip ir programa nepasidaro lengvesnė, kai kitaip for ciklą užrašai.
 
 
Žinoma, gal kažką, kuris nesuvokia programavimo, dar ir kalba trikdo, bet tai tikrai ne lemiamas faktorius. Tikrai nerasi tokios kalbos, kad visi mokiniai puikiai suprastų programavimą. Kaip ir sakiau, kai kam ir „Komenskio Logo“ per sudėtingas:

kartok 360 [priekin 5 dešinėn 1]

Tai prašau pateikti tuos faktus, o ne internetan siuntinėti. Kol kas tusčiom kulkom šaudai…
 
Programavimo kalbos vertinamos keturiais kriterijais: readability, writability, reliability ir cost. Vienas iš faktorių, įtakojančių tiek skaitomumą, tiek rašomumą, tiek patikimumą yra paprastumas (simplicity). Kuo daugiau įvairių galimybių, kuo daugiau skirtingų būdų gauti tam pačiam rezultatui, tuo kalbos paprastumas menkėja. Dėl to ją darosi sunkiau išmokti, sunkiau skaityti svetimą kodą. O ypač kai čia giriesi, kad nuolat išleidinėjami nauji feature'ai.
 
Antras dalykas yra enterprise. Taip, paprastam programuotojui smagu, kai atsiranda naujų galimybių – ar programavimo kalboje, ar naudojamame karkase ir pnš. Bet enterprise'ui permainos netinka ir per brangiai kainuoja. Nežinau, gal į C# kalbą įtraukiamos naujovės ir netrukdo enterprise'ui, tačiau vienareikšmiškai teigti, kad tai yra vien tik gėris, irgi negalima.
 
Be to, Java turi visiškai kitą ideologiją, nei C#. Java kaip įmanoma labiau supaprastinta paliekant galimybę įgyvendinti įprastą funkcionalumą. Niekad nekilo klausimas, kodėl Java'oje nėra struct, nors ji kilo iš C++? Nes lygiai tą patį gali įgyvendinti su klase, todėl neįtraukus struct pagerinamas paprastumas neprarandant funkcionalumo. Būtent todėl ir Java nelinkus pristatinėti naujovių savo kalboje – nes laikomasi konservatyvios ideologijos.
 
 
Kita vertus, C# ne itin konservatyvi. Kaip joje implementuojamas Observer pattern'as? Per delegates (kai tuo tarpu Java sugeba išsiversti su standartiniu interface paveldėjimu). Viena klase mažiau – užtat kalba sudetingesnė.
 
Ir paskutinis dalykas, darantys įtaką kainai – pernešamumas (portability). Java yra palaikoma daugumos platformų, kai C# orientuotas į Microsoft produktus. Pastarąją gelbsti tik trečiųjų šalių pastangos (pavyzdžiui, Mono).
 
Nesakau, kad viena ar kita kalba yra vienareikšmiškai geresnė. Bet taip, vos ne fanatiškai, aukštinti C# nebūčiau linkęs…

Don't send dažniausiai išmeta dviem atvejais – kai užeini už masyvo ribų ir kai dalini iš nulio.
 
Turbūt visi sutiks, kad niekas negimė mokėdamas šviesofo. Bet visiems pavyksta susieti galvoje, kad kai žalia – galima eiti per gatvę. Visi tai supranta ir nebūtina rašyti „GalimaEitiPerGatvęException“.
 
Žalia reiškia galima eiti per gatvę.
Don't send reiškia užėjai už masyvo ribų.
…
Žalia ≡ eiti per gatvę.
Don't send ≡ peržengtos masyvo ribos.

 
Jei pritaisai prie dviračio pagalbinius ratukus, tai nesakyčiau, kad taip padidinamas meistriškumas.

Ne programavimo kalbos sintaksėje visas sudėtingumas. Galim paimti, pavyzdžiui, matematiką. Konkrečiau – integralus:
Sakyčiau, pakankamai sudėtinga. Užrašykim viską supaprastintai:
Akivaizdžiai dabar viskas pasidarė daug aiškiau ir dabar net penktokas galėtų suskaičiuoti tokį integralą!
 
Kaip matematika sprendžia visą šį sudėtingumą? Ar susigalvoja atskirą sintaksę? Ne. Tiesiog viskas, kas svarbu, duodama palaispniui. Iš pradžių išmoksti paprastus aritmetinius veiksmus, vėliau kintamuosius, tada lygtis, dar vėliau šaknį ir galiausiai integralą. Ir taip, nors ir sintaksiškai sudėtingas integralas tampa išsprendžiamas. Ir tampa išsprendžiamas ne dėl to, kad vietoj to kringelio užrašytas žodis integralas, o todėl, kad pasidaro aišku, kas yra integralas ir kokia jo prasmė.
 
 
Dabar su ciklais. Jeigu žmogus supranta, ką šitas kasdieniniame nenaudojamas simbolis reiškia:
tai pagal visą logiką reikės metų metus studijuoti, kol jis sugebės suprasti šitai?

int sum = 0; for (int i = 1; i <= 100; i++) sum = sum + i;
 
 
O ką, jei paimsim autoriaus pavyzdį:

cin >> a, b;
Ar taip sunku suprasti, kad sum + a , b negalima rašyti, o reikia rašyti sum + a + b?
 
 
Nepamirškim ir pointer'ių. Matyt visas sudėtingumas kyla dėl to, kad atsiranda žvaigždutė:

int *p = new int(0);
O pasiėmę Java ir C# kalbas visi galėtų išsamiai paaiškinti objektus ir jų reference'us, nes čia jau nebėra žvaigždutės:

Integer p = new Integer(0);

 
Visas programavimo sudėtingumas kylo iš to, kad mokiniai nesugeba suvokti kaip veikia kintamieji, kaip veikia masyvas, kaip veikia pointer'iai, kaip veikia atmintis, kokia eilės tvarka vykdomi programos sakiniai. Ir lygiai taip pat, kaip mįslė nepasidaro lengvesnė, jei vietoj Žemaičių tarmės aš tau ją pasakau Aukštaitiškai, taip ir programa nepasidaro lengvesnė, kai kitaip for ciklą užrašai.
 
 
Žinoma, gal kažką, kuris nesuvokia programavimo, dar ir kalba trikdo, bet tai tikrai ne lemiamas faktorius. Tikrai nerasi tokios kalbos, kad visi mokiniai puikiai suprastų programavimą. Kaip ir sakiau, kai kam ir „Komenskio Logo“ per sudėtingas:

kartok 360 [priekin 5 dešinėn 1]

Tai prašau pateikti tuos faktus, o ne internetan siuntinėti. Kol kas tusčiom kulkom šaudai…
 
Programavimo kalbos vertinamos keturiais kriterijais: readability, writability, reliability ir cost. Vienas iš faktorių, įtakojančių tiek skaitomumą, tiek rašomumą, tiek patikimumą yra paprastumas (simplicity). Kuo daugiau įvairių galimybių, kuo daugiau skirtingų būdų gauti tam pačiam rezultatui, tuo kalbos paprastumas menkėja. Dėl to ją darosi sunkiau išmokti, sunkiau skaityti svetimą kodą. O ypač kai čia giriesi, kad nuolat išleidinėjami nauji feature'ai.
 
Antras dalykas yra enterprise. Taip, paprastam programuotojui smagu, kai atsiranda naujų galimybių – ar programavimo kalboje, ar naudojamame karkase ir pnš. Bet enterprise'ui permainos netinka ir per brangiai kainuoja. Nežinau, gal į C# kalbą įtraukiamos naujovės ir netrukdo enterprise'ui, tačiau vienareikšmiškai teigti, kad tai yra vien tik gėris, irgi negalima.
 
Be to, Java turi visiškai kitą ideologiją, nei C#. Java kaip įmanoma labiau supaprastinta paliekant galimybę įgyvendinti įprastą funkcionalumą. Niekad nekilo klausimas, kodėl Java'oje nėra struct, nors ji kilo iš C++? Nes lygiai tą patį gali įgyvendinti su klase, todėl neįtraukus struct pagerinamas paprastumas neprarandant funkcionalumo. Būtent todėl ir Java nelinkus pristatinėti naujovių savo kalboje – nes laikomasi konservatyvios ideologijos.
 
 
Kita vertus, C# ne itin konservatyvi. Kaip joje implementuojamas Observer pattern'as? Per delegates (kai tuo tarpu Java sugeba išsiversti su standartiniu interface paveldėjimu). Viena klase mažiau – užtat kalba sudetingesnė.
 
Ir paskutinis dalykas, darantys įtaką kainai – pernešamumas (portability). Java yra palaikoma daugumos platformų, kai C# orientuotas į Microsoft produktus. Pastarąją gelbsti tik trečiųjų šalių pastangos (pavyzdžiui, Mono).
 
Nesakau, kad viena ar kita kalba yra vienareikšmiškai geresnė. Bet taip, vos ne fanatiškai, aukštinti C# nebūčiau linkęs…

C++, Java ir C# – visos trys yra C šeimos kalbos. Kiek teko girdėti, C# buvo kuriamas kaip konkurentas Java'i. Būtent iš šių dviejų faktų ir kyla visas tarpusavio panašumas.

Pasižymi p = 2 + (1 / (2 + ...));
 
Tada 1/p = 1/(2 + 1/p);
 
Išsireiški p, įsistatai įpradinę lygtį;
 
<...>
 
N = √2.

http://www.mat.lt/fizikos-formules/elektromagnetiniai-virpesiai/virpesiu-konturo-periodas-tomsono-formule.html
 
Užtruko 20 sekundžių tai surasti (maždaug 30 kartų trumpiau, nei užsiregistruoti ir sukurti temą „Fizika. 10 klasė“).

http://www.mat.lt/fizikos-formules/elektromagnetiniai-virpesiai/virpesiu-konturo-periodas-tomsono-formule.html
 
Užtruko 20 sekundžių tai surasti (maždaug 30 kartų trumpiau, nei užsiregistruoti ir sukurti temą „Fizika. 10 klasė“).

C++, Java ir C# – visos trys yra C šeimos kalbos. Kiek teko girdėti, C# buvo kuriamas kaip konkurentas Java'i. Būtent iš šių dviejų faktų ir kyla visas tarpusavio panašumas.

Reikia pastumti per 8 bitus, o ne per sizeof (int) = 4.

const int BITS_IN_BYTE = 8; int byte1 = 0xf; int byte2 = 0x0; int two_bytes = (byte1 << BITS_IN_BYTE) | byte2;
 
Ir kad atspaudintum šešioliktainiame formate:

#inlcude <iomanip> ... cout << showbase << hex << two_bytes;
 
EDIT: nebent tu čia ne baitus, o po pusę baito turi ir juos nori sujungti į vieną baitą. Tada reiktų pastumti per 4 bitus. Bet vis tiek sizeof (int) semantiškai netinka.

Palauk nakties ir išvažiuok su mašina į miestą. Pats maloniausias laikas vairavimui: mažai eismo, nereikia stoti prie kiekvieno šviesoforo, nes dauguma jų geltonai mirksi, nėra jokių pašalinių trukdžių. Vairuodamas naktį patirsi daug mažiau streso, todėl smegesnys greičiau pripras prie vairavimo ir nebesies jo su stresine būsena.
 
Čia kaip su kiekviena baime – iš pradžių smegenys reaguoja jautriai. Bet po kurio laiko nuolat peržengiant tos baimės ribą ir suprantant, kad nieko blogo neatsitiko, smegenys pripranta (atbunka).

Palauk nakties ir išvažiuok su mašina į miestą. Pats maloniausias laikas vairavimui: mažai eismo, nereikia stoti prie kiekvieno šviesoforo, nes dauguma jų geltonai mirksi, nėra jokių pašalinių trukdžių. Vairuodamas naktį patirsi daug mažiau streso, todėl smegesnys greičiau pripras prie vairavimo ir nebesies jo su stresine būsena.
 
Čia kaip su kiekviena baime – iš pradžių smegenys reaguoja jautriai. Bet po kurio laiko nuolat peržengiant tos baimės ribą ir suprantant, kad nieko blogo neatsitiko, smegenys pripranta (atbunka).

Palauk nakties ir išvažiuok su mašina į miestą. Pats maloniausias laikas vairavimui: mažai eismo, nereikia stoti prie kiekvieno šviesoforo, nes dauguma jų geltonai mirksi, nėra jokių pašalinių trukdžių. Vairuodamas naktį patirsi daug mažiau streso, todėl smegesnys greičiau pripras prie vairavimo ir nebesies jo su stresine būsena.
 
Čia kaip su kiekviena baime – iš pradžių smegenys reaguoja jautriai. Bet po kurio laiko nuolat peržengiant tos baimės ribą ir suprantant, kad nieko blogo neatsitiko, smegenys pripranta (atbunka).