Go言語のイケてない部分 - ぐるぐる～
最近色々あって仕事でGo言語を使っています。 色々割り切っている言語なので、こんなこと言ってもしゃーないんですが、言語設計はミスってるんじゃなかなぁ、と思わざるを得ない点が多々あります。 使い始めて1か月くらいなので間違ったことを書いているかもしれませんので、何かあれば指摘していただけるとありがたいです。 本文ではネガばかり羅列していますが、ランタイムとツール周りは気に入っています。 Goのランタイムを使う、もっと洗練されたAlt Go的なものがあるといいのに(もしくはジェネリクスのったGo2を早くリリースしてほしい)、と思う日々です。 追記: なんか意図とは違った受け取られ方をしている方もいるので追記します。 この記事はあくまで、「Go言語を学ぶにあたって躓いた点」を列挙し、まとめ、理由を考えてみる(教えてもらう)ために書いたものです。 Go言語自体はDisってますが、Go言語ユーザーを
git bash here で開くシェルを ckw に変更する - ぐるぐる～
msysgit を入れると使える git bash here、便利なんだけどコマンドプロンプトに sh がのっかってるから、コピペとか超面倒。 なんで、ckw で sh が開くようにしてみた。 準備 まずは ckw を入手しないといけないんだけど・・・ 実は公式はもうなくなっていて、今はクローンがあるだけ・・・ ということでいつも以上に自己責任でお願いします！ ckw 自体は ckw でぐぐると改造版がいくつもヒットする上、ソースも配られているから自分で弄るのも面白いかも。 ckw改造版の修正版とuberboxの修正版と簡易電卓っぽいの。 - Perlとかmemoとか日記とか。 ckw 0.8.10 改造版を更に改造した（修正しただけ） ckw でプロンプトが消えないとき - やた＠はてな日記 ここでは一つ目のサイトのバイナリを前提に話を進めますね。 ウィンドウが 2 つ出ちゃうことがある
C# 使いから見てうらやましい Java8 の default 実装の使い方 - ぐるぐる～
Java8 から追加されるインターフェイスの default 実装ですが、C# の拡張メソッドに似てますよね。 実際、このどちらも「シンインターフェイス」を定義するだけで「リッチインターフェイス」が手に入ります。 しかし、C# の拡張メソッドと Java のインターフェイスの default 実装には、それぞれの利点と欠点があります。 拡張メソッドの利点 拡張メソッドの利点は、インターフェイスの実装者だけでなく、 インターフェイスの使用者に対してもインターフェイスの拡張が開かれている点です。 既存の型ですら、後付けでメソッドを追加することができるということです。 using System; public static class StringExtension { // インターフェイスでなくても、どんな型に対しても拡張可能 public static int ToInt(this str
並列/並行基礎勉強会で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
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
JSX の型を整理してみた - ぐるぐる～
JSX の型はかなり複雑なことになっている気がしたので、整理してみました。 プリミティブ型、オブジェクト型、可変型、未定義許可型 JSX における型は、この 4 種類に分類されるらしいです。 プリミティブ型 プリミティブ型は現在、 boolean int number string の 4 種類があります*1。 これらの型を持つ変数には null を入れることができません。 var x: int = null; // compile error! また、これらの型の値は変更不可能 (イミュータブル) となります。 3 がいつの間にか 4 に変わっていたりしてほしくないですよね？ "hoge" という文字列の o という文字がいつの間にか a に変わっていて "hage" とか悲しいですよね？ これらの型の値では、そのようなことは起こりません。 オブジェクト型 オブジェクト型は例えば、 st
JSX の進化速度が半端ない - ぐるぐる～
気に入らない所を直して pull request 投げたら、取り入れられたので、8 日前に書いたエントリが過去のものとなっちゃいました。 関数型 以前の JSX では、関数型は function(: int): string のように書く必要がありました。 これはこれでそのまま使えるのですが、新たに (int) -> string という形式にも対応しました。 ちなみに、複数引数はカンマ区切りで (int, boolean) -> string のようになります。 カリー化された関数は、 function(: int): function(: number): string の代わりに (int) -> (number) -> string と書けます。 引数を囲むカッコは、(今のところ) 省略不可能です。 これには 2 つの理由があります。 この機能を追加したとき、JSX のパーサの能力
すごい Haskell たのしく学ぼう！は本当にすごいのか？ - ぐるぐる～
すごいHaskellたのしく学ぼう! 作者: Miran Lipovača,田中英行,村主崇行出版社/メーカー: オーム社発売日: 2012/05/23メディア: 単行本（ソフトカバー）購入: 19人 クリック: 552回この商品を含むブログ (36件) を見る 今話題の、すごい Haskell たのしく学ぼう！を読んだのですが、ちょっと思ったことがあるので書評と合わせて書いておきます。 思ったこと 関数型言語がこれほど話題になるのはとても嬉しいことです。 しかし、一方で懸念点もあります。 ノリで「すごい」とだけ言う人たちがいる その人たちに乗せられて (自分には合わないのに) 買ってしまって、挫折してしまう人が出てきそう この本は、いい本です。 翻訳の質も素晴らしく、読んでいて「読みにくいな」と思った部分はありません。 それに加え、訳注と Appendix も素晴らしい。 しかし、誰にで
遅延評価ってなんなのさ - ぐるぐる～
何なんでしょうね。分かりません。 自分の頭の中をとりあえず整理するためのエントリなので、あなたの頭を混乱させるだけになるかもしれません。 もし混乱してしまったら忘れてください。え、無理？忘れてください。 自分の考えを明確にしたので、こちらをどうぞ。 遅延評価いうなキャンペーンとかどうか - ぐるぐる～ これは遅延評価ですか？ 関数を渡すだけ // 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
デブサミで自分戦略についてしゃべってきた - ぐるぐる～
いやぁ、ためになるセッションでした。 自分が若造でまだまだぺーぺーだと痛感させられましたね。 これに呼んでもらわなかったら今年はデブサミパスしようと思っていたので、呼んでもらって本当感謝です。 発表資料 自分戦略 View more presentations from bleis tift 話さなかったこと この業界に入ったきっかけになった出来事 この業界に入るきっかけとなったのは、鈴鹿高専の推薦に受かったことです。 高専の推薦って、結構早い時期に合否が出るので、受験勉強から一抜けしちゃったんですよね。 一人だけ暇になっちゃって、先生からも「周りはまだ受験シーズン真っ最中なんだから、嬉しいかもしれないけど浮かれすぎないでね」とか言われちゃって。 で、「暇をつぶすために何かやろう。せっかくだから高専に入ってから役立ちそうなことやろう」と思い立ったんですよ。 その時やったのが、微積とプログラ
再帰で考える - ぐるぐる～
再帰は関数型言語を構成する重要な部品の一つです*1。 しかし、手続型言語に慣れたプログラマにとって、再帰で考えるというのは難しいものがあります。 このエントリは、そういうプログラマが再帰で考えることができるようになるために書きました。 言語としては、F# と C# を使っています (推奨は F#。C# の例は実用性が無いに等しい) が、Java プログラマでもある程度読めるでしょう。 前提条件として、これらの言語の文法は知っているものとします。 特に、C# で言う Func デリゲートを多用します。 すごい長いので、時間があるときに一気にどうぞ。 再帰以外の話もちょろちょろと出てきます。 再帰の重要性 いきなりですが、再帰はあくまで最後の手段です。 普通は再帰をカプセル化した関数を使うことになります。 通常使わないのであれば、再帰を学ぶことに意味はないのでしょうか？ いいえ、それでも再帰を
コンフリクトが発生しなくても壊れる場合 - ぐるぐる～
push したら誰かが先に push していたので失敗した。 なので pull したが、コンフリクト (競合) は発生しなかったので何も確認せずにそのまま push した。 何も問題なさそうですね。 ・・・本当ですか？ 例えばこんな状況を考えてみましょう。 最初の状態 A さんと B さんと C さんが登場します。 作っているのは Web ページで、コードはこんな感じ。 <html> <head> <title>hoge</title> <style> .menus { overflow: auto; } ul { margin: 0; padding: 0; list-style-type: none; } .button { float: left; width: 100px; margin: 0; padding: 10px 0; text-align: center; backgr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
