身の回りに溢れているほとんど全てのプログラムは、 静止状態の表現としてソースコードを持ち、 計算機上で実行され、そして終了します。 少なくとも、終了しようと思えばできるように作られています。
しかしながら、近年では、Webサーバやネットワークプログラムのように、 継続的に動作することが当たり前で、停止状態に移行する事自体が 例外とされるようなプログラムが珍しくなくなってきています。
RubyやPerl, Pythonなどの動的言語と呼ばれる言語が普及し、 プログラム言語の価値は、実行速度から開発速度で測られる 比率が高くなりました。 そんな中、去年ぐらいから、静的言語でも動的言語でもない、 新しいプログラミング言語のパラダイムの可能性について考えています。
はてしない物語。終了状態の無いプログラム。
停止することなく、動き続けることが想定されるService型プログラムを 記述することに特化した言語があってもいいのではないか。 そんな事を思うようになったのは、 Rubyistにはお馴染みの irb と druby を頻繁に使っていたからかもしれません。
NEPL ≒ irb + druby + Erlang + Sandbox
今のところ、open な druby サーバに対して irbで接続しに行くというのが、 一番それらしいものが得られる方法だと思います。 しかしながら、openなdrubyサーバを用意するのは非常にリスキーです。 ErlangのActorモデルや、エラー処理に関する哲学が参考になりそうです。
NEPL処理系が実現すると、 ソフトウェア開発のスタイルが大きく変わるのではないかと思います。
- ソースコードを書いて、リポジトリにコミットするのではなく、 NEPL処理系に接続し、irb的なshellからActorを登録する。
- 仕様をActorの評価関数（計算機リソースの割り当て比率を決める）として定義する。
- バグを見つけてソースコードを修正するのではなく、 バグを定義してActorに対する罰金（ペナルティ）を課し、終息させる。
何かとりあえず動くものを形にしてみるべきですね。
$SAFE = 4なrubyとdrubyをベースにするか、
JavaScript
See Also
暴走して、ファイルやメモリに無限にアクセスし続けるとかという場合が起きたら、どうするのでしょう？資源アクセスへはなんらかの制約がすでに課されてるとか？
そうですね、制約が課されているべきだと思います。 また、ファイルやメモリに無限にアクセスし続けるようなアクターを書いても、 CPU時間が割り当てられないようなリソース分配を行うことを考えています。 順列都市っぽいものをイメージしてもらえるとわかりやすいかも。
Smalltalkは終了状態の無いプログラムかも。
ふむふむ。Smalltalkを使ってみます。
これは初耳です。小説みたいですね。時間があったときに読んでみたと思います。
非常に面白かったです。
Smalltalkもそうですが、Lisp系の人も走りっぱなしプログラムが好きですよね。というかそちらの方が歴史も古いですし。
そうみたいですね、Smalltalk勉強会でもEmacs-Lispの話が出てました。 Lispも腰を据えて使ったことがないんですよね。 昔は、高速なRaytracerが書けない言語には魅力を感じなかったのです。 なので、昔からある動的言語はスルーしがちでした。なんか損をしてたかもなあ。