はじめに 当初、ScalaMatsuri 2019が終わった次の日の、6月30日に書く予定だったのですが、最終出社日も終わっていることだしよいかということで、エントリを書くことにします。 2019年6月30日をもって、5年と3か月勤めた株式会社ドワンゴを退職します。最終出社日は6月26日でした。 これまで2回転職してきましたが、ドワンゴに居た期間が最長です（なお、5年で最長でというのに違和感感じる人もいるかもですが、博士卒で就職したので、まあそんなもんかと思っています）。 何やってたの 1年目こそプロダクト開発に携わっていたものの、2年目以降は、 Scala研修テキストの執筆やメンテナンス 新入社員研修の中のScala研修講師 ドワンゴ社員として各種イベントやカンファレンスで発表 論文の査読や情報処理学会関連のイベント（主にPRO（プログラミング研究会））への参加 自分主催の勉強会（テーマ

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

なんだかTwitterの一部で www.utali.io の記事が話題になってるようですが、はっきり言って誤情報です（というか、何故そんな誤解をしたのか知りたいくらい）。根拠はいくつかありますが Twitterは最近（ここ数ヶ月）にScala CenterのAdvisory Boardにjoinしている 置換えたとされるFinagleのコミットが最近でも活発である そもそも引用元ツイートで一言も、Scalaを捨てたに相当する表現が見られない 1についてですが、Scala作者のMartin Odersky先生が Odersky先生も参戦してる。"For what it's worth Twitter just joined the Scala Center advisory board as a full member. Don't believe the FUD."— 水島宏太（ゆる糖質制

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

Scala基礎文法最速マスターを書こうか迷っていたら、既にyuroyoroさんに書かれてしまったので、ちょっと違う方向で。BNFを既に知っている人は、これを読めばPEGの基礎をマスターしてPEGを書くことができるようになるでしょう(ほんとか？)。 基本 Parsing Expression Grammar(PEG)はBNFに似ているけど、ちょっと(かなり？)違う文法の表記法です。BNFはその文法がどのような言語を表現しているかを定めるのに対して、PEGは入力がどのように解析されるかを定めます。PEGとBNFの一番大きな違いは、PEGには曖昧さが無いことです。たとえば、プログラミング言語のif文を表現する次の擬似BNFには曖昧さがあります。 statement ::= if_statement | ...; if_statement ::= IF LPAREN expr RPAREN sta

カリー化と部分適用の違いについては、過去のエントリ カリー化 != 部分適用 で既に述べており、決着もついているので改めて書きません。 カリー化 != 部分適用のエントリを書いたのは2009年12月です。もう3年以上前の話になります。ですが、JavaScript界隈などをみると、未だにカリー化と部分適用の違いについての誤解は残っているようです。一方で、静的型付き言語界隈でそのような誤解をほとんどみかけません。カリー化が関数の「型」を変換する操作(関数)であるために、動的型付き言語にのみ慣れ親しんでいると、両者の違いがわかりにくいのかもしれません。 ある技術用語が指すものを誤解する事自体は仕方ないことですし、責めるものではありません。また、用語が指すものは時代を経ると変わっていくものだという主張もあるでしょう。ただ、カリー化という用語の定義は明確に定義されており、数十年もの歴史があります。こ

Java変態文法最速マスターなんてのがかなりブクマされてるみたいだが、変態さならJavaなんてScalaの足元にも及ばないぜ！！ということで、Scala版を書いてみました。しかし、実はあまり変態ではないかもしれません。元ネタと違って、これを読めば何かがわかる、という意味の実用性はあまり無いでしょう。 implicit conversion編 基本 Scalaのimplicit conversionは使いようによってはScalaの強力な型システムを台無しにしてしまう力を持っています。たとえば、 implicit def string2int(x: String): Int = Integer.parseInt(x) というimplicit conversionを定義してやると、"300" / 3が100になるなどというキモい挙動を実現することができます。また、さらにカスタマイズして、16進数

Scalaでnullを使っていいのは小学生までだよねー、というのは冗談ですが、Scala文化圏ではnullを使わないのが原則です（いくつか例外はありますが）。代わりに出てくるのがOption型です。しかし、Scalaでは困ったことにnullを返すJavaのメソッドを呼び出さなければいけない場面がたくさんあります。 たとえば、以下のようなコードを書かなければいけない場面にはしばしば遭遇します。 val javaMap: java.util.Map[String, String] = javaObject.getMapping() val value: String = javaMap.get(key) // 型注釈はあえて付けている if(value != null) { ... } else { ... } さて、ここで困るのが、javaMap.get(key)はkeyに対応する値が入って

唐突に始まったScala Tipsコーナー、初学者が陥りがちなScalaのコードパターンを例にして、より良い方法を解説していきます。第一回はOptionクラスのmap()メソッドを使おうというものです。知ってる人には今更ですが、Option#map(f)は、レシーバーの値がSome(v)の場合は、fにvを渡した結果のSome(f(v))が、Noneの場合はNoneが返ります。したがって、パターンマッチを使った以下のようなコードは val result = exp1 match { case Some(v1) => val vx = //expression using v1 Some(vx) case None => None } 常に以下のような形に書き換えることができます。 val result = exp1.map{v1 => val vx = //expression using

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