アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
パイプについての考え方 (スコア:1)
「結局どうやってこの分野に改革を起こすのか」というのがある。
つまり、
「ロードマップはできたけど、どうやって実装しよう」
「実装は終わったけど、どうやってみんなに使ってもらおう」
というところがある。
この問題に対するアプローチのやり方はいくつかあると思うけど、
趣味のプログラミングとしては、「現状+α+α+α+…」
といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
実現はありえない、と思ってる。
そういった意味で、G7 さんの意見はしきいが高く感じちゃうなぁ。
で、そういった意味からすると r
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
うーん。Macみたいに「魅了する」って手を使いますかね(藁
>実はプログラミング言語の機能の問題ではなくて、
>それを取り巻く環境(=インストールされていない、実績がない、経験者が少ない、規模が大きい…)だ、
規模については、shだって別に小さいわけじゃないと思います。
きちんと(つまり意図通りに)動かすために覚えないとならんことは、結構多いと感じてます。
俺はshとかを覚えたのが結構後から(CやDelphiより後)だったもんで、後から覚える手間(^^;をかけたわけです。
まずshありきという生活スタイルではなかった。
そんな俺から見ると、shもまた1つの、そこそこ複雑な「言語」、でしかないんですよね。
そういう意味ではVBとCとDelphiとRubyとshの間には、あまり差が無いなあと。
>sh はそこが優れていて、しかも日常的に要求される程度のことは一通りこなせる。
「要求」って何なんでしょうね?
たとえばshはデータ構造を作るのが絶望的に難しい(でしたよね)のですが、
日常的にはそんなものは作らない、と?
個人的には、3割くらいしか同意できない感じです。
俺は、何かScriptを書くときって、結構頻繁に、途中でムカついてshからRubyに書き換えたりしてます(^^;
逆にいえば、(手軽な)言語がそういう点をもっと積極的に支援してくれたなら、
もっとカジュアルにみんなデータ構造をばりばり使えるようになるんじゃないかと。
#RubyにLinkedListクラスやTreeNodeクラスが無いのが不思議なのでG7
#もちろん簡単に作れるわけですが、良質な雛形が最初から装備されてても良さそうなもんだろと…
つまり、言語は思考を規定してるんだと思います。
たとえばこの例では、データ構造を駆使しないのが「日常的な」用途だ、と規定してしまってる、と。
>グッドラッパー
ちょっとどうかなと思っています。
勿論実用的には頷ける意見なのですが、
実用的に過ぎるというか、頭隠して尻隠さずに陥る可能性が結局消えないというか。
#今月のLinuxだかなんだかの雑誌に、Smalltalk(Squeak)がDQN言語であるかのように書いてあって、がっくりしたのでG7
#少なくとも言語仕様は万全だろうに。
>ネットワークサービスのレイヤになれば、
>ほとんど完全に抽象化されたサービスを利用者に与えることができる。
いや、それもどうかと思います。
ここ [hatena.ne.jp]見てみてください。いわくEJBはもう死んでいると。
少なくとも俺は頷いた。
本当にどこでも使うくらい汎用なものは、ネット経由せずLocalなほうが(速度的に)圧倒的有利だし、
そうでないものは大抵、多少なりとも環境依存性があるもんだ、と感じてます。
というか実のところ、俺って「ネットワークサービス」って寒いなぁと思っています。
まあ粒度が充分大きければ、ああいうPipelineアーキテクチャも結構役立ちますが、
もう少し木目細かく仕事したいときには不自由します。それは例えばそれこそGUI Widgetのような、ね。
それこそ上記URLでServletを引き合いに出してるように、
shだってCGIを作れるという意味ではアレなわけです。
#てゆーか元を正せばHTTPとPipeが似てるっていうだけのこと、かな。
でも、逆にいえば、HTTP&Pipeは、所詮ソコまでのモデルだってことだと思ってます。
あと、HTTPとPipeの差としては、クライアントの頑張り度合いですね。
HTTPって、鯖は楽ですがクライアントは凄まじい仕事をする。
GUIのレンダリング云々って話もありますが、ここではそれじゃなく、
通信の登りと下りの両方を面倒観てるって点が。これはPipeには無い性質なわけで。
また前述の切り替え自在性もPipeとの大きな違いですね。
長くなりましたが、こうして書きながら考えるとつまり、
Pipeは「粒度が大きいもの専用」ってところかと。
また登り下りを同時に捌けなければ到底Widgetには成れないわけだし。
>そして CORBA はそうでないところに問題があったと思う。
>あまりに OOL に便宜を図ったために可搬性が低下した、ということで。
いやー、CORBAは、重いから駄目なんだと思います。
OOP専門は不味いかも知れないけど、少なくとも参照ベースは譲れないです。
個人的には、sh(やそれと近い立場の言語)が、参照ベースに移行してくれたら、
なんとか戦えるかなーと。
#あとは、OOPなんてのは、動的な構造体っていうかHashtableが有れば、簡単に作れますからね。
#身近な例はJavaScriptでしょうか。
#Prototypeベースな軽量言語は、基本的にshとほぼ違わない面倒さ(楽さ)だと思います。
参照で参照以外をエミュレートするのは簡単です(失うのは性能だけ)が、
逆はなかなか困難です。この差は決定的だと感じています。
>新しい言語の勉強をしないような人の開発リソースだって
>含めることができるほうが有利ですよね。
「言語は思考を規定する」んで、よりマシな言語を知らない人の思考は、期待できない、という面が有ります。
そういう人もまあ、実装以外で協力してくれればいいんですし(^^;
参照を知らない(例:ポインタをいつまでたっても理解しない(笑))人を支援するにも、
限度ってものがあると思います。どっかでパラダイムシフトが必要。
sh方式だと、やれることに限界があるんで、まあ。
>パイプというものを利用したプログラミングの形だと
パイプの利用範囲自体に限界がある、ってのが味噌だと思います。
Pipeは限られたアーキテクチャしか表現できませんが、
参照は本質的になんでもやれます。表現力が違いすぎて比較にもならない。
で、俺としては、初心者(?)の思考をパイプに縛り付けたくないし、熟年に対してもそう。
>趣味のプログラミングとしては、「現状+α+α+α+…」
うーん?
俺は一時期、趣味で「冬休みに言語1つ覚える」みたいなことをやってましたけど。
もちろん(少々の)パラダイムシフトも含めて。
趣味にも色々あるけれど、プログラミング「が」趣味だと、壁は高くないかも知れません。
趣味の手段としてのみ言語を使う人ならば、そうはいかないだろうけど、
言語を趣味と見なさずに結果だけを趣味とする人、ってのは俺は個人的には想像つかない…。
趣味プロだって、いつからかOOPが当たり前になっちゃったわけですし、
別に良いんじゃないでしょうか。
また、古典的手続き指向が「(初心者に)楽」かと問われると、俺にはさっぱりそう思えません。
少なくとも俺は楽だからこそOOPをしてるわけです。しかも長大な奴だけじゃなく使い捨てでもです。
Re:パイプについての考え方 (スコア:1)
それが理想的なんですけどねぇ。
> たとえばshはデータ構造を作るのが絶望的に難しい(でしたよね)のですが、
> 日常的にはそんなものは作らない、と?
いやいや、なんだか話の流れでやっとわかってきたんだけど、
みなさん sh に対して「メモリ上のデータ構造が複雑にできない」と
言っているわけですよね?
でも、sh ってそもそもメモリ上で完結する言語じゃないでしょう。
ruby にしろ Java にしろ、XML を扱うためにはライブラリが必要。
同じように sh だって適当なコマンド群さえあれば XML だって扱える。
どの Unix でも標準的に head, cut, nawk, sed なんかはあるから、
リスト、木構造程度は標準的に扱えると見ていいし、
ハッシュテープルに至っては一時的な作業ディレクトリに
ファイル名をキーとしてデータを置くだけで実現できる
(まぁ本当にそれがハッシュテーブルとして実装されるかどうか
はファイルシステム依存なんですけど)。
もちろんこれを使っての OOP も可能。
ここ数年 sh でスクリプトを書くことも多いけど、
sh は日常的な問題の9割をすばやく解決できる実用的な言語ですね。
まぁきれいではないですが。
じゃあ実用的な意味で、何が sh の問題かといえば単純に速度の
問題で、その問題のうちのほとんどはプロセス生成と初期化の
オーバーヘッドにかかっている。
本来、「プロセス」というのは(単語の意味から考えても)
永続的な状態を保持しないものでしょう。
状態を保持するのは「ファイル」であって、
プロセスは処理のために一時的に状態の高速なキャッシュを
メモリ上に展開しているに過ぎない。
もしメモリ上にどうしても状態を置きたくなった場合、
プロセスは長期間稼動することになる。
使い捨てのはずのメモリに状態を乗せなければならないので
信頼性が必要になるし、そうするとプログラムの難易度は上がってくる。
で、G7 さんとしては
「メモリに状態を乗せるならプロセスの壁が要らない」と
いうことになるんだろうし、
俺としては「プロセスは状態を持つべきじゃない(=パイプだ)、
それは作業用か、高速化のためのキャッシュに過ぎない」
ということになるのかな。
> 長くなりましたが、こうして書きながら考えるとつまり、
> Pipeは「粒度が大きいもの専用」ってところかと。
> また登り下りを同時に捌けなければ到底Widgetには成れないわけだし。
粒度が大きいもの、関係が疎なものってのはそのとおりでしょうね。
まぁ「上り下りを同時に捌く」ってのはパイプが処理すればいい
内容かなぁと思いますが。
> 個人的には、sh(やそれと近い立場の言語)が、参照ベースに移行してくれたら、
> なんとか戦えるかなーと。
sh っぽい言語が参照ベースに…
いいですねそれ、おもしろそう。
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
>言っているわけですよね?
>でも、sh ってそもそもメモリ上で完結する言語じゃないでしょう。
完結しないからこそshは駄目だ、と言っているわけです。
>ruby にしろ Java にしろ、XML を扱うためにはライブラリが必要。
XMLは、構造の名前じゃなく、構造を使った製品(劇藁)の名前ですよー。
>どの Unix でも標準的に head, cut, nawk, sed なんかはあるから、
>リスト、木構造程度は標準的に扱えると見ていいし、
head, cut, nawk, sed(とsh)を組み合わせてツリー構造ですか?
どうやりゃマトモに記述できるのか、ちょっと俺には想像がつきません。
実際、プログラムを作ってる最中に「あ、これは(例えば)ツリーが必要な課題だったのだな」と気付いて
慌ててshからRubyに乗り換える、ってことが、俺は頻繁に有ります。
いや、アクロバティックにとか、非効率でもいいとか、ということでしたら捻り出せますけど、
ちょっと日常(そう!まさに日常的プログラムつくり)的には、パズルには付き合いたくないですね。
なお、子プログラム…たとえばawkとか…の「中」でツリーを表現できました、ってのはナシですよ。
それはshじゃなくawk言語がやったことですから、shの手柄にはカウントできない。
そしてそれは恐らくXMLについても言えることです。
>ハッシュテープルに至っては一時的な作業ディレクトリに
>ファイル名をキーとしてデータを置くだけで実現できる
>(まぁ本当にそれがハッシュテーブルとして実装されるかどうか
>はファイルシステム依存なんですけど)。
ハッシュ関数かどうかはInterface的にはどうでもいいんで、
辞書として有能(^^;かどうかについてのみ注目しますが、
○ファイル名の文字制限を受けるし、そもそも文字しかキーになれないし。
rubyのHashは任意のObjectがキーになれます。
○「一時的な作業ディレクトリ」の取り扱い。
以前にも言ったように、Filesystem上に置くとGlobalというか寿命MAXになっちゃうんで、
他の奴(ローカル変数的なもの)との干渉の心配とか、
ガベコレの心配とかを、しないとならなくなる。
という辺りが、ちょっと弱い。#まあ無名ファイルをサポートするようにOSが変身してくれればOKですが。
そしてもう1つ、致命的に、
○(オンメモリより)遅い
という…
ハッシュつーか辞書って、何か高級なものと世間では思われてるようですが、
本当は、数字添え字配列と同じ程度には「お子様でもわかる」もの
なんだろうと想像しています。
なので、もっと楽に(かつ低コストに)使える環境が増えて欲しいわけです。
小学生(?)の頃から辞書型に慣れ親しんで欲しい。
で、そうすると、ファイルじゃ重いっしょ、トリッキーっしょ、という話になる…。
ちなみに余談ですが、デバッグのためになら、あらゆるデータがファイルに落ちてくれるのはとても嬉しいです。
かったるいデバッガじゃなく軽便なsh(やExplorer?)で「データのかたち」が丸見えになるんだったら、こんな嬉しいことはない。
つーか、もしそれが一般化したら、GNU DataDisplayDebugger なんて不要ですよね(^^;
うーん。これは益々、無名ファイルやオンメモリファイル(藁)が有ってくれると嬉しいなあ。
#ある意味で、「ワンレベルストア」と紙一重かな。
>ここ数年 sh でスクリプトを書くことも多いけど、
>sh は日常的な問題の9割をすばやく解決できる実用的な言語ですね。
まあそれはツリーを書きたくなる度合いが何割を占めるか、というその人の事情に依存しそう。
#てーか、なんでこんなにツリーが多いんだろう?>俺
#あ、そうか。「プログラムつくりの支援」のためにRubyすることが多いから、かも。
>じゃあ実用的な意味で、何が sh の問題かといえば単純に速度の
>問題で、その問題のうちのほとんどはプロセス生成と初期化の
>オーバーヘッドにかかっている。
前提が崩れてるので既にアレですが、それにしても、オーバーヘッドは馬鹿にならんです。
ソース中の数万件の単語をぶん回すときなんか、いちいちsedとか起動してたら
マヂで10倍くらい処理時間が変わってしまうんで…
で、一方で、例えばRubyしか知らないユーザが、shしか知らないユーザに比べて、
なにか失っているものがあるか?ってーと、
("過去の資産"を除けば)あんまり無いんですよね。ここが味噌。
>本来、「プロセス」というのは(単語の意味から考えても