Ohjelmointikielet tulevaisuudessa??

[MNi]

Ja aina samalla lailla kun olen kertonut sen testaavan. Ts. sillä ei ole mitään keinoa keksiä niitä testattavia seikkoja mitä minä en ole keksinyt. Siis tämä vaan niinkuin konseptina kuulostaa mun korvaan tosi oudolta (joka muuten johtuu aivan varmasti ainoastaan siitä etten ole ollut mukana tekemässä mitään isompaa). Ehkä se sitten valkenee minullekkin joskus

Mutta ideahan on tehdä testit ensin sille mitä teet, joten kaikki tulee testattua määritelmän mukaan Aina kun alkaa tekemään jotain, tehdään testi ensin ja toteutusvaiheessa ei saa tehdä mitään ylimääräistä mitä testissä ei ole jo otettu huomioon. Tuo vaatii kuria, mutta antaa hyviä tuloksia.

Edellä ollut on toki teoriaa, käytännössä tosiaan jää niitä aukkoja.

Se on tosin hyvä muistaa ettet manuaalisesti testaa myöskään sitä mitä et osaa ajatella, joten ei ainakaan huonompaan voi mennä? Lisäksi järjevässä testisysteemissä testejä on helppo parametrisoida joten erilaisten syötteiden antaminen on helppoa ja testeistä saa sitä kautta hyvin kattavia pienellä vaivalla. Ainakin määrän isoksi .

[littlebig]

Iso kiitos kaikille vastanneille ja auttaneille.
Saimme koulutehtävän tehtyä, hienot 48 sivua sisällysluetteloineen ja lähteineen
Saimme myös aikaan pieniä muutoksia maailmassa, nyt kun googlaa "ohjelmointikielet tulevaisuudessa", tulee meidän aloittamien keskusteluiden linkit ensimmäisiksi

Kiitos ja kumarrus

[pekkaj]

Mikä vika Perlissä? Minusta se on vallan hyvä kieli. Ainakin webbikötköttimien koodaamiseen.

Itse näkisin Perlin suurimman ongelman sen filosofiassa. Tai ei suoranaisesti filosofiassa, vaan siinä miten sitä käytetään. Filosofia/mottohan on "There's more than one way to do it". Kieli on siis todella joustava ja mahdollistaa mitä omituisempaa koodia. Omasta mielestä gurut ovat henkilöitä, jotka osaavat tehdä äärettömän yksinkertaista koodia ja Perlillä on suuri kiusaus tehdä yhden rivin "killereitä".

RoR on kyllä niiiiin siisti juttu että kannattaa kyllä perehtyä
Ei voi kun rakastaa kun tekee "rails keke", schema.rb:hen tavarat, "rake db:schema:load", "generate scaffold diudiu", script\server, localhost:3000 -> voilá, ror käy kyselemässä kannalta taulun kenttien nimet ja näyttää näkymässä ne. Kaikki on objekteja. Koko kirjo samassa paketissa veppiserveriä myöden.
Vaikka scaffolding onkin pelkkä tukirakenne itse ohjelman rakentamisessa, kyllä mulle käsite "framework" sai ihan uuden merkityksen.

Test-driven development tosin ei käy mulle järkeen, tuntuu että siinä rikotaan pahemman kerran yhtä kulmakiveä koko hommalle; DRY -- "Don't repeat yourself".. siinähän toistetaan itseä niin paljo ko lähtee? Voisko joku valaista?

Olen itsekin RoR:n kannattaja, mutta on siinä huonojakin puolia. Ihan puhtaasti syy, miksi mieluiten teen ihan Javalla on sen staattisuus. Java on staattisesti tyypitetty kieli ja tämä mahdollistaa sen, että kehitysympäristöt todella tietävät mistä tyypistä milloinkin on muuttujassa kyse. Tämä mahdollistaa taas erinomaiset työkalut. Refaktorointi on siis Javassa mahdollista. Jos refaktorointi on terminä tuntematon, niin kipin kapin tutustumaan siihen muutaman kirjan merkeissä. Esim. Eclipsellä on mahdollista tehdä loistavia koodausta nopeuttavia asioita. Kannattaa siis opiskella Eclipse + Java -yhdistelmä huolella.

