代数データ型の直積型と直和型の理解

代数データ型という考え方があって、型に対する代数的な操作を行うものっぽいです。代数的な操作というのは、足し算とか掛け算ですね。直和型と直積型というのがあります。

直積型は構造体のようなもので、Javaだとrecordが導入されましたね。

record A(int p1, boolean p2) {}

みたいなものです。
これがなぜ積なのかというと、このレコードAの取りうる値の組み合わせは、intの値のパターン数(2 ^ 32) × booleanの値のパターン数(2)で2 ^ 33になるからなんだと思います。

直和型は、型がこれかこれ、みたいになるやつです。Javaだとtry-catchのcatch句に直和型が指定できて、この例外かこの例外、みたいな書き方ができますね。

catch (NullPointerException | NumberFormatException ex) 

あとsealed classが導入されたので同じようなことができます。

sealed interface B permits C, D {
}
record C(int n) implements B{}
record D(boolean f) implements B{}

こうすると、型Bは型Cか型Dの値を扱えることになります。このとき、型Bの取りうる値の組み合わせは、型Cの取りうる値の組み合わせ(2 ^ 32)と型Dの取りうる値の組み合わせ(2)を足したものになって2 ^ 32 + 2になります。*1
なので直和型ですね。

ということを忘れないようにメモ

*1:Javaの場合、nullも扱えるので2 ^ 32 + 2 + 1になりますね。滅ぼすべき

基礎と低レイヤーは混同しがち。基礎とは何で、どう勉強するか。

基礎と低レイヤーは混同しがちという現象をみかけたのでメモ

よくあるのが、「IDEを使うと基礎が勉強できない、メモ帳でコードを書いてコマンドラインでjavac / javaするところから始めるべき」みたいな話。
ツールを使わずツールが隠してる部分を自分でやって勉強せよ、フレームワークを使わずフレームワークが隠してる部分を自分でやって勉強せよ、という話は、これ自体は間違いではないのだけど、これを「基礎」と言ってしまうと違った方向に行ってしまう。

これは基礎ではなくて低レイヤーではなかろうか。

そして、低レイヤーは「ツールを使わずにやれ」と言ってる人の想定する「ツールを使わず」というのもすでにツールを使っていたりする。ほんとに低レイヤー知りたいなら、javac使わずハンドコンパイルでしょう。Javaバイトコード知っておくべきでしょう。 と、だんだんマニアックなこと知ってる自慢になっていく。 こういうのは、知っておくほうがもちろんいいんだけど、それを勉強するのはある程度わかってからでよくて、最初にやることではないと思う。

じゃあ、基礎はなんなのかというのをちょっと考えてみた。 基礎というのは、楽器演奏ならスケールだったり、絵であれば球とか立方体のデッサンだったり、プログラミングなら条件分岐とループでロジックを書くことだったり、アプリケーションつくるなら入力を受け取って加工して表示とか保存とか。

つまり、基礎というのは、単純で退屈だけどこのパターンは必ず出てくるな、というものではないかと。
そういったパターンをまとめて共通部分を抜き出して抽象化したものは、より強い基礎になる。けど難しい。
なのでまずは具体的なパターンをいくつかやってみて、なんだか共通部分があるなと気づいたくらいで抽象的に考えるという具合に勉強を進めるのがいいのだと思う。

一方で低レイヤーは、細かくてめんどくさくて裏側こうなってたのかーというやつ。
これは勉強したほうがいいのだけど、やりたいことの実現が何に支えられているかという話で、やりたいことをいかに実現するかというのとは別。
楽器演奏なら楽器の仕組みだったり絵であれば画材の特性とか人体解剖図とか、プログラミングならライブラリの実装やアセンブラやCPUとか。

基礎の勉強として、もしかしたら何にでも通用するかもしれない注意点を思いついた。
「最後までやる」ということ。
基礎の教科書を最後までやるという話ではなくて、絵であれば球を書き始めるのであれば途中で失敗したとしても書き上げる、スケールも途中で音をはずしても最後のドまでとりあえずやる、ロジックを組むなら正しい処理がわからなくてもとりあえず結果が出るところまでは組む。簡単なアプリケーションを作るならアプリケーションとして成り立つところまで作る。

