by shigemk2

当面は技術的なことしか書かない

I love Scala #渋谷JVM

twitter.com

Scalaのはなし。

はじめての関数型言語

  • Common Lisp(Lispを関数型言語と呼ぶのかはおいておく)
  • Beating the Averages

ハッカーと画家 コンピュータ時代の創造者たち

ハッカーと画家 コンピュータ時代の創造者たち

  • Lispを使っていたから素早く開発できた
  • 素早さこそが競合に対する最大の武器だった

d.hatena.ne.jp

Lispを学んで得たもの

  • 関数型言語の基本的な考え方
  • マクロすごい
  • (((((((()))))))) 括弧のお化け

→Lispをやってもお金持ちに慣れなそうなことに気付き始める

2006 Haskellがちょっと流行る

きっかけはMonadius

Monadius - a scientist's toy box

  • 純粋関数型言語
  • モナド
  • コンパイルが通ればバグはない(と言われるが、そんなことはない)
  • でも仕事で使うのはちょっと厳しそうだ

2010 Clojureと出会う

  • 2007くらいには出ていたのに、Clojureはマークしていなかった

プログラミングClojure 第2版

プログラミングClojure 第2版

  • JVM上で動くLisp!!ついにLispの時代がきた
  • Lispなのに左から右へ書ける(Javaと同じ)
  • Lispの時代がきた、と思ったら来なかった

2011 Scalaと出会う

オブジェクト指向+関数型

  • 動的型付け言語の簡潔さと静的型付け言語の安全さを両立
  • 手続き型の書き方も出来、敷居が低い(モナドのことは知らなくていい)
  • JVM上で動作し、Javaと高い相互運用性を備える
  • Haskellはきびしい
  • Scalaは学術的な言語ではなく実用的な言語
  • プログラマが普通に使える言語(そういうポリシーをいろいろ感じる)

Haskell vs Scala

  • Scalaは継承とか出来てオブジェクト指向ぽくて読みやすい
  • 関数型にこだわりすぎない
  • 手続き型でも書ける
  • 必要であれば自由に状態や副作用を持てる
  • メソッドの外側からみて参照透過であれば、メソッド内では状態を持ってもよい
  • Scala使いにもいろいろ属性があって、better Java的な使い方をしている人もいればより関数型的な使いかたをする人もいる(聖戦)
  • でもまあおだすきー先生の思想から、バランスの取れた書き方が出来る
  • 一つの式に詰め込み過ぎない(Haskellとかは、やろうと思えば数行に渡るプログラムを1行にまとめることが出来る)
  • Scalaは分かりやすい名前をつけて意味的にどうにかすることが出来る

http://www.paraiso-lang.org/ikmsm/images/c80-cover.jpg

hascalator

サンフランシスコのScalaDaysで言及されたことば

  • IOや例外といった副作用のよりよい扱い方はないか
  • モナドは素晴らしいけどよりScalaらしい方法はないか
  • Scalaの一番よいところはバランス感覚
  • JVM言語なのでJavaの資産も活かせるのがメリット(better Javaなのでお客に説明しやすい。Haskellとかだと結構説明が難しいことがある)

  • これなら仕事に使えるかも知れない

当時の背景(2011-2012)

  • 少人数のチームで生産性を高めることで利益率を向上させることを追求
  • Seasar2 Apache Click S2JDBCなどのフレームワークとアジャイル開発プロセスを採用
  • でもJavaでは限界
  • 次どうしようってはまっていた時期

Scala実戦投入

  • 社内のテストツールをLiftやScalatraで作ってみる
  • 実践的な書籍がないので本を書いた

代表作

Scalaスケーラブルプログラミング第2版

Scalaスケーラブルプログラミング第2版

  • 作者: Martin Odersky,Lex Spoon,Bill Venners,羽生田栄一,水島宏太,長尾高弘
  • 出版社/メーカー: インプレスジャパン
  • 発売日: 2011/09/27
  • メディア: 単行本(ソフトカバー)
  • 購入: 12人 クリック: 235回
  • この商品を含むブログ (45件) を見る

本を書いた

Scala逆引きレシピ (PROGRAMMER’S RECiPE)

