Perl

ポインタのようなもの

• Cではその設計思想からポインタを明示的に使う理由があるが，スクリプトのような疑似コードに実体とリファレンスと明確に分けたせいか，却って煩雑な言語になってしまった感じがする．

型の判別

• リストからスカラへ変換する際にそれがもしリストのリファレンスだったりした場合正しい手順で必要な値を抜き出すまでプログラマ側で考えてやらなくてはならないのは億劫．記号文字の扱いもかなり荒いため可読性も悪くなりがち．

PHP

拡大解釈する関数

• 想定した動作と違った時によくある問題で，どんな型がこようとも「文字列操作の関数だから文字列として評価」してしまうのは戸惑うことがある．

文字化け

• 特に日本語を扱う処理では入力がcp932(sjis)であっても，スクリプト側では既にeuc-jpにされていたりする．サーバのオーナーであれば設定を変えるだけだが，レンタルサーバで安く済ませたい場合はそう簡単にはいかない．

無いものもある

• echo $undefined;してもエラーにならないのでAgileなhackをするのには向いていない気がする．かと言ってissetで保険かけて毎回判断するってのも間抜けだな．

formの複数選択input

• <input name="multisel" value="1".../> 
  <input name="multisel" value="2".../>

  だと正常動作しないし，

  <input name="multisel[]" value="1".../> 
  <input name="multisel[]" value="2".../>

  で評価すると$_REQUEST["multisel"]で取ることになっている．

formの<input name="with.dot.name"...の値がすりかわる

• $_REQUEST["with.dot.name"]じゃなくて$_REQUEST["with_dot_name"]になる．global_registerに対する配慮なんだろう．

Python

unixenをはじめとするCUIユーザとの相性

• Pythonはその言語仕様からワンライナーには向いていないため，sedやawkのようにシェルスクリプトから呼び出したりすることはまず考えられていない．ipythonといったシェルも提供されるが，大半のCUIはbashまたはtcsh，そしてzshだ．慣れたCUIユーザであれば，シェルの対話セッションでうまくいったときのスクリプトをそのままファイルに保存して繰り返し使うため，ますます出番が無くなる．

草の根が提供するライブラリ

• 何か新しいサービスや面白い仕組みが発生するとまずはPerlで突いてみる，ということが多い．その後でPythonやRubyといった同列の言語がマネをする(ときがある)．

学習言語

• プログラミング初学者が読み書きの学習には向くかもしれないが，実務でPythonを使えるシーンがかなり少ない．一部の企業では積極的に使おうとするところもあるらしい．

サーバサイドスクリプト

• CGIのようなサービスをPythonで実装しても日本国内で使える(安いまたはフリーの)サーバが極端に少ない．

バージョン地獄

• 処理系が3つくらい個別のバージョンでインストールされているのがザラ．