Pythonin oliohjelmoinni alkeiden opiskelu

Höpönlöpön.

M-Kar kirjoitti:

Höpönlöpön.

Näin se vain on. Olio-ohjelmoinnissa turhaan monistellaan struktuureja, vaikka niiden metodit voisivat olla tavallisia uudelleenkutsuttavia funktioita.

funktiot-kunniaan kirjoitti:

Näin se vain on. Olio-ohjelmoinnissa turhaan monistellaan struktuureja, vaikka niiden metodit voisivat olla tavallisia uudelleenkutsuttavia funktioita.

Eihän niitä metodeja monistella.

Käytännössä olio ominaisuudet ovat vain työkaluja joilla voi jäsennellä koodia. Se raskaus on jotain hölynpölyä.

Sitä en tietenkään kiellä, etteikö funktionaalisuus olisi hvvä juttu mutta joku C-kieli ei tähän niin hyvin sovi kun tässä on niitä rajoitetteita pinon kanssa.

M-Kar kirjoitti:

Eihän niitä metodeja monistella.

Käytännössä olio ominaisuudet ovat vain työkaluja joilla voi jäsennellä koodia. Se raskaus on jotain hölynpölyä.

Sitä en tietenkään kiellä, etteikö funktionaalisuus olisi hvvä juttu mutta joku C-kieli ei tähän niin hyvin sovi kun tässä on niitä rajoitetteita pinon kanssa.

Lue lisää

Oliot ovat luokan kopioita. Luokkametodit ovat sitten erikseen.

C-kielellä ei ole mitään rajoitteita pinon kanssa. Jokainen osaava koodaaja tietää kuinka muistia varataan.

Olio-ohjelmointi on tunarikoodaajia varten. He eivät osaa mitään. Siksi maailma on täynnä paskaa koodia.

funktiot-kunniaan kirjoitti:

Oliot ovat luokan kopioita. Luokkametodit ovat sitten erikseen.

C-kielellä ei ole mitään rajoitteita pinon kanssa. Jokainen osaava koodaaja tietää kuinka muistia varataan.

Olio-ohjelmointi on tunarikoodaajia varten. He eivät osaa mitään. Siksi maailma on täynnä paskaa koodia.

Lue lisää

"Oliot ovat luokan kopioita. Luokkametodit ovat sitten erikseen."

Eli ei eihän se sitten turvota koodia.

"C-kielellä ei ole mitään rajoitteita pinon kanssa. Jokainen osaava koodaaja tietää kuinka muistia varataan."

Kyllä on. Kun kutsutaan funktiota, se funktiokutsu varataan pinosta. Siksi C:llä kun tekee funktionaalisesti oikeaoppisesti ohjelmia niin rekursion kanssa tulee helposti raja vastaan ja prosesssi kaatuu pinon ylivuodon takia. Siksi isoja rakenteita ei pysty C:llä käsittelemään funktionaalisesti. Sama ongelma on myös C :lla, eli ei liity olio-ohjelmointiin mitenkään vaan kyse on juurikin funktioista.

M-Kar kirjoitti:

"Oliot ovat luokan kopioita. Luokkametodit ovat sitten erikseen."

Eli ei eihän se sitten turvota koodia.

"C-kielellä ei ole mitään rajoitteita pinon kanssa. Jokainen osaava koodaaja tietää kuinka muistia varataan."

Kyllä on. Kun kutsutaan funktiota, se funktiokutsu varataan pinosta. Siksi C:llä kun tekee funktionaalisesti oikeaoppisesti ohjelmia niin rekursion kanssa tulee helposti raja vastaan ja prosesssi kaatuu pinon ylivuodon takia. Siksi isoja rakenteita ei pysty C:llä käsittelemään funktionaalisesti. Sama ongelma on myös C :lla, eli ei liity olio-ohjelmointiin mitenkään vaan kyse on juurikin funktioista.

Lue lisää

"Siksi C:llä kun tekee funktionaalisesti oikeaoppisesti ohjelmia niin rekursion kanssa tulee helposti raja vastaan ja prosesssi kaatuu pinon ylivuodon takia."

Tämä lause antaa väärän kuvan ja on virheellinen väittämä, funktioiden ja aliohjelmien rekursiivisuudesta. Rekursiivinen aliohjelma tai funktio on sellainen osa koodia joka kutsuu itseään uudestaan ja uudestaan, kunnes ehto täyttyy.

