オープンソースに向いた言語はどれ？

takusi 曰く，"オープンソースには当然、何がしかのプログラミング言語が必要です。個人でプログラムを書くなら、本人が一番好きな言語を使えば良いのですが、オープンソースでは、ソースを公開し、時に共同開発になることもあるので、プログラミング言語の選択は、個人のケースとは違ってきます。皆さんは、オープンソースでは、どのような基準で言語を選択し、実際、どの言語を使っていますか？"

以前、プロジェクトを失敗に導くプログラミング言語 という記事があったが、この中では実績として C, PHP あたりが妥当なところかと言われている。実際、/.-J の参加者のうち、どのくらいの人がオープンソースプロジェクトのリーダーになっているのかはわからないが、「自分でこういったものを開発するならば」何が良いと思う？

逆転の発想

[visha (779)]

自分がらぶらぶな特定の言語を広めたいがためにそいつを使ってキラーアプリを開発するってケースはありそう。例えば、PythonとかRubyなんかで開発してるアプリやライブラリのかなりの部分が、少なからずそういう動機を持ってるんじゃないだろうか。

プログラマって、「言語は道具 用途によって最適なものを」って理屈ではわかっていても、なかなか完全には割り切れないものらしい(少なくとも俺はそう)。

メジャーな言語がいい

[kubota (64)]

なんともつまらない意見ですが、そういうことだと思います。

そのほうが、開発に協力してくれる人を得やすいですし。具体的には、C、C++、Perl あたりではないでしょうか。

この指針の問題点は、みんながみんなこの指針で行動したら、新しい言語はいくら良くてもオープンソース界では普及しない、ということになってしまう、ということです。ですので、まねしないでください :-)

ちなみに、ぼくがやってる language-env ですが、これは、別の理由から Perl を使用しています。その理由は、Debian で Perl はいつでも利用可能とされていることです。(逆に、Debian は、Perl に不具合が起きるとシステムの根本的なところから動かなくなってしまいます)

何でもいいんじゃない？

[dai75 (557)]

ソフトに適した言語を選ぶがよし。
いいソフト書けば自然に仲間は増えますよ。

--
-- wanna be the biggest dreamer

他には

[takusi (5869)]

ありきたりになってしまうので、他の方が指摘していない点を。

1. 特許や面倒なライセンスが存在しないこと(そんな言語が存在するかは知りませんが。)
2. コンパイラが特定のベンダーの商品でないこと(Visual Basicとか)
3. 特定のOSやhardwareに依存しないこと
4. 方言が少ないこと(Pascal系は方言が多いのでいまいち)
5. ソースコードが特殊な形式ではなく、テキスト形式であること

最低限、上記の基準を満たしている必要があると思います。こんなところでしょうか。(なんか当たり前すぎる気もしますが)

--
rm -rf /bin/laden

Re:オープンソースに向いた～は？

[argon (3541)]

5.オープンソースに向いた職業は？→無職

働かないでも食べていけるということ？
遺産を食いつぶしてダメなソフトを作りつづける御曹司とか。

Re:C++

[rug (55)]

mozilla.orgのC++ portability guideとか読むと、頭痛くなるかも。

Re:オープンソースに向いた～は？

[bravo (1225)]

5.オープンソースに向いた職業は？→PC関係上がりのPC関係以外の職業

だったりして:-p

「英語」の落とし穴

[brake-handle (5065)]

言語は英語としても、日本人がこういうと、それはus-asciiで書くことをimplyします。しかし、ヨーロッパ人にとってはこれはiso-8859-1で書くことを意味するようです。

実はFreeBSDのソースの中で、Soren Schmidt(oはウムラウトつき)が自分の名前をiso-8859-1で書いています。これを日本向けのchartset自動認識などがあるツールで読み込むと悲惨な結果になります。

というわけで、ヨーロッパ人などを巻き込む場合にはcharsetに気を付けましょう。

Re:「英語」の落とし穴

[kubota (64)]

日本人は、外国人が読むかもしれないメールには、気を使って、ASCII 文字だけを使います。ついうっかり、とかでなければ、JIS X 0208 文字を使う人はいません。

