動的型付き言語は素早くプロジェクトを立ち上げるのに向いており、静的型付き言語は長期間の保守にむいているという仮説 - kmizuの日記
注：誤解されないように最初にこの記事の意図を書いておくと、古典的な静的型付き言語VS.動的型付き言語の論争をするつもりはありません。これまで色々なプロジェクトを観察（風聞も含む）して来たところ、そういう傾向があるのではないかという仮説です。それと、文脈として主にWebアプリケーション開発する時のことを想定しており、それ以外のケースはいったん脇に置いています。WebアプリケーションだとPHP（動的型付き言語）の方が圧倒的に事例多いのではという感想もありそうですが、その辺りを考え出すと話がこんがらがるので、これもいったん脇においています。 たとえば、色々な事例を見聞きするに、スタートアップ企業において動的型付き言語であるRubyのWebアプリケーションフレームワークであるRuby on Rails（RoR）は好まれる傾向にあります。近年のPythonの動向はさておき、未だにRoRの求人がかなり
JavaプログラマのためのIOモナド - kmizuの日記
特に説明はしません。IOモナドなんて言っても、別に難しいことではなく、結局やってる事はこんな感じですというのがわかってもらえれば。もちろん、実際のHaskell処理系がこのような実装になっているという意味ではなく、JavaプログラマはこのようなイメージでIOモナドを理解すればいいのではないかという提案に過ぎないので、その点は注意してください。 package iomonad; import java.util.Scanner; public class IOLib { enum Unit{VALUE};//一つしか値を持たない型 public static Unit UNIT = Unit.VALUE; /** * HaskellのIO 'a型に相当 */ public interface IO<A> { /** * IOを「実行」して、A型の値を得る処理． * ユーザが直接呼び出すと参照
私なりのオブジェクト指向プログラミングの定義 - kmizuの日記
きしださんの以下のツイート オブジェクト指向はこの20年だれも再定義せずみんな自分の思うオブジェクト指向を暗黙に仮定して適当に話してるだけなので、技術的な共通認識のもとの議論はほとんどできないんですよ。という話を「オブジェクト指向をきちんと使いたいあなたへ」の記事に書いたのだけど、そろそろ公開するか— きしだൠ(K8S(Kishidades)) (@kis) July 29, 2019 を読んで、そういえば、私が思うオブジェクト指向の定義、についてツイッター以外ではあまり語ったことがなかったなと思い返し、ちょっと記事にしてみることにしました。まず、結論からいうと、私はオブジェクト指向プログラミングとは サブタイピングを活用したプログラミング手法の総称 と考えています。ここで、クラス継承とかインタフェース継承とかダックタイピングとかではなく、単にサブタイピングであるのがポイントです。なお、型
Javaのジェネリクスは「まがい物」ではない - kmizuの日記
先日、自分が書いた kmizu.hatenablog.com に対する反応として、「Javaのようなまがい物のジェネリクスと比較するのは適切でない」「Javaのジェネリクスと比較するのは適切でない」（おそらくC#や(C++等（2017/09/24追記）)の言語と比較して）といった コメントをいくつか見かけました（はてなブックマークコメントやツイッターなどで）。しかし、ここでは、そのような言説こそが適切でない、ということを言いたいです。なお、methane氏との 対話については既に終わったものなので、それとは関係ありません。 そもそも、Javaジェネリクスは、静的型付き関数型言語で既に一般的であったパラメータ多相をJavaに追加する目的で導入されました（C++テンプレートのようなものをJavaに追加するためだと思っている人がいるかもしれませんが、それは実態にあっていません）。実際、Java
Re: Go にジェネリクスがなくても構わない人たちに対する批判について - kmizuの日記
先日自分がGoについてつぶやいたものが、id:methaneさんに捕捉されていて、それに対する反論記事 methane.hatenablog.jp があがっていたので、それに対する所感を書いてみました。（2017/09/22 追記）：cocoatomoさんから指摘があったのですが、引用元は全て id:methane さんの、上記ブログエントリの文章です。雑多な感想に関して反応しているものではないです。 前置き Goや言語批判に関するスタンスを誤解されると嬉しくないので、最初に書いておきます。 Goの言語仕様はあまり好きではないけど、Goユーザーを見下したり、馬鹿だとかそういう風には思っていない 言語仕様批判とユーザー批判は別の話ですが、しばしばいっしょくたにされて、糞言語Xを使うユーザは糞だ、みたいな主張がされることがあるので、 そういう意図はないという表明です。 Goユーザーの中で、ジェ
JSONのようでそうでないデータフォーマットNSON 0.0.1リリース - kmizuの日記
きっかけは、昨夜の思いつきでした。 今日ふと思ったこと： JSONって、そもそもカンマ要らないんじゃね？ { "Foo" : "BAR" "BAR": "Baz" "Hoge" : { "name" : "Hoge" } } 特に曖昧性なくパーズできるように思える。配列も同じく。— Kota Mizushima (@kmizu) 2016年11月6日 JSONでも以前から、末尾のカンマを許すようにしてほしいとかそういう要望があったと記憶していましたが、そもそもカンマを要らなくすれば解決では？というのが動機です。 NSONは次のような特徴を持っています。 オブジェクトの属性を区切るカンマが必要ない 配列の要素を区切るカンマが必要ない 属性のキーとして、文字列リテラルの他に通常の識別子が使える JSONの完全上位互換である まず最初の点についてですが、たとえば、 { "x": 1 "y": 2
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
