Učenje programiranja

Na faksu NE učijo jezikov, na faksu učijo principe in koncepte programiranja. Izbrani jezik je le tovornjak, za prevoz teh idej.

Na VSŠ je pri Programiranju 1 Python, pri Programiranju 2 pa Java.

BigWhale je 23. jul 2012 ob 12:19 izjavil:

Spura je 14. jul 2012 ob 23:24 izjavil:

BigWhale je 13. jul 2012 ob 18:11 izjavil:

To, da ni zascitenih in privatnih spremenljivk je pa zame prednost. Lahko API uporabljas tko kot hoces in ne tko kot avtor misli, da ga mors. :>

Valda je zate prednost, ker nimas pojma za kaj se to uporablja in ne znas OOP.

Jaz sem zase sicer povedal zakaj je to prednost. Ti pa trapas in se delas pametnega. No, razlozi mi kaj delam narobe in cesa ne znam.

ne pokazali si da ti ni jasen niti pojem apija. kje šele programskih paradigm. sej če ti paše imaš proceduralne jezike pa večji del interpraterjev. pust stvari katerih ne zastopš. ampak na veliko napiš ko sodeluješ v kakem projektu sploh kjer se delo deli.
ker podobno zoprni ti morajo bit tud muteksi , semaforji in ostale zadeve, katere omejujejo tvoj programerski polet? le zakaj bi katero koli stvar zapakiral v uporaben black box če ti lahko nekdo naknadno manipulira z zankami. no ja nekoliko težje, ker v sosledje varnosti kasneje uvedemo v jezik interpreter lock pa vse kopiramo da nismo glih obupno nevarni sami sebi. pa da ne bo pomote vsi ljubimo to, ampak za neko userend aplikacijo pač to ni zaželjeno. če jo uporabljaj en ali dva še gre sicer pa ne.

lol, na vsš M$-jevi jeziki, na uni pa open source

FERI RIT UNI
Programiranje 1&2 ter aps = c++
Ostali predmeti je povečini jezik po želji, sploh v 2 letniku se ne komblicira, razen če se kaki dll-ji pišejo.
Je še pa bash, C, mfc, c#, assembler, java.
V tretjem letniku bomo pa še videli, predvidevam, da bo povečini jezik po izbiri, razen če se pri kakšni vaji izrecno zahteva kaj drugega.

Sicer pa ne vidim velike težave prešaltat na drug programski jezik, po tem ko ti en že gre kr dobro. Ali pa smo mi dobili ok podlago iz C++.

Ne vem, kaj točno me sprašuješ, ampak for/if/while... so v teh jezikih, ki sem jih uporabljal klasika (-asm), ni nekih velikih sprememb, bolj v sintaksi.
Pač hotel sem povedat, da se ni tako težko priučiti drugega jezika, če imaš osnove pokrite, pa če je dovolj literature, kar je na spletu povečini je.

Kako se debugga? Posebej nas niso učili, sam pač pripravim breakpointe, kjer se zadeva zalomi pa pogledam vrednosti. Za neko drugo pot nisem glih slišal...

Nebi se strinjal da je private/public uporaben samo za API...
Encapsulation (object-oriented programming) @ Wikipedia

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A benefit of encapsulation is that it can reduce system complexity, and thus increases robustness, by allowing the developer to limit the interdependencies between software components.

Kaj ti v javi preprečuje da ubereš natanko enako pot?
"Loaded" imena spremenljivk so pa sploh svoga dnarja vredna... GPSS comes to mind.

Seveda da ni, pa seveda se da. Samo glede na to da so morali pri Pythonu priti do tako butastih rešitev kot je delanje črtic pred imeni da simulirajo enkapsulacijo kaže, da bi taki konstrukti v jeziku precej pomagali.

Seveda, spet nekdo, ki samo trolla in ne da nobenega pametnega argumenta za svoje trditve. Edina stvar, ki jo v resnici pridobis s private/protected/public metodami/spremenljivkami je to, da lahko tvoj IDE prikaze kaj je 'public API' interface in kaj so helper metode, ki jih naceloma ne klices.

