新しいOSSプロジェクトの約半数がCを採用 51
タレコミ by hide.jikyll
hide.jikyll 曰く、
ソースコードライセンス管理製品を開発する米Black Duck Softwareの調査によると、新しいOSSプロジェクトの約半数が開発言語にCを採用しているそうだ（The Registerの記事）。Black Duckによると、2008年に開始された17000のプロジェクトのうち47％がCを採用しており、2位 Java 28％、3位 JavaScript 20％、4位 Perl 18％と続くそうだ。4位までの合計で100％を超えてしまうが、これは多くのプロジェクトが複数の言語を併用しているため。ちなみにPHPは11％でRubyは6％とのこと。ライトウェイト言語がもっと使われているかと思ったが意外な結果である。
C++ のライブラリを C で書き直す (スコア:4, 興味深い)
移植性を高めるために C++ から C に書き直したPDFのライブラリ、なんていうのもあります。
http://www.ipa.go.jp/about/jigyoseika/05fy-pro/mito/2005-1175d.pdf [ipa.go.jp]
注意：pdf です。
Re: (スコア:0)
あれ、C++とCって移植性にそんな段違いの違いってあるのですか？
Re:C++ のライブラリを C で書き直す (スコア:2, 参考になる)
世の中には、Cコンパイラしか存在しないCPUというものがたくさんあるのですよ…
fjの教祖様
Re: (スコア:0)
まずは具体例を挙げてもらおうか
Re:C++ のライブラリを C で書き直す (スコア:2, 興味深い)
http://www.semicon.toshiba.co.jp/product/micro/900family/index.html [toshiba.co.jp]
なんかどないだす?開発キットはここ
http://www.semicon.toshiba.co.jp/product/micro/900family/900/tool/index.html [toshiba.co.jp]
fjの教祖様
Re: (スコア:0)
C++はまだ細かいところでいろいろ処理系ごとに癖があるよ。
Re: (スコア:0)
驚いた。
何がって、PDFのライブラリ開発がOSS推進ならともかく、未踏でお金になるのか。
ⓒを採用 (スコア:3, おもしろおかしい)
Re: (スコア:0)
GPL信者か、はたまたアンチのFUD活動か、
Re: (スコア:0)
＞GPL信者
コピーライトがちゃんと守られてこそのコピーレフトだ。馬鹿も休み休み言え。
実行ファイルとか (スコア:2, すばらしい洞察)
実行ファイルを作る事を考えると、どうしてもLLは選択肢に含め難いのではないでしょうか。
javaは、開発者間の環境の統一とか考えだすと、面倒な印象があります。
ならば、先祖代々使ってきたc系の言語でいいじゃん、みたいな感じがあるのでは？
py2exe使用中 (スコア:1)
仕事では Java + PHP が多いけど
個人的には C/C++ + Python が多い．
で，Windowsな人にそれらのツールを配るときはpy2exe使ってます．
C++ と Python 使ってながらいまだに boost.python を使いこなせてないけど．
屍体メモ [windy.cx]
LL使っても軽くならないし (スコア:2, 興味深い)
「プロジェクト」なんて構えてやる場合だと, 当然のことながら再利用やメンテナンスってのが念頭に入ってきますし, それに伴って多かれ少なかれ事前の設計が必要になってきたりするので, LLの思いついたらすぐ作成ってパターンが利点にならないんですよね. きっちりと設計しちゃうとガーベージコレクションみたいな細部を除けば, Cみたいなプリミティブな言語もLLもコーディングの面では大差が無いし.
逆に性能やフットプリントなんかを気にし始めると, LLの場合は処理系自体の性能に加え, 処理系の内部処理なんかまで考慮しなくちゃならなくなるので, ちょっときついんですよね. その点, Cあたりだとアルゴリズムさえ極端に間違えなければ, コンパイラの最適化にまかせればコードから想像できる範囲でお手軽に高速化できちゃうんで, ついついCに逃げちゃいます.
Re:LL使っても軽くならないし(オフトピ) (スコア:2)
#ちょと辛口かも＾＾
#LL使用者にも、聞こえが良くないかも・・・；；
> それに伴って多かれ少なかれ事前の設計が必要になってきたりするので,
> LLの思いついたらすぐ作成ってパターンが利点にならないんですよね.
適材適所かと思います。「LLの思いついたらすぐ作成ってパターン」
が重厚な設計からのプログラミングに合わないのは当然でしょう。
LLの利点は「プロトタイプ」にあります。
ある人は「ワンライナ」、ある人は「書き捨て」、etcとか言うかなあぁ。
ここではCですのでCを前にたてますが、
LLの良さは「手をかけはじめてから実働までの時間が短い」につきます。
Cでごそごそしているよりは、LLでぶっちゃけた方が早いのはのですよね；。
LLは背後に(言語仕様・標準ライブラリ)多大な資産を持っていますから、
直に出来る事は多いんだなあぁ・・・。
Cにはそれが無いですから・・・；。
でも、仕事で書き始めたプロトタイプなら、その後にも使える様に最初から
書いていてくれると助かるのですが・・・。
#大抵は、仕様書にある一部分の試験で満足しちゃて、後々まで使える様に
#書く人は少ないかなあぁ；；；
> きっちりと設計しちゃうとガーベージコレクションみたいな細部を除けば,
> Cみたいなプリミティブな言語もLLもコーディングの面では大差が無いし.
「ガーベージコレクションみたいな細部」って、Cと比べれば大きな差です。
コーディングの面ではとはどんな点でしょうか。
手続き型言語でコーディングすれば、どんな言語でも似たようになります。
思うに、ちゃんとしたLL使いの方に会っていないのかも。
一度、他の型の言語に触れてみると良いかも。
> 逆に性能やフットプリントなんかを気にし始めると
ここはLLの出番では無いでしょうw^^。
無いかと思います。Cでちゃんと書かれていれば無いでしょう。
リソ～スはLLでは余り、気にしませんから。
#JavaがWebで"しか"使われていない理由がここにあります。
> Cあたりだとアルゴリズムさえ極端に間違えなければ,
Cに限りません・・・；；
アルゴリズムが的確ならLLでも十分に動作しますよ\^^。
結局、適材適所だと思います。
閑話休題
Re: (スコア:0)
三行（Re:LL使っても軽くならないし(オフトピ)） (スコア:2)
適材適所です。
閑話休題
Re: (スコア:0)
で、「プロジェクト」なんて構えてやるものはLLにとって「適所」ではないというだけの話でしょ。
わざわざ長文書いて反論するような要素がどこにも見当たらないのですが。
Re:三行（Re:LL使っても軽くならないし(オフトピ)） (スコア:1)
同意。読み終えて「既出だ」と思いました。
LIVE-GON(リベゴン)
Re:LL使っても軽くならないし (スコア:1)
lambdaやマクロ（言うまでもないけど、Cとかのヤツとは違う）なんかを使うと、かなり差が出ちゃいますよ;-)
#言語が限定されてるような気がしないでもない
お察しの通り、超濃緑茶です。 そう呼んだほうがいいでしょう。
Re: (スコア:0)
>lambdaやマクロ
そうそう。
その言語が無名関数をサポートしてるかどうかで
コーディング量なんてガバっと変わってしまうよね。
(広く言えばこれは「リテラルの充実」の問題です。
無名関数はつまり「関数リテラルを書く」という機能。
ほかに配列やHashやRangeなどなど…といった
美味しいリテラルが揃ってる言語のほうが「便利」。
あと文字列リテラルに複数行機能や変数展開機能があると更に「便利」。)
(あとRubyのModuleみたいな「改善された実装多重継承」も美味しいぞ)
スクリプトっぽい言語は世の中に色々あるけど、
ラムダ/無名関数みたいに
「決定的にコードを短くしてくれる武器」
を搭載した言
Re: (スコア:0)
そんなん言語使用じゃなくライブラリの問題じゃん。それならC++にだって全て揃ってる。boostだけど
Re: (スコア:0)
なんだかんだと 今更どうも
あの娘(php)この娘(ruby)の ツールの山に
なやむハンサム ちょとつらいざんす
ネエC++ざんしょ ネエ
ざんす ざんす C++ざんす
あたしゃ貴女に ライ・ブラ・リー
Re: (スコア:0)
> その言語が無名関数をサポートしてるかどうかで
> コーディング量なんてガバっと変わってしまうよね。
そんなに変わらないよ。
goto文は強力で何にでも使えコードサイズを短くしてくれるけど、注意深いプログラマは大抵はifやwhileですませてしまう。
それと同じことです。
> 美味しいリテラルが揃ってる言語のほうが「便利」。
> あと文字列リテラルに複数行機能や変数展開機能があると更に「便利」。)
そりゃ便利ですし、局所的にはコード量も減らしてくれるでしょう。
でも、「プログラムのいたるところが」そんな有様では、やはりプログラムの構造を見直すべきだと思いますよ。
Re: (スコア:0)
さて、たとえ話ばかりでなんですが、こういうのはいかがでしょう。
純関数型言語の世界ではもちろん無名関数は空気のように使われていますが、破壊的代入は許されません。
破壊的代入の強力さはみなご存知だと思いますが、関数型言語に破壊型代入を導入してコード量がガバっと減った…という話は聞きませんよね（笑）
ちゃんと書いてよ (スコア:1)
リンク先に生データどころか調査方法の詳細へのリンクが見当たらないのですが、どこかに出ていますか？ 検証不能な伝聞情報では論評不能です。 すでに指摘されているように C++ を C に含めている可能性が高いですが、そうであるかどうか、記事からは読み取れません。そのために、できれば生データ、それが無理な場合は調査方法の詳細へのアクセスが確保できている必要があるのですが、リンク先記事にはどちらもありません。
ちなみに、C++はCに上位互換ではないので、C++をCに含めてはいけません。C++を含めるならば、ちゃんと C family などと呼びましょう。その場合は、当然、Objective-CやDも含めなくてはなりません。
リンク先記事は学生のレポートなら不可ですね。
Re:ちゃんと書いてよ (スコア:1, 参考になる)
> リンク先に生データどころか調査方法の詳細へのリンクが見当たらないのですが、どこかに出ていますか？
リンクされてる記事のコメントに書いてありました。
http://www.blackducksoftware.com/news/news/2009-01-21 [blackducksoftware.com]
Re:ちゃんと書いてよ (スコア:1, すばらしい洞察)
Dを含めたいなら、Bも含めましょうよ。
Re: (スコア:0)
ちくしょー、AもBもCも未経験な魔法使いだこんちくしょー。
#Dってアナ○でしたっけ？
Re: (スコア:0)
ア○ルはBに含みたいですね。
僕たちはDは妊娠って言ってました。
Re: (スコア:0)
なるほど、DSのDですね？
Re: (スコア:0)
D は DT だろ
Re: (スコア:0)
> 当然、Objective-CやDも含めなくてはなりません。
うーん、JavaやC#は含むんですか? 「C family」なんてあいまいな呼びかたより、はっきり「C/C++」とか限定列挙したほうがいいと思いますが。
Re: (スコア:0)
同意。元コメの人にレポートを採点してもらうのだけは勘弁、と思った。
Re: (スコア:0)
○ C++はCの上位互換ではないので
てにをはの間違いは学生のレポートなら不可ですね。
てにおは [オフトピ] （Re:ちゃんと書いてよ） (スコア:1)
「てにおは」の間違いの指摘を「の」にしているのですね。
# 「てにおはの」間違いでしたら、ごめんなさい；；
「に」と「の」違いはあまり違和感ないかと。
C++はCに｛上位互換ではない｝ので
C++は｛Cの上位互換｝ではないので
>>C++はCに上位互換ではないので
この意見には賛成です。これには
「CはC++に下位互換ではない」
も付け加えてください^^
たまに、上司に
「君はCができるのだからC++もできるだろう」
とか、その逆で
「君はC++ができるのだからCもできるだろう」
って言われてCやC++の部屋に来ちゃう子。
そのどちらも、CとC++の相違にドツボにハマってました；；
#そのどちらも御世話しなくてはいけないのは私；；。
#もっと、真実をみてよ、各部署の上司！！。
閑話休題
Re: (スコア:0)
Re: (スコア:0)
> 検証不能な伝聞情報では論評不能です。
ここは「アレゲなニュースと雑談サイト」だそうなので、「論評」ではなく「雑談」をなさってはいかがでしょうか。
Re: (スコア:0)
なぜこれがC familyになるの？これがfamilyならJavaもC familyですねｗ
Re: (スコア:0)
Re: (スコア:0)
と、引きこもりが申しております。
C言語ってのは (スコア:1, すばらしい洞察)
ハードウェア側から見ると、作りやすい言語なんだよね。
その他の言語は作りづらかったり、リソースを大量に要求するから扱えないんだよね。
アセンブラとCしか開発環境が無いものが多種大量にあります。
C++は含まれていると思う (スコア:0)
C++は含まれていると思う。
C#は含まれていないと思う。
Re:C++は含まれていると思う (スコア:1)
たまにはObjective-Cも思い出してやれ。
Re: (スコア:0)
たまには部門名も見てやれ。
Re: (スコア:0)
Objective C++がないぞっ～
＃AC
Re: (スコア:0)
でもC#は物の数では無いと思う。
#全部妄想なのでAC
良くも悪くも (スコア:0)
Ｃは自由な言語なので扱いやすいというのがあるんじゃないのかな・・・お仕着せのルールが多い言語にはアレルギー反応を示すプログラマも未だに少なくないですし。
それでもJavaが健闘してるのは大規模開発で頭を悩ませた結果キャンペーン的に採用された歴史的事由がある、JavaScriptはブラウザという手軽なプラットフォームで動く唯一の言語（VBS？そんなの知らん）という理由があるんじゃないのかな。
PerlはUnixに偏りすぎなのですが、コンパイルが不要なCとして使われている気がします。小さなプログラムならシェルから適当に書いて実行してしまえ・・・と。
なぜだ (スコア:0)
Re:なぜだ (スコア:1)
ここ [sourceforge.net]でsourceforg.netで最近ファイルのリリースのあった
Fortran関係のプロジェクトのリストが出ます。やはり、科学工学関係が多いですな。
love && peace && free_software
t-nissie