コの業界も分野によって随分と異なると思うけど、プログラマというのは1つのプログラミング言語だけ知っていれば何とかなる職業ではないと考えている。
正確に書くと、プログラミング言語以外にも知っておかないとマズイことは沢山あるのだが、言語及び言語的なものに限っても1つ知っていれば済むシチュエーションは少ないと思う。もちろん分野によるとは思うのだけど。
組み込み系といっても色々あるが、私（TCP/IP通信関連のミドルウェア屋）の場合は以下のような言語を使っている。ちなみに何らかの形で納品物として提出する対象となる言語に限っている（実際には他の言語も使う）。
C言語
まあCプログラマなのでC言語を使わないことには始まらない :)
大抵の場合ファームウェア、デバイスドライバ、ミドルウェアはC言語で実装する。言語仕様や処理系の枯れ具合、移植性、ハードウェアリソース等の兼ね合いでC89を使うことになる。
もっともデバイスドライバに関しては少し事情が異なる。Windowsのオーディオドライバを弄ったことがあるが、オーディオドライバに関してはWinDDKのサンプルソースからしてC++で書かれていたりする。MSDNを見た限り、そういうドライバ・モデルのようだ。
ファームウェアやデバイスドライバはターゲット環境に密着した実装をする部分が多い（なので前述のオーディオドライバのようにC++で書く必要があるならそうする）。場合によっては一部をアセンブラ化*1することもあるようだが、私自身は話は聞くけど書いたことはない。
一方でミドルウェアの場合は一転して移植性を考えた実装をすることになる。ターゲットのCPUはH8かもしれないしSH（SuperH）かもしれないしARM9かもしれないしIntel Core i5*2かもしれない。OSもμITRON、Linux、FreeBSD、Mac OS X、iOS、Windowsと色々と考えられるし、そもそもOSを搭載しないかもしれない。どこまで対応するかは要求仕様次第だが、複数の環境で使用できるように実装することが圧倒的に多い。
組み込みLinuxでは、比較的小規模なアプリケーションならC言語で書くこともある。デーモンやコンソールアプリの類だ。古典的なUnixシステムプログラミングの要領で実装しておけばLinux以外のUnix系OSに移植しやすい。そもそもシステムコールがC言語の関数として公開されているので、C言語との相性は悪くない。
個人的事情として、C++を使うとどうしても便利な機能を多用してしまい、実行ファイルが肥大化してしまう。システム全体をフラッシュメモリに格納するような場合、実行ファイルの大きさを抑える必要がある訳で、自分自身が信用ならないのでC++ではなくCで書く。strip(1)は兎も角、コンパイラの最適化オプションは少し怖い。
C++
ミドルウェアよりも上の階層、アプリケーションを実装する場合はC++を使うことも多い。（スペック次第ではあるが）最近は組み込み機器といえどもGUI部分はC++で実装することが多いと思う。
機器に付属するPCアプリはどうだろうか？ ターゲットがWindowsのみならMFCという選択肢もある。C言語で書かれた既存のミドルウェアを静的リンクしてしまうのだ。もしくはミドルウェアをC++でDLL化しておきGUI側をC#等で実装する、という選択もあり得る。GUIをさくっと作る分にはC#やVisual Basicは便利らしいが、残念ながら私は使う機会が無いので分からない。
ターゲットにMacが加わると少し複雑になる。WindowsとMacではシステムプログラミング用の言語もライブラリも異なる。良くある方法として、MVCのModelにあたる部分をC++と標準ライブラリで実装し*3、ViewやControllerにあたる部分を各システム用の言語とライブラリで記述する。
ちなみに私はミドルウェア屋でC言語ばかり使う人なので、C++を使うといっても所詮はbetter Cに過ぎない。それでも、自分が何をやっているのか把握できる範囲で様々な機能を使う分にはC++はそこそこ便利な言語だと思う*4。
Objective-C
iPadやiPhone絡みの仕事で関わる機会が増えたが、「元々Mac OS Xの言語」という意識が強い。Cで書かれたミドルウェアをそのまま静的リンクできてしまう（のでWindowsでいうDLL化などの手間が少なくて済む）ので気が楽だ。
make (Makefile)
私の仕事の場合、ソース丸ごと納品することになる。なのでVisual StudioやXcodeで作成したプロジェクト一式を渡すのなら兎も角、Unixアプリの場合はビルド用のMakefileも書いて納品する。Autotoolsは使ったことがない。
歴史的経緯でGNU makeではなくNetBSD make（pmake）を使っている。両者の互換性の無さは悩みどころだ。
シェルスクリプト
組み込みLinuxの場合、何でもかんでもCやC++で書くのではなく、スクリプトで済む部分はスクリプトで実装することもある。
ただbusyboxを組み込んでいる環境でPerlとかPythonとかRubyとかが使えることはまず無い訳で、泥臭くBourne Shellのシェルスクリプトを書くことになる。dirname(1)が組み込まれてなくてのた打ち回ったのは事実だ。
sed(1)やawk(1)を使っても問題ないのならそれらでスクリプトを書くこともあるかもしれないが、今の所そのような場面は訪れていない。
VBScript
組み込みでVBScriptというのも妙な話だが、実はVisual Studio Installerのカスタム動作用にスクリプトを書いたことがある。
