1read 100read
2013年17WebProg81: Perl VS PHP (543) TOP カテ一覧 スレ一覧 2ch元 削除依頼
=== IIS === (293)
■■NetCommonsについて (119)
二回入力させるUIはアホ (201)
金出すから改造してよvol.3 (123)
【荒らしお断り】 BBQを組み込んでる人【システム】 (404)
さまざまな言語仕様について熱く語る闘技場 (198)

Perl VS PHP


1 : 2001/02/19 〜 最終レス :2013/08/17
どっちがいいでしょう?
お好きにバトルしてね

2 :
Perl=他人のスクリプトがたくさんある メジャー
PHP =動くレンタルが少ない      マイナー

3 :
Perl=今OK、今後不明
PHP=今ダメ、今後期待

4 :
PHP最高、軽いし。
Perlの掲示板と同じのなんてつくれますー。perl見て。

5 :
自分でサーバたてるなら、PHPが良いのでは?
Perlなんて、嫌いだ!
でも、セキュリティーに問題あるらしいが、どうなんだろう。

6 :
Perlやり始めたけど、
3ヵ月後にはPHPに乗り換えちゃったさ。
PHPまんせー!

7 :
>5
そうなのか?
特に目立った問題は聞かないが。
まぁ生産性から考えたら考えたらPHPの方が上だろうな。
好みの問題もあるだろーけど。

8 :
>>5
セキュリティホールは 3 ヶ月に一つくらい見つかっているね。
対応が早いのは救いだけど。
safe_mode = on にすればそれなりに安全でしょう。
それよりも、どう書けばセキュアなコードになるかってノウハウが少ないのが
ちょっと気になるといえば気になる。
>>7
生産性はコードの書き方にも依存するんじゃないかな。
Pear とか使えばかなり生産性向上すると思うけど、まだ使っている人ってあまり
みないなあ。
今一番ほしいのは Object-RDBMS Wrapper かなあ。
"Building Scalable Database Application" 読みながら勉強中・・・。

9 :
パールに比べたらPHPは本当にラクだ。
体感生産性は3倍以上。

10 :
Perl = プロが使う
PHP = 素人が使う
ダゼ

11 :
>>10 と同じ事を昔
C = プロが使う
Perl = 素人が使う
と思っていたさ。インタプリタ逝ってよし!な感じで。
けどPHPの生産性はVBのソレに近い感触でとにかくラク。
個人的にはPerlはすでに敵じゃない。
古い鯖で仕事するときに仕方なく使うだけ。
今後は JSP vs PHP vs ASP じゃないか?
ASPはGNUを取りこめない時点で負ける気がしてるけど。

12 :
ASP はもう死に体。未来なし。
JSP はマニアのおもちゃ。PHP もだけどな。

13 :
JSP+アプリケーションサーバはあなどり難いよ。
PHPはエンタープライズ向けのソリューションを提供しないと
未来はないと思うなー。取りあえず、今度ZendCache使ってみます。

14 :
>>C = プロが使う
>>Perl = 素人が使う
そうそう。プロならCGIをCでかけ。

15 :
>>12
信頼性もセキュリティにも問題がありすぎるからね・・・
でも Transaction Server がタダで添付というのはちょっとうらやましい。
クラス(オブジェクト)の中でいちいちトランザクション定義しなくて
よいというのは、実装の手間を大幅に軽減してくれる。
PHP 用の Transaction Server ってどこかにないかね。
WebLogic とか買って Java でやるしかないのかな。

16 :
>>14
いや、CGI と言っている段階で素人丸出しだ。
CGI/1.1 など遅くて使い物にならんよ。

17 :
>>16
CGI使わないで何使うの?
素人にもわかるように説明してくれ。

18 :
>>17
CGI を書くって表現を見ると、Web Server の CGI Handler を書くのかと
思うぞ。
あと >>16 は、mod_* な拡張モジュールは CGI インターフェースを
経由するわけじゃないから CGI アプリケーションとはいえないって
ことだと思うぞ。
んで、
「プロなら、予算と目的に応じて適切な道具を選ぶ」
んじゃないかと思うぞ。違うか?

19 :
>>「プロなら、予算と目的に応じて適切な道具を選ぶ」
>>んじゃないかと思うぞ。違うか?
まさに、おっしゃるとおり。
Cで書くなんて冗談だよ、はは。

