1960-luvun lopun ohjelmistokriisillä tarkoitettiin tilannetta, jossa pula ohjelmoijista ja selkeiden systeemityömenetelmien puuttuminen johti heikkoon tuottavuuteen, bugisiin ohjelmiin ja kustannusten karkaamiseen käsistä. Väitän, että nyt ollaan taas menossa ohjelmistokriisiin, tosin tällä kertaa eri syistä.
1) Ohjelmointimaailma on pysyvästi jakautunut kahteen leiriin: Microsoft ja Java. Ohjelmoijia, jotka perinpohjaisesti tuntisivat molemmat on äärimmäisen vähän. Aika ei vaan riitä molempiin. Vaikka uuden ohjelmointikielen oppiminen on kokeneelle koodarille triviaalia, niin sen kielen päälle tulevan sälän (kirjastojen, frameworkien, käytäntöjen, dokumentoimattomien piirteiden "jotka pitää vain tietää", jne...) opettelemiseen ja ennen kaikkea jatkuvaan seuraamiseen ei kenenkään aika riitä. Varsinkin jos on muutakin elämää, vaikkapa perhe tai harrastuksia tai molemmat. Itse olen valinnut Java-leirin eikä mulla siis ole enää mitään asiaa duuneihin, joissa haetaan C#/.net osaajia.
2) Frameworkit syövät tuottavuuden. Frameworkin idea on helpottaa koodausta, mutta moniko oikeasti tekee niin? Vika ei ole ole frameworkin ideassa, vaan siinä että tyypillinen framework, ainakin Java-maailmassa
a) yrittää kattaa kaiken mahdollisen maan ja taivaan väliltä
b) käyttää omaa terminologiansa jossa samat käsitteet on taatusti nimetty eri lailla kuin kilpailevissa frameworkeissa
c) oppimiskäyrä on yleensä jyrkkä koska dokumentaatio on puutteellista tai laahaa pari versiota perässä
d) korvautuu seuraavalla juuri kun olet ehtinyt oppia sen
e) on open sourcea, jonka dokumentaatiosta tai bugifixeistä ei vastaa kukaan eikä ne ketään kiinnosta
Käytännön esimerkki: vuosia sitten suunnittelin erästä web-pohjaista järjestelmää. Tutustuin silloin kuuminta hottia olleeseen Strutsiin. Tein sillä pari pilottiakin. Aivan järjetön käsitteiden sekamelska! Niihin aikoihin dokumentitkin oli vielä suunnilleen JavaDocien tasoa. Pelkään opetteluun olisi mennyt enemmän aikaa kuin olisi säästynyt sitä käyttämällä. Koodasin siis systeemin astetta matalammalla tasolla:
logiikan servelteillä, persistenssin JDBC:llä ja GUI:n JSP:llä. Toimii edelleen ja on helppo ylläpitää. Ok, ymmärrän, framework toteuttaa valmiina monet asiat, jotka jouduin itse koodaamaan - ja luultavasti paljon paremmin ja luotettavammin kuin yksittäinen koodaaja ne tekee. Mutta varsinainen pointti onkin tämä: kuka enää muistaa koko Strutsia? Nyt in ovat Spring Hibernate Wicket. Vaan kuinkahan kauan? Onko niihin investoitu osaaminen taas kuraa parin vuoden päästä?
3) Järjestelmät ovat liian monimutkaisia. Kuka muistaa ajan, jolloin koodattiin pikku ohjelmia Turbo Pascalilla? Jos koneen suorituskyky ei riittänyt, väännettiin tiukimmat rutiinit assemblerilla. Laskennalliset ongelmat ratkaistiin Fortranilla suurkoneympäristössä. Ei ollut hienoa GUI:ta, mutta ohjelmat toimivat ja tekivät sen mitä ne oli tarkoitettu tekemään. Yleensäkin IT:n tuominen jokajampan työpöydälle oli suuri virhe. Kuka oikeasti käyttää edes 5% Wordin toiminnoista? Kuka ehtii edes opetella niitä ennen kuin mikkisoftin pajasta pukataan ulos seuraava versio, jonka toiminnoista taas 95% on turhia. Wordstarista löytyisi kaikki ne ominaisuudet, jota oikeasti tekstinkäsittelyssä tarvitaan. Internet jokaisen ulottuville on ehkä ainoa hyödyllinen "keksintö" joka on tehty 1980-luvun jälkeen. Mutta sekin on pilattu kaiken maailman javascript- ja flash-härpäkkeillä. SOA on ainoa tie joka voi pelastaa siltä kaaokselta.
Kommentteja? Onko monumentaalisten softien aika ohi? Siirrytäänkö takaisin tekemään toimivia pikku ohjelmia, joita voi linkittää yhteen verkon yli standardeja rajapintoja (esim. SOAP) käyttäen? Milloin loppuu tää jatkuva uusien frameworkinen opettelu ja pääsee keskittymään varsinaisen businesslogiikan koodaamiseen? Milloin saadaan se yksi ja ainoa ohjelmointikieli, joka ratkaisee kaikki ongelmat ja jonka osaaminen vihdoinkin riittää?
1) Ohjelmointimaailma on pysyvästi jakautunut kahteen leiriin: Microsoft ja Java. Ohjelmoijia, jotka perinpohjaisesti tuntisivat molemmat on äärimmäisen vähän. Aika ei vaan riitä molempiin. Vaikka uuden ohjelmointikielen oppiminen on kokeneelle koodarille triviaalia, niin sen kielen päälle tulevan sälän (kirjastojen, frameworkien, käytäntöjen, dokumentoimattomien piirteiden "jotka pitää vain tietää", jne...) opettelemiseen ja ennen kaikkea jatkuvaan seuraamiseen ei kenenkään aika riitä. Varsinkin jos on muutakin elämää, vaikkapa perhe tai harrastuksia tai molemmat. Itse olen valinnut Java-leirin eikä mulla siis ole enää mitään asiaa duuneihin, joissa haetaan C#/.net osaajia.
2) Frameworkit syövät tuottavuuden. Frameworkin idea on helpottaa koodausta, mutta moniko oikeasti tekee niin? Vika ei ole ole frameworkin ideassa, vaan siinä että tyypillinen framework, ainakin Java-maailmassa
a) yrittää kattaa kaiken mahdollisen maan ja taivaan väliltä
b) käyttää omaa terminologiansa jossa samat käsitteet on taatusti nimetty eri lailla kuin kilpailevissa frameworkeissa
c) oppimiskäyrä on yleensä jyrkkä koska dokumentaatio on puutteellista tai laahaa pari versiota perässä
d) korvautuu seuraavalla juuri kun olet ehtinyt oppia sen
e) on open sourcea, jonka dokumentaatiosta tai bugifixeistä ei vastaa kukaan eikä ne ketään kiinnosta
Käytännön esimerkki: vuosia sitten suunnittelin erästä web-pohjaista järjestelmää. Tutustuin silloin kuuminta hottia olleeseen Strutsiin. Tein sillä pari pilottiakin. Aivan järjetön käsitteiden sekamelska! Niihin aikoihin dokumentitkin oli vielä suunnilleen JavaDocien tasoa. Pelkään opetteluun olisi mennyt enemmän aikaa kuin olisi säästynyt sitä käyttämällä. Koodasin siis systeemin astetta matalammalla tasolla:
logiikan servelteillä, persistenssin JDBC:llä ja GUI:n JSP:llä. Toimii edelleen ja on helppo ylläpitää. Ok, ymmärrän, framework toteuttaa valmiina monet asiat, jotka jouduin itse koodaamaan - ja luultavasti paljon paremmin ja luotettavammin kuin yksittäinen koodaaja ne tekee. Mutta varsinainen pointti onkin tämä: kuka enää muistaa koko Strutsia? Nyt in ovat Spring Hibernate Wicket. Vaan kuinkahan kauan? Onko niihin investoitu osaaminen taas kuraa parin vuoden päästä?
3) Järjestelmät ovat liian monimutkaisia. Kuka muistaa ajan, jolloin koodattiin pikku ohjelmia Turbo Pascalilla? Jos koneen suorituskyky ei riittänyt, väännettiin tiukimmat rutiinit assemblerilla. Laskennalliset ongelmat ratkaistiin Fortranilla suurkoneympäristössä. Ei ollut hienoa GUI:ta, mutta ohjelmat toimivat ja tekivät sen mitä ne oli tarkoitettu tekemään. Yleensäkin IT:n tuominen jokajampan työpöydälle oli suuri virhe. Kuka oikeasti käyttää edes 5% Wordin toiminnoista? Kuka ehtii edes opetella niitä ennen kuin mikkisoftin pajasta pukataan ulos seuraava versio, jonka toiminnoista taas 95% on turhia. Wordstarista löytyisi kaikki ne ominaisuudet, jota oikeasti tekstinkäsittelyssä tarvitaan. Internet jokaisen ulottuville on ehkä ainoa hyödyllinen "keksintö" joka on tehty 1980-luvun jälkeen. Mutta sekin on pilattu kaiken maailman javascript- ja flash-härpäkkeillä. SOA on ainoa tie joka voi pelastaa siltä kaaokselta.
Kommentteja? Onko monumentaalisten softien aika ohi? Siirrytäänkö takaisin tekemään toimivia pikku ohjelmia, joita voi linkittää yhteen verkon yli standardeja rajapintoja (esim. SOAP) käyttäen? Milloin loppuu tää jatkuva uusien frameworkinen opettelu ja pääsee keskittymään varsinaisen businesslogiikan koodaamiseen? Milloin saadaan se yksi ja ainoa ohjelmointikieli, joka ratkaisee kaikki ongelmat ja jonka osaaminen vihdoinkin riittää?
Vastaukset 11
Vanhimmat
"1) Ohjelmointimaailma on pysyvästi jakautunut kahteen leiriin: Microsoft ja Java..."
"2) Frameworkit syövät tuottavuuden..."
"3) Järjestelmät ovat liian monimutkaisia..."
Eivätkö nämä ongelmat ole vain Java/C# -spesifisiä? Esimerkiksi sulautettujen ohjelmointiin tämä ei päde, ei automaatiojärjestelmien graafisiin ohjelmointisysteemeihin eikä moneen muuhunkaan. Ylläolevat ongelmat kuulostavat oikeasti samoilta kuin siinä 60-luvun kriisissä -- koska koko työtapa näyttää olevan sama kuin 60-luvulla -- siis tässä Java/C# -erikoistapauksessa.
"Kommentteja? Onko monumentaalisten softien aika ohi? Siirrytäänkö takaisin tekemään toimivia pikku ohjelmia, joita voi linkittää yhteen verkon yli standardeja rajapintoja (esim. SOAP) käyttäen? Milloin loppuu tää jatkuva uusien frameworkinen opettelu ja pääsee keskittymään varsinaisen businesslogiikan koodaamiseen? Milloin saadaan se yksi ja ainoa ohjelmointikieli, joka ratkaisee kaikki ongelmat ja jonka osaaminen vihdoinkin riittää?"
Toimivien hyvin määriteltyjen pikkuohjelmien/järjestelmien periaate on se tapa, mikä on yhteensopiva yleisen insinöörilähestymistavan kanssa. Siksi näin yleensä toimitaankin -- poislukien sitten ilmeisesti Java- ja C#-softat. Yhden ohjelmointikielen periaatteessa on se ongelma, että sama työkalu ei vaan sovi kaikkeen -- ihan niin kuin joskus vasaran lisäksi saattaa olla tarvetta ruuvarillekin vaikka kyllä periaatteessa kummallakin voi tehdä kummankin työt. Automaatioon sopii graafinen ohjelmointi, palvelimiin nämä Java/C# systeemit sekä skriptikielet, numeeriseen laskentaan Matlab, sulautettuihin C/assembler/Ada jne.
"1) Ohjelmointimaailma on pysyvästi jakautunut kahteen leiriin: Microsoft ja Java."
Ehei. Nykyisin on useita alustoja joiden päälle kirjotetaan softaa. Näistä merkittäviä on Java, LSB (GTK ja Qt), .NET, PHP, Python yms.
"a) yrittää kattaa kaiken mahdollisen maan ja taivaan väliltä"
Joka johtaa liian isoon kokonaisuuteen. Toimivampaa on usein joku subsetti siihen hommaan mitä tekee, ja tarvittaessa sen tekee vaikka itse tai oppii poimimaan siitä frameworkista ne jutut mitä itse tarvitsee asioissa mikä tekee mutta vaatii sen frameworkin hallintaa. Käytännössä osaava ohjelmoija tekee millä vaan, mutta tarvitsee "sisäänajon" tekemällä jotain hommiin liittyvää softaa että tietää mitä kutsuja siitä ympäristöstä löytyy mille on kirjoittamasta ja saa pidettyä homman kasassa oman pään sisällä. Jonkun kokonaisen Javaympäristön yms. perusteellinen hallinta on loppujen lopuksi ajan hukkaa kun lähitulevaisuudessa kuitenkin ei ole enää se oikea työkalu siihen hommaan mitä on tekemässä.
"c) oppimiskäyrä on yleensä jyrkkä koska dokumentaatio on puutteellista tai laahaa pari versiota perässä"
Ennemminkin on turhan iso kokonaisuus hallittavaksi.
"e) on open sourcea, jonka dokumentaatiosta tai bugifixeistä ei vastaa kukaan eikä ne ketään kiinnosta"
Nykyisin melkein kaikki on open sourcea, ja niiden dokumentaatiosta ja korjauksista vastaa ne ketkä tekniikkaa tekee.
"Nyt in ovat Spring Hibernate Wicket. Vaan kuinkahan kauan? Onko niihin investoitu osaaminen taas kuraa parin vuoden päästä?"
No ihan varmasti.
"Milloin saadaan se yksi ja ainoa ohjelmointikieli, joka ratkaisee kaikki ongelmat ja jonka osaaminen vihdoinkin riittää?"
Ei näillä näkymin "ikinä" kun lähes jokainen uusi kieli on jossain jutuissa parempi edellisiä. Parempi osata vaan eri paradigmat ja C:n sukuisten kielten syntaksi kun se on tällä hetkellä sellainen ohjelmointikielten lingua franca.
Joo, siis aluperäinen postaukseni oli tietysti kärjistys. Ei ole eikä tule vain yhtä ja ainoaa ohjelmointikieltä, kyllä minä sen tiedän. Ajatusleikkinä se olisi hieno: kerrankin uusi osaaminen kertyisi vanhan päälle, ei sen tilalle.
Totta myös, että ongelmat on aika Java/C#-spesifisiä. Pankeissa ja vakuutusyhtiöissä on edelleen miljoonia rivejä Cobolia ja APL:ää. Sulautetuissa tehdään pientä, kaunista ja toimivaa koodia. Kirjoitin siitä minkä itse parhaiten tunnen: uudet, monimutkaiset ja suuret serveripään ohjelmistot. Mut ehkä nää systeemit onkin vain epäonnistunut sivupolku ohjelmoinnin historiassa ja kuolevat kohta möhkötautiinsa. Toivotaan niin!
Mitä tulee useimpiin Java-frameworkeihin, ei niitä voi ottaa käyttöön vain osittain tai silloin sun täytyy tuntea framework läpikotaisin jos haluat käyttää sitä muuten kuin dokumentaatiossa kerrotulla "all-or-nothing" periaatteella. Koodasin juuri yhtä järjestelmää Springin päälle (asiakkaan vaatimuksesta). Aivan hirveä erkka-purkka-viritys, sekoitus annotaatioita, xml-tiedostoja ja introspektiota. Tekijät luulevat, että helppokäyttöisyys on sitä, että ohjelmoijan ei tarvitse ymmärtää mitä konepellin alla tapahtuu vaan asiat loksahtelee paikoilleen automaattisesti nimeämiskäytäntöjen perusteella. My ass! Teet dokumentaation mukaan ja toivot että kaikki toimii. Jos ei toimi, niin googlettamaan ja toivomaan että joku muukin on saanut saman stack tracen. Ei mitään kokonaiskuvaa systeemistä, ei mitään ymmärrystä miten palaset oikeasti liittyvät toisiinsa. Jos sellaisen kuvan haluaisi, pitäisi lukea (kymmeniä)tuhansia rivejä sorsakoodia niin näkisi miten asiat oikeasti on. Mutta kellä on aikaa ja mikä asiakas sen suostuu maksamaan? Ja vuoden päästä se osaaminen on jo vanhentunutta.
Ehkä .net-maailmassa asiat on vähän paremmin? Se on yhden toimijan käsissä ja ehkä siksi edes jotenkin pysyy kasassa. Aikanaan koodasin paljon Delphillä ja siinä viehätti välineen "rajallisuus": asiat on niin kuin Borland on päättänyt ja manuaaliin kirjoittanut. Siihen verrattuna Java on muodoton, jatkuvasti paisuva pullataikina, joka pilaantuu keskeltä sitä mukaa kun uutta valmistuu reunoille. Mutta minkäs teet kun asiakas vaatii Javaa. Jonkun pitäis puhkaista tää kupla ja pian!
"Ehkä .net-maailmassa asiat on vähän paremmin? Se on yhden toimijan käsissä ja ehkä siksi edes jotenkin pysyy kasassa."
Samalla tavalla se Java pysyy kasassa kun ei käy leikkimään niillä muiden virityksillä. Jos asiaskas haluaa, että niiden kanssa tapellaan niin se näkyy sitten hinnassa.
Itse en Javalla tee nyt mitään, mutta jos tekisin niin tekisin puhtaasti tuoreen OpenJDK:n päälle suoraan ilman mitään lisä härdelliä ja karsisin kaiken deprecated kaman pois. Sitten kun homma toimii sillä niin ajaisin siinä ympäristössä missä olisi tarkoitus ajaa ja teen muutokset jos jotain tarvitsee, että homma toimii.
Vastaavasti .NET:llä tekisin homman Monolla. Syynä tähän on se, että kyseessä on rinnakkaisia toteutuksia ja jotka lienee käytännössä enemmän tai vähemmän subset sen suhteen mitä pitää sisällään, ja deprecated kama vielä pois niin saisi jotenkin sellaisen rajallisen setin kutsuja minkä päälle rakentaa softaa joka toimii ja joka on itse mahdollista hallita hyvin.
Jos hommaan alkaan sotkemaan lisää jotain jonkun muun tekemään räpellystä niin alkaa tulla riippuvuuksia ties minne ja sen myötä sitten ongelmia. Näitä pitäisi pyrkiä vähentämään.
"Itse en Javalla tee nyt mitään, mutta jos tekisin niin tekisin puhtaasti tuoreen OpenJDK:n päälle suoraan ilman mitään lisä härdelliä ja karsisin kaiken deprecated kaman pois"
Asiaa! Todellisuus vaan on ristiriidassa tän kanssa - nykyään softat kehitetään kaikenlaisten sovelluskehysten (framework) päälle. Eikä siinä mitään, sovelluskehys on iloinen asia, koska siinä saa valmiina sellaiset jutut, joita on ikävä tehdä itse joka kerta uudelleen kuten transaktionhallinta, connection pooling, yms. Mutta kun olis vaan yksi (tai kaksi...tai joku järkevä määrä) sovelluskehyksiä ja ne pysyisi muuttumattomina (ja hengissä) edes muutaman vuoden, niin niiden opiskeluun kannattaisi investoida! Mut niinkuin ketjun aloittaja sanoi, Java-puolella ei tähän ole vielä päästy.
"Asiaa! Todellisuus vaan on ristiriidassa tän kanssa - nykyään softat kehitetään kaikenlaisten sovelluskehysten (framework) päälle."
Minulle se Java on ihan riittävä sovelluskehys. Verrattuna siihen, että väännän kaiken itse vaikka assemblerilla, nollasta lähtien.
Minulle ylimääräiset lisähärpättimet on lähinnä kirosana. Nämä sovelluskehykset tuntuu olevan vähän samanlainen vitsi kuin koodin uudelleen käyttäminen millä C :aa ja olio-ohjelmointia jotkut hehkutti. Ihan rehellisesti sanoen, kuinka paljon käytätte koodia uudestaan kun ne frameworkit menee kuitenkin uusiksi parin vuoden välein?
Siis vittu järki hoi! Turhaa kuluttaa aikaa johonkin paskaframeworkkeihin kun sillä tekee yhden tai kaksi softaa ja sitten se onkin riippakivi josta halutaan eroon kun on vanhentunut, ja pitkässä juoksussa, lisää ylläpito-ongelmia kun on ylimääräisiä riippuvuuksia.
Vähän riippuvuksia, korkea koheesio. Siihen pitää tähdätä.
Juu, tärkeä asia. Mihinkään ei niin hyvin päde sanonta "on vaarallista tietää vain vähän" kuin ohjelmointiin. Kuitenkin moni ohjelmistoja kehittävä tietää vain vähän. Kokonaisuudesta on hyvin epäselvä käsitys. Frameworkit monasti käytännössä vain pahentavat tilannetta koska ne "estävät" sovelluskehittäjää näkemästä mitä hän todellisuudessa on tekemässä. Eivät suorastaan estä, mutta jos hän yrittää paneutua bisneslogiikan toteutamiseen niin ei jää aikaa kurkkia mitä siellä konepellin alla tapahtuu. Valitettavasti tästä on toisinaan seurauksena vääriä päätöksiä. Väärien luulojen perusteella tehdään virheellisiä päätöksiä jotka jossakin vaiheessa kostautuvat.
Valitettavasti ohjelmisto-alalla eivät kaikki ole, ja eivät voitkaan olla, niitä yberohjelmoijia, jotka eivät tee virheitä. Ohjelmistokehistyten avulla ainakin estetään perusteellisimmat virheet kuten esim Javan preparedstament. Ohjelmistokehykset ovat hyvästä, sillä ne juuri huolehtivat siitä etä perustus on tehty oikein.
Eipä ole .NET:n kanssa pahemmin tollaisia ongelmia, ettei hommat toimisi kun frameworkki vaihtuu.
Ite muuten uudelleenkäyttelen yhä muutamia kivoja juttuja joita on tehty 1.1:n päälle ja sorsaa vaan uuteen projektiin ja hyvin pelittää. Paljonkos tosta on mennyt aikaa kun toi tuli? No aika monta vuotta.
Ite teen paljon mielummin MS:n .NET:llä kuin sillä Monolla. Noissa öppen söyrseissa, vaikka ovat ihan kivoja, ei voi koskaan tietää jos päättävät rikkoa yhteensopivuutta MS:n suuntaan. Eikä toisinkaan päin. Ja kun MS näyttää .NEt:ssä tietä myös Monin suuntaan, ei tarvii kauaa miettiä kumpaan kelkkaan menee.
Ohjelmistokriisi on ollut aina meidän IT-alalla työkentelevien ystävä. Ei sitä ole vielä ratkaistu. Esittämäsi havainto johtuu vaan siitä, että ratkaisua vielä etsitään. Ongelman ratkaisuksi alunperin keksittiin strukturoitu ohjelmointi, sitten olio-ohjelmointi, komponentit ja nyt viimeisin ihmetys SOA. Ohjelmistotuotannon menetelmiä on paranneltu huomattavasti esim. periteisen suunnitelmaohjautuvan tavan rinnalle on noussut ketterä ja notkea tapa tehdä asioita. Näillä nyt varmaan pelastettaisiin softaprojekti jossain 80-luvun puolivälissä, mutta ei tämän päivän projekteja (ei ainakaan kaikkia). Ohjelmistokehyksiä syntyy ratkaisemaan joitain osia ongelmasta, mutta ne eivät ratkaise kaikkia. Osa ongelman synnystä selittää se, että tietokoneiden tehot tuplaantuvat joka 18. kuukausi, kun taas ohjelmoijien tuottavuus ei kasva läheskään samaa tahtia. Ja koska koneissa on enemmän tehoa, asiakkaat haluavat enemmän. Josta seuraa ongelmien monimutkaistuminenja josta seuraa ratkaisujen monimutkaistuminen.
Kun taas ajatellaan sitä, kuinka lähellä Java ja C# ovat toisiaan, niin eroavaisuuksien oppiminen ei välttämättä ole edes mikään homma ja usein vastuullinen työnantaja antaa mahdollisuuden oppia työtä tehdessä tai ohessa. Tiedän tyyppejä, jotka ovat ei-MS-C -taustaisia mutta koodaavat tänään C#:lla ja ovat ihan tyytyväisiä siihen hommaan. Monesti työtä hakiessa ei ole niin tärkeää se, mitä luulee osaavansa vaan se, että osoittaa aitoa halua oppia uusia asioita. Olen ollut osana rekrytointitiimiä sekä auttanut uusia kavereita kotiutumaan, niin usein taitavankin kaverin kanssa on joutunut lähtemään nollasta. Minusta voisit kokeilla ihan huvikseen vaihtaa javailusta särppäilyyn ;-) Voisit vaikka saada uuden työpaikan. Dokumentaatio on ainakin vähän parempi kuin OS-paketeissa yleensä (ei kuitenkaan erinomainen).
Tällä hetkellä kuuminta-hottia on juurikin SOA (Restful) sovellusten hajauttamiseen ja AJAX sovellusten visualisointiin. Tosin ne ratkaisevat vain osan ongelmista eikä edes kaikilla IT-sektorin ongelma-alueilla. SOA:n puolella mm. sovellusten kokoonpanonhallinta on kohdannut jonkun asteisia ongelmia ja ainakin toistaiseksi dynaaminen sovellusten kokoominen on ollut hiukan jäissä. Aivan tämän päivä tilannetta en tiedä, mutta huhu kertoo, että dynaamista kasaamista ei ole vielä ratkaistu.
Uusien kehysten opiskelu varsinkin web-sovellusten puolella on työlästä kun siellä tuulet puhaltavat milloin mistäkin suunnasta ja suunta tuppaa vaihtumaan vähän turhan nopeasti. Hibernate taitaa olla jo ainakin 10 vuotta vanha juttu ja edelleen se on käytössä myös muuallakin kuin vain web-sovelluksissa. Nyt on webbissä selvästi taas meneillään siirtymä thin-client ajattelusta jos ei nyt aivat fat-client ajatteluun, niin ainakin thick-client ajatteluun. Ja näitä asioita helpottamaan tehdään sitten kehyksiä, joiden perimmäinen tarkoitus on nostaa tuottavuutta.
Mitä tulee kaipaamaasi hopealuotiin, niin sitä saat odottaa. IT:n ongelmakenttä on niin laaja ja heterogeeninen, että yhden ratkaisun löytyminen kaikkiin on vaikeaa. Jos poistetaan kaikki muut ongelma-alueet kuin web-sovellukset, niin siellä tulee sitten vastaan raha. MS haluaa tehdä rahaa omilla jutuillaan, Sun/IBM omilla jutuillaan ja kaikki muut haluaa tehdä rahaan jomman kumman tai molempien jutuilla rahaa. Ja koska rahan tekeminen vaatii rahaa, usein paljonkin, ei ole helppo luopua omista jutuistaan jonkun toisen hyväksi. C#:n synnystä voidaan kiittää Sunin "ahneutta" lisenssoida Java-teknologia.
Ainoa "oikea" lähestymistapa asiaan on abstraktiotason nostaminen ohjelmointikielen tasolta ongelma-alueen tasolle ja ratkaista ongelma siellä. Tosin mallipohjaisuudessa odottavat sitten ihan omat ihanuutensa, joten se siitä.
"Uusien kehysten opiskelu varsinkin web-sovellusten puolella on työlästä kun siellä tuulet puhaltavat milloin mistäkin suunnasta ja suunta tuppaa vaihtumaan vähän turhan nopeasti. Hibernate taitaa olla jo ainakin 10 vuotta vanha juttu ja edelleen se on käytössä myös muuallakin kuin vain web-sovelluksissa. Nyt on webbissä selvästi taas meneillään siirtymä thin-client ajattelusta jos ei nyt aivat fat-client ajatteluun, niin ainakin thick-client ajatteluun. Ja näitä asioita helpottamaan tehdään sitten kehyksiä, joiden perimmäinen tarkoitus on nostaa tuottavuutta."
Kommenttina tuohon thin/thick/fat-client juttuun, niin on se ihmeellistä kuinka samoja asioita keksitään säännöllisesti uudelleen:
- Ensin oli vain erillisiä (VMS/VAX/unix/64/...) tietokoneita, jotka eivät vielä olleet verkossa mitenkään: erittäin "fat" client -lähestymistapa.
- Sitten kuusnelosiin, PC:ihin ja unix-koneisiin yhdistettiin modeemit, jolloin niillä pääsi BBS:iin yms: fat client
- Samaan aikaan ellei jo aikaisemmin tuli X-päätteet ja X WIndow System: thin client-lähestymistapa, ja hieno nimi tälle on nykyään pilvimalli
- Sen jälkeen PC/apple/mikälie -koneisiin alkoi tulla internet-yhteyksiä joita sovellukset hyödynsivät: fat -client malli
- Viime vuosina osa toiminnallisuuksista on siirretty internettiin: thin/thick -client malli, pilvimalli (taas)
"Ainoa "oikea" lähestymistapa asiaan on abstraktiotason nostaminen ohjelmointikielen tasolta ongelma-alueen tasolle ja ratkaista ongelma siellä. Tosin mallipohjaisuudessa odottavat sitten ihan omat ihanuutensa, joten se siitä."
Tämä onnistuu esimerkiksi siinä tapauksessa, että kyseessä on joku tekninen telekommunikaatioon, signaalinkäsittelyyn, säätötekniikkaan tai muuhun perustuva systeemi. Silloin toiminnallisuuden voi suunnitella sekvessikaavioiden ja matematiikan avulla aika korkealla abstraktiotasolla.
Kun sitten tällaista järjestelmään lähdetään käytännössä toteuttamaan, huomaa helposti kuin avuttoman alkeellisia nykyajan ohjelmointikielet ovat. Toiminnallisuuden, joka matemaattisen algoritmin tasolla on aika yksinkertainen, lopulliseen toteuttamiseen tarvitaan aivan tolkuton määrä Java/C#/C -koodia. On järjetöntä, että vielä nykyään ohjelmointia pitää tehdä näinkin lähellä assembleria olevilla työkaluilla.