Pascalを使う理由
(castle-engine.io)- Object Pascalは、読みやすいモダンなオブジェクト指向言語とネイティブ性能の両立を目指し、複数のプラットフォームで保守しやすいアプリケーションを作るための選択肢である
- 強い型付け、コンパイル時チェック、ランタイムチェックにより、名前のタイプミスや型の不一致といったエラーを、ユーザーに届く前に検出しやすい
- 必要であればポインタ、OS・CPU別コード、アセンブリまで利用できるが、Castle Game Engineはアセンブリなしでも高速なコードを維持する方を選んでいる
- Windows、Linux、macOS、モバイル、コンソール、Webまで幅広く対象にでき、Castle Game Engineではエンジンコードとゲームコードが同じ言語で書かれている
- FPC、Lazarus、Delphi、VS Code統合や多様なライブラリ連携があり、Pascalエコシステムの中でも実用的な開発フローを構築できる
読みやすく型安全なObject Pascal
- Object Pascalは、モダンで読みやすく高速な型安全クロスプラットフォーム言語として扱われる
- 他のオブジェクト指向言語を知っていれば比較的容易に習得でき、学習資料としてModern Object Pascal Introduction for Programmersを利用できる
- モダンなオブジェクト指向言語に期待される機能を備えている
- クラス
- ユニット
- プロパティ
- ジェネリクス
- インターフェース
- リフレクション
- クロージャ
- 構文は読みやすいコードに重点を置いている
- 型安全性のためにboolean、string、char、set、enum、rangeのような個別の型を提供する
- 整数をfloatに代入するような安全な変換は容易に処理される
- それ以外の変換は明示的に行う必要がある
コンパイル時とランタイムでエラーを捕捉する方法
- Object Pascalはコンパイル時チェックを重視する
- データ構造の再配置のようなリファクタリングを行う際、コンパイラが修正が必要な箇所を明らかにするようにできる
- 名前のタイプミスや型の不一致のような明白なミスはコンパイルを通らず、ユーザーに届かない
- 追加のランタイムチェックも提供される
- 配列範囲チェック
- 整数オーバーフローチェック
- assertion
- メモリリークチェック
- ランタイムチェックはdebug版で問題を見つけるために使い、性能が重要なrelease版では無効化できる
- CGE editorでコンパイルするときはdebug / releaseモードが自動設定され、「Run」メニューでモードを切り替えられる
- 関連文書としてWhat are range and overflow checks (and errors) in PascalとDetecting Memory Leaksを参照できる
ネイティブ性能と必要なだけの低レベル制御
- Object Pascalはネイティブコードにコンパイルされるため、基本的な実行性能を確保しやすい
- 一般的なアプリケーションでは、低レベル最適化まで踏み込む必要はあまりない
- 必要であれば望むだけ低レベル機能を利用できる
- ポインタの使用
- ポインタ演算
- OS・CPU別コードの作成
- アセンブリコードの追加
- Castle Game Engineは移植性とコード可読性を高めるため、アセンブリコードを一切使わずに高速な実行を目指している
- コンパイルも高速な方で、新規プロジェクトを初めて開いたとき、デスクトップビルドは2.5秒、Androidビルドは10.1秒だった事例がある
複数プラットフォームとCastle Game Engineの開発方式
- Object Pascalはさまざまなプラットフォーム向けに利用できる
- デスクトップ: Windows, Linux, macOS, Raspberry Pi, FreeBSD, おそらくあらゆるUnix
- モバイル: Android, iOS
- コンソール: Nintendo Switch
- Web: WebAssembly, pas2jsを使ったJS
- Castle Game Engineの対応プラットフォームはCastle Game Engine platforms supportedで確認できる
- 全体的な対応先はFPC target platformsとDelphi target platformsを参照できる
- Castle Game Engineではエンジンコードとゲームコードが同じ言語で書かれている
- エンジンはオープンソースで、必要に応じてCGEをforkして修正できる
ライブラリと開発ツールのエコシステム
- Pascalにはさまざまな分野の既存ライブラリやユニットがある
- データベース
- XML, JSON
- AI
- ブロックチェーン
- ネットワーキング
- C APIがある既存ライブラリと容易に統合またはリンクできる
- レンダラー
- サウンドライブラリ
- 物理エンジン
- Python libraries in Pascalも利用できる
- 主なツール群は次のとおり
3件のコメント
Delphi…懐かしいですね。Borland、デルマダン…
Windows開発をしていた頃は、本当にObject Pascal with Delphiが最高だったと思います。
Hacker Newsのコメント
以前Delphiを使っていた人なら、Lazarusをすでに知っている可能性が高い。Lazarusは実質的にオープンソースでの再実装に近く、Raspberry PiのようなARMボードを含め、ほぼどこでもネイティブに実行・コンパイルできる
ただしライブラリのインストールが面倒なことがあるため、IDEやモジュール、かなり興味深いアドオンの導入を自動化する目的でFpcUp、その後に FpcUpDeluxe が作られた
https://wiki.freepascal.org/fpcupdeluxe
FpcUpDeluxeに含まれている無料ウィジェットで急いで作ったメーターパネルのウィジェットデモもある
https://ibb.co/9bchx7T
FpcUpDeluxeはAlpine Linuxでも動作し、リリースページからmusl版を入手すればよい。そのため、ごく小さなシステムにもメーターパネルを載せられる可能性が開ける。複数のプラットフォームでコードがネイティブにコンパイルされて高速に実行され、インタープリタやWebブラウザも不要
最後にLazarusとDelphiを使ったときは、Unicode が難しく、全体的にASCII前提という印象だった
[0] https://github.com/markmal/freeship-plus-in-lazarus
[1] http://web.archive.org/web/20160128212152/http://hydronship.net/index.php?lang=en
[2] https://sourceforge.net/projects/freeship
一時期Delphi/Pascalを主言語として使っていて、この10〜20年ずっと自分に合う言語を探してきた。Haxeもかなり長く使ったが、結局は「それはマクロでやればいい」という罠にはまった感じだった。マクロは何でもできるが、十分に増えると誰もが自分専用のマクロ拡張言語でプログラミングするようになってしまう
JavaScriptには良い改善が入ってきており、今なおさらに必要だとは思うが、今はその方面の仕事も多い。数年前に8ビットAVRのコードを書いたとき、FreePascal をまた使ってみたら本当に楽しかった。新機能を試してみると本当にモダンな言語のように感じられ、小さな領域向けにコーディングしていたので標準ライブラリをほとんど使わず、必要なコードを自分で作っていた点も良かった
そのおかげで、FreePascalが長年にわたって積み上げてきた後方互換性のための名前空間ノイズ、たとえばTList、TFPList、TFPGList、TFPGObjectListのような層を避けられた。最も残念だったのは、FPUやエミュレーションのないターゲットではコンパイラが定数の浮動小数点式を許可しなかったことだ。コンパイル時に計算できるのだから、できてもよかったはずだと思う
他の環境を使ってみると、今では関数の途中で変数を定義できないことが制約に感じられ、ネストした関数レベルのスコープ指定もあればいいのにと思う。begin/endと
{}の違いはあまり気にならない。今は大文字小文字を区別する言語のほうが好みで、型に文字プレフィックスを付けないほうがよいと思っている。これは何よりエディタの進化のおかげだろう。構文ハイライトやリアルタイムLintが情報を別のレイヤーに移し、テキスト上のノイズを減らしてくれるFreePascalの後継言語 がクリーンスタート方式で出るなら、かなり熱狂すると思う。最新機能を第一級市民として使える新しい標準ライブラリがあるとよくて、引退したら一度作ってみるかもしれない
{}は実際には同じ意味ではない。{}は ローカルスコープ を定義するが、begin/endはそうではない90年代に数年間、仕事でDelphiを使っていて気に入っていたが、Borlandとその後の所有者たちが製品と言語を繰り返し誤った方向に運営するのにうんざりした。Anders HejlsbergもBorlandを去ってMicrosoftに移り、C# を作ったが、個人的には時間を投資するならはるかに良い言語とアーキテクチャだと思う
最近はリソース制約があるので、趣味で Pascal を使っている。昔の Borland Turbo Pascal 3.00A は CP/M 上で動作し、エディタ・コンパイラ・ライブラリをすべて 64KB の中で提供していた
対話的に使うのに十分な速さがあり、低レベルユーティリティや簡単なゲーム、ちょっとしたハックを実装するのに十分なコードを生成してくれる。より大きい、あるいは現代的な環境で Pascal を使ったことはないが、最近の体験にはかなり満足していて、選択肢から外すつもりはない
いまでもモダンな Pascal 実装が存在するとは知らなかったし、初恋ともう一度親しくなるべきなのかもしれない
CP/M が必要ならサイトで対応状況を確認できるし、対応していても驚かない。テキスト UI の IDE は Turbo Pascal にとてもよく似ていて、稲妻のように速い。言語自体は Turbo Pascal よりずっと多くの高度な機能を備えているが、望まなければ使わなくてもよい
以前 Windows で簡単に試したとき、生成されるバイナリも C のように非常に小さく、単純な hello world プログラムが 50〜60KB 未満だった
M-III BASIC の開発環境からするとものすごい進歩だった記憶があり、48KB RAM の中でも自作のゲームやユーティリティがかなりうまく動いていた。Pascal-80 のコードベースがその後どうなったのか気になる。レトロハードウェア向けの現代的なツールより良いはずはなく、おそらくずっと劣っているだろうが。『Oh Pascal!』は私がこの言語を学んだ本で、Pascal が商業的に使われる数年前のことだったから、他の選択肢はあまりなかったのだと思う
いくつかの理由には同意しにくい。Object Pascal はモダンな言語ではない。1998年にはそうだったかもしれないが、その後は大きく進化しておらず、最後の大きな変化も、他のほとんどすべての言語より遅れて導入されたジェネリクスだった
FPC が特別に速いコードを生成するわけでもなく、Object Pascal のオブジェクト特性も局所性に有利ではない。スクリプト言語よりは速いが、ガベージコレクションのある言語も含め、一般的な事前コンパイル言語よりはたいてい遅い
一方でエコシステムは素晴らしい。良いライブラリやツールが多く、特に注目すべきなのは Delphi クローンの Lazarus だ。FPC や Delphi を使う人たちは、言語のモダン化のようなことにはあまり関心がなく、ただ仕事を終わらせる傾向があった。ただ、新しい開発者にとって魅力的とは思えないので、将来どうなるかは分からない
実際の性能は十分で、ボトルネックを見つけたら必要なだけ最適化することもできる。C++ と比べると「高水準」クラスを使うのは少し面倒かもしれないが、不可能ではない
最小限の労力で基本性能を求めるなら、新しい LLVM バックエンドもある。ランタイムライブラリや FCL などもすべて LLVM バックエンドでビルドする必要があるので、コンパイラをソースからビルドしなければならないが、数分で済む。その代わりコンパイラはずっと遅くなり、個人的にはその性能差に見合う価値があるとは思わない
だから、実際より 50 倍ほど遅いと判断したベンチマークが何なのか気になる
ここで言う競技プログラミングとは、実行ごとに最大 1〜3 秒の短い CPU 中心の単一スレッドのアルゴリズム計算で、JIT には不利で、標準のコンパイラ・ランタイム設定、外部ライブラリやチューニングなしで行われる環境を指す。当時の常識は C++/Pascal を使うか、Java でやって「time limit exceeded」が出たら 200〜300 行の解答を C++ に書き直して通す、というものだった
Pascal はシングルパスの LL(1) コンパイラを使うので、ミリ秒単位のコンパイルが可能だ。Edit→Compile→Run を 1 秒以内に終えられる、REPL のような体験を与えてくれる。マクロがありコンパイル時間の遅い C/C++ は開発者体験がより悪く、少なくとも私が C の代わりに Pascal を、C++ の代わりに Delphi を学んだ理由はそこにあった
なぜわざわざそうする必要があるのか分からない。古い言語はレガシー対応のために残っているべきだが、そうした現代的な機能を古い言語に無理やり押し込むことにあまり意味は見いだせない
Javaはよく使うが、正直に言って Java 8以降 のほぼすべての機能は追加されるべきではなかったと思う。たとえばラムダはJavaでは継ぎはぎに近い
現代的な機能が欲しいなら現代的な言語を使えばよい。JavaのエコシステムにとどまりたいならKotlinを使えばよい。Pascalは文字どおり何十年も見ておらず、最後にプログラミングしたのは1980年代なのでJavaの話ばかりになるが、Pascalにそうした機能一覧を追加するのは滑稽に見える
それでも現代的な機能を押し込む価値はある。今なら新規プロジェクトをC++で始めず、Rustのような現代的言語を選ぶことはできるが、すでに書かれている数百万行の C++コード は現代的な機能によって改善できる。C++11が流れを変えたことを見れば分かる
Java言語は、言語機能の代わりにライブラリを使うという決定のせいで膨大な量の ボイラープレートコード を生み出し、その方向性は間違っていたと思う。Python、Lisp、HaskellでできることはJavaでも何でもできるが、定義上はbrainf*ckでもできる。実際のJavaでの解法は機能の多い言語より複雑になり、結局そうした言語機能を少し壊れた形で再実装するか、その代わりになる依存関係を大量に引き込むことになる。どちらにしても学ぶべきAPIの表面積が増えるだけだ
Javaの改善のおかげで JVM は関連性を保ち続け、DotNetを食い止めることができたし、Microsoftの歴史を考えればそれは良いことだった
見落とされがちだが、Ada組み込みエコシステム には静的解析、デバッグ、ターゲット対応の成熟度に強みがある
AdaのPascal風の構文は冗長に見えるが、読みにくくはない。VHDLもAda構文ベースなので、両方の言語を使う人にはむしろ取り組みやすいかもしれない
Swiftもこの一部を満たしており、クロージャ、自動参照カウント、型推論のような便利な機能も加えている。測定型についてはよく分からないが、実装は可能そうに見える。ただ、まだSwiftのようなHDLはなさそうだ
Pascalは実際に良く、性能も悪くない。高校時代にBasicの次に学んだ2番目の言語だった
業界がなぜ90年代後半から2000年代初頭にかけて Python、Ruby、Java、JavaScript へ後退しなければならなかったのか理解できない
Python、Ruby、JSのような動的型付け言語が90年代に人気を得た理由を説明していて、Webサイトを作る際に高速なフィードバックループを提供し、IDEやコンパイラを必要としなかったからだという。当時のIDEやコンパイラは遅く、無料ではないことも多かった
どうせユーザーは56kモデムで接続していた時代だったので、開発時間を性能向上と引き換えにしてもあまり得ではなかった。その発表には、この10〜20年で開発のやり方がどう変わったか、そしてなぜ流れが再び 静的型付け に戻っているのかについての興味深いポイントも多い
さらにWebブラウザが人気のプログラミングプラットフォームとなり、主にJavaScriptが使われた。今でもブラウザ部分に加えて、Webブラウザの中に 完全なオペレーティングシステム を押し込もうとしており、Chromeはかなりそこに近づいている
大学1年のときの最初のプロジェクトはPascalで作ったエレベーターシミュレータで、テキストグラフィックスを使っていた。C系言語と比べると、Pascalにはどこか 優雅さ があって楽しかった
なので最近はNimを楽しんでいるが、私の知る限りNimはAdaやPythonだけでなく、Pascal、Modula-3、Oberon、DelphiのようなWirth系言語からも影響を受けている
Pascalはそれほど悪くなく、実際、一部の現代的プログラミング言語より優れている点もあると思う。もちろん完璧ではなく欠点もある
ときどきDOSプログラミングにPascalとBASICを使うが、少なくともその用途ではPascalは悪くないように見える。CもDOSプログラミングに使われるが、特に リアルモード ではあまり向いていないように見える
LinuxプログラミングではたいていCを好むが、PostScriptも使う。CもPostScriptも、一部の現代的言語と比べて利点があると思う。Pascalは他のプログラムにも使えるし、TeXですらPascalで書かれていた