VMWare fusion上のXubuntuで?GVimが正しく描画されない問題
GVimでスクロールしたり、gg
でジャンプしたりすると正しく再描画されず画面が真っ黒に。
(たちの悪いことに、マウスで少しスクロールすると再描画される。 そのため、絶妙な「不便で作業効率は落ちるけど一応使えてしまう」不具合になっている)
どうやら前からある問題のよう https://groups.google.com/forum/#!topic/vim_use/_goVuyxdgWA
解決方法としては、掲示板にもあるように、最新版を諦めてv7-3-367を使うこと。
ただし、これはVimではなくVMWare Fusion側の問題かもしれない。
もしプログラミング言語がお昼ごはんだったら
ソフトウェアを開発するためのプログラミング言語には様々な種類があり、 歴史あるもの新しいもの、手軽さを重視したもの厳密さを追求したもの、など様々な種類があります。
ここでは、8種類のプログラミング言語を、それぞれお昼ごはんに例えてみました。 どれもとても美味しそうですね。
アセンブラ
ウサギ。まず血抜きの処理から始まる。
C言語
昔はこういうのを食べていた。
Python
色とりどりのおかずは栄養バランスがよく、持ち運びにも便利です。
Java (Version 1.5)
栄養バランスがよく、持ち運びにも便利ですが・・・
PHP
ハンバーガーセット。たまに食べる分には手軽で旨い。でも毎日はちょっとね。
Go
ステーキ定食。そうそう、こういうのでいいんだよ、こういうので。
Haskell
マナーに厳しいおフランス料理店のフルコース。味は絶品だけど、フォークの上げ下げにも一々注意され、 メインディッシュを食べる前に追い出されました。
Common Lisp
高級食材。いや、レ・ディシプル・ド・オーギュスト・エスコフィエのあなたにとっては最高の食材かもしれませんがね、 我々には調理する腕も時間も無いんです。今日のランチを食べたいだけなんです。
あとがき
ついカっとなってやりました。他言語の画像も募集中。
AngularJSのチュートリアルを移植して感じた、Elmの3つの良い点と不満点
これはElm Advent Calendar 2014の14日目の記事です。
AngularJSのチュートリアルをElmで再実装してみました!
doloopwhile/elm-phonecat · GitHub
まだ、本体のソースコードだけで、解説は何もないのですが・・・。
書いていて、気づいた事を、良い点・不満点それぞれ3つずつ書いていきます。
良い点1:必要な機能が十分に実装されている
Elm v0.14ではJson.Decoder
が追加され、JSONのパースを実用的な記述量で実装できるようになりました。
私にとってはこれがAngularJSのチュートリアルをElmで再実装する上での「最後のピース」でした。
もちろん「ウチの業務アプリをElmで再実装してよ」と言われると「いやAngularJSの方が・・・」となります。まだElmには荒削りなところもあります。
しかし、「オモチャ」と言われる段階は脱したという印象です。
良い点2:直感的
Elmは「やりたいこと」と「解決法」がすぐ近くにある感じです。AngularJSのように新しいモジュールを勉強する回り道をしなくても、すぐに解決出来るのです。
例えば、AngularJS版のチュートリアルでは「True/Falseの代わりに"✓✗"を表示する」のために、Step-9を丸々ngFilterの説明に使っています。
一方Elmでは、
checkmark x = if x then plainText "\x2713" else plainText "\x2718"
の一行だけで用が足ります。
良い点3:エラー処理をサボれない
Maybe
やResult
を使って、エラー処理を厳格に行えます。
JavaScriptだとNULLチェックなどは「if != null、if != null はぁ〜面倒くさいなあ」となってしまいがちですが、ElmではMaybeのチェックをしないとそもそもコンパイルが通らないので、ものぐさな私でも安全なコードを強制的に書くことになります。
まぁ、「厳格」はデメリットでもあります(JSONのフィールドを全列挙しないとDecoderが作れないとか)。
不満点1:Signalが不便(特に、ページの階層構造を作りづらい)
一方、ElmはまだSignalが使いづらいと感じました。
今回作ったのはシングルページアプリケーション(SPA)でしたが、AngularJSの場合は、
- 実際にページを描画するTemplate/Controller
- URLからTemplate/Controllerを選択するngRoute
という仕組みになっています。ngRoute側ではページの描画の仕方を知る必要はありません。 また、各ページのTemplate同士(例えば、トップページのTemplateと、詳細ページのTemplate)は互いの事を知る必要がありません。「関心の分離」ができる、ナイスな仕組みです。
しかし、残念ながら、現在のElmではngRouteの真似はできないようです。
-- 注:このコードは実際のElmではありません。 -- URLのハッシュによって、ページを切り替える関数 route : Location -> Signal Element route location = if | startsWith("#/phones", location.hash) -> phoneView location | otherwise -> indexView -- トップページを描画 indexView : Signal Element indexView = indexPageImpl <~ Time.fps 30 ~ Mouse.clicks -- カタログの個別ページの描画 phoneView : Location -> Signal Element phoneView location = let api = Http.sendGet ("/api/phones/" ++ String.dropLeft(8, location.hash)) in phonePageImpl <~ Time.fps 30 ~ Mouse.position ~ api -- さて、main関数の型は? main = route <~ location
main
関数はElement
型かSignal Element
型でなくてはならないからです。そのためmain
関数は「全ページの描画とルーティングに必要な全部のSignalを<~
~
で連結する」ことになりがちです。
不満点2:union typeの処理が煩雑
ElmにはMaybe
、Result
、Http.Response
などのunion typeがあるおかげで、エラー処理を安全に行えるのですが・・・case文がネストしまくって大変です。
phonesResp : Http.Response (Result String (List Phone))
という型にしました。
実際にその値を処理している部分はこちら
case phonesResp of Http.Waiting -> Text.plainText "waiting" Http.Failure code text -> Text.plainText ("failed with " ++ (toString code) ++ " " ++ text) Http.Success resultPhones -> case resultPhones of Err error -> Text.plainText error Ok phones -> indexElements q sortPhones phones
JavaScriptだったら「早期リターンに書きなおすこと -1 」と、コードレビューで却下されても仕方ない感じのコードをElmでは書かざるをえません。
また、標準ライブラリのSignal
Maybe
モジュールも、「Signal (Maybe a)
からNothing
ではない値を取り出して返すSignal a
」のような関数が無いなど、細かい関数も不足しています。
悪い所3:レイアウト・スタイルライブラリの不足
ElmはHTML/CSSよりずっと直感的にレイアウト・スタイルを書けるのですが、やはりまだ機能不足です。
例えば、
- CSSの"border"相当のものが無い(containerを2つ重ねて無理やりborderを表現することはできます)。
plainText
をcontainer
で囲んでも、中の文字列は改行されない(自動で改行させる方法がない?自分で改行位置で分割してText.Line
などを使えば可能)。- 「画像を400x400に収まるように縦横比率を変えずにリサイズ」などができない(そもそも画像サイズを取得できない。
Port
を使えば無理やりできなくもないかもしれないが・・・)
一般的に、基本的なことはElmの方がAngularJSより簡単に出来るのですが、上に上げたような事を実装しようとするとElmでは不可能ではないものの多くの労力を割いて、細かいところまで実装しなくてはなりません。
「よくある処理」「80%のケースを20%の労力でカバーできるデフォルトの選択肢」がもっと用意されればいいな、と思いました。
あとがき
Elm Advent Calendar 2014にはまだ十分な余裕がございます。ふるってご参加ください。
Elm 0.14に際して思ったこと
今回のリリースには後方互換性が保たれない、大きな変更が含まれてます。 これによりHaskellとの違いが大きくなったため、もはや「Haskellベースの言語」という表現はふさわしくないかも知れません。
ところで、このような大きな変更は、メジャーな言語では、Rubyが2007年に1.9.0で、Pythonが2008年に3.0で行っていますが、その評価は対照的です。 Rubyでは1.9.0のことはもはや話題にもなりませんが、 Pythonでは未だに「2.xと3.xのどちらを使って開発すべきか」「2.x系の開発を続行するべきか」のような記事が書かれます。
私はこんな記事やこんな記事を書くほどPython好きだったので、Pythonが移行の失敗例のように語られるのは悲しいです。
両者の明暗が別れた理由としてよく言われるのは、
- Rubyは本格的な普及の前に大きな変更をした。Pythonは2008年当時すでに主要なLinux内部やGoogle App Engineで使われ、かなり普及していた。
- RubyはいわゆるWEB系で使われていたためライフサイクルが短かった。PythonはWEB系以外でも使われており、簡単に移行できなかった。*1
などがありますが、個人的には、
- RubyではRuby on Railsを使うユーザーが多く、Ruby on Railsが旧バージョンを切り捨てれば、ユーザーも新バージョンに映らざるをえない
- Rubyの方が元々アグレッシブで非互換性バッチコイなのユーザーが多い?(多かった?)。
のような理由もあると思います。
いずれにせよ、Elmは普及にはまだほど遠い段階なので(そもそも1.0以前ですし)、0.14での変更はElmの進化に良い影響を与えることと思います。
Elmはそもそも誰が作ってるの?【Elmアドベントカレンダー2014 7日目】
これはElm Advent Calendar 2014の7日目です。 社内勉強会でElmを紹介したら、
ボス「Who is creating Elm language ?」
私 「えっ?」
ボス「Elmって誰が作ってるの?」
というわけで調べてみました。
メイン開発者はPreziの中の人
Elmコンパイラに一番多くコミットしているのはにEvan Czaplickiさん。Wikipediaによると、もともとElmはCzaplickiさんが2012年に論文(大学の卒業論文か何か?)のために始めたプロジェクトだったそうです。
CzaplickiさんはPreziに2013年に入社しフルタイムでElmの仕事をしているそうです。elm-compilerにはCzaplickiさん以外にもPrezi社員が多いようです。
Preziはプレゼン作成用WEBサービスの会社
マインドマップベースのプレゼンがとってもオサレです。上手くハマればスゴいプレゼンができそうですね!
パワポやGoogleDrive等のスライド式プレゼンに慣れた身からは「使いこなせるかな?」とちょっと不安にもなりますが。
しかし、今の所、PreziのWEBツール自体は主にFlushで作られているようです。
結論
次の勉強会では、Elmの紹介プレゼンをPreziを使って作るのがいいかもしれません。
あとがき
おかげさまでElm Advent Calendar 2014はまだまだ空きがあります。ふるってご参加ください。
Elmで青春のフラクタルを描画する【Elmアドベントカレンダー2014 6日目】
これはElm Advent Calendar 2014の6日目です。
Elmの優れた点と言えば、
などがまず挙がるでしょう。しかし、
- 図形描画ライブラリ
も、実はElmの長所の一つなのです。
Elmの図形描画機能
まずは 公式サイトの例をご覧ください。
HTML5のCanvasは、JavaScriptによる手続き型の実装を前提にしていたので、コマ毎にclearRectで消去したり、save/restoreで状態を管理したりする必要がありました。プログラマーはともかく、「学校で習った図形を書いてみよう」と言う場合にはやや非直感的です。
一方Elmでは更新処理自体はElmがやってくれます。
また、図形はForm
という「図形そのもの」を表す型として、
図形の移動や拡大縮小はmove
scale
といった関数として、自然に表現できます。
なお、注意点とがあり、collage w h forms
でw×hのキャンバスを作ったとき、原点はキャンバスの中心で、Xが大きくなるほど右、Yが大きくなるほど上の座標です。つまり、数学と同じ座標なのです。
フラクタルを書いてみる
図形が描ける、ならば初めにフラクタルを描くものと相場は決まっています。再帰呼出し&縮小+移動で、シェルピンスキーのギャスケットを描画してみました!
n = 0
では単なる三角形を、n > 0
では自分自身の縮小コピー×3を描画しています。
なお、Elmでは小さすぎる図形(1ピクセル未満?)は描画してくれないらしく、上の例で再帰が深すぎると何も表示されなくなりました。
自分語り&妄想:Elmは未来の十進BASIC
フラクタルを書いていると、十年前私がまだ紅顔の少年だった頃を思い出します。
私がプログラマーになったのは図書館から↓の本を借りたのがきっかけでした。
パソコンを遊ぶ簡単プログラミング―コンピュータを自由に操る「十進BASIC」入門 CD-ROM付 (ブルーバックス)
- 作者: 木村良夫
- 出版社/メーカー: 講談社
- 発売日: 2003/01/20
- メディア: 新書
- クリック: 7回
- この商品を含むブログ (2件) を見る
当時は悪名高いMicrosoft Visual Basicがボロクソに言われつつも全盛の時代でしたが、十進BASICはVBとは全く別の"Full Basic"という規格に沿った教育用BASIC環境でした。
教育用だけあって
と、初心者用の機能が充実しているだけではなく、
- 数値は10進小数がデフォルト(2進数モードもある)
- 10進1000桁モード(数値型が小数点以下1000桁まで格納可能になる)
- 有理数モード
- 複素数モード
- 強力な図形描画機能
- function文とは別に、図形を定義するpicture文がある
- scale, rotate, shift, 任意のアフィン変換, それらの合成変換
- グラフ描画用関数
- 図形関連の豊富なExample(含シェルピンスキーのギャスケット)
等など、数学用の機能がとても充実していました。
言うまでもなく、構造化プログラミングにも対応しており、良いプログラミングを教われなくなったり、完膚なきまでに壊れることもありませんでした。
さすがに今では、プログラマー志望の高校生にはPythonあたりを薦めます。 でも、数学者・科学者志望だけどプログラミングの素養を身につけたい高校生ならば、今でも10進BASICを薦めたいと思います。(高校生の知り合いはいないけど)。
一方Elmですが、Playground、デバッガ、図形ライブラリなどは既にかなりの充実度です。 このまま発展すれば21世紀版・十進BASIC的な地位に着けるのではないか? と、ガスケットを書いていて思いました。
あとがき
おかげさまでElm Advent Calendar 2014は今のところ途切れず続いていますが、まだまだ空きがあります。ふるってご参加ください。
- 作者: 白井豊
- 出版社/メーカー: ゆたか創造舎
- 発売日: 2009/09/05
- メディア: 単行本(ソフトカバー)
- クリック: 9回
- この商品を含むブログを見る
ElmとHaskellの6つの非互換性【Elmアドベントカレンダー2014 3日目】
これはElm Advent Calendar 2014の3日目です。
ElmはHaskellベースの言語なので、Haskellの記事や入門書もElmの学習に使えます。しかし、実はElmにはチョコチョコHaskellと違うところがあって互換性はありません。
相違点をElm公式サイトLearnの SyntaxとFAQから抜粋して解説します。
1. Elmは遅延評価ではありません
Haskellは遅延評価なのでリスト処理の効率が良いのがウリでした。 JavaScriptにもジェネレータという形で遅延評価の思想が取り入れられています。
しかし、Elmのリストや辞書等などは遅延評価ではありません。
Elmはクライアントサイドの言語なので、遅延評価があまり役立たないこと、
Signal
がJavaScriptのジェネレータのような機能を持っているためのようです。
2. Elmにモナドはありません
Signal
があるので、IOモナドは不要です。それどころかMaybeモナドもListモナドもありません。したがって、do文もありません。
なお、Maybeは標準ライブラリにMaybe
パッケージがあり、JavaScriptでnull
を使うようなコードを安全に書けます。
でも、やっぱりdo文はあった方がいいと私は思うことがあります・・・。case
を5段階ぐらいネストしたりすると。
まぁ「モナドは圏論に基づいています*1」という説明が「Haskellってモナドが難しいんでしょ?」という誤解を生むことがないからいいのかな?
3. 関数関連の演算子が違う
Elm | Haskell | 意味 | 同値なJavaScript | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
f x <| g y z
|
$
と.
がそれぞれ<|
と<<
に変わっています。そして引数の順番を逆にした>|
と>>
が加わっています。
4. ::
と:
の意味が逆
Elm | Haskell |
---|---|
norm : Float -> Float -> Float norm x y = sqrt (x * x + y * y) |
norm :: Float -> Float -> Float norm x y = sqrt (x * x + y * y) |
1 :: 2 :: alist == [1, 2] ++ alist |
1 : 2 : alist == [1, 2] ++ alist |
これは型アノテーションの方がリストへの追加よりも頻繁に使うからです。
5. foldl系関数の引数の順序が逆
List.foldr
, List.foldl
はリストの要素に次々に関数を適用する関数です。
データ構造毎にDict.foldl
、Set.foldl
といった変種もあります。他言語ではreduce
やinject
という名前で提供されていることがあります。
// elm v = List.foldr (+) 0 [1,2,3] // 同等なJS var list = [1, 2, 3]; var v = 0; for (var i = 0; i < list.length; i++) { v = v + list[i]; }
微妙な違いですがElmではList.foldl
が受け取る関数の引数の順序をあえてHaskellと逆にしてあります。
Elm | Haskell | ||
---|---|---|---|
List.foldl : (a -> b -> b) -> b -> [a] -> b
|
これは、Elmでは標準ライブラリを「データ構造はいつも最後の引数」というルールで設計しているのに関係しています。
たしかに、HaskellのようにList.foldl : (b -> a -> b) -> b -> [a] -> b
であったとすると、foldr
にはそのまま使えるのにfoldl
には使えない関数が出てきて困る気がしますが・・・私にはよく分かりませんでした。
公式サイトのLibrary Design Guidelinesにその点が書いてあるのですが、例がおかしい(間違っている?古い?)気がします。
6. 他にも色々なものがありません。
- do文以外のモナド関連の構文や演算子
- where文。代わりにletを使う
(+1)
のような記法。代わりに((+) 1)
と書く- ライブラリ
こんなに違って大丈夫?
Haskellは元もと演算子が多い(多すぎる?)言語なので、ElmではSignalが入って互換性がなくなるなら演算子も整理したいと言うことなのでしょう。
ただ「HaskellのライブラリがElmに流用できない」という懸念をもつ方もいらっしゃると思います。私も不安です。
しかし、Haskellは主にサーバーサイドやコンパイラなどに使われ、Elmはクライアントサイドのための言語なので、「ブラウザ上で動くコンパイラを作りたい」というのでもなければ、HaskellのライブラリをElmに流用する機会は実は無いのかもしれません。
あとがき
更新が24時を過ぎてしまいました。
Elm Advent Calendar 2014にはまだ空きがあります。ふるってご参加ください。
- 作者: Miran Lipovača,田中英行,村主崇行
- 出版社/メーカー: オーム社
- 発売日: 2012/05/23
- メディア: 単行本(ソフトカバー)
- 購入: 25人 クリック: 580回
- この商品を含むブログ (67件) を見る
*1:確かにモナドは圏論にルーツがありますが、 「『変数』はデカルトにルーツがあります」「正規表現はオートマトン理論に基づいています」「while文を使用することで原始計算可能な関数だけでなく真に計算可能な関数を作成することが可能になります」ってあえて説明したりしないでしょう?「モナドは圏論(ry」が使われる背景には、数学という虎の威を借りてHaskellを高尚に見せようとする心理があるように私には思えます。