アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
わかりやすいけどめんどくさい (スコア:0)
# データプロセッシング的な用途には結構向いてるんじゃないかなー
Re:わかりやすいけどめんどくさい (スコア:0)
Re:わかりやすいけどめんどくさい (スコア:0)
Re:わかりやすいけどめんどくさい (スコア:2, 興味深い)
私は脳内にあるアルゴリズムのイメージをそのまま書けると思います。頭の中の「絵のようなもの」をそのままプログラムにする、と言えば良いのかなぁ?
他の言語だと一端「言語」に変換している感じます。何かC++で書くときと使っている脳が違うような気がするんですよね。
恐らく#1226985の方は「脳内イメージ」→「得意な言語(またはそれに近い脳内言語)」→「Lisp(Scheme)」と頭の中でやっているので構文解析だと言うのでしょうが、「脳内イメージ」→「Lisp(Scheme)」と頭の中で出来るようになると世界が広がると思います。それを楽しめなければ出来るようになるためのトレーニングは「めんどくさい」ですが。
Best regards, でぃーすけ
Re:わかりやすいけどめんどくさい (スコア:0)
Re:わかりやすいけどめんどくさい (スコア:0)
手続きを考えなければならない仕事の方が多い。
だから、Lispは傍流なのだと思う。
たぶん。
Re:わかりやすいけどめんどくさい (スコア:1, おもしろおかしい)
ただ、
実際にプログラムを一杯書いて(書かされて)いて感じたことなんですが、
仕事内容を「手続き」で表現することは、
実は手抜きなんじゃないか?と
感じることが多いです。
ご存知の通り、むき出し(CPUに近い)の「手続き」というものは、
色々と取り扱いが難しい。
一度書いたら後で厳密に検証するのが難しいとか、
「抜け」に対して根本的に無防備だとか。
でも人は、面白い(?)ことに、
ほっとくと(きちんと教育しないと)
実装のみならず設計や分析まで
「手続き」的に書いてしまいがちです。
たぶん手続きで考えるほうが、
楽というか直感的なんだろうと思います。
「やらせたいこと」を順に書くだけですから簡単簡単。
ただ、それだと、
その裏の「やらないとならないこと」の網羅性は
何も保証されない。
要するに、責任を後回しにするために格好のフォーマットなんです。手続き型は。
コーダーのみなさん、
「やりたいこと」ばっかり書いてあって、
「やれるかどうか」
特に「自己矛盾がないかどうか」を
なーんにも考証してなさそうなドキュメントを
寄越されて呆然としたこと、ないですか?
私はずーっとそんなのばかりですよorz
そういう「手続き脳」な人らがドキュメントを書く(のに任せてる)限り、
たぶん状況はよくならないでしょうね。
そして逆にいえば、手続き脳な人らが職を失わないために
明示的にも無意識にも活動し続けてる結果として、
非手続き型が傍流だ、という現状が有るのではないかと愚考します。
#よーするに陰謀論かぃ
Re:わかりやすいけどめんどくさい (スコア:0)
それはその通りだと思いますが、
>私は脳内にあるアルゴリズムのイメージをそのまま書けると思います。頭の中の「絵のようなもの」をそのままプログラムにする、と言えば良いのかなぁ?
何が「イメージそのまま」なのかすら、人によって違いますから。
イメージが高級(高級言語という意味で)な人も居れば低級な人も居る。
手続き型な人も居れば関数型な人も居る。(そういえばSQLな人も居る。)
無意識のうちに落とすイメージのかたちが、
その人の得意とする言語だ、という感じかと思います。
自分のことを省みても、好きで得意なメイン言語が変遷するにつれて、
頭のなかのイメージ(モデル)自体がバサっと切り替わると
Re:わかりやすいけどめんどくさい (スコア:1)
これは承知した上で申し上げております。私も最初の言語はポケコンのBASICだし、以降、アセンブラ→C→....という順序で言語を修得しております。
以下が重要な点で、私も共感する部分が多いです。
>無意識のうちに落とすイメージのかたちが、
>その人の得意とする言語だ、という感じかと思います。
> 自分のことを省みても、好きで得意なメイン言語が変遷するにつれて、
> 頭のなかのイメージ(モデル)自体がバサっと切り替わるという経験をしてきました。
はい。このイメージのかたちを「手続き型」と「関数型」の二種類としましょう(細かい分類、他の分類は議論の都合上捨象します)。これらのイメージはトレーニング(慣れ)によってどちらも出来るようになる、というのが私の主張です。喩えて言うなら、英語で考えられるくらいに英語が上達しても日本語は忘れない、ということです。ただし、私自身関数型イメージがまがりなりにも出来るようになるまでには大分苦労しました。
また、「手続き型イメージ」→「C/C++の構文」より、「関数型イメージ」→「schemeの構文」の方がより直接的に感じます。(私の場合、Cで書くときのイメージは、Cよりも幾分かアセンブラに近いイメージですし、C++のとき(とくにtemplateを使うとき)は幾分か関数的なイメージも加わります)。私自身経験上「関数型イメージ」力はそんなに強いと言えないですが、それでもそう感じました。
その経験上、Lispで書くときに「C++だとこうだからLispだとこうなる」ではなくて、Lispが自分の最初の言語であるつもりで考えると、「関数型イメージ」力が付くと思うし、世界が広がっていくのではないでしょうか?ということを提案しています。
# もどかしいし、そのことを楽しめない限りそれこそ「めんどう」なんですけど。他にはschemeを実装してみるとか(私は今マクロで詰まってます)、schemeを組み込んだアプリを作ってみたりするとかも良い経験かと。
#それにしてもlink先の記事は楽しいですね。SQLは数独を解くのに不向きであると言うのにも同意です。私自身は、数独のヒューリスティックをC++のtemplateを使いまくりで書いたことがありますが(template<template<typename T>class MT, typename Pos>みたいなのが出てくるくらい)そのときはあまり手続的に考えてないように感じました。
Best regards, でぃーすけ
Re:わかりやすいけどめんどくさい (スコア:0)