サッカーで、試合形式での攻撃の練習は必ずシュートで終われみたいな話があって、それは途中でどんなにうまくパスまわしできてもシュートにつながらないなら意味がないしゴール前までボールをあげれてもシュートする人が走りこんでないならただのバクチだし、守備がうまくてパス回しをさせられたボールを蹴らされたというのがあるかもしれない、みたいな話。
これが結局いろいろ通じて、楽器のスケール練習にしても途中までうまくできるんだけど詰まるのならうまくできてないし、うまくできなくても最後まで音をつなげるというのは大事。絵で、途中で失敗したと思っても書きあげたらつじつまがあうということもある。アプリケーションで、実装が簡単なところだけ作って途中で作業が進まなくなるなら、それは完成させない前提だから簡単だっただけということもある。

まあ、なんにせよ基礎はちくちくとやっていくと100日もやればなんなりか力になるし、やっていくといいんじゃなかろうか。

Javaで作るのは他人のためのプログラム、Pythonで作るのは自分のためのプログラム

JavaやCで組むのは他人のためのプログラムで、Pythonで組むのは自分のためのプログラム、という違いがないかなという話。

TIOBEでとうとうPythonが1位になったというニュースが流れてました。
https://internet.watch.impress.co.jp/docs/yajiuma/1357645.html

でも、Pythonが1位になったとはいえ、CやJavaであったような、世の中のプログラム全部Pythonになるみたいな雰囲気はないなと思いました。

で、こんなツイートをしたわけです。

Pythonの入門書で「ざっくりこういうことをするのにこのくらいのコードが必要というのがわかればいい」ということが書いてあって、Javaの入門書ではそうならないよなと思ったことがありました。
それで、そもそもJavaPythonでは勉強のモチベーションが違うということに気づきました。

Javaでプログラミングの勉強を始める人というのは、基本的に転職目的が多いと思います。この場合、プログラムを作る仕事をしたいわけで、そこで作ることになるのは他人のためのプログラムです。
一方でPythonでプログラミングを始める人は、手元の作業を効率化したり、手元のデータを分析したり、純粋にプログラミングの勉強だったり、自分のためのプログラムを作ることを目的としていることが多いと思います。

つまりはJavaPythonで作るプログラムが違うなと。

Javaでは他人のために、プログラマのいないところで動くプログラムを作ります。そうすると、正しく動くことを保証する必要性は高くなり、必要な機能をすべて実装する必要もあります。
一方でPythonでは自分のために、プログラマの目の前で動くプログラムを作ります。そうすると、正しく動かなかったらそのときにやりなおせばいいし、手早く動かせる必要があります。*1

C++を作ったBjarne StroustrupC++の静的型検査についてこういうことを書いてます。

タイプミスマッチの問題をコンパイル時に検出することが、なぜこれほどまでに重要なのか?・・・それは、C++のプログラムの多くが、プログラマのいないところで使われるからだ。
C++の設計と進化

ここではJavaの話ばかりを書きましたが、静的型をはじめ、プログラムが正しく動くことを保証する仕組みというのは、プログラマをはなれて動くプログラムだからこそ重要なのだなと思った話でした。

*1: 傾向の話であって、Javaでも自分のためのプログラム作るとか、Pythonでも他人のためのプログラム作るとか、そいういう話はここではしない

龍馬1865 - おいしいノンアルビール飲み比べ

龍馬1865
以前飲んだときの甘ったるさはなくなって、栗のような香ばしさがある
f:id:nowokay:20211009152201p:plain

日本ビールのノンアルビール です。 原材料は麦芽、ロースト麦芽、ホップと炭酸で、アルコール度数は0.000%
一本あたり112円。以前は一本あたり117円だったからちょっと安くなってる。

カチプラと同じかと思っていたのだけど、レビューみる限りカチプラのほうが少し薄いぽい。

https://nowokay.hatenablog.com/entry/2020/11/02/214730

MARUKU AF LAGER ~ ノンアルビール飲み比べ

MARUKUアルコールフリーラガーはノンアル通販サイトMARUKUのオリジナルビールです。
f:id:nowokay:20211004002626p:plain

中身としては、こちらで紹介した小樽ビールのノンアルと同じだと思います。

ただ、このときよりは甘さやコーン感は抑えられていて、少しクラフトビール感も出ています。
ラベルかわいい。 原材料は麦芽(ドイツ産)ホップと炭酸。アルコール度数は0.00%

こちらから買えます。
MARUKU AF LAGER

小樽ビールのノンアルはこちら

オブジェクト指向はすでに粒度が時代にあっていない

定期的にオブジェクト指向disを書いてしまってるのだけど。

とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが
「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」
という感じです。
ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。
ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代わりのクラス使うくらいでオブジェクト指向っておおげさに言う必要ないと思ってます。