RoR on siis toteutettu Ruby-kielellä. Se on tietääkseni dynaamisesti tyypitetty kieli. Siis vahvasti tyypitetty, mutta dynaaminen. Tästä aiheutuu se, että kehitysympäristö ei voi muuta kuin tehdä sivistyneitä arvauksia tyypeistä. Tämä taas karsii suuren osan kehitysympäristön antamasta tuesta. Kehitysympäristön tukea ei todellakaan kannata vähätellä, koska sen avulla ohjelmointi nopeutuu älyttömästi.

TTD-kehitystyyli (yksi XP:n perusfilosofioista) on mielestäni erinomainen. En ole sitä käyttänyt, mutta olen asiaan perehtynyt. Usein koodia kirjoittaessa ei tule miettineeksi (ainakaan aloittelijat) sitä, että "kuinka helppoa minun koodini on testata" ja, että "tekeekö tämä moduuli tai luokka asiat, jotka sen todella kuuluu tehdä". Lisäksi vaarana on se, että ohjelmoidessa varaudutaan turhiin laajennuspisteisiin.

No, miten TDD-sitten puuttuu peliin? Yksinkertaisesti se pakottaa ohjelmoijan miettimään etukäteen, että "mitä luokan todella pitää tehdä". On siis pakko tietää mitä luokan tehtävä on, koska jos osaa kirjoittaa testin, on tiedettävä mitä luokka tekee. Ja koska luokka tehdään ensin, on luokan testattavuus lähtökohta. On helppo tehdä huonosti testattavia luokkia. Puhun siis yksikkötestauksesta tietysti. No, ilman kattavaa yksikkötestausta refaktorointi on arveluttavaa puuhaa. Kun ohjelmaa on muutettu, niin voidaanko todella olla varmoja, ettei rikottu mitään koodista. Tietysti käännösvirheet saadaan korjattua, mutta miten on semanttisten virheiden. Tottakai kattavat yksikkötestit voidaan tehdä ilman TDD:tä, mutta tietysti se tehdään myös TDD:ssä.

Kannattaa siis tutustua termeihin XP, TDD (yksi perusfilosofia XP:ssä, mutta näyttää siltä, että tämä on vahvasti eriytymässä irralliseksi XP:stä, vaikkakin jatkaa XP:n peruspilarina), Java ja Ruby. En usko, että Java on minnekään menossa.

Vielä kannan korteni kekoon .net -asiassa. .net on varsin pätevä teknologia ja varsin lähellä Java + Javan virtuaalikonetta. .netissä on hyvät kehitystyökalut ja laaja luokkakirjasto. .net 3 tuo varsin mielenkiintoisia teknologioita ja mielestäni kannattaa tutustua WPF, WWF ja WCF ankronyymeihin.

Lisäksi mainitsen yhdestä .netin kanssa käytettävästä kielestä eli C#:sta. Itse pidin sillä ohjelmoinnista. Siinä oli erinomaisia ominaisuuksia, mitä Javassa ei ole. Sehän on hyvin Javamaista.. tai oikeastaan Javan ja C++:n risteytystä. Erittäin mielenkiintoisina ominaisuuksina pidän delegaatteja, attribuutteja (vastaa Javan annotaatioita), Genericsejä ja tietysti mahdollisuutta ylimääritellä operaattoreita. Mielestäni operaattoreiden ylimäärittelyllä voi saada hyvää ja luettavaa ohjelmakoodia, kunhan käyttää operaattoreiden ylimäärittelyä viisaasti. Ja vielä propertyt on mainittava.. niillä saa oikein luettavaa ohjelmakoodia.

Tässä kannoin korteni kekoon.. mitä mieltä olette ajatuksistani?

