アカウント名:
パスワード:
どういったことを心配しておられるのか良く分からないのですが、Common Lispは言語仕様に関してだけ言えば、 多人数で問題が起こる理由は特に無いように思います。
まず、大きなプログラムを分割して複数のグループで作っていくということであれば、 Common Lispにおいて典型的には、packageで分割することが考えられます。 packageというのは名前空間を分割する仕組みです。 PythonやRubyにも似た機能があると思いますが、 外部に対してexportする名前と内部でだけ使うinternalな名前を区別したりできます。 package名とexportする名前のところで、しっかりインタフェースを擦り合わせておけば、 各package内は他の部分に影響されずに実装できます。理屈の上では。
muさんのコメント [srad.jp]を見ると、 Lispではなんでもかんでもリスト構造で表現するという印象があるように読めなくもないのですが、 実際にはCommon Lispでも構造体を作ることができ、内部表現が変わってもそれに対するインタフェースは変えないでおく、 といったことも一応できます。構造体参照はアクセサ関数経由になりますので、アクセサ関数の形さえ変えなければ、後からどうとでもなるということです。ですので、 「その場限りで構造決めて，どんどん先へ行」ってしまっても、後でプログラムの他の部分を変更することなく、 構造だけ考え直すとかいうことはできます。最初に決めたインタフェース自体が駄目だった場合苦労するのは他の言語同様ですが。
「クラス指向」でないと駄目ということでしたら、 Common Lisp仕様にはCLOS [wikipedia.org]というオブジェクト指向システムが含まれています。 これはANSI仕様にも入っていますので、ANSI Common Lisp準拠の処理系(SBCLとか)なら使えるはずです。 C++やJavaとはちょっと毛色は違いますが、クラスベース(ECMAScriptなどのようなプロトタイプベースでなく)オブジェクトシステムになっています。
クラス指向の言語だとオブジェクトのインターフェースのすりあわせとかその資料化とかに一番時間使う
……というように、言語仕様上は多人数開発もOKかと思うのです。 しかし、大きなプロジェクトをCommon Lispで立ち上げるのが難しいとしたら、 それはやはりmuさんも指摘しておられるように、Lispを使える開発者が集まらないという点に問題があるんだと思います……。orz ;; 最近そこそこ多人数なC++でのプロジェクト内で「ああっ、ここLisp(もしくはScheme等々)ならもっと楽に書けるのにっっ」とか ;; (心の中で)叫ぶ日々を送ってます。(T_T)
大規模って程大規模ではなかった（二十人は越えなかったかな？）ですけど、 数年間、 主に Common Lisp で開発してた研究プロジェクトに派遣されてたことがありますよ。 AI・自然言語処理がらみでした。
処理の速さよりも、 特定分野での書き易さ（開発の速さにつながる）でしょうかね、 Lisp の利点は。 『手続き』ではないものを、 わざわざ『手続き』に翻訳しなくてもいいので。
;; Native Lisper ではないので、 ;; あんまり偉そうなことは言えないけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
関連ストーリー (スコア:0)
ってあーた、五月のトピで１コメントって何よ、ものすごく関心薄い？
興味本位で聞きますがLISPで大規模(人数的にの意味ね)開発する事とかあるのでしょうか？
言語環境とか言語の生まれのせいか、一人か二人でコツコツフィードバックループで作る様な気がするんですが。
#個人的にはemacs-lisp以外あまりさわったことないんでAC
Re:関連ストーリー (スコア:3, すばらしい洞察)
ソフトウェア的なパーツがあらかじめ想定できるような簡単な問題なら，Lispを使うまでもないかも．
一人で開発しているだけなら，リスト構造のその場限りで構造決めて，どんどん先へ行けるという良さがあるのですが，人間が増えるとそうもいかなくなってくるのはどんな言語でも同じ．関数やマクロのすりあわせとか，いいかげん？なリストの使い方ができなくなってくると大して変わらないか．．
＃多人数開発はしたことないけど，いろんな意味で開発の効率は数段は違うような気がしますけどね．
Re:関連ストーリー (スコア:0)
多人数でソフト書くときってクラス指向の言語だとオブジェクトのインターフェースのすりあわせとかその資料化とかに一番時間使うじゃないですか。(最初にきっちり決めておいてプログラマの責任境界面をちっちゃくするかわりに大人数で分割処理的な）
LISPにおけるその界面って何なのだろうって言う疑問なわけです。
で２，３の書き込みを見てｵﾓｯﾀのは、やっぱり大人数でなく人数的に小規模ですまして
書き換えサイクルの短い開発を高速で回す感じなのだなぁと言うところでしょうか？
Re:関連ストーリー (スコア:2, 興味深い)
せいぜい10人まで。2〜3人が一番多いかな。
オブジェクトのインタフェースがプロジェクトの最初の方で決められるような
仕事なら、Lispを使う必要も無いと思います。
だいたい、最初は何がどうなるのかよくわからん状態なのを手探りしつつ
時には力業でわっと一度動かしてみる、ってな感じの話が多いです。
オブジェクトのインタフェースが決まったら、実装も出来ちゃってるって
パターン。そういう仕事だと人数増やしても効率あがらないですしね。
Re:関連ストーリー (スコア:2, 参考になる)
どういったことを心配しておられるのか良く分からないのですが、Common Lispは言語仕様に関してだけ言えば、 多人数で問題が起こる理由は特に無いように思います。
まず、大きなプログラムを分割して複数のグループで作っていくということであれば、 Common Lispにおいて典型的には、packageで分割することが考えられます。 packageというのは名前空間を分割する仕組みです。 PythonやRubyにも似た機能があると思いますが、 外部に対してexportする名前と内部でだけ使うinternalな名前を区別したりできます。 package名とexportする名前のところで、しっかりインタフェースを擦り合わせておけば、 各package内は他の部分に影響されずに実装できます。理屈の上では。
muさんのコメント [srad.jp]を見ると、 Lispではなんでもかんでもリスト構造で表現するという印象があるように読めなくもないのですが、 実際にはCommon Lispでも構造体を作ることができ、内部表現が変わってもそれに対するインタフェースは変えないでおく、 といったことも一応できます。構造体参照はアクセサ関数経由になりますので、アクセサ関数の形さえ変えなければ、後からどうとでもなるということです。ですので、 「その場限りで構造決めて，どんどん先へ行」ってしまっても、後でプログラムの他の部分を変更することなく、 構造だけ考え直すとかいうことはできます。最初に決めたインタフェース自体が駄目だった場合苦労するのは他の言語同様ですが。
「クラス指向」でないと駄目ということでしたら、 Common Lisp仕様にはCLOS [wikipedia.org]というオブジェクト指向システムが含まれています。 これはANSI仕様にも入っていますので、ANSI Common Lisp準拠の処理系(SBCLとか)なら使えるはずです。 C++やJavaとはちょっと毛色は違いますが、クラスベース(ECMAScriptなどのようなプロトタイプベースでなく)オブジェクトシステムになっています。
というような開発方法をとりたければ、CLOSベースでインタフェースを決めるのも手かもしれません。 実際にはpackageも一緒に考えることになると思いますが。……というように、言語仕様上は多人数開発もOKかと思うのです。 しかし、大きなプロジェクトをCommon Lispで立ち上げるのが難しいとしたら、 それはやはりmuさんも指摘しておられるように、Lispを使える開発者が集まらないという点に問題があるんだと思います……。orz
;; 最近そこそこ多人数なC++でのプロジェクト内で「ああっ、ここLisp(もしくはScheme等々)ならもっと楽に書けるのにっっ」とか
;; (心の中で)叫ぶ日々を送ってます。(T_T)
Re:関連ストーリー (スコア:0)
Common Lispが出てきた当初って、引数に型を宣言してたりするのが、大規模化や
多人数で大きめなことや、可読性や保守性をあげる目的だったように記憶してます
ね。 (print (eval (read)))で、readしてからなんだったかようやく考えてくれる
せっかくの寛大さをなんてことしやがるんだと思ったもんですが。（笑）
#おまけにタートルだとか亀だとか、言い出しっぺの個人的な趣味がまたこれ、ほら
Re:関連ストーリー (スコア:1, 参考になる)
こちら [msi.co.jp]のリンクはってみますね。
Re:関連ストーリー (スコア:0)
(1) 納豆相手にくさやを出して、納豆の方が臭い
(2) 納豆相手にくさやを出して、くさやの方が臭い
(3) 納豆相手にくさやを出して、どちらも臭い
(4) 納豆相手にくさやを出して、どちらも芳しい
Re:関連ストーリー (スコア:2, 参考になる)
大規模って程大規模ではなかった（二十人は越えなかったかな？）ですけど、 数年間、 主に Common Lisp で開発してた研究プロジェクトに派遣されてたことがありますよ。 AI・自然言語処理がらみでした。
処理の速さよりも、 特定分野での書き易さ（開発の速さにつながる）でしょうかね、 Lisp の利点は。 『手続き』ではないものを、 わざわざ『手続き』に翻訳しなくてもいいので。
;; Native Lisper ではないので、
;; あんまり偉そうなことは言えないけど。
Re:関連ストーリー (スコア:2)
> ってあーた、五月のトピで１コメントって何よ、ものすごく関心薄い？
日付は2001.5.10ですよ．
そして，このスラッシュドットジャパンが始まったのは2001.5.28
http://srad.jp/about.shtml [srad.jp]
Re:関連ストーリー (スコア:0)
プロジェクトへの導入 (スコア:1)
１）Lisp インタプリタ作る
２）簡易言語的な wrapper 作る
３）目的に応じた要素篇を人海戦術で作らせる
とかね。
Re:関連ストーリー (スコア:0)
# 大規模とは言えないですけどね、、、
Re:関連ストーリー (スコア:0)
computer algebra system(数式処理)のMAXIMAが思い浮かびます。
数学とLispの両方に通じていないといじれない為、大規模とはいえませんが。
amd64なマシンでは、clisp,sbcl等が使えるので、 暇を作って新しいsbclを試してみようとは思います。