Aina kun prosessori hyppää suorittamaan aliohjelmaa tai funktiota, on pääohjelman tilanne, (muuttujat, paluu osoitteet) tallennettava pinoon, jotta sitä voidaan jatkaa sen jälkeen kun aliohjelma on suoritettu, eikä tässä vielä ole kyse rekursiivisesta aliohjelmasta tai funktiosta. Rekursiiviseksi se muuttuu vasta sitten kun tuo aliohjelma tai funktion kutsuu itse itseään.

"oikeaoppisesti": Älä viiti tämmöisiä.

Turbo-Urpo1 kirjoitti:

"Siksi C:llä kun tekee funktionaalisesti oikeaoppisesti ohjelmia niin rekursion kanssa tulee helposti raja vastaan ja prosesssi kaatuu pinon ylivuodon takia."

Tämä lause antaa väärän kuvan ja on virheellinen väittämä, funktioiden ja aliohjelmien rekursiivisuudesta. Rekursiivinen aliohjelma tai funktio on sellainen osa koodia joka kutsuu itseään uudestaan ja uudestaan, kunnes ehto täyttyy.

Aina kun prosessori hyppää suorittamaan aliohjelmaa tai funktiota, on pääohjelman tilanne, (muuttujat, paluu osoitteet) tallennettava pinoon, jotta sitä voidaan jatkaa sen jälkeen kun aliohjelma on suoritettu, eikä tässä vielä ole kyse rekursiivisesta aliohjelmasta tai funktiosta. Rekursiiviseksi se muuttuu vasta sitten kun tuo aliohjelma tai funktion kutsuu itse itseään.

"oikeaoppisesti": Älä viiti tämmöisiä.

Lue lisää

"Tämä lause antaa väärän kuvan ja on virheellinen väittämä, funktioiden ja aliohjelmien rekursiivisuudesta. Rekursiivinen aliohjelma tai funktio on sellainen osa koodia joka kutsuu itseään uudestaan ja uudestaan, kunnes ehto täyttyy."

Tietysti.

"Aina kun prosessori hyppää suorittamaan aliohjelmaa tai funktiota, on pääohjelman tilanne, (muuttujat, paluu osoitteet) tallennettava pinoon, jotta sitä voidaan jatkaa sen jälkeen kun aliohjelma on suoritettu, eikä tässä vielä ole kyse rekursiivisesta aliohjelmasta tai funktiosta. Rekursiiviseksi se muuttuu vasta sitten kun tuo aliohjelma tai funktion kutsuu itse itseään."

Tietysti. Ja funktionaalisessa ohjelmoinnissa rekursiota tarvitaan.

" "oikeaoppisesti": Älä viiti tämmöisiä."

Nythän oli kyse funktionaalisesta ohjelmoinnista ja funktionaalisessa ohjelmoinnissa ei esimerkiksi käytetä sijoitusoperaattoria vaan ongelma ratkotaan funktioina. Siinä tulee väistämättä rekursiota.

Funktionaalinen ohjelmointi tosiaankin on hyvä juttu, jos suinkin on kätevää niin sillä tavalla ne ohjelmat rakennetaan eikä olio-ohjelmointina. Funktionaalisen ohjelmoinnin oikeaoppisuus ei myöskään ole mikään mielipideasia vaan tosiasia, sillä funktionaalisessa koodissa vältetään riippuvuuksia.

C-kielen rajoittuneisuus on myös tosiasia kun ei niitä ongelmia saa ratkottua aina funktionaalisesti kun tulee helposti se pinon ylivuoto vaan joutuu kirjoittamaan koodia paskemmin tekemällä imperatiivista koodia jossa tehdään niitä riippuvuuksia esim. sijoituslausekkeilla.

Kannattaisi siis ottaa selvää siitä funktionaalisesta ohjelmoinnista ennen kuin alat hehkuttamaan jotain C:tä missä on niitä heikkouksia.

M-Kar kirjoitti:

"Tämä lause antaa väärän kuvan ja on virheellinen väittämä, funktioiden ja aliohjelmien rekursiivisuudesta. Rekursiivinen aliohjelma tai funktio on sellainen osa koodia joka kutsuu itseään uudestaan ja uudestaan, kunnes ehto täyttyy."

Tietysti.

