アカウント名:
パスワード:
アプリケーションレベルなら参考にする事もあるけれど、 その場合にはOS依存の(ほとんど)無い部分が大半なので、 オープンソースがOS(カーネル)の利点になるとは思ってない。
ソースコードが参考になるのは、初心者がアプリケーションを作るときだけではなくて、中級者が(OSの機能を一部移植するくらい
JavaとかRubyとかSmalltalk(などのOSとは切り離された世界)「で」いわゆるアプリを書くのが、いいんじゃねーかと。
たとえばこの(GCの)場合だと、 GCという概念(とその実働物)が自分らの足もとに「存在」することさえ 知っていればよくて、 その実装そのものがどういう風に動くものである(つまりどう実装されてる)かは、 ほぼどうでもいい知識に過ぎないのでは？
子どもに易しいものは、当然大人にも易しいんで、 開発効率という意味でも、 「より多くの部分が、より高級な言語によるproductで構成されたシステム」が もっと増えて欲しいなと思っています。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
見当外れだとおもうが、、、 (スコア:1, すばらしい洞察)
そういう観点でOSも選択されてほしい。
Linuxを使うこと自体が目的になるのではなくて、Linuxを使うと、
Windowsより、こういうところで良かったです、とか、そういう意見があるのが
自然じゃないだろうか。
Re:見当外れだとおもうが、、、 (スコア:0)
プログラムを組むようになれば、自然とソースコードが
公開されていることのありがたさは実感できるものだと
思うので、Windowsと逐一比較しなくてもLinux（
Re:見当外れだとおもうが、、、 (スコア:0)
＞公開されていることのありがたさは実感できるものだと
＞思うので、Windowsと逐一比較しなくてもLinux（及びオープン
＞ソースソフト）の利点を理解することはできると思います。
プログラムを組むときに、ソースコード公開がありがたいの
は確かだが、OSのソースを見
Re:見当外れだとおもうが、、、 (スコア:1)
ソースコードが参考になるのは、初心者がアプリケーションを作るときだけではなくて、中級者が(OSの機能を一部移植するくらい
Re:見当外れだとおもうが、、、 (スコア:1)
上層(アプリ層)のライブラリとかにまで OS提供のAPIを
がんがん使う...という人々(「中級者」かな？「初級者」かな？)が多くて
へき易した記憶もまた、あります。
Delphi(のコンポーネント)畑で、ですが。
Delphでは、OpenSourceと呼べるかどうかはともかくソース公開の
コンポーネント(クラスライブラリ)を公開する文化は存在しました。
で、それらのうちの、妙に多くの割合の奴が、APIのラッパーだったんですよね(^^;
いわゆるアプリ(やそれ用のライブラリ)を作るときは、
下層にはあんまり手ぇ出さないで欲しい、そのほうが「きれい」なプログラムになるだろうよ、
と思ったものでした
Re:見当外れだとおもうが、、、 (スコア:1)
アプリを書く上でそういう階層性を守って欲しいというのには同意します。ただ、最近、あまりに下層のことを知らないと言うか、下層で起きていることに対する感覚がないプログラマ(素人ではない)が多いのには困っています。
常駐して動くサーバープログラム(by Java)を外注したのに、使っているうちにどんどんメモリを食い潰すプログラムを書いて納入したり、発注の目的はスピードアップですと明言しているのに明らかに GC おこしまくるようなプログラム書いてきたり。(どうもどういう時にメモリが無駄に消費されるかがピンと来ないらしい)
G7さんのいうようにプログラミングはいろんな要素からなっていて、優雅に水面を滑る白鳥も水面下では必死で漕いでいることも、(プログラマの教養として)知っておいて欲しいところ。
まあ、これらは中学・高校で教えるような話ではないのでオフとぴかもしれませんが、多少ともそちら方面に進もうとしているなら、自分が寄って立つ土台の下は、早めに覗けた方がよいような。(強制的に覗けというわけではない)
Re:見当外れだとおもうが、、、 (スコア:1)
>で起きていることに対する感覚がないプログラマ(素人ではない)が多いのには困っています。
>常駐して動くサーバープログラム(by Java)を外注したのに、使っているうちにどんどんメモリを食い潰すプログラムを書いて納入した
>り、発注の目的はスピードアップですと明言しているのに明らかに GC おこしまくるようなプログラム書いてきたり。(どうもどういう
>時にメモリが無駄に消費されるかがピンと来ないらしい)
どうなんでしょう？
たとえばこの(GCの)場合だと、
GCという概念(とその実働物)が自分らの足もとに「存在」することさえ
知っていればよくて、
その実装そのものがどういう風に動くものである(つまりどう実装されてる)かは、
ほぼどうでもいい知識に過ぎないのでは？
GCについては、それの原理とかを書いた
本やwebページや論文(？)などを読めば
それで十分だったりしませんか？
もうちょっと具体的にいえば、方式としてmark & sweep法と参照係数法に大別されて、
それぞれの動作原理の「概要」はカクカクシカジカで...という程度の知識があれば
それでいいんではないかと。
というか、かく言う俺もGCを自力で実装したことはないっす。
boehemさんを「使った」ことが有る程度。
こういう程度の"感覚"じゃ不足ですか？(^^;
>まあ、これらは中学・高校で教えるような話ではないのでオフとぴかもしれませんが、多少ともそちら方面に進もうとしているなら、自
>分が寄って立つ土台の下は、早めに覗けた方がよいような。(強制的に覗けというわけではない)
実装そのものまで見るってのは、土台(の設計図や施工報告書)だけじゃなく、
現状の土台の腐り具合まで(^^;見る、という感じでしょうね。
実装...というか部品まで見れるという性質が子どもに益する(かも知れない)点といえば、
それを子どもが「ばらして遊ぶ」ことが出来るんじゃないか、という期待が
有るんじゃないかと思います。
が、今の(典型的にはC言語の)ソースって、子どもどころか大人でもバラせないような醜い代物なんで(^^;、
それ自体の教育効果がどれくらい望めるかってーと、ちと疑問かなと思っています。
部品を通り越して分子にまでバラされてしまうような小さすぎる粒度を、
いきなり突き付けられる感じなんで。
たとえばSqueakToysの粒度が、どれくらい「適切」なのかは、俺にも判りませんが、
SqueakToysじゃなく現状一般的なOSだのなんだのといった足周りのソースは、えてして、
そういう小さすぎる粒度の言語に基づいて作られています(よね)...
子どもに易しいものは、当然大人にも易しいんで、
開発効率という意味でも、
「より多くの部分が、より高級な言語によるproductで構成されたシステム」が
もっと増えて欲しいなと思っています。
どーなんでしょう？例えばlinuxでいえば、
kernel以外は全部、Cじゃない(Cより高級な)言語で書かれたもので構成されたDistroとか...
＃ただ、Unixに関していえば、新しくもないUnixというものを、いまさら他の言語で作り直す必要が無い、
＃というのも事実上言えてますが。
Re:見当外れだとおもうが、、、 (スコア:1)
GC の具体的な実装を知る必要はないのですが、なにがメモリを消費するのか、ということさえ知らないプログラマが多いのが現状のような気がします。
例えば string の足し算(つまり append) をすれば、そこで当然のごとく新しい string が alloc され、それを回収するために(プログラムによっては) 頻繁に GC が起きてしまう、ということが直感的にわかっていないと、3重ループの一番内側など計算のボトルネックになりそうなところで、そんな無駄遣いをしてしまう。そんなところはちゃんと GC に頼らないで自分で管理しているメモリ領域（例えば buffer のようなもの)で文字列を操作するようにして欲しい。
つまり、GC は万能ではないのに、GC に頼ったプログラムしか書けない、GC に頼ってはいけない部分がどこかがわからない、といったことは、結局、下で起きていることを想像できないからではないのかという気がしています。
いわば、現状のプログラマ養成は、建築の人に土台の作りを教えないようなもののような気がしています。なので、砂上の楼閣を平気でつくって、製品として納入しようとする。
まあ、こういうことを言うようになったのは、自分が歳を取ったからなのかもしれません。
# いまだに emacs + make + gdb ですから。
# マウスを使わざる得ない統合環境はなかなかなじめないんですよね。
# すみません。年寄りの愚痴です。
たしかに一般向けのものとして、優しくプログラミングできるものがもっとそろって欲しいと思います。ただ、そういう簡単にプログラムできるようなものは、オフショアで、つまり労働力の安い地域でも簡単に作れるわけで、教育で日本のIT力をあげるとか言った観点からはあまり貢献はしない気がします。だからソースで勉強しろというのは短絡かもしれませんが、下でうごめいていることを感覚として知っていることが、上で高度でかつしっかりしたもの(=高付加価値)を構築する上では重要だと考えているので。
# かなりこのスレの本筋からはハズレた議論になり、申し訳ない。