Javan alkeiskirjan luonnos
Ilkka Kokkarinen
minulla on siitä ensimmäinen luonnos valmiina osoitteessa
http://members.rogers.com/imk-01/perus.ps
(153 sivua, 880 kilotavua). Kommentteja ja parannusehdotuksia otetaan
mielihyvin vastaan.
Ilkka Kokkarinen
Aggro
Tiedostomuotona näytät käyttävän .ps:ää. Se ei ehkä ole se kaikkein
avautuvin tiedostomuoto niille jotka varmaan eniten ohjelmoinnin
perusteista ovat kiinnostuneet. Kannattaa ehkä harkita jotain
tunnetumpaa tiedostomuotoa. Tai antaa levityksen yhteydessä tarkat
ohjeet siitä miten tiedoston saa auki.
Ilkka Kokkarinen
"Aggro" <spamme...@yahoo.com> wrote in message
news:V64Ga.485$nm4...@read3.inet.fi...
> Tiedostomuotona näytät käyttävän .ps:ää. Se ei ehkä ole se kaikkein
> avautuvin tiedostomuoto niille jotka varmaan eniten ohjelmoinnin
> perusteista ovat kiinnostuneet. Kannattaa ehkä harkita jotain
> tunnetumpaa tiedostomuotoa.
Totta, mutta minun LaTeX-järjestelmäni ei yrityksistäni huolimatta jostain
syystä tee pdf:stä sellaista, ettei se olisi ruudulla sumeaa pikselikökköä.
Laitoin sinne tosin nyt pdf-versionkin, osoitteeseen
http://members.rogers.com/imk-01/perus.pdf
Arvattavasti jokin komentorivivipunen auttaisi (\usepackage[T1]{fontenc}
ei tee mitään näkyvää), mutta jos näin on, niin pitäkööt tunkkinsa. Jostain
syystä vain ohjelmoija voi ajatella, että jos vaihtoehdot ovat (1)
dokumentti tuotetaan kökköfonteilla ja (2) dokumentti tuotetaan
hyvännäköisillä fonteilla, vaihtoehdon (1) pitää olla ohjelman käyttämä
oletusarvo ja vaihtoehdon (2) piilotettu.
Ilkka Kokkarinen
Aki Honkasuo
> Totta, mutta minun LaTeX-järjestelmäni ei yrityksistäni huolimatta jostain
> syystä tee pdf:stä sellaista, ettei se olisi ruudulla sumeaa pikselikökköä.
PDF:iä varten ei kannata käyttää LaTeXin oletusfontteja. PostScript
fonteilla saa hyvää jälkeä. Paras vaihtoehto verkkokulkaisuja varten on
mielestäni latex2html-skripti. Sisällysluettelo toimii linkeillä ja
dokumentti on luettavissa vaikka PDF-sovellusta ei olisi koneelle
asennettuna. Sopivilla parametreilla saa varmasti mieleisen rakenteen ja
ulkoasun omalle dokkarille :)
http://saftsack.fs.uni-bayreuth.de/~latex2ht/
Itse suosin LaTeX/LyX:ia osaksi siksi että LaTeX-formaatti on näppärästi
muunnettavissa niin tulostettavaksi possuksi kuin loogisiksi
HTML-sivuiksi.
--
Aki "Aksu" Honkasuo Peace, Love E-Mail: honkasuo lut fi
Punkkerikatu 1 B 30 and Voice: +358 (0)50 533 5336
Fin-53850 Lappeenranta Free Software http://www.lut.fi/~honkasuo/
Jari Laitinen
>
> Laitoin sinne tosin nyt pdf-versionkin, osoitteeseen
>
> http://members.rogers.com/imk-01/perus.pdf
>
> Arvattavasti jokin komentorivivipunen auttaisi (\usepackage[T1]{fontenc}
> ei tee mitään näkyvää), mutta jos näin on, niin pitäkööt tunkkinsa. Jostain
> syystä vain ohjelmoija voi ajatella, että jos vaihtoehdot ovat (1)
> dokumentti tuotetaan kökköfonteilla ja (2) dokumentti tuotetaan
> hyvännäköisillä fonteilla, vaihtoehdon (1) pitää olla ohjelman käyttämä
> oletusarvo ja vaihtoehdon (2) piilotettu.
>
Kökköfonteilta näytti, mutta sisältö ei varmaankaan ollut kökköä. :)
Oli ihan luettavaa tekstiä, eniten häiritsi pdf-dokun lopussa olevat
erittäin suuret tyhjät alueet.
Mitä tulee Javan-esitykseen niin minusta näytti hyvältä.
Nyt täyttyy ottaa huomioon, että en ole kirjoittanut
Javalla riviäkään. Enemmän koodanneena (eri kielillä,
paitsi tuo Java), niin oli _tuskastuttavaa_ selailla
läpi nuo normaalit ohjelmarakenne asiat
(esim. for-silmu ja jne.)
Mutta, se ei ole aloittelijan ongelma.
Asia, mikä on aloittelijan ongelma:
On se, että kuinka kirjan ensimmäinen esimerkki saadaan
käynnistymään ja tekemään tuo ihmellinen ilmoitus. Siitä
voisi olla muutama maininta. Ei paljon auta, että on koodi
esimerkkejä, mutta ei mainintaa kuinka saa toimimaan.
-Jari
Lauri Alanko
> Ilkka Kokkarinen <imk...@rogers.com> wrote:
>
> > Totta, mutta minun LaTeX-järjestelmäni ei yrityksistäni huolimatta jostain
> > syystä tee pdf:stä sellaista, ettei se olisi ruudulla sumeaa pikselikökköä.
>
> PDF:iä varten ei kannata käyttää LaTeXin oletusfontteja. PostScript
> fonteilla saa hyvää jälkeä. Paras vaihtoehto verkkokulkaisuja varten on
> mielestäni latex2html-skripti.
"Paras"? Oletko vertaillut vaihtoehtoihin?
http://www.ccs.neu.edu/home/dorai/tex2page/tex2page-doc.html
http://para.inria.fr/~maranget/hevea/
http://hutchinson.belmont.ma.us/tth/
http://www.cis.ohio-state.edu/~gurari/TeX4ht/
Lauri Alanko
l...@iki.fi
Juhani Simola
> PDF:iä varten ei kannata käyttää LaTeXin oletusfontteja. PostScript
> fonteilla saa hyvää jälkeä. Paras vaihtoehto verkkokulkaisuja varten on
Iki-ihanasta Computer Modernista on toki olemassa vektorimuotoinen
versio, tai oikeastaan useampi eri kokoja varten. Ne saa käyttöön
LaTeXissa (tai ainakin TeTeXissä) lataamalla aecompl-paketin. Siis
seuraava rivi dokumentin alkuun pelastaa:
\usepackage{aecompl}
Juhani
Juhani Simola
> PDF:iä varten ei kannata käyttää LaTeXin oletusfontteja. PostScript
> fonteilla saa hyvää jälkeä. Paras vaihtoehto verkkokulkaisuja varten on
Iki-ihanasta Computer Modernista on toki olemassa vektorimuotoinen
versio, tai oikeastaan useampi eri kokoja varten. Ne saa käyttöön
LaTeXissa (tai ainakin TeTeXissä) lataamalla ae- ja aecompl-paketit.
Siis seuraavat rivit dokumentin alussa pelastavat:
\usepackage{ae}
\usepackage{aecompl}
Juhani
Harri Nykanen
news:gB3Ga.66303$G_....@news02.bloor.is.net.cable.rogers.com:
> Kommentteja ja parannusehdotuksia
> otetaan mielihyvin vastaan.
Lainataampa hieman teostasi:
> Kirjan teksti ja esimerkit olettavat, että lukijalla on käytössään
> nimen omaan nykyaikainen BlueJ-ohjelmointiympäristö: muut
> ohjelmointiympäristöt eivät kerta kaikkiaan kelpaa.
Hmm. Muut vaatimukset?? 3GHz P4 tai AMD XP2600+ ???
Vaiko peräti IBM z390? muut alustat eivät yksinkertaisesti kelpaa...
> Perinteisiin Java-ympäristöihin verrattuna BlueJ mahdollistaa
> tiettyjen epäolennaisuuksien jättämisen kokonaan pois, mikä
> yksinkertaistaa ja suoraviivaistaa valtavasti jäljelle jääneiden
> tärkeiden asioiden käsittelyä.
Pidetään mielessä ja edetään ensimmäiseen harjoitukseen...
> Ennen kuin pääset kirjoittamaan omia luokkia, sinun täytyy aloittaa
> uusi projekti
Siis? Epäolennaisuudet jäävät pois? BlueJ:llä et voi tehdä mitään ennen
kuin on luotu projekti??? Siis ei edes yksinkertaista Hello World
sovellusta voi kirjoittaa ja kääntää.... Muistuu elävästi mieleen
Borland JBuilder / Oracle JDeveloper....
No kirjasi nimi varmaankin tulee olemaan Java ohjelmointia BlueJ:llä.
Asiallisempi näkökohta olisi kertoa saatavilla olevista
kehitysympäristöistä lyhyesti (kokemusta ilmeisesti on kun tuo BlueJ on
mielestäsi ehdoton) ja mainita että kirjan kirjoittaja on käyttänyt
BlueJ:tä kirjaa kijoittaessa.
Ja tosiaan fontit olivat luettavissa PDF-versiossa vasta 300%
suurennoksella...
--
Harri
Tätäkään viestiä ei lähetetty mphelsinki palvelun kautta
Aki Honkasuo
>> PDF:iä varten ei kannata käyttää LaTeXin oletusfontteja. PostScript
>> fonteilla saa hyvää jälkeä. Paras vaihtoehto verkkokulkaisuja varten on
>> mielestäni latex2html-skripti.
> "Paras"? Oletko vertaillut vaihtoehtoihin?
HaVeA on tehnyt kyllä mieli kokeilla. Keväällä ei ole ollut mitään
dokkaria, jota olisi pitänyt saada verkoon näkyville, joten on jäänyt
kehittyneemmät konvertterit kokeilematta :( Laiskuus, mikä ihana tekosyy
olla kokeilematta jotain uutta ilman konkreettista syytä ;)
Tosin latex2html on tehnyt sen mitä olen halunnut sen tekevän, joten voin
tuota defaulti bulautinta edelleenkin suositella. Ei tullut mieleen
suositella noita vaihtoehtoja kokeiltavaksi.
Jouko Holopainen
> (153 sivua, 880 kilotavua). Kommentteja ja parannusehdotuksia otetaan
> mielihyvin vastaan.
Vaatii tietyn IDE:n käytön?
Kannattaisiko nimeä viilata siten, että jo siitä näkee tämän
vaatimuksen? "Java aloittelijoille BlueJ:llä", tjsp?
Ainakin minulle tämä on este, ei hidaste. Minä¹ en jaksa ladata ja
asentaa - ja pettyä taas - uutta IDEä jonkun oppimiseksi.
¹ en tosin ole aloittelija, että ...
Sisällöstä:
Kannattaisi mielestäni
1. käyttää JavaDoc kommentteja heti alusta alkaen (ja kertoa jossain
vaiheessa miksi)
2. käyttää Sunin Javakoodiohjesääntöä. Eroavaisuutesi ovat tarpeettomia.
3. käyttää get/set/is... nimeämiskäytäntöä (kts kohta 2), vaikka se
suomeen huonosti sopiikin. Ehkä kuitenkaan ei?
4. Näyttää todellinen useamman objektin sisältävä ohjelma. Esim GUI
jossa HelpAbout jne? Ei jäisi koko OO pelkän teorian varaan, lähes
kaikki esimerkkisi ovat "kuin kopioitu C:stä".
--
@jhol
"Trust me, I know what I am doing"
-- m$ Trustworthy Computing slogan
Niko Kiirala
= -merkin käyttöä käsittelevä kappale on kovin sekava mielestäni. Siinä
yrität selittää tuota asiaa liian hienosti.
Yksinkertaisemmin voisi kertoa esim. että "=" tarkoittaa Javassa "saa
arvon" eikä "on yhtä suuri kuin" (joka taasen on "==")
--
Niko Kiirala
Virtanen Antti
Ilkka Kokkarinen wrote:
Tässä omia mietteitäni - selasin opuksen nopeasti läpi:
Merkkijonot esitellään melko alussa, mutta tässä yhteydessä en
huomannut mainintaa StringBuffer -luokasta, enkä siitä että
merkkijonojen vertailu pitää suorittaa == operaattorin sijasta equals
-metodin avulla.
Jälkimmäisestä ei mainittu myöskään kappaleessa jossa puhuttiin
ehtolauseista. Aloittelijan erittäin yleinen moka on käyttää
merkkijonoille == operaattoria, etenkin kun se joskus toimii.
Olen myös samaa mieltä toisen kommentoijan kanssa siitä että
javadoc-kommentteja olisi ihan hyvä käyttää alusta asti.
Joissakin koodiesimerkeissä on käytetty ääkkösiä ja ne eivät taida
mennä javakääntäjästä läpi. Tietysti esimerkin luettavuuden kannalta
on perusteltua käyttää ääkkösiä, että kyse on makuasiasta. Ehkä
kuitenkin parempi näin.
Object -luokan metodeista on vain lyhyt maininta, mutta niistä voisi
kyllä puhua enemmänkin. Etenkin equals -metodia ja sen oikeaoppista
ylikuormittamista voisi käsitellä perusteellisemmin. Kyse on
perusoppikirjasta, mutta tämän mokaaminen on yleinen virhe käytännön
javaohjelmissa.
Poikkeuksista sanotaan että "Poikkeukset ovat Javassa valmiina olevia
luokkia, jotka on periytetty kantaluokasta Exception". Usein on
kätevää määritellä omia poikkeuksiaan, minkä voisi ainakin mainita.
Kirjassa oli kiitettävän hyvin suomennettu alan termejä, mutta
englanninkielisen vastineen mainitseminen auttaa lukijaa seuraamaan
alan englanninkielistä kirjallisuutta, jota on kuitenkin huomattavasti
enemmän tarjolla.
Monisäikeisyydestä voisi puhua enemmänkin, koska se on alkeiden
opettelun jälkeen usein eteen tuleva hankala asia.
Javan valmiita rajapintoja ei juuri käsitelty. Ehkä joitakin keskeisiä
asioita voisi esitellä hieman läheisemmin. Samoin näihin liittyviä
potentiaalisia ongelmakohtia, esim. käytänkö Vectoria vai ArrayListia?
Asioiden esittelyjärjestystä voisi miettiä uudelleen. En kylläkään
osaa ehdottaa parempaa järjestystä :)
Kirjassa käsiteltiin ohjelmien optimointia lyhyesti, tähän voisi
panostaa selvästi enemmän. Aiheesta on tietenkin kirjoitettu teos jos
toinenkin, mutta javaa usein syytetään hitaaksi täysin
perusteettomasti, kun kyse on lähinnä ohjelmoijan
kyvyttömyydestä. Virikkeitä tähän aiheeseen löytynee ainakin kirjoista
Effective Java, Java performance tuning ja tietysti Bentleyn "Writing
efficient programs". No jälkimmäisen lienet lukenutkin.
Javan tavukoodista ja siitä että ohjelman voi kääntää helposti
takaisin lähdekoodiksi en huomannut mitään mainintaa, mutta tästä
voisi mainita. Usein käytetään erityisiä työkaluja koodin
sekoittamiseksi, eikä pelkästään turvallisuusnäkökohtien takia.
Kokonaisuutena hyvä alku kirjalle. Kaikki kappaleet ovat sisällöltään
loogisia ja hyvin kirjoitettuja (en tosin muuta odottanutkaan).
// Antti "lokori" Virtanen
Ilkka Kokkarinen
"Harri Nykanen" <no-...@nic.fi> wrote in message
news:Xns9398F146F...@195.197.54.116...
> > Kirjan teksti ja esimerkit olettavat, että lukijalla on käytössään
> > nimen omaan nykyaikainen BlueJ-ohjelmointiympäristö: muut
> > ohjelmointiympäristöt eivät kerta kaikkiaan kelpaa.
Okei, tuo on liian vahvasti sanottu. Mutta syy, miksi käytössä on nimen
omaan BlueJ, on se, ettei kummallisia luokkametodeita kuten public static
void main(String []) tarvitse käyttää lainkaan, vaan olioita voidaan luoda
interaktiivisesti, osoittaa niitä hiirellä ja kutsua niiden metodeita. Tämä
on aloittelijoille havaintoni mukaan aivan käsittämättömän paljon asioita
helpottava ja selkeyttävä parannus.
> Siis? Epäolennaisuudet jäävät pois? BlueJ:llä et voi tehdä mitään ennen
> kuin on luotu projekti???
Tuossa olisi kyllä parannusehdotus BlueJ:n seuraavaan versioon siten, että
jonkinlainen default-projekti olisi aluksi automaattisesti auki.
> No kirjasi nimi varmaankin tulee olemaan Java ohjelmointia BlueJ:llä.
Kyllä, nimi "BlueJ" on kirjassa ainakin alanimenä.
> Ja tosiaan fontit olivat luettavissa PDF-versiossa vasta 300%
> suurennoksella...
Toivottavasti ne ovat nyt parempia, Juhani Simolan neuvo käyttää ae-pakettia
tuntui toimivan.
Ilkka Kokkarinen
Jouko Holopainen
> Joissakin koodiesimerkeissä on käytetty ääkkösiä ja ne eivät taida
> mennä javakääntäjästä läpi.
Menee. Java on tässä suhteessa erittäin fiksu, se syä "jopa" Unicodea.
> Javan valmiita rajapintoja ei juuri käsitelty.
Totta. Javassa on erittäin laaja "valmis rengasto", ei tarvi itse
keksiä pyörivää.
> Kirjassa käsiteltiin ohjelmien optimointia lyhyesti, tähän voisi
> panostaa selvästi enemmän.
TÄYSIN erimieltä. _Aloittelijan_ EI MISSÄÄN TAPAUKSESSA pidä edes
kuvitella/ajatella optimoivansa.
Optimointi tulee vastaan ehkä jos sattuu tosi paska koodi ja mäihä,
yhtäaikaa. Jolloin profiler mitä todennäköisimmin (ei tosin aina)
auttaa.
Ilkka Kokkarinen
"Virtanen Antti" <virt...@cs.tut.fi> wrote in message
news:slrnbej9g1....@mustatilhi.cs.tut.fi...
Kiitoksia kommenteista, mutta kommentoin vähän itsekin takaisin:
> Merkkijonot esitellään melko alussa, mutta tässä yhteydessä en
> huomannut mainintaa StringBuffer -luokasta,
mikä on tarkoituksellista, koska tuon luokan eroilla Stringiin ei ole
aloittelijoille pienintäkään merkitystä.
Tällaiset kompleksisuudet ovat tietysti pieniä meidän kannaltamme, mutta kun
niitä kasataan ja kasataan joka ikiseen paikkaan, aloittelija menettää kyvyn
hallita sitä kokonaisuutta, joka hänellä on sillä hetkellä näkyvissään. Ei
aloittelija pysty millään näkemään, mikä on oikeasti olennaista ja mikä ei,
ja metsä hukkuu puilta.
> enkä siitä että
> merkkijonojen vertailu pitää suorittaa == operaattorin sijasta equals
> -metodin avulla.
Tämä onkin oikeasti tärkeä asia, joka on jäänyt pois, ja lisään sen ilman
muuta seuraavaksi käsikirjoitukseen ennen kuin alan kirjoittamaan mitään
muuta.
Nuo kaksi edellistä esimerkkiä muuten vahvistavat käsitystäni siitä, että
Javakin on vielä liian matalan tason kieli ohjelmoinnin perusopetukseen.
Kieli pitäisi suunnitella siten, että yhtäsuuruus on yhtäsuuruutta olioiden
tyypistä riippumatta, ja jos viitteitä on olemassa kielen abstraktiotasolla,
niiden yhtäsuuruus on omanlaistaan yhtäsuuruutta.
> Joissakin koodiesimerkeissä on käytetty ääkkösiä ja ne eivät taida
> mennä javakääntäjästä läpi. Tietysti esimerkin luettavuuden kannalta
> on perusteltua käyttää ääkkösiä, että kyse on makuasiasta. Ehkä
> kuitenkin parempi näin.
Kuten tuolla jo sanottiinkin, javasta menevät hyvin läpi paitsi ääkköset,
myös vaikka aasialaiset merkit. Juuri tällaisia asioita tarkoitin, kun
kirjoitin että 1970-luvun painolasti elää vieläkin ohjelmoinnin
perusopetuksessa eikä kukaan edes huomaa kyseenalaistaa sitä.
> Object -luokan metodeista on vain lyhyt maininta, mutta niistä voisi
> kyllä puhua enemmänkin. Etenkin equals -metodia ja sen oikeaoppista
> ylikuormittamista voisi käsitellä perusteellisemmin.
Totta, tuosta taidan tänään kirjoittaa oman alaluvun lukuun kuusi.
> Poikkeuksista sanotaan että "Poikkeukset ovat Javassa valmiina olevia
> luokkia, jotka on periytetty kantaluokasta Exception". Usein on
> kätevää määritellä omia poikkeuksiaan, minkä voisi ainakin mainita.
Totta... jos kyseessä olisi Javan hakuteos! Aloittelijalta kestää todella
pitkä aika, ennen kuin hän voi mielekkäästi määritellä omia poikkeusluokkia
ja käyttää niitä.
> Kirjassa oli kiitettävän hyvin suomennettu alan termejä, mutta
> englanninkielisen vastineen mainitseminen auttaa lukijaa seuraamaan
> alan englanninkielistä kirjallisuutta, jota on kuitenkin huomattavasti
> enemmän tarjolla.
Jep, tarkoitus onkin lopuksi laittaa edellisten kirjojeni tapaan kirjan
lopullisen version perään liite, joka sisältää käytetyt termit ja niiden
englanninkieliset vastineet.
> Monisäikeisyydestä voisi puhua enemmänkin, koska se on alkeiden
> opettelun jälkeen usein eteen tuleva hankala asia.
Puhuisin kyllä, jos keksisin mielekästä puhuttavaa.
> Javan valmiita rajapintoja ei juuri käsitelty. Ehkä joitakin keskeisiä
> asioita voisi esitellä hieman läheisemmin. Samoin näihin liittyviä
> potentiaalisia ongelmakohtia, esim. käytänkö Vectoria vai ArrayListia?
> Asioiden esittelyjärjestystä voisi miettiä uudelleen. En kylläkään
> osaa ehdottaa parempaa järjestystä :)
Siitä en tee kompromissia, että luokat ja oliot käsitellään ensin, ja vasta
sitten esimerkiksi ehto- ja toistolauseet. Olennainen asia käsitellään
ensin. :-)
> Kirjassa käsiteltiin ohjelmien optimointia lyhyesti, tähän voisi
> panostaa selvästi enemmän.
Nimen omaan päinvastoin. Kaikenlainen optimointi on täysin mahdotonta
aloittelijalle, joten ainoa toimiva neuvo hänelle on olla edes yrittämättä
sitä, ja kirjoittaa koodinsa tavoitteenaan selkeys ja toimivuus.
> Aiheesta on tietenkin kirjoitettu teos jos
> toinenkin, mutta javaa usein syytetään hitaaksi täysin
> perusteettomasti,
Aloittelijalta kestää tosi kauan, ennen kuin hän edes pystyy kirjoittamaan
sellaisen ohjelman, jonka suoritus vaikuttaa hänestä hitaalta.
> Kokonaisuutena hyvä alku kirjalle. Kaikki kappaleet ovat sisällöltään
> loogisia ja hyvin kirjoitettuja (en tosin muuta odottanutkaan).
Kiitokset kehuista, mikä on sikäli hyvä juttu, että kyseessä on vasta
ensimmäinen versio, joka (jos mennyt on tae tulevasta) tulee vielä
paranemaan laadultaan melkoisesti. Varsinkin kun otan saamani kommentit
huomioon.
Ilkka Kokkarinen
Vesa Lappalainen
> Olen viimeiset viikot kirjoittanut Java-ohjelmoinnin perusoppikirjaa, ja nyt
> minulla on siitä ensimmäinen luonnos valmiina osoitteessa
// metodi, joka ottaa parametrikseen merkkijonon
public void annaNimi(String n) {
nimi = n;
}
Tuosta olikin aikaisemmin puhetta: ennenkuin näin
koodiesimerkin, niin pelkkää tekstiä lukiessa ihmettelin
kovasti että mitä annaNimi tulee tekemään.
asetaNimi tai muutaNimi tms. jos on pakko käyttää
suomea. Kuitenkin jos joskus papuihin mennään niin
miksei jo nyt ota get ja set käyttöön?
Ja ilman muuta JavaDoc peliin jo heti ekoista kommenteista
alkaen. Myöhemmin voi selittää sen merkitystä.
Apinoimalla ihminen oppii ja "väärin" apinoitua
on vaikea poisoppia.
Ohjelmoinnissa ei minun kokemuksen mukaan ole mitään
pahempaa kuin globaalit muuttujat. Kuinka vältetään
vaara ettei luokista kasva liian isoja ja
attribuuteja ei sitten käytetä kuin globaaleja
muuttujia? Voi kun näisä "peruskielissä"
voisi sanoa että tätä attribuuttia saa muuttaa
vain tämä ja tämä metodi ja käyttää vain tämä ja tämä
metodi.
En käyttäisi protected-attribuutteja juuri
em. syistä, että silloin karkaa käsistä se että
kuka todella attribuutteja hallitsee.
Käsittääkseni ainoa syy protected attribuutteihin
on koodin optimointi ettei tarvtse käyttää
get/set-metodeja ja sehän jo aikaisemmin täällä
tyrmättiin. Jokos Java-osaa inlinetä yksinkertaisia
metodeja. Silloin optimointikaan ei olisi peruste
protected-attribuutille.
Vesa
Aggro
> Kuten tuolla jo sanottiinkin, javasta menevät hyvin läpi paitsi ääkköset,
> myös vaikka aasialaiset merkit. Juuri tällaisia asioita tarkoitin, kun
> kirjoitin että 1970-luvun painolasti elää vieläkin ohjelmoinnin
> perusopetuksessa eikä kukaan edes huomaa kyseenalaistaa sitä.
Ääkkösissähän ei välttämättä tule ongelmaa vastaan, paitsi siinä
vaiheessa kun jonkun vierasmaalaisen pitää lukea sitä. Nimeänkin siksi
muuttujat englannin kielisiksi nykyään ja kommentoin myös samalla
kielellä. Samalla vierasmaalaiset välttyvät ongelmalta "mistä löydän ä
kirjaimen näppäimistöltäni".
Toisaalta aloittelijan on ehkä hyvä nimetä muuttujia suomeksi, että
tajuaa sen, että muuttujat ovat varsin vapaasti nimettävissä ja että ne
kannattaa nimetä kuvailevasti.
Toisaalta taas jos Javassa oppii käyttämään ääkkösiä ja siirtyy sitten
toiseen kieleen, missä ääkkösiä ei saa käyttää, voi syntyä pieniä
vieroitusoireita.
No hieman pohdiskelua vain asiasta. En osaa sanoa mikä olisi fiksuinta.
Itse jatkan kuitenkin englannin kielisillä nimillä, kun en ihan
aloittelija enää ole ;)
Vesa Lappalainen
> Olen viimeiset viikot kirjoittanut Java-ohjelmoinnin perusoppikirjaa, ja nyt
Kirjoittelen tässä palanen kerrallaan mitä tulee mieleen kun
luen:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html
7.4 if, if-else, if else-if else Statements
The if-else class of statements should have the following form:
if (condition) {
statements;
}
Tuolla Ilkan käsikirjoituksessa on if(condition) {
Eli olen yrittänyt opettaa aina että muoto
x( on metodin kutsu
ja muoto
x ( on jokin kielen rakenne (if, for, whhile jne..)
Mielelläni koetan pitää epäyhtälöt samoinpäin,
eli if ( 0 < x && x < 5 ) {...
jolloin epäyhtälö voidaan tulkita graafisesti:
-----0---x----5------
Sitten mielestäni hieman sanonta "käyttäjä ei koskaan kutsu
muodostajaa" puree itseään nilkkaan.
Mitä sitten kun oppilas joskus näkee muodon:
Luokka olio = new Luokka(); ???
Ja kun tuota muodostajan kutsua tuossa BlueJ ympäristössä
ei aluksi näe, niin minusta oppilaalle hämärtyy se että
missäs ne oliot todella syntyvät. Meillä työkaluna
on usein käyetty JBuilderiä ja opiskelijat rupavat luulemaan
että JBuilder on Java.
Samaa pelkään tässä lähestymistavassa. Erityisesti kun
esimerkkejä ei voi edes ajaa muualla kuin BlueJ:ssä.
Ja metodikutsujen alkuvaiheessa ei kovin hyvin tule esille
misää metodeja kutsutaan kun niitä käynistetään BlueJ:n
ympäristöstä.
Ensimmäisillä vilkuiluilla en ole ollenkaan varma
saavutetaanko pääohjelman pois jättämisellä niin
suurta etua kuin sillä haetaan.
Sitten vielä yksi näkökohta. Itse koetan että meillä
opetetaan OHJELMOINTIA ja käytetty kieli on vain yksi
työkalu muiden joukossa. Eli pidän tärkeänä että kaiken
mitä opetan, voi siirtää myös muihin kieliin niin pitkälle
kuin mahdollista. Ei saa luulla että Javan jälkeen
kun menee kirjoittamaan PHP:tä, niin saisi unohtaa
aliohjelmat ja parametrin välityksen.
Liika pelkkä Javan piirteiden korostaminen voi johtaa
siihen, että opittu asia nivotaan liityvän vain Javaan
ja unohdetaan heti kun kieli vaihtuu.
(Huom, en ole vielä tarpeeksi pitkällä tietääkseni
onko tässä teoksessa sorruttu siihen.)
Itse en ole kokenut mitään ongelmaa pääohjelman esittämisessä
ja ainakin siirtyminen Java => C++ (tietty osajoukko)
on helppohkoa.
Vesa
Vesa Lappalainen
> Olen viimeiset viikot kirjoittanut Java-ohjelmoinnin perusoppikirjaa, ja nyt
Nyt sanoisin että on jos syntiin sorruttu:
// Olion sisÄaltÄamÄat jÄasenmuuttujat.
protected int i, j, t, m, s;
// Olion sisÄaltÄamÄat metodit.
public void tulostaLaatikko(int r, int s, char c) {
for(i = 0; i < r; i = i + 1) {
for(j = 0; j < s; j = j + 1) {
System.out.print(c);
}
System.out.println(""); // rivinvaihto
}
}
Teksti on pääosin hyvän tuntuista, mutta esimerkkejä
vaivaa minusta tietty päämäärättömyys.
Ensin ei selvästi aseteta jotakin ongelmaa joka haluataan
ratkaista ja sitten kieltä käytetään tähän välineenä.
Ja tässä yhteydessä saattaa tulla esille jokin
"uusi" kielen ominaisuus. (En väitä että itse
osaan hoitaa asiaa sen paremmin, mutta nyt kun
lukee toisen tekstiä, niin tämän vaan huomaan niin
konkreettisesti.)
Kielen ominasuuksia tavallaan esitelleen niiden itsensä
vuoksi, ei siten että lukija olisi johdateltu
"itse keksimään" esiteltävän rakenteen tarpeellisuus.
public void simuloiKelloa() {
for(t = 1; t < 13; t = t + 1) {
for(m = 0; m < 60; m = m + 1) {
for(s = 0; s < 60; s = s + 1) {
System.out.print(t + ":");
if(m < 10) { System.out.print("0"); }
System.out.print(m + ":");
if(s < 10) { System.out.print("0"); }
System.out.println(s);
}
}
}
}
Kannattaisko tämän seuraksi esittää perinteinen
"matkamittariversio":
s = s + 1;
if ( s >= 60 ) {
s = 0;
m = m + 1;
}
Eikä Javassa ole helpompaa tapaa sanoa että
s = 3;
fmt(s,2) => "03"
:-)
Vesa
Lauri Alanko
> (153 sivua, 880 kilotavua). Kommentteja ja parannusehdotuksia otetaan
> mielihyvin vastaan.
Okei.
Kirjan perusasetelma tuntuu aika oudolta. Onko tämän todellakin
tarkoitus olla johdatus ohjelmointiin? Koko teoksen rakenne näyttää
perustuvan Java-kielen rakenteeseen, eikä _ohjelmoinnin_ käsitteisiin.
Kunkin luvun idiksenä tuntuu olevan, että ensin esitellään jokin kielen
ominaisuus, ja sitten kerrotaan, mihin sitä voi käyttää. Alaotsikot
kuvastavat tätä lähestymistapaa hyvin. "Miten while-toistorakenne
toimii?" on kysymys, joka sopii paremmin hakuteoksiin.
Minusta ainakin ohjelmointikirjan täytyisi lähteä ohjelmoinnin
käsitteistä ja tarpeista, ja kielten ominaisuuksia voidaan esitellä
ratkaisuina näihin tarpeisiin vasta, kun tiedetään, mitä ne ovat.
Otetaan esimerkkinä vaikka rekursio. Kirjassasi se esitellään kovin
abstraktilla tasolla ja teknisesti, ja vasta myöhemmin tule muutama
maininta siitä, mihin sitä oikein tarvitaan. Tämä kuulostaa kovin
epämotivoivalta lähestymistavalta: koko kieli on lista erilaisten
ominaisuuksien nimiä, joista pitää päntätä, miten ne oikein toimivat, ja
mitä käyttöä kullakin oikein on.
(Vertailun vuoksi esim. HTDP:ssä on ihan eri lähestymistapa
<http://www.htdp.org/2002-09-22/Book/curriculum-Z-H-13.html#%_sec_9.3>:
esitellään ensin ongelma, sitten pohditaan, miten se ratkaistaan, ja
lopuksi vain mainitaan, että tätä ratkaisutyyliä kutsutaan rekursioksi.
Tämä on mielestäni paljon järkevämpi tapa esittää asia.)
Kirjassa käytetään aika arveluttavaa kieltä: "appletit", "assertiot",
"evaluoida". Alan kielenkäyttö on jo muutenkin tarpeeksi pahaa
finglish-jargonia. Soisi edes oppikirjojen tekevän osansa tilanteen
parantamiseksi. Myös muita kielioppivirheitä löytyy: "mikä" kun pitäisi
olla "joka" (s. 13).
Kehitysympäristöriippuvuutta muut ovatkin jo arvostelleet. En ihan
suoralta kädeltä sitä teilaisi, mutta siitä on parempi olla _todella_
paljon pedagogista hyötyä. En tunne BlueJ:tä, mutta teksti ei ainakaan
puhu mistään kovin kehittyneistä ominaisuuksista (esim. askelluksesta).
Johdannossa rehostellaan "kokonaan oliopohjaisella" lähestymistavalla ja
imperatiivisen [sic, po. proseduraalisen?] ohjelmoinnin "historian
painolastin" karistamisesta. Siitä huolimatta luku 2 on aivan
perinteisten proseduraalisten kontrollirakenteiden esittelyä, ainoastaan
sillä erolla että paikallisten muuttujien sijasta käsitellään olion
kenttiä. Ja minkäs teet, ei Javassa kontrollirakenteita ja muita
epäoliomaisuuksia voi välttääkään.
Jos tosiaan tarkoitus on painottua puhtaaseen olio-ohjelmointiin, niin
Smalltalk olisi varmaan ollut parempi valinta kieleksi. Smalltalk-
ympäristöissä on usein myös erittäin hyvät interaktiiviset
kehitysmahdollisuudet.
Johdannon "opettajalle"-osuus sisältää lähinnä subjektiivista paasausta.
Oppikirja ei todellakaan ole oikea paikka sellaiselle: _opettaja_
valitsee kurssille sellaisen kirjan, jonka katsoo omien näkemystensä
mukaan hyväksi. Valituksi tulemista ei todellakaan edistä se, jos
_kirja_ yrittää esittää tietävänsä opettajaa paremmin, mikä on tärkeää
ja mikä ei.
Varsinainen teksti alkaa suoraan olioista eikä millään tavoin yritä
selittää, mistä ohjelmoinnista on ylipäänsä kyse. Ehkä tämä on tietoinen
valinta, mutta silloin ainakaan tätä ei voi pitää ohjelmoinnin
oppikirjana.
Tehtävä 1 on _aivan_ hämärä: "mallinna nakkikiska olioksi". Minäkään en
pystyisi siihen annetuilla tiedoilla. Minkälaisesta järjestelmästä on
kyse? Jos tarkoitus on luoda "virtuaalinen Helsinki" 3D-grafiikalla,
niin tällöin painotettaisiin nakkikiskan geometrisia ja visuaalisia
ominaisuuksia. Jossain snägäriketjun taloushallinto-ohjelmassa
kiinnostaisivat lähinnä snägärin tuotto ja kustannukset. Tappelupelissä
olennaista olisi lähinnä, kuinka monta aggressiivista örveltäjää
snägärin luona kohtaa. Jne.
1.1.4:ssä puhutaan syntaksivirheistä ja loogisista virheistä, mutta ei
mitään tyyppivirheistä. Muutenkaan tyypeistä ei puhuta juuri mitään,
vaikka Javassa erityisesti olisi tärkeää tehdä selville, mitä ovat
staattiset tyypit ja olioiden luokat ja mikä näiden ero on. Usein tämä
jää ihmisille hämäräksi, ja sitten ihmetellään, miksi vain
parametrityypin mukaan ylikuormitettua metodia kutsuttaessa ei
ajonaikaisesti valitakaan parhaiten sopivaa metodia argumentin
ajoaikaisen luokan mukaan.
1.1.5:ssä on lisää subjektiivista paasausta, tällä kertaa
käyttöliittymistä. Jos tekstipohjainen tiedonvälitys on "auttamattomasti
vanhentunutta", niin ehkä minunkaan ei tässä pitäisi kirjoittaa mitään,
vaan esittää näkemyksini piirtämällä tai pantomiimina.
1.3.1:ssä ja muuallakin sanotaan, että metodeja kutsuttaessa niille
annetaan "parametreja", kun puhutaan argumenteista. Parametrien ja
argumenttien ero hallitaan yleisestikin kai aika huonosti, joten
oppikirjassa sitä olisi syytä painottaa.
Pidemmälle en tässä jaksa kommentoida. Yleisvaikutelmaksi jää, että niin
kirjan rakenteesta, esitystavasta kuin asiasisällöstäkään on hankala
löytää sellaisia ansioita, joiden perusteella sitä voisi suositella.
Lauri Alanko
l...@iki.fi
Jouko Holopainen
Koodiohjeen <http://java.sun.com/docs/codeconv/index.html> seuraaminen
on _aloittelijan_ kirjassa imo tärkeää.
Ei missään tapauksessa saa antaa kuvaa aloittelijalle että "koodaa
miten sattuu - paskaakos sillä on väliä".
Tähän syyllistyy aivan liian moni kirja. Yleensähän homma menee näin:
1. Kirjassa kerrotaan, että kommentointi ja koodiohjesäännön
seuraaminen on tärkeää.
2. Y.o. ohje unohdetaan sivulla N+1, jossa N == edellinen kommentti
(yleensä N == 3)
3. Joka ikinen kirjassa oleva esimerkki paskat välittää kummastakaan,
mukamas "tilan säästämiseksi".
4. Kirjan mukana rompulla tulevat esimerkit on koodattu käyttäen
klassista "juosten kustu" menetelmää.
Olen skeptinen kohdasta "3", vaikka ymmärränkin _todellisen_ kirjan
tapauksessa tilaongelmat. Sähköisen kirjan kanssa en ymmärrä. Kohtaa
"4" en kertakaikkiaan voi ymmärtää enkä hyväksyä.
Pikemminkin pitäisi laittaa linkki softaan, joka _tarkistaa_
koodaustyylin ja ja JavaDocit. Ehkäpä tuollainen ilmainen, toimiva
löytyy jostain, jolloin sen voi pistää rompulle mukaan.
Tässä yksi, joka _EI_, valitettavasti, toimi:
<http://checkstyle.sourceforge.net/> ainakaan ilman säätämistä (ja
jonka dokumentaatio on perseestä).
BTW: Itse en tykkää noista formattereista (jotka "korjaa"), koska ne
ei toimi. _Aina_ löytyy hyvä syy erkaantua "säännöstä" siisteyden tms
takia, _AINA_.
Ilkka Kokkarinen
"Niko Kiirala" <niko...@mbnet.fi> wrote in message
news:bcc1b6$5v9$1...@phys-news1.kolumbus.fi...
> Yksinkertaisemmin voisi kertoa esim. että "=" tarkoittaa Javassa "saa
> arvon" eikä "on yhtä suuri kuin" (joka taasen on "==")
Totta. Yritän kirjoittaa tuon kohdan uudestaan.
Ilkka Kokkarinen
Ilkka Kokkarinen
"Vesa Lappalainen" <ve...@tarzan.it.jyu.fi> wrote in message
news:bccnrd$q9a$1...@mordred.cc.jyu.fi...
> Ja ilman muuta JavaDoc peliin jo heti ekoista kommenteista
> alkaen. Myöhemmin voi selittää sen merkitystä.
Totta. Tämä korjaus onkin seuraavana työlistalla, kun löydän jostain
riittävästi energiaa JavaDoc-kommenttien kirjoittamiseen jokaiseen
esimerkkiohjelmaan.
> Ohjelmoinnissa ei minun kokemuksen mukaan ole mitään
> pahempaa kuin globaalit muuttujat. Kuinka vältetään
> vaara ettei luokista kasva liian isoja ja
> attribuuteja ei sitten käytetä kuin globaaleja
> muuttujia? Voi kun näisä "peruskielissä"
> voisi sanoa että tätä attribuuttia saa muuttaa
> vain tämä ja tämä metodi ja käyttää vain tämä ja tämä
> metodi.
Odotamme innokkaasti seuraavan sukupolven ohjelmointikieliä.
Ilkka Kokkarinen
Ilkka Kokkarinen
> Mielelläni koetan pitää epäyhtälöt samoinpäin,
> eli if ( 0 < x && x < 5 ) {...
Tuo on hyvä neuvo, jonka otan ilman muuta huomioon.
> Sitten mielestäni hieman sanonta "käyttäjä ei koskaan kutsu
> muodostajaa" puree itseään nilkkaan.
Ohjelmassa ei koskaan ole millekään oliolle metodikutsua a.Luokka();
mutta totta, tuon voisi muotoilla uudelleen.
> Mitä sitten kun oppilas joskus näkee muodon:
>
> Luokka olio = new Luokka(); ???
new pyytää järjestelmää rakentamaan olion, ja oliota rakennettaessa
järjestelmä kutsuu automaattisesti sen rakentajaa.
> Samaa pelkään tässä lähestymistavassa. Erityisesti kun
> esimerkkejä ei voi edes ajaa muualla kuin BlueJ:ssä.
Voihan niitä ajaa, jos kirjoittaa public static void main() -pääohjelman,
joka rakentaa olioita ja kutsuu niiden metodeita. Mutta tämä on edelleenkin
aloittelijalle mielestäni aivan liian iso askel.
> Sitten vielä yksi näkökohta. Itse koetan että meillä
> opetetaan OHJELMOINTIA ja käytetty kieli on vain yksi
> työkalu muiden joukossa. Eli pidän tärkeänä että kaiken
> mitä opetan, voi siirtää myös muihin kieliin niin pitkälle
> kuin mahdollista. Ei saa luulla että Javan jälkeen
> kun menee kirjoittamaan PHP:tä, niin saisi unohtaa
> aliohjelmat ja parametrin välityksen.
Minusta on puolestaan ajan myötä kasvanut hyvin pessimistinen sen suhteen,
miten korkealentoisia abstrakteja asioita aloittelijat on mahdollista saada
oikeasti ymmärtämään.
> Itse en ole kokenut mitään ongelmaa pääohjelman esittämisessä
Minä olen. Monet aloittelijat eivät nimittäin tuollaisessa järjestelmässä
kokemukseni mukaan opi kunnolla edes sitä, mitä eroa on luokalla ja oliolla.
BlueJ-tyyppisessä opetuksessa tämä on mahdotonta. Luokkien ja
olio-ohjelmoinnin opettaminen "uusien tyyppien määrittelemisenä"
proseduraalisessa ohjelmoinnissa tuottaa monille opiskelijoille vaikeuksia.
Ilkka Kokkarinen
Ilkka Kokkarinen
> Nyt sanoisin että on jos syntiin sorruttu:
Vain siksi, että jäsenmuuttujan ja lokaalin muuttujan ero on aloittelijoille
ihan oikeasti vaikea, saati sitten luokkamuuttujan. Kirjan luvussa 6
esitellään kaikki oikeat rakenteet vasta sitten, kun opiskelija on ensin
saatu tajuamaan yksinkertaisemmat asiat. Kun opiskelija on ensin saavuttanut
tietyn pohjan, voi kaikki Java-kielen loput asiat selittää vaikka parissa
tunnissa, mutta niiden esitteleminen tipoittain vain hämää.
> Kielen ominasuuksia tavallaan esitelleen niiden itsensä
> vuoksi, ei siten että lukija olisi johdateltu
> "itse keksimään" esiteltävän rakenteen tarpeellisuus.
Totta, ainoastaan ehtolauseita esittelevä ParempiAutomaatti on onnistunut
tässä mielestäni riittävän hyvin. Mutta on vaikeaa keksiä riittävän lyhyitä
esimerkkejä, jotka olisivat järkeviä.
> public void simuloiKelloa() {
on tuossa sen takia, että ihan oikeasti huomasin opetustyössäni
konkreettisella tavalla, miten valtavasti kello auttaa sisäkkäisten
silmukoiden idean oppimisessa.
> Eikä Javassa ole helpompaa tapaa sanoa että
> s = 3;
> fmt(s,2) => "03"
Totta, mutta mitä vähemmän kielessä on kompleksisuutta, sen parempi. Jos
jokin asia voidaan tehdä olemassaolevalla koneistolla, en halua esitellä sen
rinnalla uutta koneistoa. Nollamerkin lisääminen alle kymmenen suuruisiin
arvoihin on sitä paitsi samalla esimerkki ehtolauseen käytöstä.
Ilkka Kokkarinen
Ilkka Kokkarinen
"Lauri Alanko" <l...@iki.fi> wrote in message news:bcd35c$9l7$1...@la.iki.fi...
> Kunkin luvun idiksenä tuntuu olevan, että ensin esitellään jokin kielen
> ominaisuus, ja sitten kerrotaan, mihin sitä voi käyttää. Alaotsikot
> kuvastavat tätä lähestymistapaa hyvin. "Miten while-toistorakenne
> toimii?" on kysymys, joka sopii paremmin hakuteoksiin.
Totta. Alaotsikot ovat perua alkuvaiheista, kun mielikuvani kirjasta oli
hyvin erilainen kuin mitä se on nyt, ja aionkin muuttaa kysymysmuotoiset
otsikot tavallisiksi otsikoiksi kirjan seuraavaan versioon.
> Kirjassa käytetään aika arveluttavaa kieltä: "appletit", "assertiot",
> "evaluoida". Alan kielenkäyttö on jo muutenkin tarpeeksi pahaa
> finglish-jargonia. Soisi edes oppikirjojen tekevän osansa tilanteen
> parantamiseksi.
Totta. Muutin käsikirjoituksen kieliasun eilen kokonaan suomenkieliseksi,
joskaan en vielä keksinyt assertiolle hyvää suomennosta.
> Myös muita kielioppivirheitä löytyy:
Aivan varmasti. Vanhan kokemuksen mukaan pari per sivu siinä vaiheessa, kun
kirja lähtee kustannustoimittajalle oikoluettavaksi.
> Kehitysympäristöriippuvuutta muut ovatkin jo arvostelleet. En ihan
> suoralta kädeltä sitä teilaisi, mutta siitä on parempi olla _todella_
> paljon pedagogista hyötyä. En tunne BlueJ:tä, mutta teksti ei ainakaan
> puhu mistään kovin kehittyneistä ominaisuuksista (esim. askelluksesta).
Oman kokemukseni mukaan siitä on valtavasti pedagogista hyötyä, että olioita
voi luoda ja käsitellä interaktiivisesti. BlueJ:ssa on myös sisäänrakennettu
debuggeri, jolla voi askeltaa. Ja sitähän voisi itse asiassa käyttää
tekstissä, jumaliste. Loistavaa.
> Johdannossa rehostellaan "kokonaan oliopohjaisella" lähestymistavalla ja
> imperatiivisen [sic, po. proseduraalisen?]
Jep.
> Ja minkäs teet, ei Javassa kontrollirakenteita ja muita
> epäoliomaisuuksia voi välttääkään.
Totta.
> Jos tosiaan tarkoitus on painottua puhtaaseen olio-ohjelmointiin, niin
> Smalltalk olisi varmaan ollut parempi valinta kieleksi.
Totta, mutta kirjalla täytyy olla markkinatkin.
> Varsinainen teksti alkaa suoraan olioista eikä millään tavoin yritä
> selittää, mistä ohjelmoinnista on ylipäänsä kyse. Ehkä tämä on tietoinen
> valinta, mutta silloin ainakaan tätä ei voi pitää ohjelmoinnin
> oppikirjana.
Tuo on puute, joka on tarkoitus korjata myöhemmin: en keksinyt, miten
ohjelmoinnin käsitteen voisi liittää alussa esiteltäviin luokkiin ja
olioihin.
> Tehtävä 1 on _aivan_ hämärä: "mallinna nakkikiska olioksi".
Totta, syytä korjata.
> 1.1.4:ssä puhutaan syntaksivirheistä ja loogisista virheistä, mutta ei
> mitään tyyppivirheistä.
Liian aikaista tässä vaiheessa, mutta myöhempänä olisi tietysti hyvä
selittää, miksi kielessä on tyypit. (Ja miksi kielessä on ylipäänsä
syntaksi.)
> 1.1.5:ssä on lisää subjektiivista paasausta, tällä kertaa
> käyttöliittymistä. Jos tekstipohjainen tiedonvälitys on "auttamattomasti
> vanhentunutta",
Konsoliohjelmat ovat auttamattomasti vanhentuneita.
> Pidemmälle en tässä jaksa kommentoida. Yleisvaikutelmaksi jää, että niin
> kirjan rakenteesta, esitystavasta kuin asiasisällöstäkään on hankala
> löytää sellaisia ansioita, joiden perusteella sitä voisi suositella.
Hyvää kritiikkiä jonka otan vastaan, joten toivottavasti kirjan seuraava
versio on sitten parempi.
Ilkka Kokkarinen
Sampo Smolander
> Odotamme innokkaasti seuraavan sukupolven ohjelmointikieliä.
Vähän niin kuin http://paulgraham.com/hundred.html ?
Mikael Mätäsaho"
> Konsoliohjelmat ovat auttamattomasti vanhentuneita.
>
Tähän ei kyllä voi mitenkään yhtyä. Mielestäni kummallakin ohjelman
muodolla on oma paikkansa. Kuten lainauksessa johon tässä vastaat
sanotaan, tällainen subjektiivisten näkemysten tuputtaminen lukijalle tuo
ainoastaan kirjoittasta kuvan 'älkää tehkö niin kuin minä teen vaan niin
kuin minä sanon'.
--
Mikael Mätäsaho
Vesa Lappalainen
>> Nyt sanoisin että on jos syntiin sorruttu:
> Vain siksi, että jäsenmuuttujan ja lokaalin muuttujan ero on aloittelijoille
> ihan oikeasti vaikea, saati sitten luokkamuuttujan. Kirjan luvussa 6
> esitellään kaikki oikeat rakenteet vasta sitten, kun opiskelija on ensin
Nyt on supervahvasti eri mieltä ja uskon että moni muukin on.
Maailmassa ei ole mitään syytä käyttää attribuutti asilloin
kun lokaali muuttuja on ainoa oikea ratkaisu.
Eli tässä tulluun juuri siihen, mitä vaoittelin
aikaisemmassa postissa että liika olion korostaminen johtaa
siihen että kaikki tehdään attribuuteilla ja sorrutaan
vanahn ajan ohjelmoinnin globaalien muuttujienb ansaan.
Ihmettelen miten joku voi saada ongelmia lokaalien
muutiijien ja parametrien välillä. Kyllä ne erot
pystyy opettamaan.
Muista että vielä vaikeampi sinun on sitten opettaa ne
irti tuosta tavasta että silmukkamuuttuja ei saakaan
olla attribuuttin kun kerren kirjasta löytyy esimerkki
jossa näin on. Lisäksi aikaisemmin on sanottu
että attribuuteille kuvaavat nimet. Ja i ei ole
hyvä attribuutin nimi missään tapauksessa.
Vesa
Heikki Orsila
> Konsoliohjelmat ovat auttamattomasti vanhentuneita.
Eivätkö ne ole riittävän hyödyllisiä?
--
Heikki Orsila There has yet to be any innovation, new
heikki...@ee.tut.fi features or new capabilities out of the
http://ee.tut.fi/~heikki Linux platform. - Steve Ballmer of Microsoft
Otto J. Makela
> "Lauri Alanko" <l...@iki.fi> writes:
> > 1.1.5:ssä on lisää subjektiivista paasausta, tällä kertaa
> > käyttöliittymistä. Jos tekstipohjainen tiedonvälitys on
> > "auttamattomasti vanhentunutta",
>
> Konsoliohjelmat ovat auttamattomasti vanhentuneita.
Mikäli näin on, herää kysymys miksi java-ohjelmat kirjoitetaan
tekstipohjaisesti, eikä vaan heilutella hiirtä ja liikutella ikoneita?
GUIs normally make it simple to accomplish simple actions and
impossible to accomplish complex actions.
-- Doug Gwyn, 1991-06-22 in comp.unix.wizards
--
/* * * Otto J. Makela <o...@iki.fi> * * * * * * * * * * * * * * * */
/* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */
/* Mail: Mechelininkatu 26 B 27, FIN-00100 Helsinki, FINLAND */
/* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */
Niko Kiirala
>
> Konsoliohjelmat ovat auttamattomasti vanhentuneita.
Näin minäkin uskoin ennen kuin siirryin käyttämään Linuxia.
Windows-puolella konsoliohjelmat olivat aivan turhia, johtuen osin
kunnollisen komentotulkin puutteesta.
Linuxissa on toisin: kehittyneen komentotulkin ansiosta konsoliohjelmien
käyttö on nopeaa (tiedostonimen automaattinen täydennys yms.) ja
konsoliohjelmien tuloksen putkittaminen toiselle ohjelmalle mahdollistaa
hyvinkin monimutkaisia operaatioita.
Ja todellakin haluaisin nähdä sinun etäkäyttävän graafista ohjelmaa esim.
gprs-konnun yli :D
--
Niko Kiirala
Heikki Orsila
> [snip] Linuxissa on toisin [snip]
<nipotusta> Unix shellit yleensä. </nipotusta> :)
Vesa Lappalainen
>> Eikä Javassa ole helpompaa tapaa sanoa että
>> s = 3;
>> fmt(s,2) => "03"
> Totta, mutta mitä vähemmän kielessä on kompleksisuutta, sen parempi. Jos
> jokin asia voidaan tehdä olemassaolevalla koneistolla, en halua esitellä sen
> rinnalla uutta koneistoa. Nollamerkin lisääminen alle kymmenen suuruisiin
> arvoihin on sitä paitsi samalla esimerkki ehtolauseen käytöstä.
Yhdesä erikoistapauksessa. Entäpä jos halutaan täyttää
4 tai 10:llä etunollalla? Silloin tuo if-lauseeseen
perustuva ratkaisu ei enää toimikkaan ja yleisempi
abstraktio on parempi. Tämä on juuri sitä, mitä
yritän ohjelointina opettaa. Se mikä yhdessä tilanteessa
näyttää ilmeiseltä, ei olekkaan "oikea" ratkaisu
saman ongelman yleisempään muotoon. Ja juuri yleistäminen
on se vaikeasti opetattava asia, ei kielen syntaksi
tai muuttujien näkyvyysalueet.
Ei tietenkään aina pidä sortua etsimään ongelman yleisitä
ratkaisua, muttajos yleistämistä on harjoiteltu,
niin kohtuulisen yleisen ratkaisun löytyminen on
silloin jo selkäytimessä valmiina.
Tuossakin muistaakseni etunolla pitää lisätä
min ja sek, joten siinä olisi jo paikka jonkinlaisen
aliohjhelman esittämiseen. Jos ei heti tuossa versiossa,
niin ainakin voisi todeta tilanteen ja vähintään
harjoitustehtäväksi jättää tuollaisen fmt -tms.
metodin tekeminen.
Minusta nimenomaan ohjelmoinin opetus unohtuu "lähes"
kaikista "oppikirjoista". Liian helposti sorrutaan
syntaksin opettamiseen. Se ei oikeasti ole ihmisille
vaiketata. Sama pätee tietysty lukion matematiikan
opetukseen. Helposti sorrutaan mekaanisen integoinnin
ja derivoinnin opetukseen koska "opin" perillemenoa
on helppo testata. Ja helppo antaa tehtäviä.
Myöhemmin kirjassa mennään graafisiin käyttöliittymiin
yms. Kyllä jos joku on vaikeaa, niin Javan tapahtuman
käsittelymalli. Jos tuon saat aloittelijan ymmärtämään
niin olet tosi guru :-)
Jos et, vaan tyydyt sanomaan että näin se vain on, niin
silloin vetäisin jo muutamassa muussakin kohdassa
mutkia suoraksi ja välttäisin huonoja tai jopa
virheellisiä esimerkkejä sillä varjolla, "ettei
asian oikeata muotoilua voi vielä ymmärtää".
Muistakaa että nimenomaan matemaatikot sortuvat usein
liian kauniisiin rakenteisiin joissa kaikki pitää
olla ennalta määriteltyä ja tunnettu
(sanoo aikanaan matematiikasta väitellyt :-).
Ihmiset kestävät kyllä pieniä epämääräisyyksiä
jos ne vain vievät asiaa eteenpäin.
Vesa
Matti Rintala
> Nyt on supervahvasti eri mieltä ja uskon että moni muukin on.
>
> Maailmassa ei ole mitään syytä käyttää attribuutti asilloin
> kun lokaali muuttuja on ainoa oikea ratkaisu.
Tässä olen kyllä Vesan kanssa 100 % samaa mieltä. Jos aikomus on opettaa
alkeisohjelmointia sillä taustaoletuksella, että edes osa opiskelijoista
jatkaa pitemmällekin, niin missään tapauksessa kielen syntaksia ei pidä
"yksinkertaistaa" sotkemalla keskenään erilaisia semanttisia elementtejä.
Muuttujien erilaiset elinkaaret ja niiden hallinta (globaalit muuttujat,
jäsenmuuttujat, parametrit ja paikalliset muuttujat jne.) on oleellinen
osa ohjelmointia. Vaikka olion jäsenmuuttujia voikin käyttää ohjelmassa
paikallisten muuttujien sijaan, niin näin ei missään tapauksessa pidä
tehdä, koska jäsenmuuttujat "merkitys" on pitää muistissa olion tilaan
kuuluvia tietoja, kun taas paikallinen muuttuja on väliaikainen tiedon
talletuspaikka.
Samalla tavoin vastustan vähän sitä, että heti ohjelmoinnin alkeissa
kaikkiin pieniinkin ohjelmiin upotetaan mahdollisimman paljon luokkia (en
tässä nyt puhu Ilkan kirjasta). Tällöin tuloksena on helposti luokkia,
jotka ovat aivan liian pieniä, jotta niillä olisi mielekäs vastuualue jota
kannattaisi kapseloida. Ja jos tällaisista luokista sitten vielä
instantioidaan ohjelmassa vain yksi olio, niin koko luokan ja olion ero
hämärtyy kieltä oppivalle helposti.
Oma näkemykseni alkaa vähitellen olla, että pedagogiselta ja
psykologiselta kannalta ohjelmointikieliä (varsinkin Javan ja C++:n
tapaisia "evoluution" myötä kehittyneitä kieliä) tulisi opettaa samaan
tapaan kuin luonnollisia kieliä -- fraaseina. Ei jokaisen rakenteen
periatteeita tarvitse välttämättä opettaa pohjamutia myöten, jotta ko.
rakennetta osaisi käyttää ensimmäisen kerran, samaan tapaan kuin englantia
opetellessa sanontoja voi opetella osaamatta täydellisesti niihin
liittyvää kielioppia. Sama korostuu nykyisten ohjelmointikielten
kirjastoissa, joista löytyy paljon tehokkaita tietorakenteita, algoritmeja
ja muita työkaluja, joita voi käyttää ilman, että osaisi itse koodata ko.
asiat. Ja muutenkin kaikissa ohjelmointikielissä on joka tapauksessa
"fraaseja", eli asioita, jotka ko. kielessä on *tapana* tehdä tietyllä
tavalla, vaikka muitakin tapoja olisi.
Uskoni tämän tyyliseen ohjelmoinnin opetukseen vahvistui, kun luin Andrew
Koenigin ja Barbara Moon kirjan "Accelerated C++", joka opettaa
ohjelmoinnin alkeet C++:lla, mutta varsin perinteisestä poikkeavassa
järjestyksessä. Jo heti alusta alkaen kirja käyttää varsin korkeankin
tasoisia abstraktioita (kuten STL:ää), ja ko. asioista paljastetaan lisää
syvemmälle meneviä yksityiskohtia sitä mukaa, kun opetus etenee.
(Erityisesti mieleen jäi, kun kirja opettaa vasta puolenvälin jälkeen
C++:n taulukkotyypit ja osoitintyypit sanomalla, että taulukkotyyppi on
vähän niin kuin std::vector, mutta rajoittuneempi ja että C++:n
osoitintyyppi on yksinkertaisesti vain hajasaanti-iteraattori taulukkoon :) )
--
------------- Matti Rintala ------------ matti....@tut.fi ------------
If you do not climb you will not fall. This is true. But is it that bad to
fail, that hard to fall? Sometimes you wake, and sometimes, yes, you die.
But there is a third alternative. - from Fear of Falling by Neil Gaiman
Vesa Lappalainen
> on tuossa sen takia, että ihan oikeasti huomasin opetustyössäni
> konkreettisella tavalla, miten valtavasti kello auttaa sisäkkäisten
> silmukoiden idean oppimisessa.
Jatkampa tästä vielä ohjelmoinnin kannalta
for(t = 1; t < 13; t = t + 1) {
for(m = 0; m < 60; m = m + 1) {
for(s = 0; s < 60; s = s + 1) {
Itse asiassa tarvitsen sisäkkäisiä silmukoita erittäin harvoin.
Yleensä tarve häviää siihen, että sisäsilmukasta tehdään
oma aliohjelma. Esim. matriisin kertolaskukin voidaan
esittää vektroreiden sisätuloina, jolloin sisäkkäisten
silmukoiden määrä tuossakin vähenee (tottakait kauneus
on ristiriidassa nopeuden kanssa).
Sitten mitenkä tuon kello-esimerkin omaksunut tekee kun pitää
vaikka käydä läpi kaikki n-kirjaimiset sanat?
Yritää saada silmukkaa jossa n on sisäkkäisyyksien
lukumäärä. On muuten taidettu kysyä tälläkin palstalla?
Eli voisi hyvin ottaa tuon esimerkin jälkeen tilanteen
jossa pitää tulostaa vaikka kaikki 3-kirjaimiset
sanat (olkoot vaikka vain vokaalit kirjaimina).
Tällöin vastaus on varmaan suora kopio tuosta
esimerkistä. Sitten pyydetään tulostamaan
10-kirjaimiset sanat.
Yksi minun ohjeistani on:
"Kun käyttää copy-pastea, niin silloin pitää sattua
sydämeen."
Ja sitten pyydetään tulostamaan n-kirjaimiset sanat.
8-kuningattaren ongelmakin ratkeaa nätistä samalla
tavalla ilman rekursiota.
Mulla on klassikkona vieläkin hyllyssä kun erään
opiskelijan piti tehdä ohjelma joka laskee n:n asteen
Tshebysevin polynomeja (en edes enää muista mitä ne ovat :-)
Hän päätti että n on max 10 ja kirjoitti 10 if lausetta
jossa jokaisen alla oli aukilaskettuna n=1, n=2, n=3,..
polynomit. Ei tarvittu silmukoita :-)
Vastaus on muistaakseni 3-4 sivua Fortran-koodia.
Ja sitten vielä tuosta i = i +1;
Kukaan opiskelijani ei ole millään tavalla kyseenalaistanut
i++ merkintää silloin kun sitä käytetään yksinään.
Eri asia että n = x[i++] voi olla hämärä.
Eli jos jokainen joka kirjoittaa Javan tai C:n for-silmukan
käyttää muotoa i++ (tai paremmin ++i, onko muuten Javassa
väliä kumpaa jos on yksinään?), niin mitä tekee opiskelija
joka ei ole nähnyt tuota muotoa? Kielissä on idiomeja
joita käytetään. Ei niitä turhaan kannata välttää.
Sudenkuoppia kyllä. Eli minäkään en kannata noiden
operaattoreiden käyttöä monimutkaisemmissa lauseissa.
Toisaalta nimenomaan joku alan guru on erityisesti
kyseenalaistanut merkinnän
i = i + 1;
koska se näyttää matemaattisesti mielettömältä ( 0 = 1 ).
No totta kait tuokin muoto pitää opettaa, se kuuluu
näihin kieliin. Siksi muuten tykkään paljon enemmän
Pascalin
i := i + 1;
koska se ei näytä matemaattiselta yhtäsuuruudelta,
mutta mitäpä tuosta.
Vesa
Vesa Lappalainen
> ihan oikeasti vaikea, saati sitten luokkamuuttujan. Kirjan luvussa 6
> esitellään kaikki oikeat rakenteet vasta sitten, kun opiskelija on ensin
> saatu tajuamaan yksinkertaisemmat asiat. Kun opiskelija on ensin saavuttanut
> tietyn pohjan, voi kaikki Java-kielen loput asiat selittää vaikka parissa
> tunnissa, mutta niiden esitteleminen tipoittain vain hämää.
Tuosta viimeisestä lauseesta samaa mieltä. Itse en edes esittele muuta
kuin ne ominaisuudet, joita "tarinan" eteenpäinvienti tarvitsee.
Sama C++:n kanssa.
Mutta ennen lukua 6 on kyllä paljon muuta kuin "yksinkertaiset asiat":
Ilkka ei vielä vastannut siihen miksi käyttää protected attribuutteja?
Minusta tämä on sama kuin julistaisi koko maailmalle: "peri tämä
luokka ja pilaa sen toiminta!"
Luku 3: Esimerkki jossa olio viittaa saman luokan olioon ja on
suuri rekursion vaara. Tähän viitataan tehtävässäkin,
mutta vastaus jää silti antamatta. Entä lukija joka ei
osaa ratkaista tehtäviä. Hän jää luuloon että
tällainen on yleistä. Miksi tähän on jouduttu?
Hirveä pelko parametrimuuttujien ja lokaalien
muuttujien esittämisestä. Ja kun ei ole muuta käytössä
kuin attribuutit ja yksiluokka => voidaan antaa vain
esimerkki itseensä viittaavasta luokasta.
=> järjestys ei voi olla oikea?
"Kun BlueJ kysyy olioille annettavia nimiØa, anna niille nimet h1 ja h2."
Nämäkö niitä hyviä nimiä? Mun nyrkkisääntö: "Jos joudut numeroimaan
muutijien nimiä, niin silloin on käytössä väärä tietorakenne".
public void luoUusiParasKaveri(String n) {
parasKaveri = new HenkilÄo();
parasKaveri.asetaNimi(n);
}
Ei mallita varmaan parhaalla tavalla todellisuutta? Mistä asti
kaverit luovat toisiaan. => ehkä Java-esimerkki, mutta
erittäin huono ohjelmointi-esimerkki.
public void lisääRahaa(int s) {
- s on hyvä nimi?
Polymorfismi. Yksinkertainen asia? Yksinkertaisempi kuin
lokaalit muuttujat? Tärkeä kyllä, ehdottomasti.
public int kysyPainoa() {
- jos en näkisi metodin toteutusta en tietäisi mitä metodi tekee.
Luku 4: Interaktiivinen grafiikka
- yksinkertaisempaa kuin lokaalit muuttujat?
public void paint(Graphics g) {
// Seuraava rivi ottaa kÄayttÄoÄon Graphics2D-olion.
Graphics2D g2 = (Graphics2D)g;
// TehdÄaÄan piirtÄamisestÄa vÄahÄan siistimpÄaÄa.
g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
// Sitten voidaankin suorittaa piirtÄaminen.
g2.drawString("Terve, maailma!", 20, 50);
g2.drawString("MitÄa kuuluu?", 20, 150);
laskuri = laskuri + 1;
g2.drawString("Piirretty " + laskuri + " kertaa.", 20, 250);
}
Tässkäkö on nyt sitten lukijalla varmasti selvillä kaikkien
metodien kutsut. En sano ettei näin voi tehdä, mutta
osoittaa että joudut ennemmin tai myöhemmin antamaan periksi
sille, ettei lukijalle voi olla kaikki selvää ja hänän
on vain uskottava että joku toimii vaikkei ymmärrä.
Ja nyt on käytössä vielä monimutkaisempi käsite kuin
lokaalit muuttujat: Lokaali viite, joka vain muuttaa
olemassa olevan olion tyypin jotta sitä voidaan käsitellä
toisella tavalla. Mutta lokaaleja muuttujia ei ole
vielä käsitelty??? => Ne on pakko käsitellä aikaisemmin.
Grafiikka on varmasti motivoivampaa kuin tekstipohjainen
esimerkki ja silloin ihminen voi ottaa vastaan myös
enemmän asioita jos motivaatio on korkealla. Olen itsekin
miettinyt että mitä kaikkea saisi aikaan kun mielenkiinnon
saa nostettu tarpeeksi suureksi.
Onko Säilö hyvä nimi graafiselle säilölle? Vai pitäisikö
tätä korostaa, koska jossakin kirjallisuudessa säilöllä
viitataan nimenomaan esim. C++:n STL:n kaltaisiin
säilö-luokkiin.
Luku 5:
Rekursio: Onko esimerkki paras rekursiosta. Ei ainakaan
kovin yksinkertainen. Itse käytin rekursiona
ihan hakemiston läpikäyntiä. Ja sitten
hevosen hyppelyä shakkilaudalla. Sellaisia
missä selvästi lukijalle tulee pohtimien siitä,
että mistä tietää mistä kohti jatketaan edellisen
kerran jälkeen. Taisimpa piirtää jonkun
fraktaalinkin.
Mitäpä jos kertoisit että Fibonaccin luku
n saadan suoraan kaavasta ilman silmukkaakin :-)
Luku 6:
public double kuutio(double a) {
// MÄaÄaritellÄaÄan paikallinen muuttuja ja alustetaan se.
double tulos = a*a*a;
// Muuttujaa voi nyt kÄayttÄaÄa metodissa vapaasti.
return tulos;
}
Nyt vihdoin lokaali muuttuja, mutta tässä esimerkissä
se ei edes ole tarpeen...
Aikaisemmin oli monia esimerkkejä joissa se olisi
ollut välttämätön.
"Luokassa voi esimerkiksi olla kolme metodia, joiden nimi on f, mutta joista
ensimmØainen vaatii parametrikseen kokonaisluvun, toinen vaatii parametrikseen"
Matemaattista tapaa esittää. Miksi f välillä saa kokonaisluvun
ja välillä merkkijonon. Esimerkki joka on konkreettinen
ja jossa kuormittamisesta on hyötyä?
6.1.4 Mitä on oikosulkuevaluointi?
En pidä suomennoksesta! Oikosulku ei mielestäni viittaa siihen että
lähdetään pois kesken lauseen suorituksen.
(i >= 0 && i < 100 && a[i] > 0)
=>
(0 <= i && i < 100 && a[i] > 0)
tai kopa ryhmitellään:
( ( 0 <= i && i < 100 ) && a[i] > 0) // vai 0 < a[i] ???
Ja muuten muistutus siitä että 0 <= i <= 100 ei toimi
(vaikka ei Javassa mene kääntäjästä läpi, niin kohta menee C:ssä).
"6.1.5 Miten jäsenmuuttujien periytyminen estetään"
- no ensinkin kerro tilanteita joissa attribuuttien pitää oikeasti
periytyä? Ainahan ne joka tapauksessa periytyvät, mutta
missä niiden pitää oikeasti näkyvä jälkeläisluokalle?
En ole tarvinnut. Jos niiden annetaan näkyä, niin silloin
ei voida ikinä muuttaa kantaluokkaa mahdollisesti rikkomatta
jälkeläisluokkia. Eli ensin opettaisin ilman muuta
private ja sitten ainoastaan jotakin nopeuden takia
optimoitua tapausta varten kertoisin että voi sen
attribuutin saatta näkyväksikin perillisille jos on oikein
kaunis ja rohkea.
Luku 7:
Esimerkkejä eri paradigmoilla tehdyistä ohjelmista
ja siitä miten paljon vastaava ratkaisu vaatisi toisella
paradigmalla?
Täytyy panaeutua vielä huolella nyt ylihyppäämiini kohtiin.
Luvut 4 ja 6 ovat kyllä aika raskaita...
Vesa
Vesa Lappalainen
> Olen viimeiset viikot kirjoittanut Java-ohjelmoinnin perusoppikirjaa, ja nyt
Kun olen "moittinut" Ilkan esimerkkjä, niin varmaan pitäisi
heittä peliin jotakin sitten tilalle. Mutta on tosi vaikea
keksiä hyvä ja yksinkertaisia olio-esimerkkejä. Siksi
meidän pitäisi täällä yhdistää voimat ja kerätä kultakin
parhaat palat yhteiseen arkistoon.
Itse yhtenä parhaista esimerkeistäni pidän:
http://www.mit.jyu.fi/~vesal/kurssit/ohjelmointi2003/demot/tehtavat/demo5.html:
5. Suunnittele luokka Linja_auto, jossa on paikkojen lukumäärä ja vapaiden
paikkojen lukumäärä. Tee metodit tulosta sekä lisaa ja vahenna muuttamaan matkustajien
lukumäärää. Kirjoita testipääohjelma.
6. Modifioi edellistä ratkaisua siten, että luokaa LinjaAuto voi käyttää seuraavassa testiohjelmassa:
public static void main(String[] args) {
Linja_auto pikkubussi = new Linja_auto(10);
Linja_auto isobussi = new Linja_auto(45);
pikkubussi.lisaa(4); pikkubussi.tulosta();
isobussi.lisaa(30); isobussi.tulosta();
int yli = pikkubussi.lisaa(15);
isobussi.lisaa(yli);
pikkubussi.tulosta(); isobussi.tulosta();
if ( pikkubussi.getTilaa() > 0 )
System.out.println("Pieneen bussiin mahtuu!");
if ( isobussi.tilaa() )
System.out.println("Isoon bussiin mahtuu!");
}
Tuossa korostuu rajapinnan merkitys:
+1) ei ole väliä mitkä 2 attribuuttia valitaan esittämään 3:a toivottua
ominaisuutta
+2) Tuo 6. tehtävän pääohjelma on likempänä sitä ajattelua, miten
minusta luokkia ja olioita "synnytetään". Ensin niille on
"aito" tarve jossa määritellään tarvittava rajapinta
ja ominaisuudet. Sitten tuollainen toteutetaan.
+3) Luonnollinen tilanne jossa on parametrillinen muodostaja
ja parametritöntä ei saa olla olemassa.
("Kun tilaan tehtaalta linja-auton, minun on mainittava
sen paikkamäärä. Harvoin on vakiokokoisia linja-autoja).
-4) Noista tulosta-metodeista en ole ylpeä, olen alusta alkaen
lähtenyt niissä väärille teille. Varmaan kannattaa
jatkossa muuttaa niin että voi käyttää
System.out.println(pikkubussi);
(metodin lisaa nimi voisi olla kuvaavampi, eism. lisaa_matkustajia).
Ja tuossa minusta kyllä "kutsutaan" muodostajaa, ei sitä
automaattisesti kutsuta.
Tästä seuraavana esimerkkinä sitten on Astia, jolla on
tilavuus ja nestemäärä.
Ja "olioden välinen kommunikaatio" saadaan esimerkisistä:
Astia ampari(10);
Astia kippo(2);
ampari.tayta();
ampari.kaada(kippo); // ämpäristä kippoon, ämpäriin jää 8 l, kippoon 2 l.
// saattaa mun esimerkeissä jopa olla se vika että
// ampari.kaada(ampari) ei tee hyvää :-)
Vesa
Kalle Kivimaa
> // saattaa mun esimerkeissä jopa olla se vika että
> // ampari.kaada(ampari) ei tee hyvää :-)
Mikä on ihan hyvä asia, koska silloin voi käsitellä helposti myös sen,
mitä voi tapahtua, kun olioiden kanssa menee sekaisin ja miten se
kannattaa estää koodissa, jos mitenkään (esimerkkitapauksessa esim.
lisätään Astia.kaada()-metodiin tarkistus yritetäänkö kaataa itseensä
ja heitetään vaikka KaatoyritysItseensaPoikkeus).
--
* Sacherin laki: Suklaaleivosten määrästä riippumatta maailmassa on aina *
* liian vähän suklaaleivoksia. *
* PGP public key available @ http://www.iki.fi/killer *
A Pietu Pohjalainen
> Eli jos jokainen joka kirjoittaa Javan tai C:n for-silmukan
> käyttää muotoa i++ (tai paremmin ++i, onko muuten Javassa
> väliä kumpaa jos on yksinään?),
Javan tavukoodissa nämä molemmat muodot toteutetaan samalla
'iinc' -komennolla, joten näillä muodoilla on eroa vain
suoritusjärjestyksen osalta.
Esimerkki:
public static Object postincr(Object ob[], int i) {
return ob[i++];
}
public static Object preincr(Object ob[], int i) {
return ob[++i];
}
kääntyy seuraavanlaisiksi tavukoodeiksi
postincr:
0: aload_0
1: iload_1
2: iinc %1 1
5: aaload
6: areturn
preincr:
0: aload_0
1: iinc %1 1
4: iload_1
5: aaload
6: areturn
Tavukoodia suorittava JVM siis ei näe i++ ja ++i -muotojen
välillä eroa.
t. Pietu
A Pietu Pohjalainen
> (153 sivua, 880 kilotavua). Kommentteja ja parannusehdotuksia otetaan
> mielihyvin vastaan.
Täällä onkin kovasti käyty keskustelua Java-puolen
ominaisuuksien käsittelystä, joten minä mainitsen nyt tuon loppuosan
käsittelystä. Oma lukunsa ohjelmistotuotannosta (prosessimalleista,
testauksesta jnpp.) on varmastikin harkittu veto, mutta täytyykö siellä
nyt sitä vesiputousmallia sitten selittää.
Kirjan alussa kun kehutaan kuinka 70-luvun painolasti on
yritetty pudottaa pois, mutta näköjään kirjan loppua kohden tämä kehunta
sitten unohtuu --- vesiputousmalli kun nimenomaisesti edustaa sitä
70-luvun ajattelua parhaimmillaan. Jos ja kun kirjaan sisällytetään
ohjelmistotuotannollisia osuuksiakin, niin varmaankin kannattaa
niissäkin noudattaa kirjan 'punaista lankaa'.
t. Pietu
Toni Nikkanen
> Kirjan alussa kun kehutaan kuinka 70-luvun painolasti on
> yritetty pudottaa pois, mutta näköjään kirjan loppua kohden tämä kehunta
> sitten unohtuu --- vesiputousmalli kun nimenomaisesti edustaa sitä
> 70-luvun ajattelua parhaimmillaan.
Totta, mutta toisaalta, kyllä vesiputousmalli ansaitsee silti vähintään
maininnan, jos ei muusta syystä niin siksi, että se on yhä laajalti
käytössä.
A Pietu Pohjalainen
Ansaitsee tietysti maininnan ohjelmistotuotannon alana
kirjoissa. Eri asia on, että ansaitseeko se mainintaa ohjelmoinnin
perusoppikirjassa, jonka punaisena lankana on pudottaa 70-luvun
painolasti ohjelmoinnin perusopetuksesta pois.
Yhtä lailla proseduraalinen ohjelmointi on monessa paikassa
laajassa käytössä, ja siltikään kirjassa ei sitä yritetä opettaa.
t. Pietu
Virtanen Antti
> Nuo kaksi edellistä esimerkkiä muuten vahvistavat käsitystäni siitä, että
> Javakin on vielä liian matalan tason kieli ohjelmoinnin perusopetukseen.
> Kieli pitäisi suunnitella siten, että yhtäsuuruus on yhtäsuuruutta olioiden
> tyypistä riippumatta, ja jos viitteitä on olemassa kielen abstraktiotasolla,
> niiden yhtäsuuruus on omanlaistaan yhtäsuuruutta.
Javassa ei ole tässä asiassa periaatteessa
ristiriitaa. Primitiivityypit unohtaen == tarkoittaa olioviitteiden
yhtäsuuruutta ja equals -metodi olioiden sisällöllistä
yhtäsuuruutta. Ongelmia tulee vain siitä että == joskus näyttää
toimivan sisällön yhtäsuuruusvertailuna, etenkin merkkijonojen
kohdalla.
Tietysti olisivat voineet valita toisenlaisen syntaksin noille
operaatioille.
Itse tunaroin aluksi monta kertaa tuon kanssa kun olin tottunut C:n ja
Pascalin tapaan verrata merkkijonojen yhtäsuuruutta.
>> Kirjassa käsiteltiin ohjelmien optimointia lyhyesti, tähän voisi
>> panostaa selvästi enemmän.
>
> Nimen omaan päinvastoin. Kaikenlainen optimointi on täysin mahdotonta
> aloittelijalle, joten ainoa toimiva neuvo hänelle on olla edes yrittämättä
> sitä, ja kirjoittaa koodinsa tavoitteenaan selkeys ja toimivuus.
Kirjassa on kuitenkin annettu yleisluontoisia ohjeita siitä miten
ohjelmia optimoidaan ja miten niitä ei kannata optimoida. En
tarkoittanutkaan että perusoppikirjassa esiteltäisiin mitään
haxxor-virittely-optimointeja, mutta tätä kappaletta voisi syventää.
Mutta olen kyllä sitä mieltä että tehokkuusnäkökulmien unohtaminen
täysin antaa ihmisille väärän kuvan ohjelmoinnista. Tietysti
aloittelijan prioriteeteissa (ja muutenkin) selkeys ja toimivuus ovat
tehokkuutta tärkeämpiä, mutta tehokkuuden unohtaminen ei ole hyvä
asia. Ajatus "teen nyt ensin toimivan ja selkeän ja nopeutan sitä
myöhemmin, jos tarvitsee" johtaa usein aika kamaliin lopputuloksiin.
Samoin ajatus "kyllä koneet nopeutuvat sitä tahtia että jos se on nyt
hidas, niin kohta se on jo nopea" on aika yleinen harhakäsitys
ohjelmointia aloittelevilla.
>> Aiheesta on tietenkin kirjoitettu teos jos
>> toinenkin, mutta javaa usein syytetään hitaaksi täysin
>> perusteettomasti,
>
> Aloittelijalta kestää tosi kauan, ennen kuin hän edes pystyy kirjoittamaan
> sellaisen ohjelman, jonka suoritus vaikuttaa hänestä hitaalta.
Tässä voi olla perää. En ehkä oikein osaa asennoitua nykyisillä
tehokoneilla ohjelmointia aloittelevan ihmisen asemaan.
//Antti
Lauri Alanko
> Kieli pitäisi suunnitella siten, että yhtäsuuruus on yhtäsuuruutta olioiden
> tyypistä riippumatta, ja jos viitteitä on olemassa kielen abstraktiotasolla,
> niiden yhtäsuuruus on omanlaistaan yhtäsuuruutta.
Standard ML. Kaikki tavalliset arvot ovat muuttumattomia ja
osoitteettomia, joten niille on vain yhdenlainen yhtäsuuruus. Jos
halutaan tehdä muutoksia, on erillinen ref-tyyppi viitteille, joita
voidaan sitten osoittaa eri paikkoihin. Näillä refeillä on sitten
"identiteetti", ja kaksi refiä ovat samoja vain jos yhden muuttaminen
muuttaa toistakin.
Tähän perään muuan taannoinen horinani yhtäsuuruuksista yleensä:
"Samuus" on yleisestikin aika hankala käsite erityisesti oliomaailmassa.
Funktionaalisessa ympäristössä voidaan käyttää ekstensionaalista
Leibniz-samuutta: kaksi arvoa ovat "samat" joss ne käyttäytyvät samalla
lailla kaikissa mahdollisissa tilanteissa. Yksinkertaisten
tietorakenteiden kohdalla rakenteellinen yhtäläisyys riittää. Toisaalta
kaksi funktiota f ja g ovat samat joss kaikille x f(x) = g(x), ja
tällaista ei millään algoritmilla pysty tarkistamaan yleisesti (Ricen
teoreema).
Kun otetaan "tilan" ja "identiteetin" käsitteet mukaan, ovat oliot
Leibniz-samoja vain jos ne ovat identtisiä, sillä jos ne ovat
epäidenttisiä ja yhteen sijoitetaan, toinen ei muutu. Monessa yhteydessä
olio-ohjelmissa kuitenkin tarvitaan yleisempää "sisällön" samuuden
vertailua, ja tällaisen määrittelemisessä sitten tulee tiettyjä
ongelmia. Abstraktit oliot, joiden rakennetta ei näe, puolestaan
vastaavat aika lailla funktioita: oliot a ja b ovat samanlaisia, jos
kaikille niiden metodeille m ja kaikille m:n parametreille x pätee
a.m(x) = b.m(x). Tällainenkin vertailu on aika mahdotonta.
Ongelma oliokielissä on se, että _kaikesta_ tehdään olioita, joilla on
identiteetti ja tila, ja tämä ei oikein sovi niihin tapauksiin, jolloin
ihan tosissaan halutaan vain esittää rakenteisia arvoja:
class Complex {
public int real;
public int imag;
}
Nyt kahdella Complex-oliolla voi olla sama sisältö mutta eri
"identiteetti", oli se mielekästä eli ei.
Eli siis. Minusta imperatiivisessa kielessä tulisi olla kolmea eri
luokkaa arvoja, ja kolme eri tapaa käsitellä samuutta:
1. Tilalliset rakenteelliset oliot, esim. muuttuvat tietueet: vain
identiteettivertailu.
2. Tilattomat arvot: vain rakenteellinen vertailu.
3. Abstraktit kappaleet (funktiot tai oliot): ei minkäänlaista
"yleistä" vertailuoperaattoria, mutta olio saa toki tarjota
vertailutoiminnallisuuden jos se kuuluu järkevästi sen rajapintaan.
Lauri Alanko
l...@iki.fi
Jomppa Koskinen
> In article <8pkGa.77134$j9%.75168@news04.bloor.is.net.cable.rogers.com>, Ilkka Kokkarinen wrote:
>
> ristiriitaa. Primitiivityypit unohtaen == tarkoittaa olioviitteiden
> yhtäsuuruutta ja equals -metodi olioiden sisällöllistä
> yhtäsuuruutta. Ongelmia tulee vain siitä että == joskus näyttää
>
> Itse tunaroin aluksi monta kertaa tuon kanssa kun olin tottunut C:n ja
> Pascalin tapaan verrata merkkijonojen yhtäsuuruutta.
En kyllä ymmärrä tässä kohdin viittausta C:hen. C:ssähän nimenomaan
ei _saa_ verrata merkkijonoja tyyliin if (foo=="okok") vaan on
käytettävä strcmp & co. -funktioita. Tarkoittanet ilmeisesti C++:n
string-luokkaa, jolle on määritelty yhtäsuuruusoperaatio.
--
Eteenpäin, oi rokkaavat punajuuret!
Niko Kiirala
>
> <nipotusta> Unix shellit yleensä. </nipotusta> :)
Arvasin, että joku tämänkin heittää. En sanonut muista käyttiksistä mitään,
koska en ole niitä kokeillut...
--
Niko Kiirala
Aleksi Kallio
> tarkoitus olla johdatus ohjelmointiin? Koko teoksen rakenne näyttää
> perustuvan Java-kielen rakenteeseen, eikä _ohjelmoinnin_ käsitteisiin.
> ominaisuus, ja sitten kerrotaan, mihin sitä voi käyttää.
Minusta kirjan lähestymistapa on ihan hyvä.
Aloittelijat puhuvat usein "ohjelmantekemisohjelmista", joka näin
kokeneemmalle kuulostaa aika kummalliselta. Mielestäni se kertoo hyvin
siitä kuinka vasta-alkajalle ohjelmointi rinnastuu tekstinkäsittelyyn
tai taulukkolaskentaan. Ohjelmointikielen ja tietyn ohjelmointityökalun
välillä ei nähdä eroa.
Ohjelmointi ja ohjelmointikielet abstraktina käsitteinä ovat siis aika
kaukana aloittelijan ajatusmaailmasta. Tietenkin ohjelmoinnin
ymmärtäminen abstraktimpana ajattelutapana on tärkeää, mutta siihen
kannattaa pyrkiä varovaisesti ja hiljalleen. Ainakin lähes kaikki
positiivinen palaute mitä olen saanut omista kirjoituksistani oikeilta
aloittelijoilta on liittynyt siihen, että teksti on maanläheistä ja
siinä vältetään alkuvaiheessa abstrakteja asioita.
Itse opettelin ohjelmoimaan yrittämällä ja pääasiassa erehtymällä
yksinkertaisen Basic-tulkin kanssa. Maanläheinen räpeltäminen ei
kuitenkaan lamauttanut aivojani niin, että en olisi voinut oppia
abstraktimpaa tietojenkäsittelyä myöhemmin.
Se että kuinka valmis on "abstraktiin symbolimanipulaatioon" riippuu
tietenkin paljon kyseessä olevasta henkilöstä. Ohjelmointia
opettelevalle matematiikan professorille sopiva teos ei välttämättä ole
hyvä 10-vuotiaalle koodarivesalle. Ohjelmoinnin ihmemaailmaan on
monenlaisia polkuja... :)
Ilkka Kokkarinen
> Ilkka ei vielä vastannut siihen miksi käyttää protected attribuutteja?
Koska nähdäkseni tuossa vaiheessa periytyminen on helpompi ymmärtää
protected-tyyppisenä. Mutta harkitsen tuon kyllä vielä uudestaan. Tuossa
olen luultavasti itse mennyt siihen "koska näin on aina ennenkin asiat
opetettu" -ansaan.
> Luku 3: Esimerkki jossa olio viittaa saman luokan olioon ja on
> suuri rekursion vaara. Tähän viitataan tehtävässäkin,
> mutta vastaus jää silti antamatta. Entä lukija joka ei
> osaa ratkaista tehtäviä. Hän jää luuloon että
> tällainen on yleistä.
Kirjan loppuun on tarkoitus laittaa tehtävien mallivastaukset. Viittausten
toiminnan opettamisessa voisi tietysti käyttää kahta luokkaa, mutta
esimerkki olisi tällöin heti tuplasti monimutkaisempi.
> Miksi tähän on jouduttu?
> Hirveä pelko parametrimuuttujien ja lokaalien
> muuttujien esittämisestä.
Tuo esimerkki ei nähdäkseni lainkaan riipu noista.
> "Kun BlueJ kysyy olioille annettavia nimiØa, anna niille nimet h1 ja h2."
>
> Nämäkö niitä hyviä nimiä?
Eivät todellakaan. Hölmö kämmi minulta. Kyseisten olioiden uudet nimet ovat
pekka, ville ja kalle. Sama pätee muihinkin yksikirjaimisiin muuttujanimiin.
> Polymorfismi. Yksinkertainen asia? Yksinkertaisempi kuin
> lokaalit muuttujat?
On. Polymorfismissa ei ole mitään vaikeaa. Sehän tarkoittaa vain sitä
intuitiivista tosiasiaa, että kukin olio vastaa sille annettuihin kutsuihin
oman tyyppinsä mukaisesti.
> public void paint(Graphics g) {
> // Seuraava rivi ottaa kÄayttÄoÄon Graphics2D-olion.
> Graphics2D g2 = (Graphics2D)g;
> // TehdÄaÄan piirtÄamisestÄa vÄahÄan siistimpÄaÄa.
> g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
> RenderingHints.VALUE_ANTIALIAS_ON);
Javan suunnittelijoilta kämmi, joten tuossa kohdassa en voi muuta kuin antaa
nuo kaksi riviä loitsuina, jos haluan sovelman piirtävän jotain. Varsinaiset
piirtokutsut ovat sitten täysin loogisia.
> Tässkäkö on nyt sitten lukijalla varmasti selvillä kaikkien
> metodien kutsut. En sano ettei näin voi tehdä, mutta
> osoittaa että joudut ennemmin tai myöhemmin antamaan periksi
> sille, ettei lukijalle voi olla kaikki selvää ja hänän
> on vain uskottava että joku toimii vaikkei ymmärrä.
Tämä ei silti tarkoita, ettei tuollaisten asioiden määrää voisi ja pitäisi
minimoida.
> Onko Säilö hyvä nimi graafiselle säilölle?
Säiliö.
> Vai pitäisikö
> tätä korostaa, koska jossakin kirjallisuudessa säilöllä
> viitataan nimenomaan esim. C++:n STL:n kaltaisiin
> säilö-luokkiin.
Tuo on tietysti vaara, mutta niin pieni vaara, etten pidä sitä
todennäköisenä. Eikä säiliö ole lainkaan ainoa ohjelmoinnissa kuormitettu
termi.
> Nyt vihdoin lokaali muuttuja, mutta tässä esimerkissä
> se ei edes ole tarpeen...
Totta. Vaihdoin sen tilalle aiempana nähdyn korkoa korolle -metodin, jossa
paikallisia muuttujia ovat nyt vuotuinen korko ja silmukan vuosilaskuri. Tuo
on todellakin paljon parempi näin, alkuperäinen esimerkki oli sutaisten
tehty.
> 6.1.4 Mitä on oikosulkuevaluointi?
> En pidä suomennoksesta! Oikosulku ei mielestäni viittaa siihen että
> lähdetään pois kesken lauseen suorituksen.
Ei viittaakaan, mutta tuo on käsittääkseni vakiintunut suomennos kyseiselle
termille.
> Ja muuten muistutus siitä että 0 <= i <= 100 ei toimi
> (vaikka ei Javassa mene kääntäjästä läpi, niin kohta menee C:ssä).
Moni muukin asia menee läpi C:ssä muttei Javassa, mutta tuo lienee toisaalta
hyvä esittää muutenkin, koska kyllä sitä joku silti yrittää.
> "6.1.5 Miten jäsenmuuttujien periytyminen estetään"
> - no ensinkin kerro tilanteita joissa attribuuttien pitää oikeasti
> periytyä? Ainahan ne joka tapauksessa periytyvät, mutta
> missä niiden pitää oikeasti näkyvä jälkeläisluokalle?
> En ole tarvinnut. Jos niiden annetaan näkyä, niin silloin
> ei voida ikinä muuttaa kantaluokkaa mahdollisesti rikkomatta
> jälkeläisluokkia.
Tuota minun täytyy ilmeisesti harkita tarkemmin. Ehkä olisi viisainta
määritellä periytyminen alun alkaenkin siten, ettei aliluokalla pidä olla
pääsyä kantaluokan attribuutteihin. Mutta sitten täytyy esitellä erikseen
protected ja private, kun ensimmäistä tarvitaan metodeissa ja toista
jäsenmuuttujissa...
>Täytyy panaeutua vielä huolella nyt ylihyppäämiini kohtiin.
>Luvut 4 ja 6 ovat kyllä aika raskaita...
Kiitokset, että jaksat tehdä näin, ja sama tietysti muillekin kommentteja
esittäneille. Niiden tuloksena käsikirjoitus on jo parantunut merkittävästi.
Ilkka Kokkarinen
Ilkka Kokkarinen
"Otto J. Makela" <o...@iki.fi> wrote in message
news:m365n7j...@tigger.otto.net...
>> Konsoliohjelmat ovat auttamattomasti vanhentuneita.
> Mikäli näin on, herää kysymys miksi java-ohjelmat kirjoitetaan
> tekstipohjaisesti, eikä vaan heilutella hiirtä ja liikutella ikoneita?
Miksi kirjoitan tähänkin viestiin tekstiä enkä piirrä kuvaa? Non sequitur.
Sitä paitsi, ainakin minä käytän mieluummin ohjelman kirjoittamiseen
graafista IDE:ä kuin jotain 24*80 -tekstikonsolissa toimivaa editoria.
Graafiset käyttöliittymät ovat sitä paitsi pedagogisestikin parempia
verrattuna konsoliohjelmiin, joissa syötteiden lukeminen ja tulosten
kirjoittaminen on lineaarista. Graafisessa käyttöliittymässä käyttäjä voi
koska tahansa päättää keskeyttää senhetkisen toimintansa ja tehdä jotain
ihan muuta naapuri-ikkunassa. Oikein toimivan ohjelman on annettava
käyttäjälle tämä vapaus siten, että ohjelma reagoi
käyttöliittymäkomponenttiensa tapahtumiin sitä mukaa kuin niitä tulee,
tulevatpa ne sitten mistä komponenteista tahansa. Sisäistä tilaa on pakko
pitää yllä, mahdollisuus käyttää komponentista useaa kappaletta estää
globaalin datan jne.
Ilkka Kokkarinen
Virtanen Antti
>> ristiriitaa. Primitiivityypit unohtaen == tarkoittaa olioviitteiden
>> yhtäsuuruutta ja equals -metodi olioiden sisällöllistä
>> yhtäsuuruutta. Ongelmia tulee vain siitä että == joskus näyttää
>>
>> Itse tunaroin aluksi monta kertaa tuon kanssa kun olin tottunut C:n ja
>> Pascalin tapaan verrata merkkijonojen yhtäsuuruutta.
>
> En kyllä ymmärrä tässä kohdin viittausta C:hen. C:ssähän nimenomaan
> ei _saa_ verrata merkkijonoja tyyliin if (foo=="okok") vaan on
> käytettävä strcmp & co. -funktioita. Tarkoittanet ilmeisesti C++:n
> string-luokkaa, jolle on määritelty yhtäsuuruusoperaatio.
Juurikin. Menee aina välillä nuo C++ ja C sekaisin kielenkäytössä.
//Antti
Jouko Holopainen
> "Otto J. Makela" <o...@iki.fi> wrote in message
>>> Konsoliohjelmat ovat auttamattomasti vanhentuneita.
>
>> Mikäli näin on, herää kysymys miksi java-ohjelmat kirjoitetaan
>> tekstipohjaisesti, eikä vaan heilutella hiirtä ja liikutella ikoneita?
>
> Miksi kirjoitan tähänkin viestiin tekstiä enkä piirrä kuvaa? Non sequitur.
Ihan rehellisesti, mitä ominaisuuksia nyytistimessäsi on, joita ei
voisi toteuttaa komentorivipohjaisesti?
Vastaus: slrn, rn, gnus, ...
> Sitä paitsi, ainakin minä käytän mieluummin ohjelman kirjoittamiseen
> graafista IDE:ä kuin jotain 24*80 -tekstikonsolissa toimivaa editoria.
Älä trollaa, pliis.
Minä käytän editoria, joka tukee tarpeitani, ei joka näyttää hyvältä.
> Graafiset käyttöliittymät ovat sitä paitsi pedagogisestikin parempia
> verrattuna konsoliohjelmiin, joissa syötteiden lukeminen ja tulosten
> kirjoittaminen on lineaarista.
Näin huonoissa konsoliohjelmissa. Todella huonoissa.
Mikäli ei ole käyttänyt koskaan esim. Pineä, saattaa todella luulla
kaikkien konsoliohjelmien olevan "scanf-tyylisiä".
<http://sourceforge.net/projects/javacurses/>
> Graafisessa käyttöliittymässä käyttäjä voi
> koska tahansa päättää keskeyttää senhetkisen toimintansa ja tehdä jotain
> ihan muuta naapuri-ikkunassa.
Harvoin pystyy. Yleensä (liian usein, btw) input ikkuna on modaali.
Eikä toimintasi eroa komentorivipohjaisesta työskentelystä juurikaan,
m.m. screen, tai hyvin monissa ohjelmissa shellin käynnistys.
Kolikon toinen puoli on, että lähes jokaikinen graafinen ohjelma
_vaatii_ (tarpeettomasti) hiiren heiluttelua. Tekstipohjaiset ovat
siksi joskus todella huomattavasti nopeampia käyttää.
Vrt pankit, ja virkailijoiden käyttämät koneet.
--
@jhol
"Trust me, I know what I am doing"
-- m$ Trustworthy Computing slogan
Virtanen Antti
>>> Mikäli näin on, herää kysymys miksi java-ohjelmat kirjoitetaan
>>> tekstipohjaisesti, eikä vaan heilutella hiirtä ja liikutella ikoneita?
>>
>> Miksi kirjoitan tähänkin viestiin tekstiä enkä piirrä kuvaa? Non sequitur.
>
> Ihan rehellisesti, mitä ominaisuuksia nyytistimessäsi on, joita ei
> voisi toteuttaa komentorivipohjaisesti?
Voihan ne ominaisuudet toteuttaa vaikka
äänen/sähköshokkien/kirjekyyhkyjen välityksellä kommunikoiden sen
sijaan että käytetään jotain monitoria ja tekstiä. Toiset tykkää
vaaleasta ja toiset tummasta.
>> Sitä paitsi, ainakin minä käytän mieluummin ohjelman kirjoittamiseen
>> graafista IDE:ä kuin jotain 24*80 -tekstikonsolissa toimivaa editoria.
>
> Älä trollaa, pliis.
>
> Minä käytän editoria, joka tukee tarpeitani, ei joka näyttää hyvältä.
Niin. Luulen että kaikki muutkin käyttävät sitä editoria joka heille
parhaiten sopii. Useimmille se graafinen IDE on se paras
vaihtoehto. Ja monille se miellyttävä ulkonäkö on ainakin
alitajuisesti tärkeä.
> Kolikon toinen puoli on, että lähes jokaikinen graafinen ohjelma
> _vaatii_ (tarpeettomasti) hiiren heiluttelua. Tekstipohjaiset ovat
> siksi joskus todella huomattavasti nopeampia käyttää.
>
> Vrt pankit, ja virkailijoiden käyttämät koneet.
Tekstipohjainen on varmaan nopeampi, mutta oppimiskynnys on yleensä
kovempi kuin graafisessa kälissä, koska se nopeus vaatii käytännössä
näppäinkomentojen ulkoaopettelua. Nykyiset aloittelevat ohjelmoijat
ovat syntyneet graafisten systeemien ja hiirenheiluttelun
mailmaan. Arvaa kuulostaako joku tekstipohjainen hiiretön systeemi
heistä antiikkiselta?
En kiinnittänyt itse huomiota Ilkan kirjan JBlue
-sidonnaisuuteen. Luulisin että vähänkin enemmän koneita käyttänyt
ihminen kyllä osaa kirjan avulla javaa opetellessaan suodattaa
JBlue-jutut pois ja korvata omalla suosikkisysteemillään.
Tämä nyt ei (kohta) enää suoranaisesti liity aiheeseen.
//Antti "lokori" Virtanen
Aleksi Kallio
>>graafista IDE:ä kuin jotain 24*80 -tekstikonsolissa toimivaa editoria.
> Älä trollaa, pliis.
> Minä käytän editoria, joka tukee tarpeitani, ei joka näyttää hyvältä.
Tuo usein kuultu vihjaus, että: "minä käytän komentoriviä, koska en
välitä koreasta ulkokuoresta", ei osu oikein mihinkään. Ei graafisia
ohjelmia käytetä siksi, että ne näyttävät hienolta, vaan siksi, että
että näköaisti on ihmisen aisteista ylivertainen (vrt. esim. Saariluoma:
Taitavan ajattelun psykologia) ja niinpä siitä kannattaa ottaa kaikki irti.
Kauneus on katsojan silmässä - toimiva graafinen ratkaisu alkaa näyttää
kauniilta. Ainakin omalta osaltani hienot flash-webbisivut, jotka eivät
toimi kunnolla, alkavat pian näyttää rumilta. Sen sijaan esim. Googlen
megatoimiva etusivu näyttää kauniilta, vaikka onkin hyvin koristeeton.
Eli minusta kauneus laajasti ymmärrettynä on tärkeää ominaisuus ohjelmille.
Minäkin käytän noin puolet nörtteilyajasta komentoriviä. Koodia en
kuitenkaan kirjoita kuin IDE:ssä, koska se lisäinformaatio, mitä
graafinen IDE pystyy välittämään, tulee tarpeeseen. Tosin nykyiset IDE:t
ja ohjelmointikielet yleensä voisivat olla paljon visuaalisempiakin.
Jori Mantysalo
>> Joissakin koodiesimerkeissä on käytetty ääkkösiä ja ne eivät taida
>> mennä javakääntäjästä läpi.
> Kuten tuolla jo sanottiinkin, javasta menevät hyvin läpi paitsi ääkköset,
> myös vaikka aasialaiset merkit. Juuri tällaisia asioita tarkoitin, kun
> kirjoitin että 1970-luvun painolasti elää vieläkin ohjelmoinnin
> perusopetuksessa eikä kukaan edes huomaa kyseenalaistaa sitä.
(En ole vielä lukenut itse kirjaa.)
Mainitaanko kirjassa edes sivulauseessa, että ääkköset ovat uusi asia
ohjelmoinnissa? Mm. moni koodi johon törmää, saattaa olla kirjoitettu
ilman ääkkösiä ihan vain vanhasta muistista. On kai syytä kertoa siitäkin,
ettei aloittelija ihmettele asiaa.
Paljon riippuu siitäkin, miten tiukasti ankkuroidutaan yhteen ympäristöön.
Esimerkiksi Windows-ikkunassa Notepadilla tehty teksti ei muistaakseni aina
käänny suoraan Java-kääntäjällä DOS-puolella. Toki ongelmia tulee jo
kommenteistakin, jos niissä äät muuttuvat sigmoiksi.
--
- "Kissankakkaa lattialla? En huomaa pieniä yksityiskohtia."
- "JAA. 'Tässä ei ole välilyöntiä ennen pilkkua, njäh njäh.'"
-- Keskustelua vaimon kanssa
Jouko Holopainen
> In article <m3znkhy...@gnosis.pp.invalid>, Jouko Holopainen wrote:
>> Ihan rehellisesti, mitä ominaisuuksia nyytistimessäsi on, joita ei
>> voisi toteuttaa komentorivipohjaisesti?
>
> Voihan ne ominaisuudet toteuttaa vaikka
> äänen/sähköshokkien/kirjekyyhkyjen välityksellä kommunikoiden sen
> sijaan että käytetään jotain monitoria ja tekstiä.
Säälittävää... etkä parempaan pysty, vaikka "tiedät", paremmin?
>> Minä käytän editoria, joka tukee tarpeitani, ei joka näyttää hyvältä.
>
> Niin. Luulen että kaikki muutkin käyttävät sitä editoria joka heille
> parhaiten sopii. Useimmille se graafinen IDE on se paras
> vaihtoehto. Ja monille se miellyttävä ulkonäkö on ainakin
> alitajuisesti tärkeä.
On se hyvä, että sinä "tiedät", paremmin.
>> Kolikon toinen puoli on, että lähes jokaikinen graafinen ohjelma
>> _vaatii_ (tarpeettomasti) hiiren heiluttelua. Tekstipohjaiset ovat
>> siksi joskus todella huomattavasti nopeampia käyttää.
>>
>> Vrt pankit, ja virkailijoiden käyttämät koneet.
>
> Tekstipohjainen on varmaan nopeampi, mutta oppimiskynnys on yleensä
> kovempi kuin graafisessa kälissä, koska se nopeus vaatii käytännössä
> näppäinkomentojen ulkoaopettelua.
Täsmälleen päinvastoin - minun kokemuksella. Mutta sinähän asian
"tiedät", paremmin.
> Nykyiset aloittelevat ohjelmoijat
> ovat syntyneet graafisten systeemien ja hiirenheiluttelun
> mailmaan. Arvaa kuulostaako joku tekstipohjainen hiiretön systeemi
> heistä antiikkiselta?
EVVK. Kaikki eivät pysy aloittelijoina, asia jonka sinäkin, ehkä,
joskus "tiedät", paremmin.
Jouko Holopainen
>> Minä käytän editoria, joka tukee tarpeitani, ei joka näyttää
>> hyvältä.
>
> Tuo usein kuultu vihjaus, että: "minä käytän komentoriviä, koska en
> välitä koreasta ulkokuoresta", ei osu oikein mihinkään. Ei graafisia
> ohjelmia käytetä siksi, että ne näyttävät hienolta, vaan siksi, että
> että näköaisti on ihmisen aisteista ylivertainen (vrt. esim.
> Saariluoma: Taitavan ajattelun psykologia) ja niinpä siitä kannattaa
> ottaa kaikki irti.
Mikä aisti on tekstipohjaisissa editoireissa käytössä?
Minusta on tarpeetonta haitata sitä tärkeintä aistia häiriöillä.
Esimerkiksi Microsoftin Word 97:ssa (en tiedä uudemmista) on
ominaisuus, joka saa ikkunan alareunassa olevan kynän heilumaan, kun
kirjoittaa¹. ERITTÄIN rasittava.
¹ (saattoi liittyä oikeinkirjoitukseen taikka ei, en tiedä)
> Ainakin omalta osaltani hienot flash-webbisivut,
> jotka eivät toimi kunnolla, alkavat pian näyttää rumilta.
Tästä en tiedä, kun en viitsi flashiä asentaa :-)
> Tosin nykyiset
> IDE:t ja ohjelmointikielet yleensä voisivat olla paljon
> visuaalisempiakin.
IMO ne voisivat olla "edes" XEmacsia/Vimiä parempia.
Vesa Lappalainen
on paras liittymä? Molemmilla on oma
käyttäjäkuntansa ja molemmilla on oma paikkansa.
Kyse oli kai siitä kumpaako opetetaan Java-alkeiskirjassa?
(Tietysti oli voimakkasti sanottu että tekstiliittymästä
ei ole mihinkään, en minäkään sitä hyväksy).
Tuossa muodossa kuin BlueJ:llä graafinen liittymä tehdään,
tulee tekijälle aika paljon ylimääräistä työtä ja ymmärtämistä.
Jos se tehtäsiinkin kuten Delphissä tai VB:ssä, eli koodarille
jää näkyviin pelkästään tiettyjen komponenttien tapahtumat,
niin silloin saattaisin jopa kallistua graafisen liittymän
puolelle. Mutta nyt lyödään eteen koko Javan kauhea arsenaali
monimutkaisia kapineita tapahtuman käsittelyyn.
"Säilöjä" joiden päälle saa laittaa komponentteja yms. Niistä
ei tarvitse alkuvaiheessa tietää yhtään mitään.
VB koodarit tuskin vieläkään tietävät mitä tapahtuu
kun käyttäjä painaa heidän ruudulle vetämäänsä nappulaa.
Ja silti heidän tekemänsä ohjelmat toimivat.
Ihme ettei missään Java-vehkeessä ole päästy vielä samaan.
JBuilder ja NetBeans tätä yrittävät, mutta kun kaikki
koodi ja liittymä menee sekaisin ja sitten koodari kirjoittaa
muutaman rivin jonnekin hämyn koodin sekaan, jossa
vielä mahdollisetsi lukee "älä vaan muuta tästä".
Näin oli Win-ohjelmoinnissa joskus 90-luvun alussa.
Jos kirjoitetaan graafista liittymää, pitää se voida
tehdä graafisella editorilla. Mutta se pitää voida
kirjoittaa myös suoraan koodiinkin. BlueJ tukee
vain jälkimmäistä? => on hieman kyseenalaista
onko se silloin hyvä aloittelijalla ja korostaako
se graafisen liittymän hyviä puolia.
Itse asia "graafiset liittymät" ovat nimenomaan
kokeneille käyttäjille. Itse käyttäisin mieluummin
nimeä "suorakäyttöliittymä", eli käyttäjä voi tehdä minkä
tahansa toiminnon seuraavaksi. Koska käyttäjä ei
tiedä mitä pitäisi tehdä, varustetaan nykyisin
"graafiset liittymät" mitä ihmeellisimmillä
Wizardeilla, jotka kyselevät rivi kerrallaan
"graafisessa ikkunassa" että mitä tehdään seuraavaksi.
Kuka näkee tässä eron vanhaan kunnon:
Mikä on nimesi >Vesa[ret]
Millä kuljet töihin >pyörällä[ret]
verrattuna? Muuta kuin värit?
Vesa
Panu Mantylahti
> Mikä aisti on tekstipohjaisissa editoireissa käytössä?
Tämä nyt rupeaa jo menemään aika kauas Javakirjasta, mutta menkööt.
Itse pidän IDE-välineistä, koska niissä on käteviä toimintoja.
Esimerkiksi Eclipsessä (vapaa IDE mm. Javan koodailuun) on syntaksin
värikorostus. Toiminto on tarjolla myös Emacs & Vi -editoreihin
johdannaisineen. Kutsuttakoon E&V -ryhmää tekstieditoreiksi.
Koodin automaattinen täydennys on kätevää. Eli olion nimen perään kun
kirjoittaa pisteen, niin tarjotan kontekstivalikkoa jossa ovat julkiset
attribuutit ja metodit. Metodeista näytetään parametrien tyypit sekä
palautusarvot. Erittän käytännöllinen toiminto. Saako tätä
tekstiedotoreihin?
Itse olen huomannut Javaa opetteleville usein ongelmalliseksi muistaa,
milloin hilavitkuttimella X on .length -kenttä ja milloin .length()
-metodi. Väärin valitsemalla saa tietysti kääntäjältä virheilmoituksen,
josta joko oppii tai sitten sekoittuu entistä enemmän. Kun IDE tarjoaa
automaagisesti oikeaa vaihtoehtoa, pienenee virheenteon riski. Kyse on
tavallaan oikoluvusta.
Luokkien esitys puumaisena kaaviona. Eclipsen esitystapa auttaa
hahmottamaan varsinkin laajojen sisäluokkien rakenteet visuaalisesti
huomattavasti paremmin, kuin lähdekoodin katselu. Tähän tekstieditorit
eivät taida taipua, vaan tarvitaan erillinen työkalu (joka luultavasti
ei toimi merkkigraafisesti.)
Yhdysrakenteinen debuggeri kuuluu Eclipsen varusteluun. Koodin suoritus
askel kerrallaan ja olioiden tilan tarkkailu ovat käteviä tapoja
virheiden metsästykseen. Joku kehui taannoin comp.lang.c++ -ryhmässä
suunnittelevansa ohjelmansa etukäteen paperille niin hyvin, ettei ole
ikinä tarvinnut debuggeria. Virhetilanteessa takaisin piirrustuspöydän
ääreen, sitten taas koodaamaan. Pystyvätkö tekstieditorit vastaavaan
yhteistoimintaan?
Tilanteesta riippuen koodaan joko IDEllä tai sitten tekstieditorilla.
Yleensä valintakriteerinä on hankkeen laajuus. Pikkumokkulat on jo
kirjoitettu microemacsilla siinä vaiheessa kun Eclipsen splash-screen on
viimeinkin poistunut ruudulta ja sovellus on käyttökunnossa.
-P
--
Thou shalt not follow the Null Pointer,
for at its end Madness and Chaos lie.
Jouko Holopainen
> Koodin automaattinen täydennys on kätevää. Eli olion nimen perään kun
> kirjoittaa pisteen, niin tarjotan kontekstivalikkoa jossa ovat julkiset
> attribuutit ja metodit. Metodeista näytetään parametrien tyypit sekä
> palautusarvot. Erittän käytännöllinen toiminto. Saako tätä
> tekstiedotoreihin?
Saa (tietenkin vaihtelevalla menestyksellä per editori).
(X)Emacsissa on m.m. JED.
> Yhdysrakenteinen debuggeri kuuluu Eclipsen varusteluun. Koodin suoritus
> askel kerrallaan ja olioiden tilan tarkkailu ovat käteviä tapoja
> virheiden metsästykseen. Joku kehui taannoin comp.lang.c++ -ryhmässä
> suunnittelevansa ohjelmansa etukäteen paperille niin hyvin, ettei ole
> ikinä tarvinnut debuggeria. Virhetilanteessa takaisin piirrustuspöydän
> ääreen, sitten taas koodaamaan. Pystyvätkö tekstieditorit vastaavaan
> yhteistoimintaan?
Pystyy (ei henk koht kokemusta, tosin).
Itseäni häiritsee useimpien debuggereiden hitaus: "printf" sopivaan
paikkaan on erittäin usein nopeampi tapa selvittää ongelma.
Enkä tarkoita k.o. kohdan eka suorituskertaa, vaan noin kymmenettä.
"Tarpeeksi" hyvää debuggeria en ole vielä - erittäin valitettavasti -
ole nähnyt. Paras koskaan näkemäni lienee SoftIce, tai ehkä td32.
Paras yhdistetty IDE-debuggeri lienee Microsoftin VC++, mutta sen muut
omituisuudet (ei osaa edes sisentää C:tä oikein, *huoh*).
Kun kerran on oppinut, että editori sisentää oikein 99.9% tapauksista,
ei kertakaikkiaan kestä huonompia. M.m. tästä syystä moni IDE ei
"kelpaa".
Tässä (X)Emacs on aivan hävyttömän paljon edellä kaikkea muuta¹.
¹ Vim kuuleema on lähes yhtä hyvä?
> Tilanteesta riippuen koodaan joko IDEllä tai sitten tekstieditorilla.
> Yleensä valintakriteerinä on hankkeen laajuus. Pikkumokkulat on jo
> kirjoitettu microemacsilla siinä vaiheessa kun Eclipsen splash-screen on
> viimeinkin poistunut ruudulta ja sovellus on käyttökunnossa.
Tämä onkin oma IDEjen suurin haukkuma. Niillä ei voi tehdä "cp
vanha.java (rivit 23-45) + ... -> uusi.java", vaan koko homma pitää
joko tehdä uusiksi tai käyttää niiden "rad" ominaisuuksia.
Yhdenkään koskaan kokeilemani IDEn "rad" ei pääse lähellekkään
copy-pasten tehokkuutta. Tosin se eka kerta on tuska, mutta IMO auttaa
ymmärtämään alla olevaa systeemin taustaakin paljon.
Niin, BlueJ:tä en ole kokeillut, enkä Eclipseä, että ehkäpä jompi
kumpi niistä?
Pasi Savolainen
> mant...@cs.Helsinki.FI.invalid (Panu Mantylahti) writes:
>
>> Koodin automaattinen täydennys on kätevää. Eli olion nimen perään kun
>> kirjoittaa pisteen, niin tarjotan kontekstivalikkoa jossa ovat julkiset
>> attribuutit ja metodit. Metodeista näytetään parametrien tyypit sekä
>> palautusarvot. Erittän käytännöllinen toiminto. Saako tätä
>> tekstiedotoreihin?
>
> Saa (tietenkin vaihtelevalla menestyksellä per editori).
>
> (X)Emacsissa on m.m. JED.
olisiko tähän jotain suorempaa pointtia, en saanut kuin jed
-editorilinkkejä haettua. Ei sentään 'jde' (joka näyttää olevan java
-specifinen)?.
> Itseäni häiritsee useimpien debuggereiden hitaus: "printf" sopivaan
> paikkaan on erittäin usein nopeampi tapa selvittää ongelma.
>
> Enkä tarkoita k.o. kohdan eka suorituskertaa, vaan noin kymmenettä.
Omat kokemukset debggaamisesta ovat borland c++ 5.0:n integroidusta ja
watcom 11.0:n erillisestä debuggerista. Watcomin debuggeri oli hiukan
käsi, mutta silti _hyvin paljon_ edellä mistään printk:sta. Mitä tahansa
arvoja pystyi tarkastelemaan ja ohjelman rakenteessa hyppimään melko
vapaasti. Koodia ei voinut muokata lennossa (mihin ilmeisesti VC6
kykenee), mutta vaihtelemalla arvoja sai suurimman osan bugeista
litistettyä iteroimalla yhden session läpi.
Borlandin, vanhaa teknologiaa oleva, integroitu debuggeri tuntui silti
olevan tuosta edellä.
> "Tarpeeksi" hyvää debuggeria en ole vielä - erittäin valitettavasti -
> ole nähnyt. Paras koskaan näkemäni lienee SoftIce, tai ehkä td32.
> Paras yhdistetty IDE-debuggeri lienee Microsoftin VC++, mutta sen muut
> omituisuudet (ei osaa edes sisentää C:tä oikein, *huoh*).
>
> Kun kerran on oppinut, että editori sisentää oikein 99.9% tapauksista,
> ei kertakaikkiaan kestä huonompia. M.m. tästä syystä moni IDE ei
> "kelpaa".
Jos se on integroitu, niin miksi se muka näyttäisi sen väärin?
> Tässä (X)Emacs on aivan hävyttömän paljon edellä kaikkea muuta¹.
Tuota, kerropas vaikka joku esimerkkitapaus ja miten sinä teet.
oletetaan kieleksi C, ja sen että tiedät missä kohti asiat menevät
väärin (esim. joku yksittäinen funkkari joka antaa väärät arvot ulos).
esim. watcomissa teen niin että käännän ohjelman, avaan sen debuggeriin,
menen siihen objektiin missä funkkari on, naksutan funkkarin kohdalle
breakpoint ja annan ohjelman ajaa. kun se pysähtyy breakpointtiin,
askellan ja katson arvoja, mahdollisesti mennen 'sisään' toisiin
funktiokutsuihin.
Näin siis silloin kun jotain pitää windowsissa tehdä. Linuxissa olen
lähinnä käyttänyt printf:ää kun vaihtoehdot ei kohdattujen ongelmien
yksinkertaisuuden takia ole kiinnostaneet.
> Tämä onkin oma IDEjen suurin haukkuma. Niillä ei voi tehdä "cp
> vanha.java (rivit 23-45) + ... -> uusi.java", vaan koko homma pitää
> joko tehdä uusiksi tai käyttää niiden "rad" ominaisuuksia.
IDE on siis mielestäsi 'rad'. IMO emacs on IDE ja RAD -työkalut asia
kokonaan erikseen.
--
Psi -- <http://www.iki.fi/pasi.savolainen>
Vivake -- Virtuaalinen valokuvauskerho <http://members.lycos.co.uk/vivake/>
Ilkka Kokkarinen
> Kyse oli kai siitä kumpaako opetetaan Java-alkeiskirjassa?
> (Tietysti oli voimakkasti sanottu että tekstiliittymästä
> ei ole mihinkään, en minäkään sitä hyväksy).
On siitä johonkin, se vain on kovasti vanhentunut.
> puolelle. Mutta nyt lyödään eteen koko Javan kauhea arsenaali
> monimutkaisia kapineita tapahtuman käsittelyyn.
> "Säilöjä" joiden päälle saa laittaa komponentteja yms. Niistä
> ei tarvitse alkuvaiheessa tietää yhtään mitään.
Javan komponentit ja niiden tapahtumien käsittely on epäilemättä
ylivoimaisen vaikeaa aloittelijalle erityisesti, jos tämä on ensin opetettu
ajattelemaan ja ohjelmoimaan 70-luvun ei-olioparadigmalla, jossa ohjelma
koostuu proseduureista ja sen suoritus kerran käynnistettynä etenee siinä
käsky käskyltä keskeytymättä, kunnes suoritus lopulta päättyy tultaessa
ohjelman loppuun. Syöte, suoritus, tulostus, piste.
Mutta jos opetus on alusta alkaen tehty siinä hengessä, että on olemassa
olioita, joille voidaan kutsua niissä olevia metodeita, ei Javan
tapahtumankäsittelyssä pitäisi nähdäkseni edes olla mitään käsitteellisesti
hankalaa.
Graafisen käyttöliittymän komponentit ovat olioita ihan niin kuin mikä
tahansa muukin olio, niillä vain sattuu olemaan metodi paint, jonka
kutsuminen saa ne piirtämään itsensä ruudulle. Lisäksi komponenttiluokista
rakennetut oliot reagoivat hiiri- ja muihin tapahtumiin hihkaisemalla. Jos
jokin olio on asetettu kuuntelemaan jonkun komponenttiolion hihkaisuja,
kuuntelijaoliossa tapahtuu automaattisesti hihkaisun tyyppiä vastaava
metodikutsu.
Kuten näkyy, Javan tapahtumankäsittelyn idean voi selittää olioiden kautta
yksinkertaisesti yhdellä lyhyellä kappaleella. Enkä näe, miksi tuosta
pitäisi tehdä tuon monimutkaisempaa. Sitten vain luetellaan tarvittavien
metodien nimet, ja asia on sillä selvä.
Itse asiassa tajusin äsken, minkä muutoksen teen kirjaani seuraavaksi: koko
"ohjelman" käsite on nykyaikana pelkästään haitallinen, joten poistan
kirjastani joka ikisen tuon käsitteen esiintymän! Miksen tajunnut tätä jo
aikaisemmin huomatessani, ettei tuolle käsitteelle ollut muutenkaan kirjassa
mitään luonnollista paikkaa jossa käyttää sitä?
Eiköhän tämä ole jo riittävän vallankumouksellinen lähestymistapa, kun
ohjelmoinnin oppikirjassa ei edes mainita sanoja "ohjelma" ja "ohjelmointi".
Mutta kuten laulussa sanotaan, "vielä paljon pitää uudistaa, ennen kuin
paradigmasi kelpaa!" Toverit, mitä odotamme?
Minulle on olemassa pelkästään luokkia, joista voidaan rakentaa olioita,
jotka voivat olla tietoisia toistensa olemassaolosta. Tällä hetkellä käytän
olioiden rakentamiseen ehkäpä luokkia A, B ja C, mutta seuraavaksi käytänkin
luokkia B, C ja D. Mihin tässä ajatusmallissa tarvitaan "ohjelman" käsitettä
lainkaan? Tai no, voinhan minä ottaa tekemistäni luokista jonkin osajoukon,
niputtaa ne yhdeksi muille ihmisille jaettavaksi paketiksi ja kutsua näin
syntyvää rakennetta "ohjelmaksi". Mutta miksi?
Ilkka Kokkarinen
Saku Niskanen
> Koodin automaattinen täydennys on kätevää. Eli olion nimen perään kun
> kirjoittaa pisteen, niin tarjotan kontekstivalikkoa jossa ovat julkiset
> attribuutit ja metodit. Metodeista näytetään parametrien tyypit sekä
> palautusarvot. Erittän käytännöllinen toiminto. Saako tätä
> tekstiedotoreihin?
>
> Itse olen huomannut Javaa opetteleville usein ongelmalliseksi muistaa,
> milloin hilavitkuttimella X on .length -kenttä ja milloin .length()
> -metodi. Väärin valitsemalla saa tietysti kääntäjältä virheilmoituksen,
> josta joko oppii tai sitten sekoittuu entistä enemmän. Kun IDE tarjoaa
> automaagisesti oikeaa vaihtoehtoa, pienenee virheenteon riski. Kyse on
> tavallaan oikoluvusta.
Siis kuten tuossa jo todettiin, koodin täydennyksen saa joihinkin
tekstieditoreihin.
Mielestäni tuo kokeneemmalle ohjelmoijalle mukava ominaisuus voi kuitenkin
olla tietyllä tavalla jopa haitallinen aloittelijalle.
Javaa opettelevalle on huomattavasti hyödyllisempää etsiä oikea metodi
API-kuvauksia lukemalla, kuin arpoa "oikealta kuulostava" metodi
kontekstivalikosta nimen perusteella.
Ainoastaan API-kuvauksia lukemalla voi ymmärtää minkä kanssa on oikeasti
tekemisissä, eli mitä sivuvaikutuksia metodin kutsumisella on (esimerkiksi
muuttuuko olion tila kutsun seurauksena), mitä tapahtuu virhetilanteissa
ja mistä ne johtuvat, voiko metodi palauttaa nullin jossain tilanteessa
jne.
Pasi Savolainen
> Itse asiassa tajusin äsken, minkä muutoksen teen kirjaani seuraavaksi: koko
> "ohjelman" käsite on nykyaikana pelkästään haitallinen, joten poistan
> kirjastani joka ikisen tuon käsitteen esiintymän! Miksen tajunnut tätä jo
> aikaisemmin huomatessani, ettei tuolle käsitteelle ollut muutenkaan kirjassa
> mitään luonnollista paikkaa jossa käyttää sitä?
>
> Eiköhän tämä ole jo riittävän vallankumouksellinen lähestymistapa, kun
> ohjelmoinnin oppikirjassa ei edes mainita sanoja "ohjelma" ja "ohjelmointi".
> Mutta kuten laulussa sanotaan, "vielä paljon pitää uudistaa, ennen kuin
> paradigmasi kelpaa!" Toverit, mitä odotamme?
>
> Minulle on olemassa pelkästään luokkia, joista voidaan rakentaa olioita,
> jotka voivat olla tietoisia toistensa olemassaolosta. Tällä hetkellä käytän
> olioiden rakentamiseen ehkäpä luokkia A, B ja C, mutta seuraavaksi käytänkin
> luokkia B, C ja D. Mihin tässä ajatusmallissa tarvitaan "ohjelman" käsitettä
> lainkaan? Tai no, voinhan minä ottaa tekemistäni luokista jonkin osajoukon,
> niputtaa ne yhdeksi muille ihmisille jaettavaksi paketiksi ja kutsua näin
> syntyvää rakennetta "ohjelmaksi". Mutta miksi?
Tällä lailla opetetuilla 'olioijilla' tulee olemaan suuria hankaluuksia
ymmärtää säie -ohjelmointia. Ohjelma -käsite kun liittyy siihen että
ohjelmalla on liikkuva 'polttopiste', ja monisäikeisessä ohjelmassa
niitä voi olla useampi, ja ne voivat olla samassakin paikassa.
Aloittelijalle ei niinkään tärkeää, mutta etenemisen kannalta kylläkin.
Kalle Kivimaa
> Tuota, kerropas vaikka joku esimerkkitapaus ja miten sinä teet.
> oletetaan kieleksi C, ja sen että tiedät missä kohti asiat menevät
> väärin (esim. joku yksittäinen funkkari joka antaa väärät arvot ulos).
Asetetaan log4j:n tulostustasoksi DEBUG ja ajetaan ohjelma :) Tai no
jos kyse on C:stä niin kai siihenkin löytyy joku fiksu valmis
lokikirjasto, löytyyhän?
--
* Dean's Rule #45. The truth hurts for a moment. *
* A lie hurts for a long time. *
* PGP public key available @ http://www.iki.fi/killer *
O Juhani Simola
Pasi Savolainen
> Pasi Savolainen <ps...@iki.fi> writes:
>> Tuota, kerropas vaikka joku esimerkkitapaus ja miten sinä teet.
>> oletetaan kieleksi C, ja sen että tiedät missä kohti asiat menevät
>> väärin (esim. joku yksittäinen funkkari joka antaa väärät arvot ulos).
>
> Asetetaan log4j:n tulostustasoksi DEBUG ja ajetaan ohjelma :) Tai no
> jos kyse on C:stä niin kai siihenkin löytyy joku fiksu valmis
> lokikirjasto, löytyyhän?
Missä vaiheessa tässä pääsee muuttamaan arvoja jotta näkisi mitä muuta
funkkarissa on vialla?
IMO C-alikien 'hitaus' käännöksineen kaikkineen johtuu siitä että sitä tehdään
aina sellaisissa väleissä missä siihen ei ole mitään tarvetta, vain sen
takia että ei käytetä oikeita työkaluja.
Tietty rauta on auttanut tähänkin, mutta jo pelkästään se että joutuu
vaihtamaan tehtävästä (debuggaus-korjaus-käännös) toiseen tuhoaa työtehon.
Kalle Kivimaa
> valitsemisen voi jättää välistä. Lisätietoja saa vaikka kirjoittamalla
> googleen avainsanat 'gdb tutorial'. GDB integroituu emacsiin niin,
> että kokonaisvaikutelma on aika lailla samanlainen kuin wanhassa
> Borlandin debuggerissa. Emacsin gdb-moodissa on kyllä valikoiden
> lisäksi komentorivi, ja se varmaan näyttää jotenkin uhkaavalta.
Juu toki näin kun debugataan ohjelmaa. Debuggerin käytön ongelma tulee
vain siinä, että _asiakasta_ on vaikea saada ajamaan debuggeria
tuotannossa. Paljon nopeammin ongelmia saa setvittyä kun pyytää
asiakasta nostamaan lokitasoa joko lennosta tai vaikka systeemin
uudelleenkäynnistämällä. Monesti olen kaivannut todella hienojakoista
lokia, joten vähänkään monimutkaisemmassa serverisysteemissä kannattaa
mielestäni ihan alusta lähtien lokittaa melkein kaikki tarvittaessa.
Ja kun puhutaan useassa threadissa pyörivästä ohjelmasta, ainakin minä
menen ihan liian sekaisin debuggerin käyttämisessä sellaisessa
tilanteessa. Paljon enemmän saan irti tarkasta lokista aikaleimoineen.
Vesa Lappalainen
> Javan komponentit ja niiden tapahtumien käsittely on epäilemättä
> ylivoimaisen vaikeaa aloittelijalle erityisesti, jos tämä on ensin opetettu
> ajattelemaan ja ohjelmoimaan 70-luvun ei-olioparadigmalla, jossa ohjelma
porukalla ollut mitään vaikeutta tajuta tapahtumapohjaista
ohjelmointia. En tiedä miten metsään joku pystyy opettamaan
jos joutuu sanomaan että "nyt unohtakaa kaikki". En
ole tätä joutunut koskaan tekemään. Mutta se johtuu ehkä
siitä että jo alusta saakka tiedän mihin loppupelissä tullaan
menemään. Eli en opeta mitään mikä olisi ristiriidassa
tulevan kanssa.
Se mikä on vaikeaa, on Javan tapa hoitaa se tapahtumankäsittely
kuuntelijoineen ja sovittimineen. Ihme ukko joka ne voi
muistaa ulkoa. Eli olla viikon koodaamatta ja sitten ilman
minkään manuaalin tms. apua osaa tehdä edes mun kurssin
autolaskuriesimerkin.
> koostuu proseduureista ja sen suoritus kerran käynnistettynä etenee siinä
> käsky käskyltä keskeytymättä, kunnes suoritus lopulta päättyy tultaessa
> ohjelman loppuun. Syöte, suoritus, tulostus, piste.
Eipäs se aivan näin ole. Mulla jo teksipohjaisessa liittymässä
on aivan vastaava rakenne kuin Windowsin viestisilmukka.
> Mutta jos opetus on alusta alkaen tehty siinä hengessä, että on olemassa
> olioita, joille voidaan kutsua niissä olevia metodeita, ei Javan
> tapahtumankäsittelyssä pitäisi nähdäkseni edes olla mitään käsitteellisesti
> hankalaa.
Sen toteutus on tehty hankalasti. Vaatii tosi syvällistä olioiden
ja rajapintojen ymmärtämistä jotta pystyy tajuamaan miksi asiat
tehdään noin.
> Graafisen käyttöliittymän komponentit ovat olioita ihan niin kuin mikä
> tahansa muukin olio, niillä vain sattuu olemaan metodi paint, jonka
> kutsuminen saa ne piirtämään itsensä ruudulle. Lisäksi komponenttiluokista
Totta mooses, ei siitä ole kyse.
> kuuntelijaoliossa tapahtuu automaattisesti hihkaisun tyyppiä vastaava
> metodikutsu.
Automaattisesti. Hih!
> kirjastani joka ikisen tuon käsitteen esiintymän! Miksen tajunnut tätä jo
> aikaisemmin huomatessani, ettei tuolle käsitteelle ollut muutenkaan kirjassa
> mitään luonnollista paikkaa jossa käyttää sitä?
Ehkä siksi ettei tuossa ajatuksessa ole mitään järkeä!
Välillä ehdin pitää jo sinua kehityskelpoisena yksilönä, mutta
nyt täytyy sanoa että mopo on käynnistynyt ja...
> olioiden rakentamiseen ehkäpä luokkia A, B ja C, mutta seuraavaksi käytänkin
> luokkia B, C ja D. Mihin tässä ajatusmallissa tarvitaan "ohjelman" käsitettä
> lainkaan? Tai no, voinhan minä ottaa tekemistäni luokista jonkin osajoukon,
> niputtaa ne yhdeksi muille ihmisille jaettavaksi paketiksi ja kutsua näin
> syntyvää rakennetta "ohjelmaksi". Mutta miksi?
Siksi koska näin on.
Maailmassa on pultteja ja muttereita ja rattaita.
Kun niistä kootaan tietty joukko, sitä kutsutaan koneeksi.
Onneksi insinöörit eivät vielä "ole tajunneet" unohtaa koko koneen
käsitettä ja viskellä vain pultteja ja muttereita ja rattaita ympäriinsä.
Olio-ohjelmoinnilla voidaan mallintaa proseduraalista paremmin
ympäräivää maailmaan, mutta ei sitä pidä tehdä sen itsensä
vuoksi.
Jo lähestymistapa on älytön.
Aluksi oli olioita! Aluksi oli pultteja (kohta joku ottaa pulttia :-)!
Ei suinkaan. Aluksi on ongelma! Ongelmasta voidaan hahmottaa
olioita. Oliot voivat ratkaista ongelman hoitamalla jokainen
oman osansa ja kertomalla tietojaan toiselle oliolle.
Jonkun pitää pitää huolta että tämä yhteistyö toimii.
Se on ohjelma. Se on kone.
Seuraavaa ohjelmaa varten saattaa löytyä jotakin käyttökelpoista
vanhoista olioista. Sama pultti voi käydä seuraavaankin koneeseen.
Mutta pultti ei ole sen takia että se on pultti. Se on siksi
että sitä voi käyttää apuna kun konetta rakennetaan.
Tuolla sinun ehdotuksella eivät ikinä opi suunnittelemaan niitä
olioita. Kukaan ei voi tehdä toimivaa pulttia jos ei ole
ensin selvillä siitä, mihin sitä pulttia tullaan käyttämään?
Katsoitko niitä mun Linja_auto ja ja erityisesti Astia esimerkkejä.
Niissä on tietyssä mielessä ensin se ongelma ja
siitä löytyy rajapinta luokille. Sitten niiden rajapintojen
toteuttaminen on tasan sitä normaalia proseduraalista ohjelmointia,
siitä ei päästä yhtään mihinkään.
Siksi en ole koskaan katunut että ensin opetan sen proseduraalisen
puolen ja ajattelemaan algoritmejä. Ilman niitä ei synny
metodeja. Ja mitään ei tarvitse unohtaa.
Kaiken lisäksi maailmassa tarvitaan vieläkin tavallisia aliohjelmia.
Javan Math? Entä jos String-luokassa on jotakin mikä ei riitä.
Sitä ei voi periä. Miten parannat tilannetta? Teet aliohjelman
jolle se String viedään parametrina ja aliohjelma (funktio) palauttaa
tietyllä tavalla muokatun jonon. En ymmärrä miten tämän voisi
hoitaa olioiden avulla?
Kohta ollaan samassa tilanteessa kuin matemaatikot parhaimmillaan.
Ensin todistetaan leegio lemmoja ja sitten usean luennon jälkeen
liimataan lemmat yhteen ja kappas, hokkus pokkus, niistä syntyy
kuin syntyykin se kaivatun lauseen todistus. Ja sitten ihmetellään
miksi lukion jälkeen ei opita matematiikkaa...
Uskallatko mennä salin eteen ja sanoa: "Antakaa mulle ongelma niin
teen siitä tässä teidän edessä toimivan ohjelman?"
Mietippäs miten sitä lähdet tekemään. Tuskin alusta asti bottom-up
keksimällä joukkoa olioita joilla on kivoja metodeja?
Sinun kirjassa ei ole mitään vinkkiä siitä, miten tehdään
toimiva ohjelma johonkin ongelmaan? Ei muuten ole monessa
muussakaan :-) Se on se sama asia missä opiskelijan pitäisi
itse tajuta ettei matemaatikko oikeasti ensin niitä lemmoja keksi
vaan lähtee etenemään ja paloittelemaan ongelmaa ja toteaa
että jos tuon voin todistaa niin pääsen eteenpäin. Sen lemman
voi todistaa samantien (bottom up) tai voi jatkaa eteenpäin ja
jättää todistuksen myöhemmäksi (top-down) jne.
En ole ikinä nähnyt merkittävää eroa matemaattisen ajattelun
ja ohjelmoinin välillä. Siksi kannatan matematiikan
perusopintoja tietotekniikan linjalla. Se opettaa ajattelemaan.
(Tässä Antti Valmari on erimieltä :-)
Ja soveltamaan samaa ajattelumallia muidenkin ongelmien
ratkomiseen.
Vesa
Jouko Holopainen
> * Jouko Holopainen <jh...@gnosis.pp.invalid>:
>> (X)Emacsissa on m.m. JED.
>
> olisiko tähän jotain suorempaa pointtia, en saanut kuin jed
> -editorilinkkejä haettua. Ei sentään 'jde' (joka näyttää olevan java
> -specifinen)?.
Ei, kyllä tarkoitin jde:tä. Sori kirjoitusvirheeni. Se on tosin Java
spesifinen, ja todellakin emacsien suurin puute on tuo täydennyksen
puute. Tätä paikkaa erittäin hyvin "dabbrev-expand" (joka mulla on
f2:ssa). Hyvin mutta ei täydellisesti.
>> Kun kerran on oppinut, että editori sisentää oikein 99.9% tapauksista,
>> ei kertakaikkiaan kestä huonompia. M.m. tästä syystä moni IDE ei
>> "kelpaa".
>
> Jos se on integroitu, niin miksi se muka näyttäisi sen väärin?
Näyttäisi?
Ei, vaan että XEmacsiissa tabulaattorin painallus missä tahansa
sisentää k.o. rivin (erittäin harvoin väärin).
>> Tässä (X)Emacs on aivan hävyttömän paljon edellä kaikkea muuta¹.
>
> Tuota, kerropas vaikka joku esimerkkitapaus ja miten sinä teet.
> oletetaan kieleksi C, ja sen että tiedät missä kohti asiat menevät
> väärin (esim. joku yksittäinen funkkari joka antaa väärät arvot ulos).
Tämä riippuu niin paljon tapauksesta. Yleensä eka yritys on pistää
tulostus k.o. funkkariin, että mitä saatiin ja mitä palautetaan (plus
ehkä johonkin strategiseen kohta).
Tällöin, kun funkkaria kutsutaan "useammin" (satoja kertoja), ei tarvi
painaa "continue" debugginäppäintä pohjaan - ja missata *se* 99s kerta.
> esim. watcomissa teen niin että käännän ohjelman, avaan sen debuggeriin,
> menen siihen objektiin missä funkkari on, naksutan funkkarin kohdalle
> breakpoint ja annan ohjelman ajaa. kun se pysähtyy breakpointtiin,
> askellan ja katson arvoja, mahdollisesti mennen 'sisään' toisiin
> funktiokutsuihin.
Lisäksi itselläni liian usein käy niin, että jos debuggeri on
pisteessä A kauemmin kuin X s (0.1 < X < 10), niin jossain (muualla)
jokin timeri laukeaa (tai muu ajoitusongelma) ja ...
Ajoituksesta johtuen tulostan hyvin usein tiedostoon - se on
nopeampaa¹ ja vaikka tulostus olisi suurikin, niin lessillä löytää.
¹ ei tietenkään takaa mitään.
Linuxissa ddd:llä homma menee melko tarkkaan samoin (kuin Watcomilla).
Kalle Kivimaa
> Missä vaiheessa tässä pääsee muuttamaan arvoja jotta näkisi mitä muuta
> funkkarissa on vialla?
Sitä vartenhan ovat ne Unit-testit :)
--
* Military intelligence is a contradiction in terms. (Groucho Marx) *
Virtanen Antti
>>> Ihan rehellisesti, mitä ominaisuuksia nyytistimessäsi on, joita ei
>>> voisi toteuttaa komentorivipohjaisesti?
>>
>> Voihan ne ominaisuudet toteuttaa vaikka
>> äänen/sähköshokkien/kirjekyyhkyjen välityksellä kommunikoiden sen
>> sijaan että käytetään jotain monitoria ja tekstiä.
>
> Säälittävää... etkä parempaan pysty, vaikka "tiedät", paremmin?
En ymmärrä mitä yrität sanoa.
>>> Minä käytän editoria, joka tukee tarpeitani, ei joka näyttää hyvältä.
>>
>> Niin. Luulen että kaikki muutkin käyttävät sitä editoria joka heille
>> parhaiten sopii. Useimmille se graafinen IDE on se paras
>> vaihtoehto. Ja monille se miellyttävä ulkonäkö on ainakin
>> alitajuisesti tärkeä.
>
> On se hyvä, että sinä "tiedät", paremmin.
No eiköhän useimmat ihmiset käytä sitä työkalua jota pitävät parhaana,
kustannustekijöiden ja työnantajan yms. reunaehtojen puitteissa
tietysti. Samalla tavallahan ihmiset valitsevat asuntonsa, autonsa,
ruokansa jne.
Jos epäilet että pitävätkö ihmiset graafista IDEa parhaana niin kyllä
ne aika suosittuja ovat. Jos ne olisivat kaikkien mielestä huonompia
kuin tekstipohjaiset systeemit ja xemacsit niin kaikki varmaan
käyttäisi tekstipohjaisia systeemejä? Ilmaisikin kun ovat nuo
jälkimmäiset yleensä.
>>> Kolikon toinen puoli on, että lähes jokaikinen graafinen ohjelma
>>> _vaatii_ (tarpeettomasti) hiiren heiluttelua. Tekstipohjaiset ovat
>>> siksi joskus todella huomattavasti nopeampia käyttää.
>>>
>>> Vrt pankit, ja virkailijoiden käyttämät koneet.
>>
>> Tekstipohjainen on varmaan nopeampi, mutta oppimiskynnys on yleensä
>> kovempi kuin graafisessa kälissä, koska se nopeus vaatii käytännössä
>> näppäinkomentojen ulkoaopettelua.
>
> Täsmälleen päinvastoin - minun kokemuksella. Mutta sinähän asian
> "tiedät", paremmin.
Hohhoijaa. Toiset oppivat tekemään voltin ensi yrityksellä. Useimmat
eivät opi toisellakaan kerralla. Mitä sitten? Asiaa on tutkittu,
joten tästä oppimiskynnys/tekemisen nopeus -asiasta graafisten ja
tekstipohjaisten järjestelmien välillä on turha väitellä.
>> Nykyiset aloittelevat ohjelmoijat
>> ovat syntyneet graafisten systeemien ja hiirenheiluttelun
>> mailmaan. Arvaa kuulostaako joku tekstipohjainen hiiretön systeemi
>> heistä antiikkiselta?
>
> EVVK. Kaikki eivät pysy aloittelijoina, asia jonka sinäkin, ehkä,
> joskus "tiedät", paremmin.
Kirja oli kuitenkin aloittelijoille suunnattu.
Jos ymmärsin oikein, niin mielestäsi kaikkien pitäisi käyttää sinun
lempisysteemiäsi ohjelmointiin ja muut näkemykset ovat vääriä.
Koodaan itse käytännössä pelkästään (x)emacsilla, mutta ei sillä ole
minusta väliä jos joku muu koodaa jollain muulla. Kuten sanoin, toinen
tykkää tummasta ja toinen vaaleasta.
//Antti
Matti Rintala
> Maailmassa on pultteja ja muttereita ja rattaita.
> Kun niistä kootaan tietty joukko, sitä kutsutaan koneeksi.
> Onneksi insinöörit eivät vielä "ole tajunneet" unohtaa koko koneen
> käsitettä ja viskellä vain pultteja ja muttereita ja rattaita ympäriinsä.
No, olio-puolella tuo "viskellään vain pultteja"-mentaliteetti tuntui
olevan esillä pahimman markkinointihuuman aikana vuosia sitten, mutta
luulin että se olisi jo mennyt ohi. Mutta näköjään ei. :)
> Olio-ohjelmoinnilla voidaan mallintaa proseduraalista paremmin
> ympäräivää maailmaan, mutta ei sitä pidä tehdä sen itsensä
> vuoksi.
Amen. Ja on paljon ongelmia ja osa-ongelmia, joihin olioajattelu ei
välttämättä kovin hyvin sovi. Niihin sitä ei yleensä kannata käyttääkään,
ellei sitten ohjelman toteutuskieli (tai muut ympärillä olevat ohjelman
osat) siihen pakota.
> Ei suinkaan. Aluksi on ongelma! Ongelmasta voidaan hahmottaa
> olioita. Oliot voivat ratkaista ongelman hoitamalla jokainen
> oman osansa
...
> Seuraavaa ohjelmaa varten saattaa löytyä jotakin käyttökelpoista
> vanhoista olioista. Sama pultti voi käydä seuraavaankin koneeseen.
... ja sitten huomataan, ettei se pultti sovikaan ihan samanlaisena siihen
seuraavaan koneeseen, vaan sitä pitää vähän viilata. Sitä seuraavan koneen
kanssa käy täsmälleen samalla tavalla. Sitten päätetään yksittäisten
ongelmien lisäksi analysoida koko ongelma-alue ja miettiä, mitä yhteistä
jo rakennetuilla ja mahdollisesti rakennettavilla koneilla on keskenään.
Tämän tuloksena saadaan vihdoin pultti, jonka saa sopimaan ilman muutoksia
kohtalaisen helposti tuleviinkin koneisiin. Kannattaa lukea Czarneckin ja
Eiseneckerin kirja "Generative Programming".
Näin se on ollut oliokirjastoissakin. STL tai käyttöliittymäkirjastot
eivät todellakaan ole syntyneet niin, että joka vaan on kirjoittanut
luokkia, vaan olemassa olevia sovelluksia ja käyttöliittymäkirjastoja yms.
on analysoitu ja niiden pohjalta pyritty luomaan mahdollisimman
yleiskäyttöinen arkkitehtuuri luokkineen. Siihen en ota kantaa, kuinka
hyvin Javan kirjastot tässä ovat onnistuneet.
> Kaiken lisäksi maailmassa tarvitaan vieläkin tavallisia aliohjelmia.
> Javan Math? Entä jos String-luokassa on jotakin mikä ei riitä.
> Sitä ei voi periä. Miten parannat tilannetta? Teet aliohjelman
> jolle se String viedään parametrina ja aliohjelma (funktio) palauttaa
> tietyllä tavalla muokatun jonon. En ymmärrä miten tämän voisi
> hoitaa olioiden avulla?
Jep. Kyllä tavallisilla proseduureilla ja aliohjelmilla on paikkansa
silloin, kun halutaan nimenomaan tehdä toiminnallisuutta, jossa ei ole
säilytettävää tilaa (jota pitäisi tallettaa olioon), eikä tuo
toiminnallisuus syystä tai toisesta selkeästi kuulu minkään luokan
vastuulle. Javat Math nyt on malliesimerkki. Luokka, josta ei ikinä tehdä
olioita, ja joka on luokka vain siksi, että Java ei muuta vaihtoehtoa anna.
Toinen hyvä esimerkki on C++:n STL:n algoritmit, jotka on toteutettu
luokkien ulkopuolisina funktiomalleina (tai miksi templateja sitten
haluaakin kutsua). Sillä, että ne on pidetty luokkien ulkopuolella, on
saatu lisättyä huomattavasti STL:n geneerisyyttä ja yleiskäyttöisyyttä.
Ja Vesalle kiitos sen tosiasian muistuttamisesta, että opetuksen pitäisi
lähteä aina ongelmasta ja sen ratkaisemisesta, jotta hommaan saadaan oikea
motivaatio. Matematiikan tapauksessa ihmiset kyllästyvät ilman tuota
motivaatiota, mutta ikävä kyllä olio-ohjelmoinnissa jostain syystä
yksittäiset luokatkin ovat niin vinkeitä kapistuksia, että ihmiset
innostuvat niillä leikkimiseen ja unohtavat, minkä takia niitä luokkia
ollaan tekemässä. :)
--
------------- Matti Rintala ------------ matti....@tut.fi ------------
If you do not climb you will not fall. This is true. But is it that bad to
fail, that hard to fall? Sometimes you wake, and sometimes, yes, you die.
But there is a third alternative. - from Fear of Falling by Neil Gaiman
Jani Miettinen
> Itse olen huomannut Javaa opetteleville usein ongelmalliseksi
> muistaa, milloin hilavitkuttimella X on .length -kenttä ja
> milloin .length() -metodi.
Tällaiset ongelmat eivät kaipaa ratkaisukseen ehdotuksia oikeista
muodoista, vaan kunnollista nimeämiskäytäntöä. Siitä on nimittäin
iloa ylläpitovaiheessakin, eikä vain kirjoitusvaiheessa (ja kuten
kaikki tietysti tietävät, ylläpitovaiheen kesto on moninkertainen
verrattuna kirjoitusvaiheen kestoon).
--
Jeesaus auttaa, kun parasiitti tulee.
Julman valtakunnan asiat hoidetaan yhdessä.
Jani Miettinen
> Kaiken lisäksi maailmassa tarvitaan vieläkin tavallisia
> aliohjelmia. Javan Math? Entä jos String-luokassa on jotakin
> mikä ei riitä. Sitä ei voi periä. Miten parannat tilannetta?
> Teet aliohjelman jolle se String viedään parametrina ja
> aliohjelma (funktio) palauttaa tietyllä tavalla muokatun
> jonon. En ymmärrä miten tämän voisi hoitaa olioiden avulla?
Muuten hyvään argumentointiin tuo ei minusta sovi laisinkaan. Tuo
mainitsemasi pätee ehkä Javaan ja muutamaan muuhunkin oliokieleen,
mutta nuo eivät ole yleisesti olioparadigman rajoitteita.
Aleksi Kallio
>>muistaa, milloin hilavitkuttimella X on .length -kenttä ja
>>milloin .length() -metodi.
> Tällaiset ongelmat eivät kaipaa ratkaisukseen ehdotuksia oikeista
> muodoista, vaan kunnollista nimeämiskäytäntöä. Siitä on nimittäin
> iloa ylläpitovaiheessakin, eikä vain kirjoitusvaiheessa (ja kuten
> kaikki tietysti tietävät, ylläpitovaiheen kesto on moninkertainen
> verrattuna kirjoitusvaiheen kestoon).
Kunnollinen nimeämiskäytäntö on hyvä asia, mutta ei ratkaise ongelmaa
kokonaan. Jotta nimi kertoisi metodin/luokan/yms... toiminnasta yhtä
paljon kuin esimerkiksi Netbeansin tarjoama JavaDoc-vinkki, niin sen
pitäisi olla usean lauseen pituinen. Eli joskus joutuu katsomaan
referenssiä, ja on kätevää jos se on "at my fingertips". Selviäähän sitä
ilmankin, mutta kovasti olen itse ainakin iloinnut code completion +
javadoc -härdellistä.
Jari Vuoksenranta
> Niko Kiirala <niko...@mbnet.fi> wrote:
>> [snip] Linuxissa on toisin [snip]
> <nipotusta> Unix shellit yleensä. </nipotusta> :)
tcshk, tcshk, eipäs yleistetä.
--
Jari Vuoksenranta
"170 226 2245 3042 400"
Sami Autio
> Tämän tuloksena saadaan vihdoin pultti, jonka saa sopimaan ilman muutoksia
> kohtalaisen helposti tuleviinkin koneisiin. Kannattaa lukea Czarneckin ja
> Eiseneckerin kirja "Generative Programming".
Onko "domain specific modelling" :ista kirjoitettu yleiskattavaa
ja tasalaadukasta teosta?
Asko Saura
> Ilkka Kokkarinen <imk...@rogers.com> wrote:
>> (153 sivua, 880 kilotavua). Kommentteja ja parannusehdotuksia otetaan
>> mielihyvin vastaan.
> Täällä onkin kovasti käyty keskustelua Java-puolen
> ominaisuuksien käsittelystä, joten minä mainitsen nyt tuon loppuosan
> käsittelystä. Oma lukunsa ohjelmistotuotannosta (prosessimalleista,
> testauksesta jnpp.) on varmastikin harkittu veto, mutta täytyykö siellä
> nyt sitä vesiputousmallia sitten selittää.
Mainitun selityksen alussa erikseen sanotaan, että nyt puhutaan
vesiputousmallista, koska se "on suoraviivaisuutensa vuoksi varmaankin
selkein ohjelmistoprosessin jaottelu". Perustelu on oikea - kappale 7.1.1
etenee ymmärrettävällä tavalla siten, että ohjelmoinnin alkeita vähän
oppinut kykenee luultavasti seuraamaan selitystä.
--
Mä oon matkalla sinne missä
-a...@iki.fi - http://iki.fi/as/
Arto V. Viitanen
Virtanen> In article
Virtanen> <8pkGa.77134$j9%.75168@news04.bloor.is.net.cable.rogers.com>,
Virtanen> Ilkka Kokkarinen wrote:
>> Nuo kaksi edellistä esimerkkiä muuten vahvistavat käsitystäni siitä, että
>> Javakin on vielä liian matalan tason kieli ohjelmoinnin perusopetukseen.
>> Kieli pitäisi suunnitella siten, että yhtäsuuruus on yhtäsuuruutta
>> olioiden tyypistä riippumatta, ja jos viitteitä on olemassa kielen
>> abstraktiotasolla, niiden yhtäsuuruus on omanlaistaan yhtäsuuruutta.
Virtanen> Javassa ei ole tässä asiassa periaatteessa
Virtanen> ristiriitaa. Primitiivityypit unohtaen == tarkoittaa
Virtanen> olioviitteiden yhtäsuuruutta ja equals -metodi olioiden
Virtanen> sisällöllistä yhtäsuuruutta. Ongelmia tulee vain siitä että ==
Virtanen> joskus näyttää toimivan sisällön yhtäsuuruusvertailuna, etenkin
Virtanen> merkkijonojen kohdalla.
Javassa on ristiriita, ja se on siinä, että String on luokka. Luontevaa
olisi sama käytäntö kuin numeroilla ja totuusarvoilla, eli tietotyyppi string
ja luokka String. Tai myöntää että Microsoft on oikeassa (C#) ja tehdä
kaikista olioita. Niinpä string muuttujilla == olisi yhtäsuuruus vertailu ja
String muuttujilla id -yhtäsuuruus.
--
Arto V. Viitanen a...@cs.uta.fi
University of Tampere, Department of Computer and Information Sciences
Tampere, Finland http://www.cs.uta.fi/~av/
Lauri Alanko
> Javassa on ristiriita, ja se on siinä, että String on luokka.
Ei siinä ole mitään ristiriitaista. On _epäintuitiivista_ että
merkkijonoja esitetään olioina, joilla on identiteetti, mutta tämä pätee
_kaikkiin_ "puhtaisiin arvoihin", joita oliokielissä pyritään
mallintamaan olioilla. Bignumit java.math.*:ssa ovat ihan samassa
asemassa kuin Stringit. Ja java.net.InetAddress, ja itse asiassa melkein
kaikki, jolle vain voidaan määritellä tilasta riippumaton konsistentti
equals-metodi. Ongelma on kyllä olemassa, mutta se on yleinen puute itse
_kielessä_ eikä mitenkään erityisesti String-keskeinen.
Lauri Alanko
l...@iki.fi
Virtanen Antti
> Virtanen> Javassa ei ole tässä asiassa periaatteessa
> Virtanen> ristiriitaa. Primitiivityypit unohtaen == tarkoittaa
> Virtanen> olioviitteiden yhtäsuuruutta ja equals -metodi olioiden
> Virtanen> sisällöllistä yhtäsuuruutta. Ongelmia tulee vain siitä että ==
> Virtanen> joskus näyttää toimivan sisällön yhtäsuuruusvertailuna, etenkin
> Virtanen> merkkijonojen kohdalla.
>
> Javassa on ristiriita, ja se on siinä, että String on luokka. Luontevaa
> olisi sama käytäntö kuin numeroilla ja totuusarvoilla, eli tietotyyppi string
> ja luokka String. Tai myöntää että Microsoft on oikeassa (C#) ja tehdä
> kaikista olioita. Niinpä string muuttujilla == olisi yhtäsuuruus vertailu ja
> String muuttujilla id -yhtäsuuruus.
Se että kaikki eivät ole Javassa olioita, on suunnitteluhetken
sanelema kompromissi tehokkuuden nimissä. Jos Javaa rakennettaisiin
nyt, luultavasti päädyttäisiin siihen että kaikki tietotyypit ainakin
näyttävät olioilta.
Asia tulee joka tapauksessa muuttumaan versiossa 1.5 siten että
primitiivityyppien ja vastaavien olioiden välillä konvertointi on
automaattisempaa.
http://java.sun.com/features/2003/05/bloch_qa.html
Se on totta että kaikilta osin Java ei ole onnistunut
tekele. Epäkohtia on korjattu sitä mukaa kun niitä on havaittu, mutta
painolastia on alkanut kertyä koska yhteensopivuutta alaspäin ei
haluta rikkoa. Enpä tosin ole nähnyt mitään muutakaan
ohjelmointikieltä, jota voisin pitää täysin onnistuneena.
--
// Antti Virtanen -//- http://www.students.tut.fi/~virtanea -//- 050-4004278
--
"Ei sanat salahan joua eikä luottehet lovehen;
mahti ei joua maan rakohon, vaikka mahtajat menevät."
Jouko Holopainen
> Tai myöntää että Microsoft on oikeassa (C#) ja tehdä
> kaikista olioita.
C#:ssä kaikki ei ole olioita, vaan siinä on sama moka, eli löytyy
primitiivityypit.
C#:ssä on "boxing" eli automaattinen konversio intin ja Integerin
(jne) välillä.
Tämä on tulossa Javaankin. Typerää (intin jne poistaminen on se
oikeampi tapa, IMHO):
X
> (jne) välillä.
>
> Tämä on tulossa Javaankin. Typerää (intin jne poistaminen on se
> oikeampi tapa, IMHO):
Samalla voi hyvästellä Javan siirrettävyyden ja versioiden ylöspäin
yhteensopivuuden! Primitiivityypit ovat tehokkaita ja taloudellisia. Kenen
asiakkaiden koneissa on ylimääräisiä resursseja, käsi ylös nyt!
C on tehokas kieli, Java ei. Tuntuu hullunkuriselta, mutta C-ohjelmoijat
kiinnittävät huomiota koodinsa tehokkuuteen, kun taas Java-apinat veisaavat
viis tehokkuudesta ja taloudellisuudesta, vaikka juuri heidän/niiden pitäisi
tähän erikoisesti kiinnittää huomiota. Ei primitiivityypeillä tietysti voi
koko maailmaa pelastaa, mutta "sama kaiku on askelten" kautta linjan
muutenkin.
Jyrki O Saarinen
: C on tehokas kieli, Java ei. Tuntuu hullunkuriselta, mutta C-ohjelmoijat
Perusteluja.
: kiinnittävät huomiota koodinsa tehokkuuteen, kun taas Java-apinat veisaavat
: viis tehokkuudesta ja taloudellisuudesta, vaikka juuri heidän/niiden pitäisi
Perusteluja.
Jyrki O Saarinen
: C on tehokas kieli, Java ei. Tuntuu hullunkuriselta, mutta C-ohjelmoijat
Perusteluja tähän ensimmäiseen väitteeseen, kiitos?
: kiinnittävät huomiota koodinsa tehokkuuteen, kun taas Java-apinat veisaavat
: viis tehokkuudesta ja taloudellisuudesta, vaikka juuri heidän/niiden pitäisi
Ja myös tähän.
Aleksi Kallio
>> oikeampi tapa, IMHO):
> Samalla voi hyvästellä Javan siirrettävyyden ja versioiden ylöspäin
> yhteensopivuuden! Primitiivityypit ovat tehokkaita ja taloudellisia. Kenen
> asiakkaiden koneissa on ylimääräisiä resursseja, käsi ylös nyt!
Kenen projekteissa on ylimääräistä aikaa kaikenlaiseen nysväämiseen,
käsi ylös nyt!
> C on tehokas kieli, Java ei. Tuntuu hullunkuriselta, mutta C-ohjelmoijat
> kiinnittävät huomiota koodinsa tehokkuuteen, kun taas Java-apinat veisaavat
> viis tehokkuudesta ja taloudellisuudesta, vaikka juuri heidän/niiden pitäisi
> tähän erikoisesti kiinnittää huomiota.
Nyt vedettiin väitettä hatusta oikein Porvoon mitalla.
Kyllä Java-simpanssit veisaavat myös tehokkuuden virsiä. Käypäs
huviksesi surffailemassa internetiä ja selvittämässä vaikka kuinka monta
erilaista profilointityökalua Javalle on saatavissa, jos et ole niin
vielä tehnyt.
Primitiivityyppien tasolla olevilla optimoinneilla saavutetaan
vakiokertoimisia nopeusparannuksia, yleensä luokkaa "joitamia
kellojaksoja" - joka silmukassa on jo ihan kiva juttu. Javassa sellainen
kuitenkin on pääasiassa virtuaalikoneen tekijöiden hommaa. Sen sijaan
paljon pahempia pullonkauloja löytyy vähän korkeammalta tasolta, muistin
käsittelystä ja säikeistyksestä. Silloin puhutaan enemmän järjestelmän
logistiikasta, kuin (lähes) bittitason logiikasta.
Eli kyllä myös javangutangit panostavat tehokkuuteen ja
taloudellisuuteen. Java-sovellukset ovat vaan korkeammalla
abstraktiotasolla kuin C-sovellukset, joten keinot ovat myös erilaisia.
Yksi EJB-komponentteihin tehty optimointi vaikuttaa enemmän kuin
pussillinen yksittäisten muuttujien tasolla olevia optimointeja.
Toni Nikkanen
> Eli kyllä myös javangutangit panostavat tehokkuuteen ja
> taloudellisuuteen. Java-sovellukset ovat vaan korkeammalla
> abstraktiotasolla kuin C-sovellukset, joten keinot ovat myös
> erilaisia. Yksi EJB-komponentteihin tehty optimointi vaikuttaa enemmän
> kuin pussillinen yksittäisten muuttujien tasolla olevia optimointeja.
Yksi perusongelma näissä iänikuisissa tehokkuusväittelyissä onkin se,
että tyypillisesti Java-ihmiset ja C-ihmiset ohjelmoivat aivan eri
universumeissa. En ole optimoimassa mitään EJB-komponentteja jossain
sulautetussa vehkeessä, enkä toisaalta koodaamassa jotain enttöprais
bisneslogiikkahärpätintä C:llä.
X
> vakiokertoimisia nopeusparannuksia, yleensä luokkaa "joitamia
> kellojaksoja" - joka silmukassa on jo ihan kiva juttu. Javassa sellainen
> kuitenkin on pääasiassa virtuaalikoneen tekijöiden hommaa. Sen sijaan
> paljon pahempia pullonkauloja löytyy vähän korkeammalta tasolta, muistin
> käsittelystä ja säikeistyksestä. Silloin puhutaan enemmän järjestelmän
> logistiikasta, kuin (lähes) bittitason logiikasta.
Juuri tuollaisissa korkeamman tason jutuissa käytännön Java-koodissa monasti
heitetään asiakkaan kalliita resursseja oikein kaksi käsin menemään koodarin
taitamattomuuden vuoksi.
Ongelma ei niinkään ole virtuaalikoneessa. Ongelma on käytännön koodareiden
Java-koodissa. Java tai sen oppikirjat opettavat tehokkuuden ja
taloudellisuuden kannalta huonoille tavoille. Ehkä "olio-kielet" yleensäkin
tekevät niin : huomio keskittyy ongelman jakamiseen olioiksi. Mitä useampi
olio, sitä komeampi projekti. Tärkeät perusasiat jäävät unholaan.
Omaatuntoaan voi sitten koettaa rauhoitella vaikkapa laskemalla paljonko
wepissä on profilointityökaluja...
Asiakas kiroilee ensin hiljaa itsekseen, mutta pitemmän päälle koodari ei
voi menestyä asiakastaan paremmin. Jos asiakkaalla alkaa pyyhkiä huonosti,
joutuu koodari leikkaamaan kokis- ja pizza-budjettiaan vastaavasti.
Luokkia käytetään aivan tarpeettomastikin. Ei ole tavatonta nähdä Javassa
käytettävän java.math.BigDecimal -olioita laskennassa, jossa 3:n merkitsevän
numeron tarkkuus riittää, koska lähtötiedot eivät ole sen tarkempia. Äly
hoi, älä jätä!
Juuri tällaisiiin asioihin pitäisi mielestäni Javan alkeiskirjassa
kiinnittää huomiota. Kieli ei ole helpompi käyttää sen takia, että siinä
(luokkakirjastossa) on valmiina korkeamman tason valmiuksia. Päinvastoin,
se on vaativampi!
Aleksi Kallio
>> logistiikasta, kuin (lähes) bittitason logiikasta.
> Juuri tuollaisissa korkeamman tason jutuissa käytännön Java-koodissa monasti
> heitetään asiakkaan kalliita resursseja oikein kaksi käsin menemään koodarin
> taitamattomuuden vuoksi.
Ilmeisesti me ohjelmoimme jollain eri Javalla (ehkä rinnakkaisissa
universumeissa?), koska minusta Javan ja siihen liittyvien tekniikoiden
(esim. EJB:n ja RMI:n) suorituskykyyn kiinnitetään paljon huomiota.
Hakemalla Googlella "EJB performance" tai "Java performance" saa jotain
kuvaa. Tai katsomalla mistä JavaOnessa puhuttiin tänä vuonna.
On totta että detaljitason optimointiin ei kiinnitetä niin paljon
huomioita. Resursseja on rajallisesti, joten ne kannattaa käyttää siihen
mistä merkittäviä nopeushyötyjä on todennäköisimmin luvassa. Javalla
ohjelmoidaan useimmiten verkossa toimivia palvelinjärjestelmiä, joten
silloin pullonkaulat ovat useimmiten korkeammalla tasolla. Jos tehdään
vaikkapa tiukkaa 3D-peliä, niin silloin optimoinnissa pitää keskittyä
grafiikkarutiinien nippeleihin. En vaan välttämättä valitsisi Javaa
tuohon hommaan...
> Ongelma ei niinkään ole virtuaalikoneessa. Ongelma on käytännön koodareiden
> Java-koodissa. Java tai sen oppikirjat opettavat tehokkuuden ja
> taloudellisuuden kannalta huonoille tavoille. Ehkä "olio-kielet" yleensäkin
> tekevät niin : huomio keskittyy ongelman jakamiseen olioiksi. Mitä useampi
> olio, sitä komeampi projekti.
Hyvässä Java-ohjelmassa käytetään paljon olioita, se on totta. Ja
olioiden luominen (tai lähinnä tuhoaminen) maksaa, se on totta. Mutta
oliot vaan kuuluvat olio-ohjelmointiin. Joissain tilanteissa
epäoliomainen ratkaisu voi olla merkittävästi nopeampi ja siten järkevä
optimointi, mutta sen merkittävyyden tietää vasta kun on kasannut
järjestelmän ja pystyy mittaamaan sen toimintaa. Hyviä arvauksia voi
tehdä, mutta ne ovat parhaimmillaankin vain hyviä arvauksia.
Parempi hidas ja toimiva, kuin nopea ja virheellinen. Olettekin
saattaneet kuullakin lausahduksen: "Premature optimization is the root
of all evil"...
> Tärkeät perusasiat jäävät unholaan.
Haloo! Ongelman jakaminen olioiksi on juuri se tärkein peruasia kun
opetetaan olio-ohjelmoinnin alkeita!
> Omaatuntoaan voi sitten koettaa rauhoitella vaikkapa laskemalla paljonko
> wepissä on profilointityökaluja...
Ei niillä rauhoiteta omaatuntoa, vaan etsitään että mikä todellisuudessa
on pullonkaula ja mitä pitää optimoida. Kaikkea kun ei voi viilata,
vaikka kuinka tekisi mieli.
> Luokkia käytetään aivan tarpeettomastikin. Ei ole tavatonta nähdä Javassa
> käytettävän java.math.BigDecimal -olioita laskennassa, jossa 3:n merkitsevän
> numeron tarkkuus riittää, koska lähtötiedot eivät ole sen tarkempia. Äly
> hoi, älä jätä!
Millä tavalla tämä liittyy tähän asiaan? "Luokat on pahoja, koska jos
valitsee väärän luokan niin se ei sovellu tehtävään".
> Juuri tällaisiiin asioihin pitäisi mielestäni Javan alkeiskirjassa
> kiinnittää huomiota. Kieli ei ole helpompi käyttää sen takia, että siinä
> (luokkakirjastossa) on valmiina korkeamman tason valmiuksia. Päinvastoin,
> se on vaativampi!
Olen samaa mieltä että korkean tason kieli on tietyssä mielessä
vaativampi. Assemblyhan on älyttömän helppo kieli oppia (jos tuntee
prosessorin arkkitehtuurin).
Mutta en ole samaa mieltä siitä, että Javan alkeiskirjoissa pitäisi
opettaa optimointia. Jos on niin pönttö että palkkaa pelkästään
alkeiskirjat lukeneita ohjelmoijia, niin oma on häpeänsä. Optimointi on
tärkeä taito, mutta ensin pitää opetella ohjelmointi.
Virtanen Antti
>> paljon pahempia pullonkauloja löytyy vähän korkeammalta tasolta, muistin
>> käsittelystä ja säikeistyksestä. Silloin puhutaan enemmän järjestelmän
>> logistiikasta, kuin (lähes) bittitason logiikasta.
>
> Juuri tuollaisissa korkeamman tason jutuissa käytännön Java-koodissa monasti
> heitetään asiakkaan kalliita resursseja oikein kaksi käsin menemään koodarin
> taitamattomuuden vuoksi.
Millä perusteella Java-ohjelmoijat ovat oleellisesti taitamattomampia
kuin jollain muulla kielellä koodaavat henkilöt?
Tiedän että C:llä tehdään nykyisin tyypillisesti sulautettuja
järjestelmiä, joisssa tehokkuus ja muistinkulutus ovat paljon
tärkeämpiä reunaehtoja ohjelmalle, mutta ei se tarkoita että
C-ohjelmoijat olisivat olennaisesti taitavampia.
Usein on niin että koodarin aika on huomattavan kallista verrattuna
konetehoon tehtäessä jotain bisnessovelluksia. Vaikka koodaaja osaisi
optimoida koodia nopeammaksi, niin se ei aina ole rationaalista.
> Ongelma ei niinkään ole virtuaalikoneessa. Ongelma on käytännön koodareiden
> Java-koodissa. Java tai sen oppikirjat opettavat tehokkuuden ja
> taloudellisuuden kannalta huonoille tavoille.
En tiedä mitä "käytännän koodareita" tarkoitat, mutta mailmasta löytyy
jokaisella kielellä tehtyä huonoa ja hyvää koodia.
> Ehkä "olio-kielet" yleensäkin
> tekevät niin : huomio keskittyy ongelman jakamiseen olioiksi.
> Mitä useampi
> olio, sitä komeampi projekti. Tärkeät perusasiat jäävät unholaan.
> Omaatuntoaan voi sitten koettaa rauhoitella vaikkapa laskemalla paljonko
> wepissä on profilointityökaluja...
Yleensä algoritmi ja ohjelman looginen jako osiin on se olennaisin osa
projektia. Ainakin niissä projekteissa joita yleensä Javalla
tehdään.
Siinä ei auta mitään loop unrollingit, precalc-taulut ja muut
haxxor-temput jos algoritmeja ja muuta ohjelman loogista rakennetta ei
osata tehdä hyvin.
> Asiakas kiroilee ensin hiljaa itsekseen, mutta pitemmän päälle koodari ei
> voi menestyä asiakastaan paremmin. Jos asiakkaalla alkaa pyyhkiä huonosti,
> joutuu koodari leikkaamaan kokis- ja pizza-budjettiaan vastaavasti.
Kyllä.
> Luokkia käytetään aivan tarpeettomastikin. Ei ole tavatonta nähdä Javassa
> käytettävän java.math.BigDecimal -olioita laskennassa, jossa 3:n merkitsevän
> numeron tarkkuus riittää, koska lähtötiedot eivät ole sen tarkempia. Äly
> hoi, älä jätä!
Yleinen virhe on kai toisinpäin, riippumatta kielestä.
> Juuri tällaisiiin asioihin pitäisi mielestäni Javan alkeiskirjassa
> kiinnittää huomiota. Kieli ei ole helpompi käyttää sen takia, että siinä
> (luokkakirjastossa) on valmiina korkeamman tason valmiuksia. Päinvastoin,
> se on vaativampi!
Korkeamman tason valmiudet antavat mahdollisuuden keskittyä
olennaisiin asioihin ohjelmia tehdessä. Siinä on toki se heikkous että
helposti koko tehokkuuspuoli unohtuu, mutta kyllä minusta kieli on
sitä helpompi käyttää mitä vähemmän juttuja täytyy keksiä uudestaan.
Tästä syystä ehdotinkin että Javan alkeiskirjoissakin voisi mainita
joitakin asioita tehokkaasti toimivan koodin kirjoittamisesta ja
yleisistä pullonkauloista.
Jouko Holopainen
> Primitiivityypit ovat tehokkaita ja taloudellisia. Kenen
> asiakkaiden koneissa on ylimääräisiä resursseja, käsi ylös nyt!
Eiffelissä ei ole inttiä, on vain Integer ja nopeusero on 1-2% tämän
takia. Tai oli 5v sitten.
> C on tehokas kieli, Java ei.
No jaa, eipä eroa valtavasti enää ole.
> Tuntuu hullunkuriselta, mutta C-ohjelmoijat
> kiinnittävät huomiota koodinsa tehokkuuteen, kun taas Java-apinat veisaavat
> viis tehokkuudesta ja taloudellisuudesta, vaikka juuri heidän/niiden pitäisi
> tähän erikoisesti kiinnittää huomiota.
Tuntuu todella hullunkuriselta takertua suorituskykyyn. Olipa kieli
mikä tahansa.
Jep, ennemmin tai myöhemmin softaan tulee "pullonkaula", mutta se ei
ole se taloudellisesti merkittävin asia (yleensä).
> Ei primitiivityypeillä tietysti voi
> koko maailmaa pelastaa, mutta "sama kaiku on askelten" kautta linjan
> muutenkin.
Aha, asmia kehiin?
X
Javassa
> > käytettävän java.math.BigDecimal -olioita laskennassa, jossa 3:n
merkitsevän
> > numeron tarkkuus riittää, koska lähtötiedot eivät ole sen tarkempia.
Äly
> > hoi, älä jätä!
>
> Millä tavalla tämä liittyy tähän asiaan? "Luokat on pahoja, koska jos
> valitsee väärän luokan niin se ei sovellu tehtävään".
Ei. Tähän ei pidä valita luokkaa lainkaan. Kolmen merkitsevän numeron
tarkkuus ei edellytä BigDecimal -olion käyttöä, vaan tuollainen laskenta on
taloudellisesti hoidettavissa primitiivityypeillä tarkkuuden siitä
kärsimättä. Tyyppinä int jos on kyse kokonaisluvuista ja float jos
liukuluvuista. Ei tarvita rajatonta tarkkuutta jota varten tuo (hieno)
luokka on tehty.
Asiasta sujuvasti toiseen:
Monasti olen kiinnittänyt oppikirjoissa huomiota tyyppien kirjoitustapaan
lauseen ensimmäisenä sanana. Lause voidaan aloittaa esim näin: Int on
primitiivityyppi. Javassa ei kuitenkaan ole Int -tyyppiä, vaan tyypin nimi
on int, siis pienellä alkukirjaimella.
On se niin väärin! Taas primitiivityyppejä sorsitaan ;-)
Matti Vuori
news:m34r22b...@gnosis.pp.invalid:
> Jep, ennemmin tai myöhemmin softaan tulee "pullonkaula", mutta se ei
> ole se taloudellisesti merkittävin asia (yleensä).
Varsinkin suomalaisten b2b-Javakehittäjien maailmassa softan pullonkaulat
eivät yleensä ole lainkaan niin oleellisia kuin softa_projektin_
pullonkaulat -- aikataulut, määrittelyn laatu, lopputuloksen
robusti toiminnallisuus ja ylläpidettävyys -- niistä riippuu paljon enemmän
asiakkaan ja ohjelmistokehittäjän pitkän tähtäimen menestyminen kuin
suorituskyvyn optimointiin tähtäävästä ohjelmointistrategiasta, joka
suuntaisi projektien huomion usein aivan hakoteille.
--
Matti Vuori, <http://sivut.koti.soon.fi/mvuori>
Jarkko Hietaniemi
>
> Haloo! Ongelman jakaminen olioiksi on juuri se tärkein peruasia kun
> opetetaan olio-ohjelmoinnin alkeita!
No, toivottavasti niitä "enttöprais-tason eejiibee-ratkaisuja"
ei käytetä olio-ohjelmoinnin harjoitteluun...
--
Jarkko Hietaniemi <j...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Jari Vuoksenranta
> Yksi perusongelma näissä iänikuisissa tehokkuusväittelyissä onkin
> se, että tyypillisesti Java-ihmiset ja C-ihmiset ohjelmoivat
> aivan eri universumeissa.
No voisitko neuvoa miten javaa sitten voisi nopeuttaa
verrattuna perliin joka näyttää olevan javaa nopeampi:
"
class foo { public static void main(String[] args) { ; } }
$ time java -cp . foo
real 0m0.360s
user 0m0.020s
sys 0m0.020s
$ time perl -e ';'
real 0m0.090s
user 0m0.020s
sys 0m0.060s
"
class foo {
public static void main(String[] args) { System.out.println
("java");
}
$ time java -cp . foo
java
real 0m0.417s
user 0m0.020s
sys 0m0.020s
$ time perl -e 'print 'perl';'
real 0m0.062s
user 0m0.030s
sys 0m0.030s
Jari Vuoksenranta
> Yksi perusongelma näissä iänikuisissa tehokkuusväittelyissä onkin
> se, että tyypillisesti Java-ihmiset ja C-ihmiset ohjelmoivat
> aivan eri universumeissa.
No voisitko neuvoa miten javaa sitten voisi nopeuttaa
verrattuna perliin joka näyttää olevan javaa nopeampi:
"
class foo { public static void main(String[] args) { ; } }
$ time java -cp . foo
real 0m0.360s
user 0m0.020s
sys 0m0.020s
$ time perl -e ';'
real 0m0.090s
user 0m0.020s
sys 0m0.060s
class foo {
public static void main(String[] args) { System.out.println
("java");
}
$ time java -cp . foo
real 0m0.417s
Jari Vuoksenranta
> Yksi perusongelma näissä iänikuisissa tehokkuusväittelyissä onkin
> se, että tyypillisesti Java-ihmiset ja C-ihmiset ohjelmoivat
> aivan eri universumeissa.
No voisitko neuvoa miten javaa sitten voisi nopeuttaa
verrattuna perliin joka näyttää olevan javaa nopeampi:
"
class foo { public static void main(String[] args) { ; } }
$ time java -cp . foo
real 0m0.360s
user 0m0.020s
sys 0m0.020s
$ time perl -e ';'
real 0m0.090s
user 0m0.020s
sys 0m0.060s
class foo {
public static void main(String[] args) { System.out.println
("java");
}
$ time java -cp . foo
real 0m0.417s
user 0m0.020s
sys 0m0.020s
$ cat >> foo.pl
print 'perl';
$ time perl foo.pl
real 0m0.096s
user 0m0.050s
sys 0m0.020s
Aleksi Kallio
>>se, että tyypillisesti Java-ihmiset ja C-ihmiset ohjelmoivat
>>aivan eri universumeissa.
> No voisitko neuvoa miten javaa sitten voisi nopeuttaa
> verrattuna perliin joka näyttää olevan javaa nopeampi:
Nuo antamasi "suorituskykytestit" eivät mitanneet kielten/kääntäjien
suorituskykyä, vaan pelkästään sitä kumpi käynnistyy nopeammin,
Java-virtuaalikone vai Perl-tulkki. Hienostuneesta roskienkeruusta,
JIT:stä ja muusta sellaisesta johtuen normaali JVM käynnistyy aika
hitaasti, kuten huomasitkin. Mikäli sillä on merkitystä, niin käytä
yksinkertaista tulkitsevaa virtuaalikonetta (java interpreter) -
sellainen käynnistyy nopeasti, mutta ajaa ohjelmia hitaammin.