Scala逆引きレシピ (PROGRAMMER’S RECiPE)

  • Seasar2の開発が止まっていたので、Play2をやってみる

つらいことも多い

  • コンパイルが猛烈に遅い(あまりに有名なやつ)
  • IDEが猛烈に重い(Eclipseのプラグイン ScalaIDE)
  • Play2が猛烈にバグっている(2からScalaで書きなおされていて、1では出来たことが2では出来ないみたいなことがあって自分で作らないといけない)
  • sbt(名前と違って全然シンプルじゃないので名前が変わった)
  • 突然シャットダウンでビルドできないからセントラルにデプロイ
  • いろいろな混乱があった(政治的な問題でTomcatの上から動かさないといけない)
  • でもJavaに失われていた熱気があった
  • マクロもある

Macros - def マクロ - Scala Documentation

2013 GitBucket開発開始

  • Scalaで開発されたOSSのGitHubクローン

github.com

  • ScalatraやSlickなどに加えて、趣味で作っていたのでJGit Apache MINA Jetty H2など既存のJava技術を活用
  • コンパクトなコードで、少人数で開発を継続
  • インフラよりの実装がJavaで多いのはよいこと

2014 Scalaで大規模開発

  • Scalaの状況として、Play2も安定してきたし、その他のフレームワークやツール、ライブラリも揃ってきた
  • IntelliJ IDEAが無償で使えるようになった
  • 非同期処理分散処理が注目されはじめた

これからのScala

  • コンパイル速度
  • バイナリ互換性(Javaだとバージョンが上がってもコンパイルしたものが使える異常なやつだけど、Scalaだとバージョンアップするとバイナリ互換性が保証されない。ソースコードの互換性は保証されるが)
  • 解決するために新しいコンパイラを開発している(おだすきー先生がプライベートで)
  • TASTYで中間ファイルを作り、バイトコードやJSを生成する(Scala.jsとかもあつい)
  • でもこういうことすると余計にコンパイルが遅くなりそうな気がするので実用化されるかどうかは不明。6月7月あたりでアムステルダムでScalaDaysがあるのでそこでアルファリリースがあるのかしら
  • 言語仕様の整理
  • 行けてない昨日やシンタックスを廃止したり別機能で代替したり
  • よりシンプルな記述が可能になるような機能やシンタックスシュガーとか(UnionTypeとか)
  • 実行環境

今後の方向性

  • 関数型へシフトしていくわけではない
  • オブジェクト指向と関数型の融合
  • 強力な静的型付
  • Scalaの特徴を活かしたよりいsンプルで直感的な記述

Immutable時代のプログラミング言語 Clojure #渋谷JVM

twitter.com

特長

  • 重要なのはイミュータブルであること
  • Lisp
  • 関数型プログラミング
  • 確固たるプラットフォームと共生(.netやJS上でも動く)
  • 型にこだわる人にはなじまないかも
  • Concurrencyのためにデザイン(マルチコア)

github.com

Simple

  • ひとつの役割
  • ひとつのタスク
  • ひとつの概念
  • ひとつの次元

シンプルな構成要素を定義しようっていうのがClojureの思想

Easy

  • すぐに実現できる
  • IDE
  • apt-get gem install

Complex or Simple

  • 状態やオブジェクトは複雑、値はシンプル
  • メソッドは複雑、関数やネームスペースはシンプル
  • 出来るだけvarは使いたくない

複雑さのもとは組み合わせ

  • 状態=触るもの皆複雑
  • オブジェクト=状態、アイデンティティ、値 → これらのものは分解しよう
  • 文法 意味と順序

Abstraction

計算機プログラムの構造と解釈[第2版]

計算機プログラムの構造と解釈[第2版]

  • 作者: ハロルドエイブルソン,ジュリーサスマン,ジェラルド・ジェイサスマン,Harold Abelson,Julie Sussman,Gerald Jay Sussman,和田英一
  • 出版社/メーカー: 翔泳社
  • 発売日: 2014/05/17
  • メディア: 大型本
  • この商品を含むブログ (1件) を見る

  • 10のデータ構造に10の関数操作があるよりも、1つのデータ構造に100の関数操作があるほうがいい
  • seq function

