Scalaの学習コストについての私見 - kmizuの日記
※2022/01/25 17:10追記 以下のツイートが別に「Scalaが主眼でない」こと自体は承知しています。一般論として、Scalaに限らず言える技術選定の話ですよね。ただ、妙な方向への読解をちょくちょく見かけたので、それに乗っかる形で現状のScalaについて率直な感想を書いておこうと思ったのでした。「この話とは別なんだけど」みたいな言葉をつけておけば良かったです。申し訳ありません。 数日前、以下のツイートに端を発して色々な意見が交わされていました。 「Scala好きなメンバーがプロダクト開発にScalaを採用して1人で開発していたが、そのメンバーが抜けてしまいScalaコードの保守ができなくて別の言語で書き直すことになった」という技術選定の失敗のお手本のような事例を目の当たりにしてしまった....— コミさん (@komi_edtr_1230) 2022年1月19日 これを見て「いや
実践Scala入門（共著）が発売されます - kmizuの日記
https://www.amazon.co.jp/dp/4297101416 企画自体は2015年くらいから始まっていたんですが、紆余曲折あって、約3年経ってしまいました。ともあれ、ようやく出版までこぎつけられてほっと一息です。 実際には多少遅れる可能性がありますが、10月27日から技術評論社さんから発売予定なので、この機会にScalaを勉強してみたい方は、是非予約していただければと思います。 さて、書いてる間の紆余曲折書いても意味がないので、このエントリでは、この書籍のウリを簡単に書きたいと思います。 現状の日本語のScala書籍は、大半が新しいバージョンのScalaに追随できてなくて、新しくScalaに入門する人に勧められるいい書籍が ほとんどないという問題意識がありました。いわゆるコップ本はScala書籍の中でもかなり売れていることもあってか、2.12対応の第三版まで出版されているも
Re: Go にジェネリクスがなくても構わない人たちに対する批判について - kmizuの日記
先日自分がGoについてつぶやいたものが、id:methaneさんに捕捉されていて、それに対する反論記事 methane.hatenablog.jp があがっていたので、それに対する所感を書いてみました。（2017/09/22 追記）：cocoatomoさんから指摘があったのですが、引用元は全て id:methane さんの、上記ブログエントリの文章です。雑多な感想に関して反応しているものではないです。 前置き Goや言語批判に関するスタンスを誤解されると嬉しくないので、最初に書いておきます。 Goの言語仕様はあまり好きではないけど、Goユーザーを見下したり、馬鹿だとかそういう風には思っていない 言語仕様批判とユーザー批判は別の話ですが、しばしばいっしょくたにされて、糞言語Xを使うユーザは糞だ、みたいな主張がされることがあるので、 そういう意図はないという表明です。 Goユーザーの中で、ジェ
型クラスの真の力を見せる - kmizuの日記
昨日、 kmizu.hatenablog.com という記事を書いたわけだが、その後、今日、型クラスに関する議論が一部で（？）盛り上がっているようだ。それは型クラスじゃなくても実現できるのでは、いや、やっぱりインタフェースのようなものと思っていいのでは、などなど。 今回の記事では、型クラスじゃないと実現が著しく困難であると思われる 使い方について書くことにする。 まず、前の記事では、Orderingの使い方を通して、型クラスの単純な使い方について説明したのであった。単純なオブジェクトの場合はそれでもいいが、より複雑なオブジェクトをOrderingを使ってソートしたい場合、前回の記事のようなやり方だけでは難しいことがある。 一例として、(A, B)というタプル型、つまり、A型の要素とB型の要素からなるペアを比較して、ソートしたいという要求を考える（実際には、標準ライブラリでタプル型の比較が提
型クラスをOrderingを用いて説明してみる - kmizuの日記
ちょっと今日は疲れてるので、表題の件について、簡単に書いてみる。私の経験上、型クラスにおける、最も多い誤解は、(Javaとかにおける）インタフェースのようなもの、というもので、これはかなり多くの人にみられるように思う。 まず、そもそも、何故そういう勘違いが生まれたかを考えてみると、「インスタンス」「メソッド」といったオブジェクト指向言語にもある用語が使われていること、また、両者とも「操作の集合を提供する」という特徴があるためではないかと思う。しかし、根本的な違いがある。一番大きなものは、型クラスは（一般的には）レシーバ（thisといってもselfといってもなんでもいいが）とそれに付随する状態が基本的に存在しない、という点だ。 この点について、Scalaの標準ライブラリにおいて、両者の違いを説明するのに格好の例がある。OrderingとOrderedだ。混乱を避けるために先に説明しておくと、
Rubyっぽく楽にIO処理を書けるライブラリScaruby 0.3をリリースしました - kmizuの日記
Scalaは標準IOライブラリが非常に貧弱な言語です。scala.ioはまともに使えるものではありませんし、JDKのライブラリのIOを使うのも面倒です。そこで、サードパーティのIOライブラリを使うことになります。そこで、いくつかサードパーティのIOライブラリを見てみたところ、いずれも自分のやりたいことをぱっとできるように思えなかったので、自分で作ってみることにしました。 なお、better-filesは、自分の要求に一番近かったですが、java.ioやjava.nioがインタフェース部に露出しているのがあまり好みではありませんでした。 そこで、 java.ioがインタフェースに露出しない Rubyのように簡単なIO処理が簡単に書ける リソースの後始末は可能な限り簡単に 多数のリソースをネストせずに扱える オーバーロードをしない（！） を目標として、新しいライブラリScarubyの開発を始め
Scalaでimplicits呼ぶなキャンペーン - kmizuの日記
はじめのはじめに implicitsは可読性が…という人が居たら、この記事へのリンクを教えてあげていただければと思います TL;DR Scalaには俗に「implicits」と呼ばれる機能がある 実際にはそれらは３つの機能をまとめて指す用語である それぞれの機能は全く異なる 暗黙の型変換は現代では無視してよし 拡張メソッドは、既存の言語でそれを持つのと同じ程度の簡単さである 型クラスとしての用法は、型クラスがある言語を知らないとやや難しいが、積極的に使う価値がある機能である 「implicits」は異なる３つの機能を一つにまとめた呼び方に過ぎず混乱を招くので、使うのをやめよう（個々の機能名で呼ぼう）。また、暗黙の型変換は無視して良いし、拡張メソッドはよく知られているので、型クラスとしての用法にフォーカスして良い はじめに Scalaには俗にimplicitsと呼ばれる機能（群）があります。
Scalaに関する誤解と事実を語る - kmizuの日記
TL;DR 世間のScalaに関するイメージは、昔のままであることが多い 昔のままどころか、最初から間違ったイメージを持たれていることも多い 実際には、既に解決されている問題は多々あるし、改善に向かっていることも多い プロジェクト管理の問題を言語に押し付けているケースもある はじめに 自分が最初にScalaに触れたのが2005年（Scala 1からカウントした場合）、あるいは2007年（Scala 2以降からカウントした場合）と、Scalaとの付き合いも結構長くなってきましたが、その間に Typesafe社（現Lightbend社）の設立 実質標準ビルドツールとしてのsbtの確立 ライブラリのバイナリ後方互換性に関するポリシーの策定 公式ScalaイベントScala Daysのはじまり Play 2 Frameworkの登場 Scala Center発足 その他色々 がありました。この間、
TwitterはScalaを捨ててません（少なくとも現在は） - kmizuの日記
なんだか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."— 水島宏太（ゆる糖質制
Scalaアンチパターン：変更可能コレクションをvarとして宣言する - kmizuの日記
Scalaは最初から関数型プログラミングのスタイルで書くことを意識して設計されたという意味で関数型プログラミング言語と言えますが、一方で、「Better Java」な手続き型スタイルで書くことも基本的には否定されるべきではないと思います。たとえば、ビッグデータ関係のソフトウェアとして有名なApache SparkはScalaで書かれていますが、（おそらく）パフォーマンス上の理由のため、手続き型のスタイルで書かれている部分がかなり多いです。 さて、それはいいのですが、そういう「Better Java」なScalaコードによく見られるパターンに、変更可能コレクションを使っているのに、そのコレクションを格納する変数をvarとして宣言しているものが（割と有名なソフトウェアでさえ）あります。ですが、そういうコードは 書いてはいけません（かなり例外的な場合を除いて）。 「書いてはいけません」というのは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
