KESKUSTELU

Sopiva suositus riippuu aika paljon siitä mikä on tavoite- ja ambitiotaso.

Jos kiinnostus on puhtaasti pienten sovellusten väsäämisessä omaan käyttöön ja helppojen harjoitustöiden teko koululle, niin varmaankin joku sopiva korkean tason oliokieli IDEineen on varmaakin oiva valinta. Itse suosittelisin Pythonia, koska sillä on äärimmäisen helppo lähteä liikkelle, mutta sillä kuintenkin potentiaalia varsin pitkälle.

Jos taas haluaa ymmärtää asiat perinpohjaisesti ja päästä kunnolla "sisuskaluihin" kiinni, niin sitten korkean tason kielistä on vain haittaa. Yksi suuri ongelma on esim. siitä, että ne usein abstrahoivat tietorakenteet ohjelmoijan näkymättömiin (tästä ei tietysti ole haittaa, jos on aiemmin opetellut asiat tai puskee töitä perustason koodarikulina, jolle joku muu kertoo mitä tietorakenteita ja algoritmejä käyttä).

Riittävän yksinkertaisella kielellä pääsee (eli siis joutuu) koodaamaan itse alusta alkaen kaikki aivan yksinkertaisimpia rakenteita lukuunottamatta. Tällöin pystyy omaksumaan sen, miten eri asioita kannattaa koodata ja esim. miten tietorakenteiden ja algoritmien valinta vaikuttaa suorituskykyyn, muistinkulutukseen jne.

Yksin kertaisista kielistä C olisi ainakin ilmeinen valinta - se ei ole kielistä mitenkään kaunein tai siistein, mutta ainakin sillä on mahdollisesti käyttöä jatkossakin - ainakin, jos haluaa tehdä jotain laiteläheistä tai peuhata muuten käyttöjärjestelmien kanssa. Toinen vaihtoehto olisi tietysti scheme...

Työelämää on monenlaista. Voisin yhtä hyvin väittää, että työelämässä tarvitaan .Nettiä. Riippuu ihan puhtaasti siitä minkä alan hommia päätyy tekemään.

Notepadia en edes laske tekstieditoriksi.

Kaikille nykykielille saa kehittyneet työkalut aivan ilmaiseksi, joten niiden perusteella ei valintaa tarvitse tehdä. Kunnollinen tekstieditori kuuluu joka tapauksessa ohjelmoijan työkalupakkiin, vaikka koodin vääntäisikin IDEssä.

Pitää taas mainostaa Project Euleria. Erinomainen tapa harjoitella kielen kuin kielen alkeita.* Samalla saa vähän harjoitusta algoritmeihin ja ongelmanratkaisuun yleensä. Koska tehtävissä toistuu tietyt peruskäsitteet, fiksu ohjelmoija oivaltaa tehdä uudelleenkäytettäviä osia, joten jotain suunnitteluymmärrystäkin saattaa kehittyä.

*: Toki noita tehtäviä voi ratkoa ihan kynällä ja paperillakin, mutta haastavaksi menee.

Auttaisi vähän jos tietäisi mitä alaa aiot opiskella. Hyödyllisin kieli vaihtelee paljon alan mukaan. Kannattaa katsoa opiskeliaoppaat, ja kurssikuvaukset sekä kurssien kotisivut.

Jos on todella tylsää voi ilmoittautua jo nyt avoimeen yliopistoon ja etäsuorittaa kursseja.

Tämäpä olikin hyvä vinkki, kiitos

Tietotekniikan osalta on ainakin tullut kuultua sellaista, että suurin osa "mää oon koodannut javaa 7-vuotiaasta alakaen" -tyypeistä valittaa peruskursiin kaikkille opiskelijoille yhteisen osan aikana kurssin "naurettavasta helppoudesta" - vaan sitten kun siirrytään tietotekniikan opiskelijoille spesifiseen osaan, niin nämä "lapsigurut" aloittavatkin vielä suuremman parkumisen opintojen järjettömyydestä ja - käsittääkseni - osa jopa lopettaa opintonsa tuohon.

Ilmeisesti se on vain niin vaikea tunnustaa, että kaikki mitä on itse oppinut vuosien saatossa onkin pelkää roskaa, joka pitäisi unohtaa, että pääsisi eteenpäin.

