Times like these

6 Kommenttia Lisää kommentti

• 1. Artti Jaakkola  |  Heinäkuu 29th, 2006 at 21.16

  Joku muukin on näköjään kirjoittanut lähestulkoon identtisen listan toisaalla:

  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).

• 2. Artti Jaakkola  |  Heinäkuu 30th, 2006 at 10.07

  Löysin hyvän selostuksen, mitä vaaditaan uuden kielen toteuttamiseksi Eclipseen:

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

• 3. Juha Komulainen  |  Heinäkuu 30th, 2006 at 10.59

  Dang, kirjoittelin jo pitemmänkin kommentin, mutta sitten softa valitti tarkistuskoodin olleen väärin ja menetin sen. (Siitäs sain kun en noudattanut sääntöä numero 1: kopioi aina kirjoittamasi teksti leikepöydälle ennen kuin klikkaat submittia.) No koitetaan uudestaan, hieman lyhyemmin.

  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.

• 4. Artti Jaakkola  |  Heinäkuu 30th, 2006 at 19.20

  En tiennytkään, että Microsoft on tehnyt oman versionsa OCamlista. Vaikka Haskell taitaakin olla tällä hetkellä kehittyneimpänä pidetty staattinen FL, niin mielestäni tuo OCaml on jotenkin selkeämpi. Johtuu ehkä siitä, että lukemani Haskell-selostus kertoi noin kymmenen erilaista tapaa tehdä yksi ja sama rekursio. Tuli vähän liikaa tavaraa kerralla.

  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!

• 5. Juha Komulainen  |  Heinäkuu 30th, 2006 at 20.38

  OCaml on varmasti helpompi hahmottaa kuin Haskell. OCaml ei ole laiska ja siinä on mahdollisuus sivuvaikutuksiin ilman monadeja. Joku sanoi, että ML on Scheme staattisella tyypityksellä, eikä tuo kaukana olekaan. OCaml lisää tähän pakettiin vielä oliosysteemin.

  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ä.

• 6. Artti Jaakkola  |  Elokuu 10th, 2006 at 22.41

  C#:n “using” avainsana olisi myös aika mainio. Se takaa, että nimetyn muuttujan Dispose-metodia kutsutaan blokin päätteeksi.

  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);
  }