あなたは本当に「プログラミングができない、向いてない」のか？ 〜うるう年判定プログラムで考える〜

「プログラミングができない」の前に、PCの使い方やOSの使い方、プログラミング言語の環境構築、プロジェクトの作成の仕方、コンパイルの仕方、実行コマンドでつまづいてる人も多そう。

@ringo-apo さん
コメントありがとうございます。
そこで躓いている人、めちゃくちゃ多いと思いますね...。

すぐ向き不向きの話になりがちですが、「ちょっと知ってる人に聞いたらすぐ解決できた」みたいなケースもあるので、わからないところを相談できる人が周りにいるか、とかも、学習を左右しそうですね。

カルノー図を書くと条件が理解しやすくなるのではないかと思います。

A:0 4の倍数でない
  1 4の倍数である
B:0 100の倍数でない
  1 100の倍数である
C:0 400の倍数でない
  1 400の倍数である

year = int(input())
if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:
    print("うるう年です。")
else:
    print("うるう年ではありません。")

さすがにこれができない人は向いてないと思います。
プログラミングでつまずいてるわけではないと言うのは詭弁です。

プロレスに向いてないんじゃなく体が小さいだけだからうちのスクールに来なさいとか、歌手に向いてないんじゃなく声が悪いだけだから壺を買いなさいとか、そのレベルの話になってます。

これらの知識・感覚が自分に有るのか・無いのかを自覚して、無いならそれを補っていくことが重要。

と簡単におっしゃいますが、具体的にどうやれば補えますか？小学生のドリルからやり直しますか？

この記事レベルの問題が解けない人が、その後何らかの努力によって立派なプログラマーになった事例があるなら、どうやって学習したのか知りたく思います。

コーディングと課題解決のためのアルゴリズム考案は普段プログラミング業務としてひとまとめにされる内容かと思うので、「文の書き方、オブジェクトや型の扱い方といった文法サイドの難しさ」のみを「プログラミング」として扱っていることに違和感があります

この記事を読んだ自分の感想は
・プログラミングは「文法」「アルゴリズム」の二面で難しさを評価するべき
・「アルゴリズム」は「文法」よりもプログラミングの本質に近い部分
・今回の問題は「アルゴリズム」の難しさが高いもので、むしろ「向いていなさ」がわかるだろう
という感じです

ある程度のアルゴリズム考案能力を持っているかという試金石には悪くないと思いますが、逆に数か月以上学習してきたプログラマがこの問題を解けないようであれば「あなたはプログラミングで一線級にはなれない」と断じられる難易度だとも思います
アルゴリズムの考案能力は文法の知識よりもずっと伸ばしづらいものなので……

個人的にはこの分け方は好きです。保守性、可読性、テストのしやすさなどプログラミングにおいては重要なスキルですから。

そう考えると本記事では、「上手く書くスキル」と「要求仕様を実装に落とし込むスキル」で分けているように感じます。

プログラマーにおいてこの2つのスキルは大事と感じます。（あ、もしエンジニアだったら要求仕様を満たせないって致命的か……）

ですが、センスという言葉だけで初心者を切り捨てたり挫折させたりと暗い未来を暗示する非建設な姿勢よりも、こういった分け方もあるという考えの提示の方が未来があって自分は好きです。

@fujitanozomu

カルノー図を書くと条件が理解しやすくなるのではないかと思います。

if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:

書いたあなたは良いけど別の初見の人は何してるのか分からないのでそういう書き方は辞めてください。

※うるう年問題ではなく、問題を汎化させて言っています。

@ashworth さん

書いたあなたは良いけど別の初見の人は何してるのか分からないのでそういう書き方は辞めてください。

えっそうなの?
カルノー図を知らなかった人は勉強する機会になるし、知ってる人は流せば良いのでは?
初見の人には理解されない書き方は控えるべきということであれば新しい知見に会う機会もなくすべきということだと思いますがそれが正しいのですか?? 自分はそうは思わないですね。

いやー、さすがにこの程度で何をしているかわかりませんとか言われると困ります...

※うるう年問題ではなく、問題を汎化させて言っています。

の意味が分からない方が２人。
仕事できなそうな方ですね。社会人じゃないのかな？

相手がわかっていないというその思い込み、やめたほうがいいですよ。

@error_401

あなたがね。

社会人で他人の書いたコードを沢山見てくれば、
どういうコードが悪質なのかという基準が出来てくる。

あなたにはその基準が、全く無い。

分からない人がいる可能性を考慮してWikipediaの記事のリンクまで貼った投稿に「問題を汎化させて言っています」とは呆れる他ない

