(Huom: siirretty keskustelusta https://www.ohjelmointiputka.net/keskustelu/
Antti Laaksonen kirjoitti:
Helsingin yliopiston MOOC-kurssi voisi olla sinulle hyvä:
<semiOT>En suosittele tuota kovin varauksetta. Nimittäin opettavat intin muuttamisen merkkijonoksi tapahtuvan ""+i, hakevat merkkiä merkkijonosta jono.contains(""+char), käyttävät setterinä nopan mukaan asetaJoku(), setJoku() tai muutaJoku() jne. Yllätyin itse täysin kun aloin tuota huvikseni suorittaa. En olisi uskonut HYn opettavan noin huonoja tapoja. Jopa minä, joka olen Javaan koskenut käytännössä viimeksi viime vuosituhannella (ja silloinkin vähän) ymmärsin käyttää String.format(), jono.indexOf() jne. Toki kokemusta muista kielistä sen verran, että tietää mikä on järkevää. Kurssin suunnittelijoilla ehkä ei käytännön kokemusta?
Myöskin rahasummia käsitellään ensin liukulukuina, myöhemmin sanotaan että niitä ei pitäisi käyttää ja käsketään tehdä koodia, joka laskee eurot ja sentit erikseen. En nyt ihan noinkaan tekisi itse rahasummia, mutta toki joskus voi olla järkevää.
Yritin vähän palautettakin antaa, paino sanomalla "kun opetatte aloittelijalle asiat pieleen, teette aikamoista hallaa jatkolle" mutta tiedä sitten kiinnostiko ketään.
</semiOT>
feenix kirjoitti:
Myöskin rahasummia käsitellään ensin liukulukuina, myöhemmin sanotaan että niitä ei pitäisi käyttää ja käsketään tehdä koodia, joka laskee eurot ja sentit erikseen. En nyt ihan noinkaan tekisi itse rahasummia, mutta toki joskus voi olla järkevää.
No juu, periaatteessa jotenkuten ymmärrettävä neuvo, jos joutuu käyttämään ohjelmointikieltä, jossa ei ole decimal tyyppiä tai vastaavaa. Mutta siinäkin tapauksessa ennemmin laittaa vaan yhteen kokonaislukumuuttujaan sentit. Erilliset eurot ja sentit muuttujat on lähinnä itsensä jalkaan ampumista, kun pitää sitten ohjelmoida perus laskuoperaatiotkin itse tuollaiselle vajukkityypille.
Grez kirjoitti:
No juu, periaatteessa jotenkuten ymmärrettävä neuvo, jos joutuu käyttämään ohjelmointikieltä, jossa ei ole decimal tyyppiä tai vastaavaa. Mutta siinäkin tapauksessa ennemmin laittaa vaan yhteen kokonaislukumuuttujaan sentit. Erilliset eurot ja sentit muuttujat on lähinnä itsensä jalkaan ampumista, kun pitää sitten ohjelmoida perus laskuoperaatiotkin itse tuollaiselle vajukkityypille.
Tuossa selvästi haettiin sitä, että osaa sitten tehdä laskutoimituksia noiden välillä, vaikka tosiaan järkevin olisi vain tallentaa sentit. Tekstit vain silmäilin läpi, joten en ole varma puhuttiinko siellä mitenkään tarkemmin asioista.
Kiitos hyvästä kritiikistä. Olen itsekin kirjoittanut osia MOOC-kurssin materiaalista, joten voin yrittää vastata kritiikkiin.
Voisitko selventää, mikä on ongelmana merkinnöissä ""+i ja jono.contains(""+char)? Merkinnän ""+i etuna on lyhyys, koska muut tavat muuttaa luku merkkijonoksi ovat selvästi pidempiä. Merkin etsimiseen metodi contains on luontevampi kuin indexOf, koska haluamme tarkistaa, onko merkki merkkijonossa eikä mikä sen sijainti on.
Epäyhtenäiset nimet metodeissa ovat todellakin huonoa tyyliä. Tähän on osittain syynä se, että materiaalia on tehnyt suuri määrä henkilöitä, ja toisaalta yhtenäiseen nimentään ei ole kiinnitetty tarpeeksi huomiota.
Olen samaa mieltä, että eurojen ja senttien tallentaminen erillisiin muuttujiin on käytännössä huono ratkaisu. Kuitenkin tämäkin tapa tuo esille sen tärkeän asian, että liukulukujen sijasta tarkkojen arvojen tallentamiseen täytyy käyttää jotain muuta tapaa.
Kurssin tekijöillä on itse asiassa satoja tunteja kokemusta ohjelmoinnin henkilökohtaisesta ohjauksesta yliopistossa, ja olemme pystyneet myös seuraamaan opiskelijoiden ohjelmointitaidon kehitystä myöhemmillä kursseilla. Käytännössä on epärealistinen tavoite opetella asioita "kerralla oikein", vaan monen asian oppii vasta kokeilemalla eri tapoja käytännössä. Toisaalta monet asiat ovat henkilökohtaisia mieltymyksiä.
En usko ohjelmoinnin peruskurssien valinnoilla olevan kauaskantoisia vaikutuksia opiskelijoihin. Kukaan kokenut ohjelmoija ei käytä metodia contains tai indexOf vain siksi, että niin tehtiin vuosia sitten ensimmäisellä ohjelmointikurssilla.
Jos sinulle tai muille tulee muuta mieleen kurssista, niin kerrothan. Tässä lähiaikoina kokoonnumme yhteen miettimään MOOC-kurssin jatkoa, joten pystyn välittämään terveisiä muillekin. Kriittinen palaute on meille arvokasta, ja se todellakin kiinnostaa meitä.
Antti Laaksonen kirjoitti:
Merkinnän ""+i etuna on lyhyys, koska muut tavat muuttaa luku merkkijonoksi ovat selvästi pidempiä.
Vika on se, että tuosta ei käy suoraan miksi noin tehdään. i.ToString() kuvaa luontevasti mitä/miksi tehdään. Toki se on pidempi, mutta mitä sitten? Jos koodin lyhyys olisi joku itseisarvo, käyttäisimme vain 1-merkkisiä muuttujia, Unicodea käyttäenhän ne ei heti lopu kesken. Itse kuitenkin sanoisin että se ei olisi hyvää koodaamista vaan pikemminkin obfuskointia.
Antti Laaksonen kirjoitti:
En usko ohjelmoinnin peruskurssien valinnoilla olevan kauaskantoisia vaikutuksia opiskelijoihin. Kukaan kokenut ohjelmoija ei käytä metodia contains tai indexOf vain siksi, että niin tehtiin vuosia sitten ensimmäisellä ohjelmointikurssilla.
Minusta olet vain osittain oikeassa. Joo, tuskin juuri jotain tiettyä metodia sen takia väkisin käytetään. Mutta jos kurssilla oppii uhraamaan selkeyden esim. lyhyen koodin alttarilla, niin sillä voi olla suurempi vaikutus.
Grez kirjoitti:
i.ToString() kuvaa luontevasti mitä/miksi tehdään. Toki se on pidempi, mutta mitä sitten?
Java ei sisällä tällaista mahdollisuutta. Jos kriteerinä on ymmärrettävyys, feenixin mainitsema String.format ei ole ainakaan parempi.
No on se String.format minusta inasen parempi. Se sentään kertoo että tavoite on muuttaa numero merkkijonoksi, eikä että tavoite on katenoida kaksi merkkijonoa.
Mutta en taas muistanut että Java. Itse käyttäisin ehkä tätä vaihtoehtoa: Integer.toString(i)
Siis joku ei ymmärrä mitä eroa on siinä, että luodaan ""+char -tavalla uusi string, jota käytetään hakiessa stringistä string, eikä että haetaan sillä olemassaolevalla merkillä sieltä merkkijonosta se merkki? Jälkimmäinen on hieman yksinkertaisempi eikä luoda turhia väliolioita.
Toki voi perustella aina sillä, että "me halutaan vaan tietää onko se siellä ja ihmiset menee sekaisin" mutta ei se silti ole minun mielestäni fiksua.
Mikä muuten oli alunperinkään perustelu sille, että hirsipuupelissä tallennetaan jo annetut merkit merkkijonoon, jotta sieltä piti etsiä sitä merkkiä? Kuitenkin niitä listoja ja taulukoita oli käytetty niin tuossa jostain syystä haluttiin tallentaa merkkijonoon?
Samoin tosiaan tuo numeron muuttaminen on järjetöntä opettaa tuollaisella tavalla kun Integer.toString() on olemassa ja on se oikea tapa tehdä asia. Eli jos perustelu "mutta halutaan vain tietää, että siellä on se merkki" on käytössä, samalla perustelulla "mutta kun halutaan muuntaa int merkkijonoksi eikä yhdistää merkkijonoa ja numeroa" perustelisi minusta Integer.toStringin käyttöä.
Ja kyse ei tosiaan ole yhden metodin käytöstä vaan siitä, että opetetaan heti alussa "virittely on ok, ei väliä vaikka luot merkkijonoja yhdistämällä tyhjän merkkijonon ja numeron" jne. Entäs kun vastaan tulee liukuluku? "Ai joo, mähän voin vaan tehdä näin" ja sitten meillä on taas sama ongelma kuin miljoonalla VB-softalla, joiden tekijät eivät edes tajunneet, että desimaalierotin voi olla erilainen eri koneissa.
Ja kuka ei ole nähnyt työelämässä väkeä, jotka koodaavat ties miten päin peetä, ihan vaan siksi kun ovat sattuneet oppimaan niin? Aika moni ei koskaan ole käynyt läpi mitään hyviä käytäntöjä tai miettinyt miksi tekee asiat kuten tekee. Sitä suuremmalla syyllä olisi hyvä, jos HYn peruskurssilla asiat olisivat järkevästi tehtyjä.
Mistä lähtien koodin lyhyys on ollut muuten tärkeämpää kuin selkeys?
Juu. Jos ihmiset opetetaan koodaamaan idioottimaisesti, niin tuloksena on satoja idiootteja ja pari osaajaa, jotka tajusivat kyseenalaistaa väärät mantrat. Ihmiset on luotu lampaiksi, joten ihan turha odottaa, että heistä tulisi mitään muuta.
Hyvä koodi on sekä lyhyt että selkeä. Kokemusteni mukaan tuo lyhyyden saavuttaminen on paljon vaikeampaa.
Javassa metodi Integer.toString on naurettavan pitkä, kun luvun muuttaminen merkkijonoksi on niin usein tarvittava toiminto. Esim. Pythonissa on funktio str, eikä kukaan valita sen lyhyydestä.
En ymmärrä, missä on ongelma, jos hirsipuun käytetyt merkit tallentaa merkkijonoon. Toki sen voi tehdä monella muullakin tavalla, mutta tämä ei tunnu asialta, jolla olisi syvällistä merkitystä.
Desimaalierottimen kanssa riittää ongelmia, vaikka koodin toteuttaisi millä tavalla. Jos tietää varmasti, että syötteessä on käytössä desimaalipiste, niin tämän olettava suoraviivainen koodi on hyvä vaihtoehto.
Suoritin MOOC:in huvin vuoksi vuosi sitten keväällä. Olen sen jälkeen suositellut sitä joillekin tutuilleni ja tällä hetkellä pari kaveriani käyvät kurssia. Molemmat ovat yleisesti ottaen tykänneet tehtävistä ja materiaalista. Autan heitä välillä tehtävien kanssa ja koodin taso on ollut mielestäni yllättävän hyvää aloitteleville ohjelmoijille. Lisäksi se on mennyt selvästi parempaan suuntaan kurssin edetessä. En ole huomannut mitään systemaattisia huonoja tapoja, joista voisi syyttää MOOC:ia.
Minua ärsytti MOOC:issa eniten se, miten iso osa kurssista keskittyy olio-ohjelmointiin ja Javan tapoihin tehdä asioita. Toinen mieleentuleva asia on se, miten useissa tehtävissä neuvotaan vaihe vaiheelta millainen luokkahierarkia ja mitkä metodit ja mitkä luokkamuuttujat pitää tehdä, eikä itsenäistä ajattelua vaadita tai sallita ollenkaan. Netbeansin valikot tulevat varmasti tutuksi, mutta välillä nämä tehtävät tuntuivat pelkältä ajanhukalta.
Yhdenmukainen koodaustyyli kaikissa esimerkeissä ja mallivastauksissa olisi todella hyvä juttu, mutta ymmärrän jos resurssit eivät toistaiseki ole riittäneet siihen.
MOOC:ssa on kuitenkin paljon hyvää ja suosittelen sitä varmasti jatkossakin jos joku haluaa tustua ohjelmointiin tai harkitsee käpistelyä.
Onko feenixillä muuten ehdottaa jotain parempaa vaihtoehtoa MOOC:ille?
Olio-ohjelmoinnin asema ohjelmoinnin peruskursseilla on vaikea kysymys. Omasta mielestäni olio-ohjelmointi tulisi jättää kokonaan pois ensimmäisiltä kursseilta ja käsitellä se kunnolla erillisellä kurssilla, mutta monen muun yliopistolla mielestä oliot on tärkeää tuoda mukaan heti alusta alkaen. Tästä on mahdotonta saada aikaan kaikkia tyydyttävää ratkaisua.
Antti Laaksonen kirjoitti:
Olio-ohjelmoinnin asema ohjelmoinnin peruskursseilla on vaikea kysymys. Omasta mielestäni olio-ohjelmointi tulisi jättää kokonaan pois ensimmäisiltä kursseilta ja käsitellä se kunnolla erillisellä kurssilla, mutta monen muun yliopistolla mielestä oliot on tärkeää tuoda mukaan heti alusta alkaen. Tästä on mahdotonta saada aikaan kaikkia tyydyttävää ratkaisua.
Kun Java on ollut viime vuosina yliopistoissa yleisimäpänä ohjelmointikielenä perus - ja jatkokursseilla (Ohjelmointi 1/2), niin on ollut aika hankalaa olla käsittelemättä olioita edes perustasolla.
Antti Laaksonen kirjoitti:
Javassa metodi Integer.toString on naurettavan pitkä, kun luvun muuttaminen merkkijonoksi on niin usein tarvittava toiminto. Esim. Pythonissa on funktio str, eikä kukaan valita sen lyhyydestä.
Eihän kukaan nytkään valittanut lyhyydestä, vaan siitä että lyhyyttä tavoitellaan jonkin muun kustannuksella.
Antti Laaksonen kirjoitti:
Hyvä koodi on sekä lyhyt että selkeä. Kokemusteni mukaan tuo lyhyyden saavuttaminen on paljon vaikeampaa.
Sekoitatkohan nyt merkkimääräisen lyhyyden ja rakenteellisen lyhyyden keskenään?
Olen samaa mieltä, että ohjelma jossa sama työ saadaan aikaiseksi vähemmällä määrällä koodia (=työtä ohjelmoijalle ja tietokoneelle) on yleisesti parempi, mutta silti mielestäni näistä jälkimmäinen on parempi:
var km = db.Users.Count();
vs
var käyttäjäMäärä = db.Users.Count();
Riippuu tilanteesta. Joskus tämä voisi olla paras:
var n = db.Users.Count();
Myös merkkimääräinen lyhyys on tärkeää, koska vähän tekstiä on nopeampaa hahmottaa kuin paljon tekstiä. Esim. matematiikassa käytetään merkkiä π, vaikka saatavilla olisi paljon selkeämpi nimi ympyranKehanSuhdeHalkaisijaan.
Seuraava koodipari selventää ehkä asiaa:
int luvuistaPienempi(int ensimmainenLuku, int toinenLuku) {
boolean ensimmainenPienempi = ensimmainenLuku < toinenLuku;
if (ensimmainenPienempi) {
return ensimmainenLuku;
} else {
return toinenLuku;
}
}int pienin(int a, int b) {
if (a < b) return a;
return b;
}Tosiaan riippuu tapauksesta. Tarkoitin tilannetta missä muuttujan scope on pidempi kuin muutama rivi ja jossa muuttujalla on selkeä merkitys.
Tuo funktio pienin on mainio esimerkki tapauksesta, jossa funktio itse ei tiedä ko. muuttujien merkityksestä yhtään mitään. Silti esim. MS on päättänyt nimetä ne Math-luokassaan val1 ja val2 (takes 2 values)
jlaire kirjoitti:
Minua ärsytti MOOC:issa eniten se, miten iso osa kurssista keskittyy olio-ohjelmointiin ja Javan tapoihin tehdä asioita. Toinen mieleentuleva asia on se, miten useissa tehtävissä neuvotaan vaihe vaiheelta millainen luokkahierarkia ja mitkä metodit ja mitkä luokkamuuttujat pitää tehdä, eikä itsenäistä ajattelua vaadita tai sallita ollenkaan. Netbeansin valikot tulevat varmasti tutuksi, mutta välillä nämä tehtävät tuntuivat pelkältä ajanhukalta.
Varsinkin nuo valmiiksi pureskellut tehtävät ärsyttivät minua. Onhan siinä tietenkin se hyvä puoli, että saa alle toistoa. Toisto olikin kurssin paras osa, koska en pysty kuvittelemaan, että ilman tuollaista kurssia kukaan tekisi noin paljoa aika samanlaisia asioita ja rakentaisi parempaa tulevaisuutta omalle ohjelmoinnilleen. Kurssi taisi olla myös suunniteltu yläaste ikäisille tai ainakin selvästi nuoremmille, koska välissä selitykset olivat kuin tehty uuasavuttomille. En vain nyt saa päähäni, mitkä kohdat herättivät huomioni.
Antti Laaksonen kirjoitti:
Myös merkkimääräinen lyhyys on tärkeää, koska vähän tekstiä on nopeampaa hahmottaa kuin paljon tekstiä. Esim. matematiikassa käytetään merkkiä π, vaikka saatavilla olisi paljon selkeämpi nimi ympyranKehanSuhdeHalkaisijaan.
Matematiikka on ensinnäkin symbolinen kieli ja toisekseen se on kehitetty sellaiseen aikaan, jolloin vielä piirreltiin kepillä viivoja hiekkaan. Matematiikka ei ole oikein mitenkään verrannollinen ohjelmointiin tässä asiassa.
The Alchemist kirjoitti:
Matematiikka on ensinnäkin symbolinen kieli
Ai onko? No sittenhän se eroaa ohjelmointikielistä merkittävästi, itsehän koodaat aina vain konekielillä, et noihin symbolisiin koske.
The Alchemist kirjoitti:
toisekseen se on kehitetty sellaiseen aikaan, jolloin vielä piirreltiin kepillä viivoja hiekkaan.
Eiköhän matematiikkaa ole kehitetty ihan nykypäivään saakka. On täysin toissijaista milloin ensimmäisen kerran matematiikkaa tai sen syntaksia kehitettiin.
Minä kylläkin koodaan muiden putkalaisten tapaan hyvinkin paljon kirjoitettua kieltä muistuttavilla ohjelmointikielillä. Käytetty merkistökin on melkolailla yksinkertaistettua asciita.
Szanne kirjoitti:
Varsinkin nuo valmiiksi pureskellut tehtävät ärsyttivät minua. - - Kurssi taisi olla myös suunniteltu yläaste ikäisille tai ainakin selvästi nuoremmille, koska välissä selitykset olivat kuin tehty uuasavuttomille.
Kurssin opiskelijoiden lähtötaso ja kyky omaksua ohjelmointia vaihtelevat suuresti. Kommentistasi päätellen sinulle on ollut helppoa oppia ohjelmointia, ja hyvä niin, mutta uskon kurssilla olevan myös yläasteen ohittaneita osallistujia, joille materiaalin rautalangasta tehdyt selostukset ovat hyödyllisiä.
The Alchemist kirjoitti:
Matematiikka on ensinnäkin symbolinen kieli ja toisekseen se on kehitetty sellaiseen aikaan, jolloin vielä piirreltiin kepillä viivoja hiekkaan.
Niissä symboleissa on nimenomaan ideana, että merkintöjä lyhentämällä oleellisen asian havaitsee paremmin. Välillä näyttää siltä, että "modernissa" ohjelmoinnissa ollaan menossa toiseen suuntaan.
Itse ainakin koin kurssin hyväksi juurikin nuiden valmiiksi pureskeltujen tehtävien ansiosta. Näki hyvästi muitakin tapoja ohjelmoida kuin oman tavan ja nuo muut tavat ovat varmasti huomattavasti parempiakin vaikka nekään eivät kaikkia miellytä. On varmasti hyvä ja myös välttämätöntä oppia ratkaisemaan ongelmia itse, mutta miksi pimittää aloittelijalta hyviä tapoja ohjelmoida? Ongelmanratkontaa tulee varmasti eteen heti ensimmäistä omaa projektia aloittaessa jolloin on hyvä ottaa mallia valmiista esimerkeistä.
Antti Laaksonen kirjoitti:
Niissä symboleissa on nimenomaan ideana, että merkintöjä lyhentämällä oleellisen asian havaitsee paremmin. Välillä näyttää siltä, että "modernissa" ohjelmoinnissa ollaan menossa toiseen suuntaan.
Jotenkin tuntuu ettei vaan haluta ymmärtää, miksi esim. niitä pidempiä muuttujien, luokkien, funktioiden yms. nimiä käytetään vaan takerrutaan lillukanvarsiin ja tekemällä tehdään älyttömiä vastaesimerkkejä.
Tietenkin tilapäismuuttujat ja muut pienen näkyvyysalueen muuttujat voi olla esim. yksikirjaimisia jne.
Mutta tyypillisesti kokonainen ohjelma on sisältää monta kertaluokkaa suuremman määrän muuttujia kuin joku matemaattinen juttu. En usko että matemaattisessakaan jutussa olisi enää kovin havainnollista, jos siellä olisi vaikka 100 yksimerkkistä muuttujaa.
Ja samoin jos muuttujalla on laaja näkyvyysalue, katoaa lyhyen muuttujan "havainnollisuus" nopeasti. Jos vaikka matematiikan kirjassa olisi sivulla 1 joku juttu jossa käytettäisiin muuttujaa n, niin ei varmaan olisi kovin havainnollista viitata sivulla 100 samaan asiaan ihan vaan pelkästään sillä että käytetään taas muuttujaa n.
Matematiikka on symbolinen kieli ja php- tai c++-ohjelmointi ei sellaista niinkään ole. Tällaisten kielten yhteydessä on paljon selvempää lukea pidempiä muuttujien nimiä. Funktioiden nimeämiseen tällainen käytäntö on sentään saatu adoptoitua jo kauan sitten, vertaa vaikka c-kielen funktiota itoa() ja Javan funktiota Integer.toString().
Jos alkaisin ohjelmoida lispiä tai haskellia tai jotain muuta funktionaalista kieltä (symbolista kieltä), niin lyhyet muuttujien nimet olisivat selvästi paljon hyödyllisempiä, koska käytetyt ilmaisut ovat monimutkaisempia ja abstraktimpeja kuin imperatiivisissa kielissä. Ymmärtääkseni funktiot ovat toteutuksiltaan myös paljon lyhyempiä, jolloin muuttujien näkyvyysalueet ovat pieniä ja siten havainnollistavan nimeämisen hyötykin jää itsessään mitättömäksi.
Grez kirjoitti:
Ja samoin jos muuttujalla on laaja näkyvyysalue, katoaa lyhyen muuttujan "havainnollisuus" nopeasti. Jos vaikka matematiikan kirjassa olisi sivulla 1 joku juttu jossa käytettäisiin muuttujaa n, niin ei varmaan olisi kovin havainnollista viitata sivulla 100 samaan asiaan ihan vaan pelkästään sillä että käytetään taas muuttujaa n.
Noinhan juuri matikassa tehdään, ei tosin muuttujien kanssa vaan vakiot (pii, neperin luku...), lukujoukot (N,Z,Q,R,C), summa (∑), derivaatta (´), integraali (∫) jne...
Varmaan esim. on tuttu: m, n ∈ Z
(Vastaa "oudosti" ohjelmointikoodia int n, m; kummaa...)
Aihe on jo aika vanha, joten et voi enää vastata siihen.