Clojure - sequences

Clojureについて使いたくなる本

Seven Concurrency Models in Seven Weeks: When Threads Unravel (The Pragmatic Programmers)

Seven Concurrency Models in Seven Weeks: When Threads Unravel (The Pragmatic Programmers)

  • 非同期プログラミングのやり方が書いてある

Immutable

  • すべてがイミュータブル
(println "Hello World!")

Sharing Structure

  • イミュータブルっていうともとのデータ構造をコピーしている
  • コレクションに対して変更操作すると新しいコレクションがかえるが、変更のないデータは共有される

Managed refs

あまり実用的じゃない部分があるので、refの仕組みがある

Clojure - refs

  • 参照先を切り替える(若干いんちきくさい)

Epochal time model

www.safaribooksonline.com

過去の事実はそのまま残しておいて、状態を変更する。

Identity/State/Value

  • Identity 普遍的に同一実体
  • State ある時点の集合
  • Value 不変なデータ

STM

  • 複数のrefsを一貫性を持って更新したい
  • STMはロックをしない
  • Clojureが出た最初はSTMが標準実装されていた
  • でもSTMは性能が出にくい
  • ClojureのConcurrencyの対応としてcore.asyncが使われている

core.async

  • イミュータビリティを基礎として作られたライブラリ
  • 別のスレッドで呼び出す

github.com

  • スレッドベース。ひとつの処理はひとつのスレッド、チャネルの入出力でブロック
  • 並列性と多くのスレッドを要求する
  • スレッドプールからスレッドを取り出す
  • スレッドマクロに渡されたコードを実行する

  • コルーチンベース。ブロック地点でpark状態にし、スレッドをプールに戻す。少ないスレッドで並行処理ができるのがメリット。

  • JVMだとサイズが大きくなる。
  • core.asyncはClojureScritpでも、Clojureと全く同じように動く。
  • ただ、JavaScriptはシングルスレッドモデルなので、goのみ対応。

core.asyncのいけてるところ

  • go配下の構文解析
  • ブロック呼び出しの箇所を分割
  • ただのライブラリなので本体とは非依存
  • やっぱりマクロはすごい

Clojureをはじめてみよう

  • 依存性はleiningen(ライニンゲン)
  • IDEはLighttableもしくは Emacs + cider(開発者はEmacsが多い)

独習サイト

4clojure – Welcome!

Clojureはわりと実用的でRubyと同じようなアーキテクチャスタックで開発出来る

  • (Clojure)tomcat jetty Ring Compojure hiccup enlive
  • (Ruby)thin puma Rack Sinatra Haml Erb

Clojurescript

github.com

Google Clojure CompilerをつかってJSに変換。CircleCIなどで実績あり。

Grunt / Gulp layer

  • leiningenに統合されている
  • Aggregate / Minify
  • ライブラリロード

React

  • ReactもClojurescriptから自在に使える(JSX不要 すべてLispっぽく)

業務だとどうなの?

Excel開発も出来る

Excel界隈のつらみをどうにかしたい

qiita.com

github.com

仕事の開発

Job Streamer

www.slideshare.net

あなたとClojure今すぐイミュータブル

  • Lispのコンセプトを学びたくてClojure
  • 習得する際はClojureで何がしかのアプリを書いてみる

今さら始めよう Groovy #渋谷JVM

Groovy みんな使っていた。

twitter.com

プログラミングGROOVY

プログラミングGROOVY

  • 作者: 関谷和愛,上原潤二,須江信洋,中野靖治
  • 出版社/メーカー: 技術評論社
  • 発売日: 2011/07/06
  • メディア: 単行本(ソフトカバー)
  • 購入: 6人 クリック: 392回
  • この商品を含むブログ (155件) を見る

ElmやRustも推してる

Grails徹底入門

Grails徹底入門

  • 作者: 山田正樹,山本剛,上原潤二,永井昌子,杉山清美,杉浦孝博,笠原史郎,香月孝太,福岡竜一,伊堂寺北斗
  • 出版社/メーカー: 翔泳社
  • 発売日: 2008/08/26
  • メディア: 大型本
  • 購入: 3人 クリック: 42回
  • この商品を含むブログ (28件) を見る

