これについて、PHP関連の著書で有名な大垣氏が記事をかいています。
http://blog.ohgaki.net/lamp-4

結論から言えば、「言語を替える事はセキュリティ問題の解決策にはなりません。」

古いバージョンのPHPで書かれたコードに脆弱性があると言うが、この点ではPerlやRubyにも同じようなケースは良くあるとの事。つまり言語の問題ではなくバージョンの問題であると。

これで、まつもと氏のPHP批判がどうも具体性に欠ける理由が判りました。だって批判する理由が無いのだから。

それはともかく、ポインターの概念はPHPでは普段意識することないですね。ファイルの読み書きで初めて耳にして、最初は「なんのこっちゃ」でした。今でもよく判りませんが、そういえばCではポインタの理解が鬼門だというのは聞いたことがあります。

あと、僕は破綻するほど複雑なプログラムは書いていないんだと思いますね。そういうのって多分学術系のプログラムで問題になるのでは？

その他、Cの場合では、ある一定の概念が理解できないって人も結構いますね。特のポインター系が鬼門ですね。ポインターによる多次元配列の概念とか、そこで落ちこぼれる人がかならず何人かいます。

変数宣言については、そういえばPHPには何も制約がないですね。というか、制約とは具体的にどんなものかが良くわからない（＾＾；そういう意味で、制約の強い言語を学んでおいた方が良いって話なんでしょうね。

グローバル変数は、$_SESSION[],$_COOKIE[],$_SERVER[]などが予め定義されていますが、それ以外に自分で定義する必要性を感じた事はないですね。確かにグローバル変数はセキュリティー上も良くないですしね。

学生とかに教えていて、レベルがまちまちって言うのは、こうした知識や経験のほかにセンスの差ってあるんですかね？ちなみに僕は、細かく変数宣言をしながら、代入を繰り返すのがあまりすきじゃないんですよ。「お前どっから来てん」みたいな（＾＾

僕自身は、簡単なプログラムを書く場合は、ベーシックを好んで使ったりもしますし、TPOに合わせて言語と書き方は選んでもよいとは思います。ただ、教育としてはある程度、オブジェクト指向は学んでおいたほうがよいとは思います。

悪いプログラムを誘発する要因は色々ありますが、もっともよく見られるのは自由度がたかすぎる点でしょうね。PHPは知らないのでbasicとかで例をあげると、変数宣言の自由さ、処理ライン変更の自由さなどですね。
変数宣言の自由さは、まずデバッグが大変になります。
また、オブジェクト指向の秘匿性カプセル化をくずしてしまう場合がありますし、グローバル変数を多用するとかもまずいですね。わかって使い分けてればいいですが。gotoなどで簡単に処理ラインを飛び越せるので構造化プログラムからはなれやすいなどです。
大体、いいといわれる言語ほど文法の制約が強くなっているといったらいいでしょうか。だから、ちょっとしたプログラムをつくるときには、面倒になります。ただ、教育としては、この制約の強いプログラム言語を一度習得しておいたほうがよいと思います。
その思想は、PHPなどの簡易といわれる言語を使う場合でも、間違いなく役にたつとおもいますよ。

まあ何にせよ、自己流表現が大プロジェクトの妨げになる、という事は理解しているつもりです。ただ、僕が言いたかったのは「PHPを使う人全員がSEを目指している訳でも、将来巨大システムを開発したいと考えている訳でもはない」ということです。例えば、WEBデザイナーが単にメールフォームから実際のメール送信をしたいだけ、というケースはありえます。であれば、汚かろうが何しようがとにかく動けばよい（セキュリティー上問題がない事が前提ですが）。よって、そういう使い方やそれに適したプログラム言語があっても良いのではないかと考えます。

しかし、まつもと氏はそういうのは許されないと「PHPしか使ったことがない初心者がWEBアプリを作って公開するな」と言ってる訳です。それは無いんじゃないか、というのが僕の意見です。

プログラムの一般論として考えると、言ってることはある程度、共感できますね。

確かに、文法上、悪いプログラムを誘発してしまうプログラム言語というものはあります。Javaなどはその辺をよく考えて作られた言語で、最初にぱっと作れませんが、これで書くと文法上、そう変なプログラムにならないし、しらずしらずの内に構造化、オブジェクト化の考えが身についていくと思います。

エンドプログラマーでは、己の才能と責任で乗り切れるので、少々悪いプログラムになっても、結果として正常に動作するプログラムがかければ問題ないわけですが、ある程度以上の複雑なプログラムまたは、多人数でのプロジェクト開発では少々問題がでてきます。

たとえば、システム上流設計者側として考えると、多人数のプロジェクト開発を管理する場合、エンドプログラマーのスキルが低くても、問題がないようにするのが重要です。このためには上流設計で、切り分けして、機能ごとにカプセル化してしまえば、下流での品質ばらつきの抑制やバグチェックが簡単になります。こういう場合にはやはり下流で下手なことのできない、かっちりした言語のほうがあっています。

もうひとつは教育の問題ですね。僕も今まで、学生や研修生などのプログラムの講義・演習を担当したことがありますが、プログラムスキルのばらつきは個人ごとに大きいなというのが感想です。
よくない人の場合、やはり、プログラムの大枠づくりや関数・変数構造の作り方などに問題がある人が多くて、変なクセがついている場合があります。こうなると、巨大プロジェクトをつくる場合の上流プログラム設計にはあまり向いてなくて、後でかなり苦労している人が大半です。
やはり、最初にある程度のプログラム開発の方法論を把握しておいたほうが後々は困らないかなと思います。