--
Pekka Mattila

[MNi]

Olen itsekin RoR:n kannattaja, mutta on siinä huonojakin puolia. Ihan puhtaasti syy, miksi mieluiten teen ihan Javalla on sen staattisuus. Java on staattisesti tyypitetty kieli ja tämä mahdollistaa sen, että kehitysympäristöt todella tietävät mistä tyypistä milloinkin on muuttujassa kyse.

Lisäksi tuo tyypitys tuo vähän lisää turvallisuutta. Esim. webbiohjelmissa yleinen virhe on että luetaan joku parametri (mukamas) kokonaislukuna eikä sitä tarkisteta mitenkään ja laitetaan suoraan johonkin tietokanta hakuun. Mutta koska muuttujaan voi laittaakin ihan mitä vaan, niin ilkeä käyttäjä voi laittaa sinne jotain ihan muuta kuin kokonaisluvun ja lukea vaikkapa tietokannasta salasanat. Tuo ei onnistu jos muuttujat on staattisesti tyypitettyjä, joten siitä tulee tälläinenkin hyöty. Toisaalla tuo on tietenkin haitta, jos sen näkee kankeutena.

ohjelmoinnista. Siinä oli erinomaisia ominaisuuksia, mitä Javassa ei ole. Sehän on hyvin Javamaista.. tai oikeastaan Javan ja C++:n risteytystä. Erittäin mielenkiintoisina ominaisuuksina pidän delegaatteja, attribuutteja (vastaa Javan annotaatioita), Genericsejä ja tietysti mahdollisuutta ylimääritellä operaattoreita. Mielestäni

Java 1.5:ssa on ainakin Genericsit:

http://java.sun.com/j2se/1.5.0/docs/gui ... erics.html

Hyvää tekstiä kirjoitit.

[v_vega77]

Mikä vika Perlissä? Minusta se on vallan hyvä kieli. Ainakin webbikötköttimien koodaamiseen.

Itse näkisin Perlin suurimman ongelman sen filosofiassa. Tai ei suoranaisesti filosofiassa, vaan siinä miten sitä käytetään. Filosofia/mottohan on "There's more than one way to do it". Kieli on siis todella joustava ja mahdollistaa mitä omituisempaa koodia. Omasta mielestä gurut ovat henkilöitä, jotka osaavat tehdä äärettömän yksinkertaista koodia ja Perlillä on suuri kiusaus tehdä yhden rivin "killereitä".

RoR on kyllä niiiiin siisti juttu että kannattaa kyllä perehtyä
Ei voi kun rakastaa kun tekee "rails keke", schema.rb:hen tavarat, "rake db:schema:load", "generate scaffold diudiu", script\server, localhost:3000 -> voilá, ror käy kyselemässä kannalta taulun kenttien nimet ja näyttää näkymässä ne. Kaikki on objekteja. Koko kirjo samassa paketissa veppiserveriä myöden.
Vaikka scaffolding onkin pelkkä tukirakenne itse ohjelman rakentamisessa, kyllä mulle käsite "framework" sai ihan uuden merkityksen.

Test-driven development tosin ei käy mulle järkeen, tuntuu että siinä rikotaan pahemman kerran yhtä kulmakiveä koko hommalle; DRY -- "Don't repeat yourself".. siinähän toistetaan itseä niin paljo ko lähtee? Voisko joku valaista?

-->snip<--

Tässä kannoin korteni kekoon.. mitä mieltä olette ajatuksistani?

--
Pekka Mattila

Täyttä asiaa, paitsi, että yllä oleva ei ole minun kirjoittamaani.

[v_vega77]

Mikä vika Perlissä? Minusta se on vallan hyvä kieli. Ainakin webbikötköttimien koodaamiseen.

