スクリプト言語と開発効率について

1 ：07/04/26 〜 最終レス ：10/03/21

最近PHPをはじめました。
スクリプト言語は基本的に、変数の型を指定できないものが多いわけです。
で、これは本来、これら開発効率を売りにした言語の特徴だったはず。
でもちょっと待って下さい。
この仕様が間違いなく開発効率を下げている。
意図しない挙動をフォローするための機能実装がとても非効率的です。
皆さん、特にC系統の言語に精通されている方にお聞きします。
スクリプト言語での開発効率に関して、
普段意識的に実装されているロジックとかありますでしょうか。

2 ：

お前はPHPを選ぶべきではなかったな。終了。

3 ：

スレタイと>>1の各段落との関連性が互いにすべて薄い件について

4 ：

結局PHPで作る物は一回限りの書き捨てが多いので
メソッドの引数のタイプをいちいちチェックして、他の誰かが使ったり、
また再利用したりするときに備えるなんてことはそれほど重要じゃないことに気がついた。
メソッドどうしが互いにバンバン依存しあってても気にしない。
間違った呼び出しかたでメソッドを呼んでるコードがあったら、
メソッドの方を書き換える勢いで行けばいいよ、動けば良いのだから。
これはPHPが悪いって訳じゃなく、動的型付けのスクリプト言語はそういう性格のものだってだけのこと。
Railsだって一見きれいだけど、なかみはガチガチの密結合だしね。

5 ：

perlならともかく、phpで作るものって
普通一回限りの書き捨てよりも
ウェブアプリの方が多くないか？
> れはPHPが悪いって訳じゃなく、動的型付けのスクリプト言語はそういう性格のものだってだけのこと。
いや、悪いのはPHPでも、動的型付けのスクリプト言語でもなく、
そういうコードを書くプログラマ。

6 ：

物に寄るわな
ちょっとDB繋いで情報表示するだけの告知ページやら、メールフォーム系で微妙に違うものいくつも作るときとかではphpで書き捨てる
がつがつ使い回す状態想定する時にphp採用したいかっていうと・・それもケース次第だな
うちだとあんま規模大きいのだと、phpは選定対象から外れがちだなー
だからって人材配置考えると、JAVAがいいとかRubyで行くぜとか一概に言えるもんでもないし
あー、なによ一言で言うと結局「場合次第」かよ
ゴミカキコよ俺

7 ：

>>5
PHPでウェブアプリを作るとき、フレームワーク以外の自作ビジネスロジックを使い回す事ある?
汎用掲示板機能クラスとかみたいな感じで

8 ：

他の言語が出来る（あるいは出来るPGを集めることが出来る）なら、PHPを選ぶ理由はない。

9 ：

rubyはメモリを多く食います

10 ：

Cみたいにコンパイルが-Wallで通ればそこそこ動くという事が無いので、
PHPでもRubyでも自動テストはちゃんと書く事にしてる。
自動テストが通る == -Wallで警告無しでビルド出来る
という認識。
あと、ヘッダファイルだけみりゃ何やっててどう呼ぶかが大体わかるということもないので
関数の中身を読まなきゃやってることを理解出来ないことが比較的多い。
これには面倒でもコメントをちゃんとつけるくらいの対応しかないね。

11 ：

趣味でサービスサイト作ってるけど、テスト作れる人に憧れる
できたほうが絶対によいとはわかっていながらずるずる勉強先延ばしだ

12 ：

CとかJavaとか使えるけど、使い捨てと割り切ってスクリプト言語使う香具師と、
精一杯がんばってphpとかのスクリプト言語がすべてって香具師では、スクリプトの品質が異なっていて当然。
プロジェクトで悩ましいのは、そういう混在したスキルの香具師のモチベーションを維持させ続けるレベルを設定できるか。
理想論だと実力のある香具師はモチベーション高まるけど、下の方は落ちこぼれる。
妥協論だと、下の方は付いて来れるけど、実力のある香具師はモチベーション維持できずに逃げ出す。

13 ：

サブルーチンとかメソッドだけ巧いこと書いとけばぉk

14 ：

