Ohjelmointi harrastuksen aloittaminen

[tmv]

Ja jos aikeena on nimenomaan harrastuksena aloittaa ohjelmointi, ei siinä ole niinkään väliä onko jokin kieli vanhentunut, viitaten perliin. Tavoitteet on harrastelijalla erilaiset kuin ammatikseen tai puoliammatikseen tekevät. Mun mielestä siihen kannattaa ehdottomasti tutustua. Tällä hetkellä eniten  itseä juuri kiinostaa bash ja perl. Perl tuntuu hauskemmalta kuin python.

Perl on hyvä säännöllisten lausekkeiden pyörittelyyn ja muuhun vastaavaan merkkijonojen käsittelyyn. Se on edelleen ihan kätevä Linux/Unix-administraattorin työkalu. Muunlaiseen ohjelmointiin en sitä oikein suosittelisi etenkään aloittelijoille. Perlillä on kyllä vielä jossain määrin elinvoimainen ekosysteemi, mutta Pythoniin verrattuna se on moniin juttuihin aika rajallinen aloittelijankin kannalta. Lisäksi harrastelijoilla on usein tapana jämähtää siihen yhteen kieleen, jolloin huono ensimmäinen valinta alkaa jossain vaiheessa rajoittaa harrastusta ikävästi.

Joo. Ja toki harrastelijoillakin on eri tarkoitusperiaatteet. Tuskin muilla alustoilla kuin linux/unix edes mainitaan perliä. Administraattorin työkaluna tyyppisenä sitä lähinnä opetellutkin, joskin ainakin omissa tarkoitusperiaatteissa bash on monesti kätevämpi, kun ronklaa vaan komentorivin komentoja.

PHP on kuin Perl web-koodaukseen, mutta amatöörien suunnittelemana.   

Se on kyllä totta, että sillä saa aika vaivattomasti jotain aikaan. Muutenhan web-ohjelmoinnissa muutosvauhti on tällä hetkellä täysin järjetön. Ohjelmointikehykset ja paradigmat muuttuvat jatkuvasti, ja ammattilaisillakin on vaikeuksia pysyä kelkassa. PHP voi siis olla jopa suositeltava kieli aloittelijalle web-palvelujen toteuttamiseen.

Jaahas. Olen pitänyt php:tä melkolailla standardina web-ohjelmoinnissa, monesti osoiterivipalkissa ainakin php lukee.

Tokihan koitin, kun perlin aika oli ns. ohi, perl+cgi yhdistelmää web-sivustoissa, mutta se tosiaan oli monimutkaista. Tutustuin php:hen ja moni asia mikä perlillä vaati monta riviä, meni php:llä yhdellä rivillä - epämääräisenä kuriositeettina mainittakoon.

[snifi]

Minä olin itse aikaisemmin hyvinkin innokas Pythonin käyttäjä. Kuitenkin lopulta tuli aika, jolloin halusi tehdä aidosti käännettäviä ohjelmia. Silloin olisi pitänyt siirtyä kahden kielen käyttäjäksi ja minusta se ei ollut toimiva ratkaisu. Ehkä hienoisena houkuttimena toimi vielä, kun saattoi jättää yhdet ylimääräiset sulkumerkit pois `print`-funktiosta.

[AimoE]

Silloin olisi pitänyt siirtyä kahden kielen käyttäjäksi ja minusta se ei ollut toimiva ratkaisu.

En kyllä osaa kuvitella miten pelkästään yhden ohjelmointikielen käyttö voisi olla toimiva ratkaisu, ellei sitten ole kyse yksittäisestä sovelluksesta.

[nm]

kun pythonia ei tarvitse kääntää niin voiko sen silti kääntää jos haluaa?

Jos tavoitteena on saada ohjelma paketoitua sellaiseen muotoon, ettei lähdekoodia pysty suoraan lukemaan, on mahdollista käyttää esimerkiksi PyInstalleria. Se tuottaa yhden ajettavan binäärin, jossa on sisällä ohjelman tavukoodi, kaikki käytetyt Python-oheiskirjastot ja myös Python-tulkki.

En kyllä osaa kuvitella miten pelkästään yhden ohjelmointikielen käyttö voisi olla toimiva ratkaisu, ellei sitten ole kyse yksittäisestä sovelluksesta.

Niinpä. Ruuvia ei kannata asentaa vasaralla. Usein myös laajempien yksittäisten ohjelmistojen toteutukseen käytetään useita kieliä.

[snifi]

En kyllä osaa kuvitella miten pelkästään yhden ohjelmointikielen käyttö voisi olla toimiva ratkaisu, ellei sitten ole kyse yksittäisestä sovelluksesta.

En ymmärrä ihan täysin kysymystäsi, mutta itse olen kokenut yhteen kieleen keskittymisen erinomaisen hyväksi valinnaksi.

