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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

本発表の楽しみ⽅ #きのこ2025 をつけて、懐かしい〜、へぇ〜とツイート。注⽬ポイント ● 各時代で変化した事よりも、そのキッカケや背景に注⽬ ● 実際の⾏動、考えなどくわしいことは、今⽇、明⽇話したりして掴めると良さそう！

Slide 3

Slide 3 text

本発表の流れ ● 1990年から2025年現在までのWeb開発を駆け上がります ○ 説明の都合、時代が多少前後しても許してください ● はじめに要所を説明した後、ライブコーティングします ○ 題材は、インターネット掲⽰板（BBS）です。

Slide 4

Slide 4 text

⾃⼰紹介 ● わいとん - @ytnobody ● 最近イベントでやってたこと ○ YAPC::Hakodate 2024 実⾏委員⻑ ○ YAYAPC::Hiroshima 2024 司会 ○ NT函館にて某TV番組⾵の審査員⽤ボタンを展⽰ ● 普段やってること ○ 零細IT企業の代表。そろそろ4期⽬。 ○ エンジニア。主にバックエンドシステムの設計‧実装

Slide 5

Slide 5 text

⾃⼰紹介 ● kobaken a.k.a @kﬂy8 ● 経歴 ○ YAPC::Hiroshima 2024 実⾏委員⻑ ○ YAYAPC::Hiroshima スポンサー ○ 元Japan Perl Association理事 ○ 元エンジニア組織開発責任者 ● 現在 ○ 個⼈事業主、起業準備中 ○ 9歳と0歳の娘の⽗。今年40歳。

Slide 6

Slide 6 text

インターネット掲⽰板とは ChatGPT先⽣「特定の話題に関して⾃由に意⾒を交わせる場として、多くの⼈に利⽤されています。興味のあるテーマの掲⽰板に参加すると、同じ趣味や関⼼を持つ⼈と交流できるのが魅⼒です」

Slide 7

Slide 7 text

きのこ掲⽰板の仕様 ‧名前とコメントを投稿できる ‧投稿が⼀覧で閲覧できる ‧投稿はURLかわかれば誰でもできる。ログインは不要。

Slide 8

Slide 8 text

STEP1: 1990年頃 CGI

Slide 9

Slide 9 text

1990年頃 ‒ CGI ● リクエスト受け、プロセス起動 ○ すごく⼿軽。 ○ コードが巨⼤になれば効率悪 ● 右はChat GPT先⽣作 ○ ファイルに投稿を直書き ○ 本発表をよくわかってる😄

Slide 10

Slide 10 text

CGI を今みると ● リクエスト受け、プロセス起動 ○ コードが⼩さいなら⼿軽 ○ ある意味、今どき。AWS Lambda, Cloudﬂare Workers ○ 必要な時だけリソースを利⽤ ● ファイルに投稿をただ追記するのはいただけない ○ 編集難、検索難、同時書き込みなど

Slide 11

Slide 11 text

1990年頃から2000年初期での変化 ● リクエストを受け、プロセスが起動 ○ →プロセスを常駐化してリクエストを待つWebサーバ ○ 例：Fast CGI, Apache mod_perl ● ファイルに投稿をただ追記するのはいただけない ○ →データベース利⽤ ● Webアプリケーションの共通の問題を解くフレームワークが続々と ○ Ruby on Rails のversion 1 は2005年

Slide 12

Slide 12 text

WebサーバーとWebアプリケーションフレームワークが乱⽴さらに時代が進むと Catalyst CGI::Application フレームワーク Jifty Mojo Apache lighttpd nginx HTTP::Server::Simple サーバー

Slide 13

Slide 13 text

2009年ころ PSGI/Plack

Slide 14

Slide 14 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

Slide 15

Slide 15 text

そもそも… ● プロダクト規模が⼤きくなってる。 ● ユーザー要求も⾼まっている。 ○ 「きのこ掲⽰板では物⾜りない!」 ● 問題は多々 ○ 変更を容易に、スケール、UXUI、チーム開発 ○ 今も私たちは向き合っているコト

Slide 16

Slide 16 text

問題の例 ● 環境構築 ○ →依存モジュール管理、コンテナ化 ● 未然の問題検知 ○ →⾃動テスト、CI、静的型付け ● プロダクトの複雑化 ○ →フレームワークの発展、OOP、関数型プログラミング「もし2010年にタイムリープしたら、何を開発しますか？」

Slide 17

Slide 17 text

Slide 18

Slide 18 text

2011年ころ Carton

Slide 19

Slide 19 text

Carton ● 依存するモジュールの管理 ● 多⾔語なら ○ Bundler(Ruby), Go Modules(Go), Cargo (Rust) ● 同⼀環境作りやすく。 ● バージョンが不意に変わって壊れない ● 今でこそ、当たり前

Slide 20

Slide 20 text

