Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

---

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

Kenta Kobayashi

February 24, 2025
Tweet

More Decks by Kenta Kobayashi

Other Decks in Technology

Transcript

  1. ⾃⼰紹介 • わいとん - @ytnobody • 最近イベントでやってたこと ◦ YAPC::Hakodate 2024

    実⾏委員⻑ ◦ YAYAPC::Hiroshima 2024 司会 ◦ NT函館にて某TV番組⾵の審査員⽤ボタン を展⽰ • 普段やってること ◦ 零細IT企業の代表。そろそろ4期⽬。 ◦ エンジニア。主にバックエンドシステムの 設計‧実装
  2. ⾃⼰紹介 • kobaken a.k.a @kfly8 • 経歴 ◦ YAPC::Hiroshima 2024

    実⾏委員⻑ ◦ YAYAPC::Hiroshima スポンサー ◦ 元Japan Perl Association理事 ◦ 元エンジニア組織開発責任者 • 現在 ◦ 個⼈事業主、起業準備中 ◦ 9歳と0歳の娘の⽗。今年40歳。
  3. 1990年頃 ‒ CGI • リクエスト受け、プロセス起動 ◦ すごく⼿軽。 ◦ コードが巨⼤になれば効率悪 •

    右はChat GPT先⽣作 ◦ ファイルに投稿を直書き ◦ 本発表をよくわかってる😄
  4. CGI を今みると • リクエスト受け、プロセス起動 ◦ コードが⼩さいなら⼿軽 ◦ ある意味、今どき。AWS Lambda, Cloudflare

    Workers ◦ 必要な時だけリソースを利⽤ • ファイルに投稿をただ追記するのはいただけない ◦ 編集難、検索難、同時書き込みなど
  5. 1990年頃から2000年初期での変化 • リクエストを受け、プロセスが起動 ◦ →プロセスを常駐化してリクエストを待つWebサーバ ◦ 例:Fast CGI, Apache mod_perl

    • ファイルに投稿をただ追記するのはいただけない ◦ →データベース利⽤ • Webアプリケーションの共通の問題を解くフレームワークが続々と ◦ Ruby on Rails のversion 1 は2005年
  6. 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
  7. 問題の例 • 環境構築 ◦ →依存モジュール管理、コンテナ化 • 未然の問題検知 ◦ →⾃動テスト、CI、静的型付け •

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

    プロダクトの複雑化 ◦ →フレームワークの発展、OOP、関数型プログラミング 「もし2010年にタイムリープしたら、何を開発しますか?」
  9. Carton • 依存するモジュールの管理 • 多⾔語なら ◦ Bundler(Ruby), Go Modules(Go), Cargo

    (Rust) • 同⼀環境作りやすく。 • バージョンが不意に変わって壊れない • 今でこそ、当たり前
  10. 複雑化するプロダクトにPerlはどう⽴ち向かってる? • ⾮常に⾼い後⽅互換性、スコープ機能が、Good ◦ “Historically, we've held ourselves to a

    far higher standard than backward-compatibility -- bugward-compatibility.” ◦ 互換性を壊した先の未来は? • 柔軟さ、曖昧さで困る(諸説) ◦ 例:オブジェクトの外から中⾝を書き換える ◦ 黒魔術 ⇔ どうにかできる脱出ハッチ
  11. 変化の背景 • Perlには⽂法を拡張する術がある • =コンパイルフェーズでキーワードにフックして、AST相当のツリーを書き 換える術がある(keyword plugin) ◦ PEVANS⽒らによる v5.12

    (2010年)での仕込み • →互換性を保ったまま、曖昧な⽂法改善や現代的なプラクティスを試験でき る。v5.36(2022年)以降、急速に変化している
  12. 外圧きっかけの変化 • 2007年 iPhone 販売開始(国内は2008年) • 2010年 国内4G開始 • →

    UXUI要求が⼤きく変化 ◦ モバイル端末とWebサーバーで通信する
  13. 発展 • クライアント↔サーバーやサーバー同⼠のコミュニケーションをするのにス キーマがほしい ◦ 2011年 Swagger, Open API •

    Webフロントエンドが⼤規模開発に ◦ 2010年〜2015年ころ Alternative JavaScript 発展 ◦ 2012年 TypeScript 0.8 リリース • クライアント側の要求で必要⼗分なデータを取得したい ◦ 2012年 GraphQL 開発開始 / 2015 オープンソース化
  14. 今後はどうなるだろうか? • ⽣成AIは、間違いなく変化の外圧 ◦ Perlであれば、新旧様々な書き⽅をAIが学習してしまっている。 ◦ 令和モダンPerlにAIを適⽤させたい。 • 内発的に起こしたい変化は? ◦

    PEVANS「Perlをもっとよくしていくには、公開されている機能をギリ ギリまで使い倒して、できる⼈たちに『そんな無茶なやり⽅よりもっと いい⽅法がある』と⾔わせるといい」
  15. まとめ‧感想 • Perlを軸としつ、1990年代からの変化を駆け⾜で辿りました ◦ CGI → すごく⼿軽 ◦ PSGI/Plack →

    秩序を保ちつつ、多様性を持てる ◦ Perlの⽂法拡張 →互換性を保ったまま⾔語拡張する仕組み ◦ Webサーバの設計変化(SPA,SSR) • 要求レベル、重⼼の変化はあれど、変更を容易に、スケール、UXUI、チーム 開発といった要求に引き続き向き合っていき!