Läskipää: "Erot koodaukseen tuhlatussa ajassa yllättävän suuria."
Onko tosiaan niin että ohjelmoinnissakin voidaan puhua ajantuhlauksesta? Suunnitelmallisesti tarpeeseen tehty ohjelma palvelee vuosia, joten miksi kehitysvaihe pitäisi olla virtaviivaista. Eikö tärkeintä ole että ohjelma saadaan toimimaan halutulla tavalla.
Onko tosiaan niin että ohjelmoinnissakin voidaan puhua ajantuhlauksesta? Suunnitelmallisesti tarpeeseen tehty ohjelma palvelee vuosia, joten miksi kehitysvaihe pitäisi olla virtaviivaista. Eikö tärkeintä ole että ohjelma saadaan toimimaan halutulla tavalla.
Vastaukset 27
Vanhimmat
"Eikö tärkeintä ole että ohjelma saadaan toimimaan halutulla tavalla. "
Ei. Jos ohjelmaa ei voi jatkossa ylläpitää (dokumentoimantonta/kommentoimatonta spagettikoodia) niin ohjelma on melko arvoton.
kun suoraan alkaa koodaamaan ilman suunnittelua ja sitten korjaa korjauksia korjauksilla niin lopputulos on spagettikoodia. sitä ei enää kunnon koodiksi helpolla muuteta vaan on usein helpompaa aloittaa alusta.
Tarkoitin että jos pitää toteuttaa *sama* toiminallisuus niin:
A: Tehdään Javalla => meni 10h
B: Tehdään Pythonilla => meni 3h
Nyt tapaus A:ssa on tuhlattu aikaa 7h *verrattuna* tapaus B:hen.
Yleensä varsinaista hukka-aikaa syntyy virheiden etsimisestä. Tuskin tuo 7 tuntia on sitä, vaan Javan luokkahierarkian oppimista tai ohjelman suunnittelua, joka ei ole ehdottoman negatiivinen asia?
Viittaan näihin tutkimuksiin:
http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf
http://www.flownet.com/gat/papers/lisp-java.pdf
Aikaa tuskin meni tossa tutkimuksessa Javan luokkahierarkian oppimiseen, koska ongelma ei vaadi OO:ta ja olivatpa vielä melko kokeneita koodareita.
Ei asiakas halua maksaa siitä, että ensin laitat virheitä ohjelmaan ja sitten etsit ja arvailet missä niitä voisi olla. Eikä se halua maksaa siitä, että opettelet n:n kerran sitä Javan loistavaa luokkahierarkiaa.
Kai nyt voisi olettaa, että läskipää olisi vertaillut esimerkissään samantasoisia ohjelmoijia. Asiakasta kiinnostaa vain ne tulokset, joiden on oltava tarpeiden mukaisia. Mitä paremmin ja nopeammin joku ne tekee, sitä parempi asiakkaalle.
Selittelyä nuo sun jutut.
nippeliohjelmien tekoon mihin tutkimuksessa viitataan vaan laajoihin serveriohjelmiin.
Esimerkkinä voisi olla joku terveydenhuoltosofta. (Niistä on viime aikoina ollut puhetta) Uskaltaako potilaalle sanoa että ohjelma tehtiin ihan muutamalla skriptillä.
Rupes hymyilyttämään kun mieleeni tulvi kuva lääkärin vastaanotosta jossa vanha ja valkohiuksinen lääkäri selittää raajarikolle potilaalle "Tiesitkös muuten että tämä meidän potilastietokannan käyttöliittymä on tehty muutamalla skriptillä"
Jos muutaman skriptin toteutus tekisi saman kuin 2 000 000 rivin J2EE-viritys, ostaisin ehdottomasti mieluummin sen skriptin. Hinnalla ei väliä --- tosin tietenkin muutaman rivin skriptit ovat yleensä myös paljon halvempia kuin 2 000 000 rivin J2EE-virirykset.
Jos joudutaan käyttämään monimutkaisia teknologioita (kuten J2EE) ja kirjoittamaan paljon koodia, on erittäin todennäköistä, että myös virheitä tulee paljon ja ylläpito on tuskallista.
"Jos joudutaan käyttämään monimutkaisia teknologioita (kuten J2EE) ja kirjoittamaan paljon koodia, on erittäin todennäköistä, että myös virheitä tulee paljon ja ylläpito on tuskallista."
Riippuu paljon siitä koodista. Entä jos se monimutkaisuus on suurelta osin virheiden tunnistamista: Olio huomaa että kaikki ei ole kohdallaan ja heittää virheen. Virheentunnistamista on helppo lisätä Pythoniin ja Rubyyn mutta miksi ei siirtyisi kokonaan "oikeaan" kieleen.
"Virheentunnistamista on helppo lisätä Pythoniin ja Rubyyn mutta miksi ei siirtyisi kokonaan "oikeaan" kieleen."
Voisitko kertoa miten Java on "oikeampi" kieli kuin Python?
"Voisitko kertoa miten Java on "oikeampi" kieli kuin Python?"
Python ja Ruby sopii ehkä testaamiseen ja kokeiluihin, ei yli 1000 rivin ohjelmiin joissa pitää olla isoja kokonaisuuksia... Ehkä pitäisi tehdä 500 riviä Pythonilla ja loput kurinalaisemmalla kielillä...?
No miten esim. Ruby on Rails ja Zope on sitten onnistuttu tekemään. Tietenkään se ei onnistu, jos on tämmöinen tapaus: http://humdi.net/evo/index.php
"No miten esim. Ruby on Rails ja Zope on sitten onnistuttu tekemään."
En tiedä, enkä tiedä miksi kummassa ne on tehty noilla funkkis-skriptikielellä. Kun kasataan paljon pinoja, listoja ym. flip-flap-foo-juttuja, ei siitä vaan saa selvää.
Funkkis on muuten ihan mukava muoti-ilmiö, mutta sille voisi etsiä jotain muuta tarvetta kun "oikeat" ohjelmat.
"En tiedä, enkä tiedä ..."
Niin et tiedä, mutta ymmärrätkö että ne *todistavat* väitteesi vääräksi. (Väitehän oli: "Python ja Ruby sopii ehkä testaamiseen ja kokeiluihin, ei yli 1000 rivin ohjelmiin joissa pitää olla isoja kokonaisuuksia...")
"Kun kasataan paljon pinoja, listoja ym. flip-flap-foo-juttuja, ei siitä vaan saa selvää."
Se on sinun ongelmasi. Toiset osaa, toiset ei.
"Funkkis on muuten..."
Python ja Ruby luokitellaan multiparadigma-kieliksi.
Heh... Kun olin vahvasti samaa mieltä 3 vuotta sitten, kunnes opettelin "oikeasti" ohjelmoimaan "oliosuunnittelulla", UML jne. Mitä ei voisi tehdä "monoparadigma-kielillä"? Joo, on Java-koodaus vähän hitaampaa mutta sitähän keskustelun aloituksessa julistin. Syntyy ainakin vähemmän hukkaohjelmia... Suosittelen.
Käsityksesi Pythonista ja Rubystä lienee linjassa yleisen käsityksen kanssa, mutta se on mielestäni pahasti metsässä. Molemmat kielet soveltuvat hyvin selvästi skriptejä suurempienkin sovellusten kehittämiseen, mutta eivät vain ihan samalla tavalla käytettyinä kuin Java ja muut ohjelmoijaa paapovat kielet.
Olen kirjoittanut Pythonilla useita pelkkiä "kokeiluita" suurempia sovelluksia. Suurimmassa projektissa (joka sisältää myös Javaa, PHP:ta, shell-skriptejä ym.) on yhtenäistä Python-koodia pitkälti yli 10 000 riviä. Vastaavan toiminnallisuuden aikaan saaminen Javalla vaatisi luultavasti huomattavasti enemmän koodia.
Kokemuksen kautta olen tosin tullut siihen tulokseen, että vanhanaikainen
koodaa -> käännä -> kokeile(?) -> kommittoi versionhallintaan, ja toista sama uudelleen
-ohjelmointiprosessi ei toimi Pythonin ja Rubyn kaltaisten dynaamisten ohjelmointikielten kanssa --- kääntäjä kun ei monista lipsahduksista valita. Luulen, että yleinen käsitys näiden kielien soveltumattomuudesta "oikeaan" ohjelmointiin johtuu juuri tämän havainnon aiheuttamasta järkytyksestä.
Useimmissa yli 1000 rivin projekteissa olenkin alkanut kirjoittaa moduuleille (tai luokille) yksikkötestit suunnilleen samaan aikaan kuin toteutan myös varsinaisen logiikan. Suunnilleen sama aika tarkoittaa joskus vähän ennen varsinaista toteutusta, joskus ihan samaan aikaan ja joskus vähän sen jälkeen. Yksikkötestikoodin ja leipäkoodin suhde näyttäisi luonnostaan asettuvan yleensä 1:2 ja 1:1 väliin, hieman moduulista riippuen. Joissakin pahoissa paikoissa (esim. jäsentäjän tai protokollan toteutus) testikoodia tarvitaan selvästi tätä enemmän.
Olen varma, että vielä yksikkötestikoodin kirjoittaminen mukaan luettunakin kehitys on näillä kielillä huomattavasti nopeampaa kuin Javalla. Kannattaa myös muistaa, että yksikkötestikoodi ei ole pelkästään Java-kääntäjää parempi virheiden löytäjä. Se on myös verraton apu ylläpitovaiheessa. Se paljastaa usein, jos tehty muutos rikkoo jonkin aiemmin toimineen asian.
Jos kovasti kaipaa staattista tarkastusta, on siihenkin olemassa lint-tyyppisiä työkaluja myös dynaamisille ohjelmointikielille. Esimerkiksi PyCheckeriä tulee käytettyä silloin tällöin.
http://pychecker.sourceforge.net/
Parasta kuitenkin näissä dynaamisissa ohjelmointikielissä on se, että monet äkkiä mieleen tulleet jutut voi toteuttaa pienellä vaivalla. Pari viikkoa sitten tuli ajatus, että S60-puhelinta olisi kiva käyttää kaukosäätimenä siten, että sen nappeja painelemalla voisi lähettää Bluetoothin yli X-eventtejä Linux-koneen X-serverille. Koska pikaisen haun perusteella haluamani kaltaista softaa ei löytynyt, päätin tehdä itse. Alle 10 tuntia ja 303 Python-riviä myöhemmin puhelimeni toimi kaukosäätimenä, jolle voi antaa useita vaihtoehtoisia keymappeja, missä jokaiselle napille voi määritellä monen X-eventin sarjan, minkä napin painallus lähettää PC:lle. Koskaan aiemmin en ollut Bluetoothia ohjelmoinut puhelimella enkä PC:llä, enkä myöskään X-eventtejä lähetellyt ikkunoihin, joten asiaan perehtymiseen ja tekniikan kokeiluun meni tuosta ajasta ehkä kolmisen tuntia. Eikä muuten tarvinnut asentaa ainuttakaan SDK:ta.
Javalla en olisi ikinä viitsinyt edes aloittaa koko projektia, koska harrastusten on tarkoitus olla hauskoja, eikö vain?
"Vastaavan toiminnallisuuden aikaan saaminen Javalla vaatisi luultavasti huomattavasti enemmän koodia."
Java ei ole vain "koodia", jos vertaan noihin funktionaalisempin kieliin. Java on paljolti dokumentaatiota. Sekin, kun Javassa yhden asian voi tehdä vain yhdellä tapaa, on hyvin dokumentoivaa ja standardisoivaa. Ja koska tuotantokielet ovat voimakkaasti kehittyneet tähän suuntaan, Skriptikielille on jäänyt iso alue paikattavaksi.
"Parasta kuitenkin näissä dynaamisissa ohjelmointikielissä on se, että monet äkkiä mieleen tulleet jutut voi toteuttaa pienellä vaivalla."
Tarvitsetko siihen Pythonia. Voisit jättää ideasi vähän hautumaan ja tehdä pitempiaikaisen toteutuksen tuotantokielellä. Itse pyrin siihen että Pythonia ei tarvitsisi käyttää lainkaan.
"Javalla en olisi ikinä viitsinyt edes aloittaa koko projektia, koska harrastusten on tarkoitus olla hauskoja, eikö vain?"
Tämä on taas vähän eri asia. Vapaa-aikana on hauska viritellä Pythonilla, mutta internet-selaimen toteutus QuickBasicilla on kanssa hyvin mielenkiintoista.
"... kunnes opettelin "oikeasti" ohjelmoimaan "oliosuunnittelulla", UML jne"
Useilla kielillä (mm. Ruby, Python) onnistuu OO, UML jne.
"Java ei ole vain "koodia", jos vertaan noihin funktionaalisempin kieliin. Java on paljolti dokumentaatiota."
Voisiko tarkentaa, en oikein ymmärrä.
Javadocia tarkoitin.
Niiden kaavioiden ja kiekuroiden kanssa puuhastelu se vasta ajan ja resurssien tuhlausta onkin!
Ei nää "doku"-työkalut liity kieleen itseensä mitenkään ja löytyyhän noita muitakin:
http://en.wikipedia.org/wiki/List_of_documentation_generators
"Ei nää "doku"-työkalut liity kieleen itseensä mitenkään"
Liittyy. Joku sanoi funkkisparadigman perustuvan "nimettömiin funktioihin". Eikös Pythonin ja Rubyn nopeus perustukin juuri siihen "nimettömyyteen": Koodi on erittäin tiivistä, ei liikaa selittelyä. Javassa puolestaan on kielenä köpelöitä ja "ahdasmielisiä" rakenteita (Listenerit on hyvä esimerkki), mutta se on kuitenkin isoja sovelluksia tehdessä edullisempaa...
Isoja ohjelmia ei tehdä koodilla
foo()
bar()
Vaikka olishan se hienoa.
"...Skriptikielille on jäänyt iso alue paikattavaksi."
Itse kielessä Javalla on paljon paikattavaa:
http://www.ferg.org/projects/python_java_side-by-side.html
Lisäksi, miksi helvetissä Javassa ei ole funktio osoitinta(/viittausta).
Koodauksen osuus ohjelmistoprojektin työstä jää helposti tuonne 15% kieppeille. Eli jos saat sitä vähennettyä 30%, vaikutus kokonaisuuteen on vain 5%. Tärkeämpää on, että koodaus tehdään kielellä ja ympäristössä mille löytyy osaavia ylläpitäjiä.