おしながき

  • Groovyはどんな言語
  • Groovyの思想
  • Groovyはどう役立つのか
  • 今どきのGroovy(最新情報)

Groovyはどんな言語

  • 文法はJavaの(ほぼ)上位互換(do-whileがないとか例外はあるけど)
  • 真のクロージャを持ち簡潔な記述を旨とする
  • 型システム 型チェック
  • Groovy 1.8までは実行時型チェックのみ
  • Groovy 2.0からは静的型チェック 静的コンパイル
  • Javaに準じた静的なコードも書ける(動的型言語という表現は正確ではない)

  • GroovyコードはJavaバイトコード(クラス)に常にコンパイルされて実行される

  • ラッパーや特殊なコンテキストやインタプリタなし
  • ライブラリ
  • 独自の体系はもたず、Java標準のAPIを基本としてGroovy独自のクラスやメソッドを追加

Groovyの歴史

  • 2003 誕生
  • 2006 JSR
  • コア開発会社がどんどん変遷している
  • シンタックスエラーがデラデラ出てくるようなコンパイラ
  • 今はだいぶ改善されている

最近の話題

  • Pivotal社がスポンサーを降板
  • ASFプロジェクト

やりたいこと

バビロンの日記: Groovyで "Hello World!!"

Javaがやりたいことが濃縮されているし、コード量はJavaの半分以下で抑えることが可能。

Groovyコードの実行

Java

javacからクラスファイルを作ってjavaコマンドで実行

Groovy

クラスファイルを生成しなくても実行することが出来うる

GDK

Groovyの思想

  • Javaを置き換えない
  • Javaとの併用 共存 補完が存在意義そのもの
  • GroovyはJavaクラスファイルを別ルート 別記法で読み込ませるためのクラスローダーであり、ライブラリの一種でもある
  • JavaのAPIやライブラリはGroovyにとって必要悪ではない
  • Javaライブラリは直接もしくはGroovyラッピング拡張して使う
  • RxGroovy/RxJava

github.com

JavaのライブラリをGroovyで使えるようにする

JRuby想定ユーザタイプ別Groovy乗り換えガイド

  • しょうがなくJVMを使う必要に迫られたRubyist(Groovyと競合しない)
  • Java APIもJVMも大好きだけど、Javaの文法だけは嫌い(Groovyと強豪する)
  • RubyのライブラリをJVM上で使いたいだけの人(Groovyと競合しない)

Groovyはどう役立つのか

主な用途

  1. DSLを実装するための言語(Grails Gradle Spock)
  2. Javaスクリプティング(Javaプログラマの日々のしごとをGroovyで)

DSL実装用語としてのGroovy

  • Spock(テストコード用)

qiita.com

  • Grails など

Why Groovy DSL?

  • Groovy Java開発者向けのDSLに最適
  • Groovyのシンタックスやセマンティクスが優れている必要はない
  • Java開発者にとって素直にわかればよく、意表をつく何かがない方が良い

動的型とDSL

  • 本質的に動的な対象のDSLモデリングには動的型が自然な記述に寄与(JSONを対象とした処理が出来る)

Why DSL?

なんでDSL使うの?

  • ドメインモデルを書き下すときに既存言語の文法や実装都合の範囲内でクラス名とか工夫する
  • 実装都合を受け入れるのではなく、あるべき記法を追求する

  • 日本語DSLもGroovyで書ける

uehaj.hatenablog.com

  • もともとGroovyにはない、Haskellでいうところのリスト内包表記をGroovyで実現する

uehaj.hatenablog.com

  • 型クラスもどきをGroovyで無理やりやってみる

github.com

(Scalaっぽいけど、こういうことも出来る)

  • LispBuilder

uehaj.hatenablog.com

いくつかのツールが作られ、便利に使われている。

リアルワールドGroovy/Grails

  • Androidの標準ビルドシステム

Gradle 日本語ドキュメント

  • Netfilxでの大規模で多彩な活用
  • 国内最大級のオンラインマガジンサービスはGrails
  • AndroidはGroovyなのでNYTでも使われている

リアルワールドGrails

