我不是要發表什麼新的觀點，只是想問 mega salary 的各位幾個問題。
1. 各位可能都學過 C/C++/Java/Obj-C/JS/PHP/Python/Ruby/Swift/C#，
但有人研究過像 OCaml/Prolog/Scheme&Racket/Lisp/Erlang/Haskell/Algo/Agda&Coq
之類的語言嗎?
2. 如果撇開 ecosystem 的大小不論，各位心裡最鍾愛的語言，心裡認為設計最完美的
語言是什麼呢?
3. 如果各位認為最完美的語言，是像 C/C++/Java/PHP/JS/Python/C# 這樣有龐大
ecosystem 的語言，那這個問題不適合你，但如果不是，你認為為何這些語言
有那麼龐大的 ecosystem 與 API，但你的完美語言沒有呢?
4. 假設，你要把你現在在使用的語言抽出一些核心元素，形成一個 subset，足以完成
你現在所做的工作，你認為至少應該要有哪些語言特性需要被抽取出來呢?
5. 補充一個，假設你已經會一個語言，Java/C#/JS/Python/C 都好，讓你接觸一個新
語言，解決一個原有的問題，你會怎麼思考呢?

你問的問題都是沒意義的 因為所有語言都是turing等價因為現在語言最後都是變成Von Neumann架構 所以核心就只有每次至多一筆資料去執行指令你如果要說subset那就是原本的分類像是funtional prog.object-oriented 之類的Programming paradigms所以根本就不存在A語言能解的問題但B語言不能解

你要這麼說真的是沒錯，這樣 Assembly與C便統一天下了程式語言最終也是轉成 machine code 執行，但它提供的抽象機制，目的我認為是要提高語言的可讀性因為可讀，所以可以傳達，因為可以傳達，所以可以合作的確不存在A語言能解，而B語言不能的問題，除非B語言的設計有本質上的問題

板大獨漏Self

的確不存在A語言能解，而B語言不能的問題 <= 我想到一種狀況，那這樣是不是在努力之後，可以用javascript或是lua之類的東西去寫BIOS以及韌體之類的?

臉書有社群號稱js在寫作業系統

抽像是抽像，可讀是可讀

只要實現組語產生器，還有各專案的變數記憶體配置表高階語言就能碰底層，但如果不是研究或好玩就沒必要

不能因為最後都轉成機器碼就都說這都一樣阿？不然人跟狗都原子組成反正都一樣 這樣邏輯對嗎？為何要有高階語言就是因為用低階語言寫某些東西會搞死人阿不然程式語言都可以扔了大家回去組語 不然寫機器碼好了 XD一堆程式語言和平台架構的最終目的是在做什麼？先搞清楚來因為人類對於過度複雜的東西無法全面掌控 所以才使用切割並且模組化的策略 高階語言也是模組化低階部份功能來的 真正為的是簡化重複出現的問題 以面對更複雜的真實世界需求整個資訊技術事實上都在努力化繁為簡 努力的切割模組 努力的讓後人不要再造輪子 難道這些都沒意義？

樓上所言甚是，程式語言常是為了某些領域的問題所造以減化問題的解決過程,並重複那些好的practice與paradigm

我選給我兩百萬年薪的工作要寫的語言

用 C 刻個 web framework,就能丟掉 ror, node 了(~誤

還好你沒提到Scala 不然先噓再說

糟，我竟壓根地把它忘了.....

其實除了切割模組外 黑暗面是商業考量 甚至我覺得商業考量的影響還多過於業界真正想解決問題呢 XDDD

R大這麼討厭scala哦

我在剛轉行時也覺得scheme很棒，學這個才是cs正統但現在只求做出有那麼一點點價值的產品就好成功或淘汰都是有歷史因素 就跟人類文明一樣而且要比簡單 R5RS 應該沒人比得過吧

我現在只希望能用一個沒那麼多弱點，但可能特性也不多的語言，能夠搭建出具有時間價值的東西，Java 有很多 3rdparty 的東西，ecosystem 極為龐大，雖然用起來很方便，但我更希望能夠慢慢地自己能建構更深的東西，用更簡潔的方法來做事，Scheme、Haskell、OCaml都是很值得一學的語言，不一定能用在真實場景，有時候是因為旁邊的人沒辦法接受太跳tone的語法，但真的可以重新建構寫程式的觀點

推OCaml Haskell不過最近也蠻喜歡Rust的

推這篇，感謝原po的分享

第6點那句話最後翻得不太對 沒有"好使得" 就只是移減少看似需要加入新特性才能彌補短處的缺陷

最後一句翻得怪怪的。原意白話是：語言設計的考量點不該是如何在既有特性上追加更多能力，而是要反其道而行——移除那些造成要追加功能才能使語言更加完善的弱點和限制。

跟大家講個翻譯的觀念，不要侷限在原本的句子而是要把它的意義翻出來。若設計的語言存在不足與缺陷，我們該做的是移除這些缺陷而不是新增功能來彌補這些缺陷

謝謝樓上的修正，我一直不知道怎麼翻比較正確....