raymonandrfsx｜痞客邦

埃及語翻譯我不是要發表什麼新翻譯概念，只是想問 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:二次規劃複變離散線代) : 軟體設計師也是越老越值錢的板上大大們也是從沒破百爬到年薪三百萬的