>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コンパイラの「最適化」によって得られる安価さのほうが支配的だったんじゃないか、と。
ローカ
Re:最も最近覚えたプログラム言語＝脳内基本構文 (スコア:0)
>一番素朴な実装なら
>その通りなのですが、
>実装を後から交換するのも楽々だってのも
>メソッドチェイン方式の利点だと思います。
それはメソッドチェインの影響ではなくて、抽象化されたデータ型の恩恵ですね。
抽象化されていれば良いので、こんな風にオブジェクト指向言語でなくても可能です。まどろっこしさが拭えないのは否めませんけど。
rows = SelectRow(rows, 'hoge')
rows = SelectRow(rows, 'fuga')
values = CollectCol(rows, 'y')
つまり、その利点を生み出す元は「言語の機能」ではなく「設計」に有る訳で、この言語じゃないとこういう設計はできないという考え方は、言語に縛られていて嫌だなあと思う次第です。もちろん言語の機能から想起させられる設計や、言語によっては実装が面倒な設計というのは有りますが、本当に必要なものなら、そういうものとは関係なしにそう設計しますよね。というか、設計とはそうでなくてはならない。
>するとですね。
>リソース少ないと大騒ぎしてた当時の、
>BASICって、
>すごく無茶なものだったんだなーと思うんですよ。
>
>なんせあの時代のくせに
>ガベコレからなにから揃ってるお気楽環境だったわけですから。
>あまり意識されてませんでしたが。
BASICはガベコレしませんよ。参照というものが無く、変数のスコープ以上に長生きなデータが無いので、変数の管理以外に回収の仕組みを用意する必要がないのです。サブルーチンを越えて長生きするデータはすべてグローバル変数に入れる必要が出てくるので、大抵の場合、プログラムの先頭で必要な変数を全て定義して、あとはそれをやり繰りして行くという形になります。
今となってはそれは悪いプログラムの書き方の代表ですが、それはコンピューターに代わって人間がメモリを管理することになるからなんですよね。
>理由は乱暴にいえば皆がLispを知らなかったからです。
何となく、Lispから入ると「Lisp以外は言語に非ず」という片寄った思想になりそうでイヤです。(^^;)