SF(すごくふつう)なブログ

記録・メモ・自己啓発・他

アイカツLIVEイリュージョンに行ってきた

アイカツとはバンダイが展開してる女児向け玩具・アニメ・ゲームです。詳しいことは公式ホームページをご覧ください。

今回そのアイカツのライブイベントに行く機会があったので何枚か写真を撮ってきました。

続きを読む

ElmでN-Queenしてみた

説明

動作するもの

題名の通り、ElmでN-Queen問題をやってみました。リアルタイムにクイーンを配置していくので、アニメーションとして楽しめます。

N-Queen問題ではバックトラック法を使うわけですが、木構造深さ優先探索していないので、厳密な意味でのバックトラック法ではないかなと思います。

N-Queenの場合、縛りのせいで最大2手戻ればすべて網羅できるので、そのせいで解けています。

2014-08-16追記: 良く考えるとツリーをすべて網羅しているということはバックトラック出来ているということですよね。

書いてて思ったのはやはりリストをがっつり扱えるElmという言語のパワーです。特にクイーンの配置をチェックする部分が物凄くきれいに書けます。

斜めチェック用のリストを生成している部分です。

-- left down to right top
ldrtCoords w h =
  let xys = xyCoords w h
  in map (\(x, y) -> y - x) xys

-- right down to left top
rdltCoords w h =
  let xys = xyCoords w h
  in map (\(x, y) -> y + x) xys

それを使ってチェックします。

      -- チェッカー関数 nはそれぞれチェックするグループIDを示す
      rowCheck n = filter (\(x, cellState) -> x == n) <| zip (yCoords bw bh) xyq
      colCheck n = filter (\(y, cellState) -> y == n) <| zip (xCoords bw bh) xyq
      ldrtCheck n = filter (\(ldrt, cellState) -> ldrt == n) <| zip (ldrtCoords bw bh) xyq
      rdltCheck n = filter (\(rdlt, cellState) -> rdlt == n) <| zip (rdltCoords bw bh) xyq
      
      checkFn = (>=) 1
      
      -- チェックフラグ
      rowCheck' = all checkFn <| log "row" <| map (countQueens . rowCheck) [1 .. bw]
      colCheck' = all checkFn <| log "col" <| map (countQueens . colCheck) [1 .. bh]
      ldrtCheck' = all checkFn <| log "ldrt" <| map (countQueens . ldrtCheck) [(1 - bw) .. (bw - 1)]
      rdltCheck' = all checkFn <| log "rdlt" <| map (countQueens . rdltCheck) [2 .. (bw + bh)]

Cなどの手続き型で書かれたN-Queen問題のソースコードは結構ぐちゃっとしてる場合が多いと思うのですが、やはりここは関数型の簡潔さ・スマートさを感じますね。

ちなみにRosetta Codeというサイトでいろんな言語のN-Queen問題の解法を見ることができます。

続きを読む

ElmでHttpリクエストを投げる例

説明

ここ最近関数型言語が私の中でブームになっています。

中でもElmという言語が、取っつきやすく、また(他の関数型に比べて)平易なので楽しんで取り組むことができています。

まだ世間では知名度があまり高くないようですが、次のような記事が有ります。

Googleエンジニア曰く「私たちにはより多くのWebプログラミング言語が必要だ」

GoogleのソフトウェアエンジニアであるGilad Bracha氏は、ニューヨークで開催されたQCon開発者会議の壇上で、Webアプリケーションについて触れた。同氏はWebアプリケーションについて、機能と使いやすさでデスクトップアプリケーションを上回る可能性を有している。しかし、実現するにはWebアプリケーション開発でより多くのプログラミング言語が選択できる必要があるだろうとしている(ITWorld、Slashdot)。 その理由として、Webアプリケーションには、ネットワークに接続できない環境では使えないという欠点がある。将来的にはWebアプリケーションをオフラインで実行する能力は重要になる。このためどんなWebプログラミング言語でも、オフライン使用のための何らかの方法が必要になるだろう。またプログラマがアプリケーションを組み上げたり、テストするのがより簡単になる必要がある、と語った。 また、現在、Webアプリケーションに使用されている主要言語はJavaScriptだが、アプリケーションのオフライン運用には機能的に不十分だ。Googleプログラミング言語である「Dart」を支援することに決めたのは、Webのために強力なプログラミング言語を提供する目的があるという。同氏は有望ではあるが知名度が低い言語として「Elm」についても触れている。Googleとしては特定の言語を否定したり、支援するのではなくWebアプリケーション向けにより多くの開発言語の選択肢が増えることを望んでいるようだ。

この記事で触れられているように、Googleのエンジニアも注目しているプロダクトの様です。

Elmは主にリアクティブ・プログラミングというプログラミングパラダイムを使用するために存在するようですが、まだリアクティブ・プログラミングが従来のイベント駆動型プログラミングに対して持つ明確な優位性を私自身は理解できていません。しかし広く使われているイベント駆動型に比べて考え方がガラッと変わるので、頭の体操・新たなモノの見方を習得するといった観点において、Elmによるプログラミングを経験することは十分に意味があると思います。また関数型言語が持つ明瞭さ・簡潔さを朧げながらも感じ始めると、通常の手続き型言語によるプログラミングにもどかしさを感じれるようになると思います。どこか大人になったような気分になれます。

AppleSwiftという関数型の特徴を持った言語を新たに持ってきたりと、確実に主流の言語は関数型の特徴を取り入れようとしています。またElmの構文は、関数型言語でひときわ有名なHaskellの構文にとても良く似ています。しかしHaskellに比べるといくつか足りない構文があるせいか比較的シンプルです。特にモナド周りはElmにおいて存在が希薄なので、モナドで躓いた私のようなプログラマにとっては非常に取り組みやすいと思います。ElmでHaskellライクな構文や関数型言語に慣れ、その後Haskellや他の関数型言語に挑戦するという道筋も十分にありだと思います。というか私がその路線を考えています。Elmサイコーです。

以下私が考えたElmのメリットです。

  • モナドを意識しなくて良い
  • Javascriptに変換されるので様々な環境で実行可能
  • Haskellライクな構文で非常に読みやすく、簡潔に書ける

デメリットはそれほどないと無いと思いますが、あえてあげるとすれば

  • エディターの対応が貧弱(しかし関数型は型をしっかりと意識するのでさほどエディターの補助機能は必要ないように感じる)
  • 使ってる人があまりいない(しかしこれは時間の問題だと思われます)

ぐらいでしょうか。もっとあるかもしれませんが、まだElmはβバージョンであり、さらに期待してしまう部分が大きすぎて不満は特に感じないと思います。

長々と前置きを書きましたが、以下ElmでHttpリクエストを投げるサンプルコードです。Elm初心者なのでぐだぐだなコードになっていると思います。

続きを読む

当ブログのコンテンツの引用は自由です。