アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
パイプについての考え方 (スコア:1)
「結局どうやってこの分野に改革を起こすのか」というのがある。
つまり、
「ロードマップはできたけど、どうやって実装しよう」
「実装は終わったけど、どうやってみんなに使ってもらおう」
というところがある。
この問題に対するアプローチのやり方はいくつかあると思うけど、
趣味のプログラミングとしては、「現状+α+α+α+…」
といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
実現はありえない、と思ってる。
そういった意味で、G7 さんの意見はしきいが高く感じちゃうなぁ。
で、そういった意味からすると r
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
> といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
> 実現はありえない、と思ってる。
それってメインストリームの変更方法じゃないですか?
言ってみればC言語的な。
わたしは、むしろ趣味だからこそ全く違うものをいきなり持ってこれるのだと思います。
具体的な手法は、その言語・環境で動くキラーアプリを作るって、オープンソースで配布する。
バイナリは自分好みの設定をデフォルトにして配布する。
そうすると、その設定が気に入らない人が出てくる。
ここで、じゃあソースからいじっちゃえ、という人が出てくれば言語が広まるはず・・・と。
Re:パイプについての考え方 (スコア:1)
まあviもそんなに美ではなくバッドでしょうね。
ただ、やたらと多いルールを「大脳が」覚えるか「小脳が」覚えるか、
という違いは有るような気がします。
emacsは知りませんが、viだと、その操作体系のうちかなりの割合を
小脳に覚えさせられます。つまり無意識にやれちゃう。
そして意識は(無意識層の存在を意識せず)対象であるファイルと交信しようとしますから、
結局vi方式は、意識と対象物との間の「BUS」が広くなるんですよね。
#少なくともカーソル移動キーの個数が 約4 vs 約100 では、勝負になりませんね>世間の多くのカーソルキー依存エディタ
>そういえば、ふとソフトウェア配線 [no-ip.com]を思い出しました。
>結局今の話って目指すところはこれと同じですよね?
あはは。どうでしょうか…
#ところであの家主氏、言ってることを結局理解してくれたんだろか??
ソフトウェア配線については、例の業務屋さん(藁)が推してる一連の奴(DIconとかいう奴)が、
結果的に近いかなとも思っています。
まあ実際「DIconはDelphiと似てるよね」という問いにはYESという解答を貰っているんで、
たぶんそうなんでしょう。
>そもそもの設計の難しさをOOPの難しさと混同しているような感じがします。
う。素晴らしいどーさつ。
憂鬱本の言い回しを借用するならば、
「今まで見なかったことにしていた「設計の難しさ」が OOPで隠せなくなった」
といった所かな。
>極端な話、OOPってpush(array,element)がarray.push(element)になっただけじゃないですか。
まあ字面は飾りで、偉い人にはそれが判らんのです。
#ここで某氏の名前を挙げたくなる黒い悪寒…
俺はOOPで、「能動者の逆転」というパラダイムシフトがあったようには思います。
OOPは「される」の世界なんですよね。イベントが飛んできてCall「され」て初めてお仕事します的世界。Callback世界。
#そういう意味では、DIconのDI(DependencyInjection)の前身であるInversionOfControlってのは噴飯モノです。
#Callback、つまりOOPやWindowsやMac(藁)の時点で既に、ControlはInvertしていたっていうのに。
#気付いてくれてありがとう、っていうか初手で気づけよ>ファウラーたん
余談ですが、Rubyが気楽だと言われる所以の1つに、この「逆転」を無視したければ無視できる、
という点が有ると感じています。
つまるところ「main」が我が手に有るか否かの差なのですが、
RubyはScript言語らしく、まずmain相当物がユーザに開放されています。てゆーか何も考えずに書けばmainになる。
とりあえず命令(手続きやMethodのCall)を書ける、ということは、とりあえず自分が「する」側に立てる、ということです。
これがノーコストでやれるのがRubyです。あまりOOPくさくない、「する」側の視点で、とりあえず書ける。
で、ちょっと気のきいたことをしたくなったら、さりげなく「される」側に回ればいい。(これも、無料ではないが低コストで回れる)
「する」と「される」の駆動比率を、自在に(かつ楽に)加減できる。
>それよりも、初心者ができないのって、問題の分割なんですよね。
>Aという問題をA1,A2,A3に分割できれば、
>def A; A1(); A2(); A3(); end
>で終わりなのに、それができない。
すばらしーどーさつ*50
正にソレです!!
ちなみに俺の近所にそういう奴らがいない保証は無いです(T_T)
UseCaseをIncludeで分解することすら出来ないし。
てか、既にそういう仕様書が山のように蓄積してるし(T_T)
これ、どう始末しろってのよって感じぃ…鬱…
#今日煩悶したネタも、そういや突き詰めれば「問題分割」ネタだったよなあ…(T_T)
初心者という呼称は不適切だと最近思っています。
経験した「時間」も短くないし、まして「心」なんて初心から遥かに離れているわけですが、
それでも出来てない奴らってのは、
○初脳者
○初能者
とでも呼べばいいんでしょうかね…
#先輩や上司は、こういう奴らを"刈ら"ないと駄目だって。刈るのは首である必要は無いけどね。