新しいプログラミング言語を学ぶということ

プログラマのスキルを判断する際に、特定のプログラミング言語の経験の有無を重視しすぎるのはよくない。プログラマにとっても、雇う会社にとってもだ（関連記事：Javaなんて知りません）。

プログラマとしては、それを実務で使うかどうかに関わらず、気になる言語があれば、積極的に学んでおきたいものだ。

★

前回の記事にも書いたが、何かしらプログラミング言語の経験があれば、他のプログラミング言語を学ぶことはそれほど難しくはないように思う。

もちろん、プログラミング言語といっても、似ているものとそうでないものがあるので、一概にはいえないのかもしれない。例えば、Ｃ言語（手続き型言語）と LISP（関数型言語）とでは、全く書き方が違う。

しかし、職業プログラマが特定の職場で求められる言語ということであれば、ある程度のパターンが決まってくるのではないだろうか。例えば、私の会社であれば、何かしらのオブジェクト指向言語と SQL を覚えれば、なんとかなりそうだ。

★

とはいえ、「似た言語」を学ぶからこそ、考慮すべき問題もある。

端的な例では、いわゆる switch 文に break が必要かどうかという問題がある。C/C++ や Java などの switch 文では、各 case 処理の終りに break を書かなければ、次にある case 処理が続けて実行される。一方で、VB（Visual Basic）の Select 文（Ｃ言語系の switch 文に相当）では、break に相当するものが存在せず、条件に一致しない Case が実行されることはない。このため、VB に慣れているプログラマが、Ｃ言語で break を書き忘れてしまうことがあるのだ。当然、これはバグに直結する。

他にも、VB プログラマがＣ言語で「if(a == b)」と書くべきところで「if(a = b)」と書いてしまう（※１）とか、C++ プログラマが Java で「text.equals("foo")」と書くべきところで「text == "foo"」と書いてしまう（※２）など、言語の微妙な違いに起因するミスは多い。

個々のプログラミング言語ならではの特徴をきちんと把握しておかないと、思わぬところでバグを生むことになるのである。

★

新しい開発プロジェクトの立ち上げ時など、このような「言語の特徴」を、短期間で多くのメンバーに浸透させなければならないことがある。チームとしては、上記のような「落とし穴」をリストアップし、教育や品質チェックの仕組みを整えておいたほうがいいだろう（そうした仕組み作りがしっかりしていれば、人材募集の際にも、具体的な開発言語の経験有無によって間口を狭めてしまう必要もなくなるはずだ）。

しかし、実際のところは、そのような組織的な取り組みが行われているケースは少ないようだ。結局のところ、プログラマ個人の努力に依存してくることになってしまう。

もっとも、根っからのプログラマは、そんなことを「努力」などとは思わない。むしろ、新しい言語を覚えること自体に喜びを見出すだろう。目の前の仕事に必要であるかどうかに関わらず、役に立ちそうな新しい道具があるのなら使ってみたいと思うのは、プログラマに限ったことではないだろう。

しかし、一方で、仕事で必要だからと嫌々ながら勉強するようなタイプの人もいるようだ。その仕事は彼にとっての天職ではないのだろう。もちろん、誰もが天職につけるわけではないのだから、仕方ないといえばそれまでなのだが・・・。

応援のクリックお願いします →