なので、オブジェクト指向いらないと書いたときに「大きいプログラム作らなければそれでいいんでは」みたいなコメントつくけど、「大きいプログラムつくるときにオブジェクトを基本にする必要なくない?オブジェクトを基本にすることほとんどなくない?」となります。
あと、「オブジェクトを使わなくてもオブジェクト指向の考え方は使える」みたいなツッコミが入ることあるけど「オブジェクト使わないならオブジェクト指向って名前で議論する必要なくない?それオブジェクト指向関係なくソフトウェア工学の話では」ってなります。

オブジェクト指向が流行ったときは、分析設計で出てきた要素をコーディングでもそのまま使えるというのが大きな宣伝文句でした。
ソフトウェア部品の再利用をするときに、オブジェクトを単位として販売するというのも見込まれていました。それで販売されたのは結局は画面部品だけだったので、ビジネスロジックを組織をまたがって再利用できるようにするというのを目指したのがEJB(Enterprise JavaBeans)でもありました。でもビジネスロジックを再利用する部品としてEJBが商売になることはありませんでしたね。

結局のところ、ソフトウェアの部品を組織をまたがって再利用する方法としてはWeb APIが主流になっています。
組織内でソフトウェアを管理しやすいように分類するときも、オブジェクトを基本として考えるのではなくて、マイクロサービスとしてサーバごと分離してWeb API経由で結合することが主になっています。
つまり、ソフトウェアの記述をどうまとめるかというレイヤーで管理するのではなく、サービスとして管理するようになっています。
これはオブジェクト指向のあとに現れたSOA(サービス指向アーキテクチャ)が、ようやく形になったとも言えます。ただ、すでにCORBAみたいな分散オブジェクトというのは忘れられていて、オブジェクト指向はベースになっておらずHTTPがベースになりました。
追記:ライブラリとして共有されてるのでは、という指摘をもらっていて、確かにその通りなのだけどうまくこの話の筋に組み込めてない・・・
追記続き:クラスを使ったライブラリはオブジェクト指向なのかというと、またそれは別の話だけど、本筋から外れるので、ここでは「クラスライブラリ=オブジェクト指向」ではない、とだけ書いておきます

オブジェクト指向がなぜソフトウェア部品の共通化通化で使われなかったかというと、ソフトウェアのバージョンアップやメンテナンス、運用といったソフトウェアライフサイクルを管理する視点が欠けていたからだと思います。
そういったライフサイクルまで含めてマイクロサービスとして管理されるようになりました。
サービス管理の細分化を推し進めて、ラムダとかファンクションという単位でサーバレスとして配備するようにもなっています。

そうするともうソフトウェアの記述としてはオブジェクトという単位は大きすぎて、関数という単位で管理すれば十分ということにもなります。

ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。

オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない?」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。発祥がオブジェクト指向ならオブジェクトが関係なくてもそれはオブジェクト指向だ、みたいな考えの本です。「ソフトウェア工学でなぜつくるのか」って名前変えればいいのだけど、それでは売れないんでしょう。
オブジェクト指向が流行ったときに、オブジェクト指向方法論というのが流行って、いろいろな方法論をつくってそれをベースにコンサルするというのが流行りました。とにかくオブジェクト指向と名前をつけておけばコンサル料が取れるという感じだったのだと思います。
いまでも書籍に「オブジェクト指向」とタイトルにつければ売れるということで、まあ結局、昔も今も、オブジェクト指向は技術用語ではなくマーケティング用語なんでしょうね。

もし「オブジェクト指向」を勉強したいと思ったら、その知りたいことは実際にはソフトウェア工学という分野でまとまっているので、そういったタイトルの本を読むのがいいと思います。

エルディンガーアルコールフリー レモン ~ ノンアルビール飲み比べ

エルディンガーのアルコールフリー、レモン
ビールにレモンの酸味と小麦の甘みがいい感じに混ざっておいしい。 f:id:nowokay:20210920185331p:plain

瓶に「リフレッシュにピッタリな1本です」って書いてあるとおり、食事と一緒に飲むよりは休憩時間に飲むとよさそう。
なので今回はパスタと一緒ではない。

原材料は「小麦麦芽、大麦麦芽、ホップ、酵母」といったエルディンガーに「果糖、レモン果汁、レモンエキス、アセロラ果汁」を混ぜたものになってる。
アルコール度数は0.2%。エルディンガーアルコールフリーが0.4%なので、少し薄まっている。

MARUKUから6本単位で買えます。
大人の味わい エルディンガー アルコールフリー レモン330ml ボトル – MARUKU
1本あたり286円

アマゾンではここから選べるけど在庫切れ

他のノンアルビールについてはこちら。