>>1
> 意図しない挙動をフォローするための機能実装
が大変という時点で、少なくともWEBアプリ系のシステム規模では言語関係なく腐ってます。
データの入り口をきっちり処理することを前提にするなら、後は内部コードが腐ってるだけの
ことじゃないですか。PHPならassertもあるし、それ以上の何が必要か正直わからない。

15 ：

とりあえず、PHPはセッションとPOST GETリクエストから変数取ってくる事ぐらい
分ってれば十分なので、さっさと他の言語に移る事をおすすめする

16 ：

あっ、あとSQLを実行した結果を連想配列にいれられるところもだな

17 ：

テストになれてくると、テストやらないと逆に後で面倒な
ことになるのが恐くなるな
http://www.phpunit.de/pocket_guide/2.3/ja/index.html

18 ：

>>1
>この仕様が間違いなく開発効率を下げている。 
って例えば？

19 ：

>>15
それプラス、困ったらprint_r()だ。これでPHPのマスター完了。

20 ：

print_r()より、var_dump()のがいい。

21 ：

>>18
すぐ下にあるように、変数がなんなのか知るためにいちいちprint_rが
必要な分、手間がかかるってことじゃないかな。
ほら、動きがおかしいプログラムの怪しい変数をprint_r()して、
バグの原因がわかるっていうことよくあるじゃん?
例えばCには類似の問題がトリッキーな書き方をしないかぎり無いでしょ?
全部の変数に型が決まってるわけだから。

22 ：

> ほら、動きがおかしいプログラムの怪しい変数をprint_r()して、
> バグの原因がわかるっていうことよくあるじゃん?
Cでも怪しい変数をprintfしてバグの原因がわかることよくありますが？

23 ：

PHPはスクリプト言語なのでコーディング時間が短くて済むというのはある意味
正しいが、デバッグの時間を考慮すると一概に効率がいいとはいえないな。
デバッグの事を考えるならMVCを分けて、テストを書いて、重複のあるコードを避けて
となるが、そういうプログラミングを行うならHTMLの中にプログラムが書けるPHPの
魅力半減だし、始めから簡素なPerlやRubyでフレームワーク使ったほうが良いんじゃ
ないかと思えてくる

24 ：

適材適所と言う言葉を知らんと言うことで FA ?

25 ：

PHPはソフトウェアの品質を高くするという目的には
適さない言語という事でFA？

26 ：

>>25
規模と書き方に大きく依存すると思う。それは多分JavaでもRubyでも一緒。
Perlですら、十分に高品質なプログラムはあると思うが。
もっと言うならOSを落とす危険が常にあるようなC・C++みたいな言語は
最悪の「品質」のプログラムも「容易に」書けると思う。

27 ：

>>24 を証明してくれてありがとう ⇒ >>25
>>26
> OSを落とす危険が常にある
それは、ＯＳもしくはその設定に問題があるんじゃ...

28 ：

PHPでデバッグが容易になるような書き方、
つまりオブジェクト指向を活用して、コードのあちこちに
ルーチンやデータが分散しないようにオブジェクトに
閉じ込めておく。そういう書き方をするとJAVAと同じような
冗長な書き方をしないといけないし、そこまでやるなら
JAVAと同じようにデータ型のチェックをコンパイル時に
してくれてもいいと思うのだが

29 ：

PHPがレンタルサーバーなどでも簡単に運用できるJAVA目指すなら
かなり需要があると思うが、劣化Perlのような仕様をいつまでも引きずってる
せいで中途半端な言語に成り下がった。

30 ：

>>28
そう思うなら Java 使ってれば？
>>29
> PHPがレンタルサーバーなどでも簡単に運用できるJAVA目指すなら
誰もそんなもん目指してませんが。

31 ：

始めからPHP使うなという事で
このスレの結論でてしまいましたか

32 ：

PerlをPHPなんかと一緒にするなよ。
PHPは変数の宣言が出来ず、スコープが関数単位。
だから、コードが汚くなって、ケアレスミスが増える。
いまどきPerlをuse strictなしで書く人はいないが、PHPはno strictで書くしかない。
その分、誰でもすぐになんとなく書けてしまえるけどな。

