>buf = [] >for x in a > if x.hoge continue > if x.fuga buf += x.y >end > >みたいなのは、 >「1つの」ループの中に >色んな分岐やデータ収集が >ごちゃ混ぜなのが厳しいです。 それはごちゃまぜに書いているからであって、以下のようにすれば行の選択部分と行に対する処理の部分にきれいに分かれます。
buf = [] for x in a
if x.hoge continue
if !x.fuga continue
buf += x.y end
初めて覚えたプログラム言語=脳内基本構文 (スコア:0)
原始的であるため (覚えることが少ないため)、その後の言語は新しい概念を差分とし
て覚えればよかったぶん楽でした。(古い因習を引き摺る弊害もありますが)
いま初めてプログラム言語を覚えようとすると、言語以外の事にも色々気を配らなけれ
ばならないように思うので、大変な気がします。
ただ、だからといって箱庭の簡易言語がいいかというと、それも難しい問題です。
私はアイディアを脳内でコーディングする時には、様々な言語のいいとこ取りをするの
ですが、覚えたのが古い言語ほど現在メインで使用している言語に準ずるくらい基本文
法に馴染みがあるような気がします。
最初にオブジェクト指向言語を覚えた人は、無意識にそう考えるものなのでしょうか?
だいぶ矯正されたとは思いますが、私はいまだにスパゲッティ指向ですよ。:-P
最も最近覚えたプログラム言語=脳内基本構文 (スコア:0)
そうかなあ…?
私は逆に、
それまで知ってた言語のカッタルサに耐えられなくなって次の言語に乗り換える、
ってことを繰り返してたので、
脳内基本構文は今一番新しく覚えた言語になってます。
で、言われて気付いたのですが、それ多分逆なんですよ。
BASICは覚えることが「多い」んです。
BASICは「覚えること」が多いんです。
共通化して考えれる部分が少ないですから。
(私が知ってる)当時のBASICって、ほとんどの機能が「命令」でした。
そして命令は言語ビルトインであり、不動なものだった。
するとユーザはそれを「丸暗記」するしか無いん
Re: (スコア:0)
マテ
何を覚えてたんだって?
手続き型言語では繰返しは覚えるもんでないでしょ?
ごりごりと書くもので。
関数型言語だとか、Rubyではinjectとか使って自作するのかとは思いますが。
Re: (スコア:1, 興味深い)
for「文」とかwhile「文」とかの文法を、です。
あ。(今は)文と式の違いを指摘したいわけではないので、
for「式」と呼ぶ言語であっても扱いは同じとします。
>ごりごりと書くもので。
それは(私の言い方でいえば)
繰り返しじゃなく、
繰り返しの中っていうか後に続く実行部分、です。
for (xxx) yyy
のyyyの部分ね。
今気にしてるのはそこじゃなく
for (xxx)
までの部分です。
>関数型言語だとか、Rubyではinjectとか使って自作
まあ結果的にはそうなんですが、
この繰り返しの自作の話は、
関数型言語限定の話題だと強く言い切る必要は無い話題だと
思うんです。
というのは、やってる
Re: (スコア:0)
>for x in a
> if x.hoge continue
> if x.fuga buf += x.y
>end
>
>みたいなのは、
>「1つの」ループの中に
>色んな分岐やデータ収集が
>ごちゃ混ぜなのが厳しいです。
それはごちゃまぜに書いているからであって、以下のようにすれば行の選択部分と行に対する処理の部分にきれいに分かれます。
buf = []
for x in a
if x.hoge continue
if !x.fuga continue
buf += x.y
end
CやBASICなどまだリソースが潤沢でなかった頃から存在する言語で書くと、なぜか1ステップでも1バイトでも少なくみたいな貧乏
Re:最も最近覚えたプログラム言語=脳内基本構文 (スコア:0)
> if !x.fuga continue
ああ、これは後から気付きました(^^)
が、それでも、
「その程度の綺麗さでは満足できない」自分が居ます。
Ruby(やLisp)を識ってしまった直後から。
(字面が)一個のループの中に詰め込まれてしまってる、ってのが痛い。
>なぜか1ステップでも1バイトでも少なくみたいな貧乏性
貧乏性の価値自体は理解するし(場面によって)賛同するんですが、
ほんとにC/BASICの書き方のほうが安価だったのか?ってのは
時々疑問に感じます。
どっちかというとCコンパイラの「最適化」によって得られる安価さのほうが支配的だったんじゃないか、と。
ローカル変数を(スタック相対の)番号アクセスに変換するのも、広い意味でいえば「最適化」です。
現実にはそれ以外に有意義な実装が無い(無かった)ので、「最適化」というよりは「それしか無いから当然化」ではあるんですが、それはそれとして。
>buf2 = []
>for x in buf1
> if x.fuga buf2 += x
>end
前述のwhereとかが
一番素朴な実装なら
その通りなのですが、
実装を後から交換するのも楽々だってのも
メソッドチェイン方式の利点だと思います。
たとえば遅延評価できるリストに交換したくなったら、
(大規模データを扱いたくなったら有りがちな話です)
手続き型言語で頭から順番に書いてあったら、
大改造になっちまいます。
メソッドチェイン方式だと、
whereメソッドの振る舞い、
言い換えると[]だのなんだのといった奴ら(もしOOPのObjectならば)の性質、を
修正してやれば一発です。
アプリコード(?)のほうは一文字も変えずに済む。
お仕着せのfor文とかに縛られてる記述形態だと、
そのへんが厳しいです。
さて、
脱線ですが。
リストが遅延評価型に交換されると、
たぶん、データ置き場としてのリストを「余計に」生成するコスト(メモリ)も
あまり気にしなくてよくなる、と思います。
すると、やってることは上記でいう変数xだけしか使わず回すのと大差なくなる…とまで言い切らないにせよ、それにどんどん近づいていく。
するとですね。
リソース少ないと大騒ぎしてた当時の、
BASICって、
すごく無茶なものだったんだなーと思うんですよ。
なんせあの時代のくせに
ガベコレからなにから揃ってるお気楽環境だったわけですから。
あまり意識されてませんでしたが。
あれがアリだったのだとすれば、
逆にいえば、当時足りなかったのはむしろ
BASICのパラダイムを脱却するような方法論「だけ」
だったんじゃないか?という気がするんですよ。
あの時代は、言語の高級度と、効率とが、完全に相反するものだ、という考え方が市井では支配的でした。真実じゃないけど支配的。
理由は乱暴にいえば皆がLispを知らなかったからです。
なにを自動化し、なにを手動にすれば、効率や書きやすさはこう変化するんだ、という色々な試みが、メジャー路線には存在しなかったんですよね。
#LispポケコンでIT人生を始めたかったものだ、と未だに時々思うのでAC
まあいずれにせよ、
「ハードの進歩」のおかげで、
貧乏性を発揮しないとならない閾値は、だんだん上にあがってきてます。
もちろんターゲット環境次第ですが、
たぶん「あらゆる」ターゲット環境はそうやって性能が「あがって」ますよね。
(CPUとかがわざわざ絶賛性能低下中のジャンルって、有るんでしょうか??)
Re: (スコア:0)
>一番素朴な実装なら
>その通りなのですが、
>実装を後から交換するのも楽々だってのも
>メソッドチェイン方式の利点だと思います。
それはメソッドチェインの影響ではなくて、抽象化されたデータ型の恩恵ですね。
抽象化されていれば良いので、こんな風にオブジェクト指向言語でなくても可能です。まどろっこしさが拭えないのは否めませんけど。
rows = SelectRow(rows, 'hoge')
rows = SelectRow(rows, 'fuga')
values = CollectCol(rows, 'y')
つまり、その利点を生み出す元は「言語の機能」ではなく「設計」に有る訳で、この言語じゃないとこ