結論は同意できても途中の論理展開がおかしい記事の話 - kmizuの日記
おはようございます。朝から非常に微妙な気持ちになる記事を見てしまったので、ちょっとそれについて書いてみたいと思います。対象は、 toyokeizai.net というとても残念な記事です。本題に入る前に常日頃から思うのですが、結論自体は著者と別の理路から同意できなくもないが、途中の論理展開が破綻してる記事って多過ぎません？あくまで感覚ですが、ネットの一応まともな出版社の記事でも、1/10くらいの確率で誇張でなくそういう残念な記事に出会ってしまう気がします。今回の記事もそのような残念な記事の一つです。 さて、この記事の主題は、昨今蔓延している古文不要論へのカウンターパートとして、 「現代の文章や言葉を理解するために、古文を勉強する必要がある」（原文より引用） ということにあります。筆者の気持ちはわかります。私自身、古文が全く役に立たないとは思っていないし、実際問題として、古文だけでなく歴史など
ChatGPTで日本語プログラミング（本当）をやってみた - kmizuの日記
さて、相変わらずChatGPTにハマっておりますが、ふと思いついたアイデアがあります。どうも、ChatGPT君はプログラミング言語「そのもの」の普遍的な理解があるのではと思えてきたので、それを考えると自然言語をプログラムとして解釈させることも可能な気がしてきたのですよね。というわけで、以下がスクショです。階乗を計算させるのが目的ですが、階乗と書くと空気読まれそうなので「ほげ数」にしてあります。 なんか「どのプログラミング言語で解釈すればいいかわからないタスク」についてはどうもPythonに内部的に変換して解釈してる節があります。ともあれ、再帰を含む日本語疑似コード（表記ゆれあり）をそのまま解釈できるのは凄いですね。 不完全ですが対話ログを gist に保存しておきました。回答はプロンプトごとに微妙に違うものが返ってくる可能性があるのでご注意をば。
ChatGPTはプログラミング言語マスター（語弊ありまくり） - kmizuの日記
皆さんおはようございます。見ている人は見ていたかもしれませんが、昨夜はかなり遅くまで巷で話題沸騰のChatGPTによくわからんクエリを投げて、その結果をみてげらげら笑っていました。特に存在しないプログラミング言語であり「ScalaにHaskellと同じ型推論を加えた」言語Scalayがあることにしたら、ChatGPTが本当にHaskellぽい（単なるHMでなく、Haskellぽいというのは型クラスまで推論される辺り）型推論を持つ架空のScalayコードを解釈実行してくれたりしたところは、控えめに言っても予想外の結果で深夜なのに部屋で忍び笑いをしていました。 Scalaに引数の型推論を追加したようなパチもんのプログラミング言語Scalay（仮）ができてしまった（ChatGPTと対話してる間だけの短い命）。 一応、add: (Int, Int) => Int が推論されてるのすばらですね。 p
動的型付き言語は素早くプロジェクトを立ち上げるのに向いており、静的型付き言語は長期間の保守にむいているという仮説 - kmizuの日記
注：誤解されないように最初にこの記事の意図を書いておくと、古典的な静的型付き言語VS.動的型付き言語の論争をするつもりはありません。これまで色々なプロジェクトを観察（風聞も含む）して来たところ、そういう傾向があるのではないかという仮説です。それと、文脈として主にWebアプリケーション開発する時のことを想定しており、それ以外のケースはいったん脇に置いています。WebアプリケーションだとPHP（動的型付き言語）の方が圧倒的に事例多いのではという感想もありそうですが、その辺りを考え出すと話がこんがらがるので、これもいったん脇においています。 たとえば、色々な事例を見聞きするに、スタートアップ企業において動的型付き言語であるRubyのWebアプリケーションフレームワークであるRuby on Rails（RoR）は好まれる傾向にあります。近年のPythonの動向はさておき、未だにRoRの求人がかなり
Qiita記事「エンジニアの"有害な振る舞い"への対処法」への強烈な違和感 - kmizuの日記
最近、Qiitaで話題になってそこそこバズった（？）記事に、 qiita.com がありました。これ、最初は一読して凄いまともなことばかり書いているように見えましたが、一方で何か妙な違和感がありました。それは、私がいくつかの振る舞いについて思い当たりがあるせいではないか？と考えてみましたが、反省するところがあるなと思いつつも、何かが変だと感じていました。今朝、違和感の理由がわかった気がするので、書いておきたいと思います。 一番大きな問題は、「有害な振る舞い」といいながら、客観的に観察できる行為ではなく、主観的に行為の意図を勘繰っていることです。 そもそも、著者様は 私個人の経験に基づくため定性的かつ主観的な意見にはなりますが、メガベンチャーにて8年間様々なチームメンバと開発業務に携わりながらスクラム開発の各役割を1年ずつ、それからミドルマネージャーを2年経験し、さ> らに周辺チームや他部署
Kotlinのコレクションは「不変」と「可変」に分かれていない - kmizuの日記
Kotlinのコレクションライブラリに関する解説として、よく、 Kotlinのコレクションは不変と可変に分かれていて〜 といった形のものを見かけます。そして、その例として、 val list: List<Int> = listOf(1, 2, 3) list.add(4) // コンパイルエラー のようなコードが挙げられていたりします（このような解説を結構見かけるということで、特定の誰かを想定しているわけではありません）。しかし、これは誤りです。以下のコードを実行することで、Kotlinのコレクションの、一見「不変」っぽい型は単に「読み取り専用」の型でしかないことがわかります。 val list1: MutableList<Int> = mutableListOf(1, 2, 3) val list2: List<Int> = list1 list1[0] = 4 println(list
Javaのジェネリクスは「まがい物」ではない - kmizuの日記
先日、自分が書いた kmizu.hatenablog.com に対する反応として、「Javaのようなまがい物のジェネリクスと比較するのは適切でない」「Javaのジェネリクスと比較するのは適切でない」（おそらくC#や(C++等（2017/09/24追記）)の言語と比較して）といった コメントをいくつか見かけました（はてなブックマークコメントやツイッターなどで）。しかし、ここでは、そのような言説こそが適切でない、ということを言いたいです。なお、methane氏との 対話については既に終わったものなので、それとは関係ありません。 そもそも、Javaジェネリクスは、静的型付き関数型言語で既に一般的であったパラメータ多相をJavaに追加する目的で導入されました（C++テンプレートのようなものをJavaに追加するためだと思っている人がいるかもしれませんが、それは実態にあっていません）。実際、Java
技術イベント「Understanding Scala」を開催しました（6/10） - kmizuの日記
Understanding Scala - connpass 昨日、表題の技術イベントを自分主催で行いました。なんでこんなイベントをやろうと思ったかというと「皆、Scalaを難しくめんどくさい方法で学んでるのでは？」という疑問が自分の中であって、その原因として、サンプルプログラムの集合を通して、ボトムアップになんとなくイメージで 全体像を作りあげてるのではという思いがありました。 そのようなアプローチに対して懐疑的な自分としては、このイベントでは（厳密にはやってませんが）どちらかというとトップダウン的アプローチでプログラミング言語について理解してもらおうと思い（もちろん、例は大切なので必要に応じて詳細に下りるのは忘れませんでしたが）、５つの発表の全てを全部自分でやりました。さすがに、５時間程度しゃべりっぱなしというのは疲れましたが、おかげさまで（？）、色々な疑問が解決したとか、メソッドと関
型クラスの真の力を見せる - kmizuの日記
昨日、 kmizu.hatenablog.com という記事を書いたわけだが、その後、今日、型クラスに関する議論が一部で（？）盛り上がっているようだ。それは型クラスじゃなくても実現できるのでは、いや、やっぱりインタフェースのようなものと思っていいのでは、などなど。 今回の記事では、型クラスじゃないと実現が著しく困難であると思われる 使い方について書くことにする。 まず、前の記事では、Orderingの使い方を通して、型クラスの単純な使い方について説明したのであった。単純なオブジェクトの場合はそれでもいいが、より複雑なオブジェクトをOrderingを使ってソートしたい場合、前回の記事のようなやり方だけでは難しいことがある。 一例として、(A, B)というタプル型、つまり、A型の要素とB型の要素からなるペアを比較して、ソートしたいという要求を考える（実際には、標準ライブラリでタプル型の比較が提
型クラスをOrderingを用いて説明してみる - kmizuの日記
ちょっと今日は疲れてるので、表題の件について、簡単に書いてみる。私の経験上、型クラスにおける、最も多い誤解は、(Javaとかにおける）インタフェースのようなもの、というもので、これはかなり多くの人にみられるように思う。 まず、そもそも、何故そういう勘違いが生まれたかを考えてみると、「インスタンス」「メソッド」といったオブジェクト指向言語にもある用語が使われていること、また、両者とも「操作の集合を提供する」という特徴があるためではないかと思う。しかし、根本的な違いがある。一番大きなものは、型クラスは（一般的には）レシーバ（thisといってもselfといってもなんでもいいが）とそれに付随する状態が基本的に存在しない、という点だ。 この点について、Scalaの標準ライブラリにおいて、両者の違いを説明するのに格好の例がある。OrderingとOrderedだ。混乱を避けるために先に説明しておくと、
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発足 その他色々 がありました。この間、
Scalaの学習コストを下げるための心得 - kmizuの日記
追記：Twitterで、「それって、言語マニアにしかできない技のような気が」という指摘を受けました。自分としては一般的に適用可能な話だと思っていますが、あるいは自分の感性が著しくずれているのかもしれません。その辺承知の上でお読みください。 Scalaは習得が難しい言語だ、とよく言われます。また、実際問題として、Scalaの言語仕様の全体はそれなりに複雑でもあります。しかし、それはたとえばJavaでも言語仕様の全体像を把握するのは難しい話であり、Scalaに限った話ではありません。にも関わらず、Scalaの習得が難しいとよく言われるのはプログラミング言語の学習モデルが誤っているからではないかと最近思うようになりました。そこで、Scala（や他の言語も含めて）のコストを下げるために必要な心得についてちょっと書いてみます。 Scalaはオブジェクト指向言語である これは、Scalaは関数型プログ
Scalaアンチパターン：変更可能コレクションをvarとして宣言する - kmizuの日記
Scalaは最初から関数型プログラミングのスタイルで書くことを意識して設計されたという意味で関数型プログラミング言語と言えますが、一方で、「Better Java」な手続き型スタイルで書くことも基本的には否定されるべきではないと思います。たとえば、ビッグデータ関係のソフトウェアとして有名なApache SparkはScalaで書かれていますが、（おそらく）パフォーマンス上の理由のため、手続き型のスタイルで書かれている部分がかなり多いです。 さて、それはいいのですが、そういう「Better Java」なScalaコードによく見られるパターンに、変更可能コレクションを使っているのに、そのコレクションを格納する変数をvarとして宣言しているものが（割と有名なソフトウェアでさえ）あります。ですが、そういうコードは 書いてはいけません（かなり例外的な場合を除いて）。 「書いてはいけません」というのは
ScalaとKotlin（と昔のJava）のジェネリクスが壊れている理由 - kmizuの日記
表題の通りです。とりあえず、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)というメソッドが 定義されている
お役立ち中置パターン in Scala - kmizuの日記
Scalaには中置パターン（infix pattern）と呼ばれる機能があります。これは単純にいうと、 case class ~[A, B](a: A, b: B) のようにして定義したケースクラスに対して*1、 scala> val ab = new ~(1, "FOO") ab: ~[Int,String] = ~(1,FOO) scala> val a ~ b = ab a: Int = 1 b: String = FOO このようにパターン名を中置（infix）にして書くことができる機能です。この機能、一見使い道が少なそうですが、実は皆さん、日頃からよく使われています。 まず、 list match { case x::y::xs => ... } のように、リストを::を使ったパターンマッチで分解することはよくあると思いますが、これは、::という中置パターンがあればこそできる書き
Scalaのメソッドや関数に関するQ&A - kmizuの日記
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
Scala doesn't Need Generics! (or You can Encode Generics Using Abstract Type Members) - kmizuの日記
タイトルは煽りではありません。もちろん、Scalaを実用的に使う上では「直接」Genericsを扱えないのは困ります。しかし、記述の冗長ささえ我慢すればGenericsのほぼ全ての機能をAbstract Type Membersによって表現できます。このことを指して、GenericsはAbstract Type Membersでエンコードできると言ったりします。とりあえずコード出せやといわれそうなので、実際のコードを貼りつけてみます。 gist.github.com このコードでは、不変Listと、その上の高階関数mapとforeachをGenericsなしで構築しています。 ポイント： Genericな型 => Abstract Type Memberを持った型 Genericなメソッド => Abstract Type Memberとメソッドを持った型 関数 => Abstract T
ScalaでMLスタイルのモジュールを使ったプログラミングをする - kmizuの日記
何はともあれ以下のコードを見てください(ちなみに複素数クラスの実装は、 d.hatena.ne.jp を参考にさせていただきました）： trait Complex { type T def re(a: T): Double def im(a: T): Double def make(re: Double): T def plus(a: T, b: T): T def minus(a: T, b: T): T def multiply(a: T, b: T): T def divide(a: T, b: T): T } object Complex extends Complex { case class C(re: Double, im: Double) type T = C def re(a: T): Double = a.re def im(a: T): Double = a.im d
『Scalaファンクショナルデザイン ―関数型プログラミングの設計と理解』の雑感 - kmizuの日記
表題の書籍について、出たとき（2015/5/29）に買って随分放置していたのだが、最近、一通り読んでみたので簡単な感想を書いてみようと思う。 結論からいうと、Scalaについて特に使う予定はないがおおまかにどんな言語か知っておきたいという方にはそこまで悪くない本だが、副題の「関数型プログラミングの設計と理解」について本書で学ぶのはオススメできない。そういう人には、Scala関数型デザイン&プログラミング ―Scalazコントリビューターによる関数型徹底ガイドをオススメしておこう。こっちの本も、ScalaでHaskellスタイルのFPをすることにこだわり過ぎて、Scala Wayからは外れていると感じる部分もあるのだが、少なくとも関数型プログラミングについて丁寧に取り組んでいるとはいえる。 本書を読む前に気になっていたのは、技術的な点での瑕疵がどの程度あるかということだったが、この点に関して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