33 ：

perlで済ませる様な一発処理ならphpとかのスクリプトでもメリット有るだろ。
でも業務システムとか大規模サイトとか堅牢さと処理能力を求められるのは、コンパイル言語じゃないと厳しい。
銀行の口座サイトが、ミクシのようにperlで設定ミスでスクリプト漏れたら痛いし。

34 ：

>>32 は error_reporting() とかを知らんのだろうな...。

35 ：

何、頓珍漢なこと言ってるんだか。
Javaはコンパイルが必要だからエンタープライジーなんじゃなくって、型チェックが出来るからエンタープライジーなんだよ。
PHPの場合、型の宣言どころか変数の宣言自体出来ないから話にならない。
$status_flg = false;
...
$status_flag = true;
...
if ($status_flg) {
...
}
↑最後のifが通らなくて、その理由がわからない。それがPHPクオリティ。

36 ：

>>34はE_STRICTとuse strictが別物だと言う事を知らないんだろうな…。

37 ：

>>35 は多分 error_reporting(E_ALL) を知らない。
いや、>>35は知ってるが、それを使わないのがPHPクオリティと言いたいのか。
それなら同意。
>>36 は俺にはよく分からないので詳しく。
・・・というか PHP の E_STRICT は多分ONではやってられない。
あまりに「非推奨」とか「廃止予定」とかが多すぎてPEARのライブラリすら使えない。
それもPHPクオリティ。

38 ：

>>37
いや>>35はE_NOTICE がONでも通るだろ。よく読め。(PHPクオリティ?)
だからといって全ての変数に型宣言が必要とか言うのは掲示板スクリプト等程度
においては正直効率的とも可読性が高いとも思えない。
（明示的なキャストしまくりとか勘弁して）
やっぱり規模（と開発体制・人手の分散度合い）によるケースバイケース
でいいんじゃないか？ ←ここでループ

39 ：

型宣言というか、if （$obj->validData)みたいにオブジェクト指向を使えば、
実装のデータ型はカプセル化されるので問題ないと思うが、
しかしPHPのオブジェクト指向は書きづらいし、使いづらいよね。

40 ：

if ($obj->validData())だった

41 ：

if ($runtime->getStatus())
とかやって、もしクラスがgetStatusインタフェースを持って無かったとしても
使用してみないとエラーが出ないという恐さはあるか。

42 ：

>>35
言いたいことはわかるし、間違ってるとは言わないけど、その手のタイプミス
にかかわるバグが処理系で摘出できないケースは頻度は少ないが Java にだっ
てある。
もちろん頻度が少ないと言うのは重要で、だから大規模なソフトウェアに PHP
より Java が適していると言いたいんだろうけど、ごちゃごちゃ書かなくても
>>24 で充分だろ？

43 ：

変数は補完入力かコピペ入力をするから、
>>35 のようなミスが起きた記憶はほぼないな。
今となっては、変数宣言はあってもよかったなと思うけど。
設定で、変数宣言の必要なモードをつけてもいいと思う。

44 ：

>>43
同意。

45 ：

PHPの問題は、間違った引数の型でもメソッドを呼べるということだよなぁ。
で、デバッグに勘が必要になる。
自分だけが書いたのコードなら自分の思考パターンは大体わかるからいいけどさ。
まぁそのへんの融通が効くから書き飛ばすのには向いているとも言える。
上にあるように、間違った呼びかたをしてたら呼び出された先をさっさと直しちまえば良い。
アプリ全体の構造が頭の中で把握できる範囲ならこれで大抵はうまくいく。

46 ：

ケースバイケースって言っても、Perlでuse strictしないで書くなんて、それこそ10行未満の使い捨てのスクリプトだけだよ。
PHPを使うケースって10行未満のスクリプト限定になっちゃうけど。

47 ：

例えば、
use strict;
sub foo {
my $arg = shift;
print "$arg\n";
}
sub bar {
print "$arg\n";
}
foo('hello');
は、実行しようとするとコンパイルエラーが起きちゃう。bar関数で不正に$arg使ってるから。

48 ：