@fujitanozomu

何を言っているのか分からないですが、

社会の要求に沿ったシステムを開発するために必要な汎用的なコードが書けていないので
「迷惑だから辞めてください」と言っているだけです。

あなたは四重三項演算子とか書きそうだ。

思い込みが激しすぎて笑うしかない。

説明皆無で例(しかも該当しない謎の例)を一つだけ出されてもどう汎化すればいいのかわかりません。
一行に演算子が多すぎるということですか？

うるう年の計算は初見で十分わかるので、他の例を二つ三つ出し、どこがどう悪いのか説明を加えると伝わりやすくなるかもしれません。

プログラミングができない、あるいは素質がないとはどういうことで、その原因は何で、改善可能なのかどうかということに興味があります。
例のふたこぶラクダの論文が話題になったとき、ある程度の納得感を得られたのですが、その論文も撤回されたようで。

そういう文脈でこの記事にも興味を持ちました。

ちなみに個人的には、素質がない人は何をやってもダメなんじゃないかと思ってます。

・・・お見苦しいコメントをいくつかかいてしまったので、すこし方向修正。

整理せず問題文ののまま愚直に書くとこうですかね

def is_leap(year):
    flag = False
    # A: 4の倍数ならばうるう年 
    if year % 4 == 0:
        flag = True
        # B: 100の倍数ならば平年
        if year % 100 == 0:
            flag = False
        # C: 400の倍数ならばうるう年
        if year % 400 == 0:
            flag = True
    return flag

@ashworth さんの　2022-04-21 22:48　の書き込み

仕事できなそうな方ですね。社会人じゃないのかな？

こちらは下記のコミュニティガイドラインを見る限り
ふさわしくない表現ではありませんか？

コミュニティガイドライン

誹謗中傷や差別的表現を含む記事、犯罪行為の助長になる記事は禁止
中略
また例え本人が知り得ない場であっても、誰であろうとバカにされたり、影で嫌なことを言われて気持ちよく思う人はいません。 Qiitaは、サービスを通してエンジニアを幸せにしたいと考えていますので、他人をそのように扱わない真摯なコミュニティを目指します。

ガイドラインの見出しでは記事となっていますが、コメントに関するガイドラインが無かったためこちらを参考にしています。
引用したコメントが出てくる前のやり取りとは関係ない誹謗中傷であるようにしか見えません。
こちらの記事自体は、プログラマーとして仕事ができるかどうかがスタートになっているのではなく、プログラマーに向いているかどうかという話題が起点となっているようなので、仕事ではなく趣味の日曜プログラマーかもしれません。ましてや社会人じゃなさそうってお話をされていますが、社会人かどうかなんて全く関係ない視点のお話です。どう見ても自分の意見と異なる人を貶めて自分が正しいと主張するのが目的としか読めません。
エンジニアであるのでしたら、ご自身の意見の正当性を論理的に書かれては如何でしょうか？
相手を貶めないと出来ないようでしたら、あなたには正当性が無いと自白しているとは思えませんか？

一応自分の個人的な感想としては、ソースコード上にカルノー図は載せられないので、引継ぎ資料に作った図を保存しておき、そちらへの誘導をコメントで書いておくだけで、うるう年となる条件のブロックをORで列挙しているだけというのが理解できるかと思います。が、作成したカルノー図が無いとソースとの連携がないので作った人がつっくった時以外だと分かりにくいかもしれませんね。

カルノー図が必要ならマークダウン形式で複数行コメントに書くこともできますが、閏年の計算方法は天文学を応用した学術計算に基づいたもので、数式で表すこともでき、資料はいくらでもあるため、この図すら必要ないと思います。

「汎化」の意味が今一つわかりませんが、「複雑な学術計算をプログラム中に記述する方向性」の違いであるなら、効率を求めても読みやすさを求めてもケースバイケースでどちらが絶対ということはないと思います。
このケースにおいては、たかが閏年の計算法なので、なおさらどうでもいいです。
コード例ではなく実用であれば、バグ混入のリスクを減らすために、既存のカレンダークラスを使えばいいと思いますよ。

ちなみに .NET の閏年計算はこちら。

@osorezugoing

それ、問題文の条件のまま書いちゃダメなんですよね。
「ただし」がある場合は前出の条件を否定してくるので、条件の順番通りに書くと破綻します。
だから、「ただし」がある場合は条件を逆に記述していくのが鉄則です。

@Zuishin

「汎化」の意味が今一つわかりません

汎化は汎化でしょう。

閏年問題に限った話では無いと言っています。

