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

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

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

表題の通りです。とりあえず、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 本郷 rpscala.doorkeeper.jp は、サブテーマ「Scalaの言語仕様」であったため、久々に熱弁をふるったところ、特に、メソッドや関数の仕様や区別に関して疑問に思った方が多かったらしく、質問も多かったので、Q&A形式でまとめておきます。 Q: (x1, xN) => body 形式と、{ case pat1 => body1; ... case patN => bodyN }形式の違いは何でしょうか？ A: 前者は必ずFunctionN[S1,...,SN,R]型を持つのに対して、後者は期待型(expected type)によって型が異なります： 1: FunctionN[S1,...,SN,R]: この場合、 (x1:S1,...,xN:SN) => (x1,...,xN) match { case pat1 => body1 case

このエントリは、これまで自分がさんざんTwitterで書いてきたことですし、Martin Odersky教授へのインタビュー www.artima.com でおおむね語られていることでもあります。ただ、この辺の事情についてあまり詳しくない方も居るようなので、上記インタビューの引用を交えて、JavaにGenericsが入るに至った経緯や関連して活躍した人物についても書いてみようと思います。 事の始まりは1995年にJavaが発表されたことでした。これに触発された、Philip Wadler先生（世界的に有名なコンピュータ科学者）、Martin Odersky先生と同じ研究室に居た助手さん？がこれでなんかやってみないかと煽ったらしく、翌年の1996年には、JavaにGenericsや高階関数、ADTなど関数型プログラミング言語の機能を入れ込んだPizza言語をMartin Odersky先生が

表題の書籍について、出たとき（2015/5/29）に買って随分放置していたのだが、最近、一通り読んでみたので簡単な感想を書いてみようと思う。 結論からいうと、Scalaについて特に使う予定はないがおおまかにどんな言語か知っておきたいという方にはそこまで悪くない本だが、副題の「関数型プログラミングの設計と理解」について本書で学ぶのはオススメできない。そういう人には、Scala関数型デザイン&プログラミング ―Scalazコントリビューターによる関数型徹底ガイドをオススメしておこう。こっちの本も、ScalaでHaskellスタイルのFPをすることにこだわり過ぎて、Scala Wayからは外れていると感じる部分もあるのだが、少なくとも関数型プログラミングについて丁寧に取り組んでいるとはいえる。 本書を読む前に気になっていたのは、技術的な点での瑕疵がどの程度あるかということだったが、この点に関して

Scala Days 2014(2014年6月16日〜2014年6月18日)に参加することは先日のエントリで書いた通りなのですが、今年は正式にドワンゴ社のエンジニアとして参加することになりました。ですので、一部の費用を除いて、必要経費のほとんどが会社から出ることになります。 今年はその分いつもより現地でのエンジニアとの議論や発表の視聴を初め、気合いを入れて行って来たいと思います。滞在記も書き溜めて、帰国後はドワンゴ社のエンジニアブログでScala Days 2014についてリポートする予定です。それなり以上の性能のカメラで写真も豊富に撮ってくる予定ですので、こうご期待！ ○○をOdersky教授に聞いてきてもらいたい 発表者の○○さんにこんな質問をして来て欲しい といった希望もこのコメント欄で受け付けていますので、どうぞよろしくお願いします。 ドワンゴ社は、社内のプロジェクトの新規案件では

ときどきみかけるコードなのですが、パターンマッチを使ったコードで、次のようなものがあります。 exp match { case A => { expA1 expA2 ... } case B => { expB1 exbB2 ... } } Scalaでは、case節に複数の式を続けて書くことができるのでこのようなブレースは不要です。 exp match { case A => expA1 expA2 ... case B => expB1 expB2 ... } としてしまいましょう。

データベース実践講義 ―エンジニアのためのリレーショナル理論 (THEORY/IN/PRACTICE) 作者: C.J.Date,株式会社クイープ出版社/メーカー: オライリージャパン発売日: 2006/02/01メディア: 大型本購入: 4人 クリック: 170回この商品を含むブログ (52件) を見る 実はまだ完読してないのだけど、結構刺激的で面白い本なのでブログ再開ついでに紹介してみよう。 まず断っておく必要があるのは、この本は、SQLや特定ベンダのRDBMSの取り扱い方のノウハウ本ではないということ。その意味でこの本を読むことで即座に実践に何かを活用できるかは不明である。彼は関係モデルの祖であるCoddと共同作業をしていた時期があったこともあってか、この本では本来RDBの基礎であるべき（と彼が主張する）リレーショナルモデルをきっちり理解しなければならないという主張で一貫しており、こ

この記事はPlay or Scala Advent Calendar 2012 の 6日目です。今回の記事は、とりわけ役に立たないことを自負しています(役に立つ記事を読みたい人は飛ばしてください)。 本題に入る前に、conformanceという概念についてざくっと簡単に説明しておきます。これは、(Scalaの言語仕様では)サブタイプ関係とだいたい同じです。詳しくは、Scala Language Specification 3.5.2 を参照してください。 さて、このconformanceに関係した概念としてScala 2.8ではweak conformanceというものが導入されました。というと、何やら難しく聞こえますね。でも、実はとても簡単な話で、単にJavaのプリミティブな数値型相当の型(Byte, Short, Int, Long, Float, Double)同士の関係を、通常のc

Scalaに限らず、関数型言語の入門記事には、必ずといっていいほど、最初の方でリスト型が出てきます。不変データ構造として単純なので説明しやすいことや、実際に小さなコレクションとしてリストを使うことが多い事など、理由は色々あるでしょう。 まあ、それはどうでもよくて、今回はScalaにおけるリストの実現であるscala.Listが共変でなければいけない理由をちょっと説明してみようと思います。実は、他の静的型付け関数型言語のリスト型、たとえばSMLやOCaml、Haskellにおけるリスト型は共変ではありません*1(そもそもOCaml以外はサブタイプが無いですが…)。共変についての解説は面倒なので省きます。 結論を一言で書くと、共変でなければ空のリスト(Nil)値が簡単に作れないからです。 仮にscala.Listが共変でなかったとします。このとき非常に困るのは、空のListであるNilの型は一

JsondaはScalaでJSONオブジェクトをエレガントに*1構築するためのDSL、あるいはリテラル的な何かです。 ScalaでJSONオブジェクトを構築するときに、前々から私はイラっと来ていました。もっとも原始的な方法としては、JsonParser*2などを使って、 val person = JsonParser.parse(""" { "name":"Kota Mizushima", "age":28 """) とする方法があります。しかし、これだとtypoに気づきにくいですし、JSONの一部を別の値で置き換えたいときにとても不便でした。そのために、XMLリテラルを使って val person = JsonParser.parse(<t> { "name":"Kota Mizushima", "age":{age} </t>.text) といった事をしてたこともありましたが、途中で<

Scala 2.10.0 M3の新機能を試してみる記事第二段。今度はSIP-13 - Implicit classesです。 さて、Scalaでは従来、implicit conversionを使って、既存のクラスにメソッドを追加するPimp My Libraryと呼ばれるパターンが使われてきました。たとえば、Stringに対して、文字列を表示するdisplayメソッドを追加するためには、次のようなコードを書く必要がありました。 scala> class RichString(self: String) { | def display(): Unit = println(self) | } defined class RichString scala> implicit def enrichString(self: String): RichString = new RichString(s

先日というかしばらく前ですが、Scala 2.10.0 Milestone 3がリリースされました。この、「マイルストーンリリース」については、以前に書いたように、RCほどの品質は無い点に注意する必要がありますが、今回のMilestone 3で2.10.0に導入予定の機能の多くがとりあえず実装されているので、遊んでみる価値はあります。 というわけで、Scala 2.10.0 M3で実装された新機能を今後数回にわたって紹介していきます。まず最初は、SIP-11 - String Interpolation and formattingです。この機能、Rubyなどの言語ユーザにとっては非常におなじみの機能だと思います。早い話が、Rubyの puts "1 + 2 = #{1 + 2}" #" 1 + 2 = 3" と同様に、文字列リテラルの中に、実行時に評価されるScalaの式を埋め込める機能

なんか久しぶりに、技術ネタっぽい何かです。 Scalaの標準ライブラリは結構偏りがあって、scala.ioとかのIO周りは壊滅的だったりする(ので早くScala-IO入って欲しい)のですが、コレクションライブラリは結構充実してて、色々便利メソッドがあったりします。コレクション絡みで何か非常に短めのメソッド再発名発明したくなったら、APIリファレンスを読んでみると良いかもしれません。 例１： Option#toRight Optionは、Scalaでは非常に色々なところで使われており、それゆえにScalaでnullが明示的に使われる場面はあまりありません。しかし、Optionは、Some(x)かNoneの２種類しかなく、Noneの場合にどのようなエラーが発生したかという情報を持ち運ぶことができません。そのような場合、Eitherを使うことができますが、OptionからEitherに変換したい

このエントリはScala Advent Calendar jp 2010の11日目です。また、このエントリはTwitterでの@xuwei_kさんの疑問に答えようと考えて作成したコードが元になっています。どうもありがとうございます。 皆さん、C#のdefaultみたいなことScalaでしたくなったことありませんか。C#のdefaultというのはdefault(T)のようにして使い、Tが参照型の時はnullを、数値の型の時は0を、構造体の場合、0またはnullでメンバが初期化された構造体を返します。たとえば、 using System; namespace example { class DefaultValue { static void Main(string[] args) { Console.WriteLine(default(string)); Console.WriteLine(

今年5月くらいから、Scalaに関する日本語情報を一極集中化してまとめるサイトを目指して、プログラミング言語Scala日本語情報サイトというサイトを開設して、少しずつ更新していたのですが、最近、私生活の方が忙しい事もあって、あまり更新時間が取れていません。何名か協力していただいている方も居られるのですが、それらの方もやはり私生活等が忙しく、なかなか時間を割けていない状況です。 そこで、プログラミング言語Scala日本語情報サイトの運営・記事執筆を手伝ってくださる方を募集したいと思います。特に、必要な技術スキルなどはありません。日本のScala情報をまとめたい！と思ってくださる方なら歓迎いたします。 さしあたって、更新が遅延しているのが Scalaのニュース記事の翻訳 で、この辺り、もし、お手伝いしていただける方が居れば幸いです。また、それ以外でも、まだまだ情報が充実していない部分が多くあり

まずは引用： 続いてやってみた。お題はこちら。 お題：ある金額になるコインの組み合わせ - No Programming, No Life あまり芸のない総当たりだけど、こんなんでいいのかな。 object CoinAssort { def search(coinList: List[Int], sum: Int, curAssort: List[Int] = Nil): List[List[Int]] = { val preCoin = curAssort.lastOption.getOrElse(0) coinList.filter(coin => coin >= preCoin && coin <= sum).flatMap(coin => { sum - coin match { case 0 => List(curAssort :+ coin) case n => search(