Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025

登壇者
- わいとん https://x.com/ytnobody
- kobaken https://x.com/kfly8

---

エンジニアがこの先生きのこるためのカンファレンス2025
https://kinoko-conf.dev/

1. Perlの⽣きのこり エンジニアがこの先⽣きのこるためのカンファレンス2025
2. 本発表の楽しみ⽅ #きのこ2025 をつけて、懐かしい〜、へぇ〜とツイート。 注⽬ポイント • 各時代で変化した事よりも、そのキッカケや背景に注⽬ • 実際の⾏動、考えなどくわしいことは、今⽇、明⽇話したりして掴めると良 さそう！
3. 本発表の流れ • 1990年から2025年現在までのWeb開発を駆け上がります ◦ 説明の都合、時代が多少前後しても許してください • はじめに要所を説明した後、ライブコーティングします ◦ 題材は、インターネット掲⽰板（BBS）です。
4. ⾃⼰紹介 • わいとん - @ytnobody • 最近イベントでやってたこと ◦ YAPC::Hakodate 2024 実⾏委員⻑ ◦ YAYAPC::Hiroshima 2024 司会 ◦ NT函館にて某TV番組⾵の審査員⽤ボタン を展⽰ • 普段やってること ◦ 零細IT企業の代表。そろそろ4期⽬。 ◦ エンジニア。主にバックエンドシステムの 設計‧実装
5. ⾃⼰紹介 • kobaken a.k.a @kfly8 • 経歴 ◦ YAPC::Hiroshima 2024 実⾏委員⻑ ◦ YAYAPC::Hiroshima スポンサー ◦ 元Japan Perl Association理事 ◦ 元エンジニア組織開発責任者 • 現在 ◦ 個⼈事業主、起業準備中 ◦ 9歳と0歳の娘の⽗。今年40歳。
6. インターネット掲⽰板とは ChatGPT先⽣ 「特定の話題に関して⾃由に意⾒を交わ せる場として、多くの⼈に利⽤されてい ます。興味のあるテーマの掲⽰板に参加 すると、同じ趣味や関⼼を持つ⼈と交流 できるのが魅⼒です」
7. きのこ掲⽰板の仕様 ‧名前とコメントを投稿できる ‧投稿が⼀覧で閲覧できる ‧投稿はURLかわかれば誰でもできる。 ログインは不要。
8. STEP1: 1990年頃 CGI
9. 1990年頃 ‒ CGI • リクエスト受け、プロセス起動 ◦ すごく⼿軽。 ◦ コードが巨⼤になれば効率悪 • 右はChat GPT先⽣作 ◦ ファイルに投稿を直書き ◦ 本発表をよくわかってる😄
10. CGI を今みると • リクエスト受け、プロセス起動 ◦ コードが⼩さいなら⼿軽 ◦ ある意味、今どき。AWS Lambda, Cloudflare Workers ◦ 必要な時だけリソースを利⽤ • ファイルに投稿をただ追記するのはいただけない ◦ 編集難、検索難、同時書き込みなど
11. 1990年頃から2000年初期での変化 • リクエストを受け、プロセスが起動 ◦ →プロセスを常駐化してリクエストを待つWebサーバ ◦ 例：Fast CGI, Apache mod_perl • ファイルに投稿をただ追記するのはいただけない ◦ →データベース利⽤ • Webアプリケーションの共通の問題を解くフレームワークが続々と ◦ Ruby on Rails のversion 1 は2005年
12. WebサーバーとWebアプリケーションフレームワークが乱⽴ さらに時代が進むと Catalyst CGI::Application フレームワーク Jifty Mojo Apache lighttpd nginx HTTP::Server::Simple サーバー
13. 2009年ころ PSGI/Plack
14. 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
15. そもそも… • プロダクト規模が⼤きくなってる。 • ユーザー要求も⾼まっている。 ◦ 「きのこ掲⽰板では物⾜りない!」 • 問題は多々 ◦ 変更を容易に、スケール、UXUI、チーム開発 ◦ 今も私たちは向き合っているコト
16. 問題の例 • 環境構築 ◦ →依存モジュール管理、コンテナ化 • 未然の問題検知 ◦ →⾃動テスト、CI、静的型付け • プロダクトの複雑化 ◦ →フレームワークの発展、OOP、関数型プログラミング 「もし2010年にタイムリープしたら、何を開発しますか？」
17. 問題の例 • 環境構築 ◦ →依存モジュール管理、コンテナ化 • 未然の問題検知 ◦ →⾃動テスト、CI、静的型付け • プロダクトの複雑化 ◦ →フレームワークの発展、OOP、関数型プログラミング 「もし2010年にタイムリープしたら、何を開発しますか？」
18. 2011年ころ Carton
19. Carton • 依存するモジュールの管理 • 多⾔語なら ◦ Bundler(Ruby), Go Modules(Go), Cargo (Rust) • 同⼀環境作りやすく。 • バージョンが不意に変わって壊れない • 今でこそ、当たり前
20. @miyagawa • PSGI/Plack , Carton author • 今の当たり前を作ってる • カッコイイ
21. 問題の例（再掲） • 環境構築 ◦ →依存モジュール管理、コンテナ化 • 未然の問題検知 ◦ →⾃動テスト、CI、静的型付け • プロダクトの複雑化 ◦ →フレームワークの発展、OOP、関数型プログラミング
22. 問題の例（再掲） • 環境構築 ◦ →依存モジュール管理、コンテナ化 • 未然の問題検知 ◦ →⾃動テスト、CI、静的型付け • プロダクトの複雑化 ◦ →フレームワークの発展、OOP、関数型プログラミング
23. 複雑化するプロダクトに Perlはどう⽴ち向かってる？
24. • プログラミング⾔語⾃⾝も変化する ◦ 例：ES5の”use strict” ◦ 例：ES6のclass構⽂導⼊。プロトタイプが隠蔽 • プラクティスも変化する ◦ var → let, const ◦ 例：可変な変数より不変な変数
25. 複雑化するプロダクトにPerlはどう⽴ち向かってる？ • ⾮常に⾼い後⽅互換性、スコープ機能が、Good ◦ “Historically, we've held ourselves to a far higher standard than backward-compatibility -- bugward-compatibility.” ◦ 互換性を壊した先の未来は？ • 柔軟さ、曖昧さで困る（諸説） ◦ 例：オブジェクトの外から中⾝を書き換える ◦ 黒魔術 ⇔ どうにかできる脱出ハッチ
26. perlの変化例: OOP ⼤昔：リファレンスとパッケージを紐づける bless→素朴だが、多重継承, 中⾝を触れる 昔：MooseなどのMeta Object Programmingに対応したOOPライブラリを 活⽤ 今：builtin class。単⼀継承, 中⾝を触れら れないなど現代のOOPに
27. 変化の背景 • Perlには⽂法を拡張する術がある • ＝コンパイルフェーズでキーワードにフックして、AST相当のツリーを書き 換える術がある(keyword plugin) ◦ PEVANS⽒らによる v5.12 (2010年)での仕込み • →互換性を保ったまま、曖昧な⽂法改善や現代的なプラクティスを試験でき る。v5.36(2022年)以降、急速に変化している
28. 外圧きっかけの変化
29. 外圧きっかけの変化 • 2007年 iPhone 販売開始（国内は2008年） • 2010年 国内4G開始 • → UXUI要求が⼤きく変化 ◦ モバイル端末とWebサーバーで通信する
30. 2010年頃から広まる設計 • ユーザーの端末に重⼼を寄せた設計 • サーバープログラミングでは、インタラクション困難 • Web フロントエンドでは、jQuery によるDOM操作から、Backbone.js と いったモデリングが広まる • → Single Page Application
31. 発展 • クライアント↔サーバーやサーバー同⼠のコミュニケーションをするのにス キーマがほしい ◦ 2011年 Swagger, Open API • Webフロントエンドが⼤規模開発に ◦ 2010年〜2015年ころ Alternative JavaScript 発展 ◦ 2012年 TypeScript 0.8 リリース • クライアント側の要求で必要⼗分なデータを取得したい ◦ 2012年 GraphQL 開発開始 / 2015 オープンソース化
32. 発展２ • Single Page Applicationでは、ユーザーがコンテンツを体験するまで遅い。 SEOも不利。けれど、インタラクションは欲しいし、JavaScriptのエコシス テムも利⽤したい。 • サーバーサイドで極⼒処理して、インタラクションをあとから注⼊ • → Server Side Rendering , islands architecture Backend for frontend Frontend Backend API
33. ライブコーディング
34. 今後はどうなるだろうか？ • ⽣成AIは、間違いなく変化の外圧 ◦ Perlであれば、新旧様々な書き⽅をAIが学習してしまっている。 ◦ 令和モダンPerlにAIを適⽤させたい。 • 内発的に起こしたい変化は？ ◦ PEVANS「Perlをもっとよくしていくには、公開されている機能をギリ ギリまで使い倒して、できる⼈たちに『そんな無茶なやり⽅よりもっと いい⽅法がある』と⾔わせるといい」
35. まとめ‧感想 • Perlを軸としつ、1990年代からの変化を駆け⾜で辿りました ◦ CGI → すごく⼿軽 ◦ PSGI/Plack → 秩序を保ちつつ、多様性を持てる ◦ Perlの⽂法拡張 →互換性を保ったまま⾔語拡張する仕組み ◦ Webサーバの設計変化(SPA,SSR) • 要求レベル、重⼼の変化はあれど、変更を容易に、スケール、UXUI、チーム 開発といった要求に引き続き向き合っていき！