改めて（？）か昔からあるのか不明ですが、10進小数を言語のデフォルトにすべきかどうかという議論が一部で行われています。私自身、特にプログラミング教育を最近やっている立ち場もあって、10進小数を言語のデフォルトにすることに賛成の立ち場です。ただ、正直言ってこれに大して「反対する」側は何が焦点になっているかについて「ずれている」と思わざるをえないです。まずは、直近で見かけたWindyMeltさんのブログ記事より。 blog.3qe.us ちなみにこれはCOBOLかそうではないか、という軸が問題になっているのではなく、浮動小数点型を利用するか、それともBigDecimalのような十進演算のために用意された型を利用するか、という軸の問題であって、しかもそれも正確な軸の取りかたではない。 というのも、BigDecimalでカバーされない問題があるのだ。例えば、BigDecimal型を利用しても(1

こんばんは、みずしまです。最近は主に強化学習の勉強をしているのですが、読み進めていく過程で少し悩みの種がありました。それは、サンプルコードの扱いです。サンプルコードはPythonで書かれていて、実際に書き写すことが私にとって理解の助けになるのは確かなように思えましたが、一方で過去の経験から、そのまま写経すると「スルスルと動いてしまってフィードバックとして不十分そうだな」と感じたので、Scalaで書いてみることにしました。 別にScalaでなくて、JavaでもRubyでもあるいはJuliaでも良かったのですがそれはともかくとして、元のサンプルコードと違う言語で書くことで得られる利点も結構あるものだなというのが正直に感じた点です。たとえば、np.mean(...)というコードが書籍では出て来るわけですが、「そういえばScalaでmeanと同じことをするにはどうしたらいいんだっけ？」と考えること

まえがき タイトルが一体何言ってるんだお前は、という感じのものなのですが、初めて構文解析器ぽいものを書き始めてから、たぶん20年くらい経ったかなくらいの意味です。私を知っている方はご存知かも知れませんが、修士~博士にかけての私の研究テーマは、Packrat Parser/PEGで、博士論文もそれ関係でした。 で、博士号取った後、査読付き論文は一本も出していないのですが、中田育男先生の、ISO-Rubyパーザの試験実装をお手伝いしたり、なんだかPEGや構文解析に関する論文の査読をしていたら、去年からプログラミング研究会の論文誌編集委員になったりしています。最近、まともに（査読付き）論文書いてない私がこんな立場引き受けていいのかなーと思うものの、構文解析という分野はとてもニッチなので、査読できる人が少ないせいか、構文解析に関する論文は、私に査読の話が来ることがしばしばあります。 私が型システム

プログラミング言語大全 作者:クジラ飛行机発売日: 2020/04/18メディア: 単行本（ソフトカバー） 技術評論社の編集さんから、「プログラミング言語に詳しい人」枠でなんだか献本いただきました。ただ、タイトルを見た時点でそこはかとなく不安があったので、記述がひどいぽかったら書評は書かないでおこうと思いましたが、ぱらぱらと読んで、よく調べて書かれた書籍だと思ったので、ご紹介したいと思います。 この書籍は、日本語プログラミング言語「なでしこ」や「ひまわり」の作者として知られているクジラ飛行机さんが、世の中に数多あるプログラミング言語の中で、（比較的）知られているものについて、 プログラミング言語の歴史 影響を受けた言語 影響を与えた言語 利用シーン 文法や処理系の特徴 といった側面から紹介するといった趣です。 オススメしない読者 初めにこれを書くのはどうかと思ったのですが、読む必要がない人

先日、自分が書いた kmizu.hatenablog.com に対する反応として、「Javaのようなまがい物のジェネリクスと比較するのは適切でない」「Javaのジェネリクスと比較するのは適切でない」（おそらくC#や(C++等（2017/09/24追記）)の言語と比較して）といった コメントをいくつか見かけました（はてなブックマークコメントやツイッターなどで）。しかし、ここでは、そのような言説こそが適切でない、ということを言いたいです。なお、methane氏との 対話については既に終わったものなので、それとは関係ありません。 そもそも、Javaジェネリクスは、静的型付き関数型言語で既に一般的であったパラメータ多相をJavaに追加する目的で導入されました（C++テンプレートのようなものをJavaに追加するためだと思っている人がいるかもしれませんが、それは実態にあっていません）。実際、Java

先日自分がGoについてつぶやいたものが、id:methaneさんに捕捉されていて、それに対する反論記事 methane.hatenablog.jp があがっていたので、それに対する所感を書いてみました。（2017/09/22 追記）：cocoatomoさんから指摘があったのですが、引用元は全て id:methane さんの、上記ブログエントリの文章です。雑多な感想に関して反応しているものではないです。 前置き Goや言語批判に関するスタンスを誤解されると嬉しくないので、最初に書いておきます。 Goの言語仕様はあまり好きではないけど、Goユーザーを見下したり、馬鹿だとかそういう風には思っていない 言語仕様批判とユーザー批判は別の話ですが、しばしばいっしょくたにされて、糞言語Xを使うユーザは糞だ、みたいな主張がされることがあるので、 そういう意図はないという表明です。 Goユーザーの中で、ジェ

今まで、あまり見たことがない（一般エンジニア向け）勉強会で、かつ、これを学ぶことは実用上とても意味があるテーマの一つに「構文解析」があります*1。 たとえば、Webアプリケーションにおいて、ユーザの入力に大して何らかの構文的制約をつけてバリデーションをする機会は多いですが、正規表現による簡単なチェック（あるいは、滅茶苦茶複雑な正規表現を作って色々な入力のバリエーションに対応する）や、よくわからない緩いバリデーションで済まされることは多いように感じます（自分の開発経験というより、Webアプリケーションのフォームのバリデーションの仕方などを見ての感想です）。 正規表現によるバリデーションで十分なことも多いので、それをむやみに否定するものではありませんが、入力が（原理的に）正規表現でバリデーションできない場合や、可能だが正規表現が爆発するケースだと、正規表現が不適当なこともしばしばです。 個人的

Understanding Scala - connpass 昨日、表題の技術イベントを自分主催で行いました。なんでこんなイベントをやろうと思ったかというと「皆、Scalaを難しくめんどくさい方法で学んでるのでは？」という疑問が自分の中であって、その原因として、サンプルプログラムの集合を通して、ボトムアップになんとなくイメージで 全体像を作りあげてるのではという思いがありました。 そのようなアプローチに対して懐疑的な自分としては、このイベントでは（厳密にはやってませんが）どちらかというとトップダウン的アプローチでプログラミング言語について理解してもらおうと思い（もちろん、例は大切なので必要に応じて詳細に下りるのは忘れませんでしたが）、５つの発表の全てを全部自分でやりました。さすがに、５時間程度しゃべりっぱなしというのは疲れましたが、おかげさまで（？）、色々な疑問が解決したとか、メソッドと関

Scalaは標準IOライブラリが非常に貧弱な言語です。scala.ioはまともに使えるものではありませんし、JDKのライブラリのIOを使うのも面倒です。そこで、サードパーティのIOライブラリを使うことになります。そこで、いくつかサードパーティのIOライブラリを見てみたところ、いずれも自分のやりたいことをぱっとできるように思えなかったので、自分で作ってみることにしました。 なお、better-filesは、自分の要求に一番近かったですが、java.ioやjava.nioがインタフェース部に露出しているのがあまり好みではありませんでした。 そこで、 java.ioがインタフェースに露出しない Rubyのように簡単なIO処理が簡単に書ける リソースの後始末は可能な限り簡単に 多数のリソースをネストせずに扱える オーバーロードをしない（！） を目標として、新しいライブラリScarubyの開発を始め

TL;DR 世間のScalaに関するイメージは、昔のままであることが多い 昔のままどころか、最初から間違ったイメージを持たれていることも多い 実際には、既に解決されている問題は多々あるし、改善に向かっていることも多い プロジェクト管理の問題を言語に押し付けているケースもある はじめに 自分が最初にScalaに触れたのが2005年（Scala 1からカウントした場合）、あるいは2007年（Scala 2以降からカウントした場合）と、Scalaとの付き合いも結構長くなってきましたが、その間に Typesafe社（現Lightbend社）の設立 実質標準ビルドツールとしてのsbtの確立 ライブラリのバイナリ後方互換性に関するポリシーの策定 公式ScalaイベントScala Daysのはじまり Play 2 Frameworkの登場 Scala Center発足 その他色々 がありました。この間、

connpass.com 今回開催したこのイベントは、私が学習用に作成したプログラミング言語nub github.com の文法や機能拡張を通じて、プログラミング言語処理系の作成の基礎について学ぶというものでした。 自分がこのイベントを開催したねらいは主に二つあって、 プログラミング言語（処理系）作成に興味のある技術者を増やしたい プログラミング言語処理系初学者にとって、学びの障害となるのはどこか知りたい というものでした。準備には十分時間をかけたかったので、昨年秋から募集を始め、また、チューターとなってくれる 方も同時に募集しました。結果として、応募人数は十分過ぎる程、チューターも4名（うち2名は遠方（静岡と名古屋から！））来てくれる ことになりました。 チューターのno_maddoさん、yontaさん、long_long_floatさん、tetsuromさんの協力があったのは、特に、自

追記：Twitterで、「それって、言語マニアにしかできない技のような気が」という指摘を受けました。自分としては一般的に適用可能な話だと思っていますが、あるいは自分の感性が著しくずれているのかもしれません。その辺承知の上でお読みください。 Scalaは習得が難しい言語だ、とよく言われます。また、実際問題として、Scalaの言語仕様の全体はそれなりに複雑でもあります。しかし、それはたとえばJavaでも言語仕様の全体像を把握するのは難しい話であり、Scalaに限った話ではありません。にも関わらず、Scalaの習得が難しいとよく言われるのはプログラミング言語の学習モデルが誤っているからではないかと最近思うようになりました。そこで、Scala（や他の言語も含めて）のコストを下げるために必要な心得についてちょっと書いてみます。 Scalaはオブジェクト指向言語である これは、Scalaは関数型プログ

Scalaは最初から関数型プログラミングのスタイルで書くことを意識して設計されたという意味で関数型プログラミング言語と言えますが、一方で、「Better Java」な手続き型スタイルで書くことも基本的には否定されるべきではないと思います。たとえば、ビッグデータ関係のソフトウェアとして有名なApache SparkはScalaで書かれていますが、（おそらく）パフォーマンス上の理由のため、手続き型のスタイルで書かれている部分がかなり多いです。 さて、それはいいのですが、そういう「Better Java」なScalaコードによく見られるパターンに、変更可能コレクションを使っているのに、そのコレクションを格納する変数をvarとして宣言しているものが（割と有名なソフトウェアでさえ）あります。ですが、そういうコードは 書いてはいけません（かなり例外的な場合を除いて）。 「書いてはいけません」というのは

「プログラマのための技術書籍○選」とかよく見るじゃないですか。あれ、自分はどうにも好きになれないというか、後進を自分がたどってきた道に引きずり込みたいだけじゃねーかと思うのが多いです（全部がそうだとは言いません）。なので、今回のエントリでは、あくまで、「私が好きな」技術書籍を10冊紹介することにします。単に思い出深いというだけの書籍も入っており、間違っても「オススメ書籍」ではないのでご注意を。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行本（ソフトカバー）購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る オブジェクト指向入門 第2版 方法論・実践 (IT Archi

表題の通りです。とりあえず、Kotlin版とScala版のコード貼ります。 gist.github.com gist.github.com これらのコードでは、両方とも明示的なダウンキャストやその他の抜け穴を使っていないので、実行しても決してClassCastExceptionが起きてはいけないのですが、実際に実行するとClassCastExceptionが起きてしまいます。 さて、これはコンパイラの実装のバグでもあり、言語仕様のバグでもあるのですが、ちょっと理由を説明してみたいと思います。 class B extends A with Comparable[B] { def compareTo(b: B): Int = 0 } 上記のコードをコンパイルすると、下記のコードが生成されます。ここで、int compareTo(java.lang.Object)というメソッドが 定義されている

Scala Nativeはscalaのコードを(LLVMのIRを経由して）ネイティブコードにコンパイルするAOTコンパイラ（Ahead Of Time Compiler）です。その存在については、少し前にサイトができていたことで一部で話題になっていましたが、Scala Days 2016 NYCにて正式に公開されました。現在はPre-Release段階ですが、既にサンプルコードを試せるようになっていたので、環境を構築してみました（on Mac OS）。 scala-nativeのリポジトリをcloneする $ git clone git@github.com:scala-native/scala-native.git --recursive git submoduleとしてscala/scalaを持っているので、--recursiveを付けるのを忘れないようにしましょう。 llvm(cla

先日の、Scala勉強会第170回 in 本郷 : サブテーマ「Scalaの言語仕様」 rpscala.doorkeeper.jp でScalaの言語仕様について解説していたときの反応をみて、どうも、自分のプログラミング言語の把握の仕方はあまり一般的ではないのではということを考えました。どう違うかというと一言では説明できないのですが、世間的には、プログラミング言語については、よりフィーリング的になんとなく理解している部分理解していない部分がぼやーっとしているのに対して、自分の場合、理解している部分とそうでない部分の境界がくっきりしているような感じです。 それはともかくとして、このエントリでは、自分が最近新しく触った言語であるKotlinについて、どのようにして理解を進めたかを書いてみたいと思います。 公式ドキュメントを読む 定番といえば定番ですが、公式ドキュメントが一番正確に言語について書

2014年3月末をもって、株式会社ユビレジを退職することになりました。在職期間は2年3ヶ月とそれほど長くありませんが、スタートアップ企業の顧客に近い位置で仕事をすることができて、とてもいい経験が出来たと考えています。 退職に関して 新しい職場で自分の力量を試してみたくなったことと 現在のユビレジにおいて自分が果たせる役目が一通り終わったという実感 そもそもユビレジにジョインした時点で、働き始めて2年間経ったら転職先を考えようと思っていた というのが大きな理由です。 ユビレジに入った当初～去年４月までは、駒場東大前近くにある、通称ユビハウスという一軒家の１階をオフィス用として利用していました。おかげで、 柿の木から柿を収穫（！）して食べた 東大駒場キャンパスの食堂で昼食を食べた タイカレーを皆で作って食べた たこやきを皆で作って食べた といった貴重な経験をすることができました…というのは冗談

少し前に献本いただいたのですが(竹添さん、翔泳社様、ありがとうございます)、時間が無くてあまり読み進められていませんでした。昨日使って一通り目を通したので、ちょっとした感想を書きます。購入の際の参考になれば幸いです。 まず、結論から言うと、本書は、 (特に)Javaをメイン言語として使っている人で、Scalaを学習したい人 Scalaを使った実用プロジェクトを作り始めたい人 Scalaの各種ライブラリの基本的な使い方を知りたい人 にお勧めできる書籍といえます。主な理由としては、 現行安定版である Scala 2.9.X (現在最新安定版はScala 2.9.2) に対応している事 言語機能に関するレシピがある事 sbtを使って、実際に開発を行うために必要な記述がちゃんとあること 準標準的なライブラリ(Akka, Specs 2, 等)や新しいFW(Play 2)に関する記述が豊富な事 など

JavaとScalaとC#のジェネリクスは、いずれも継承を持ったオブジェクト指向言語においてParametric Polymorphismを実現するための手段であり、それぞれ異なった特性を持っている。というわけで、それぞれの言語においてジェネリクスがどのようにサポートされているかを比較した表を用意してみた。後で気が向いたら、各項目の説明を追加するかも。 Java(5.0以降) Scala C#(4.0) ジェネリックなクラス ○ ○ ○ ジェネリックなメソッド ○ ○ ○ 型パラメータの上限 ○ ○ ○ 型パラメータの下限 × ○ × 型パラメータの推論 ○ ○ ○ 全ての型のサブタイプ(ScalaにおけるNothing) × ○ × definition-site variance × ○ ○ use-site variance ○(Wildcard) ○(Existential Typ