NTTソフトウェア株式会社でGrailsをWebアプリ開発の標準フレームワークとして使っている

Javaスクリプティング!

身近なスクリプティング

  • Java開発のお供に
  • GDKメソッド数をGroovyのドキュメントサイトからクラス別に集計する といったことも

今時のGroovy

  • Groovy2.3 2.4あたりでドラスティックな変更はない。

2.3

  • Traitの導入
  • マークアップテンプレートエンジン

2.4

  • Android対応

Trait

  • ScalaのTraitにごく近い
  • 状態が持てる
  • 動的トレイト注入
  • Grails3で積極的に活用されている

  • マークアップテンプレートエンジン

  • HTMLをGroovyプログラムとして書けるhamlっぽいテンプレート

まとめ

  • GroovyはJava開発者の能力を高めるツール
  • Javaスクリプティング
  • DSL ユビキタス言語
  • 対象領域の問題に対して、最小完全な記述を求めることが大事で、そのための記述を追求。
  • 自由度の高い記法を作れる!

better Java的なGroovy

  • GroovyはJavaのほぼ上位互換みたいなところがあるけど、ある段階まではJavaに追随できているけど、どんどん独自発展していっている感がある
  • 例えば、ラムダ式、デフォルトメソッドについては互換性がない
  • 互換性という点ではどんどん離れていっているだろうと思われる

盛り返すJava #渋谷JVM

d.hatena.ne.jp

Spring Framework + JSF + JPA

collection.line.me

それなりにハマる。

まだJavaで消耗してるの?

  • Java嫌いな俺かっこいい
  • Javaを批判するとプログラミングに造詣が深い気がする
  • Javaの文法を批判すると言語に造詣が深い気がする
  • 実際Javaが嫌い

そういう風潮あったよ

なんでJavaがいけてないのか

誰も教えてくれないJavaの世界

  • クライアント→Web業務→ネットサービス…
  • 黎明期(-2000)→黄金期(-2005)→停滞期(-2010)→再生期(-2015)

  • 適切に機能が更新されていないから

  • 適切に予算が投入されていない
  • 適切にマネジメントされていない

オラクル

  • おかねもち
  • 淡々とマネジメント
  • OracleにとってJavaはわりとどうでもよく、Javaが消滅してもそんなにダメージがなかったりするし、逆にJavaでうまくやっても株価が上がるわけでもない。故に淡々とやるべきことをやっているイメージだし、逆に派手な機能も入っていない。

JLUG CCC

  • 参加者が伸びている(2013春で280人だったのが2015春で666人)

TIOBE一位返り咲き

www.tiobe.com

ラムダ!

  • 実装すべきメソッドがひとつのインターフェース
  • Runnable run()
  • ActionListener actionPerformed(ActoinEvent)