Itse näkisin Perlin suurimman ongelman sen filosofiassa. Tai ei suoranaisesti filosofiassa, vaan siinä miten sitä käytetään. Filosofia/mottohan on "There's more than one way to do it". Kieli on siis todella joustava ja mahdollistaa mitä omituisempaa koodia. Omasta mielestä gurut ovat henkilöitä, jotka osaavat tehdä äärettömän yksinkertaista koodia ja Perlillä on suuri kiusaus tehdä yhden rivin "killereitä".

RoR on kyllä niiiiin siisti juttu että kannattaa kyllä perehtyä
Ei voi kun rakastaa kun tekee "rails keke", schema.rb:hen tavarat, "rake db:schema:load", "generate scaffold diudiu", script\server, localhost:3000 -> voilá, ror käy kyselemässä kannalta taulun kenttien nimet ja näyttää näkymässä ne. Kaikki on objekteja. Koko kirjo samassa paketissa veppiserveriä myöden.
Vaikka scaffolding onkin pelkkä tukirakenne itse ohjelman rakentamisessa, kyllä mulle käsite "framework" sai ihan uuden merkityksen.

Test-driven development tosin ei käy mulle järkeen, tuntuu että siinä rikotaan pahemman kerran yhtä kulmakiveä koko hommalle; DRY -- "Don't repeat yourself".. siinähän toistetaan itseä niin paljo ko lähtee? Voisko joku valaista?

Olen itsekin RoR:n kannattaja, mutta on siinä huonojakin puolia. Ihan puhtaasti syy, miksi mieluiten teen ihan Javalla on sen staattisuus. Java on staattisesti tyypitetty kieli ja tämä mahdollistaa sen, että kehitysympäristöt todella tietävät mistä tyypistä milloinkin on muuttujassa kyse. Tämä mahdollistaa taas erinomaiset työkalut. Refaktorointi on siis Javassa mahdollista. Jos refaktorointi on terminä tuntematon, niin kipin kapin tutustumaan siihen muutaman kirjan merkeissä. Esim. Eclipsellä on mahdollista tehdä loistavia koodausta nopeuttavia asioita. Kannattaa siis opiskella Eclipse + Java -yhdistelmä huolella.

-->snip<---

Tässä kannoin korteni kekoon.. mitä mieltä olette ajatuksistani?

--
Pekka Mattila

Lisäsin vain, että dynaaminen tyypitys ei ole este refaktoroinnille. Se vain vaikeuttaa automatiikan toteuttamisen refaktorointivälineisiin. Automatiikan puute -> manuaalista työtä -> virheitä ja jos testit kuralla -> vakavia ongelmia. Jos on hyvät testit niin manuaalinen refaktorointi ei ole niin vaarallista.

Java-maailmassakaan refaktrointi ei ole aina niin mutkatonta jos projektissa on mukana esim. Velocity tai jotain XML-pohjaisia härpäkkeitä (ei sinänsä Javan ongelmia).

Itselläni on vielä kokeilematta nuo MS:n kalut. Poijjaat puhhuu kylillä että niillä leipominen on parin kurssin jälkeen kuin linnunmaitua. Ehkäpä se ei olisi niin pahasta kuin sukurutsa tai kansantanssit.

[pekkaj]

Lisäsin vain, että dynaaminen tyypitys ei ole este refaktoroinnille. Se vain vaikeuttaa automatiikan toteuttamisen refaktorointivälineisiin. Automatiikan puute -> manuaalista työtä -> virheitä ja jos testit kuralla -> vakavia ongelmia. Jos on hyvät testit niin manuaalinen refaktorointi ei ole niin vaarallista.

Java-maailmassakaan refaktrointi ei ole aina niin mutkatonta jos projektissa on mukana esim. Velocity tai jotain XML-pohjaisia härpäkkeitä (ei sinänsä Javan ongelmia).

Itselläni on vielä kokeilematta nuo MS:n kalut. Poijjaat puhhuu kylillä että niillä leipominen on parin kurssin jälkeen kuin linnunmaitua. Ehkäpä se ei olisi niin pahasta kuin sukurutsa tai kansantanssit.