ISO-8859-1 使いの人たちは、そのへん、どう思ってるのでしょうね。世界には ISO-8859-1 以外を使っている人々もいるというあたりまえの事実を、分かってないんでしょうか。

いや、こっちが一方的に気を使わないといけないなんて、不公平じゃないですか。

順当なところだと・・・・・

[znc (2768)]

やはりCかな・・・・
ライブラリやマクロはともかく(というかそれが最大の問題なんだけど),
言語仕様そのものには方言もあまりないので,
特に他機種展開には有効だと思います・・・・・

あと,理想だけで話ができるのならjavaはかなりいけるのでは
無いかと思います.
javaなら(原則として)ライブラリ関係も共通化していますから
面倒な機種ごとの処理分けがなくてかなり便利ではないかと思います.
# 現実では全然なのであまり使えないのでしょうけど・・・・・

--
『今日の屈辱に耐え明日の為に生きるのが男だ』
宇宙戦艦 ヤマト 艦長 沖田十三氏談
2006/06/23 JPN 1 - 4 BRA

GNU coding standard

[oku (4610)]

GNU coding standard では 最も良い選択肢は C となっていますね。 取り敢えず参考文献という事で。

開発言語選択のクライテリア

[gori (3642)]

単純にオープンソースだからこれがいいという解はないでしょう。
目的に対して適した言語であるかが第一

その前堤であえてクライテリアを挙げると
0. 合目的的か
1. 動作環境への制約
      javaやperlはそれぞれの動作環境が求められるが、それでいいか
2. パフォーマンス
      インタプリタ言語かコンパイル言語か
3. プロジェクト管理
      複数人で共同開発する際の、役割分担の手法、品質管理手法→オブジェクト指向の適用可否
4. 発案者のスキルと設計手法への適合性
      そもその発案者が知っていて、習熟している言語でないと無意味

まず、4番のクライテリアから幾つかの言語絞って、他のクライテリアを考慮して決定するべき。
私は、メール転送サーバを作っていますが、開発言語にはC++を選択しました。(未公開。近日公開予定)
パフォーマンス要件から、インタプリタ言語は捨て。
習熟している設計手法がOOなのと、STLが使えるのが魅力なので、C++。

オープンソースの場合なら

[Futaro (2025)]

他の目的や条件は置いといて、とにかくオープンソースが目的、として、まず考えなくてはいけないのは、以下の点と思います。

１．開発者のあいだで十分に広まっていること
２．その言語が動く環境も一定のものが広まっていること
３．言語そのものの仕様や標準的に使われるライブラリの仕様に方言が少ないこと

やはり「プログラマの一般教養」的な位置を占める「C」かな？というのが、妥当と私は思いますが。

オープンソースに向いた～は？

[Ryuzi Kambe (38)]

ちょっとオフトピックで、

オープンソースに向いた～は？シリーズは継続して欲しいかな。

1.オープンソースに向いたプラットフォームは？
2.オープンソースに向いたディストリビューションは？
3.オープンソースに向いた開発コミュニティは？
4.オープンソースに向いた雑談コミュニティは？
5.オープンソースに向いた職業は？
6.オープンソースに向いたライフスタイルは？

--

- Ryuzi Kambe -

Re:GNU coding standard

[kubota (64)]

Linux カーネルの Documentation/CodingStyle に、

First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture.
(まず、GNU コーディング規約を印刷してください。しかし読むためではありません。焼くためです。これは象徴的な意思表示です。)

ということが書いてあるのは有名な話です。が、にもかかわらず、Linux カーネルは (GNU コーディング規約に従って:-) C で書かれています。

最も良い選択肢はC

[rug (55)]

で、様々なlanguage bindingsを用意すると。そうすればみんなが幸せになれる、かも。

ただ、現状はlanguage binding地獄というかglue code地獄であると言えなくもないな。

Re:順当なところだと・・・・・

[zeissmania (3689)]