@miyagawa ● PSGI/Plack , Carton author ● 今の当たり前を作ってる ● カッコイイ

Slide 21

Slide 21 text

問題の例（再掲） ● 環境構築 ○ →依存モジュール管理、コンテナ化 ● 未然の問題検知 ○ →⾃動テスト、CI、静的型付け ● プロダクトの複雑化 ○ →フレームワークの発展、OOP、関数型プログラミング

Slide 22

Slide 22 text

Slide 23

Slide 23 text

複雑化するプロダクトに Perlはどう⽴ち向かってる？

Slide 24

Slide 24 text

● プログラミング⾔語⾃⾝も変化する ○ 例：ES5の”use strict” ○ 例：ES6のclass構⽂導⼊。プロトタイプが隠蔽 ● プラクティスも変化する ○ var → let, const ○ 例：可変な変数より不変な変数

Slide 25

Slide 25 text

複雑化するプロダクトにPerlはどう⽴ち向かってる？ ● ⾮常に⾼い後⽅互換性、スコープ機能が、Good ○ “Historically, we've held ourselves to a far higher standard than backward-compatibility -- bugward-compatibility.” ○ 互換性を壊した先の未来は？ ● 柔軟さ、曖昧さで困る（諸説） ○ 例：オブジェクトの外から中⾝を書き換える ○ 黒魔術 ⇔ どうにかできる脱出ハッチ

Slide 26

Slide 26 text

perlの変化例: OOP ⼤昔：リファレンスとパッケージを紐づける bless→素朴だが、多重継承, 中⾝を触れる昔：MooseなどのMeta Object Programmingに対応したOOPライブラリを活⽤今：builtin class。単⼀継承, 中⾝を触れられないなど現代のOOPに

Slide 27

Slide 27 text

変化の背景 ● Perlには⽂法を拡張する術がある ● ＝コンパイルフェーズでキーワードにフックして、AST相当のツリーを書き換える術がある(keyword plugin) ○ PEVANS⽒らによる v5.12 (2010年)での仕込み ● →互換性を保ったまま、曖昧な⽂法改善や現代的なプラクティスを試験できる。v5.36(2022年)以降、急速に変化している

Slide 28

Slide 28 text

外圧きっかけの変化

Slide 29

Slide 29 text

外圧きっかけの変化 ● 2007年 iPhone 販売開始（国内は2008年） ● 2010年国内4G開始 ● → UXUI要求が⼤きく変化 ○ モバイル端末とWebサーバーで通信する

Slide 30

Slide 30 text

2010年頃から広まる設計 ● ユーザーの端末に重⼼を寄せた設計 ● サーバープログラミングでは、インタラクション困難 ● Web フロントエンドでは、jQuery によるDOM操作から、Backbone.js といったモデリングが広まる ● → Single Page Application

Slide 31

Slide 31 text

発展 ● クライアント↔サーバーやサーバー同⼠のコミュニケーションをするのにスキーマがほしい ○ 2011年 Swagger, Open API ● Webフロントエンドが⼤規模開発に ○ 2010年〜2015年ころ Alternative JavaScript 発展 ○ 2012年 TypeScript 0.8 リリース ● クライアント側の要求で必要⼗分なデータを取得したい ○ 2012年 GraphQL 開発開始 / 2015 オープンソース化

Slide 32

Slide 32 text

発展２ ● Single Page Applicationでは、ユーザーがコンテンツを体験するまで遅い。 SEOも不利。けれど、インタラクションは欲しいし、JavaScriptのエコシステムも利⽤したい。 ● サーバーサイドで極⼒処理して、インタラクションをあとから注⼊ ● → Server Side Rendering , islands architecture Backend for frontend Frontend Backend API

Slide 33

Slide 33 text

ライブコーディング

Slide 34

Slide 34 text

今後はどうなるだろうか？ ● ⽣成AIは、間違いなく変化の外圧 ○ Perlであれば、新旧様々な書き⽅をAIが学習してしまっている。 ○ 令和モダンPerlにAIを適⽤させたい。 ● 内発的に起こしたい変化は？ ○ PEVANS「Perlをもっとよくしていくには、公開されている機能をギリギリまで使い倒して、できる⼈たちに『そんな無茶なやり⽅よりもっといい⽅法がある』と⾔わせるといい」

Slide 35

Slide 35 text

まとめ‧感想 ● Perlを軸としつ、1990年代からの変化を駆け⾜で辿りました ○ CGI → すごく⼿軽 ○ PSGI/Plack → 秩序を保ちつつ、多様性を持てる ○ Perlの⽂法拡張 →互換性を保ったまま⾔語拡張する仕組み ○ Webサーバの設計変化(SPA,SSR) ● 要求レベル、重⼼の変化はあれど、変更を容易に、スケール、UXUI、チーム開発といった要求に引き続き向き合っていき！