アカウント名:
パスワード:
プログラミングってのは創作活動の一種なんですかね？（自分はプログラマーではないのでわからないのですが）だとしたら、適性がある、誰もができるものではない、というのはわかるような気がします。
私もプログラマではないですが、プログラミング自体は創作活動とは別物であると思います。プログラミングは、コーディングともいいますがこの意味では翻訳です。創作活動は面白く意欲が湧くけれど、翻訳は面白くないです。つまり適正ではなく意欲の問題があると思います。
プログラミングってコーディングより広い範囲を指してる気がする。コーディングは確かに翻訳みたいなもんだけど、プログラミングはもうちょっと広い設計とかも入ってね？
プログラミングの範囲についてはよくもめるね。大きく分けても「設計」、「コーディング」、「テスト、デバッグ」といった工程に分かれるし、コーディング以降しかやらなくてもプログラマって呼ばれてたりするし。
個人的には「設計」やるのがプログラマで、それ以外はIT土方って認識なんだけど。
# 私自身はプログラムは書きますがIT系の職業ではありません。
「設計」というのは、与えられた「仕様」に対してアルゴリズムにまでブレークダウンするようなものでしょうか。アルゴリズムにまでブレークダウンする過程で初めて気付く「仕様」のバグというのもあるように思うのですが、そういう場合は、どうするのでしょうか？それとも、そういうのは仕様策定の段階ですでにやってる（ことになっている）のでしょうか？
仕様策定の段階でわかる奴がいるなら、3/32は世の中にない。仕様策定だけして逃げる奴が多いから困ってんだよ。自分でケツ拭かせろ。そして拭けないくらい糞が噴き出してたら、もう手を出すな。そして金返せ。
# コンサルとかそういう人種だよ！！
仕様のバグという言葉自体が誤りでないですか？バグのいうのはプログラミングの誤りの結果、仕様どおりに動かなかったということですね。
仕様の誤りの結果どうやっても実現できないものや、要件を満たせないもの何ていうのでしょうか。これが仕様バグってやつじゃないかな。「プログラミングの誤りの結果、仕様どおりに動かなかった」ってのは実装バグ？
誤りだけどわかりやすいよ。仕様そのものに矛盾があったり、想定漏れがあったり。仕様どおり実装すると使い物にならなかったり。
いいえ、より上位の欲求を満足させるに失敗した成果物を、「バグがある」といいます。従って、運用のバグ、実装のバグ、仕様のバグ、設計のバグ、要求のバグ… があり得るのです。
# と考えるようにしている。
東電、オリンパスという実例があっても仕様、システムのバグですますとか
社畜乙って感じですね
？ バグがあったら済まさないのでは？「これはバグではない」なら、済ませてしまったことになると思うが。
解無しで、いくらがんばっても結果が出ない状態だと思います。これは（やってみて結果的にですが）客観的に判定できますし、しばしば起こる事です。（仕様の書きすぎが原因の場合が多いです。）
しかし、むしろ、「仕様のバグ」と言える／言ってもらえる所は風通しが良い所だと思います。通常なら、仕様は至上の存在であり、盾突けないものなので、そのまま時間切れまでいってしまうはずです。「仕様のバグ」だと言ってもらえるのは幸いだと思います。
「仕様のバグ」の嫌な点は、前提となる解の存在がそもそも成り立っていないせいで、もしなった場合、バラ色になる（様に見える）点です。今回の仕様の肝である場合が多くあると思います。それを止められたら企画自体が成立しなくなるかも知れず、えらくこじれます。
仕様を書く人には、とにかくがんばってもらいたいものです。
自然言語処理もだいぶ進歩してきたのだから、もうそろそろ、（自然言語で書かれた）仕様書を食わせると自動的にプログラムができるシステムとか、できそうな気がする。
そうすれば、仕様策定の段階で、仕様にバグがあればたちどころに分かるし、非常にいいんじゃない？
仕様書をプログラムに翻訳するだけの能しかないプログラマは職を失うけど。
自然言語で「複数の物体は同時に同じ座標に存在できない」と書くのはあまり自然なことではない。常識を前提とした自然言語で、常識を持たない計算機が常識から外れないよう、どの常識を教えなければならないかを想起できるヒトがプログラマになるわけだ。今とそんなに変わらん。
自然言語処理ができるというのはつまり、そういう「常識データベース」もできつつある、ということでは？
言語そのものの情報(文法)には、言語で表現される情報は入ってませんよ。
フレーム問題と同じく「常識データベースを充実させればコンピュータでも常識的な判断が可能」っていうのは楽観的すぎでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
あなたもプログラマーになれる（わけではない） (スコア:0)
プログラミングってのは創作活動の一種なんですかね？（自分はプログラマーではないのでわからないのですが）
だとしたら、適性がある、誰もができるものではない、というのはわかるような気がします。
Re: (スコア:0)
プログラミングってのは創作活動の一種なんですかね？（自分はプログラマーではないのでわからないのですが）
だとしたら、適性がある、誰もができるものではない、というのはわかるような気がします。
私もプログラマではないですが、プログラミング自体は創作活動とは別物であると思います。
プログラミングは、コーディングともいいますがこの意味では翻訳です。
創作活動は面白く意欲が湧くけれど、翻訳は面白くないです。
つまり適正ではなく意欲の問題があると思います。
Re: (スコア:0)
プログラミングってコーディングより広い範囲を指してる気がする。
コーディングは確かに翻訳みたいなもんだけど、プログラミングはもうちょっと広い設計とかも入ってね？
Re:あなたもプログラマーになれる（わけではない） (スコア:0)
プログラミングの範囲についてはよくもめるね。
大きく分けても「設計」、「コーディング」、「テスト、デバッグ」といった
工程に分かれるし、コーディング以降しかやらなくてもプログラマって
呼ばれてたりするし。
個人的には「設計」やるのがプログラマで、それ以外はIT土方って認識なんだけど。
Re: (スコア:0)
# 私自身はプログラムは書きますがIT系の職業ではありません。
「設計」というのは、与えられた「仕様」に対してアルゴリズムにまでブレークダウンするようなものでしょうか。
アルゴリズムにまでブレークダウンする過程で初めて気付く「仕様」のバグというのもあるように思うのですが、
そういう場合は、どうするのでしょうか？それとも、そういうのは仕様策定の段階ですでにやってる（ことに
なっている）のでしょうか？
Re: (スコア:0)
仕様策定の段階でわかる奴がいるなら、3/32は世の中にない。
仕様策定だけして逃げる奴が多いから困ってんだよ。
自分でケツ拭かせろ。
そして拭けないくらい糞が噴き出してたら、もう手を出すな。そして金返せ。
# コンサルとかそういう人種だよ！！
仕様のバグ (スコア:0)
そうすると、その仕様に関係する他の部分にも影響するので、相当な手戻りをきたしかねません。
ですので、仕様策定の段階でしつこい位確認するのですが、その際に、プログラムにまで持っていけるかいけないか、つまり、適用可能なアルゴリズムが存在するか否かを判断できる人間が確認しないと意味をなさないことになります。
すでにやっていることになっていますが、稀には意味のない作業であったことが判明することがあり、良い火消し役がいないと、プロジェクトが炎上し、裁判沙汰にまでなることさえあります。
Re: (スコア:0)
仕様のバグという言葉自体が誤りでないですか？
バグのいうのはプログラミングの誤りの結果、仕様どおりに動かなかったということですね。
Re: (スコア:0)
仕様の誤りの結果どうやっても実現できないものや、要件を満たせないもの何ていうのでしょうか。
これが仕様バグってやつじゃないかな。
「プログラミングの誤りの結果、仕様どおりに動かなかった」ってのは実装バグ？
Re:仕様のバグ (スコア:1)
誤りだけどわかりやすいよ。
仕様そのものに矛盾があったり、想定漏れがあったり。
仕様どおり実装すると使い物にならなかったり。
Re:仕様のバグ (スコア:1)
いいえ、より上位の欲求を満足させるに失敗した成果物を、「バグがある」といいます。
従って、
運用のバグ、実装のバグ、仕様のバグ、設計のバグ、要求のバグ… があり得るのです。
# と考えるようにしている。
Re:仕様のバグ むしろ人間や組織のバグの方が。。。。 (スコア:0)
東電、オリンパスという実例があっても
仕様、システムのバグですますとか
社畜乙って感じですね
Re:仕様のバグ むしろ人間や組織のバグの方が。。。。 (スコア:1)
？ バグがあったら済まさないのでは？
「これはバグではない」なら、済ませてしまったことになると思うが。
Re: (スコア:0)
解無しで、いくらがんばっても結果が出ない状態だと思います。
これは（やってみて結果的にですが）客観的に判定できますし、しばしば起こる事です。
（仕様の書きすぎが原因の場合が多いです。）
しかし、
むしろ、「仕様のバグ」と言える／言ってもらえる所は風通しが良い所だと思います。
通常なら、仕様は至上の存在であり、盾突けないものなので、そのまま時間切れまで
いってしまうはずです。「仕様のバグ」だと言ってもらえるのは幸いだと思います。
「仕様のバグ」の嫌な点は、前提となる解の存在がそもそも成り立っていないせいで、
もしなった場合、バラ色になる（様に見える）点です。
今回の仕様の肝である場合が多くあると思います。それを止められたら企画自体が成立
しなくなるかも知れず、えらくこじれます。
仕様を書く人には、とにかくがんばってもらいたいものです。
Re: (スコア:0)
自然言語処理もだいぶ進歩してきたのだから、もうそろそろ、
（自然言語で書かれた）仕様書を食わせると自動的にプログラムができるシステムとか、
できそうな気がする。
そうすれば、仕様策定の段階で、仕様にバグがあればたちどころに分かるし、
非常にいいんじゃない？
仕様書をプログラムに翻訳するだけの能しかないプログラマは職を失うけど。
Re: (スコア:0)
自然言語で「複数の物体は同時に同じ座標に存在できない」と書くのはあまり自然なことではない。
常識を前提とした自然言語で、常識を持たない計算機が常識から外れないよう、
どの常識を教えなければならないかを想起できるヒトがプログラマになるわけだ。
今とそんなに変わらん。
Re: (スコア:0)
自然言語処理ができるというのはつまり、そういう「常識データベース」もできつつある、ということでは？
Re: (スコア:0)
言語そのものの情報(文法)には、言語で表現される情報は入ってませんよ。
Re: (スコア:0)
フレーム問題と同じく「常識データベースを充実させればコンピュータでも常識的な判断が可能」っていうのは楽観的すぎでしょう。
Re: (スコア:0)
プログラミングの本質とは違う。