Totta. Dynaaminen tyypitys ei todellakaan ole este refaktoroinnille. En ole tullutkaan ajatelleeksi sitä, että dynaamisesti tyypitetyissä kielissä refaktorointi onnistuu ihan ok, jos yksikkötestit ovat kunnossa. Tuo on hyvä pointti.

Tuo on kannssa erinomainen huomio, että Javan kanssa refaktorointikaan ei ole aina helppoa. Esimerkiksi olen käyttänyt Spring Frameworkkia ja siinä voidaan käyttää XML-tiedostoa esim. rajapintojen toteuttavien luokkien määrittelyyn (jotka annetaan esim. settereillä luokille). Ainakaan Eclipsen refaktorointi ei osaa kaivella noita XML-tiedostoja. En sitten tiedä, että olisiko tuohon Eclipsen java-pluginiin jotain laajennoksia, joka osaisi tehdä muutoksia ihan esim. XML-tiedostoihin.

En ole perehtynyt Javan Genericseihin, kuin perusteiden osalta eli ihan säiliöluokkien käytössä ja C++:n templatet ovat tuttuja. Jostain syystä minulla on käsitys, että C# Genericsit ovat erittäin laaja asia ja kenties jopa laajempi kuin Javassa? Tämä ei ole faktaa. Jotain perustavaa laatua olevia eroja C# Genericseissä on C++:n templateihin verrattuna. Ja C# genericsit ovat laaja asia, koska ko. aiheesta on kirjoitettu kirjoja.

Onko kellään lisätä tähän Generics-aiheeseen jotain?

--
Pekka Mattila

[spiidi78]

Onkos porukalla kokemusta sellaisesta kuin CakePHP? Rails tyyppinen MVC-framework PHP:lle

[Aaaron]

PHP:lle on myös Smarty, jolla saa sen HTML-sotkun sieltä välistä pois ja parannettua MVC-malliyhteensopivuutta.

[spiidi78]

Kaivetaas ikivanha keskustelu haudasta
Mikäs on tämän päivän tilanne web-kehityksessä? Onkos jengi tutustunut Play!:hun, mitä mieltä? MVC, RoR:n helppous ja Java pitäisi olla yhdistettynä. Olen itse nykyään c++ "hörhö", mutta ajattelin opetella "kakkosvaihtoehdoksi" jonkun tuoreen web-frameworkin. Javaan olisi helppo sisäistyä, koska se muistuttaa paljon C++:aa (+ siitä on jonkin verran kokemustakin).

[morbusg]

Kaivetaas ikivanha keskustelu haudasta
Mikäs on tämän päivän tilanne web-kehityksessä? Onkos jengi tutustunut Play!:hun, mitä mieltä? MVC, RoR:n helppous ja Java pitäisi olla yhdistettynä. Olen itse nykyään c++ "hörhö", mutta ajattelin opetella "kakkosvaihtoehdoksi" jonkun tuoreen web-frameworkin. Javaan olisi helppo sisäistyä, koska se muistuttaa paljon C++:aa (+ siitä on jonkin verran kokemustakin).

En tuosta Play!:stä tiedä, mutta RoR on itselle jo menneen talven lumia. Ohjelmoinnin perusteisiin tutustumisen jälkeen koko ruby on alkanut tuntua purukumilla kootulta lelulta. Tosin Sinatra+Datamapper on kyllä nopea ja helppo protoiluun, ainakin omaan käteen.

[jjari]

Kaivetaas ikivanha keskustelu haudasta
Mikäs on tämän päivän tilanne web-kehityksessä?

Jos javalla kehitys kiinnostaa niin suosittelen tutustumaan Vaadin-frameworkiin. Selain-liittymät koodataan swing tyyliin ja pyöritetään palvelinpäässä. Käyttöliittymäpuoli on qwt-widgettejä. Mahdollistaa mm. käyttöliittymäkoodin debuggauksen IDE:ssä todella näppärästi. Ja paljon muuta.

Edit: tehty Suomen Turussa.

