C言語は滅びるべきか 215
ストーリー by hylom
適材適所 部門より
適材適所 部門より
ソフトウェアエンジニア/作家/ジャーナリストのJon Evans氏によると、「C言語は滅びるべき」だそうだ（TechCrunch。なお、この記事のタイトルは「C/C++に死を」だが、原文タイトルにはC++は含まれていない）。
C言語はさまざまなソフトウェアの開発に使われており、必要不可欠なものとなっているが、いっぽうで原始的なメモリ管理機能しか備えておらず、それが脆弱性や不具合を生む原因となっているという。氏は代替としてRust言語を勧めており、特にパーサーや入力ハンドラなどの部分から、徐々にCのコードをRustに入れ替えていくべきであると主張している。
言語のせいじゃない (スコア:5, 参考になる)
C言語が悪いんじゃなくて、それを扱う人間のレベルが低いのが悪いということ、質を担保するためのコストがかなり高くなること、でしょう。
かといって、そう簡単にレベルの底上げができたり質を担保するためのコストが下がるわけでもなく、危ないことがやりづらい・起きにくい環境を選びましょう、というのは同意できて、オススメとしてRustを挙げるのも同じではありますが。
個人的な危惧として、未だにコンピュータを理解するにはC言語を知らないとだめだ、という原理主義者が結構いることです。そんなことないんだけどなぁ…。
ほえほえ
Re:言語のせいじゃない (スコア:4, 参考になる)
コンピュータを理解したいのなら一つくらいアセンブラを知ってほしいとは思う。
理解のためだけでいいので古いのでいい。
86系より68000系の方がコンピュータを理解するのはいいと思う。（個人の感想です。）
その上でC言語を理解してほしい。そうすると他の言語の何が良くて何が悪いのかよくわかり、使用用途がはっきりする。
＃まあ、タレコミ時のタイトルのC++は死んでいいと思う。（個人の感想です。）
Re:言語のせいじゃない (スコア:3)
先にLISPを知っててCを知ったとき、
struct list {
struct list *car;
struct list **cdr;
};
なんだって理解した。
forthも解りやすかった。すぐコンパイラ？が書けた。
Cがアセンブラにどう落ちるか理解すると、大体の言語は理解できると思うけどなぁ。
C言語はなんでもやらなければならない（≠なんでもできる） (スコア:3)
細かいところの始末が個人レベルに委ねられすぎというか、
だからこそもう少し高級言語使えや、となるのも理解はできる。
自分は、C言語を使えますが、別に知らなくてもいいんじゃね、という気はしてます。
C言語を使いこなすうえでの七転八倒は、確かに血肉となってますが、
掛けなきゃいけなかったコストかというとスゲエ微妙。
当時はそれしか選択肢がなかっただけで。いやTurbo Pascalとかはありましたけどね。
Re:言語のせいじゃない (スコア:2, おもしろおかしい)
> 人間のレベルが低いのが悪いと
つまり、滅びるべきは、人 間 ！
Re:言語のせいじゃない (スコア:1)
> 未だにコンピュータを理解するにはC言語を知らないとだめだ、という原理主義者が結構いることです。
「コンピュータを理解するにはC言語を知っているだけじゃダメだ」ならその通りでしょうけどC言語知らないとコンピュータを理解するのが厳しいのはその通りでしょう。
Re:言語のせいじゃない (スコア:2)
C, C++言語を知っていれば確かにJavaもカバーできないことはないけど、Javaでの「お作法」とかライブラリとかは想像もつかないから、結局最初から学び直しでしたね。
たかが｛ ｝をどこにくっつけるかで宗教的違いがぁっ！
SQLに至ってはインデントの仕方すら、まだ自分の中でさえ決まってないや。
Re:言語のせいじゃない (スコア:1)
> C言語扱える人は大抵別な言語も扱えるかと・・・？
COBOLとProlog以外はねwww
Re:言語のせいじゃない (スコア:1)
プログラミングができる人でコンピューターを理解したい・させたいならコンピューターの仕組みについて直接学ぶほうが早いだろう。その上で実際のプログラムの記述がコンピューターの動作の何になるのか考えていけばいい。
どうせなら低級言語でやるほうが良い。CPUの仕様書なり解説書なりを読んだ後でコンパイラを作るのが良いんじゃないのかね。そこまでする必要があるのかそこまでしたいのかは人によるんだろうけど。
道具の仕組みを知りたいなら道具を使うのではなく分解するほうが早い。
Re: (スコア:0)
＞未だにコンピュータを理解するにはC言語を知らないとだめだ、という原理主義者が結構いること
あと「C言語は万能で何でも出来る」という考えを実践するのもどうかと。
確かにコンピュータ言語の中では比較的何でも出来る言語ではあるんだけど
それは決して「どんなプログラムを書くのにも向いている」ではない。
awkのワンライナーで済む処理をCで書いて半日潰してデバッグしてる人が
隣にいたりすると「C氏ね」とか言いたくなる人がいるのもわからんでもない :-)
Re:言語のせいじゃない (スコア:1)
たいていの言語はチューリング完全だから向き不向きを考えなければ何でもできる
Re:言語のせいじゃない (スコア:1)
DASH村的にはそれで合ってると思うのですが、
原理主義者的には鉱石掘り出してNANDゲートを作り、全ての回路をそのNAND回路で構成するところから…
Re:言語のせいじゃない (スコア:2)
DASH村的には、土から何かを掘り出すんだったらまずは機械式計算機とかビー玉計算機辺りから始めてブートストラップしていく方がドラマチックなんじゃないでしょうか。
簡潔な道具は入門教材に適してる (スコア:4, すばらしい洞察)
C言語を学ぶと機械の気持ちが少しわかるよ
小学生にシャーペン使わせないのとC言語を学ばせたい理由は似てると思う
Re:簡潔な道具は入門教材に適してる (スコア:1)
他のもちっと高級な言語よりC言語が教育に適している所。
「書いた通りにしか動かない」ってのを教えるのに良い。
C言語よりもトラブルを起こし辛い言語も多く、そういう奴の方が実務では良いとも思う。
が、バグって悩んでってのをトラウマとして刻み込むには、C言語が一番。
最近のスマートなのはそんなのはカバーしてくれたりするからね。
自分は昔々、無茶苦茶高額だった頃のHDDの制御ミスってHDDからデカイ音が出たのが未だにトラウマ。
Re:簡潔な道具は入門教材に適してる (スコア:1)
それならアセンブラと機械語でいい。
中途半端に機械の気持ちが判ってもしょうがない。
老兵は死なず、ただ消え去るのみ (スコア:3)
新規プロジェクトではC++とかRustを考えたりできるでしょうが、
Linuxカーネルとか既存のプロジェクトではCが多いし、
C11や新しいライブラリを使えばモダンな書き方ができるので、
滅びろ。とまで言わないと思います。
＃それと今後のプログラマーの職の確保のために。
女房と言語は新しい方がいい (スコア:1)
と言ってるだけだな。
Cの何が悪いかちゃんと理解できればC++できちんとしたコード書けるだろ。
Windowsにはmanaged objectだとかもあるだろ。
取り替えられるならとっくにやってる＆あんたが知らないだけだと思われ。
Re:女房と言語は新しい方がいい (スコア:1)
GCが許容できない分野では今までまともな代替はなかったよ。
Re:女房と言語は新しい方がいい (スコア:1)
今のC++は複雑すぎるだろう。
新しい言語の成果をどんどん取り入れるのはいいが、頑なに互換性を守るために歪な文法を強いられる。
Cの良いところは、言語使用が小さく一行一行がどういう機械語に置き換わるか予想できるところ。
モダンC++は a = b;とだけ書かれていても凡人には想像も及ばないことが行われていたりする。
あと、C++のコミュニティが最悪だね。
間違った理解やちょっと古臭いコードを書くと「そんなことも知らないんですか。勉強して出直してきてください」だもんな。
Re:女房と言語は新しい方がいい (スコア:4, 興味深い)
どこかで似たような話を読んだなぁと思ったらブックマークに残ってた。
間違ったコードは間違って見えるようにする [joelonsoftware.com]
一般的に言って、私はものごとを隠してしまうような言語機能には恐れを感じる。次のコード
i = j * 5;
･･･を見れば、少なくともCであれば、j の値が5倍されて結果が i に格納されるということがわかる。
しかしC++の場合では、同じスニペットから分かることは何もない。まったく。C++で本当に起こることが何か知るためには、ぜんぜん違う場所で宣言されているかもしれない i と j の型を見つける必要がある。それはjがoperator*をオーバロードしている型の変数かもしれず、かけ算したときにはなはだ気の効いたことをやってくれるかもしれないからだ。そして i はoperator=をオーバロードしている型の変数かもしれず、また型が異なるために暗黙の型変換関数が呼ばれることになるかもしれない。そして何が起るか知るためには変数の型をチェックするだけでなく、その型を実装しているコードを見つける必要があり、そして，神よ救いたまえ、どこかで継承が行われていれば、コードが実際どこにあるのか自分でクラス階層をたどる必要があり、そしてどこかにポリモーフィズムがあれば、あなたは本当に難儀することになり、それは i と j の型がどう宣言されているか知るだけでは不十分で、実行のその時点における型が何か知る必要があるからであり、それにはどれくらいの量のコードを調べなければならないかわからず、停止性判定問題のおかげで、あなたは決してすべてをチェックしたか本当に確信することはできないのだ。(やれやれ!)
Re:女房と言語は新しい方がいい (スコア:1)
＞ Cの良いところは、言語使用が小さく一行一行がどういう機械語に置き換わるか予想できるところ。
最近はコンパイラの最適化がかなり進んだ代償として、Cでもどういう機械語に置き換わるか予想できないことがかなり増えたよ。
Re:女房と言語は新しい方がいい (スコア:1)
左辺の型によって代入演算子だったり初期化演算子だったりする。
右辺値の評価結果がconst参照を返す関数の場合、右辺の関数のreturn文で左辺が直接初期化される。
Re:女房と言語は新しい方がいい (スコア:1)
代入演算子が信用できないって話だろ。実際、カウンタを回したりしてるんだし。
Re:女房と言語は新しい方がいい (スコア:1)
C#の場合
a.xは何が起きるかわからないし
rustでも
a + bがどうなるかもわからんぞ
演算子が代わりに関数を呼び出すっていうのはモダンな言語では当たり前に実装されてるし
そこがC++は複雑だとはならんだろう
Re:女房と言語は新しい方がいい (スコア:1)
演算子がオーバーライドされていることを知っていれば、
調べようという気が起きるでしょうけど、起きなかったらそれまでですね。
調べるのも開発環境のサポートがあるから簡単なだけで、無ければ結構手間ですね。
C以上にフリーダムであり、演算子が想像通りの動きをしてくれるとは限らず、
人によってはむしろバグの温床になったりしませんかね。
Re:女房と言語は新しい方がいい (スコア:1)
C++は色々な出自のライブラリを組み合わせるとそこら辺で各ライブラリで方針が異なっていて非情に厄介ですね。
他の言語なら「ベンダ毎の方針が異なるの当たり前だろ？」となるのだが、C++だと最悪組合せを諦める事になる。
Re: (スコア:0)
>Cの何が悪いかちゃんと理解できればC++できちんとしたコード書けるだろ。
まったくもってC++を理解してないな。
「Cの何が悪いかちゃんと理解できれば」程度で「C++できちんとしたコード書ける」とはおこがましい。
理解したと思ったらまだそこが入口だった、それがC++。
C++できちんとしたコードが書ける、とは宇宙の真理を探るに等しい。
Re: (スコア:0)
宇宙の真理って、、、
C++はそこまで膨大でもないしそこまで筋が通ってる訳でもない。
Re:女房と言語は新しい方がいい (スコア:1)
難しい、あてがない、ということじゃないの。
必要だから (スコア:0)
使われてると思うんだけど
ゼロから作るのならともかくC言語が使われてるのって元のコードがC言語だからってのが大概なんじゃないの
そこからわざわざ他の言語に移植するかって言ったらしないよね…
とはいっても今ではC言語を使わなくてもいい場面が増えたのは喜ばしいこと
Re:必要だから (スコア:2, 興味深い)
そもそも滅びるかどうかなんてのはべき論じゃないですよね。
開発言語なんて人間の意志で自由に代替していけるものが
結果としてRustなどへなかなか置き換わらずC言語は一向に安泰、
もくろんでいた席が開かなくて目ざわりだから「老害、滅びろ」とは少々ヒステリー。
RustでOS書けんの？ (スコア:0)
全然知らないけどOSやデバドラ書くのに使えるんですか？
Re:RustでOS書けんの？ (スコア:3, 参考になる)
このへん [github.com]に比較が載っています。
Re:RustでOS書けんの？ (スコア:1)
Rustには、そういう意味でのGCは入ってないよ。
>プログラマが、スタック・ヒープ・GC付きメモリ、の3つから選べるようにすりゃ
まず、この流れで言ってるGCとは厳密には違うものだけど、C++がそんな感じしようと頑張ってる。shared_ptrとか。
その辺を使うと、ソースコードを解析した時点で、ここで確保したヒープメモリはここで開放される
(あるいは後で確実に開放してくれる関数かなにかに渡される)と、決定されるから、deleteは明示的に書かなくても良い。
参照してる変数の寿命が尽きた時点で自動で開放されるという点ではGCと似たような楽が出来る機能を、
実行時コスト(いつGC処理が始まってプログラムの実行が停止してしまうか分からない)無しに使える便利な仕組み。
ただ、C++の場合は、後付けでそういう便利機能をライブラリとして載せた経緯がある
(というか、Cからの伝統の、どこまででも危険なプログラムが書けてしまうという特性もある)
ので、「どういう性質を持った機能なのかをきちんと把握した上で、正しく書いた場合は」GC付き言語のような楽が出来る、
というような条件付きの仕組みにならざるを得ない。
そこを改良したのがRustで、C++のshared_ptrなどだと出来た危険な操作が全くできないような言語仕様になってる。
結果として、色々窮屈ではあるけど、実行時無しでヒープも含めて綺麗なメモリ管理がされているプログラムが書ける(というかそれしか書けない)。
Rustは、まさにハードリアルタイムシステムを安全に書くために作られたような言語。
ハードウェアを直接叩くような部分は、メモリが生で見えてるC系で無理矢理書いた方が性能が良いかもしれないけど。
Re: (スコア:0)
Redox is a Unix-like Operating System written in Rust [redox-os.org]
C++の方こそお役御免では？ (スコア:0)
> この記事のタイトルは「C/C++に死を」だが、原文タイトルにはC++は含まれていない
とはいうが、Cの方はリソースの厳しい組み込み向けなど、他で置き換えられないニーズがまだある。
C++の方こそ、それが使われていた用途向けには今ではもっと洗練された言語がある。
まあ放っておいても滅びそうだからあまりそういう話題にもならないのだろうけど。
C言語の方は放っておいたら当分は滅びそうにないから「滅びるべき」という話が出てくるんだろうな。
しかし、訳文にC++を勝手に追加した御仁は何の考えあってのことなのだろうか。
Re: (スコア:0)
リソース制限が理由でCは使えるのにC++が使えないことなんかあるの?
Re:C++の方こそお役御免では？ (スコア:1)
使えないじゃなくて必要が無い。
オブジェクト指向ってのはそもそも、大規模で複雑なシステムを大勢で開発するようなケースで
便利な方法として考えられたもの。
リソース制限が厳しい環境はそもそも大きなプログラムを置けないので、C++を持ち出す必要もない。使ってもいいが。
まあC++でC的な書き方もできるなんて屁理屈を捏ねだす奴もいるだろうけど。
Re: (スコア:0)
まあC++でC的な書き方もできるなんて屁理屈を捏ねだす奴もいるだろうけど。
屁理屈じゃなくて普通に書けるけど。
リソースの制限だって、C/C++ってそんなに変わらないと思う。
ライブラリも不要ならリンクの必要なものだけリンクすればいい。
C/C++のメリットって、言語以外の関連知識が充実すればするほど、
その辺の開発環境に依存しない使い方が生きてくるところでしょ。
Re:C++の方こそお役御免では？ (スコア:1)
「プログラミング言語C++」なんかを読めばわかりますが、初期のC++に関するStroustrup氏の設計思想としては、「従来のCコードは、C++でもオーバーヘッドなく使える」というベターCとして設計してるんですよね。
今時の肥大化したC++は置いといて、仮想関数とかテンプレートは使わない、その当時のレベルのC++で「クラススコープによる隠蔽と名前空間の分離」ができるだけでも、Cに比べて記述コードは格段に分かりやすくなるし保守しやすくなる。それぐらいならCに比べてオーバーヘッドはありません。
で、たぶん、実際に組み込みでC++を使っている、一番メジャーなプラットフォームは「Arduino」でしょう。
Arduinoの開発言語は自称Arduino言語となってますが、その中身はC++(gccベース)で独自のライブラリを載せたものになってます。
専用のクラスライブラリを作っただけあって、それなりに省メモリというかオーバーヘッドのないものになってますので、
標準的な環境(ATmega328pなど)ではROM(プログラム)32kB・RAM8kBぐらいですが、
ROM8KB・RAM512Byteってレベルのマイコンチップでも動かすことができたりします。
#4バイトなintをガンガン使ってるのだけはツッコミを入れたいですが…
Re: (スコア:0)
いやだから、C言語的な書き方をするなら、わざわざC++を持ち出す必要が無いだろうという話だよ。
オブジェクト指向を使ったプログラミングをしたいからC++の存在価値があるんだろう。
そしてオブジェクト指向と言う点では、今日もっとましな言語がある。
Re:C++の方こそお役御免では？ (スコア:1)
過去の自分は十分他人になりえるだろ
規模がどんなに小さかろうがオブジェクト指向を利用するよ
そのほうが楽で簡単だからな
Re:C++の方こそお役御免では？ (スコア:1)
「他人の作ったものを『安全簡単』に使いまわし」
これが本当に安全ならどんなに楽か・・
低品質なコードはオブジェクト指向では救えません。
ちゃんとテストしてくださいとしか言いようがありません。
オブジェクト指向だと、オブジェクトを間違った使い方を「させない」ことができるから「安全」なのです。
間違った引数を受け取らない。外部からの不正な操作をさせない。これがカプセル化です。
オブジェクト指向が楽と言っている人は、このようなカプセル化はしていないんでしょう。
構造化プログラミングをオブジェクトで実現しているだけ。
Re:C++の方こそお役御免では？ (スコア:1)
publicスコープとprivateスコープの使い分け程度ならば、
オブジェクト指向というより、構造化プログラミングの範疇であり、
C言語でもよく使われる書き方です。
Re:C++の方こそお役御免では？ (スコア:1)
publicスコープとprivateスコープ
厳密にいえば、public、protected、private はスコープじゃなくて、アクセスコントロールなんだけど。つまり、親のプライベートは見られるけどアクセスできない。
Re: (スコア:0)
わたしたちのC++言語
Re: (スコア:0)
タイトルは "Death to C, ++" なので
"C++" は含まれてはないですね
Re:C++の方こそお役御免では？ (スコア:1)
"Death to C" [techcrunch.com]の「続編」という意味で"++"が付いているのでしょう。
いずれにしても、本文にはC/C++の代わりにRustを使えと言っているので、
タイトルにC++が含まれているかどうかというのは些細な話だと思います。
Re: (スコア:0)
タレコミでは言及されてないですし
タレコミより前に取得されたアーカイブ [archive.fo]でもタイトルは同じなんで
hylomのせいでは