  |
はてなキーワード: 関数型言語とは
ラテン語・古代ギリシャ語・サンスクリット語のうち、最低どれか１つは読めるようになった方が良いとは思う。
少し前に、ギリシア詞華集に出てくる女性詩人をヒロインにしたマンガが一部で流行って、それで古典ギリシャ語に手を出した人が相当数いたみたいだが、何らかのきっかけでこういう古典言語に入ると広い世界が拡がってる。
それはともかく、たとえばHaskellを勉強して遅延評価関数型言語の妙味を知り、Rustを勉強してメモリ管理の大変さを知り、Goを勉強してCSP代数の面白さを再認識する、などの知的好奇心を満足させる意味で、各言語の特徴を把握した上で勉強するのはすごく楽しいんじゃないだろうか。
さらにバックグラウンドとして、簡単でも良いので半導体ゲートと同期回路がどうCPUやメモリを作り出していったか、を知ると、よりこれらの「プログラミング言語」というものの妙味を味わえるだろう。
金を儲けたければ、浅く広く勉強した上で、どれか１つの言語に絞って、深く、深く、ライブラリと同じ機能は自前で用意できる程度まで深められたなら、おそらく食いっぱぐれはない。
ならないんだよなあ。
そもそも数学とプログラミングはモチベーションが違うんだよね。数学における証明に構成的証明と非構成的証明があるように、「手続き」というのは数学のごく一部でしかない。それに対して、プログラミングは「手続き」が全てだよね（って言うと関数型とかの人があれこれ言ってくるけど、関数型言語だって結局コンパイラが手続きに落とせる範囲のものでしかない）。
機械学習については、論文書いてる奴も含めて大多数はプログラミング脳なので、最初からコードで発想してそれを論文にするために無理矢理数式で書いてるだけというものがほとんど。無理矢理書いた後付けに過ぎないから意味不明なものも多いしコードに落とせないものも普通にある。だから数式は無視して著者のリポジトリにあるコードだけ見てればいいよ。実用の観点ではコード公開されてない論文は全無視で何も問題ない。
（私は入門書（象の絵のやつ）を読んだことがあるだけで、使ったことはまだありません。）
で、関数型言語の良さをアピールするひとからは、いい意味でのの宗教性というか敬虔さを
私は感じるんですよね。
本題。「関数型プログラミングが『銀の弾丸』である という非常識な常識 2022」 と題された長い文章をみつけました。
ここ。https://kentutorialbook.github.io/functionalprogramming2022
まるで熱心な信者による経典なので、ほとんどちゃんと読んでないし読む気も起きませんが、
流し読みをしていて、目に入った 次の一節 がとても私の心に刺さりました。
ーー我々が暮らしている「現実世界」はミュータブル（mutable）なのです。
を撤回させていただいて、
( https://kentutorialbook.github.io/functionalprogramming2022/#n0.19337518569281165 )
ちなみに、ミュータブルは「可変」、 イミュータブルは「不変」の意味。
まあ私も世俗的なSEをやってるので、まっさきに、↓くらいのことは、思うわけです。
多分、プログラミングの世界での、世間一般の反応も似たようなものかと。
ところがですね。
ところがですね。これ、意見戦わせても、たぶん議論でどうにもならず、宗教間の対立みたいなものになる気がするんですね。
というのも。上の文章でとりあげられている数学やら物理やらというのは、おそらくレトリックでしかなくて。
そのレトリックで、伝えられようとしているものは何かというと、
ビジネスの世界だろうが何だろうが、本来、世界は不変なものとして記述されるべき」
なぜなら、私が隠し持っている信念が、まさにそれに近しいものだからです。
物理学の法則が成り立たとうが、物理学の通じないアナーキーな世界であろうが
世界は不変であり、私自身による世界への介入なぞありえない、と直観的に思っています。
だから 「やればできる」 「世界は変えられる」 「努力は裏切らない」 みたいな言葉は大嫌いなわけです。
この直観を私は自分で勝手に、「離人症的世界観」と名付けています。
この世界観の持ち主は多分少数派で、社会から見れば異端どころか、害悪とみなされるかも。だから、隠し持っている。
関数型言語が好きな人も、おそらく私が似た直観と似たものを隠し持っているのでは、と、
私は思うのですね。
もし、離人症的世界観に基づくコミュニケーションが社会に浸透し、
「自分の意志や感情」すら、あたかもファーストクラスオブジェクトとしての関数のように、
客観的に表明されるようなコミュニケーションが、もしこの世の中に広まれば
そうでもならないと、関数型言語は流行らないだろうな。というのが私の予想。
ま、宗教てものは、広まるときは、あっと言う間らしいですから。
ひょっとしたら20年後くらいには、手続き型言語が滅びているかも。こればっかりは分かりませんけどね。
以上！
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
いらねーよプログラマーとか
じゃねーよアホか
別にいらねーんだよそんな奴
今のDXで一番求められてるのはコンサルなんだよ
「今の流行はこのツールとかこういう方法で、こういう形で実装すればいいですよ！」
とか言う奴はプログラマーな
いらねーんだよ
そうじゃなくて
っていうのとか
ってちゃんと分かる奴
ただの知識としてプログラミングできますとか、つまんねーゲーム作れますとか、しょーもないオープンソースの端っこの方を書きましたとか
そんなの全然いらねーの
ちゃんと人・部署・会社・社会それぞれに応じた世界観を感じ取って
そんじゃそんな能力をどうやったら作れるか、教えてやるよ
そんだけだ
テーマはなんでもいいから社会そのものを具現化して体系化して整理する
これを毎日やるだけ
コンサル出来る奴は話聞きながらそういう絵を頭の中に瞬時に描いている
まぁ、とはいえ悪いがこの手のコンサル業界にはそういうのを小学生からずーっとやってきててなおかつ天才ってやつしかいねーから
おう！外部キー制約を語るとは、RDB を勉強しているのだな？いい心がけだ。増田は外部キー制約があると「どんなメリットがあるか知りたい」のだな？良し、答えてやろう！外部キー制約があると「変なデータが入らない」ということが開発者が『保証』できるのだ。うん、それで？って増田は思うだろう。それで、実例を挙げるけど、sex というカラムを create で作ったときに、そこに insert into で入る値が「男」「女」「その他」というデータに限りたいときが設計者にあったとする。そうすると、「 insert するのは『チンポ』でしょ？」みたいなアホを防げるだろ？もちろん、limit みたいな副クエリで実装しても構わない場合もある。型を指定して、boolean にしたい場合もある。だが、「入るのはこれだけだと思うが、後に追加で変更できる」としたら、嬉しい場合があるのじゃ。まぁ、究極的に OOP や関数型言語、または（古い）命令形言語だと、enum みたいなものなんだよ。いや、だとしたら、enum でよくね？って思うのなら、リプライくれ。答えるから。
Scala や Elm と Lisp やら Haskell と OCaml に SML と関数型のプログラミング言語を勉強したけど、これらが命令型言語に劣る理由を解説しよう。
これは、SQL も同じ問題を持っているが、関数型言語は「こういうふうに動いてね」という解釈をインタープリターやコンパイラが「推測する」必要があるのだ。つまり、書いているときにパフォーマンスをプログラマーが想像できない。
それが、現実的に厳しいのだよ。マジでコンパイラ関連は金にならない領域になってきたので、関数型言語のための独自コンパイラを作る持続可能な組織が無い。確かに、LLVM を使えば x64 や arm といった最新のアーキテクチャに対応できるかもしれないけど、フロントエンドのレベルすら応対が辛い。よって、関数型言語は C言語にてチューリング完全な同等なコードだと「いくら最速に書いても」遅いのである。
例えば if と書いたら、関数型言語は else が必須ですが、命令型言語は else 無しでも動いちゃうのですね。文系の連中が数学的な背景を加味して要件定義できると思うか？違うだろ。毎回、上に else のことについて聞いたら、プログラマーの生産性は下がるだろ。関数型言語は、上が文系だとますますだが、分岐もきっちりとおさえる必要があるから、生産性は命令型言語に劣るよ。
1についてだけ。
＞分かるけれどこれでどうやって動画や音楽のエンコードをしたり画像処理をしたりするソフトウェアになるのか
エンコードに関してはプログラムはエンコードの理論に従って作られているだけ。大事なのは研究者の考えた理論
画像処理は定型の処理の塊でこれも代替やり方は決まってる。"python 画像処理"とかでググれば多分出てくる
＞あるいはWordとかExcelとかがどうやってこんなので作られているのかが分からない
まず基本的な、ウィンドウシステムがどのように実現されているかをWin32アプリベースでも
よいので理解するべき。ユーザーのマウス操作、キーボード操作をどのようにプログラムが認識し、
処理するかが理解できる。この仕組みは基本的にすべてのアプリで共通と思われ。
＞プログラミング入門書を読んでも、一般的に知られているソフトウェアの作り方みたいな事が書いてない
多くの人が共通的な作り方に挑み敗れているわけで、プログラムは10個あれば10通りの作り方がある。
また、クラスレベルで抽象化してソフトウェア構造を整理しようとする、オブジェクト指向(最近は
クリーンアーキテクチャに昇華させる流れもあり)もあるけれど、オブジェクト指向に向かない
対象領域があったり、なんでもクラス病にかかる等して、銀の弾丸とは言い難い。
また自説だが、順次処理を基本とする、手続き型言語はデータと処理が入り乱れることになるため、
全てを設定しきることが極めて困難なため、きれいにすべてを設計するのであれば関数型言語を使う必要が
あると感じている。
＞だからそのフレームワークがどういう風になっているのかって説明からして欲しいって思う。
そのフレームワークが内包するベストプラクティスの量を鑑みれば、中身を意識せずに
＞つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
＞プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
＞これがもう滅茶苦茶イライラする。
天才的な人はコードを書きながら、考えられるけれど、常人はまず詳細設計と言われる
フローチャートを書けるようになったほうがよい。
次に"抽象化"を覚える。"抽象化"を使うことで少なくとも、処理は全体をざっくり設計できる
＞つまり完成しているプログラムを参考にしようと思っているにも関わらずそれがないのでよく分からない。
githubに山のように転がっている。
ただそれを見て理解できるかは別問題。モチベーションを保って継続学習可能な形に
消化できる人間の登場が待たれる
馬鹿に継承を扱わせると、仕事している感を醸し出すために継承を活用せざるを得ない。だから、継承はクソに見える。よって、増田の言いたいことはわかる。
しかし、冒頭で書いたとおり、多態を適切に扱うために継承は必要なのだ。これ以上は書けない。これからもクラスベースの OOP は消えることないであろう。それを書くすべを私は持ち得ていないので、null が消えない事実を例にして語ろうと思う。
21世紀のプログラミング言語のチャレンジの１つはなにか、と言ったら「null 撲滅」であろう。関数型言語は null を排除することに努めたし、Swift 言語は Optional という null がはいっていないことを保証する仕組みを作ったり、Haskell は圏論という数学の概念で応対しようとし、Ruby 言語は &. という「null をスルーするメソッド」を開発した。でも、null は撲滅出来ないままである。
そもそも null とは何か？C言語では、ポインタが指すとそこでお終いだし、Java だとヌルポ（例外）の要因だし、Ruby だと NilClass のインスタンスだし、SQL言語だと「3値論理」では未来のことを記述するためのものだし、言語によって null はバラバラである。つまり、null 自体には特に意味はないのだ。逆に null があると便利だと思わないか？C言語ではポインタに死んでもらえるし、Java だとヌルポがあったら例外にできるし、Ruby だと nil があったらなにかの理由があるからだし、SQL言語だと未来のことは不明と記述できるし。そうなのだ、null はプログラミングに必要なのだ。null をちゃんと扱うのが難しいだけで、null 自体に罪はない。
これを継承、というか多態にあてはめてみよう。多態がないとどうなるか想像してくれ。とてもしんどいことになる。なぜなら...
（作者は眠たくなりました。続きが読みたかったら反応ください。）
プログラミング未経験者から「プログラミングを勉強してみたい、でもどのプログラミング言語をやればいいのかわからない」というような悩みを聞くことがあるので、https://redmonk.com/sogrady/2020/02/28/language-rankings-1-20/ に載っている人気の言語TOP 20について、未経験者が最初に学ぶのはどの言語が良いかという観点で簡単に解説してみます。
対象読者はプログラミング未経験者なので、なるべく難しい言葉を使わないようにしたつもりです。また、正確性よりもわかりやすさを重視しているので何かしら間違っているかもしれません。ご留意ください。
Webブラウザの上で動くプログラミング言語。元々ただの文書しかなかったインターネットの世界に、グリグリ動くページを作りたいという欲求により生まれた。JavaScriptのおかげで今のWebページはグリグリ動きまくりである。
元々HTMLをちょちょっといじる為だけのものだったが、どんどん進化を続けて今は一つの超人気プログラミング言語である。今ではブラウザ上でなくても普通に動かせる（Node.jsという）ので様々な用途で使われている。
ブラウザ上で動くプログラミング言語は基本的にJavaScriptしかないので、JavaScriptはすべてのWebプログラマが学ぶ必要があると言っても過言ではない。
ちょっとしたプログラムを書いてすぐブラウザ上で動かせるので楽しい。そういう点ではプログラミング入門に適していると言えるかもしれない。
機械学習を始めとしたデータサイエンスの分野で激烈に人気のある言語。理由としてはNumPyとかTensorFlowのようなライブラリが充実しているというのが大きく、資産がたくさんあるのでこれからも使われ続けるであろう。
言語としては、誰が書いても簡潔で読みやすいコードになる傾向にあり、小さいプログラムを書くにはいい感じである。米国ではプログラミング教育にPythonがよく使われているという話も聞くし、初心者がプログラミングを始めるのにはいいのかもしれない。
将来AIやデータサイエンスをやってみたいと思うのであればPythonから始めましょう。
ランキングでは常に一位に近い順位をつける言語。Javaができた当時は色々と革新的だったらしく、組み込み業界からWebまで流行りまくっていた。今でもその名残か使っているところは多い。過去の資産やプログラマの数が多いのが一番の理由だと思う。AndroidアプリもJavaで書く（もしくはKotlin）。
実行速度が速く、また下位互換性がしっかりしているので過去に書かれたコードが新しいマシン上でも動きやすいのが長所。短所としては、歴史ある言語で下位互換性を保っているため文法が古い感じがする。タイプ量も多くなるし、学習コストはJavaScriptやPHP, Ruby, Pythonあたりに比べると高い。
正しく使えば強力な言語だが、日本のクソSEもどきは全員（自称）JavaエンジニアであることがJavaが毛嫌いされる理由の一つになっている[要出典]。いわゆるGAFAもJavaをかなりヘビーに使っているので要は玉石混交ということである。
Androidアプリを作ってみたいというならJavaからはじめるのはアリ。
Webページを作るためだけに生み出された言語。プログラマの数が非常に多い。日本で求人が一番多いのはJavaかPHPであろう。
初心者でもとっつきやすく、すぐに動くプログラムを作れるので入門に使われることも多い。学習コストの低さはトップレベルである。しかし基本的には古くてダメな言語とみなされており、PHPで作られたWebサービスは脆弱性が多いという都市伝説もある。真実は闇の中である。
近年のバージョンアップで比較的良い方向に向かっている（と個人的には思う）ので、選択肢としては意外と悪くないかもしれない。
Microsoftが生み出した言語で、.NETというプラットフォームを使ってWebサービスを、Unityというゲームエンジンを使ってゲームを作ることができる。
最近有名なのはUnityで、今やほとんどの3Dソーシャルゲーム（の一部分）はUnityで作られている。そう考えるとC#のプログラマは結構いそうだし将来もある程度安泰かもしれない。もちろん.NETも広く使われている。
ただし.NETもUnityも触らない人にとっては基本的に縁のない言語である。
なんかゲーム作ってみたいかもなーと思う人はC#から始めてもいいんじゃないでしょうか。
C言語に色々な機能を足しまくってできた巨大な迷宮のような言語。言語仕様は複雑怪奇だが実行速度は全プログラミング言語中でも最速レベルなので、パフォーマンスが重要な開発において使われる。アプリやサービスというよりは、それらを作るためのライブラリ、プラットフォームなどを作るときに使われることが多い。Web系の会社でいうとGoogleなどは主にC++を使っている。
基本的には初心者が触る必要はない。競技プログラミングを極めたいとかならC++からはじめてもいいかもしれない。
このランキングの中で唯一、日本人によって作られた言語。作者のまつもとさんは世界的有名人である。ちなみに島根県出身、在住。
プログラミングを楽しくすることがモットーらしく、確かに書き味は良い。また作者が日本人なこともあってか日本語情報が多く、情報収集という点ではとてもやりやすい。
Ruby on RailsというWebサービスを作るためのフレームワークが世界的に大ヒットしたため、必然的にRubyの知名度も上昇した。少し前まで日本のWeb系スタートアップは猫も杓子もRuby on Railsといった様相であった。今は少し落ち着いたようだが今も人気は根強く、Web系プログラミングスクール等ではだいたいRuby on Railsを教えているとかいないとか。
Webに興味があるのならRubyから始めるのが一番無難な選択肢と言える…のか？まあ悪くはないと思う。今でも需要は多い。スクールに行きたいのであれば黙ってスクールのカリキュラムに従いRailsをやりましょう。
これは他の言語とは毛色の違う言語である。というかCSSはプログラミング言語と呼んでいいのだろうか？
CSSはHTMLを装飾するためのものである。字に色をつけたり、背景を変えたり、レイアウトやサイズを変えたりするのは基本的にCSSの役割である。
すごく大雑把にいうと、HTMLで表示する内容（文章や画像）を定義し、CSSでその見た目を整え、JavaScriptで動きをつける。というのがWebサービスの”見た目”を作るやり方である。
なので、Webに興味があるのであればある程度はCSSの知識が必要である。が、これ単独で学ぶようなものではない。Webサービスを作る時についでに調べて少しずつ覚えていけば良い。
TypeScriptは比較的新しい言語で、JavaScriptをさらに拡張したものである。Microsoftによって開発されている。
プログラムにはデータの型（Type）というものがある。例えば「1」や「2」は数値型、「あいうえお」は文字列型といった具合である。大まかに言うと、この「型」に対して厳しい言語は型チェックによりバグの混入を防ぎやすいがプログラムを書くのが大変、というかコード量が多くなる。型が緩い言語はサクサクかけるし短く書けるがバグを生みやすくプログラマの力量が問われる。ランキングの中だとJavaScript, Python, PHP, Ruby, Perlあたりは緩く、Java, C++, C, Swift, Go, Kotlinあたりは厳しい。
そんな中、世で広く使われているJavaScriptの型チェックが緩すぎるのでもっとちゃんと型をつけたい、そんな要望を叶えるのがTypeScriptである。基本的にJavaScriptを理解している人間が使うべき上級者向け言語というのが現状なので、初心者が始めるには適していない。
ただしこの先主流になっていく可能性は大いにあるので、どこかのタイミングで勉強してみても損はしないと思う。
C言語は基本的にOSを作るための言語である。OSというのはWindowsとかmacOSとかLinuxといったもので、マシンを動かすための基盤となるソフトウェアである。AndroidスマホにはAndroid（という名のOS）, iPhoneにはiOSが載っている。コンピュータは基本的にOSがあって初めて動かすことができ、OSが提供する機能を使ってブラウザやスマホアプリなどを動かせるのである。
というわけで、初心者が学んで実用的なものではない。ただしC言語というのは世の中の様々なものの基盤になっており、他言語の文法もC言語から拝借しているものが多い。例えばC言語をある程度勉強していればJavaやPHPなどはなんとなく雰囲気で書けてしまったりする。
そういうわけで、コンピュータサイエンスをこれからちゃんと学んでいきたいという人（大学生とか）はC言語から始めるのもいいと思う。ちなみに筆者は初めて書いた言語はCであるが、意味が理解できるまでに２年かかった。才能がないとこうなるので注意。
SwiftはAppleによって作られたAppleのための言語である。iOSアプリ（iPhoneアプリと言い換えても良い）を作るためだけに存在している。
言語自体は他と比べて新しいため文法や機能がイケてる雰囲気があるので基本的にはいいのだが、iOSアプリ以外で使っている人は多分世界で5人くらいしかいないと思う。なのでiOSアプリに興味がない人はやめておきましょう。iOSアプリを作りたいあなたは他に選択肢はない。Swiftをやりなさい。
Swiftが生まれる前はiOSアプリを書くためにObjective-Cが必要だったため、多くの人がこの言語を使っていた。が、今はSwiftがあるので、古くからあるObjective-C製アプリをメンテナンスする時以外に使う機会はない。名前すら覚える必要がないので存在を忘れてしまって構わないが、これだけ順位が高いということは多くの企業がいまだにObjective-Cで開発し続けているということであり、ニッチな需要はこれからも残るのかもしれない。
Scalaは関数型言語と呼ばれる言語の一つ。Javaの親戚みたいなものなのでJavaとの連携が容易であり、上手く使えば性能も出るしコード量も少ないしバグも少なくて最高、な感じらしい。が、その分難易度が非常に高いので初心者が手を出すものでは絶対にない。どんなに早くても他に二つは言語を覚えてから勉強しましょう。Javaを覚えてからやるのがベター。
正直ほとんど書いたことがないのでよくわからないが、ビッグデータというワードが流行りだした頃はデータ解析用途でかなり流行っていた。その後機械学習やAIブームが来て、今でも現役で使われてはいるがPythonがどんどん勢力を拡大しているので少し目立たなくなってきた、というのが個人的な印象である。まあプログラミング初心者が最初にやるようなものではないことだけは確かである。
Go言語は比較的新しいGoogle製のプログラミング言語で、Googleのように巨大なシステムでの使用を目的に作られたものである。しかし実際には様々な企業が利用しており今一番勢いのある言語と言ってもかもしれない。
他のプログラミング言語の良い点や悪い点を参考に設計されており、実行速度の速さと生産性（プログラムの書きやすさ、読みやすさ）を両立できるような言語になっている。ただし、機能を増やすのではなく本当に重要な機能だけに絞るという思想があるようで、他の言語に慣れていると機能の少なさに不便を感じるかもしれない。
学習コストが低いという点では最初に学ぶ言語として適しているかもしれないが、GoだけでWebサービス等をサクッと作れるのかというと微妙なので、アウトプットを出しにくいというのはあるかもしれない。
シェルというのはテレビなんかでハッカー的な人間がPCを開いて謎の黒い画面に白い文字を打ち込んだりするアレである。説明としては正確ではないがまあ大体そんなもんである。何が言いたいかというと初心者が最初に学ぶとかそういうものではない。しかし実際に開発の仕事をやるとシェルの知識はあったほうがいいし、シェルに多少詳しくなるとPC上でテキスト操作をしたりファイルをいじったりというのが便利にできるようになる。ただし（通常は）極める必要はない。
Shellと言っても実際にはbash, csh, tcsh, zshなど色々あるのだがそれらをひとまとめにしてShellとなっているようだ。
PowerShellは上のShellの親戚みたいなもので、ShellがMacやLinuxで動くのに対しPowerShellはWindowsで動く。そんだけである。あと正直あまり知らない。
ランキングの中ではかなり昔からある言語で、サーバーと呼ばれるマシンには大体Perlが入っている。そのくらい市民権を得た超有名言語で、C言語やC++で書くほどでもない小さなプログラムはとりあえずPerlで書く、というくらいには広く使われていた。インターネット初期はほとんどのWebサイトはPerlで書かれていたとかいないとか。PHPなどの登場はその後である。
今でも広く使われてはいるが、RubyやPythonがPerlの後継的な位置付けであるため、初心者が新しくPerlを学ぶメリットというのはあまり思い浮かばない。何か特定の目的があるのであればいいと思う。
Kotlinは簡単に言えばBetter Javaである。Javaをもうちょっといい感じに書きたいという気持ちで作られた言語で、Scalaと同じくJavaの親戚のようなものである。
ランキングの中ではSwiftと並んでかなり新しい部類。AndroidアプリをKotlinで書けるようになったことがきっかけで人気が爆発的に上昇、今ではWebの開発にも使われていたりする。
とは言えまだまだ新参者といった感じで、ドキュメントなどの情報も他の言語に比べると物足りないので初心者には厳しいかもしれない。
言語自体はとてもいい感じなので、もう少しコミュニティが成熟してくれば最初に学ぶ言語の選択肢として有力になるかもしれない。
HaskellはScalaと同じく関数型言語である。ScalaがJava的な書き方でも動くの対し、Haskellは「純粋関数型言語」と呼ばれ、ランキング中の他の言語とは一線を画した書き方になる。どう考えても初心者にはオススメしない。少なくとも他に二つは言語をマスターしてからやりましょう。
なんとなくWebに興味がありそうならJavaScriptかRubyもしくはPHP、Androidアプリに興味があればJava、iPhoneアプリに興味があればSwift、AIやデータ分析に興味があればPython、3Dゲーム開発に興味があればC#。この辺りをやりましょう。
特に目的がないのであればフィーリングで選んで大丈夫ですが、やめておくべき言語というのはあるのでその辺だけ参考にしてもらえれば。
なお筆者はただのヘボプログラマであり、大好きな記事（http://www.mwsoft.jp/column/program_top10.html） の現代版かつより初心者向けなものを書いてみたいと思ってこの記事を書きなぐった次第である。あまり真に受けないよーに。
