Slide 1
Slide 1 text
Perlの⽣きのこり
YAPC::Fukuoka 2025
1
Slide 2
Slide 2 text
本発表の楽しみ⽅
「懐かしい〜」「そんなことがあったのか〜」とコメント。
各時代で変化した事よりも、そのキッカケや背景に注⽬
2
Slide 3
Slide 3 text
キリ番Get
お題は
BBS
3
Slide 4
Slide 4 text
令和最新Perl製BBSはコチラ👇
https://yapc-fukuoka-bbs.kobaken.co
記念カキコ！
4
Slide 5
Slide 5 text
⾃⼰紹介
● わいとん - @ytnobody
● 最近のようす
○ YAPC::Hakodate 2024 実⾏委員⻑
○ YAYAPC::Hiroshima 2024 司会
○ NT函館にて某仮装⼤賞の審査員⽤ボタンや
某⽶国横断クイズ番組のオマージュ品を展⽰
● 普段のようす
○ 合同会社Y.pmの代表。4期⽬、やってます。
○ バックエンドエンジニアもやってます。
5
Slide 6
Slide 6 text
⾃⼰紹介
● kobaken a.k.a @kfly8
● 経歴
○ YAPC::Hiroshima 2024 実⾏委員⻑
○ YAYAPC::Hiroshima スポンサー
○ 元Japan Perl Association理事
○ 元エンジニア組織開発責任者
● 現在
○ 個⼈事業主
○ 9歳と1歳の娘の⽗
6
Slide 7
Slide 7 text
1990年頃
CGI
7
Slide 8
Slide 8 text
1990年頃 ‒ CGI
● リクエスト受け、プロセス起動
○ 必要な時だけリソースを利⽤
○ ある種、今どき
○ AWS Lambda, Cloudflare
Workers
● デプロイ簡単
○ ftpでファイルを置く
○ 実⾏権限つける
● すごく⼿軽
8
Slide 9
Slide 9 text
書籍もたくさん。⼤流⾏。
9
Slide 10
Slide 10 text
2000年初期
mod_perl
10
Slide 11
Slide 11 text
CGI
リクエスト時にプロセス起動
複雑な要件🙅
mod_perl
プロセスを常駐化しリクエストを待つ
複雑な要件🙆
11
Slide 12
Slide 12 text
Webアプリケーションフレームワークが続々と
課題
● 複雑なルーティング
● データベース処理
● テンプレート
● 認証認可
● Catalyst
● Jifty
● Ruby on Rails (2005)
12
Slide 13
Slide 13 text
Webサーバーも続々と‧‧
● Apache
● lighttpd
● nginx
● …
13
Slide 14
Slide 14 text
乱⽴するフレームワークとサーバー
Catalyst
CGI::Application
フレームワーク
Jifty
Mojo
Apache
lighttpd
nginx
HTTP::Server::Simple
サーバー
14
Slide 15
Slide 15 text
2009年ころ
PSGI/Plack
15
Slide 16
Slide 16 text
PSGI/Plack
● PSGI=Perl Web Server Gateway Interface
● Plack = PSGIの実装
● WSGI (Python )/Rack (Ruby) の後発
● フレームワーク、サーバーが
PSGIを満たせば、⼊れ替え可
● →秩序を保ち、多様性を持てる
Catalyst
CGI::Application
フレームワーク
Jifty
Mojo
Apache
lighttpd
nginx
HTTP::Server::Simple
サーバー
PSGI
16
Slide 17
Slide 17 text
現代っぽくなった
17
Slide 18
Slide 18 text
時は遡り、2005年
18
Slide 19
Slide 19 text
プロダクトはより複雑に。⾔葉にならない問題。
「⾃分の環境だと再現しない…」
「デプロイしたら、壊れた…」
「この処理どうなってるの？」
「この機能使いにくいらしい…」
19
Slide 20
Slide 20 text
問題の発⾒。⾔語化。
● 環境構築 → 依存モジュール管理、コンテナ化
● 未然の問題検知 → ⾃動テスト、CI、静的解析
● プロダクトの複雑化 →コードの責務分割、宣⾔的に
○ ⇒SOLID原則、OOP、関数型ドメインモデリング
● ユーザー体験、インタフェース設計、アクセシビリティ
● ⇒プログラミング⾔語限らず今も私達が向き合ってる問題
20
Slide 21
Slide 21 text
「あの時に戻ったら何を開発するか？」
21
Slide 22
Slide 22 text
2011年初頭
Carton
22
Slide 23
Slide 23 text
Carton
● 依存モジュールの管理
○ 同⼀環境作りやすく
○ バージョンが不意に変わって壊れない
● 多⾔語なら
○ Bundler(Ruby), Go Modules(Go), Cargo (Rust)
○ 今は⾔語標準でつく時代
● 今でこそ、当たり前
23
Slide 24
Slide 24 text
@miyagawa
● ロックスター
● 今の当たり前を作ってる
● カッコイイ
24
Slide 25
Slide 25 text
感想‧質問どうぞ👇
https://yapc-fukuoka-bbs.kobaken.co
キリ番Get
前半パートおしまい
25
Slide 26
Slide 26 text
複雑化するプロダクトに
Perlはどう⽴ち向かってる？
26
Slide 27
Slide 27 text
● プログラミング⾔語⾃⾝も変化する
○ 例：ES5の”use strict”
○ 例：ES6のclass構⽂導⼊。プロトタイプが隠蔽
● プラクティスも変化する
○ var → let, const
○ 例：可変な変数より不変な変数
● 「変化のための痛みは⽌む得ないのか？」
27
Slide 28
Slide 28 text
複雑化するプロダクトにPerlはどう⽴ち向かってる？
⾼い後⽅互換性を保ちつつ、変化できる柔軟性
“Historically, we've held ourselves to a far higher standard than
backward-compatibility -- bugward-compatibility.”
28
Slide 29
Slide 29 text
Perlの変化例: オブジェクト指向プログラミング
Perlは、OOPをあとづけ。
⼤昔：リファレンスとパッケージを紐づける
bless→素朴だが、多重継承, 中⾝を触れる
昔：MooseなどのMeta Object
Programmingに対応したOOPライブラリを
活⽤
今：builtin class。単⼀継承, 中⾝を触れら
れないなど現代のOOPに
29
Slide 30
Slide 30 text
令和最新Perlの変化の背景
● builtin class、try/catch、isaなど続々拡張。
● その背景は、keyword plugin
○ コンパイルフェーズでキーワードにフック。OPツリーを書き換える術
○ PEVANS⽒らによる v5.12 (2010年)での仕込み
○ Corinnaでデザイン ⇒ Object::Pad でPoC。⇒ builtin class
● →互換性を保ちつつ現代的なプラクティスを検証、実装
30
Slide 31
Slide 31 text
杜甫々
“実はフレームワークに頼るのはあまり好きじゃなくて。なにか
を使っていてもすぐに陳腐化したり、依存パッケージが多過ぎて
サポートが切れるものが出てきたり。あとは、バージョンアップ
の追従にコストがかかったりとか、なかなかちょっと⼤変なの
で、シンプルなものだったら、あまり使わなくてもいいんじゃな
いのかなというところもあります。
そもそもOSSのサポート期間が短いと思うんですよね。これは
「endoflife.date」というサイトで、いろいろなOSSのサポート
状況が⾒ることができるんですが、短いといっても若いみなさん
からの2、3年は⻑いんですが、私らから⾒た2、3年はメチャク
チャ短いので。” YAPC::Hiroshima 2024 キーノートより
31
Slide 32
Slide 32 text
2007
iPhone
32
Slide 33
Slide 33 text
市場きっかけの変化
● 2007年 iPhone 販売開始（国内は2008年）
● 2010年 国内4G開始
● → UXUI要求が⼤きく変化
○ サーバープログラミングでは、インタラクション困難
○ モバイルクライアントが⼤規模化。クライアント、サーバの境界定義
33
Slide 34
Slide 34 text
2022年11⽉30⽇
ChatGPT
34
Slide 35
Slide 35 text
今後はどうなるだろうか？
● 2022年11⽉ ChatGPT
● ⽣成AIで、⽣活は様変わり
● 今、⾔葉にできていない問題は？
○ ⇒ 話しましょう！技術コミュニティの価値のひとつ
● Perlであれば
○ 新旧様々な書き⽅をLLMsは学習 ⇒良し悪しは？
35
Slide 36
Slide 36 text
⾃分たちができることは？
PEVANS
“Perlをもっとよくしていくには、公開されている機能をギ
リギリまで使い倒して、できる⼈たちに『そんな無茶なやり
⽅よりもっといい⽅法がある』と⾔わせるといい” London
Perl Workshop 2016 / Charsbar::Note より
36
Slide 37
Slide 37 text
まとめ‧感想
● Perlを軸としつつ、1990年代からの変化を辿りました
○ CGI → すごく⼿軽
○ PSGI/Plack → 秩序を保ちつつ、多様性を持てる
○ Perlの⽂法拡張 →互換性を保ったまま⾔語拡張する仕組み
● 要求レベル、重⼼の変化はあれど、変更を容易に、スケー
ル、UXUI、チーム開発など引き続きやっていき！
37
Slide 38
Slide 38 text
感想‧質問‧ベストトークの投票待ってます。
https://yapc-fukuoka-bbs.kobaken.co
このスレッドは１０００を超えました。
38