で、PHPはどうかというと、
<?
error_reporting(E_ALL);
function foo($arg) {
print "$arg\n";
}
function bar() {
print "$arg";
}
foo("hello");
実行すると、出ました、「hello」。残念ながらerror_reporting()はbar()を見てません。アッザース。

49 ：

>>48
それ、PHPじゃなくてもPythonやRubyでもおんなじことだよ。
コード読み込んだ時点ではエラーが出ず、その箇所が実行されてはじめてエラーが分かる。
でもunit testを書いていれば、error_reporting(E_ALL) のレベルで十分、特に困らない。
PHPもRubyもPythonもみんなそれで問題なく開発できてる。
もしuse strictサイコー、他のスクリプト言語ダメダメというなら48の勝手だけど、use strictしたところでJavaやC#からみれば
> アッザース
だな。目くそ、鼻くそを笑うとはまさにこのこと。

50 ：

>>49
だな。>>47のも
use strict;
my $arg;
（以下略）
で通るし。だからケースバ(ry

51 ：

>>46
> PHPを使うケースって10行未満のスクリプト限定になっちゃうけど。
君は、それでいいんじゃね。
俺はももう少したくさん書けるけどね。

52 ：

PHPの最大の問題はブロックによるスコープの切り替えがないことなんだよな。
無名関数がないから他の言語だったらインラインでも書けることを、どうしても一時変数を使わないといけない。
で、その変数は関数全体で有効になるから、大事な変数と使い捨ての変数がごっちゃになってしまう。
↑と変数の宣言が出来ないこととあいまって、熟練者が書いてもあまり綺麗にならないし、初学者が書くと恐ろしく汚いコードになる。

53 ：

PHPは要するにインスタントラーメンなんだよな。
システム開発産業としてみた場合のPHPのメリットは大きい。
メリットがあるからこそこれだけ流行してる。証明されてる。
確かにお湯かけるだけで作れて、少なくとも不味くて食えないってことはない。
しかし、インスタントラーメンばっかり作ってて、料理人とはいえないよね。

54 ：

>>53
ってぇとPHP用フレームワークは有名店コラボのカップ麺？

55 ：

実際の日常生活でも料理人が求められることってないだろ
普通は自炊なり家庭料理なりだ
インスタントラーメンで用が済むのに料理人が出張ってきたら困る
しかも料金高いし

56 ：

インスタントラーメンだけ作ってても、客が来て儲かってれば
料理人だろ。
○○の言語じゃなきゃ駄目とか言ってる方が素人ぽくみえるぞ。

57 ：

そうだな、言語が開発効率と無関係なら
アセンブラでウェブアプリ造れるよな

58 ：

結論：Javaでメジャーなフレームワーク使うのが一番。

59 ：

>>58
なんでそうなるんだｗ

60 ：

徹底してルーチンやクラスを分けて
変数のスコープを数十行程度にする
そういう当たり前の事が簡単にできる
スクリプト言語がいいね。RubyとかPythonとか。

61 ：

ここまでの流れに加えるなら、Web用途ならやはり文字列の扱い重要。
スクリプト言語の有利な点は、全て文字列の扱いと配列（およびリスト）や
連想配列のデフォルト実装だと思う今日この頃。
正直、perlやPHP、rubyから入った人間はCやJavaの文字列、配列の
扱いは気が狂うほどのパラダイムシフトじゃないか？マイナス方向への。
int i;
for(i=0; i<ar.length(); i++){
ar[i] にほげほげ
}
は正直foreachやeachに慣れた人間には耐えられないんじゃないかな。

62 ：

ふつうのCやJavaだと
> ar.length()
は
ar.size()
なのかなと思う今日この頃。不勉強すんません。

63 ：

Perlって実はかなり厳格なプログラミングを要求されるんだよね。スクリプト言語の中では。
Perl6ではよりその傾向が強まる。

64 ：

以前のPerlがテキトー万歳だったんだよ
それだからこそ受け入れられてきたんだがそれゆえ5で崩壊した
use strictとかがある時点で

65 ：

>>61
俺はまさにPHPでプログラム始めた人間だが、最近Cを使ってその辺は耐えられなかったことはないが、
「だからPHPとかPerlができたのか」とスゴく納得した。

66 ：

Javaは冗長だけど注意深く使用すれば誰が読んでも内容が理解しやすい
コードを書きやすいので、一概に悪いとは思わないな。

67 ：

そんなこと言ったらたいていの言語は読みやすいように書くことはできるよ
無限の時間とリソースが使えればな
それを極力圧縮するできるがどうかが「便利」の要だろ

68 ：

Rubyも読みやすい書きやすいっていうけど、リフレクションを多用すると
恐ろしいことになるからなぁ。
リフレクションみたいに、静的な型なんてクソクラエみたいな書き方は、
なかなか強力で、使いどころを間違えなければたしかに書くときの効率はかなり上がるけど、
一方乱発するとメンテの効率をいちじるしく落とすね。

69 ：

型付けの弱い言語はバグの温床

70 ：

>>69 型付けが弱い云々というよりは文化じゃないのかなと。
PHPならそれ３日でできますよ。フレームワークなんていりませんよ。て
べたべたべたべた書いて動いちゃう、それでいいやって仕事が多く、そんな
ソースを槍玉にあげてもなぁ、という気もする。そりゃ手を加えるほどに
バグも入るさ。安さ速さ最優先なんだから。
PHPの問題は言語仕様そのものというよりその使われ方だろう。
またそういう書き方でやってきた人間が、ある程度以上でかいもしくは
業務処理系のものまで上記の延長でPHPで作ろうとするから、言語の（糞）
仕様まで問題になるんだと思う。
perl, ruby, python なんかはまだツールとしての用途があるから違う文化が
あるのかもしれないが、PHPはもうwebしかないから、もともとやばい言語仕様
なのにそのままでフレームワークとかオブジェクト指向の整備とか大型化の
方向でどんどん泥沼にはまってるような気がする。

71 ：

PHPにはちいたんがある

72 ：

なんのためにプログラムがあるのか勘違いしてないか？おまえら

73 ：

プログラミング言語はプログラム作成のために存在しておりますよ
思想体現の手段ではありませぬ

74 ：

人間の思考つまり、思想に近いプログラム、
読みやすく書きやすいプログラムとも言えるな。

75 ：

結果がよければあとは何でもいいじゃん。
自分の得意なもので結果だせればそれでいいでしょ。
批判ばっかりしてて神経質じゃねえのかプログラマーって

76 ：

君の世界に客というものはいないのか
あるいは他の開発者でもいい
未来にそのプログラムを改修する自分でもいい
誰か他者は介在してないのか

77 ：

ヒント：ニートの耳年増

78 ：

>>69
php で色々組んでるけど、型関係でバグったことは使い初めの頃の
勘違いしかない。
処理系に型の間違いのチェックアウト能力がないのは確かだけど、
そもそもそんな間違いをぼろぼろやるプログラマは他のところでも
バグってる可能性が高い。

79 ：

さー、自称天才PHPプログラマーが登場しましたよ

80 ：

>>78
>バグってる可能性が高い。
まぁ、そうだな。69みたいな知ったかな書き方する奴はたいていどの言語でもバグ出す。

81 ：

そのさー、バグを出す/出さないをプログラマの能力依存にしないための方策の一つが、
強い型付けなんだが…。

82 ：

ならバグを出さなけりゃ型の概念要らないって事だね

83 ：

バリアント！バリアント！

84 ：

コンパイラーが型チェックしてくれるので、単純なバグはそれだけでつぶせる。単純なミスをまったくしないプログラマーには不要な機能かもしれないが。

85 ：

バグをださないように慎重に行うプログラミング、
バグが出てからバグを潰していくプログラミング、
どっちが効率がいいかってどこかで見たな

86 ：

>>81, >>84
いや、型のチェックアウトができることによるバグ検出能力にケチつける気はないけど、
強い型付けによる不便さもあるわけだから、トレードオフでしょ？

87 ：

>>85
それきいてFreeBSDとWindowが頭にうかんできた

88 ：

コンパイラによる型チェックが不便とか言ってるのは素人だけだろ？
後はMCでない、ぬるい仕事しかした事のない歳だけ食った自称ベテラン。

89 ：

>>88
ゆとりまっしぐらな俺でも「変数の宣言いらないよ！」「型が柔軟だよ！」な謳い文句に気持ち悪さしか感じない
使い捨ての変数をバカみたいに量産する糞スクリプトしか書けないのか？って思う

90 ：

>>88-89
また、適材適所を知らないアフォが沸いてきたよ。(w

91 ：

>>90
バカの一つ覚え乙

92 ：

その一つすら覚えられないの？ (w

93 ：

>>91
いや、それが全てだろ。だから何回で(ry
まあそれぞれの適所を（実際に使わずに）理解するためには、こういうスレは
いいと思うがな。

94 ：

適す範囲が著しく狭い物や、どこにも適さない物もあるでしょう
ホント思考が極端だな

95 ：

そりゃあるだろうけど、このスレと何の関係があるんだ？
具体的に指摘できないなら、自分の日記帳にでも書いたほうがいいよ。

96 ：

>>94
> どこにも適さない物もあるでしょう
つまり存在意義のかけらもない言語？これは言い切る自信はないなぁ。
（強いて言うならMSのJ#みたいな？）

97 ：

動的な型と静的な型の長所短所はあるけど、（もっともRubyの松本なんかは動的な型で決まりって言ってるけど）、
動的な型付けでかつ変数の宣言ミスをコンパイラーがチェックしてくれるPerlはかなり理想的だな。
PHPの場合、型が動的なのに加えて、ブロックによるスコープのコントロールが利かないこと、
変数が1種類しかないこと（Perlでいうところの@arrや%hashがなく、$arr/$hash）、
名前空間がないこと（まあ、パッケージ変数の代わりにクラス変数を使うんだけど、パッケージがないので今度はクラスの管理が難しくなる）
これらが組み合わさって、汚いコードを書くことを強制されるというか。ゆえにバグを誘発する。

98 ：

>>95
具体的に指摘できていないのは適材適所適材適所言ってる奴も同じだろ

99 ：

>>97は>>48と同一人物
Perlのーは自分のブログでやれ
じゃないと>>48とおなじようにやり返されて恥かくだけ

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

まあ。ほとんどないとおもうが。。 (130)
●CGI作成に愛の手を・・・● (159)
結局ＷＥＢの言語は何がいいんだ？ (239)
PHP上級者が集まるスレ (498)
Webでオブジェクト指向プログラミング (431)
Rubyにはプログラミング言語以上の価値があると思う (536)
--log9.info------------------
【SKE48】原望奈美応援スレ Part6 【新逆上公演】 (162)
【目指せ】NMB48総選挙対策本部【10議席】2 (505)
【リバイバル公演】SDN48☆237【一夜限りの復活】 (879)
【AKB48】大場美奈応援スレ★48【みなるん】 (630)
【事務所】ムーサとAKSについて 77【総合】 (915)
【一般人お断り】矢神久美スレ3【くーみん】 (566)
【SKE48】木崎ゆりあ応援ｽﾚ ☆77【ゆりあぴーす】 (409)
【AKB48】柏木由紀応援ｽﾚ☆917【ゆきりん】 (1001)
【NMB48】山本彩 応援スレPart71【さや姉】 (615)
【AKB48】山内鈴蘭応援スレ☆78【らんらん】 (587)
【NMB48】三田麻央応援スレ☆３【横溝真琴】 (459)
【NMB48】高野祐衣応援スレ★2.3【ゆいぽん】 (738)
【乃木坂46】生駒里奈応援スレ★8【いこまちゃん】 (725)
【マジすか学園】センターとネズミの屋上★13 (332)
新規の俺に板野△なエピソード教えて (292)
【AKB48】秋元才加 応援スレPart307 (930)
--log55.com------------------
★2ch.scは何故失敗したのか
★クロール批判要望スレ
★削ジェンヌに文句ある人集合
★迷惑行為報告担当 - 小さな親切募集中 2
★2ch.scへの要望スレ Part3
★かっこう観測所
★スレ立て人キャップ
★2ch.scニュース系板観測所