条件分岐が商業的な理由でどんどん仕様変更されていく事があるのは、仕事でプログラミングをした事があれば分かりませんか？

その時に

if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:

この条件分岐を延々と伸ばしていくのですか？
頭がおかしいでしょう。

正直、この程度の事が分からない方が多数居る事に驚愕しています。

@lensouko

運営の方がどう判断するか次第ですが、

社会で仕事をしていく上で、迷惑な事をする人が自分のしている事に何の疑いも抱いていないのなら、

それは迷惑行為その物なので「迷惑です」と言っているだけです。

汎化は汎化でしょう。

汎化の意味をどうとらえていますか？
私はあなたの言う「汎化」の意味を想像して書きましたが、それに対して合っているとも違っているとも返事がありません。
否定的に書かれているということは、違っているということですか？

汎化であるなら、閏年の例にはあなたの言う問題が含まれていることになります。
その問題は何ですか？
一行の長さが長すぎるということなら、別にそこまで長くないと思います。

仕事仕事と連呼されていますが、一流のコードはこうなっているというのを示しましたよね？
あれを見てもあなたの「仕事」が偏っていると思いませんでしたか？

『今しか見えない』おばかさんが何か言っていて読む気も起きません。

また、時間を無駄にしてしまった。

整理せず問題文ののまま愚直に書くとこうですかね

こちらを愚直にリファクタリングするならこんな感じでしょうか。
普段Pythonは書かないので、文法が変だったらすみません。

# リファクタリング前
def is_leap(year):
    flag = False
    # A: 4の倍数ならばうるう年 
    if year % 4 == 0:
        flag = True
        # B: 100の倍数ならば平年
        if year % 100 == 0:
            flag = False
        # C: 400の倍数ならばうるう年
        if year % 400 == 0:
            flag = True
    return flag

時代は早期リターンだと思っているので、一番最後に影響する条件が一番厳しい条件だろうという考えのもと、最後の条件を一番上に持ってきます。

def is_leap(year):
    # AかつCならうるう年
    if year % 4 == 0 and year % 400 == 0:
        return True

    flag = False

    # A: 4の倍数ならばうるう年
    if year % 4 == 0:
        flag = True
        # B: 100の倍数ならば平年
        if year % 100 == 0:
            flag = False
    return flag

再び最後の条件を上に持ってきますが、早期リターンより上にならないようにします。
この理由がうまく言語化できない……

def is_leap(year):
    # AかつCならうるう年
    if year % 4 == 0 and year % 400 == 0:
        return True

    # AかつBなら平年
    if year % 4 == 0 and year % 100 == 0:
        return False

    flag = False

    # A: 4の倍数ならばうるう年
    if year % 4 == 0:
        flag = True
    return flag

もうフラグはいらないよね？

def is_leap(year):
    # AかつCならうるう年
    if year % 4 == 0 and year % 400 == 0:
        return True

    # AかつBなら平年
    if year % 4 == 0 and year % 100 == 0:
        return False

    # A: 4の倍数ならばうるう年
    if year % 4 == 0:
        return True

    return False

全部の条件式にyear % 4 == 0が入ってる……ということは、これにあてはまらないなら結局Falseになりますね。

def is_leap(year):
    # Aでないなら平年
    if year % 4 != 0:
        return False

    # AかつCならうるう年
    if year % 400 == 0:
        return True

    # AかつBなら平年
    if year % 100 == 0:
        return False

    # 残りはすべてAかつBでもCでもない
    return True

こんな感じでしょうか。

@ashworth さん、

閏年問題に限った話では無いと言っています。

条件分岐が商業的な理由でどんどん仕様変更されていく事があるのは、仕事でプログラミングをした事があれば分かりませんか？

その時に

Copied!

if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:

この条件分岐を延々と伸ばしていくのですか？
頭がおかしいでしょう。

ルールが変わらないであろう閏年の判定と、仕様変更がある前提の案件とでケースバイケースで判断できない方であることは理解しました。

あなたは四重三項演算子とか書きそうだ。

もそうなのですが藁人形論法で他人を批判するのは少しは考えられたら良いと思います。ちょっと恥ずかしいですよ。

@ashworth さん、

閏年問題に限った話では無いと言っています。

条件分岐が商業的な理由でどんどん仕様変更されていく事があるのは、仕事でプログラミングをした事があれば分かりませんか？

その前提とするとこの記事のコードは

• 100の倍数ならば、4の倍数である
• 400の倍数ならば、100の倍数である