＞理想だけで話ができるのならjavaはかなりいけるのでは無いかと思います
私も理想だけで言うならJavaがよいと思います。
つーか個人的にすっかりJavaな体になってて、Cじゃプログラム書く気になれないんですが(笑)
Javaのライブラリは、基本ライブラリはこなれてきていると思いますけど、GUI周り要するにSwingがまだまだ安定していないので、これからですねぇ。
後、C++をそのままJavaに置き換えただけの似非Javaプログラマも多いのが問題かなぁ？

Re:他には

[rug (55)]

4. 方言が少ないこと(Pascal系は方言が多いのでいまいち)

じゃあLispだめじゃん。

rms曰く「Tclを使うべきではない」

[rug (55)]

というのを思い出して、調べてみたら、こんな文書がありました。

GNU 機能拡張用言語計画(GNU Extension Language Plans)

しかしながら、現状のGuileは単なるSchemeの変種に過ぎないし、 ここに書かれている目標からは遥かに遠いところにいるように思います。

いっそ

[argon (3541)]

gas のインタプリタとか?

英語のドキュメント

[kt (4556)]

ソースコードをどの言語で書くかはさておき、国際的なひろがりのために、英語のドキュメントも書いたほうがいいでしょう。

Re:GNU coding standard

[crouton (9)]

「Cで書くけど、GNU規約の変態インデントは嫌だからステ」という意味だと思いますが。

# どうしてもあの括弧の位置のメリットがわからんのよ。

--
"Quidquid latine dictum sit, altum videtur."

誤解が生じる原因

[kubota (64)]

形容詞の限定用法か形容用法かの違いやね。 限定用法と解釈すれば、「C (で書かれたプログラム) にもいろいろあるけど、そのなかで可読性の低いもの」という意味だし、 形容用法なら「C (で書かれたプログラム) はそもそも可読性が低いから」 という意味になる。典型的なあいまい文です。

Re:書き方も大事?(Re:別に)

[brake-handle (5065)]

私はもっぱらUnixカーネルしかいじらないんですが(本業はどうした)、例外処理を実装するためにgotoを使うことがあります(もちろんC++などは使えない)。例えば...

int
some_system_call(...)
{

int errno;
errno = 0;

...

mutex_lock(&some_mutex);

...

if (...) {

errno = EBUSY;
goto err;

}

...
err:

mutex_unlock(&some_mutex);
return (errno);

}

というように、エラーが起きてもロックを確実に解除したい場合に使えますね。if文の中でmutex_unlock()を直接呼び出すと却ってごちゃごちゃしますし、エラーで抜ける個所が複数あるとロックを解除し忘れるなどの問題があります。

Re:オープンソースに向いた～は？

[rug (55)]

7.オープンソースに向いた食事は？→たんしちゅー
8.オープンソースに向いた飲物は？→ウィルキンソン ジンジャーエール

Re:逆転の発想

[dai75 (557)]

言語に合ったキラーアプリを開発ってまさに
「アプリに合った言語」
だと思いますよ。
正しくは「言語に合ったアプリ」だが逆もまた真なり。

--
-- wanna be the biggest dreamer

Re:C++

[shuna (99)]

個人的に Embedded C++ に期待してるんだけど
(仕事のターゲットがPCじゃない事もあって)
全然話題になりませんね…

っていうか、
http://www.caravan.net/ec2plus_j/index.html
はどーゆー事よ。

Re:C++

[takusi (5869)]

それがそう簡単ではないのです。言語というのは、当然、仕様だけで構成されているわけではなくて、ライブラリも重要です。ライブラリがC++のどの言語仕様に基づいているかも厄介な問題です。例えば、STLが使いたいとなると、例外と、完璧なtemplate仕様をコンパイラがサポートしている必要があります。

--
rm -rf /bin/laden

Re:順当なところだと・・・・・

[Artane. (1042)]

確かに、私も速度やMPUリソースの消費を考えなければJavaが最もやりやすいと思いま す。
実際、「これから」OOPを勉強する人には、Javaが最適だと思いますし。
しかし、Javaの問題点は汎用性重視のためにVirtual Machineをかませないといけない あたりで、ここが凄い癌になっていると思うのですよ。
速度の面ではJITコンパイラの併用でかなり改善されますが、リソースの消費は頭が痛いですし、ドライバを書くには結構きつそうな言語ではあります。
# そういう意味ではApplixのJ-Tronなんかの実装には興味がある