[AimoE]

En ymmärrä ihan täysin kysymystäsi, mutta itse olen kokenut yhteen kieleen keskittymisen erinomaisen hyväksi valinnaksi.

Ei se ollut kysymys vaan toteamus. Ihan jo pelkästään se että ohjelmointityökaluja komentelee omentotulkissa, olipa se bash tai joku muu, vaatii jonkinlaista komentojonojen ohjelmointia milloin mihinkin tarkoitukseen. Ja koodia muokatessa tulee muokattua ediotrin makroja tms. Tämän lisäksi eri asioita (nettilitíttymiä, taustaproseseja, jne.) tulee ohjelmoitua hieman eri työkaluilla. En kertakaikkiaan pysty kuvittelemaan että voisin rajoittaa ohjelmoinnin yhteen ainoaan kieleen. Kuka palkkaisi työhön ohjelmoijan joka osaa vain yhtä ohjelmointikieltä? Eihän ohjelmointitaitoa voi oppia jos ei kokeile monenlaisia kieliä. Parasta ohjelmointiharjoittelua on ylläpitää vanhoja ohjelmistoja. Siinä oppii samalla myös ohjelmistosuunnittelua.

[snifi]

Ei se ollut kysymys vaan toteamus. Ihan jo pelkästään se että ohjelmointityökaluja komentelee omentotulkissa, olipa se bash tai joku muu, vaatii jonkinlaista komentojonojen ohjelmointia milloin mihinkin tarkoitukseen. Ja koodia muokatessa tulee muokattua ediotrin makroja tms. Tämän lisäksi eri asioita (nettilitíttymiä, taustaproseseja, jne.) tulee ohjelmoitua hieman eri työkaluilla. En kertakaikkiaan pysty kuvittelemaan että voisin rajoittaa ohjelmoinnin yhteen ainoaan kieleen. Kuka palkkaisi työhön ohjelmoijan joka osaa vain yhtä ohjelmointikieltä? Eihän ohjelmointitaitoa voi oppia jos ei kokeile monenlaisia kieliä. Parasta ohjelmointiharjoittelua on ylläpitää vanhoja ohjelmistoja. Siinä oppii samalla myös ohjelmistosuunnittelua.

Tokihan erilaisiin kieliin törmää väistämättä niin komentotulkissa kuin ohjelmien asetustiedostoissa. Mutta mielestäni edellä oli kysymys tilanteesta, jossa tehdään yksinkertaiset työt Pythonilla ja kun tarvitaan kääntäjää, vaihdetaan C-kieleen. Tällaista kahden kielen asetelmaa minä pidän huonona. Minä itse teen Pythonin, C:n ja PHP:n työt yhdellä kielellä. Seurauksena on, että hallitsen tämän yhden kielen paremmin kuin jos olisin hajauttanut työt kahdelle tai kolmelle kielelle. Tämän olettaisi olevan myös työnantajan tavoitteissa.

[kamara]

Minusta kannattaa käyttää sopivinta ohjelmointikieltä ongelmanratkaisuun.

Jos haluan nopeutta, niin C (Joskus ehkä Assembler, mutta nykyään sitä ei juuri tarvitse). Pdf:ssä ja netissä käytän mielelläni php:tä (selaimissa JavaScriptiä). Kännyköissä olen käyttänyt Javaa.

Mielestäni ohjelmointikielellä ei ole niin väliä, kunhan sillä saa ratkaistua halutun ongelman riittävällä nopeudella tai sopivalla vaivalla.

Tavoitteena on ratkaista ongelma, enkä itse osaa sanoa, että onko oikea ratkaisu toteutettu väärällä tavalla. (Vähän kuin palomies sanoisi, että tulipalo on sammutettu väärin.)

En siis edes osaisi tehdä C:llä selaimessa pyörivää ohjelmaa,.

[DDR55]

Mitä eroa on metodilla ja funktiolla

[kamara]

Mitä eroa on metodilla ja funktiolla

Metodi on jonkin luokan funktio/proseduuri.

Tosin opiskeluistani jonkin verran aikaa, joten tietävämmät voisivat tarkentaa/korjata selitystäni.

Edit - http://users.jyu.fi/~vesal/kurssit/cpp/materiaali/olio/

Edit2 - https://fi.wikipedia.org/wiki/Olio-ohjelmointi

[DDR55]

Kumpaa kannattaa käyttää Python 3 ssa?

[AimoE]

Kumpaa kannattaa käyttää Python 3 ssa?

Kumpaakin, tilanteesta riippuen. Ei se riipu kielestä vaan ongelmasta jota olet ratkaisemassa.

[kamara]

Kumpaa kannattaa käyttää Python 3 ssa?