Jao, ne nakladi no. Pejt enkrat en mal večji projekt pogledat (oz. raje dva, enega v Javi, drugega v Pythonu) pa ti bo mal bolj jasno zakaj so take stvari zelo uporabne pri razvoju. Pri projektih kjer se trije ljudje bockajo pač to ni nekaj kar bi prišlo do izraza - isto kot type sistem.

BigWhale gre se za to da se ti lahko zgodi, da nekaj sprogramiraš, in potem čez eno leto nekaj delaš, ko si že pozabil točno kako in kaj. Če so pa še drugi programerji v igri potem pa sploh. Je napaka da obravnavaš programerje kot neke ljudi brez napak ki se ne morejo zmotit. Pač enkapsulacija je en način kako preprečit da se dela z objektom nekaj kar ni bilo načrtovano. Če bi bli programerji popolni je verjetno nebi lih rabil. Pomaga pa tudi pri abstrakciji pa take stvari.
Lah se ti zgodi da recimo ne veš da v bistvu ta pa ta metoda spreminja to pa to stvar in je nej nebi klical izven samega objekta... Itd. mal pogoogli oop encapsulation pa boš najdu kakšno bolj konkretno razlago.
Enkapsulacija je ena od temeljnih stvari v OOP, tko da če se greš OOP naj bi načeloma tko delal. Lah se pa greš kej drugega.

Ja, ampak to ti pomaga samo takrat, ko tvoj IDE zna pred teboj skriti privatne in protected zadeve. Dokler imas dostop do kode APIja, ki ga uporaljas je to skoraj edina prednost. Za uporabo APIja bos moral ali prebrati dokumentacijo ali odpreti kodo.

Ce nimas kode, potem uporabljas tiste stvari za katere ves, da obstajajo in so omenjene v dokumentaciji. Seveda, ce so privatne zadeve skrite, potem necesa ne mores po nesreci uporabiti in preprecis, da bi nekdo namenoma iskal taksne stvari. Hkrati pa preprecis tistim, ki bi lahko to uporabili v svojo prednost, da tega ne morejo narediti. Meni se je ze zgodilo, da je nekdo naredil nekaj spremenljivk privatnih in ni bilo nobenega getterja zanje. Ker je bil to nek zaprt API je trajalo pol leta, da so na drugi strani to potem popravili. Po precej prepricevanja so ugotovili, da imam prav in da bi bilo lepo imeti vsaj getter za tiste zadeve.

Ce pa imas kodo, potem je pa tako ali tako iz kode razvidno kaj lahko uporabljas in cesa ne.

Hocem samo povedati, da enkapsulacija ni nek sveti gral OOPja in da je vcasih lahko precej v nadlego. Moj prvi post o tem je bil pa itak flamebait. In to se kar uspesen! ;)

Ja, pa kaj? To se ne pomeni, da ti ne more biti v napoto. :) Pa zaradi tega ni sveti gral. Hehe.

Men se zdi podobno, kot da bi rekel da ne rabiš compilerja, da ti preverja sintaktične napake, ker itak dobri programerji "vejo" kako je treba delat.
Vsi programerji se motijo.

Pred kom hudica mors zavarovat interne variable in metode? Tukaj ne gre za uporabnike tipa 'joze in micka', ki klikata po aplikaciji ampak gre za uporabnike doticnega lib-a, api-ja. Gre za ljudi, ki vsaj priblizno vedo kaj delajo in kako se dolocene zadeve uporablja.

ker ne moreš zagotovid thred safe delovanja, če tega ne veš ne trapaj kot krava s teletom.

noraguta je 26. jul 2012 ob 13:41 izjavil:

Pred kom hudica mors zavarovat interne variable in metode? Tukaj ne gre za uporabnike tipa 'joze in micka', ki klikata po aplikaciji ampak gre za uporabnike doticnega lib-a, api-ja. Gre za ljudi, ki vsaj priblizno vedo kaj delajo in kako se dolocene zadeve uporablja.

ker ne moreš zagotovid thred safe delovanja, če tega ne veš ne trapaj kot krava s teletom.