[Sleepperi]

Kaivetaas ikivanha keskustelu haudasta
Mikäs on tämän päivän tilanne web-kehityksessä? Onkos jengi tutustunut Play!:hun, mitä mieltä? MVC, RoR:n helppous ja Java pitäisi olla yhdistettynä. Olen itse nykyään c++ "hörhö", mutta ajattelin opetella "kakkosvaihtoehdoksi" jonkun tuoreen web-frameworkin. Javaan olisi helppo sisäistyä, koska se muistuttaa paljon C++:aa (+ siitä on jonkin verran kokemustakin).

Olen itse C++ -immeinen, ja webin suhteen ihan noob, mutta tuo framework kuulostaa minun korvaani hyvältä. Java-virtuaalikoneen päällä pyöriminen tekee tuosta systeemistä varmaan yhteensopivan moneen paikkaan. Ehkä myös nopean vrt. Rubyt, Pythonit sun muut? Ja Java-yhteensopivuus antaa tietysti käyttöön loppumattoman määrän valmiita kirjastoja, työkaluja jne.

Javasta itsestään en pidä, selkärankatasolla. Se tuntuu vähän kuin polkupyörältä apupyörillä, kankealta, ja melkeinpä askeleelta taaksepäin verrattuna hyvinkoodattuun C++:aan. Jos itse lähtisin tuota frameworkia käyttämään, niin tekisin sen huomattavasti nätimmällä Scala-kielellä jota Play näyttää myös tukevan natiivisti ja mainostavan etusivullaan.

Ruby on Railsista en tykännyt ihanlyhyen kokeilun perusteella (koulukurssi). Olin tosi innostunut oppimaan sitä ja odotin sen olevan loistojuttu, mutta sellainen tuntu jäi että systeemi teki kaiken omasta puolesta, asiat eivät jotenkin tuntuneet olevan tarpeeksi omassa hallinnassa ja "näkyvissä". Valmiilla resepteillä pystyi tekemään paljon nopeasti, mutta oli vaikea saada tolkkua mitä tapahtuu ja miksi, tai soveltaa mitään. Olin tosin siinä ekaa kertaa sekä Rubyn että webin kanssa tekemisissä. Ehkä olisin ottanut RoR:n paremmin vastaan jos olisin ensin tehnyt jonkun pienen puhtaan Ruby-softan.

[spiidi78]

Olen itse C++ -immeinen, ja webin suhteen ihan noob, mutta tuo framework kuulostaa minun korvaani hyvältä. Java-virtuaalikoneen päällä pyöriminen tekee tuosta systeemistä varmaan yhteensopivan moneen paikkaan. Ehkä myös nopean vrt. Rubyt, Pythonit sun muut?

Joo mitä kokeilin tuota, niin välitön innostuminen tuli yksinkertaisuudesta:
$play new TestProject
$play run TestProject
-> uusi projekti nimeltä TestProject ja serveri päälle noilla komennoilla.
Sen lisäksi koodia pystyy editorilla editoimaan niin, että lopputulos näkyy ruudulla pelkästään refreshaamalla sivu. Käännösvirheet näkyvät selaimessa myös. Ja kevyt kuin mikä.

Javasta itsestään en pidä, selkärankatasolla. Se tuntuu vähän kuin polkupyörältä apupyörillä, kankealta, ja melkeinpä askeleelta taaksepäin verrattuna hyvinkoodattuun C++:aan. Jos itse lähtisin tuota frameworkia käyttämään, niin tekisin sen huomattavasti nätimmällä Scala-kielellä jota Play näyttää myös tukevan natiivisti ja mainostavan etusivullaan.

C++:ssa muistinvaraukseen, pointtereihin ja referensseihin tottuneena Javan koodaaminen on vähän kuin kiertäisi ruosteista puukkoa rinnassa Pidän kuitenkin itse Javan ulkoasusta. Minulle erittäin helppolukuista.