ことを利用し、400の倍数か? から判定するロジックになってますが、4や100や400の値が仕様変更で別の数字になった場合、コード中のそれらの値を変更された値に書き換えたとしても正しく判定されるとは限らないので宜しくないですね。噛み付く先を間違えてはいませんか?

@fujitanozomu

ちょっと恥ずかしいですよ。

それ、あなたの感想ですよね。あなたが恥ずかしいです。

@fujitanozomu

2022-04-23 13:18
@ashworth さん、

閏年問題に限った話では無いと言っています。

条件分岐が商業的な理由でどんどん仕様変更されていく事があるのは、仕事でプログラミングをした事があれば分かりませんか？

その前提とするとこの記事のコードは

100の倍数ならば、4の倍数である
400の倍数ならば、100の倍数である
ことを利用し、400の倍数か? から判定するロジックになってますが、4や100や400の値が仕様変更で別の数字になった場合、コード中のそれらの値を変更された値に書き換えたとしても正しく判定されるとは限らないので宜しくないですね。噛み付く先を間違えてはいませんか?

ごめんなさい、誰のどんな発言に対して何を言っているのですか？ 論旨が良く分かりません。

あなた、頭大丈夫ですか？　冷静になってからコメントをお願いします。

頭おかしい人しか居ないのかなぁ…？

@jintz

んー…。

なんかひたすら難しい事をやっていますけど、私、上で言いましたよね？
「ただし」がある場合は仕様を逆算すればいいだけですよって。
意味分からなかったのかなぁ？？？？？

というか、仕事で本当にプログラミングしているんですか？

たまたま5chを見たらひたすらｽﾄｰｶｰしている変な人が居るし…。

だから正常な社会生活を営めないプログラミングしか能の無いオタクと関わるのは嫌になるんですよ。

普通に前向きに、社会に役に立つプログラミング技術とはどういう物なのか考えられないんですかねぇ？　発達障害のアスペルガーの人達は。

@Zuishin

汎化の意味をどうとらえていますか？

日本語大丈夫ですか？　あなたの立場でそういうことを言うなら「汎化の意味をどのように定義していますか？」でしょう？？？

どうとらえていますか？って…。　あきれ果てて言葉も出ないです。

私が汎化って言っているのは、「何も閏年問題に限った話ではなく、複雑な条件分岐が必要な命題が出された時にどういう風に問題解決するのか？という解法として捉えてくれ」と言っています。

だから論理演算子で延々と横に繋げていくのはバカげている、という話をしている…、

…という事すら理解できない方々が、社会生活において業務でプログラミングコードを書いている事に恐怖を覚えます。頭がおかしい。

もう少しまじめにやってくれませんか？　仕事とは、あなた達のスペルマをぶちまける場所ではありません。

多分、これが仕様書か基本設計書に書かれるんですよね。

• A: 4の倍数ならばうるう年
• B: 100の倍数ならば平年
• C: 400の倍数ならばうるう年

そうしたら、この仕様に沿った形でコード書かないと。

なんであなた達のスペルマコード書いちゃうんですか？

まじで頭おかしいです。社会に出た事無いんですか？

知ってますけどね、社会の公共の場でスペルマぶちまけちゃう頭のおかしいプログラマが沢山いる事。
だからプログラマはどこでも地位が低くてあんまり尊重されていない事。

ほんと迷惑なんですよね。

もうちょっと、まじめにやってください。

たくさん書けてえらい。

@Zuishin

何主張なのかわかりませんけど、お疲れ様です。

かなりストレスがたまっているようなので、ほめてみました。
これで少し落ち着かれたら幸いです。

ハッキリ言わないと分からないみたいなので敢えて言いますが、
この記事って、「プログラミングが出来ないのはどういう理由なのか？」というところの記事で、「閏年問題」はあくまでもそれを紐解くための１題材に過ぎないんですよね。

なのに
@fujitanozomu
は、まるで「閏年問題こそ全てだ！」と言わんばかりに主題と全く関係ないのにカルノー図を持ち出して

if (year % 4 == 0 and year % 100 != 0) or year % 400 == 0:

こう書けます！！とか悦に入って書き始めて、本当にあなた、なにやってんの？　って話です。元の記事の主旨分かってないんですか？って。

そんな話、してないでしょ？

プログラミングが出来ない人は「こういう風に考えてしていけばいいんですよ？」っていう記事です。

それに対して「俺様すげー」っていうスペルマをぶちまけてしまう。もう、完全な病気です。本当に、もう一回この元の記事とあなた @fujitanozomu のコメントを読み返してくれませんか？　狂気じみています。

5chを覗いたらまだ頭のおかしい人が必死に粘着していたんですけどね、

