アカウント名:
パスワード:
> ぜひとも > 「ソフトウエア技術者の怠惰と短気と傲慢とででできております」 > と言いたい所なのですが…
心情的にも、そして、現実的にも、そのような時代は来ないでしょう。漠然とした要求があった時、それを現実的に動作する形で記述するためには、機械が逆立ちしても真似できない知的労働は不可避です。というのも、動作のセットもその組み合わせも無限にあるからです（オペコードまで話を落とすとセットは可加算ですが、それでも組み合わせがね）。すごーく分野を限って半自動化することは可能でしょうけれど。
文章にしても音楽にし
> だってコレ、Perl作者のあの名台詞(?)なので。
彼は、lazy, impatient and hubris が大好きのようですね。 優秀なプログラマがそうだと言っている表現は何箇所かありましたが、プログラマが３大美徳によって作られると言っている箇所は、少しググってみたのですが、見つけられませんでした。本か何かで言ってるんですかね。
まぁ perl 作者が言おうが、emacs の作者が言おうが、G7 さんオリジナルだろうが関係ないですけどね。プログラマの３大美徳というのは納得ですが、プログラムが３大美徳によって作られるという表現には違和感を覚えます。
> しかし、それこそ技術の発達のお陰で、少しづつ減っては居るわけです。 > 例えばいわゆる言語の高級化って奴ね。
本当にそう思います？ 減ってはいるものの、ごく微々たる部分だったりしませんか？ 何かシステムを実現する必要がある時、それをコーディングするよりも、要求分析とか仕様決めのほうが大変だったりしませんか？ 僕が以前作ったプログラムは、コーディングにとりかかるのに4年以上かかって、コーディングはたったの３週間で済みました。 まあ、これは極端な例（というか僕がアホだという例）だとしても、何かシステムを作る時、プログラミングやデバッグよりも、もっと重要な作業として、要求分析や仕様決めやシステム設計という作業があり、それらは、人間様が考えて、何かの形で記述しデータベース化（ライブラリ化？）しない限り、機械から自動的にgenerate されるなんて事にはならないでしょう。 プログラミング言語がいくら高級になってもきっと駄目なんじゃないでしょうか。 まず人間が頭を捻れということですよ。 やはり、血と汗と涙なくして、語れないと。
そして、その人間が優秀なら（怠惰で短気で傲慢なんだけど、ソレが故に得られた卓越した能力により）、それらをさっくりやっちゃって、実装できちゃうということですよね。でもそれは、使っているシステムが高級だからとかではなく、ノウハウとか経験とか…やっぱり人間側の精進ありきの話だと僕は思います。
すみません。ミスを発見しました。
> 彼は、lazy, impatient and hubris が大好きのようですね。 > 優秀なプログラマがそうだと言っている表現は何箇所かありま > したが、プログラマが３大美徳によって作られると言っている > 箇所は、少しググってみたのですが、見つけられませんでした。 > 本か何かで言ってるんですかね。
のくだりで、 「プログラマが３大美徳によって作られると言っている箇所は」ではなく「プログラムが３大美徳によって作られると言っている箇所は」のつもりでした。
> その優秀なプログラマによってプログラムが作られるのですから、OKじゃないですか。
「風が吹けば桶屋が儲かる」ですか。僕にはそのようなギャグを笑うことができるセンスはないようです。
たとえ優秀であっても、プログラマが全然苦労せずに作ったプログラムが、人の役に立ったという例は聞かないのですが、何かありますか？
それに、それを理想にするのはいいのですが、それが（現実には（まだ？）ないのに）当たり前で、将来必ずそうなるものだという論調は控えていただきたい、というのが僕の主張です。もちろん、業界に携わる人々がそれに向かって進んでいるというのはわかります。でも、現状は（例え世界一優秀なソフトウェア技術者のチームを組んだとしても）ほど遠いものであることはクライアントを含め皆さんにわかっていただきたいのです。例えば、商売ソフトウェア業界は今とてもバブリーで、色々新しそうに見えるシステムと用語を作っては、世の中の人々に、ソフトウェアでは何でもできる時代になってきている、という誤解を与えています。しかし、現実には、ソフトメーカーの商売戦略にまんまと乗せられているだけで、中身がそんなに変わっているわけではありません。学術的ソフトウェア業界で進歩があるのでしょうが、正しい評価を受けることが出来ずに、予算も与えられず、危機に瀕している所もあると聞いています。ワードエクセルが少し使えるレベルで、もう技術がわかったような気になって、あれこれ物事を判断される風潮が蔓延っている現状を憂います。いや G7 さんがこれだとは決して思っていませんよ。でも、例えば今回 G7 さんが言うことを鵜呑みにして（さらに誤解もして？）、さもそれが真実であるかのごとく、得意げに話し、決定を下すおやじ達が蔓延ると、日本のソフトウェア業界にとって、非常に困った事態になりそうだということです。（この論法こそ「風が吹けば―」の域を出ませんが ;_;）
実は、学術業界ですら、ソフトウェアの作り難さについて、目をそらしているのではないかと個人的には疑っています。外注すればいいじゃんという声が複数の方面から聞こえてきていました。僕の感覚からすると、嘆かわしいことだと思いました。業界の首を絞める行為のような気もしています。
> それは所謂「血と汗と」とは程遠いものだと感じています。
ここなんでしょうね、争点は。
> 技術者らしい頭の使い方というか、技術の「勘所」を如何に押さえるか？
もちろん、それは理想です。でも、現実には、どんな問題にでも、その勘所が存在するわけではなく、むしろ、力技のみでしか解決できない問題が多いと僕は思っています。また、エレガントな解答を求め過ぎるが故に、締め切りに間に合わなかったり、力技実装者に出し抜かれるのも面白くないですよね。 「銀の弾」は、ある問題にはあるかもしれないし、でも一般には無いと言われています。だからこそ、ソフトウェア技術の探求は面白い。
また、ある問題にたまたま「勘所」が存在したとしても、それに気付くことができるかどうかは、天才でもない限り（いや、確かに天才は居ますが）、努力によって培われた勘と経験でしかないでしょう。やはり、それまでに流した血と汗と涙が物を言うと。それに、数個の勘所を押さえれば、たちまち解けてしまう問題なんて、現実に作らねばならないシステムではなかなか無いのではないでしょうか。
> たとえば業務アプリを作るとして、業務について頭を絞る過程はなくならないでしょうけど
そこが大変だし、それはそのシステムを作る上で必要な作業でしょう？その労力をどうしてシステム作りの労力にカウントしたがらないのか、不思議でなりません。
それに「こんなの一瞬で出来たけど、これって僕ちんが優秀だからなんだよ」なんて物言いも、（本当にそれが出来たとしても）冗談で言う台詞ですよね。僕なんかは肝っ玉が小さいので、冗談で言うのも恥ずかしいです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
電池もそうかも知れないが (スコア:2, すばらしい洞察)
# 最近のシロートさんは「プログラムってなに？」みたいな方も多い。
# 「見て作っていくだけの仕事です」とか言う大学教授までいるわけで。
Re:電池もそうかも知れないが (スコア:1)
「ソフトウエア技術者の怠惰と短気と傲慢とででできております」
と言いたい所なのですが…
＃夢はなかなか実現しないのでG7
＃実際には、無体言う上司や客の怠惰と短気と傲慢とででできております(T_T)
>#
Re:電池もそうかも知れないが (スコア:1)
> ぜひとも
> 「ソフトウエア技術者の怠惰と短気と傲慢とででできております」
> と言いたい所なのですが…
心情的にも、そして、現実的にも、そのような時代は来ないでしょう。漠然とした要求があった時、それを現実的に動作する形で記述するためには、機械が逆立ちしても真似できない知的労働は不可避です。というのも、動作のセットもその組み合わせも無限にあるからです（オペコードまで話を落とすとセットは可加算ですが、それでも組み合わせがね）。すごーく分野を限って半自動化することは可能でしょうけれど。
文章にしても音楽にし
Re:電池もそうかも知れないが (スコア:1)
>> 「ソフトウエア技術者の怠惰と短気と傲慢とででできております」
>> と言いたい所なのですが…
>
>心情的にも、そして、現実的にも、そのような時代は来ないでしょう。
後半じゃなく前半のコレにこう返答されてしまうと、困っちゃうんですが…。
だってコレ、Perl作者のあの名台詞(?)なので。
つまり、「優秀なソフトウェア技術者の優秀さの粋によってできております」ってこと。
＃前半と後半は違う話題です。はい。
この三大美徳って、ソフトの勘所が判ってる奴がやるんなら良いんだけど、
判ってない奴がやると、たちどころに誤用に陥る諸刃の剣です。
Re:電池もそうかも知れないが (スコア:1)
> だってコレ、Perl作者のあの名台詞(?)なので。
彼は、lazy, impatient and hubris が大好きのようですね。 優秀なプログラマがそうだと言っている表現は何箇所かありましたが、プログラマが３大美徳によって作られると言っている箇所は、少しググってみたのですが、見つけられませんでした。本か何かで言ってるんですかね。
まぁ perl 作者が言おうが、emacs の作者が言おうが、G7 さんオリジナルだろうが関係ないですけどね。プログラマの３大美徳というのは納得ですが、プログラムが３大美徳によって作られるという表現には違和感を覚えます。
> しかし、それこそ技術の発達のお陰で、少しづつ減っては居るわけです。
> 例えばいわゆる言語の高級化って奴ね。
本当にそう思います？ 減ってはいるものの、ごく微々たる部分だったりしませんか？ 何かシステムを実現する必要がある時、それをコーディングするよりも、要求分析とか仕様決めのほうが大変だったりしませんか？ 僕が以前作ったプログラムは、コーディングにとりかかるのに4年以上かかって、コーディングはたったの３週間で済みました。 まあ、これは極端な例（というか僕がアホだという例）だとしても、何かシステムを作る時、プログラミングやデバッグよりも、もっと重要な作業として、要求分析や仕様決めやシステム設計という作業があり、それらは、人間様が考えて、何かの形で記述しデータベース化（ライブラリ化？）しない限り、機械から自動的にgenerate されるなんて事にはならないでしょう。 プログラミング言語がいくら高級になってもきっと駄目なんじゃないでしょうか。 まず人間が頭を捻れということですよ。 やはり、血と汗と涙なくして、語れないと。
そして、その人間が優秀なら（怠惰で短気で傲慢なんだけど、ソレが故に得られた卓越した能力により）、それらをさっくりやっちゃって、実装できちゃうということですよね。でもそれは、使っているシステムが高級だからとかではなく、ノウハウとか経験とか…やっぱり人間側の精進ありきの話だと僕は思います。
Re:電池もそうかも知れないが (スコア:1)
すみません。ミスを発見しました。
> 彼は、lazy, impatient and hubris が大好きのようですね。
> 優秀なプログラマがそうだと言っている表現は何箇所かありま
> したが、プログラマが３大美徳によって作られると言っている
> 箇所は、少しググってみたのですが、見つけられませんでした。
> 本か何かで言ってるんですかね。
のくだりで、 「プログラマが３大美徳によって作られると言っている箇所は」ではなく「プログラムが３大美徳によって作られると言っている箇所は」のつもりでした。
Re:電池もそうかも知れないが (スコア:1)
その優秀なプログラマによってプログラムが作られるのですから、OKじゃないですか。
なお優秀でないプログラマはプログラマじゃないので(藁
＃つまり、地球上にはご存知の通りの現状程度の技術しかないにも関わらず、
＃「優秀でないプログラマ」を雇用するのは、既に間違っているぞと(^^;
>本当にそう思います？ 減ってはいるものの、ごく微々たる部分だったりしませんか？ 何かシステムを実現する必要がある時、それをコーディン
>グするよりも、要求分析とか仕様決めのほうが大変だったりしませんか？
まあそれはそうです。贅肉は徐々に落ちてるが(小さくはないとは思いますがね)、骨子はそう変わるものではない。
そしてアホはどうせその骨子を記述できなくて、これはもうどうしようもないので。
ただ、「アホ」と「プログラム無知」とはイコールじゃないだろうし。
単に知る機会が無かったとかさ。
逆にいえば、知る機会が有ったのに尚DQNなこと言うような奴は、30世紀になっても救済できないでしょうね。
>まず人間が頭を捻れということですよ。 やはり、血と汗と涙なくして、語れないと。
あとですね、頭を絞る必要は有るとは俺も思いますが、それは所謂「血と汗と」とは程遠いものだと感じています。
技術者らしい頭の使い方というか、技術の「勘所」を如何に押さえるか？に懸かっていて、
血や汗(いわゆる「苦労」の象徴かと思いますが)というより、
むしろ機転とかそっちのほう、鉈じゃなく剃刀、みたいな感覚を受けています。
＃で、馬鹿上司は、血と汗と人月を要求するのね。困ったもんだ…
>でもそれは、使っているシステムが高級だからとかではなく、ノウハウとか経験とか…やっぱり人間側の精進ありき
>の話だと僕は思います。
「ソフトウェアの作り方」は、出来れば無くなったほうがいいんです。
たとえば業務アプリを作るとして、業務について頭を絞る過程はなくならないでしょうけど、
その絞った結果をプログラムに「落とし込む」手順とか手間とかは、
理想を言えばゼロであるべきだし、
まあ少しづつですが近づいてるんじゃないでしょうか？
＃もとよりその比率が「微々たる」ものならば、尚更それはゼロに近いのではなかろうか？
抽象化、という思考は必要でしょうね。
ただ、これは、計算機を使う(あるいはソフトを作る)かどうかとは無関係に
必要な技術だと思います。
どんなシゴトでも、抽象化という思考をせずにマトモにやれる仕事なんて
ないんじゃなかろうか？
そしてそれは、どんなシゴトでも共通の技術なんじゃないだろうか？(もちろん充分条件ではないですが)
Re:電池もそうかも知れないが (スコア:1)
> その優秀なプログラマによってプログラムが作られるのですから、OKじゃないですか。
「風が吹けば桶屋が儲かる」ですか。僕にはそのようなギャグを笑うことができるセンスはないようです。
たとえ優秀であっても、プログラマが全然苦労せずに作ったプログラムが、人の役に立ったという例は聞かないのですが、何かありますか？
それに、それを理想にするのはいいのですが、それが（現実には（まだ？）ないのに）当たり前で、将来必ずそうなるものだという論調は控えていただきたい、というのが僕の主張です。もちろん、業界に携わる人々がそれに向かって進んでいるというのはわかります。でも、現状は（例え世界一優秀なソフトウェア技術者のチームを組んだとしても）ほど遠いものであることはクライアントを含め皆さんにわかっていただきたいのです。例えば、商売ソフトウェア業界は今とてもバブリーで、色々新しそうに見えるシステムと用語を作っては、世の中の人々に、ソフトウェアでは何でもできる時代になってきている、という誤解を与えています。しかし、現実には、ソフトメーカーの商売戦略にまんまと乗せられているだけで、中身がそんなに変わっているわけではありません。学術的ソフトウェア業界で進歩があるのでしょうが、正しい評価を受けることが出来ずに、予算も与えられず、危機に瀕している所もあると聞いています。ワードエクセルが少し使えるレベルで、もう技術がわかったような気になって、あれこれ物事を判断される風潮が蔓延っている現状を憂います。いや G7 さんがこれだとは決して思っていませんよ。でも、例えば今回 G7 さんが言うことを鵜呑みにして（さらに誤解もして？）、さもそれが真実であるかのごとく、得意げに話し、決定を下すおやじ達が蔓延ると、日本のソフトウェア業界にとって、非常に困った事態になりそうだということです。（この論法こそ「風が吹けば―」の域を出ませんが ;_;）
実は、学術業界ですら、ソフトウェアの作り難さについて、目をそらしているのではないかと個人的には疑っています。外注すればいいじゃんという声が複数の方面から聞こえてきていました。僕の感覚からすると、嘆かわしいことだと思いました。業界の首を絞める行為のような気もしています。
> それは所謂「血と汗と」とは程遠いものだと感じています。
ここなんでしょうね、争点は。
> 技術者らしい頭の使い方というか、技術の「勘所」を如何に押さえるか？
もちろん、それは理想です。でも、現実には、どんな問題にでも、その勘所が存在するわけではなく、むしろ、力技のみでしか解決できない問題が多いと僕は思っています。また、エレガントな解答を求め過ぎるが故に、締め切りに間に合わなかったり、力技実装者に出し抜かれるのも面白くないですよね。 「銀の弾」は、ある問題にはあるかもしれないし、でも一般には無いと言われています。だからこそ、ソフトウェア技術の探求は面白い。
また、ある問題にたまたま「勘所」が存在したとしても、それに気付くことができるかどうかは、天才でもない限り（いや、確かに天才は居ますが）、努力によって培われた勘と経験でしかないでしょう。やはり、それまでに流した血と汗と涙が物を言うと。それに、数個の勘所を押さえれば、たちまち解けてしまう問題なんて、現実に作らねばならないシステムではなかなか無いのではないでしょうか。
> たとえば業務アプリを作るとして、業務について頭を絞る過程はなくならないでしょうけど
そこが大変だし、それはそのシステムを作る上で必要な作業でしょう？その労力をどうしてシステム作りの労力にカウントしたがらないのか、不思議でなりません。
それに「こんなの一瞬で出来たけど、これって僕ちんが優秀だからなんだよ」なんて物言いも、（本当にそれが出来たとしても）冗談で言う台詞ですよね。僕なんかは肝っ玉が小さいので、冗談で言うのも恥ずかしいです。