Jos javalla kehitys kiinnostaa niin suosittelen tutustumaan Vaadin-frameworkiin. Selain-liittymät koodataan swing tyyliin ja pyöritetään palvelinpäässä. Käyttöliittymäpuoli on qwt-widgettejä. Mahdollistaa mm. käyttöliittymäkoodin debuggauksen IDE:ssä todella näppärästi. Ja paljon muuta.

Edit: tehty Suomen Turussa.

Täytyy kokeilla. Tuo näyttää olevan Java EE:n päälle kyhätty, kun Play taas pelkän Javan päälle. Java EE tuppaa olemaan aika raskas, täytyy silti kokeilla, kiitos Turusta plussaa

[jjari]

Täytyy kokeilla. Tuo näyttää olevan Java EE:n päälle kyhätty, kun Play taas pelkän Javan päälle. Java EE tuppaa olemaan aika raskas, täytyy silti kokeilla, kiitos Turusta plussaa

Voiko javalla tehdä web-kehitystä käyttämättä EE-stäkkiä edes jollain tasolla? Vaadin vaatii vain servletit toimiakseen, Lopun EE:stä voi jättää hyllylle.

[Sleepperi]

C++:ssa muistinvaraukseen, pointtereihin ja referensseihin tottuneena Javan koodaaminen on vähän kuin kiertäisi ruosteista puukkoa rinnassa Pidän kuitenkin itse Javan ulkoasusta. Minulle erittäin helppolukuista.

Minusta C++:n muistinhallinnassa on kovasti parantamisen varaa - siinähän pitää osata aika paljon hoitaakseen asiat "perusjärkevästi" mikä korkeamman tason kielissä on ~automaattista. Normikoodissa pitäisi harvoin näkyä esimerkiksi noita pointtereita.

Javassa ulkoasu on juurikin niitä kankeuden aiheuttajia. Pitkäveteisyys ja ilmaisuvoiman puute tekee koodista vähemmän luettavaa, kun ideat joutuu esittämään pienempien abstraktioiden kautta ja pusertamaan Javan sallimaan ahtaaseen muottiin. Tuosta Scalasta esimerkiksi sanotaan, että koodin pituus jää noin kolmasosaan vastaavasta Java-koodista. En muista koodaritutuistani yhtäkään, joka oikein erityisen mielellään käyttäisi Javaa kun muitakin vaihtoehtoja on.

[arttula]

Eilen saapuivat tilaamani O'Reillyn "Learning Python" ja "Programming Python". Melkoisia järkäleitä molemmat ! Nuo, kun opiskelee ajatuksella, on helpompi varmaan alkaa katselmaan noita tulevaisuuden ohjelmointikieliä.

[spiidi78]

Minusta C++:n muistinhallinnassa on kovasti parantamisen varaa - siinähän pitää osata aika paljon hoitaakseen asiat "perusjärkevästi" mikä korkeamman tason kielissä on ~automaattista. Normikoodissa pitäisi harvoin näkyä esimerkiksi noita pointtereita.

Manuaalisuus on hyvä ja huono asia. Huono asia on se, että se on työlästä. Hyvä asia on se, että se soveltuu kaikkiin mahdollisiin tilanteisiin. Tarvittaessa senkin voi tietty automatisoida vaikka käsin C++11 standardissa näkyy muuten olevan muutama (Boostista tuttu) smart pointteri-template lisää helpottamaan (tai vaikeuttamaan) elämää.

[Sleepperi]

Minusta C++:n muistinhallinnassa on kovasti parantamisen varaa - siinähän pitää osata aika paljon hoitaakseen asiat "perusjärkevästi" mikä korkeamman tason kielissä on ~automaattista. Normikoodissa pitäisi harvoin näkyä esimerkiksi noita pointtereita.

Manuaalisuus on hyvä ja huono asia. Huono asia on se, että se on työlästä. Hyvä asia on se, että se soveltuu kaikkiin mahdollisiin tilanteisiin.

