アカウント名:
パスワード:
「配列のすべての要素が条件を満たすなら真」という定義で「入力が空集合なら、返り値は真か偽か」ってのは数学・論理学やそこら辺の話で、現実のプログラミングでは「関数を書く者がその想定する用途にあわせて定義し、その定義を関数の説明に明示すること」、「関数を使う人はそういう極端なケースが起きた場合の振る舞いに気を付けること」と言うので済む話。
同意します。この件は定期的に湧く「数学も出来ないプログラマなんてマウント」の亜種ですね。
でもこの程度のブール代数の素養すらなければ、アプリケーションの中で条件式を正しく書くのは困難だよね。少なくとも職業プログラマとしては失格だ。
すべてこうすべきだって意識の紋切り型の決め打ちって、経験が浅い人にありがちなんだよね。世の中の多種多様で複雑な事象を扱ったプログラミングしたことがないから、理屈っぽく原理原則に縛られる。そして他の経験が浅い人が鵜呑みにして自由に発想することがなくなっていく。
> 経験が浅い人にありがちなんだよね。
ってシッタカがよく使いたがる言葉だよねｗ
つまり忖度が求められる
「忖度」とは明らかに示されていないことを慮ること。「明示すべき」というのだから全く違う。
使う人間は書く人間よりわからないのだから明示すべきとしてもあまり意味がないお前どうせ「理解できないやつが悪い」とか放言しちゃうんだろ？
今回の件は明示されていないケースなので、数学や論理学に従うべきですね。ロジックを単純化できますし、後から関数を見たときに誤解することを避けられます。
いや、挙動を明示すべきじゃなかろうか。その関数の目的は数学的に正しい事を目指すものではないし、「配列のすべての要素が条件を満たすならtrueを返す」という動作だけを指定しているのがそもそもの過ちで、空の配列を渡した場合の動作も定義すべきだった。
そういう中途半端な事をしておいて「空の配列を渡したらfalseを返すかtrueを返すかが、良いプログラマかどうかの一つの境目だ」と」などと言い出すのが根本的に間違っていると思う。
さらに、「「メールのすべての添付ファイルが安全であれば受信箱に入れる」という処理において、添付ファイルのないメールはどうすべきかを考えれば、自然と答えがイメージしやすい」とか言ってるけど、添付ファイルが無いものに対して添付ファイルが安全であるかどうか調べる、という動作を想定するのがおかしい
添付ファイルが存在する場合、添付ファイルが存在しない場合、それぞれに対する挙動を指定すべきなのに、「どうすべきかを考えれば」じゃないだろう。
気をつけるで済むかぁ。別の例を出してみる。#define TRUE 0#define FALSE 1これを見たプログラマの心境を述べよ。
空集合が false を返すのも同じような違和感がある。
実際に世の中にはそういうプロセッサ(DSP/IP)が実在するんだから、文句を言ってもしょうがない。自分に選定権限がないなら、そういう系もあるんだと納得するしかないんだ。
ブール代数としての論理演算が出来ない定数定義を「系」などと呼ばないでください。
プロセスの終了コードなんかは、「EXIT_SUCCESS=0」だけど、シェルの論理演算なんかは0が真として動作するから特に問題ない。
でも、「#define TRUE 0」だと、C言語の&&や||が使えない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
プログラミングは数学や哲学ではない (スコア:4, すばらしい洞察)
「配列のすべての要素が条件を満たすなら真」という定義で「入力が空集合なら、返り値は真か偽か」ってのは
数学・論理学やそこら辺の話で、
現実のプログラミングでは「関数を書く者がその想定する用途にあわせて定義し、その定義を関数の説明に明示すること」、
「関数を使う人はそういう極端なケースが起きた場合の振る舞いに気を付けること」と言うので済む話。
Re:プログラミングは数学や哲学ではない (スコア:1)
同意します。
この件は定期的に湧く「数学も出来ないプログラマなんてマウント」の亜種ですね。
Re:プログラミングは数学や哲学ではない (スコア:2, すばらしい洞察)
でもこの程度のブール代数の素養すらなければ、アプリケーションの中で条件式を正しく書くのは困難だよね。
少なくとも職業プログラマとしては失格だ。
Re: (スコア:0)
すべてこうすべきだって意識の紋切り型の決め打ちって、経験が浅い人にありがちなんだよね。
世の中の多種多様で複雑な事象を扱ったプログラミングしたことがないから、理屈っぽく原理原則に縛られる。
そして他の経験が浅い人が鵜呑みにして自由に発想することがなくなっていく。
Re: (スコア:0)
> 経験が浅い人にありがちなんだよね。
ってシッタカがよく使いたがる言葉だよねｗ
Re: (スコア:0)
つまり忖度が求められる
Re: (スコア:0)
「忖度」とは明らかに示されていないことを慮ること。
「明示すべき」というのだから全く違う。
Re: (スコア:0)
使う人間は書く人間よりわからないのだから明示すべきとしてもあまり意味がない
お前どうせ「理解できないやつが悪い」とか放言しちゃうんだろ？
Re: (スコア:0)
今回の件は明示されていないケースなので、数学や論理学に従うべきですね。ロジックを単純化できますし、後から関数を見たときに誤解することを避けられます。
Re:プログラミングは数学や哲学ではない (スコア:1)
いや、挙動を明示すべきじゃなかろうか。
その関数の目的は数学的に正しい事を目指すものではないし、
「配列のすべての要素が条件を満たすならtrueを返す」という動作だけを指定しているのがそもそもの過ちで、
空の配列を渡した場合の動作も定義すべきだった。
そういう中途半端な事をしておいて「空の配列を渡したらfalseを返すかtrueを返すかが、良いプログラマかどうかの一つの境目だ」と」などと言い出すのが根本的に間違っていると思う。
さらに、「「メールのすべての添付ファイルが安全であれば受信箱に入れる」という処理において、添付ファイルのないメールはどうすべきかを考えれば、自然と答えがイメージしやすい」
とか言ってるけど、添付ファイルが無いものに対して添付ファイルが安全であるかどうか調べる、という動作を想定するのがおかしい
添付ファイルが存在する場合、添付ファイルが存在しない場合、それぞれに対する挙動を指定すべきなのに、「どうすべきかを考えれば」
じゃないだろう。
Re: (スコア:0)
気をつけるで済むかぁ。別の例を出してみる。
#define TRUE 0
#define FALSE 1
これを見たプログラマの心境を述べよ。
空集合が false を返すのも同じような違和感がある。
Re: (スコア:0)
実際に世の中にはそういうプロセッサ(DSP/IP)が実在するんだから、文句を言ってもしょうがない。
自分に選定権限がないなら、そういう系もあるんだと納得するしかないんだ。
Re: (スコア:0)
ブール代数としての論理演算が出来ない定数定義を「系」などと呼ばないでください。
プロセスの終了コードなんかは、「EXIT_SUCCESS=0」だけど、
シェルの論理演算なんかは0が真として動作するから特に問題ない。
でも、「#define TRUE 0」だと、C言語の&&や||が使えない。