Miksi tyytyä tekstieditoreihin ja huonoihin valmistajakohtaisiin IDEihin, koska aina voi käyttää emacsia?

Niinpä! En ole vielä kohdannut DSP järjestelmiä, jossa tarvitaan JAVAA. Siellä C on edelleen se lähes ainut ja oikea kieli assyn rinnalla

C-kielen kun hanskaa, niin hanskaa kaikki muutkin + oppii ymmärtämään matalantason hommistakin jotain. Tosin mihin sitä matalantason osaamista tarvitaan, jos survoo UI koodia tms.

Joskus näin analogisen kellon Windowsissa, joka oli koodattu 100% assemblerilla. Tais mennä melko pieneen tilaan. Tosin nykyään on vähän hankala käyttää pelkkää assya moniydinprossuissa

Tässäpä varsin oiva koodaamisprojekti

Mutta koodin koko ja suoritusaika kunniaan, siirtykäämme assembleriin

Matalan tason ymmärryksestä on tietenkin aina hyötyä, mutta muuten tuo ei pidä paikkaansa. Vaikka Javan tai C#:n syntaksi on C:stä peritty, niin kielinä niillä ei C:n kanssa ole juuri mitään tekemistä. Proseduraalisesta oliokieleen siirtyvä joutuu opettelemaan paljon uusia asioita. Siirtymävaiheessa, joka voi kestää vuosia, ensimmäistä oliokieltä opetteleva koodari soveltaa pääasiassa aivan vääränlaisia (siis proseduraalisia) ongelmanratkaisu- ja suunnittelumalleja. Koodi on pullollaan staattisia metodeja ja luokiksi naamioituja structeja (IDE "auttaa" tässä, kun saa napin painalluksella julkiset getterit ja setterit kaikille kentille). Polymorfismia, perintää, rajapintoja ja abstrakteja luokkia tms. olio-ominaisuuksia ei ole hyödynnetty yhtikäs missään. On vain structeja ja niitä manipuloivia funktioita, joita vain nimitetään luokiksi ja metodeiksi.

Itse asiassa väittäisin, että samaan syntiin sortuvat myös pelkästään oliokielten kanssa peuhanneet ja kokeneetkin ohjelmoijat. Olioajattelu on vaikea oppia ja vielä vaikeampi soveltaa. En ole eläissäni nähnyt yhtään lähellekään tyylipuhdasta oliototeutusta. Enkä tehnyt.

Toisaalta tuohan on harvoin kellekään mikään päämäärä, ainakaan minusta "oliomaisuudella" ei ole itseisarvoa.

Ei tietenkään. Pitää nyt korjata sen verran, että olen myös nähnyt niitä hyviä ja jonkin verran oliomaisiakin toteutuksia. Tarkoitin vain sitä, että tyylipuhtauteen on vaikeaa tai mahdotonta päästä.

Jos työkaluksi on kuitenkin valittu oliokieli, toteutuksissa olisi ihan hyvä pyrkiä mahdollisimman oliomaisiin ratkaisuihin. Niitä ajatellen se kieli on suunniteltu, ja niissä se toimii parhaimmillaan.

Mikään lopullinen hopealuotiparadigma olio-ohjelmointikaan ei tietenkään ole.

Tavallaan totta turiset.

Tuo puhdas olioajattelu ja ohjelmointi on nykyään lähinnä harha-ajattelua. Firmoissa (niin suomessa kuin muuallakin) käytetään hyvinkin paljon erilaisia UML mallinnustyökaluja ja niillä jopa pyritään saamaan aikaan toimivaa koodia. Käsin koodatut C++ sovellukset on varsin kaukana olioajattelusta.

Eräässäkin suuressa saksalaisessa firmassa lähes kaikki oli mallinnettu ja hienoja luokkakaavioita yms. oli piirretty viimesen päälle, mutta kun koodiin vilkas, niin se kauheus paljastu. Siellä oli suvereenisti käytetty strukturaalisia tapoja. Eli kuten sanoit, tehty structeja, jotka "näyttää" luokilta. Kun jotain uutta oli lisätty, niin mallikaavioita ei oltu päivitetty. Ja itse mallikaaviot oli 3-4v vanhoja