V bistvu res nevem o cem govoris in zakaj ne bi mogel zagotoviti thread safe delovanja, ce nimas privatnih/protected spremenljivk in metod. Das lahko kak primer?

Se vedno ne vem o cem govoris pri thread safe delovanju in privatnimi spremenljivkami. Zato sem tudi prosil, da das primer, ko bo neka allegedly thread safe funkcija odletela, ker bo uporabljala public namesto privatno spremenljivko.

Ma ja, ta fiksacija na Pravi Jezik je čisto mimo. Al znaš govorit al pa ne znaš. To je vse kar šteje.
Al se v Pythonu da skladat sonete al je boljši za Rap je pomembno šele ko že znaš govorit.

BigWhale je 23. jul 2012 ob 12:19 izjavil:

Spura je 14. jul 2012 ob 23:24 izjavil:

BigWhale je 13. jul 2012 ob 18:11 izjavil:

To, da ni zascitenih in privatnih spremenljivk je pa zame prednost. Lahko API uporabljas tko kot hoces in ne tko kot avtor misli, da ga mors. :>

Valda je zate prednost, ker nimas pojma za kaj se to uporablja in ne znas OOP.

Jaz sem zase sicer povedal zakaj je to prednost. Ti pa trapas in se delas pametnega. No, razlozi mi kaj delam narobe in cesa ne znam.

Na tem forumu so dostikrat debate o prednostih quick and dirty jezikov pred bolj staticnimi jeziki z visibility modifierji in podobnim, oziroma o nepotrebnosti uporabe teh mehanizmov v jezikih, ki jih podpirajo. Do neke mere so take debate legitimne (ceprav sem jaz vedno za uporabo teh mehanizmov), ker tukaj prakticno vsi delamo koncne produkte, kjer je vsa oziroma vecji deli kode nasa lastna ali pa vsaj iz ozkega kroga ljudi, in je zato omejevanje vidnosti nekoliko manj smiselno.

Potem pa prides ti in reces, da je prednost ne imet omejene vidnosti pri APIjih. Od vseh stvari moznih si ravno APIje najdu, softwersko podrocje kjer so prednosti visibility modifierjev dalec najbolj ocitne. Iz tega je mogoce sklepat le, da ne poznas izdelave in vzdrzevanja APIjev in ne razumes OOP.

APIji oziroma objekti ki nastopajo v njih imajo pogosto contracte, ki se jih morajo drzat. Lep primer je java String, ki mora bit immutable. Ce nobene metode ni mozno skriti, potem ne mores imeti convenience metod v APIju katere bi unicile ta contract. Recimo String class ima konstruktor, ki prejeti char[] ne kopira, kar omogoca, da naredis String, ki je mutable. To bi lahko unicilo delovanje celega kupa druge kode, zato je ta konstruktor package scoped in ga uporabljajo samo posveceni classi kot je StringBuilder. Ce je vse public ne mores imeti metod, ki predpostavljajo, da so parametri pravilno formirani, ne mores imeti metod, ki predpostavljajo, da je objekt v dolocenem stanju, ne mores imeti metod, ki predpostavljajo, da so klicane pred ali za neko drugo metodo. Vse to izredno otezi pisanje APIja in dela njegovo kodo konfuzno. Potem takoj pride potreba po pisanju dolge dokumentacije o tem kdaj se lahko kaj klice in kako to mutira stanje objekta, ker je to pomembno za funkcije in treba je popisat vse tipe in vse funkcije, kaj so in kaj pocnejo.

Druga stvar je to, da vse kar je public lahko nekdo uporablja, torej ko izdas novo verzijo APIja moras naceloma public del ohranjat identicen. Ce ne mores nicesar skriti potem je vsako metodo v APIju potencialno nekdo uporabil in ne mores spremenit niti enega method signaturea v APIju, kaj sele da bi delal velike refactoringe v kolikor hoces da je nova verzija kompatibilna s staro. Kar je se hujse, lahko se spremeni delovanje kaksne metode, tako da vraca drugacne rezultate pri dolocenem inputu.