"Aina kun prosessori hyppää suorittamaan aliohjelmaa tai funktiota, on pääohjelman tilanne, (muuttujat, paluu osoitteet) tallennettava pinoon, jotta sitä voidaan jatkaa sen jälkeen kun aliohjelma on suoritettu, eikä tässä vielä ole kyse rekursiivisesta aliohjelmasta tai funktiosta. Rekursiiviseksi se muuttuu vasta sitten kun tuo aliohjelma tai funktion kutsuu itse itseään."

Tietysti. Ja funktionaalisessa ohjelmoinnissa rekursiota tarvitaan.

" "oikeaoppisesti": Älä viiti tämmöisiä."

Nythän oli kyse funktionaalisesta ohjelmoinnista ja funktionaalisessa ohjelmoinnissa ei esimerkiksi käytetä sijoitusoperaattoria vaan ongelma ratkotaan funktioina. Siinä tulee väistämättä rekursiota.

Funktionaalinen ohjelmointi tosiaankin on hyvä juttu, jos suinkin on kätevää niin sillä tavalla ne ohjelmat rakennetaan eikä olio-ohjelmointina. Funktionaalisen ohjelmoinnin oikeaoppisuus ei myöskään ole mikään mielipideasia vaan tosiasia, sillä funktionaalisessa koodissa vältetään riippuvuuksia.

C-kielen rajoittuneisuus on myös tosiasia kun ei niitä ongelmia saa ratkottua aina funktionaalisesti kun tulee helposti se pinon ylivuoto vaan joutuu kirjoittamaan koodia paskemmin tekemällä imperatiivista koodia jossa tehdään niitä riippuvuuksia esim. sijoituslausekkeilla.

Kannattaisi siis ottaa selvää siitä funktionaalisesta ohjelmoinnista ennen kuin alat hehkuttamaan jotain C:tä missä on niitä heikkouksia.

Lue lisää

"Kannattaisi siis ottaa selvää siitä funktionaalisesta ohjelmoinnista ennen kuin alat hehkuttamaan jotain C:tä missä on niitä heikkouksia."

Kuulehan, et ymmärä lukemaasi, VAIN SINUN VASTAUKSESTA OLEVASSA LAINAUKSESSA MAINITTIIN C -kieli.

Ymmärrätkö vain sinun, sanomaa lainasin, koska se oli välttämätöntä. Minä en hehkuttanut yhtään mitään. ÄLÄ VÄÄRISTELE SANOMAANI.

"Siinä tulee väistämättä rekursiota."
Funktioiden ja aliohjelmien käyttö ei ole rekursiivista ohjelmointia, eikä se pakoita käyttämään rekursiota onglemien ratkaisuun. Koita nyt hyvä mies ymmärtää, AINA kun ohjelman suorituksessa hypätään aliohjelmaan, pääohjelman tilanne ja paluu osoitteet tallennetaan sen vuoksi että pystytään jatkamaan, myös funktio on aliohjelma, siihen ei tule rekursiota, se ei ole mikään veteen piirretty viiva jota voi siirrellä mielensä mukaan, ei ole hyvä ajatus lähteä väittämään että aliohjelman kutsuminen tuo väkisin rekursiota.

Kuvitteles nyt, menet kauppaan päivittäiselle ruokaostoksille, mutta tullessa huomaat että kahvi unohtui, joten sinun on palattava takaisin kauppaan. Tässä syntyy rekursio, koska itse kaupassa käynti aihetti toisen käynnin, jolla unohtamis onglma ratkaistiin.

Normaalissa kaupalla käynnissä ei ole rekursiota, koska se on päivittäinen asiointi, MUTTA eri syistä, vaikka se toistuukin, kunhan toistuminen ei aiheudu kaupalla käynnin vaikutuksesta.

EI HITTO
Liikaa puuta heinää tuossa sinun viestissä, ei viitsi ruveta jauhamaan asiaa tämän enempää.

Turbo-Urpo1 kirjoitti:

"Kannattaisi siis ottaa selvää siitä funktionaalisesta ohjelmoinnista ennen kuin alat hehkuttamaan jotain C:tä missä on niitä heikkouksia."

Kuulehan, et ymmärä lukemaasi, VAIN SINUN VASTAUKSESTA OLEVASSA LAINAUKSESSA MAINITTIIN C -kieli.

Ymmärrätkö vain sinun, sanomaa lainasin, koska se oli välttämätöntä. Minä en hehkuttanut yhtään mitään. ÄLÄ VÄÄRISTELE SANOMAANI.