Puhas mallinnus / olio-ohjelmointi on nykyään aikataulujen puiteissa melko hankalaa ja siks useimmissa isoissa alan firmoissa koodit on sitä C ja C++ sekamelskaa.

Matalantason softat onneks tehdään vielä perinteisellä C kielellä ja hyvin paljon embedded SW hommia tehdään vielä C-kielellä. Trendi on nykyään se, että erilaiset itsenäiset rautakortit, driverit, aktiivisensorit, modeemit, L2-L3 protokollakerrokset yms. toteutetaan pääosin C -kielellä.

Kyllähän tuo olio-ohjelmointi välillä tuottaa aika hupaisia implementaatioita, esim.

http://www.vtk.org/doc/nightly/html/cla ... _graph.png

Googlen C++ -ohjeistus on aika lähellä sitä, miten meilläpäin on pyritty asioita käytännössä toteuttamaan.

Monesti kun siirrytään IT-puolesta insinöörisovellusten kautta tieteelliseen laskentaan, niin oliopohjaiset kielet vaihtuvat proseduaalisiin, eikä tarvitse mennä edes kovin hard core sovelluksiin kun hallitsevaksi kieleksi tulee Fortran.

Tuo kaavio taitaakin olla sitä nykytaidetta olioajattelulla höystettynä....

Nuo C++ ohjeistukset on monessa firmassa varsin hyvällä tasolla. Projektin alussa niitä noudaetaan pilkuntarkkaan. Mutta ongelma usein piileekin vanhoissa koodeissa, joita on päätetty käyttää uudessa tuotteessa. Sieltä kun löytyy varsin mielenkiintoisia "olioita", joiden modaaminen projektin haluamalle tasolle on vaivalloista. Ja jos aikataulu on tiukka, niin vanhaan koodiin sörkitään nopeasti halutut muutokset ja sovitaan, että tehdään uus ja parempi kun jää aikaa. Ja senhän nyt sitten tietää miten siinä käy. Eli vanhat oliohässäkät tunataan kuntoon ja taas sama ongelma odottaa toista projektia

Olis joskus mukava päästä sellasiin hommiin, jossa alkuperäinen roska on tehty alusta saakka oikeilla menetelmillä ja olioajattelulla. Sellaselle toiminnalle nostaisin hattua

DSP hommissa C on aivan ykkönen. Nykykääntäjät tekee hyvin hyvin tiivstä koodia ja osaa ottaa huomioon esim. käskyjen rinnakkaisajoa jne. Kooduksessa joutuu käyttämään muutamia jippoja, joilla kääntäjä tajuaa että nyt lasketaan ALU A rekkareilla ja nyt B:n rekkareilla. Hyvin harvoin kannattaa käsin koodailla assya nyky DSP:lle. Kääntäjät tarjoo ns. intrinsic -toimintoja joilla pääsee käsiks DSP spesiaalisiin käskykantoihin. Kääntäjä on joskus jopa niin fiksu, että osaa C koodista päätellä, että tässä kohtaa voisi käyttää sisäänrakennettuja käskykantoja.

Kääntäjät mahdollistaa C++ koodin, mutta sitä ei käytetä, kun käyttikset on useimmiten kaupallisia ja varsin tehokkaasti optimoitu juuri siihen DSP prossuun. Voipi olla että firmat eivät ole ottaneet riskiä siirtyä C:stä C++:aan sen takia, että reaaliaika laskenta vaatimukset tunnetaan nykykoodista ja C++ on kuin musta verho systeemisuunittelijoille. Vaikkakin siitä voisi olla hyötyä ylläpidossa ja uudelleenkäytettävyyden ansiosta. Nykyisten yksittäisten DSP verkkokomponenttien koodi koko on kuitenkin kymmenien megatavujen luokkaa, ja joka ei muuta tee kuin murskaa numeroita niin hätäseen kun mahdollista. Niin voisi olla tavallaan perusteltua mallintaa koko DSP arkkitehtuuri uudelleen olioajattelulla.

Mielnkiintoista olisi nähdä / kuulla mielipiteitä asiasta.