Esim:

using (TextReader r = File.OpenText(“log.txt”))
{
    // Tiedoston lukua
}   // < - Tässä kutsutaan r.Dispose()

Javassa sama homma vaatii enemmän nakuttelua, eikä kieli itsessään mitenkään varmista resurssien vapauttamista:

final FileInputStream f = new FileInputStream("log.txt");
try
{
    // Tiedoston lukua
}
finally
{
    close(f);
}

Voin kyllä silti suositella Haskellia. En usko, että mikään kieli on vaikuttanut ajatteluuni yhtä paljon kuin Haskell. Ensin olin aivan pihalla, mutta nykyään se on ehdottomasti kolmen kärjessä suosikkikielieni listalla. Valitettavasti en osaa sanoa mikä olisi hyvä ensimmäinen Haskell-tutoriaali, mutta hyvä toinen tutoriaali on Jonathan Tangin Write Yourself a Scheme in 48 Hours, jossa toteutetaan Haskellilla Scheme-tulkki.

Groovy on kyllä väärin niin monella tasolla ettei sitä viitsi edes ajatella.

En ole itsekään testannut SISC:iä, mutta Scheme on yksi suosikkikielistäni ja pari vuotta takaperin kirjoittelin itsekin Scheme-toteutuksen JVM:lle. En tiedä tukeeko SISC Java-rajapintojen toteutusta Scheme-koodissa, mutta mikäli tukee, niin se kärsii samasta ongelmasta kuin omakin toteutukseni: tulkilla on monta kontekstia, joidenka välillä continuationit eivät toimi. Käytännössä tämä tarkoittaa sitä, että continuationeita voi käyttää vain triviaaleissa ohjelmissa.

Mutta ongelmia JVM:llä tulee jo ilman continuationeitakin: pelkkä häntäkutsujen optimointi tarkoittaa sitä, että joko koodia ei voi kääntää Java bytekoodiksi tai jokaisessa kutsussa täytyy käyttää trampoliinia. Kumpikaan ei ole oikein kiva ratkaisu.

Ilmeisesti Scheme on Marsista ja JVM Venuksesta. Joka tapauksessa olen luopunut yrityksistä ajaa Schemeä JVM:n päällä.

OCamlin tutoriaali taas oli erittäin selkeä:

http://www.ocaml-tutorial.org/

Javan päälle rakennetuista kielistä olen kolunnut vasta Groovyä ja Niceä. Groovyn ongelma alkaa mielestäni olla se, että siinä on turhaan ruvettu sekoittamaan Javan ja Rubyn syntaksia. Hyvänä esimerkkinä viimeaikainen @Property/def-säätö. Nyt eri näkyvyydet menevät seuraavasti:

http://docs.codehaus.org/display/GroovyJSR/Property+proposal

Ihan hyvä, että tiputtivat tuon @Propertyn.

Yksi mikä on kanssa odotellut testaamista on SISC, R5RS-toteutus. Näyttäisi olevan varsin pätevästi toteutettu:

http://sisc.sourceforge.net/r5rs_pitfall.php

Tuo Scala vaikuttaa kyllä varsin tyylikkäältä. Täytyykin ladata se heti. Kiitoksia!

Oletko sattunut tutustumaan Scalaan? Scala on ehkä lupaavin JVM-pohjainen kieli, johon olen törmännyt ja se ratkaiseekin melko monet näistä ongelmista.

Microsoftin LINQ on itse asiassa paljon mukavampi miltä se näyttää: kääntäjä ei itse asiassa ymmärrä lainkaan LINQ-lauseiden semantiikkaa, vaan ainoastaan muodostaa parse-puun, johon pääsee ajonaikana käsiksi ohjelmallisesti. Näin ohjelmoija voi itse määritellä haluamansa semantiikan LINQ-lauseelle. (Esimerkiksi generoida siitä SQL- tai XPath-kyselyn.)

Guy Steelen Fortress menee vielä astetta pitemmälle: Fortressissa voi määritellä ohjelmallisia makroja, jotka jäsentävät ohjelmaa ja generoivat mielivaltaisia rakenteita jo käännösaikana. Ehkä tämä on se Fortressin ominaisuus, jossa Steelen Lisp-tausta näkyy parhaiten.

Olen kyllä menettänyt melkein toivoni Sunin suhteen. Siinä missä Microsoft kehittää omaa alustaansa jatkuvasti (LINQ, F#, …), sanoo Sun mahdollisesti lisäävänsä tuen propertyille, metodiviitteille ja closureille Java 7:aan. No, ehkä pitää antaa Sunille anteeksi Fortressin takia, vaikka se onkin suunnattu vähän eri kohderyhmälle. (Eikä siis toimi JVM:llä.)

Tulipas tästä nyt linkkipommitus. Anteeksi.

http://wiki.eclipse.org/index.php/The_Official_Eclipse_FAQs#Implementing_Support_for_Your_Own_Language

http://bagotricks.com/blog/2006/06/16/a-tale-of-two-javas/

1a -> “Number literals default to being arbitrary precision. Like BigDecimal or maybe a bit more serious.”
2a -> “Everything not-null by default.”
2c -> “Members are private by default.”
4 -> “Maybe JSON-esque object, map, and list literals”

Tässä listassa oli muitakin hyviä ideoita, kuten esimerkiksi “==”-notaation muuttaminen nulleja sietäväksi equalsiksi kuten Groovyssä ja charactereiden muuttaminen int-tasoisiksi (32-bittinen unicode).