Recimo neka interna funkcija za iskanje po drevesu v seznam zadetkov poleg otrok po novem doda tudi vozlisce samo. Ti si to spremenu, ker nekje rabis za neko novo funkcionalnost, in potem popravis vse klicatelje te funkcije znotraj te knjiznjice, da upostevajo to novo dejstvo. In ce je ta funkcija public in jo je nekdo uporabljal, si bo nalozil novo verzijo knjiznjice in se mu ne bo nic rdece pobarvalo, ker je sintaksa ista in bo njegova koda zacela vracat napacne rezultate. Vcasih zaradi kompleksnosti ali pa kolicine podatkov traja mesece, da napacno delovanje opazis in odpravis. In potem moras za knjiznjico pisat podrobne change loge in folk jih mora brat (fat chance).

Torej manjsi kot je public del, bolj si fleksibilen v spremembah delovanja knjiznjice, ki bodo povsem transparentne za uporabnika.

Tretja stvar je to, da imajo dobri API ozek interface (kolikor pac to omogoca problemska domena). Ni hujsega kot da si za nekaj relativno enostavnega potegnes dol knjiznjico in je potem 100 classov s 10 metodami vsak pa ogromno konstruktorji, da te na rit vrze ko stisnes autocomplete k je tok opcij. Stevilo tipov naj bo omejeno, stevilo vstopnih tock cim manjse (vstopne tocke kot prva API funkcija ki jo klices), prav tako je dobro minimizirat stevilo povezav med deli APIja (torej stevilo poti rezultatov neke operacije v naslednji korak - razen kadar je v naravi problema nasprotno).

Recimo da delam XPath over JSON knjiznjico. Zadeva obsega 40 classov, vidnih je 5. Dva exception classa brez vidnih konstruktorjev, dva interfaca s po dvema metodama(metode enega vracajo instance drugega), en class brez vidnega konstruktorja in z eno staticno metodo, ki vraca implementacijo enega od interfaceov.

Tak API ima natancno eno vstopno tocko (staticna funkcija), dobis instanco enega interfacea, iz katerega dobis listo instanc drugega. Simpl kot pasulj. API sam rabi 0 vrstic dokumentacije. Jst lahko zamenjam parser generator iz JCup na Beaver (cisto drugi classi in function signaturei) in noben uporabnik ne bo nicesar opazu.
Ce bi imel pa vidnih vseh 40 classov pa vse metode, bi pa moral napisat user manual, ohranjat sintakso in delovanje obstojecih funkcij, le nove bi lahko dodajal, rigidno k svinja, v vse funkcije dodat checke za razna stanja, ker ne bi mogel delat dolocenih predpostavk, itd... stvari k sm jih zgoraj omenil.

Zdej ce pa kdo misli, da boljs ve od avtorjev kako API uporabljat, ima pa ponavadi na voljo source, pa naj si ga sname pa nastima vse na public pa si naredi lib in ga da v svoj projekt. In naj to tudi sam podpira, ostalih 99.9% uporabnikov bo pa raje imelo easy to use, narrow API, ki je funkcionalno in sintakticno stabilen skozi verzije.

In v koncni fazi, ce so si avtorji slabo zamislili ali implementirali API, pa skoraj nikoli tega ne bos resil z drugacnim, lasnorocnim klicanjem njihovih internal funkcij, ampak bos to resil bodisi z downloadanjem sourcea in odpravo bugov bodisi z izbiro druge knjiznjice bodisi s pisanjem svoje. Torej tudi iz tega stalisca tvoja ideja ni smiselna.

V koncni fazi imas te benefite tudi na produktih za koncne uporabnike (mocnjesi benefiti vec kot ljudi dela na projektu), zato je zagovarjam klasicne OOP prijeme pri vseh projektih. Ampak ce je tam to stvar debate ("jst raje hitro prototipiram z node.js bla bla" - can be a valid opinion) so ti benefiti pri APIjih 100x mocnejsi in kakrsnokoli mnenje, da je implementation hiding brezveze pri njih, nima nobene podlage.