Javaラムダ式メモ(Hishidama's Java8 Lambda Expression Memo)

匿名クラスのシンタックスシュガー?

シンタックスシュガーではない。

  • thisの扱いが違う
  • ラムダの外側のオブジェクトを示す
  • 匿名クラスの場合は匿名クラス自身を示す

  • ラムダをコンパイルしても余分なクラスはできていない。

  • バイトコードを読んで見ると、InvokeDynamicが最初に使われている。
  • で、クラスができていない。

なぜ匿名クラスじゃないのか

  • 匿名クラスだとクラスができまくる
  • しかもあまり使われないクラスが生成される
  • 起動時にクラスロードに時間がかかる可能性がある
  • いちいちコンストラクタを呼び出してオブジェクト生成する(いちいちnewするからリソースが無駄になってしまう)

Java SE 7 で導入されたInvokeDynamic

  • もともとは動的型言語のため(実行時にもJavaVMが使えるように Cと変わらない速さで動く)
  • 実行時にメソッドの型を決めつつJava VMの最適化もかけやすくなる
  • invokedynamic命令

  • ラムダオブジェクトの生成

  • 関数型インタフェースを実装したクラスのインスタンスを生成するメソッドが返される
  • VMが変わるとより最適化されたインスタンスが生成された可能性

くわしくはこちらから。

www.slideshare.net

Javaの欠点

  • 基本型の参照型の非互換性
  • ラムダが入っていても記述がダサい

基本型の参照型の非互換性

  • StringとIntStream
  • OptionalとOptionalInt(命名規則がよくわからない)
  • 用意された関数型インタフェース

関数型インタフェースについてはこちらを参照。 d.hatena.ne.jp

  • 記述がダサい(Optionalとか長い) シンタックスシュガーを導入してしまうにはOptionalというオブジェクトを毎回使うのは実行時コストが高い
  • 小さいノードで動かすプログラムが増えていくなかでOptional使うのは面倒だし、オブジェクトを使わないと実行出来ないのも面倒(BigDecimalとか)

Project Valhalla

OpenJDK: Valhalla

d.hatena.ne.jp

  • Specialization ArrayList
  • Genericsの型指定に基本型を指定可能とする

d.hatena.ne.jp

  • ジェネリクス
  • any T
  • 配列の生成が出来る
  • nullと比較できない
  • Objectとの変換ができない
  • synchronizedできない
  • キャストの制約

anyTの問題点

  • nullどうしよう
  • オーバーロード
  • void remove(T)
  • void remove(int)

Specializedされたクラスをいつつくるか

  • コンパイル時にはつくらない
  • ClassDynamicを導入したらどうか
  • 動的なクラスリンク
  • InvokeDynamicのクラス版

Value Type

valhallaで追加された機能。

value class Point {
  int x;
  int y;
}
  • 参照ではない
  • メモリに直接配置される
  • 効率がいい
  • 現在のクラスと互換性が保てればOptionalシンタックスシュガーの導入も可能。

case classは22個までしかメソッドは用意できない

value typeはJava10(3年後)に入る予定。。

ほかの言語は?

  • Scala
  • Don Giovanni(ググラビリティ低すぎだろ)

まとめ

  • そろそろJava見なおしてもいいと思う

Project Valhallaについて

d.hatena.ne.jp

パネルディスカッション #渋谷JVM

  • Groovy
  • Java
  • Scala
  • Clojure

JVMでよかったこと

  • G すべてがリファレンス 素直なシンプルな世界 gcがよい
  • J LINEという会社に就職 不満なところはC#に対しても劣る部分があること
  • S Javaのライブラリを使えるのはよいところ
  • C Rubyだとバージョン互換性が低い Javaだと環境が作りやすい

JVMでつらいところ

  • G 現状維持したいひとがおおい(Java)
  • J ネイティブとの接続がよわい
  • S JVMにたいしては特にない ロングタームのサポートがよわい
  • C 起動の遅さが不満

  • JVMが発展すれば、他の言語も発展していく

他の言語でいつどこで知りましたか

  • C ClojureとJavaしか知らない Scalaは待ち時間が嫌
  • S コーディング能力がついていけないのでScalaくらいの待ち時間のほうがよい
  • J ハードウェアのコンパイルをしたほうがいいと思う
  • G Scalaはあまり記憶ないけど面白そうだ的な Haskellつまみぐいしてたりしていた

他の言語に負けないところ

  • C イミュータブルで選択の余地がないからコーディング規約が不要
  • S コンパイルの長いからちゃんと考えてコードを書くクセがつく 無理に関数型を押し付けない
  • J 継続性(よくもわるくも)
  • G 拡張子の長さ GroovyはJavaに対するサブウェポン

コンパイラについて

  • G ClojureほどではないにしてもGroovyは手軽
  • J 処理系はとても複雑なので、自分でいじろうとかそういう気にはならない(でも自分の処理系は作りたい)
  • S Scalaのコンパイラも割と複雑。でもマクロを使えば拡張は簡単なのでやりたいことはできている
  • C あまり興味がなくって、Clojurescriptは謎のコンパイラなのでどうにかしたい

Java10

  • C プラットフォームの上にのっかる
  • S Javaがよくなっていくのはよいこと
  • J パイが増えるからいいんじゃないでしょうか
  • G 最終的にGroovyのすべてをJavaが吸収することはなかろう

渋谷JVMに参加しました。LTしました。 #渋谷JVM

概要

本日、株式会社ビズリーチ様主催の渋谷JVMに行ってきました。そして、LTをやりました。場所はビズリーチ様のオフィスでございます。勉強会と発表の場をご提供くださったビズリーチ様に深く感謝いたします。

d-cube.connpass.com

いつものことですが、無論、発表内容はブログにまとめております。一部の発表はSlideshareなどにアップロードされておりますので、そちらもご覧ください。

shigemk2.hatenablog.com

shigemk2.hatenablog.com

shigemk2.hatenablog.com

shigemk2.hatenablog.com

shigemk2.hatenablog.com

僕のLTの内容はこちらとなります。

shigemk2.github.io

内容としては、こちらのQiita記事の紹介となっております。

qiita.com

参加の経緯

JVM自体は、仕事でScalaのプロダクトに携わっていることと、以前Javaのクラスファイルの勉強会に参加したことから、自分の中でなんとなくの関連性がありました。ので、JVMという言葉に釣られて参加しようと思ったのですが、勉強会の中身を見てみると、テーマはJVMそのものやクラスファイルあたりの低レイヤーなものではなく、JVM上で動く言語についての勉強会のようでした。

Scalaの話が出てくるようなので、参加しようと思ったのですが、参加ボタンをクリックしようとした時点で既にキャンセル待ちの状態で、LT枠を見てみるとまだ枠があるので、LT枠で参加しようと思った次第です。

参加枠がないから発表枠で参加しよう!というのは、なんかたまにやるメソッドなのでそんなに抵抗感はないのですが、JVM言語というScala以外にはほとんど馴染のない言語そのものがテーマの勉強会だったので、大丈夫かなっていう感じはしていました。

感想

Scalaについて

他の言語のことはあまり良くわからないのでScalaについての感想ですが、竹添さんの仰るとおりだと思います。異論はありません。

オダスキー先生が志向されているように、Scalaは関数型言語っぽくも書けて、オブジェクト指向っぽくも書けて、Javaっぽくも書けるようになっているハイブリッドで実践的な言語で、(軽量言語とは別の意味で)間口の広い言語なのだと実感しております。

LTについて

ここで発表者たる僕の身の上話をしますが、僕は大学を卒業するまではプログラミングはほとんどやったことがありません。大学を卒業してからプログラミングを始めたクチです。

現職はScalaですが、それまではPHP Ruby JavaScript Pythonといわゆる軽量言語を中心に仕事をしておりました。なので、大学を卒業してから今まで関数型言語はおろかコンパイル言語さえ触ったことがない状態でした。

LTではそういう経緯を交えつつ、Scalaの関数型言語っぽい機能をHaskellから移植した話をしました。で、マサカリをくださいで〆たところ、それまでの発表ではあんまり質問が飛んでこなかったのに僕のところにどんどんマサカリが飛んできたのでした。これはちょっと謎です。

これについては懇親会でも@kamekoopaさんとちょっと話をしましたが、Scalaは通常はJavaの人がbetter Java的に始めるパターンが多くて、僕みたいにほとんど全くJavaを経由せずに軽量言語からいきなり関数型言語をかじってScalaを始める人は結構レアらしいです。

そういうのがあるので、たぶん色々マサカリが来たのだと思います。質問内容は、Scalaで可変長引数は出来るのか、PHPer視点から見るPHPとJavaの文法上の類似点、Scalaのカリー化は厳密にはカリー化じゃないといったご指摘をいただきました。ありがとうございます。

あと件のQiita記事についてですが、再帰でごにょごにょするとスタックオーバーフローになるので、末尾再帰でやったほうがよい、というご指摘をいただきました。これにつきましては、そもそも再帰にあまり馴染のない人間にとってはいきなり末尾再帰では難易度が高すぎるのではないかと思っております。

考えてみると、Javaの人がかなり多いところにいきなりJavaの人ではない人間が突然カチコミをかけたような感じなので、いささか勉強不足かつ準備不足な感じが否めませんでした。

そういったマサカリに対し、いかに精神的なダメージを少なくしつつ自分の技術的な成長につなげることが出来るかが、今後の鍵になるのではないかと痛感しております。

最後に

重ねて申し上げますが、株式会社ビズリーチ様と、Haskellラムダ超入門の作者 id:7shi さんに深く感謝いたします。ありがとうございました。