タグ

ブックマーク / bleis-tift.hatenablog.com (7)

  • C# 使いから見てうらやましい Java8 の default 実装の使い方 - ぐるぐる~

    Java8 から追加されるインターフェイスの default 実装ですが、C# の拡張メソッドに似てますよね。 実際、このどちらも「シンインターフェイス」を定義するだけで「リッチインターフェイス」が手に入ります。 しかし、C# の拡張メソッドと Java のインターフェイスの default 実装には、それぞれの利点と欠点があります。 拡張メソッドの利点 拡張メソッドの利点は、インターフェイスの実装者だけでなく、 インターフェイスの使用者に対してもインターフェイスの拡張が開かれている点です。 既存の型ですら、後付けでメソッドを追加することができるということです。 using System; public static class StringExtension { // インターフェイスでなくても、どんな型に対しても拡張可能 public static int ToInt(this str

    C# 使いから見てうらやましい Java8 の default 実装の使い方 - ぐるぐる~
    USAGI-WRP
    USAGI-WRP 2013/05/28
    そんなことより Scala ですよ
  • 並列/並行基礎勉強会でasync/awaitをDisってきた - ぐるぐる~

    async/await不要論 from bleis tift 3/23 に開催された、並列/並行基礎勉強会で「async/await 不要論」という発表をしてきました。 一番言いたかったこと 一番言いたかったことは、実は並列とかとは全く関係ないことです。 それは、言語への機能追加に関することです。 C# は 5.0 で非同期処理のための専用の構文として、async/await を導入しました。 これは、F# が計算一般という抽象度の高いものための汎用的な構文として、コンピュテーション式を採用しているのとは対照的です。 専用の構文を用意するかしないかは、その言語を取り巻く環境次第です。 専用の構文の利点と欠点 専用の構文の利点は、その使用用途が明確であるというところにあります。 そのため、書き方さえ覚えてしまえば、その裏で何がどうなるかなどを一切気にせずに使えてしまえたりします。 欠点は、専

  • 「変数に型がないということの利点について考える」の問題について考える - ぐるぐる~

    id:perlcodesample さんの 変数に型がないということの利点について考える - サンプルコードによるPerl入門 から。 ううむ。 けれども、型がないということは、当に素晴らしいことです。 型がないことによって、たくさんの面倒から解放されるからです。 冒頭のこれが、「静的型付き言語にはメリットが(ほとんど)ない」と言っているように思えてしまいます。 コメントのやり取りを見ても、ある程度そう考えているように受け取れます。 勘違いなどが多く見られたので、補足というか、反論というか、そんな感じのことを書きます。 追記: ごく一部、このエントリを「動的型付き言語と静的型付き言語を比べて、静的型付き言語の方が素晴らしい言語である」ということを言うためのものだと勘違いしている人を見かけました。 このエントリは、そこについては言及していません。 あくまで、元記事で「動的型付き言語のメリッ

    「変数に型がないということの利点について考える」の問題について考える - ぐるぐる~
  • C# から使いやすい F# コードの書き方 - ぐるぐる~

    さて始まりました、F# Advent Calendar 2012 です。 今年は、「実用」がテーマと言うことで、F# で書いたコードを C# から使いたくなった時に気を付けるべきポイントなどをまとめました。 F# と C# で異なる名前を付ける F# では、module に定義する関数や変数の名前は、lowerCamel で付けるのが一般的です (List.map など)。 しかし .NET の世界では、これらの名前は基的に PascalCase で付けることになっています。 CompiledName 属性を使うことで、この差を埋め、F# からは lowerCamel に、C# からは PascalCase に見える名前を付けることができるようになります。 (* F# *) module Util = [<CompiledName "ToStr">] let toStr x = spri

  • JSX のアレな所 - ぐるぐる~

    注意!このエントリは既に古いので、JSX の進化速度が半端ない - ぐるぐる〜もあわせて読んでください。最新のコードを参照するのが手っ取り早いです。 JSX なる言語がリリースされました。 この言語が謳っているのが、 高速 安全 簡単(生産性が高い、とも) という 3 点です。 高速と安全はまぁいいでしょう*1。 問題は、はたしてこの言語は簡単なのか?という点です。 簡単かどうかは人によるのでアレなのですが、まぁ一部の人にとっては簡単とは言えない (というか書く気がしない) 書き方を強制されるのです。 関数型 数値を受け取って文字列を返す関数を表す型は、JSX では以下のように書きます。 function(:number):string これ単体で見ると分かりやすそうな気配はします。 では、これ読めますか? function f(g: function(:number):number):

  • 遅延評価ってなんなのさ - ぐるぐる~

    何なんでしょうね。分かりません。 自分の頭の中をとりあえず整理するためのエントリなので、あなたの頭を混乱させるだけになるかもしれません。 もし混乱してしまったら忘れてください。え、無理?忘れてください。 自分の考えを明確にしたので、こちらをどうぞ。 遅延評価いうなキャンペーンとかどうか - ぐるぐる~ これは遅延評価ですか? 関数を渡すだけ // Scala def hoge(f: Unit => Int) = for (i <- 1 to 2) println(f()) (* F# *) let hoge f = for i in 1..2 do printfn "%d" (f()) この関数に渡す f は 2 回実行されます。そのため、f の中で画面出力をしていた場合、2 回出力されます。 これは遅延評価でしょうか?俺は違うと思います。 ここは多くの人で合意が取れると思ってます。 Sc

    遅延評価ってなんなのさ - ぐるぐる~
  • Lazy を使って Seq の foldBack 的なものを書いてみた - ぐるぐる~

    @yoshihiro503 Seq.foldBack は標準にはないですが、仮にあったとして、たとえば Haskell のように、map を foldr で実装する的なことってできないんじゃ、と思ってるんですが、どんなもんでしょうか? 2012-01-20 00:30:23 via web to @yoshihiro503 書いてみた。 let rec foldBack f xs init = if xs |> Seq.isEmpty then init else f (Seq.head xs)(lazy foldBack f (Seq.skip 1 xs) init) let cons x (xs: Lazy<'a seq>) = seq { yield x; yield! xs.Force() } let map f xs = foldBack (f >> cons) xs Seq.e

  • 1