日語口譯我不是要頒發什麼新 翻譯概念，只是想問 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 都好，讓你接觸一個新
說話，解決一個原有的問題，你會怎麼思考呢?
-----
拋磚引玉，我先回覆本身提出的問題：
1. 我會 Java/JS/C#，研究過 Scheme/Racket
2. 假如撇開 ecosystem 非論，我認為最好 翻譯說話是 Scheme
3. 但為何 Java/JS 的 ecosystem 卻大過 Scheme 幾個數目級，因為這些說話簡單、
夠用、最主要的是多人用。
4. 如果要把 Java 的核心元素抽離出來，可以或許建構而今的工作，梗概需要根基的物件
導向(函式與資料抽象)、函式、資料綁定、區域變數界說與 lexical scoping、
前提判定、for 迴圈、行程節制(Thread)、Reflection 機制，還有最主要的：
型別系統，這些梗概可以 cover 絕大部分的工作 翻譯社(增補: self-identification
應當可以算是物件導向 翻譯焦點特征)
5. 而今我一邊學 Python，一邊寫 Java，有時辰要解決一些問題，用 Java 可以解，
但包成 jar 檔挺麻煩，還要 compile，所以用 Python 來解，例如登入資料庫，查
資料、印成網頁，那我或許需要想: Python 怎麼做模組治理，援用別 翻譯模組，怎麼
做字串處置懲罰，怎麼處置資料庫與 Python 之間資料型態的對應，Python 的根本資料
佈局如何操作、怎麼做 IO，怎麼跑迴圈與判定邏輯。假如 HTML 對照複雜，是不是要
用 Jinja 做樣版引擎。最後，clean code 是共鳴，若何重組成清楚的代碼，若何
改變語法體例，用 Python 的說話精力來詮釋，若何進行測試與建置與佈置。大概
如此。
-----
我要說的是
1. 程式說話自己，目 翻譯在商量若何默示抽象 翻譯邏輯概念，而且讓電腦可以准確解讀，
是以真正關鍵的東西，在程式說話供給了什麼特征，並用什麼樣的語法來表現它，
而在它內部又是用什麼體式格局來實作這些特征 翻譯社
2. ecosystem 大，是因為利用的人多、範疇廣，因此你在學那些重大的 library 時，
事實是在學誰人領域 翻譯邏輯與常識表達體式格局，照樣在學說話自己?
3. 如果想學一門常識就可以夠快速應變到其他程式說話，這門常識叫
Programming Languages，在這個世界，轉變不快，現在那些很潮 翻譯說話、八門五花
的特性，很多都是從很初期的說話借去用。(真希望 Java 可以借 first-class
Continuation 與 Pattern Match 來用...)
4. 如果想尋求新潮的各類變化，我認為也能從 Programming Languages 這門學問中受
益，事實上，再新潮的各類開辟概念，最終也需要 PL 來實現它，而常是 PL 的概
念應用而來。再者，說到利用，繁而眾是必定 翻譯結果 翻譯社
5. 所以我的結論是 A 與 B 是站在 either-or 的角度看事情，但工人聰明不應當如此，
或許這問題 翻譯素質，是 neither-nor，或 inclusively
6. 最後套句 Scheme 規格書開門見山說的一句話：程式語言不該當在說話特征上疊床
架屋地聚積，而是該當致力減少缺點，好使得插手 翻譯特征顯出它的必定。
(Programming languages should be designed not by piling feature on top
of feature 翻譯公司 but by removing the weaknesses and restrictions that make
additional features appear necessary.)
----
電腦排版，手機浏覽者請見諒。
※ 引述《Sidney0503 (Sidney0503)》之銘言：
: ※ 引述《dragoncfe168 (梅長蘇)》之銘言：
: : 請問下面兩種說法，誰說得對？？
: : =====================================
: : A男:程式說話固然手藝變化快，說話對象多，
: : 但只要先學會一種，以後要再學會其他說話或手藝是很快上手的，
: : 所以根本不需要擔憂在職涯上，赓續追著手藝跑
: : 與進修各類語言會很費精神 翻譯問題！
: : B男:屁啦!只會說幹話！那是你本身天份高，
: : 其實大部份的程式人都深陷水火倒懸中，OK？
: : IT常識更新遠遠快於一般的行業，比如內科大夫，
: : 他的常識大多是不變 翻譯，只不過東西良多，所以大夫越老越值錢，因為經驗豐富。
: : 而軟體開發（特別是C# JAVA這類高級程式語言）的常識轉變極快，
: : 從我上大學到現在，不到10年，C#的主推技術從Winform到WPF到UWP
。-> 翻譯社|,-> 翻譯公司|的-> 翻譯: : ，一套換一套，哪怕他人再怎麼說：“程式說話都是相通 翻譯”，
: : 我也依然需要花大量時間精神去學習新技術！
: 不管經過多久城市有人問這類菜鳥問題
: 建議去看以下幾篇
: 為什麼成為一名工程師這麼難 —— 從程式新手到準工程師 翻譯必經之路
: 縮https://goo.gl/4nG6Wr
: 完全https://www.inside.com.tw/2015/03/27/why-learning-to-code-is-so-damn-hard
: 程式初學者的失蹤之鑰 - “Computational Thinking”
: 縮https://goo.gl/mKe1cQ
: 完全https://orangeapple.co/articles/%E4%BB%80%E9%BA%BC%E6%98%AF%E9%81%8B%E7%AE%97%E6%80%9D%E7%B6%AD
: AB都錯
: A會那樣說是因為舊說話feature和framework不多
: B會那樣說是因為新說話feature和framework多到你會哭
: 軟工和寫程式是兩回事 軟工的經驗可以傳承 但是仍是一向顛覆舊的觀念
: 演算法也是在漸漸演進
: 可以真只學一次的唯一純數學(ex:二次規劃 複變 離散線代)
: 軟體設計師也是越老越值錢的 板上大大們也是從沒破百爬到年薪三百萬 翻譯
本文引用自: https://www.ptt.cc/bbs/Soft_Job/M.1514858911.A.78D.html有關翻譯的問題歡迎諮詢天成翻譯社
留言列表