"Siinä tulee väistämättä rekursiota."
Funktioiden ja aliohjelmien käyttö ei ole rekursiivista ohjelmointia, eikä se pakoita käyttämään rekursiota onglemien ratkaisuun. Koita nyt hyvä mies ymmärtää, AINA kun ohjelman suorituksessa hypätään aliohjelmaan, pääohjelman tilanne ja paluu osoitteet tallennetaan sen vuoksi että pystytään jatkamaan, myös funktio on aliohjelma, siihen ei tule rekursiota, se ei ole mikään veteen piirretty viiva jota voi siirrellä mielensä mukaan, ei ole hyvä ajatus lähteä väittämään että aliohjelman kutsuminen tuo väkisin rekursiota.

Kuvitteles nyt, menet kauppaan päivittäiselle ruokaostoksille, mutta tullessa huomaat että kahvi unohtui, joten sinun on palattava takaisin kauppaan. Tässä syntyy rekursio, koska itse kaupassa käynti aihetti toisen käynnin, jolla unohtamis onglma ratkaistiin.

Normaalissa kaupalla käynnissä ei ole rekursiota, koska se on päivittäinen asiointi, MUTTA eri syistä, vaikka se toistuukin, kunhan toistuminen ei aiheudu kaupalla käynnin vaikutuksesta.

EI HITTO
Liikaa puuta heinää tuossa sinun viestissä, ei viitsi ruveta jauhamaan asiaa tämän enempää.

Lue lisää

C-kieli mainittiin tässä: https://keskustelu.suomi24.fi/t/15324116/pythonin-oliohjelmoinni-alkeiden-opiskelu#comment-94192180

Ja nimimerkki "funktiot-kunniaan"

Mitenkäs tämä nyt sitten niinkuin pitäisi tulkita kuin niin, että puhutaan ongelman ratkaisusta funktioilla ja C-kielellä? Tämä siis oli se mistä nyt puhuin ja sinä vastasit siihen.

"Funktioiden ja aliohjelmien käyttö ei ole rekursiivista ohjelmointia, eikä se pakoita käyttämään rekursiota onglemien ratkaisuun."

Kyse oli funktionaalisesta ohjelmoinnista.

"Koita nyt hyvä mies ymmärtää, AINA kun ohjelman suorituksessa hypätään aliohjelmaan, pääohjelman tilanne ja paluu osoitteet tallennetaan sen vuoksi että pystytään jatkamaan"

Tietysti. Ja C-kieli ei tästä syystä sovi funktionaaliseen ohjelmointiin.

"myös funktio on aliohjelma, siihen ei tule rekursiota"

Ymmärrä se, että kun ongelmia ratkotaan funktionaalisesti, ei tehdä sijoituslausekkeita vaan käytetään funktioita.

Hyvin moni ongelman ratkaisu funktionaalisesti kirjoitettuna siis vaatii rekursiota. Esimerkiksi vaikka kaikki divide & conquer tyylin algoritmit kuten vaikka quicksort.

"Kuvitteles nyt, menet kauppaan päivittäiselle ruokaostoksille, mutta tullessa huomaat että kahvi unohtui, joten sinun on palattava takaisin kauppaan. Tässä syntyy rekursio, koska itse kaupassa käynti aihetti toisen käynnin, jolla unohtamis onglma ratkaistiin."

Kuvitteles semmoinen asia että ratkot asian niin, että et tallenna yhtään mitään mihinkään muuttujaan vaan kutsut funktiota mikä palauttaa asian. Eli ongelman ratkaisu funktionaalisesti että ei tule riippuvuuksia minkään muuttujan tilaan.

Kyllä, funktiot kunniaan. Funktionaalisuus on hyvä juttu. Ja C-kielessä on ongelma tässä kun pinomuisti voi vuotaa yli. Puhdas funktionaalinen ratkaisumalli onnistuu C:llä vain pienillä tietorakenteilla.

M-Kar kirjoitti:

C-kieli mainittiin tässä: https://keskustelu.suomi24.fi/t/15324116/pythonin-oliohjelmoinni-alkeiden-opiskelu#comment-94192180

Ja nimimerkki "funktiot-kunniaan"

Mitenkäs tämä nyt sitten niinkuin pitäisi tulkita kuin niin, että puhutaan ongelman ratkaisusta funktioilla ja C-kielellä? Tämä siis oli se mistä nyt puhuin ja sinä vastasit siihen.

