アカウント名:
パスワード:
言語の数だけ概念が有る(という言い方でもなお過小評価だが)わけだから、 言語にかこつけて(^^;それらを片っ端から知っておくのは、損はなさそう。
同意. 少なくともその言語を作った人は「既存の言語ではだめ」と思って作ったわけですし. プログラム言語をいじることによって,その言語の作者の思想に触れる,というのはあると思います.
で,更にプログラミングの概念の歴史的変遷,というのも見えてきますね.
# 個人的には Lisp が必須だと思うが
データも関数も区別なくS式なのがよい? C#はXML Schemaのインテリジェンスを使って自動的にデータを扱えるよ。
Call-CCなんかは例外で十分。プログラミングモデルを壊すだけ。
継続は、その実用的な価値よりも、スタック型計算モデル (関数を呼んだらスタックの上のほうで計算されて、帰って来たら それでおしまい)みたいな概念をぶちこわす存在として 有益であるような。継続的な見方 (call/ccに限らず、 継続渡し的に制御フローを見るやりかた)は、 関数呼び出しと関数からのリターンは実は同じであるとか、 普通の手続き型言語をやっていたのではなかなか お目にかかれない概念を提供してくれます。 ただ、初心者に教えるべきかどうかは確かに疑問。 ある程度、プログラミングモデルが固まった時に教えて 新鮮な見方を提供するって方がいいのでしょう。
無名関数とかクロージャとかあんの?末尾再帰も?
delegateは確かに(状態+処理を渡せるという意味では)クロージャと 等価だけれども、lambdaみたいにインラインでコードブロックを がんがん書いてそれが自動的に状態を内包してくれる、という感覚 とはかなり違うと思います。
「 PythonとLispの関係について [dreamhost.com]」 でPaul Prescodが反論しているように、内包される状態は インスタンス変数という形でプログラマが明示的に指定すべき、 というのもまた一つのパラダイムでしょうが、それは クラスを作らなくてもlambdaでお気軽に状態を包んでしまえる のとはやっぱりスタイルが違うので、善し悪しは別にして 両方学んでおくのは有意義でしょう。
あ、今までdelegateにコードブロックを直接渡せるという例を 見たことがないのでこう書いていますが、もしそういうことも できる(そしてそのコードブロックから参照される変数が クローズされる)のならこの意見は当てはまりませんね。 ただ、Schemeなんかのクロージャのひとつの基礎になっているのは 「全ての変数は無限エクステントを持つ」というモデルなので、 変数がローカルフレームと命運を共にする モデルとはやっぱり相容れないように思えます。
BSD(これはMSらしいが)
rotorについては、8月号のMSDN Magazineで特集組まれてたみたいですね。
Microsoftもソープとかローターとか、何かやらしーよね。
まあ、よく言われてはいるが、
あ。あと重要なものがひとつ。開発したソフトを動かすターゲット環境に対する刷り込みも、問題ですね。 APIとかさぁ。 てゆーか、そのまんま.NET必須っすか? .NETの世界オンリーで脳が漬物になった学生さんって、その後どうなるんでしょう?
なので洗脳されるかどうかは大学のカリキュラム(と自己学習)しだい。むしろ、開発/実行環境が特殊になってしまう言語よりかはいいかなと思うんだけどなぁ~。
#個人的にはSunも好きくないので、*BSDなCLIでプリミティブに開発を勉強しなおしたいな(笑)
.NETの世界オンリーで脳が漬物になった学生さんって、その後どうなるんでしょう?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
結局は、「よりよい教育」か否かが問題 (スコア:1)
そこまで言わないにしても、教育的「効果」の良し悪しってのものは、無視するわけにはいかないかも。
どれだけ「良い」言語で勉強させるか?によって、出来上がる(^^;学生の質は
結構変わってしまったりしないだろうか?ということです。
心配するのはやっぱり、「言語は思考を規定する」という意味での、言語の影響力ですね。
変な面のある言語で刷り込まれてしまうと、痛いわけで。
たとえば往年の行番号BASICに刷り込まれた人々ってのも、それだったかなと。#そういやあれもMS由来だったなあ。
そういう意味では、引き合いに出されてるSUNのサーバーのほうがまだしも罪(^^;は軽いかと。
思考を規定する度合いは、鯖よりも言語のほうが「深刻」だと思いますので。
#ということは、むしろ心配なのは、今実際に巷の多くで学ばせさらてるらしきJava言語かな。
#この場合、もともとのライセンスが無料であるかどうかは別問題です。
使いでが無いかどうかは、むしろ学生さん段階ならば、あまり拘り過ぎないほうが良いと思います。
仕事で仕方なく使わされる糞言語の類(どれとは言いませんが)に、学生のころから耽溺しちゃったら、
そりゃもう痛々しいっす。使いでの無さだけで「よい教育」かどうかを決めるのは、たぶん的外れっす。
で、C#ですが…どうなんでしょうね?(^^;
まあ仕様から察するに言語の潜在能力自体はJavaより上かも知れないけど、
その潜在能力をMSの実装がきちんと過不足なく出しているかどうかは別だし。
あと、開発統合環境の問題もあるかな。
環境も結構、思考を規定しちゃうので、あんまり変なもので刷り込まれてほしくない。
C#のMS実装は指一本触れたことがないんで判らないんですが、その↑へんがどうなのかは、識者のコメントを期待します。
ん?そういやC#の非MSな実装は、どんなのが有るんでしたっけ?
あ。あと重要なものがひとつ。開発したソフトを動かすターゲット環境に対する刷り込みも、問題ですね。
APIとかさぁ。
てゆーか、そのまんま.NET必須っすか?
.NETの世界オンリーで脳が漬物になった学生さんって、その後どうなるんでしょう?
目に触れたものをそのままじゃなく、いったん抽象化して理解することが出来るくらいにまで成長した後ならば、
なにをどう触れようが良いんですが、それ以前だとどうなんだろうな?
#文中でしばしば仕事という言葉を使っていますが、趣味だって同じことだと思います。
#糞言語に耽溺するのは、趣味だとしても、ハタから見てて痛々しい。
##フリーソフト作者で時折、自分がなじんだ(糞)言語の選択の自由(「この言語を使うのは俺の自由だ、
##なぜならこれは趣味だからだ」)を叫ぶ人が居ますが、自由かどうかと貴賎が無いかどうかは別問題です。
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なんかのクロージャのひとつの基礎になっているのは 「全ての変数は無限エクステントを持つ」というモデルなので、 変数がローカルフレームと命運を共にする モデルとはやっぱり相容れないように思えます。
Re:結局は、「よりよい教育」か否かが問題 (スコア:2, 興味深い)
>まあ仕様から察するに言語の潜在能力自体はJavaより上かも知れないけど、
>その潜在能力をMSの実装がきちんと過不足なく出しているかどうかは別だし。
いまだに普通の環境でまともに動く統合開発環境すら出してくれない sun に
比べたらMSの方がよほどマシです。
forte と VisialStdioの差を見れば明白です。
フリーとか有償とかはこの際問題ではありません。
まともに動くということが大切です。
>ん?そういやC#の非MSな実装は、どんなのが有るんでしたっけ?
BSD(これはMSらしいが)
Linux(mono project)
などがあります。
by rti.
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
VSを使いやすいと思ったことは無いなあ…
あ。そういや俺が使ったのは2つくらい前の版だったか。
VSもここ数年で劇的に改善されたのかな?
Re:結局は、「よりよい教育」か否かが問題(オフトピ) (スコア:0)
rotorについては、8月号のMSDN Magazineで特集組まれてたみたいですね。
Microsoftもソープとかローターとか、何かやらしーよね。
Re:結局は、「よりよい教育」か否かが問題(オフトピ) (スコア:0)
PinkOS を作ってた会社のことも忘れないでください。
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
まあ、よく言われてはいるが、
C# != CLI != .NET Frameworkではあるはず。なので洗脳されるかどうかは大学のカリキュラム(と自己学習)しだい。むしろ、開発/実行環境が特殊になってしまう言語よりかはいいかなと思うんだけどなぁ~。
#個人的にはSunも好きくないので、*BSDなCLIでプリミティブに開発を勉強しなおしたいな(笑)
M-FalconSky (暑いか寒い)
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
>環境も結構、思考を規定しちゃうので、あんまり変なもので刷り>込まれてほしくない。
(統合環境の是非はともかく)
C#はコマンドラインでも使えますよ。
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
調子に乗るんだと思う。
Re:結局は、「よりよい教育」か否かが問題 (スコア:0, フレームのもと)
初耳。
そこまで「馬鹿」な奴が居るの?だったらなおさらモデレシステムは終わってるなあ。
和訳:逆に君が言ってることのほうが嘘(や誤解)である可能性は、どれくらい有るの?>「君」以外
和訳2:もしかして君がその実例なの?
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
#控えおろう。この「フレームのもと」紋所が、目に入らぬか?
Re:結局は、「よりよい教育」か否かが問題 (スコア:0, 余計なもの)
こういう妄想文自体がフレームなんだよな。
妄想文がついちゃうことまでもが俺の責任だといわれたら、ちょっと首をかしげるね。つまり、
フレームのもとが悪いのか、それともフレーム「自体」が悪いのか、とね。
フレームのもとを心配してるの?それと
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)
>もし(良識に基づいて)後者だというならば、そもそもフレームを起こさなきゃいいのです。
と、思うなら、「フレームのもと」だと自分でわかっている記事を投稿なさるべきではないでしょう。
Re:結局は、「よりよい教育」か否かが問題 (スコア:1)
>と、思うなら、「フレームのもと」だと自分でわかっている記事を投稿なさるべきではないでしょう。
いや、そうじゃなく。
それが自分にとっての良識だと思う人「ならば」、その自らの良識に従わないと
行動に整合性が取れないよ、と言ったのです。
#自己矛盾したまま突っ走りたいというならば、それはそれで大した度胸ですが。
で、俺が良識だと認めるものの中には、あいにく(?)ソレは入っていませんので、NotSupportedです。
てゆーか、あの記事を「フレームのもと」と評したのは俺ではないのですから;-P、俺の良識から外れるのは当然ですね。
Re:結局は、「よりよい教育」か否かが問題 (スコア:0)