一般的には情報量の多さから、C/C++、C#、VB.NET、Java辺りから選ぶのがよさそうです。
スクリプト言語は、変数に型をつけないなど比較的単純なプログラムを記述するため、
初めてプログラミングを学ぶ人にとってはやや適切でない部分があるかもしれません（一概には言えませんが）。
どの言語を学ぶかは、「何をやりたいか」で考えると良いと思います。
ゲームを作りたいとか、便利なツールを作りたいとか、そういう目標があれば楽しく学べるでしょう。
例えば、「nekomimiフォルダの中の全画像に対して、ファイル名の先頭に「neko_」とつけたい」などといった、日常でのちょっとした作業（でも、画像が100枚あったら大仕事ですよね）をささっとやりたい場合、スクリプト言語であるPerl、Python、Ruby、もしくはなでしこがおススメです。
Mac? MacでリネームするならAutomatorかAppleScriptの方が楽ですよ。
などがあります。おススメはPerl、Python、Rubyなどを用いたCGIやPHPです。
当然、他にHTMLの知識も必要になります。まあざつとこんな感じで。
最近流行りのページ構成はMVC的発想があるのでグラマ的にもおいしい所は充分にあると思う。てかHTML造ったのはNEXTSTEP使いのイギリス人グラマですよ。URL・HTTP・HTML・世界初のブラウザ、全部彼が原型を造ったてんだから、グラマだってんならこういう偉業を成し遂げたいと思わなく・・・ないかね？
とりあえず、
といった感じで身につけていくのはどうでしょうか。コンパイラ系とスクリプト系はどちらからでもかまいません。
また、関数型言語（Lisp、Ocaml、Haskellなど）の世界に足を突っ込んでみるのも楽しいかもしれません。
さらにPrologなどの論理型言語と呼ばれるものもあります。
Pythonは、オブジェクト指向のプログラミング言語です。 初心者でも分かりやすいのですが、とても奥深い言語です。 習得が容易でありながら、アプリケーション作成、システム管理、ウェブプログラミングなど色々な事が出来ます。 C++やJavaと連携したCPython、Jythonなどもあるのでプログラマの方でも満足できると思います。 他には、IronPythonと言う.NET Framework上で動作するPythonまで出てます。 将来性に優れたPythonを始めても損はしないはずです。これを期にPythonを始めてはいかがでしょうか。
Carbon はやめたまへ。血をみるよ。サポート打切りの噂も絶えない。フツーのアプリなら Cocoa になさい。Xcode （Project Builder）を入れるといいよ。Mac OS なひとは今から何か作るのは無謀でないか。Xcodeでのアプリケーションは次のどれかとなる筈です。
以外におもうかも知れないけど、C++があります。これは 低レベル系の開発で使うだけのようです（註：SSE は Intel が ObjC に未対応なため、C++ だけらしい）。
Objective-C++はC++にObjective-Cの拡張部分をつなげたもので、Safari は Objective-C++で組まれているそうです。ちなみに Safari の WebCore.framework やらのソースコードは公開されてますヨン。
Python や Java、Ruby は Objective-C の Cocoa API が使えます。先述の WebObjects ではWO5より Java化され、PythonやRubyはグルーとしてもですがPython CocoaやRubyCocoaとして一般のアプリケーションも作れます。それからAppleはJavaScriptも力を入れて居て、Widget なんかはコレ。
AppleScriptは知らないとわからないけれど、AppleScriptは（コンパイルして）保存した物を独立したアプリケーションとして使用できます（実体はOSレベルで実行されるアプリケーションコマンドの塊？で、gccされたのとは違うよ）。QuickTime などの基幹機能は AppleScript を遣ってムービー変換ができたりする優れもの。Mac OS の昔はこれを日本語で書けたけれど今は知らない。UNIX コマンドの呼出し（及びシェルからのAppleScriptの呼出し）などの拡張が Mac OS X から増えてます。AppleScript はプログラムで遣う配列やらの概念と簡単な英文法を知っていればすぐ理解できるはずです。昔は、明らかに影響を受けたと思しき、 HyperTalk という物もあったのだけれど、それはまた別の話（AppleTalk、漢字Talk とそういう名前が多かった）。
他にも「Quartz Composer」で簡易スクリーンセーバ（本格的なのはXcodeで作る）ができたり。「WebObjects Builder」でのWebObjects開発は、WebObjects Builderのコードが古いために 10.5 からはできません。Audio Unit、Metadata Importer（Spotlight）、Quick Look Generator、Preference Panel（システム環境設定書類）など小物用のテンプレもXcodeには揃ってます。
上にも述べたけど、Web サーバ系の開発も可能です。また UNIX（カーネルである Darwin は BSD系で 10.5からはUNIXになりました）として使用することもできるので、シェルで遊ぶこともできましょう。Objective-Cが今いちマイナーな言語ですから、言語の紹介を得るのがむつかしいのですが、それなりにドキュメントは揃ってるようです。
流行ってるみたいだね。SDK のダウンロードも結構多いとか。Mac OS X と同じ体系になるけど、微妙に違うので別項として扱うよ。
iPhone SDK の開発言語は Objective-C の模様。理解レベルは「Mac OS X アプリケーション開発に必要な知識（ここ重要）」と「iPhone 用に拡張された API 及び iPhone のハードとしての擧動」を知る必要があります。ですから、Mac OS X アプリケーション（Objective-C、Cocoa API）に就ても参照してみて下さい。基本的にはMac OS X アプリケーションを作る際に必要な知識が大きな比重を占め、iPhoneのみの理解はごくごくわづかな比重となるかと思います。言語理解とCocoaの理解は並行して進めるとよいでせう。
面白いのができたら App Store に発表するべし。SDKとドキュメントはアップルのサイトにある。http://developer.apple.com/iphone/
昨今のコンパイラは優秀で、かなりのレベルで最適化をして下さる縁の下の力持ちであるけれど、コンパイラはバイナリを最適化しているに過ぎない。等差数列の和や等比数列の和を求めるのに、ひとつづつ計算して合算するような無駄な作業の最適化まではできず、高速化するには「公式」を使って記述してやる必要がある。
こういう最適化は、最初に「アルゴリズム」の改良によってなされるけど、実装を変えることで最適化をすることがある。C++ や Objective-C のコードを C で書くとか、Ruby の拡張ライブラリのように、速度面の改良は実装で解決できることがある。
特に Motorola の AltiVec、Intel の Streaming SIMD Extensions（SSE）なんてのは最適化を CPU というハードへ投げるもの。ソフトで改良するよりもハードに合わせた方が圧倒的に早いのは、あたりまえのことだけど、忘れがち。
メモリ管理でもその事は云えるようで、高頻度で参照するメモリは、一定の領域を参照する方が早くなるように設計されている。戸棚を開けたら閉めずにおくイメージ、次に使うと想定されるメモリはキャッシュされるので、ヒープ領域を考慮する。
最近は Multi-thread（マルチスレッド）という遣り方もある。iTunes は MP3 Encoder に lame を使用してるみたいだけれど、Multi-thread も使用する。iTunes で変換を始めるとスレッドが10くらい増えるけど、もし lame で単純に変換するだけだったら、スレッドは増えない。その速度差は結構あるみたいで、どうも三倍は違うらしい。
ところが Multi-thread へ対応するには、かなり面倒な問題もある。CPU 命令だとか、C での実装、メモリ管理だとかは、環境依存だけれど、Multi-thread はメモリの参照の仕方をよく考えないといけないから。並列して計算した結果が確実に取得できる迄は、それを必要とする限り先に進むわけにはいかないし、そういった情報が確認できないといけない。だから、敬遠しがち。
それから OS でみると、Mac OS X の場合はハードを制限するために、ハードに纏るソフトの開発は比較的容易だけれど、他の OS だと少し面倒かもしれない。そういった苦労に見合うだけの最適化が重要で、そして最適化には、CPU の処理はどうなってるか、言語実装はどうなってるか、という知識が不可欠になる。だからプログラミングをやる過程で自然と身に付く。
また OpenCL のような、計算機の数を増やすぜ的な発想とか、Grid COMPUTING のように、連?して計算するヨってのもある。しかしながら、Multi-thread と同じ問題を抱えているのが難点で、こういうのは計算が分割できて且つ計算量が多い場合に有効だよ。
ところで分散処理って GC で mark する（mark, sweep）とかしないとか、そういう問題に近い気がするのですが、どのメモリが参照されてるかというのを複雑なコードから確実に認識するには、それなりのリスク（確実な処理のため）を伴う物が多いので、誰か解決して下さい。
最適化してくと多分 API に詳しくなれます。Apple の手が入ることで、Mac らしさが Mac OS X にはあるわけですが、それがまた知らない人にはわかりづらいということもあるわけで、そこは Windows らしさや UNIX らしさが難解になることと同じです。だから Mac で何か作る時は、Apple がどんな改造を施してるのか考慮しないと、通常の UNIX 的発想が通じないことはよくありまする。
さて Cocoa には NSZone 型というヒープ領域（ゾーン領域）を表す物があって、喩えば malloc_zone_malloc という函数が malloc.h に宣言されてる。これは Kernel の実装に拘る函数らしく、malloc はデフォルトのヒープ領域からメモリ確保してるとか。AltiVec、SSE は、vecLib.framework、Accelerate.framework などを使えば C で使用できる。これはある程度の高速化を望むなら使用するといいけれど、更なる最適化はアセンブラでなす必要がある。
そういえばMulti-thread の問題を解決するよって Grand Central Dispatch（GCD）を出したけど、よくわかんねえ。GCD は OPEN SOURCE なため、FreeBSD に移植された？ らしいけれど、言語拡張はどうなるんだ・・・？
分散処理といえば、Xgrid を使えば、分散処理ができるかもしれないけれど、よくわからない。Xcode では distcc を使って分散ビルドできる。QuickTime API による動画変換は、Final Cut Studio や Logic Studio の qmaster やらで分散エンコードができる。これら分散処理の問題点は、処理が分割できることは明らかなので、従ってネットワーク上でのリソース参照にあって、Apple Qmaster は仮想ディスクをマウントすることで解決してるらしい。Xsan でリソース共有もやってるから、Apple は此の手の事にかなり積極的な気がする。
プログラミングを楽しみたい人やプログラミング自体を勉強したいという方は、
余計なことをあまり考えなくていいPythonやRubyといったスクリプト系がいいと思います。
どちらも、WebのCGIプログラムからGUI、ゲームなどなど色々なものが作れますから、
実用的にも覚えておいて損はないと思います。