重要なのは C 言語のエントリポイント、つまり関数呼び出しが、CPU と OS によって
決まる Application Binary Interface (ABI)と一致している(あるいは ABI を C の関
数呼び出しに一致させている)ことではないですか?
そういう言語の中で 1番 普及している言語として、C 言語が生き残ると。
> osの設計を変えてもcできちんと動作するプログラムが存在することは、異なるosでも
> cが使えること、
C プログラムの移植性は、言語の仕様といよりは、プログラマーが移植性を考慮して
がんばっているから、果たせているのだと思います。
# C 言語は構造体のパディング、Endian 等に対する対策が言語仕様のレベルでまったく
#ないですし、int型の長さはおろか、char型が 8ビットであることすら決まっていない。。。
> さらにOSがない環境下ですらもCで書いたプログラム(Cで書いたOSが動
> くことが何よりの証拠)が動くことで十分証明されています。
OS のない環境下で C プログラムを動かす場合には、適切なスタートアップが必要です。
実際、C でコーディングされた UNIX 系 OS は、要所要所でアセンブラやインライン
アセンブラを必要としています。
ISOってなんか意味あるの? (スコア:2, 興味深い)
よく分からないのですが、今のところ.NETフレームワーク以外に使用されるようなことはなさそうですし、標準でなくていいからMSのほうで勝手にやっていてくれという感じです。
ちなみに、
そんなことないと信じています。
というか、C#ってC++の派生だったような気がするのですが。もうしそうだとしたならば、廃れることはないんでしょうけど。
#あ、C#の道連れで荒廃していく可能性も考慮せねば...
まぁ、Mac OS Xの日曜プログラマとしてはささやかながらもObjective-Cを応援し続けるつもりでいますが。
// Give me chocolates!
ISOシリーズ (スコア:2)
ISO9000とかISO14000の認証を得たところで、トッププレゼンするには、「営業を騙しやすくて」いいぢゃん。
# と思っていたら、「技術的なことは弊社の○○から」と呼び出されて汗を書く罠
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:ISOってなんか意味あるの? (スコア:1)
Re:ISOってなんか意味あるの? (スコア:1)
それはそれとして、C#って存在自体無駄だよな。
C++の代わりになる(文法の話でなくて、適用分野だけど)わけでもなし、.NETも、C#でなくてはいけないって訳でもなし。
wild wild computing
Re:ISOってなんか意味あるの? (スコア:1)
個人的には情報系の資格でJavaを選択肢に入れるところがあるみたいですが、ISO取るとどうなんでしょうね。
そういう方面でどうなるか気になっていたり。
Re:ISOってなんか意味あるの? (スコア:2, 興味深い)
C#はもともとJavaの当て馬として開発されただけだから、ISOに認証されてどうなろうが、Javaを潰せればそれでいいんだという計算はあると思います。
一方、Javaの方はSunの主軸商品だから、どうにも主導権を失いたくない。少なくとも会社の将来を左右する決断でしょう。ISOなんて通ったらIBMあたりにも持っていかれそうでかなり危なそう。
立場の違いがありますが、個人的にはSunの対応が注目ですね。
Re:んでも (スコア:2, おもしろおかしい)
右手が一文字分ズレたみたいですな。
Re:ISOってなんか意味あるの? (スコア:1)
いや、JAVAのパチモンという呼び名が打倒かと。
C#がリリースされたときにはビビった。
ここまでJAVAっぽくする必要があるんか。
ってね。
PCにECC Registeredメモリの利用を推奨します。
Re:ISOってなんか意味あるの? (スコア:1)
Re:ISOってなんか意味あるの? (スコア:1)
Re:ISOってなんか意味あるの? (スコア:1)
よく例に挙げられるtemplateによる階乗なんて、どんなプログラムでも使えますよね。
Re:ISOってなんか意味あるの? (スコア:1)
C++のtemplateを利用したものはそれを分かりやすい形(万人にとってはではないでしょうが)でソースに記述できることに意味があるのだと思いますが。
Re:ISOってなんか意味あるの? (スコア:2, 参考になる)
高速化に関しては、一つの手法を採用したから画期的に性能が上がったとか、そんな簡単なことばかりじゃないです。小さなことの積み上げが最終的に大きく効いてくるということもよくある。メタプログラミングの例でも、通常ランタイム時に計算するところをコンパイル時に済ませられるようになったというのは、非常に意味のあることだと思っています。
Re:ISOってなんか意味あるの? (スコア:1)
Microsoft 以外からも処理系を出して欲しいという意思表示でしょうか。あるいは既にあるのかな?
Re:ISOってなんか意味あるの? (スコア:1)
http://www.go-mono.com/c-sharp.html [go-mono.com]
Re:ISOってなんか意味あるの? (スコア:1)
ISOになると、各国政府がある程度の後押しをすることになってます。
例えば、おそらくJISにもなるでしょうし、情報処理技術者試験の
選択科目にもなるかもしれません。さらにひょっとしたら、中学や
高校の授業でとりあげられるかもしれません。
今すぐの影響は小さいですが、10年後にはJavaが今のCOBOLのような
存在になっちゃうかもしれませんね。あくまでも可能性ですが。
#今後30年を生き残る言語って何があるだろか。
#スクリプト言語とC以外に、OCAML/Tkでも勉強してみるべいか。
100年たっても生き残る言語 (スコア:3, 興味深い)
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには必ず通らなければならない関門であり、ほかの言語にはマネができません。どんなにプログラムが組みにくくても、この2言語だけは捨てることはできないでしょう。
もっとも、アセンブラがどういう言語かという問題は残りますが、LispマシンだったらLispがアセンブラのようなものですしね。
Re:100年たっても生き残る言語 (スコア:3, すばらしい洞察)
> 言語が少なくとも2つはあるでしょう。アセンブラとCです。
アセンブラが当分生き残るということには同意しますが、100年と言われるとちょっとどうかなあという気が。
アセンブラはノイマン型コンピュータの最下層のソフトウェア(を人間に可読な表記にしたもの)ですから、ノイマン型コンピュータと一蓮托生です。その意味で、ご指摘の通りアセンブラの寿命が非常に長いというのはほぼ間違いないでしょう。が、ノイマン型コンピュータがあと100年持つかどうかというと、それにはちょっと漠然とした疑問があります。確かに今のところ不動の地位を保っていますが。
また、Cは「アセンブラの体のいいwrapper」としての側面が強く、今さらCと同じ立場を置き換える言語が現れることもないでしょうから、アセンブラとCは同じ寿命を持つと思います。この点はそのまま同意です。
もしノイマン型コンピュータを駆逐するような制御構造が現れたとすると、記述の抽象度が高い関数型言語や論理型言語の方が案外生き残りやすいかもしれません。
# ただの妄想かも
Re:100年たっても生き残る言語 (スコア:1)
ノイマンを覆すようなパラダイムについては、夢を語るぐらいならやってみてもいいでしょう。ですが、商売として成り立つかというと、私は悲観的な見方をしています。
計算機を買ってくれそうなお客さんというのは、まず第一に処理速度を見ます。過去、関数型や論理型で攻めた人達はプロセッサの数を増やすことでお客さんに買ってもらおうとしました(そもそも言語が大量の記憶域を仮定していたため、メモリやディスクを買い足す発想がなかった)。ところが、このアプローチの場合、データをロックするために必要なコストの見積もりが難しく、一定の性能を達成することが困難でした。
一方、ノイマンで押した勢力は、メモリやディスクを増やしただけスケールアップするようなシステムを目標としていました。この場合、メモリやディスクの管理に必要なコストはプロセッサの場合よりもはるかに確実な見積もりがとれます。かくして、一定の性能を容易に達成できるだけでなく、処理能力の制御までも可能になりました(リアルタイムはその典型)。
いくら夢があるものでも、暴れ馬ではお客さんに売りたくなるようなものにはならないでしょうね...
Re:100年たっても生き残る言語 (スコア:1)
> 夢を語るぐらいならやってみてもいいでしょう。
> ですが、商売として成り立つかというと、私は
> 悲観的な見方をしています。
それはそうです。現時点や予測可能な近い未来についてであれば、専用用途ではなく汎用用途においてノイマン型を上回るものは存在しないでしょう。性能・開発効率・費用対コスト・ソフトウェア資産量などの観点からノイマン型が合理的だからです。
私の意見はただ単に、現状で考えられる条件で100年も先のことは予想できないかな、と考えたって話でして。
ついでに関数型言語や論理型言語については、生き残りやすいかもしれないけれど主流にはならないと思います。新しいハードウェアに適した構造を持つ言語が開発されて、新しい主流になるんではないかと。その方が性能面で有利でしょうから。
Re:100年たっても生き残る言語 (スコア:1)
> ですが、商売として成り立つかというと、私は悲観的な見方をしています。
量子コンピュータやDNAコンピュータは?
得意分野が違うんで、ノイマン型を覆すってことにはならないと思うけど、
商売としては成り立つんじゃないの?
DNAコンピュータはすでに実用化 [olympus.co.jp]もされてるし。
このオリンパスの製品のように、ノイマン型と非ノイマン型は補完し合ってくもんだと思うけど、
100年後にいまだにノイマン型が主流か、といわれると断言できないと思うな。
#どうでもいいが、「遺伝子解析用DNAコンピュータ」の「電子計算部」って、どうみてもDELLのPCだよな。
Re:100年たっても生き残る言語 (スコア:1)
非ノイマン型のアーキテクチャのための言語です。
ハードウェアですので、すべてが並列に動作します。
で、C言語のコードをHDLに変換するものがすでに存在しています。
(詳細は、googleってください)
CのコードからアセンブラやHDLが生成できるとなると
重要なのは、言語では無くて思想なのかもしれませんね。
Re:100年たっても生き残る言語 (スコア:1)
> で、C言語のコードをHDLに変換するものがすでに
> 存在しています。
おそらく、System-Cなどに代表される「C言語をハードウェア記述言語として用いる開発環境」のお話かと思います。
私見かもしれませんが、C言語がHDLに採り入れられるようになって来たのは、Cがハードウェア設計に向いているからではなく、別の理由によるものではないかと思います。
C言語をHDLとして使う試みは4~5年前ぐらい(もっと前?)からありますが、一部の現場で使用されるようになってきたのは最近(1~2年前ぐらいから?)の話だと思います。採用されるようになった理由は、
(ごく簡単に言えば普通にコンパイルして普通に実行するだけ)
# 怪しげなので識者・経験者のツッコミ歓迎
ということで、私はC言語は非ノイマンな用途への流用にはあまり向いていないんじゃないかな、と思います。
Re:100年たっても生き残る言語 (スコア:1)
>C言語をHDLとして使う試みは4~5年前ぐらい(もっと前?)から
>ありますが、一部の現場で使用されるようになってきたのは
>最近(1~2年前ぐらいから?)の話だと思います。
>採用されるようになった理由は、
わたしは、ハードウェアの設計が出来る人間が少ないし、増えにくいので、
計算機言語の論理などを理解できるソフトウェア技術者をハードウェアの
設計者に転用するための方便だと思っています。
#ま、(Cからの変換とは言え)HDLが書けるだけではハードウェアの設計は
#完了しないので、HDLを作った後にいろいろ他のシミュレーションするの
#からは、逃れられはしないんですけどねぇ・・・。
---- redbrick
Re:100年たっても生き残る言語 (スコア:2, 興味深い)
アセンブラについては CPU が存在している限り消えないでしょうが、
C言語に関してはスレッドもサポートしていない言語が
30年、100年後に生き残っているとは思えません。
もし、残っているとしても、今の COBOL 並みの地位にいると思います。
boost が取り込まれた C++ は生き残っていくような気がします。
ただし、デスクトップというより、むしろ組み込み系、
今のアセンブラ地位の言語として生き延びていくと思います。
by rti.
Re:100年たっても生き残る言語 (スコア:5, すばらしい洞察)
Cが今まで生き延びてきた、そしてこれからも生き延びていけるであろう本質は、後から追加が必要になった機能を全てlibraryに押し込めることができるためです。決して新しい機能のために言語の文法や意味論に手を加え、それゆえに過去のsourceを捨ててしまうようなことをしなかったのが強く効いています。その点では、threadingなんか1996年にとっくに実現されているのです。しかも、それ以前に作られたsourceを一切壊さずに。
似たようなところでは、memory allocatorがあります。Cには汎用的なmemory allocatorとしての意味を持つ要素は一切ありません。高々stack上にとれる配列ぐらいです。これは実装が非常に簡単で、stack pointerの加減算ができればすぐに実現できます。一方、C++は汎用的なmemory allocatorの意味を持つnewとdeleteを定義してしまいました。したがって、C++を走らせる環境に応じてmemory allocatorを作り直さなければなりません。しかし、我々はいつでも4GBのだだっぴろい空間が使えるわけではありません。ページ数が限られているがゆえ、backing storeを作らなければ実用にならない環境にも直面します。わざわざそんな環境でまで、C++を走らせたいですか?
Cがアセンブラとともに持っている専売特許は、環境への適応性です。memory allocatorなんかなくてもいい、単にRAMにloadしてentryへ飛び込むだけで実行できるプログラムを作れる言語がなければ、OSのような基本ソフトウェアは絶対に作れません。そもそも、メモリ管理をするプログラムをmemory allocatorが必要な言語で作ったりすることがタマゴとニワトリ問題を引き起こすので、そんなものを選ぶのはナンセンスですが。
Re:100年たっても生き残る言語 (スコア:1)
BeOSはC++で記述されていたと思いましたが....。
NeXTはObjective-Cで記述してたのでは?
ま、どちらもCの記述がそのまま使えるから、要の所はCだ、と言われればそれまでですけど。
Re:100年たっても生き残る言語 (スコア:1)
> BeOSはC++で記述されていたと思いましたが....。
> NeXTはObjective-Cで記述してたのでは?
OSというよりはKernelについていいたかったのでは。
BeではKernelコードではC++は使えないし、NeXTはmachカーネルですよね。
Re:100年たっても生き残る言語 (スコア:1)
要がCっぽいというのもありますけど、それ以上に注目すべきはそれらのOSで作られたcomponentが実際にはほかのOSでは一切役に立たなかったことでしょうね。片や完全にCで実装したMach VMはBSDにも移植できたというのに。
C++だけじゃなくてオブジェクト指向の落とし穴なんですが、再利用性なんて形をきっちり決めただけじゃ全然実現できないんです。むしろ、外側から見える形に合わせて再利用元を変更するハメになったりして、本末転倒です。言語を設計する側にとってはもの作りのネタになりますが、その上で何十年も保守しなければならないものを作る側としてはまず採用できません。
Re:100年たっても生き残る言語 (スコア:1)
それ、OOが「害」になった、とまで強く言えるんでしょうか?
もしそうでないなら、OOが有っても無くてもせいぜい同じ、という程度のことでしょうね。
で、便利なものは使います。
Vector(動的配列)「クラス」(のObject)が無かったらウンザリするよね、
毎回似たようなコードを書いてたら日が暮れるよね、
しかも似てるけど違う性質の(つまり兄弟の)クラスとかとも一緒に(=多態して)使いたいよね、
とか言い出したら、せめてOOくらい無いと辛いですね。
もちろん、辛かろうがどうしようが茨の道を歩む「自由」は有りますが。
「再利用性」そのものの神話については、たしかにあれは神話でしかないですね。
しかし、逆にいえば、OOを捨てたところで何かが楽になるわけでも無いわけで。
それに、べつにOO(PL)だからって必ずガチガチの設計&再利用オタクに陥らないとならないわけじゃないです。
>んです。むしろ、外側から見える形に合わせて再利用元を変更するハメになったりして、本末転倒です。
そういうことはCだって生じることでは? Cに関数と構造体が有るからには、
再利用性の問題は、クラス(関数と構造体と幾つかの追加オヤクソクの集成物でしかない)
が有る言語と同じくらいに、ついて回るはずです。
たとえば継承(再利用120%の世界)はイタイから必要最小限にしたほうがいい、ってのは
OO内輪ですら既に言い尽くされた話です。OO人だってそれくらいの自衛策は心得てます。
無策で取り掛かれば火傷するのは、どの言語や方法論(?)だって、同じ。
稀に誤解してる人が居ますが、再利用といっても、実際にゃ大型や中型の部品は土台再利用しにくいんですよね。
振り返って冷静に考えればCoding始める前から判りきってる事ではあるんだけど、
システム全体のアーキテクチャに関わるような大きなObject(のクラス)は、一品物と思ったほうがいい。
そして、逆に小さい部品の再利用性は、有効であることが多い。
あたかもネジや釘のような小さくて「イロ」のついてない部品は再利用しやすい。
ここを押さえていれば、再利用性自体は、そんなに御し難いものになったりはしない、んだけどなあ。
大きな一品物をObject(Class)として作るのは、むしろ再利用性のためじゃなく、
「そのほうがうまくまとまる物」であればObjectにするのが良いぞ、という感じだと思います。
今自分が作ろうとしているプログラムがどういう性質のものであるか、によって決まると思います。
ちょうど、ある処理を関数にする基準を、必ずしも「同じ処理の登場回数の多さ」だけで決めないほうがいい、のと同じです。
#もちろん、小さい部品も、同じような調子で、Objectにするほうが似合うものと、そうでないものとがあります。
余談:
ところでC++以外のOOP言語は、どれくらい親しまれています?
>その上で何十年も保守しなければならないものを作る側としてはまず採用できません
それは変ですね。関数という部品の再利用は、(Cを使ってるからには)肯定されているのではないのですか?
Re:100年たっても生き残る言語 (スコア:1)
残念ですが全てではありません。
上(?)で書いたように、Stackの使い方とかは処理系お仕着せになっちゃいますよね。
ある実装のコンパイラのStackの使い方が不都合だからそれを捨てて違う実装を選ぶことは可能でしょうけど、
それだってその処理系「の」お仕着せであるのは同じ。
Cそのものの能力としてプログラマブルであるわけではないですよね。
#俺のような、Cのたいした使い方をするわけでもない奴でも、時としてその「制限」が不快になります。
そして、ここではたまたま「Stack」について書きましたが、
そういうお仕着せによる制限は、C言語には、たしか他にも幾つかありますよね。
確かにCは、お仕着せが他の多くの言語より「少なめ」ではあるんですが、「無い」わけではない。
ここで「無い」なんて言い切っちゃうと、ほげ言語のパラドックス [dreamhost.com]の餌食になるのがオチです。
>決して新しい機能のために言語の文法や意味論に手を加え、それゆえに過去の
>sourceを捨ててしまうようなことをしなかったのが強く効いています。
それは逆でしょう。
Cが万能なのじゃなく、巷の多くのソフトが長年にわたって、Cの流儀にあわせてくれたんでしょう。
Cでやれる範囲のことしかやらないようにしてきた、ということでしょう。
Cは確かに万能ではなくても千能?くらいは有る言語なんで、そういう妥協をしても
不都合が「あんまり」生じないわけですが、不都合は全く無いというわけじゃないです。
>その点では、threadingなんか1996年にとっくに実現されているのです。しかも、それ以前に作られたsourceを一切壊さずに。
#threadingって、(Multi)Threadのことですよね?違ったら御免。
事情は全く知りませんが、それ、そういうものなのですか?
96年という年は、Threadという"基本的な"ものが実装されるにしては遅すぎる時期であるような気がします。
それに、「一切壊さず」ってのは無理が有りますよね。
Threadが導入されればアプリ(など)側のアーキテクチャすら変わるのに、
そのアプリ(など)のソースが無事でいられる筈が無いのでは?
#そういやたしかちょうどその頃、そういうテーマの本を本屋で見かけた記憶が。
#あの頃のイタイケな俺は驚いたもんだったけど、他の幾つかの言語を知った今となっては、もうあんまり驚けないな。
>似たようなところでは、memory allocatorがあります。Cには汎用的なmemory allocatorとしての意味を持つ要素は一切ありません。
というか、memory allocator「は」Cではライブラリとして提供「できる」機能(の1つ)ですね。
他にも幾つか、Cにはそういう機能はあります。
が、Cではライブラリの形態で提供できない機能「も」世の中には沢山有るわけで。
たとえばLoopとかIfとか。
また、前述のようにStackの使い方を変更したい場合があるので、「関数」という仕組み自体もまた
場合によっては自作したりカスタマイズしたりライブラリ化したりしたいものですが、これも不可能ですよね。
ここで「そんな機能を自作する必要は(滅多に)無い」という話をしてしまうと、
Cの特徴もしょせんは程度問題だったのだということになります。
>一方、C++は汎用的なmemory allocatorの意味を持つnewとdeleteを定義してしまいました。したがって、C++を走ら
>せる環境に応じてmemory allocatorを作り直さなければなりません。しかし、我々はいつでも4GBのだだっぴろい空間が使え
>るわけではありません。
ん?そういうレベルの自作をアリだというならば、問題は簡単じゃありませんか?
C++だって、とりあえず間に合う程度のお粗末なallocatorを作って与えればいい、ってことなのでは?
>わざわざそんな環境でまで、C++を走らせたいですか?
べつにCの後釜がC++でなきゃならんわけじゃないので、C++が不都合ならC++を捨てるまでです。
つまりたまたまC++が例として不適切だっただけでは?
Re:100年たっても生き残る言語 (スコア:1)
制御構造がないのはプロセッサとして失格、マル。
あなたは恐ろしい人ですね、そのallocatorが実はOS全体で使うallocatorになってしまうことに気が付かないとは。
OSの中でallocateする必要があるmemoryの大きさは、数十バイトから数GBまで非常に大きなばらつきを持っています。malloc(3)のように空のmemoryを持ってくるallocatorが実用になるのはせいぜい数十KBだけで、それ以上になると空きページを圧迫して性能を落としかねません。また、MB級になると全てを使い切らず、sparseにたたいていくことも増えてきます。
そういう需要の方が実は性能に大きく響くことが分かっているから、複雑な機能を持つVMをいろいろ作ったわけです。仕様は後から変えると困る人が増えるだけに、単純にnewとdeleteで片付けているとひどい目に遭いますよ。
Re:100年たっても生き残る言語 (スコア:2, 参考になる)
言語の semantics を考えるときは、その言語の色々な実装(例えば C言語だったら
C インタプリタ)でその話が成り立つかどうかを考えるべきです。
> これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が
> 一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり
> 処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには必
> ず通らなければならない関門であり、ほかの言語にはマネができません。どんなにプ
> ログラムが組みにくくても、この2言語だけは捨てることはできないでしょう。
一般的なコンパイラ出力の C 処理系のみを考えても、
スタートアップコードを必要とします。これは C 以外のもので書かれていますよね。
また、エントリポイントに飛ぶ機能を持った言語は、普通 自分で作ったエントリ
ポイントに安全に飛ぶことができます(Lisp とか VB とか)。
重要なのは C 言語のエントリポイント、つまり関数呼び出しが、CPU と OS によって
決まる Application Binary Interface (ABI)と一致している(あるいは ABI を C の関
数呼び出しに一致させている)ことではないですか?
そういう言語の中で 1番 普及している言語として、C 言語が生き残ると。
# 個人的には、C のデータ構造を ABI に合わせるための処理(register spill とか)
# は実行時の支援処理といえると思います。
# すでに G7 さんが指摘されていますが可変長引数や alloca などのスタックの使い方
# もそうです。そして C9X はさらに進む。
私なら、こう書きます。
「 C の言語とその一般的な処理系の特徴は、OS の ABI を強く意識した関数呼び出しを
持つこと。そのため、OS やライブラリと極めて高い親和性を持ち、OS やライブラリ
の既述言語としても適している。
また、C 言語の『言語仕様』は不可分な処理を定義していない。
ここで言う不可分な処理とは、その途中で割り込み処理が入ることを禁止し、連続して
実行する必要のある処理のことである。
(不可分な処理の例としては、Stop-the-world型の GC を持つ多くの言語は GC 中に割り
込みが入らないこと要求される。また、Java においてはオブジェクトの生成などが不可
分な処理として定義されている。)
現在の計算機はシグナル・例外による割り込みを利用することが前提となっている。
これらを言語側でコントロールするためには、不可分処理のない C のような言語が適し
ている。
以上の 2 つの理由によって現在の計算機・OS モデルがなくならない限り、C 言語は
残り続ける。
また、CPU のローレベルな機械語を既述する必要はこの先もなくならない。
その時、テキストによって機械語を既述できる『記法』としてアセンブラが残る。」
p.s.
C 言語の言語仕様としての最大の特徴はポインタですね。
ポインタは、、、100年後はなくてもいいや。
コンタミは発見の母
Re:100年たっても生き残る言語 (スコア:1)
>ポインタは、、、100年後はなくてもいいや。
ガンダム0083はデンドロビウムのプログラム。C言語で書かれていて…
far* なんて書かれてて、見た瞬間にぶっ倒れた(笑)
#その時代にもセグメントあるのかよー!
#史実(?)に則ってセグメント残します?>ガンダマーな人たち
-//-
Re:100年たっても生き残る言語 (スコア:1)
Re:100年たっても生き残る言語 (スコア:1)
Re:100年たっても生き残る言語 (スコア:1)
プログラムは全てユーザプロセスとして動くものばかりではありませんよ。あるOSの元でプログラムが動くと勝手に仮定すると、Cの重要な本質を見失ってしまいます。
私はとあるRISCの評価中、IPLのためのload addressとentry addressだけをheaderとしてつけたC言語のプログラムを組んだことがあります。cross compilerゆえlibraryどころかstartupすら使えませんでした。それでもmain()をいきなりentry addressとしてきちんと動作しているんです。なので、上述の命題は誤りです。
OSの設計を変えてもCできちんと動作するプログラムが存在することは、異なるOSでもCが使えること、さらにOSがない環境下ですらもCで書いたプログラム(Cで書いたOSが動くことが何よりの証拠)が動くことで十分証明されています。
Re:100年たっても生き残る言語 (スコア:1)
> c言語のプログラムを組んだことがあります。cross compilerゆえlibraryどころかstartupすら
> 使えませんでした。それでもmain()をいきなりentry addressとしてきちんと動作しているんです。
> なので、上述の命題は誤りです。
brake-handle さんの書いたコードが実行される前に、フレームポインタやスタックポインタを
セットする(スタートアップの代わりを果たす)コードがあったはずですが、、、
> osの設計を変えてもcできちんと動作するプログラムが存在することは、異なるosでも
> cが使えること、
C プログラムの移植性は、言語の仕様といよりは、プログラマーが移植性を考慮して
がんばっているから、果たせているのだと思います。
# C 言語は構造体のパディング、Endian 等に対する対策が言語仕様のレベルでまったく
#ないですし、int型の長さはおろか、char型が 8ビットであることすら決まっていない。。。
> さらにOSがない環境下ですらもCで書いたプログラム(Cで書いたOSが動
> くことが何よりの証拠)が動くことで十分証明されています。
OS のない環境下で C プログラムを動かす場合には、適切なスタートアップが必要です。
実際、C でコーディングされた UNIX 系 OS は、要所要所でアセンブラやインライン
アセンブラを必要としています。
p.s.
実用上の問題ない話ですが、C では書けないプログラムがあります。
メモリアドレス番値 0 に対するメモリアクセスです。
0 は他のポインタ値と聖別されており 何も指さない状態を示すヌル値です。
アドレスの 0 番とは区別されます。
ですから、システムに 0 番のメモリが実装されていたとしても、ヌルへの
代入はなんらかのエラーとすべきです。
そのため、本当にマジメに仕様を満すと 8086 の割り込みベクタテーブルの
最初のエントリが埋められないコンパイラが出来てしまいます。
# そういう実装系はないと思いますが。
コンタミは発見の母
Re:100年たっても生き残る言語 (スコア:1)
stack pointerの更新にinline assemblerを使えば、残りの部分はCで書くことができます。特にmemory mapped I/Oの場合はそうです。この場合、ROMにCで作ったcodeを焼き、Cの関数をCPUの初期program counterに合わせることすら可能になります。
0を使うのもあくまでlibraryの都合です。別に言語仕様がaccessを禁止しているわけではありません(DOSのころは割込ベクタを直接書き換えるために0番地をaccessしていた)。お望みなら、0xffffffffを使ったっていいんです。ただ、それだとaddress spaceの大きさによって値が変わってしまうことや、一部のRISCではalignment errorを起こすために0を選んだのです。
一見言語仕様に思えるこの実装は、実はエラーの早期発見のためにOSがやっていることなのです(pagingが可能な場合)。
Re:100年たっても生き残る言語 (スコア:1)
# そんだけ。
Re:100年たっても生き残る言語 (スコア:1)
アセンブラは今風の延長のCPUがありつづける限り、その「後釜言語」が出現するってことを
考える意味が無いはずなので、そういう意味では未来永劫残るでしょう。
でもCは、後釜言語が出現するかも知れない。
30年後の俺らの後輩?は、今のCと似ているような似てないような後釜言語を
(そういう用途に)使っているかも知れない。
もちろんこれは、たまたま惰性でCが今のまま使われ続ける可能性を否定するものではありません。
ただ、残るにせよ残らないにせよ、それは「たまたま」であって、アセンブラのそれとは違って必然では無い、とは言えると思います。
だから、「アセンブラと、Cのような中級言語と」が残る、という説ならまだなんとなく納得がいきます。
もっとも、未来における中級言語のメジャーな位置付け自体が、上か下のどっちかにシフトしてしまう可能性も
ないわけではないでしょうから、後釜がCに十分(?)似てるという保証すら、必ずしも無いのですが。
なお、Schemeの実装におけるスタックフレーム [dreamhost.com] あたりを読んでいると、
Cの(メジャーな(と言っていいですか?俺ぁ疎いもんで御免))実装の Stackの使い方とかは、
色々考えられる実装形態のうちの1つでしかなくて、それ以外の実装
(たとえばこの例ではScheme寄りの)を支援しないものに過ぎない、のだなと思っちゃいます。
つーか、そのとおりですよね?
そういう意味では、そのCの限界を超えられる言語は常に必要であり、それがアセンブラだったり
アセンブラとCの間くらいの高級度のなんらかの言語だったり、するのだろうと思います。
>もっとも、アセンブラがどういう言語かという問題は残りますが、LispマシンだったらLispがアセンブラのようなものですしね。
うーん。そうなんだろうか?
Luspマシンって、ユーザプログラミングのために提供された(隠されなかった)部分の高級度が、 Lispのソレであるわけですよね。
アセンブラというノリじゃないような気がします。
むしろ大昔のパソコン(^^;でいうROM BASICに近い位置付だったりしませんかね?
もちろん言語の出来が違いすぎるんで、BASICとLispでは色々な面で比較にならないでしょうけど、ね。
Re:100年たっても生き残る言語 (スコア:2, 参考になる)
Lisp マシンというのは、CPU の設計からすでに LISP 向きに設計されているものをさすのだと思います。例えば、あらゆるメモリにはかならずタグがついており、car や cdr など基本関数はハードウェアで実装。GCもマイクロコードでやったりとか。少なくともいまはなき Symbolics Machine という Lisp マシンは、アセンブラコードがかなり Lisp に近いもので、car, cdr, cons とかに相当するものが並んでました。
Re:100年たっても生き残る言語 (スコア:1)
Cが生き残るのは「低機能で実装が簡単」だからで、機能が足らないから
廃れるってのは逆方向ではないですか?
リンク先読みましたが、組み込み系で多用されているZ80の発展型にガベコレを
実装した環境ってあるのでしょうか?Cに比べて実行時の要求リソースがかなり
大きいと思いますが。実装依存と書いてあるから、Cに匹敵する少リソースでの
実装形態もあるのかもしれませんが。
#Schemeは初めてかじったので、理解が浅い点はご容赦ください。
あっと、100年後の話でしたね。100年後でも、消費電力の関係やサイズの関係で
強力なCPUを採用できないとか、コストをギリギリまで削る必要のある用途では
低速低機能なCPUの用途は無くならないと思います。そもそもZ80程度の能力で
済んでしまうというような用途も無くならないでしょう。低機能CPUの需要が
無くならない限りは、低機能なC言語の需要も無くならないでしょう。
-//-
Re:100年たっても生き残る言語 (スコア:1)
> 実装した環境ってあるのでしょうか?
CP/M-80上で動くLispはありましたね。Prologも。APLも。
昔、TIかどっかで作ってた、PC-Schemeでしたっけ、直接
機械語に落す処理系があったと思うんですが、あれは
ターゲットプロセッサは何だったかな。
最近のものでマイクロコントローラ向けに書かれたものとしては
Bitとか。http://www.iro.umontreal.ca/~dube/ から論文への
リンクがあります。68HC11とかで走らせることを念頭に置いて
いるとか。ただ、実装はCで素直に書かれたVMのようです。
Re:100年たっても生き残る言語 (スコア:1)
その意味で役に立つかどうかわかりませんが、アセンブラとCについての私の意見です。多くの項目が既出ですが、ご勘弁を。結論はbrake-handleさんの元コメント [srad.jp]と同じです。
アセンブラは、#183921 [srad.jp]で既に述べた通り、ノイマン型コンピュータの最下層のソフトウェアです。ノイマン型が存在する限りアセンブラはなくならないでしょう。
ただし、アセンブラをプログラミングで直接使うことは稀です。機種依存性が高く構文が貧弱なため、開発効率が低いからです。アセンブラで記述しなければならない状況の例として、特権命令等の特殊機械語命令を書く時、スタックポインタなど特定のレジスタにアクセスしなければならない時などがあります。また、アセンブラで記述した方が望ましい状況の例として、スタックポインタなどコンパイラが自動で使用するレジスタ変数が初期化されていない時(例えばIPL)などがあります。
アセンブラの主用途はコンパイラのバックエンドであり、言語としては「裏で生き続ける」という感じでしょうか。
Cは、「すべての構文要素が、単体で動作する機械語列に変換される」という特徴を持ちます。これがCの最大の利点です。OSやサポートライブラリが関与する操作は構文内には存在しません。OSが関与する多くのOSに共通する機能・一般的に便利な機能は、標準ライブラリとして構文とは独立に定義されています。この(そのまま機械語になるという)利点があるため、他の高級言語ではほとんど真似のできない、OSを記述すること・OSが存在しない状況で動作するプログラムを書くことなどが可能です(ただしC++でも可能ですよ)。
Cまたはアセンブラで記述できる状況であれば、より機種独立性の高いCを選択する方が合理的です。したがって、現在のCの地位を奪うものが現れない限り、Cは生き続けるでしょう。また、Cのほぼ上位互換言語でさらに付加機能も持っているC++が、今のところCを置き換えることに成功していないことから想像して、Cを駆逐する言語は現れ得ないように思います。アセンブラの生存理由と違ってこちらは明確な根拠じゃないですけどね。
以上の理由から、アセンブラとCはどちらも長い寿命を持つ、と思います。
# 細部はともかくとして、基本的には元々こういう話じゃないか
# と思っていましたがどうでしょう > brake-handleさん
Re:ISOってなんか意味あるの? (スコア:1, おもしろおかしい)
おかむらたかし って読んじゃいました。
JIS といえば (スコア:1)
ちょっと驚いたんで。
Re:JIS といえば (スコア:1)
%% 規格の取りまとめやった方に酒場で聞いた話。
%% ちなみに ISO の日本代表委員も同じ人。:-)
の
Re:JIS といえば (スコア:1)
というかC#もたぶんJIS規格になるわけで。
Re:JIS といえば (スコア:1)
素通ししないで、独自の拡張入れられちゃったりしても困ると思うんだけど。
#JISにやって欲しいのは、日本発の技術や、日本人にとって使いやすいものを
#ISOになるよう働きかけることだよな。