要は、未だJavaの目指す理想に現実が付いていっていなくて、JavaのソースなりバイトコードなりからMPUネィティブなオブジェクトを吐かせるしか現実への解決策がないと言う現実があります。

# GNUのgcjって、こういう物でしたっけ？

TransmetaのCode Morphing(TM)技術とかでJavaのバイトコードが動くMPU…特に組み込 み用…が出来ないか。と言うのが正直なところ。
組み込み用Java-MPUが出来れば、今の携帯電話のような無茶な開発状況のソフトウェア の開発TCOを激減できるのに…って思うのですが。

Re:順当なところだと・・・・・

[zeissmania (3689)]

＞ドライバを書くには結構きつそうな言語
Javaのクラスライブラリもその辺りはNatvieだらけで、実際はCで書かれていますからね。VM自体がCですから(笑)

＞GNUのgcjって、こういう物でしたっけ？
そういうもののようです。私もまだ使ったことはないですが。
後、JBuilderとかVisualCafeでネイティブコート吐くコンパイラ付いてたはずです。Windowsのみの対象だったと思いますけど。
けどネイティブにしても速くないみたいですけどね。

＞Javaのバイトコードが動くMPU…特に組み込 み用…が出来ないか
JavaChipはJavaが登場した頃から構想はありますけど、出てきませんからねぇ。

Re:GNU coding standard

[crouton (9)]

> Emacs の cc-mode を冗談抜きで使っている方

とてもじゃないですが "gnu" スタイルは耐えられないので、お手軽に "k&r" とか "bsd" とかの他の既成のスタイルを使うか、いずれかをベースに自分でガシガシカスタマイズするのが吉。

--
"Quidquid latine dictum sit, altum videtur."

Re:順当なところだと・・・・・

[bero (5057)]

＞＞Javaのバイトコードが動くMPU…特に組み込 み用…が出来ないか
＞JavaChipはJavaが登場した頃から構想はありますけど、出てきませんからねぇ。

ARM CPUは通常32bit命令長ですが、16bit命令長のthumbモードってのがあるシリーズがあって、容量制限のきつい組み込み（携帯ゲーム機含む）用途だとよく使われてると思いますが、同様にJava bytecodeを実行できるモードのついたシリーズもあるようです。

Re:GNU coding standard

[Average (3404)]

単純にRMSがリクルートして来た人材が、RMSも含めてLISP屋さんだからだと思います。
RMSもMITのAIラボ出身だから、人脈がLISP系なんじゃないのかな？ただ広く普及させるためにＣを使っているだけで。

--
-----------------
#そんなワタシはOS/2ユーザー:-)

Re:他には

[rug (55)]

結構良いんだろうと思います。 ただ、たしかFPってまだRAD環境は無いんでしたよね？

一応、LazarusというProjectがあるようですね。現時点で使い物になるかどうかはよくわかりませんが。

Re:picoJava

[zeissmania (3689)]