"Funktioiden ja aliohjelmien käyttö ei ole rekursiivista ohjelmointia, eikä se pakoita käyttämään rekursiota onglemien ratkaisuun."

Kyse oli funktionaalisesta ohjelmoinnista.

"Koita nyt hyvä mies ymmärtää, AINA kun ohjelman suorituksessa hypätään aliohjelmaan, pääohjelman tilanne ja paluu osoitteet tallennetaan sen vuoksi että pystytään jatkamaan"

Tietysti. Ja C-kieli ei tästä syystä sovi funktionaaliseen ohjelmointiin.

"myös funktio on aliohjelma, siihen ei tule rekursiota"

Ymmärrä se, että kun ongelmia ratkotaan funktionaalisesti, ei tehdä sijoituslausekkeita vaan käytetään funktioita.

Hyvin moni ongelman ratkaisu funktionaalisesti kirjoitettuna siis vaatii rekursiota. Esimerkiksi vaikka kaikki divide & conquer tyylin algoritmit kuten vaikka quicksort.

"Kuvitteles nyt, menet kauppaan päivittäiselle ruokaostoksille, mutta tullessa huomaat että kahvi unohtui, joten sinun on palattava takaisin kauppaan. Tässä syntyy rekursio, koska itse kaupassa käynti aihetti toisen käynnin, jolla unohtamis onglma ratkaistiin."

Kuvitteles semmoinen asia että ratkot asian niin, että et tallenna yhtään mitään mihinkään muuttujaan vaan kutsut funktiota mikä palauttaa asian. Eli ongelman ratkaisu funktionaalisesti että ei tule riippuvuuksia minkään muuttujan tilaan.

Kyllä, funktiot kunniaan. Funktionaalisuus on hyvä juttu. Ja C-kielessä on ongelma tässä kun pinomuisti voi vuotaa yli. Puhdas funktionaalinen ratkaisumalli onnistuu C:llä vain pienillä tietorakenteilla.

Lue lisää

Aivan naurettavia vastauksia, jos minä kirjoita että:

"Lapiosta katksi varsi."

niin sinä vastaat

"Ymmärrä nyt se että kivet eivät kasva puissa."

ei tällaisesta keskustelusta tule hevonpaskaakaan.

Entäs ne vähemmän tunnetut?

trollerson kirjoitti:

Entäs ne vähemmän tunnetut?

Ei niitä ole, tai on mutta kukaan ei niitä tunne, en minäkään ja näköjään et sinäkään.

trollerson kirjoitti:

Entäs ne vähemmän tunnetut?

Kuka se on joka tarvitsee termiä "olio-ohjelmointi"
Liittyyköhän se ollenkaan Lazaruksella ohjelman tekoon, en ole koskaan ajatellut jotain tehdessäni tuollaista termiä, minä vain kirjoittelen, se on paljon helpompaa kuin olioiden teko.

Oliopohjainen ohjelmointi on monissa yhteyksissä helpoin, nopein ja yksinkertaisin tapa koodata. Siksi myös olio-ohjelmoinnin ymmärtämäinen on tärkeää.

VääntäkääPyytton kirjoitti:

Oliopohjainen ohjelmointi on monissa yhteyksissä helpoin, nopein ja yksinkertaisin tapa koodata. Siksi myös olio-ohjelmoinnin ymmärtämäinen on tärkeää.

Nämä ohjelmointiparadigmat, ovat termejä joita tarvitsee vain Suomen tiedekustantajien liitto jonka on vuosittain perusteltava kirjallisuuspalkintonsa ansaitsemisperusteet:

Deklaratiivinen ohjelmointi, Epärakenteellinen ohjelmointi, Funktionaalinen ohjelmointi, Geneerinen ohjelmointi, Imperatiivinen ohjelmointi, Logiikkapohjainen ohjelmointikieli, Olio-ohjelmointi, Proseduraalinen ohjelmointi, Prototyyppipohjainen ohjelmointi, Reaktiivinen ohjelmointi, Rinnakkaisohjelmointi, Strukturoitu ohjelmointi.

Ohjelmat ovat parhaimillaan, kun kirjoittaja ei ole ikinään edes kuullut noista yhtään mitään, vielä vähemän hänen tarvitsee niitä ymmärtää.