あなたたち、頭がおかしいからもうちょっと冷静になった方がいいんじゃないですか？

色々みてますけど、 @Zuishin て人は基本的に煽りと荒らししかしてないし。

何やってるんでしょうね、この手の人たち。

かなりストレスがたまっているようなので、ほめてみました。
これで少し落ち着かれたら幸いです。

はい、頭のおかしい人がまたなんかわけのわからない事を言っています。
Qiitaはこういう頭のおかしい人を放置なんですね。

@Zuishin という人、あちこちで問題ばっかり起こしてるけど、
社会人としてまともに仕事が出来ているのだろうか？
ネット弁慶ならまぁ、できることはできるんだろうけど。

5ch観に行ったら

2ch見てること書いちゃったのは悪手じゃねぇかなあ。

とか、書いてありましたけど、

あなたたたちみたいなクズのこと、誰もまともに相手にしてませんよ？
頭大丈夫ですか？
大体、今そこ2chじゃないでしょ？　本当に頭悪い人達だなーって思いました。
2chと言っている時点で、結構いい歳してると思うんですけどね。
何やってるんでしょう、“彼ら”は。

私じゃなくて「あなたたち」が、必死にQiitaを見てあれやこれや難癖付けてるだけでしょ？
本当にバカな人たちだと思います。

普通にQiitaに対する営業妨害行為ですね。
さすが5chのクズネラー達です。

ちなみに、こちら

主に、「ミジンコ」って呼ばれている人の仕業みたいですね。

5chのクズたちは、こういう風にQiitaの記事をやり玉に挙げて根も葉もない事をあーだこーだ言って、

よろこんでるみたいです。

本当にバカですね。

主に、「ミジンコ」って呼ばれている人の自演みたいですけどね。

@osorezugoing さん、

惜しいと思いますがこうだと思います。

def is_leap(year):
    flag = False
    # A: 4の倍数ならばうるう年 
    if year % 4 == 0:
        flag = True
        # B: 100の倍数ならば平年
        if year % 100 == 0:
            flag = False
            # C: 400の倍数ならばうるう年
            if year % 400 == 0:
                flag = True
    return flag

@fujitanozomu
あなた、何年コード書いているんですか？

@fujitanozomu さんが、どうして変なコードばかり書いているのかわかりました。
Cが得意だからですね。
だから、いまだにMISRAの流儀に従ってコードを書いているんだ。
もはや、呪縛ですね、それは。

@fujitanozomu

その前提とするとこの記事のコードは
100の倍数ならば、4の倍数である
400の倍数ならば、100の倍数である
ことを利用し、400の倍数か? から判定するロジックになってますが、4や100や400の値が仕様変更で別の数字になった場合、コード中のそれらの値を変更された値に書き換えたとしても正しく判定されるとは限らないので宜しくないですね。噛み付く先を間違えてはいませんか?

だからUnitTestという物があります。
カルノー図を用いたあなたのやり方で、まともなUnitTestが出来ますか？　出来ないでしょう？
噛み付く先を間違えているのはあなたではありませんか?

…というか、

この記事を書いてらっしゃる @kjm_nuco さんが

まとめると、ある西暦に対して、

• 400の倍数ならば、うるう年
• 400の倍数でない、100の倍数ならば、平年
• 100の倍数でない、4の倍数ならば、うるう年
• 4の倍数でないならば、平年

ということになります。

と、その導出の過程まで詳細に説明して結論付けているのに、それを完全無視して持論を唱えます？
4や100や400の値が仕様変更で別の数字になったら、そりゃ、導出も変わって結果も変わるでしょうよ。
あなた、仕様変更があったらパラメタ書き換えるだけで検証しないんですか？

大丈夫かなぁ…、この人…。

多分、@fujitanozomu さんは「影響範囲」っていう言葉を知らないんじゃないかなぁ？
仕事でコードを書いていれば誰でも知っている言葉だと思っていたけど…。

@error_401

また、時間を無駄にしてしまった。

人生全部無駄にしている人が何を今更…。

@fujitanozomu

なんと言えばいいか良く分からなかったのですが、今、分かりました。

惜しいと思いますがこうだと思います。

def is_leap(year):
    flag = False
    # A: 4の倍数ならばうるう年 
    if year % 4 == 0:
        flag = True
        # B: 100の倍数ならば平年
        if year % 100 == 0:
            flag = False
            # C: 400の倍数ならばうるう年
            if year % 400 == 0:
                flag = True
    return flag

そのコード、スタックを積み上げている行為と何が違うんでしょうか？

多分、これだな。