回答編集履歴
1
怒られたので真面目に書きました
test
CHANGED
|
@@ -1 +1,45 @@
|
|
|
1
1
|
そんなことより Haskell やろうぜ Haskell！！
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
### 低評価で怒られちゃったので真面目なお話
|
|
6
|
+
|
|
7
|
+
#### プログラミング言語について
|
|
8
|
+
|
|
9
|
+
プログラミング言語は様々なものが生まれ、様々なパラダイムを呼び、様々に使われ、様々に廃れていきました。ですが実はどれでもチューリング完全というやつなので表現力は変わりません。極端な話 Python と CSS + HTML5 は同等のプログラミング能力を持ちます。
|
|
10
|
+
|
|
11
|
+
[本の虫: うっかりチューリング完全になっちゃったもの](https://cpplover.blogspot.com/2013/10/blog-post_20.html)
|
|
12
|
+
|
|
13
|
+
|
|
14
|
+
|
|
15
|
+
じゃあお前 C++ のプリプロセッサだけで Rust のコンパイラ実装してみろやっていうのは（面白そうだけど）違う話ですよね。もっとわたしたちは楽して効率的にプログラムをしたいわけです。C 言語だって今でこそ書きにくい言語の代表のように扱われますが、アセンブリを書くのを楽にするため B 言語を生み、それが C 言語になったのです。
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
ですが C 言語や Java、COBOL、FORTRAN みたいにお硬い言語と対象的になんでも動的に扱う LISP というのがあり、その影響を受けた Smalltalk、Perl、そして Ruby や Python、PHP、JavaScript などが生まれてきました。これらはお硬い言語に比べて自由にプログラミングできるということでプログラマたちに大いに受け入れられ、広まっていきました。
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
ところがこれら自由の効く言語は小規模なら問題は発生しにくいのですが、大規模な開発をしようとするとその自由が返って仇になることもわかってきました。正しくシステムを動かすために膨大な規約を持ち込み、それをチームで守るというコストを払わなければいけません。これをどうにか自動化出来ないか。そこで最近再注目されているのが ML という言語が持つ「型推論」という機能です。ML に影響に直接の影響を受けた言語は数知れずあり、また間接的な影響も数え切れませんが、型推論を持つ言語が使われ始めています。例えば TypeScript は非常によく使われている例でしょう。Go も最近増えてきました。海外では Rust の事例も多くなってきています。
|
|
24
|
+
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
このようにプログラミング言語は、表現力はチューリング完全の枠から逃れられませんが、パラダイムを何度も変えています。しかし、プログラミング言語というのは 2, 3 パラダイムが違うものを覚えてしまうと後はだいたい機能の予測がついて学習コストが下がっていきます。その 2, 3 が大変かもしれませんが、誰もが通る道ですので通ってください。もし学んだ言語が廃れ、使われなくなったとしてもパラダイムが似ていればほぼノーコストで移ることが出来ます。パラダイムの違う言語を学んでいれば変化に強くなっていきます。
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
また、コンピューターの世界には「物理の世界に近いほど移り変わりが緩やかである」という法則があります。画面に見えるアプリケーション、特にフロントエンドの世界はとても目まぐるしく流行が変化しますが、それを動かすライブラリ、サーバーのアプリケーション、サーバーを動かす技術、サーバー自体、コンピューターの仕組み……と実際の世界に近くなるほど変化は遅くなります。もし 10 年 20 年通用する技術を身に着けたいのなら基礎の基礎を並行して学ぶことをおすすめします。
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
#### フレームワークについて
|
|
36
|
+
|
|
37
|
+
フレームワークというのは「よくわかってる人が使うととりあえずさっと物ができる便利セット」だと思ってください。つまり**よくわかってない人が使うとあんまりさっとできない**のです。また、フレームワークを使ってものを作るというのはその下に隠れた仕組みというのを意識できなくなります。わかっている人には便利なのですが、わかっていないひとがこれを使うと時々大変なことになります。まずはフレームワークを使わないやり方を学んで、便利そうだったら使いましょう。
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
そしてフレームワークというのは一度誕生すると**肥大化が止められなくなります**。機能がどんどん増えるのです。よいことのように思えるかもしれませんが、選択肢が増えるというのは初学者にとって「何をすればいいかわからない」という状況を作り出します。また、実行時のパフォーマンスにも影響を与えます。「A という機能だけ使いたいのにフレームワーク全部を入れないといけない」ということもよく発生します（密結合といいます）。フレームワークにはこういったデメリットもあるのです。
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
一度便利そうなフレームワークが世に出ると似通ったフレームワークが各言語で出回ります。しかし似通ったフレームワークなので結局できることは似通っています。根本的に新しいパラダイムに移りたいときにはフレームワークを脱し、自らライブラリを組み合わせるしかありません。もっと言えばライブラリすら書く必要があるでしょう。フレームワークを利用したほうが力が発揮できるのか、それとも新しいライブラリから始めなければいけないレベルなのかはあなたのやりたいこと次第です。ですが、その力を持っておくというのは悪いことではないでしょう。
|