Ei. On hyvä, että voi halutessaan rakentaa kaiken atomeista alkaen, mutta on yksiselitteisesti huono, että perusjärkevä toiminta vaatii manuaalista nysväystä, tietotaitoa ja tarkkaavaisuutta. Erikoistouhu jota tarvitaan ehkä 5% ajasta pitäisi olla opt-in.

Esimerkiksi D-kieli taitaa olla jokseenkin sitä, mitä C++ voisi olla ilman historian painolastia ja inertiaa.

[spiidi78]

Esimerkiksi D-kieli taitaa olla jokseenkin sitä, mitä C++ voisi olla ilman historian painolastia ja inertiaa.

Piti mielenkiinnosta vilkaista tuota D-kieltä. Muistuttaa jonkin verran sitä, mitä Qt tekee. Puhdas C++ on tietty hyvin alkeellinen verrattuna esim Qt-frameworkiin. Bonusta tietty on se jos ne löytyy kielestä jo valmiiksi, miinusta on se ettei high level koodiin pysty juurikaan itse vaikuttamaan, jos haluaa tehdä asiat jollain muulla kuin "sillä oikealla" tavalla. Loppupeleissä kaikissa kielissä on hyviä ja huonoja puolia. Jotkut sopivat paremmin toiseen asiaan kuin toiseen. En voisi kuvitella tekeväni mitään rautaläheistä koodia jollain javascriptillä. En myöskään web-sivua assemblyllä. Jne. Täytyypä vilkaista tuota Scalaa. Onneksi sekin on staattisesti tyypitetty kieli.

[jalski]

Omat kaksi suosikkiani ohjelmointikielistä ovat: Infernon Limbo ja PL/I.

Javalla ja C++:lla en nykypäivänä tekisi mitään edes maksusta! ;-) Mielestäni objektipohjaisuus (vierastan olio-termiä) on nykyään yliarvostettua ja sitä tungetaan pakolla joka paikkaan, vaikka siitä ei välttämättä ongelman ratkaisuun mitään lisäarvoa saisikaan.

[Sleepperi]

Esimerkiksi D-kieli taitaa olla jokseenkin sitä, mitä C++ voisi olla ilman historian painolastia ja inertiaa.

Piti mielenkiinnosta vilkaista tuota D-kieltä. Muistuttaa jonkin verran sitä, mitä Qt tekee. Puhdas C++ on tietty hyvin alkeellinen verrattuna esim Qt-frameworkiin.

En ole tutustunut Qt:hen, mutta ihmettelen miten applikaatioframeworkia voi verrata matalan tason ohjelmointikieleen jossa on pikkuruinen standardikirjasto, kuten C/C++/D? Qt:stähän on bindingit tsiljoonaan kieleen, muun muassa D:hen...

Bonusta tietty on se jos ne löytyy kielestä jo valmiiksi, miinusta on se ettei high level koodiin pysty juurikaan itse vaikuttamaan, jos haluaa tehdä asiat jollain muulla kuin "sillä oikealla" tavalla. Loppupeleissä kaikissa kielissä on hyviä ja huonoja puolia. Jotkut sopivat paremmin toiseen asiaan kuin toiseen. En voisi kuvitella tekeväni mitään rautaläheistä koodia jollain javascriptillä. En myöskään web-sivua assemblyllä. Jne. Täytyypä vilkaista tuota Scalaa. Onneksi sekin on staattisesti tyypitetty kieli.

Kieliä on eri tarkoituksiin, mutta samaan tarkoitukseen olevia kieliä on tietysti parempia ja huonompia. Tuskin käyttäisit minkään koodaamiseen C:tä, jos C++ olisi tarjolla? Vastaavasti D tappaisi varmaankin C++:n jos olisi puitteiden puolesta samalla viivalla. Valmiin koodin, työkalujen, alustojen, osaamisen jne muodostama inertia luonnollisesti säilyttää valtakielet hengissä riippumatta siitä miten fiksu itse kieli sattuu olemaan.