20 :
>18
たしかに!その意味でPHPはいろんな意味でコストパフォーマンスが
高い。ASPやJSP、Perlに比べてね。

21 :
PHPの限界を知ってこそプロ。妄信するなよ。

22 :
>>21
そだね。あくまでPHPはロー〜ミドルレンジ向けのソリューション。
ハイエンドでお金に糸目をつけなければサーバサイドJava。

23 :
>>11
Perl の用途、CGI が全てだなんて思ってるんじゃねーの?
そもそも C と Perl を同じ土俵で比べてることが痛いけどさ。(w

24 :
もともと 10 のあほな書き込みが発端みたいだな。
PHP も Perl も C もみんなプロも使ってる。適材適所でな。
なんでもかんでもこれだって変なこだわりを捨てきれないやつが素人なだけだ。
サラシトコウ

25 :
プロでもこだわりは必要だろ?
こだわりの無い奴はどれを使わせても中途ハンパな仕事しかできないぜ。
素人バリのアホなこだわりは勘弁だけどな。
極めれば極めるほどこだわりも出てくるって思うけどな。

26 :
24も25もどっちも正しい。
適材適所で、ベストソリューションを選ぶのがプロ。
ある道にこだわるのもプロ。でもこだわってばかりで、周りが見えないのはガキ。
この前PostgresのMLで、糞アニオタが"Oracleは糞だ。RMDBSならPostgres"
とかほざいて突っ込みを受けて、後から分ったんだが、そのアニオタはOracle
を使ったことがないらしい・・・ここまでくるとビョーキだな。
PHP vs Perlの不毛な議論も、こんなやつらがやってるから結論がでない。

27 :
>>25
>プロでもこだわりは必要だろ?
こだわりは必要だと思う。
例えば、テキストから正規表現使って文字を抜き出す処理だけをしたい時に、
「Cでやるんだ!」って主張する奴と、
「Perl か Awk か Sed でやろうよ」って主張する奴がいるとする。
俺が言いたかったのは、この場合の前者はただの言語羽化だってこと。

28 :
こだわりで時間と金を使うのは
プロとはいえない・・。と思う俺。

29 :
それは近視眼的に考えるか長期的に考えるかで変わってくるな。

30 :
趣味プログラマで最近CGIを始めたものですが、
この用途だったら、デバッグのやりやすさだけでも、
PHPに軍配が上がるような気がするな
データベースとかはよくわかりません

31 :
趣味プログラマならPHPおすすめするよ。プロ目指すならCから始めた方がいい。最終的にPHPを選ぶことになってもね。

32 :
>>18
腹痛が痛いね。

33 :
>>27
マーフィーの法則(アスキー)シリーズのどれかで
『「そんなの C で書ける」と言う人間は C でプログラムを書けない』
というのがあったね。

34 :

 JSPとPHPはどっちがどういう風に優れているのでしょうか。
 この部分ではPHPが勝っていて、JSPはこの部分が勝っているみたいな。


35 :
JSP 単体と PHP を比較する意味はほとんどない。強いて言えば Java を作っている
Sun 純正だから Java との親和性が保証されている程度。PHP から Java の
プログラムを使うこともできるけど、一人で両方こなすのは面倒くさい。
好きなほうを使えばいいじゃん。

36 :
将来的にロジックを切り離して再利用したり、大量のアクセスが
きたときにスケールアップさせたければJSP+AS
初期の生産性・開発スピードを優先するならPHP

37 :

お返事ありがとうございます。
結局好きなほうを使えばいいんだなーとは思うのですけれど、興味として聞いてみました。すみません。
PHPの本を読んだときに、予算があって、時間もとれるのならばJSPでやるけれど、そうじゃないときは
PHPで著者は仕事をしている、という下りがあって、「そうするとPHPはCGIとしてのPerlのリプレース
にしかすぎず、最終的にはJAVAに駆逐されるのかなあ」と思ったので。
どうなんでしょう。

38 :
PHP4でPHPLIBは使えますかね??
誰かお願いします。

39 :
使えますよ。

40 :
>>37
ジャンボジェットとセスナは別なのりものでしょう?
どっちかだけが生き残る、なんてもんじゃない。
小回りは聞かないが圧倒的な乗り心地、でも高いジャンボ(JSP)と、
軽快にスイスイと飛び回るセスナ(PHP)

41 :
>>40
その比喩は無理があるぞ。

42 :
>>41
そいじゃ、どういう比喩が?

43 :
さぁ?

44 :
PerlやPHPのお手軽さを知ると、
JavaServletやJSPで書くなんてバカバカしくてやってらんない。
Java好きだけどね、たいがいの場合、手間くってめんどくさいだけ。
よっぽと巨大なWebアプリでも開発するんなら、わからんでもないが。

45 :
車とバイク程度かな。
高速道路使って長距離ドライブは車が楽だが、
近所のコンビニにはバイクが便利。
やれることはどっちでも無理すりゃできるが、イージーさ
が違う。

46 :
Perlはバイク、
PHPは電動自転車、
JSPは非オートマ車
Servletは二階建て大型観光バス

47 :
>>46
おぉ! 良いっ! (・∀・)

48 :
どうも違和感があるな。
その「何か大きなすごいモノ」って、アプリケーションサーバを指してないかい?
JSPもServletも本来は手軽なものだよ。

49 :
でかいもの作るには手軽なだけだろ

50 :
JSPはともかく、Servletはちょっと面倒でない?

51 :
Servletはコンパイルが必要という時点で、もう手軽とはいえないでしょう。
場合によっては、つーか、たいがいは一本のサーブレットに対して、
クラスファイルが沢山できる事になるし、jarでパックすりゃ一つに
なるといっても、それだって一手間よけいにかかる事にかわりない
し。とかいいながら、サーブレット使ってるんだけどさ。
サーブレットからPerlやPHPのモードになると、それまで大リーグ
ボール養成ギブスでもつけてたんかみたいな開放感を感じるのは
おいらだけか?

52 :
suExec がかかるかどうかの違いが一番大きくない?
掲示板の場合書き込みに Perl CGI、
表示に PHP って感じにしないと
権限の管理ができないような気がするんだけど。
何かいい方法あるんですか?

53 :
その ギブスで 養成されたか知りたい

54 :
>>53
Servlet を使おうとすると、それなりにオブジェクト指向設計・実装技法を
身に付ける必要があるから、アプリケーションの設計能力は若干高まるんじゃ
ないかな。
まあ Java プログラマー自称していても巨大な main() 作る人もいるから、
「常にそうなる」わけではないけど、少なくともそういう機会は与えられる
よね。
PHP だけしか使っていないと、なかなかそういうやり方が身につかない。
そういう設計・実装が必須ではないし、オブジェクト指向的に書く問題点も
あるし(全体の見通しが悪くなる、書きなれていない、適切なサンプルがない)、
具体的なメリットが痛感できるわけでもないから、これは仕方が無いと思う。
# マンモス本のコードを見れば痛感できるでしょう・・・。
もちろん、そういうオブジェクト指向的な書き方ができるようになることの
是非はまた別だね。書けるようになるまでに必要な労力や、メリットを考えると
あらゆる場合にお勧めするわけではない。
議論がずれてきたのでこの辺はまた別の機会にでも。

55 :
>>53
大リーグボール的魔球のようなプログラムが書けるようになったとは思わんさ(藁
開発にかかる労力としての比喩だよ。でもJavaって悪くない言語仕様だとは思う。

56 :
意外と素人が多いな、ここ。(もちろん全員ではないが)
適材適所はプロの現場、趣味を含めて当然だと思う。
とりあえず企業のサイト(コンテンツ)でPHPはちょっと痛いと思う。
JSPのアプリケーションサーバーだって安いんだからさぁ。
自分は自宅で趣味でやるからPHP使うけど。

57 :
つうかPerl VS PHPだったっけ。
個人的にはWebのアプリケーションとして使うなら
PerlよりPHPの方が生産性が高い(特に小規模なら)と思う。
たとえば、よーいドンで作ったら勝つのはPHPでしょう。
(同等のスキルの人間が作ったとして)
Perlは今後、コマンドラインから使うことにしよう(藁
それはそれで便利。覚えておいて損はないよね。

58 :
PHPってPerlより生産性高い?
PHP3はデバッガがなくて苦労したけれどな。
データベースにしてもDBI使えば変わらないし。
Perlのほうがライブラリが充実しているし、いろんなことが出来ると
思うんだけれどなー

59 :
ツール,参考書籍等においては当然Perlだけど、
それをふまえても生産性はPHPに軍配上がると思う。
PHPが枯れてくればさらに差は広がるであろう。

60 :
>>59
>それをふまえても生産性はPHPに軍配上がると思う。
なんで?
理由は?

61 :
>>58
デバッガについては Zend Debugger がある。有償になるけど。
VB のようなステップ実行とかブレークポイントの設定とか可能みたい。
ただまだ使った経験がないので、どこまでカタログスペック通りかは不明。
>>59-60
そういう議論は定量的な数字を示さない限り「そう思う」「いや思わない」
という水掛け論になりがち。もっとも数字を出しても、その数字をどう評価
するかという別の問題が出てくるので、これが決定的ではないが。
ちなみに会社でプログラミング初心者にやらせてみた感じでは、PHP の方が
受けがよかった。
PHP の場合、HTML 埋め込みになるため、まず素の HTML で書いてみて、
そこにだんだん PHP のコードを入れるという形で徐々に試すことが出来る。
その点がとっつきやすそうに見えるらしい。
Perl だとどうしても最初から Perl 「プログラム」から書くことになり、
その辺の心理的抵抗が大きい模様。
そういう事例もある、程度に読んでほしい。

62 :
ちなみに生産性は、言語仕様よりも
・再利用・メンテナンスを意識したコーディングをしているか
 (コーディングスタイル)
・きちんと設計できているか(特にビジネスロジック層と永続化データ層)
の影響を大きく受けると思うので、Perl だろうが PHP だろうが違いがあっても
誤差程度というのが自分の考え。
Perl は write-once な言語だと揶揄されることが多いが、PHP にも同じ傾向が
見られるような気がする。そうだとすると、どちらもそのままでは生産性は低い、
が正解では?。で、どうやったら生産性が高まるか?という話になるのでは
ないかと思う。

63 :
s/write-once/write-only/
鬱だし脳

64 :
電動ナナシ氏はかなりもっともなことを言うなぁ。
生産性についてはどう捕らえるか、色々あるけど、
HTMLのデザインを先にデザイナーに作ってもらって、
それをそのまま流用できるのは大きな差だと思う。
もちろんPerlだってそうすると思うけど、PHPの方がそこが楽だと思う。
修正が入ったときでも、ソースを書いた本人以外が見ても
デザイン程度の変更だったら割と楽だと思うし。
これに関してはPerlとPHPというよりは、
スクリプト(もしくは言語)にHTMLを吐かせるタイプか、
HTMLにスクリプトを埋め込むタイプかという比較ですけどね。

65 :
あと、メンテナンスを考慮した云々の話しでコーディングしているか
って話しだと、Webの仕事だといわゆる「やっつけ」に近い形で
来ることが多いので(自分の経験に限り)、ちゃんと設計している
暇がないことが多い。
Perlなどの言語主体の作りをする場合は、どちらかと
言うと共通して使えるようなモジュールになってくることが多かった。

66 :
>65
っつーか、自分がそーゆーことになってます。
ホントは俺だって再利用したいんだよ。いろいろ。
でも、結構アクセスがあるんで、requireとかincludeにかかるコスト&
納期を考えると、だらだらとよだれ垂れ流し型のみっともないコードを
かかざるを得ない。んで、クライアントから「前つくったのと同じだから
半分の納期でできるでしょ?」とか言われちゃって・・・。
すまん、グチった。

67 :
>>66
んまあ、それが現実だよねえ。自分も納期間際になって「あーゼロからやり直したい!」と
いう衝動によくかられる。
> クライアントから「前つくったのと同じだから
> 半分の納期でできるでしょ?」とか言われちゃって・
あーそれはよくあるねえ。再利用が完全な形で利用できるなら確かにクライアントの
言う通りだけど、実際には「作り直し」に近い事態になりがちなんだよね。
実際の統計データとして、
・企業が新規開発に投入するコスト
・新規開発にあたり企業が既存のシステムの解析・デバッグに要するコスト
がほぼイコールだっていう話もあるしね。再利用が完全なら前者のコストだけですむはず
なんだけど、実際にはレガシーコードが足を引っ張って倍以上のコストになるという
お話だった。
あと、PHP 使った小規模案件だと、発注者も要求仕様をきちんと詰めないで「こんな感じ」を
連発した非常によく分からない発注の仕方をするから、仕様が確定するのはいつも
納品時ということになりがち(いや仕様は最後まで確定しないで、とりあえず納品する
という方が正確か)。このために再利用性を高めるべく事前に設計をしようと思っても
できないことが多い。これがさらに状況を悪化させると思う。
もちろん、この曖昧な顧客の要望を仕様にまとめあげるのが技術者の能力の一つである
ことは間違いないんだけど、朝令暮改というのは本当に困る。
みんなはどうよ。
# 愚痴スレになってきたかな・・。

68 :
Perlでもヒアドキュメントを使えば、PHPライクに書けるぞなもし。

69 :
>>68
Text::Template を使ったりしてた

70 :
>>67
>朝令暮改というのは本当に困る。
同意。
顧客のニーズを察して汲み上げて・・
顧客本位の姿勢て大切だけど何かと大変ですね。
私は優柔不断な顧客をねじ伏せる力技・小技・裏技を日々駆使してますよ。
楽したいからじゃなくって、最後に顧客に満足してもらいたからこそ。マジで。

71 :
Perlと比べて…。
正規表現めんどい。
リファレンス(=&)わかりにくい。
いちいち array とか list とか面倒くさい。
array_* とか関数名が無駄に長い。何故だ?

72 :
電動ナナシ氏って、所謂「判っている技術者」って感じですよね。
「わかってる」ってのは、技術云々もそうだけど、技術者に仕事を
出す側の論理とかクライアントの要求とかをちゃんと見てる、という
意味で・・・。
一番の疑問は、何故こんな優れた技術者が2chにこんなに頻繁に
書き込んでるのか?ってこと。こんな人をほっといていいのか?
>電動ナナシ氏の会社

73 :
現実逃避だよ・・・。
# まだハマっています。X-(
会社にばれたらやばいだろうな・・・。

74 :
>>1-

75 :
>>1-ああああ

76 :
今回の仕事は某N○○系列の仕事だったんだが、向こうのSEがしっかりしているので、
珍しく仕様がカッチリ固まっていて良い感じ。
ドキュメントも先に書いているしね。
やっぱり大手は違うんすかね。
PerlでもPHPでもないんですけどね:)
これまた某N○○関係のアプリ。

77 :
私、仕事でJSP+Java。趣味でPHP使ってます。
Java系はクラス設計からしっかり作れるから、自分の知的財産として高く売りやすいですね。
通常画面周りをJSPで作って処理自体をクラスとかBean(use Bean)で作るので、
JSP部分をWebデザイナーに流せるのもチームな仕事向きですね
でも、PHPはWebプログラムで欲しい機能が一通り入ってるので好きです。
画像生成だけでなく、PDFやShockwaveFlashまでさっくり作れるのはうれしいですね。
デバッガ無いとか言われてますけど、
ほとんどの趣味Perlプログラマがデバッガ無しで作っている状況で、
エラーメッセージが画面に出るだけ幸せに感じてるのは私だけ?
Perlも一応使えるんですが、C言語から育った世代なので、Java PHPの方が忘れにくいですね。
複数言語使ってると混乱するもので(^^;

78 :
どうしてもPHPでなきゃいけない理由がない。
となると枯れてるとか、どこの鯖でもたいがい動くとか、
「ぺっぷ〜?なんだねそりゃ」なんていわれて説明する手間も
いらないってわけでPerlにおちつくな。

79 :
むしろ「この言語じゃないと」って必然性があるほうが珍しいだろうね。

80 :
>>78
はう? 「ぺっぷ」って呼ぶの?
「ぴいえいちぴい」だと思ってた....。

81 :
>>80
そっちが正解。
でも HTML を「はとまる」って読む人もいるご時世だからね。
世の中にそういう読み方をする人がいても不思議はないような・・。

82 :
「○○言語じゃなきゃいけない」とか言ってるのは一部の風潮であって
TPOではないでしょうか?
会員ページを作るとき、セッションにデータを格納できないPerlではさすがにきついです。
メールアドレスの整合性チェックはCやJavaだと面倒だけど、正規表現が使える言語だと1行だし。
結局自分の持ちネタが多い言語に落ち着くかな。

83 :
あぁ、TPOは私の個人的意見。
仕事では許してくれません。
コールドフュージョン使ってみたい
ところでPerlで画像ライブラリってあるんでしたっけ?

84 :
>>83
GD とか PerlMagick のこと?

85 :
>>84
GDはPHPで動作する奴ですよね?
PerlMagic・・・ImageMagicと言うものを見つけました。
X用のイメージビュアーのようですけど、それを操作して画像処理するのでしょうか?

86 :
>>83
URLキボンヌ。

87 :
GD::Imageとか、Image::Magickとかモジュールがあります。
もちろんそれぞれライブラリが必要。
『WEB+DB Press Vol.1』技術評論社 に記事が載ってたよ。
perlって見た目が嫌いで敬遠してるけど、その膨大な資産は魅力的かも。

88 :
GD
http://search.cpan.org/search?dist=GD
PerlMagick
http://search.cpan.org/search?dist=PerlMagick
それぞれGDライブラリ、ImageMagickライブラリをPerlから
使うモジュールね。

89 :
修正
GDはPHPで動作する
  ↓
GDはPHPでも動作する
PHPのマニュアルにもGDライブラリが必要と書いてました。
ライブラリを呼び出す仕組みがあれば、Javaでも動作しそうですね。
>>86
URLって88が書いてくれた奴で良いんですよね?
それともコールドフュージョン?
http://cfusion.sirius.co.jp/products/cfbegin.cfm

90 :
>>79
言語仕様や性能に言語選択の必然性がある場合は少ないが、
それを使う側の事情に言語選択の必然性がある場合は非常に多い。

91 :
>>89
GD は知らないけど、ImageMagickはJavaインターフェイスあるよ。
http://www.imagemagick.org
ftp://ftp.imagemagick.org/pub/ImageMagick/java/

92 :
age

93 :
245 CGI、Perl 5
305 PHP 1
このアクセスの少なさ、なんとかならんのか・・・
このアクセス1って、俺のことだ。

94 :
>このアクセス1って、俺のことだ。
俺の1は何処??

95 :
>>93
これって書き込み数なんじゃないの?
>>90
「トンカチを持つと、問題がすべて釘に見える」ってやつだね。

96 :
鬱だし脳

97 :
PHPだと、インタフェースデザインとプログラムが分離しにくいから嫌いだ。

98 :
Perlだと、インタフェースデザインとプログラムが分離しにくいから嫌いだ。

99 :
>>97-98
JSPのTagLibはいいらしい。詳しく知らないけど。

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼
【PHP】フレームワークMapleに舌鼓 (467)
【Python】TurboGearsスレ Part 1【Framework】 (174)
PHP を流行らせるには (212)
もうBootstrap3使っても良いんじゃねぇ? (193)
Apache2.x 【新鯖入荷しました】 (646)
WebLogic に詳しい人いません。 (623)
--log9.info------------------
NARUTO ナルト恋愛・雑談510 (1001)
↑と↓のスレタイを合体させるin漫画サロン (319)
魁!男塾・強さ議論スレッド (236)
漫画家の御○漬○苔先生 (280)
とある魔術の禁書目録&科学の超電磁砲強さ議論28 (306)
【星野桂】灰色男達がバラすスレ108【D.Gray-man】 (341)
【リレー小説】〜帰ってきた殺人鬼スネ夫〜 (907)
【山本隆一郎】サムライソルジャー ネタバレスレ3鬼衆目 (729)
IDにるーみっくキャラを出していこう13 (182)
■ドラゴンボールの戦闘力考察スレ■2 (212)
【霊媒師いずな】いずな×沙聖に萌える (378)
【霊媒師いずな】いずな×リンを語ろう (390)
【犬夜叉】殺生丸×りんを萌え語るスレ【殺りん】 (988)
IDにDBが7つ出るまで地球人が龍球を探すスレ21 (917)
【るろうに剣心】四乃森蒼紫×巻町操 (152)
IDスタンド変換スレACT83 (900)
--log55.com------------------
【タラコキハ】いすみ鉄道 19両目【キハニハチ】
阪急神戸線を語ろう!
北陸新幹線・未開通区間スレ2
JR東日本車両更新予想スレッド Part223
関西本線非電化区間20駅目【山城列茶】
「さっさと廃車にしろ」と思う車両47編成目
☆☆JR北海道総合スレッドPART189☆★
【荒らし】工藤大介【ネトウヨ】