Osaisiko joku yksinkertaisesti selittää tuon Cosan perusperiaatteen. En oikein päässyt sisään tuohon englanninkieliseen pitkään dokumenttiin. Onko se vain joku visuaalinen viritelmä vai onko siinä jotain uutta?
(Ymmärrän kyllä yleiset ohjelmointitekniikat, paitsi funktionaaliset kielet ovat osittain käsittämättömiä.)
(Ymmärrän kyllä yleiset ohjelmointitekniikat, paitsi funktionaaliset kielet ovat osittain käsittämättömiä.)
Vastaukset 13
Vanhimmat
1. Tärkeintä on mielestäni komponenttien (olioiden) synkronisuus. Kaikki toimivat tasatahtiin. Kun esim. C :ssa kutsutaan toisen olion metodia, niin kutsuja vaimenee siihen asti kunnes kutsu palaa. Cosassa viestin lähettäjä jatkaa toimintaansa. Cosa toteuttaa "virtuaalisen ajan", jota komponentit noudattavat. Tämä ei ole ainutlaatusta. Monet muutkin ohjelmointiympäristöt pystyvät samaan.
2. Toinen tärkeä asia on tuo visuaalisuus. Tekstipohjaista ohjelmointia ei käytetä ollenkaan. Minusta tämä on hieno juttu ylemmillä hierarkisilla tasoilla, mutta ihan pohjalla tarpeetonta.
3. Kolmas oli kai selkeä ero aktiivisten olioiden
ja dataolioiden kanssa. Tämä on mielestäni takapakkia olio-ohjelmoinnista.
Nämä olivat kai kolme pääasiaa. Moni asia jäi auki, kuten esim. dynaamisten datarakenteiden toteutustapa. Ei se silti ole mitenkään ristiriidassa esitetyn kanssa. Varmaan onnistuu helposti. Unohdinkohan jotakin tärkeää?
Minusta sivut ovat havainnolliset ja selkeät. Fanaattisuus, suuret lupaukset ja vanhojen paradigmojen haukkuminen hieman häiritsee, mutta ei paljon :)
"1. Tärkeintä on mielestäni komponenttien (olioiden) synkronisuus"
Hienoa! Sitenhän olioiden tulisi toimia, että ne olisivat "oikeita" olioita. Vertauksena: Eihän kahvinkeittimellekään luovuteta aikaa.
Tosin tuollalailla ohjelmoiminen taitaa tulla paljon mutkikkaammaksi.
Henkilökohtaisesti en pidä olioista hirveästi, koska se on vain yhdenlainen lähestymistapa ohjelmointiin. Se jotenkin rajaa kaikki byrokraattiseksi maksimaalisen tehokkuuden vuoksi. Niin kuin kahvinkeitin olisi pelkkä kahvinkeitin, vaikka monille sekin on enemmän. Puhumattakaan muista luonnon olioista, vaikka ihmisistä.
Uudet tietokonepelitkin ovat liian samanlaisia, kun aina pitää käyttää yleisiä virallisia polygoni-hahmoja ja muita olioita, jotka on ennalta kapseloitu paketeihinsa. Commodore-aikaan uskallettiin kokeilla kaikkia tekniikoita. No, olihan silloinkin "spritet" tavallaan olioita, mutta ne olivat vapaammin ohjelmoitavissa jo pelkästään yksinkertaisuuden vuoksi.
Joten olisi hyvä jos jotenkin vapaammaksi ohjelmointia saataisiin, mutta vaikeaa se on nykypäivän monimutkaisuudella. Tuskin Cosakaan siihen pystyy. Itse en oikein ymmärrä tuota ctrl-alt-del-esimerkin toimintaakaan.
"
Tosin tuollalailla ohjelmoiminen taitaa tulla paljon mutkikkaammaksi.
"
Mutkikkuus jää koneen huoleksi. Käyttäjälle se on helpompaa. Eihän siinä muuten olisi mitään ideaa.
"Se jotenkin rajaa kaikki byrokraattiseksi maksimaalisen tehokkuuden vuoksi."
Tehokkuutta kuuluu maksimoida, koska useimmat ohjelmoijat ohjelmoivat työkseen, ja haluaisivat lisää vapaa-aikaa tai lisää rahaa(pomot haluaa aina lisää rahaa). Koneen pitää hoitaa vähemmän luovat tehtävät ohjelmoinnissa (ja lopulta myös luovat tehtävät).
Parempiakin vastaajia tähän löytynee jostain esim. yliopistoista ja ohjelmistofirmoista, mutta minun mielestäni tärkein yksittäinen idea on datariippuvuuksien automaattinen selvitys(epävirallinen suomennos). Toisaalta COSA:ssa on parasta se kokonaisuus.
Mitäs muuten jos COSA:aa voisi ohjelmoida sillä tavalla, että vasemmassa kehyksessä/ikkunassa näkyy graafinen esitys ja oikeassa tekstuaalinen esitys. Aina kun lisää jommallakummalla tavalla ohjelmistoprojektiin uusia soluja yms., niin se ilmestyy toiseen ikkunaan automaattisesti.
Kone voisi tiettyä nappia klikkaamalla optimoida graafisen esityksen selkeyden eli esim. minimoida kytkentöjen risteämiset ja minimoida kytkentöjen yhteispituuden. Se ei vaikuttaisi itse ohjelmaan, vain siihen miten ihminen sen näkee ruudulla.
Tässä on se sivusto vielä kerran:
http://users.adelphia.net/~lilavois/Cosas/Reliability.htm
1.Ainiin, mitä jos COSA-kuvauksista tehtäisiinkin epäsynkronisia algoritmeja, kääntäjällä(compiler) joka automaattisesti ja mutkikkaasti selvittää ja todistaa kaiken osuvan kohdalleen? Se lisäisi nopeutta ja vähentäisi muistin tarvetta. En tiedä miten paljon...
2.Tässä on eräs toinen sivusto:
http://feedler.twoday.net/
"minun mielestäni tärkein yksittäinen idea on datariippuvuuksien automaattinen selvitys(epävirallinen suomennos)"
Selitä tuota vähän enemmän.
Onko Cosa ns. "monimutkaisuuden hallintaa" vai mitä? Yrittetäänkö sillä helpottaa ohjelmarakenteen käsittämistä? Pystyyko aloittelija oppimaan Cosaa? Miksi perinteinen ohjelmoiminen on kriisissä? Miten tuo ctrl-alt-del esimerkki toimii, ja miksi se kannattaisi toteuttaa niin Cosalla?
Harmi ettei tuosta ole suomenkielistä tekstiä missään, kun tuon sivun englanti on niin hankalaa.
Ymmärtääkseni kaikkien ohjelmoinnin paradigmojen perimmäinen tavoite on monimutkaisuuden hallinta. Olen aina itselleni selvittänyt tämän siten, että tavalla tai toisella (ohjelmalohkot, datarakenteet, aliohjelmat, oliot, synkroniset komponentit..) luodaan hallittavia, täysin testattuja (yksikkötestaus!!!) kokonaisuuksia, joiden väliset rajapinnat ovat niin yksinkertaisia ja helposti käytettäviä kuin mahdollista, vaikkapa suorituskyvyn kustannuksella. Tällaisista lohkoista tehdään sitten hierarkiatasojen avulla yhä laajelmpia, monimutkaisempia, mutta hallittavia ohjelmia. Kerralla tarkasteltava kokonaisuus täytyy aina olla hallittavissa, täysin ymmärrettävissä, se ei saa olla ylivoimaisen monimutkainen. Monimutkaisuus piilotaan.
Mielestäni synkroniset komponentit piilottavat hyvin tehokkaasti monimutkaisuutta. Sitä Cosin sivuillakin painotetaan verrattaessa HW-suunnitteluun. Mutta ASIC-suunnittelussakin yksikkötestauksessa nähdään hirvittävästi vaivaa. Komponentin testipenkin ohjelmointi on yhtä suuri vaiva kuin itse komponentin suunnittelu. Luotettavuutta ei saada synkronisessa ohjelmoinnissakaan ilmaiseksi.
Mielestäni suurin yksittäinen syy ohjelmien huonoon laatuun, epäluotettavuuteen, on yksikkötestauksesta, ja testauksesta yleensäkin tinkiminen (aikataulu- ja taloudellisista syistä). Syytän johtajia, en ohjelmoijia.
Datariippuvuuksien automaattinen hallinta edellyttää mielestäni formaalista analyysiä, joka ei jostakin syystä ole yleistynyt. Siihen ei ole kai osattu tehdä automaatiota, joka olisi riittävän helppoa käyttää.
Tästä käsitteestä lisää:
http://www.ewh.ieee.org/soc/es/May2001/11/Begin.htm
"Tehokkuutta kuuluu maksimoida, koska useimmat ohjelmoijat ohjelmoivat työkseen, ja haluaisivat lisää vapaa-aikaa tai lisää rahaa(pomot haluaa aina lisää rahaa). Koneen pitää hoitaa vähemmän luovat tehtävät ohjelmoinnissa (ja lopulta myös luovat tehtävät)."
Siltä se näyttää. On huvittavaa että ohjelmoijien suurin tavoite on tehdä itsestään helposti korvattavia! Pomon on helppo vaihtaa ohjelmoijia, kun jokainen yksityiskohtakin on standardisoitu ja kapseloitu.
"Hiljainen tieto" ei todella ole ohjelmoijilla muotissa. Kaikki pitäisi järjestää ja dokumentoida muille ohjelmoijille ja itselleenkin. Dokumentointi on hieno sana mutta mitä jo Platon sanoi kirjoittamisesta:
http://www.uta.fi/~tierka/viisaus.htm
Pieni kaaos vain parantaa ohjelmoijan muistia ja hahmottelukykyä. Sitäpaitsi kun jonkun saman työn tekee montakin kertaa, sen tekee joka kerran aina nopeammin ja paremmin. Valmiit moduulit kannattaisi tehdä vain jatkuvasti tarvittaville toiminnoille.
Ehkä liian paljon arvostetaan "hyvien ohjelmointitapojen" omaksumista. Toisaalta yliarvioidaan ohjelmointitehtäviä vaikeimmiksi, kun ne vähän "ovelasti" toteutettuna olisikaan. Muttei uusiin ohjelmointitekniikoihin perehtyminen silti haittaa, vaikka ohjelmoisi rivinumerobasicilla. :D
"Pieni kaaos vain parantaa ohjelmoijan muistia ja hahmottelukykyä. Sitäpaitsi kun jonkun saman työn tekee montakin kertaa, sen tekee joka kerran aina nopeammin ja paremmin. Valmiit moduulit kannattaisi tehdä vain jatkuvasti tarvittaville toiminnoille."
Kaaos on usein niin väistämätöntä, että siihen ei mitenkään eksplisiittisesti kannata pyrkiä.
Ainoat kunnolla dokumentoidut projektit, jotka olen nähnyt, ovat olleet ulkoistettuja tilaustöitä, joissa tilaaja on edellyttänyt kunnon dokumentointia ennen laskun maksamista. Sisäisissä projekteissa fuskataan lähes aina ja on karmeaa jatkaa jonkun toisen hommaa, jos tekijä ei enään ole paikalla kommentoimassa aivoituksiaan. Sama koskee omia esim. vuoden takaista koodia.
Hyvät työtavat eivät tee ohjelmoijia työttömäksi. Ne antavat työhön mielekkyyttä ja vähentävät stressiä.
Se mitä Platon kirjoitti on ihan asiaa, mutta ei mielestäni paljon liity tähän.
"Kaaos on usein niin väistämätöntä, että siihen ei mitenkään eksplisiittisesti kannata pyrkiä."
Tavallaan. Mutta toistaalta kaaos on niin väistämätöntä, ettei sitä voi estää.
"Sisäisissä projekteissa fuskataan lähes aina ja on karmeaa jatkaa jonkun toisen hommaa, jos tekijä ei enään ole paikalla kommentoimassa aivoituksiaan. Sama koskee omia esim. vuoden takaista koodia."
On varmaan jokin hyvä syy, miksi näin tapahtuu kaikilla. Joskus itsekin innostun dokumentoimaan tarkoin kaikkea, mutta sitten se taas unohtuu. Kyllä jotenkin luulisin, että ohjelmoija saa päähänsä tuon Platonin ajatuksen, vaikka se tekeekin todella pahaa ohjelman jatkoa ajatellen.
Ehkä järjestystä maailmaan saadaan vain, kun sen tekee yksi auktoritaarinen vaikuttaja, hyvänä esimerkkinä Microsoft. Valitettavasti.
"Liian tuottavaa?"
No ehkä, vaikea sopeutua noihin tapoihin. Ohjelmointi kiinnostaa minua muualtakin, kun vain tuotannollisista lähtökohdista. :-)
"Ehkä järjestystä maailmaan saadaan vain, kun sen tekee yksi auktoritaarinen vaikuttaja, hyvänä esimerkkinä Microsoft. Valitettavasti. "
Mainitsin edellä tuon ohjelman ulkoistettu toimittaja/tilaaja suhteen. Se takaa tehokkaasti kunnon työtavat. Silloin toimittajan projektisuunnittelunkin on pakko ottaa aikatauluissa kunnon dokumentointi ja testaus huomioon jo tarjousta tehdessä, muuten urakka kusee 101% varmuudella.
Mutta on menty kauas pääasiasta... :)
"Mainitsin edellä tuon ohjelman ulkoistettu toimittaja/tilaaja suhteen. Se takaa tehokkaasti kunnon työtavat."
Ainakin se takaa ohjelmistotuotantoon sopivat tavat.
Aikaisemmin kirjoitit: "Tehokkuutta kuuluu maksimoida, koska useimmat ohjelmoijat ohjelmoivat työkseen"
Ohjelmoivatko? Itse olen sellainen Pelle Peloton-ohjelmoija, eli ohjelmoin enimmäkseen kokeiluluonteisia ohjelmia omaan käyttöön huviksi, hyödyksi ja haitaksi. Kokoamani funktiokirjastot kyllä ehdottomasti nopeuttavat ohjelmointiani.
"Aikaisemmin kirjoitit: "Tehokkuutta kuuluu maksimoida, koska useimmat ohjelmoijat ohjelmoivat työkseen" "
Se taisi olla Ville.
Samat havainnot kuitenkin koskevat tavoitteellista harrasteohjelmointia (esim Open Source projektit) sekä taloudellisten realiteettien kahlitsemaa leipätyötä. Joku virtuuosi voi boheemilla, kaaoottisella, luovalla otteella saada jotakin merkittävää aikkaiseksi, mutta me tavikset tarvitsemme paradigmoja tueksemme.
Fast prototyping-ajattelu sallii projektin aluksi jonkinlaisen luovan irroittelun, mutta kun siitä on tulokset saatu, on pudottauduttava maanpinnalle ja otettava tuki hyviksi koetuista menetelmistä, joihin kuuluu esim. yksikkötestaus ja perusteellinen dokumentointi. Muuten ei tule tuloksia.
En ole tullut tätä hirveästi ajatelleeksi. Itse olen siis ohjelmoijana ilmeisesti hyvinkin taiteilijatyyppiä. Tosin ilman mitään paradigmoja ja kommentointia en minäkään saisi ohjelmia aikaiseksi. En pidä liian määräävistä paradigmoista, joihin joutuisin omat erikoiset ohjelmani sopeuttamaan. Ne jopa lisäisivät minun ohjelmointiaikaa.
Ohjelmointiympäristöni tulisi olla mahdollisimman "hiekkalaatikkomainen" (en tarkoita tietokoneen kannalta kuten Java). Tulokset pitäisi nähdä välittömästi. Olen käyttänyt Visual Basicia ja Pythoniinkin olen tutustunut. Java ja C kielien kanssa en ole tullut toimeen.
Tällaisiakin erikoistapauksia siis löytyy ohjelmoinnin piiristä.