Kirjautuminen

Haku

Tehtävät

Keskustelu: Yleinen keskustelu: Funktionaalisen ohjelmoinnin alkeita

Sivut:

Sivu 2 / 2

Sivun loppuun

Grez [05.10.2019 19:07:38]

#

(Aiheesta "function type signature":
Tuolla käytetään näköjään "funktion tyypitys"
http://www.mit.jyu.fi/opiskelu/seminaarit/ohjelmistotekniikka/funktion/ )

Selma-koira [05.10.2019 19:19:44]

#

Grez kirjoitti:

(Aiheesta "function type signature":
Tuolla käytetään näköjään "funktion tyypitys"
http://www.mit.jyu.fi/opiskelu/seminaarit/ohjelmistotekniikka/funktion/ )

Oisko vaan funktion tyyppi?

Lisäys:

Grez kirjoitti:

(05.10.2019 18:29:14): ”– –” "for x in luvut" ei kylläkään viittaa mihinkään...

Se antaa sitten syntaksiltaankin ymmärtää, että joukkoa käsitellään. Kiitos vinkistä, tuijotin tuota for-sanaa vaan. Samaltahan ne näyttää siinä, mutta merkityseroja on paljon. Toi Haskellin mapin perässä oleva lista on funktori ja noi yhtäsuuruusmerkin vasemmalla puolella olevat on nimiä.

Lisäys:

Metabolix kirjoitti:

Selma-koira kirjoitti:

Kyse ei ole reiluudesta tai epäreiluudesta, vaan siitä, millaisilla abstraktiolla lähdetään liikkeelle. Noi kaksi paradigmaa olettavat erilaiset abstraktiot ja se on ihan ok - siksihän niitä paradigmoiksi kutsutaankin - fundamentit on eri.

Minusta tuo on erittäin suuri ajatusvirhe. Kuten on aika monta kertaa yritetty selittää, imperatiivinen ohjelmointi ei edellytä mitään tiettyä abstraktion tasoa. Abstraktion määrä riippuu välineistä (kielestä, kirjastoista ym.). Tämä näkyy vaikkapa tuosta Python-koodista, jossa ”abstraktion taso” on samanlainen kuin esittämässäsi Haskell-koodissa.

Mun mielestä ne perustuu eri abstraktiolle, yksi Turingin koneelle ja toinen lambda-laskennalle. Onko nyt kyse siitä voidaanko nämä kaksi asiaa määritellä samoiksi vai ei?

Lisäksi, koska lista on funktori ja Pythonin vastaavassa koodin kohdassa oleva käsite ei, niin vaikuttaako se mielestäsi jotenkin asiaan. Vai ovatko abstraktiot edelleen "niin kuin ne siinä koodissa seisovat". Saako "lista" ja koko koodi mielestäsi silloin eri merkityksen vai ovatko ne edelleen "samoja". Fp-edellyttää ton funktorin käsitteen, muuten siitä ei oikein tule mitään.

Sä voit toki kommentoida, että "kyllähän Pythonissakin voi funktoreita tehdä, ihan vaan koodaamalla". No totta kai voi. Ja voi sen tehdä muillakin kielillä, muttei se kieli ole niiden varassa.

Sitten on se kysymys, että millä perusteella kieliä voi vertailla. Minä tein kirjassa niin, osoittaakseni eron, jossa näkyy, että toisessa on muuttujia, toisessa ei, koska pidin sitä oleellisena erona ko. paradigmojen välillä.

Tronic [06.10.2019 09:05:54]

#

Imperatiivisella ohjelmoinnilla ei kyllä ole mitään tekoa Turingin koneen kanssa. Muistin käyttö on muuttujiin perustuvaa ja GOTO on poistunut käytöstä, joten nauhaa ei voi kelata tai tilojen välillä siirtyä vapaasti, ja abstraktio hajoaakin sitten jo siihen.

Ohjelmointitapojen eroja selvitellään myös tässä:

https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/#what-happened-to-goto:

It may seem like this is obvious, but if you have a language with goto – a language where functions and everything else are built on top of goto, and goto can jump anywhere, at any time – then these control structures aren't black boxes at all! If you have a function, and inside the function there's a loop, and inside the loop there's an if/else, and inside the if/else there's a goto... then that goto could send the control anywhere it wants. Maybe control will suddenly return from another function entirely, one you haven't even called yet. You don't know!

Grez [06.10.2019 10:36:23]

#

Tronic kirjoitti:

https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/#what-happened-to-goto:

If you have a function, and inside the function there's a loop, and inside the loop there's an if/else, and inside the if/else there's a goto... then that goto could send the control anywhere it wants.

Joissakin kielissä tosin on tarjolla vähävoimainen goto, eli sillä voi hyppiä, mutta ei mihin tahansa (esim. toiseen funktioon, for loopin sisään tms). Tällöin tuon tekstin "goto could send the control anywhere" ei pidä paikkaansa.

Näköjään muuten netistä löytyy jopa mielipiteitä, että goton hienosteltuja versioitakaan, kuten break ei pitäisi käyttää.

Tronic [06.10.2019 10:38:55]

#

Lukaise se koko artikkeli, jos kiinnostaa. Molemmat mainitsemasi seikat ovat aiheina siinä.

Grez [06.10.2019 11:37:31]

#

No sehän se ongelma tietenkin on kun lainaa artikkelista pätkän näkyville. Eli lainatussa pätkässä käsiteltiin tilannetta aikana ennen nykyisiä kieliä, joissa goton toimintavapautta on rajoitettu.

Selma-koira [06.10.2019 11:39:02]

#

Teuro kirjoitti:

(04.10.2019 18:36:48): ”– –” Nojaa toista taulukkoa ei tarvita mihinkään...

Toi idea on, että imperatiivisessa toi toinen taulukko tarvitaan, koska pitää luoda uudet numerot. Jos sen tekee noin kun tuossa sulla nyt on, se merkitsee eri asiaa kuin toi Haskell pätkä.

Metabolix [06.10.2019 12:08:03]

#

Selma-koira kirjoitti:

Mun mielestä ne perustuu eri abstraktiolle, yksi Turingin koneelle ja toinen lambda-laskennalle. Onko nyt kyse siitä voidaanko nämä kaksi asiaa määritellä samoiksi vai ei?

Ahaa, en todellakaan arvannut, että tarkoitit abstraktiolla tuollaista perimmäistä taustateoriaa. Tämä ei ole termin normaali käyttötapa ohjelmoinnissa. Ohjelmoinnissa abstraktiolla tarkoitetaan toteutuksen piilottamista: map-funktio on korkeamman tason abstraktio kuin sen toteutus, ja vielä korkeammalta abstraktion tasolta voi löytyä esimerkiksi funktio ratkaiseLabyrintti – riippumatta kielestä tai paradigmasta.

Tässä keskustelussa ei ole tietääkseni millään tavalla kyse Turingin koneesta ja lambda-laskennasta ja niiden välisestä yhteydestä. Tuskin kukaan edes miettii niitä tavallisessa ohjelmoinnissa.

Selma-koira kirjoitti:

jos halutaan hahmottaa miten tietoa käsitellään funktiolla, pärjätään alkuun hyvin ilman tyyppejäkin

Esimerkkisi ”map (+1) lista” edellyttää lukujen ja listan hahmottamista, vaikka sitä ei nimeltä sanottaisi. Toisaalta, jos mielestäsi tässä pärjätään ilman tyyppejä, sama tilanne esiintyy imperatiivisessa ohjelmoinnissa Pythonilla, eli mitään funktionaalisen ohjelmoinnin etua ei ole vieläkään tullut osoitetuksi.

Selma-koira kirjoitti:

Fp-edellyttää ton funktorin käsitteen, muuten siitä ei oikein tule mitään.

On totta, että opitut käsitteet usein ohjaavat ihmisten ajattelua. Toisaalta tästä käsitteiden ylivallasta voi pyrkiä eroon. Funktiot ja funktorit ja ties mitkä ovat koodin toteutusta (aivan samoin kuin muuttujat ja silmukat), eivät koodin ajatusta.

Varsinaisen ratkaisun kannalta olennaista on se, mitä ohjelmoija ajattelee. Ohjelman tai algoritmin suunnittelu voi tapahtua abstraktisti aivan irrallaan tietyn kielen käsitteistä ja määritelmistä.

Yleensä tiedonkäsittelyssä algoritmin suunnittelu alkaa siitä, että hahmotetaan ongelma ja sen osat. Käsiteltävän ongelman korkeimmasta abstraktiosta (ratkaiseLabyrintti) siirrytään matalampiin kerroksiin. Valittu ohjelmointikieli tai paradigma tulee vastaan viimeisenä; sen ei tarvitse vaikuttaa suunnitelmaan vaan toteutukseen. On täysin epäolennaista, tehdäänkö jokin toimenpide taulukolle lopulta map-funktiolla vai jollain muulla tavalla, koska tuossa vaiheessa ollaan jo erittäin matalalla tasolla toteutuksessa.

Asiaa voi verrata rakentamiseen: Ei kannata ostaa nauloja ja lautaa, jos ei ole edes piirustuksia. Toisaalta puisen rungon voi koota nauloilla tai ruuveilla, eikä tällä ole kovin suurta merkitystä piirustusten kannalta.

Loppukäyttäjälle tehdyissä ohjelmissa kuten vaikka graafisissa tietokantaohjelmissa on usein vähemmän ideaa ja enemmän toteutusta, joten niissä tilanne on erilainen kuin algoritmiohjelmoinnissa.

Pyysin aiemmin esittämään jonkin konkreettisen esimerkin, mutta eipä ole kuulunut. Esitän siis itse: Miten ratkaiset Datatähti 2020 -tehtävät? (Toki ei saa julkaista vielä vaan vasta kisan päätyttyä.) Vaikka käytännössä silmukat ja ehdot täyttävät suuren osan C++-koodista tehtävissä A–D, varsinainen ratkaisu ei ole näissä paradigmaan sidoksissa. E-tehtävä onkin kiinnostavampi sikäli, että siinä ei voi suoraan laskea oikeaa vastausta.


Sivun alkuun

Sivut:

Vastaus

Aihe on jo aika vanha, joten et voi enää vastata siihen.

Tietoa sivustosta