Pienissä scripteissä käytän yleensä funktiota/proseduuria, mutta jos kyseessä on isompi kokonaisuus, niin kannattaa käyttää olio-ohjelmointia eli metodeita, jolloin luokkien kapseloinnista on hyötyä.

[AimoE]

Oppimisen kannalta on helpointa aloittaa funktioista ja proseduureista, ja siirtyä metodeihin sitten kun alkaa hiffata mihin olio-ohjelmointia tarvitaan.

[JA5U]

Itsellä olisi kovasti haluja päästä tuosta Olio-ohjelmoinnista kärryille.
Etenkin erilasiten suunnittelumallien (design pattern) soveltaminen omiin tarpeisiin.

Tuntuu olevan vain kovin haastavaan saada käsitys ongelmanratkaisusta ja siihen sovellettavasta suunnittelumallista.
Myös muiden olioohjelmointia ohjaavien periaatteiden kuten DRY, SRP jne. soveltaminen tuntuu haastavalta.

Ja joskus jos yrittää päästä kärryille jostain hyvin abstraktisti luodusta koodista, niin se vasta onkin haastavaa.
Yleensä koodin lukeminen ja ymmärtäminen on kuitenkin aika kohtuu helppoa. Jokseenkin vieraat syntaksit tuppaavat hidastamaan.

[AimoE]

Itsellä olisi kovasti haluja päästä tuosta Olio-ohjelmoinnista kärryille.
Etenkin erilasiten suunnittelumallien (design pattern) soveltaminen omiin tarpeisiin.

Suosittelen kirjaa "Refactoring", kirjoittaja Martin Fowler. Kannattaa hankkia omaksi jos vaan löytää sen jostain. Luet sen sitten ensin aloittelijan silmi, muöhemmin uudelleen kokeneemmin silmin. Miolemmilla kerroilla se avaa uusia näkökulmia. Kirjan esimerkit tosin on kirjoitettu Java-kielellä, mutta sillä ei ole mitään väliä, samat esimerkit voi vääntää milä tahansa ohjelmointikielellä, jossa on jonkinlainen oliomalli mukana. Osa esimerkeistä ei vaadi sitäkään. Itse koen tehneeni samoja siirtoja Cobol-kielellä kauan sitten 80-luvulla, ja kirjan lukeminen oli kiva elämys kun tajusin että jokainen ohjelmoija (jolla on oikeasti taupumusta ohjelmintiin) luonnostaan päätyy tekemään samoja siirtoja vaistomaisesti, enemmän tai bähemmän säntillisesti.

Edit: Refactoring ei varsinaisesti koske olio-ohjelmointia, vaan ohjelmointia ylipäätään. Siitä vain on helpointa esittää esimerkkejä oliomallien avulla, koska oliokoodissa siirtojen tavoite toteutuu selkeimmin.

[snifi]

Tässäkin olisi oma keskustelun aiheensa: Olio-ohjelmoinnin arvostus verrattuna muihin ohjelmointiparadigmoihin. Olio-ohjelmoinnista funktionaaliseen ohjelmointiin siirtyneenä tiedän, että olio-ohjelmointi on tänä päivänä yliarvostettua ja sen etuja liioitellaan.

[_Pete_]

Go:ssa on Javan tapaan pakollinen roskienkeruu, joka hieman rajoittaa kielen käyttömahdollisuuksia. Sillä ei esimerkiksi voi kirjoittaa ihan kernelitason koodia.

Kyllä pystyy: http://jnode.org/

 

[nm]

Go:ssa on Javan tapaan pakollinen roskienkeruu, joka hieman rajoittaa kielen käyttömahdollisuuksia. Sillä ei esimerkiksi voi kirjoittaa ihan kernelitason koodia.

Kyllä pystyy: http://jnode.org/

 

No joo.

Oikeastaan ajattelin olemassa olevan käyttöjärjestelmän laajentamista, kuten uuden ajurin kirjoittamista Linuxiin. Sekin voi kikkailulla olla periaatteessa mahdollista Go:lla tai Javalla, mutta itse en siihen lähtisi. Rust soveltuu sellaiseen matalan tason koodaukseen paremmin, ja on pitkällä tähtäimellä varteenotettava vaihtoehto C:lle käyttöjärjestelmäohjelmointiin.

[JA5U]

Ja toinen suuri ongelma tuppaa olemaan, että keksin uusia juttuja ennen kuin edellisetkään on valmiita.
Sitten lähden pykäämään sellaista elämäntarkoituksen ratkaisevaa geneeristä ratkaisua, joka taipuisi kaikkiin tuleviin tarpeisiin.

Tämän myötä törmäsin hiljattain YAGNI - You "Ain't Gonna Need It.
Eli ei tehdä sellaisia ominaisuuksia tai oteta niitä huomioon, jotka koetaan mahdollisesti vasta tulevaisuudessa hyödylliseksi.