アカウント名:
パスワード:
言語の数だけ概念が有る(という言い方でもなお過小評価だが)わけだから、 言語にかこつけて(^^;それらを片っ端から知っておくのは、損はなさそう。
同意. 少なくともその言語を作った人は「既存の言語ではだめ」と思って作ったわけですし. プログラム言語をいじることによって,その言語の作者の思想に触れる,というのはあると思います.
で,更にプログラミングの概念の歴史的変遷,というのも見えてきますね.
# 個人的には Lisp が必須だと思うが
データも関数も区別なくS式なのがよい? C#はXML Schemaのインテリジェンスを使って自動的にデータを扱えるよ。
Call-CCなんかは例外で十分。プログラミングモデルを壊すだけ。
継続は、その実用的な価値よりも、スタック型計算モデル (関数を呼んだらスタックの上のほうで計算されて、帰って来たら それでおしまい)みたいな概念をぶちこわす存在として 有益であるような。継続的な見方 (call/ccに限らず、 継続渡し的に制御フローを見るやりかた)は、 関数呼び出しと関数からのリターンは実は同じであるとか、 普通の手続き型言語をやっていたのではなかなか お目にかかれない概念を提供してくれます。 ただ、初心者に教えるべきかどうかは確かに疑問。 ある程度、プログラミングモデルが固まった時に教えて 新鮮な見方を提供するって方がいいのでしょう。
無名関数とかクロージャとかあんの?末尾再帰も?
delegateは確かに(状態+処理を渡せるという意味では)クロージャと 等価だけれども、lambdaみたいにインラインでコードブロックを がんがん書いてそれが自動的に状態を内包してくれる、という感覚 とはかなり違うと思います。
「 PythonとLispの関係について [dreamhost.com]」 でPaul Prescodが反論しているように、内包される状態は インスタンス変数という形でプログラマが明示的に指定すべき、 というのもまた一つのパラダイムでしょうが、それは クラスを作らなくてもlambdaでお気軽に状態を包んでしまえる のとはやっぱりスタイルが違うので、善し悪しは別にして 両方学んでおくのは有意義でしょう。
あ、今までdelegateにコードブロックを直接渡せるという例を 見たことがないのでこう書いていますが、もしそういうことも できる(そしてそのコードブロックから参照される変数が クローズされる)のならこの意見は当てはまりませんね。 ただ、Schemeなんかのクロージャのひとつの基礎になっているのは 「全ての変数は無限エクステントを持つ」というモデルなので、 変数がローカルフレームと命運を共にする モデルとはやっぱり相容れないように思えます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
結局は、「よりよい教育」か否かが問題 (スコア:1)
そこまで言わないにしても、教育的「効果」の良し悪しってのものは、無視するわけにはいかないかも。
どれだけ「良い」言語で勉強させるか?によって、出来上がる(^^;学生の質は
結構変わってしまったりしないだろうか?ということです。
心配するのはやっぱり、「言語は思考を規定する」という意味での、言語の影響力ですね。
変な面のある言語で刷り込まれてしまうと、痛いわけで。
たとえば往年の行番号BASICに刷り込まれた人々ってのも、それだったかなと。#そういやあれもMS由来だったなあ。
そうい
Re:結局は、「よりよい教育」か否かが問題 (スコア:3, 参考になる)
プログラミングを独習するには10年かかる [neweb.ne.jp]でも書いてあるが、
プログラミング言語は複数学ぶことが必要だろう。
そのうちの一つがC#であっても、何ら問題は無いと思われ。
# 個人的には Lisp が必須だと思うが
# mishimaは本田透先生を熱烈に応援しています
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
それもそうですね。少なくともどれか1つしかやったことが無い人ってのは
「話にならない」感じがすることがしばしば有ります。
言語の数だけ概念が有る(という言い方でもなお過小評価だが)わけだから、
言語にかこつけて(^^;それらを片っ端から知っておくのは、損はなさそう。
ただ、
>そのうちの一つがC#であっても、何ら問題は無いと思われ。
C#の実力とか、逆に「毒度」とかが、どうなってるか次第だと思います。
なにごとも経験とはいっても、あんまり変な言語が「そのうち」に入っていると、ちょっとねえ。
C#が変かどうかはさておきますが。
># 個人的には Lisp が必須だと思うが
そうらしいですね。経験してないので、今ごろ困って(ってゆーか…)います(^^;
Re:結局は、「よりよい教育」か否かが問題 (スコア:2, 興味深い)
同意. 少なくともその言語を作った人は「既存の言語ではだめ」と思って作ったわけですし. プログラム言語をいじることによって,その言語の作者の思想に触れる,というのはあると思います.
で,更にプログラミングの概念の歴史的変遷,というのも見えてきますね.
Re:結局は、「よりよい教育」か否かが問題 (スコア:2, 参考になる)
現状でも,情報系の学科・コースでは複数の言語を扱っている所がほとんどなのですが,それらの間の諸概念の関連を(理論的内容もある程度含めて)きちんと扱っている授業は案外少ないようです.その辺を理解していないと,多くの学生さんは結局メジャーとされる言語(例えばCなど)だけわかっていればいいと思ってしまうようです.
Cなどによる初歩的なプログラミングの講義を受講した学生を対象にHaskellやStandard MLを使った講義をしたことがあります.後でまたCのプログラムを書く際,プログラムの見通しがよくなってバグが少なくなったと報告してくれた学生が複数いたのがちょっとうれしかったです.
あと,言語だけでなく仮想機械やミドルウェアのような実行環境もいろいろ経験するといいのでしょうが,大学の講義や演習ではなかなか全てをカバーしきれませんね.教えられる人も限られてきてしまいますし.
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
「毒度」ってなに?はさておき、言語ってプログラミング言語に関わらず、「考え方」を規定するのでどの言語が悪いかなんて、へんな考
Re:結局は、「よりよい教育」か否かが問題 (スコア:1, すばらしい洞察)
言語そのものからくる繁雑な制約を気にせずに、問題をどう解くかだけに専念しやすい言語から入ることで、まずはプログラムを書くときに何に注目しなければいけないかをしっかり学ばせたほうが良い、というコンセンサスがアメリカの計算機学科界隈にはできあがっているような気がする。そういう判断から、実際に学部1年向けにscheme、ML、HaskellやJavaといった比較的「評判」の良い言語を使っている計算機学科が多いのだと思う。
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
データも関数も区別なくS式なのがよい? C#はXML Schemaのインテリジェンスを使って自動的にデータを扱えるよ。
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
んー、C# の詳しい文法を知らんので何とも言えんが、
オブジェクト指向言語と関数型言語のパラダイムの違いについては
こんなスレ [2ch.net]があるよ。
# mishimaは本田透先生を熱烈に応援しています
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
(特定の)モデルを仮定すれば、そこでLisp系のモデルのうちの幾つかの要素を取りこぼしている恐れが、つきまとうんではないですか?
少なくとも今回(C#対Lisp)においては、取りこぼすような気がします。
「例外で十分」と言い切っちゃった瞬間に、Call-CCに出来て例外に出来ない何かを「切り捨てて」しまっただけのことであって。
ほげ言語のパラドックス [dreamhost.com]を思い出します。
いや、Lispであることとか、その優位性とか、についてはここではどうでもいいんですが、
少なくとも、馴染んでるものとは「違う」言語の能力を、どう取りこぼさずに認識するか?ってのは、問題であるように思います。
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
継続は、その実用的な価値よりも、スタック型計算モデル (関数を呼んだらスタックの上のほうで計算されて、帰って来たら それでおしまい)みたいな概念をぶちこわす存在として 有益であるような。継続的な見方 (call/ccに限らず、 継続渡し的に制御フローを見るやりかた)は、 関数呼び出しと関数からのリターンは実は同じであるとか、 普通の手続き型言語をやっていたのではなかなか お目にかかれない概念を提供してくれます。 ただ、初心者に教えるべきかどうかは確かに疑問。 ある程度、プログラミングモデルが固まった時に教えて 新鮮な見方を提供するって方がいいのでしょう。
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
delegateは確かに(状態+処理を渡せるという意味では)クロージャと 等価だけれども、lambdaみたいにインラインでコードブロックを がんがん書いてそれが自動的に状態を内包してくれる、という感覚 とはかなり違うと思います。
「 PythonとLispの関係について [dreamhost.com]」 でPaul Prescodが反論しているように、内包される状態は インスタンス変数という形でプログラマが明示的に指定すべき、 というのもまた一つのパラダイムでしょうが、それは クラスを作らなくてもlambdaでお気軽に状態を包んでしまえる のとはやっぱりスタイルが違うので、善し悪しは別にして 両方学んでおくのは有意義でしょう。
あ、今までdelegateにコードブロックを直接渡せるという例を 見たことがないのでこう書いていますが、もしそういうことも できる(そしてそのコードブロックから参照される変数が クローズされる)のならこの意見は当てはまりませんね。 ただ、Schemeなんかのクロージャのひとつの基礎になっているのは 「全ての変数は無限エクステントを持つ」というモデルなので、 変数がローカルフレームと命運を共にする モデルとはやっぱり相容れないように思えます。