富士通のサイト覗いてみましたが、未だに評価用のままですね (-_-;;;;

Re:cvsとCVSup

[rug (55)]

ん?? なぜ

例えばperl(やruby^^;)でcvsを作ったら、

という文章が、「この人はcvsとCVSupが同じものだと思っている」という解釈につながるのですか? 理解に苦しみます。

POBox

[G7 (3009)]

すげー蛇足でオフトピですが1つだけ。

>日本語入力ソフトは日本人か、日本語のできる人にしか作れませんね。

俺もそう信じていたんですが、少し前、例外に出会ってしまってビックリしました。

POBoxです。

あれの原理って全然日本語に依存してないんですよねえ。
単に、複数の単語を並べて書いても互いが干渉して変化したりしない言語、であれば何でも良いし、
もしそうでない言語でも、逃げを打つ手は幾らでも有りそう。
それどころか、対象が「言語」である必要すら無いじゃん？という議論も何処かで見かけたことが(^^;
あれがやってることは単に「Mapする」ことと「選ぶ」ことだけ。

にも関わらず日本語入力ソフトとして(入力デバイス次第では)凄くいい感じ。

いやはや、作者増井さん、凄いです。感服。

Re:GNU coding standard

[takashi (105)]

C言語のBNF文法に沿ってインデントを考えれば、
GNU coding standardは非常に合理的な
インデントだと思います。

「文」が「複合文」であろうがなかろうが、
「if文」は

  if (条件)
    文
  else
    文

のような構造になっている、ということを、
素直に表現しているだけのように思います。

たまたま「文」のところが「式 + 『;』」ならば

  if (条件)
    式;

になるし、たまたま「文」のところが
「複合文」ならば

  if (条件)
    {
      ・・・
    }

になるわけです。
というわけで、私は好きです:-)

向いているかというより

[sinkope (230)]

向いていない言語を理由と共に挙げていき、
残ったものが「比較的宜しい」となるのではないかと。

Re:向いているかというより

[takusi (5869)]

C++とPerlは言語仕様が安定していないからだめとか。

--
rm -rf /bin/laden

C++

[tkh (235)]

C++は既に仕様がフィックスされていますよ。

Re:オープンソースに向いた～は？

[gori (3642)]

模範解答になるかな?

1.オープンソースに向いたプラットフォームは？→Windows系ではない。貧乏人には辛すぎ。同様に、メインフレームでも無い。
2.オープンソースに向いたディストリビューションは？→GNU AutoXXXが使えること
3.オープンソースに向いた開発コミュニティは？→SourceForge
4.オープンソースに向いた雑談コミュニティは？→/.
5.オープンソースに向いた職業は？→無職
6.オープンソースに向いたライフスタイルは？ →ヒッキー

Re:C++

[takusi (5869)]

でも、コンパイラの対応が不十分だったりします。全ての人に(開発者以外も)、最新のC++の仕様にmatchしたコンパイラを強要することはできないでしょう。

--
rm -rf /bin/laden

Re:GNU coding standard

[takusi (5869)]

ちなみに、GNU coding standardの日本語訳はこちらにあります。

--
rm -rf /bin/laden

Re:他には

[takusi (5869)]

追加。
6. ソースコードが英語以外の言語(日本語)で書く必要がないこと。(昔、日本語でかけるプログラミング言語がありましたよね。)

--
rm -rf /bin/laden

別に

[minz (3213)]

なんでもいいと思いますけれどね...

大切なのはインターフェイスとアルゴリズムが公開され、
それがきちんとインプリメントされているかを検証できるコード、であれば。

可読性の低いCなら、アセンブラでも一緒っす。

＃ハンドアセンブルな「オープンバイナリ」ってのでもいいのか？とか :) 読めればそれも結構でわないかと。

--
みんつ

Re:別に

[takusi (5869)]

> 可読性の低いCなら、アセンブラでも一緒っす。
Cの可読性は悪くないですよ。それをいったら、Perlのコードは記号だらけだし、Lispは(の嵐だし。

--
rm -rf /bin/laden

Re:別に

[kimura (2954)]

「Ｃで書かれたプログラムは可読性が低い」と言っているわけではなくて、「メジャーな言語と認知されているＣで書いたとしても、書き方によっては可読性が低くなるし、もしそんな状況になったらアセンブラでも変わらんよね」ってなことでしょう。

書き方も大事?(Re:別に)

[znc (2768)]

: 可読性の低いCなら、アセンブラでも一緒っす。
これはどの言語でも同じですよね・・・・
- 統一のとれたインデント
- ブロックごとの分かりやすいコメント
- IN/OUTが分かりやすいルーチンデザイン
このぐらいはしっかりしないとだめでしょうね・・・・

# ところで,(ステートメントの)gotoは
# やっぱり使わない方がいいですか?
# 私も使わないようにはしていますが・・・・

--
『今日の屈辱に耐え明日の為に生きるのが男だ』
宇宙戦艦 ヤマト 艦長 沖田十三氏談
2006/06/23 JPN 1 - 4 BRA

Re:別に

[takusi (5869)]

それならいいんだけど、そうは読み取れない気が。
> 可読性の低いC

--
rm -rf /bin/laden